A sensor claim like "±0.02 m/s" means nothing on its own. Accuracy figures are only as credible as the reference standard they were measured against, and the protocol used to compare the two. I want to walk through how I actually validated ORCA, because the process matters as much as the number it produced.
Why you need a ground truth first
Before I could claim anything about ORCA's accuracy, I needed a reference system whose own error was small enough, and well characterized enough, to serve as ground truth. I used a tethered linear position transducer as that reference for the strict vertical case, since its error on a purely vertical path is well documented and small relative to what I was trying to measure.
That choice matters. A reference system is only useful if its own uncertainty is meaningfully smaller than the effect you're trying to detect. If I validated ORCA against something with comparable or worse error, I would have learned nothing.
The comparison protocol
I ran ORCA and the tethered reference simultaneously on the same bar, across a range of loads and movement velocities, and compared the two velocity traces sample by sample rather than just comparing peak or mean values per rep.
This distinction is important. Two systems can agree closely on mean velocity for a rep while disagreeing substantially at specific points in the trajectory, particularly near the transition points where acceleration changes sign. Averaging over the rep would hide exactly the kind of error I needed to find.
I looked at:
- Instantaneous velocity error at each sample, not just per-rep summary statistics.
- Error as a function of load, since drift and integration error can scale differently at heavy, slow reps versus light, fast ones.
- Error as a function of bar path deviation, deliberately introducing small lateral and rotational components to see how each system responded once the strict-vertical assumption broke down.
That last test is where the two-sensor fusion earned its keep. On a strict vertical pull, both systems tracked closely. Once I introduced even modest deviation from vertical, the tethered reference's own error grew in the way you'd expect from a single-axis system, while ORCA's dual-IMU estimate held.
What ±0.02 m/s actually represents
The figure I publish isn't a single measurement, it's the bound on instantaneous velocity error observed across that full protocol: multiple loads, multiple athletes, multiple bar paths, compared sample by sample against the reference. It's a worst-case bound within the tested envelope, not a best-case number from a single clean rep under ideal conditions.
I think that distinction matters more than the number itself. A sensor that's accurate on one perfect rep and drifts on the next fifty isn't useful for programming. A sensor whose error is bounded and repeatable across a realistic range of conditions is.
Why I keep re-running this
Validation isn't a one-time event I ran before shipping. Every hardware revision, every firmware update to the sensor fusion algorithm, gets run back through the same comparison protocol against the same reference standard before it goes out. That's the only way I can be confident that a change made to improve one thing, battery life, latency, form factor, hasn't quietly degraded the number that the entire system is built around.
That discipline is what lets me put a number on the spec sheet and stand behind it.
Léo Fortin Dionne designed the advanced measurement systems behind ORCA Strength Systems.