So, I am going to try to build a clock, and document it here. Not because I am expecting a spectacular design that everyone will want to copy, but because it's a convenient reference for me, and it may provide someone else some ideas too.
Then I got the bright idea to have it display caller-id. This is going to necessitate something a little more complex at the back-end, so I have chosen the Atemel AVR line of microcontrollers (this will be my first microcontroller project of any kind). The AVR seems great for this project because there is little external circuitry needed, runs off 1.8-5V (depending on model), it has serial inputs to accept the output of a caller-id decoder (or can even be used directly to decode the FSK caller-id signal), comes in a wide variety of sizes, is very inexpensive (under $3 for many of the smaller models), can be programmed in-circuit with a minimum of fuss (just a cable to a pc's parallel port), has a free gcc-based c-compiler and free simulator, and has lots of enthusiastic users which means sample code and circuits abound.
One major design goal is to build as little as possible. I don't have the time or facilities to etch my own PCBs, and having PCBs made professionally is not practical for a small-board single prototype. Software can help with layout for stripboard or the like, which will reduce the chance of wiring errors, but soldering and layout are still time-consuming, so I want to minimize them. The microcontroller really helps here, since most changes -- even something silly like connecting BCD outputs in the wrong order -- can be made in software.
Also to that end, rather than buying bare tubes, I am acquiring old nixie-based equipment (mostly frequency counters) with the hope of using, at minimum, their power supplies and nixie drivers.
So, we have the following components:
Display: As it turns out, these meters all seem to be designed with separate display and logic boards, and some of them have quite usable display boards. I'll pull some of the extraneous circuitry, and feed BCD outputs to the 7441-type decoder/drivers, and I'm all set to go. The major downside of this is that there is no physical spacing between pairs of digits (to delineate hh:mm:ss). But I may be able to make use of decimal points instead of colons.
Processor: it might be simplest to just output BCD directly from the processor's i/o pins, in parallel. But this takes 4 bits per digit, so it doesn't scale well at all. A better way is to use the AVR's serial output to feed a set of cascaded shift registers -- I will use 74HC595's -- as a kind of serial-parallel convertor. This scales very well to any desired number of digits, since the software just needs to know how many bits to output.
There are many choices for the AVR's clock. An external clock source can be used, or a crystal oscillator, and some even have an internal RTC. Some can be used with a so-called "watch crystal". I plan on using this mode if possible. External capacitors are not needed, and it's fairly simple to use this to generate 1-second timing.
I have not yet decided on which model of AVR to use. There's a comparison table here. Choice will depend on the code size needed (I'll write some code using the simulator) and i/o requirements I end up with (I'll have to work out the exact features I want). I plan on using a socketed DIP, but programming will be in-circuit (which will require a header for a programming cable). I'll also provide headers for all unused inputs and outputs so that I'll have easy access to them in the future.
interconnections: The cpu board will have the following physical connections:
Power supply: I plan on using the power supply from one of my surplus meters. This provides both HV and LV power, a fuse, and power cord, saving a lot of work. I would like to have my processor module run completely off battery, though, rather than trying to design battery backup circuitry. I may provide a jumper-selectable way to have power fed from the display board though. Enclosure: I am envisioning something made of wood, with the tubes enclosed (never liked the ones that stick out the top). I don't like the ugly brown filters often used in front of nixies, but smoked glass may be nice. However, I may initially start out using one of my surplus meters as the enclosure. The only downside of that is there will be room for only 6-8 digits, and I ideally want 10 for caller-id.
I'm still deciding on the physical layout of the display. I have three HP boards, with 5, 5, and 4 digits respectively, but each can accept 6 digits (the boards have spots for the components). I could move the necessary components from one of the 5-digit boards, giving me a 6 and a 4, which I could line up side-by-side for 10 sequential digits. Conceivably, if I put the 6 above the 4, I could use the 6 for time, the 4 for date; in caller-id mode I could put areacode and exchange in the 6, and the last 4 digits in the 4. This might be kind of confusing though. Controls: I would like to use a rotary encoder knob for time setting, with a switch to select 'set/run' mode (there are encoders with pushbutton switches that could do this all in one package). There may be a pushbutton or two for function activation -- for example, push button to see the date for a few seconds, or push button to toggle between caller-id display and time/date display. Caller-id: I need to find a decent caller-id decoder IC. These typically would feed decoded date over a serial connection to the microcontroller.
Initially, there will just be an HH:MM:SS display, 12- or 24-hour mode. Setting the time will be done by switching to 'set' mode and using the rotary encoder knob, which will allow forward or backward setting. You will not set hours and minutes independently, but rather turning the knob will advance or reverse the time one minute at a time.
There will be a test mode which will rapidly count through all digits. Probably actually more than one test mode; turn on through a switch, and then use the function selector to switch between modes. Modes might be "all digits increment together", "count" in various ways, or random.
The next feature to be added will probably be the date. Setting the date is really incompatible with the time-set routine I specified above. So I may need to use a three-position switch -- set time, set date, run.
Next to add would be caller-id. Depending on the functionality of the caller-id decoder, I may be able to automatically set the time and date based on caller-id timestamps. If so, this will be jumper-selectable in case the phone company's clock is not so accurate.
I have a little speaker I pulled out of a toy which may be used to add sounds by direct manipulation of one of the AVR's outputs.