naked nixie - modern take on nixie clocks

1 year 2 weeks ago #7577 by vladco

I wanted to share with you my not yet finished nixie clock.

The story:
I first saw a nixie tube clock some years ago and I said I need to have one. Time has passed and it was time to actually start building it and i set some project goals:
  1. front viewing tubes
  2. hardware (cathode drivers) made with jelly beans parts (like Dave from EEVblog like to call them) - this was mostly because prices at the distributors in Romania are high and the availability of some high voltage drivers usually used in projects are simply not available, also it needed to be modular because i haven't decided yet if i want a 4/6 tube clock
  3. it needed to have WiFi simply because i had most of the software written for a different clock which has an web interface.
  4. power in should be 5V so i can power it from a phone charger
  5. nice hardwood case

After i had the goals set i started looking for tubes and i chose the IN-4 because they had a nice size (not to small and not to big) and i found them on ebay sold by someone from Romania so i could source them locally. In the process of searching for tubes i found a nice IN-4 with a find grid from Ukraine, and between the bought tubes i found one that has slightly different digits

For hardware (cathode drivers) i found this blog post which talked about using low voltage drivers with zener clamping and i thought i would give that a try. Driving the cathode drivers was accomplished with the good old '595 shift register. At that moment i have decided i would go with direct drive instead of multiplexing.

Initial HV power supply was based on M. Moorrees MK 1.5 design which worked perfectly for testing but had the minimum input voltage too high for my goals.
After spending a lot of time looking for a design which will allow a smaller input voltage i found Taylor HVPS which were a perfect fit.

Fast forward some 1-2 months for PCB development and production and the first prototype was working, though i have chose to use the ULN2003 with a 47V clamp which for my IN4 was too low and caused a "glow" when no digit was driven, but moving to higher voltage SN75468 with 75V clamp voltage solved the problem.

As for the brains i went with the ESP8266 because i had most of the software already written for a different WiFi clock. While waiting for the brains i designed a nice wooden case in Fusion360 and with some help from NOD makespace the case came to life (oak wood, CNC milled)

anyway i was a nice journey and the clock is almost complete, some small firmware changes are needed and the case still needs to be finished :)

some pictures/videos with various stages of the build process


Please Log in or Create an account to join the conversation.

1 year 1 week ago #7578 by Ty_Eeberfest
Looks good!! How well does the ESP8266 maintain accurate time, e.g. how often do you need it to update from NTP (or whatever) to stay within +/- 1 second of correct time??

Look into it later when the dust is clearing off the crater.

Please Log in or Create an account to join the conversation.

1 year 1 week ago #7579 by vladco
Hi Ty,

The main clock routine is implemented in a system timer of the ESP and I do an update every 12hours from NTP, not sure how accurate it is because I never looked into it, so far it was good enough :D

I will however look into implementing a better NTP (actually SNTP) client taking into account all the delays added by the communication and so on.

The following user(s) said Thank You: Ty_Eeberfest

Please Log in or Create an account to join the conversation.

1 year 1 week ago #7580 by Ian
Hi Vlad,

really nice work! I'm curious about a few things:

Did you have to use any level shifting on the outputs of the ESP8266?

Do you do anything for DST? Do you have an algorithm for that, or are the dates sort of "hard coded"?

Does the clock do any dimming? I am facing a problem doing dimming on the ESP, because the human eye is very sensitive to changes in brightness, and when the ESP works on web, it stops working on the dimming (it is single core, web gets priority). I'm using dimming using PWM of the HV, and the PWM signal needs to be really stable.

Which ESP are you using ESP12? Did you have a look at ESP32? (My next design is probably going to be based on ESP32).

Would you like to do an article about your experiences? I'd help you with putting it on the site if you were interested... I'm sure the readers of the site would love to read about it...


Please Log in or Create an account to join the conversation.

1 year 1 week ago #7582 by vladco
Hi Ian, thanks, a lot of work went into it.

to answer your questions:

1. the ESP is driving the '595 shift register which is a TTL part, even if i power it @5V the 3V3 from the ESP is enough to register a logic one, so no level shifting, i could also power the shift register from 3V3 because the variant i am using could got down to 2V VCC

2. DST currently is handled manually via webui but the plan is to move to an API provided by google which should give you the timezone and DST based on geographical location but i haven't looked into that yet manually works just fine atm :)

3. they idea was it should do that, and i was going to use the OE (output enable) of the '595 shit register for that purpose - unfortunately i didn't pay close attention to the datasheets where its stated that when the OE is HIGH the outputs are HiZ and i am not entirely sure what the darlington array is doing when its not driven.

for the webui I'm using the great work of Hristo Gochkov, with his implementation of AsyncTCP, AsyncWebServer which compared to the stock tcp/webserver implementation is a x10 (maybe more) improvement in speed, resources and usability. , if you are not using this and you are serious about using the ESP for webui and other task take a look at them - you will not regret it :D

4. The ESP is the ESP07, i haven't looked yet at ESP32 because currently the resources i have on the ESP07 are enough for what i am doing.

regarding the article, sure we can talk about that :)

The following user(s) said Thank You: Ian

Please Log in or Create an account to join the conversation.

1 year 1 week ago #7583 by vladco
Regarding your brightness issues you may want to look into brightness correction or gamma correction as is sometimes called

A few years ago I did a project with some LEDs and I achieved linear brightness using a lookup table to drive de PWM, you can find the lookup table here with a link to the original source

I am not sure if Nixie respond the same as LEDs but you could give it a try.

Also if anyone is interested I have a github repo with all the work done for the clock - it's still a work in progress :D

The following user(s) said Thank You: Ian

Please Log in or Create an account to join the conversation.

1 year 6 days ago #7602 by vladco
on the matter of clock accuracy how does one test the accuracy of his clock ? Do you just take a somewhat accurate clock and compare it with your own ? or is there a more complex method of testing ?

Please Log in or Create an account to join the conversation.

1 year 6 days ago #7603 by Ty_Eeberfest
My test method is simple: over a period of several days, occasionally compare the Nixie time to a GPS sync'd device such as my mobile phone.

I've read about other guys picking up old atomic clocks (rubidium? cesium? can't recall, just know they are made by Hewlett Packard) off eBay, restoring them to working condition, and using them to run sophisticated testing and logging on their clocks. But I think that's a bit crazier than I want to get.

With my phone as a reference and a good TCXO controlling the clock, I've been able to tune my clocks in to about +/- 2 seconds per year, which is quite good enough for me, especially since my clocks do not sync to NTP or GPS or WWV or anything.

Look into it later when the dust is clearing off the crater.

Please Log in or Create an account to join the conversation.

1 year 6 days ago #7606 by vladco
+/-2 sec a year is pretty darn good!

When i first implemented a clock on the ESP8266 controller i only synchronised the clock on power on but after a few days the clock would drift +/- 1-2 minutes

After that i started synchronising it every 12h and that seemed to give better results and the drift was not noticeable any more.

Today i started looking more into the internal timer which currently counts the seconds in the current design and found out its highly dependent on the wifi tasks and its not really recommended if you need any acurracy

The good thing is that the ESP has two more timers which can be used to keep time also given that i can sync it via NTP i think i can make it sub second accurate :D

Please Log in or Create an account to join the conversation.

1 year 5 days ago #7608 by Ty_Eeberfest
Please keep us updated on how that goes. I know the timers on the ESP chips have a reputation for being inconsistent, that's part of the reason I was asking about accuracy in the first place. I'll be interested to hear if you can come up with a way to keep really stable time, with only infrequent NTP hits, using only ESP on-chip timers.

I vaguely recall seeing some ESP clock circuits that relied on a Maxim / Dallas clock chip for accurate timekeeping and pulled time from the chip by way of SPI or I2C or something.

The way I get the accuracy on my clock designs is pretty straightforward, at least hardware-wise. I let the Atmega328P run off its internal 8MHz system clock oscillator (who cares if the CPU speed isn't perfectly stable). That leaves the TOSC pin available to hook up a 32KHz crystal (poor) or a Maxim DS32KHZ TCXO chip (excellent). Software configures the 328 to send TOSC to a prescaler and on to a hardware counter. Hardware counter fires an interrupt precisely once a second regardless of CPU drift, CPU load, etc. etc. What's also kind of cool is that if you lose power, the 328 can go to sleep and be just fine powered by a 3 volt coin cell. Sleeping 328 + DS32KHZ = only a few microamps, The aforementioned counter still counts, and its interrupt keeps firing to wake the CPU once per second so it can update the time and go right back to sleep. In theory it can keep time for a few months running on the coin cell though I've never really tested it.

The last step to getting the tightest possible accuracy requires patience. In my experience the DS32KHZ always run a tiny bit fast, probably because they are "certified" at 3.0VDC but I'm using them at 3.3 or 5.0 volts (which is OK but it makes the frequency output a little high). By observing the clock over a period of weeks I can figure out how much too fast it is running, then do some math, and come up with a "calibration value". Based on that value I can then (in software) drop one count (of the *hardware* counter, so it's 1/256 of a second) every so often to keep the clock on time. Typically it ends up being 1 count dropped every 1000 seconds or so in a 5 volt system. Note that this count dropping is only done when on "line" power, since when it's sleeping on battery power the voltage to the DS32KHZ is 3.0, so it's not running fast. I usually end up changing the calibration a few times during the first year or so of the clock's life, thus the need for patience! It's a slow tweaking-in process.........

Yeah, I could have saved a lot of complexity by designing in a precision 3.0 volt regulated supply for the DS32KHZ and maybe I will some day, but I figured all this stuff out gradually and things just sort of evolved. Also, regulating 5 volts down to 3 is simple but when it fails over to battery I'd need the regulator to "disappear" since the battery voltage and the desired DS32KHZ voltage are the same - 3 volts. I'm not aware of an LDO regulator that will behave itself when VOut == VIn.

Sorry about the wall of text... got carried away.

Look into it later when the dust is clearing off the crater.

Please Log in or Create an account to join the conversation.

Moderators: AccutronTy_EeberfestIan
Time to create page: 0.115 seconds


Tube Suppliers

Go to top
JSN Boot template designed by