NTP and GPS
The turbulence tower data system (aka, the DSM) uses a GPS receiver and the NTP (Network Time Protocol) software to set its the system clock, which, in addition to the normal uses of the a system clock, is used to time-tag the data samples.
...
The RMC records contain the current date and time, in addition to latitude, longitude, and other quantities. The transmission time of the RMC message is not tightly controlled and appears to be primarily effected by lags associated with internal GPS processing, and is also likely effected by what other messages are enabled for output on the GPS. The exact receipt time of the RMC message is not used for clock adjustments. NTP simply uses the time fields within the RMC message as a an absolute time label for the previous PPS, whose timing is very precise.
Clock Variables
We monitor the following variables to keep track of the DSM timekeeping, and plot them on the daily web plots:
- GPSdiff: The time difference, in seconds, between the time-tag that was assigned to a RMC message and the date and time that is contained within the message. The time-tag assigned to a message sample is the value of the system clock at the moment the first byte of the message was received. For example, a value of 0.6 secs means that the data system assigned a time-tag to the RMC message that was 0.6 seconds later than the time value contained in the message. GPSdiff will be effected by processing lags within the GPS, DSM data sampling lags, and the drift of the DSM system clock relative to the clock within the GPS receiver. When 5 minute statistics are computed, the maximum and minimum values of GPSdiff for each 5 minute period are written to the output NetCDF files as GPSdiff_max and GPSdiff_min, and then plotted on the daily web plots.
- GPSnsat: number of satellites being tracked by the receiver, that is, the number of satellites whose signals are used in the time and location solution.
...
- NTPFreqOffset: the correction applied to the system clock frequency in parts-per-million, a positive value indicates that NTP has determined that the system clock oscillator is slow and the frequency offset is being added to the system clock values.
The NTP values logs have not been recorded consistently since the beginning of the project. Data in 2010 from May 3 to August 12th and Oct 14th to November 9th are available, as well as all data from April 9, 2011 onward.
New Garmin 18-LVC GPS
On April 12, 2011 the old Garmin GPS 25-HVS at the tower was replaced with a much newer Garmin 18x-LVC model. The model numbers are shown in the $PGRMT messages, where the time is UTC:
...
The NTPClockOffset_max ranges from approximately -1000 to 50000 microseconds during that period. The upward spikes in NTPClockOffset_max are simultaneous with positive jumps in GPSdiff_max, up to as much as 2.5 seconds. These jumps in GPSdiff_max also seem to happen when the number of received tracked satellites changes, indicating that internal processing lags in the 25-HVS cause it to report late. It is unknown if the PPS signal is effected by these events. At these moments, NTP estimates that the system clock is early relative to the GPS, and starts to correct for the error by speeding up the system clock, seen as the positive spike in NTPClockOffset and NTPFreqOffset. When the GPS recovers from its delayed reporting, then NTP sees that the system clock has gotten ahead of the GPS, reports a negative NTPClockOffset and gradually returns to the previous frequency offset.
...
At these times there is also a little bump in NTPFreqOffset. It is likely that this occurs due to increased interrupt load at these times, increasing the latency of interrupt function that is called in response to the PPS interrupts. Increased latency in response to PPS interrupts should cause NTP to think that the system clock is ahead of the GPS clock, but the NTPClockOffset at these times is positive, and the slope of NTPFreqOffset is positive, indicating that NTP thinks the GPS clock is ahead. The bump shows up at cold ambient temperatures, so I don't think it is due to increased heating of the CPU card and the system clock oscillator, under the increased CPU load caused by the network transfers. The sign of NTPClockOffset is consistent with a heating effect (described below) however. One could check to see if the effect is diminished at colder outside temperatures.
Temperature Effects
As expected, the frequency offset shows a temperature dependence in the system clock oscillator. We do not have a measurement of the temperature inside the data system. The top panel in the plot below shows a time series of the ambient air temperature at 2 meters on the tower, along with the NTPFreqOffset, for a cool 3 day period in April. When the ambient air temperatures is below 5 deg C, the system clock oscillator does not show an obvious temperature relation.
...