Placing copper strips on our board game panel

We're making a matrix of hall sensors in a 280mm x 280mm square. Getting PCBs made this size is really expensive (especially after the Brexit vote which made the GBP/$ rate pretty piss-poor, so buying anything from China has suddenly become quite expensive!).

But we don't need a complicated PCB - just copper strips running up and down and left-to-right that we can stick some hall sensors to will do just fine. So that's what we're doing, with copper tape.

After marking out the places for the hall sensors, we need to place the horizontal copper tracks for our hall sensors.


This video only ever had an intended audience of one. We made it to give to one person who hadn't seen any of the ongoing builds, to see if they could understand and follow it. It's poorly lit, the sound is terrible, the noise from slurping coffee is distracting, and hands and arms get in the way all over the place. 

Making an electronic board game playing surface

It's been a while without posts, but that doesn't mean nothing's been going on at Nerd Towers. In fact, quite a lot has. And in real-life work too (but that's all confidential, hush-hush, say-no-more). But one of the things we've been playing about with is CyberLink Power Director (Deluxe) to make some videos.

Now video isn't our preferred format. Written words and pictures are what the blog is all about, not videos. Some people make great video blogs - but there's a degree of dedication in editing, lighting, getting everything "just so" required that we simply can't commit to. Whether it's because we're working in a poorly lit loft, a messy, noisy hackspace, or a freezing cold shed in the winter, videos just don't work for us right now.

With all that said, however, we've been asked to put together an instructional video, demonstrating how to create our electronic board game playing surfaces. So here goes with the first rough cut.

This video only ever had an intended audience of one. We made it to give to one person who hadn't seen any of the ongoing builds, to see if they could understand and follow it. We gave them a kit of laser-cut bits, some components and wanted to see if they could make a board section, without any intervention, just by watching the video.

It's poorly lit, the sound is terrible, the noise from slurping coffee is distracting, and hands and arms get in the way all over the place. But that's partly the point of it - so when we come to make the "proper" version of the video, and have gone to the trouble of hiring a properly lit studio and all the right video equipment, we know what to avoid doing and where best to put things and so on. 

The quality of the video is terrible. But in the name of sharing what you do and all that, here goes....

Files and links to the templates, schematics, firmware and all that will be released as soon as we're happy that they're complete - at the minute, we're changing things as we go; making a tutorial video really does show us where things we thought we'd finished actually need much more improving upon!

EDIT:

On reviewing this, perhaps we should have created an introduction video, showing the final thing working, to demonstrate what it actually is we're creating! But there are more than just one or two posts throughout this blog that bang on incessantly about the electronic board game idea. So maybe not.

Unity fonts PC vs mobile

Unity is a great, cross-platform development environment. Ok, it uses crappy C# and Monodevelop (which, despite it's problems, knocks crappy Visual Studio into a cocked hat!). But it's pretty good.

The 3d engine is great, the built-in physics work well, and the asset store is a god-send for us non-artistic coders who are used to placing blocks, cubes and pyramids as place holders in our games and never really progressing from there.

But Unity is also a bit buggy.
Sometimes it just craps out and closes. Sometimes Monodevelop just throws up a runtime error and wipes out your latest code changes. But these things are few and far between (unless you're working with a particularly badly written asset-store script).

And we've got a particularly quirky bug in our latest game/app for our electronic board game. It's all the more frustrating because it only appears after compiling and deploying onto a mobile device. On the PC, and in the runtime/test environment, everything works as it should. But on our mobile device, something as simple as changing a textbox is causing no end of headaches.

(in the editor, click the boxes in the bottom left, and the character successfully changes and the character name and weapon text changes as it should)

[image]

(on the mobile device, each time the text is updated, the previous entry looks like it remains on screen, creating a white blobby mess instead of clear, easy-to-read text)

Also we're struggling to understand how lighting works - particularly baked lighting and optimising for mobile. The first time we baked the lights for this demo scene, the bitmaps for the textures were updated and had an amazing, realistic looking set of shadows on them. But every subsequent compile rendered the entire scene as black (as if no lights were present in the scene).

The only way we've managed to make our characters visible again is by using an unlit shader to render the scene.

Is this another bug? Or just a fundamental lack of understanding of Unity?
Or both?

Troubleshooting WTV020-SD-16P and arduino

Today was quite a trial, getting our .ad4 files playing consistently well on a WTV020-SD-16P module with an Arduino. We'd had this running for a few weeks, and all appeared to be well. But today, after we put some different .wav files onto the SD card, and tried running it from a usb-based device, things started to go awry.

It's not that the sound files wouldn't play - they did. But quite often they would "clip" during playing; so after a second or two of sound, the audio would stop, but the module would remain in a "busy" state, and refuse to play any more sound files. The problem was particularly noticeable if we interrupted one file that was already playing and tried to play a second file.

Unfortunately, there were a lot of changes between the module we had working (running off an Arduino Pro Micro at 3.7v with a lipo battery) and the one that gave us so much trouble today (an Arduino Pro Mini, off a changeable 3.3v/5v laptop usb supply).

• We were using a different SD card - although both were branded Sandisk, it's quite possible that one, neither or both actually were! The working sd card was 2Gb, the non-working one was 1Gb.
• We were using a different power supply - the working module was powered off a 3.7 lipo, the non-working one was problematic at both 5v and 3.3v
• We were using different sound files - though even when we copied the .ad4 files off the working sd card onto the non-working one, the problem remained.

Clipping has already been identified as a possible problem with these modules.
Because the module uses the data instruction 0xFFFF to stop the audio playing and values 0xFFF0-0xFFF7 to change the volume, any clipping in the audio data might accidentally fire the "stop" command

So we made sure that all our sound files had no clipping in them. But the problem remained.
We tried copying the working .ad4 files onto the non-working sd card - but the problem remained.
We tried powering the non-working device off a lipo battery - but the problem remained.

We tried playing each sound file in it's entirety, instead of interrupting the file and trying to play a different one, mid-way through. Success was more frequent. But every now and again the module would "lock up" and get stuck in the busy state.

It was starting to look like we had two identical-looking modules, potentially with different firmware versions handling how the audio data is read and played back off the SD card. And that's when Steve had a bit of a breakthrough - a full, complete, FAT-format of the card, then copy the files onto the disk in one go (instead of copying them one-at-a-time).

When we did this, the audio playback worked as expected.

The more we pondered why this was, the more we were reminded of when we created our own audio module a few years back. Parsing FAT tables was quite arduous. And most of the time, a file was written to disk using consecutive sectors. So when the file was written to a blank, virgin disk, it would be written onto sector one, then two, then three etc.

We spent quite a bit of time making our playback routines work with a FAT-based file system. It was tempting at the time to simply find the start of the file and assume that is was written on consecutive sectors - it would have saved a lot of messing about every 512 bytes! But while we went out on a limb to ensure that our playback routines would work with files anywhere on the disk, it appears that the WTV020-SD modules don't....

So if you've copied files onto your sd card and then deleted them (in doing so, the 8.3 file format name is simply prefixed with a ? character) then it's quite possible that any subsequent file might get written to sectors one, two, then nine,  forty-seven etc. The FAT table does the job of bringing all the file fragments together.

But if your playback routine assumes that the file continues on consecutive sectors, it's easy to see why playback would fail. And it would also explain why the WTV020 module doesn't like playing back files that have been copied onto a disk after other files have been deleted off or moved around on it.

So, in short, to get your sound modules to work consistently well, always format the SD card fully before copying your files to it. Not a "quick format" (we tried that, it didn't work, since quite format simply blanks down the FAT table but leaves the data still written on the sectors). But a full, slow, 3-4 minutes to blank a 1Gb disk type format.

Do that and everything should be golden!

Arduino Pro Mini - it's ok as it is

Sometimes, making custom PCBs can be quite fun. There still remains - even after all these years - that little tingle of a thrill when you boot up your custom circuit board and everything works.

It's like committing to your idea. Once etched in copper, there's no going back and changing it (although given the number of times we've forgotten to add a ground plane, it is easy to tack on a wire or two to correct a couple of mistakes!),

I still love making PCBs (at least, I do, when they work). But that's only for one-offs or small volume prototypes. The idea of having to make 100 identical circuit boards leaves me cold.

Which is probably what Tony was thinking when he asked why, for our latest board-game-controller-idea, we'd stuck a "hulking great big atmega" onto a board and simply extended all of the i/o lines to the edges.

But that's all we actually need - we're multiplexing an array of hall sensors, and sending the data out to a bus-connected serial port. That's all there is to the board! Size is important, so we made the board as small as we could. But not everyone is a whizz with hand-soldering surface mount parts, so we used the large, through hole components.

So he asked "why are you making your own boards? Why aren't you using an Arduino Pro Mini?"

And we couldn't think of a single good reason.
Although not everyone may be comfortable hand-soldering surface mount parts, there are more people comfortable with ebay than a soldering iron - so why not just buy the boards, ready-made?

It seemed like such a dumb question. Which made our current approach look even more stupid! So that's what we're doing - not only going open source, but using off-the-shelf parts. Steve would be so proud!

Inkscape to draw PCBs

Of course, drawing PCBs with Inkscape is an utterly ridiculous idea. After all, that's what ExpressPCB is for, right?

Well, 99.9% of the time, we'd agree with that. ExpressPCB is indeed a brilliant bit of PCB design/layout software. It encourages you to lay things out in a nice, neat grid, with perfectly perpendicular lines and 45 degree elbows on all your joins. It's great for making professional-looking boards with 90 and 45 degree angles.

But for this one particular project, that's a bit of  a restriction.
We're looking to put 12 hall sensors around a ring. Which means we want to space them at 30 degree intervals. And ExpressPCB doesn't like rotating anything that isn't 90 (or 180) degrees. So we had to try something else.

Which is where Inkscrape came in.
Using ExpressPCB to get the dimensions of our components the right size, I "printed" the document to a PDF document (using the excellent CutePDF virtual printer) and imported that into Inkscape. From there, I could add and embellish as much as I liked to get the final PCB design!

And suddenly, without the constraints of 45 degrees, the artwork started to get a little bit more... well, arty. I think I've been hanging around artists and designers too long this month!

Through hole as surface mount components

We love surface mount components at Nerd Club. Not just because they're tiny (although miniaturising designs to as small an area as possible is quite fun sometimes too) but because they eliminate the need for all that fussy drilling.

Putting a 1mm hole in the centre of a 2mm pad is straight-forward enough. But if you're soldering up a 40-pin DIP and a number of wire-pads for socket connectors then all that drilling can make your eyes go funny! Surface mount components mean far fewer holes, which means more time making cool stuff and less time hunched over a dremel drill.

We've already come up with a number of designs for our electronic board game, using surface mount components. But, going down the open source route, we're also acutely aware that not everyone is as confident at soldering, or has the same degree of practice we have, with soldering tiny little surface mount parts.

Coupled with the extra difficulty when soldering to homebrew boards (there's no solder resist to ensure it only goes where you want it, so bridging tracks is quite easy to do) we thought about how best to make the controller PCBs as simple as possible to solder.

Now it seems like through-hole is obviously the way forward; everyone with a soldering iron has probably soldered through-hole components in the past. But that then means that our PCBs would have a load of components on the top, and a whole load of little spiky bits on the bottom - neither surface would be completely flat (which would be preferable, so you can stick the flat part of the board to be flush with the bottom of the playing surface).

Through-hole components are larger, and therefore easier to solder. So we came up with (yet another) compromise: use through-hole components (for their larger size) but treat them as if they are surface mount components.

So the components go on the "copper side" of the PCB, but have much larger pads and legs, for the homebrew hobbyist to have a go at soldering.

(our "surface mounted" through-hole atmega DIP chip waiting to be soldered in place)

This approach has meant that pretty much all the designs we've spent the last few evenings working on are now redundant. But that's just a casualty of the rapid-reiterative-design-process we're embarking on - not to make the PCBs the "best" or the smallest, or even the cheapest; but to make them the easiest for most people to work with.

(checking the overall height of the board + mcu against 6mm thick mdf playing surface)

(before soldering, we'd snip the legs off, to make the understand completely flat and flush. By turning the entire thing upside-down we can more easily see that it fits within the profile of piece of 6mm thick mdf)

More updates with more designs as they are worked on (and, probably, discarded!)