Rb / OCXO / TCXO Timebase for Instrument References
← Back to: Test & Measurement / Instrumentation
An instrument-grade timebase is a self-contained reference module that delivers low phase noise, predictable stability, and serviceable calibration evidence through temperature control, monitoring/logs, and controlled holdover/switching. Choosing TCXO, OCXO, or Rb is less about ppm and more about the stability window that matters (jitter/phase noise, ADEV, aging) and the proof you can produce in production and in the field.
H2-1 · What this page covers: instrument-grade timebase module
An instrument-grade timebase module is the chassis-level reference subsystem that provides low-phase-noise frequency outputs (typically 10 MHz / 100 MHz), a time-alignment marker (1 PPS), and REF IN/OUT plumbing, while also delivering holdover, health telemetry, and a calibration/trim interface.
Where it sits in an instrument
- Upstream / external: REF IN from a lab standard (e.g., GPSDO or house 10 MHz), plus service access for calibration.
- Inside the chassis: the timebase module acts as a reference service feeding multiple subsystems without exposing their internal clock trees.
- Downstream: REF OUT to cards/subsystems as a stable baseline for synthesizers, sampling clocks, and timestamp alignment (details belong to other pages).
I/O contract: what the module must provide
- Frequency outputs: 10 MHz (common) and/or 100 MHz with buffered, distribution-ready drive.
- Time marker: 1 PPS for time alignment and long-interval drift tracking (marker integrity matters as much as edge timing).
- Reference ports: REF IN/OUT with clear state signaling (Locked / Holdover / Reacquire).
- Health telemetry: lock state, oven/temperature status, EFC/trim headroom, internal frequency/phase offset trend, supply & sensor flags.
- Calibration interface: safe trim path (EFC/DAC/digital) + versioned storage + audit-friendly event logging.
Three performance needs (and what they really mean)
Scope boundary (to prevent topic overlap)
- This page covers: TCXO/OCXO/Rb reference choices, temperature control, redundant switching, holdover behavior, monitoring/logs, and calibration/trim interfaces.
- Not covered here: counter/TDC internals, trigger/event routing implementations, instrument-specific front-end/IF chains, and detailed phase-noise measurement methodologies.
Quick check: if a paragraph starts describing a specific instrument’s signal chain, it belongs in a different child page.
Figure ALT: Instrument chassis diagram highlighting a timebase module with REF IN, 10 MHz/1 PPS outputs, monitoring logs, and calibration interface.
H2-2 · Fast selection: TCXO vs OCXO vs Rb (decision table)
Selection should start from constraints (power budget, acceptable warm-up, and required holdover), then be validated with evidence (phase-noise shape, Allan deviation trend, and drift/aging logs). The same “ppm” headline can hide very different short-term noise and mid-term environmental sensitivity.
| Decision axis | TCXO / DTCXO | OCXO | Rubidium (Rb) |
|---|---|---|---|
| Power | Lowest; best for portable / always-on low budget. | Higher due to oven; steady thermal load. | Moderate to high; warm-up + maintain lock. |
| Warm-up to spec | Fast; minutes-scale stabilization typical. | Longer; “to spec” can be much longer than “oscillating.” | Longest; needs lock acquisition and thermal settling. |
| Close-in phase noise (1–100 Hz offsets) |
Limited; often dominated by crystal & compensation residuals. | Best short-term stability; strong choice when close-in noise is critical. | Strong long-term; close-in noise depends on internal disciplining design. |
| Far-out noise (>10 kHz offsets) |
Can be good; validate output buffer and supply noise coupling. | Usually good; buffer choice and rail noise still matter. | Depends on output conditioning; verify distribution driver noise. |
| Mid-term stability (ADEV trend, τ=1–1000 s) |
Sensitive to ambient gradients; compensation limits show up in τ region. | Excellent; oven isolates the crystal from ambient changes. | Very strong; designed for stability and predictable behavior. |
| Aging & drift | Can drift with temp/stress; needs periodic check if used as a lab ref. | Good; aging exists but can be tracked and trimmed if interface exists. | Best long-term; still requires health monitoring and service planning. |
| Holdover (REF IN lost) |
Limited; suitable when short outages are acceptable. | Good; depends on warm-up state and aging slope tracking. | Best; typical choice when outages must not ruin accuracy. |
| Size / cost / service | Smallest, lowest cost, simplest service. | Medium; thermal considerations in chassis placement. | Highest; service strategy benefits from telemetry and replaceable module design. |
| What to verify | Warm-up curve shape, temp residuals, EFC/trim headroom, rail-noise coupling to output buffer. | Warm-up to spec (not just start), oven stability vs airflow, g-sensitivity, EFC headroom trend. | Lock acquisition time, holdover drift curve, health flags (lock/temp), long-term drift evidence and service interval. |
Typical boundaries (pick by constraints first)
- Portable / low power / instant use: start with TCXO/DTCXO. Validate temperature residuals and trim headroom.
- Bench / best short-term stability: start with OCXO. Validate warm-up to spec and airflow sensitivity.
- Holdover / long-term evidence / serviceable reference: start with Rb (or Rb-disciplined crystal). Validate lock time and holdover drift curve.
Common mistake: “ppm-only selection”
- ppm is not phase noise: a tight frequency tolerance does not guarantee low close-in noise (timing coherence can still be poor).
- ppm is not mid-term stability: Allan deviation shape and environmental sensitivity determine repeatability during real instrument use.
- ppm is not holdover: outage behavior depends on drift slope, temperature sensitivity, and trim headroom, not a single static tolerance.
Quick check: if the system must remain trustworthy during reference loss, prioritize holdover evidence and monitoring signals over headline tolerance.
3-question self-test (fastest way to choose)
- Power budget: can the chassis spend continuous power on an oven or Rb module?
- Warm-up tolerance: can users wait for “to spec” stability, not just “output present”?
- Outage requirement: if REF IN disappears, must accuracy remain usable (holdover), and for how long?
Figure ALT: Triangle decision map comparing TCXO, OCXO, and Rubidium by power budget, warm-up time, and holdover requirement.
H2-3 · Specs that matter: phase noise ↔ jitter ↔ stability ↔ aging
Timebase quality is best understood by time scale: phase noise shapes short-term timing error, Allan deviation describes mid-term stability under real environments, aging sets long-term drift, and g-sensitivity explains why “moving air and moving chassis” can change frequency.
Phase noise L(f) → jitter / phase error (short-term)
- L(f) is a shape, not one number: close-in offsets (e.g., 1–100 Hz) represent slow phase wandering; far-out offsets contribute more to random edge timing noise.
- Jitter depends on the integration band: the same L(f) curve can yield very different integrated jitter when the offset limits change, so any jitter value must be tied to a stated band.
- Engineering meaning: prioritize close-in performance when phase coherence matters; prioritize integrated jitter (with stated band) when edge timing margin is the bottleneck.
Quick check: if a datasheet quotes “jitter” without an integration range, it is not comparable across parts.
Allan deviation σy(τ) (mid-term stability)
Quick check: compare the curve shape across τ, not a single τ point; the shape predicts real-world repeatability.
Aging → drift slope → calibration interval (long-term)
- Aging is about slope and predictability: the key question is whether drift follows a stable trend that can be logged and compensated, not just a yearly headline.
- Calibration interval is evidence-based: set by allowed error budget × observed drift slope × confidence from monitoring logs (not by a fixed calendar rule).
- Holdover and aging interact: when REF IN is lost, drift immediately depends on the current aging state and recent environmental history.
Quick check: a reference with good short-term noise can still force short recalibration intervals if drift slope is unstable.
g-sensitivity: vibration becomes frequency error
- Real sources: chassis handling, transport shocks, fan vibration, and bench resonance can translate to instantaneous frequency offsets.
- Why it matters: g-sensitivity explains “mysterious” frequency steps or increased mid-term instability even when temperature looks controlled.
- What to do: include vibration/shock conditions in validation and record event flags so field issues can be proven and traced.
Quick check: if stability changes when a fan speed changes, g-sensitivity and airflow gradients are likely contributors.
Figure ALT: Spec mapping diagram linking phase-noise and Allan-deviation curves to trigger jitter, holdover drift predictability, and recalibration interval, with g-sensitivity field effects.
H2-4 · TCXO / DTCXO deep dive: compensation, control, and sensitivity
A TCXO (or digitally compensated DTCXO) improves crystal stability by sensing temperature, applying a compensation model, and steering the oscillator via an EFC path. Practical performance is often limited by thermal lag, model residuals, and rail-noise coupling into the oscillator and output buffer.
Typical signal chain (blocks and roles)
- Crystal + oscillator core: sets the intrinsic short-term noise floor and reacts to stress/temperature.
- Temperature sensor: measures the local thermal state; sensor placement and filtering define delay and phase lag in compensation.
- Compensation model: analog shaping or digital LUT/polynomial that converts temperature to a trim command.
- Steering element: varactor or DAC/EFC that adjusts frequency; resolution and noise of this path can impact short-term behavior.
- Output buffer: drives 10 MHz/100 MHz out; buffer noise and supply coupling can dominate if not controlled.
Key engineering points (symptom → cause → verify)
Cause: sensor temperature ≠ crystal temperature; filtering adds delay.
Verify: temperature step/ramp test and residual-vs-time curve.
Cause: insufficient table resolution or poor fit strategy.
Verify: multi-point temperature sweep and residual curve, not only max ppm.
Cause: oscillator/buffer PSRR limits; ground impedance modulation.
Verify: compare output noise across power/load states and activity modes.
Cause: trim range saturates as aging accumulates.
Verify: log trim code/voltage trend and alert when headroom drops below threshold.
Quick check: if a TCXO looks fine on the bench but drifts in a chassis, thermal gradients and rail coupling are common causes.
Maintainability hooks (so the module can be serviced)
- Store calibration points with context: cal version ID, timestamp, reference source, and temperature range used during trim.
- Out-of-range behavior: when temperature exceeds modeled limits, enter a degraded state and log an event rather than silently drifting.
- Safe update path: protect calibration writes (lock/permission) to avoid “over-trimming” and unstable long-term behavior.
TCXO/DTCXO acceptance checklist (evidence-oriented)
- Warm-up curve: time to settle to a defined stability target (not merely “oscillation start”).
- Temperature residual: residual-vs-temperature plot over expected range; verify no sharp kinks.
- Trim headroom: EFC/DAC range margin at start-of-life and after accelerated aging.
- Rail sensitivity: compare output noise across supply ripple and activity states.
- Logs available: trim code, temperature, and state flags must be readable for field diagnosis.
Figure ALT: TCXO/DTCXO block diagram showing temperature sensor, compensation model, DAC/EFC steering, crystal oscillator and output buffer, with side arrows for rail-noise coupling and thermal lag.
H2-5 · OCXO deep dive: oven physics, control loop, and warm-up behavior
An OCXO stabilizes frequency by holding the crystal on a controlled thermal platform. Practical performance is set by the thermal RC model, the control loop behavior, and the warm-up “tail” that determines true time-to-spec rather than “time-to-output.”
Oven thermal model (heat capacity, thermal resistance, setpoint)
- Heat capacity (Cth): larger thermal mass reduces sensitivity to fast ambient changes, but increases warm-up time and can lengthen settling tails.
- Thermal resistance (Rth): higher isolation reduces the impact of airflow and chassis gradients, but also slows recovery from disturbances and raises steady heater power.
- Setpoint selection: should balance isolation vs power vs long-term stress. A higher setpoint is not automatically better if it increases gradients, drift steps, or aging pressure.
Quick check: a stable-looking oven temperature does not guarantee the crystal’s effective temperature is settled; gradients and sensor placement matter.
Control loop (PI/PID) and low-frequency disturbance risk
- Loop objective: keep the crystal region at setpoint despite ambient and load disturbances.
- Sensor placement and filtering: excessive filtering or poor placement adds delay; delay can turn disturbances into long settling tails or slow oscillations.
- Low-frequency modulation: heater power corrections and slow thermal dynamics can imprint low-frequency wander that shows up as mid-term instability.
- Dual-oven / dual-layer isolation: an outer layer buffers ambient swings so the inner oven sees a quieter environment, at the cost of higher power and longer time-to-spec.
Quick check: if frequency “steps” repeat when fan speed changes, the system is seeing a thermal disturbance path and a slow recovery tail.
Warm-up behavior: define time-to-spec, not just warm-up time
A usable definition of time-to-spec is: within a defined observation window, frequency change stays below a stability threshold and does not rebound strongly under small environmental perturbations (airflow or nearby heat activity).
Noise and sensitivity sources (what limits real instruments)
- Oscillator core noise: sets the fundamental short-term performance baseline.
- Thermal control disturbance: heater corrections and slow dynamics can inject low-frequency wander.
- Mechanical stress and mounting: screw torque, board flex, or mounting orientation can shift frequency and change g-sensitivity response.
- Output conditioning: ALC and the output buffer can couple supply activity into the reference output if not controlled.
Quick check: a “great” OCXO block can look average at the chassis connector if buffer noise and airflow disturbance are not managed.
OCXO acceptance checklist (evidence-oriented)
- Time-to-spec curve: measure or characterize the settling “tail,” not just time-to-start.
- Airflow sensitivity: verify frequency response to fan mode changes or airflow perturbations.
- Mounting repeatability: check for frequency shifts under re-mount or orientation change.
- Heater margin: confirm stable operation across ambient range without saturation.
- Telemetry hooks: log oven temp, heater drive, and state flags for field traceability.
Figure ALT: OCXO diagram showing oven heater control loop and a warm-up frequency error curve with setpoint, time-to-spec, and long-tail milestones.
H2-6 · Rubidium timebase: physics block + disciplining loop (engineering view)
A rubidium timebase is best treated as a locked reference module: a physics package produces a lock error signal, a control loop disciplines a clean oscillator via an EFC path, and the module exposes outputs plus states (Lock / Holdover / Alarm) that must be logged as evidence.
Engineering block view (what matters in integration)
- Rb physics package: treated as a black-box reference that generates a lock discriminator signal.
- Lock detector: determines lock quality and exposes lock/holdover state flags.
- Loop filter + servo: converts lock error into a stable correction command.
- VCXO/OCXO (controlled oscillator): provides low-noise distribution-ready output while being slowly corrected.
- I/O and evidence: 10 MHz and 1 PPS outputs, EFC monitor value, and state/event logs.
Quick check: “Lock = true” is not enough; usability also depends on EFC headroom and trend stability.
Warm-up, lock, and time-to-spec (deliverables)
- Warm-up time: from power-on to the point where lock acquisition can start reliably.
- Lock acquisition: time to reach a stable locked state without frequent dropouts.
- Time-to-spec: time until drift and stability meet the instrument’s error budget (often longer than lock acquisition).
- Evidence signals: lock flag, holdover flag, alarm flags, EFC level, and lock/unlock event counters.
Quick check: if lock time grows over months, it is a service-relevant indicator and should trigger maintenance investigation.
Lifetime risks and what to monitor
- Wear-out / aging risks: internal elements can degrade, increasing lock time, reducing stability margin, or raising dropout probability.
- Common symptoms: slower acquisition, unstable lock, EFC drifting toward limits, or narrower “safe” temperature window.
- Monitoring priorities: long-term EFC trend, lock/unlock counts, time-to-lock trend, temperature/heater states, and alarm history.
Quick check: treat trend logs as part of the timebase spec; they enable proof and shorten field debug cycles.
Typical combination: Rb disciplines OCXO/VCXO (module relation)
- Why it works: the controlled crystal oscillator provides clean short-term output; the Rb loop corrects slow drift for long-term accuracy.
- Key property: the disciplining loop is typically low-bandwidth, so it improves long-term behavior without “dragging” short-term noise.
- Integration boundary: this describes the timebase module relationship only; downstream clock-tree and synthesizer details belong elsewhere.
Rb acceptance checklist (practical)
- Time-to-spec: confirm it is documented and acceptable for the instrument workflow.
- State visibility: lock/holdover/alarm flags must be readable and logged.
- EFC headroom: verify margin so the module can stay disciplined over aging.
- Trend logs: lock time and EFC trends should be archived for service decisions.
- Outage behavior: holdover behavior must be predictable and flagged when degraded.
Figure ALT: Rubidium timebase block diagram showing physics package, lock detector, loop filter disciplining a VCXO/OCXO via EFC, with 10 MHz/1 PPS outputs and telemetry logs for lock/holdover evidence.
H2-7 · Holdover engineering: what happens when reference is lost
Holdover is the timebase module’s controlled behavior when REF IN disappears or an upstream reference loses lock. The goal is not “perfect time,” but predictable drift with explicit state flags, a frozen baseline, and a safe recovery path back to in-lock operation.
Entry conditions: detect → debounce → confirm → act
- Detect: reference presence, lock flag, and a quality indicator (when available).
- Debounce: require persistent failure over a defined window to avoid false triggers from short disturbances.
- Confirm: capture a last-known-good snapshot (EFC, temperature, source ID, timestamp, quality).
- Act: assert Holdover=1, freeze/guard control loops, and log a ReferenceLost event.
Practical rule: without debounce + latch, marginal references can cause repeated enter/exit cycles that look like random drift in the field.
What dominates holdover drift (time-scale view)
- Short term (seconds): residual control noise and the controlled oscillator’s intrinsic stability.
- Mid term (10 s → hours): Allan deviation shape, thermal disturbances, and loop-state choices.
- Long term (days → months): aging slope and predictability, which define re-calibration cadence.
- Temperature sensitivity: airflow, chassis gradients, and nearby heat sources can turn drift non-linear if not contained.
Engineering takeaway: holdover is an error-budget problem across time scales, not a single number.
Core strategies inside the timebase module
Guardrails: if EFC headroom is low at entry, assert an alarm early—freezing near a limit can shorten usable holdover time.
Recovery path: Reacquire vs Settling (do not merge them)
- Reacquire: reference returns; re-check presence/quality; re-enable lock with debounce and stability checks.
- Settling: lock is achieved, but time-to-spec may still require a tail period; expose Ready/ToSpec separately.
- Output signaling: keep Holdover=1 until reacquire is stable; keep ToSpec=0 until settling gates pass.
- Anti-flap behavior: use hysteresis and minimum-dwell timers to prevent rapid state toggling near thresholds.
Best practice: treat “Lock” and “ToSpec/Ready” as different promises to downstream consumers.
Holdover evidence checklist (what to log)
- ReferenceLost event: reason code (presence=0, upstream unlock, quality fail) + timestamp.
- Entry snapshot: EFC value, temperature, source ID, lock/quality flags.
- Duration and exit: holdover duration, reacquire attempt count, and time-to-lock trend.
- State flags: Holdover, Reacquire, ToSpec/Ready, and any limit alarms (EFC headroom, heater margin).
Figure ALT: Holdover state machine diagram showing Locked, Holdover, Reacquire, and Settling with output flags and event logs.
H2-8 · Redundant switching: A/B references, hitless changeover, alarms
A/B reference redundancy aims to keep a stable 10 MHz / 1 PPS output even when one source degrades. “Hitless” changeover means phase continuity and minimal short-term disturbance, achieved by pre-alignment, debounced decision logic, and auditable logs.
A/B architectures (practical options)
- Same-class redundancy: OCXO A + OCXO B for consistent behavior and simpler maintenance.
- Complementary pair: Rb + OCXO for long-term discipline plus low-noise distribution output.
- Hot standby: keep the standby warmed and health-checked; switching to a cold standby is not redundancy.
Switch criteria: hard fault / soft degradation / trend limits
- Hard fault (immediate): lock fail, ref missing, heater saturation, critical alarm.
- Soft degradation (debounced): quality drop, temperature abnormal, frequency delta exceeds limit for a sustained window.
- Trend limit (preventive): time-to-lock growing, EFC headroom shrinking, or persistent aging slope drift.
- Anti-flap: debounce + latch + minimum-dwell time to prevent repeated toggles near thresholds.
What “hitless” really means (principles)
- Phase continuity: avoid phase steps at the output when changing sources.
- Small Δf at switch: pre-align the standby so the instantaneous frequency difference is minimized.
- Stable output conditioning: keep buffer drive and amplitude stable to avoid coupling disturbances during switching.
Implementation detail stays at module level: comparator → pre-align → switch/crossfade → output buffer.
Alarms and logs (treat switching as an auditable event)
- switch_reason: fault / degradation / trend code.
- from → to: active source and new source.
- snapshot: phase/frequency delta summary + EFC_A/EFC_B + temperature states.
- post-check: whether ToSpec/Ready was achieved and how long settling took.
Redundancy acceptance checklist
- Standby readiness: confirm standby is warmed, stable, and monitored continuously.
- Switch repeatability: validate no output phase step beyond the allowed budget.
- Decision robustness: verify debounce, latch, and hysteresis prevent flapping.
- Evidence: verify event logs capture reason + snapshots + post-check results.
Figure ALT: Redundant A/B reference switching diagram with comparator, pre-align gate, debounce/latch decision logic, switch/crossfade, output buffer, and alarm/log evidence.
H2-9 · Monitoring & event logs: prove stability in the field
Instrument-grade timebases stay trustworthy in the field when health is observable and stability is evidence-based. A good telemetry design separates slow trends (drift/aging/margin) from discrete events (reference loss, over-temp, rail dips, and A/B changeovers) and ties both to a consistent alarm severity model.
Must-log telemetry (minimum set)
Practical rule: capture flags + temperatures + control words + internal offsets so stability can be proven without guessing.
Trends vs events (two different products)
- Trends explain slow change: EFC drift, heater baseline, time-to-lock trend, margin shrinkage.
- Events explain incidents: ReferenceLost, OverTemp, SwitchOver, PowerDip, LockDropout.
- Link them: each event stores a snapshot so trends can be correlated with the failure moment.
Trends answer “is it getting worse”; events answer “what happened at that time.”
Alarm severity model (ties into switching)
Best practice: use the same severity tags in state flags, event logs, and A/B switching decisions.
Event record: minimum fields for traceability
- timestamp + event_code + severity (W/D/C)
- state_flags: Lock/Holdover/ActiveRef/ToSpec
- snapshot: EFC, OvenTemp, HeaterPower, Δf/Δφ summary, rails flags
- counters: lock_drop_count, switch_count, overtemp_count
Proof pack (what “stable in the field” looks like)
- 30/180-day EFC trend summaries with headroom margin snapshots.
- Lock dropout counts and duration distribution (with rail/thermal correlation tags).
- SwitchOver list: reason codes + before/after snapshots + time-to-spec after switching.
- Calibration version history and post-check results (links to the service workflow).
Figure ALT: Monitoring points map for a timebase module showing Temp, Heater, EFC, Lock, RefDiff, Rails, Shock/Vibe flags, and EventLog flowing to a telemetry service port.
H2-10 · Calibration & trim interface: EFC, DACs, storage, and service workflow
Calibration makes a timebase maintainable: trims are versioned, stored with integrity checks, applied deterministically at boot, and protected against accidental writes. The workflow is designed around last-known-good, post-check gates, and a service-grade audit trail.
What gets calibrated (module-only scope)
- Frequency offset: bring the module’s 10 MHz output back to target.
- Temperature residual: reduce leftover error after compensation/oven control.
- 1 PPS alignment (if provided): align module output timing without touching downstream distribution.
Scope boundary: calibration applies to timebase outputs only, not to a system-wide clock distribution fabric.
Trim interfaces (analog vs DAC vs digital)
Storage integrity: CalVersionID, CRC, apply-on-boot
- Versioned records: each trim update produces a new CalVersionID.
- Integrity: store parameters with CRC (or equivalent) and reject partial writes.
- Deterministic boot: apply the latest valid version; otherwise fall back to last-known-good.
- Write safety: power-loss tolerant update sequence to avoid “half-written” calibration states.
Common failure mode: version updates without complete parameter writes. Prevent by atomic update rules and validation gates.
Service workflow (field-maintainable steps)
- Pre-check: confirm Lock=1 and ToSpec/Ready=1 (stable thermal state).
- External reference gate: only proceed when the reference quality gate is satisfied.
- Read baseline: log current CalVersionID, EFC word, headroom, and offsets summary.
- Compute trim: generate new trim values with bounded deltas.
- Write + verify: store in NVM with CRC and update CalVersionID.
- Apply + post-check: re-lock and confirm offsets are within target; record time-to-spec.
- Audit trail: store operator level and reason; update next service recommendation from trends.
Prevent mis-calibration (auth/lock/rollback)
- Access levels: read-only, service, factory; default to locked in normal operation.
- Calibration lock: require an explicit unlock step with a time-limited window.
- Rollback: if post-check fails, revert to last-known-good and log the rejection reason.
- Bounded changes: clamp trim step sizes to avoid accidental large offsets.
Figure ALT: Calibration data flow diagram showing external reference compare, trim computation, versioned NVM write with CRC, EFC/DAC apply path, auth/lock gate, post-check ToSpec gate, and rollback to last-known-good.
H2-11 · Validation & production checklist: what proves it’s done
Acceptance is evidence-based: design validation proves the timebase meets stability targets across environment and faults, production tests keep every unit consistent, and screening reduces early-life drift and outliers. A “PASS” is not a statement— it is a traceable bundle of curves, logs, and calibration IDs.
A) R&D validation (release gate)
- Precision DAC (EFC): ADI AD5693R / AD5683R; TI DAC80501 / DAC8551
- Precision reference: ADI ADR4550 / ADR4525; TI REF5050 / REF5025
- Temp sensor: TI TMP117; ADI ADT7420
- High-res ADC (telemetry): TI ADS124S08; ADI AD7124-8
- Power/current monitor: TI INA228 / INA229; ADI/LTC LTC2947
- NVM for cal/logs: FRAM MB85RC256V / FM24C256; EEPROM 24LC256
- Supervisor / reset: TI TPS3890 / TPS3808; ADI/LTC LTC2937
B) Production test (fast factory screen)
- Warm-up / lock / ready timing: measure time-to-lock and time-to-ready (ToSpec). Flag long tails.
- EFC headroom: record DAC/EFC code and ensure margin-to-limit is healthy (avoid “railed” units).
- Thermal control power: for OCXO, log steady heater power (or duty) and reject saturation behavior.
- Internal offset summary: capture a quick phase/frequency offset summary for consistency and outlier detection.
- Rails health snapshot: UV/OV flags and key rail values at steady state to catch assembly issues early.
- Low-leak mux/switch (path self-test): ADI ADG1209 / ADG1219; TI TMUX6111
- Current/rail snapshot: TI INA228/INA229; ADI/LTC LTC2947
- eFuse / protection (rail dips & events): TI TPS25982 / TPS2660; ADI/LTC LTC4368
- FRAM for high-write logs: MB85RC256V / FM24C256
C) Burn-in & screening (aging risk control)
- Burn-in exposure: run controlled time/temperature power-on exposure to reveal early-life instabilities.
- Drift slope estimate: compute drift trend from EFC movement and internal offset summaries over a defined window.
- Outlier rules: reject units with frequent lock dropouts, heater saturation, shrinking EFC margin, or step-like temp residual changes.
- Recovery behavior: verify consistent reacquire and settling after stress or reference disturbance.
- High-stability temperature readout: TI TMP117; ADI ADT7420
- Heater/rail monitoring: TI INA229; ADI/LTC LTC2947
- Integrity-protected storage: FRAM MB85RC256V; Supervisor TPS3890
D) PASS evidence pack (deliverables)
Figure ALT: Validation matrix listing timebase test items versus TCXO, OCXO, and Rb columns with MUST, SAMPLE, and N/A marks.
Request a Quote
H2-12 · FAQs (TCXO / OCXO / Rb timebase)
These FAQs answer the most common selection, specification, and field-proof questions for instrument-grade timebases. Each answer stays at the reference-module level: what the metric means, what to watch, and what evidence proves stability.
