BLE Connection Interval Tuning for Continuous Medical Monitoring Devices

Tuning BLE connection intervals for steady medical data streaming

Your ECG patch streams clean waveforms on the bench, runs 3 days on a coin cell, and reconnects every time you walk it across the lab. Pick two.

That’s the trap with continuous medical monitoring over BLE. Power, latency, and link reliability pull against each other, and the moment you tune one parameter in isolation you’ve quietly broken another. Shorten the connection interval to fix throughput and your battery life craters. Stretch the supervision timeout to stop nuisance disconnects and now a real link drop goes undetected for seconds, which is a problem when a clinician is watching that trace.

For consumer wearables these are preferences. For a device streaming ECG or SpO2, they’re constraints tied to data integrity and patient safety. This is a peripheral-side guide to tuning the three parameters that govern a ble connection interval medical link, anchored on what continuous ECG and SpO2 streaming actually demand. Numbers here are illustrative starting points. Validate every one against your silicon and your clinical requirements.

The Three Parameters and How They Interact

You’ve got three levers on the connection, and they’re coupled.

Connection interval sets how often the central and peripheral wake to exchange packets. Range is 7.5 ms to 4 s, in 1.25 ms steps. It’s the master lever. Shorter means lower latency and more connection events per second (higher throughput), but you’re waking the radio more often, so current draw climbs. Longer saves power and starves throughput.

Slave latency (peripheral latency) lets the peripheral skip up to N connection events when it has nothing to send. The catch: the instant you queue data, the peripheral wakes on the next event anyway. Latency saves power when the link is idle. It does almost nothing when you’re streaming, because you’re queuing data every single interval.

Supervision timeout is how long either side waits without a successful packet before declaring the link dead. The hard rule from the Core Spec:

timeout > interval × (1 + slaveLatency) × 2

If you set latency to 4 and a 30 ms interval, the effective worst-case gap between required events is 30 × (1 + 4) = 150 ms. Your timeout has to clear that with margin.

Parameter              Shorter/Lower →        Longer/Higher →
---------------------  ---------------------  ----------------------
Connection Interval    ↓latency ↑throughput   ↓power
                       ↑power                  ↑latency ↓throughput
Slave Latency          ↑responsiveness        ↓power (idle only)
                       ↑power                  delayed link-loss detect
Supervision Timeout    fast drop detection     tolerant of brief loss
                       false disconnects       slow fail-safe response

You don’t pick three numbers. You pick a streaming profile, then derive the numbers so they’re consistent.

Sizing the Interval for BLE Continuous Monitoring

Start from the clinical data rate, not the radio. Work backward.

Sustained throughput is sample_rate × resolution × channels. A diagnostic single-lead ECG at 500 Hz, 16-bit samples, one channel:

500 Hz × 16 bit × 1 = 8 kbit/s raw

That’s the floor before framing overhead, and before any second lead or SpO2 plethysmograph riding alongside. Multi-lead ECG at 12 channels pushes you near 100 kbit/s. SpO2 waveform data is lighter, often a few kbit/s, but the full pleth at 75–125 Hz adds up.

Now map that to packets per interval. With Data Length Extension you can move ~244 bytes of payload per packet, and a modern central will often grant several packets per connection event. Say you conservatively budget 1 packet of ~240 bytes per event for your stream. At a 30 ms interval that’s:

240 bytes × 8 / 0.030 s ≈ 64 kbit/s of headroom

Comfortable for single-lead, tight for 12-lead. The data rate sets a ceiling on how long your interval can be, and that ceiling is where power optimization stops. You can’t save battery past the interval your throughput floor allows.

Latency budget matters too. Real-time waveform on a bedside display wants end-to-end latency in the low tens of milliseconds, so you want a short interval (7.5–15 ms) and you eat the power cost. With buffered upload, data gets stored and shipped in chunks, so a longer interval is fine because nobody’s watching the trace live. Decide which mode you’re in before you touch the parameter.

Rough single-lead starting point: 15 ms interval, DLE on, 1 connection event per stream packet. Profile your actual current at that setting before you commit.

Applying Slave Latency Without Breaking Streaming

Here’s the part engineers get wrong. They set a non-zero slave latency to save power during streaming, then wonder why it does nothing.

During active medical ble streaming, you queue a packet every interval. The peripheral can’t skip events it has data for, so the effective latency is zero no matter what you configured. You’ve gained no power and added risk, because the configured latency still inflates your supervision timeout math.

While streaming, set slaveLatency = 0. Keep the interval short, keep the timeout tight, accept the current draw.

Slave latency earns its keep in idle and standby. Between monitoring sessions, or when the device is worn but quiet, you can skip most events and let the radio sleep. That’s where a latency of 2–4 cuts average current meaningfully.

The clean pattern is two states with a renegotiation between them:

  STREAMING STATE          IDLE/STANDBY STATE
  ----------------         ------------------
  interval:  7.5–15 ms     interval:  100–500 ms
  latency:   0             latency:   2–4
  timeout:   sized to      timeout:   sized to
             streaming                idle window
        |                        |
        +----- renegotiate ------+
              (Conn Param Update)

Fire a Connection Parameter Update when you cross between states. Don’t try to find one set of parameters that’s “good enough” for both. There isn’t one, and the compromise costs you battery in idle and latency in stream.

Setting a Fail-Safe Supervision Timeout

For a consumer device a missed disconnect is an annoyance. For a monitor, the link dropping silently means the clinical system thinks it has live data when it has nothing. The timeout is your fail-safe detection window.

Two things have to be true. The timeout must be long enough to ride out brief RF dropouts (a patient rolling over, walking past a microwave) without nuisance disconnects. And it has to be short enough that a genuine link loss is caught fast enough to alarm or fall back to a local buffer.

Work it with the streaming numbers. At 15 ms interval, latency 0:

interval × (1 + latency) × 2 = 15 × 1 × 2 = 30 ms  (absolute minimum)

You’d never run that tight, you’d flap on every glitch. A practical streaming timeout lands around 2–4 seconds. That clears the minimum by a wide margin and still detects a real drop inside a few seconds, usually inside the clinically acceptable window for “this trace just went away.” Confirm that window with your clinical and regulatory team; it’s a requirement, not an engineering preference.

Resist the urge to set a 10+ second timeout to make disconnects “go away.” All you’ve done is delay the moment the system notices the patient is no longer monitored. A masked disconnect is worse than a visible one.

In idle state, recompute. At 200 ms interval, latency 4:

200 × (1 + 4) × 2 = 2000 ms minimum

Your idle timeout needs to be well above 2 s. This is exactly why you renegotiate the full triple, not just the interval.

Negotiation Reality and Reporting Beyond the Gateway

You request parameters. The central decides. A phone, a hospital gateway, or an aggregator can reject or modify your requested interval, latency, and timeout, and many enforce their own minimums (iOS is famously opinionated here).

Treat your parameters as a proposal. Implement the Connection Parameter Update Procedure, read back what you were actually granted, and check it against your throughput and timeout requirements. If the granted interval is too long for your data rate, you need to know at runtime, not from a field complaint. Handle rejection: retry with a relaxed request, or flag that the link can’t sustain the clinical stream and let the application layer react.

BLE is only the first hop. When a device has to report beyond gateway and BLE range, the tuning strategy shifts, because the connection parameters only govern that first link; Hubble’s global BLE gateway network carries the data the rest of the way with no gateway hardware to deploy. If that’s your topology, design the BLE side as one leg of a longer path, and apply the same parameter discipline to that first link as you would to any medical IoT connectivity hop.

A Tuning Checklist You Can Run

Work it in this order, every time:

  1. Derive sustained throughput from sample_rate × resolution × channels, add framing overhead.
  2. Set the interval ceiling from that throughput; pick short (7.5–15 ms) for live waveforms, longer for buffered upload.
  3. Set slaveLatency = 0 while streaming; reserve non-zero latency for idle state.
  4. Size the supervision timeout against interval × (1 + latency) × 2, then pick a real value (2–4 s streaming) that detects a drop inside your clinical window.
  5. Renegotiate the full triple between streaming and idle states.
  6. Request parameters, read back what was granted, and handle rejection in firmware.

Every number here is a starting point. Profile current on your hardware, confirm latency and detection windows with your clinical requirements, and let the measurements set your final values.

Hubble Network keeps continuous monitoring devices connected at scale, so your tuned intervals hold up across the whole fleet—not just the bench. See how it works →