Multiplexing an array of hall sensor inputs

We've tried a few times to multiplex an array of hall sensors, and each time ended up getting a load of random garbage as input data. Power up a hall sensor, leave it with a permanent power supply and read back it's value, and everything works fine.

But try to multiplex the inputs (using the traditional rows and columns approach) and things start to go a bit awry. The sensors give the impression of having floating pins on the inputs - sometimes they're activated and sometimes not, whether or not a magnet is over the sensor.

That's why we'd invested so much time and effort into creating daisy-chained hall-sensors-and-shift-register inputs. These work really well. But the actual assembly of them is pretty time consuming. They're also fairly expensive to manufacture, since each panel of 12x12 squares requires no less than 18 dedicated PCBs (each with 8 resistors, a couple of capacitors and a hall sensor on each).

So the other day, we returned to the copper-tape-and-multiplexing idea - just to give it one last shot.

The main difference this time, is that instead of trying to source the current for the hall sensors directly from the i/o pins on the mcu, we're going to sink the current  - this means that every hall sensor has a permanent 5v supply to it, and we toggle the ground pin on each one, to turn it on and off.

Sadly, this made little difference - except that the hall sensors remained resolutely unresponsive. So, with one last throw of the dice, we decided to try switching the ground lines; not directly through the i/o pins, but each "row" through an NPN transistor (I think we used 2N7000 transistors, but they might have been BS170s).

This time - amazingly - the multiplexing worked.
Well, it worked with a 4x2 matrix of hall sensors.
But we coded things up to accommodate a 12x12 matrix, and the pins that actually had hall sensors attached still reported back the correct values, even when we multiplexed with a 5ms delay between polling each row on the board (the delay is to allow the hall sensors time to settle to give a stable reading).

With 12 rows and a 5ms delay between reading each row, we've a latency of about 60ms. For an input device that involves picking up a piece and putting it back down again, 1/16th of a second response time is pretty good. There's probably more latency between the board controller, the ethernet/wifi module and the app running on the PC/smart device than there is between polling the rows and columns of a multiplexed array!

The multiplexing approach means a number of  changes, even at this late stage, to our game idea. Firstly, the cost is slightly reduced (since we don't need all those pcbs, shift registers and so on) but each panel now needs an mcu with at least 25 i/o lines (12 pins for rows, 12 pins for columns and one dedicated pin for serial/UART communication) - so we're losing 18 x 7p shift registers, but now require a slightly more expensive mcu with more pins! Although, we would no longer need to get 18 pcbs manufactured.

It also means assembly time should be reduced a little - although preparing the board (with strips of copper tape) can take a little while, it's still probably less than hand-soldering 18 x 5-way wire connectors for each of the pcbs carring the shift register and 18 hall sensors.

There's only one sure-fire way to find out - and that's to make up a few panels, using all the different techniques we now have available, and see which

• works best
• is quickest
• works out cheapest

Like every electronics-based project, the trick is to find the best compromise between all three!

Intelligent board game (Blood Bowl) development

Here are some photos of the latest board game development;
although we're working on a Blood Bowl clone, the same technology could - in theory - be used for a large number of games, with different board sizes. To date, we've settled on a 4-square module and will make our board game(s) up from this/these.

These photos are from our 4x2 boards (earlier design) but the principles work the same for both.
On the sides of each playing square (N,S,E and W) we drilled a 1mm hole and soldered some pcb studs

The studs are slightly raised on the playing surface of the game board. This isn't as nasty as it sounds - for our Blood Bowl game, it means we can add some "flocking" or similar covering but still get the playing pieces to make a good contact with the pins.

stupid cheap HP camera - even in "macro mode" it doesn't quite know what to focus on!

The plan is to weight our playing piece bases with a small copper disk (something like a 2 pence piece would be ideal, only we don't want to get thrown in prison for "defacing a coin of the realm" or whatever the punishment is these days!). Placing these on the playing side of the board bridges the two connections between the "rows" output pin on the master controller and the "columns" input pin on the slave - so when the slave is asked "which inputs are high/low" this can be used to work out which squares have playing pieces on them.

once again, a nice focussing job by our little HP camera

The tracking of which playing piece is on which square will be done by the master IC. For these early prototypes, we're more concerned about proving the concept of tracking which piece is being lifted/replaced to/from the board.

Creating the playing squares for an intelligent board game board

While toner-transferring and etching our game board "modules" something became obvious - though it's not something we'd thought of when designing our PCBs. The photo below shows our game board etched onto a piece of eurocard sized (160mm x 100mm) copper-clad board

While trimming to size, we realised that the bit cut off the bottom was almost exactly the right size for a single row of 4 playing squares (the printed module above shows a 2x4 grid of playing squares). It then occurred to us that there's no real reason why we couldn't create modules that were 1x4 instead of 2x4.

After all, the top row still has to be connected to the bottom row using a wire jumper/via even when they are drawn/etched on the same piece of board. So here's the new PCB layout for four playing squares at a time:

Since the spacing of the playing squares is 30mm (standard Blood Bowl size) the PCB is also 30mm high (with the playing squares pretty much in the middle of each "strip" of 1x4 squares).

If you want smaller playing squares, simply resize the whole PCB. The overall size will shrink to match the size of each playing square so they should still be able to be cut to size and placed side-by-side, without affecting the spacing between playing squares.

4x1 Board Piece

As you can see, they line up perfectly for connecting horizontally once etched and cut to size:

A little bit of multi-core wire or maybe even some gloopy solder should connect the two boards, edge-to-edge.

Testing multi-plexed LEDs for word clock

Having ditched the impossible-to-debug charlie-plexing idea, we've made up a board which simply places LEDs in columns and rows.

We're going to drive the "rows" through a shift-register (to allow more than 20mA current to be sourced) and sink them through a number of ULN2803A darlington arrays (since sinking directly to the microcontroller pin would only allow up to 20mA per row which could make a full row of lit-up LEDs appear quite dim).

Before we get clever with the sinking and sourcing, we needed to make sure that our array of LEDs worked - and to test it we simply connected the +ve and -ve terminals of a 3V coin-cell battery to the different lines on the PCB.

By touching the exposed wire ends to the positive and negative terminals of a 3V battery, we were able to confirm that every LED in the array worked individually of the others.

Electronic board game - Blood Bowl clone

Some interesting developments over the last few evenings as we've put together all kinds of ideas for an intelligent board for a board game (like, our old favourite Blood Bowl).
Our original proposal - based on freeing up as many pins as possible from two 40-pin PIC microcontrollers - was to allow for up to 600 squares, or a grid of 20x30

To allow for as much flexibility as possible, while at the same time making it relatively easy to understand, we've decided on a modular approach. Our board game will actually be made up of a grid of 4x2 "blocks" which can then be wired together in any arrangement. It means we've lost the flexibility of really wacky board layouts (although using the same technology it should be possible to create one-off boards with pretty much any layout as required) but does mean that we can simplify making boards of different dimensions.
(it also means that anyone who buys their copper boards in eurocard 100mmx160mm size can still make a board game, using a "patchwork" of smaller boards)

4x2 Board Piece

Each playing square in this board is marked out by a "cross" shape on the board. Small through-hole studs are soldered to this underside, so that on the playing side of the board, a small contact point is visible on the playing surface. Each playing piece has a conductive base (a copper coin glued to the bottom would suffice!) and when placed over the four points of a cross, makes a connection between the top and right contacts and the bottom/left contacts.

Using the above layout, we can place these pieces side-by-side and join the edges, while connecting each group of top/right contacts together using short pieces of (insulated) wire

Using this approach, we've designed our Blood Bowl board.
It's not quite 30 x 20, but we found that vertically connecting 7 "rows" of 4 contacts means for each row we can read back up to 28 lines of "column" data. By placing four of these smaller boards side-by-side, our board size is 28 x 16 playing squares. Not a bad compromise and certainly a sizeable playing area for a lot of different board games.

So what does it look like? In short, a nightmare!

As you can see, each smaller board is connected to the board horizontally next to it (the traces were deliberately lined up to make this bit quite easy). Every 7 vertical rows of contacts are connected via wire traces (shown in this diagram by different coloured bars) and each group of these 7x4 = 28 contacts is then connected to the slave microcontroller via a short wire (the connection points for these wires are circled in a matching colour).

There are 16 wire connect points - these go to the master PIC. The 28 traces from the bottom/left sets of contact points are connected to the slave. By flashing one of the 16 wires at a time, and reading the input values on the 28 inputs, we should be able to work out which set(s) of contacts are being bridged by a playing piece on the board.

That's the theory anyway.......

Multi-plexing LEDs for word clock

Having failed miserably at debugging our charlie-plexed LED array we've decided to stick to the simpler approach of using multi-plexing.

There's a subtle difference, but since we're already getting down and dirty with multi-plexing for inputs on a board game it made sense to use this same approach for outputs/LEDs. The main difference is that we'll be using a pin for each row and a pin for each column (10 rows x 9 columns = 10+9 = 19 pins).
If we move away from the 16F628A (with 18 pins) and go far a larger chip, with more i/o pins, then multi-plexing gives us a simpler, easier-to-debug solution.

With this in mind, we set about creating a new PCB to use multi-plexing.
So far we've just put a load of LEDs into a grid formation - the actual controller board will be a separate PCB mounted onto the back:

Uln2803a Driven LED array

Here's a photo of the completed board, populated with LEDs, ready for testing.

Unlike last time, testing LEDs is quite straight-forward; and already we've found some potential problems; a lot of the LEDs are re-used from the old board and by connecting a 3v coin-cell battery straight across the anode and cathode of each LED, we've found about half-a-dozen that refuse to light up.

Whether these were damaged during removal, or never actually worked on the original board, we'll never know. But at least we've an explanation as to why the charlie-plexed board didn't work. Sort of.

Anyway, we're going to pop out those duds and test each individual LED on this board before even considering wiring it up to the rest of the project!

Using 2 PIC micros for a huge input array

After spending some time thinking about a large board game input device - which simply tracks the position of each piece by comparing the current board state to a previously known state - we've decided that a multi-plexed approach will probably be the easiest to implement.

The problem with a multi-plexed approach is that whatever size grid is used determines the number of pins needed (so a 10 x 10 grid needs 10+10=20 i/o pins).

Rather than try the idea out with something simple, then discover it doesn't expand well for bigger/more complex games, we've decided to have a go at quite a complex game, and - if it works - scale it back for simpler board games. For now, we're concentrating on tracking the positions of "dumb" game pieces on the board throughout a game.

One of our favourite geek-games of the 80s was Blood Bowl (which thanks to a console remake being released in 2011 is seeing a bit of revival in recent months). Now, the original Blood Bowl board was a massive 15 x 26 = 390 squares in size.

Obviously, using a PIC with only about 30 spare pins is never going to cut it. So we're back to either using analogue inputs or increasing the i/o pins using shift registers. After much discussion, however, one idea really started to appeal: use two PIC microcontrollers!

This is not only cheaper than implementing a whole array of shift registers, but also gives us a bit more oomph to play with, as we could split game play up over a master and a slave controller.

We're planning on using the master to activate an entire "row" of inputs (the output Port1 in this previous port) but then to start listening on a serial RX pin for a response from the slave. The slave micro simply looks at the input state of all the pins (uC Port2 input in this previous post) and sends this back to the master via serial TX.

Because the master knows which row it activated, it can decode the value received over serial and work out which combination of buttons/inputs were activated. Now, by using 2 x 18F4550 chips, we've up to 30 pins available on each chip and a grid of 30 x 30 inputs (900 squares) is suddenly achievable.

For our Blood Bowl game, we could easily implement a 15 x 26 grid of squares and still have about 15 i/o pins freed up on our master controller (this controlling 15 rows, with the 26 inputs on each column being read by the slave controller). With this in mind, and after much more discussion (and a few more cups of tea and a whole packet of hob-nobs) we reckon we could come up with a generic board game controller which would have:

a) support for up to 600 squares (e.g. 20x30 but not necessarily in a square formation)
b) an LCD display for each player/side which can display current game status
c) built-in dice roll and other random-number generators
d) ability to calculate results/outcomes which would otherwise require dice rolls and table look-ups in the rule book

Although we've not actually built anything yet, this is quite an exciting development.
We remember Blood Bowl as being a great game, but bogged down with dice rolling, looking up results in tables, applying modifiers based on the playing piece type and so on. The Third Edition of Blood Bowl tried to do away with a lot of this by using a simpler dice system, but eventually the same thing happened: the immediate action could be resolved quickly (did a particular action succeed or fail) but when this affected another players ability, yet more dice rolls and table look-ups were necessary.

 If we could remove all this dice rolling and referring back to the rule book and introduce a simple interface - so a player could pick up a piece to identify which is being moved, then press a button to say which action they were performing - the microcontroller could do all the random number generating and issue resolving; simply displaying a message on an LCD screen to the user, to inform them of the outcome and what to do next.

Here's how our Blood Bowl game could look with the clever electronics in place:

Using a multiplexed keypad for other input ideas

After a less-than-successful show-and-tell session at the weekend (yes, the one we've been devoting so much time and effort to over the last few weeks, and putting all our own personal projects on the backburner for!) the few people who did turn up spent some time discussing the various projects we were working on.

A few old ideas were explored once again - sometimes a fresh pair of ideas on an old problem can turn up some really interesting ideas in themselves - and a few new ideas were chewed over.

One of the ideas that came up was using a keypad style matrix, not for output (lighting LEDs like we were doing with our charlie-plexed array for the word clock) but for input. It came following the announcement that some of the members of BuildBrighton were looking to set up a monthly board-game-geek meeting (ok, we left Brighton some time ago, but it's important to keep in touch and see what those crazy guys are up to every now and again!). A few of us here at Nerd Towers remember fondly playing uber-geek board games like Blood Bowl, HeroQuest and Space Crusade, as pimply-faced youths, when they were first released during the 80s.

The idea being investigated is using a microcontroller to load data about each piece (a lot of playing pieces in these role-play type games had a range of different values associated with them) and then to place them on the board in a specific sequence. Each piece will be a "dumb" token - i.e. does not contain or broadcast data about itself - but the board-game controller would keep track of each piece on the board, based on when it was placed on the board, and comparing the current board state with a previously known state, to work out which piece has been lifted off the board.

A quick search on Google turned up some interesting results, but most solutions broadly follow one of two methods - a multi-plex approach (using a pin to activate a full row of inputs, then querying each pin on the row to see if it has been activated) and an analogue approach, to reduce the number of pins required.

Because we're potentially dealing with hundreds of squares on a typical board game (even the simplest of board games, chess, uses 64 squares in an 8x8 grid) we're keen to keep the number of pins required down to an absolute minimum:

With the correct value resistors, we should be able to read which key has been pressed using a single input pin. This idea looks perfect for what we need. However, in practice this is quite a difficult method to implement. Why?

The solution above is better suited to single-key entry, such as a telephone keypad or security pad, where each key is pressed, one at a time.

To be able to detect multiple key presses using a single analogue input pin, we'd need to use resistor values in roughly base-2 increments. i.e. 200 ohms, 400 ohms, 800 ohms, 1600 ohms, 3200 ohms etc.

Now we know that 

a) resistors don't always come in exactly the value we want so we have to go for a best match

b) resistors have up to 10% error in them already

c) reading an analogue input is not accurate - you need to take an average over time, or work with "bands" or thresholds, to decide the true value of the input on the analogue pin.

In fact, to get to 16 inputs, we'd end up using really huge value resistors - the error in which could be more than some of the lowest-value resistors, further down the array. In short, calculating unique key combinations on a single analogue input pin is going to be, at best, difficult and in practice, almost impossible!

Which takes us back to the multi-plex approach:

Here, we need to strobe each of D0, D1, D2, D3 and take multiple readings to calculate which pins are pressed. So, for example, we could force Port1 (output) D0 low (since the outputs are tied to Vcc through a pull-up resistor) and then read the values on input pin D3 on the Port2 (input).

Under normal circumstances, D3 is pulled high through the pull up resistor at the top left of the circuit. If, however, D3 is LOW, we know that button 3 must be being pressed down. Now we read the value of Port2 D2. Like before, we expect it to be high (no button pressed) but if it is low, this tells us that button 2 must be being pressed. Similarly, if Port2 D1 is low, button 1 is pressed, and if Port2 D0 is low, button 0 must be being held down.

Now we sent Port1 (output) D0 high and pull Port1 D1 (output) low.

Checking the input pins again this time tells us whether buttons 7,6,5 or 4 are held down.

Although this approach uses more pins and appears more complex (in execution rather than in hardware) it does allow us to tell exactly which combination of buttons are pressed, even if two, three or more buttons are pressed all at the same time.

We're looking at the 18F4550 which is a 40-pin PIC microcontroller (and includes USB so we can easily download game data onto the chip) but when you take out all the used pins (2 x power, 2 x ground, usb etc) we're lucky if we have up to 28 pins to play with.

In a grid arrangement, this gives us not much more than a 14 x 14 matrix which is pretty small for anything but the simplest of board games......