[time-nuts] Re: NIST NTP servers way off for anyone else?
> The hardware are done by the network PHY and need 1588 support in the driver, which is not common. PTP HW timestamping is thankfully a bit more common than NTP one. From which you can deduce that it's unlikely you'll get HW timestamping in NTP context. However, new Chrony has support for encapsulating NTP in PTP to utilize the HW timestamping support for PTP. Thought I'd mention. On Wed, Dec 15, 2021 at 4:03 AM Trent Piepho wrote: > On Tue, Dec 14, 2021 at 2:21 PM Hal Murray wrote: > > > > > I've seen cards (ethtool) that support several time options - what > are they > > > and how do I use them? > > > > I'm not sure which options you are referring to. > > Probably the flags from ethtool -T output: > > Time stamping parameters for eth0: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) > software-system-clock (SOF_TIMESTAMPING_SOFTWARE) > hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE) > > The software ones are normally alway present and are what you describe > with the kernel's timestamping. The hardware are done by the network > PHY and need 1588 support in the driver, which is not common. I don't > think any of the RPis support it. > > > > > You can't have boxes on the internet update packets if you are > interested in > > security. > > That seems too restrictive. Consider that TLS doesn't include the > TCP/IP header, which can be modified by IP fragmentation, and that is > still considered secure. > > I think one could design a protocol such that each appended timestamp > is signed, and included a digest of all timestamps before it, so that > while one does not trust every timestamp in the chain, it can be > trusted that each timestamp was generated by entity that said it > generated it and that any timestamps generated by a trusted entity > were not later modified by a untrusted one. > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send > an email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: NTP servers
Speaking of Raspberry Pi's as time servers, does anyone here know of a nice single board computer that supports both Ethernet hardware timestamping and GPIO PPS input? On Tue, Nov 23, 2021 at 12:49 PM McFail Troll wrote: > > If you have a good local NTP setup, you can measure how good other > servers are, or more likely how good the network connection is. NTP > assumes the network delays are symmetric. Often, that's not true. So "how > good" turns into measuring network (a)symmetries. > > Yes this is what I'd like to do eventually. Trying to get a Raspberry pi + > gps setup going first though. > > On Mon, Nov 22, 2021 at 5:42 AM Hal Murray wrote: > > > time.isan...@gmail.com said: > > > but I am curious to see if I could sync up with some of you guys who > > seem to > > > have some pretty cool set-ups. > > > > GPS has taken over the time-distribution business. > > > > If you want to use GPS, there are 2 ways to go. > > > > You can get a simple GPS receiver and plug that into your PC. For decent > > time, you need a PPS signal and a real serial port, not USB. > > > > The other approach is to get a GPSDO -- GPS Disciplined Oscillator. > > That's a > > box with a GPS receiver and a good crystal and some software. It > smoothes > > out > > the rough edges in the timing from the GPS signal and/or keeps going > > (holdover) when the GPS signal fades or dies. > > > > GPS is very very good in the long term but noisy in the short term. > Short > > means seconds to minutes. Long means days/months. A GPSDO will get rid > > of > > most of the short term noise. > > > > There are/were several models available at relatively low cost after they > > were recycled from cell phone towers. HP Z3801A and Trimble Thunderbolt > > are popular. "GPSDO" will get lots of hits on eBay. I don't know how > good > > the recent ones are. > > > > Just reading the info available can be fun if you like that stuff. > > http://www.realhamradio.com/GPS_Frequency_Standard.htm > > The Z3801A manual is a good read. > > http://www.leapsecond.com/museum/z3801a/097-z3801-01-iss-1.pdf > > Time sink warning! > > > > GPS works much better if you have a good antenna location. Modern GPS > > receivers are sensitive enough that they sometimes/often work indoors, > > maybe better on a window sill, maybe even better if the window faces > > south. Just because it's working now doesn't mean it won't glitch often > > enough to cause problems. Mumble. Try it and see what happens. > > > > - > > > > There is actually a 3rd way: buy a box that does it all. But that's not > > much > > fun, at least for most of the people on this list. > > > > -- > > > > > there are plenty of good stratum 1 NTP servers open to the public (e.g. > > > NIST's servers), > > > > If you have a good local NTP setup, you can measure how good other > servers > > are, or more likely how good the network connection is. NTP assumes the > > network delays are symmetric. Often, that's not true. So "how good" > turns > > into measuring network (a)symmetries. > > > > > > -- > > These are my opinions. I hate spam. > > > > > > ___ > > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe > send > > an email to time-nuts-le...@lists.febo.com > > To unsubscribe, go to and follow the instructions there. > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send > an email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: Comparison/evaluation of u-blox timing receivers
Hi, I hope you don't mind me starting a "newcomer" thread based on your sentence: "with a GPSDO, finding one that’s got a clean output is not at all easy". Are there any up-to-date resources that would provide such information about a larger selection of GPSDOs? Are there any GPSDOs that people really recommend purchasing right now, costing say up to $500? Or is the "just build your own" approach the most cost-effective way? P.S: "Study John Vig's Introduction to Quartz Frequency Standards" link on http://www.leapsecond.com/time-nuts.htm is broken On Tue, Aug 24, 2021 at 3:20 PM Bob kb8tq wrote: > Hi > > The problem with the approach used in the basic GPS / GNSS modules is > that the TCXO is not tuned on frequency. Even with an integer relation to > the > internal oscillator, you still see the pulse drop / pulse add into the > divider. The > result is that they are noisy. > > There are a couple of modules that *do* tune the frequency. ( as noted in > the > paper). There the very coarse DAC used is what gets you in terms of noise. > Again, it’s regardless of output frequency. The signal *is* cleaner, it’s > just not > as clean as what most folks are looking for. > > Even with a GPSDO, finding one that’s got a clean output is not at all > easy. > Yes, this all depends a lot on just what you mean by clean. It normally > comes > up in the context of folks wanting to run radios at microwaves. Indeed the > normal answer there is that you use multiple oscillators in your multiplier > chain. > > Bob > > > On Aug 24, 2021, at 7:18 AM, Marek Doršic > wrote: > > > > Hello, > > > > thank you for sharing valuable comprehensive comparisions. > > > > In the high timepulse rate experiment, have you also investigated other > rates than the standard 10 MHz? Most Ublox receivers use 48MHz internal > clock thus the 10MHz timepulse must be missing some of the clock pulses > which generates additional jitter. 8MHz or 12MHz rates which are integer > divisions might have cleaner output. > > > > .marek > > > >> On 24 Aug 2021, at 03:51, John Ackermann N8UR wrote: > >> > >> In 2020 I did an extensive evaluation of the timing ability of the > u-blox LEA-M8F, NEO-M8N, NEO-M8T, NEO-M9N, ZED-F9P, and ZED-F9T. The work > was made possible by support from the HamSci consortium ( > https://hamsci.org) under NSF grants supporting HamSci activities. > >> > >> I was sure I'd posted about the paper on time-nuts, but I can't find > any record that I did, so this is a belated announcement. It's available > for download from > >> > >> > https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf > >> > >> As BobC says, "Lots of fun!" > >> > >> John > >> > >> ___ > >> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe > send an email to time-nuts-le...@lists.febo.com > >> To unsubscribe, go to and follow the instructions there. > > ___ > > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe > send an email to time-nuts-le...@lists.febo.com > > To unsubscribe, go to and follow the instructions there. > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send > an email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: PPS on Ubuntu server 20.04 LTS
> DEVICES="/dev/ttyS0 /dev/pps0" Specifying pps0 here is not required because gpsd is usually compiled with the MAGIC_HAT flag which means it will always also use /dev/pps0, no way around it other than rebuilding. Specifying it twice makes gpsd attempt to open it twice. Probably works, but might cause some unnecessary warnings and such. On Sat, Apr 24, 2021 at 1:08 AM James Perkins wrote: > x GPS shows that the GPS serial data is being received on /dev/ttyS0 with > reachability of 377 - so it's consistently coming in and being interpreted > correctly by something (presumably, gpsd service); however, the x means > that it is deemed a falseticker (inaccurate, compared to the chosen NTP > server, 192.168.0.20). This is probably because you need to adjust the > offset period to match the mean delay in serial data coming in from your > serial port to be in line with other NTP servers. > > ppscheck is showing two events per second, the CTS event happening about > .9784 offset relative to the system clock, and the serial data about 100ms > later at .078. So, an offset of 0.100 would be a possible first try. The > fact ppscheck (part of the gpsd package's set of tools) sees this means > that gpsd was compiled with support for CTS edge detection. However, you're > not getting any pps input at chrony at all. What are your chrony.conf > refclock lines? > > For example, on my server, I'm using an adafruit Ultimate GPS Hat on a > Raspberry Pi 4B. gpsd will recognize it as an NMEA0183 device. It provides > serial input to /dev/ttyS0 and PPS on gpio 4. In /boot/config.txt I added: > > enable_uart=1 > dtoverlay=pps-gpio,gpiopin=4 > > And rebooted. This will cause the kernel to activate the appropriate pins > for the GPS serial input/output, and run a software timestamp driver > (pps-gpio) which links the PPS gpio pin edge to an event on the /dev/pps0 > device. > > gpsd is run this way (setup in /etc/default/gpsd): > > START_DAEMON="true" > USBAUTO="true" > DEVICES="/dev/ttyS0 /dev/pps0" > GPSD_OPTIONS="-n" > > And start the service: > > systemctl enable gpsd.service > systemctl restart gpsd.service > > The 'systemctl status gpsd.service' command reveals it is running with > parameters: gpsd -n /dev/ttyS0 /dev/pps0 . This updates NTP shared memory 0 > when the serial data becomes available (usually quite a while after PPS), > and NTP shared memory 2 when the PPS clock edge is found. > > Then in /etc/chrony/chrony.conf, the big offset on the slow-to-arrive > imprecise serial data (GPS) and the accurate PPS: > > refclock SHM 0 poll 3 refid GPS precision 1e-1 offset 0.5774 delay 0.2 > refclock SHM 2 poll 3 refid PPS precision 1e-7 > > In the above, Shared memory 0 is the serial GPS source with low precision > and 0.5774 offset. Shared memory 2 is the PPS gpio source with high > precision (100ns precision was my ballpark guesstimate to use here, I need > to get a better oscilloscope for further testing). > > Hope this example helps, > James Perkins > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send > an email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
Re: [time-nuts] Raspberry Pi 4 oscillator replacement
> 2) Grab any of the various conversion chips to take the 10 MHz to 54 (= I don’t know of a standard that puts out 54 MHz). Wire the 10 into it and pull the 54 off of it. (Yes, the chip needs to be programmed and there will be various bits and pieces connected to it) Do you have any recommendations as to which chip would let me achieve this? In any case, thanks for the help. I will try and document the process when I start it and share it here, might be interesting for some. On Thu, Feb 4, 2021 at 5:15 PM Bob kb8tq wrote: > Hi > > Pretty basic approach: > > 1) Get a Rb standard. > > 2) Grab any of the various conversion chips to take the 10 MHz to 54 > (= I don’t know of a standard that puts out 54 MHz). Wire the 10 into it > and pull the 54 off of it. (Yes, the chip needs to be programmed and > there will be various bits and pieces connected to it) > > 3) Rip the oscillator (or crystal) off the RPi board. > > 4) Figure out which pin is the drive to the crystal and which is the > return. > (or which is the output if it’s an oscillator) > > 5) Wire the 54 MHz into the return / osc out pin. > > 6) Power it all up off of a common supply ( = power the conversion > chip off the RPi’s regulator. > > Yes there is a lot of research needed to complete all of that. > > When done you would need to figure out how to ( … if you can ) disable > the spread spectrum stuff on the clock. You still would be stuck with > the normal issues related to clock frequency stepping ( turbo mode …). > How much of that actually gets you on an RPi 4 … who knows. > > Bob > > > On Feb 4, 2021, at 5:20 AM, Avamander wrote: > > > > Hi, > > > > I was wondering if anyone here has replaced the 54 MHz oscillator on the > > Raspberry Pi 4 with a GNSS-disciplined rubidium standard? An overkill > > upgrade, but is technically doable? What hardware would it take in > addition > > to a GNSS-disciplined rubidium standard and a Pi 4? > > > > Here's where I got my inspiration from, someone replacing the oscillator > on > > a Pi 3 with a TXCO: > > > https://raspberrypi.stackexchange.com/questions/74482/switch-out-the-x1-oscillator-on-a-rpi-2-3 > > > > > > Yours sincerely, > > Avamander > > ___ > > time-nuts mailing list -- time-nuts@lists.febo.com > > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > > and follow the instructions there. > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] Raspberry Pi 4 oscillator replacement
Hi, I was wondering if anyone here has replaced the 54 MHz oscillator on the Raspberry Pi 4 with a GNSS-disciplined rubidium standard? An overkill upgrade, but is technically doable? What hardware would it take in addition to a GNSS-disciplined rubidium standard and a Pi 4? Here's where I got my inspiration from, someone replacing the oscillator on a Pi 3 with a TXCO: https://raspberrypi.stackexchange.com/questions/74482/switch-out-the-x1-oscillator-on-a-rpi-2-3 Yours sincerely, Avamander ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
