Inconsistent streaming frequency


I am having some issues with sensor streaming frequency when collecting data from two MetaMotion R sensors simultaneously. 

  • When streaming Euler angles at 100Hz, the elapsed time increases inconsistently (i.e., the collection frequency varies throughout the duration of the trial). As well, the time stamp does not match the elapsed time (the number of significant figures suggests that the time stamp should increase by 0.01s each frame, but this is not the case). This issue occurs when also streaming Quaternions at 100Hz. 
  • When streaming accelerometer, gyroscope, and magnetometer data simultaneously (each at 25Hz), the elapsed time reads the same value 3x in a row (for accelerometer and gyroscope), however the x,y, and z columns continue to change. The elapsed time readings between groups of 3 frames is also inconsistent. The magnetometer elapsed time reading increases from frame to frame, however it still increases inconsistently (i.e., not by 0.04s each frame). These issues are the same when collecting these three simultaneously, or individually, and at different frequencies. 
  • The number of samples per sensor is then different between the two sensors during simultaneous collection, and during the same trial.
These issues are very problematic for our research, as so much relies on timing and accuracy of the sensors. Here is a link to a folder containing Quaternion, Acclerometer, Gyroscope, Magnetometer, and Euler angle data:

Do you have any suggestions as to why this might be happening? And if so, are they able to be addressed and fixed?

Thank you,



  • edited December 2017
    Timestamps for streamed acc, gyro, and mag data with the MetaBase app are discussed here:

    Given that you are recording data from multiple sensors (and devices) simultaneously to one device, I suggest logging the data instead of streaming it live.  If you want to continue streaming data, you will need to post process the data to recalculate the timestamps as described in the above post.  
  • Thanks! 

    This project requires data to be recorded from 9 sensors at once using a raspberryPi, and multiple bluetooth dongles. It is required to collect either: 

    1) Magnetometer (25 Hz) + Gyroscope (100 Hz) + Accelerometer (100 Hz); or
    2) Euler angles (100 Hz)

    Would you suggest logging in this case over streaming data? The maximum time for a trial is approximately 4 minutes. When streaming raw data- the BLE bandwidth is exceeded (i.e., 25 + 100 + 100 = 225 Hz > 100 Hz). Does this cause any issues? 

    When streaming Euler angles at 100 Hz, we are experiencing connection issues (i.e., the ability to connect to all sensors occurs very rarely - it is very unpredictable which sensors will connect). Do you have any suggestions as to why this may be occurring?

    We have tried:
    • Charging all sensors fully.
    • Using 1 raspberry pi, with multiple bluetooth dongles each, to try to reduce the frequency bandwidth of each dongle.
    • Using 2 raspberry pis, with multiple bluetooth dongles each, to try to reduce the frequency bandwidth of each dongle.
    • Reducing collection frequency of all sensors to try to minimize the collective streaming frequency bandwidth.
    Also, do you have any suggestions on how to increase the reliability of sensor connectivity during all trials?

    Thank you very much for your help!

  • Since you have multiple dongles, both streaming or logging will be fine.  If you're streaming, make sure your app and board are properly configured for high frequency streaming and you will be able to collect data at your required rates:

    There's no one specific root cause for connection issues; it could be the BLE stack, adapter, or library.  Your code should handle connect errors and attempt to reconnect should one arise.  You may also need to reset the adapter from time to time.

    If you are not already, try writing your app with the JavaScript SDK as Noble seems to be the best BLE library for Linux.
  • Thanks for the quick reply! We will give this a go.
This discussion has been closed.