Smartwatch / fitness tracker

The interesting wearable is not an Apple Watch Ultra (Cortex-A class, runs a real OS, 1-day battery). It's the week-long-battery segment: Garmin Forerunner, Fitbit Charge, Whoop, low-end Amazfit, Polar — devices that run for a week or more on a tiny battery by being aggressively power-managed Cortex-M designs.

At a glance

The dual-core architecture that makes this work

The defining trick of modern wearable SoCs is two Cortex-M33 cores in one chip, with separate flash/RAM and a hardware mailbox between them:

The application core runs your firmware. The network core runs the BLE controller as a precompiled binary (Nordic ships it as nrf5340_netcore_softdevice.hex). Inter-core communication uses IPC (a shared-memory mailbox) — your app pushes a "send packet" request, the network core handles all the timing-critical BLE link-layer work, and the radio gets serviced with microsecond latency that would never survive an RTOS context switch on a single core.

This is the same architectural pattern as a Wi-Fi router (control plane on Linux, MAC plane on dedicated MCU) but at a fraction of the size and power.

The power story

A 200 mAh Li-Po battery has ~0.7 Wh of energy. To last 14 days, the average power draw must be:

0.7 Wh × 3600 s/Wh = 2520 J
2520 J / (14 days × 86400 s/day) = 2.08 mW average

At 3.0 V, that's 0.7 mA average. Yet the SoC alone draws 5+ mA in active mode. The math only works because the SoC sleeps 99%+ of the time.

Typical duty cycle:

Wake every 1 second for HR sample:
   200 µs wake-up
   2 ms ADC + HR algorithm
   500 µs back to sleep
   ── 2.7 ms active per second = 0.27% duty cycle
 
Wake on motion (acceleration > threshold) every ~30 s:
   adds ~5 ms × ~2× per minute = trivial
 
BLE advertising every 1 s:
   ~3 ms radio TX at 4 mA
   ── ~12 µC per second
 
Sleep current: ~3 µA (RAM retained, RTC running, SOC in System ON)

Average: ~30 µA × 95% sleep + 5 mA × 5% wake ≈ 0.28 mA. Within budget. Add a 5-minute workout once a day with continuous HR + accelerometer at 25 Hz and BLE streaming → ~10 mA average for that 5 minutes → still under budget for 14 days.

Sensor stack

The "smart" in smartwatch is mostly sensor fusion:

   ┌─────────────────┐
   │ Accelerometer   │   3-axis, ±16g, 25-200 Hz
   │ (LSM6DSO, etc.) │   I²C/SPI
   └────────┬────────┘
   ┌────────┴────────┐
   │ Gyroscope       │   3-axis, ±2000 dps
   └────────┬────────┘
            │
   ┌────────┴────────┐
   │ Magnetometer    │   compass heading
   │ (LIS3MDL, etc.) │
   └────────┬────────┘
            ▼
   ┌─────────────────┐
   │ Sensor fusion   │   typically a Mahony or Madgwick filter
   │ (on Cortex-M33) │   running at 50–200 Hz on the app core
   └────────┬────────┘
            ▼
   ┌─────────────────┐
   │ Activity classifier ──→ "walking", "running", "cycling", ...
   │ (often DSP+ML)   │
   └─────────────────┘

The fusion typically lives in a periodically-scheduled task that grabs raw IMU data via DMA, runs ~50 multiplies of a Mahony filter, updates orientation/heading state, and re-sleeps. Total CPU cost: < 1% of the M33 at 64 MHz.

Optical heart rate (PPG) is its own little world: a green LED pulses at the wrist, a photodiode reads the reflected light, signal processing extracts the AC component (blood flow) from the much-larger DC component (tissue reflectance). Vendors keep this code proprietary because it's the dominant feature differentiator.

Software stack

Most non-Apple/Google wearables use Zephyr (Nordic-pushed) or FreeRTOS (everyone else). Lifecycle:

power on → bootloader (MCUboot) → app image → main()
                                                │
                                                ▼
                                  ┌───────────────────────────┐
                                  │ Init Zephyr / FreeRTOS    │
                                  │ Start BLE host stack       │
                                  │ Start IMU sensor thread    │
                                  │ Start UI thread            │
                                  │ Start sync thread          │
                                  │ Start sensor-fusion task   │
                                  └───────────────────────────┘
                                                │
                                                ▼
                                       Run forever in tickless idle
                                       with WFI between events

MCUboot is the standard secondary bootloader. It supports A/B image slots, signed updates, swap-on-test rollback. Critical for OTA firmware updates pushed via BLE.

BLE GATT services are the wire protocol your phone talks. A typical fitness tracker exposes:

• Heart Rate Service (0x180D) — standard SIG profile
• Battery Service (0x180F) — standard SIG
• Device Information Service (0x180A) — model, serial, firmware
• Current Time Service (0x1805) — phone sets the watch's clock
• Vendor service (random UUID) — proprietary data sync, raw sensor streaming

When you pair via the manufacturer's app, the app discovers these services and reads/writes characteristics. No mystical magic — just BLE.

Real products

Apple Watch (S9 SoC = Cortex-A class), most Wear OS watches (Snapdragon W5 = Cortex-A7), and Galaxy Watch (Exynos W930) are a different category — they run a real OS, recharge daily, and don't belong in this analysis.

See also

• Cortex-M33 / M23 — the application core.
• TrustZone — used for secure boot + key storage in wearables.
• Nordic Semiconductor — the dominant SoC vendor in this segment.
• Zephyr — the typical RTOS choice.
• USB — for charging cradles and sync.