A sensor fusion algorithm is only as good as the hardware pipeline feeding it. I could design the cleanest fusion model in the world, but if the PCB, the firmware, and the data path introduce latency, jitter, or noise before the data ever reaches that model, the accuracy claim on the spec sheet is worthless. Building ORCA meant treating the electronics, the firmware, and the fusion algorithm as one continuous engineering problem, not three separate ones handed off in sequence.
Why the PCB layout comes before the algorithm
It's tempting to think of sensor fusion as a software problem that starts once the data arrives. In practice, the quality of that data is set at the board level, before a single line of fusion code runs.
Two 6-axis IMUs sampling at 200 Hz each are sensitive to electrical noise, and that noise couples in through the PCB itself if you're not deliberate about layout. I placed the IMUs to minimize trace length and avoid routing digital switching lines near the analog-sensitive sections, kept power planes clean and properly decoupled at each sensor, and grounded the board to control common-mode noise between the two sensors. If the two IMUs pick up correlated noise from a shared power rail, that noise doesn't cancel out in the fusion step, it looks like a real signal and corrupts the cross-reference the entire fusion approach depends on.
This is the kind of decision that never shows up on a spec sheet, but it directly bounds the accuracy of everything built on top of it.
Firmware: getting 200 Hz to actually mean 200 Hz
A microcontroller sampling at a nominal 200 Hz doesn't automatically deliver evenly spaced samples. Timer jitter, interrupt priority conflicts, and blocking operations in the main loop can all introduce timing variance that looks small in isolation but compounds badly once you're integrating acceleration into velocity.
I built the firmware around a hardware-timer-driven sampling interrupt with a strict priority above anything else running on the microcontroller, so the acquisition timing itself doesn't depend on what the rest of the firmware is doing at that instant. Sensor reads, fusion computation, and Bluetooth transmission are decoupled into separate stages, so a slow radio transmission never delays the next sample. That separation is what lets the system claim a fixed sample interval rather than an average one, and the difference between the two matters once you're integrating.
Where the fusion runs, and why that's a design decision
I made an explicit choice to run the sensor fusion on the microcontroller itself rather than streaming raw IMU data to the phone and fusing it there. Doing the fusion on-device means the two IMU streams are combined at the source, at full sample rate, before Bluetooth's inherent transmission jitter and packetization ever touch the data. Pushing raw dual-IMU data over Bluetooth at 200 Hz per sensor would also strain the link and reintroduce exactly the kind of timing uncertainty the firmware architecture was built to eliminate.
The tradeoff is that the fusion algorithm has to run within a tight compute and memory budget on embedded hardware, which shaped how I structured the filter itself: computationally efficient enough to run in real time on-device, without cutting the corners that degrade accuracy.
The app is the last mile, not an afterthought
The app receives a fused velocity stream, not raw sensor data, and its job is to present that stream with zero perceptible latency and to correctly segment it into sets and reps without the athlete doing anything. I built that pipeline end to end: the Bluetooth protocol that carries the fused output, the rep-detection logic that runs on the incoming stream, and the interface that displays velocity, power, and load in real time.
Building the full path this way, from PCB layout through firmware through the app, meant no layer could quietly degrade what the layer below it had done right. A perfect fusion algorithm behind a noisy PCB is worthless. A precise data path feeding into a laggy app is worthless. Every layer had to hold to the same standard.
Why I engineered it end to end
Each of these decisions, board layout, interrupt priority, where the fusion runs, how the app consumes the output, is defensible on its own terms, and each one has to be right for the accuracy figure on the spec sheet to mean anything at all. That's the standard I hold every layer of this system to: the physics, the firmware, and the user-facing number in the app all have to agree.
Léo Fortin Dionne designed the advanced measurement systems behind ORCA Strength Systems.