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 this entire subsystem with no microcontroller and no silicon counter at all — a rack of relays that physically clicks its way around the clock face, which is this hub’s Relay Nixie Clock and the reason §5.6 is the longest section in the volume. We start 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.

FIGURE SLOT 5.1 — Accuracy-budget chart plotting accumulated time error (s/day, s/month, s/year) against timebase error in ppm on a log scale, with three labelled points: an uncompensated ±20 ppm crystal (~1.7 s/day), a ±0.5 s/day target line (~5.8 ppm), and a DS3231 ±2 ppm TCXO (~1 min/year). Diagram: project original.

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.

FIGURE SLOT 5.2 — DS3231 RTC wiring and signal flow: the chip on the I²C bus (SDA/SCL with pull-ups to the MCU), the CR2032 backup cell on VBAT, and the SQW pin programmed to 1 Hz running to an MCU interrupt input; inset noting the on-die temperature sensor and trim-capacitor compensation that holds ±2 ppm. Diagram: project original.

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:

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 offers it as an option. 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.

FIGURE SLOT 5.3 — Two timebase chains side by side: a 32.768 kHz crystal feeding a 15-stage binary divider to 1 Hz (annotated “steady but drifts”), versus a mains transformer winding through a zero-cross detector and ÷120 divider to 1 Hz (annotated “wanders short-term, grid-locked long-term”). Diagram: project original.

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 this same idea in hardware — a SET/RUN switch and a SLOW/FAST switch that gate a fast pulse train into the counters — proving the function is fundamental, not a software nicety.

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.

FIGURE SLOT 5.4 — Firmware architecture diagram: the 1 Hz interrupt setting a tick flag; the main loop running the BCD carry-chain state machine (seconds→minutes→hours with the mod-6 tens stages); the continuous refresh/multiplex loop feeding Vol 4’s 74141/74HC595 drivers; and the button-set and hourly anti-poison cathode-cycle routines branching off the main loop. Diagram: project original.

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 no chip at all

Everything above assumes a counter made of transistors — an MCU, or at least a CMOS divider. The most celebrated project collected in this hub throws that assumption out: the Relay Nixie Clock (Path 5 of Vol 1) keeps and counts time using electromechanical relays, so the clock physically clicks its way from one second to the next, and you can watch (and hear) the carry propagate up the digits. It is slower, larger, hungrier, and far less accurate than a one-dollar RTC — and it is exactly the point. This is the volume’s set-piece, and the hub holds the board files for a real example: the RL1200, a 4-digit, 12-hour nixie clock built almost entirely from relays (the relay reappears as a finished build in Vol 8).

5.6.1 How a relay remembers — the self-holding latch

The whole technique rests on one trick a single relay can do: latch itself. A relay is a coil that, when energised, pulls an armature that closes (and opens) a set of contacts. Wire one of its own normally-open contacts in series with its own coil, and once the relay is pulsed on, that contact feeds the coil’s own supply back to itself — the relay holds itself energised after the triggering pulse is gone. It has become a one-bit memory: set by a pulse, holding until its supply is interrupted. The RL1200’s bill of materials shows this literally, distinguishing a “storage relay inrush-limiting resistor” (10 Ω, to limit the surge as the coil first pulls in) from a “storage relay holding resistor” (330 Ω, in the self-hold path to keep the coil energised at a gentler current once latched). A relay that can remember one bit is all you need; chain them and you can count.

5.6.2 From a latch to a ring/decade counter

To count, you arrange a row of self-holding relays as a ring counter (a “one-hot” decade counter): exactly one relay in the ring is latched at a time, representing the current digit 0–9, and each incoming second-pulse advances the “lit” relay one position — unlatching the current one and latching the next, the way a stepping switch or a Geiger-counter dekatron walks a glow around a ring. When the lit position falls off the tenth relay, the ring wraps back to zero and emits a single carry pulse into the next stage up. That carry is the gear mesh of a mechanical clock rendered in copper and iron:

  1 Hz tick ─► [ UNITS-SECONDS ring, mod-10 ] ─carry every 10 s─►
               [ TENS-SECONDS  ring, mod-6  ] ─carry every 60 s─►   ( = 1 pulse/minute )
               [ UNITS-MINUTES ring, mod-10 ] ─carry every 10 m─►
               [ TENS-MINUTES  ring, mod-6  ] ─carry every 60 m─►   ( = 1 pulse/hour )
               [ HOURS counter, mod-12 or 24 ]

Each ring is the relay incarnation of the §5.4.1 carry chain: units stages are mod-10, the seconds- and minutes-tens stages are mod-6 (a ring of only six relays, wrapping at “5→0”), and the hours stage wraps at 12 or 24. The relay outputs then drive a relay decoder that pulls the matching nixie cathode to ground — so the same latched relay that holds the digit also displays it, standing off the full anode voltage on the nine cathodes it is not selecting exactly as a 74141 would. The RL1200’s silkscreen names these blocks outright — 1-MIN / 10-MIN / 12-HOUR registers (the ring counters) feeding 1-MIN / 10-MIN / 12-HOUR decoders (the cathode drivers) — and its output ports confirm the moduli: 1 MIN outputs 0–9, 10 MIN outputs 0–5, 1 HOUR 0–9, 10 HOUR 0–1.

5.6.3 The relay that does it — the Omron G2R-2

The RL1200 is built from 55 identical relays, every one an Omron G2R-2-12VDC: a DPDT (2 Form C, two changeover) PCB relay with a 12 VDC coil. The “2” is what makes it suited to this job — two independent change-over contact sets per relay let one relay both self-hold (one contact in its own coil path) and switch a downstream signal (the other contact carrying the carry or the cathode drive). The G2R family’s contacts are rated for ordinary control loads (on the order of 5 A at 250 VAC / 30 VDC for the general-purpose G2R-2), which is wildly more than a nixie’s milliamp cathode current needs — the relay is chosen for its two-pole logic, not its switching muscle. A 12 V coil means the whole clock runs from a single +12 VDC input (the board’s “POWER IN” port), the same rail the on-board nixie supply boosts to ~170 V. Fifty-five relays is the price of doing decimal counting one hot wire at a time: roughly a dozen relays per displayed digit once you account for the register ring and its decoder.

5.6.4 The timebase for a clockwork-of-relays

A ring of relays still needs something to tell it when a second has passed, and here the RL1200 is pragmatic — it does not make the 1 Hz with relays (a relay oscillator would be noisy, drifty, and would wear its contacts out in months). Instead it offers two timebase sources, matching §5.3’s two philosophies. The default is a small silicon timebase island: a 4.194304 MHz crystal (Y1) feeding a CD4521 24-stage frequency divider (U1) — 4,194,304 Hz is exactly 2²², so dividing by 2²² yields a clean 1 Hz — with a pair of CD4017 decade counters (U2, U3) handling the fast seconds count and emitting one pulse per minute into the relay registers. The alternative is the board’s “EXT IN” port, an active-low external 1 Hz reference that lets you drive the clock from a mains-derived 50/60 Hz divider instead — buying the grid-locked long-term accuracy of §5.3 and dispensing with the crystal. Either way the relays do the displaying-and-carrying; a tiny bit of silicon (or the grid) provides the metronome. Purists who want zero semiconductors can replace even that island with a synchronous-motor or mains-divider tick, but the shipped design draws the line sensibly at “let a 30-cent CMOS counter make the second; let the relays count it.”

5.6.5 Click, bounce, accuracy, and why anyone builds one

A relay clock’s defining quality is sound. Every advancing second throws at least one armature, every ten seconds a carry throws another, every minute a cascade ripples up the stages — so the clock ticks audibly, with a soft mechanical chorus that swells on the minute as the carry climbs from seconds to minutes to hours. It is the closest a solid-state-era display gets to the heartbeat of a pendulum, and it is most of the charm.

The engineering cost is real and worth stating. Contact bounce — the few milliseconds an armature’s contacts chatter as they close — means every relay edge is electrically messy, so a relay-logic design must be tolerant of bounce by construction (the self-hold latch helps: once latched, brief re-closures don’t change the held state). Speed is glacial by silicon standards: a relay takes on the order of 5–15 ms to pull in or drop out, which is why the seconds are pre-divided in CMOS rather than rippled through relays at audio rates — a relay chain simply cannot settle 60 times a second cleanly. Power is far higher than an MCU clock: dozens of coils, each drawing tens of milliamps, mean the relay clock sips watts where a microcontroller clock sips milliwatts. And accuracy is entirely inherited from the timebase of §5.6.4 — the relays neither add nor subtract error, they just count whatever tick they are fed, so a crystal-fed relay clock keeps crystal-grade time and a mains-fed one keeps grid-grade time. Lifetime is the relays’: contacts that switch a clean, lightly-loaded logic signal millions of times can last years, but they are a wear item in a way no transistor is, and a relay clock is a thing you expect to service.

So why build one? For the same reason this hub exists at all: because it is a celebrated novelty that makes the invisible visible. A microcontroller clock hides its counting inside a chip; a relay clock spreads the entire carry chain across a board you can watch and hear work, marrying the cold-orange glow of the nixies to the warm mechanical click of the logic that drives them. It is the most honest clock in the collection — every state it holds is a physical contact you could probe — and it is, deservedly, the show-stopper of the build volume that follows (Vol 8).

FIGURE SLOT 5.5 — State/transition diagram of a single self-holding relay decade ring: ten relays in a ring, exactly one latched (“hot”), an incoming pulse unlatching position n and latching n+1, and the mod-10 wrap emitting a carry pulse; inset showing one G2R-2 relay with its own NO contact wired back into its coil path (the self-hold latch) plus the 10 Ω inrush and 330 Ω holding resistors. Diagram: project original.

FIGURE SLOT 5.6 — RL1200 block diagram: the +12 V input feeding both the MC34063 nixie boost supply (~170 V) and the relay logic; the 4.194304 MHz crystal → CD4521 ÷2²² → 1 Hz → CD4017 seconds island (or the EXT IN 1 Hz alternative); the cascade of mod-10/mod-6 relay registers carrying seconds→minutes→hours; and the relay decoders driving the four nixie tubes. Diagram: project original.

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.