Bluetooth Dropout Losing VBT Reps Mid-Set: How to Diagnose and Fix It

A lifter racks six back squats. The app's live counter reads six. Back at the laptop, the session export shows four. Reps two and five are gone - no velocity, no bar path, just a timestamp gap. Once, it's a fluke. Two or three times a week, on the same rack, it's a signal - and most coaches chase the wrong fix first: firmware update, factory reset, new phone. Half the time none of that touches the real problem, because 'Bluetooth dropped a rep' isn't one failure. It's at least three, and each needs a different fix.

This matters because a velocity-based program decides off whatever data a dropped rep leaves behind. If rep two was the fastest of the set and it silently vanishes, peak velocity, average velocity and velocity loss percentage - the numbers deciding whether the next set loads up or gets cut short - all get computed from a partial, unflagged set. The fix isn't just getting Bluetooth to behave. It's knowing, every time a gap shows up, whether the missing reps are trustworthy noise or a reason to throw the set out.

Bluetooth Low Energy (BLE), the protocol nearly every VBT sensor uses to talk to a phone, doesn't fail as one on/off switch. It degrades along three independent axes. Interference is another radio - a second athlete's sensor, a phone hotspot, a speaker, a busy Wi-Fi router - sharing the 2.4 GHz band and stepping on the sensor's packets mid-transmit. Distance/line-of-sight loss is the phone too far from the sensor, or a body, a rack upright, or a plate stack between them, attenuating signal below the noise floor. Buffering is internal to the connection: BLE exchanges data on a negotiated interval, and if a rep's data arrives while the radio is mid-buffer or the stack is busy with the prior packet, the sample gets queued, corrupted, or silently dropped even with a perfect signal.

Bluetooth and Wi-Fi share the unlicensed 2.4 GHz band, and a gym is rarely quiet on it: headphones, other athletes' VBT sensors, a smart speaker, the Wi-Fi access point all compete for the same spectrum. Golmie, Van Dyck and Soltanian (2001, ACM MSWiM, later Wireless Networks) simulated coexistence between classic Bluetooth and 802.11b Wi-Fi. Their models showed Bluetooth packet and frame error rates staying under roughly 5% once an actively transmitting Wi-Fi device sat 8-10 meters away on a non-overlapping channel, but climbing past 50% in heavier-traffic scenarios once that device closed to within a couple of meters on an overlapping channel while transmitting continuously. The limitation worth flagging: this simulated classic Bluetooth and older 802.11b hardware, before adaptive frequency hopping became standard, so exact percentages won't reproduce on a modern BLE sensor and Wi-Fi 6 router. What transfers is the shape of the relationship - proximity and channel overlap drive packet loss up sharply, and it's a nonlinear jump, not a gradual slope.

The practical version: rep drops that worsen specifically when a device is active nearby - a Bluetooth playlist starts, a second lifter's sensor connects, the gym Wi-Fi runs a firmware check - point at interference. The isolation test above confirms it fastest: move to an empty room and repeat the set; if the drop rate falls near zero, the surrounding electronics are the problem, not the sensor or app.

BLE sensors used for VBT are almost always Class 2 radios, rated for a nominal open-air range around 10 meters - but that assumes clear line of sight. A rack upright, a loaded barbell, or the lifter's own torso between the sensor and a phone several meters away pushes effective range well under the rated figure, since tissue and steel both attenuate 2.4 GHz signal far more than open air. The signature is distinct from interference: it correlates with a fixed physical layout rather than other devices being active, so it shows up reliably on the same far-side rack, session after session, regardless of what else is happening in the room.

The fix is usually simpler than it looks. Keep the logging device within 2-3 meters of the sensor with clear line of sight for the whole working set, not just at pairing - some apps verify signal strength once, at connection, and never flag it when the lifter walks the phone away afterward. If the layout genuinely needs more distance, a Class 1 BLE extender or relaying through a phone clipped to the rack itself closes the gap without touching the sensor.

The third failure mode has nothing to do with signal strength and everything to do with timing inside the BLE stack. Every BLE connection negotiates a connection interval - typically 7.5 milliseconds to 4 seconds - at which the phone and sensor actually exchange data. Siekkinen, Hiienkari, Nurminen and Nieminen (2012, IEEE WCNC Workshops) measured real BLE 4.0 hardware across connection-interval settings and found a direct trade-off: shorter intervals cut latency and queued data but keep the radio active more of the time; longer intervals save power dramatically but force more samples to accumulate per exchange, so a single lost packet at a long interval takes a larger, more contiguous block of samples down with it rather than one isolated point. Their limitation: measured on one era of BLE chipset in controlled conditions, not a busy gym with concurrent high-motion sensor traffic, so it establishes the mechanism rather than exact numbers for a specific sensor today.

The tell for buffering is that it survives the isolation test: phone right next to the sensor in an empty room, and drops still show up at a consistent point - right after the first rep, during the handshake, or after a rest pause longer than the connection tolerates. That means the fix is software: use a shorter connection-interval or 'high performance mode' setting if the app exposes one, confirm app and firmware are matching, current versions (a mismatch is a common source of buffer bugs), and avoid running other Bluetooth-heavy apps on the same phone, since its BLE stack is shared across every connection it juggles.

Once a set has already dropped reps, the question shifts from cause to consequence: can these numbers be trusted, or does the set need discarding and rerunning? Run this checklist before entering it into a training log.

1. Pull the raw export, not the summary card. Most apps compute peak, average and loss velocity from whatever reps landed, without flagging what's missing. Export as CSV or JSON and check the rep index or timestamp sequence directly.
2. Identify the gap type. A missing rep number in an otherwise continuous sequence (1, 3, 4, 6 - 2 and 5 absent) is a true drop. A rep with an implausible velocity or a timestamp identical to the prior rep is corrupted, not missing - arguably worse, since it passes a check that only looks for gaps.
3. Check where the gap falls. A drop on the last rep of a fatigue-based set invalidates it for velocity-loss purposes, since the metric depends on the final rep's decline. A drop on an early, submaximal rep matters far less to peak- or average-velocity readings.
4. Apply a threshold, not a blanket rule. Working standard: fewer than 15% of reps missing from a set of 5+, none in the final third, can usually be logged with a note. Beyond that, or any drop in the final third of a velocity-loss set, discard the derived metrics and rerun - never interpolate a missing rep's value from its neighbors, since it carries no fixed relationship to the reps around it.
5. Tag the set at logging, not after. A partial set merged into history as if complete corrupts every downstream comparison built on it - week-over-week trends, autoregulated load decisions. Flag it partial the same session it happened.

Most recurring dropout traces back to a short list of setup habits, not a defective sensor. Before blaming the hardware: keep the logging phone within 2-3 meters of the sensor with clear line of sight for the whole set, not just at pairing; move away from other active Bluetooth sources - a second lifter's sensor nearby, a speaker, a phone streaming over BLE; close other Bluetooth-connected apps so the phone's stack isn't juggling multiple connections; keep sensor firmware and app version matched and current, since a mismatch is a common source of buffer bugs; and charge the sensor fully, since a battery below roughly 15-20% is an easily overlooked cause of instability that looks identical to interference.

A lifter runs a six-rep velocity-loss squat set. The summary card shows average velocity 0.58 m/s and velocity loss 22%. The raw export tells a different story once the rep index is checked against timestamps.

The gap at rep 3 shows a timestamp interval double the spacing at rep 4 - a single missed exchange, not a full disconnect, consistent with buffering or brief interference rather than distance, since nothing in the layout changed mid-set. More important: the 22% loss silently used rep 6 as the endpoint, but rep 6 reads faster than rep 5 late in a fatiguing set - an unusual pattern that deserves a second look before being trusted as the true final-rep value. One missing rep out of six is within the 15% allowance, but because the questionable value falls in the final third of a velocity-loss set, the right call is to flag the set unreliable for that purpose, not log 22% as clean.