NTP timing detailsΒΆ

The Raspberry Shake’s timestamping is based on NTP, where the NTP daemon program governs the local Raspberry Pi computer clock on a permanent basis, assuming a connection to the Internet.

Once the system is started, the program responsible for timestamping the actual data packets reads the local Raspberry Pi clock, using this time to stamp the actual data packets delivered by the micro-chip for onward forwarding.

During ongoing data processing, constant adjustments between the data packet processing program and the local clock are maintained, guaranteeing that any data sample will be within one sample interval of time.

For the different types of Raspberry Shakes, this means the timestamps will be within a margin of error based on the instrument’s sample rate, defined for each as:

  • The original Raspberry Shake (1D) - (data delivered @ 50Hz) - 20 Msecs
  • Raspberry Shake 3D, 4D and Raspberry Jam - (data delivered @ 100Hz) - 10 Msecs

Some things to keep in mind:

  • This accuracy very much depends on NTP maintaining access to the Internet to keep the local Raspberry Pi clock as close to real-time as possible. That is to say that timing is only good as NTP’s ability to govern the local clock itself.
  • After the NTP daemon has been running for a week, it has “learned” how the local Raspberry Pi clock drifts and becomes very good at maintaining good time even when not connected to the Internet for long periods of time. (of course, this assumes conditions affecting clock drift remain mostly constant when not connected to an NTP server).
  • If connection to an NTP server is lost for some time, timestamping will drift exactly in step with the drift of the local Raspberry Pi clock itself and the NTP client will continue to govern the local Raspberry Pi clock according to what it has learned over time in terms of its specific drift rate, keeping relatively good time
  • When an Internet connection is restored, and NTP makes a large adjustment to the local Raspberry Pi clock (large defined as >= one sample interval of time), the data processing program will do a hard reset of the data packet timestamp, thus forcing a timestamp re-sync with the local clock. This will necessarily result in a time-tear, either a gap or an overlap, depending on the direction of drift, which will be reported at /opt/log/odf_SL_plugin.info.
  • In “stand-alone mode” (see I have no Internet Connection. Will my Shake work?), data will still flow locally and use the system time for time stamping (It always uses the computer clock, whether NTP is running or not. The difference is if the clock disciplined by NTP). If there is no NTP, however, Raspberry Shake will recognize that the timing quality has been compromised and will not stream the data to the community server.