Does Your RTC Crystal Actually Matter for Battery Life?

Your coin cell died in 4 days. You expected 6 months. You’re Googling “reduce battery drain IoT project” at midnight, and some forum post from 2019 says “ditch the RTC module to save power.” You’re staring at your DS3231 breakout board like it’s the enemy.

It’s not. Your RTC is almost certainly drawing less than 1 µA. Something else on your board is pulling 100x to 1000x more, and until you find it, desoldering that RTC module will buy you roughly nothing.

Let me show you the actual numbers.

Where the Microamps Actually Go in an RTC Subsystem

People say “RTC power consumption” like it’s one thing. It’s two: the crystal and the oscillator circuit driving it.

The 32.768 kHz crystal itself is a passive component, a tiny quartz tuning fork in a metal can. The drive current flowing through it during oscillation is in the nanoamp range. Basically zero.

The real current draw comes from the oscillator circuit, whether that’s inside a standalone RTC IC or built into your MCU’s RTC peripheral. These circuits were designed from the ground up to sip as little as physically possible. That’s the whole point of the 32.768 kHz frequency: it’s low enough to keep power tiny, and it divides cleanly into 1 Hz for timekeeping.

Here’s what common parts actually draw:

Even the ESP32, the hungriest entry on this list, pulls just 5 µA. And that’s the entire RTC domain, not just the oscillator. The nRF52840 does it for a tenth of a microamp.

These are typical operating values straight from datasheets, not best-case marketing specs.

The Power Budget Reality Check

Let’s put 1 µA in context. A CR2032 coin cell holds about 225 mAh. At a 1 µA draw, that’s roughly 225,000 hours, over 25 years. Your RTC will outlive the battery’s shelf life by a wide margin.

Here’s what your board’s current draw probably looks like in relative terms:

RTC subsystem:         ~1 µA    ▏
Quiescent LDO (bad):  ~50 µA   ▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊▊
Power LED:             ~2 mA   ████████████████████████ (off scale)
Radio TX burst:        ~15 mA  ████████████████████████ (off scale)
Sensor polling:        ~500 µA ████████████████████████ (off scale)

The RTC is invisible next to a mediocre voltage regulator, let alone an LED or a radio.

If your battery dies in a week on a CR2032, your average draw is around 1.3 mA. The RTC accounts for roughly 0.08% of your power budget. Removing it saves you nothing meaningful.

The classic culprits are almost always one of these:

Voltage regulators with high quiescent current. That cheap AMS1117 on your breakout board pulls 5 mA just existing. Even “low dropout” doesn’t mean “low quiescent.” Check the Iq spec, not the dropout voltage.

LEDs left on. A standard indicator LED through a 1kΩ resistor draws 2–3 mA, which is 2000x your RTC. Many dev boards ship with a power LED you can’t easily disable.

Radios not sleeping properly. An ESP32’s WiFi radio pulls 80–160 mA when active. If your code doesn’t explicitly put it to sleep, or if it’s waking up more often than you think, there’s your battery killer.

Sensors polling when they should be interrupting. A BME280 in forced mode draws 0.1 µA between measurements. In normal mode? 3.6 µA. An accelerometer like the LIS3DH can wake your MCU on motion instead of your MCU constantly asking “did anything move yet?”

When Skipping the RTC Actually Makes Sense

There are legitimate reasons to remove an RTC. They’re just not about power.

BOM cost and board space. An external RTC IC like the DS3231 costs $2–5. The crystal, caps, and layout space add up. If you’re building 10,000 units and every cent matters, cutting an external RTC is a legitimate optimization.

Simplicity. One fewer I2C device means one fewer driver to write, one fewer thing to debug at 2 AM, one fewer part that can arrive DOA from your supplier.

Network-synced devices. If your device always has WiFi or cellular access, you can grab the time from NTP or GPS every time it wakes up. No local timekeeping needed.

Know the trade-offs, though. Without a crystal-driven RTC, you lose precise wake-up scheduling from deep sleep. Your MCU’s internal RC oscillator drifts ±2% or worse, compared to ±20 ppm for a 32.768 kHz crystal. To make that concrete: ±2% drift means you lose or gain about 72 seconds every hour, while ±20 ppm means just 72 milliseconds. After a power loss, you have no idea what time it is until you reach the network.

The smart move for most projects: skip the external RTC IC if you want to simplify your BOM, but keep a 32.768 kHz crystal on your MCU’s LSE pins. The MCU’s built-in RTC peripheral, driven by that crystal, gives you accurate timekeeping and timed wake-ups for essentially free power. The nRF52840 does it for 0.1 µA. The STM32L4 for 0.55 µA.

If you’re working with Hubble’s network, the timing requirements for BLE advertising windows make a stable clock source especially valuable. The timing management guide covers how the RTC peripheral fits into transmission scheduling.

What You Should Actually Investigate

If your battery life is bad, here’s where to look, in order of impact:

1. Measure your actual sleep current. Use a µCurrent Gold, a Nordic PPK2, or even a multimeter on the µA range. If your “sleeping” board draws more than 10 µA and you don’t know why, that’s your starting point. Is it µA or mA? That single measurement tells you everything.

2. Check your voltage regulator’s quiescent current. Look up the Iq spec in the datasheet. If it’s above 10 µA, consider replacing it with something like a TPS62740 (360 nA Iq) or an RT9080 (0.5 µA Iq).

3. Confirm your radio is actually asleep. Don’t assume WiFi.disconnect() puts the radio to sleep. On an ESP32, you need esp_wifi_stop() before entering deep sleep. On an nRF52, check that the softdevice isn’t keeping the radio in idle.

4. Look for floating GPIO pins. Unconnected inputs toggle randomly and can source current through internal ESD diodes or enable unexpected peripherals. Set unused pins to output low or input with pull-downs.

5. Kill indicator LEDs. Cut the trace, desolder the resistor, or at minimum drive the GPIO low in your sleep routine. A single LED wastes more power than 1000 RTCs.

6. Check for parasitic current paths. ICs on shared I2C or SPI buses can be sneaky here. Say you cut Vcc to a chip but leave the bus lines high: the pull-ups will source current through the chip’s data pins and ESD diodes. That parasitic drain adds up.

For devices designed around BLE, where sleep current budgets really matter, the Hubble device SDK includes reference implementations that handle radio sleep and wake scheduling properly across nRF52, STM32, and other supported platforms.

Keep Your RTC, Fix Your Regulator

Your RTC is fine. It was designed for exactly this job: keep time for years on microamps. The components actually draining your battery are pulling 100x or more what the RTC draws.

The RTC doesn’t just cost you almost nothing in power; it actively saves you power by enabling precise timed wake-ups from deep sleep. Without it, you’re stuck with cruder wake-up methods (watchdog timers, external interrupts) or keeping the MCU in a lighter, thirstier sleep mode.

Go measure your sleep current. That single number will tell you whether your problem is a 1 µA RTC or a 5 mA voltage regulator. I think you already know which one it’ll be.

Hubble Network enables direct-to-satellite connectivity for battery-powered devices—no gateways, no infrastructure. See how it works →