Accounting for non-contiguous timestamp when recording in synchronized logging mode

In synchronized logging mode, it is possible for monitors in the "mesh" to record data with non-contiguous timestamps under the following conditions:

  1. The monitors were recently undocked and they have not yet synchronized their clocks.
  2. Following initial synchronization, one or more monitors have lost communication with one another and their clocks have drifted enough during this period to require a correction after they regain communication and re-synchronize.
These jumps do not indicate periods where no data was recorded, but rather instances when the clock on the monitor was re-adjusted in order to synchronize with the rest of the mesh. During this synchronization process, the clock values will only jump forward in time, and never back.
The following example describes how to detect a timejump using Matlab and an HDF file named "file.h5" for monitor "BE-000001":
syncVals = hdf5read('file.h5','/BE-000001/SyncValue');
jumps = diff(syncVals);
[jumpSizes firstJumps jumpLocations] = unique(jumps,'first');
[jumpSizes lastJumps jumpLocations] = unique(jumps);
numberOfJumps = sum(jumpLocations ~= 1);
firstJump = min(firstJumps(2:end))+1;
lastJump = max(lastJumps(2:end))+1;
  • jumpSizes indicates all of the unique jumps in the syncvals. A normal sampling interval at 128Hz is 20 syncvals, so jumpSizes should include 20 as the first value.
  • numberOfJumps indicates the number of jumps > 20 syncvals. 
  • firstJump indicates the location of the first jump > 20 syncvals
  • lastJump indicates the location of the last jump > 20 syncvals
Under the assumption that the mesh is synchronized at the end of the recording. The following code will allow you to create a new vector of syncvals for the recording without the jumps:
newSyncVals = fliplr(syncVal(end):-20:(syncVal(end)-length(syncVal)*20));
Have more questions? Submit a request


Article is closed for comments.