Medical Equipment · IoT
Connected medical devices live at the intersection of sensing accuracy, secure event logging, and reliable wireless links (BLE, Wi-Fi, Zigbee, and sub-GHz are all common). Clock integrity underpins all three. This guide focuses on practical crystal choices for medical IoT platforms—how to plan RTC and MCU/radio references, preserve startup margin, and reduce clock-driven EMI and drift risks.
1) Timing architecture in connected medical devices
Medical IoT designs usually split timing into at least two domains: an always-on RTC domain for accurate timestamps and long-standby scheduling, and a performance clock domain for the MCU, sensors, and wireless baseband. Treating “the clock” as a single part is a common root cause of intermittent bugs—drifted logs, missed wakeups, unstable sampling cadence, and radio sensitivity loss under interference.
A practical clock-tree model
Battery / Main Power
│
├── RTC domain: 32.768 kHz crystal → RTC / always-on timer → timestamps / alarms / duty cycling
│
└── Performance domain: MHz crystal → MCU PLLs / ADC clocks / RF baseband → sensing + connectivity
In many platforms, the RF clock tolerance and the RTC drift budget must be evaluated separately. The right choice is a system decision: clock specs, firmware calibration strategy, and deployment environment.
2) Frequency planning for medical IoT (what engineers actually use)
Across IoT wireless platforms, a small set of reference frequencies repeatedly appear because they divide cleanly into common protocol timing, PLL plans, and MCU clock trees. In medical equipment, these choices also affect measurement repeatability and EMI behavior.
Core clock domains
| Domain | Typical frequency | Why it matters |
|---|---|---|
| RTC / always-on | 32.768 kHz | Event logs, alarms, sleep scheduling, backup timekeeping |
| MCU / baseband | 16 / 24 / 26 / 32 / 40 MHz | Processing cadence, peripheral timing, PLL plans |
| Wireless RF reference | Usually shared with MCU/baseband | Frequency error, channel tolerance, packet timing stability |
Common medical IoT use cases (where the clock bites)
- Remote monitoring: stable sampling cadence for ECG/SpO₂/temperature trends and time-aligned uploads.
- Portable therapy/control: deterministic control timing, watchdog behavior, and safe state transitions.
- Auditability: RTC-backed, tamper-resistant timestamps for alarms, dosage events, and service records.
- Wireless margin: fewer “mystery” disconnects and desense when the RF reference has adequate tolerance and startup margin.
3) Low-power operation and startup margin (wearables, handhelds, battery instruments)
Battery life is a first-order requirement in many medical IoT products, especially wearables and portable monitors. When the SoC uses a low-power crystal oscillator with limited drive capability, crystal ESR becomes a practical constraint: lower ESR improves oscillation margin and can reduce startup failures across temperature and aging.
Fuji Crystal provides low-ESR options specifically for low-power wearable and battery designs, where the oscillator circuit needs additional margin without increasing drive level.
What to validate
- Startup at cold and at low battery voltage
- ESR and drive-level margin vs. the SoC datasheet limits
- Sleep / wake transitions and RTC continuity
What usually fails in the field
- Marginal startup on some units (process + layout variation)
- Unexpected drift due to CL mismatch or parasitics
- Wireless instability traced to poor reference tolerance
Mitigation patterns
- Use a low-ESR crystal where the oscillator is weak
- Keep the crystal loop compact; isolate from aggressor nets
- Budget ppm against system needs, not just “datasheet comfort”
4) Temperature range and reliability planning
Medical IoT products span environments—from controlled indoor care settings to outdoor and home deployments. Crystal selection should reflect the real temperature envelope and the system’s tolerance to drift.
Typical operating temperature ranges used in IoT platforms
Product programs often align to common envelopes; extended ranges may be required for field devices and transport/storage profiles.
| Deployment profile | Typical operating range | Design implication |
|---|---|---|
| Indoor / consumer-style medical IoT | −20 to +70 °C | Focus on low power, small size, and stable startup across normal extremes |
| Industrial / edge healthcare environments | −40 to +85 °C | More margin required for startup and drift; consider calibration strategy |
| Automotive-adjacent / harsh deployments | −40 to +125 °C | Evaluate frequency stability over temperature and aging; consider TCXO where needed |
| Special programs (custom) | Up to −40 to +150 °C | Requires program-specific qualification and careful oscillator margin checks |
Small form factor is not always the priority in medical IoT. Many infrastructure and gateway-class devices prefer traditional package sizes when cost or assembly robustness dominates.
5) Platform map: common IoT SoCs and reference crystal choices
The table below consolidates common IoT SoC and wireless platforms with typical crystal frequency and footprint choices, mapped to representative Fuji Crystal series. Use it as a starting point, then verify the platform’s oscillator requirements (CL, ESR/drive, startup time, and tolerance).
| IC Brand | IC Number | Package size | FCom Series | Frequency |
|---|---|---|---|---|
| Broadcom | BCM43235 | 5032 SMD-4 | FCX-5M | 20 MHz |
| Broadcom | BCM43235 | 2520 SMD-4 | FCX-2M | 20 MHz |
| Broadcom | BCM4360 | 2520 SMD-4 | FCX-2M | 40 MHz |
| CSR | CSR1010 | 3225 SMD-4 | FCX-3M | 16 MHz |
| CSR | CSR1010 | 2520 SMD-4 | FCX-2M | 16 MHz |
| CSR | CSR8510 | 3225 SMD-4 | FCX-3M | 26 MHz |
| CSR | CSR8510 | 3225 SMD-4 | FCX-3M | 26 MHz |
| DME | DME_1080 | HC-49SMD-2 | FCX-9M | 16 MHz |
| Nordic | nRF24AP2 | 3225 SMD-4 | FCX-3M | 16 MHz |
| Nordic | nRF24AP2 | 2520 SMD-4 | FCX-2M | 16 MHz |
| Nordic | nRF24L01 | 3225 SMD-4 | FCX-3M | 16 MHz |
| Nordic | nRF24LE1 | 3225 SMD-4 | FCX-3M | 16 MHz |
| Nordic | nRF24LU1 | 3225 SMD-4 | FCX-3M | 16 MHz |
| Nordic | nRF51/24/80 Series | 3215 SMD-2 | FCT-3M | 32.768 KHz |
| Nordic | nRF51422 | 2520 SMD-4 | FCX-2M | 32 MHz |
| Nordic | nRF51422 | 2520 SMD-4 | FCX-2M | 16 MHz |
| Nordic | nRF51822 | HC-49SMD-2 | FCX-9M | 16 MHz |
| Nordic | nRF51822 | 2520 SMD-4 | FCX-2M | 32 MHz |
| Nordic | nRF51822 | 2520 SMD-4 | FCX-2M | 16 MHz |
| Nordic | nRF51824 | 2520 SMD-4 | FCX-2M | 32 MHz |
| Nordic | nRF51824 | 2520 SMD-4 | FCX-2M | 16 MHz |
| Nordic | nRF8001 | 3225 SMD-4 | FCX-3M | 16 MHz |
| Nordic | nRF8001 | 2520 SMD-4 | FCX-2M | 16 MHz |
| Nordic | nRF8001 | 2016 SMD-4 | FCX-2S | 16 MHz |
| Nordic | nRF8002 | 3225 SMD-4 | FCX-3M | 16 MHz |
| Nordic | nRF8002 | 2520 SMD-4 | FCX-2M | 16 MHz |
| Nordic | nRF8002 | 2016 SMD-4 | FCX-2S | 16 MHz |
| Nordic | nRF905 | 3225 SMD-4 | FCX-3M | 16 MHz |
| Nordic | nRF9E5 | 3225 SMD-4 | FCX-3M | 16 MHz |
| Remoteble | RT400 | 3225 SMD-4 | FCX-3M | 12 MHz |
| Remoteble | RT400 | HC-49SMD-2 | FCX-9M | 12 MHz |
| St Microelectronics | STM32 Series | 2520 SMD-4 | FCX-2M | 24 MHz |
| St Microelectronics | STM32 Series | 3215 SMD-2 | FCT-3M | 32.768 KHz |
| TI | CC2541 | 3225 SMD-4 | FCX-3M | 32 MHz |
| TI | CC2564 | 3225 SMD-4 | FCX-3M | 26 MHz |
| TI | CC2564 | 3225 SMD-4 | FCX-3M | 38.4 MHz |
| TI | CC2564 | 2016 SMD-4 | FCX-2S | 26 MHz |
| TI | CC2564 | 2016 SMD-4 | FCX-2S | 38.4 MHz |
| TI | CC2564 | 3215 SMD-2 | FCT-3M | 32.768 KHz |
| TI | CC2640 | 3225 SMD-4 | FCX-3M | 24 MHz |
| TI | CC2640 | 2016 SMD-4 | FCX-2S | 24 MHz |
| TI | CC2640 | 3215 SMD-2 | FCT-3M | 32.768 KHz |
| TI | CC2650 | 3225 SMD-4 | FCX-3M | 24 MHz |
| TI | CC2650 | 2016 SMD-4 | FCX-2S | 24 MHz |
| TI | CC2650 | 3215 SMD-2 | FCT-3M | 32.768 KHz |
| TI | CC3200 | 3225 SMD-4 | FCX-3M | 40 MHz |
| TI | CC3200 | 3225 SMD-4 | FCX-3M | 40 MHz |
| TI | CC3200 | 2016 SMD-4 | FCX-2S | 40 MHz |
| TI | CC3200 | 3215 SMD-2 | FCT-3M | 32.768 KHz |
| TI | CC3200 | φ2*6 | FCT-2T | 32.768 KHz |
Tip: If you share your SoC/MCU part number, target frequency, footprint, and temperature range, the FCom team can propose a shortlist and a verification checklist.
6) Design review checklist for medical IoT timing
Electrical (clock integrity)
- Load capacitance (CL) match and total parasitics budget
- ESR / drive-level margin vs. SoC oscillator limits
- Startup time across temperature and battery voltage
- Frequency tolerance budget for the radio standard in use
Layout & EMI (field robustness)
- Shortest possible crystal loop; guard against aggressor nets
- Keep high-edge-rate clocks away from analog front ends
- Ground referencing and return-path continuity near the oscillator
- Validate worst-case “RF on + ADC sampling + charging” scenarios
FAQ
Why do medical IoT devices still use a 32.768 kHz RTC crystal?
A 32.768 kHz tuning-fork crystal provides an ultra-low-power always-on time base for timestamps, event logs, alarms, and duty-cycled radios. It also enables clean 1 Hz division and predictable long-term timekeeping during sleep or backup power.
Which clock domain usually drives wireless link quality: the RTC clock or the RF/baseband clock?
Wireless performance is dominated by the RF/baseband reference (often a MHz crystal feeding the radio/SoC). RTC accuracy mainly affects scheduling and timestamp integrity, while the RF/baseband clock impacts frequency error, channel tolerance, and packet timing.
What frequencies are most common for MCU/radio references in connected medical devices?
Common IoT platform references include 16 MHz, 24 MHz, 26 MHz, 32 MHz, and 40 MHz, alongside 32.768 kHz for RTC. The exact choice depends on the SoC/radio, required accuracy, and the clock tree/dividers used by the firmware.
When is a low-ESR crystal worth specifying?
Low-ESR options are helpful when the SoC uses a low-power oscillator with limited drive capability (typical in wearables and battery instruments), or when you need extra startup margin across temperature, aging, and process spread.
How should I choose load capacitance (CL) for a crystal?
Match the crystal’s specified CL to the effective load seen on the PCB (including MCU/SoC pin capacitance, routing parasitics, and external capacitors). Correct CL reduces frequency offset and improves repeatability across builds.
When should I use a TCXO instead of a quartz crystal in medical IoT?
Use a TCXO when the radio/system needs tighter frequency stability over temperature than a standard crystal can provide, or when field conditions cause frequent re-calibration/re-sync. TCXOs are common in harsh outdoor deployments and precision wireless links.
