iOS Sampling at 100Hz Gyro and Accelerometer and 10Hz Magnetometer

Hello,

In our iOS app, we are fusing together 100Hz accelerometer/gyro data and 10Hz Magnetometer data coming from MetaMotion R/RL (v0.4 and v0.5). In some but not all cases, the timestamp data is not very periodic (10ms apart for 100Hz stream)

In some cases (but interestingly not in all the cases with the same setup above i.e., 100+10Hz), we are not able to receive several samples (ending up with losses of 33% to 67%) at iPhone. We are using your API but as part of our own application. I suspect that this could be due to loss over BLE wireless channel, although the phone and the pod are only 2 m apart from these but not in direct line of sight. I understand that the default transmission power is 0dB so we are going to try the maximum transmission power just to be sure that the problem is not due to the wireless channel. Is 4dB the maximum transmission power supported?

Also, we noticed that typically a row of consecutive samples (typically 2 or 3) end up being assigned the same timestamp at the iPhone.

Can you please let us know based on the description of the problem what could be other logical reasons for the problems above?

I should be able to share the downloaded data via a private email as it is outputted by our own app. If you are interested in looking into data logs, please share an email address where I can send you these logs.

Many thanks
Yannis

Comments

  • @Laura or anyone esle do you have any feedback on this post please?

  • @yannisps

    In streaming mode the timestamp is created at reception time (at the mobile device), to avoid transmitting that with the data. It may be necessary to adjust the timestamps to deal with dropped packets, or multiple samples that are received in one connection interval.

    Streaming multiple sensors at 100Hz will be near the bandwidth limit for BLE on some devices, so it would help considerably to switched to the "packed" transmission mode. This will send 3 samples in each packet from the sensor, but may require additional correction of the timestamps.

    Matt

Sign In or Register to comment.