Pattern Matrix PCBs arrived & first tests

After triple checking the schematics and design files and ordering 80 PCBs (50 sensors and 30 i2c boards) there was an anxious wait for them to arrive and do some initial tests to find out if there were any mistakes. We now have enough boards to make two new pattern matrix devices, one 4X4 and one 5X5 – the plan is to evaluate the design and refine it for future builds.

img_20170628_105103

img_20170628_105226

img_20170628_110233

The picture below shows the first test boards populated and plugged it into the Pi – it’s much neater than the lego and breadboard prototype! The good news is that it seems to work so far, the only problem I’ve had is with the hall effect sensors, the pads are a tiny bit too close together for my skills. After a couple of tricky situations fixed with a de-soldering pump, I think I’ve come up with a strategy that works. I can bend the outer pins away from each other and solder the central pin first – then bend them back to finish the outer ones and being very careful not to bridge the pads.

img_20170628_173331

The blue jumpers on the square i2c boards allow you to program the device channel that the two expanders use – these could alternatively be hard soldered, but it’s good to have the option to reuse the parts or reconfigure a pattern matrix so we can add different sensors etc.

img_20170628_185854

For reference, the KiCad 3D viewer models look pretty close.

i2c-render

sensor-render

PCB design for pattern matrix 2

This is the pattern matrix 2 tangible sensor schematic, which is fairly simple – just 4 hall effect sensors and a capacitor to smooth out any noise on the power supply.

sensor-schematic

We need to make hundreds of these for the Penelope Project, and we can save some costs by using the built in pull up resistors in the MCP32017 to get a decent signal from the sensors. The difficulty with this PCB is arranging the sensors so they align with the magnets in the tangible programming block in the optimum manner. From tests with the prototype Lego rig, this isn’t actually too critical – but it’s set up so the lead length can be tweaked a bit at soldering time.

sensor-render

This took me about 20 variations to finally get right, but the circuit is just about simple enough that it can be made single sided – this is good because the top side will be partly exposed, while the lower side with all the copper traces can be protected. It’s good practice to have large areas of copper left connected to ground, partly as it’s a common connection needed all over the board, partly for stability but also it reduces the amount of chemicals required to etch the circuit – as only the parts around the traces need to be removed.

sensor-render2

The i2c expander board is a little more complicated. The design is made to be modular so we can stack up any number of these connected to the Raspberry Pi for different arrangements of sensors. Each board can deal with 8 sensor locations (each comprising 4 individual hall effect sensors). Their job is to convert the digital signals from each sensor into serial data (using the i2c protocol) so the Raspberry Pi can read them all just using 2 wires, plus 2 for power.

i2c-schematic

Each board can be configured to a separate i2c device address to tell it apart from the others using jumper connectors. This one had to be 2 sided, but I managed it without any ‘vias’ (holes to pass traces from one side of the board to another). I also added a power indicator LED as a last minute addition.

i2c

I’ve been learning the open source Kicad software to design these, which is now used by CERN for building the LHC, so it’s pretty fully featured! The idea is that you draw the schematic first, link each component with a physical ‘footprint’, then switch to the PCB design stage. Other software I’ve used in the past tries to route everything in one go for you (and can come up with some pretty strange and messy results). Kicad works in a semi-automatic manner – you need to draw each trace by hand, but it routes them around components and other traces, and suggests the shortest path for you. This is quite a lot better than a fully automatic approach as you have more control over the end result, and easily end up with a decent placement of all the parts.

i2c-render

This project is of course open hardware, and can be found on github here.