Re: [time-nuts] Designing an embedded precision GPS time
Depends upon the results you are trying to achieve. Using Linux pretty much guarantees that your server clock will be off by 6-10us, with substantial variance. Even with a good nic that supports hardware timestamping, the variance will increase substantially as you go off box (spread spectrum is a big annoyance!). If you don’t have hardware timestamping, the base error will increase by another 10-100us, and the variance will simply go through the roof. Any load on the system whatsoever will quickly drive further degradation throughout. This is why people generally talk about NTP having a “typical" accuracy of 1ms and a standard deviation over 100us. For casual use, this is fine for most people. The LeoNTP units operate in a completely different world. Leo advertises accuracy of under 1us, which matches the general performance of PTP. In my testing, the units actually do a bit better than that. Using hardware timestamps on the client, I generally see less than +-100ns, with a standard deviation of around 35ns. And the performance remains constant under load. I am not able to do heavy load testing, but Leo has described the heavy load performance earlier in the thread. Basically the units are capable of operating at 100Mb wire speed. As I said, a completely different world. Your mileage may vary. Denny > On Oct 31, 2017, at 17:11, Attila Kinali wrote: > > Basically, all you have to do is use an SBC that runs linux and has > a GPIO with an interrupt to act as a PPS input. Attach a GPS receiver > and you are almost done. ___ 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] Holdover, RTC for Pi as NTP GPS source
(I suspect this is drifting from the original thread too much, so new subject) Temperature ranges from 65F to 78F, with the potential for drafts, but is more typically 76F. I read about the NTPsec runs with insulating a Pi and running a load generating program to better maintain a stable core temperature. Just today I've put my GPS module inside a case for an RF shield that is also semi insulated. It's feeding LH on a PC while I do the next step. The Pi 3 is going inside a large enough tea tin and that will be lined with insulation. I'm wondering about insulating the RTC... The low cost for a 'precision' RTC means it is cheap to test. I'd completely discounted coasting with the system clock, as I have fixed in my head the variable loads on my production machine mean that Window's time lags variable amounts, as the CPU load is variable with variable burst loads every 1/8 of a second. Michael On 31/10/2017 11:45 PM, Hal Murray wrote: I'm intending to add a "precision" (well, precision to the Pi world) RTC to my Pi 3 to use for a holdover source when it hasn't got PPS from the GPS module. An RTC that +/- 3 PPM over 24 hours would be great for holdovers of one to 20 minutes. Run some experiments to collect some data and play with the numbers. How stable is the temperature in your environment? The key to keeping sane time on a PC or Raspberry PI is to calibrate the crystal. Most CPUs have a register that counts at the CPU clock frequency - or something in that range. Most systems smear the clock to keep the FCC happy... Most OSes keep time by watching that register and dividing by the clock rate. The actual clock rate doesn't usually match the number printed on the crystal. It's close, but ntpd can easily measure the error and tell the kernel so the kernel can use the right value. If you turn on loopstats, ntpd will log it and you can graph it. If you are writing an embedded system, you will want that sort of logic too. My guess is that in the under 30 minute range, you will get better results by just coasting with the system clock rather that using a RTC. It would be an interesting experiment. Implement both clocking schemes and compare them. ___ 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] Designing an embedded precision GPS time
> From: Attila Kinali > Basically, all you have to do is use an SBC that runs linux and has > a GPIO with an interrupt to act as a PPS input. Attach a GPS receiver > and you are almost done. The cheapest option are probably the i.MX233 > based ones (go as low as €20). Thank you, Attila, this sounds like the way to go - perhaps I can repackage this solution in a smart attractive enclosure and market it as a high performance product. I was a bit behind the curve on recent developments - do you have a suggestion for the best linux running SBC and cheap GPS suitable for this? >> I am not measuring any frequencies - the whole device runs synchronously >> hard- >> locked to GPS time when it is available and freewheeling when not. > > You should have a control loop somewhere, which explicitly or implicitly > estimates the frequency of the TCXO. > The time-nuts archives are full with discussions how to do such > control loops and improve hold over performance. Though there > weren't many in the last 2-3 years. John Vigs tutorial is also > a good start. OK, so I need to introduce additional TCXO and a control loop to improve the holdover performance? Thanks Leo ___ 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] Designing an embedded precision GPS time
> I'm intending to add a "precision" (well, precision to the Pi world) RTC to > my Pi 3 to use for a holdover source when it hasn't got PPS from the GPS > module. > An RTC that +/- 3 PPM over 24 hours would be great for holdovers of one to > 20 minutes. Run some experiments to collect some data and play with the numbers. How stable is the temperature in your environment? The key to keeping sane time on a PC or Raspberry PI is to calibrate the crystal. Most CPUs have a register that counts at the CPU clock frequency - or something in that range. Most systems smear the clock to keep the FCC happy... Most OSes keep time by watching that register and dividing by the clock rate. The actual clock rate doesn't usually match the number printed on the crystal. It's close, but ntpd can easily measure the error and tell the kernel so the kernel can use the right value. If you turn on loopstats, ntpd will log it and you can graph it. If you are writing an embedded system, you will want that sort of logic too. My guess is that in the under 30 minute range, you will get better results by just coasting with the system clock rather that using a RTC. It would be an interesting experiment. Implement both clocking schemes and compare them. -- 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] Designing an embedded precision GPS time
> From: Bob kb8tq > Working all this back into a holdover spec in an unknown temperature > environment is not at all easy. > Bob This is true, it is too easy to multiply figures from the datasheet and then start believing in them. We did extensive testing of real units in real life before committing to any specification figures. They are based on statistical measurements followed by an expanded safety margin. Here is a typical holdover offset curve over 24 hours in non-DC environment (i.e. 5-10 degrees ambient temperature change during day/night period.) http://leobodnar.com/balloons/NTP/24hr-holdover.png Time drift over 24h on this particular unit was below 0.7ms. This is pretty good for the device that consumes 1W of power (via PoE or USB) and fits in the pocket. I have used typical Raspberry Pi with a GPS add-on run-of-the-mill timeserver as suggested by Attila to monitor relative offsets - this is why reported timing is jittery and local (to RPi) 1PPS has an offset. It is really puzzling why holdover has suddenly come into focus. Due to NTP redundancy feature it is trivial to put several inexpensive time servers around the local or campus network and let clients do the standard NTP sanity checking and server selection. And those building an NTP system able to cope with 24h+ global GPS outage know what they are doing anyway. Leo ___ 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] Designing an embedded precision GPS time
I'm stuck with a near ground level antenna site (~16" above grade?), with half a sky view (thankfully to the SSE), less some low blocking buildings with regular mutlipath, plus multipath bouncing off a taller building to the SE that bounces sats from the NW at me from low over the Bering Strait. The building I'm in is concrete with flat steel under each floor from the construction method. As I write this I'm down to two green sats in LH. A number of times a day, it will drop to one sat, and there's a few dropouts a day where it goes to none of sufficient signal. How many times and for how long varies by the day. It's worse when it's wet out, which it is right now. If I lower the signal strength threshold, then I end up with tons of multipath signals. If I can ever get a bios update to my NEO-M8T, then I'll have GAL in the mix and should experience fewer dropouts, potentially none. An RTC that +/- 3 PPM over 24 hours would be great for holdovers of one to 20 minutes. While I wrote this, LH was typically showing two or three green sats, once up to five and once down to one. And I just hit a dropout... for a minute and a half; the one remaining green sat went behind the corner of the building's entrance canopy, then back out. On 31/10/2017 10:30 PM, Bob kb8tq wrote: Hi Under what conditions would you expect to loose GPS? I seem to be able to do just fine sitting in an armchair here in the family room. That’s hardly a fancy setup. Bob On Oct 31, 2017, at 10:27 PM, MLewis wrote: I'm intending to add a "precision" (well, precision to the Pi world) RTC to my Pi 3 to use for a holdover source when it hasn't got PPS from the GPS module. On 31/10/2017 10:04 PM, Chris Caudle wrote: On Tue, October 31, 2017 7:19 pm, MLewis wrote: ...the "better" quality RTCs seem to be DS3231 based How does one translate that into an expected 24 hour holdover? For the RTC, or for an NTP server? If the NTP server is running it will not make a difference, modern operating systems do not use the RTC for the system clock, only to get close to the correct time at startup. ___ 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. ___ 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] Designing an embedded precision GPS time
On 10/31/17 1:47 PM, Bob kb8tq wrote: HI TCXO is a very loosely defined term. A part that does +/- 5 ppm -40 to +85C is a TCXO. A part that does +/- 5x10^-9 over 0 to 50C may also be a TCXO. Dividing the total deviation of either one by the temperature range to come up with a “delta frequency per degree” number would be a mistake. You would get a number that is much better than the real part exhibits. Working all this back into a holdover spec in an unknown temperature environment is not at all easy. Very much so - most of the TCXO curves I've seen tend to be "much" better than the spec over the central part of the frequency range (which makes sense, the underlying crystal is a cubic with temp, most likely) Retrace and hysteresis might be your dominant uncertainty. I've attached a typical TCXO data plot for your viewing pleasure.. (that's an expensive oscillator, because it's for space, but I don't think space or not changes the underlying performance) Bob TCXODataVectron 47.pdf Description: Adobe PDF document ___ 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] Designing an embedded precision GPS time
Hi Under what conditions would you expect to loose GPS? I seem to be able to do just fine sitting in an armchair here in the family room. That’s hardly a fancy setup. Bob > On Oct 31, 2017, at 10:27 PM, MLewis wrote: > > I'm intending to add a "precision" (well, precision to the Pi world) RTC to > my Pi 3 to use for a holdover source when it hasn't got PPS from the GPS > module. > > On 31/10/2017 10:04 PM, Chris Caudle wrote: >> On Tue, October 31, 2017 7:19 pm, MLewis wrote: >>> ...the "better" quality RTCs seem to be DS3231 based >>> How does one translate that into an expected 24 hour holdover? >> For the RTC, or for an NTP server? If the NTP server is running it will >> not make a difference, modern operating systems do not use the RTC for the >> system clock, only to get close to the correct time at startup. >> > > ___ > 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] Designing an embedded precision GPS time
I'm intending to add a "precision" (well, precision to the Pi world) RTC to my Pi 3 to use for a holdover source when it hasn't got PPS from the GPS module. On 31/10/2017 10:04 PM, Chris Caudle wrote: On Tue, October 31, 2017 7:19 pm, MLewis wrote: ...the "better" quality RTCs seem to be DS3231 based How does one translate that into an expected 24 hour holdover? For the RTC, or for an NTP server? If the NTP server is running it will not make a difference, modern operating systems do not use the RTC for the system clock, only to get close to the correct time at startup. ___ 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] Designing an embedded precision GPS time
I don't know of any "non-historic" NTP implementation that even attempts to drift correct the RTC clock. Now, the RTC clock is useful to set the time at boot before ntpd gets started. Tim N3QE On Tue, Oct 31, 2017 at 8:19 PM, MLewis wrote: > If one is building a GPS disciplined NTP Stratum 1 server from a Pi or > Beaglebone, the "better" quality RTCs seem to be > > DS3231 based (DallasSemi/Maxim), Accuracy ±2ppm from 0°C to +40°C, ±3.5ppm > from -40°C to +85°C > > or > > NXP: > PCF2127AT: ±3 ppm from -15 °C to +60 °C > PCF2127T: ±3 ppm from -30 °C to +80 °C > PCF2129AT: ±3 ppm from -15 °C to +60 °C > PCF2129T: ±3 ppm from -30 °C to +80 °C > > How does one translate that into an expected 24 hour holdover? > > And, are there better choices for a low cost RTC? > > Thanks, > > Michael > > On 31/10/2017 4:47 PM, Bob kb8tq wrote: > >> HI >> >> TCXO is a very loosely defined term. A part that does +/- 5 ppm -40 to >> +85C >> is a TCXO. A part that does +/- 5x10^-9 over 0 to 50C may also be a TCXO. >> >> Dividing the total deviation of either one by the temperature range to >> come >> up with a “delta frequency per degree” number would be a mistake. You >> would get a number that is much better than the real part exhibits. >> >> Working all this back into a holdover spec in an unknown temperature >> environment is not at all easy. >> >> Bob >> >> >> On Oct 31, 2017, at 4:03 PM, Attila Kinali wrote: >>> >>> Hoi Leo, >>> >>> On Sat, 28 Oct 2017 11:14:08 +0100 >>> Leo Bodnar wrote: >>> >>> True. An NTP server does not need to measure time better than 100ns or >>> so. >>> 10ns is probably more than good enough. But then, this raises the >>> question >>> what your performance metric is that you optimize for? >>> >>> If it is hold-over, then this will be limited by the TCXO and how well >>> you can measure its frequency, which in turn depends on how well you >>> can measure the PPS pulse. You say that your device is typically within >>> 4-5ms in 24h of hold-over. That translates to frequency uncertainty >>> of approximately 5e-8. That's not that good. >>> >> > >> To summarize: If you want to improve your ntp devices hold over >> performance >> you have to improve the frequency measurement and use a better clock >> modeling. >> Ie, use a timing GPS receiver and its sawtooth correction, and model the >> clocks frequency change over time. >> >> >> Attila Kinali >> -- >> > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/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] Designing an embedded precision GPS time
On Tue, October 31, 2017 7:19 pm, MLewis wrote: > ...the "better" quality RTCs seem to be DS3231 based > How does one translate that into an expected 24 hour holdover? For the RTC, or for an NTP server? If the NTP server is running it will not make a difference, modern operating systems do not use the RTC for the system clock, only to get close to the correct time at startup. -- 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] Designing an embedded precision GPS time
At the moment, my plan is to not support hold-over at all. If GPS doesn’t have a fix and I’m not getting PPS pulses, I intend to either jump immediately to stratum 16 or just not respond. > On Oct 31, 2017, at 1:03 PM, Attila Kinali wrote: > > Hoi Leo, > > On Sat, 28 Oct 2017 11:14:08 +0100 > Leo Bodnar wrote: > >>> From: Attila Kinali >>> Can you tell a little bit how your device looks like on the inside? >> >> GPS is a Ublox. MCU is Cortex-M7 and does not run any OS - just main loop >> with prioritised interrupts. Network stack is hand-made. >> I don't use saw-tooth correction in this device because +-11ns is not worth >> correcting for NTP application for such a budget device. >> If you can build a test NTP client system that can detect sawtooth 10ns >> offset from the NTP server I'd like to know how you did it. > > True. An NTP server does not need to measure time better than 100ns or so. > 10ns is probably more than good enough. But then, this raises the question > what your performance metric is that you optimize for? > > If it is hold-over, then this will be limited by the TCXO and how well > you can measure its frequency, which in turn depends on how well you > can measure the PPS pulse. You say that your device is typically within > 4-5ms in 24h of hold-over. That translates to frequency uncertainty > of approximately 5e-8. That's not that good. > To put this into perspective have a look at the two attached plots. > These are the PPM values that ntp reports for a standard server (HP DL380G7). > The first plot shows the long term variation of all the data I currently have. > The three jumps coincide with days when we restarted ntpd. As you can see, > the long term variation of the crystal frequency is well below 0.5ppm. The > second plot zooms in into one of the day with large variations. The worst > of these being about 10ppb. Lets assume for simplicity, the 10ppb step happens > instantaneous, then this would result in a hold over performance of ~0.9ms > in 24h. Yes, this is not a fair comparison. The sever is in a room where > temperature is pretty much constant (sorry, I don't have any data on that, > but assume less than 5°C variation within a day). And it's not true hold > over performance, but a guestimation from the ntp provided loop data. But > even if we add a factor of 10, this simple, unstabilized, unsophisticated > PC comes pretty close to the performance your device claims. And that's not > even a PC with a good crystal (I have measurements of others, that showed > variation of less than 2ppb over months in rooms without air conditioning). > > Or to put it differently: If i'd get a Minnow Turbot, add a GPS receiver, > put everything in a metal box and just use normal ntpd, i'd expect to > have a hold over performance of better than 100ms/24h (assuming 1ppm > stability of the crystal), probably in the order of 10ms/24h and it would > have no problems handling a humongous number of clients, thanks to the > fast CPU (1.4GHz) and the Gbit/s ethernet interface. > > So, why does a simple PC with ntp do such a good job? The secret > lies in the measurement: Very much simplified, ntp measures the > frequency in 1000s intervals. Measurement uncertainty is reported to be > better than 100us per reference server. Ie the uncertainty is in > better than 1e-7 (compare with the estimated 5e-8 from above). > Add to that averaging over multiple reference severs (4 in this case) > and a sophisticated clock parameter estimation and the uncertainty > goes down quite a bit. > > To summarize: If you want to improve your ntp devices hold over performance > you have to improve the frequency measurement and use a better clock modeling. > Ie, use a timing GPS receiver and its sawtooth correction, and model the > clocks frequency change over time. > > > Attila Kinali > -- > It is upon moral qualities that a society is ultimately founded. All > the prosperity and technological sophistication in the world is of no > use without that foundation. > -- Miss Matheson, The Diamond Age, Neil 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. ___ 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] Designing an embedded precision GPS time
HI > On Oct 31, 2017, at 8:19 PM, MLewis wrote: > > If one is building a GPS disciplined NTP Stratum 1 server from a Pi or > Beaglebone, the "better" quality RTCs seem to be > > DS3231 based (DallasSemi/Maxim), Accuracy ±2ppm from 0°C to +40°C, ±3.5ppm > from -40°C to +85°C > > or > > NXP: >PCF2127AT: ±3 ppm from -15 °C to +60 °C >PCF2127T: ±3 ppm from -30 °C to +80 °C >PCF2129AT: ±3 ppm from -15 °C to +60 °C >PCF2129T: ±3 ppm from -30 °C to +80 °C > > How does one translate that into an expected 24 hour holdover? The simple answer is that you really don’t have enough information. The useless answer (which is easy to come up with) is that you would be off by a bit under 0.3 seconds per day if you clock is 3 ppm off. Since that’s just the TC error, there would have to be a zeroing process. If you “zero out” the error at -3 ppm and then temperature moves you to +3 ppm, you could be off by a bit under 0.6 seconds in a day. Yes you could carry this out to many more digits, it’s really an accurate guess beyond the first digit. Bob > > And, are there better choices for a low cost RTC? > > Thanks, > > Michael > > On 31/10/2017 4:47 PM, Bob kb8tq wrote: >> HI >> >> TCXO is a very loosely defined term. A part that does +/- 5 ppm -40 to +85C >> is a TCXO. A part that does +/- 5x10^-9 over 0 to 50C may also be a TCXO. >> >> Dividing the total deviation of either one by the temperature range to come >> up with a “delta frequency per degree” number would be a mistake. You >> would get a number that is much better than the real part exhibits. >> >> Working all this back into a holdover spec in an unknown temperature >> environment is not at all easy. >> >> Bob >> >> >>> On Oct 31, 2017, at 4:03 PM, Attila Kinali wrote: >>> >>> Hoi Leo, >>> >>> On Sat, 28 Oct 2017 11:14:08 +0100 >>> Leo Bodnar wrote: >>> >>> True. An NTP server does not need to measure time better than 100ns or so. >>> 10ns is probably more than good enough. But then, this raises the question >>> what your performance metric is that you optimize for? >>> >>> If it is hold-over, then this will be limited by the TCXO and how well >>> you can measure its frequency, which in turn depends on how well you >>> can measure the PPS pulse. You say that your device is typically within >>> 4-5ms in 24h of hold-over. That translates to frequency uncertainty >>> of approximately 5e-8. That's not that good. > >> >> To summarize: If you want to improve your ntp devices hold over performance >> you have to improve the frequency measurement and use a better clock >> modeling. >> Ie, use a timing GPS receiver and its sawtooth correction, and model the >> clocks frequency change over time. >> >> >> Attila Kinali >> -- > > ___ > 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] Designing an embedded precision GPS time
If one is building a GPS disciplined NTP Stratum 1 server from a Pi or Beaglebone, the "better" quality RTCs seem to be DS3231 based (DallasSemi/Maxim), Accuracy ±2ppm from 0°C to +40°C, ±3.5ppm from -40°C to +85°C or NXP: PCF2127AT: ±3 ppm from -15 °C to +60 °C PCF2127T: ±3 ppm from -30 °C to +80 °C PCF2129AT: ±3 ppm from -15 °C to +60 °C PCF2129T: ±3 ppm from -30 °C to +80 °C How does one translate that into an expected 24 hour holdover? And, are there better choices for a low cost RTC? Thanks, Michael On 31/10/2017 4:47 PM, Bob kb8tq wrote: HI TCXO is a very loosely defined term. A part that does +/- 5 ppm -40 to +85C is a TCXO. A part that does +/- 5x10^-9 over 0 to 50C may also be a TCXO. Dividing the total deviation of either one by the temperature range to come up with a “delta frequency per degree” number would be a mistake. You would get a number that is much better than the real part exhibits. Working all this back into a holdover spec in an unknown temperature environment is not at all easy. Bob On Oct 31, 2017, at 4:03 PM, Attila Kinali wrote: Hoi Leo, On Sat, 28 Oct 2017 11:14:08 +0100 Leo Bodnar wrote: True. An NTP server does not need to measure time better than 100ns or so. 10ns is probably more than good enough. But then, this raises the question what your performance metric is that you optimize for? If it is hold-over, then this will be limited by the TCXO and how well you can measure its frequency, which in turn depends on how well you can measure the PPS pulse. You say that your device is typically within 4-5ms in 24h of hold-over. That translates to frequency uncertainty of approximately 5e-8. That's not that good. To summarize: If you want to improve your ntp devices hold over performance you have to improve the frequency measurement and use a better clock modeling. Ie, use a timing GPS receiver and its sawtooth correction, and model the clocks frequency change over time. Attila Kinali -- ___ 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] Designing an embedded precision GPS time
On Tue, 31 Oct 2017 21:03:05 + Leo Bodnar wrote: > The goal was maximum throughput with minimum time offset. > Maximum throughput eventually ended up as "fully saturated full-duplex > 100BASE-TX" and minimum time offset as "below 1 microsecond" > There was nothing on the market below £2-3k that could do that. I think > Microsemi has recently made a server that can do 100kpps+ but I don't know > its price. Hmm? There are at least a dozen how-tos out there that explain how to make an NTP server out of an SBC. And I have seen the one or other being sold as a complete box with batteries included. Basically, all you have to do is use an SBC that runs linux and has a GPIO with an interrupt to act as a PPS input. Attach a GPS receiver and you are almost done. The cheapest option are probably the i.MX233 based ones (go as low as €20). The probably most mentioned option is using a Beaglebone Black. If I had to build something like this today, I would probably go for an OSD3358, which is an AM3358 packaged with memory and power management and allows using a simple 4 layer board. Add a few bits for ethernet and the GPS and you are almost done. > I do want to improve my NTP devices but I do not understand what you are > suggesting. > Why would sawtooth correction matter when there is no GPS signal available at > all? It matters while you have signal. > I am not measuring any frequencies - the whole device runs synchronously hard- > locked to GPS time when it is available and freewheeling when not. You should have a control loop somewhere, which explicitly or implicitly estimates the frequency of the TCXO. The time-nuts archives are full with discussions how to do such control loops and improve hold over performance. Though there weren't many in the last 2-3 years. John Vigs tutorial is also a good start. > Are you saying that if you deprive any PC of any connectivity it will drift > by 4-5ms in 24 hours? Almost. It has to have ntp running and ntp must have had time to discipline the local oscillator. If the PC is then in an environment that will not cause its oscillator to drift more than 10-100ppb per day, then it will stay below 10ms. There are a few ifs there, but it's nothing out of the ordinary. Even ordinary crystal oscillators can be quite stable if they have been running for a while. Just for comparison: decent wrist watches drift less than 1min in half a year. Good ones less than 10s. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil 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.
[time-nuts] Nanosecond level GNSS data from Android devices
http://www.theregister.co.uk/2017/10/31/google_gnss_analysis_tool_accurate_to_nanosecond_movements/ I wonder how well it works on a $20 Android tablet / phone? ___ 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] Designing an embedded precision GPS time
> From: Attila Kinali > True. An NTP server does not need to measure time better than 100ns or so. > 10ns is probably more than good enough. But then, this raises the question > what your performance metric is that you optimize for? The goal was maximum throughput with minimum time offset. Maximum throughput eventually ended up as "fully saturated full-duplex 100BASE-TX" and minimum time offset as "below 1 microsecond" There was nothing on the market below £2-3k that could do that. I think Microsemi has recently made a server that can do 100kpps+ but I don't know its price. > If it is hold-over, then this will be limited by the TCXO and how well > you can measure its frequency, which in turn depends on how well you > can measure the PPS pulse. You say that your device is typically within > 4-5ms in 24h of hold-over. That translates to frequency uncertainty > of approximately 5e-8. That's not that good. > To put this into perspective have a look at the two attached plots. > These are the PPM values that ntp reports for a standard server (HP DL380G7). > The first plot shows the long term variation of all the data I currently have. > The three jumps coincide with days when we restarted ntpd. As you can see, > the long term variation of the crystal frequency is well below 0.5ppm. The > second plot zooms in into one of the day with large variations. The worst > of these being about 10ppb. Lets assume for simplicity, the 10ppb step happens > instantaneous, then this would result in a hold over performance of ~0.9ms > in 24h. Yes, this is not a fair comparison. The sever is in a room where > temperature is pretty much constant (sorry, I don't have any data on that, > but assume less than 5°C variation within a day). And it's not true hold > over performance, but a guestimation from the ntp provided loop data. But > even if we add a factor of 10, this simple, unstabilized, unsophisticated > PC comes pretty close to the performance your device claims. And that's not > even a PC with a good crystal (I have measurements of others, that showed > variation of less than 2ppb over months in rooms without air conditioning). > > Or to put it differently: If i'd get a Minnow Turbot, add a GPS receiver, > put everything in a metal box and just use normal ntpd, i'd expect to > have a hold over performance of better than 100ms/24h (assuming 1ppm > stability of the crystal), probably in the order of 10ms/24h and it would > have no problems handling a humongous number of clients, thanks to the > fast CPU (1.4GHz) and the Gbit/s ethernet interface. > > So, why does a simple PC with ntp do such a good job? The secret > lies in the measurement: Very much simplified, ntp measures the > frequency in 1000s intervals. Measurement uncertainty is reported to be > better than 100us per reference server. Ie the uncertainty is in > better than 1e-7 (compare with the estimated 5e-8 from above). > Add to that averaging over multiple reference severs (4 in this case) > and a sophisticated clock parameter estimation and the uncertainty > goes down quite a bit. > > To summarize: If you want to improve your ntp devices hold over performance > you have to improve the frequency measurement and use a better clock modeling. > Ie, use a timing GPS receiver and its sawtooth correction, and model the > clocks frequency change over time. I do want to improve my NTP devices but I do not understand what you are suggesting. Why would sawtooth correction matter when there is no GPS signal available at all? I am not measuring any frequencies - the whole device runs synchronously hard-locked to GPS time when it is available and freewheeling when not. This is reference stratum 1 clock, it does connect to any servers, it only serves clients. If you chop off its antenna and disconnect local LAN segment from the internet and other NTP servers, local network time will drift off by 4-5ms in 24 hours and then the server will fall back to stratum 16 and will tell clients that it cannot provide accurate time anymore. > But even if we add a factor of 10, this simple, unstabilized, > unsophisticated PC comes pretty close to the performance your device claims. Are you saying that if you deprive any PC of any connectivity it will drift by 4-5ms in 24 hours? Leo ___ 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] Designing an embedded precision GPS time
HI TCXO is a very loosely defined term. A part that does +/- 5 ppm -40 to +85C is a TCXO. A part that does +/- 5x10^-9 over 0 to 50C may also be a TCXO. Dividing the total deviation of either one by the temperature range to come up with a “delta frequency per degree” number would be a mistake. You would get a number that is much better than the real part exhibits. Working all this back into a holdover spec in an unknown temperature environment is not at all easy. Bob > On Oct 31, 2017, at 4:03 PM, Attila Kinali wrote: > > Hoi Leo, > > On Sat, 28 Oct 2017 11:14:08 +0100 > Leo Bodnar wrote: > >>> From: Attila Kinali >>> Can you tell a little bit how your device looks like on the inside? >> >> GPS is a Ublox. MCU is Cortex-M7 and does not run any OS - just main loop >> with prioritised interrupts. Network stack is hand-made. >> I don't use saw-tooth correction in this device because +-11ns is not worth >> correcting for NTP application for such a budget device. >> If you can build a test NTP client system that can detect sawtooth 10ns >> offset from the NTP server I'd like to know how you did it. > > True. An NTP server does not need to measure time better than 100ns or so. > 10ns is probably more than good enough. But then, this raises the question > what your performance metric is that you optimize for? > > If it is hold-over, then this will be limited by the TCXO and how well > you can measure its frequency, which in turn depends on how well you > can measure the PPS pulse. You say that your device is typically within > 4-5ms in 24h of hold-over. That translates to frequency uncertainty > of approximately 5e-8. That's not that good. > To put this into perspective have a look at the two attached plots. > These are the PPM values that ntp reports for a standard server (HP DL380G7). > The first plot shows the long term variation of all the data I currently have. > The three jumps coincide with days when we restarted ntpd. As you can see, > the long term variation of the crystal frequency is well below 0.5ppm. The > second plot zooms in into one of the day with large variations. The worst > of these being about 10ppb. Lets assume for simplicity, the 10ppb step happens > instantaneous, then this would result in a hold over performance of ~0.9ms > in 24h. Yes, this is not a fair comparison. The sever is in a room where > temperature is pretty much constant (sorry, I don't have any data on that, > but assume less than 5°C variation within a day). And it's not true hold > over performance, but a guestimation from the ntp provided loop data. But > even if we add a factor of 10, this simple, unstabilized, unsophisticated > PC comes pretty close to the performance your device claims. And that's not > even a PC with a good crystal (I have measurements of others, that showed > variation of less than 2ppb over months in rooms without air conditioning). > > Or to put it differently: If i'd get a Minnow Turbot, add a GPS receiver, > put everything in a metal box and just use normal ntpd, i'd expect to > have a hold over performance of better than 100ms/24h (assuming 1ppm > stability of the crystal), probably in the order of 10ms/24h and it would > have no problems handling a humongous number of clients, thanks to the > fast CPU (1.4GHz) and the Gbit/s ethernet interface. > > So, why does a simple PC with ntp do such a good job? The secret > lies in the measurement: Very much simplified, ntp measures the > frequency in 1000s intervals. Measurement uncertainty is reported to be > better than 100us per reference server. Ie the uncertainty is in > better than 1e-7 (compare with the estimated 5e-8 from above). > Add to that averaging over multiple reference severs (4 in this case) > and a sophisticated clock parameter estimation and the uncertainty > goes down quite a bit. > > To summarize: If you want to improve your ntp devices hold over performance > you have to improve the frequency measurement and use a better clock modeling. > Ie, use a timing GPS receiver and its sawtooth correction, and model the > clocks frequency change over time. > > > Attila Kinali > -- > It is upon moral qualities that a society is ultimately founded. All > the prosperity and technological sophistication in the world is of no > use without that foundation. > -- Miss Matheson, The Diamond Age, Neil 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. ___ 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] Spice simulation of PSRR and phase noise
Hoi Bert, On Sun, 29 Oct 2017 08:06:37 -0400 Bert Kehren via time-nuts wrote: > Thank you for posting the link to Richard's excellent paper that does not > only apply to Cs. In my opinion it is a must read for any one serious in > doing any work on time and frequency issues. Well, the way how the HP 5071 synthesis chain is designed is the way one would do it today. Using SRDs went pretty much out of fashion, and not only because they are hard to buy these days. Today we have monolithic VCOs that give 9GHz in a tiny packages with good phase noise performance. We have PLLs with integrated dividers that can handle 10GHz inputs with 10MHz references directly. Ie you could simplify the synthesis chain even further. You could build the complete synthesis chain for the 5071 on a PCB of 5x5cm and still have space to spare. Even using a DRO (for lower phase noise) would not make the circuit much bigger. We kind of live in the golden age of electronics design, even if the constant shrinking of parts makes them harder to handle for hobbyists. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil 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] Designing an embedded precision GPS time
Hoi Leo, On Sat, 28 Oct 2017 11:14:08 +0100 Leo Bodnar wrote: > > From: Attila Kinali > > Can you tell a little bit how your device looks like on the inside? > > GPS is a Ublox. MCU is Cortex-M7 and does not run any OS - just main loop > with prioritised interrupts. Network stack is hand-made. > I don't use saw-tooth correction in this device because +-11ns is not worth > correcting for NTP application for such a budget device. > If you can build a test NTP client system that can detect sawtooth 10ns > offset from the NTP server I'd like to know how you did it. True. An NTP server does not need to measure time better than 100ns or so. 10ns is probably more than good enough. But then, this raises the question what your performance metric is that you optimize for? If it is hold-over, then this will be limited by the TCXO and how well you can measure its frequency, which in turn depends on how well you can measure the PPS pulse. You say that your device is typically within 4-5ms in 24h of hold-over. That translates to frequency uncertainty of approximately 5e-8. That's not that good. To put this into perspective have a look at the two attached plots. These are the PPM values that ntp reports for a standard server (HP DL380G7). The first plot shows the long term variation of all the data I currently have. The three jumps coincide with days when we restarted ntpd. As you can see, the long term variation of the crystal frequency is well below 0.5ppm. The second plot zooms in into one of the day with large variations. The worst of these being about 10ppb. Lets assume for simplicity, the 10ppb step happens instantaneous, then this would result in a hold over performance of ~0.9ms in 24h. Yes, this is not a fair comparison. The sever is in a room where temperature is pretty much constant (sorry, I don't have any data on that, but assume less than 5°C variation within a day). And it's not true hold over performance, but a guestimation from the ntp provided loop data. But even if we add a factor of 10, this simple, unstabilized, unsophisticated PC comes pretty close to the performance your device claims. And that's not even a PC with a good crystal (I have measurements of others, that showed variation of less than 2ppb over months in rooms without air conditioning). Or to put it differently: If i'd get a Minnow Turbot, add a GPS receiver, put everything in a metal box and just use normal ntpd, i'd expect to have a hold over performance of better than 100ms/24h (assuming 1ppm stability of the crystal), probably in the order of 10ms/24h and it would have no problems handling a humongous number of clients, thanks to the fast CPU (1.4GHz) and the Gbit/s ethernet interface. So, why does a simple PC with ntp do such a good job? The secret lies in the measurement: Very much simplified, ntp measures the frequency in 1000s intervals. Measurement uncertainty is reported to be better than 100us per reference server. Ie the uncertainty is in better than 1e-7 (compare with the estimated 5e-8 from above). Add to that averaging over multiple reference severs (4 in this case) and a sophisticated clock parameter estimation and the uncertainty goes down quite a bit. To summarize: If you want to improve your ntp devices hold over performance you have to improve the frequency measurement and use a better clock modeling. Ie, use a timing GPS receiver and its sawtooth correction, and model the clocks frequency change over time. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil 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] HP 5335A Question
Hi, The HP5335A with it’s about 1 ns single-shot resolution is with 9 digits at 1 s. The beauty of it is how you just turn a knob to balance read-out speed vs. resolution. It remains one of the user-friendliest counters I’ve worked with. The averaging allows to extend beyond the time-base length, but that’s where I prefer to move over to TimeLab instead. Cheers, Magnus > On 31 Oct 2017, at 16:57, Bob kb8tq wrote: > > Hi > > One of the most user friendly ways to get a 5334 or 5335 to display max > resolution > is to put in into a math function mode. Subtract out the nominal center > frequency of > the source and just look at the “delta” from that center. > > Regardless of the tricks, these counters will not give you 12 real digits in > a second. > They are only able to get to 9 digits (or slightly less) in a second. Extend > the gate time > past a point and they overflow internally. You can still get data out, it > takes some thought > to make sense of it. > > Bob > >> On Oct 31, 2017, at 2:12 AM, Hal Murray wrote: >> >> >> rch...@earthlink.net said: >>> There is mention in the manual that the counter can display 11 or 12 digits >>> (in addition to the two Exponent digits). I presently have it displaying >>> nine digits. >> >> I have a 5334A, no 5335. >> >> As Jeff said, you get more digits with a longer gate time. >> >> If you make the gate time long enough on a 5334A, you can get more digits >> via >> HPIB than fit on the screen. >> >> >> -- >> 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. > > ___ > 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.
[time-nuts] Thanks
Thanks for the help on the HP 5335A! Richard ___ 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] HP 5335A Question
Hi One of the most user friendly ways to get a 5334 or 5335 to display max resolution is to put in into a math function mode. Subtract out the nominal center frequency of the source and just look at the “delta” from that center. Regardless of the tricks, these counters will not give you 12 real digits in a second. They are only able to get to 9 digits (or slightly less) in a second. Extend the gate time past a point and they overflow internally. You can still get data out, it takes some thought to make sense of it. Bob > On Oct 31, 2017, at 2:12 AM, Hal Murray wrote: > > > rch...@earthlink.net said: >> There is mention in the manual that the counter can display 11 or 12 digits >> (in addition to the two Exponent digits). I presently have it displaying >> nine digits. > > I have a 5334A, no 5335. > > As Jeff said, you get more digits with a longer gate time. > > If you make the gate time long enough on a 5334A, you can get more digits via > HPIB than fit on the screen. > > > -- > 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. ___ 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.
