Nixie Tube Clock

If you've poked around the internets where electronics hobbyists collect, it is likely that you are acutely aware of our incontrovertible affinity for building timekeeping clocks.  It is similarly unlikely that you have been able to evade the plenitude of nixie tube based projects.  There is a reason for this.

Nixie tubes are cool.  They have great aesthetic appeal with their difficult-to-photograph, warm orange glow, and dem curvy numerals.  They add an organic je ne sais quoi to a hobby with ostensibly digital design cues.  Further, they pose technical challenges in the way of producing and switching the ~175 V DC needed to light each tube element.  And as far as I am aware, there are no new nixie tubes being produced; as such, procurement can be a challenge unto itself.  My N.O.S. nixies came from Russia thru Ebay, and only 3 were duds.  Incidentally the seller replaced those 3, FOC.

The strike thru text above results from a tip from +nicholasStock  who points out new nixie tubes ae in fact being produced: http://www.daliborfarny.com/  The linked tubes are really impressive from a technical standpoint as well as asthetics.  They seem to amplify all of the design cues we love about NOS nixies and the results speak for themselves.  Might still be an issue with procurement, however...

Nixie Tubes and HV Driver
From Russia with love

K155ID1's are shipped in stacks bound by rubber bands

Fortunately, not all nixie tube clocks are implemented the same.  In fact, look around at all the schematics for nixie clocks, and you will realize there are more permutations in methodology than there are models of nixie tubes.  This is how it should be.  We ( DIY electronics people ) like to put our own spin on things.

My version of the Nixie Clock has a few of its own nifty features.  The list includes:

• Single microcontroller design.
• Software based RTC.
• Software driven boost converter for ~175 V DC supply.
• Time, Date, and behavior configuration via USB
• Windows application for clock configuration.
• Time, Date, Temperature, and AC Power line frequency display.

The Name

I was working on the PCB layout and thought it would be cool to write "Nixie Tube Clock" in Cyrillic script, so I did a google translate.  You can see the translation on the top right of the PCB.  Well, it turns out that "Nixie" translates to something of a shapeshifting water-woman.  So, I call this the mermaid clock now.  Thanks to the native language speakers that pointed this out to me.

Downloads

The clock firmware can be found on GitHub here: https://github.com/pilotingpete/Nixie-Tube-Clock

The Nixie Clock Communicator code can be found on GitHub here: https://github.com/pilotingpete/nixieClockCommunicator

An Electronics Bill of Materials - Please notify me of any errors: BOM

The KiCad schematic and board files.  Also, a collection of datasheets, and some logfiles from when I calibrated my prototype clock.  Perhaps there are some other files in this archive that I thought were useful while I was working on this project too: Electronics Package

Here is the current schematic in PDF in case you don't have KiCad installed.

Researching Nixie Tubes online I learned about Cathode Poisoning.  I don't know a whole lot about it, but suffice to say an unused or seldom used nixie element will deteriorate over time.  I read that you can sometimes reverse this deterioration by applying a higher than normal voltage to the element for a period of time.  I also read that you can try to make sure all elements get some ON time to prevent or slow the deterioration of elements.

The last paragraph should be read as "We have an opportunity to do some neat blinky stuff with our tubes!"  Hence, the video below.  This pattern occurs every 30 minutes - at the top and bottom of each hour.

RTC

Four short years ago I posted about a method for building your own microcontroller based realtime clock.  This is essentially a method to calibrate your xtal to more closely match real time, and some code to keep track of the time and date.  The benefits of a uC based RTC include a reduction in components and everything that comes with that; increased reliability, cost reduction, real estate savings, &c.  We can also achieve accuracy in timekeeping greater than that specified in stand alone IC RTC's datasheets.

In the aforementioned post, we only discussed the theory and showed a proof of concept example.  There were no software provisions for calendar with leap year, 12/24 hr format, etc.  That is, the finishing touches to make a useful RTC for a clock were left out.  This nixie clock builds upon the methods for coding your own RTC and shows the implementation to make a useful clock.  This code could easily be recycled into any number of clock projects with LED, LCD, OLED, displays too.

The core RTC code can keep track of the time and date, account for leap years, and report the day of the week.  One could expand this to take care of DST, but I go into detail about why I don't in the previous post.

While designing the hardware for the clock I added a "zero cross detector" to the incoming AC power line.  We can use this in lieu of the calibrated xtal to keep time - users choice.

All those nixies controlled with just 3 uC lines.  Thanks, shift registers!

USB Interface

Using the ATMega328's built in UART we are able to communicate with the firmware via an FTDI USB cable to configure clock settings and behavior parameters.  These parameters can also be read back out of the clock and/or stored to the internal eeprom of the ATMega328.  Parameters stored to eeprom are read into memory at boot up, so that the clock's configuration is persistent thru total power loss.

For example, open a terminal to 56700 baud and type "celsius=1" and hit enter.  This will set the clock to display the temperature on the Celsius scale.  Setting this parameter to 0 would result in the Fahrenheit scale i.e. "celsius=0".

If you were to type "hours?" the clock would reply with "Hours: nn" where nn is the currently displayed hours.  There are also parameters for "showFreq", "showDate", showTherm; each of which are set to display its unique parameter value at the top of each minute or not.  i.e. if you type "showtherm=1" then at the top of each minute the temperature will be displayed - in Celsius or Fahrenheit as previously discussed.

Below is a screenshot of the available commands.  At the terminal type "help" and hit enter.  The column labeled "command" shows you the available parameters to configure.  "Set/Read" column suggests that you may set a value with '=' and read the value with '?'.  The "Low Lim" and "High Lim" columns show the range of acceptable values to input.

USB Terminal Interface

• "getall" returns a csv line of all current parameter values.  The order can be verified in the firmware.
• "ramtoeeprom" will store all current parameters to eeprom so that they are recalled after a total power removal.  Time and date are excluded - view the firmware to confirm all parameters that get stored.
• "poke" returns the clock serial number - mine is S/N: 100; what will yours be?
• "pwrok", "hvfeedback", "battvoltage", and "rectifiedac" return system voltages.  Refer to the schematic for voltage points.
• "doecho" is a UART echo and is useful for typing at a terminal; it lets you see what you are typing.  It is not so useful when using the NCC app and should probably be turned off i.e. "doecho=0"
• "nixiesleepstart" and "nixiesleepend" set the time that the nixies turn off and on at night.  We dont need to burn up valueable nixie time while we are sleeping.  If nixiesleepstart is 0, then they will never sleep and nixiesleepend is necessarily ignored.
• "toggleled" if set to 1 then the LED on PD7 will toggle at 1 Hz.  Set to 0 and no more toggling - the LED will remain in its current state.  It is neat, although power wasteful, if toggleled=1 and a power outage occurs.  The LED continues to toggle letting you know the clock is still running.  

Wouldn't it be cool if we had a PC app to handle all the communication?  So that we can just click a button and the app would send the current PC time to the clock, for instance?  I think so too, and more on that below.

A video showing the time, date (2015.05.29), temperature (28.93 C), and AC Frequency (59.991 Hz).

Boost Converter

The boost converter utilizes one PWM channel and one ADC channel on the ATMega328.  A function is called at 1 kHz to check the voltage coming out of the boost converter and thru a voltage divider.  If the voltage is higher than a setpoint, then the PWM duty cycle is reduced.  If the voltage is too low, the duty cycle is increased.  The resultant ~175 V DC is quite stable.

*I discovered that stopping the timer is not a suitable method of turning the boost converter off.  The state of the output pin can sometimes come to rest at ON.  The result is a direct short thru the boost converters inductor.  Many fuses gave indication to a problem here.  The solution is to disconnect the pin from the PWM timer in software and then set the output low.  Check the firmware and code comments for more information.

Reflow soldering the SMD components

Kapton Solder Paste Screen

Hardware

There were/are a couple of mistakes made when I designed the PCB.

First, the datasheet I have for the nixie tubes was incorrect.  I used the datasheet to make PCB footprints in KiCad and never checked the physical tube before sending the PCB to manufacture.  They were in the mail at the time.  The physical tubes are a full 180 degrees upside down compared to the datasheet.  I corrected this in KiCad and sent the new gerbers to be manufactured again.

The new boards came back ready to go.  Or as it would turn out, ready for me to find more mistakes.  Like R8, which is supposed to be a pullup resistor for the DS18B20 temperature sensor, not a pulldown as I drew originally.  I discovered this one when I couldn't get any temperature readings.  Rather than remake the boards I drilled out R8's via to GND and added a wire jumper to VCC.  You can see this fix below.

Drilled out VIA to disconnect R8 from GND

Red Jumper for R8 to VCC

The R8 pullup/pulldown error has been fixed in KiCad and included in V1.1 as REV A.

Prior to discovering the pullup/pulldown mix up on the DS18B20, I had discovered that my linear voltage regulator supplying VCC was overheating.  I had underestimated how much current the HV driver IC's would consume - they doubled the circuit total.  I also underestimated the voltage that would be coming out of my 12 V AC adapter.  It is approaching 18 V DC after rectification.

To salvage this embarrassingly obvious oversight I ordered 10 premade buck converters from ebay for about $10 total.  They are based on the LM2596 IC and are voltage output adjustable.  Now, I feed that ~18 V DC into the buck converter and send ~6.5 V DC out to the linear regulator.   Hopefully, I will remember this lesson and incorporate buck converters appropriately in the future.

Below are some pictures showing the repair/mistake.  Since this photo was taken I have potted the linear regulator and wires to prevent shorts or strain failures.

LM2596 Buck Converter

Buck Converter Wiring

I currently have several of these nixie clock boards as spare.  If you would like one, send me an email and I can figure out how much they cost.  Although I did drill out R8's VIA on all boards they are subject to needing the R8 jumper to VCC fix still, and the buck regulator fix described above.

SW1

There is an unpopulated tactile switch on my PCB.  I put it there "just in case" but I don't have a need for it.  Perhaps it could be used to cancel an alarm or put the nixies to sleep/wake them up?  Let me know if you end up coding anything for it!

 Battery Backup

In the picture below you can see the battery backup schematic.  BATT-4.5V is just a 3x AAA battery holder.  I resisted the urge to use a CR2032 battery or similar in lieu of the larger AAA batteries.  My reasoning being that I have plenty of real estate inside the clock case, and weight was not a concern.  Also, I always have AAA batteries on hand, and they are cheap.

So, this battery pack is connected to VCC via a schottky diode such that the battery is not a source so long as VCC is at a greater potential.  When power is lost, and VCC is at a lower potential than BATT_VOLTAGE, the diode allows the battery backup to conduct and keep the circuit alive seamlessly.

Here, BATT_VOLTAGE goes to the ADC on the ATMega328 and allows us to measure the voltage of the battery pack.  Presumably, we could work out a way to determine when battery replacement is necessary.  For now, we just read the voltage.

AC Frequency Measurement

Below you can see a schematic showing the method of digitizing the AC input waveform.  There is a nominal 12 V AC on L1 and L2.  AC_FREQ goes to a pin with internal pullup on the ATMega328.  Therefore, this pin is normally high and pulled low once per positive AC cycle.  Say, for an AC sine wave input somewhere between 0 and Pi there is a square pulse output. 

I included this part of the circuit mainly because I wanted to measure the ac frequency of the power line.  I have never done his before, and thought it would be a good opportunity to do so.  There is the added benefit that you could use this AC input to drive the clock if you were so inclined.  The software would just need to count up 60 cycles ( or 50 in some countries ) and tick over the seconds.

EDIT: As I wrote the previous paragraph I realized that I should just take a break and code the AC frequency as a timekeeping source.   To run the clock in this mode, you can now type "acclock=1" at the terminal.

I am partial to the xtal calibration method described in the RTC section above ("acclock=0") , but I do recognize that method takes some level of commitment to implement.  Certainly, both timekeeping methods have their merit based on the expected usage environment of the finished product.

When a power outage occurs and acclock=1 the xtal will step in and keep time.  Yet another good reason to run the calibration procedure anyway...

I tried to get a scope cap of what this looks like in operation, but it didn't come out very well because the AC and DC sides of the circuit don't share a ground.  Anyway here it is.  You can see blue half of the AC sine wave and the digitized red trace that we can feed to the input of the uC. 

Counting up the rising edges of the red trace until we get to our nominal AC frequency ( 60 Hz in the USA ) then ticking over our seconds.  So far this has been quite acceptable for accuracy although I have not run this mode for more than a week or so.

The AC/AC Transformer

Clock Case

Functionally, a clock case is very important.  It needs to provide thermal stability for the clock innards, mechanical protection from bumps and dings, light splash protection from water, and protection from dust, or rather a surface to collect dust that is easier to clean than the populated PCB alone.

Putting on my humility hat I attempt to create a clock case from wood.  Sycamore; locally harvested to be precise.  It is a work in progress, but my vision for the case involves dovetails, radii, and a glass front panel - possibly etched.  I hope to continue on the case soon - I imagine the wood quipping that it could have grow itself into a clock case faster.

Local Sycamore

Table sawing the 1-1/8" thick boards to half thickness for case sides.

Marking and cutting out dovetails

Admiring the Sycamore grain

Windows Application

The purpose of the Nixie Clock Communicator app ( NCC ) is to simplify the setting, and calibrating of this nixie clock.  It is not required for use, but is handy - particularly during development and debug. 

For instance, to set the time I could open a terminal and connect.  Then type "hours=12" [ENTER], "minutes=55" [ENTER], "seconds=13" [ENTER] and the nixie clock would be set to 12:55:13.  

No problem.  But with the NCC app, I can click the "Send PC Time" button and the app will look at the current system time, wait for a new second to tick over ( mS = 0 ), and then immediately send the seconds, minutes and then hours. 

Additionally, the app can datalog the time and date that the clock thinks it is, concatenate this with the PC time and date, and log this to a text file.  Using this information we can derive a calibration value such that the long term accuracy of the XTAL is compensated to drive the clock very near to real time.  More on this in the "Calibration" section below.

The app is written in C# using Microsoft Visual Studio 2013.  Although the code compiles, runs and does it's job, it is very much a work in progress - I am currently trying to work out some bugs where there seem to be some phantom characters triggering my serialRead event handler.  I am sure there is a logical explanation, but I have not sorted it out just yet.  If you do, please let me know!

Nixie Clock Communicator ( NCC ) app for Windows.

Calibration

Before you attempt to calibrate the clock it should be placed in a suitable enclosure.  One that is vented yet free from drafts.  The idea being that you want to keep ambient thermal excursions from affecting the temperature of the xtal case.  Direct sunlight might be desirable to avoid.

It does not greatly matter what the temperature of the xtal is, so long as it is stable over the long term. Having said that, if one were to have a choice of temperatures to put the xtal near, it would be wise to select one nearest to 25 C, however do not neglect the benefit inherent to a stable temperature.

It might save you some frustration to have tested out the battery backup before now.  However, if power outages do occur during calibration, the outcome may be an improper calibration value.  It occurs to me now that there should be a firmware counter that keeps track of the number of times the clock enters battery backup mode.  If that number is > 0 while calibrating, a new calibration should be performed.

Steps:

• With the clock in its case, and the case with the clock placed in its preferred place of use, set "mscal = 0" and set the time and date precisely and accurately.  Use time.gov or something similar.
• Allow the clock to run continuously for at least 1 week.  Longer calibration periods get a greater average of environmental changes and potentially a higher degree of calibration precision.  Allow the clock to experience all environmental changes expected during normal operation - if you have a programmable thermostat let it run its course etc.  
• Optional - use the NCC app to data log the nixie clock time, and host PC time/date to a log file.  I set my logfile up in a google drive folder so I can check the progress anywhere.
• When the clock has run for a week or more, compare the current real world time to that of your nixie clock.  This is particularly easy if you've been using the NCC app.
• If the nixie clock is running faster than the real world time, set "xtalisfast=1", otherwise "xtalisfast=0".
• Compute the time error in Parts Per Million by (realWorldTime / nixieTime)^-1
• Compute the mS Calibration value by mscal = F_CPU / (F_CPU * PPM_ERROR)
• Set "mscal=nnnn" where nnnn is the calibration value calculated above
• Read back your values to be sure you set them right: "mscal?" and "xtalisfast?"
• Store the values to EEPROM so they will be remembered even thru a total power loss by typing "ramtoeeprom" and hit [ENTER]
• Optional - remove power, reapply power and check that mscal and xtalisfast have been stored properly.

Below is a screen cap from some notes I took while calibrating my prototype clock.  The first 2 lines were generated by the NCC app and serial nixie data.  The nixie clock sends out the time/date that it thinks it is on the right at the top of a minute.  The NCC app prepends the current system time/date on the left then logs this to a file.  The last value on each of the first 2 lines is the current temperature.  In the example below, you can see my mscal value is 21180 and xtalisfast should be set to 1.

To be more explicit, the format of the top 2 lines in the screen cap below is as follows.  PC Date, PC Time, Nixie Clock Date, Nixie Clock Time, Clock Temperature in Celsius.

Since the proof is in the pudding, as they say I wanted to log some real world data to see how well this calibration scheme would work.  So, I stored "mscal=21180" as found from above, and ran the clock with the NCC app logging data again.  After 45 days it was revealed that the nixie clock was running 8.698 seconds fast which is about 2.24 ppm.

That's pretty darn good I'd say.  For reference, 2.24 ppm is about 70 seconds in 1 year, and somewhere around 46 seconds in 8 months.  Since I adjust for DST in intervals < 8 months, it is clear that the nixie clock should never be a full minute off from real time.

Miscellaneous

If you're thinking about skipping the fuse in the circuit, please don't.  It is remarkably important.  I once thought of using a PTC, but even that is a bad idea here.  You really want total separation from the power source and a deliberate reapplication.  To that end, do not move past a burned fuse until you fully understand why it blew.  Read the section on the boost converter and look at the schematic if you need further convincing.

This project has taken somewhere around 6 months to date.  I have to admit that I am a little surprised by how challenging this project has been.  It has also been a lot of fun.  If you have any questions, please feel free to email me or leave a comment.