MetaBase Streaming Timestamps

edited March 2018 in Android
This discussion was created from comments split from: Data streaming using MetaHub (Android).

Comments

  • edited January 2017
    Hi!

    I have a different issue during data streaming with MetaHub (Android).

    I am running MetaHub 1.1.4 on Xiaomi Mi Note 3 running Android 5.0.2. 

    My MetaMotion R have firmware 1.3.3.

    When I stream the data from Accelerometer/Gyroscope/Magnetometer at specific frequency, I got this frequency in data in average, but time intervals are not uniform at all. Every time point have 2 duplicates (data writes 3 times at the same moment). And then the timer waits for triple expected period. 

    For example, in frequency 50 Hz I have elapsed (s) values 
    0.292
    0.292
    0.293
    0.352
    0.352
    0.352

    And the effective interval between really different times is not 0.02 s, but 0.06 s, which is 3 times more. So, effective real frequency turns out to be 3 times lower. 

    This is waste of Bluetooth channel and I can't get as much data as I want. The formal limitation of Bluetooth is 125 Hz of total records. So if I want to record Accelerometer and Gyroscope 50 Hz sampling, I will effectively have 16.6 Hz sampling. 

    I attach the screenshot of my example data in Excel:
    image


    So, can you change the firmware or the MetaHub app to work correctly?
  • You will never have reliable timestamps when streaming data via Bluetooth LE due to the sensors pushing out data faster than the devices exchange data through the BTLE connection.  As a way to increase the data throughput, the firmware can send 3 data samples per BLE packet so you can do things like sample acc and gyro data at 100Hz along with the magnetometer at 25Hz.

    The sensors produce data at very accurate intervals so you can relay on the sample count, time of the first element, and the ODR to reconstruct the timestamps if you need them.
  • edited January 2017
    Eric,

    So, I don't understand. Do you say that every sample creates at very accurate intervals, just the fields 'time' and 'elapsed' filled wrong? If I recalculate them, will everything be correct?

    Should this:
    0.000
    0.001
    0.002
    0.052
    0.052
    0.052
    be that:
    0.000
    0.020
    0.040
    0.060
    0.080
    0.100
    ?

    And what is ODR?
  • ODR is output data rate, which is included in the filename.  In your screen shot, the filename says 50Hz so that means the data is spaced at 20ms intervals.
  • Eric,

    So, I don't understand. Do you say that every sample creates at very accurate intervals, just the fields 'time' and 'elapsed' filled wrong? If I recalculate them, will everything be correct?

    Should this:
    0.000
    0.001
    0.002
    0.052
    0.052
    0.052
    be that:
    0.000
    0.020
    0.040
    0.060
    0.080
    0.100
    ?
  • Please, explain me the rules of streaming data.

    I need to understand how to regenerate time column by myself.

    Does Bluetooth send packages by 3 samples? 
    Should I recover all time grid with the information about all streaming period (total duration and total samples count), or I should recover time values only inside each Bluetooth package (it means I need to learn how to detect which samples were in the same package)? 

    I think, sometimes packages are lost and full uniform grid is not the best solution.
  • You know how often the sensor is sampling data and that MetaHub packs 3 data samples together.  Given these parameters, you can compute when every 3rd data sample should arrive.  If the next set of 3 samples has an elapsed time greater than the expected elapsed time, within a relative error if you want, then the rest of the data samples should use the erred elapsed time as the new reference point.

    A quick way to check if you have received all of the data is to dividing the number of received samples the by elapsed time of the last sample and compare it against the ODR in the filename.
  • Ok, thank you!

    About "dividing the number of received samples the by elapsed time of the last sample and compare it against the ODR in the filename":
    Result for one: 50.464395, for another: 49.510729 (per over 2 000 000 samples). So I think even if result would be 50.000 there could be some misses. 

    The question:
    Windows app MetaHub make timestamps in 12-hour format. So it is very uncomfortable to use them when my experiment if from 11:00 till 13:00 and from 23:00 till 01:00 next day. 
    Is there some setting so that I can change time format to 24-hour format?
  • Ah yes, that is a mistake in the code using the wrong hour formatter.  We'll address that in the next MetaHub update.
This discussion has been closed.