SPIDriver's production tests

On July 13th at 5pm, the SPIDriver campaign will end. At that point I will place orders for all the parts, starting a process that will eventually lead to a lot of blank SPIDrivers lined up, waiting to be loaded with firmware and tested. I'm going to talk some about small-scale production testing, which I've done for the Gameduino 1, 2, 3 and will soon start for the SPIDriver.

Pogo time

For the development SPIDriver prototypes, I just soldered a 4-pin header to the board and plugged it into the flash programmer. Here's the header from one of the prototypes:
That's great while hacking on the firmware, but the production SPIDriver doesn't have a header like this. Instead there are small pads on the bottom of the PCB. The test person will hold the board in the test jig for a short time, and the jig has spring-loaded "pogo pins" which make contact with the board. As soon as the test system detects the presence of a PCB, it runs the tests and loads it with the production firmware.

Here's the jig's lower board with the pogo pins in place. It's actually two unpopulated PCBs stacked to give the pins a little more stability. The pogos are soldered onto straight headers to make it easier to connect to the test system (which is a Raspberry Pi running some Python).

And a close-up of a pogo / header pin combo. Pretty neat as these things go:
There will be a frame to hold the top board exactly in place, made from laser cut acrylic. More on this in a couple of weeks.
 

Calibration

As well as its digital functions SPIDriver also includes some analog sensing. It measures voltage and current. Both readings are affected by resistors on the PCB, and component variations in the microcontroller's ADCs and the current sensor. These variations happen from device to device.

Of course it would be possible to perform the conversion functions using "best guess" values for all the parts. That might be OK in some situations, but for SPIDriver I wanted to be giving somewhat accurate values for voltage and current, because they're such useful diagnostics.

To run the calibration, the test system loads some custom firmware on to the SPIDriver that makes measurements on the ADCs, and reports the values back. The test stand has a calibrated 5.000 V power supply, so given the analog readings, it's simple to compute the scaling factor that the SPIDriver can use to compute the actual voltage. This whole process takes a few milliseconds. The tester also measures the speed of the microcontroller's oscillator, and calibrates the temperature sensor.

The test program creates a report like this, giving a full set of readings for all the sensors. It also builds the custom firmware using this particular SPIDriver's calibration, and programs it into the microcontroller's flash.

Certificate of Authenticity

After all this effort, it's good to tag the tested unit so it's clearly been processed. A Dymo thermal printer is hooked up to the Raspberry Pi tester, and a little bit of Python with qrcode produces this nice clear label. The QR code links back to the actual test results page, so we can tie the unit back to its test results -- and you can too if you point your cellphone at the label.

The serial number on the label is the unique code that identifies the SPIDriver unit, and it's the name of the serial device on some operating systems. It's the same code that appears in the control utility:

These codes are randomly assigned by FTDI - each FT230X has a unique 8-character serial number. If you're one of the Gold backers you get to pick your own "vanity" serial code -- classy!

As the test finishes, the test person peels off the label, and fixes it onto the bottom of the SPIDriver. The whole process should take a few seconds - ideally it will be possible to test, calibrate and load hundreds of SPIDrivers per hour.