Hi Based on what I’ve seen of the F9T, the claim that it has an “absolute timing accuracy” of 5 ns is a bit of a stretch, even one sigma. If “absolute accuracy” is a reference to timing against UTC it really isn’t going to do that. Even to get reasonably close, your filter needs to process the sawtooth correction message from the F9T. Bob > On Apr 28, 2025, at 6:48 AM, Pavel Kořenský via time-nuts <time-nuts@lists.febo.com> wrote: > > Hello, > > I just wanted to share that u-blox also makes the F9T module (the "T" stands for "timing," I believe), which is generally even more precise than the F9P. SparkFun has a board based on it here: > https://www.sparkfun.com/sparkfun-gnss-timing-breakout-zed-f9t-qwiic.html > > The board isn't cheap, but according to the datasheet, the F9T offers an absolute timing accuracy of 5 ns (1-sigma, fixed position mode), depending on things like temperature, atmospheric conditions, baseline length, GNSS antenna quality, multipath, satellite visibility, and geometry. In differential timing mode, the accuracy can go down to 2.5 ns. > > I'm currently using this module in my prototype GPSDO based on a cesium clock, and so far, the results have been very good. I'm not using the standard 1PPS output — instead, I use a programmable output from the GPS receiver set to 1.25 MHz, and I feed it into a PLL with a Kalman filter at the input. > > Now, regarding how to measure which clock is "better": that's a tough question. If you have only two clocks, you can't really tell which one is more accurate — you need a third, better reference. Ideally, that would be a cesium standard or, even better, a hydrogen maser. Unfortunately, getting access to something like that is very difficult for a home lab. > What I did was use my rubidium (Rb) standard as a reference and measured my GPS-PLL design disciplining an old, reliable HP10811 crystal oscillator. Later, I used the same setup to stabilize the Rb oscillator and compared it against a commercial GPSDO. I'm still hoping to get access to a cesium clock in the future (as far as I know, there's no hydrogen maser available in Prague or anywhere in the Czech Republic). > The main reason I haven’t published my design yet is that I haven't been able to make a full comparison against a top-tier reference clock. > > Best regards, > > PavelK > > > Dne 27.04.2025 v 10:52 drew wollin via time-nuts napsal(a): >> Hi All >> >> I have a long-term interest in GPS/GNSS for accurate position, frequency and time. >> >> Conventional GNSS receivers are accurate to a few metres and about 10 nanoseconds. >> >> The accuracy can be improved by using correction information via RTK over the internet. The receiver needs to be within about 20 km of an RTK base station. The RTK base stations are linked and available as government or private correction networks, some of which are free. See the link for the Australian RTK network. >> >> The RTK corrections are based on local space weather and the ionosphere's effect on the received satellite signal. >> >> It is relatively inexpensive and easy to use these networks to get cm accuracy positioning. U-blox and Quectel make RTK-capable receivers, which are available from SparkFun and AliExpress. The receiver boards from AliExpress cost around US$50. >> >> The receivers can be used with software from the respective manufacturers >> >> With centimetre position accuracy, presumably, time pulse accuracy also improves. Does anyone know if that is the case? I looked on the web without success >> >> The Quectel LG290P has a 1 PPS output that could be connected to other timing equipment. >> >> I have an SRS PRS10 GPSDO cesium clock with an early single-satellite GPS receiver. I was thinking of replacing it with a 1 PPS signal from an RTK-corrected LG290P. >> >> The other question, of course, is how do I measure if the time is better? >> >> Regards Drew VK4ZXI >> >> https://portal.ga.gov.au/persona/pa >> >> https://docs.sparkfun.com/SparkFun_LG290P_Quadband_GNSS_RTK_Breakout/print_view/ >> [https://docs.sparkfun.com/SparkFun_LG290P_Quadband_GNSS_RTK_Breakout/print_view/%22https://i.ytimg.com/vi/a-aU4-Yodzg/default.jpg%22]<https://docs.sparkfun.com/SparkFun_LG290P_Quadband_GNSS_RTK_Breakout/print_view/> >> Introduction - SparkFun LG290P Quadband GNSS RTK Breakout Hookup Guide<https://docs.sparkfun.com/SparkFun_LG290P_Quadband_GNSS_RTK_Breakout/print_view/> >> The SparkFun Quadband GNSS RTK Breakout - LG290P (Qwiic) features the Quectel LG290P GNSS module. The board's dimensions, pin layout, and connectors are exactly the same as our vary popular SparkFun GPS-RTK-SMA Breakout - ZED-F9P (Qwiic); and can be used as a drop-in replacement.The board also accommodates users with a diverse choice of interfaces including UART, SPI 1, and I 2 C 1. >> docs.sparkfun.com >> >> [https://nonprod.portal.ga.gov.au/cache/images/portal_ga.png]<https://portal.ga.gov.au/persona/pa> >> Geoscience Australia Portal<https://portal.ga.gov.au/persona/pa> >> This portal (Geoscience Australia Portal Core) provides full access to Geoscience Australia data and other publically available data sources as well as suite of analytical and multi-criteria assessment tools to maximise the value of the data. A series of personas have been created on the Geoscience Australia Portal Core technology to meet specific stakeholder and project requirements. >> portal.ga.gov.au >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe send an email to time-nuts-leave@lists.febo.com > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

Hello, yes, I also think that the "absolute timing accuracy" is a marketing babble. After all, we all knows the datasheet speech. :) But when it comes to sawtooth correction, I used another approach in my design. It seems that the combination of high frequency input from GPS module, the clock jitter of Raspberry Pi Pico GIO and Kalman filter is able to smooth/smudge this problem. Not for 100%, but I am working hard on it. Best regards PavelK Dne 28.04.2025 v 20:56 Bob Camp via time-nuts napsal(a): > Hi > > Based on what I’ve seen of the F9T, the claim that it has an “absolute timing accuracy” of 5 ns is a bit of a stretch, even one sigma. If “absolute accuracy” is a reference to timing against UTC it really isn’t going to do that. Even to get reasonably close, your filter needs to process the sawtooth correction message from the F9T. > > Bob > >> On Apr 28, 2025, at 6:48 AM, Pavel Kořenský via time-nuts <time-nuts@lists.febo.com> wrote: >> >> Hello, >> >> I just wanted to share that u-blox also makes the F9T module (the "T" stands for "timing," I believe), which is generally even more precise than the F9P. SparkFun has a board based on it here: >> https://www.sparkfun.com/sparkfun-gnss-timing-breakout-zed-f9t-qwiic.html >> >> The board isn't cheap, but according to the datasheet, the F9T offers an absolute timing accuracy of 5 ns (1-sigma, fixed position mode), depending on things like temperature, atmospheric conditions, baseline length, GNSS antenna quality, multipath, satellite visibility, and geometry. In differential timing mode, the accuracy can go down to 2.5 ns. >> >> I'm currently using this module in my prototype GPSDO based on a cesium clock, and so far, the results have been very good. I'm not using the standard 1PPS output — instead, I use a programmable output from the GPS receiver set to 1.25 MHz, and I feed it into a PLL with a Kalman filter at the input. >> >> Now, regarding how to measure which clock is "better": that's a tough question. If you have only two clocks, you can't really tell which one is more accurate — you need a third, better reference. Ideally, that would be a cesium standard or, even better, a hydrogen maser. Unfortunately, getting access to something like that is very difficult for a home lab. >> What I did was use my rubidium (Rb) standard as a reference and measured my GPS-PLL design disciplining an old, reliable HP10811 crystal oscillator. Later, I used the same setup to stabilize the Rb oscillator and compared it against a commercial GPSDO. I'm still hoping to get access to a cesium clock in the future (as far as I know, there's no hydrogen maser available in Prague or anywhere in the Czech Republic). >> The main reason I haven’t published my design yet is that I haven't been able to make a full comparison against a top-tier reference clock. >> >> Best regards, >> >> PavelK >> >> >> Dne 27.04.2025 v 10:52 drew wollin via time-nuts napsal(a): >>> Hi All >>> >>> I have a long-term interest in GPS/GNSS for accurate position, frequency and time. >>> >>> Conventional GNSS receivers are accurate to a few metres and about 10 nanoseconds. >>> >>> The accuracy can be improved by using correction information via RTK over the internet. The receiver needs to be within about 20 km of an RTK base station. The RTK base stations are linked and available as government or private correction networks, some of which are free. See the link for the Australian RTK network. >>> >>> The RTK corrections are based on local space weather and the ionosphere's effect on the received satellite signal. >>> >>> It is relatively inexpensive and easy to use these networks to get cm accuracy positioning. U-blox and Quectel make RTK-capable receivers, which are available from SparkFun and AliExpress. The receiver boards from AliExpress cost around US$50. >>> >>> The receivers can be used with software from the respective manufacturers >>> >>> With centimetre position accuracy, presumably, time pulse accuracy also improves. Does anyone know if that is the case? I looked on the web without success >>> >>> The Quectel LG290P has a 1 PPS output that could be connected to other timing equipment. >>> >>> I have an SRS PRS10 GPSDO cesium clock with an early single-satellite GPS receiver. I was thinking of replacing it with a 1 PPS signal from an RTK-corrected LG290P. >>> >>> The other question, of course, is how do I measure if the time is better? >>> >>> Regards Drew VK4ZXI >>> >>> https://portal.ga.gov.au/persona/pa >>> >>> https://docs.sparkfun.com/SparkFun_LG290P_Quadband_GNSS_RTK_Breakout/print_view/ >>> [https://docs.sparkfun.com/SparkFun_LG290P_Quadband_GNSS_RTK_Breakout/print_view/%22https://i.ytimg.com/vi/a-aU4-Yodzg/default.jpg%22]<https://docs.sparkfun.com/SparkFun_LG290P_Quadband_GNSS_RTK_Breakout/print_view/> >>> Introduction - SparkFun LG290P Quadband GNSS RTK Breakout Hookup Guide<https://docs.sparkfun.com/SparkFun_LG290P_Quadband_GNSS_RTK_Breakout/print_view/> >>> The SparkFun Quadband GNSS RTK Breakout - LG290P (Qwiic) features the Quectel LG290P GNSS module. The board's dimensions, pin layout, and connectors are exactly the same as our vary popular SparkFun GPS-RTK-SMA Breakout - ZED-F9P (Qwiic); and can be used as a drop-in replacement.The board also accommodates users with a diverse choice of interfaces including UART, SPI 1, and I 2 C 1. >>> docs.sparkfun.com >>> >>> [https://nonprod.portal.ga.gov.au/cache/images/portal_ga.png]<https://portal.ga.gov.au/persona/pa> >>> Geoscience Australia Portal<https://portal.ga.gov.au/persona/pa> >>> This portal (Geoscience Australia Portal Core) provides full access to Geoscience Australia data and other publically available data sources as well as suite of analytical and multi-criteria assessment tools to maximise the value of the data. A series of personas have been created on the Geoscience Australia Portal Core technology to meet specific stakeholder and project requirements. >>> portal.ga.gov.au >>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@lists.febo.com >>> To unsubscribe send an email to time-nuts-leave@lists.febo.com >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe send an email to time-nuts-leave@lists.febo.com > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

-------- Pavel Kořenský via time-nuts writes: > I'm currently using this module in my prototype GPSDO based on a cesium > clock, [...] > > Now, regarding how to measure which clock is "better": that's a tough > question. If you have only two clocks, you can't really tell which one > is more accurate — you need a third, better reference. […] But that is not really what you want to know, is it ? What you want to know is that your PLL has the right time-constant, so that you derive maximum benefit from both your two sources. This is what Dave Mills called "The Allan Intercept" When your PLL tracks near the Allan Intercept, the error output of the phase detector will have a flat-ish frequency spectrum. If your PLL is too loose, the spectrum will slope up towards higher frequencies, if it is too stiff, lower frequencies will dominate. But be aware that with a Cs-VCO, the signal is in constant peril from rounding and truncation in floating point math. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Hello, this is my mistake. I thought about something and wrote something other. Of course, my GPSDO is based on rubidium clock, not cesium. I do not know what I was thinking when I wrote the message. Probably dreaming about my own private cesium or H-maser frequency standard. Best regards PavelK Dne 28.04.2025 v 21:58 Poul-Henning Kamp napsal(a): > -------- > Pavel Kořenský via time-nuts writes: > > >> I'm currently using this module in my prototype GPSDO based on a cesium >> clock, [...] >> >> Now, regarding how to measure which clock is "better": that's a tough >> question. If you have only two clocks, you can't really tell which one >> is more accurate — you need a third, better reference. […] > But that is not really what you want to know, is it ? > > What you want to know is that your PLL has the right time-constant, > so that you derive maximum benefit from both your two sources. > > This is what Dave Mills called "The Allan Intercept" > > When your PLL tracks near the Allan Intercept, the error output of > the phase detector will have a flat-ish frequency spectrum. > > If your PLL is too loose, the spectrum will slope up towards higher > frequencies, if it is too stiff, lower frequencies will dominate. > > But be aware that with a Cs-VCO, the signal is in constant peril > from rounding and truncation in floating point math. >

1 - not to mention that NTP transmissions on a Pi4 are way outside the PLL of ntpd, due to the enet being hung off a USB bus (read up on resetting/probing every 250m), vs on a Pi 5, where it’s all internal to the Bcom CPU/everything including enet in one chip and only L1 cache distance away. 2 - Ditch Pi4’s for timing. Largely bad. Unless uS vs nS matter to you. Not being rude :-) 3 - I don’t know if I can believe chronyc saying it’s 10nS off (from what ?) a timing related UBlox LEA-M8T board off a Pi5. Which I have running in a temp compensated enclosure (aka my lunchbox with a thermocouple/fan and highly regulated linear power supply). 4 - One interesting measurement that I have not done yet is to graph received time for GPS vs Glonass vs BeiDou vs Galileo vs Cthulu alien (Allan ? har har) time measurements ( just kidding). The U Blox board is pretty amazing in that it can handle all these constellations at once. Those guys know what they are doing. Not bad for $19 off Ebay. M8T, make sure it is the ’T’ version. 5 - RTK makes no difference, time wise. It is after the fact, so to speak. 6 - The California public RTK network is nice (another UBlox board) but 10 cm doesn’t matter to us. But it is free. 1200 stations. The basic issue is the ‘time' is the time, the RTK comes after the ‘time' to null out the position error. It is of no help whatsoever for precise time, but great for position. Go read up on Leica Total Station RTK vs handheld RTK sticks, if you are in to surveying. The farmer’s shared RTK networks are pretty incredible, loads of them around here. cm accurate farming. cm accurate watering, planting, fertilizing, tilling, yield mgmt, seed use, seed variety/DNA/plots etc me correlated through using GPS time for location, the RTK measures the slip distances. 7 - BTW, if you have not used it, this is the most incredible video cam network across Calif , many with co - located sesimic sensors. An amazing piece of work and well done. All time syncd. Cal FIRE uses this to spot fires and time stamp them. <https://ops.alertcalifornia.org/> Operations<https://ops.alertcalifornia.org/> ops.alertcalifornia.org<https://ops.alertcalifornia.org/> [AW-favicon-180x180.png]<https://ops.alertcalifornia.org/> rgds to all ! g On Apr 28, 2025, at 12:58 PM, Poul-Henning Kamp via time-nuts <time-nuts@lists.febo.com> wrote: -------- Pavel Kořenský via time-nuts writes: I'm currently using this module in my prototype GPSDO based on a cesium clock, [...] Now, regarding how to measure which clock is "better": that's a tough question. If you have only two clocks, you can't really tell which one is more accurate — you need a third, better reference. […] But that is not really what you want to know, is it ? What you want to know is that your PLL has the right time-constant, so that you derive maximum benefit from both your two sources. This is what Dave Mills called "The Allan Intercept" When your PLL tracks near the Allan Intercept, the error output of the phase detector will have a flat-ish frequency spectrum. If your PLL is too loose, the spectrum will slope up towards higher frequencies, if it is too stiff, lower frequencies will dominate. But be aware that with a Cs-VCO, the signal is in constant peril from rounding and truncation in floating point math. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-leave@lists.febo.com

-------- Geoffrey Baehr writes: > 3 - I don’t know if I can believe chronyc saying it’s 10nS off (from what ?) I suspect what they're actually saying is, that their PLL never estimates the phase error to be more than 10 nanoseconds. That only tells you that they are really good at tracking the input signal, it says nothing about their resulting stability and it strongly hints that their PLL is (too) loose. With modern hardware a loose PLL is not necessarily a bad strategy, but it does have the downside that during loss of reference, it is anyones guess what your last frequency estimate was, and therefore your clock may rapidly wander of target. I usually explain it like this: The XTALs used have spectral purity as controlling parameter, because their output get PLL'ed into the GHz domain. The XTAL temp-co is typically 1 PPM/K. Well adjusted air-con swings the temperature +/- 1-2 K over a 20 minute period. That means that the XTALs, left alone, will swing +/- 1-2 msec over the same 20 minute period. A loose PLL will try to out-compensate the 20 minute swing, giving you timekeeping better than the 1-2 msec, at cost of rapidly wandering into the weeds during LOS. A stiff PLL will average out the 20 minute swing, giving you 1-2 msec timekeeping, also during reasonably long periods of LOS. Pick your poison... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.