My experience with the Arduinix Nixie tube shield

This was not an easy project to finish. Anything that could go wrong, it did, due to a rare combination of ambiguous hardware kit design (that's what started it all), and bad luck (software bugs in Arduino IDE 1.0 nevertheless). In the end, I learned a few things, which made me a better person :) :) :)

Please don't take this as a rant, nor as a (negative) review. As usual, the main purpose of the post is to document the experience and eventually help others troubleshoot similar problems they may have with the Arduinix shield kit.

The first issue I had was not getting the high voltage (180V) required by the Nixie tubes. For some reason, the provided schematic and assembly instructions are ambiguous on the exact value of the C3. This made me look at other HV power supplies, with the conclusions captured in this post. Anyone taking a closer look at the Arduinix HV schematic will notice at least 3 differences compared to others using the same 555-based design:

- the very important capacitor C3 has unusually small value (only 47pF, compared to 2.2nF, a much better value, according to the calculations);
- pins 6 and 7 are connected;
- transistor Q5 is shown as PNP (though correctly marked as MPSA42, an NPN transistor).

The assembly instructions, showing 2.2nF for C3, say that the value of this capacitor varies "the most", "as we make slight modifications and improvements to the kit". What improvements in a standard, proven and tested schematic?

What else was there for me to try? Most of the components around the oscillator, of course: the inductance, the resistors, the capacitors. The highest voltage I got was about 80V. So I decided to revert to "the standard". I cut (top side) and re-routed (bottom side, see photo) the PCB traces around pin 6, 7 and R14/16, I replaced C3 with a 2.2nF, and, unsurprisingly, I got the long desired 180V.

Next step was the software. After I uploaded the sample sketch using Arduino 1.0, only 2 digits were lit.
Three hours and a lot of effort and frustration later (even wondering how everybody else got this sketch working), I realized that Arduino 1.0 itself was the problem. Even the simplest test sketch, tried on multiple Arduinos, failed, incredibly, to work!!! (And you can try it and confirm this too.) Here it is:

void setup() 
{
  Serial.begin(9600);
  Serial.println("in setup");
}

void loop()     
{
  Serial.println("in loop");
  delay(1000);
}

Switching to Arduino 1.0.4 solved it. My Arduinix shield is now functional. Making it into a clock is going to take a few more steps though, including hardware (adding RTC, probably by resurrecting Wiseduino+), writing the software (with functionality to set up the time from buttons), and of course, the most challenging of them all, making a proper enclosure.

A few more observations:

- the INS-1 neon lamps are too tall to be used as dots between the IN-17 Nixie tubes;

- it seemed that the little Nixie PCB could be placed at the same level as the Arduino board (and under the shield, as opposed to on top, as it is currently, see the photo above); it has holes that align with those in the original Arduino 2009, but the ICSP connector is in the way though;

- all photos on arduinix gallery show the Nixie board attached to the shield by ribbon cables; I wondered a bit if my solution, using regular headers, was proper;

- this is the cheapest open source Nixie-kit out there.

High voltage power sources for tubes (Nixie, VFD, Geiger)

Updated June 2, 2017 - added VFD power supply with automatic dimming (#4 in the list below), contributed by Ken

This is a superficial review of the few schematics I encountered while building Nixie clocks, VFD clocks and Geiger counters (no tube amplifier just yet). Although the schematics seemed basic at a glance, they usually ended up being a challenge (that is, they rarely worked right away) for me. That's another reason I am trying to cover them here, so I can use this post as consolidated reference any time I need it.

Tubes require high voltage to work. Some (Vacuum Fluorescent Display) need 40V, others (Nixie) 180-200V, and some others (Geiger) even higher, 400-1000V. The high voltages are generated these days by switching-mode power supplies. Essentially, there is only a handful of popular solutions, and each DIY tube kit picks one of these, based on size, power requirements, cost.

In principle, a switching mode power supply, also known as "boost converter", uses a square wave oscillator ("switch") to create magnetic energy in an inductor, then releasing it as high voltage.
Some scientific explanation (with formulas) can be found here, some practical advice (with schematics and photos) here. Adafruit has a very useful online boost calculator.

1. One of the most popular solution for the square wave oscillator is by using the ubiquitous 555. This is inexpensive, but requires some tweaking and adjusting (values of resistors and capacitors). The schematic is standard, but there seem to be a few variations.
The one below is from Ronald Dekker.

Frank clock (from Pete's Nixie kits) uses an almost identical schematic, but a different set of values for R2-R3- C4 (used for setting the frequency). In the end, the oscillator frequency is about the same at approx 30kHz, calculated with formula  f = 1/0.693/C4/(R3+2R2)  (in the schematic below).

Same 555 is used in Arduinix, but in a different configuration, although still as astable oscillator. This one has an extra HV capacitor (C4) in series with a resistor (R15), whose exact purpose I don't understand. The oscillation frequency is also weird, according to the above formula, with C3 at 47pF, should be 1.5kHz. No wonder this did not work for me.

Another almost identical HV power supply for Nixie tubes is used in the recently-kickstarted "Nixie tube shield" (for which I pledged $15 for the PCB, and yet to receive it).

And finally, 555 is also used to generate the higher voltages required by Geiger tubes, as used by BroHogan (and MightyOhm). The frequency of oscillation is 4.5kHz (f = 1/R1/C2). (I built several Geiger kits from BroHogan and they were all trouble-free.)

2. Other solutions use specialized chips like MAX1771 and MC34063.
Shown below is the high-efficiency boost converter from Nick de Smith (sold by ogiLumen), based on MAX1771.

Akafugu's VFD Version 1 clock uses the same MAX1771, to generate a lower 50V (for VFD tubes) MC34063 to generate 38V for the tubes (thanks Ken for the  correction - see his comment at the end of the post).

For MK2, Akafugu uses the same MC34063 chip (schematic not published yet).
The same chip is also used in their Nixie clock (schematic shown below), to generate 180V. This HV circuit has its own (all SMD) board, which I assembled it myself and worked without a glitch.

3. Yet others use a PWM pin of a microcontroller. This method requires the processor to be connected and programmed in order to generate the high voltage. The solution is cheap (saves an extra chip), smaller in size (again, one less chip), and also seems to be highly efficient.

Below is the HV schematic used by Adafruit's IceTube clock.

Some of the microcontroller-based boost converters have feedback (close loop, with PWM adjusting to the voltage output, if I am not mistaken), as are those from Cogwheel and Satashnik (shown below, respectively).

As with any analog electronics circuit, troubleshooting a HV supply is not easy. A suitable tool would be an oscilloscope, allowing for the measurement and adjustment of the frequency and pulse width. Once these are cleared, the high voltage could be adjusted usually from the trim pot. To modify the voltage range, try different values for the inductor.

4. A very useful addition is Ken's VFD power supply with automatic dimming, schematic shown below. Detailed info can be found here.

Play Tetris on Wise Clock 4

No kidding.
I was looking for a suitable application to demo with Wise Clock 4 placed vertically (that is, standing on its shortest side), when I found this hackaday post about Tetris on a LED matrix. The code, already written for Arduino, clean and easy to understand (kudos to Jianan), was a breeze to port. I only had to change a few functions (display, user buttons), comment out a few more (sound, text etc) and downsize from 7 colors to just 3.
Commands come from Bluetooth terminal ("BlueTerm" app on Android), basically replacing the buttons with letters (U, R, L, D; you got the idea).

The Wise Clock 4 vertical stand is possible thanks to the enclosure-mounted power jack, wired to the display's screw terminals, as shown in the photo below (that also captures a part of my messy desk).

(This is a typical example of how one thing leads to another. I don't usually play games, but when I do, I use my implementations. "Time well wasted", as the saying goes.)

New release of Wise Clock 4 software

Some of the latest software features have already been introduced (see this post). Since then, a few bugs have been fixed (again, thanks Mike!), the code was streamlined even more, and some apps (Countdown, Score, Stopwatch, Quote) have been expanded and improved.

Below is a list of the most recent code changes:

• added PWRON setup option to select app to run when the clock starts up;

• compilations options (add/remove features) moved to file "UserConf.h". That is:

- Instead of editing WiseClock.cpp to select applications to build, edit "UserConf.h".
- Instead of editing WiseClockVer.h to select WiseClock 3 or 4, edit "UserConf.h".
- Instead of editing HT1632.h to select the number of displays, edit "UserConf.h".

• on dual display, Countdown includes days as well, in the format DD:HH:MM:SS;

• Countdown shows the correct amount of time left even if power was down for a while (this is done by saving the end time in eeprom); for this feature, the PWRON must be set to "CNTDWN";

• similar to Countdown, app Score has been extended to "remember" the numbers even after the power was out for a while; in either case, the respective app must be selected in PWRON;

• ability to display quotes randomly, if the user selects "RND" in app Quote;

• on dual display, Stopwatch is now using regular-size font (still using tiny font on single display);

• Stopwatch has a new mode, "Conventional", in addition to the previous one (called "Rattrapante"); the conventional mode accumulates the time passed between consecutive presses of the start/stop button, as a mechanical chronometer would do; "rattrapante" mode shows the amount of time passed from the moment it was first started, regardless of how many times the chronometer was stopped;

• on dual display, with "Font+" selected, Score and Stopwatch are using big font and no longer show the current time on the bottom line (they show as before with "Font-" selected); 

One of the challenges in writing complex code for embedded systems is the compromise between following an Object Oriented approach and trying to minimize the amount of RAM at runtime. Let me elaborate a bit. Each C++ object, once created (at runtime), used or not, takes some RAM, storing data members and the vtable (when using virtual functions). Wise Clock software is trying to follow an OO design. Each App class is derived from an abstract base class. The base class defines 2 pure virtual functions (init and run), which must be implemented by every App class.

At runtime, each app is created as a static object. Therefore, if 12 apps are declared (through the use of ifdefs in UserConf.h), 12 objects will be created in RAM, each one storing its own data and its own vtable. That's a pretty big price to pay in the world of embedded systems with little RAM space (just a guess, based on my very limited experience).

A non OO approach would create and use variables only for the app that is in current use, as the code is being executed. Although this solution would use less RAM, the current complexity would make the code unmanageable.

So back to the compromise, how does one solve it? (This is not a rhetorical question.)

Mechanical Design and Engineering

I was having a conversation with my friend JohnW, a Mechanical Engineer by education and trade, about his latest "small" project. I suggested he should publish and document aspects of his interesting work. But he mentioned he does not have a blog just yet, so I "volunteered" to do it for him right here, as a quick (and hopefully useful) example.

John designed a portable agitator, a device used for mixing low-viscosity liquids or liquids with small-size solids.
Mixing is performed by a propeller driven by an internal pneumatic system, and not using an electrical motor, as shown in the diagram below.

The whole contraption is made of plastic, calculated for a maximum internal pressure of 80 psi.
The liquids are poured in manually, through PRV-07 (features a screw-in lid). The mixed liquid is released through the pinch-valve PRV-06. The lid PRV-01 can be removed (8 screws) for inside cleaning.

The mixing capacity is 1 gallon, but it can be easily scaled, in both dimensions and power.

This agitator was designed to be safely used in the food, pharmaceutical, chemical industries.

Here is a photo of the agitator built to specs.

If anyone is interested in this kind of engineering work, I will be glad to re-direct them to him. John is versatile, works on tight budgets and schedules, and very proficient in Autocad, Inventor etc.