The platform connects to dynamometers directly through the browser using Web Bluetooth, so most pairing problems are browser-and-device problems rather than platform problems. The troubleshooting flow below is organized by symptom (what's happening on your screen and on the device) rather than by which dynamometer you have, because the same handful of root causes account for most of the issues across every supported device.
Before working through the symptoms: this assumes you're on a browser that supports Web Bluetooth (current Chrome, Edge, or Opera, on desktop or Android), and that you've granted the browser permission to access Bluetooth devices. Safari and Firefox do not support Web Bluetooth as of writing; the device picker will not find anything in those browsers.
Device is on but the picker doesn't find it
The picker scans for nearby BLE devices that advertise themselves. If the device is powered on but doesn't appear:
- Wait five to ten seconds. Some devices advertise on a slow interval and don't appear on the first scan refresh. Hit refresh once or twice with brief pauses between.
- Check the device is in advertising mode, not connected. Most BLE dynamometers stop advertising once they're connected to a host. If you connected the device to a manufacturer app (for example, a phone app from the device vendor) on the same phone or laptop, that app may hold the connection and the platform's picker will not see the device. Quit the other app and try again.
- Move closer. Web Bluetooth doesn't pair through walls reliably. A device 15 feet away through a door often doesn't appear; the same device three feet away on the same desk usually does.
- Power-cycle the device. Off, count to five, on. This clears any half-connected state from a prior session.
- Refresh the page. The browser's Bluetooth permission state can desynchronize after a disconnect. A page refresh resets that.
If none of the above works, the issue is usually one layer down: the browser itself isn't seeing any BLE peripherals. Open chrome://bluetooth-internals (or the equivalent in your browser) and check whether any devices are visible there. If the browser-level Bluetooth panel is empty too, the issue is the operating system's Bluetooth stack rather than the platform or the device.
Device pairs, then drops a few seconds later
The browser-to-device handshake completes but the connection drops shortly after. Common causes:
- The device's battery is low. Many BLE dynamometers complete pairing on whatever power they have, then drop the connection when the radio's transmit current exceeds what the battery can supply. Charge the device fully and retry.
- Another host is competing for the connection. Same root cause as the picker-not-finding-device case: a phone or laptop that the device was previously paired with may try to reconnect automatically when the device comes into range. The reconnect attempt collides with your new pairing. Unpair the device from the other host through that host's Bluetooth settings.
- The device has firmware that drops idle connections. Some firmware versions disconnect after a few seconds of no data being sent or received. Starting a capture immediately after pairing (before the idle timeout fires) usually avoids this. If it happens consistently within the same time window after each pair, the cause is almost always an idle timeout.
Device auto-shut-off between sets
Some devices (notably the Tindeq Progressor) power themselves off after a fixed period of inactivity, typically around ten minutes. This is a feature, not a bug; it's how the device protects battery life. The platform handles the disconnect cleanly: the BLE connection drops on the platform side when the device powers off, and the next pairing attempt is treated as a fresh connection.
If a long inter-set rest pushes you past the auto-shutoff window:
- Pair again from the picker. No need to reconfigure the assessment; the platform preserves the protocol state across the pairing change. The session-in-progress doesn't get a new ID, the trials you already captured stay on it, and you can resume capturing where you left off.
- For protocols that involve long planned rests (between-limb switching with patient repositioning, multi-joint assessments with break time), consider re-pairing proactively just before the next set rather than discovering the disconnect when you hit start.
Pairing seems fine but the trace is flat or pinned
The device is connected, the chart is running, but the force trace doesn't move when the patient pushes:
- The device may be in the wrong mode. Some devices have separate modes for tension (pulling through a strap) vs compression (pushing on a pad), or have a calibration mode that doesn't stream live data. Check the device's display for a mode indicator.
- The device may need a tare. A few devices won't report changes below a calibration threshold until they've been tared after power-on. See taring the dynamometer and what a good baseline looks like for the broader baseline conversation.
- The strap may not be transmitting load to the gauge. If the strap is rigged so the gauge isn't in the load path (a common mistake when adapting a generic strap to a specific dynamometer), the gauge sees zero force regardless of how hard the patient pushes. Wiggle the strap to confirm a small load appears on the trace; if it doesn't, the rig needs adjustment.
The session ended but it's not on the patient's record
This isn't a pairing issue but it's the third-most-common "something went wrong" report:
- The session is saved when you end it, not while it's recording. If the browser tab closed, crashed, or lost network connection mid-recording, the in-progress trial may not have been saved. The platform's data flow saves the session document on session end.
- The session is scoped to the active patient at the moment of save. If you switched patients mid-session, the session may be on the patient who was active when you hit end, not the patient who was active when you hit start. Check the active-patient bar at the time of recording.
What to do next
- Power-cycle the device before you call it broken. Most BLE pairing issues are resolved by the off-on cycle on the device side.
- Use the same browser for the same device every time. Browser-level Bluetooth permissions are per-origin, and switching browsers means re-establishing them.
- Keep one charging cable per device station. Battery-related pairing failures are the most preventable category, and they're invisible until the connection drops.
- If repeat issues persist with a single device, document the firmware version. Some pairing issues are device-firmware-version specific, and that information is what a manufacturer support request needs.