Electronic board game - more than one section at a time

Having got one board section working, we got straight to work soldering up a second one, to see how the two would interact with each other.

All our board sections share a common serial tx (transmit) line, so we had to make a slight change to the firmware. When any board section is not sending serial data, we need to make the tx pin high-z or high-impedence (so it's treated as being disconnected from the board). For the PIC microcontrollers we're using, this simply means, turn it into an input pin.

If we leave all tx pins as outputs, when not transmitting, they're pulling the output either high or low (depending on the last state set in the firmware code) and we want them to be floating about - basically if they're not being used, don't let them influence the tx line at all.

After getting success with one board section on it's own, the next step was to see how it worked with two or more board sections connected together.

So after updating the firmware, we connected one board and checked it was still working (firmware updates are a great way of introducing bugs and while you're trying to resolve one problem, it can often be a completely unrelated something that is causing another!). After confirming that the firmware update hadn't broken anything, we plugged in another board.

Each time the playing piece is moved we get the square number in the lower 6 bits, and a 1 or a 0 in the MSB to indicate whether the piece has been put down or removed. Look out for values starting 0x80 or 0x90 when the piece is put down, and values less than 0x24 (36 in decimal) when the piece is removed.

The video shows the serial output from our test firmware after a second board has been plugged in to an already live, powered board. We get a broadcast message telling the host which board has just been plugged in (and in this example, it also reports the initial state of each input pin being used - this behaviour will be amended in future versions).

You can see as the playing piece moves from one board section to the other, the square numbers reported back to the host change (since one section is rotated in relation to another) but all that can be handled by the host's software, so long as it knows which way around each section is facing. At the minute, both boards report back their serial numbers as 0xFFFF because my PIC programmer doesn't burn values to EEPROM when it writes firmware down to the device. I need to build something that will allow me to write data to the PIC internal EEPROM (over serial perhaps?) to give each board section type a unique serial number/identifier.

But other than that, it's pretty cool to see something working properly, at long last!

Electronic board game - success at last!

It's been a long time coming, and we've had to make yet more revisions to our final design (strobing multiple connected sensors in a keypad type arrangement didn't work either!) but we've finally managed to get a positive result with our digital board game.

Our new board section has had to undergo major revision, and we've had to cut yet another design for the top layer/mdf - including cutouts for our surface mount SMT resistors (some of which are 0R resistors, acting as vias on a single-sided board)

Here's the output from recent testing:

We placed a magnet over each of the 12 input points on the L-shaped game board section and wrote some firmware that sends data over the serial connection whenever any of the sensor inputs change.
The output message begins with a zero value, followed by two bytes (the serial number of the board section) and a single byte character to indicate which square has caused the message to be sent.

For example, square one on our board section generates the message 0x00, 0xFF, 0xFF, 0x8D

The value 0x8D translates into binary value 10001101
We're using the first (most significant) bit to indicate whether a piece has been added (1=piece added, 0=piece removed) and the remaining bits to indicate which square the activity took place over. In this case, 1101 is the decimal value 13 and the leading bit (msb) 1 tells us that a piece has just been added.

Although our board section is an L-shape, and the playing piece was placed over the first square on our board, the number coming back is 13. This isn't a mistake: we're treating each of our board sections as if they have been "cut out" of a 6x6 square

The next value was 0x0D. In binary this is 00001101.
From the previous example, we can see that this represents the decimal value 13 and the leading (most significant) bit is zero - indicating that the playing piece has been removed.
The next value in the list is 0x8E. This is 10001110 in binary.
Or rather, the decimal value 14 with a single bit indicator to tell us that a playing piece has just been placed on the board (i.e. a playing piece has been added to the board at square number 14). The next value received over serial is 0x0E (playing piece removed from square number 14).

The list of numbers in the results continues through 13, 14, 15, 16 then  the next value received is 0x93 (playing piece placed at square number 19).

This is because our L-shaped board has been cut out of a 6x6 grid and square numbers 17 & 18 are unused (the square immediately below 13 on our board section is numbered 19). Likewise, once we get to square number 22, the next square number received is 27 (since squares numbered 23 through 26 are not part of this particularly shaped board section).

Reading through the list of messages received over serial, it's possible to calculate that our board section is correctly (and more importantly, consistently) reporting back which squares have playing pieces placed over them, and which squares are becoming vacant as a playing piece is removed.

In short, a success!
At last.

SVG to GCode converter

It was a particularly busy night at BuildBrighton, last night. Not just in the number of visitors (it was great to see so many people hanging out though, with both the main areas and the workshop filled with people all hanging around, talking nerd) but in getting stuff done.

CNC Paul made some excellent progress with the CNC software and managed finally to get the machine carving out shapes from lumps of mdf. More impressive than that even, it managed to draw/drill a matrix of dots from our own hand-crafted G-code (something we've struggled to get working for a while now).

So having carefully laser-etched, hand-drilled and manually cut out some pcbs for our electronic board game, we're hoping that it won't be long before we're letting the CNC machine do most of the work - at least, pre-drilling and routing/shaping the boards, so we can line up the pre-drilled boards and screen print the etch-resist onto them, quickly and easily.

What currently takes about an hour to do, and often leaves us with wobbly-edged boards, and off-centred drill holes, we're hoping can be reduced to minutes, once we've mastered the CNC!

And the first step towards mastery is being able to produce valid G-Code for drilling holes, from our PCB designs. As regular visitors to this blog will know, we're real fans of ExpressPCB for designing our PCBs (sometimes DipTrace if we have to export to gerber, or for creating 3d images of the boards). ExpressPCB is really easy to use, but doesn't have an export option (it's free software, provided by a manufacturer so you can email them files in their own proprietary format) so we use CutePDF to get the software to produce a PDF file of our designs.

In fact, any PCB design software can be used with CutePDF to produce PDF files of the final designs. So with this in mind, we're focussing on working with PDF files (rather than have to create a load of filters/parsers to import lots of different file types).

The general idea is this: create a PDF file and load it into Inkscape. Manually find and colour all your drill holes (we're using red to identify a hole to be drilled). Since all our PCBs use the same 2mm pads with 0.89mm hole, we don't have to worry about tool changing and different sized holes; we'll just treat all our holes as exactly the same size.

From Inkscape, delete all the unnecessary information and leave just the red drill holes, and save as a plain SVG. This is where we're going to start parsing, to create our g-code. Inkscape creates peculiar SVG data: it's strictly correct, and syntactically accurate to the SVG specifications, but it's a peculiar way of doing things.

Let's say you draw a circle, at some arbitrary point on the screen. Then you edit the co-ordinates, so that it sits at, say 10,10. When the image is saved as SVG, Inkscape keeps the original co-ordinates at which you drew the shape, and applies a matrix transformation to the shape, to get it to end up where you wanted it. It basically means that when you save even a really simple, single shape in Inkscape, the SVG is almost unsuable from the outset!

The example above shows a grid of dots, placed at 5,5mm then 10,5mm then 15,5mm.
As you can see from the crazy decimal placings after each set of co-ordinates, the dots have been placed at one point on the screen, then translated (moved) to their final resting place. The first thing we need to do, is to "bake" our co-ordinate points and translation matrices together, to get the actual point that each dot sits on.

For testing we created a grid of dots, starting at 5,5mm and spaced 10mm apart.
Then we had to parse the SVG, getting each co-ordinate point and applying the related translation matrix (if any) and spit these values back out. In the screenshot below, the results of this are shown in the centre panel

Our co-ordinate points at least now look consistent (there are a few 19.44821 values in there for example) but they don't seem to relate to the points we created in the drawing. And after a bit of digging, we found out why: the SVG specification does not allow for units - each image is simply made up of points, and then a transformation matrix (what else?) is applied to the whole image to scale it up/down, so that it matches the required units. It turns out that the default unit for Inkscape is the pixel. And Inkscape assumes a 90 DPI resolution.

Now one inch is 25.4mm, so we need to multiply each point by 25.4/90 (or about 0.282222) and doing this got us somewhere nearer, but not quite (since the dots were being handled as a single entity or group, and the entire group had a translation applied to it, so that each dot would eventually appear in the correct place in the document).

Since we're going to be working from a 0,0 origin on the CNC, we looped through all the points and found the lowest X and lowest Y values. Then subtracting these from each set of co-oridinates, we started to get something a little more useable.
In fact, after rounding to two decimal places (the CNC software only goes to 1/100th of a millimetre and the actual machine really only works to a resolution of about 1/30th of a millimetre) our final co-ordinates looked just like we wanted them to:

A grid of dots, starting at 0,0 followed by 10,0 then 20,0 and so on.
We inserted the drill plunge command between movements (Z down to zero, back up to about 6mm then move to the next point) and suddenly we've some valid-looking g-code to describe our grid of dots, from a document loaded into Inkscrape. This is great news!

The next step is, obviously, to load an actual PCB design and drill the points and see how these line up to the 1:1 printed image. It's only baby steps at this stage, but it's looking quite likely that we're going to be able to drill (and rout out) PCBs from pretty much any CAD/PCB design software after all....

Finally, some working board game sections?

After a few hours down at the BuildBrighton Hackspace last night, we managed to get a few pcbs (and mdf top layers) etched and cut out. As ever, it wasn't all plain sailing, but we got there in the end! (well, sort of)

The first thing to do was to etch a PCB which is suitable for our new Hall Effect sensor layout.

The mdf layer was a pefect match for the pcb, with holes where the sensors sit, and hole for the 0R resistors we're using in place of jumpers, or vias on a double-sided board.

Unfortunately, we forgot to add in some slots for the row of pins on either side of the (through-hole) microcontroller. D'oh. Luckily, the PCB didn't need any amendment, it was just a case of cutting a new pdf layer.

It was exciting to solder up the board, ready for testing. We've done quite a bit of surface mount hand-soldering in the past, but it was a while ago, so it took a little time to get back into the swing of things. Those hall effect sensors are SOT-23 (or maybe SC59) sized, so pretty small.

(fingers don't always give a true idea of scale, so here's a SOT-23 hall effect sensor with a one pence piece to demonstrate the actual size)

Anyway, with the board soldered up and the top layer fitting perfectly over the top....

.. it was time to plug it all in and give it a whirl. The firmware for testing was just a simple serial output report (printing the value of the PORTB i/o port periodically). And the result.....

Ta-da!
Nothing.

It didn't work.
Sometimes it feels like we're never going to get this project off the ground, but - having invested so much time to get this far and feeling like we're so close to victory - it was once again time to break everything apart and debug right from the very start...

We already know that our hall effect sensors work individually. Put a magnet near them, and the output of the device is pulled low. So the problem must lie with the way we've chained them together, to create a matrix (in much the same way multiple buttons are laid out to use row/column scanning when making a keypad).

Since all of our PORTB pins have internal pull-up resistors, we're expecting to see the inputs high on all our sensors - and when a sensor is activated, the output is pulled low through a transistor (inside the hall sensor switch) and the input goes low (the pull-up resistor inside the PIC microcontroller is about 47k, the resistance between the output pin of the hall sensor and ground is a few tens of ohms at worst).

So what's going wrong?
We stripped everything back and put a few hall sensor switches on our breadboard.

All of the outputs of the hall sensors are connected together, to the same input pin on the PIC. The firmware simply puts power onto each of the sensors, one at a time, and reports back which "row" is currently activated, and the entire PORTB value. The results of this test looked something like this

And there's our first clue: no matter which "row" is activated, the PORTB result is hex 0xFB. In binary, this is 1111011. i.e. the third pin is always low, no matter which hall sensor is currently activated. We would expect to see this return to 0xFF (binary 11111111) when a hall sensor with no magnet on it is activated.

So it looks like the hall sensor with the magnet on it is pulling the rest of the outputs (of the other sensors) low, even when it is not activated. This needs some investigation....
The hall sensors are from Farnell - they're SL353HT sensors and a quick look at the datasheet tells us that they're not just simple hall switches: they have some internal logic in the including push/pull resistors to hold the output so no external pull-up resistors are required.

But we've already got "external" pull-up resistors (they're connected to each of the input pins). And we certainly don't want pull-down resistors anywhere on the inputs. This is really frustrating! If only because, having made two PCBs, we were so excited to try the two boards out and see how they interacted with each other, we soldered both of them up using these SL353 sensors - which in turn include some internal circuitry which is pulling (and latching) our microcontroller inputs low (even when no magnet is in place on the sensor). So we've effectively got two useless boards!

So what's the answer?
Luckily, we had some other hall effect sensors from a previous project. They're unipolar (only respond to a north pole from a magnet) but we checked the datasheet to make sure that they had a true open collector output, and they behave the way we want them to. This time, we tried our test rig with these different hall sensors, in place of the SL352 integrated switches that are already stuck all over the two PCBS. The results were very encouraging:

Using the same firmware (and after a couple of false starts, with the magnets the wrong way up over the sensors) we finally saw the results we were expecting:

When row 1 is activated (the first value 31 tells us that row 1 is currently "high" - ie the first sensor is powered up), the value of PORTB is 0xFB (in binary, this is 11111011). Our hall sensor outputs are all connected together, and are also connected to RB2 on the microcontroller. So far so good - with the first sensor activated, the input pin value is low (telling us that the sensor has detected a magnet).

When row 2 is high (ie the second sensor is powered up) the value of PORTB is 0xFF (in binary 11111111). This is because the second sensor has no magnet on it, and the output is left floating. The input pin on the PIC has a 47k pull-up resistor on it, so the input pin value is high (telling us that no magnet is over the second sensor).

When row 3 goes high (ie the third sensor is powered) the value of PORTB once again goes to 0xFB. This is telling us that the output from the third sensor is pulling the input pin low - i.e. a magnet is over the third sensor.

This is exactly the setup we had in the photo! A little more testing, swapping magnets around, taking them off, putting them back on again and so on, and the results were consistently correct. At last it looks like we're making progress. We need to make sure that whichever hall sensors we use (the SS349 sensors are no good) they have an open collector output and no fancy extras!

It's BuildBrighton again tomorrow night, so maybe tomorrow we'll (finally) be posting showing some success...

Hall sensors have it

It's been a long time since we first came up with the idea of a digital board game, and dismissed hall effect sensors as too expensive. But here we are, months and months down the line, and we're no really much further on.

We've tried different ways of detecting playing pieces above a playing surface (inductors, capacitance, pin-to-pin contacts, copper tape, custom keypad membranes, magnets, washers and ball-bearings) but they've all generated problems in one way or another. So we're right back where we started, only this time we're concentrating on getting a consistently working board game, rather than focussing on the price point first.

About 18 months ago, we were dubious as to whether a board game enthusiast would be willing to drop a hundred quid on a playing surface - no matter how cool or clever it might be. But with the recent explosion of board games and table top gaming on Kickstarter, it's becoming obvious that people are willing to pay a premium for new and interesting ideas. There are games launching with a rulebook and a few dozen miniatures for over a hundred pounds - all of which leads us to think that we should just make our electronic board game and stop worrying about the price!

So all that said, it's time to see if hall effect sensors are any good (after all, we've investigated and dismissed pretty much every other approach we've tried!)

Our hall sensors arrived from Farnell this morning, so we knocked up a quick SOT-23 breakout board and tested one with a simple LED. We're using 2xAA batteries for a 3v source, connected to pins 1 and 2 of the hall effect sensor. The LED is connected to the 3v supply and the cathode to the output of the hall effect sensor.

When activated, the output of the sensor goes low (it's an open collector connected to ground) which in turn makes the LED light up. We tried the sensor out with one of our playing pieces, with a tiny 3mm neodymium magnet embedded in the base.

Some of our pieces have one, offset-from-centre magnet, some have two.

What we noticed during testing was that the tiny magnets activated the sensor when placed directly over it, but the "hot spot" was very small - by rotating the playing piece, it was possible to get the LED to go out, even when the piece was placed such that we wanted the sensor to continue to detect it. Although this was encouraging, we really need the board to sense the playing piece when it's placed roughly in the centre of a square, irrespective of which way around it's facing.

Now some people say that hall effect sensors become more sensitive at higher voltages. So we tried the same thing but with a 5v supply (note the PIC programmer in the later video, providing 5v from the laptop's USB port). The LED lit up more brightly, but the sensor was no more sensitive than before. What we need is a bigger magnet!

Luckily, we have some larger, 10mm x 1mm disc magnets. These worked much better. Once the sensor was activated, it remained switched on until the magnet was removed - rotating the magnet made no difference to the output. 

When we last worked with larger magnets, we had the opposite problem to the one here - as a piece was lifted off the board, multiple squares detected the presence of a "ghost piece" as it floated over the top of the playing surface. The magnet was so strong as to activate a "cluster" of up to 9 squares at a time, as the playing piece was lifted up and moved over the board. So we needed to devise a test to make sure that wasn't happening again.

The LED in this video lit up much more brightly than the previous one - it's just that we've had to turn on the backlight on the camera (it was getting dark) so it doesn't appear anywhere near as bright. It is, though, honest!

This time we had exactly the result we were looking for!
The playing piece activated the sensor up to 5mm or 6mm above the board, but the magnet wasn't so strong that it could activate nearby sensors inadvertently. As the playing piece is moved away from the centre of the square, the sensor shuts off as expected - but with enough room to allow the playing piece to be rotated or moved slightly off-centre without affecting the output.

We quite like the single-sided, copper-side up approach of earlier designs. Keeping the mcu on the underside is nice but not critical (there's no reason why we couldn't put a surface mount SOIC style chip on the top and cut a hole for it in the mdf layer). But our board edge connectors are critical - and the through-hole versions of these work really well (plus, we've not found any surface mount alternatives to these, if everything went SMT). So we're quite happy to stick with through hole components, and keep the mcu and connectors on the "bottom/underside" of the PCB. This does mean, however, that we need our hall sensors on the same side as the copper (so through-hole versions won't cut it). Which means using SC59/SOT-23 style SMT versions of the hall effect sensors.

So here's a PCB using SMT hall sensors

Hopefully we can get this etched and assembled tomorrow - and who knows, we may even end up with a working electronic board game! Hang the cost, let's just get it working!

One last try for mechanical switches

Having visited the BRT Group in Hove this dinnertime, it was time to put Steve's theory to the test. Our latest design allows for small holes between two PCB pads, into which we'll drop our ball bearing, bridging the contact, and informing our controller that piece has just arrived or been moved away from each square on the playing surface of our board game.

Everything has looked promising, as the ball bearing "borrowed" from a tilt switch worked just fine. Having just an hour to work in, I quickly etched and drilled some boards for testing. Here's the ball bearing from the tilt switch triggering a simple circuit (the LED is connected to 2xAA batteries, with the ground from the battery going to the two contacts then to the cathode of the LED).

I tried a number of "drop tests" and when the ball bearing finally settled in the hole, the LED lit up every time (it flickered as the ball bearing wobbled about in the hole). Things were looking good.

Sadly, with the (chrome-plated) steel ball bearing, the results were less encouraging. Just like earlier tests with washers, the LED would only light up if the ball bearing was pressed firmly into place. Given that everything else is the same, only the bearing has changed, it makes us believe that the coating of the bearing (or the material the washer is made from, in earlier tests) has a dramatic effect on the reliability of the switch.

So there we have it. Mechanical switches, whether made from washers, ball bearings, steel, copper, chrome-plating and so on are all just a bit too flaky for us. I tend to agree with Steve - there's a simple solution to this somewhere, we're just not seeing it. Because we're focussing on using easily-accessible materials, such as off-the-shelf washers and bearings, if the solution involves sanding or grinding these to get them perfectly flat, they're not really the answer we're looking for.

In fact, after some discussion, we're beginning to wonder if mechanical switches are going to be suitable at all. Even if we had them working, no-one has actually addressed how to stop the exposed copper from oxidising (tinning the contacts with solder also reduces the surface conductivity) or how reliable the contact might be after a few thousand open/close operations. In short, perhaps it's time to give something else a try...

Testing tilt switch ball bearing as an electrical contact

Following an exchange of comments on a G+ thread, Steve seems quite insistent that the current method (magnet pulling a piece of metal off two contacts) should work. After all, a tilt switch is just a ball bearing that balances on three or four pins, and they work consistently well.

So before we commit to the (much) more expensive design using hall effect sensors (even at China prices, 12p each soon mounts up if a room has 24 squares: that's nearly three quid per board section) it was time for a little test.

Having cut open a tilt switch and stolen the ball bearing, we tried testing for electrical conductivity by just dropping the ball into a gap between two copper plates. Amazingly, it worked!

The delay between the ball bearing landing and the LED lighting is our enormous 500ms debouncing routime. The horrible fingernail colouring is because Ferric Chloride is a nightmare to wash off one you get it onto your hands!

To make sure it wasn't the copper plates making the difference, we tested again with the copper washer (it still required pushing down to work consistently) and also with the steel washer (took a lot of pressing to make contact).

So it looks like the problem with our earlier design is one of a few things: either the surface wasn't flat enough to ensure that both sides of the two-part contact were actually touching the washer when landing (though this test disproved that to some degree) or the base of the washer wasn't flat enough to ensure good contact when dropped onto a flat copper board. This is the more likely, since some washers do have a slight burr on one side (where they've been pressed out of a sheet of steel). Or, simply, the material used in the washers isn't conductive enough (though copper washers are made from about the most conductive material we can find without getting involved with semi-precious metals). However, since we're looking to simplify construction and use easily available parts, sanding/griding washers flat and gluing a steel one onto a copper one is not likely to be an acceptable solution.

The ball-bearing idea, however, is looking very promising.

The only problem so far, is that the ball-bearing from the tilt switch is only attracted to even a large magnet very, very weakly. It seems to work consistently and triggers the LED every time during testing (except in the video when it doesn't land between the two plates properly!) so if we can get the same result with a steel-based ball-bearing (so it can be attracted by a magnet) we might be onto something.

Our PCB has undergone yet another redesign:

The larger circles represent 6mm holes that an M5 (or 5mm) ball-bearing can sit in and the smaller, inner circle represents a 2mm hole drilled into the PCB (the larger holes are 6mm  across, allowing the ball-bearing to move freely up and down, but restrictive enough to ensure that it locates into the 2mm-sized hole when it lands).

Ideally, copper-plated steel ball-bearings would be perfect for this. We've no idea what metal is used for the ball-bearing inside the tilt-switch. All we know is, it's not attracted to magnets (ok, it is but only the tiniest little bit, only just strongly enough to lift it off the table and it drops off easily, if shaken). Let's hope that a steel or stainless steel, or chrome-plated steel (or any other easily available) ball-bearing is just as conductive as this one.

Once again, it's a little late to go down to the 'space and knock out a few PCBs to try this design out, so it'll have to wait until tomorrow evening and we can see if this works. If not, we've already got a PCB designed for SOT-23 hall effect sensors (and there's about 100 arriving from Farnell in the morning, if their next-working-day-delivery is as good as it usually is!)

Not even copper washers work

Steve came up with a great idea yesterday: copper washers!

Copper is a number of times more conductive than stainless steel (or even zinc, as we're not sure if any of our many different washers are electroplated steel) so it makes sense that copper washers would give a better connection.

When I suggested that the steel is needed because of the magnets in the bases of our playing pieces, his response was as brilliant as it was succinct: glue a steel washer to a copper one! This not only allows the piece to be pulled up by the magnet, but also adds a bit more "bulk" to help press the washer down onto the contact(s). Perfect!

So I just tried this with a dab of superglue to hold the washers together (I just learned, only ever use a dab, not a big splodge: ripping a superglued copper washer off the end of your finger is painful). And the result...

The values displayed tell us that a contact on column three has been activated. The most significant bit of the value being returned tells us is the contact has been made (zero) or released (one) resulting in the values of 0x03 (contact made) and 0x83 (contact released)

Sadly, not much difference.

The washer still needs to be forcibly pushed down in order to create continuity between the two parts of the contact. Even after scrubbing the washers with wire wool (to make sure there was no protective coating on them) the result was the same.

It looks like the washers idea is suffering from the same problem as the keypad membranes: it simply requires too much downward force to make a mechanical connection between two parts of the contact. Time for something else...?

Another almost success with the electronic board game

This board game designing is harder than you'd think. Not creating an actual game, just getting the mechanics of tracking pieces around a board with electronics. It's proving quite difficult!
Our inspired idea, using washers which drop into place and are attracted to a magnet embedded in the base of each playing piece (effectively breaking the connection on the pcb) seemed like the perfect solution to requiring super-strong magnets to pull the pieces down onto a custom keypad membrane.

Using our single straight corridor pcb as a base, this time we created a couple of corner sections for the board. Starting with the PCBs, we laser cut a top section from 3mm mdf and mounted the components on the underside.

With the mdf top layer in place, we can simply drop our (8mm diameter) washers into the (9mm diameter) holes. This makes assembling the boards pretty straight forward!

The boards are connected using single-inline (SIL) sockets with pins at right angles to the board. We've reduced the pin count down to 3 (power, ground, data transmit) and duplicated these as a mirror image on the connector. So the connector goes, from pin 1:

ground
data transmit
power
data transmit
ground

The idea behind making each socket mirrored is that board sections can now be rotated, and any board section can be connected to any other board section (a limitation we hadn't solved in our earlier four-pin design)

Strictly speaking, only three of the five pins need to be plugged in, so long as they are 1,2,3 or 3,4,5 (you can, of course, connect 1,2,3,4 or 2,3,4,5 as well as the full set of 1,2,3,4,5 and the boards will still work)

Just for good measure, we made two of these corner sections, so that we could test the connections when either (or both) boards were rotated a number of different ways

With the washers in place, it was time to stick on the top layer and try out the board section(s)!

With the board sections cut to shape, the miniatures looked really good on the corridor sections, and fit in really well with the style of artwork. In this example, we forgot to add in an extra bit along the edges, for the walls, but we'll make sure they are put into the final version!

The playing pieces moved really well on the board sections.
We had to use only the smallest magnet in the base of each piece (using a large magnet caused a number of washers to "jump up" when a piece was picked up and moved around too closely to the playing surface). With the appropriate magnet in place, the pieces automatically settled into the centre of each square - the magnet being attracted to the steel of the washer helps the playing piece to "lock" into each square.

The playing pieces can be picked up (an audible click accompanies this as the washer falls back down) and moved into a new space (which is accompanied by a satisfying clunk and the next washer is pulled up by the magnet) or they can slide from one square to the next. Because of the "auto-centring" effect of the magnet, this is a particularly satisfying way to move the playing pieces.

Everything seemed to be working fine, so we coded up some simple firmware to report the state of each washer/square on the board, so we could monitor the inputs being triggered and released and the pieces moved about the board. And that's where things started to go awry!

It turns out that resting a washer across two parts of a contact doesn't provide enough conductivity - the washer needs to be pushed down to get continuity across the two parts of the contact. This is almost the opposite of our earlier problem: now we don't need to push the playing piece down onto the contacts to register a playing piece, but we need to push the washer down to indicate no playing piece is in place (since the magnet in the playing piece causes the washer to break the contact when it is present).

It may be the conductivity of the steel, or the weight of the washers (we tried replacing the M4 washers with much heavier M5 and M6 bolts during testing, but had a similar problem, and inconsistent triggering) but without actively pushing the washer down onto the contacts, there's still no difference on the microcontroller input, whether a playing piece is present or no.

To prove this theory, we made a simple rig out of vero board and placed a washer on top of some pcb pins. We then put a magnet on the underside of this arrangement, so that the washer was actually being pulled down onto the pcb pins

Even with the washer being pulled onto the pcb pins on the vero board by a magnet, there's no continuity between the two pins

But pressing the washer down onto the pins created the continuity we're after

So it seems that our "drop-washers-in-and-pull-them-up-with-magnets" idea isn't going to work either. Which is a shame - because the action of the miniature playing pieces moving around the board sections felt really nice and responsive.

We're not quite back at square one, but it seems that this thing is going to take a little more thinking about.....

New method for creating board game sections

Another evening at BuildBrighton means another go on the laser cutter and another PCB/mdf combo for our new-style board game sections. Having spent a while designing the PCB so that it can be made from a single piece of single-sided copper board, (meaning manufacturing should be both simple and cheap!) the actual making of the first prototype board went quite smoothly.

The PCB was etched using our currently favoured method: coat the copper board with Halford Matt Acrylic car paint, allow to dry (we did use a hot air gun to speed this up, but it can cause the copper board to curl a little bit) then laser the PCB design onto the paint. A few minutes in the heated bubble-etching tank, and our PCB is good to go.

Another visit to the laser cutter and our top layer of mdf was ready.

A perfect match! The holes in the top layer will hold M4 washers, which in turn connect the two halves of each button contact. We were just about to drill and glue the whole thing together when someone pointed out a problem, which meant making another PCB.

On our first PCB, the "filled pour" plane (the copper between the tracks and traces) meant that any washer over two contacts would also connect to any other washer on the same plane - basically all our washers would be electrically connected together! So it was time to knock out another PCB - this time with the copper fill removed from around the contact pads (in the fullness of time, when these are produced with a solder mask, only the contacts will be exposed, but for our prototype, we need to remove all the extra copper from around the pads).

With the new PCB in place, it was time to fit it all together and see how it looked.

The extra slots in the mdf are where through-hol components are to be mounted on the underside and soldered to our exposed copper surface. These slots allow the mdf to sit flat against the PCB, even though there are rows of solder joints on the "top" side of the board.

Unlike when trying to pull a playing piece down onto a fixed steel disc, allowing the washer to float and using the magnet to pull the washer up works through very thick material even when one of the "weaker" 1m thick magnets are used:

We've yet to decide whether or not to keep the "clicky" sound: it could be dampened by placing a little funky foam on the underside of the top layer - but just at the minute we're thinking it might provide some nice, tactile feedback. We can always add the foam to dampen the sounds at a later date if necessary.

Next will be the printed playing surface for this corridor section, then to hook it up to a computer and see if it actually works! Because this new method means we don't need super-strong magnets and large steel discs, we can even use some thicker material for the printed top surface: some 350gsm photo quality card, laminated in 45 micron gloss film might look very nice. Maybe it's time to call in a few favours from Nick at customstuff.co.uk....

A new approach for New Year

Having decided that we need some steel parts in the construction of our board game sections, it was once again time to try out a new idea.

This time we've tried to focus on easy-to-source materials, rather than trying to focus on the long-game and manufacturing costs and keeping the material costs to a minimum. So the easiest way to get some decent sized steel discs into our board game is with "penny washers". These are 25mm (outside) diameter with a hole for an M4, M5 or M6 bolt (i.e. 4mm-6mm inner diameter).

Because the washers already have a hole in the centre, we decided to use this to house a small pin, and to bridge the pin and the washer using a small conductive circle stuck/printed onto the underside of the top layer: as the playing piece is placed on the board, the magnet in the piece would pull the conductive disc down towards the steel washer, and the pin and the outer washer would be electrically connected.

So it was time to crack out ExpressPCB and put together a design. Then we opened the PDF of our PCB in Inkscape and drew a design for some mdf to house the washers

The great thing about Inkscape is that it lets you open any PDF file and draw over the top of it.  This helped us create a design for the mdf which we could guarantee would fit perfectly over the correct place(s) on the PCB

Another visit to BuildBrighton over the New Year Bank Holiday and another PCB is etched and ready for testing!

The laser cutter was in super-smokey cut-and-burn mode for some reason - but it hacked some 25mm circles out of a piece of scrap mdf. We cut some discs of thick photo paper and placed these on the washers, before flipping the whole thing over and hot-gluing the washers in place. The idea is that each washer is sunk into the hole by the thickness of the piece of paper (allowing us to place a top sheet over the whole assembly, without needing to create a separator layer.

Now each pin on the PCB needs to be placed at the same height, so that each is perfectly flush with the washer that surrounds it. Since our tracks run horizontally on the underside, it made sense to connect the washers on the top side vertically just using the copper tracks on some double-sided copper board.

With all the pins and washers in place, the underside looked something like this.

It soon became apparent that the height of the pin head is going to be critical in this approach: too high and the playing surface will quickly become covered in little dipples (where the pin head is pushing through the paper membrane). If the pin is either too high or too low, there's a chance that a copper dot on the layer above won't actually make an electrically conductive connection between the washer and the pin - the height of the pin and the thickness of the washer are critical in this case.

Already we've found that using a magnet to pull a playing piece down onto even the thinnest of membranes is sometimes not strong enough. It seems that the surface tension on the top layer of a membrane (whether manufactured from bits of paper and copper tape, or made professionally by a manufacturer in China) is too great for a small magnet: we need a large magnet and a large piece of steel (the magnetised rubber matting we originally planned on is nowhere near good enough) to make the connection.

Which got us thinking....
If we can't get the magnet to pull the top layer down onto a fixed piece of steel (and given the amount of effort required to get the pins and washers perfectly flush) maybe we could have a small washer "floating" inside a pocket, and use the magnet to pull the washer away from two contacts - when a playing piece is above a square, the washer is pulled up, off the underlying PCB, breaking the contact, and when it is removed, the washer will fall down onto the PCB, bridging the two contacts.

This method seems to offer a number of advantages over our previous attempts:
For a start, the thickness of the mdf layer is not critical, making construction simpler. We can also use smaller (i.e. cheaper) washers, since we don't need a large bulk of steel to pull the magnet down onto. This approach also means we can create our top/printed layer out of any suitable material, we're no longer restricted to keeping it as thin and flexible as possible (in fact, a thicker layer made from printed card might actually be preferable).

This also means that we don't have the problem of trying to attach a top and bottom conductive layer together - everything can be done on a single side of the PCB. In fact, given that we want the conductive side of our PCB to be facing upwards, it's going to be beneficial to work with through hole (rather than our preferred surface-mount) components!

The design above shows how small M4 washers (9mm outer diameter, 4mm inner diameter) could be used to bridge contacts on the PCB. Since we're going to be putting a cardboard/mdf layer on top of this circuit board, we can simply cut a few strips into the mdf to accommodate the soldered pins from the through hole components.

A final, printed top layer over the whole thing, and we should have our first board game section that works with an actual miniature playing piece, not just a heavy duty magnet! It's Thursday today, which means more laser cutting, etching and PCB drilling at BuildBrighton tonight. Fingers crossed.......