Understanding streaming timestamps
Hi,
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"
So,
a) What is the reason of these intervals between the timestamps?
b) How can I know the exact timestamp of each sample?
Thanks,
Marc
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"
So,
a) What is the reason of these intervals between the timestamps?
b) How can I know the exact timestamp of each sample?
Thanks,
Marc
This discussion has been closed.
Comments
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.
Thanks!
Marc