Timestamp Error on MMR
We've been using MetaMotion R and logging sensor fused acceleration data to flash, and transferring to iOS devices using our own app. The sensor is using latest firmware 1.44 and HW version is 0.3.
We noticed suddenly jumping in one timestamp, going from normal timing of 8.x seconds, jumping to 6152 second, then back to 8.x seconds. (See screen shots below).
This occurred twice in about an hour period when we were collecting multiple 30 seconds data sets. The sensor cached was flushed, disconnected and reconnected to iOS app in between each data set,
Example 1: 7.540 sec -> 6151.55 sec -> 7.559
Example 2: 8.29 sec -> 6152.306 sec -> 8.31 sec
Please advice. Thank you.
Comments
Seems like whatever tool you are using to read the data is not reading it correctly. This happens in excel all the time because it attempts to read a Number as a String or Date instead.
Try opening the same file using a different viewer like VIM or NOTEPAD. You will see there isn't an issue at all.
Hi Laura,
This is not an editor issue.
Below is the actual epoch times received from the sensor.
Jumped from 1550050851.54 to 1550056995.549 then back down to 1550050851.559
Thanks
I can't reproduce on my side as I am not getting this error with timestamps and no one has filed a similar error.
Can you re-install the app, try with other devices and get back to us.
Worst case, just fix the timestamps by hand.
We are using v3.1.9 of iOS SDK.
We've been using 8 different MMRs the last few months without this issues.
Issue did not reproduce in MetaBase app. That is not surprising since within that one hour period we had about 45 normal samples, and 2 error samples.
Yes, we will do more stress testing on that specific MMR and other MMRs to see if it happens again.
@Eric, @Laura
My team did more digging into the pervious results.
In addition to the 2 incident reported above, the same sensor produced 6 additional incidents in Feb, 2019. We have 8 total.
A different MMR had 3 incidents out of 404 samples taken over three days in Nov 2018
All 11 incidents showed single timestamp jumping into 6100 range.
@Eric, @Laura
We found a third MMR with timestamp error. There were 5 incidents out 279 samples taken between Oct 29 - 30, 2018.
We also found more incidents, 10 out of 1002 samples taken during that period by the second MMR reported yesterday.
All incidents shoes single timestamp jumping to 6100x seconds range.
All samples were logged sensor fused acceleration and MF data. We log about 30 seconds worth of data, download to iOS, clear sensor cache, and repeat. This usually goes for 2-4 hours continuously.
Can you post a minimal function that creates this issue?
@gjin,
Please send reproducible steps, we still aren't seeing this error and no reports from other users either.
@Laura @Eric
We are logging sensor fused Acceleration and MF data simultaneously, then download from log to iOS. We just read the timestamp that's in the log, and have no code relating to timestamps.
Each sample is about 30 seconds in duration.
Getting a sanitized code/function to share will take some time. Would you guys be able to run stress testing with logging of sensor fused accel + mf using your test rigs, and see if that combo triggers the issue?
Thanks
Code describes what you are doing much better than words. Furthermore, there is no point in us recreating your code.
@Eric
Here is snippet of what we do to start and stop logging
Thanks, we'll give it a try.
@Eric
We had a fourth sensor showing the timestamp jump issue.
We also noticed that with all 14 incidents across 4 sensors, the amount of seconds changed is the same: 6144 seconds.
In my two examples above:
Hopefully this clue helps with identifying the culprit.
@gjin,
Do you ever get this timestamp issue when you use our MetaBase App instead of the APIs?
@Laura
We are trying to repro the problem with MetaBase App, but found this problem with the app.