ForceIQ Device Interoperability Specification
Version 1.0, 17 August 2026
For force-measurement hardware manufacturers who want their device supported in ForceIQ.
What this document is
ForceIQ is a clinical analytics platform for isometric strength testing. It takes a force signal, detects contraction onset, and computes peak force, rate of force development, force steadiness, and bilateral symmetry, then tracks those over time for a patient. It is used by physical therapists, athletic trainers, and strength coaches.
ForceIQ does not manufacture hardware. Every device our customers use is somebody else's product, which makes device support a shared interest.
This document states exactly what ForceIQ needs from a device in order to support it, so that supporting us is a decision you can make and implement without asking us for anything. There are two conformance paths, and the first one most manufacturers already meet.
Our position on protocols, stated plainly: ForceIQ implements a device's Bluetooth protocol only where the manufacturer publishes it for third-party use, or where we hold written permission from the manufacturer. Where neither is true, we support the device through file import instead. If you would like native support and your protocol is not public, a short written interop permission is all we need, and we have a one-page template we are happy to send.
Path A: file export
Effort: usually none. Most systems already qualify.
If your device or its companion software can export a force-time trace as CSV, ForceIQ can already ingest it. No coordination with us is required and no permission is involved, because file import touches no protocol of yours.
Minimum
| Requirement | Detail |
|---|---|
| Two columns | A time column and a force column. Header names are auto-detected across common variants (time, t, Time; force, Force, torque, Torque) |
| Monotonic time | Strictly increasing. Either seconds or milliseconds; the parser infers which |
| Consistent units | Newtons, kilograms-force, or pounds-force |
| Length | At least 500 samples, no more than 120 seconds per file |
Strongly recommended
- Declare the unit in the file, either in the header row (
force_N) or in a leading comment line. Unit ambiguity is the single most common cause of an import that succeeds and is wrong. - Export at the native sample rate. If your software downsamples, smooths, or filters before writing the file, say so in a comment line. ForceIQ derives the effective sample rate from the timestamps and flags metric reliability from it, so a file exported at 100 Hz from a 500 Hz sensor is analyzed as 100 Hz. That is the correct behavior, and it is better for both of us if the file is honest about it than if it is quietly pre-processed.
- One contraction per file, or continuous with rest included. ForceIQ detects onset itself and can segment multiple contractions from one file. It cannot recover a rest baseline that was trimmed out before export, and onset detection needs it.
- Include a comment header with device model, firmware version, and configured sample rate. Lines beginning with
#are ignored by the parser and retained as provenance.
Example
# device: ExampleForce Pro 300
# firmware: 2.4.1
# sample_rate_hz: 200
# unit: N
time_ms,force_N
0.0,1.204
5.0,1.187
10.0,1.233
Path B: native Bluetooth streaming
Effort: documentation, mostly. Usually no firmware change.
Native streaming is what enables live capture and real-time biofeedback training, where the clinician sees the force trace as the contraction happens. It is a better experience than file import and it is the reason a clinician chooses one device over another for in-clinic work.
To support a device natively we need the protocol documented. That is the whole requirement. It does not need to be public if you would rather it were not, though public is simpler for everyone.
What the documentation needs to cover
| Item | Why it matters |
|---|---|
| Service and characteristic UUIDs, and which are notify vs write | Connection |
| Advertised name pattern (e.g. a stable prefix with a per-unit suffix) | Device discovery. We filter on a stable prefix so any unit of that model pairs, and never bind to a MAC address |
| Start and stop stream commands, exact bytes | Control |
| Packet layout, including how many samples per packet and the byte order | Decoding |
| Units and scale: what the transmitted number means in Newtons, and any fixed offset | Correctness, and the most common source of a silent error |
| Sign convention: which direction is tension and which is compression, or tension-only | Polarity |
| Zero / tare: whether a hardware tare command exists, or the host is expected to subtract a baseline | Every clinical trial starts from a zero |
| Timestamps: whether the device stamps each sample, and in what clock and resolution | The single most valuable thing you can offer. See below |
| Battery, if exposed | Nice to have; standard Battery Service (0x180F) is ideal |
| Firmware version, readable over the connection | Sample rate and packet format often vary by firmware. Being able to read the version turns a support ticket into a lookup |
The three properties that actually decide the metrics
These are the ones worth engineering attention, because they determine which clinical measures your device can support. They are not the ones that usually lead a spec sheet.
1. Delivered sample rate, not internal sample rate. Rate of force development is a slope fitted through the first 75 to 200 ms after onset. What matters is how many real samples land in that window at the receiving end. A sensor that samples at 500 Hz internally and transmits 100 Hz gives the metric 100 Hz. Batching several samples per Bluetooth packet is the standard way to beat the connection-interval ceiling, and it works well.
2. Continuity, not just resolution. A signal that steps in fine increments can be low-pass filtered and the noise removed. A signal quantized into coarse steps produces a staircase, and the derivative of a staircase is a train of spikes separated by flat stretches. Filtering cannot remove quantization, because it is built into the number rather than added on top of it. A device transmitting in whole pounds or tenths of a kilogram is limited for rate of force development and for force steadiness at low loads, regardless of how fast it samples. Transmit the finest value your ADC gives you and let the display round, not the protocol.
3. Timestamp provenance. Rate of force development divides by time, so the quality of the time axis goes directly into the result. Three tiers, in order:
| Tier | What it means | ForceIQ's handling |
|---|---|---|
| Per-sample hardware timestamp | Each sample carries the device's own clock value | Used directly as the time axis. Preferred, and rarer than it should be |
| Constant rate | No per-sample stamp, but a documented, stable period | Samples spaced from a monotonic counter at the declared period |
| Packet arrival | Timing inferred from when packets reach the host | Accepted, and the least precise. Bluetooth stacks deliver in bursts, so arrival time clusters |
Adding a per-sample timestamp is usually a small firmware change with a disproportionate effect on what your device can credibly measure. If you are choosing one improvement from this document, choose this one.
What ForceIQ does on its side, every session
- Measures the effective sample rate from actual inter-sample intervals rather than trusting any declared figure, and stores it on the session record.
- Flags per-metric reliability from that measurement. Rate-of-force-development readings from a low sample density carry a visible reliability badge; peak force and steadiness, which average over thousands of samples, do not.
- Converts everything to Newtons at the adapter boundary. Every downstream computation is in SI units.
- Never silently substitutes a spec-sheet number for a measured one.
This means a device that streams at a modest rate is not excluded. It is analyzed accurately and the clinician is told which metrics the rate supports. We would rather support your device honestly than exclude it or flatter it.
Conformance declaration
If you would like your device listed, send us this table filled in. These figures are yours, published as yours. ForceIQ stores them attributed to you as the manufacturer's declared specification, and any figure you do not supply is simply shown as not declared.
| Field | Your value |
|---|---|
| Manufacturer and legal entity | |
| Model name, and the advertised Bluetooth name pattern | |
| Rated maximum load, and recommended working load | |
| Direction: tension, compression, or both | |
| Internal sample rate (Hz) | |
| Delivered sample rate over the connection (Hz) | |
| Smallest force step in the transmitted value (N) | |
| Signal type: continuous, or quantized to a fixed step | |
| Timestamp provenance: per-sample hardware / constant rate / packet arrival | |
| Idle noise, standard deviation over an unloaded recording (N), if characterized | |
| Calibration method, and whether a per-unit coefficient is stored on the device | |
| Firmware version this declaration describes, and how to read it over the connection | |
| Protocol status: publicly published / documentation supplied under written permission / file export only |
Two of these are worth a note. Idle noise is the figure that actually determines whether your device can support force steadiness measurement, and almost nobody publishes it; it is a ten-second unloaded recording and a standard deviation. Per-unit calibration coefficients, if you store them on the device and expose them over the connection, remove an entire class of accuracy problem for every third party that integrates you.
What ForceIQ commits to
- No fee, in either direction. We do not charge for a listing and we are not asking to be paid for one.
- No exclusivity. Support us and support anyone else you like.
- No support obligation on you. Documentation is the whole ask. We do not expect an SLA, an engineer, or a roadmap commitment.
- Your declared figures, attributed to you. We do not publish device rankings or comparative scorecards, and we do not present our own numbers as a verdict on your instrument.
- Reliability shown honestly, per metric. We will not tell a clinician a measurement is trustworthy because of the brand on the device, and we will not tell them it is untrustworthy either. We tell them what the signal supports.
- Termination at will. Withdraw permission and we remove the integration.
How to reach us
support@forceiq.app, subject line "Device interoperability".
Send the conformance table, whatever protocol documentation you have, and tell us which path you want. If your protocol is not public and you would like it to stay that way, say so and we will send the one-page interop permission template.
If your protocol is already published for third-party use, tell us where, and there is nothing further we need.
ForceIQ, Acton, Massachusetts. This specification is published for the benefit of manufacturers and imposes no obligation on anyone. It describes what ForceIQ can consume and what it commits to in return; it is not an offer, a contract, or a warranty.