If you are buying a dynamometer to do more than record a peak number, the spec sheet will not answer your question. Sample rate and maximum load sit at the top of every product page because they are easy to print. Neither one tells you whether the device can support a trustworthy rate of force development, and neither one tells you whether a force steadiness measurement will reflect your patient or your sensor.
Three properties decide that, and only one of them is usually advertised. This article is about what they are, why they matter for each metric, and how to work out most of the answer yourself before you spend anything.
What this article is not
It is not a ranking, and it does not name devices. Which properties matter depends entirely on which metrics you actually use, and a device that is a poor choice for early-phase rate of force development can be an excellent choice for peak force at a third of the price. There is no ordering that survives contact with a specific clinical question.
It is also not a review of any manufacturer's instrument. Everything below is arithmetic and measurement methodology: what a given force step does to a coefficient of variation, what a given sample rate does to a slope estimate. You can apply it to whatever is in front of you, including hardware that did not exist when this was written.
The three properties
Sample rate, specifically the rate that reaches your software rather than the rate the sensor runs at internally. Devices commonly sample faster inside than they transmit.
Signal continuity. Whether the number you receive moves in fine increments or jumps in fixed steps. This is usually not on the spec sheet at all, and it is frequently confused with the sensor's internal resolution, which is a different thing.
Timestamp provenance. Where the time axis comes from: the device's own clock, an assumed constant rate, or the moment a packet happened to arrive at your computer. Almost never advertised.
What each metric demands
Peak force
Peak force is the forgiving one. It is a single post-onset maximum, so it does not care about sample rate in any practical sense, and a modest amount of noise averages out at the top of the curve. What it cares about is calibration and range.
| Adequate | Better | Best | |
|---|---|---|---|
| Calibration | Factory calibration, unverified | Linearity verified across the working range | Multi-point verified, with the residuals published |
| Range | Covers your heaviest test | Headroom above your heaviest test | Headroom plus both tension and compression |
| Rate and resolution | Almost irrelevant |
The property to check first is direction, because it is binary and it decides whether a device fits your setup at all. A compression-only device cannot be pulled through a strap or tether, and a tension-only device put into compression can clamp its reading rather than fail loudly, which is the worse failure of the two because it still produces a number. Match the direction of the sensor to the direction of your test before you compare anything else on this page.
Rate of force development
RTD is the slope of the first 75 to 200 ms after onset. It is a time derivative, which makes it the most demanding metric on this page and the one where spec sheets mislead most often.
Sample rate sets how many real points the slope gets. ForceIQ flags reliability from the sample count that actually lands in the window: six or more is high, four or five is moderate, fewer than four is low. Over the 0 to 75 ms early window that works out to:
| Sample rate | Samples in the 75 ms window | RTD Early flag |
|---|---|---|
| 40 Hz | 3.0 | Low |
| 54 Hz | 4.1 | Moderate, just over the threshold |
| 80 Hz | 6.0 | High, at the threshold |
| 100 Hz | 7.5 | High |
| 250 Hz | 18.8 | High, and enough for early-phase work |
The same rule runs against the RTD Late window (100 to 200 ms), which is 100 ms wide rather than 75, so the rate needed to clear each tier is lower: 60 Hz for high, 40 Hz for moderate. A device can legitimately earn a high flag on RTD Late and a moderate one on RTD Early from the same contraction. That is not an inconsistency, it is the windows being different widths.
Two things follow from this that are easy to miss. The flag is computed from the rate measured on your actual recording, not from the rate on the box, so a device that drops packets or streams unevenly can land a tier below its spec. And the tiers describe the slope estimate only. Peak force, steadiness, and limb symmetry are computed across hundreds of samples over seconds and are unaffected by which tier a session lands in.
But rate is necessary, not sufficient. A derivative amplifies whatever the signal does between samples, and a quantized signal does something specific between samples: nothing, and then a whole step at once. On a device with a 1 lb step, a slow contraction produces a staircase, and the derivative of a staircase is a series of spikes separated by zeros. Nothing in that trace is patient behavior.
The important part is that this is not fixable downstream. Sensor noise is roughly random and a low-pass filter removes most of it. A quantization step is built into the number itself, so there is nothing to filter. A high sample rate on a coarsely stepped signal does not produce a good derivative. It produces a very well sampled staircase. If you take one thing from this article, take that, because it is the trap that a spec sheet is most likely to walk you into: the highest number in a comparison can belong to the weakest device for the metric you care about.
Timestamp fidelity is the third piece and the least discussed. RTD divides by time, so the quality of the time axis goes straight into the result. A device that stamps every sample in hardware gives you a true time base. A device that delivers samples in batches and leaves the receiver to space them out from an assumed period gives you a good approximation, with the error concentrated at packet boundaries.
On a clean stream the two produce results that agree closely, and inferred timing is not a defect. It matters in two situations: when you are deciding how much weight a single early-phase slope can carry, and when the stream is not clean, because an assumed period silently closes a gap left by a dropped packet while a real clock leaves it visible.
| Adequate | Better | Best | |
|---|---|---|---|
| Sample rate | 54 to 80 Hz (moderate flag) | 80 Hz and above (high flag) | 200 Hz and above |
| Signal type | Continuous, or fine steps at high force | Continuous | Continuous with a measured noise floor |
| Timestamps | Packet arrival | Documented constant rate | Per-sample, from hardware |
Note that these do not resolve into a ranking either. A device at the bottom of the high band with hardware timestamps and one at three times the rate with arrival-based timing are different trade-offs, not different amounts of quality. Which you want depends on whether your protocol needs early-phase resolution or a defensible time base.
Force steadiness
Steadiness metrics (coefficient of variation, and normalized RMS error against a target) ask a harder question than they appear to: how much does force fluctuate during a hold? The answer is only meaningful if the sensor's own fluctuation is well below the patient's.
Quantization sets a hard floor here, and the arithmetic is unforgiving. A uniform quantization step produces a standard deviation of step divided by the square root of 12, no matter how still the patient holds. Divide that by the hold force and you get the lowest CV the device can possibly report.
| Force step | SD floor | CV floor at 50 N | at 100 N | at 200 N |
|---|---|---|---|---|
| 0.28 N | 0.08 N | 0.16% | 0.08% | 0.04% |
| 0.52 N | 0.15 N | 0.30% | 0.15% | 0.08% |
| 0.98 N (0.1 kg) | 0.28 N | 0.57% | 0.28% | 0.14% |
| 4.45 N (1 lb) | 1.28 N | 2.57% | 1.28% | 0.64% |
Physiological force steadiness runs about 1 to 3% CV in healthy adults, and up to roughly 5% in clinical populations. Put the last row against that range. At a 50 N hold, a 1 lb step produces about 2.6% CV from quantization alone, which lands in the middle of the physiological band. The device is not measuring tremor. It is reporting its own resolution, and it looks exactly like tremor.
The same device at a 200 N hold has a 0.64% floor and is perfectly usable. Steadiness capability is not a property of the device alone, it is a property of the device at the force you are testing at. Run that division for your own typical hold before you trust a steadiness number.
One thing the table cannot tell you: quantization is a floor, not a prediction. A device's own electrical noise can sit well above its step size, and then the step size is irrelevant. A device whose noise standard deviation is comparable to its step has a real steadiness floor several times worse than the step alone implies, which can put it inside the low end of the physiological range rather than comfortably below it.
This cuts both ways. Past a certain resolution the step size stops being the number that matters at all, and only the noise measurement means anything. Either way the published step is the best case, and the only way to know where your floor actually sits is to measure it: a ten second unloaded recording and a standard deviation. That figure is the one you should ask a manufacturer for, and it is the one almost nobody publishes.
What to ask before you buy
The specs that decide your metrics are mostly not the ones on the box. Four questions get you most of the way:
- What is the smallest force change the device reports? Not the sensor's internal resolution, the step in the number you receive. Divide it by your typical hold force to get your steadiness floor, then compare that to the 1 to 3% physiological range.
- Is the signal continuous or stepped? A fine staircase is workable at high force and a problem at low force. Filtering removes noise; it cannot remove quantization.
- Where do the timestamps come from? Per-sample hardware timing is the gold standard and is rare. Anything else is an approximation, which is usually fine, and is worth knowing about before you build a protocol around early-phase RTD.
- What is the delivered rate, not the internal rate? Devices commonly sample faster internally than they transmit. The rate that matters is the one that reaches your software.
A manufacturer who can answer all four quickly is telling you something about the instrument beyond the answers themselves. If you are a manufacturer reading this, those four questions and the rest of what we need are written up in the device interoperability specification.
How ForceIQ handles this
ForceIQ measures the effective sample rate and the quantization behavior of whatever signal it receives, on every session, and flags per-metric reliability from that rather than from a device name. What each rate tier looks like in practice is in sample rate and what it does to your metrics, and the resolution side is in when steadiness numbers are resolution-limited. A 40 Hz trace and a 250 Hz trace are both analyzed; the difference shows up as a reliability badge on the metrics that the rate cannot support, rather than as a silent change in the number.
That matters more than picking a winner would. It is the honest way to run a mixed fleet, where different clinicians own different hardware and files arrive from isokinetic systems nobody in the building controls. It also means the device you already own does not have to be the best device to be useful. It has to be well characterized, and the platform does that characterization itself, on your recording, every time.