Synchronizing Multiple BLE Sensors on Android: Timestamps, Drift, and Correction

DEVSFLOW Neuro · 2026

Multi-modal biosignal recording is becoming standard in neurotechnology research and consumer products. A typical setup might combine an EEG headset sampling at 250 Hz, an electrodermal activity (EDA) sensor at 4 Hz, and a heart rate monitor delivering RR intervals at irregular timing. Each device has its own clock, its own BLE connection, and its own ideas about when things happened. Getting these streams aligned to within a few milliseconds on an Android phone is a real engineering problem with no turnkey solution.

This post covers the synchronization challenges we have solved at DEVSFLOW for multi-sensor recording setups, including the specific clock drift characteristics of common BLE chipsets, practical alignment strategies, and the jitter correction techniques that make the difference between research-grade and toy-grade data.

Why Clock Drift Is a Bigger Problem Than You Think

Every BLE peripheral has its own crystal oscillator driving its clock. Consumer-grade 32.768 kHz crystals used in most wearable designs have a tolerance of +/- 20 ppm (parts per million). That translates to roughly +/- 1.7 seconds of drift per day, or about 1.2 milliseconds per minute. Over a 30-minute recording session, two peripherals can drift apart by up to 72 milliseconds if they are at opposite ends of their tolerance range.

For EEG event-related potential (ERP) analysis, temporal accuracy of 1 to 2 milliseconds is needed. For EEG-EDA correlation studies, 50 milliseconds is often acceptable. For EEG-HR coupling analysis, 10 milliseconds is a reasonable target. Your synchronization strategy needs to be designed for the tightest requirement in your multi-modal pipeline.

Temperature makes drift worse. A sensor strapped to a wrist in a warm room drifts differently from one sitting on hair-covered scalp. The temperature coefficient of a typical tuning fork crystal is roughly -0.035 ppm per degree Celsius squared, referenced to the turnover temperature of about 25 degrees Celsius. In practice, this means body-worn sensors drift more than bench-test conditions suggest.

Timestamp Architecture: Phone Clock as the Reference

The fundamental architectural decision is choosing your time reference. You have three options: use one peripheral's clock as the master, use the phone's clock, or use an external time server (NTP). For mobile biosignal recording, the phone's monotonic clock is the right choice.

On Android, use SystemClock.elapsedRealtimeNanos() as your reference. This clock is monotonic (it never jumps backward), it counts during deep sleep, and it is not affected by wall-clock adjustments from NTP or the user changing the time zone. Do not use System.currentTimeMillis(), which can jump forward or backward when the network time sync kicks in, creating apparent gaps or overlaps in your data.

Stamp every incoming BLE notification with elapsedRealtimeNanos() at the earliest possible point: inside the onCharacteristicChanged callback, before any processing. This gives you a phone-clock arrival timestamp for every packet from every sensor.

Why Not NTP?

NTP synchronization gives you wall-clock accuracy of 5 to 50 milliseconds over the internet, depending on network conditions. It is useful for aligning recordings that happen on different phones, but it is not useful for aligning streams within a single phone session. The phone's monotonic clock is already the best time source available locally, and adding NTP synchronization to the inter-sensor alignment problem introduces complexity without improving accuracy.

Use NTP only when you need to correlate a mobile recording with data collected on a separate system, such as a lab computer or another mobile device. In that case, record both the monotonic timestamp and the NTP-synced wall-clock time, and perform the cross-device alignment offline.

Handling BLE Notification Jitter

The arrival time of a BLE notification on Android is not the time the sample was captured on the sensor. Between the ADC sampling instant and your onCharacteristicChanged callback, several variable-latency stages intervene: the peripheral's BLE stack queuing the notification for the next connection event, the over-the-air transmission, the Android Bluetooth HAL receiving and buffering the packet, and the Binder IPC delivering the callback to your app.

In our measurements across multiple Android devices, the jitter between sample capture and callback delivery ranges from 7.5 milliseconds to 45 milliseconds, with a typical standard deviation of 5 to 12 milliseconds. This jitter is not random noise. It has structure: it correlates with the BLE connection interval, the number of active BLE connections, and whether Wi-Fi is actively transmitting.

To remove this jitter, you need the peripheral to include its own timestamp in the packet payload. If the peripheral embeds a counter or timestamp from its local clock, you can reconstruct the original sample timing on the phone side. The phone-clock arrival timestamps then serve only to establish the initial offset between the peripheral's clock and the phone's clock, not to time individual samples.

The Synchronization Algorithm

Our synchronization pipeline has four stages:

1. Initial offset estimation. When each peripheral first connects and starts sending data, use the first 10 packets to estimate the offset between the peripheral's clock and the phone's monotonic clock. Take the minimum (not mean) of the arrival-time-minus-peripheral-timestamp differences. The minimum is the best estimate because jitter only adds delay, never subtracts it.
2. Drift estimation. After 60 seconds of data, compute a linear regression of phone arrival timestamps against peripheral timestamps. The slope of this line gives you the relative clock rate. A slope of 1.00002 means the peripheral's clock runs 20 ppm fast relative to the phone.
3. Continuous correction. Apply the estimated offset and drift rate to convert every peripheral timestamp to phone-clock time. Update the drift estimate every 60 seconds using a sliding window of the last 5 minutes of data. This handles temperature-induced drift changes.
4. Cross-stream alignment. Once all peripheral timestamps are expressed in phone-clock time, resample slower streams (EDA at 4 Hz, HR at variable rate) to align with the fastest stream (EEG at 250 Hz) using linear interpolation for continuous signals or nearest-neighbor assignment for event-based signals like R-peaks.

Real-World Example: EEG + EDA + HR

Here is how this plays out with a concrete sensor configuration we have deployed: a Muse 2 EEG headset (256 Hz, BLE notification every 48 ms containing 12 samples), an Empatica E4 wristband providing EDA at 4 Hz and BVP (blood volume pulse) at 64 Hz, and a Polar H10 chest strap providing RR intervals via the Heart Rate Measurement characteristic.

The Muse sends timestamps as a 16-bit sample counter that wraps every 256 seconds. The E4 sends Unix timestamps with millisecond resolution. The Polar H10 sends cumulative RR intervals in 1/1024-second units. Three completely different time representations that need to be unified.

For the Muse, we convert the sample counter to microseconds using the known 256 Hz sample rate and handle the 16-bit wrap by detecting backward jumps. For the E4, we convert its Unix timestamps to phone-relative time by subtracting the initial offset. For the Polar, we reconstruct beat timestamps by cumulatively summing RR intervals from a known start time.

After applying drift correction, the three streams align to within +/- 4 milliseconds over a 30-minute session. Without drift correction, the Muse and E4 diverge by roughly 25 milliseconds over the same period, which is enough to corrupt ERP-EDA correlation analysis.

Android-Specific Pitfalls

Several Android behaviors can sabotage your synchronization:

• When Android's Bluetooth stack manages multiple simultaneous connections, it time-division multiplexes the connections across the radio. This means adding a third BLE sensor can increase jitter on the first two. If you see jitter jump when connecting additional sensors, request CONNECTION_PRIORITY_HIGH on all connections and verify that connection intervals are not being stretched.
• elapsedRealtimeNanos() can stall briefly on some MediaTek-based devices during deep sleep transitions. If your app records during screen-off periods, validate that the monotonic clock does not show gaps by cross-checking with SystemClock.uptimeMillis() and flagging any discrepancies greater than 50 milliseconds.
• Doze mode can batch BLE notifications, delivering a burst of delayed packets when the device briefly wakes. Your drift estimation must be robust to these bursts. Discard any packet whose arrival jitter exceeds 3 standard deviations from the running mean when updating your drift estimate.

Validating Synchronization Quality

You need a way to verify that your synchronization is actually working. The simplest approach: generate a simultaneous event that appears in all sensor streams. For EEG + HR, a sudden loud clap produces both an auditory ERP in the EEG and a heart rate acceleration visible in RR intervals. For EEG + EDA, a deep breath produces both a frontal EEG change and an electrodermal response with known latency (1 to 3 seconds).

Build this validation into your test suite. Record a 5-minute multi-sensor session with 3 stimulus events, then verify that cross-stream event alignment is within your target accuracy. We run this test on every build that touches the synchronization pipeline.