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…..
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…