TCXO-Based RTC for Low-Drift I2C Timekeeping
← Back to:Reference Oscillators & Timing
TCXO-Based RTC improves real-world timekeeping by disciplining a 32 kHz RTC with a stable TCXO reference and a measurable correction loop. It turns drift control into an engineering workflow—error budget, thermal strategy, firmware guards, validation gates—so accuracy is provable and maintainable in production.
What is a TCXO-Based RTC (and when you need it)
A TCXO-Based RTC keeps time in the usual low-power RTC domain (often a 32 kHz timebase), but uses a temperature-stable reference (TCXO, or TCXO-referenced measurements) to discipline the RTC: measure drift, apply trim or corrections, and keep long-term error close to the TCXO-grade behavior.
Definition in one line
RTC timekeeping remains in the always-on clock domain, while accuracy is enforced by TCXO-grade stability via periodic discipline (frequency trim and/or time correction).
What improves (quantified, in practical units)
- Drift is best reasoned in seconds per day, not just ppm. (Rule of thumb: 1 ppm ≈ 0.0864 s/day.)
- Typical goal: move from tens of ppm down to a few ppm or better, with the exact target set by the system budget (temperature profile, holdover duration, logging requirements).
- The gain comes from observability + correction: drift is measured against a stable reference and corrected before it accumulates.
When it is worth it (trigger checklist)
Out of scope (to avoid topic overlap)
- TCXO internal physics and phase-noise deep dives → see TCXO.
- Generic RTC fundamentals (calendar/alarms/basic 32 kHz crystal design) → see RTC.
- Backup switchover circuitry, supercap/coin-cell leakage troubleshooting → see RTC Backup & Switchover.
- Network time distribution/discipline (PTP/SyncE/GPSDO) → see Timing & Synchronization.
System architectures: 3 ways to discipline an RTC with TCXO
TCXO-based timekeeping can be built in three practical ways. The best choice depends on power budget, required observability, temperature dynamics, and production calibration constraints. The goal of this section is to map architectures clearly; loop theory and deep PLL/cleaner behavior are intentionally excluded.
Key decision dimensions (fast scan)
Labels A/B/C correspond to the architecture cards below. Values are directional; final choice must be validated against the drift budget and temperature profile.
A) Ref-in: TCXO provides a stable reference
- A stable TCXO output available to the timekeeping logic (directly or via measurement).
- Defined behavior for startup/warm-up and reference validity detection.
- Calibration performed before the TCXO output is thermally settled (initial minutes dominate error).
- Reference path contamination (power/ground noise) misleads the discipline loop.
B) Measure-and-trim: measure RTC drift, write trim
- A way to measure frequency or time error over a stable interval (counter/timer).
- RTC supports trim granularity that can actually move the drift distribution.
- Too-short measurement window (noise dominates) or too-coarse trim step (no convergence).
- Trim write timing near rollovers causes occasional apparent “time jumps”.
C) Soft discipline loop: firmware corrects time error (slew/step)
- Reliable time-error estimator (reference + stable logging cadence).
- A correction policy that keeps application time monotonic when required.
- Over-correction creates visible time wobble (frequent steps) instead of reducing long-term drift.
- State loss across power events breaks convergence until re-initialized properly.
Out of scope: PLL/clock-cleaner loop theory and deep jitter transfer. For those topics, use PLL and Jitter Attenuators / Clock Cleaners.
Error budget: from ppm to seconds/day (what dominates in reality)
Drift discussions become actionable only after choosing one consistent unit and an error budget structure. This section defines the conversion from ppm to seconds/day, then breaks total error into components that can be measured, controlled, and validated.
Conversion (fixed units for specs and acceptance)
seconds/day = ppm × 86400 / 1,000,000
Rule of thumb: 1 ppm ≈ 0.0864 s/day
seconds = ppm × holdover_seconds / 1,000,000
Example placeholder: X ppm × Y hours → Z seconds
Acceptance criteria should always specify the temperature profile and time window; ppm numbers without context are rarely predictive in real systems.
Error terms (structured for engineering control)
- TCXO stability (temperature behavior and aging).
- Reference validity during startup and warm-up.
- RTC divider/counting granularity and trim step size.
- Calibration quantization (cannot correct smaller than one step).
- Thermal gradients (sensor location ≠ TCXO/RTC thermal domain).
- Measurement window too short (noise dominates drift estimate).
- Write/read timing (rollover, shadow registers, I²C latency).
- Update strategy (step/slew policy causes apparent “drift”).
Out of scope: deep TCXO datasheet interpretation (phase-noise, internal compensation modeling). Use TCXO for device-level details.
“Expected root cause” vs “dominant real-world cause”
Quick check: log time_error and temperature during a chamber sweep and evaluate correlation and lag.
Quick check: increase measurement window by N× and verify whether the estimate converges or still wanders.
Quick check: use a burst/latch read mode or double-read verify around second boundaries.
Acceptance template (reusable pass criteria)
- Temperature profile: T(t) explicitly defined (step, ramp, cycle; include dwell time).
- Primary metric: max |time_error| over the window (e.g., 24 h) < X seconds (system budget).
- Secondary metric: error rate (seconds/day) bounded under the same profile.
- Behavioral constraint: no prohibited time back-steps for logging/audit use-cases.
- Health constraint: trim/correction does not remain saturated (otherwise the model/thermal proxy is wrong).
Disciplining algorithms: open-loop trim vs closed-loop control
Discipline is an engineering policy: correct frequency (trim) or correct time (step/slew), while controlling noise sensitivity, thermal tracking, and time behavior constraints (especially monotonic logs). This section maps practical options without diving into network time algorithms.
Open-loop: temperature/LUT → trim
Closed-loop: error estimate → filtered correction
- Window: longer = less noise, slower reaction.
- Update interval: too fast = chases noise, too slow = misses thermal drift.
- Limits: clamp correction rate and handle saturation to preserve stability.
Out of scope: PTP/SyncE academic algorithms and link delay correction. Use Timing & Synchronization.
Step vs Slew (time behavior policy)
Update interval selection (fast vs slow costs)
- Choose interval based on thermal time constant: fast thermal dynamics require faster tracking, but only if measurement noise is controlled.
- Use a window long enough to average measurement noise; shrinking the window should not change the estimated drift direction dramatically.
- Enforce rate limits: correction per update should be bounded to avoid visible time wobble.
- Log these fields together to debug real behavior: time_error, temperature, trim/correction, interval.
Temperature strategy: TCXO compensation, sensing, and thermal gradients
In TCXO-based timekeeping, temperature is not a single number. It is a field shaped by heat sources, copper planes, airflow, and thermal time constants. If the temperature proxy is wrong, even a strong ppm-grade TCXO can still produce visible drift at the system level.
TCXO internal compensation ≠ board temperature
The system temperature proxy must represent the same thermal domain as the TCXO/RTC. Physical distance alone is not sufficient; thermal coupling paths dominate.
- Sensor sits in a different airflow or copper plane than the TCXO.
- Local self-heating changes package temperature without changing “board temp”.
- Heat sources (SoC/PMIC) shift gradients during workload transitions.
Sensor placement & thermal path management (actionable)
- Place the sensor in the TCXO/RTC thermal domain.
- Avoid direct airflow and avoid high-gradient heat plumes.
- Prefer stable coupling: predictable lag beats random airflow-driven noise.
- Use keepouts / isolation slots to limit heat spreading from SoC/PMIC.
- Avoid large copper planes that “drag” heat into the TCXO area.
- Keep TCXO/RTC away from inductors and hot power stages.
Out of scope: oven-based stabilization details. For oven control strategies, use OCXO.
Thermal time constants: fast vs slow changes (control impact)
Risk: the proxy temperature moves faster than the oscillator domain. Updating too often can chase noise, creating visible wobble. Use longer windows, slower update, and correction clamps.
Risk: time error accumulates if the update interval is too slow. Tracking requires an interval that follows the thermal drift, while using windows long enough to keep estimates stable.
Typical root causes when drift persists
First check: correlate time_error with temperature proxy and measure lag.
First check: compare drift with identical temperature profile but different operating states.
First check: increase window and reduce update rate; verify whether correction events reduce.
Hardware design: reference routing, power, and I²C integrity
Hardware details often become “time drift” symptoms. Reference routing, low-noise power domains, and I²C integrity determine whether frequency correction is stable and whether time reads/writes remain atomic and reliable.
Reference path: routing & returns (key points only)
- Keep the reference path short and keep a clean return nearby.
- Avoid crossing split planes or noisy return loops that modulate threshold crossings.
- Maintain separation from fast I/O and switching nodes to reduce injected jitter into measurement.
- If level/interface options exist (CMOS/LVDS, etc.), treat them as a system choice; this section focuses on layout risk control.
Power domains: main / backup / always-on (why it matters)
TCXO/RTC should sit on a quiet LDO with clear domain boundaries to prevent digital load steps from modulating timekeeping.
Avoid “half-powered” states that can corrupt RTC configuration or cause intermittent resets. Ensure backup switchover does not create ambiguous register behavior.
I²C integrity: pullups, capacitance, and EMI (engineering keys)
- Pullups set a trade-off: stronger pullups improve edge rate but increase backup-domain power.
- Bus capacitance (trace length + devices) slows edges and reduces noise margin; intermittent retries can look like time “jumps”.
- EMI coupling can flip bits or force retries. Use routing separation, clean returns, and robust read/write retry policies.
- Clock stretching compatibility should be confirmed; mismatches can create silent timeouts and partial reads.
Out of scope: protocol teaching (addressing, arbitration, timing spec walkthroughs). This section focuses on failure modes that produce incorrect time reads/writes.
Shadow registers & atomic read (hardware + system cooperation)
Use a latch/snapshot mechanism if supported so that all time fields are read from a consistent captured state.
If snapshot is not available, use double-read consistency checks and avoid second-boundary reads; reliable edges and EMI control keep this effective.
Firmware timekeeping: read/write pitfalls, logging, and monotonicity
Many “RTC drift” issues are firmware artifacts: non-atomic reads, rollover-edge writes, inconsistent correction policy, or missing traceability. A disciplined RTC stack must make reads consistent, writes safe, and time behavior monotonic where required.
Read time correctly (avoid mixed-field reads)
- Use latch/snapshot read mode if supported.
- Use burst read for full time fields in one transaction.
- Double-read-verify: read, then re-read and confirm stability.
- Avoid sampling at second boundaries when snapshot is unavailable.
Write/correct safely (avoid rollover-edge writes)
- Use a defined write window away from rollover edges (seconds/minutes boundary).
- If the device supports shadow registers, use the recommended “write + commit” flow to avoid partial field updates.
- Treat I²C errors as first-class events: retries must be bounded; repeated failures should trigger a fault state rather than silent drift.
- Apply correction in the smallest domain possible (trim first; step only when policy allows).
Monotonicity: prevent time back-steps for logs
If the product requires ordered events, enforce no back-steps. When negative correction is needed, use bounded slew or an offset layer instead of rewriting time backward.
Step is reserved for explicit re-sync conditions (boot, large error, non-audit mode). Slew is preferred when logs must remain smooth.
Correction logging (required for field diagnosis)
Every correction should be traceable. Without a minimal record, thermal-proxy mismatch and I²C faults become indistinguishable from oscillator drift.
- timestamp, rtc_time, system_time (or reference time)
- time_error, estimated drift, trim/correction applied
- temperature proxy, update interval, window length
- reason code (boot, periodic, fault-recovery, manual)
- correction saturates for long periods (model/proxy mismatch)
- frequent corrections without shrinking error envelope (noise chasing)
- I²C retries spike near load transitions (EMI / return path)
Out of scope: operating system time subsystems. This section covers only RTC discipline behavior and error-proof read/write strategy.
Holdover and backup: what happens when main power disappears
Backup mode must preserve continuity and preserve the “discipline state” so that restoration does not introduce a large discontinuity. The design must balance retention, write cadence, and leakage while keeping a clear re-discipline sequence after power returns.
Backup-mode goals (what must survive)
- Continuous timekeeping (no resets, no ambiguous time state).
- Retention of calibration parameters (trim/LUT/controller state if required).
- Predictable restoration: no large time jump, no back-step for monotonic logs.
- Low leakage discipline: backup budget is dominated by always-on load and bus pullups.
Parameter storage: RTC RAM vs EEPROM vs FRAM (engineering trade-offs)
Lowest write cost and fastest access, but retention depends on backup power continuity and device behavior.
Strong retention but has wear and higher write energy. Requires rate limiting and careful commit timing.
Low write energy and high endurance, often preferred when frequent parameter updates are required in the field.
Write cadence (avoid draining backup or wearing storage)
- Write only on meaningful state changes (model update, temperature regime change, fault recovery).
- Rate limit periodic commits; prefer aggregated commits with a checksum and a version tag.
- Do not write at the power-fail edge unless a safe “last-gasp” mechanism is guaranteed.
- Log commit attempts and failures; a silent failure behaves like unexplained drift on restoration.
Restoration flow (coarse first, fine later)
After power returns, re-establish a trusted baseline quickly (validate RTC, confirm monotonic policy, load retained parameters).
Resume periodic discipline with conservative window/interval until temperature and load settle, then return to normal tracking.
Out of scope: supercap/coin-cell switchover circuits and leakage troubleshooting. Use RTC Backup & Switchover.
Validation & measurement: how to prove drift improvement (bench + chamber)
This section turns “drift improved” into a measurable acceptance claim. The proof requires a trusted reference, consistent sampling, and traceability of the control output (trim/correction). The goal is time-drift validation, not RF purity or phase-noise deep evaluation.
A) What to measure (minimum set)
Measure both the outcome (time error) and the cause (trim/correction trajectory). Without control-output traceability, measurement artifacts can be misread as oscillator drift.
- time_error: RTC vs reference (s/ms)
- freq_error: counter or slope estimate
- temp_proxy: TCXO/board sensor readout
- trim/correction: code + mode (trim/slew/step)
- sampling interval Δt (actual, not assumed)
- read method (snapshot/burst/double-verify)
- I²C retries/timeouts (counts)
- reason code (boot/periodic/fault-recovery)
B) Bench methods (choose one primary + one verifier)
Best for freq_error. Use sufficiently long gate time to avoid mistaking short-term noise for drift. Correlate against temp_proxy.
Best for proving read/write correctness: snapshot/burst usage, retry storms, and rollover-edge behavior.
Best for acceptance: time_error envelope over 24–72 hours with consistent sampling and full correction traceability.
Practical rule: trust improves when one method produces the primary metric and another independently verifies read/write integrity.
C) Chamber sweep (make temperature drift reproducible)
- Define a temperature profile: ramp rate, dwell/soak time, and number of dwell points.
- Record both chamber setpoint and temp_proxy to expose thermal lag and gradients.
- Evaluate drift during transients (ramps) as well as at dwell points; ramps often dominate real systems.
- Keep sampling interval stable; log correction trajectory to separate control behavior from the thermal plant.
D) Typical pitfalls (false drift)
Short gate or short log span makes noise look like drift. Use longer windows and report confidence bands.
Assuming a fixed Δt when the system jitters in scheduling distorts slope-based frequency estimates. Always log actual Δt.
PC clock corrections can dominate the measured error. Use a trusted reference source or explicitly log host sync events.
Variable bus delay/retry changes apparent timestamps. Record retries/timeouts and avoid rollover-edge reads/writes.
E) Pass criteria template (acceptance-ready)
- Profile: temperature profile Y (ramp + soak defined)
- Duration: continuous run T (e.g., 24–72 h)
- Metric: worst-case |time_error|, plus drift rate (optional)
- Criteria: worst-case error < X seconds, no persistent trim saturation, and no recurring I²C fault storms
Thresholds (X, Y, T) must come from system budget and workload profile. This page provides structure, not fixed numbers.
Production calibration & field maintenance: what to store, what to alarm
A TCXO-disciplined RTC must be manufacturable and maintainable. This section defines calibration strategies, storage structure, alarm triggers, and safe fallback behavior. Security/audit time signing is out of scope here and should be handled in a dedicated secure-time design.
A) Production calibration strategy (1-point / 2-point / multi-point)
Lowest cost. Suitable when thermal gradients are controlled and the error model is stable. Verification must still use a defined profile.
Balanced approach. Captures a dominant slope term without exploding complexity. Often the best default for production.
Used when temperature behavior must be explicitly modeled. Requires guardrails against overfitting and a stronger verification gate.
- Use a verification profile different from the calibration points (do not “train on the test”).
- Reject solutions that rely on persistent trim saturation to meet short tests.
- Treat sensor/TCXO thermal mismatch as a model risk; more points can amplify the mismatch.
B) What to store (versioned + integrity-checked)
Storage must survive resets and field updates. Use explicit versioning and CRC so corrupted or incompatible data triggers a predictable fallback rather than silent drift.
- cal_version + model id
- CRC (full record integrity)
- points[]: temperature point(s) + coefficients/trim base
- valid_range: temperature/profile label
- write_count + commit sequence number
C) Field alarms (detect “discipline is lying”)
Trigger when error growth rate exceeds a budgeted threshold. First action: check temperature correlation and correction cadence.
Trigger when trim remains near limits for long periods. This often indicates model mismatch or a dominant unmodeled thermal gradient.
Trigger when temperature changes no longer correlate with expected error response (lag/gradient changed by airflow or load).
Alarm thresholds must be derived from system budget. This page defines signals and failure modes, not fixed numbers.
D) Maintenance actions + safe rollback
- Re-calibrate when alarms indicate persistent mismatch and the environment profile has changed.
- Re-verify after firmware updates that change sampling cadence, correction policy, or temperature source.
- Fallback if discipline becomes unstable: degrade to “plain RTC behavior” while preserving logging and alarms.
- RMA decision when CRC fails repeatedly, trim saturates across conditions, or I²C reliability collapses.
Secure audit / signed time should be handled in the Secure RTC page (avoid mixing production drift maintenance with security architecture).
Engineering checklist (bring-up → validation → shipment)
This checklist converts “TCXO-based RTC discipline” into verifiable actions. Each item defines what to check, what to log, and what counts as pass, so results remain reproducible across bench, chamber, and production.
A) Bring-up — make the time path trustworthy first
- Check: reading time/date never returns mixed fields across a rollover boundary.
- How: snapshot/latch mode, burst read, or double-read-verify (two identical reads required).
- Log: read method, retry count, torn-read counter, bus error codes.
- Pass: 0 torn reads in long-run sampling; retry rate under a defined threshold (project-specific).
- Check: trim/offset registers are writable and read back identically.
- How: write → readback → soft reset → verify expected persistence behavior.
- Log: written code, readback code, reset context, CRC/metadata if stored externally.
- Pass: readback matches; post-reset behavior matches datasheet expectations.
- Check: changing trim produces a consistent change in measured frequency/time error.
- How: apply two trim codes; measure error sign and response repeatability.
- Log: trim code vs time error trend; “trim activity” (how often changes occur).
- Pass: monotonic direction; no high-frequency toggling that indicates chasing noise.
B) Thermal — verify the temperature proxy and gradients
- Check: ramp/soak steps are defined and repeatable.
- Log: profile ID, setpoint, measured proxy temperature, time stamps.
- Pass: repeated runs stay within the same thermal envelope (project-specific tolerance).
- Check: sensor reading represents the TCXO/RTC neighborhood (not a distant heat source).
- Log: sensor vs board reference temperature; estimated time constant (lag).
- Pass: offset/lag is stable enough to be compensated or bounded in the error budget.
- Check: time error does not jump when airflow/load conditions change.
- Log: labels for airflow/load modes + time error trajectory.
- Pass: delta stays within budget; otherwise enforce a more conservative update cadence.
C) Algorithm — cadence, step/slew policy, monotonicity
- Check: corrections are not toggling rapidly (a sign of measurement noise domination).
- Log: update period, time error variance, trim activity, outlier counters.
- Pass: time error converges while trim activity remains bounded.
- Check: policy matches the system’s audit/logging requirement.
- Log: correction mode (step/slew/trim), correction magnitude, reason codes.
- Pass: no forbidden step events; slews stay within allowable slope limits (project-specific).
- Check: system time never decreases, even during correction and restore.
- Log: monotonic violation counter, last-good timestamp, mitigation action.
- Pass: 0 violations; or violations are explicitly flagged and quarantined by design.
D) Backup/Holdover — persistence, restore, and re-discipline
- Check: single clean transition into backup mode (no chatter).
- Log: power-fail timestamp, entry flags, backup current snapshot (if measurable).
- Pass: no repeated entry/exit; critical parameters remain intact.
- Check: storing calibration/metadata does not exceed energy or endurance budget.
- Log: write count, write reason code, CRC/version, last-write age.
- Pass: write schedule obeys policy; CRC always validates after restore.
- Check: restore uses “coarse then fine” and respects monotonicity.
- Log: restore phases + time error/trim trajectory, fallback triggers.
- Pass: time error returns inside the budget within a defined recovery window.
Shipment gate — one-page acceptance template
- X) Worst-case time error: 24 h worst-case error < X s under temperature profile Y (project-defined).
- Y) Control health: trim does not saturate long-term; correction activity stays bounded.
- Z) Robustness: I²C error storms and monotonicity violations are 0 (or within a defined spec).
Fail mapping: X → error budget/thermal/measurement; Y → control strategy/thermal; Z → I²C integrity/firmware handling/factory-field policy.
Applications & IC selection notes (TCXO-Based RTC)
This section turns “TCXO-based RTC” into a selection flow: choose the architecture (A/B/C), then select TCXO/RTC/NVM features that match the drift budget, holdover profile, and logging integrity needs. Part numbers below are starting points for datasheet lookup—verify suffix, package, temperature grade, and availability.
A) Application slices (within this page boundary)
- Need: controlled drift over long runtimes.
- Constraint: weak/absent external time sources.
- Accept: 24 h worst-case error < X s under profile Y (project-defined).
- Need: predictable drift + monotonic time policy.
- Constraint: corrections must not break audit trails.
- Accept: no forbidden steps; all corrections are logged with reason codes.
- Need: stable time base without relying on periodic sync.
- Constraint: power budget, backup domain behavior.
- Accept: holdover drift stays inside the budget; restore is “coarse then fine”.
- Need: acceptable drift when sync is intermittent.
- Constraint: unpredictable reacquisition times.
- Accept: drift bounded across temperature and airflow perturbations.
B) Selection fields (TCXO / RTC / NVM) + concrete part numbers
Use when minimal part count and predictable drift matter more than custom discipline loops.
- DS3231SN# — I²C RTC with integrated TCXO + crystal.
- DS3232S# — I²C RTC with integrated TCXO + crystal, plus battery-backed SRAM.
- DS3234S# — SPI RTC with integrated TCXO + crystal, plus SRAM (SPI systems).
- DS3231M — I²C temperature-compensated RTC with internal MEMS resonator (no external crystal).
Use when the system already has a stable MHz reference (MCU/SoC timer) or needs tighter stability than a plain 32 kHz crystal domain.
- SiT5356AI-FQ-33E0-10.000000X — 10 MHz Super-TCXO (LVCMOS).
- ASTX-H11-25.000MHZ-T — 25 MHz TCXO (HCMOS).
- ASTX-H11-27.000MHZ-T — 27 MHz TCXO (HCMOS; common for platform clocks).
Note: external TCXO frequency can be divided to seconds via a timer/counter path; the RTC can be corrected (slew/step/trim) through firmware policy.
Use FRAM when frequent updates or “always-on logs” would wear out EEPROM; use EEPROM when writes are infrequent and power is tight.
- MB85RC256V — 256 Kbit I²C FRAM (Fujitsu).
- FM24CL64B-GTR — 64 Kbit I²C FRAM (Infineon).
- 24LC256 — 256 Kbit I²C EEPROM (Microchip; family includes 24AA256 / 24FC256 variants).
- TPS7A0220PDQNR — nanopower-IQ LDO (TI).
- MCP1700T-3302E/TT — low-IQ LDO 3.3 V option (Microchip).
- ADP150AUJZ-3.3-R7 — ultra-low-noise LDO 3.3 V option (Analog Devices).
Selection rule: backup-domain current dominates holdover; main-domain noise can dominate short-term correction stability. Use two rails/domains when needed.
C) Architecture mapping (A/B/C) — the minimum decision set
- Need the stable reference directly for a timer/counter? → prefer A) Ref-in.
- RTC exposes fine trim/offset controls? → prefer B) Measure-and-trim.
- MCU can stay active and enforce policy? → prefer C) Soft discipline loop.
- Monotonic event logs required? → constrain to slew/trim-first behavior; avoid uncontrolled step events.
D) Risk notes (what breaks drift claims in real deployments)
A “ppm-grade” device can still drift if the temperature proxy does not track the oscillator neighborhood. Validate with airflow/load perturbations, not only steady soaks.
Short observation windows, irregular sampling, or torn reads can look like frequency error. Always log bus retries and read method alongside time error.
Store calibration version + CRC and correction history (offset/temp/trim/reason). When discipline fails, fall back to a safe RTC mode rather than producing silent time regressions.
Reference examples (part numbers only; verify suffix/package/grade)
- Compensated RTC: DS3231SN#, DS3232S#, DS3234S#, DS3231M
- TCXO reference: SiT5356AI-FQ-33E0-10.000000X, ASTX-H11-25.000MHZ-T, ASTX-H11-27.000MHZ-T
- FRAM: MB85RC256V, FM24CL64B-GTR
- EEPROM: 24LC256 (family: 24AA256 / 24FC256)
- LDO examples: TPS7A0220PDQNR, MCP1700T-3302E/TT, ADP150AUJZ-3.3-R7
Recommended topics you might also need
Request a Quote
FAQs (TCXO-Based RTC)
Short, actionable troubleshooting. Each answer follows a fixed 4-line structure: Likely cause / Quick check / Fix / Pass criteria.
