You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

The turbulence tower data system (aka, the DSM) uses a GPS receiver and the NTP software to set its clock, which, in addition to the normal uses of the system clock, is used to time-tag the data samples.

The serial messages from the GPS are received on serial port 3, /dev/ttyS3. The pulse-per-second square-wave signal (PPS) from the GPS is also connected to the CTS line of that serial port. The PPS patch has been added to the Linux kernel on the data system so that an interrupt function can be registered to run in response to the CTS interrupts. This interrupt function will be called immediately after the rising edge of the PPS signal has been detected by the serial port hardware.

The NTP software on the DSM runs a reference clock driver for a Generic NMEA GPS Receiver, with PPS. This driver reads the 1 second GPS RMC records from the serial port, and registers a function to be run on receipt of the PPS interrupt. NTP then uses these two sets of information to adjust the system clock.

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 receipt time of the RMC is not used as a reference for adjustment of the system clock. NTP simply uses the time fields within the RMC message as a label for the previous PPS, whose timing is very precise.

We monitor the following variables to keep track of the DSM timekeeping:

  • GPSdiff: The time difference, in seconds, between the system clock 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 sample is the value of the system clock at the moment the first byte of the sample 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.

NTP on the DSM is configured to log information about time-keeping in a "loopstats" file. See http://www.eecis.udel.edu/~mills/ntp/html/monopt.html for information on the NTP monitoring options.

  • NTPClockOffset: the estimated offset of the GPS time from the data system time. A positive value indicates the GPS clock is showing a later time than the system clock.
  • 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 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.

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:

data_dump -i 1,30 -A manitou_20110412_120000.bz2 | fgrep GPS
...
2011 04 12 16:41:39.6568    0.15      49 $PGRMT,GPS 25-HVS VER 2.50 ,P,P,R,R,P,,23,R*08\r\n
2011 04 12 16:42:50.4248  0.1249      51 $PGRMT,GPS 18x-LVC software ver. 3.10,,,,,,,,*6D\r\

Unexpectedly, the newer GPS provided much better time-keeping.

The following plot is for the old 25-HVS model for 3 days prior to the swap:

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 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.

After installing 18x-LVC, the NTPClockOffset is in a much smaller range, from -10 to 25 microseconds:

GPSdiff is also much better behaved, ranging from a minimum of 0.5 to 1.1 seconds. The number of satellites tracked by the new GPS is also generally higher.

  • No labels