Ed, first of all, welcome to the mail list! I have been lurking here for some time now and wanted to try an apply what I have learned about NTP to your question. I, too, haven't posted on here before, so please forgive me if I have quoted his question wrong, and replied incorrectly.
I believe that as long as the pulse is consistent , the fact that it is 'early' should make little to no difference. To give an example from my experimentation with using GPS receivers and independent rubidium oscillators for the PPS input into NTP, I found the following to be true: 1) that a PPS signal alone (without any NMEA strings from the GPS receiver) requires a 'prefer' peer configured in the ntp.conf file (as is stated in the refclock driver docs) to "number the seconds" - or in other words - to give NTP an idea exactly what second that it is seeing from the PPS source. I have taken to calling these "epoch seconds" or "numbered seconds". 2) that a PPS signal from an oscillator (one which ticks seconds, but not necessarily "the" second, or "epoch seconds") is going to be pretty accurate and give a good timing source but its second is going to be offset from the "true" or "epoch second" based upon when you powered it on. Since it's not locked to any "true" source, and is simply going to give you a very accurate pulse every second on its own schedule, I have taken to calling these "orphan seconds". 3) when NTP sees a PPS source from GPS (again, no NMEA strings, just the PPS signal), it checks with its 'prefer' peer and sees the numbered second, the "true" second, and is pretty happy with the GPS PPS source. (that is, assuming, it's 'prefer' peer is using GPS or the like to number ITS seconds) When NTP sees a PPS source from an oscillator, since the same driver is being used, it also checks with its 'prefer' peer, sees the numbered second, and is NOT at all happy with the PPS source (and will de-select it and mark it as a falseticker) since it is offset by some random amount from the "true" second. It may be giving a PPS, but they are "orphan seconds". 4) I have found that the solution to "orphan seconds" using the "PPS Clock Discipline" driver listed here: http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html is to adjust the time1 fudge factor to an offset that matches how far off the oscillator "orphan seconds" are from - say - a GPS sourced "epoch second". This offset should be entered in SECONDS on the fudge line for that driver. 5) to be very clear, let me draw a picture here. Below, "J" is a PPS from a GPS source ("epoch seconds") and "K" is a PPS from an oscillator ("orphan seconds"). They are 242ms apart in the diagram: ...K...242ms...J...758ms...K...242ms...J...758ms...K...242ms... I would then set the time1 fudge factor for this driver to -0.242 (or, I guess 0.758) 6) I was told that (with a similar driver, the NMEA driver here: http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html ) as long as the PPS is within 500ms that NTP can correlate the two. I haven't found that to be true with the PPS Clock Discipline driver. 7) this fudge factor is going to drift over time, since that independent oscillator isn't being disciplined from a source of "epoch seconds". How much it will drift and when depend on the oscillator. 8) I would say that "close enough" really depends upon your application. These "orphan seconds" could also come from - say - a 10MHz source that has been divided down to 1Hz (or a PPS). That, too, is going to give you very accurate seconds, but not necessarily "THE" second since it is going to change depending when you turned it on. I think that with the correct fudge factor and your source, that you will find a very nice, accurate, fudged clock for inputting the PPS into your Raspberry Pi. (something I, too am experimenting with and have several Pi set up and running NTP). Cheers! -Randal "r3" -----Original Message----- From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Ed Armstrong Sent: Tuesday, 09 June, 2015 22:30 To: Discussion of precise time and frequency measurement Subject: [time-nuts] PPS for NTP Server - How Close Is "Good Enough"? Hi, this is my first post ever to a mailing list, so if I'm doing anything wrong please be gentle with your corrections :-) A short time ago I purchased a Nortel/Trimble NTGS50AA GPSTM, I'm sure many on this list are familiar with it. At the time of purchase, my only interest was the 10 MHz output, for use with my HP5328b frequency counter and perhaps in the future also my signal generator. No question here, it just works great as is. However, it certainly seems best to leave these devices powered up all the time. OK, now were getting close to my question. The unit pulls about 10-11 watts, which is really not very much. But it kinda bugs me to have it sit there using electric and basically doing nothing when I'm not using it. So, I bought a Raspberry Pi 2 with the intent of using it as an NTP server. I can't really say I'm enjoying my intro to Linux a whole lot, but I'll get there. It still needs some work, but it does function with the PPS output from an Adafruit ultimate GPS, which I bought for testing this and possibly building my own GPSDO in the future. The NTGS50AA is a very capable device, but unfortunately it does not have a PPS output. Instead it has an even second output, which goes low for approximately 50 ns. The falling edge of this pulse marks the beginning of the second. During my search for a solution to this, I came across a post from this mailing list which I believe was discussing repair of one of these units. Someone in that post mentioned that there was a PPS signal at test point 33 which went low for about 10 µs. Thank you, that saves me a lot of probing. The first thing I did was verify that this pulse did exist, then I decided to examine it a little closer. I kind of suspected that it may have been a rather raw pulse as received from the satellites. I found out that is not correct, once the unit successfully phase locks, this PPS signal is very accurately tied to the 10 MHz output, even when the unit goes into holdover mode. I was very happy about this :-) Next step was to see how accurately it was synced to the even second pulse. The bad news is that it does not occur at exactly the same time as the even second. The good news is that the offset is very consistent, 253 ns before the even second pulse, +/- 1 ns. My next step was to find out where the even second pulse entered the output circuitry. I then broke the trace taking the even second into the output circuitry, and ran a piece of 30gauge wire wrapping wire from the via at test point 33 to the via at the input to the output circuitry. The wire fit so perfectly it felt like the vias were made for just this purpose :-) Now I've got a very nice PPS signal available both at the front jack and at the backplane connector in the rear of the unit. OK, here is the actual question. Do you think it is OK to consider a pulse which arise 250 ns early to be close enough? And no, I am not forgetting about that 3 ns, there is about 3 ns of delay added by the output circuitry. Hope you didn't mind the long-winded post, and I thank you in advance for any advice you offer. Ed _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
