NBP Protocol device error - Error detected in timing data?

Printable View

10-29-2018
tmkdev

NBP Protocol device error - Error detected in timing data?

Working on my implementation of NBP - what would cause this error in the data log?

40.873,1540708202.873,1,0.000,33.1228245,-117.2735884,42.5,140,9.8,281.0,3.2,0.12,0.06,0.00, 0,14.608,166,2.250,0.000,0.000,765.750,0.000,1.000 ,30.273,0.000,2.000,0.219,0.000,30.875
40.919,1540708202.919,0,0.000,33.1228245,-117.2735884,42.5,140,9.8,281.0,3.2,0.09,0.08,-0.00,0,14.608,166,2.250,0.000,0.000,765.750,0.000, 1.000,30.273,0.000,2.000,0.219,0.000,30.875
40.931,1540708202.931,0,0.000,33.1228245,-117.2735884,42.5,140,9.8,281.0,3.2,0.08,0.08,-0.01,0,14.608,166,2.062,0.000,0.000,690.000,0.000, 1.000,16.119,0.000,2.000,0.062,0.000,31.000
# Error detected in timing data
# Error detected in timing data
# Error detected in timing data
.
.
# Error detected in timing data
# Error detected in timing data
57.118,1540708219.118,1,0.000,33.1241580,-117.2742679,44.6,146,38.5,323.2,3.2,0.03,0.08,-0.01,0,14.585,209,0.188,0.000,0.000,1386.000,29.88 0,1.000,1.573,0.000,5.000,0.391,0.000,1.875
57.167,1540708219.167,0,0.000,33.1241580,-117.2742679,44.6,146,38.5,323.2,3.2,-0.10,0.07,-0.02,0,14.585,209,0.188,0.000,0.000,1386.000,29.88 0,1.000,1.573,0.000,5.000,0.391,0.000,1.875
11-06-2018
Weston@HPTuners

I've been looking into this, trying to determine how this may have happened, under the assumption that it's not just a hardware clock issue. I should be able to isolate the cause, and issue an app update (if need be) by the end of this week...
11-07-2018
Weston@HPTuners

Updates...

This error is logged when we think we're trying to write a log entry with a timestamp that is before the last one we had written. It was designed to detect device timing issues and prevent them from messing up the log timing too much, which had previously been an issue with some older Samsung devices.

My best working theory in this case is that there may have been a bunch of individual NBP updates coming in at the same time (or at least being processed at the same time; Bluetooth may sometimes lag and queue up a bit), and then it's possible that a floating point precision issue could have caused identical timestamps to appear to have gone backwards ever so slightly. That doesn't quite explain the log you posted above, but it's a great fit for the one you attached to the ticket you submitted to our support system.

So, there's two things we can do here:

1) If practical, try to make sure that any NBP update packets you send include as many channels as possible, rather than sending a bunch of separate update packets for one channel at a time.

2) TrackAddict v4.2.1 adds additional data when this timing error occurs, and improves the detection logic to mitigate floating point precision issues. ETA later this week...