What a GPSDO/Atomic Clock actually delivers in avionics

Featured answer (the “definition that matters”)

A GPSDO (GNSS-disciplined oscillator) is a timing-reference system that continuously steers a high-quality local oscillator (OCXO/CSAC) using GNSS as a long-term truth source. The result is a reference that preserves low short-term phase noise from the local oscillator, while correcting long-term frequency/phase drift to remain traceable to GNSS time.

The three deliverables (what the system truly “hands to” other boxes)

Why a free-running XO/RTC is not enough (the engineering boundary)

• Traceability vs self-consistency: a free-running oscillator can be stable yet still drift away from an external time scale; a GPSDO explicitly constrains drift using GNSS observations.
• Time-scale fusion: short-term behavior is dominated by the local oscillator; long-term behavior is corrected by disciplining. This “fusion” is what enables both low phase noise and bounded long-term error.
• Observability and trust reporting: a GPSDO can output lock state, holdover state, and estimated error so the rest of the avionics stack can make safe decisions.
• Defined loss-of-reference behavior: when GNSS is degraded or lost, the system can enter holdover with a known policy (freeze/slow-steer/model-based) rather than drifting silently.

What “Atomic Clock” means on this page (no physics, only system value)

“Atomic clock” here refers to using a CSAC (chip-scale atomic clock) or a rubidium-based reference as the local holdover timebase. The practical value is not “better GNSS,” but more predictable holdover: lower mid-term drift, improved resistance to temperature/aging uncertainty, and therefore smaller time-error growth when GNSS is unavailable.

Figure F0 is intentionally minimal: it prevents scope creep while making the three deliverables explicit. The full architecture and signal flows appear in H2-2.

System architecture: GNSS receiver + disciplining engine + OCXO/CSAC + outputs

How to read the system: four flows (keeps the design coherent)

A GPSDO becomes easy to design and validate when the architecture is expressed as four distinct flows. Each flow has different failure modes, different “right” bandwidth/time constants, and different evidence signals.

• Reference flow: GNSS provides 1PPS, time-of-day, and reference health indicators (e.g., C/N0, satellite count, solution status).
• Measurement flow: phase and frequency are estimated by comparing GNSS timing markers against the local clock domain.
• Control flow: a disciplining/steering engine converts measured errors into actuator commands (DAC word, DDS bias, or DCO tuning).
• Output & distribution flow: clock synthesis, buffering, pulse shaping, and time-code formatting produce usable 10 MHz/1PPS/ToD outputs.

Core blocks (what must exist in any “real” GPSDO)

The implementation details vary, but the functional blocks below are unavoidable if the system must deliver low phase noise and bounded long-term drift.

• GNSS receiver: produces 1PPS + time solution; also exposes integrity cues (solution validity, C/N0 trends, leap/epoch status).
• Phase/frequency measurement: computes phase error (time offset) and frequency error (rate offset) between reference and local clock.
• Disciplining engine (steering law): selects bandwidth/time constants, filters measurement noise, and applies safe-state rules during degraded reference.
• Actuator: DAC or digitally-controlled oscillator interface that steers the local timebase without injecting avoidable noise/steps.
• Local timebase: OCXO/CSAC that dominates short-term stability; its temperature drift and aging dominate holdover growth.
• Clock synth + output conditioning: derives required frequencies, shapes 1PPS edges, and provides fanout with controlled additive jitter.
• Health/quality reporting: lock/holdover state, phase-step detection, and estimated time error (ETE) for system-level decision making.

Time path vs frequency path (the key mental model)

Although both outputs originate from the same timebase, the control objectives differ: 1PPS enforces an epoch boundary (phase/time alignment), while 10 MHz enforces a continuous tick-rate (frequency accuracy and short-term noise). Treating them as a single “lock” often causes a classic failure: either GNSS measurement noise is injected into the oscillator (too fast), or convergence becomes slow and recovery/holdover transitions become unpredictable (too slow).

What must be observable (signals that prove trustworthiness)

A GPSDO that cannot report internal evidence behaves like a black box. A system-ready design should expose at least: phase error, frequency error, PPS jitter, reference health, lock/holdover state, and quality flags. These are not “nice-to-have”; they are the only practical way to prevent silent time-base corruption.

This architecture page intentionally stops at “clean reference outputs.” Network distribution mechanisms (e.g., PTP/SyncE) belong to sibling pages and should be linked, not expanded here.

Oscillator selection boundaries: OCXO vs CSAC vs TCXO vs Rb (engineering view)

Selection principle (avoid “best oscillator” thinking)

Oscillator selection is a time-scale problem. A GPSDO is judged across multiple time windows: short-term cleanliness (phase noise / integrated jitter), mid-term stability (how the rate wanders over seconds to minutes), and long-term predictability (temperature drift + aging that dominates holdover time error). The correct choice is the oscillator that wins in the time window that drives the mission requirement, while meeting power, warm-up, and cost constraints.

What must be defined before choosing

• Primary deliverable: is the system dominated by frequency cleanliness (derived clocks) or by time-boundary accuracy (1PPS/time tags)?
• Holdover objective: target holdover duration and maximum allowed time error growth (minutes vs hours vs longer).
• Operating envelope: temperature range, vibration exposure, and whether warm-up time is acceptable.
• Operational budget: available power, size, cost, and calibration/test capability.

Engineering comparison (wins by time scale, not by marketing)

Clear boundary statements (when each becomes “necessary”)

• Choose OCXO when short-term cleanliness is the gating requirement and warm-up power is acceptable.
• Choose CSAC when mid-term holdover predictability is the gating requirement and a higher-cost timebase is justified.
• Choose Rb when extended holdover time-error bounds are mandatory and power/size/cost can be allocated.
• Choose TCXO when power/startup dominates and the system can tolerate larger time-error growth during GNSS loss.

The map shows “win windows,” not absolute rankings. The disciplining loop (H2-4) must still be tuned to avoid injecting GNSS measurement noise into the timebase.

Disciplining loop deep dive: PLL/FLL, bandwidth, time constants, and “steering”

Core idea (what the loop is really doing)

Disciplining is not “locking everything tightly.” It is a controlled fusion of two truths: GNSS is accurate but noisy in the short term, while the local oscillator is clean in the short term but drifts long term. The loop must follow GNSS only where GNSS is trustworthy (slow time scales), and preserve the oscillator where the oscillator is superior (fast time scales).

Why GPSDOs commonly use FLL + PLL (engineering roles)

• FLL (frequency loop): corrects rate error. It is best at pulling a large initial frequency offset into a small, manageable range and stabilizing the long-term slope of time error.
• PLL (phase loop): corrects residual phase/time offset (e.g., 1PPS alignment). It is best at enforcing a stable epoch boundary once the rate is under control.
• Combined behavior: FLL prevents slow “runaway” during outages and reduces recovery shock; PLL cleans up phase alignment without demanding unrealistic correction speed.

The tuning knobs (what to set, what it changes)

Steering implementations (what matters in system behavior)

• DAC tuning: fine control, but DAC noise/quantization and update behavior can couple into phase noise. Requires clean reference voltages and careful filtering.
• DCO / digital tuning word: compact control interface, but quantization steps can create discrete phase/frequency jumps if not rate-limited and filtered.
• Fractional-N / synthesizer bias: flexible frequency generation, but spur management and additive noise of synthesis stages must be controlled.
• DDS offset: strong fine resolution, but spur and image control are central; apply only where the spur budget is acceptable.

Common failure patterns (symptom → likely cause → corrective action)

Figure F2 highlights the three dominant noise-injection paths. Later sections quantify their impact using phase-noise/jitter metrics and holdover time-error growth.

Phase noise and jitter: from L(f) plots to a usable jitter budget

What the plot must become (the only output that budgets can use)

A phase-noise plot is not the goal. The engineering goal is a single, comparable number: RMS time jitter over a stated integration window and carrier frequency. Without the window and the carrier, a “jitter value” is not comparable across clocks or architectures.

Executable conversion workflow (L(f) → t_rms)

• Step 1 — Identify the carrier: choose the clock of interest at carrier frequency f₀ (e.g., 10 MHz or a derived higher-rate clock).
• Step 2 — Choose the integration window: select [f₁, f₂] in offset frequency that matches what the downstream system converts into timing error.
• Step 3 — Integrate to phase jitter: integrate the phase-noise density over the window to obtain φ_rms (phase jitter).
• Step 4 — Convert to time jitter: t_rms = φ_rms / (2π f₀).

How to choose the integration window (engineering rules, not a standards lecture)

Why different systems care about different offsets (kept generic to avoid scope creep)

• Edge/instant timing sensitivity: systems that convert clock edge uncertainty directly into measurement error are most sensitive to the offsets that dominate edge timing variance.
• Synthesis chain sensitivity: derived clocks may be dominated by mid-band noise and spur behavior from synthesis and division stages.
• Distribution sensitivity: a clock tree can dominate far-out noise through additive jitter from buffers and fanout.

Who dominates the jitter (a diagnostic view)

A clock system is rarely limited by “the oscillator” alone. Dominance shifts with offset region: near-in noise often comes from the local timebase, mid-band from synthesis stages, and far-out from distribution buffers and power coupling. A usable budget separates these contributors instead of chasing one expensive component.

A “good jitter number” is one that matches the receiving system’s sensitivity. Always publish f₀ and the integration bounds with the RMS jitter result.

Allan deviation σy(τ): interpreting stability across time scales

What σy(τ) means (in engineering terms)

Allan deviation, σy(τ), is a stability map: it shows how fractional frequency stability changes when measurements are averaged over time τ. It is the most practical way to answer: “which time scale dominates the clock’s wandering, and what does that imply for holdover predictability?”

τ is not abstract: it maps to real engineering questions

• τ ≈ 1 s: short-term stability—how smoothly the clock rate behaves second-to-second.
• τ ≈ 10–100 s: mid-term wandering—how the rate drifts over tens of seconds to minutes (critical for short holdover windows).
• τ ≈ 1000 s and beyond: slow drift and aging—how temperature sensitivity and aging start to dominate long holdover behavior.

How to read the curve (dominant noise by region, explained without heavy math)

The curve shape tells which mechanisms dominate. When σy(τ) decreases with τ, short-term noise is being averaged out. A plateau often indicates flicker-like behavior or limits of the system’s control/modeling. An upward trend at large τ signals slow drift mechanisms that will dominate long holdover unless temperature and aging are managed.

Using σy(τ) to judge holdover potential (without turning into a full holdover chapter)

• Match τ to the outage window: focus on σy(τ) near the holdover time scale that matters operationally.
• Look for stability floor: a low, stable region around that τ suggests more predictable time-error growth.
• Watch large-τ rise: if σy(τ) rises strongly at large τ, long holdover bounds will require temperature control, aging estimation, or a higher-grade timebase.

Allan vs TDEV vs MTIE (selection guidance only)

Use Allan deviation for “stability vs time scale” and dominance diagnosis. Use TDEV when the project needs a time-error flavored RMS view across τ. Use MTIE when the project needs an upper-bound style view of maximum time deviation within a window. This page uses them only to choose the right lens; pass/fail criteria belong in the validation chapter.

This figure intentionally stays generic. It teaches interpretation without turning into a standards tutorial or a full holdover error-budget chapter.

Holdover design: predicting time error when GNSS is lost

What holdover must deliver (system-facing outputs)

Holdover is not a binary “GNSS lost” mode. A usable design must output two items that let the system make decisions: (1) a predicted time-error bound over mission windows (e.g., 30 min / 2 h / 24 h), and (2) a confidence grade that states how trustworthy that bound is right now.

Time error is the integral of frequency error (a practical framework)

Time error grows when the clock frequency is wrong. The engineering model starts with fractional frequency error Δf/f. In the simplest case, a bounded frequency offset produces a time-error bound that grows with time: TE(t) ≈ |Δf/f| · t. When drift terms dominate, time error accelerates, so long holdover depends heavily on temperature and aging management.

Where holdover error comes from (layered, so the dominant term can be attacked)

How to keep time error bounded (three hard tools + one safe recovery rule)

• Temperature compensation model: use temperature sensing plus a calibrated mapping from temperature to frequency correction; track residuals and widen bounds when residuals grow.
• Aging-rate estimation: update slow drift parameters using long observation windows; prevent short-term noise from corrupting aging estimates.
• Noise-aware policy: keep holdover tuned for the τ range that dominates the outage window; avoid importing reference noise into the holdover estimate.
• Recovery smoothing (phase-step guard): when GNSS returns, limit the maximum phase correction per second and ramp steering back gradually to avoid a discontinuous phase step.

This state machine emphasizes safety: do not keep steering from a suspicious reference; prefer a bounded holdover mode and an explicit confidence grade.

GNSS reference integrity in the timing domain (without an anti-jam deep dive)

The core safety problem

The most dangerous failure mode is not losing GNSS. It is following a bad GNSS reference and silently biasing the timebase. Timing integrity focuses on detecting suspicious timing behavior and switching policies that protect the disciplined oscillator.

Timing-domain detectors (what can be checked without signal-processing details)

Policy responses (graded actions that protect the timebase)

• Level 1 — Degraded trust: reduce steering bandwidth, increase averaging, tighten outlier rejection; continue monitoring residuals.
• Level 2 — Suspicious reference: freeze steering (hold last good), enter holdover, start TE-bound timers, and publish a lower confidence grade.
• Level 3 — Persistent anomaly: remain in holdover, widen bounds as needed, and publish explicit fault flags for downstream safe degradation.

Cross-checking sources (mention-only, timing-domain use)

Integrity improves when a suspect reference can be compared against an independent source: dual GNSS receivers, GNSS + CSAC behavior consistency, or an external 1PPS reference. Cross-checking is used here only as a timing-domain consistency gate, not as an anti-jam algorithm.

Timing integrity is a protection layer. It detects suspicious reference behavior, selects a safe policy, and exports explicit flags so downstream systems can degrade safely.

Timestamp units: time tagging architecture and error sources

Why a “good clock” can still produce “bad timestamps”

Timestamp accuracy is determined by the entire time-tagging chain, not only by the reference oscillator. A clean timebase can still yield poor timestamps when event edges are distorted, clock-domain crossings add uncertainty, or the UTC/ToD mapping is stale or invalid. A robust design therefore reports both timestamp values and timestamp quality.

Time-tagging data path (what each block actually does)

Error sources (classified so the dominant term can be attacked)

Engineering techniques that make timestamps trustworthy

• Per-channel delay calibration: measure and store deterministic delays for each input path (cable + isolator/conditioner + I/O path) and apply correction.
• Deterministic capture domain: keep capture and counter in a controlled clock domain; reduce CDC ambiguity by design (not by hope).
• TDC calibration / linearization: correct bin nonlinearity and temperature drift using a calibration table; widen uncertainty when calibration is stale.
• Quality flags: publish lock validity, calibration status, and an uncertainty estimate so the system can reject or down-grade timestamps safely.

Outputs and distribution: 1PPS / 10MHz / IRIG-B / ToD and redundancy

Goal: deliver a clean reference without creating new jitter or failure modes

Outputs are not “free.” Conditioning, isolation, cabling, and fanout buffers can add jitter, distort edges, or introduce reflections. A high-quality GPSDO output stage therefore treats each output as a controlled interface with a defined impedance, edge rate, and explicit health flags.

Output types and electrical boundaries (practical choices)

Distribution and fanout (where additive jitter accumulates)

• Keep fanout deterministic: use a planned distribution tree instead of ad-hoc buffering; limit cascade depth where possible.
• Control impedance and termination: treat 50Ω lines as transmission lines; avoid unterminated stubs that create reflections.
• Protect the reference from digital noise: isolation and clean power/ground segmentation prevent return currents from corrupting edges.
• Export output health: each output domain should publish status so downstream logic can degrade safely.

Redundancy A/B timebases (selection and switching semantics)

Redundancy is not only having two sources; it is having a defined switching meaning. Switching may be glitchless (no phase step), a controlled phase step (bounded and logged), or an alarmed cutover (fast switch with explicit flags). The correct choice depends on system tolerance, but the policy must be explicit and observable.