In this exciting episode, we’ll be continuing our tour of the ArduiNIX schematic, simplifying a bit so we can see how things are structured, heading towards our software design.
Keep those symbols simple
As we continue our tour, we’re going to use simplified symbols for the decoders and the Nixie tubes.
The Nixies I’m using have 10 cathodes (shaped like numerals) and a screen-like anode. These are old Russian IN-12A’s that I obtained from an excellent Ukrainian shop on eBay. Other Nixies might have more cathodes for a decimal point or other symbols (like the IN-12B shown below).
Similarly, the 74141 or Russian equivalent decoder chip, which translates a four-bit nibble into one of ten output pins, will be shown as a simple rectangle with a four-line bus going in and a ten line bus coming out.
So, these are the symbols I'll be using:
Driving the series of tubes!
So, let’s dive into the schematic. (you can see a small copy here or at http://arduinix.com). Now, as an alert reader pointed out, there’s a “typo” on the ArduniNIX schematic in the anode drivers – the MPSA42 is shown with a PNP symbol instead of the NPN device that it is. But don’t worry – the circuit actually works the right way. Here’s a simplified diagram of one anode driver circuit that shows the transistors but omits the biasing and current-limiting resistors.
When your software turns on the output pin to enable the anode, the MPSA42 at Q1 amplifies the microcontroller’s wimpy little output current and turns on the MPSA92 at Q6. These are high-voltage transistors and they are able to supply current to the Nixie tube at the high voltage it requires. It doesn’t need much current, only a few milliamps, so they don’t need to handle a lot of power. It’s the breakdown voltage that’s the important parameter.
Cathode driver
Now, I’ve shown the cathode side of the tube as going straight to ground. In reality, the circuit uses a 74141 high voltage decoder (or Russian K155N equivalent). This circuit converts four bits, presented simultaneously by four Arduino output pins, into one of ten output pins one at a time. It implements a table that looks something like this:
So, let’s put the anode driver circuit (represented now as just a box) and the cathode driver decoder chip together and see how the ArduiNIX connects to four tubes.
One tube at a time
You should only drive one tube at a time, for two reasons: 1) you don’t want to make the decoder pull too much current and exceed it’s maximum dissipation rating and 2) it’s boring to have all the tubes show the same numeral at the same time!
Instead, your software needs to drive just one tube at a time in a four step process:
- Set all four output pins (2 through 5) to have the decoder select one cathode
- Set just one of pins 10 through 13 to turn on just one anode of one tube
- Leave the tube on for a minimum length of time
- Turn that anode driver off before you go to the next tube.
Wait for ionization
You have to pause on each tube and keep it lit for a millisecond or so. Nixies are slower than semiconductors. It can take from 10 mS up to 50 mS to get all those glowing ions moving from a cold start. Even after the tube is up and running, it can take at least a millisecond to light up the second cathode when you are switching from one cathode to another. So, your code needs to set the decoder, turn on the appropriate anode driver to light up the tube, and leave it that way for a relatively long time. Your code can go off and do other stuff while the tube stays lit, however, so there’s no worries.
On the positive side, Nixies stay lit for a similarly long time period (10 mS or more) after you remove the voltage, so this persistence works to our advantage during multiplexing.
The complete block diagram
The ArduiNIX includes two decoder chips, so the whole schematic (except for the high voltage power supply) boils down to this:
The same principle applies, but we can light up two tubes at once and cycle through all four pairs as fast as possible.
Simplified multiplexing code
The code (again, simplified and squeezed to fit on the blog) might look something like this:
// Variables // first, keep the numerals in an array byte NumberArray[8]={0,0,0,0,0,0,0,0}; const byte numberOfPairs = sizeof(NumberArray)/2; // Set the minimum time to keep a tube lit const byte MinimumNixieDelay=5; // Remember when we can light up the next tube pair. // This needs to be big to reduce rollover problems unsigned long TimeForNextNixie; // Keep track of which pair of tubes are lit int tubePair; // setup code omitted for brevity void loop() // Arduino main loop { // loop through all the pairs of nixie tubes for (tubePair=0; tubePair < numberOfPairs; tubePair++) { // light up a pair of tubes and leave them lit DisplayNumberPair(tubePair, NumberArray[tubePair], NumberArray[(tubePair+4)]); // Set the future time to light the next pair TimeForNextNixie = millis() + MinimumNixieDelay; // use the time while the tubes are lighting up // to do other stuff OtherStuff(); // Finally we wait in case we still // have time left in the minimum interval. while (millis() < TimeForNextNixie ) { delay(1); } } // end of for loop }My demo hardware arranges the tubes in a line exactly like this, so you can see the multiplexing in action in the following short video. Notice how some frames show one pair lighting up while the previous one is still glowing. This is the persistence I mentioned earlier. When I speed up the multiplexing rate, it looks like all the tubes are on simultaneously. You may notice a little flickering. I think this is a combination of several factors: the multiplexing itself, the interaction between the frame rate of the transcoded video and the multiplexing rate, and the tube’s natural variations. It’s visible in person, not just on a recorded video. In the end, I like the effect. It’s all part of the overall tubalicious Nix-a-esthetic!
Next time
Next time, we’ll take a look at your options for cabling up your tubes, and then we’ll look closer at the software.
Thanks very much for these posts. They are very informative and helpful as I'm putting together my Arduinix. I'm looking forward to future articles.
ReplyDeleteGreat stuff.....when do you expect to publish your next ArduiNIX article?
ReplyDelete'Sorry for the delay. I'm investigating the Ardunio scheduling & state machine libraries and sketching out software. I'll have something up soon!
ReplyDelete