Hi guys, I am also working on a motion capture tool for fitness. 2 of these IMU in hands (both in peripherial role), and an extra working as a hub (both central/peripherial role). My question is which one is better? to send packets in in every 10ms to the hub, and then the hub to send to the phone in every 10ms as well…and do the data processing (motion recognition) on the phone? or it’s best to recognize motion in the 2 hand imus first and send the recognized data to the phone?
I am having issues with the 1st option because the hub sometimes drops 1 of the hand imus. I am having a gut feeling that I am sending too much in too little timeframe.
am I reaching the BLE limits by sending sensor data in every 10ms from 2 IMUS to a 3rd IMU?
Hi there and welcome!
So, Your gut feeling is 100% correct here—you are bumping into the limits of BLE radio scheduling, not necessarily just the raw bandwidth.
Here is a breakdown of the architectural side and why Option 2 is definitely the way to go:
Why Option 1 (10ms Raw Streaming) is dropping connections: While BLE can theoretically go down to a 7.5ms connection interval, trying to maintain two concurrent 10ms (100Hz) links to a single central hub is a scheduling nightmare for the radio. The central hub has to perfectly interleave the listening windows for both hand IMUs. If there is any standard 2.4GHz noise in the room, or if the internal clocks on the boards drift even slightly, those radio windows will collide. When collisions happen repeatedly, packets drop, the supervision timer expires, and the hub gracefully drops one of the peripherals to save the connection to the other.
Why Option 2 (Edge Processing) is the standard for wearables: Processing the motion on the two hand IMUs first is absolutely the best approach for this kind of fitness tracking.
- Drastically Reduces Collisions: Instead of blasting a continuous firehose of raw X, Y, and Z vectors every 10ms, your peripheral only needs to transmit when a specific motion event or state change occurs (e.g.,
“rep complete” or “punch detected”). 
- Power Efficiency: Radio transmission is power-hungry. Keeping the radio asleep and only transmitting processed data will massively extend your battery life on the hand nodes.
- More Stable Intervals: By sending smaller, processed data packets, you can relax your BLE connection interval to something much safer—like 30ms to 50ms—ensuring rock-solid stability for both connections.
If you absolutely must stream raw data to the hub, you’ll need to increase your connection interval and pack multiple sensor readings into a single payload using a larger MTU size. But if you can do the math on the edge, that is the much cleaner architecture!
If you end up posting some of your code later on,use the code tags above “</>” paste it in there. we can definitely take a look at the specific implementation.
HTH
GL 
PJ 
Check some post I have on the concurrent connections and others like @msfujino Also has some very useful and informational examples on here as well. 
thanks for your input. Finally after two weeks of trying, I managed to make this work. All three sensor transmitting without disconnect steadily.
1 Like