Showing posts with label hall sensor. Show all posts
Showing posts with label hall sensor. Show all posts

Wednesday, 9 September 2015

New PCBs for electronic board sections

After getting our multiplexed hall sensor array working last week - and failing to demonstrate them at a Unity meetup in Brighton recently after wiring the one working prototype up incorrectly! - we made up some smaller sections, this time in a 7x7 grid.

This means we can use a single input port (PORTB) with pull-up resistors (since the hall sensors pull to ground when activated) and a single port to activate each transistor individually to turn on each row of hall sensors at a time. This means loads of discrete components:

For prototyping (and because of space restrictions on our breadboard) we've only actually wired up five of the seven transistors, but after proving the concept worked, went on to use all 7 in a test (we went on to wire up two of the SMT transistors at the top of the board).

Ok, not exactly loads. But quite a few. Enough to make wiring up each controller circuit for each board section quite fiddly. We etched up a few different circuit boards, using a variety of different mcus, surface-mount and through-hole components.


Even after making as many components as possible surface mounted, there were still a lot of discrete components to stick down on each PCB! Enough to make it worthwhile investigating an alternative, all-in-one integrated (IC) chip to do most of the work for us...

The A2982 may be relatively expensive, at about a quid a time when bought in bulk, but it does simplify the circuit a great deal.


The A2982 is a source current driver. It includes resistors on the transistor bases, to allow them to work at 5v logic levels, and each channel can source up to 500mA if needed. So all those discrete components are gone - and the entire circuit is now just two IC units: a single PIC 16F1829 and a single AS2982 chip.

Each panel is now much simplified from our earlier 12x12 design - both in terms of hall sensors and the controller PCB. Here we're using some thin hook-up wire just to get the board working (the final version will use ultra-thin magnet wire)


We're using 3.5mm stereo jack sockets to connect our PCBs to power/ground/data. So here's the final PCB design all soldered up and ready for the new firmware.


Right now we've got a couple of panels soldered up and working individually - so we're in for a marathon etching session tonight, to make up half-a-dozen or more controller PCBs for all the other panels. A few more like this and some updated firmware and we can create one, big, playing surface....

Monday, 31 August 2015

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!