This page contains a description of a clock made with Nixie tubes which I designed and built. Questioning my sanity is not encouraged.
This is a picture of the clock with ZM1177 tubes mounted, click on the picture for a larger image.
The hardware of the Nixman is based around a PIC16F876 microcontroller. PICs aren't necessarily the quickest micros going, but I know them well enough to make them easy to use.
I used the SPI bus to communicate with most of the peripherals on the board, with a few direct connections to switches, LEDs etc... The clock, as shown in the following schematic, can be divided into a few design blocks:
Click on the pictures for PDF representations of the schematics.
The clock is powered from any 12V to 18V DC power source, in my case usually a wall wart power supply. The input voltage is fused and fed to two linear regulators to produce 9V for the high-voltage driver chips and 5V for the microcontroller and other digital bits. In order to generate the 200 V or so required to run the Nixie tubes, I built a step-up DC/DC converter based on a MAX771 controller chip. The input to the controller is the 12 to 18V input to the clock. Basically, the MAX771 controls an IRF740AS MOSFET which switches current through a fairly large inductor to generate the required high voltage. The resulting voltage is smoothed by the large storage capacitor (C13) before being used to power the tubes. With all tubes lit the clock draws around 300 mA at 13V. The output of the DC/DC, shown as HV_SUPPLY on the schematic, is well regulated and fairly stable. The shutdown input of the MAX771 is controlled by the PIC so that the clock can shut off the high-voltage supply when not required.
The timekeeping in the clock is handled by a Dallas Semiconductor DS1305, connected over the SPI bus to the PIC. The 1306 has its own 32.768kHz watch crystal and seems to keep fairly good time, though I have had trouble with traffic on the SPI bus causing the clock to run a bit fast. The 1305 is also connected directly to the PIC with its interrupt line. I did this so that the clock can inform the PIC about alarms or special conditions without being polled constantly. The 1305 is powered by the 5V supply but I've also connected a battery backup in the form of a little rechargeable lithium coin cell which could run the RTC with clock power off for a few months even by my most conservative estimates.
Each of the six tubes on the board has a single anode resistor used to limit current from the high voltage source. The 60 cathodes (10 per tube) are driven by a pair of Supertex HV5530s. These great little driver chips, though expensive, allow easy control of 32 high-voltage outputs each. I know there are cheaper ways to do this, but the single chip solution is just so elegant... Although intended to run with 12V logic, I haven't had any problems communicating with the HV5530s with the 5V levels of the SPI bus. I did drop the supply voltage of the chips down to 9V instead of 12, though. This puts them outside of spec but I've found they work very reliably all the way down to 5V, so 9V made for a nice simple interface. The leftover 4 outputs of the driver chips are used to run a load resistor (to keep some load on the DC/DC when many of the tubes are off) and 3 decimal point cathodes if available.
I designed the PCB for the clock to accept two different tube types directly and many others indirectly. The flexibility of the high-voltage drivers means that changing tubes is just a matter of loading different software and changing the anode resistors if necessary. There are three possible mounting points for each of the six tubes:
The micro in question is a PIC16F876, clocked with a 20MHz crystal. It may be overkill for this application, but that's half the fun and means there's lots of room left for expansion. To that end, I've built in a 12-pin expansion port (J2) giving access to power, the SPI bus, the serial lines, a dipswitch, a couple of analog inputs etc... The micro can be programmed and debugged using the ICD port which I've wired up to J4 to allow easy connection of a Microchip or similar ICD. The user interface consists largely of three pushbuttons used to set the time and other settings. Obviously, the main feedback is the nixie tube display, but I've also got a little surface mount LED for debugging and flashing for no reason. There are also a couple of dipswitches available although I'm not using them for anything at the moment.
The Nixman is equipped with a serial interface suitable for connecting a PC or a GPS unit. At the moment, I use the serial interface mostly for loading firmware, but I hope to implement NMEA listening so that the clock can set itself from GPS unit. The interface consists of a hardware UART on the PIC connected to a level shifting interface chip similar to the MAX232 (in this case the HIN232), which is in turn connected to the DB9 connector on the board. No hardware handshaking is implemented.
Having the SPI bus available to easily connect peripherals, I've added in a couple of other chips which don't have much of a practical use but may eventually come in handy. First, the Dallas Semiconductor DS1722 SPI thermometer is used to read the ambient temperature and display it on the clock. Second, a 25LC640 serial EEPROM is connected in case extra storage becomes necessary (at the moment all the clock settings are stored in the PIC's internal EEPROM.)
The PCB which I designed for this project measures 226mm by 70mm. It has 8 mounting points to support the weight of the board and the tubes without bending. These mounting points divide the board into three sections, one of which contains only short components, allowing a daughterboard to be mounted to the expansion connector described above. All the components with the exception of the power drivers and the tubes themselves are mounted on the same face of the board. The power drivers and the tubes are mounted on the side which becomes the top when the clock is mounted. I designed the PCB and had it manufactured by Olimex in Bulgaria, who did a great job.
Here's the PCB from the component side and tube side. (Click on the pictures for larger images.) The ZM1177 tubes are mounted on this board, but you can see the mounting holes for the IN18 tubes as well.
I wrote the software for the clock in PIC assembler. Sure, I could have used C, but I like using assembler and the whole point of this project was to enjoy doing it. The software has the following functional blocks:
The UI for the clock consists of three buttons, and the software handles them with a small state machine. Buttons are debounced, checked for rising and falling edges, and fed to the state machine. In the idle state (where the clock spends most of its time) the time is displayed, with the date and the temperature displayed once a minute for a second. When the user presses the set button, the clock moves into the first setting state, hour setting. The hours digits blink to show the user what they're doing, and they can then use the up and down buttons to set the hour. Pressing the set button again moves the flashing digits to the minutes, where up and down will then set the minutes. This continues through seconds, days, months, years and a series of user settings. These include 12 or 24 hour mode, an offset to calibrate the temperature setting, and an offset from GMT in hours for use when a GPS is connected. (I haven't implemented the GPS reception yet, but I plan to accept NMEA standard protocol.) Once all the settings have been completed, the clock returns to idle and shows the time normally. If no button is pushed for 10 seconds in any state, the clock times out and returns to idle. User settings such as the 12/24 hour mode are stored in internal EEPROM so that they're not lost when power is removed.
The display is controlled by writing bit patterns to the two HV5530 high-voltage drivers over the SPI port. The drivers are cascaded so that they are in effect seen as a 64 bit shift register. The display interface keeps track of the patterns sent so that only when the pattern changes will it be actually transmitted (this keeps SPI traffic to a minimum to reduce noise.) The bit pattern is calculated using a lookup table which contains the connections between the driver outputs and the nixie tube cathodes. (This way I can change the pinout of the nixies or use different tubes just be changing this include file.) Other devices on the SPI bus include the RTC and the temperature sensor, and these each have their own driver routines which allow initialization, reading and writing to the devices.
The hardware UART on the microcontroller is used to handle serial I/O. This is all interrupt driven, I've got a ring buffer each for output and input characters which can be written and read by higher level routines. The interrupt routines handle the buffers and notify the high level code when characters have been received.
I wrote a little bootloader which allows the clock to be reprogrammed over the serial port since I don't want to have to hook up a programmer every time I make a software change. This also allows me to send a software update to someone with a clock but no programmer. The bootloader loads on startup, checks the status of the set button, and activates itself if the button has been held down. If not, it branches into the normal program. I wanted the bootloader to be usable without any special software, so I have it generate the XON/XOFF software flow control signals to signal the host when it can receive data and when the host should wait. While the host is waiting, the received program codes are checked and written into flash. All the user needs to do is hook up the PC to the serial port and dump the hex file out to the clock using software handshaking. The bootloader responds with some feedback characters that indicate whether programming has been completed successfully.
I'm still working on the case for the clock, but I plan to do something pretty simple, just a polished aluminum or nickel-plated steel block with the tubes emerging from the top surface. The advantage of having a mechanical engineer for a girlfriend is that she can produce a cool 3D model of just such a thing in CATIA.
Here are a couple of pictures of what I have in mind for the clock with ZM1177 tubes mounted (obviously I wouldn't drill the big holes when these tubes are mounted.)
Here instead are a few pictures of the clock with IN18 tubes. Visible in the pictures are the tubes, the serial connector, the user interface buttons, and the power connector.
I've got a lot of ideas for expansion of the clock and too little time... In particular I'd like to finish the GPS input handling and then possibly implement a 433MHz receiver so that I can have a single reference point set all my clocks in the house. If the NeoNixie-L list has settled on a protocol I'll use that, if not I'll just do something simple. I'd also like to use a little Ethernet interface I've got to make a clock I can plug into the network at work to send and receive UDP packets requesting the time from PCs on the network. Let me know if you have any other cool ideas (the NeoNixie list on Yahoo Groups has been great for this.)
I've had some trouble with accuracy with this clock, and after fiddling around quite a lot I seem to have identified the source. The DS1305 RTC oscillator circuit seems to be very sensitive to noise, which causes it to run fast. When I first got the clock running it was gaining around 5 minutes a day. I then made the following discoveries:
I'd appreciate any ideas people may have as to why the DS1305 seems so sensitive to traffic on the SPI bus - I need to use the bus to communicate with the chip, but the act of doing so seems to make it run fast! I'm running the SPI bus quite slowly at the moment. Thanks for any ideas.
If you've got any questions or feedback about this clock, feel free to email me. As I've learned from experience not to put my whole email address on a webpage lest I be spammed out of existence, I'll just say that my email is eshort at name_of_big_Italian_sports_car_company_beginning_with_F_for_which_I_work .it