NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
Configuring Motorola ONCORE Refclocks Development Discussion
Here is where we discuss the stuff from ConfiguringMotorolaOncoreRefclocks
Please chime in below...
After reading several times the 3.42-3.45 pages of the Motorola Oncore User's Guide V5.0, I understand that:
- The PPS output is adjusted to the top of the second.
06.09.2004 9:10:46 000000
- The "Measurement epoch" T(k) is the point in time at which the receiver makes satellite range measurements to set a position. The Measurement epoch starts 0-1 ms after the PPS output.
06.09.2004 9:10:46 850225
is 850225ns=0.850225ms inside the 0-1ms range.
- The resulting time data displayed in the
@@Hb messages is the best estimate of "local time" corresponding to the T(k) "Measurement epoch". The data (
@@Hb message) output 0 to 50 ms after the T(k).
- The "local time" is an UTC or GPS time specified by the Time Mode (I have used the @@Aw command to set GPS time).
- The T(k) "Measurement epoch" "local time" accuracy is supposed to be approximately 20 to 300 ns depending on satellite geometry and the effects of selective availability.
Following the example, the @@Hb time received would be:
06.09.2004 9:10:46 850225
I try now to obtain the PPS output accurate timing details using the T-RAIM Status message (@@Hn).
The @@Hn response message includes a "negative sawtooth time error of next 1PPS pulse".
To use the T-RAIM function the receiver must be in "Position-Hold" mode.
The @@Gd command set in option 3("enable autosite survey") averages 10000 position fixes and then force the receiver in to "Position-Hold".
How can I be sure that the receiver is in "Position-Hold"?
I look the "Autosurvey Mode" information included in the @@Hb response but it is always 1.
- The time included in the @@Hb answer has the format
hmsffff: hours, minutes, seconds, fractional second(ns). Is this the exact GPS time?
- Data Latency: The Oncore receiver can output position, velocity, and time data on the TTL port once each second. The start of the output data is timed to closely correspond with the receiver measurement epoch. The measurement epoch is the point in time at which the receiver makes satellite range measurements for the purpose of computing position. The first byte of TTL data in the position message is output beetween 0 and 50 ms after the most recent Oncore receiver measurement epoch.
Refer to figure 3.11 for the discussions that follow
Let T(k) be the most recent measurement epoch. The Oncore Receiver takes about one second to compute data from the satellite range measurements. Consequently, the data output 0 to 50 ms after T(k) represents the best estimate of the position, velocity, and time based on the measurements taken one second in the past, at time T(k-1). Position data (latitude, longitude, and height) is computed from the most recent measurement epoch data, and is output immediately after the next measurement epoch, which is 1.0 to 1.05 seconds after the original measurements were taken.
Note that the time scale is selectable to either UTC or GPS time.
- Also note that the pulse is NOT sync'd to GPS time!! It is derived from a local 1 KHz osciillator and not synchronized with anything! That is why you get fractional seconds. You can, if you wish, adjust the PPS output to synchronize it with something but, as far as I know, it is not necessary. ntpd is quite capable of dealing with fractional seconds!
- Of course it is sync'd to GPS time, even if 'synchronized' might not be the right word. The 1 PPS output is the best reconstruction of GPS time the receiver can build; not exactly 'synchronized' but the result is identical: 1PPS gives you access to GPS time.
I have at work a continuous flow of data from several oncore units of different generation timed against different atomic clocks, that show each second that the 1 PPS is a realization of GPS time.
Unprocessed, it is only affected by negative sawtooth, thus showing peak-to-peak variations of 30 ns in the short term. When corrected from the negative sawtooth, the jitter at 1-sigma is around 3-4 ns (I don't mean accuracy).
- The PPS signal is not synchronized to the "top of the second!" It merely marks the receiver epoch. The receiver epoch is arbitrary! The serial output tells you the time, fractional seconds and all, marked by the leading edge of the pulse.
- I think it is: https://www.bhargavaz.net/gps/ch3.pdf
Page 39 (3.38):
1 PPS rising edge = top of second - 1PPS cable delay + 1PPS offset.
(where cable delay and 1PPS offset are user-controlled parameters that can be adjusted to fit the user's setup)
Also figure 3.12 page 3.37 shows the 0-1 ms variable delay between 1 PPS and measurement epoch.
- The text you cite says that "The 1PPS can also be positioned anywhere in the one second window using the 1PPS Offset Command.."
On page 3.36 you will find "When the receiver starts, it defines the first clock cycle as the measurement epoch. Every 1000 clock cycles from that point define the next measurement epoch."
- Yes. What is your point here? By default the 1PPS is on top of the second, modulo cable delays.
- I interpret these texts to mean that the measurement epoch, and thus the position of the PPS signal relative to the top of the second is random!
- Agree for the measurement epoch, at least at boot time; but it will not remain random (see below).
As for the 1 PPS, your interpretation is false, but I admit these pages of oncore user's guide are far from being clear.
Nevertheless, page 3.37 again:
"The oncore observes the error between actual receiver local time and the desired measurement epoch and then slips the appropriate integer milliseconds to place the measurement epoch to the correct millisecond.
"When a time skew occurs (such as after initial acquisition [...]), the receiver lengthens or shortens the next processing period in discrete one ms steps.
This explains how the measurement epoch is kept within 1 ms from 1PPS (figure 3.12), and how the initial "randomness" of the measurement epoch is solved as soon as measurements are available.
- This position can, but need not, be set by whatever software you are using to whatever pleases you.
- Sure. But its default position is on top of the second, as it is clearly stated by :
1 PPS rising edge = top of second - 1PPS cable delay + 1PPS offset
- Further, if the PPS occurs at the top of the second, what possible explanation is there for fractional seconds in the serial output?
- This was the initial question. And I think the answer is now clear: it is the time stamp of the measurement epoch.
I can only speak from experience using various versions of the Oncore and M12+ for applications where the 1pps signal is used directly, without making any use of the serial data output at all.
And all that experience is that unless you have used one of the receiver commands to move the position of the pulse (e.g., to account for cable or instrumentation delay), the 1pps output when the receiver is locked is as close to the GPS second mark as the receiver can get, plus or minus the sawtooth (more significant in the earlier receivers than in the M12+ Timing unit).
I've compared various Oncore receivers to other time sources (such as WWVB receivers) as well as to each other, and the pulses have always been in sync within the accuracy of the sources (admittedly, the WWVB accuracy as received is measured in milliseconds rather than nanoseconds).
There are many applications of these receivers (e.g., time synchronization in digital cellular systems) that use the 1pps pulse for time synchronization without any reference to the serial data stream, and these wouldn't work unless the 1pps was in fact synchronized to the second.
Richard Gilbert replies to:
- Just to make sure I understand you, the time in the @HA is the exact time that the PPS pulse occurred at?
I believe it's the exact time of the leading edge of the pulse.
Francois Meyer disagrees.
I do believe that he has established that the leading edge is within one millisecond of the "top of the second" but not that it's exactly the top of the second.
And Francois replies:
Would a third party data set of raw 1PPS pulses against a reliable time scale convince you ?
And Richard replies:
Not until I understand where the fractional seconds in the timestamp are coming from.
At the moment, my receiver is synched and the timestamp shows a fractional part of 0.00058. . . seconds.
The manual says, and the reality appears to agree, that the receiver adjusts its measurement epoch and the signal that marks it, to within 1 millisecond of the top of the second.
My receiver appears to be about 580 microseconds late which is well within the one millisecond that the manual mentions.
I can also find instances in which the pulse appers to be a few microseconds ahead of the top of the second according to the timestamp.
It is clear that the receiver can be programmed to place the pulse anywhere you want it but it also seems clear that the receiver reports the exact time measured at the previous measurement epoch plus 1.0000000 seconds to allow for the processing delay.
It appears to me that if the measurement epoch is adjusted to exactly the top of the second, the pulse would occur at the top of the second and the fractional part would become zero.
ntpd does not appear to do this.
You do not appear to agree with this interpretation and I do not understand why not.
Instead, you assert without any proof that I can see, that the PPS marks the exact top of the second without regard to any fractional seconds reported in the serial output.
The evidence you cited shows the PPS output of four carefully tuned receivers tracking the USNO pulse within a few nanoseconds but it does not show the the corresponding timestamps and whether or not they exhibit fractional seconds or not.
And Wolfgang then asks (about the previous paragraph):
Is the point of contention the so-called "sawtooth" caused by the PPS output being constrained to be on some integer multiple of an internal clock?
If so should the @HA time also have the same sawtooth as the time drifts between the two trip points?
(I don't know if it does, I need to find my old data.)
The curve shape of the @HA fractional second might be some indication that it is related to this PPS sawtooth.
The time that you get in a @@Ha message is the time of transmission of that @@Ha message.
It is not
the time of the PPS pulse.
The timing of all the messages that the GPS module sends out over its serial interface is at the mercy of the module's multitasking scheduler; in other words, the serial messages can be delayed if high-priority tasks need to be serviced.
The module takes account of the delay and adjusts the timestamp accordingly -- that, including the fractional second information, is what you see in @@Ha.
The PPS ticks take a completely different signal path through the GPS receiver.
The fact that they have a sawtooth error limited to +/- 128ns implies that they are strobed from an oscillator running at around 4MHz.
The ticks are timed to occur exactly on the GPS/UTC second (after applying the sawtooth corrrection) (unless you've deliberately shifted them with @@Ay).