Archive for April 2015
I become interested in Nixie tubes after I bought a Netduino and tried out the ArduiNIX. From that I decided to make my own Nixie Tube clock. My clock, besides showing the time, also shows the date, year, temperature, has an alarm, and can communicate with a PC via USART.
The clock is built on two PCB boards connected by two 10 pin IDC cables. I use stand-offs to screw the two boards together, doing that makes the clock free standing and eliminates the need to build a separate case or stand. I would have done it on one giant board but that was not feasible due to size limitations in Eagle freeware. The boards were manufactured through OSHPark.
I use four IN-17 Nixe tubes for the display. Although they are small, IN-17 tubes are cheap and easy to source through Ebay. Also I had several left over from my ArduiNIX experiment.
The tubes are multiplexed through 2 SN74141 BCD to decimal drivers. I built a version with one driver per tube but that seemed wasteful which is why I decided to multiplex them. I also tried a version where I drove the tubes with individual transistors but the switching was slow resulting in much ghosting.
The SN74141 drivers interface to the microcontroller through TLP-627 optoisolators. I chose an optoisolator to isolate the microcontroller from the tube high voltage. In theory it is cheaper to replace a $1.30 optoisolator than a $8 micro. In my case the optoisolator did not isolate enough and I ended up ruining a MCU in a high voltage probing accident.
The microcontroller is an ATMega32. It is run at 8MHz with the JTAG fuse bit disabled. I originally selected the ATMega32 because it has enough pins to drive four SN74141 tubes and perform serial I/O. In hindsight, for the two drivers I ended up with, I could have gone to a lower pin-count MCU like the ATMega328 and saved some board space. The code only uses 10% of the available 32KB of flash. It is nice to not have to worry about IOs or having to optimize the code to eke out every iota of performance and it leaves room for expansion.
The power-supply is based on the one in the ArduiNIX that I write about here.
The time, date, alarm, and temperature come from the DS3231 RTC chip on my RTC breakout board documented here. I wired up a buzzer for the alarm but I didn’t read the datasheet correctly and wired one of its pins to the input voltage. This leads to a high DC voltage across the buzzer which the datasheet warns again. I’ve fixed this in the Eagle files so it will work when order another set of boards.
The user interface is through three push-buttons on the Nixie tube board. One button is used to switch between the modes and the other two are used to increment the left and right sides.
In addition, I brought out the TX and RX pins for serial communication. I used Dean Camera’s Interrupt Driven USART guide to get the interface up and running but I haven’t done much with it since. It would be interesting to show stock prices and other numerical data from the internet on the display. There are three LEDs available for debug, alarm, and to show seconds.
The code is based around an overflow interrupt on Timer0. The interrupt calls the RTC to get the current time. From that the input pushbuttons, the alarm, and LEDs are toggled once per second.
The display() function drives the digits and uses a state machine to multiplex between them. This avoids wasting cycles in a delay loop to implement a delay between switching displays to avoid ghosting.
UpdateLeftRight() updates the variables that hold the values to write to the tubes with the correct value based on the selected mode. update_time() updates the time, date, day, and alarm based on the mode and which increment button the user is pushing. The RTC data is read through the GetTimeDateAlarmDataFromRTC() function.
I didn’t wire the outputs of the SN74141 to the correct leads on the nixie tubes, Instead I wired them based on ease of routing. remap() remaps the input to the driver to the correct value that should be written to the driver.
In addition, I have ‘anti_flashy‘ code to toggle the digits once per second through all their values per minute. This is done to avoid cathode poisoning that will eventually dim the tubes and also as a way to count the first 9 seconds of each minute. It is a nice effect. And since I don’t have the buzzer wired up, I toggle the debug LED on pin D6 when the time hour and minutes match the alarm.
Things I Learned
Be careful with the high voltage output. I’ve shocked myself a few times by touching the board accidentally in a high voltage area.
Don’t probe around the board with wires hooked up to 170V. I had a case where one of my tubes were not working and I tried powering them directly using very sloppy techniques. Something shorted out and I ended up damaging the neighboring tube, shorting the optoisolator, and burning out the microcontroller!
Use IC sockets as much as possible. Using a socket meant I could quickly replace a burnt out ATMega without having to rebuild a whole board. Not using a socket for my tubes meant I had to re-do the entire display board when I fried one of the tubes.
Read the datasheets and then read them one more time. Not reading the buzzer datasheet and just going off information from the internet meant that I wasn’t able to use the buzzer in my project.
Check your header directions and orientations of the components. Print out a paper copy of your board, place your components on them, and check the pin orientation. I put the tubes on the back of the board in one iteration of the design which meant that I had to re-do the board.
Always have a current limiting resistor in place. Testing my tubes with high vcc and no limiting resistor resulted in them flickering and glowing when off.
There is some optimization possible on the board and in the software.
For the hardware, I’ve added a switch to the board to turn off the clock at the input supply for when I’m away and of course fixed the buzzer. There are enough I/O pins open to drive a LCD display to show additional information. This with the serial I/O can give us a nice PC connected display. The MCU is only running at 8MHz but can be clocked at up to 16MHz so there are plenty of spare cycles available.
The timings for reading the RTC and driving the display can be optimized further. Initially I used delays to wait between turning off a tube and turning on its neighbor – you can see this in the commented out code in the display() function. I later took out the delays but did not check to see if I can read the RTC or multiplex the tubes less often. This will save power and free up cycles for additional features and effects.
Additional effects are possible with the tubes. Things like flickering, scrolling, fading in, fading out e.t.c
For the original inspiration and for sharing their designs:
For inspiration and samples of code for driving the DS3231 RTC chip:
All code and files are released as ‘Do what you want with it. I am not responsible for anything that happens.’
CPU board schematic:
Tube board schematic:
I wrote this code to drive the Adafruit 32×64 RGB Matrix using a Beaglebone Black and Adafruit’s IO Python library. The code is super simple – it writes a static color background to the top and bottom halves of the display through the shift registers and triggers the latch. It then iterates through the addresses so the LEDs for that row turn on and then goes to the next address. This should create a background color through persistence of vision.
Along the way I discovered:
The Python Library isn’t fast enough to drive the RGB matrix to provide a persistent display. There is flicker and when updating colors, you see each row turn on and off. You literally see the delay. There are ways to speed up the writes by using the PRU or direct IO writes. But I should not have to do that on a 1GHz processor.
The RGB matrix doesn’t light up unless you continually change the address. This was really annoying when I was figuring things out. I did not find this documented anywhere on the web except on rayslogic’s RGB writeup.
It appears the BeagleBone Black’s IO pins cannot push enough current to turn on the input schmitt triggers. I spent a lot of time being frustrated because I couldn’t get the green and blue LEDs to light up on my board.
Finally I noticed the green LEDs were barely on and had a brightness gradient from low to high address. My guess is the address pin was barely turning on which meant 0 was the most common address – hence the higher brightness on the lower rows. I got around this by plugging the G(reen) input directly into the 5V pin on the BeagleBone Black. Of course this now meant the green LEDs are always on!
Adafruit charges too much for the RGB panels. For example, the seller kbellenterprises on ebay has a 16×32 RGB matrix for $16 including shipping. Adafruit has the same panel for $25 and you pay for shipping.
Adafruit charges too much for male-to-male jumper wires. The seller funny-diy on ebay sells 40 for $1.80 with shipping while Adafruit charges $4+shipping for their so-called “premium” wires. Adafruit needs to rename them to “premium-priced“.