Metabase: Windows v Android version - timestamp issues
When using the Windows version of Metabase to capture Linear Accelerations from MMR the capture file shows timestamps (epoch ms) that are at irregular intervals and sometimes even have the same value for multiple data points that have different acceleration values e.g.
See Windows_MMR_2020-09-21T184.108.40.2065_E639F9D62615_LinearAcceleration_100.000Hz.xlsx attached. Note - the csv file was saved as .xlsx since this forum won't allow attaching .csv files. This behaviour is repeatable. What I expect is data points with timestamps 10ms apart.
I have run similar Linear Acceleration captures using Metabase on Android. The resulting file is as I would expect, 10ms intervals between each data point:
epoch (ms),time (16:00),elapsed (s),x-axis (g),y-axis (g),z-axis (g)
See Android_MetaWear_2020-09-21T220.127.116.112_E639F9D62615_Linear Acceleration_100.000Hz_1.5.0.xlsx attached.
I have also modified your example C# RealTimeGraph program to capture Linear Acceleration data and write out to a CSV file. The timestamps of each packet are as erratic as when running Metabase on Windows. I've attached the code snippet extracting the timestamp data from the packet.
Is the behaviour of the Windows version of Metabase (or other developed applications running on Windows) what you expect?
Model Number: 5
Motorola MotoG3, Android version 6.0.1, Security patch 1 April 2017
Lenovo IdeaPad Core i7, 8GB RAM
Windows 10 Home, version 2004, build 19041.508
This is normal.
When sensor data comes in from the sensor, the timestamp is created with the time on the final storage device. In your case it is either Android or Windows.
In the Android case, there is enough time for us to post process the really fast incoming data and create the proper timestamp.
In the Windows case, there is not enough time for us to post process the incoming data. This App was created when Bluetooth on Windows was "early".
Please note that all of your data is still accurate and good to use. What you need to do is post-process the Windows file yourself and update the timestamps (those are not accurate).
Please note this is a known issue and has already been cited in other forum posts.
So that I'm clear, for the Windows platform:
1. Timestamp data from Metabase or any app developed using the Metawear SDK is erroneous and unreliable
2. Any app consuming this data should disregard the timestamp and assume that the data points are at the frequency of the Output Data Rate configured for that sensor
Is this correct?