Timebase & Logic

The three volumes before this one were about light: how a nixie strikes (Vol 2), how to manufacture the ~170 V that strikes it (Vol 3), and how to route that voltage to one chosen cathode out of ten (Vol 4). This volume is about time — the far quieter half of the clock, the part that decides which digit the drivers of Vol 4 should be lighting in the first place. It is, on the face of it, the easy half: a $2 chip keeps better time than a wristwatch, and the counting logic is the same seconds-into-minutes-into-hours a schoolchild can recite. But “good enough that the owner never has to touch it” is a higher bar than it sounds, the choice of where the one-second tick comes from quietly sets the whole clock’s character, and there is one celebrated way to build the counting half with no microcontroller at all: a board of relays that holds the time in binary and clicks it forward once a minute, which is this hub’s Relay Nixie Clock, summarised in §5.6 and covered in full by its own deep dive. It starts with what “keeping time” actually demands.

5.1 The timekeeping requirement

A clock has exactly one job that the user judges it on: at any moment, the digits must read the correct time. Everything in this volume exists to serve a single deceptively simple deliverable — a clean, accurate one-pulse-per-second tick — and then to count that tick into a 24-hour (or 12-hour) display. “Clean” and “accurate” are separate requirements that pull on different parts of the design. Clean means the tick arrives exactly once per second with no missed beats and no spurious doubles: a single glitch adds or drops a second that never gets corrected, so the edge that drives the counter has to be debounced, well-defined, and immune to supply noise. Accurate means the long-run rate of those ticks matches true time closely enough that the user does not notice drift between the occasions when they happen to reset it.

5.1.1 The accuracy budget, worked out

Timekeeping accuracy is quoted in parts per million (ppm) of frequency error, and the single most useful conversion to keep in your head is what one ppm costs you in accumulated time. One ppm is one second of error per million seconds, and there are 86,400 seconds in a day, so:

• 1 ppm ≈ 0.0864 s/day ≈ 2.63 s/month ≈ 31.5 s/year.

From that one anchor every other number falls out by multiplication. A garden-variety ±20 ppm watch crystal — the kind soldered next to a cheap RTC — therefore drifts:

• 20 ppm × 0.0864 s/day ≈ ±1.7 s/day ≈ ±53 s/month ≈ ±10.5 min/year.

Turn the budget around and it tells you what a target buys: if you decide the clock may never be more than ±0.5 s/day wrong between resets, you need a timebase good to about ±5.8 ppm (0.5 ÷ 0.0864), which is already better than an uncompensated crystal can hold across a warm-to-cold room and is exactly the gap a temperature-compensated part closes. And at the top of the hobby range, a ±2 ppm TCXO drifts only:

• 2 ppm × 0.0864 s/day ≈ ±0.17 s/day ≈ ±5.3 s/month ≈ ±63 s/year ≈ ±1 min/year.

That last figure is the one users actually feel. A clock that gains or loses a couple of seconds a month is one you reset twice a year for daylight saving and otherwise trust; a clock that drifts a couple of seconds a day is one you find yourself nudging every week and quietly resenting. The whole of §5.2 and §5.3 is the engineering of which side of that line you land on, and the headline is simple: the crystal you choose, and how its frequency moves with temperature, dominates everything else in the timebase.

5.2 RTC chips — outsourcing the tick

The path of least resistance, and the one almost every microcontroller nixie clock takes, is to not generate the second from the MCU’s own oscillator at all but to buy a purpose-built real-time clock (RTC) chip whose only job is to keep accurate time and hand it over on request. An RTC packages four things the MCU would otherwise have to manage: a 32.768 kHz oscillator and the divider chain that turns it into seconds, a set of BCD registers that already hold seconds/minutes/hours/date, a tiny battery input so those registers keep counting when the clock is unplugged, and an interface — almost always I²C — to read and set them. Hang one on two wires and the MCU’s timekeeping job collapses from “run an accurate oscillator and divide it” to “ask the chip what time it is, then light the digits.”

5.2.1 The DS3231 — the one to use

The Maxim/Analog DS3231 is the default choice for any nixie clock the builder wants to set and forget, and it earns it with one feature: the 32.768 kHz crystal is inside the package, and temperature-compensated. A bare crystal’s frequency wanders with temperature along a parabola — typically tens of ppm of pull between a cold and a warm room — and that drift, not the crystal’s nominal tolerance, is what wrecks a cheap clock’s accuracy. The DS3231 measures its own die temperature every 64 seconds and switches in trim capacitors to cancel the parabola, holding the output to ±2 ppm from 0 °C to +40 °C (±3.5 ppm over the full −40 to +85 °C industrial range). By the §5.1.1 arithmetic that is the ±1 minute per year part — good enough that the clock’s accuracy is limited by how precisely you set it, not by how it drifts afterward.

The DS3231 talks I²C (a 7-bit address of 0x68, two open-drain wires SDA and SCL with pull-ups), holds time and date in BCD registers, carries an aging-trim register for the last fraction of a ppm, and — the feature that matters most for this volume — provides a programmable square-wave / INT output (the SQW pin) that can be set to emit a clean 1 Hz (or 1.024 kHz, 4.096 kHz, 8.192 kHz). That 1 Hz output is the clean tick of §5.1 delivered on a silver platter: wire SQW to an MCU interrupt pin and the chip itself provides the heartbeat the firmware counts (§5.4.3), already disciplined by the temperature-compensated oscillator. Most hobby modules pair the chip with a CR2032 coin cell (or, on the notorious early modules, a LIR2032 the board tries to charge — worth disabling) so the registers survive a power cut.

5.2.2 The DS1307 — cheaper, crystal-dependent

The older DS1307 is the same idea at a quarter of the price and a fraction of the accuracy. It is also an I²C RTC at address 0x68 with BCD registers and a battery input, but it omits the oscillator and the temperature compensation — you solder an external 32.768 kHz crystal across its X1/X2 pins, and the clock is then only as good as that crystal and the room it sits in. With an ordinary ±20 ppm watch crystal, untrimmed and uncompensated, a DS1307 clock realistically holds the ±1.7 s/day of §5.1.1 at constant temperature and noticeably worse as the room swings — a minute or two a month is typical. Its square-wave output (the SQWE/OUT pin) likewise offers 1 Hz, 4.096 kHz, 8.192 kHz, or 32.768 kHz, so it drops into the same firmware unchanged. The DS1307 is fine for a clock that lives in a temperature-stable room and gets glanced at, but for a few cents more the DS3231 is so much better that it has become the reflexive choice; the DS1307 survives mostly in old designs and the cheapest kits.

5.2.3 Battery backup, the bus, and the 1 Hz output in practice

Three practical points tie the RTC into the rest of the clock. First, battery backup keeps time, not light — exactly as the OSC4.4’s 9 V backup in the scope hub kept the count alive but never the CRT, an RTC coin cell preserves the seconds/minutes/hours registers through a mains outage so the display is correct the instant power returns; it runs the oscillator and registers (microamps) but comes nowhere near the milliamps the nixie boost supply of Vol 3 demands. Second, the I²C bus is shared and cheap: SDA and SCL need one pair of pull-up resistors (typically 4.7 kΩ to the logic rail) for the whole bus, and the same two MCU pins can also talk to a temperature sensor or an EEPROM. Third, and most useful, the 1 Hz SQW output decouples timekeeping from display: the MCU does not have to poll the RTC over I²C every second and risk jitter, it simply takes the hardware 1 Hz edge as its interrupt and reads the full time over I²C only occasionally (at startup, after a set, or once a minute as a sanity check). That division of labour — RTC keeps the time, its 1 Hz drives the counter, I²C reconciles them now and then — is the backbone of the firmware in §5.4.

5.3 Crystal vs mains-derived timebase

Before RTC chips were a dollar, and still today when a builder wants the timebase to be part of the design rather than bought-in, there are two classic ways to manufacture the one-second tick: divide down a quartz crystal, or count cycles of the AC mains. They fail in opposite directions, and understanding that trade is the key to §5.3.

A 32.768 kHz watch crystal is chosen for one arithmetic reason: 32768 is 2¹⁵, so a plain 15-stage binary divider turns it into exactly 1 Hz. (The relay clock of §5.6 uses the same trick one octave up — a 4.194304 MHz crystal, which is 2²², divided by a 24-stage CMOS counter to land on 1 Hz.) A crystal timebase is excellent in the short term — its tick is rock-steady second to second — but its long-term accuracy is whatever the crystal’s tolerance and temperature coefficient allow, the ±20 ppm / ±1.7 s/day story of §5.1.1. Nothing ever corrects it; the error accumulates forever until you reset the clock by hand.

Counting mains zero-crossings inverts that. The North American grid runs at a nominal 60 Hz (Europe and most of the world at 50 Hz), and a clock can derive its tick by watching the AC waveform cross zero — 120 crossings per second at 60 Hz (60 at 50 Hz if you count one edge per cycle), divided down to 1 Hz. The grid’s instantaneous frequency is sloppy: it sags toward 59.95 Hz under heavy load and rises above 60.05 Hz when generation runs ahead, so a mains clock’s short-term rate visibly wanders. But here is the saving grace — utilities deliberately practise time-error correction, nudging the average frequency over the day so that the cumulative count of cycles tracks true time. Over a day the grid delivers very close to its nominal cycle count (5,184,000 cycles/day at 60 Hz), and the long-term error of a mains clock stays within a few seconds over weeks with no crystal, no trimming, and no temperature drift to fight. The worked contrast:

Table 1 — contrast

Property	32.768 kHz crystal (÷2¹⁵)	Mains zero-crossing (÷120 or ÷60)
Short-term stability	Excellent (steady tick)	Poor (±0.05 Hz frequency wander)
Long-term accuracy	±10–50 ppm, drifts forever	Tied to grid average — seconds/weeks
Temperature drift	The dominant error (±tens of ppm)	None — the grid does not care about your room
Parts cost	A crystal and two caps	A divider tap off the existing transformer
Survives a power cut	Yes (with battery)	No — loses count when mains drops
50/60 Hz portability	Same crystal everywhere	Must rewire the divide ratio per grid

The honest summary is that a mains-derived timebase is a wonderfully cheap way to get grid-accurate long-term timekeeping for free when the clock is always plugged in and never travels between a 50 Hz and a 60 Hz country — which is exactly why it was near-universal in the original 1960s nixie era, and why the relay clock of §5.6 has an external clock input that could take one. A crystal (and better, a temperature-compensated RTC) wins the moment you want battery-backed timekeeping or portability. Many modern clocks split the difference: crystal/RTC for the steady tick, with an optional network sync (§5.5) standing in for the discipline the grid used to provide.

5.4 MCU firmware structure

For the overwhelming majority of nixie clocks the timebase feeds a small microcontroller — an ATmega/AVR in this hub’s worked build (Vol 6), or any PIC/STM32/ESP equivalent — and the firmware that runs on it has a structure that barely changes from one design to the next. It is worth laying out explicitly, because every block of it touches a neighbouring volume: the tick comes from §5.2/§5.3, the digit output goes straight into the drivers of Vol 4, and the anti-poison routine implements the cathode-care discipline of Vol 2. The firmware is four cooperating pieces: a one-second interrupt, a counting state machine, a display-refresh loop, and a handful of user-input and housekeeping routines.

5.4.1 The counting state machine — seconds → minutes → hours in BCD

At the heart sits a trivial finite-state machine that does exactly what a mechanical clock’s gear train does, in software. Time is held in binary-coded decimal (BCD) — each decimal digit in its own nibble or byte — because the display is decimal: holding 47 minutes as the two digits 4 and 7 means the refresh loop can hand each digit straight to its driver with no binary-to-decimal division on every refresh. Each one-second tick runs the carry chain:

  seconds_units++            ; advance the units-seconds digit
  if (seconds_units == 10):  seconds_units = 0; seconds_tens++
  if (seconds_tens  == 6):   seconds_tens  = 0; minutes_units++   ; mod-6: 0..5
  if (minutes_units == 10):  minutes_units = 0; minutes_tens++
  if (minutes_tens  == 6):   minutes_tens  = 0; hours++
  if (hours == 24):          hours = 0          ; (or 12-hour wrap)

The only subtlety is that the tens of seconds and minutes are mod-6, not mod-10 — there is no “60-something” minute — which is why a from-scratch counter (and the relay clock of §5.6) needs a divide-by-6 stage where the units need divide-by-10. Hours wrap at 24 (or roll 12→1 with an AM/PM flag for a 12-hour display). The state machine is so light it finishes in microseconds and spends the other 0.999+ seconds idle or refreshing the display.

5.4.2 The display-refresh / multiplex loop

While the state machine updates the time once a second, the refresh loop runs continuously, and this is where the firmware shakes hands with Vol 4’s drivers. If the clock direct-drives every tube (one 74141/K155ID1 BCD decoder per tube, fed from shift registers — the static scheme of the hub’s ATmega build), the loop’s job is light: when a digit changes, clock the new BCD values out to the 74HC595 shift-register chain and latch them, and the drivers hold that digit lit until the next change. If instead the clock multiplexes — lighting one tube (or one digit-position across tubes) at a time and relying on persistence of vision — the refresh loop is the busiest code in the build: it must cycle through the tubes fast enough (well above the ~50–100 Hz flicker-fusion threshold, so each of N tubes is revisited every few milliseconds) that the eye sees a steady display, holding each tube’s anode on only for its slot while presenting that tube’s cathode pattern. Multiplexing trades a steady glow for fewer driver channels, at the cost of brightness (each tube is lit only 1/N of the time) and firmware that must never stall — a long-running routine that blocks the refresh for tens of milliseconds shows up as a visible flicker. The mechanics of decode, latch, blanking, and per-digit dimming are Vol 4’s subject; the firmware’s responsibility is simply to feed that hardware on time, every time.

5.4.3 The one-second interrupt

The clean tick of §5.1 enters the firmware as an interrupt. Whether it is the DS3231’s 1 Hz SQW edge (§5.2), a mains zero-cross squared up into a logic level (§5.3), or the MCU’s own timer dividing an internal crystal, the rising edge fires an interrupt-service routine (ISR) whose whole body is “set a tick flag” (or, in the simplest designs, run the §5.4.1 carry chain directly). Keeping the ISR to a single flag-set and doing the counting in the main loop is the disciplined pattern — it keeps the interrupt short so it never collides with the time-critical refresh loop. Driving the counter from a hardware edge rather than a software delay loop is what makes the clock keep time while it does everything else: the display can be mid-refresh, a button can be held down, and the second still lands exactly on the edge because the hardware, not the code’s timing, defines it.

5.4.4 Button-based time setting

Because there is no keyboard, setting the time falls to one to three buttons and a small sub-state-machine layered over §5.4.1. The canonical scheme is a Mode button that walks a cursor through fields (hours → minutes → done, often with seconds-zeroing on exit) and an Up (and sometimes Down) button that increments the selected field, with auto-repeat if held. Two refinements separate a pleasant clock from an annoying one: debouncing every button (a 10–50 ms settle, in software or with an RC, so one press is not read as five), and zeroing the seconds when the user finishes setting minutes so the clock starts the new minute cleanly rather than mid-count. The relay clock of §5.6 implements the fast-set half of this in hardware — a SET/RUN switch and a SLOW/FAST switch that gate a fast pulse train into the counters — though it has no way to zero its seconds.

5.4.5 Where the anti-poison cathode-cycle runs

One housekeeping routine is specific to nixies and lives nowhere else in clock firmware: cathode-poisoning prevention. As Vol 2 explains, a nixie cathode that is rarely lit slowly accumulates sputtered material from its neighbours and grows hard to strike and blotchy; the cure is to make sure every cathode lights regularly. The firmware implements this as a periodic slot-machine / cathode-cycle routine that, on a schedule — commonly once an hour, or each day at a quiet time like 03:00 — rapidly runs every tube through all ten digits 0–9 (often several times, sometimes as a deliberate “spin” animation) so the seldom-used cathodes get exercised. Architecturally it is just another consumer of the refresh loop: the time keeps counting underneath (the §5.4.1 state machine is untouched), the cycle routine temporarily overrides what the refresh loop displays for a second or two, then hands the display back to the real time. Because it must not lose a tick, it is written to run between seconds or to read the true time back from the RTC when it finishes. It is the one piece of timekeeping firmware whose reason for existing is the display technology, not the clock.

5.5 Network and satellite sync — set-and-forget accuracy

The accuracy budget of §5.1 assumes the clock is a closed system whose only correction is a human pressing buttons. Add a network or satellite reference and the budget changes entirely: the clock disciplines itself to an external time standard and the crystal’s drift stops mattering, because any accumulated error is wiped out at the next sync. Two paths dominate.

NTP over Wi-Fi. An ESP8266 or ESP32 module (the cheapest path, since it is itself a capable microcontroller and can be the clock’s brain) joins the local Wi-Fi and queries an NTP time server, retrieving UTC to within tens of milliseconds — vastly tighter than any nixie display can show. The firmware then applies the timezone and daylight-saving rules and sets the count. Re-syncing even once a day reduces the displayed accuracy to “always correct”; between syncs the local crystal/RTC carries the time, so a power blink that outlasts the coin cell is recovered automatically at the next NTP poll. This is the modern set-and-forget nixie clock: it never needs setting, it handles daylight saving by itself, and it survives outages without a battery because the network re-disciplines it on boot.

GPS / GNSS. A small GPS receiver module gives the same discipline without any network at all, which suits a clock that must be authoritative or lives where there is no Wi-Fi. The receiver emits the time of day in its NMEA sentences ($GPRMC/$GPZDA) and, crucially, a 1 PPS (one-pulse-per-second) hardware output whose rising edge is aligned to UTC to well under a microsecond. The firmware reads the date/time from the NMEA stream to set the clock and can then take the 1 PPS edge as its one-second interrupt (§5.4.3) directly — the tick itself becomes atomic-clock-traceable, not merely a crystal divided down. The cost is needing sky view for the antenna and a minute or two to acquire a fix at power-on, after which the local oscillator holds time through any brief signal loss.

Either way the architectural insight is the same: networked sync turns the timebase from a generator you must trust into a flywheel you periodically re-discipline, which is why a synced clock can get away with a cheaper local oscillator than a standalone one. The hub’s scope-clock OSC4.4 offered exactly these as plug-in Wi-Fi and GPS modules; a nixie clock adds them the same way.

5.6 The relay-logic alternative — counting time with relays

Everything above assumes a counter made of transistors. The most unusual project in this hub does its counting with electromechanical relays instead: the RL1200 Relay Nixie Clock, designed by Jon Stanley and sold as a board by Catahoula Technologies, a 4-digit, 12-hour nixie clock built around 54 Omron G2R-2 relays (the original layout had 55; a later revision dropped one from the minutes decoder). I am building one, and it has its own four-volume deep dive in this technology’s machines — Relay Nixie Clock, which carries the full theory of operation, a review of its high-voltage supply, the build, and running notes. This section is the short version, so it can sit alongside the chip-based timebases above.

It is easy to imagine a relay clock as rings of relays stepping round once a second. The RL1200 is nothing like that, and the difference is the most interesting thing about it.

5.6.1 Silicon makes the minute

The relays never keep time. A 4.194304 MHz crystal (exactly 2²² Hz) drives a CD4521 divider to a clean 1 Hz, and two CD4017 decade counters count the seconds 0–59 on sixteen LEDs, silently. For the first ten seconds of each minute the second counter’s 0 output turns on a MOSFET that pulls a line called /CLK low, and that one ten-second pulse per minute is the only thing the relays ever see. A SET switch replaces it with a 1 Hz or 8 Hz square wave for setting the time.

5.6.2 Binary registers, sampled by capacitors

The time is held as three binary numbers: the hour (4 bits, codes 0–11 displayed as 1–12), the tens of minutes (3 bits) and the minutes (4 bits). Each bit is a storage relay that holds itself in through a 330 Ω resistor from its own output contact — energised, its output is +12 V and keeps the coil fed; released, its output is ground and keeps it off.

Writing a new value uses a 470 µF capacitor per bit. Between clock pulses a sampling relay connects the capacitor, through 10 Ω, to the bit’s next value, so it charges to 0 V or 12 V. When /CLK goes low, the sampling relay swings the capacitor onto the storage relay’s coil: a charged capacitor pulls the relay in, an empty one drags it out. Because the capacitor is disconnected from the next-value line for the whole pulse, the new value computed after the bit changes cannot leak back into it. The capacitor is the master and the relay the slave of an edge-triggered flip-flop.

5.6.3 Adding one with a relay coil

Each digit has an incrementer computing “value + 1” continuously, with one double-pole relay per bit. A relay coil is energised whichever way current flows, so a coil wired between the carry into a bit and that bit’s output is energised exactly when they differ — an exclusive-OR gate. One pole gives the sum, the other passes the carry on: one relay, one half adder. This works because the design uses CMOS-style levels, a 1 being +12 V and a 0 being ground, with every line driven both ways.

The minutes add one every pulse. The tens of minutes and the hours add one only when the digit below is rolling over: their carry-in is the lower digit’s clear signal. Spare relay poles detect minutes = 9, tens = 5 and hour code = 11, and a pair of clear relays per digit grounds its next value instead of passing the sum. All three registers sample on the same pulse, so every digit changes together — a fully synchronous counter, chosen deliberately because relays are slow enough to turn the timing hazards of a ripple counter into real failures.

5.6.4 Decoding onto the tubes

Relay decoder trees turn each binary number into one grounded cathode: ground enters at the relay for the top bit and branches through one relay per bit to exactly one of the tube’s cathodes. The 1-minute decoder needs six relays, the 10-minute four, and the hour ten, including one that drives the 10-hour tube’s “1” for hours 10–12. The tubes are static, not multiplexed.

5.6.5 What it is like to live with

The seconds are silent; the relays work once a minute, a short burst at :00 and a softer click at :10 when the sampling relays let go, with bigger bursts on the hour and at 12:59. Accuracy is entirely the crystal’s: the relays count whatever pulse they are given. The cost is power — the relays and LEDs average about 0.7 A at 12 V and peak around 1.6 A, against milliwatts for a microcontroller clock — and wear: the sampling relays operate over half a million times a year.

The on-board nixie supply is an MC34063 boost set by its divider to about 156 V as designed, below the 170 V minimum supply of the CD72 tubes the designer used. The Relay Nixie Clock dive reviews it and recommends values for a reliable strike.

The reason to build one is the reason this hub exists: it makes the invisible visible. A chip clock hides its counting; this one spreads a synchronous binary counter, adders and decoders across a board where every bit has an LED and every state is a contact you could probe.

5.7 References (Vol 5)

• Relay Nixie Clock — RL1200 “4-digit 12-hour nixie clock” designer documentation (datasheet/BOM/port list) and schematic. Source of the 55× Omron G2R-2-12VDC DPDT relay count; the “storage relay” inrush (10 Ω) and holding (330 Ω) resistor distinction; the CD4521 + 4.194304 MHz crystal timebase and twin CD4017 seconds counters; the MC34063AP nixie boost supply; the 12 VDC “POWER IN” rail; the active-low 1 Hz “EXT IN” reference; and the register/decoder block structure with 1-MIN (0–9), 10-MIN (0–5), 1-HOUR (0–9), 10-HOUR (0–1) outputs. Held in 02-inputs/Relay Nixie Clock/ (RL1200_ds.pdf, RL1200_sch.pdf, Relay Logic Projects.pdf).
• Relay Nixie Clock project page — Electronix & More, relay-logic projects, electronixandmore.com/projects/relaylogic/. Held as Relay Nixie Clock.url.
• Omron G2R-2 general-purpose DPDT relay datasheet — coil and contact ratings (12 VDC coil; 2 Form C contacts; general-purpose contact rating ~5 A). Vendor listing held as Relays.url (tme.com, Omron G2R-2-12VDC).
• Maxim/Analog Devices DS3231 Extremely Accurate I²C-Integrated RTC/TCXO/Crystal datasheet (±2 ppm 0–40 °C; on-die temperature compensation; programmable 1 Hz/1.024 k/4.096 k/8.192 kHz SQW; battery backup; I²C address 0x68).
• Maxim/Analog Devices DS1307 64×8 Serial I²C RTC datasheet (external 32.768 kHz crystal; programmable 1 Hz/4.096 k/8.192 k/32.768 kHz SQWE output; battery backup).
• ATMega Based Cool Nixie Clock — ATmega firmware/manual, 74HC595 shift-register and 74141 driver documentation (the multiplex/refresh-loop and direct-drive context of §5.4). Held in 02-inputs/ATMega Based Cool Nixie Clock/.
• NTP (RFC 5905) and NMEA 0183 / 1 PPS GPS timing references (§5.5 network/satellite sync background); ESP8266/ESP32 Wi-Fi-MCU platform.
• _shared/safety.md (hub-wide HV safety baseline) and _shared/deep_dive_protocol.md.