Nixie Tube Driver Test Jig

For those of you who don't already know, recently we ran a Kickstarter for our Nixie Tube Driver (NTD). The project was a huge success. To follow on from that, we ordered a second batch of drivers to put on our tindie store. The difference this time, however, is that we weren't building these drivers ourselves. For the first time, we decided to get our product manufactured in a PCB assembly house (if you're curious as to why: it turns out that making 100 drivers by hand in your bedroom is no fun at all...). As a result of this, we will be selling the drivers as a kit: all the SMD soldering is done, and the through-hole components are provided to solder yourself.

This presents a new challenge, how do we test the drivers when we recieve them from the assembly house?

All PCBs need testing before they are deemed ready for use, but the methods of testing can range from simply an optical inspection (which is usually offered by default at most PCB assembly houses) to something much more involved, like paying a test engineer to run through a formalised procedure. Obviously with increased complexity comes increased cost, and how much you pay comes down to how critical the testing needs to be, and how complex.

Automated Self-Test

If your PCB involves some form of processing, then building in an automated self-test procedure is a no-brainer. Whenever I'm using a micro-controller in any project I try to include some form of this test. The principle of the test is fairly simple: you give your processor some way of introducing signals onto the board and measure how the board responds. If it responds as expected, brilliant! If not, then you can light an LED or spit something down the UART or let the user know in some way that something isn't right. This is useful in several ways: for one it gives you an idea of whether your board is working properly right when you turn it on, and for another if your board needs any calibration the self-test can become a self-cal very quickly.

It's also really easy to implement! It's a rare occurance for me to max out the capabilities of a micro-controller (I like having head room), so usually there's a spare DAC or SPI line somewhere around I can use to introduce signals onto my board, the extra cost of components to get the self-test in there is usually nothing compared to what it would cost to formally test every board. It also means if something goes wrong in the field, I've got code built in to diagnose it.

Bed of Nails Testing

If your board doesn't have any processing on it, or involves a significant amount of analog circuitry, the bed of nails test is probably worth thinking about. The idea is to marry pads on your board with a pre-built test circuit by pressing it down onto pins sticking up out of the test board (see image below). The pins can probe reference signals, clocks, or any important line on your board, and also introduce signals and measure them further down the signal chain. This can be particularly useful if you have circuitry like analog filters in a critical signal path, as these require large amounts of processing to test properly (Fourier Transforms and generating waveforms might well be out of the scope of your processor).

It's also usually very quick. While test procedures can run up to hours, the majority of them will usually take a couple of seconds, and being able to simply press the board to a fixture and hold it till it's finished is about as efficient as you get. Most importantly, it's a non-invasive procedure which works for surface mount components as well as through hole, making it ideal for basically any board you can think of (though I don't know if it would work for flat flex).

The problem with bed of nails testing, however, is that a professional service is expensive. And for simple boards it can be a little excessive.

The Nixie Tube Driver

The NTD presents a challenge. It has no micro-controller on it, rendering an automated self-test impossible, but a professional bed of nails test would be prohibitively expensive. Not testing the NTD was ruled out quickly as an option, as we were not as yet sure what quality the manufacturers would come back to us with. So how to test it? It is of course possible to test the NTD to some degree with a simple multimeter, testing the continuity of every line. Indeed, while making the kickstarter batch this needed doing several times. But with 100 boards and a test like this taking a good 10 minutes each, 16.7 hours of my time could be much better spent.

So why not spend that time making my own bed of nails test jig? Knowing the theory of operation of the boards well, and understanding the interface to them and the requirements for a test, this should be easy! Right?

To successfully build an automated jig for the NTD, it is first beneficial to study the requirements of any such device. The test jig needs to be a bed-of-nails platform on which a single NTD (with only surface mount components soldered) can be placed, which will automate the process of testing the functionality of every digit of every segment of the NTD. It should also be able to check that there is a valid HV connection to every segment, and that the RGB backlights are functioning as they should.

To make the test useful any errors encountered in the test should be reported back to the us via a serial terminal, rather than simply stating whether the board has passed or failed. This reporting should be comprehensive, explaining in detail where an error was found, and what kind of error it was. This was specified to allow us to fix any broken boards, if they were fixable.

So how do we go about doing this? Well to explain that it's first necessary to go through the operation of the NTD itself, as it will be impossible to design a test for an operation we don't understand.

The NTD is essentially a 65-bit open drain shift register. It consists of 2 HV5122 High Voltage shift registers in series, followed by a single D-type flip flop with its output to an open drain MOSFET configuration. When a number is displayed on the NTD it will flag the desired bit of the deisred segment, causuing the output of the shift register to pull LOW, in turn turning on the digit of the NTD. The schematic for the NTD can be found here.

The functional diagram of the HV5122 is shown to the right, showing how each pin activates the digit by pulling the line LOW.

The segments and digits of the NTD are arranged in the manner shown above and to the left, and the shift register is arranged so the digits are triggered in order of 1-9 followed by 0 from segment 0-5, this is followed by the 5 available decimal points in order. This is explained in more detail in this document.

Combining this knowledge, the control bit stream is made up of 6 groups of 10 bit, corresponding to 1->9 followed by 0, followed by a group of 5 bits representing the decimal point. On receipt of a ‘1’, the open drain MOSFET will be turned ‘ON’ and the net will be pulled to GND. On receipt of a ‘0’ the net will be High-Z, and will float.

The #E1 and #E2 inputs to the decoder will be tied LOW, and the E3 input will be used as an output enable pin for the decoder.

The tri-state buffer function table is given to the right, each output of the decoder is fitted with one of these buffers. The 'OE'  and 'A' pins on these buffers is tied together, ensuring the only 2 available states are either HIGH or Hi-Z, which is exactly what is required of the test jig.

By combining these 2 function tables together, the truth table below can be created for the segment selection. The final solution requires 4 outputs from the microcontroller, while allowing the selection of 6 seperate segments. This is a crucial saving, as the ATMega328P is not a microcontroller with a high pin count, thus any savings which can be made are beneficial.