How Disposable Medical Wearables Use BLE: From CGMs to ECG Patches

Inside the Bluetooth designs powering single-use glucose monitors and ECG patches

A 14-day disposable patch has roughly 220 mAh to spend. The BLE radio will eat half of it before your sensor takes its first sample. If you’ve ever wondered why two CGMs from competing vendors look identical on the outside but behave completely differently on the air, the answer lives in the connection interval, the GATT topology, and one architectural decision most teams make by default: trusting the patient’s phone to be a reliable gateway.

This is a playbook for the firmware and systems engineers designing disposable medical BLE devices, the kind that ship sealed, run for 7 to 14 days, and never get charged. We’ll work through the three constraints that drive every other decision: energy, GATT design, and gateway reliability. Concrete numbers, vendor-neutral, with FDA-cleared CGMs and ECG patches as design anchors.

A note on numbers cited from shipping products: treat them as publicly observed behavior, not gospel. If precision matters for your design, verify against the current 510(k) summaries.

1. The Power Budget Reality

A CR2032 gives you about 220 mAh at room temperature, less in cold storage and toward end-of-life. Printed batteries can be smaller. Whatever you’ve got, the radio is the dominant load.

Energy Budget (CR2032, 220 mAh, 14 days)
─────────────────────────────────────────
Total available:       ~650 µA average
  Sensor + AFE:        ~150 µA
  MCU active/sleep:    ~80 µA
  BLE radio:           ~300 µA  ← biggest lever
  Margin/leakage:      ~120 µA

A few rules of thumb worth memorizing:

  • Connection interval is the single biggest knob. Going from 100 ms to 1 s cuts radio duty cycle by roughly 5 to 10x depending on event length. If you’re not streaming, you shouldn’t be at 100 ms.
  • 2M PHY costs less energy per bit than 1M. The radio is on for half the time to move the same payload. Use it when both ends support it.
  • Coded PHY (S=8) buys range at a 4x energy cost per bit. Almost never the right call for a body-worn disposable that lives 30 cm from a phone.
  • TX power: +0 dBm is the sweet spot. Going to +4 dBm roughly doubles peak current. Going to -8 dBm saves less than you’d hope because the radio still has to ramp.

Target somewhere under 50 µA average for a comfortable 14-day life with margin. If you can’t get there, you’re either over-sampling or over-transmitting.

2. Connection Intervals & Advertising Strategy

CGMs and ECG patches sit at opposite ends of the BLE timing spectrum.

A CGM produces a small reading every 1 to 5 minutes. Publicly documented behavior of devices like the Dexcom G7 and Abbott Libre 3 suggests advertising intervals in the 1 to 2 second range with brief connection windows when the phone is nearby. The radio is essentially off most of the time. The device buffers readings locally (8+ hours of capacity is typical) so a missed connection isn’t a missed reading.

An ECG patch like the iRhythm Zio or a Vital Connect VitalPatch has a different problem: many kilobytes per second when streaming. During an upload, you want a short connection interval (50 to 200 ms), 2M PHY, and the largest MTU you can negotiate. When not streaming, the device drops back to slow advertising.

Two underused tools:

  • Slave latency lets the peripheral skip empty connection events. Pair it with a longer interval to keep responsiveness while sleeping through most slots.
  • Directed advertising for fast reconnect to a known central, falling back to undirected after a few hundred ms. Saves the central’s scan time and the peripheral’s radio time.
1s interval, slave latency 4:
|CE|----|----|----|----|CE|----|----|----|----|CE|
 ↑                       ↑                       ↑
 actual radio events (every 5s effective)

3. GATT Design for Intermittent Connectivity

Design for the disconnected case. Connections are the exception, not the rule.

Most shipping CGMs use vendor-custom services rather than the Bluetooth SIG’s CGM Service (0x181F). The standard profiles assume a connection model that doesn’t match how disposables actually behave, so a custom service over a standardized profile is usually the right call.

Notifications beat indications here. Indications add a GATT-layer ACK that costs you a round trip per record. Skip it, run reliability at the application layer with sequence numbers and CRCs, and let the cloud deduplicate. The advertising packet format and BLE design notes in the Hubble device SDK follow a similar pattern: assume the link is lossy, build idempotency above it.

The flash-buffer-and-replay loop is what makes everything else work. Each sample lands in a flash ring buffer as a sequence-numbered, CRC’d record. On reconnect, the device replays everything since the last ACKed sequence number; the gateway sends back a high-water mark, and the device frees the flash.

A few smaller calls worth getting right:

  • Negotiate MTU early, request 247 bytes. Fragmentation kills throughput on big payloads. Do it in the first few hundred ms after connection.
  • Bonding. LESC pairing with keys stored in OTP or write-protected flash. For single-use disposables, key rotation isn’t a thing, so make provisioning bulletproof at the factory.
  • Skip OTA. A disposable that’s going in the trash in 14 days doesn’t need a 60 KB DFU bootloader stealing flash and adding attack surface. Keep a documented path for a security patch if regulators ask, but don’t ship the runtime.

4. Two Anchor Examples

CGMs (Dexcom G7, Abbott Libre 3 family). Small payload, perhaps 20 bytes per reading, every 1 to 5 minutes. Optimized for an always-paired phone but tolerant of multi-hour gaps. Encryption typically lives at the application layer in addition to BLE LE Secure Connections, because the threat model includes a malicious central. Pairing flow is designed to be one-shot at sensor start, with the patient never touching it again.

ECG patches (iRhythm Zio, BardyDx CAM, Vital Connect). Multi-day continuous ECG stored locally on the patch. Some products are mail-back: no realtime BLE at all, the device gets opened in a lab. Others stream on demand or in scheduled bursts. The design lesson is to decouple sampling from transmission. Sample at the rate clinical requirements demand, transmit at the rate the radio budget allows, and let flash absorb the difference.

This decoupling is the generalizable rule across CGM BLE, ECG patch Bluetooth, and every other disposable category I’ve seen. Your sensor cadence and your radio cadence are independent design variables.

5. The Gateway Problem

Here’s the part of medical wearable connectivity that engineers tend to discover late: the patient’s phone is the weakest link in the chain, and it’s the link you control least.

What goes wrong:

  • iOS background BLE constraints. If the companion app gets killed, scanning behavior changes.
  • Android Doze and background scan throttling, especially post-Android 8.
  • Patients uninstall apps. Patients turn on airplane mode. Patients let phones die.
  • OS upgrades occasionally break pairing or change permission models mid-study.

Clinical literature on remote monitoring has reported data loss in the 10 to 30% range attributable to smartphone gateway issues, depending on study population and protocol. The exact numbers vary by paper and you should check current sources for your specific use case, but the order of magnitude is consistent enough to plan around.

Mitigation tiers:

Tier         | Gateway          | Loss Rate | Cost/unit
─────────────┼──────────────────┼───────────┼──────────
1            | Patient phone    | 10–30%    | $0
2            | Dedicated hub    | <2%       | $40–80
3            | Networked GW svc | <2%       | varies

Tier 1 is free and adequate for low-acuity wellness. Tier 2 (a cellular hub shipped with the device) is what most high-acuity remote monitoring programs end up doing, at real BOM and reverse-logistics cost. Tier 3 is a networked gateway service that opportunistically picks up your device’s advertisements through third-party infrastructure already in the field, with no patient phone required.

Hubble runs one such network, using existing devices in the field as receivers for BLE advertisements. It trades per-unit hardware cost for coverage dependence, and is worth evaluating as one option among the three rather than a default.

The decision rule is simple. If a missed reading has clinical consequence, don’t depend solely on the patient’s phone.

6. End-to-End Data Flow Checklist 

[Device]
  ├─ Sample → timestamp → CRC → flash ring buffer
  ├─ Advertise (connectable, 1–2s interval)
  └─ On connect: stream unsent records, await ACK, mark sent

[Gateway: phone OR dedicated]
  ├─ Scan/connect on schedule
  ├─ Forward records to cloud (with device-level auth)
  └─ Confirm receipt back to device

[Cloud]
  ├─ Deduplicate by (device_id, seq_num)
  ├─ Order by device timestamp, not arrival
  └─ Surface gaps to clinical workflow

If your design implements every line, intermittent connectivity becomes a latency problem, not a data-loss problem.

Challenge the Phone-as-Gateway Default

The three constraints stack: energy sets your radio budget, GATT topology determines whether you survive the disconnected hours, and gateway architecture decides whether your data ever reaches a clinician. BLE itself is solved silicon; the differentiation comes from how you handle the disconnected intervals.

If you’re starting a new disposable medical BLE program in 2025, challenge the inherited assumption that the patient’s smartphone will be the gateway. For low-acuity wellness, fine. For anything where missed data has clinical weight, that single design choice will determine more about your product’s reliability than any silicon decision you make.

Hubble Network provides direct-to-satellite BLE connectivity for medical wearables, eliminating the smartphone gateway dependency that drives most disconnected-data failures. See how it works →