Timebases & Counting Logic

Every clock in this hub is the same four blocks — timebase, counting logic, driver, display — and Vol 1 introduced them. This volume takes the first two apart. The timebase is whatever in the machine produces a steady, repeatable frequency; the counting logic is the part that divides that frequency down to one pulse per second, one per minute, one per hour, and maps the running total onto where the mechanism should sit. Vols 2 and 3 covered the display end of that chain (how a hand angle or a segment row reads as a time); Vol 4 covered the driver end (the coils and steppers that move things). What connects them is the question this volume answers: where does the second come from, and how good is it?

The three collected builds answer that question very differently, and laid out on an accuracy axis they span almost the entire history of electromechanical timekeeping. The TuningFork clock is the strange one and gets the depth here, because it is the only build in the hub where the resonator and the clock are inseparable — the 440 Hz fork is not a reference the logic consults, it is the thing being counted. The PlanetaryGear and Aviation builds take the modern, boring, accurate route: a DS3231 temperature-compensated crystal does the timekeeping and the microcontroller is merely a bookkeeper that asks the RTC what time it is and moves a needle to match. Aviation adds a fourth tier on top — the network itself, via Wi-Fi NTP, the “infinite accuracy” reference everything else is measured against.

5.1 The general principle — frequency in, position out

A timebase is a frequency source. Counting logic is a divider plus an accumulator plus a map. The pattern is identical across the three builds even though the numbers differ wildly:

1. A physical thing oscillates at a frequency f — mains at 50 or 60 Hz, the fork at 440 Hz, the DS3231 crystal at 32 768 Hz, the network at “whatever UTC says.”
2. The logic divides f down to human units. To get 1 Hz you divide by f: 60 from 60 Hz mains, 440 from the fork, 32 768 from the crystal. To get one event per minute you divide by 60·f.
3. The logic accumulates — it keeps a running seconds, minutes, hours count and rolls each over at 60, 60, 24.
4. The logic maps that count onto the mechanism: a hand angle (Vol 2), a stepper target (Vol 4), or a lit set of seven-segment digits.

The accuracy of the whole clock is set almost entirely by step 1 — by how stable f is — because the divide-and-count of steps 2–4 is exact integer arithmetic that introduces no error of its own. A divider that counts to 26 400 will always count to 26 400; the only question is whether 26 400 cycles of the source actually took one minute. That is why this volume spends most of its length on the timebases and on calibration (§5.4) — telling the counter the truth about how fast its source really runs.

5.2 The timebase spectrum — five references on one accuracy axis

Ordered from most-mechanical to most-electronic, here are the references this category uses. None of the three collected clocks uses mains, but it is the historical floor of the spectrum and the idea every later timebase refines, so it leads.

5.2.1 AC mains (50/60 Hz) — the historical synchronous timebase

The oldest electric clocks have no oscillator of their own at all: a synchronous motor turns in lockstep with the mains frequency, and a gear train divides the motor’s rotation down to hands. The “timebase” is the power grid itself. To recover one second from a 60 Hz supply you divide by 60 (50 Hz → divide by 50); a synchronous-motor clock does this mechanically through gearing, an electronic mains clock does it by counting zero-crossings — count 60 crossings of a 60 Hz supply and one second has, on average, elapsed.

“On average” is the whole story of mains as a timebase. Its character is the exact opposite of a crystal:

• Short-term: poor. The instantaneous grid frequency wanders with load. A 60 Hz grid routinely sits at 59.95–60.05 Hz; ±0.05 Hz is ±0.05/60 = ±830 ppm of instantaneous rate error — enough that a mains clock visibly gains or loses a second or two over an afternoon as demand swings.
• Long-term: excellent. Grid operators historically held the cumulative cycle count to the nominal value (so many million cycles per day) through time-error correction, nudging frequency slightly the other way after a deficit. The integrated error was kept to a handful of seconds, so a mains clock left running for a month stayed within seconds of correct — better long-term than any uncompensated quartz watch of the era.¹

That short-term-bad / long-term-good signature is why mains clocks were the household standard for decades and why none of the maker builds here use them: a desk clock you watch wants steadiness over seconds, which mains does not give, and the collected builds all run from low-voltage DC supplies (Vol 1, §1.10) with no line-frequency reference to count.

5.2.2 The tuning fork (440 Hz) — a mechanical resonator as timebase

The TuningFork clock revives the escapement-and-oscillator idea (Vol 1, §1.2) in electronic form: a real steel tuning fork rings at its mechanical resonance and that vibration is the reference. It is the direct descendant of the 1960 Bulova Accutron, which sustained a 360 Hz fork electromagnetically and ratcheted a wheel from it; the collected clock uses a 440 Hz “concert A” fork and counts it electronically instead of ratcheting it. The sustaining amplifier that keeps the fork ringing — sense coil, common-emitter stage, ~440 Hz bandpass, drive coil — is Vol 4’s subject; here we care only that the fork delivers a clean 440 Hz mechanical oscillation that gets turned into countable logic pulses (§5.3.1).

A fork is a genuine resonator, but a low-frequency mechanical one, and that places it well below quartz on the accuracy axis for two physical reasons:

• Quality factor (Q). A fork’s Q — its ringdown sharpness, the energy stored per cycle divided by the energy lost — is in the thousands. A quartz crystal’s Q is in the tens of thousands to millions. Higher Q means the resonator more stubbornly holds its own frequency against pushes from the sustaining circuit, so a higher-Q reference is more stable. The fork’s Q is high enough to make a clock (the article reports a couple of seconds per day after tuning) but orders of magnitude short of quartz.
• Temperature coefficient. A steel fork’s resonant frequency depends on the elastic modulus and dimensions of the metal, both of which drift with temperature; its frequency temperature coefficient is substantially larger than quartz’s. (The Accutron’s achievement was partly a special low-tempco alloy; a plain fork has no such trick.) A warm room versus a cold one shifts the fork’s rate in a way the count cannot know about, which sets the floor on how well the calibration of §5.4 can hold.

The fork’s redeeming feature — and the reason it is the most interesting timebase in the hub — is that there is no separation between “the oscillator” and “the clock.” There is no crystal the firmware trusts; the firmware is counting the same physical motion that is the clock’s heartbeat. Lose the hum and you lose the time (§5.3.5).

5.2.3 Quartz in the DS3231 (32.768 kHz, temperature-compensated)

Both RTC builds delegate timekeeping to a DS3231 module. Inside is a quartz crystal cut to vibrate at 32 768 Hz — chosen because 32 768 = 2^15, so a 15-stage binary divider produces exactly 1 Hz with no fractional remainder. That is the whole appeal of quartz here: it is an electronic resonator, far higher Q and far lower tempco than any fork, mass-produced, and trivially divided to the second.

The DS3231 goes one step further than a bare crystal: it is a TCXO — temperature- compensated. A tuning-fork-cut quartz crystal has a parabolic frequency-vs-temperature curve (it loses a few tens of ppm at the temperature extremes), so the DS3231 contains a temperature sensor and a switched-capacitor array that trims the load capacitance to flatten that curve. The datasheet result is ±2 ppm from 0–40 °C. In clock terms:

• 2 ppm = 2×10⁻⁶ × 86 400 s/day = 0.17 s/day
• over a year, 2×10⁻⁶ × 31.5×10⁶ s ≈ 63 s/year ≈ ±1 minute per year

The module communicates over I²C, keeps time through power loss on a CR2032 backup cell, and is read by the Arduino (planetary) or ESP32 (aviation) as just another I²C device. For the maker builds this is “solved” timekeeping — better than a wristwatch, no calibration, no drift you will notice between battery changes.

FIGURE SLOT 5.4 — A DS3231 RTC breakout module (the ZS-042 / “DS3231 AT24C32” style board with its CR2032 coin cell), top-down, showing the I²C header. To be fetched license-clean via the Photo Helper in the figure pass; credit verbatim.

5.2.4 Network time (ESP32 NTP) — the “infinite accuracy” reference

The Aviation build’s ESP32 has Wi-Fi, so it can reach the top of the spectrum: NTP, the Network Time Protocol, which disciplines the clock to UTC served ultimately by atomic references. As a timebase NTP has no rate error to speak of long-term — it is steered to UTC, so it neither gains nor loses; its only error is the synchronization latency (tens of milliseconds of network round-trip and a poll interval of minutes to hours). Practically, an NTP-synced clock is correct to a fraction of a second, indefinitely, with zero drift between syncs that the user would ever see, because each sync re-pins it to UTC.

The important architectural point for this build: the ESP32 does not run on NTP moment to moment. It uses NTP to set the DS3231 (and its own internal time), then runs from that local timebase between syncs, re-syncing periodically. So NTP is the calibrator, the DS3231 is the flywheel, and Wi-Fi outages degrade gracefully to ±1 min/year DS3231 accuracy rather than stopping the clock.

5.3 Counting the fork in depth — the TuningFork clock

This is the build where the counting logic is the interesting part, so it gets the close read. The firmware is clock.c on an ATtiny4313 running at F_CPU = 1 MHz. The signal chain from steel to digits is short and is worth following end to end.

5.3.1 From fork to logic pulses — sense amp → 555 → timer clock

The sustaining amplifier (Vol 4) gives a roughly sinusoidal ~440 Hz signal off the sense coil — fine for an analogue ear, useless for a digital counter that wants clean edges. So the last analogue stage is an NE555 wired to square the sense signal into a rail-to-rail logic pulse train at the fork frequency. As the original build notes put it, the 555 “ensures that the analog signal from the sense coil amplifier is suitable for a digital input pin on a microcontroller.” The 555’s output is one clean rising edge per fork cycle: 440 edges per second, fed to the ATtiny’s Timer1 external-clock input.

This is the move that makes the fork a timebase rather than a curiosity: the firmware does not sample or measure the fork, it lets the fork clock the counter directly. In main(), Timer1 is configured TCCR1B = CS10 | CS11 | CS12 | WGM12 — clock-select 111 selects the external clock source on the T1 pin, rising edge, and WGM12 selects CTC (Clear Timer on Compare). So Timer1’s count register advances by exactly one for every fork cycle, and the microcontroller’s own 1 MHz system clock is used only for housekeeping, not timekeeping.

5.3.2 The divisor — 26 400 pulses per minute

The firmware declares its two divisors as plain constants:

unsigned int pulses_per_minute = 440 * 60;   // = 26400
unsigned int pulses_per_second = 440;

A perfect 440.000 Hz fork delivers 440 pulses/second and 440 × 60 = 26 400 pulses/minute. The designer’s note explains the choice of the minute as the master count: “the larger number of pulses would allow for finer adjustment of the speed the clock runs at.” Calibrating against 26 400 lets you trim rate in steps of 1 part in 26 400 (≈ 38 ppm) — far finer than trimming against the 440-count second (1 part in 440 ≈ 2272 ppm). That choice is exactly what makes the calibration of §5.4 useful.

5.3.3 Deriving seconds and minutes — Timer1 COMPA and COMPB

Two compare values ride on the one Timer1 count, producing the two overflow events the original notes describe (“one roughly every second, and one every minute”):

• OCR1A = pulses_per_minute (26 400). Because Timer1 is in CTC mode, reaching OCR1A clears the counter and fires TIMER1_COMPA_vect. That ISR is the minute tick: it zeroes seconds, increments minutes, rolls minutes at 60 into hours, and rolls hours at 24. This is the authoritative, exact timekeeping path — one fork-counted minute, every minute.
• OCR1B = pulses_per_second (440), and TIMER1_COMPB_vect is the second tick. Because the counter is cleared only at OCR1A, COMPB must reschedule itself: the ISR does OCR1B += pulses_per_second, walking the compare point up through 440, 880, 1320, … within the minute. It increments seconds (guarding seconds < 60) and pulses the once-per-second output and blink indicator. This second count is, in the designer’s words, “a rough approximation of the progress of the minute” — a smooth display feed, while COMPA holds the real time.

A second timer, Timer0, has nothing to do with timekeeping: TCCR0A = WGM01 (CTC), TCCR0B = CS00 | CS01 (clk/64), OCR0A = 12, so it interrupts at 1 MHz ÷ 64 ÷ (12+1) ≈ 1.2 kHz. Its ISR scans the five multiplexed seven-segment digits via the 74HC595, runs display blink animations, services input timeouts — and monitors the fork (§5.3.5). The main loop does only non-time-critical work — serial parsing and command execution — and otherwise sleep_mode()s to save power, waking on interrupts. The architecture cleanly separates the counted timebase (Timer1, fork-clocked) from the housekeeping clock (Timer0, MCU-clocked).

5.3.4 Modes and the serial protocol — summary level

The firmware is a small state machine over an enum of modes — MODE_TIME (‘D’, display), MODE_SET_HOURS (‘H’), MODE_SET_MINUTES (‘M’), MODE_TUNE (‘T’, the pulses-per-minute calibration screen), and MODE_ERROR (‘E’, fork lost). A push-button rotary encoder walks through them locally; a 9600-baud serial interface does the same remotely. The command set is single-letter — E echo, A auto-send time, C charset (the custom Elian-derived script vs. plain numerals), T get/set time, P get/set pulses-per-minute, M read mode, R read/set run state — each answered with =OK or =ERR plus an error code (:UC unknown command, :INV bad parameter). The full command table and the error semantics belong to the collected-project walk-through (Vol 9) and the cheatsheet (Vol 10); what matters for this volume is the one command that touches the timebase: P, the calibration register (§5.4).

5.3.5 The error mode — losing the fork

Because the fork is the timebase, the firmware must notice if it stops humming — a dead fork is not a slow clock, it is no clock. The Timer0 ISR watches the squared fork signal on pin PIND5 every ~0.8 ms: it tracks whether the level is still toggling. If the input keeps changing it asserts the “oscillator OK” status LED; if the level stops changing for a debounce count (clock_timeout), it clears running and, if the clock was displaying time, forces mode = MODE_ERROR. The ‘E’ mode then shows the error glyph instead of a frozen, silently-wrong time. This is the one failure mode the RTC builds simply cannot have — their crystal is sealed and self-sustaining — and it is the price of making the resonator and the clock the same object.

5.4 Calibration — the pulses-per-minute register

A real fork never rings at exactly 440.000 Hz. Manufacturing tolerance, the magnet and coil loading, mounting, and temperature all pull it off by some small amount. The firmware’s entire rate accuracy therefore comes down to telling the counter the fork’s true pulses per minute, so that the COMPA minute tick (§5.3.3) lands on a real minute. That is what the P command and the MODE_TUNE screen set.

5.4.1 Worked example — a fork at 440.2 Hz

Suppose the actual fork rings at 440.2 Hz instead of 440.000 Hz. Its true output is:

• 440.2 pulses/second
• 440.2 × 60 = 26 412 pulses per minute

Left uncalibrated at the default P = 26400, the firmware declares a minute as soon as it has counted 26 400 pulses. But the fork delivers those 26 400 pulses in only

• 26 400 ÷ 440.2 pulses/s = 59.973 s

so the clock thinks a minute has passed after just under 60 real seconds — it runs fast. The fractional error is

• (26 412 − 26 400) / 26 400 = 12 / 26 400 = 4.545×10⁻⁴ = 454.5 ppm

Over a day that is

• 4.545×10⁻⁴ × 86 400 s/day ≈ +39 s/day fast

— a clock that gains over half a minute a day, which is dreadful and entirely the counter’s fault, not the fork’s. Note 454.5 ppm ≈ 0.2 Hz / 440 Hz, exactly the fork’s fractional offset: the rate error equals the frequency offset, as it must.

Calibrated, you set P = 26412 (over serial, P26412\n, or by dialing the rotary encoder in MODE_TUNE until the display reads 26412). Now COMPA fires after 26 412 counts = 26 412 ÷ 440.2 = exactly 60.000 s, and the rate error goes to zero — limited thereafter only by the fork’s stability and temperature drift (§5.2.2), which the article reports gets the clock “within a couple of seconds per day,” i.e. roughly ±25 ppm. The firmware’s adjustment resolution is one count in 26 400 ≈ 38 ppm ≈ 3.3 s/day per step, fine enough that the residual error is the fork’s, not the counter’s.

How do you find the true count without lab gear? Run the clock against a known-good reference (your phone, an NTP clock) for a measured interval, note how many seconds it has gained or lost, and adjust P by P × (gain in s ÷ interval in s). Gained 39 s in a day? Increase the period per minute, i.e. increase P by 26 400 × 39/86 400 ≈ 12 counts → 26 412. One or two iterations converges.

5.4.2 Setting P, and where it is stored

Both the serial P command and exiting the MODE_TUNE encoder screen do the same three things in firmware: update pulses_per_minute, recompute pulses_per_second = pulses_per_minute / 60, load the new minute count into OCR1A, and write the value to EEPROM (eeprom_update_word). On boot, main() reads that EEPROM word back; if it is not the erased value 0xFFFF it overrides the 26 400 default. So calibration survives power loss — you trim the clock once and it stays trimmed. (Setting pulses_per_second from the integer division means the per-second display tick is rounded to whole counts, e.g. 26 412/60 = 440; the master minute count keeps the exact rate regardless.)

5.5 Counting in the RTC builds

The two RTC builds have almost no counting logic worth the name — and that is the point. The hard timekeeping is inside the DS3231; the microcontroller is a position controller that reads a time and drives a mechanism to match. The interesting logic moves from dividing a frequency to closing the loop between commanded time and actual mechanism position — which is really Vol 4’s motion-control story, summarized here from the timebase side.

5.5.1 PlanetaryGear — DS3231 over I²C, position error drives the stepper

The Arduino reads H:M:S from the DS3231 over I²C. From that it computes where the hands should be — the minute hand at (minutes + seconds/60) × 6°, the hour hand at 1/12 that rate (the gear reduction that produces the 12:1 ratio mechanically is Vol 3). It compares the target to the stepper’s tracked current position and steps the difference, through the L293D and the GT2 belt pre-reduction. There is no frequency to divide: the RTC owns the second, and the loop simply nulls the error between “what time is it” and “where is the hand.”

The one piece of genuine counting-logic care is the zero reference. A stepper has no absolute position sense, so on power-up the firmware homes: it drives the carrier until the A3144 hall sensor sees the neodymium magnet, declares that the mechanical zero, and counts steps from there. Every subsequent target is steps-from-home. Lose count (a skipped step, a bind) and the clock is wrong until the next home — which is why Vol 4 dwells on backlash and repeatability. The timebase, though, is rock-solid DS3231 (§5.2.3): ±1 min/year, untouched by the maker.

5.5.2 Aviation — DS3231 + NTP, gauges from the RTC, chime scheduling

The Aviation build stacks both upper tiers of the spectrum. On boot (and periodically) the ESP32 connects to Wi-Fi and pulls NTP, using it to set the DS3231 and its own time (§5.2.4); between syncs it runs from the DS3231. Each update tick it reads the RTC time and positions three NEMA-17 gauge needles — seconds, minutes, hours — through TMC2208 microstepping drivers, each gauge homed against its own 3144E hall sensor at startup exactly as the planetary clock homes (Vol 4). So time flows NTP → DS3231 → RTC read → needle angle, with the network as calibrator and the crystal as flywheel.

The build also schedules a chime: the firmware watches the RTC time and triggers a JQ6500 audio module at the appropriate moments (e.g. the top of the hour). A caution on naming carried from Vol 1: the audio pack is labelled “DCF77,” but here that is the name of a chime sound theme, not evidence of a DCF77 radio-clock receiver. The timebase is the DS3231 disciplined by NTP; the only thing “DCF77” about this clock is what the chime sounds like. Describe it that way and you will not mislead anyone into thinking there is a longwave receiver on the board.

5.6 Accuracy budget — the four references compared

Putting numbers to the spectrum of §5.2, expressed as fractional rate error (ppm) and the resulting drift. “Fast/slow” is short-term behaviour; the long-term column is what the clock does left running for a year.

Table 1 — 5.6 Accuracy budget — the four references compared

Timebase	Rate error (ppm)	Drift	Character
AC mains, short-term	±~830 ppm instantaneous (±0.05 Hz on 60 Hz)	seconds gained/lost over an afternoon	wanders with grid load
AC mains, long-term	~0 ppm (time-error-corrected)	a few seconds over a month	excellent average, poor moment-to-moment1
440 Hz fork, uncalibrated	hundreds of ppm (454.5 ppm in the 440.2 Hz example)	≈ 39 s/day fast	rate error = fork frequency offset
440 Hz fork, trimmed (P set)	~±25 ppm (residual fork temp/stability)	≈ a couple s/day	”within a couple seconds per day” per the build
DS3231 (TCXO quartz)	±2 ppm (0–40 °C)	≈ 0.17 s/day ≈ ±1 min/year	set-and-forget
NTP (network time)	~0 ppm long-term	sub-second, bounded by sync latency	re-pinned to UTC each sync

Two things stand out. First, the fork spans nearly three orders of magnitude depending on one serial command — uncalibrated it is the worst timebase in the table, trimmed it is within spitting distance of the mains long-term and only ~10× worse than the DS3231. The single number P is the difference. Second, the gap from a trimmed fork (~25 ppm) to the DS3231 (~2 ppm) is not the divider logic — both count perfectly — it is the resonator: a sealed, temperature- compensated 32 768 Hz crystal simply holds its frequency better than a bare steel fork in open air. That is the whole reason the maker builds that “just want a clock” reach for the DS3231 and the build that “wants a humming fork” accepts a few seconds a day as the cost of the most interesting timebase in the hub.

The unifying lesson, restated from §5.1: a timebase produces a steady frequency, and counting logic divides it down to 1 Hz / 1 min / 1 hr and maps that onto the mechanism’s position. In two of the three builds the resonator is a sealed component the firmware merely queries; in the fork clock the resonator and the clock are inseparable, the firmware is counting the heartbeat itself, and calibration (§5.4) is the act of telling the counter how fast that heart truly beats.

5.7 References

• TuningFork firmware — NuclearLighthouseStudios, “Tuning Fork Clock” firmware (clock.c, Makefile, clock.hex) and serial-protocol README. ATtiny4313 at F_CPU 1 MHz; Timer1 in CTC mode clocked externally by the NE555-squared 440 Hz fork signal, OCR1A = pulses_per_minute = 440×60 = 26 400, OCR1B = pulses_per_second = 440; calibration register P persisted to EEPROM; modes D/H/M/T/E; serial 9600 baud, commands E/A/C/T/P/M/R, errors :UC/:INV. Held in 02-inputs/TuningFork/code/.
• TuningFork build article — NuclearLighthouseStudios, “The tuning fork clock” (The tuning fork clock.docx): the magnetic sense/drive coils, the single-stage common-emitter sustaining amplifier with ~440 Hz bandpass, the NE555 squarer, the choice to count pulses-per-minute for finer rate trimming, and the reported “within a couple of seconds per day after tuning.”
• DS3231 datasheet — Maxim/Analog Devices DS3231 extremely-accurate I²C TCXO RTC: 32 768 Hz temperature-compensated crystal oscillator, ±2 ppm 0–40 °C, I²C interface, battery-backed. Used by the PlanetaryGear and Aviation builds.
• Cross-references — Vol 1 (the four-subsystem architecture and the three threads), Vol 2 (how a position reads as a time), Vol 3 (the 12:1 gear reduction that maps minutes to hours), Vol 4 (the fork sustaining amplifier, the NE555 squarer, stepper microstepping and hall homing), Vol 9 (full collected-project walk-throughs incl. the complete serial command table), Vol 10 (cheatsheet: formulas and quick-refs). Bulova Accutron history: Vol 1, §1.2 and footnote ¹.

Footnotes

1. Historically, North American and European grid operators applied time-error correction — deliberately nudging the line frequency to keep the integrated cycle count matched to nominal time, holding synchronous-clock error to a few seconds. (Some operators have relaxed or discontinued formal correction in recent years, but the frequency remains tightly bounded.) This is what makes mains a poor short-term but excellent long-term timebase, and why synchronous-motor clocks kept good time for decades without any oscillator of their own. ↩ ↩² ↩³