...
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.
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.
The bottom panel shows a close relationship between the NTPClockOffset and the time derivative of NTPFreqOffset, indicating how NTP adjusts the clock.
On a warmer 3 day period in July, where the temperatures were all above 5 degC, the temperature effect on the system clock oscillator is very evident.
Time Offsets During File Transfers
The periodic spikes in GPSdiff_max up to 1 second that occur at 23:00 local time and last about an hour, are simultaneous with the network transfer of the day's data files from the DSM to the RAL server. These indicate increased sampling buffering and latency is happening at these times, which needs to be investigated and improved.
At these times there is also a little bump in NTPFreqOffset. It is likely that this occurs . I can think of two possible causes of this. It could be due to increased interrupt load at these times, increasing the latency of causing increased latency in the 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 GPS clock has fallen behind the system 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
Or the bump could be caused by increased heating of the CPU and the system clock oscillator, under the due to increased CPU load caused by during the network file 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.
The bottom panel shows a close relationship between the NTPClockOffset and the time derivative of NTPFreqOffset, indicating how NTP adjusts the clock.
On a warmer 3 day period in July, where the temperatures were all above 5 degC, the temperature effect on the system clock oscillator is very evident.
, as described above. Also, when the ambient air temperature is very cold, the bump is diminished, or has the opposite slope. So my thinking at this point is that the bump is caused by increased oscillator heating.
PPSTEST
On the DSM, the ppstest program is helpful for gaining an understanding of the system and GPS clocks. It displays the system clock value when the interrupt function is called at the time of the assertion and the clear of the PPS signal. Do ctrl-C to terminate ppstest.
...