The first 75 ms of a contraction is a small window. At 40 Hz it contains three samples. At 80 Hz it contains six. At 250 Hz it contains nineteen. Same contraction, same patient, same window: the only thing that changes is the resolution of the slope you can compute through it. The review literature on explosive force production makes the same point with a sharper edge: rapid contractions should be treated as a time series, not as a small set of sampled points, because the time windows themselves are arbitrary thresholds rather than physiological events (Del Vecchio 2022).
Strength (peak force), the Control metrics measured across the plateau, and the LSI between sides are mostly insensitive to this. They average across hundreds of samples over multiple seconds and don't depend on resolving fast transients. RTD does. It is a slope between two points, the force at onset and the force 75 ms later, each interpolated from the samples on either side of it. At 40 Hz those samples are 25 ms apart, so onset can only be placed to within a third of the window, the interpolated endpoints are straight-line guesses across a curving rise, and noise on any one of the few samples involved moves the slope by 20 to 30 percent. At 250 Hz the samples are 4 ms apart, and all three problems shrink.
ForceIQ measures the effective rate on every connection (or every uploaded file) and surfaces it as a reliability badge on the two RTD tiles, Explosiveness (RTD Early) and Build-up (RTD Late). This article walks through what each tier looks like, which devices land in which tier, and what to do when the badge is yellow or red.
Low: below 60 Hz
The first plot below is a clean MVIC captured at roughly 40 Hz. The trace looks fine because the contraction itself is multi-second; you cannot tell from the plateau that the rise was undersampled. The RTD Early window (the orange band) is where the limitation shows up. There are only three samples inside it, which is enough to draw a slope but not enough to be confident the slope reflects the patient's actual rate of force development rather than the noise on the samples either side of its endpoints.
What you'll see in the app. Both RTD tiles (Explosiveness and Build-up) on a session at this rate show a red Low Confidence badge, with an inline warning naming the rate. RTD Late's window is wider (100 ms), but it starts from the same onset, so it carries the same tier.
What lands here. Two kinds of recording, mostly. Devices whose transmitted rate is lower than their advertised rate, which is common enough to be worth assuming until measured: a rate is often quoted for the sensor and not for what reaches your software, and a firmware option that adds a feature sometimes costs transmission rate to pay for it. And files that were downsampled somewhere between the sensor and the export.
Grip trainers sit further down the same scale. A device with an event-driven readout rather than a continuous stream can put well under one sample inside the RTD Early window. That is a design decision rather than a defect, and those devices serve the screening purpose they were built for. They are simply not instruments for rate of force development, and the platform flags them accordingly.
The science underneath is unchanged regardless of which device produced the signal. A 75 ms window holds three samples at 40 Hz, period. Strength (peak force), the Control metrics on the plateau (Drift from peak, Steadiness and Smoothness, or nRMSE, CV and Yank), and bilateral symmetry on any of those measures are unaffected by the rate and remain fully valid.
Moderate: 60 Hz to under 100 Hz
The plot below is the same MVIC captured at 80 Hz. Six samples fall inside the RTD Early window and eight inside the RTD Late window (100 to 200 ms), twice the density of the 40 Hz trace. That is enough for a slope that is usable but not durable, and ForceIQ marks it Mod. Confidence in yellow on both RTD tiles. The number is shown the same as any other; the badge is your reminder that it deserves less weight in the read than a high-confidence number would.
The tier is set by the rate rather than by the count in each window. Both windows hang from onset, and onset can only be placed to within one sample interval: 25 ms at 40 Hz, 12.5 ms at 80 Hz, 10 ms at 100 Hz. A wider window gives RTD Late more samples between its endpoints, but it does not move its start any closer to the true onset, so RTD Early and RTD Late share one rule.
What lands here. Most hand-held tension gauges built for clinical testing stream near 80 Hz, so this is the tier most clinic recordings fall in. One property is worth checking separately from the rate: a device that stamps every sample in hardware gives you a true time base, and an 80 Hz device with per-sample hardware timing is a better foundation for a time-derivative metric than the modest rate suggests. That combination is rarer than it should be, and it is almost never on the spec sheet.
A high rate does not by itself earn a good RTD number. Some devices stream fast and report in coarse steps, and the reliability badge on this page only describes sample density. A device reporting in 0.1 kg or 1 lb increments produces a staircase, and the derivative RTD depends on turns into a series of spikes separated by flat stretches no matter how many samples per second arrive. That limitation is tracked separately, as a steadiness reliability flag rather than a rate flag; see What the steadiness reliability badge means. Read the two together when you are judging whether a fast but coarse device suits explosive testing.
High: 100 Hz and above
At 100 Hz the RTD Early window holds seven or eight samples and onset sits within 10 ms of a real sample, close enough that a single noisy sample cannot dominate the slope.
What you'll see in the app. No badge on the RTD tiles. The reliability flag exists on the session document either way; high-reliability sessions simply don't surface it visually.
What lands here. Isokinetic exports, laboratory strain-gauge rigs, and Bluetooth gauges that send several samples in each packet. Uploaded files land here when the export preserved a native rate of 100 Hz or more.
Very high: 250 Hz and above
At very high rates the RTD Early window contains many samples (about seventeen at 225 Hz, nineteen at 250 Hz, twenty-five at 333 Hz, thirty-seven at 500 Hz, and seventy-five at 1000 Hz). The slope estimate is stable; the limiting factor on RTD precision shifts from sample count to the patient's own motor-unit firing variability between trials, which is a real biological signal rather than a measurement artifact.
What you'll see in the app. No badge. The chart looks visibly denser inside the RTD windows, but the metrics output is unchanged in format from the 100 Hz case.
What lands here. Isokinetic dynamometers commonly export between 100 and 500 Hz, and some research-grade strain-gauge rigs sample at 1000 Hz or higher. A number of Bluetooth force gauges reach this range too, by sending several samples in each packet rather than one, so this is not only an upload tier.
Files uploaded from any of these systems land in this tier when the CSV preserves the native rate. If an export was downsampled before being saved, the platform will measure the post-downsample rate and flag accordingly; the file's history matters, not the device's catalog spec.
This tier is also where the caveat from the moderate section bites hardest. A device can earn a high rate flag on sample density alone while reporting in 0.1 kg or 1 lb increments, so the signal it delivers is a staircase rather than a smooth rise. A high rate flag on the RTD tiles means the slope had enough points to fit; it does not certify that the underlying signal was smooth enough for the slope to mean what you want it to. The steadiness reliability badge is the one that speaks to that, and at this tier it is the one to read first.
Why the platform measures the rate instead of trusting the spec sheet
A device's listed sample rate and its effective streaming rate often diverge. Firmware updates change the transmission rate. Bluetooth congestion drops packets. Some devices buffer and burst rather than streaming evenly. ForceIQ measures the rate from the actual inter-sample intervals over the first two seconds of every recording and uses that measured value to decide the badge tier. The spec sheet is never consulted.
The same applies to uploaded files. If a CSV exported at 200 Hz was post-processed and saved at 100 Hz, the platform sees 100 Hz and treats it that way. There's no metadata header that overrides the actual timestamps. The methodological lineage on this point is well established in the rapid-force literature. The platform filters the natively sampled signal with a zero-lag Butterworth low-pass at 20 Hz, the same filter family and cutoff Del Vecchio et al. (2019) used, and never resamples it first.
The other reason the rate matters is onset placement. Threshold-based onset detection at low sample rates can place the onset off by 24 to 30 ms (Tillin et al. 2013), and that error budget falls almost entirely inside the RTD Early window. Higher sample rates do not solve onset detection on their own, but they make it possible to do better.
When to act on a low-confidence badge
The badge does not mean the RTD value is wrong. It means the value depends on so few samples that one noisy reading can swing it by a clinically meaningful amount. Whether that matters depends on what you're doing with the number:
- Return-to-sport decisioning that hinges on RTD asymmetry. A low-confidence RTD value is a noisy estimate of the patient's actual rate of force development. The clinical question to ask is whether the noise floor of a three-sample estimate is compatible with the threshold you're using to clear the patient; that's a clinical judgment, not a platform one.
- Within-patient longitudinal tracking on the same recording method. Low-confidence trends are still informative as long as the rate hasn't changed between visits. The noise floor is consistent across recordings, so the direction of change is preserved even when the absolute value isn't durable.
- Strength and Control. Peak, nRMSE, CV, and Yank are computed over hundreds of samples across multiple seconds. Their precision is not meaningfully affected by the rate tier.
Try it in the Dynamometry Lab: resample a real recording and count the samples inside RTD Early's 75 ms window.
What to do next
- Check the badge before reading the RTD numbers, not after. The reliability tier is the context everything else sits in.
- After any device firmware update, restart the device once and reconnect. Firmware changes can move the transmission rate in either direction. The first session afterward measures and stores the new effective rate, and the badge tier updates from there.
- If you're doing high-stakes RTD work and only have a 40 Hz device, document it in the session notes. The number still ships and is useful as a relative measure, but the next clinician reviewing the patient should know which tier the data came from.
Sample rate is one of three device properties that decide which metrics a recording can support. The other two, the size of the step in the reported number and where the timestamps come from, are worked through in which dynamometer specs actually decide your metrics.
References
- Del Vecchio A. Neuromechanics of the rate of force development. Exerc Sport Sci Rev. 2022. doi:10.1249/JES.0000000000000306
- Del Vecchio A, Negro F, Holobar A, et al. You are as fast as your motor neurons: speed of recruitment and maximal discharge of motor neurons determine the maximal rate of force development in humans. J Physiol. 2019;597(9):2445-2456. doi:10.1113/JP277396
- Tillin NA, Pain MTG, Folland JP. Identification of contraction onset during explosive contractions. Response to Thompson et al. J Electromyogr Kinesiol. 2013;23(4):991-994. doi:10.1016/j.jelekin.2013.04.015