Streaming sensors over BLE: packets, fragmentation and flow

A handwriting pen is, from the radio's point of view, a demanding little device. It produces a steady, high-rate stream of sensor numbers and has to ship every one of them, in order, over a wireless link that was never designed for that job.

BLE was built for sips, not streams

Bluetooth Low Energy earns the "low energy" in its name by being frugal. It was conceived for devices that send a sip of data now and then, a heart-rate reading, a temperature, a button press, and then sleep. Its defaults reflect that: the basic data unit (the ATT MTU) is just 23 bytes, of which only about 20 carry payload, and the radio wakes to exchange data only once per connection interval, which can be milliseconds to tens of milliseconds apart.

Now point that at a pen sampling multiple sensors, accelerometers, gyroscopes, a magnetometer, a force sensor, hundreds of times per second. Each sample is many bytes. Naively sending one sensor reading per 20-byte packet would overflow the link almost immediately. Streaming over BLE is, fundamentally, an exercise in fitting a firehose through a straw, gracefully.

Packetising the IMU firehose

The first move is to stop wasting packets. Instead of one reading per packet, the firmware batches several samples together and sends them as one payload. Two techniques make each packet count:

• Negotiate a larger MTU. Modern BLE can raise the MTU well above the default (commonly up to 247 bytes), so a single notification carries far more than 20 bytes, dramatically cutting per-packet overhead.
• Pack tightly. Samples are encoded compactly, fixed-width fields, sometimes delta-encoding values that change little between samples, so more readings fit in the same space.

Each packet also carries a small header: a sequence number and a timestamp reference. Those few bytes are what make the stream recoverable if anything goes wrong downstream.

MTU, fragmentation and ordering

Even a generous MTU has a ceiling, and a busy batch can exceed it. When a payload is larger than a single link-layer packet can hold, it gets fragmented, split across several radio packets and reassembled on the other side by the Bluetooth stack. Fragmentation is normal and handled for us, but it has consequences: a single lost fragment can spoil a whole batch, and under a congested radio environment, packets can arrive late or out of step with the connection interval.

This is where the humble sequence number earns its keep. Because every batch is numbered, the receiver can instantly tell if one is missing (a gap in the count), if a duplicate arrived, or if two batches landed out of order, and respond appropriately rather than silently corrupting the motion record.

Keeping the stream lossless and in time

A handwriting stream has to be both complete and correctly ordered, a sample dropped or shuffled at the wrong moment distorts a stroke. Several mechanisms keep it honest:

• Sequence numbers detect loss, duplication and reordering at the application layer.
• Buffering on the receiver absorbs the jitter of BLE's connection intervals, smoothing bursty arrivals back into a steady timeline before reconstruction.
• Timestamps let samples be placed back on an accurate time axis even if they arrive unevenly, which matters because velocity and rhythm depend on exact timing.
• Tuning the connection, a shorter connection interval and a larger MTU, raises throughput to match the pen's sample rate, trading a little battery for a lossless stream.

An interesting wrinkle: BLE's reliability and its low-energy goal pull in opposite directions. Push throughput too hard and you drain the battery; throttle it to save power and you risk dropping samples. Getting handwriting off the pen cleanly is largely about finding the sweet spot between those two, enough radio time to never lose a stroke, no more than necessary so the pen lasts the day.