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!