Understanding streaming timestamps


I need to stream data from a MetaMotion R board, firmware version 1.3.3.

At this moment, I am using Metawear C++ API 0.7.14 in a PC.

I am doing some tests streaming only accelerometer data at different rates. However, I observe that received samples are grouped with the same (or consecutive) timestamps, and for each group of samples received (with a number of samples not necessarily constant) I find and big jump of timestamps.

To take a concrete example, see the following timestamps (in milliseconds) from samples received from the accelerometer configured at 50Hz:

timestamp          elapsed(msec)
-------------           -------------
1488456803859 0
1488456803860 1
1488456803861 1
1488456803861 0

1488456803929 68
1488456803929 0
1488456803930 1
1488456803931 1

1488456803999 68

1488456804069 70
1488456804070 1
1488456804071 1
1488456804071 0
1488456804072 1
1488456804073 2

Taking 10 seconds of samples, I obtain an average frequency of 50.47Hz, which is quite near to 50Hz, but considering the time between samples, which must be 20msec, it is not.

From the documentation I understand that the timestamp from MblMwData::epoch corresponds to the data of creation:

"Timestamp of when the data was created"


a) What is the reason of these intervals between the timestamps?

b) How can I know the exact timestamp of each sample?



  • Thanks Eric. I've read it, but it is still not clear for me.

    In the thread, you say that firmware can send 3 data samples per BLE packet, but that is not a rule, isn't it? I can see groups of 1 sample, 3 samples, 6 samples... It seems like BLE firmware is using best effort to send samples.

    We need a timestamp as much accurate as possible for each sample, so we need to understand:

    a) How does it works.
    b) What is the worst case error in milliseconds (i.e. the accuracy) between the timestamp of a sample and when was the sample really created.
    c) The best way to readjust the timestamps.

  • The thread I linked explains how to reproduce timestamps if desired.  If you need accurate timestamps, you should log the data instead of stream it as you will never have exact timestamps from a stream.
This discussion has been closed.