Battery Life Isn't Magic —
It's Engineering

Every embedded project we take on at DigitalMonk starts with the same two questions before we ever touch a schematic: how long does this have to run, and what's the coin cell budget? For the Smart Golf Ball and the Sports Wearable, those questions defined every architectural decision from MCU selection through to firmware scheduling strategy. This post is a teardown of exactly what we did — not a tutorial on nRF SDK APIs, but the reasoning, the measurements, and the trade-offs we actually lived through.

Before we dive into techniques, it's worth establishing why these two devices needed such different strategies despite both running on nRF52840.

The Golf Ball is in deep sleep for more than 99.9 % of its life. It needs to detect a strike event, record IMU data for the ball's flight arc, transmit via BLE, and go back to sleep — all in a few hundred milliseconds. The Wearable is the opposite: it needs to sustain 400 Hz IMU sampling across a full sprint or training session, with continuous BLE connection to a phone app. Two completely different firmware architectures, same silicon.

The nRF52840 ARM Cortex-M4 has three relevant low-power states. The SDK wraps these, but knowing what happens in hardware tells you exactly why certain choices crush battery life.

For the Golf Ball, we spend the vast majority of time in System ON with the CPU off, not System OFF. This sounds counterintuitive — System OFF is lower current on paper. The reason: waking from System OFF is effectively a cold boot. SoftDevice re-initialises, BLE advertising restarts, and you lose ~20 ms and ~6 mA·ms of charge on every wake. At strike frequency (maybe 50–100 strikes per round), that overhead is significant. System ON keeps the BLE stack warm in SoftDevice and lets us wake via IMU interrupt, capture data, and burst-transmit within ~140 ms — then return to sleep.

Calling sd_app_evt_wait() Correctly

In SoftDevice builds, you cannot call __WFE() directly — you use sd_app_evt_wait(). The SoftDevice schedules BLE events, releases control, and your application main loop calls this. What kills power here is spin-polling on a flag before calling wait. We saw this in one early build of the wearable scheduler: a 2-second interval timer flag was being polled with a while(!flag) loop. The nRF never entered low-power because the CPU was always executing. A simple callback-into-flag combined with sd_app_evt_wait() in the main loop dropped current by 780 µA in connected standby.

/* WRONG — CPU never sleeps */
while (!m_data_ready_flag) /* spin */
process_imu_data();

/* CORRECT — CPU enters WFI via SoftDevice */
while (true) {
    if (m_data_ready_flag) {
        m_data_ready_flag = false;
        process_imu_data();
    }
    uint32_t err = sd_app_evt_wait();
    APP_ERROR_CHECK(err);
}

The radio is by far the heaviest consumer on the nRF52840 — 5.3 mA in TX at 0 dBm, 4.6 mA in RX. Every millisecond of unnecessary radio-on time directly eats into your battery. On both devices we attacked this differently.

Golf Ball — Advertising Interval Strategy

The Golf Ball does not maintain a persistent BLE connection. Instead, after a strike event, it enters a fast-advertising window (100 ms interval) for 5 seconds, then drops to a slow-advertising window (1 s interval) for 25 seconds, then goes back to sleep if no connection is made. This is the standard tiered approach, but the numbers matter enormously at CR2032 scale.

The key architectural insight: we do not advertise at all when no strike has occurred. The ball is completely silent. A phone app that wants to find the ball must be patient — it only shows up after a strike. This was a UX decision as much as a power decision, and it's why the 18-month battery life is achievable.

Wearable — Connection Parameter Negotiation

The Sports Wearable maintains a continuous connection during a training session. The critical parameter here is the BLE connection interval. A short interval means more radio wake-ups; a long interval increases latency. We targeted a 20 ms connection interval during active recording (needed for 400 Hz IMU → real-time display on phone) and negotiated a 500 ms interval during idle standby between sets.

Connection interval negotiation happens via sd_ble_gap_conn_param_update(). The phone can reject the request and suggest different values — so your firmware needs to handle the negotiation callback and work with whatever the central offers. On iOS this is particularly important because iOS BLE stack has its own preferences and will often push back on aggressive intervals below 15 ms.

Below is the complete checklist we run through on every nRF project before declaring a battery-life target. The order matters — tackle the biggest current contributors first, measure after every change.