Metabase: Windows v Android version - timestamp issues

DAM

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.
1600670638628,2020-09-21T14.43.58.628,0.062,0.000,-0.003,0.005
1600670638628,2020-09-21T14.43.58.628,0.062,0.001,0.000,0.005
1600670638644,2020-09-21T14.43.58.644,0.078,-0.001,-0.053,0.014
1600670638664,2020-09-21T14.43.58.664,0.098,0.023,-0.378,-0.014
1600670638670,2020-09-21T14.43.58.670,0.104,0.032,-0.206,0.007
1600670638687,2020-09-21T14.43.58.687,0.121,0.002,0.348,-0.001
1600670638687,2020-09-21T14.43.58.687,0.121,-0.075,0.392,0.042
1600670638702,2020-09-21T14.43.58.702,0.136,0.010,-0.092,0.002
1600670638702,2020-09-21T14.43.58.702,0.136,0.003,-0.012,0.001
1600670638718,2020-09-21T14.43.58.718,0.152,-0.002,0.006,0.003
1600670638747,2020-09-21T14.43.58.747,0.181,-0.001,0.001,0.011
1600670638748,2020-09-21T14.43.58.748,0.182,-0.001,0.001,0.009
1600670638748,2020-09-21T14.43.58.748,0.182,0.000,-0.002,0.005
1600670638748,2020-09-21T14.43.58.748,0.182,-0.001,-0.001,0.003

See Windows_MMR_2020-09-21T14.43.58.265_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)
1600660365046,2020-09-21T11:52:45.046,0.000,0.000,0.000,0.000
1600660365056,2020-09-21T11:52:45.056,0.010,0.001,0.000,0.006
1600660365066,2020-09-21T11:52:45.066,0.020,0.001,-0.000,0.006
1600660365076,2020-09-21T11:52:45.076,0.030,-0.000,0.000,0.005
1600660365086,2020-09-21T11:52:45.086,0.040,-0.001,0.000,0.002
1600660365096,2020-09-21T11:52:45.096,0.050,-0.000,-0.001,0.004
1600660365106,2020-09-21T11:52:45.106,0.060,-0.001,0.000,0.005

See Android_MetaWear_2020-09-21T11.52.44.932_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?

Environment Info:
MetaMotionR
Model Number: 5
Firmware: 1.5.0
Hardware: 0.4

Android
Motorola MotoG3, Android version 6.0.1, Security patch 1 April 2017

Windows
Lenovo IdeaPad Core i7, 8GB RAM
Windows 10 Home, version 2004, build 19041.508

Laura

Hey @Dam,
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.

DAM

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?

Laura

1. No, it is reliable, you just have to reconstruct it.
2. Yes but you can just fix the timestamp, they are fine. The data just comes too fast for us to post-process and fix the timestamps, you can do that yourself easily.