Re: [time-nuts] Designing an embedded precision GPS time

[Denny Page]

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

[MLewis]

(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

[Leo Bodnar]

> 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

[Hal Murray]

> 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

[Leo Bodnar]

> 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

[MLewis]

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

[jimlux]

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

[Bob kb8tq]

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

[MLewis]

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

[Tim Shoppa]

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

[Chris Caudle]

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

[Nick Sayer via time-nuts]

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

[Bob kb8tq]

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

[MLewis]

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

[Attila Kinali]

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

[Mark Sims]

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

[Leo Bodnar]

> 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

[Bob kb8tq]

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

[Attila Kinali]

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

[Attila Kinali]

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

[Magnus Danielson]

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

[Mogford, Richard H. (ARC-TH)]

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

[Bob kb8tq]

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.

Re: [time-nuts] HP 5335A Question

[Hal Murray]

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.

Re: [time-nuts] HP 5335A Question

[Jeremy Elson]

I think single shot is only 9 digits. Press "mean" on the left side to get
a 100 sample average that gives you more digits.

On Oct 31, 2017 1:01 PM, "Richard Mogford"  wrote:

> I have an HP 5335A and I am measuring the output of a Suzler 2.5.  I have
> a GPSDO 10 MHz input into the back of the 5335A.
>
> 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.
>
> Does anyone have one of these and could help me figure out how to get 12
> digits displayed?  The manual is not very helpful here.
>
> Richard
> ___
> 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.