Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
On Fri, 12 Jun 2015 18:29:29 -0400 Ed Armstrong eds_equipm...@verizon.net wrote: The Ethernet on the Raspberry Pi is on the USB bus. That adds about a 1/2 ms of jitter. Is it possible to modify the kernel so the USB is polled more often, and would that significantly reduce the jitter? Yes. You can add more interrupt slots per frame. IIRC there was an upper limit on how many you can add (sorry, I don't remember any specifics, it's been some time since I read the USB standard). What you need to ensure as well is, that the device itself does nothing weird with the data, aka that any pipelining and collation is turned off. Attila Kinali -- I must not become metastable. Metastability is the mind-killer. Metastability is the little-death that brings total obliteration. I will face my metastability. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the metastability has gone there will be nothing. Only I will remain. ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
Hal, what stopped me from going down the BBB path was the reports of RF noise, they supposedly create a lot of noise. Not acceptable in an HF environment. Google around about the RF noise with the BBB. mg NG7M On Sat, Jun 13, 2015 at 12:02 AM, Hal Murray hmur...@megapathdsl.net wrote: eds_equipm...@verizon.net said: Is it possible to modify the kernel so the USB is polled more often, and would that significantly reduce the jitter? Modifying the kernel may not be enough if the timing parameters are in the microcode for the USB device. Whether any improvement is significant probably depends upon your goals. It's unlikely to become a great NTP server. If I wanted a good low power NTP server, I'd probably start with a BeagleBone Black. I haven't seen a low cost no-assembly-required GPS board for the BBB (There is at least one GPS board for the BBB, but it includes a cell phone modem which doubles the cost.) I'd probably try the GPS breakout board from SparkFun. It should take 5 wires: power, ground, trans, recv, and PPS. (and then the appropriate software hacking) -- These are my opinions. I hate spam. ___ 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. -- M. George ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
Several time-nuts have asked about my setup, here are some details of what I changed in the kernel and in the NTP build... Make sure and use the default config for the Pi 2 CPU when setting up .config for the Linux kernel. Make sure you are actually seeing your new kernel after you copy it to the /boot directory... name it kernel7.img if you dont' override the file name in config.txt. Also make sure dynamic modules are working. Here are details about the Linux kernel I'm currently using: Over clocked params in /boot/config.txt: #uncomment to overclock the arm. 700 MHz is the default. arm_freq=900 core_freq=500 sdram_freq=500 over_voltage=3 force_turbo=1 use force_turbo, I don't think the overclock really did anything. I do have a very good 5v power supply and I'm not using a wall wart USB power supply. Here are the contents of my /boot/cmdline.txt: dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait smsc95xx.turbo_mode=0 Use the smsc95xx option to drop the latency on the network interface. Before building the kernel, in menu_config, in kernel options, set the timer frequency to 1000HZ. In CPU Power Management CPU Frequency scaling, set the default CPUFreq governor to 'performance'. I'm using this kernel code: Linux raspi2 3.18.14-v7+ #6 SMP Sun May 31 22:32:33 MDT 2015 armv7l GNU/Linux When you compile NTP, after running .configure, manually edit config.h and set DEFAULT_HZ to 1000 and then compile NTP. On the Pi 2, it can handle 4000 interrupts per second, I'm not sure how the previous Pi versions performed on interrupts. Google around and see what else you can find for a low latency raspberry pi configuration. Here is my ntpq -crv output as of the time I wrote this email: associd=0 status=0419 leap_none, sync_uhf_radio, 1 event, leap_armed, version=ntpd 4.3.37@1.2483-o Thu Jun 11 00:12:07 UTC 2015 (1), processor=armv7l, system=Linux/3.18.14-v7+, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=1.075, refid=GPS, reftime=d9241692.3770a686 Thu, Jun 11 2015 8:15:46.216, clock=d9241697.6570084f Thu, Jun 11 2015 8:15:51.396, peer=6887, tc=4, mintc=3, offset=-0.000472, frequency=-7.870, sys_jitter=0.001907, clk_jitter=0.002, clk_wander=0.000, tai=35, leapsec=20150701, expire=20151228 So the offset at the moment was 472ns. But again, the sys_jitter has never been lower that I have seen, than 1.907 us. On Sat, Jun 13, 2015 at 11:14 AM, M. George m.matthew.geo...@gmail.com wrote: Hal, what stopped me from going down the BBB path was the reports of RF noise, they supposedly create a lot of noise. Not acceptable in an HF environment. Google around about the RF noise with the BBB. mg NG7M On Sat, Jun 13, 2015 at 12:02 AM, Hal Murray hmur...@megapathdsl.net wrote: eds_equipm...@verizon.net said: Is it possible to modify the kernel so the USB is polled more often, and would that significantly reduce the jitter? Modifying the kernel may not be enough if the timing parameters are in the microcode for the USB device. Whether any improvement is significant probably depends upon your goals. It's unlikely to become a great NTP server. If I wanted a good low power NTP server, I'd probably start with a BeagleBone Black. I haven't seen a low cost no-assembly-required GPS board for the BBB (There is at least one GPS board for the BBB, but it includes a cell phone modem which doubles the cost.) I'd probably try the GPS breakout board from SparkFun. It should take 5 wires: power, ground, trans, recv, and PPS. (and then the appropriate software hacking) -- These are my opinions. I hate spam. ___ 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. -- M. George -- M. George ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
eds_equipm...@verizon.net said: Is it possible to modify the kernel so the USB is polled more often, and would that significantly reduce the jitter? Modifying the kernel may not be enough if the timing parameters are in the microcode for the USB device. Whether any improvement is significant probably depends upon your goals. It's unlikely to become a great NTP server. If I wanted a good low power NTP server, I'd probably start with a BeagleBone Black. I haven't seen a low cost no-assembly-required GPS board for the BBB (There is at least one GPS board for the BBB, but it includes a cell phone modem which doubles the cost.) I'd probably try the GPS breakout board from SparkFun. It should take 5 wires: power, ground, trans, recv, and PPS. (and then the appropriate software hacking) -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
m.matthew.geo...@gmail.com said: As you can see, the PPM frequency on this Pi is still showing -7.742. I assume that is if it was undisciplined? I have wondered about that. That's the fudge factor needed to make that box keep reasonable time. At one level, it's the difference between the number printed on the oscillator package and the actual frequency coming out of the package. On another level, it's what the kernel measures at startup time. That measurement includes things like spread spectrum (EMI) and bugs in the calibration software. It's usually a good thermometer. -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
On 6/10/2015 5:00 AM, Hal Murray wrote: eds_equipm...@verizon.net said: 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. If you want to earn your time-nut merit badge, you have to measure it. The Ethernet on the Raspberry Pi is on the USB bus. That adds about a 1/2 ms of jitter. Is it possible to modify the kernel so the USB is polled more often, and would that significantly reduce the jitter? If you are using ntpd, there is a fudge factor that lets you correct for any offset. (and another one that lets you use the other edge, but I think the Pi doesn't capture it) ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
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
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
Hi Be careful of “single source” comparisons. When running with one reference, NTP is really measuring the reference against it’s self. It’s analogous to using a frequency counter to check it’s own reference. It *does* indeed check a number of things. It’s not really checking everything. An overly simple way to look at it: NTP is running a PLL, it “locks” a (software based) oscillator to the reference. With a single reference, it’s comparing the output of that PLL to the input to the PLL. The obvious way to get around this is to have multiple references coming into NTP. That’s easy if you want “less stable” references. It’s more money if you want to duplicate the GPS you have. After that it’s a matter of telling NTP which sources to discipline to and which to simply observe. Bob On Jun 11, 2015, at 12:05 AM, M. George m.matthew.geo...@gmail.com wrote: Here is what I have been able to do with a Motorola Oncore UT+ that I got from Bob Stewart awhile back. This is with a Raspberry PI 2 with a number of tweaks and a custom compiled kernel. Nothing too drastic... plus the current Dev version of NTP compile on the Raspberry PI. I'm getting better results letting ntpd discipline the clock over doing kernel discipline... not surprising because the algorithms in the ntpd code are much more sophisticated than the Linux kernel pps code... ntpd discipline provides much lower jitter in my experience. I'm rambling at this point, but the following samples are with a $30 antenna on the peak of my roof with LMR-400 solid conductor coax at a length of 70 ft. ~1.2 ns per foot delay based on the LMR-400 specs and nice low loss. I'm running the coax into an 8 way antenna splitter etc... nothing that anyone else hasn't done before here. The Raspberry PI 2 in this case is under load too as part of the www.pool.ntp.org pool: time.nc7j.com if you want to sync against it. As everyone else has mentioned, it's total overkill for NTP, but I'm just interested in tweaking and seeing how good I can get for fun more than anything else... i.e. time-nut obsession. I'm pretty happy with the following under load with www.pool.ntp.org set at 25MB of bandwidth which controls the traffic to my Pi 2 running NTP. It's taking a lot of traffic per second... the CPU for ntpd on the Pi is still low at around .5% to 1% of one core on the Pi 2. Here is a block of offsets from a loopstat file, and yes I cherry picked a nice block in the low nano seconds, but it rarely shows an offset into the micro seconds over time.. these are 16 second samples of the offsets... -0.00225 -0.00273 0.00094 0.00328 -0.00155 -0.00042 -0.00169 0.00323 0.00038 -0.00312 -0.00675 -0.00036 0.00213 -0.00193 0.5 -0.00503 -0.00154 -0.00179 -0.00321 0.00096 -0.00119 -0.00173 Not too shabby for a killer deal on an Oncore UT+ for $5 from Bob! I'm running the PPS out of the UT+ through a level converter to get the ~3.3v PPS output... the serial output on the UT+ is also going through a level converter direct into the Pi 2. Using the oncore 127.127.30.0 ntpd driver and again, i'm not using hardpps kernel discipline. Anyway, users on the other end are at the mercy of the network latency and noise etc... but I'm serving up some pretty consistent time references, considering the Pi 2 was $35... and the only one that really cares is me... I'm trying to masquerade as a nerdy wana-b time-nut. I think NTP is a great place to start... if you want to toy around and tinker, plus provide a service to the rest of the Internet by joining www.pool.ntp.org and sharing your obsession with time. Max NG7M ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
Hi Ed, I have started another thread under the name NTG550AA 1 PPS mod for finding the subject easier and I include here my thoughts about this modification. I am the one who discovered the 1PPS pulse while troubleshooting a NTG550AA. For me I don't imagine any future use of the X8 Chip signal but having the even second output could be useful, at least to see the difference with the 1 PPS. Instead of removing the 1/2 PPS output and missing this signal, my plan is to recycle the 9.8304 MHz output circuitry and connector, the circuits are almost identical. So I will cut the trace that goes from TP14 to U405 pin 6 and also use a wire to joint TP14 to TP33 so the 1PPS will be at J5. I think that I will do the modification this weekend and will post the results and pictures. I have not measured the time difference yet, but I made a partial schematic of the board for my troubleshooting and there I see that the 1/2 PPS signal is synchronized with the 19.6608 signal that is the source for the 8X Chip ( 9.8304 MHz), this is done in U405B . The period of this signal is about 50 ns and this is the origin of the 1/2 PPS width. The 19.6608 MHz oscillator is phase locked somewhere to the 10 MHz oscillator thus it is as stable as this one. I think that using the other half of U405, which actually is used to divide by 2 the 19.6608 MHz signal, could render the 1 PPS synchronized with the 1/2 PPS and also with the same width but probably this is overkill and an easier way to adjust this is to use the command which sets the antenna cable delay and compensate for the difference. Checking the specs documentation of a very close cousin of this board, the GSBW50AA, I found the requirement for the even second pulse: +/-1 μs traceable to and synchronous with GPS Time Even_Second with at least one satellite in view. In fact this is something not easy to measure unless you have a calibrated 1 PPS source. Another spec states The falling edge of Even_Second shall occur 0-5 ns after the falling edge of SYS_CLK. (the 9.8304 MHz signal that is used as the clock reference in the CDMA system). This specs are the reason why the even second pulse is synchronized to the SYS_CLK as I said before. So my opinion is that the difference that you measured is not relevant because we can not be sure about the even second accuracy and if we need to be sure of the absolute time we will need to compare the 1 PPS output against a calibrated source, maybe another GPSDO that has been compared with a known standard and compensated for the antenna cable delay. Of course for a NTP server you have more than enough. As I said in the other post I have a partial schematic of the board, ask me if you want a copy. Best regards, Ignacio El 10/06/2015 a las 6:30, Ed Armstrong wrote: 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
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
Hi Bob, yes I'm including several other sources and usually about 3 are getting included in the discipline of the local clock. Here is my ntpq -pcrl output at the time I wrote this message. pi@raspi2 ~ $ ntpq -pcrl remote refid st t when poll reach delay offset jitter == LOCAL(0).LOCL. 10 l 20h 6400.0000.000 0.000 oGPS_ONCORE(0) .GPS.0 l 13 16 3770.0000.000 0.002 +time-c.timefreq .ACTS. 1 u2 64 377 21.373 -0.344 0.504 +utcnist2.colora .ACTS. 1 u3 64 377 22.2620.144 1.720 +india.colorado. .NIST. 1 u 48 64 377 22.2360.188 0.122 -time-a.timefreq .ACTS. 1 u 27 64 377 21.566 -0.595 0.405 associd=0 status=0419 leap_none, sync_uhf_radio, 1 event, leap_armed, version=ntpd 4.3.37@1.2483-o Thu Jun 11 00:12:07 UTC 2015 (1), processor=armv7l, system=Linux/3.18.14-v7+, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=1.195, refid=GPS, reftime=d9246d02.38389bc3 Thu, Jun 11 2015 14:24:34.219, clock=d9246d0f.92141a9c Thu, Jun 11 2015 14:24:47.570, peer=6887, tc=4, mintc=3, offset=0.000163, frequency=-7.742, sys_jitter=0.001907, clk_jitter=0.002, clk_wander=0.000, tai=35, leapsec=20150701, expire=20151228 I have been careful to try and tweak the time1 offset to get a reasonable offset against the reference servers that show something less than 1ms over time. Shortly I'll have another GPS / M12+ up and running on another PI that I can use as a local reference along with other NTP servers over the internet. As you can see, the PPM frequency on this Pi is still showing -7.742. I assume that is if it was undisciplined? I have wondered about that. Matt On Thu, Jun 11, 2015 at 4:59 AM, Bob Camp kb...@n1k.org wrote: Hi Be careful of “single source” comparisons. When running with one reference, NTP is really measuring the reference against it’s self. It’s analogous to using a frequency counter to check it’s own reference. It *does* indeed check a number of things. It’s not really checking everything. An overly simple way to look at it: NTP is running a PLL, it “locks” a (software based) oscillator to the reference. With a single reference, it’s comparing the output of that PLL to the input to the PLL. The obvious way to get around this is to have multiple references coming into NTP. That’s easy if you want “less stable” references. It’s more money if you want to duplicate the GPS you have. After that it’s a matter of telling NTP which sources to discipline to and which to simply observe. Bob On Jun 11, 2015, at 12:05 AM, M. George m.matthew.geo...@gmail.com wrote: Here is what I have been able to do with a Motorola Oncore UT+ that I got from Bob Stewart awhile back. This is with a Raspberry PI 2 with a number of tweaks and a custom compiled kernel. Nothing too drastic... plus the current Dev version of NTP compile on the Raspberry PI. I'm getting better results letting ntpd discipline the clock over doing kernel discipline... not surprising because the algorithms in the ntpd code are much more sophisticated than the Linux kernel pps code... ntpd discipline provides much lower jitter in my experience. I'm rambling at this point, but the following samples are with a $30 antenna on the peak of my roof with LMR-400 solid conductor coax at a length of 70 ft. ~1.2 ns per foot delay based on the LMR-400 specs and nice low loss. I'm running the coax into an 8 way antenna splitter etc... nothing that anyone else hasn't done before here. The Raspberry PI 2 in this case is under load too as part of the www.pool.ntp.org pool: time.nc7j.com if you want to sync against it. As everyone else has mentioned, it's total overkill for NTP, but I'm just interested in tweaking and seeing how good I can get for fun more than anything else... i.e. time-nut obsession. I'm pretty happy with the following under load with www.pool.ntp.org set at 25MB of bandwidth which controls the traffic to my Pi 2 running NTP. It's taking a lot of traffic per second... the CPU for ntpd on the Pi is still low at around .5% to 1% of one core on the Pi 2. Here is a block of offsets from a loopstat file, and yes I cherry picked a nice block in the low nano seconds, but it rarely shows an offset into the micro seconds over time.. these are 16 second samples of the offsets... -0.00225 -0.00273 0.00094 0.00328 -0.00155 -0.00042 -0.00169 0.00323 0.00038 -0.00312 -0.00675 -0.00036 0.00213 -0.00193 0.5 -0.00503 -0.00154 -0.00179 -0.00321 0.00096 -0.00119 -0.00173 Not too shabby for a killer deal on an Oncore UT+ for $5 from Bob! I'm running the PPS out of the UT+
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
Here is what I have been able to do with a Motorola Oncore UT+ that I got from Bob Stewart awhile back. This is with a Raspberry PI 2 with a number of tweaks and a custom compiled kernel. Nothing too drastic... plus the current Dev version of NTP compile on the Raspberry PI. I'm getting better results letting ntpd discipline the clock over doing kernel discipline... not surprising because the algorithms in the ntpd code are much more sophisticated than the Linux kernel pps code... ntpd discipline provides much lower jitter in my experience. I'm rambling at this point, but the following samples are with a $30 antenna on the peak of my roof with LMR-400 solid conductor coax at a length of 70 ft. ~1.2 ns per foot delay based on the LMR-400 specs and nice low loss. I'm running the coax into an 8 way antenna splitter etc... nothing that anyone else hasn't done before here. The Raspberry PI 2 in this case is under load too as part of the www.pool.ntp.org pool: time.nc7j.com if you want to sync against it. As everyone else has mentioned, it's total overkill for NTP, but I'm just interested in tweaking and seeing how good I can get for fun more than anything else... i.e. time-nut obsession. I'm pretty happy with the following under load with www.pool.ntp.org set at 25MB of bandwidth which controls the traffic to my Pi 2 running NTP. It's taking a lot of traffic per second... the CPU for ntpd on the Pi is still low at around .5% to 1% of one core on the Pi 2. Here is a block of offsets from a loopstat file, and yes I cherry picked a nice block in the low nano seconds, but it rarely shows an offset into the micro seconds over time.. these are 16 second samples of the offsets... -0.00225 -0.00273 0.00094 0.00328 -0.00155 -0.00042 -0.00169 0.00323 0.00038 -0.00312 -0.00675 -0.00036 0.00213 -0.00193 0.5 -0.00503 -0.00154 -0.00179 -0.00321 0.00096 -0.00119 -0.00173 Not too shabby for a killer deal on an Oncore UT+ for $5 from Bob! I'm running the PPS out of the UT+ through a level converter to get the ~3.3v PPS output... the serial output on the UT+ is also going through a level converter direct into the Pi 2. Using the oncore 127.127.30.0 ntpd driver and again, i'm not using hardpps kernel discipline. Anyway, users on the other end are at the mercy of the network latency and noise etc... but I'm serving up some pretty consistent time references, considering the Pi 2 was $35... and the only one that really cares is me... I'm trying to masquerade as a nerdy wana-b time-nut. I think NTP is a great place to start... if you want to toy around and tinker, plus provide a service to the rest of the Internet by joining www.pool.ntp.org and sharing your obsession with time. Max NG7M ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
Hi Comparing a GPS to a series of “over the net” sources will always make the GPS look good. NTP is usually smart enough to figure out that the GPS is the one it wants and lock in on it. The ppm’s at the bottom are talking about the software PLL and how it’s offset from your computer’s local clock. It’s telling you what it’s best guess is at the frequency of the oscillator on your Pi. It’s a guess until you can do enough work to be sure that NTP isn’t being messed up by something else going on in the system. Bob On Jun 11, 2015, at 4:32 PM, M. George m.matthew.geo...@gmail.com wrote: Hi Bob, yes I'm including several other sources and usually about 3 are getting included in the discipline of the local clock. Here is my ntpq -pcrl output at the time I wrote this message. pi@raspi2 ~ $ ntpq -pcrl remote refid st t when poll reach delay offset jitter == LOCAL(0).LOCL. 10 l 20h 6400.0000.000 0.000 oGPS_ONCORE(0) .GPS.0 l 13 16 3770.0000.000 0.002 +time-c.timefreq .ACTS. 1 u2 64 377 21.373 -0.344 0.504 +utcnist2.colora .ACTS. 1 u3 64 377 22.2620.144 1.720 +india.colorado. .NIST. 1 u 48 64 377 22.2360.188 0.122 -time-a.timefreq .ACTS. 1 u 27 64 377 21.566 -0.595 0.405 associd=0 status=0419 leap_none, sync_uhf_radio, 1 event, leap_armed, version=ntpd 4.3.37@1.2483-o Thu Jun 11 00:12:07 UTC 2015 (1), processor=armv7l, system=Linux/3.18.14-v7+, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=1.195, refid=GPS, reftime=d9246d02.38389bc3 Thu, Jun 11 2015 14:24:34.219, clock=d9246d0f.92141a9c Thu, Jun 11 2015 14:24:47.570, peer=6887, tc=4, mintc=3, offset=0.000163, frequency=-7.742, sys_jitter=0.001907, clk_jitter=0.002, clk_wander=0.000, tai=35, leapsec=20150701, expire=20151228 I have been careful to try and tweak the time1 offset to get a reasonable offset against the reference servers that show something less than 1ms over time. Shortly I'll have another GPS / M12+ up and running on another PI that I can use as a local reference along with other NTP servers over the internet. As you can see, the PPM frequency on this Pi is still showing -7.742. I assume that is if it was undisciplined? I have wondered about that. Matt On Thu, Jun 11, 2015 at 4:59 AM, Bob Camp kb...@n1k.org wrote: Hi Be careful of “single source” comparisons. When running with one reference, NTP is really measuring the reference against it’s self. It’s analogous to using a frequency counter to check it’s own reference. It *does* indeed check a number of things. It’s not really checking everything. An overly simple way to look at it: NTP is running a PLL, it “locks” a (software based) oscillator to the reference. With a single reference, it’s comparing the output of that PLL to the input to the PLL. The obvious way to get around this is to have multiple references coming into NTP. That’s easy if you want “less stable” references. It’s more money if you want to duplicate the GPS you have. After that it’s a matter of telling NTP which sources to discipline to and which to simply observe. Bob On Jun 11, 2015, at 12:05 AM, M. George m.matthew.geo...@gmail.com wrote: Here is what I have been able to do with a Motorola Oncore UT+ that I got from Bob Stewart awhile back. This is with a Raspberry PI 2 with a number of tweaks and a custom compiled kernel. Nothing too drastic... plus the current Dev version of NTP compile on the Raspberry PI. I'm getting better results letting ntpd discipline the clock over doing kernel discipline... not surprising because the algorithms in the ntpd code are much more sophisticated than the Linux kernel pps code... ntpd discipline provides much lower jitter in my experience. I'm rambling at this point, but the following samples are with a $30 antenna on the peak of my roof with LMR-400 solid conductor coax at a length of 70 ft. ~1.2 ns per foot delay based on the LMR-400 specs and nice low loss. I'm running the coax into an 8 way antenna splitter etc... nothing that anyone else hasn't done before here. The Raspberry PI 2 in this case is under load too as part of the www.pool.ntp.org pool: time.nc7j.com if you want to sync against it. As everyone else has mentioned, it's total overkill for NTP, but I'm just interested in tweaking and seeing how good I can get for fun more than anything else... i.e. time-nut obsession. I'm pretty happy with the following under load with www.pool.ntp.org set at 25MB of bandwidth which controls the traffic to my Pi 2 running NTP. It's taking a lot of traffic per second... the CPU for ntpd on the Pi is still low at around .5% to 1% of one core on the Pi 2. Here is a block of offsets from a
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
Do you think it is OK to consider a pulse which arise 250 ns early to be close enough? For NTP usage that will be no problem whatsoever. Dave ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
On Wed, Jun 10, 2015 at 6:30 AM, Ed Armstrong eds_equipm...@verizon.net wrote: Hi, this is my first post ever to a mailing list, so if I'm doing anything wrong please be gentle with your corrections :-) Welcome! [snip] 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. Very clever. 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. Depends on your needs, of course. For NTP, 250ns will be essentially unnoticeable. For other purposes, it might be an issue, but not for NTP. NTP typically works on the micro- and millisecond level. Any offset or jitter on the nanosecond level will be lost in the noise, so to speak: the interrupt latency of the Pi will far exceed any nanosecond-level offset. Cheers! -Pete -- Pete Stephenson ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
From: Ed Armstrong [] 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 ___ Yes, Ed, if you are within a microsecond for the PPS input to your Raspberry Pi that's fine. Don't forget it's a 3.3 V level. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
For driving NTP.. 1) NTP works in microseconds and your networked clients will see accuracy in the range of a few milliseconds. 2) There is a way to fix this in NTP's configuration file, you can specify what the delay is. On Tue, Jun 9, 2015 at 9:30 PM, Ed Armstrong eds_equipm...@verizon.net wrote: 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. -- Chris Albertson Redondo Beach, California ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
Hi Ed -- For standard PC hardware, 250ns is way under the interrupt granularity of the computer, and will never be noticed. Some specialized configurations (https://www.febo.com/pages/soekris/) have timer resolution to a few hundred nanoseconds, but that takes hacking. I know there have been discussions about the RPi as an ntp server, and I don't recall anyone talking about what a wizard device is was as a pure timekeeper. It ultimately comes down to the interrupt resolution, and the short-term stability of the computer clock source. So, (a) I don't think you don't need to worry, and (b) even if you do, you can insert a fudge factor into the ntp configuration to neutralize fixed offsets like this. John On 6/10/2015 12:30 AM, Ed Armstrong wrote: 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
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
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
On Wed, Jun 10, 2015 at 12:30 PM, Ed Armstrong eds_equipm...@verizon.net wrote: 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. If you know what the offset is, and it is stable, (and you have shown you understand PCB traces, etc), I do not see how this is not OK. For someone like me, who cannot solder, and wants something off-the-shelf, it would be a problem. I would not know how to correct for the offset. If you are feeding this to NTP, the driver has a fuge factor, which you can use to consistently compensate for the 240ns (although I doubt the Pi is stable to that level). -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
Hi Welcome! At best your NTP setup will be good to a few microseconds. By the time you get the time delivered (even over a LAN) it will be good to a few hundred microseconds at best. The ~ 250 ns error should not be a big deal. This being Time Nuts, you might take a look at the options on NTP and the drivers. I believe you will find an “offset” capability buried down in there. It’s most commonly used for radio (WWVB etc) based clocks. (They need to be corrected for propagation). Based on observing it’s use on public servers - it’s pretty easy to get the setting backwards. Of course it does beg the question of “which pulse is correct?”. Without further research, (and more timing gear :) there’s no real way to be sure that the even pps is right …. Bob On Jun 10, 2015, at 12:30 AM, Ed Armstrong eds_equipm...@verizon.net wrote: 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
On Tue, June 9, 2015 11:30 pm, Ed Armstrong wrote: 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? It is only 250ns early relative to the even second output. What is the even second output referenced to? What most people care about is relation to established UTC, and that you don't know for either pulse. You did not mention measuring the length of the antenna cable and adjusting for that. That will probably be a few tens of nanoseconds. There could be other processing delays or propagation delays in the signal path. Without accounting for all of those, and knowing whether the firmware in the GPSDO takes those into account, you don't really know whether the PPS is early, or the PP2S is late relative to UTC (and assuming you have accounted for antenna delay). -- Chris Caudle ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
eds_equipm...@verizon.net said: 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. If you want to earn your time-nut merit badge, you have to measure it. The Ethernet on the Raspberry Pi is on the USB bus. That adds about a 1/2 ms of jitter. If you are using ntpd, there is a fudge factor that lets you correct for any offset. (and another one that lets you use the other edge, but I think the Pi doesn't capture it) -- These are my opinions. I hate spam. ___ 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.
