Results 1 to 3 of 3

Thread: NBP Protocol device error - Error detected in timing data?

  1. #1
    Potential Tuner
    Join Date
    Aug 2018
    Posts
    3

    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

  2. #2
    HPT Employee Weston@HPTuners's Avatar
    Join Date
    Jul 2014
    Location
    39.735034, -103.894459
    Posts
    868
    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...

  3. #3
    HPT Employee Weston@HPTuners's Avatar
    Join Date
    Jul 2014
    Location
    39.735034, -103.894459
    Posts
    868
    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...