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.
How to read the numbers below
Everything in the tables is what we measure over each device's own Bluetooth stream, on our bench, against known weights. That is a specific claim with specific limits, so it is worth being precise about what it does and does not mean.
A property of the Bluetooth stream is not a verdict on the instrument. Some devices publish a data stream that carries less information than their sensor captures, either because the manufacturer's own software fills in the rest or because the connection has a ceiling the sensor does not. Where that is the case we say so. None of this is a claim that a manufacturer's own app produces the same numbers we do, and none of it is a claim that a device is defective. Manufacturers change firmware, and a figure here is a snapshot of what we saw.
We are also not going to tell you which one to buy. 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.
The comparison
| Device | Sample rate | Force step | Signal type | Timestamps | Mode |
|---|---|---|---|---|---|
| Tindeq Progressor | ~80 Hz | Float (no step) | Continuous | Per-sample, from hardware | Tension + compression |
| VALD DynaMo | 225 Hz delivered | ~0.52 N | Near-continuous | Verified constant rate, from the device clock | Tension + compression |
| ActivForce 2 | ~97 Hz | ~0.28 N | Continuous | Constant rate, from a sample counter | Compression only |
| FightTech | ~250 Hz | ~0.28 N noise floor | Continuous | Packet arrival | Tension + compression |
| PitchSix Force Board | ~40 Hz stock, ~84 Hz after a firmware upgrade | 4.45 N (1 lb) | Quantized staircase | Packet arrival | Tension only |
| Muscle Meter | ~485 Hz | 0.98 N (0.1 kg) | Quantized staircase | Constant rate, from a sample counter | Tension + compression |
| Squegg | Low, event-driven | 0.98 N (0.1 kg) | Quantized staircase | Packet arrival | Grip |
| Frez Dyno (unreleased) | 250 Hz claimed | 0.1 kg claimed | Not yet known | Not yet known | Not yet known |
Read that table across, not down. The Muscle Meter row has the highest sample rate on the list and is the weakest device on it for rate of force development, for reasons that have nothing to do with rate. That is the whole point of the rest of this article.
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 |
Every device in the table above can produce a defensible peak force inside its range and mode. Mode is the one to check first, 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 we measure 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. Worse, quantization is not filterable. Sensor noise is roughly random and a low-pass filter removes most of it; a quantization step is a floor built into the number itself.
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 infer timing gives you a good approximation with jitter at the packet boundary.
| 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 | Verified constant rate | Per-sample, from hardware |
This is why the table at the top does not resolve into a ranking. The Tindeq Progressor runs at 80 Hz, which is the bottom of the "high" band, and pairs it with per-sample hardware timestamps, which nothing else on the list offers. FightTech runs at roughly three times the rate on a continuous signal with arrival-based timing. The VALD DynaMo sits between them on timing, at a comparable rate on a near-continuous signal with a verified constant period read from the device's own clock. Those are different trade-offs, not different amounts of quality, and which one 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.
One thing the table above 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. We measured this on the DynaMo, which resolves in roughly 0.52 N steps but shows about 0.45 N of noise standard deviation sitting still and unloaded. Its real floor at a 50 N hold is near 0.9%, not the 0.30% the step size implies, which is inside the low end of the physiological range rather than comfortably below it. The published step is the best case. Ask for a measured noise figure, or measure it yourself with a ten second unloaded recording.
| Adequate | Better | Best | |
|---|---|---|---|
| Force step | Under 1 N, at mid to high force only | Under 0.3 N | Under 0.1 N |
| Signal type | Fine staircase | Continuous | Continuous with a measured noise floor |
| Zero drift | Tare before each trial | Stable across a session | Stable across a session, verified |
Device notes
Tindeq Progressor. Roughly 80 Hz, continuous float readings, and the only device we have decoded that timestamps every sample in hardware. That last property is genuinely rare and it matters more than the modest rate suggests, because it removes an entire class of error from any time-derivative metric. Reads in both tension and compression.
VALD DynaMo. The highest-specified hardware in the group, sampling internally well above what the Bluetooth connection delivers. The delivered stream is 225 Hz on a near-continuous signal, which puts about seventeen samples inside the early RTD window.
The stream is unusual in how it encodes force. Most of the time it carries the change since the last sample in a small fixed field, which is efficient but has an obvious limit: a fast enough rise cannot fit. The device handles that by switching to a full absolute reading for that sample instead of clipping, so an explosive effort is represented rather than flattened. We assumed a ceiling here before we had a unit on the bench and confirmed the escape behavior; there is not one. Software reading this stream does have to handle both forms, because a delta-encoded signal is a running sum and a discarded sample is a permanent offset rather than a missing point.
It also does not stamp individual samples, but it does publish its own sample clock periodically, which is enough to measure the true period rather than assume it. On our bench that came out at 4,444 microseconds per sample, identical to the microsecond across every interval in two separate recordings. That is a verified constant rate rather than an inferred one, and it lands a tier above arrival-based timing for anything involving a derivative.
Resolution is where this device surprised us, and it is the reason it is not the steadiness pick it looks like on paper. The stream carries force in roughly 0.1 N units, so that is the number you would write down from the protocol. But the sensor behind it only ever moves about five of those units at a time: across five ninety second recordings, not one of sixty one thousand non-zero steps was smaller than five. The real step is around 0.52 N, five times coarser than the encoding suggests. That is still fine for clinical loads, but it is a different device on the steadiness table than the count size implies, and it is a good illustration of why we measure the stream rather than reading the protocol.
Calibration is the last open item. A 35 lb weight held for eleven seconds gives about 0.0973 N per count, which puts the constant we ship 2.8% high, and a small amount of that is probably the mass of the hook the weight hangs from. One load cannot separate the two.
ActivForce 2. Continuous signal at fine resolution with a configurable rate, topping out just under 100 Hz because of how the data is packetized. Comfortably in the high band for standard RTD windows, not an early-phase instrument. Compression only, which suits handheld break and make testing and rules it out for any setup that pulls through a strap or tether.
FightTech. The highest usable combination in the group as we decode it: roughly 250 Hz on a continuous signal with a noise floor around 0.28 N and calibration that fits a straight line essentially perfectly across our test weights. Timing is arrival-based rather than hardware-stamped.
Worth knowing what you are actually buying here. There is no FightTech-branded manufacturer: this is a white-label load cell sold on Amazon under rotating generic brand names, currently listed as a 500 kg isometric tester under HCAUYNN among others. FightTech is the name of the companion app it ships with, which is what we key it by in the device list because the brand on the box is not stable. That makes it the cheapest route to a genuinely high-rate continuous signal in this group, with the trade-offs you would expect from an unbranded product: no manufacturer support channel, no published calibration certificate, and no guarantee that the unit you receive next year runs the same firmware as the one we tested.
PitchSix Force Board. Reports in whole pounds, which is a 4.45 N step, and that single fact drives most of its profile. Peak force in tension is solid. Steadiness below roughly 150 N is dominated by the step rather than the patient, and the staircase disrupts the derivative that RTD depends on. Rate is the part to plan for. The board streams at around 40 Hz on the firmware it ships with, which is three samples in the RTD Early window and a low reliability flag. Reaching roughly 84 Hz, and a high flag, requires deliberately installing a firmware upgrade; it is not something a stock unit does out of the box. The rate is set in firmware rather than commanded over the connection, so it is a property of the specific unit in your hands, and ForceIQ measures it from the recording rather than assuming either value.
Muscle Meter. The instructive case. It samples at roughly 485 Hz, the highest number in the table, and reports in 0.1 kg increments, which is a 0.98 N staircase. High rate plus coarse steps does not produce a good derivative, it produces a very well-sampled staircase. Fine for peak force, and usable for steadiness at mid to high forces where the step is small relative to the hold.
Squegg. Built as a grip trainer and screening tool rather than a research instrument, with an event-driven readout rather than a continuous stream. It does the job it was designed for. We do not evaluate it for RTD or steadiness because it was never meant to serve them.
Coming soon: the Frez Dyno
Frez has an official sensor listed as coming soon, published at 250 Hz with 0.1 kg precision, positioned as a low-cost option. If the rate holds up in delivery, it would sit alongside the fastest devices we have decoded, at a price point well below them. That is a genuinely interesting prospect and we will test one as soon as we can get hold of it.
One caution worth stating now, because it is the exact trap this article is about. If that 0.1 kg figure describes sensor quantization rather than display rounding, the device would have a 0.98 N step, which is the Muscle Meter profile rather than the Tindeq profile: an excellent sample rate feeding a staircase that a derivative cannot use cleanly. If it describes display precision over a finer underlying signal, the picture is completely different and very attractive. Those two readings of the same published number lead to opposite conclusions about whether the device suits RTD work, and nothing on a spec sheet distinguishes them. We will report what we measure.
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.
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. 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 is the honest way to run a mixed fleet, and it means the device you own does not have to be the best device to be useful.