Philco nixie clock


I first read about nixie clocks in a 2002 IEEE Spectrum article and immediately wanted to build my own. I picked up some tubes on Ebay but never got around to finishing a clock project. The best designs are executed in beautiful wood or precision-crafted metal and glass, and my shop skills aren't great.

Fast forward twelve years, and I had just acquired an old tube radio, a Philco 42-323 manufactured in late 1941. Although antique-radio purists might object, I thought this could be a good chassis for my nixies (tubes on top). The technologies at least date to the same era.

As the project took shape in my mind, I decided to turn the radio into an audio “time machine” using an MP3 player with World War II radio recordings found on the web. I wanted to keep the old radio intact, so this was to be accomplished by means of an internal AM transmitter. The audio player suggested an embedded Linux design, so I decided to structure the project around a Raspberry Pi, with a daughterboard of my own design containing the tube drivers and AM transmitter.

Fixing the Philco

I was told the radio was not working, and some online research suggested the first recourse (before applying power, even) was to replace all of the old leaky wax-and-paper capacitors with new ones. Working inside an old radio chassis with its point-to-point wiring and components jammed in every which way gave me a new appreciation for printed circuit boards! It helps to take close-up photos of the wiring before starting.

With the capacitors replaced, I plugged in the set and... nothing. None of the tubes lit up, which I learned is because all of the filaments are connected in series, so any one burned-out filament is like a fuse for them all. Continuity testing quickly revealed the bad tube, and after replacing this the radio came to life. Hooray!

Nixie and Dekatron power scheme

My ZM1042 nixies want a supply voltage of at least 180V at perhaps 5 mA per tube, and the GC10-style Dekatron at least 350V at a few hundred uA. The safer way of providing these voltages is usually a DC-DC converter circuit powered by a low voltage supply, but when starting with a 120V appliance, it is very tempting to adopt a simpler design and just “be careful”.

I ultimately settled on a 120V-to-240V center tapped power transformer, followed by two stages of full-wave voltage doubling. Using a toroidal transformer also allowed me to add a separate ~ 7V secondary winding for a linear 5V supply for the Raspberry Pi (see below). Under load, the doubler stages yield 280V for the nixies and 570V for the dekatron. Of course, these are lethal voltages and great care is required.

Philco enclosure with radio chassis removed, showing power transformer

The radio is connected to one leg of the center-tapped secondary, considerably improving its electrical safety: In its stock configuration the chassis could end up either hot or neutral depending which way the [non-polarized] plug went in! With the galvanic isolation afforded by the transformer, one should not get a shock by touching any part of the circuit with one hand.


The Raspberry Pi doesn't have many GPIO lines on its expansion connector, but it does provide an I2C interface, so I used a couple of TI “port expanders” (TCA6416A), remote GPIO ports controlled through I2C commands. My Nixie drive scheme requires seven GPIOs per digit, leaving four GPIOs free for controlling the Dekatron and flashing seconds indicators.

Some builders like to use the TTL 74141 driver IC or its more-available Russian clone, the K155ID1, but discrete transistors work fine too. I used the 2x5 driving scheme suggested here with PMBTA42 dual transistors, which pack two MPSA42s in a single SMD package.

The nixies are mounted in sockets procured on Ebay. The ten cathodes are soldered to ribbon cables with 10-pin IDC connectors at the other end, for mating with the PCB. The anodes are “fly wired” to the high-voltage supply through their anode resistors.


Dekatron drive waveforms were obtained through a combination of MOSFETs and 47V zener diodes. (Note that the schematic has an error here: D2 should actually be two diodes, one in each branch.) For some reason the reset logic is not working, but I haven't investigated further. To spin the Dekatron one direction or the other, the guides G1 and G2 are driven with quadrature square waves.

IN-28 seconds indicators

I initially planned on using a pair of ordinary neon lamps for the seconds indicator, between the hours and minutes nixies. Then I came across these large (and cheap) IN-28 indicators from Ukraine.

I decided to have some fun and, because I only had a single control line left over, put the two tubes into a configuration where each input pulse (via MOSFET Q24) transfers the glow back and forth between them. The inspiration for this came from a truly remarkable page on neon ring counters by a Philips employee with a keen appreciation of history. My circuit is essentially Figure 5 on that page, but with only two stages and some additional biasing for the trigger/grid of the IN-28s. (Each pair of bias resistors adds to 1-2 Mohm, with the grid potential chosen so that one and only one tube lights up when power is first applied. Some experimentation was necessary to get the values right, as my tubes had slightly different trigger voltages.)

Neon “logic” such as this is possible because of the hysteresis inherent in the gas discharge: The strike voltage required to light up a tube is quite a bit higher than the maintaining voltage required to keep it lit, and this comprises a sort of memory. In principle, one could build a computer out of neon tubes, and in fact this was done with the Dekatrons (see

Radio transmitter

The AM transmitter takes the rather low-fi mono sound output from the Raspberry Pi and broadcasts it at a frequency determined by the LTC6904 I2C-programmable clock generator. I am using a class E amplifier designed using free online tools, then simulated in LTSpice. This is mostly for fun as I wanted to learn more about this highly efficient topology. In my case the modulation is supplied by a single-supply op-amp (LTC6252), which destroys this efficiency by burning the difference between 5V and its instantaneous output as heat. A real class-E design would use something like a buck converter instead, but at 50-mW output power, who cares?

Most of that RF power is dumped into a resistor, but there is enough coupling between L2 (air core, wound on a film canister) and the Philco loop antenna for a good strong signal. RV1 and the RPi audio output level are set so the op-amp output does not clip, leaving a ~ 1V minimum drive level on Q21's drain. The audio quality out of the RPi isn't great, but it sounds fine on the Philco speaker, as good as any other broadcast station.

Battery-backed clock

The Raspberry Pi does not have a real-time clock on board, so I added a DS3231 on the daughterboard. The CR2032 battery should keep it running for the useful life of the project. Of course, when an Ethernet connection is available, the RPi gets accurate time via NTP.

Added electronics: Raspberry Pi, daughterboard, and power supplies (on perfboard)

Raspberry Pi, lessons learned

The Raspberry Pi is loaded with Raspbian distribution (Debian with some customizations) and runs a simple C program to read the system clock and drive the nixies, dekatron, and IN-28s via I2C commands. At startup it also sets the AM transmitter frequency and grabs the current time from the DS3231 RTC. In the background, mpd loops through all of the MP3s in the audio directory. A pushbutton behind the radio will skip to the next audio file, or, if held down, will initiate a clean shutdown (see below).

The RPi was the cheapest embedded Linux option and mostly works ok, but it comes with some baggage. There are persistent reports of unstable hardware or hardware bugs. Some of these relate to USB, which I am not using, but others have to do with SD-card corruption, especially when power is lost abruptly. (Because the RPi has no on-board flash, it must boot from the SD card every time it powers up.) The devs are unapologetic, pointing out that the problems are due to improper shutdown. While technically true, this ignores the fact that bad shutdowns leading to an unbootable system are virtually unheard of nowadays on any other Linux-based system. So, the Raspberry Pi turns out to be a rather poor choice for embedded projects.

In this project I have mitigated the risk of improper shutdown by (a) mounting most of the filesystem read-only, and (b) providing a shutdown button on the back of the radio. If I had it to do over again, I would choose a more robust embedded platform like the Beaglebone Black.