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

[Andrew Rodland]

Hi Nick,

I've got a project along those lines that I've been hacking on for the past
three years or so, and always meaning to do a thorough writeup on. I'm more
of a software than hardware guy, so the heart of it is a Taijiuino Due (a
weird Chinese clone of the Arduino Due, so an 84MHz ATSAM3X8E, with the
difference from the official board being that it brings out the SAM's
Ethernet pins to a header that you can perch a PHY module on). It then
talks to a GPS (Resolution-SMT) and Rb (SA.22c, digitally controlled),
multiplied up 25/8 times by a TAPR Clock-Block to get 32ns granularity
(more or less). Apart from some of the low-level MAC code which is from
Atmel it's all my code for GPS decoding, timekeeping, NTP, etc, and has
some basic support for health monitoring and holdover.

As a NTP server it's pretty good when it's behaving -- I've got a
particularly-stable Linux machine on the same Ethernet segment polling it
at 16s interval and chrony reports a 500ns - 1us stdev for it, so you can
take that as a jitter figure. It outperforms the old Spectracom NetClock
9183 (w/OCXO option) I've got, in any case.

I'd be interested in comparing notes, and also interested in any
possibility of designing a PCB to replace the rat's nest of wires I've got
going on -- as I mentioned, I'm not "really" a hardware guy and EDA isn't a
skill I've picked up at this point. I've always wanted to derive the
micro's clock from the Rb (and PLL it up on the chip) rather than having to
live with the restrictions of an externally-clocked timer... but making
that happen is beyond my abilities :)


On Wed, Oct 25, 2017 at 8:53 PM, Nick Sayer via time-nuts <
time-nuts@febo.com> wrote:

> I’ve just completed a project (off topic) with the ATSAMS70 chip and
> learned a lot in a relatively short time, and I really like the result.
>
> I am considering a new project based on its cousin, the ATSAME70. The E70
> has an Ethernet 10/100 MAC built in as well as the rest of the stuff the
> S70 has (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice),
> and Atmel Start (the software development framework I’ve been using)
> purports to have a ready-to-use IP stack (alas, no IPv6, but it’s a
> starting point at least).
>
> Where I am going with this is I am considering designing a precision
> embedded NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got
> piles of up to a GPIO and USART and the Ethernet port would provide
> NTP/PTP. The idea behind making it an embedded system would be to try and
> make it as accurate as it reasonably can be with the hope that (at least on
> the local segment) it would wind up being more accurate than a Pi Zero
> doing the same thing. At the very least, you’d expect such a thing to be a
> whole lot less hassle to set up, given decent firmware.
>
> This may be a fool’s errand, certainly, but looking at it from here, I
> would think that such a design might offer accuracy in the microsecond
> range, but that’s just a tremendously uninformed guess at this point (and
> what does that accuracy mean to a peer that might itself be incapable of
> better than 2 orders of magnitude coarser?).
>
> Anybody have any ideas or suggestions along these lines?
> ___
> 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

[Denny Page]

The 6-7us of latency in this discussion does not involve the network path. In 
this regard network latency is fairly well addressed with hardware 
timestamping, although trying to get readings across the clock domains looses 
dozens of nanos of precision. In this discussion, the 6-7us of latency 
originates from servicing the serial device interrupt in order to timestamp the 
TOS pulse. This is entirely in the kernel, and there is no user space context 
switch involved. If you have a way to dramatically reduce the 6-7us interrupt 
latency with the Linux kernel, say to a 100 nanos, please do share.


> On Nov 12, 2017, at 07:23, Attila Kinali  wrote:
> 
> The kernel has already quite a few low-latency network paths.
> You just need to enable them and then cut out the biggest timing uncertainty:
> the user-space to kernel context switch.

___
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 Wed, 1 Nov 2017 10:15:43 -0700
Denny Page  wrote:

> > 6-10µs is the interrupt latency of linux on ARM SoC. I guess, to get
> > below that you'd have to tweak the kernel a bit. Which should not
> > be that difficult. Definitly simpler than writing your own IP and NTP
> > stack from scratch.
> 
> Just tweak the Linux kernel a bit? No. You would have to a rewrite 
> substantial chunks of it. A tremendous effort. Low latency and accurate 
> timing is not what Linux is designed for. This has been discussed 
> extensively for years.

Not really. The kernel has already quite a few low-latency network paths.
You just need to enable them and then cut out the biggest timing uncertainty:
the user-space to kernel context switch. If you write a small stub driver
that takes from user space the required data to build a NTP packet, you
can cut out quite a bit of the latency. You could even get a decent estimate
on when the packet will be send out in case of conguestion, if you check
the buffer fill marks. My guess, for someone who knows his way around
the kernel network stack, that would be 1-4 weeks of effort.

> > Spread spectrum can usually be switched off, though requires at least a
> > custom DTB or even patching of the kernel. There are a few boards, though
> > that do not allow spread spectrum to be switched off.
> 
> Unfortunately is usually has to be done in the bios. The control space that 
> would allow spread spectrum to be turned off is usually disabled prior to 
> kernel load. For compliance, most bios implementations have removed spread 
> spectrum as an option so you have to build a custom one. I can’t begin to 
> tell you what kind of a chill comes over the conversation with a vendor 
> (even a maker oriented one) when you tell them you want to create a custom 
> bios to disable spread spectrum.

Ah.. sorry for the confusion. I was specifically talking about embedded
systems. On a PC all bets are off, while on a embedded system you have
quite a high level of control of what's going on. At most you have to
tweak the DT file a bit, or set some initialization values a bit differently.



Attila Kinali
-- 
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering.  -- The Doctor
___
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 Wed, 1 Nov 2017 13:11:00 -0400
 wrote:

> I am trying to beat existing products like the Dallas DS3231 and Micro 
> Crystal RV-8803-C7-32.768kHz-3PPM-TA-QC, which use (I think) a similar 
> strategy. I’m hoping I can beat them by using more accurate temp tensing, 
> longer and more exhaustive calibration effort, and anything else possible! 
>
> Can you give a quick explanation (or point to reference material) covering 
> the fundamental limits to XTAL compensation accuracy, and how to get there?

You probably can get better, but is it worth the effort?
The problem with temperaure compensation is, that you have to measure
the crystal temperature with very high accuracy. Measuring something
close by means you have to model the crystals actual temperature using
the temperature measurements you made before. The more parameters you
add to your system to be identified, the more problems you get accurately
identifying them, as they are not completely independent and cannot be
directly measured.

Directly measuring the crystal temperature has been done and one quite
popular approach is MCXO. [1] and [2] are two early papers that describe
the approach in quite some detail. There are a few problems with this.
One is that you need a special crystal that is designed for dual mode
operation and the other is that you need quite a bit of electronics
around it to work. Oh.. and if you are living in the US, please be
aware that MCXO are covered by ITAR.

For general modeling of crystals, I recommend reading John Vigs
Oscillator Tutorial. It covers most of what we know about crystal
oscillators and gives lot of references.


Attila Kinali


[1] "A Microcomputer-Compensated Crystal Oscillator Using a
Dual-Mode Resonator", by Benjaminson, 1989

[2] "Resonator Self-Temperature-Sensing Using a Dual-Harmonic-Mode
Crystal Oscillator", Schodowski, 1989

-- 
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering.  -- The Doctor
___
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 11/1/17 12:13 PM, Adrian Godwin wrote:

How do those compare with vectron's part : ?

https://www.vectron.com/products/ocxo/mx-503.htm



That part is interesting, but the phase noise (-124 dBc @ 100 Hz) isn't 
particularly impressive compared to a middle of the road OCXO (-155dBc 
at 100Hz)


The frequency stability is very nice, compared to a TCXO, and at a LOT 
less power (40mW) than the OCXO (2W after warmup).




There's also this patent.

http://www.google.sr/patents/US20020005765

I don't really know if that's valid - it seems to propose something similar
to the numerically-compensated oscillator in my rather old PM frequency
counter.



___
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]

Regarding spread spectrum issues:

You might be lucky to find (or have) SSCG implementation that is reasonably 
stable.  I suspect most are - because it is easy to generate hershey kiss 
spectrum based on SM, LUT or some sort of multi-level LFSRs.  I don't know what 
this means - these are some random Internet acronyms so it must be true.

I have several Linux workstations with system board crystals replaced with GPS 
synchronised synthesiser.  Instead of trying to disable SSCG or spending time 
analysing it I have tweaked system clock frequency until local time drift of 
the freewheeling system (with NTP setup with disabled time adjustment and clock 
correction) was less than 1 microsecond per day.  This took several days and 
needed better than 10^-11 level frequency adjustments and stability.  With GPS 
synchronisation this is easily achievable. If I keep NTP local time corrections 
disabled (basically remove all the servers from ntpd configuration) the local 
time drift is better than 0.01ppb.  Interestingly, to achieve that what used to 
be 26.000M crystal has ended up being a system clock that looks more like 
26,000,001.7193Hz 

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

> On Nov 1, 2017, at 1:11 PM, tn...@joshreply.com wrote:
> 
>> While crystal curves are indeed cubic, there are higher order terms in 
>> the curve. The “why” is something people get to write papers on. If you 
>> are trying to compensate to tight specs, you will see all sorts of 
>> stuff. It is not at all uncommon to see >9th order curves residual curves. 
>> Indeed some of that is from residuals in the compensation circuit as well as 
>> from the crystal.
> 
> I’ve been trying to research this very topic!
> 
> Can you point to some of these papers?

The Frequency Control Symposium has papers going back > 50 years on crystals 
and how to 
cut them from raw quartz bars. Plan on spending a few million dollars to get 
set up to do this well. 
Something in the $5M is likely the “going rate” these days for a basic line, 
even with some of it
bought surplus. 

> 
> I am trying to build the most accurate fee running, low power time base I 
> can. I am using an MCU, 32768Khz watch crystals,


Which are very low precision crystals by their very nature…..

> 0.5C accuracy temp sensor, lots of thermal bringing between them, and mass 
> around them.

Which is pretty loose by todays standards. You can get parts that will do 
better than that. 

> The idea is to measure the frequency shift at all temps in the range, and 
> even in both directions (hopefully to capture some hysteresis)

Keep in mind that your hysteresis runs need to be at multiple speeds and over 
multiple temperature ranges. The results vary with 
both promoters.  

> for each unit and then use that database to compensate in software once the 
> system is free running. 

Assuming you have a “normal” watch crystal, you can get into slopes well over 
10 ppm / C without going to crazy extremes. That
and your 0.5 C resolution is going to have a pretty big impact. 

> 
> I am trying to beat existing products like the Dallas DS3231 and Micro 
> Crystal RV-8803-C7-32.768kHz-3PPM-TA-QC, which use (I think) a similar 
> strategy. I’m hoping I can beat them by using more accurate temp tensing, 
> longer and more exhaustive calibration effort, and anything else possible! 

I’d say it’s unlikely. 

> 
> Can you give a quick explanation (or point to reference material) covering 
> the fundamental limits to XTAL compensation accuracy, and how to get there?

The FCS proceedings have a number of papers. The basics depend a lot on the 
type of crystal you have and the net result you are after. If you must 
have the output on frequency that leads in a different direction than if you 
just want an accurate one second tick. For example, with the one second tick, 
you can drop (or add) cycles in your divider. If the oscillator is at 10 MHz, 
the net result will always be within 100 ns. For something like NTP, there
is no real advantage going past that point. You can accumulate error over a 
long period. That allows very good stability over the long term. 

If you need low power and proper frequency, a thermistor resistor network 
driving a varicap diode is the classic answer. You generate a cubic voltage
function over temperature. It is the “required signal” to tune the oscillator 
on frequency. The components in the network are evaluated and adjusted with 
multiple 
temperature runs. The software to make it all work is generally the “top 
secret” IP of the people making the TCXO.

A brute force approach using a good temperature sensor (say an RTD) and a good 
ADC is possible. You can get into the low mili C range with this sort of
setup. Pairing that with a good low frequency overtone crystal can do pretty 
well. There are also multi mode ostillators that head in the same direction. 
There
are many twists and turns. A starting engineer generally takes something in the 
5 year range to come up to speed on most of them. 

> 
> That is, if I had an infinitely precise temp sensor and an infinite amount of 
> time to characterize an XTAL, what would be limits to how accurately I could 
> temp compensate it?

Well, aging is one obvious issue. ADEV is another. A reasonable goal for aging 
would be in the low parts in 10^-11 per day range. Good ADEV at 1,000 seconds 
would be at least that good. The electronics to make it all happen might use as 
much power as a low power OCXO …. Managing temperature in a TCXO like 
device below 1x10^-10 is unlikely.  Figure the crystal used would be > $100 in 
volume. Single piece (if you could buy one) might be over a thousand dollars. 

> 
> Also, what are the limits of characterizing and compensating for aging?

Low parts in 10^-11 per day on a “production” basis if cost is not a 
consideration. It also depends quite a bit on the constraints you put on the 
problem. (how many
days on power, what sort of environment, ….)

> 
> What other sources of inaccuracy would I need to consider?

There are *many*. How many years do you have to study the various topics? 
Thermal gradients are one that will bother you. 

Again, the FCS papers are a 

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

[Denny Page]

> On Nov 01, 2017, at 05:39, Attila Kinali  wrote:
> 
> 6-10µs is the interrupt latency of linux on ARM SoC. I guess, to get
> below that you'd have to tweak the kernel a bit. Which should not
> be that difficult. Definitly simpler than writing your own IP and NTP
> stack from scratch.

Just tweak the Linux kernel a bit? No. You would have to a rewrite substantial 
chunks of it. A tremendous effort. Low latency and accurate timing is not what 
Linux is designed for. This has been discussed extensively for years.

Writing your own IPv4 datagram stack for ICMP and NTP is rather trivial. It’s 
all static state, you don’t have to deal with fragments, you don’t have to deal 
with options, etc. There really is very little you actually have to do. IPv6 is 
more work because you have to maintain some dynamic state (routing), process 
options, etc., but it’s still nothing near like trying to turn Linux into a 
real-time system.


> Spread spectrum can usually be switched off, though requires at least a
> custom DTB or even patching of the kernel. There are a few boards, though
> that do not allow spread spectrum to be switched off.

Unfortunately is usually has to be done in the bios. The control space that 
would allow spread spectrum to be turned off is usually disabled prior to 
kernel load. For compliance, most bios implementations have removed spread 
spectrum as an option so you have to build a custom one. I can’t begin to tell 
you what kind of a chill comes over the conversation with a vendor (even a 
maker oriented one) when you tell them you want to create a custom bios to 
disable spread spectrum.

Denny

___
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]

tn...@joshreply.com said:
> I am trying to build the most accurate fee running, low power time base I can.

> I am trying to beat existing products like the Dallas DS3231 and Micro
> Crystal RV-8803-C7-32.768kHz-3PPM-TA-QC, which use (I think) a similar
> strategy. I’m hoping I can beat them by using more accurate temp tensing,
> longer and more exhaustive calibration effort, and anything else possible!  

That should be easy.
  http://users.megapathdsl.net/~hmurray/time-nuts/Temp-tcxo32khz-a.png

Do you need an accurate output frequency, or just know what the actual 
frequency is so you can compensate when counting cycles to keep track of 
elapsed time?

I would start by bolting your setup to a large thermal mass and putting it 
inside an insulated box.  Not too well insulated or it will cook itself.  You 
want the thermal time constant to be long enough to give your control loop 
plenty of time to react.  You also want the thermal sensor at the same 
temperature as the crystal.



-- 
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

[Adrian Godwin]

How do those compare with vectron's part : ?

https://www.vectron.com/products/ocxo/mx-503.htm


There's also this patent.

http://www.google.sr/patents/US20020005765

I don't really know if that's valid - it seems to propose something similar
to the numerically-compensated oscillator in my rather old PM frequency
counter.



On Wed, Nov 1, 2017 at 5:11 PM,  wrote:

> >While crystal curves are indeed cubic, there are higher order terms in
> >the curve. The “why” is something people get to write papers on. If you
> >are trying to compensate to tight specs, you will see all sorts of
> >stuff. It is not at all uncommon to see >9th order curves residual
> curves. Indeed some of that is from residuals in the compensation circuit
> as well as from the crystal.
>
> I’ve been trying to research this very topic!
>
> Can you point to some of these papers?
>
> I am trying to build the most accurate fee running, low power time base I
> can. I am using an MCU, 32768Khz watch crystals, 0.5C accuracy temp sensor,
> lots of thermal bringing between them, and mass around them. The idea is to
> measure the frequency shift at all temps in the range, and even in both
> directions (hopefully to capture some hysteresis) for each unit and then
> use that database to compensate in software once the system is free running.
>
> I am trying to beat existing products like the Dallas DS3231 and Micro
> Crystal RV-8803-C7-32.768kHz-3PPM-TA-QC, which use (I think) a similar
> strategy. I’m hoping I can beat them by using more accurate temp tensing,
> longer and more exhaustive calibration effort, and anything else possible!
>
> Can you give a quick explanation (or point to reference material) covering
> the fundamental limits to XTAL compensation accuracy, and how to get there?
>
> That is, if I had an infinitely precise temp sensor and an infinite amount
> of time to characterize an XTAL, what would be limits to how accurately I
> could temp compensate it?
>
> Also, what are the limits of characterizing and compensating for aging?
>
> What other sources of inaccuracy would I need to consider?
>
> Thanks!!!
>
> -josh
>
>
>
>
> ___
> 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

[Attila Kinali]

Hoi Leo,

On Wed, 1 Nov 2017 15:35:46 +
Leo Bodnar  wrote:

> > From: Attila Kinali 
> > What you should do is basically system identification and adaptive control. 
> 
> Thanks for your advice, Attila, I am going to google this tonight.  This is 
> exciting!

Before you dive into sys-id and adaptive control, make sure you
have at least basic knowledge of control theory. Otherwise nothing
will make sense. I recommend [1] usally, as I find it a nice
and easy to understand introduction. Phk recommended [2] some
time ago, which gives a more historical view (or "the motherlore" as
phk called it).


Attila Kinali

[1] "Fedback Control of Dynamic Systems",  by Gene F. Franklin,
J. Da Powell, Abbas Emami-Naeini

[2] "Radiation laboratory series" https://www.jlab.org/ir/MITSeries.html

-- 
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

[tnuts]

>While crystal curves are indeed cubic, there are higher order terms in 
>the curve. The “why” is something people get to write papers on. If you 
>are trying to compensate to tight specs, you will see all sorts of 
>stuff. It is not at all uncommon to see >9th order curves residual curves. 
>Indeed some of that is from residuals in the compensation circuit as well as 
>from the crystal.

I’ve been trying to research this very topic!

Can you point to some of these papers?

I am trying to build the most accurate fee running, low power time base I can. 
I am using an MCU, 32768Khz watch crystals, 0.5C accuracy temp sensor, lots of 
thermal bringing between them, and mass around them. The idea is to measure the 
frequency shift at all temps in the range, and even in both directions 
(hopefully to capture some hysteresis) for each unit and then use that database 
to compensate in software once the system is free running. 

I am trying to beat existing products like the Dallas DS3231 and Micro Crystal 
RV-8803-C7-32.768kHz-3PPM-TA-QC, which use (I think) a similar strategy. I’m 
hoping I can beat them by using more accurate temp tensing, longer and more 
exhaustive calibration effort, and anything else possible! 

Can you give a quick explanation (or point to reference material) covering the 
fundamental limits to XTAL compensation accuracy, and how to get there?

That is, if I had an infinitely precise temp sensor and an infinite amount of 
time to characterize an XTAL, what would be limits to how accurately I could 
temp compensate it?

Also, what are the limits of characterizing and compensating for aging?

What other sources of inaccuracy would I need to consider?

Thanks!!!

-josh




___
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 
> What you should do is basically system identification and adaptive control. 

Thanks for your advice, Attila, I am going to google this tonight.  This is 
exciting!

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]

Antenna is a Tallysman TW4722.

I'll try a different antenna later. If nothing else, right now I've got regular 
dropouts for failsafe testing...


But I feel a better solution is a reliable holdover capability, which I should 
have anyway for failsafe.


Thanks,

Michael


On 01/11/2017 10:22 AM, Bob kb8tq wrote:

Hi

Ok, local RF interference sounds like a significant part of the problem. I would
suggest that swapping antennas might make sense. Not all “super interference
rejecting” antennas are created equal.

Bob


On Nov 1, 2017, at 9:55 AM, MLewis  wrote:



I'm also too close to that tall building that is reflecting the sats over the Bering 
Strait at me. It's a military computer site, which I thought would be pretty tight on 
stray RF, but it has antennas. I asked a friend who works there about my GPS issues and 
if RF from the site may be influencing things. He hesitated, then said "'Yes'. 
That's all I can say."
For first power up I had obtained an active antenna for multi-constellation and a 
pre-filter that "provides protection from near  frequency or strong harmonic 
interfering signals."


___
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 Martin]

One can minimize temperature change which affects things like 
regulated voltages, CMOS transition points for those converting

sine to TTL with gates, etc. in addition to the oscillators.

The November issue of Nuts and Volts Magazine has an article on an
Arduino based PID controller which might interest someone who wants 
to experiment with reducing temperature effects by controlling 
temperature.


Bob M

On 10/31/2017 8:42 PM, jimlux wrote:

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





___
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

Ok, local RF interference sounds like a significant part of the problem. I 
would 
suggest that swapping antennas might make sense. Not all “super interference
rejecting” antennas are created equal. 

Bob

> On Nov 1, 2017, at 9:55 AM, MLewis  wrote:
> 
> I wish.
> 
> It's using GLO and GPS now, yet gets reception dropouts.
> That's why I'm hoping to eventually get the firmware update that will add GAL 
> to the mix.
> 
> I had anticipated reception issues, which is why I went with the M8T for its 
> sensitivity, multi-constellation and it's a timing module so a good PPS on a 
> single sat - only to get surprised that my version didn't have GAL enabled. 
> But I didn't envision reception would be so bad that not having GAL would be 
> material.
> 
> I'm also too close to that tall building that is reflecting the sats over the 
> Bering Strait at me. It's a military computer site, which I thought would be 
> pretty tight on stray RF, but it has antennas. I asked a friend who works 
> there about my GPS issues and if RF from the site may be influencing things. 
> He hesitated, then said "'Yes'. That's all I can say."
> For first power up I had obtained an active antenna for multi-constellation 
> and a pre-filter that "provides protection from near  frequency or strong 
> harmonic interfering signals."
> 
> As it's just for NTP accuracy, I may be better off letting all the multipath 
> through than getting dropouts. I'm starting to think that part of my problem 
> is that I know the GPS is capable of getting better than I need, so instead 
> of working to get what I need, I want what it should be capable of.
> 
> But I feel a better solution is a reliable holdover capability, which I 
> should have anyway for failsafe. So perhaps the reception dropouts are a way 
> to make me address holdover properly rather than limp in and get surprised 
> later.
> 
> Hence adding a 'precision' RTC to the Pi.
> 
> Michael
> 
> On 01/11/2017 8:45 AM, Bob kb8tq wrote:
>> Hi
>> 
>> For NTP levels of accuracy Glonas is quite fine. Combining that with GPS 
>> should
>> get you a pretty good “time source” even under your extreme conditions.
>> 
>> Bob
>>> On Oct 31, 2017, at 11:14 PM, MLewis  wrote:
>>> 
>>> 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
 
> 
> ___
> 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 wish.

It's using GLO and GPS now, yet gets reception dropouts.
That's why I'm hoping to eventually get the firmware update that will 
add GAL to the mix.


I had anticipated reception issues, which is why I went with the M8T for 
its sensitivity, multi-constellation and it's a timing module so a good 
PPS on a single sat - only to get surprised that my version didn't have 
GAL enabled. But I didn't envision reception would be so bad that not 
having GAL would be material.


I'm also too close to that tall building that is reflecting the sats 
over the Bering Strait at me. It's a military computer site, which I 
thought would be pretty tight on stray RF, but it has antennas. I asked 
a friend who works there about my GPS issues and if RF from the site may 
be influencing things. He hesitated, then said "'Yes'. That's all I can 
say."
For first power up I had obtained an active antenna for 
multi-constellation and a pre-filter that "provides protection from 
near  frequency or strong harmonic interfering signals."


As it's just for NTP accuracy, I may be better off letting all the 
multipath through than getting dropouts. I'm starting to think that part 
of my problem is that I know the GPS is capable of getting better than I 
need, so instead of working to get what I need, I want what it should be 
capable of.


But I feel a better solution is a reliable holdover capability, which I 
should have anyway for failsafe. So perhaps the reception dropouts are a 
way to make me address holdover properly rather than limp in and get 
surprised later.


Hence adding a 'precision' RTC to the Pi.

Michael

On 01/11/2017 8:45 AM, Bob kb8tq wrote:

Hi

For NTP levels of accuracy Glonas is quite fine. Combining that with GPS should
get you a pretty good “time source” even under your extreme conditions.

Bob

On Oct 31, 2017, at 11:14 PM, MLewis  wrote:

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



___
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 Nov 1, 2017, at 9:17 AM, jimlux  wrote:
> 
> On 11/1/17 6:01 AM, Bob kb8tq wrote:
>> Hi
>> Unfortunately not all TCXO’s are created equal. It depends a bit on the
>> original intended use. I’d bet it also depends a bit on the original target
>> price. Perturbations  (frequency jumps) over temperature are one “feature”
>> that might be present. Hysteresis at half the temperature spec is another
>> “feature”.
>> Even within the same batch or same test run, some will be much better
>> than others. You stop the compensation process when they get “good enough”.
>> That will mean that a few are right at whatever the production target is and
>> others exceed the target by quite a bit.
>> While crystal curves are indeed cubic, there are higher order terms in the
>> curve. The “why” is something people get to write papers on.If you are trying
>> to compensate to tight specs, you will see all sorts of stuff. It is not at 
>> all uncommon
>> to see >9th order curves residual curves. Indeed some of that is from 
>> residuals
>> in the compensation circuit as well as from the crystal.
>> Why all this yack? A lot of people come from a background using OCXO’s. An
>> OCXO generally has a low order temperature characteristic. It also is rare 
>> to see
>> things like frequency perturbations in an OCXO. Moving from one to the other
>> can be a bit interesting.
> 
> Indeed - I was looking at algorithmically compensating some cheap TCXOs and 
> there's an amazing spread in the "details" of the curves - sure, they all met 
> the spec (several ppm, as I recall), but it was clear after very little 
> testing that there was no "one algorithm to fit them all"
> 
> As you say, good grist for a paper or thesis project.
> 
> That's why I wish they'd sell OCXOs, cheap, without the oven. Or maybe look 
> for regular XO (no TC).  Those might have a more "pure" (read lower order) 
> freq vs temp characteristic.

The issue there is that the crystal is where the money is. The oven circuit is 
actually pretty far 
down the list cost wise. Poke at this spec, poke at that spec and you have a 
$50 crystal (in volume). 


> 
> The problem I see with regular XO is that they tend to be designed to a cost 
> point and there might be more of the hysteresis and mechanical effects - if 
> you're not claiming better than 100ppm, then 50 ppm of hysteresis isn't a 
> problem.
> 
> A 1ppb OCXO is going to have to be a better mechanical design - so that it 
> can hit that 1ppb every time when you turn the oven on and go from cold to 
> hot.

It very much has a crystal that spent more time on the production line 
(somewhere) being processed than 
it’s lower spec cousins. Time is money and that equipment isn’t cheap either. 
There then is the minor 
issue of yield. Toss in a more expensive package while you are at it ….

> 
> 
> Maybe this is just griping in general - why don't mass production 
> manufacturers make exactly the niche part I want to buy (that is of no use to 
> anyone else)for $3 each
> 
> I suppose if you were going to build little algorithmically compensated 
> modules, you'd bite the bullet and design a crystal oscillator and then YOU 
> get to choose what crystal in what mount etc.

If you are buying a few million of this or that a month, you most certainly can 
get people’s attention. Toss 
in a willingness to pay a few dozen bucks a piece on top of that and you will 
get a *lot* of people’s attention. 

Crystals are made and sold with characteristic data on them. The same is true 
of just about any type of
oscillator. Getting to the point that the data is *useful* takes a lot of 
engineering on both ends of the process. 
There are a number of companies that have set up to do the characterization 
once the device is in the
end end product. To a great extent that gets done to speed up the engineering 
process ….


> 
> When all is said and done, the production cost for a design that uses a 
> crystal in a can plus half a dozen discrete devices to make an oscillator is 
> probably not a lot different than the production cost for a design using an 
> oscillator in a can.  it's the "other stuff" in the design that will add up.

If the crystal is at some odd frequency or in an odd package … be careful. 
Experience counts in terms of making a good crystal. 
Experience at 5.00 MHZ in an HC-40 is unfortunately not the same as 
experience at 5.05 MHz in the same package. I have a lot
of data on this ….

Bob


> 
> 
> 
> 
> 
> 
> 
> 
> 
>> Bob
>>> On Oct 31, 2017, at 10:42 PM, jimlux  wrote:
>>> 
>>> 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 

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

[jimlux]

On 11/1/17 6:01 AM, Bob kb8tq wrote:

Hi

Unfortunately not all TCXO’s are created equal. It depends a bit on the
original intended use. I’d bet it also depends a bit on the original target
price. Perturbations  (frequency jumps) over temperature are one “feature”
that might be present. Hysteresis at half the temperature spec is another
“feature”.

Even within the same batch or same test run, some will be much better
than others. You stop the compensation process when they get “good enough”.
That will mean that a few are right at whatever the production target is and
others exceed the target by quite a bit.

While crystal curves are indeed cubic, there are higher order terms in the
curve. The “why” is something people get to write papers on.If you are trying
to compensate to tight specs, you will see all sorts of stuff. It is not at all 
uncommon
to see >9th order curves residual curves. Indeed some of that is from residuals
in the compensation circuit as well as from the crystal.

Why all this yack? A lot of people come from a background using OCXO’s. An
OCXO generally has a low order temperature characteristic. It also is rare to 
see
things like frequency perturbations in an OCXO. Moving from one to the other
can be a bit interesting.



Indeed - I was looking at algorithmically compensating some cheap TCXOs 
and there's an amazing spread in the "details" of the curves - sure, 
they all met the spec (several ppm, as I recall), but it was clear after 
very little testing that there was no "one algorithm to fit them all"


As you say, good grist for a paper or thesis project.

That's why I wish they'd sell OCXOs, cheap, without the oven. Or maybe 
look for regular XO (no TC).  Those might have a more "pure" (read lower 
order) freq vs temp characteristic.


The problem I see with regular XO is that they tend to be designed to a 
cost point and there might be more of the hysteresis and mechanical 
effects - if you're not claiming better than 100ppm, then 50 ppm of 
hysteresis isn't a problem.


A 1ppb OCXO is going to have to be a better mechanical design - so that 
it can hit that 1ppb every time when you turn the oven on and go from 
cold to hot.



Maybe this is just griping in general - why don't mass production 
manufacturers make exactly the niche part I want to buy (that is of no 
use to anyone else)for $3 each


I suppose if you were going to build little algorithmically compensated 
modules, you'd bite the bullet and design a crystal oscillator and then 
YOU get to choose what crystal in what mount etc.


When all is said and done, the production cost for a design that uses a 
crystal in a can plus half a dozen discrete devices to make an 
oscillator is probably not a lot different than the production cost for 
a design using an oscillator in a can.  it's the "other stuff" in the 
design that will add up.











Bob




On Oct 31, 2017, at 10:42 PM, jimlux  wrote:

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

___
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

[Bob kb8tq]

Hi

> On Oct 31, 2017, at 11:33 PM, Leo Bodnar  wrote:
> 
>> 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 
> 

Looking at the data, the DUT did some sort of discrete frequency shift around 
4,000 seconds. The rest of the time it 
plodded along do nothing much ( = it was very stable). None of that is terribly 
unusual in terms of a holdover plot. 
The nasty question that always gets asked is “what if shift happened earlier?”. 
Depending on the test profile, that
may be unlikely or …. . Doing a lot of testing is about the only way to sort 
things out. 


> 
> 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.

This is TimeNuts ….


>  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.

Based on some other posts, it appears that some of the applications are in 
*very* unusual environments. They are 
far more outage prone than one would normally expect. 

Bob

> 
> 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.

___
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

Unfortunately not all TCXO’s are created equal. It depends a bit on the 
original intended use. I’d bet it also depends a bit on the original target
price. Perturbations  (frequency jumps) over temperature are one “feature”
that might be present. Hysteresis at half the temperature spec is another
“feature”. 

Even within the same batch or same test run, some will be much better 
than others. You stop the compensation process when they get “good enough”. 
That will mean that a few are right at whatever the production target is and
others exceed the target by quite a bit. 

While crystal curves are indeed cubic, there are higher order terms in the
curve. The “why” is something people get to write papers on.If you are trying
to compensate to tight specs, you will see all sorts of stuff. It is not at all 
uncommon
to see >9th order curves residual curves. Indeed some of that is from residuals
in the compensation circuit as well as from the crystal. 

Why all this yack? A lot of people come from a background using OCXO’s. An
OCXO generally has a low order temperature characteristic. It also is rare to 
see
things like frequency perturbations in an OCXO. Moving from one to the other
can be a bit interesting. 

Bob



> On Oct 31, 2017, at 10:42 PM, jimlux  wrote:
> 
> 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
> ___
> 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

For NTP levels of accuracy Glonas is quite fine. Combining that with GPS should
get you a pretty good “time source” even under your extreme conditions.

Bob 
> On Oct 31, 2017, at 11:14 PM, MLewis  wrote:
> 
> 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.

___
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 22:13:01 -0700
Denny Page  wrote:

> 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!).

6-10µs is the interrupt latency of linux on ARM SoC. I guess, to get
below that you'd have to tweak the kernel a bit. Which should not
be that difficult. Definitly simpler than writing your own IP and NTP
stack from scratch.

Spread spectrum can usually be switched off, though requires at least a
custom DTB or even patching of the kernel. There are a few boards, though
that do not allow spread spectrum to be switched off.

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]

On Wed, 1 Nov 2017 04:06:06 +
Leo Bodnar  wrote:

> > 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?

Depending on your expertise and the volume you expect, I would probably
build my own board. Select a SoC that has fast 32bit timers so you
can accurately measure the PPS. The OSD3358 I mentioned is a good
compromise IMHO, as it allows you to build upon the Beaglebone community,
without having to deal with a complex board design. And the PRU allows
you to sample with 5ns precision. A simple interpolation like what
Nick Sayer did would also be a good idea, IMHO.


> > 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?

Not an additional TCXO, but model its behaviour. What you should do
is basically system identification and adaptive control. The most
common way to do that is a Kalman filter. Though Marek Peka wrote 
a paper on the problems of Kalman filters for clock modeling
(mostly stability issues of the predicition) and presented it at
IFCS/EFTF in Prague in 2013.

> 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.

Well, that was me guessing what your goal was. Seems like I was off.


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

[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] 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.

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] 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] Designing an embedded precision GPS time server

[Mike Cook]

> Le 29 oct. 2017 à 11:29, Leo Bodnar  a écrit :
> 
> If you are making an open source thing you might want to use Laureline NTP 
> http://partiallystapled.com/pages/laureline-gps-ntp-server.html as a starting 
> point or as a performance yardstick.  I have never seen one so can't comment 
> on how well it works but if done properly it should be reasonably solid and 
> agile.  I think the guy who designed it also sells them commercially but from 
> what I can see the design is also available for others to use.
> 

Try again.Sorry if some of you got a SPAM header.. My client has issues.

I bought one of these  three  years ago. It is very reliable and the perf is 
very good. I attach a couple of shots from this morning. 


Unfortunately it does not propagate leap seconds.

> 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.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
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 server

[Denny Page]

Back to back with 100Mb is good, particularly for latency tests, but you’ll 
need a switch for general testing. FWIW, an otherwise idle switch generally has 
very consistent latency, and if both ports are at 100Mb, it is symmetric. Also, 
with any kind of managed switch you can easily monitor traffic via a tap or 
span (mirror) port.

Alternatively you could use an hub (yes, a hub!). I have one that I keep for 
very special occasions. :)

Denny


> On Oct 29, 2017, at 09:12, Nick Sayer via time-nuts  
> wrote:
> 
> I don’t have the wherewithal to try and gauge the timing of switches, and of 
> course the function of switches makes monitoring unicast traffic by third 
> parties “impossible” (yes, you can play games with the switch table, but 
> that’s more trouble than it’s worth).

___
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 server

[Nick Sayer via time-nuts]

I think my test rig is likely to be a pair of units connected with a crossover 
cable, with test firmware on one to act as a fake client, and using spare GPIOs 
on test points to measure latency and the like with a scope. I don’t have the 
wherewithal to try and gauge the timing of switches, and of course the function 
of switches makes monitoring unicast traffic by third parties “impossible” 
(yes, you can play games with the switch table, but that’s more trouble than 
it’s worth).




> On Oct 29, 2017, at 5:27 AM, Scott McGrath  wrote:
> 
> With 1588 switch architecture counts as well because you have two major 
> classes of switch,  blocking and non blocking plus buffering etc.
> 
> Most 'enterprise' switches once the flow is set up directly forward frames 
> from the ingress port to the egress port each of which also tends to have a 
> fairly deep buffer so RTT Is non deterministic on a normal network
> 
> Most SOHO  switches use shared ring buffers so their performance is even worse
> 
> 
> 
>> On Oct 29, 2017, at 6:29 AM, Leo Bodnar  wrote:
>> 
> 
>> From: Nick Sayer 
>> I believe I’m going to start with one of my GPS module breakouts and an E70 
>> XPlained development board. From a hardware perspective, I expect that to be 
>> reasonably close to what the final hardware will be (the one thing I would 
>> guess would change would be perhaps swapping out the PHY chip for one that’s 
>> capable of doing PHY level timestamping, if that’s necessary and possible).
> 
> Hi Nick,
> 
> Note that PTP/IEEE1588 compliant hardware and NTP use different points in the 
> packet as reference timestamps. Timestamping transmitted packets in hardware 
> is useless for NTP.  I suspect you know that already.
> 
>> But my plan at the moment is to first try to get something that even answers 
>> the phone, see how terrible it is, and then see what has to be done to make 
>> it truly worthy.
> 
> You will find it trivial to get basic functionality working and reasonably 
> challenging to get it to work reliably under heavy load and edge cases.  
> "Heavy load" is not an abstract scenario since even on a lightly loaded 
> network there is a probability of several clients requesting time 
> simultaneously and network switch stacking NTP packets back to back.
> 
> If you are making an open source thing you might want to use Laureline NTP 
> http://partiallystapled.com/pages/laureline-gps-ntp-server.html as a starting 
> point or as a performance yardstick.  I have never seen one so can't comment 
> on how well it works but if done properly it should be reasonably solid and 
> agile.  I think the guy who designed it also sells them commercially but from 
> what I can see the design is also available for others to use.
> 
> 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.
> ___
> 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 server

[Scott McGrath]

With 1588 switch architecture counts as well because you have two major classes 
of switch,  blocking and non blocking plus buffering etc.

Most 'enterprise' switches once the flow is set up directly forward frames from 
the ingress port to the egress port each of which also tends to have a fairly 
deep buffer so RTT Is non deterministic on a normal network

Most SOHO  switches use shared ring buffers so their performance is even worse



> On Oct 29, 2017, at 6:29 AM, Leo Bodnar  wrote:
> 

> From: Nick Sayer 
> I believe I’m going to start with one of my GPS module breakouts and an E70 
> XPlained development board. From a hardware perspective, I expect that to be 
> reasonably close to what the final hardware will be (the one thing I would 
> guess would change would be perhaps swapping out the PHY chip for one that’s 
> capable of doing PHY level timestamping, if that’s necessary and possible).

Hi Nick,

Note that PTP/IEEE1588 compliant hardware and NTP use different points in the 
packet as reference timestamps. Timestamping transmitted packets in hardware is 
useless for NTP.  I suspect you know that already.

> But my plan at the moment is to first try to get something that even answers 
> the phone, see how terrible it is, and then see what has to be done to make 
> it truly worthy.

You will find it trivial to get basic functionality working and reasonably 
challenging to get it to work reliably under heavy load and edge cases.  "Heavy 
load" is not an abstract scenario since even on a lightly loaded network there 
is a probability of several clients requesting time simultaneously and network 
switch stacking NTP packets back to back.

If you are making an open source thing you might want to use Laureline NTP 
http://partiallystapled.com/pages/laureline-gps-ntp-server.html as a starting 
point or as a performance yardstick.  I have never seen one so can't comment on 
how well it works but if done properly it should be reasonably solid and agile. 
 I think the guy who designed it also sells them commercially but from what I 
can see the design is also available for others to use.

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.
___
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 server

[Leo Bodnar]

> From: Nick Sayer 
> I believe I’m going to start with one of my GPS module breakouts and an E70 
> XPlained development board. From a hardware perspective, I expect that to be 
> reasonably close to what the final hardware will be (the one thing I would 
> guess would change would be perhaps swapping out the PHY chip for one that’s 
> capable of doing PHY level timestamping, if that’s necessary and possible).

Hi Nick,

Note that PTP/IEEE1588 compliant hardware and NTP use different points in the 
packet as reference timestamps. Timestamping transmitted packets in hardware is 
useless for NTP.  I suspect you know that already.

> But my plan at the moment is to first try to get something that even answers 
> the phone, see how terrible it is, and then see what has to be done to make 
> it truly worthy.

You will find it trivial to get basic functionality working and reasonably 
challenging to get it to work reliably under heavy load and edge cases.  "Heavy 
load" is not an abstract scenario since even on a lightly loaded network there 
is a probability of several clients requesting time simultaneously and network 
switch stacking NTP packets back to back.

If you are making an open source thing you might want to use Laureline NTP 
http://partiallystapled.com/pages/laureline-gps-ntp-server.html as a starting 
point or as a performance yardstick.  I have never seen one so can't comment on 
how well it works but if done properly it should be reasonably solid and agile. 
 I think the guy who designed it also sells them commercially but from what I 
can see the design is also available for others to use.

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 server

[Philip Gladstone]

I built a couple of NTP time servers around this board: 
https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware 
which supports IEEE1588. It also acts as a PTP source on the LAN. It is 
part of the IPv6 ntp pool and is currently serving about 1000 requests 
per minute. It uses a custom PCB to connect to a small display an the 
GPS board (it has support for a number of different GPS boards).


It just needs putting into a case to complete the project. Of course, 
the last 10% takes 90% of the time!


Philip


On 28/10/2017 15:58, Nick Sayer via time-nuts wrote:

That looks and sounds very, very much like what I want to do.

Thank you very much for your testing suggestions. When it comes time, I had 
indeed planned on adding it to the NTP pool if for no other reason than to 
contribute to the cause (but also for testing).

I believe I’m going to start with one of my GPS module breakouts and an E70 
XPlained development board. From a hardware perspective, I expect that to be 
reasonably close to what the final hardware will be (the one thing I would 
guess would change would be perhaps swapping out the PHY chip for one that’s 
capable of doing PHY level timestamping, if that’s necessary and possible).

But my plan at the moment is to first try to get something that even answers 
the phone, see how terrible it is, and then see what has to be done to make it 
truly worthy.

Those interested can follow the hackaday project. This whole thing is going to 
be open hardware and GPLed firmware (again, assuming I succeed).

https://hackaday.io/project/27873-embedded-gps-ntp-server


On Oct 27, 2017, at 12:27 PM, Leo Bodnar  wrote:

Hi Nick,

Last year I have designed an NTP server with sub-microsecond turnaround 
accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire 
speed) that costs just £250 from stock.
Its holdover performance on signal loss is in the order of 4-5ms/day.
https://store.uputronics.com/index.php?route=product/product=60_70_id=92

If you can come up with a cheaper and higher performance alternative I am very 
interested in licensing your design.

When you come to testing I can highly recommend placing your prototypes in 
public NTP pool and asking the admins to add it to .ch zone - you are 
guaranteed to get full 110kpps traffic spikes that will help to flush out bugs.
Just a few devices collectively served 1.1 trillion packets in less than a year 
http://leobodnar.com/LeoNTP/ (and have been through the infamous snapchat 
incident.)

Jitter and holdover need to be tested on a controlled LAN segment - I can 
highly recommend contacting Denny Page on this list and sending him a unit to 
test.
He built sophisticated and highly tuned testing system that tracks timing 
jitter and offset down to dozens of nanoseconds accuracy.
Denny is vendor-neutral and provided honest and fair feedback while I was 
developing my unit.

Hope this helps!

Thanks
Leo

On 26 Oct 2017, at 17:00, time-nuts-requ...@febo.com wrote:


Date: Wed, 25 Oct 2017 17:53:46 -0700
From: Nick Sayer 

I’ve just completed a project (off topic) with the ATSAMS70 chip and learned a 
lot in a relatively short time, and I really like the result.

I am considering a new project based on its cousin, the ATSAME70. The E70 has 
an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 has 
(USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and Atmel 
Start (the software development framework I’ve been using) purports to have a 
ready-to-use IP stack (alas, no IPv6, but it’s a starting point at least).

Where I am going with this is I am considering designing a precision embedded 
NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got piles of up to 
a GPIO and USART and the Ethernet port would provide NTP/PTP. The idea behind 
making it an embedded system would be to try and make it as accurate as it 
reasonably can be with the hope that (at least on the local segment) it would 
wind up being more accurate than a Pi Zero doing the same thing. At the very 
least, you’d expect such a thing to be a whole lot less hassle to set up, given 
decent firmware.

This may be a fool’s errand, certainly, but looking at it from here, I would 
think that such a design might offer accuracy in the microsecond range, but 
that’s just a tremendously uninformed guess at this point (and what does that 
accuracy mean to a peer that might itself be incapable of better than 2 orders 
of magnitude coarser?).

Anybody have any ideas or suggestions along these lines?



___
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 server

[Nick Sayer via time-nuts]

That looks and sounds very, very much like what I want to do.

Thank you very much for your testing suggestions. When it comes time, I had 
indeed planned on adding it to the NTP pool if for no other reason than to 
contribute to the cause (but also for testing).

I believe I’m going to start with one of my GPS module breakouts and an E70 
XPlained development board. From a hardware perspective, I expect that to be 
reasonably close to what the final hardware will be (the one thing I would 
guess would change would be perhaps swapping out the PHY chip for one that’s 
capable of doing PHY level timestamping, if that’s necessary and possible).

But my plan at the moment is to first try to get something that even answers 
the phone, see how terrible it is, and then see what has to be done to make it 
truly worthy.

Those interested can follow the hackaday project. This whole thing is going to 
be open hardware and GPLed firmware (again, assuming I succeed). 

https://hackaday.io/project/27873-embedded-gps-ntp-server

> On Oct 27, 2017, at 12:27 PM, Leo Bodnar  wrote:
> 
> Hi Nick,
> 
> Last year I have designed an NTP server with sub-microsecond turnaround 
> accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire 
> speed) that costs just £250 from stock.
> Its holdover performance on signal loss is in the order of 4-5ms/day.
> https://store.uputronics.com/index.php?route=product/product=60_70_id=92
> 
> If you can come up with a cheaper and higher performance alternative I am 
> very interested in licensing your design.
> 
> When you come to testing I can highly recommend placing your prototypes in 
> public NTP pool and asking the admins to add it to .ch zone - you are 
> guaranteed to get full 110kpps traffic spikes that will help to flush out 
> bugs.
> Just a few devices collectively served 1.1 trillion packets in less than a 
> year http://leobodnar.com/LeoNTP/ (and have been through the infamous 
> snapchat incident.)
> 
> Jitter and holdover need to be tested on a controlled LAN segment - I can 
> highly recommend contacting Denny Page on this list and sending him a unit to 
> test.  
> He built sophisticated and highly tuned testing system that tracks timing 
> jitter and offset down to dozens of nanoseconds accuracy.  
> Denny is vendor-neutral and provided honest and fair feedback while I was 
> developing my unit.
> 
> Hope this helps!
> 
> Thanks
> Leo
> 
> On 26 Oct 2017, at 17:00, time-nuts-requ...@febo.com wrote:
> 
>> Date: Wed, 25 Oct 2017 17:53:46 -0700
>> From: Nick Sayer 
>> 
>> I’ve just completed a project (off topic) with the ATSAMS70 chip and learned 
>> a lot in a relatively short time, and I really like the result.
>> 
>> I am considering a new project based on its cousin, the ATSAME70. The E70 
>> has an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 
>> has (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and 
>> Atmel Start (the software development framework I’ve been using) purports to 
>> have a ready-to-use IP stack (alas, no IPv6, but it’s a starting point at 
>> least).
>> 
>> Where I am going with this is I am considering designing a precision 
>> embedded NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got 
>> piles of up to a GPIO and USART and the Ethernet port would provide NTP/PTP. 
>> The idea behind making it an embedded system would be to try and make it as 
>> accurate as it reasonably can be with the hope that (at least on the local 
>> segment) it would wind up being more accurate than a Pi Zero doing the same 
>> thing. At the very least, you’d expect such a thing to be a whole lot less 
>> hassle to set up, given decent firmware.
>> 
>> This may be a fool’s errand, certainly, but looking at it from here, I would 
>> think that such a design might offer accuracy in the microsecond range, but 
>> that’s just a tremendously uninformed guess at this point (and what does 
>> that accuracy mean to a peer that might itself be incapable of better than 2 
>> orders of magnitude coarser?).
>> 
>> Anybody have any ideas or suggestions along these lines?
> 
> ___
> 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

[Leo Bodnar]

> 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.

>> When you come to testing I can highly recommend placing your prototypes in 
>> public NTP pool and asking the admins to add it to .ch zone - you are 
>> guaranteed to get full 110kpps traffic spikes that will help to flush out 
>> bugs.
> 
> Why specifically the .ch zone? IIRC you are located in the uk.
> I am running an NTP server in the .ch pool and have not yet noticed any large 
> spikes. (ok, my monitoring is rather crude and if the spike is very short 
> lived, i wouldnt notice it)

Sorry, it was a typo - I meant Chinese zone (.cn)
Spikes usually happen around full or half-hour and last only few seconds but 
you often (about once a day) get true 100% fully saturated wire speed with 
packets coming in (and out) back to back.
The theory behind these spikes is interesting - most probably they are results 
of SNTP clients running from cron jobs. So, ironically, the more accurate time 
they receive from you, the more concentrated their behaviour becomes.

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 server

[Denny Page]

> On Oct 26, 2017, at 19:29, Chris Caudle  wrote:
> 
> On Thu, October 26, 2017 7:38 pm, Denny Page wrote:
>> If you are going to do PTP with ptp4l, or NTP with Chrony, you are going
>> to want hardware timestamping support on the ethernet phy.
> 
> Or the MAC.  The processor used on BeagleBone Black has timestamping in
> the MAC.  Not quite as accurate as stamping in the phy, but should be a
> relatively consistent fixed offset.


Yes, but it might not be as consistent as you would like. The Intel i210 is a 
pretty good reference. It does mac timestamping and has a built-in phy. At 
100Mb, Intel advertises a timestamp latency range of 984-1024ns for outbound 
packets, and 2148-2228ns for inbound packets. The ranges are a result of mac 
clock issues, unassociated with phy communication.

External measurement shows that the mean values are actually outside the ranges 
given, 1044ns for outbound, and 2133ns for inbound. [I suspect, but don’t know 
for sure, that the offset is a result of a fixed 20ns delay between the phy and 
mac.] Anyway, on a loopback between two i210 instances, you will see an average 
total timestamp latency of 3177ns, with a standard deviation of around 100ns. 
Pretty good, but not that great.

What chip does the BeagleBone Black use? Do they publish specs on the ethernet 
timestamp latency?

Thanks,
Denny

___
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 server

[Attila Kinali]

Hoi Leo,

On Fri, 27 Oct 2017 20:27:53 +0100
Leo Bodnar  wrote:

> Last year I have designed an NTP server with sub-microsecond turnaround 
> accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire 
> speed) that costs just £250 from stock.
> Its holdover performance on signal loss is in the order of 4-5ms/day.
> https://store.uputronics.com/index.php?route=product/product=60_70_id=92

Can you tell a little bit how your device looks like on the inside?
What do you use as microprocessor? What as GPS receiver? From the
hold-over spec, I would guess you are using a TCXO, which one is it?
What do you use to get the timing of the PPS pulse? Do you apply
saw-tooth correction?

> If you can come up with a cheaper and higher performance alternative I am
> very interested in licensing your design.

Getting better performance is not that difficult. Getting it cheaper is.
An OCXO (new, not from ebay) and a timing GPS receiver would already cost
something around 100-150€. That's one third to half of the cost of your
complete device already. Using an OCXO from ebay and you can do it quite
easily.
 
> When you come to testing I can highly recommend placing your prototypes in 
> public NTP pool and asking the admins to add it to .ch zone - you are 
> guaranteed to get full 110kpps traffic spikes that will help to flush out 
> bugs.

Why specifically the .ch zone? IIRC you are located in the uk.

I am running an NTP server in the .ch pool and have not yet noticed
any large spikes. (ok, my monitoring is rather crude and if the spike
is very short lived, i wouldnt notice it)

Attila Kinali

-- 
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering.  -- The Doctor
___
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 server

[Leo Bodnar]

Hi Nick,

Last year I have designed an NTP server with sub-microsecond turnaround 
accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire 
speed) that costs just £250 from stock.
Its holdover performance on signal loss is in the order of 4-5ms/day.
https://store.uputronics.com/index.php?route=product/product=60_70_id=92

If you can come up with a cheaper and higher performance alternative I am very 
interested in licensing your design.

When you come to testing I can highly recommend placing your prototypes in 
public NTP pool and asking the admins to add it to .ch zone - you are 
guaranteed to get full 110kpps traffic spikes that will help to flush out bugs.
Just a few devices collectively served 1.1 trillion packets in less than a year 
http://leobodnar.com/LeoNTP/ (and have been through the infamous snapchat 
incident.)

Jitter and holdover need to be tested on a controlled LAN segment - I can 
highly recommend contacting Denny Page on this list and sending him a unit to 
test.  
He built sophisticated and highly tuned testing system that tracks timing 
jitter and offset down to dozens of nanoseconds accuracy.  
Denny is vendor-neutral and provided honest and fair feedback while I was 
developing my unit.

Hope this helps!

Thanks
Leo

On 26 Oct 2017, at 17:00, time-nuts-requ...@febo.com wrote:

> Date: Wed, 25 Oct 2017 17:53:46 -0700
> From: Nick Sayer 
> 
> I’ve just completed a project (off topic) with the ATSAMS70 chip and learned 
> a lot in a relatively short time, and I really like the result.
> 
> I am considering a new project based on its cousin, the ATSAME70. The E70 has 
> an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 has 
> (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and Atmel 
> Start (the software development framework I’ve been using) purports to have a 
> ready-to-use IP stack (alas, no IPv6, but it’s a starting point at least).
> 
> Where I am going with this is I am considering designing a precision embedded 
> NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got piles of up 
> to a GPIO and USART and the Ethernet port would provide NTP/PTP. The idea 
> behind making it an embedded system would be to try and make it as accurate 
> as it reasonably can be with the hope that (at least on the local segment) it 
> would wind up being more accurate than a Pi Zero doing the same thing. At the 
> very least, you’d expect such a thing to be a whole lot less hassle to set 
> up, given decent firmware.
> 
> This may be a fool’s errand, certainly, but looking at it from here, I would 
> think that such a design might offer accuracy in the microsecond range, but 
> that’s just a tremendously uninformed guess at this point (and what does that 
> accuracy mean to a peer that might itself be incapable of better than 2 
> orders of magnitude coarser?).
> 
> Anybody have any ideas or suggestions along these lines?

___
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 server

[Chris Caudle]

On Thu, October 26, 2017 7:38 pm, Denny Page wrote:
> If you are going to do PTP with ptp4l, or NTP with Chrony, you are going
> to want hardware timestamping support on the ethernet phy.

Or the MAC.  The processor used on BeagleBone Black has timestamping in
the MAC.  Not quite as accurate as stamping in the phy, but should be a
relatively consistent fixed offset.

-- 
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 server

[Chris Caudle]

On Thu, October 26, 2017 5:58 pm, Bob kb8tq wrote:
> Why go to the green?

Cheaper.

> Just go with one of these Pocket Beagles I have
> sitting here wondering what to do with them.

Pocket Beagles do not have Ethernet.  How are you going to make a network
time server from a board with no network?

> get two Pi Zeros for the pice of the Pocket Beagle. Lash an interface
> onto any of them (just like the Green) and get going.

I suppose you could connect a network interface of some kind using the
USB, but I have never seen a USB network adapter with hardware
timestamping.  Possibly they exist, but I do not believe that a driver
currently exists which could read the hardware timer on a USB interface,
you would need to create the driver (probably after you created the
hardware).

-- 
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 server

[Bob kb8tq]

Hi

I suspect that once you find a group of chips that do have 1588 embedded in 
them that
digging into all the nasty details will take a bit. Time stamping to a 1 ms 
resolution might
not be a very helpful thing ….. There are ex-Freescale / now NXP devices that 
do have
pretty good 1588 in them. I’m sure they are not the only ones to go down that 
route.

Bob


> On Oct 26, 2017, at 8:38 PM, Denny Page  wrote:
> 
> If you are going to do PTP with ptp4l, or NTP with Chrony, you are going to 
> want hardware timestamping support on the ethernet phy. I would view this as 
> one of the principal concerns in choosing a system.
> 
> I’m not sufficiently familiar with Beagles… do any of them support hardware 
> timestamping?
> 
> Denny
> 
> 
> ___
> 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 server

[Denny Page]

If you are going to do PTP with ptp4l, or NTP with Chrony, you are going to 
want hardware timestamping support on the ethernet phy. I would view this as 
one of the principal concerns in choosing a system.

I’m not sufficiently familiar with Beagles… do any of them support hardware 
timestamping?

Denny


___
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 server

[Bob kb8tq]

Hi

Why go to the green? Just go with one of these Pocket Beagle’s I have sitting
here wondering what to do with them. They were just a bit under $20 when I 
picked them up. I doubt the price will climb over time …… Indeed you could
get two Pi Zero W’s for the pice of the Pocket Beagle. Lash an interface onto 
any of them (just like the Green) and get going. 

Is any of that cheaper once you get 1588 Ethernet going than a board (or chip) 
with
integrated Ethernet? My guess is no. 

Bob


> On Oct 26, 2017, at 5:26 PM, Iain Young  wrote:
> 
> On 26/10/17 22:11, Chris Caudle wrote:
> 
>> The processor you mentioned has a Cortex-M7 at 300MHz.   has a
>> Cortex-A8 running at 1GHz plus a Cortex-M processor available as a
>> coprocessor. Peripheral set is pretty comparable, and you can buy BBB at
>> retail for $50 which gets you the faster higher class processor, 512MB of
>> DRAM and 4GB of flash.  It runs linux right out of the box so you
>> basically  power it on and have NTP running.
> 
> The BB Green is even better value for money, and why would we need HDMI
> for timing apps ? (It also simplifies doing my Poor man's TIC!)
> 
>> On my list of projects to work on is a cape for BeagleBone Black that
>> takes 10MHz and 1PPS inputs along with a couple of RS232 converters for
>> the UARTs so you can connect a GPSDO to a BBB to make a time server.  In
>> my estimation that seemed like the best return on effort.
> 
> Wheen you get around to it, *Please* consider:
> 
>   1) multiplying that 10MHz up to 24 MHz as an option
>   2) RS422 option instead of RS232 (for the Lucent/HP GPS/Rb boxes)
>   3) PPS routed to TIMER4/5/6/7 rather than any old GPIO
>   4) Cover _all_ UARTS, even if serial headers are needed, rather than
> 9-pin D connectors
>   5) Some method of dropping a 5V PPS down to 3.3V (2N comes to
> mind, as does a /2 voltage divider [2.5V is sufficient to trigger the
> GPIO pins], I have done both - and yes measured the delay through the
> 2N!)
> 
> (Sorry Chris, I was looking at the serial cape options earlier today
> to try an santise my lash-ups, and was most disappointed!)
> 
> 
> Iain
> ___
> 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 server

[Iain Young]

On 26/10/17 22:11, Chris Caudle wrote:


The processor you mentioned has a Cortex-M7 at 300MHz.   has a
Cortex-A8 running at 1GHz plus a Cortex-M processor available as a
coprocessor. Peripheral set is pretty comparable, and you can buy BBB at
retail for $50 which gets you the faster higher class processor, 512MB of
DRAM and 4GB of flash.  It runs linux right out of the box so you
basically  power it on and have NTP running.


The BB Green is even better value for money, and why would we need HDMI
for timing apps ? (It also simplifies doing my Poor man's TIC!)


On my list of projects to work on is a cape for BeagleBone Black that
takes 10MHz and 1PPS inputs along with a couple of RS232 converters for
the UARTs so you can connect a GPSDO to a BBB to make a time server.  In
my estimation that seemed like the best return on effort.


Wheen you get around to it, *Please* consider:

   1) multiplying that 10MHz up to 24 MHz as an option
   2) RS422 option instead of RS232 (for the Lucent/HP GPS/Rb boxes)
   3) PPS routed to TIMER4/5/6/7 rather than any old GPIO
   4) Cover _all_ UARTS, even if serial headers are needed, rather than
9-pin D connectors
   5) Some method of dropping a 5V PPS down to 3.3V (2N comes to
mind, as does a /2 voltage divider [2.5V is sufficient to trigger the
GPIO pins], I have done both - and yes measured the delay through the
2N!)

(Sorry Chris, I was looking at the serial cape options earlier today
to try an santise my lash-ups, and was most disappointed!)


Iain
___
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 server

[Chris Caudle]

On Wed, October 25, 2017 7:53 pm, Nick Sayer via time-nuts wrote:
> I am considering a new project based on its cousin, the ATSAME70.

What is a reasonable cost target for that at the volumes you could
produce?  Coming up with something that is a better value than BeagleBone
Black at any kind of hobby project volume seems difficult.

The processor you mentioned has a Cortex-M7 at 300MHz.   has a
Cortex-A8 running at 1GHz plus a Cortex-M processor available as a
coprocessor. Peripheral set is pretty comparable, and you can buy BBB at
retail for $50 which gets you the faster higher class processor, 512MB of
DRAM and 4GB of flash.  It runs linux right out of the box so you
basically  power it on and have NTP running.

> Anybody have any ideas or suggestions along these lines?

On my list of projects to work on is a cape for BeagleBone Black that
takes 10MHz and 1PPS inputs along with a couple of RS232 converters for
the UARTs so you can connect a GPSDO to a BBB to make a time server.  In
my estimation that seemed like the best return on effort.

-- 
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 server

[Bob kb8tq]

Hi

So, get it up and running on the 1588 hardware built into one of these “all in 
one” 
MCU’s should be possible. Note the absence of words like easy or 
straightforward :)

Bob


> On Oct 26, 2017, at 12:45 PM, Chris Caudle  wrote:
> 
> On Thu, October 26, 2017 9:40 am, Bob kb8tq wrote:
>> Since time stamping hardware does exist for 1588, why not simply put the
>> effort into folding that into NTP?
> 
> According to the Chrony project web page chronyd already includes support
> for that.
> See "NTP timestamping" section:
> https://chrony.tuxfamily.org/comparison.html
> 
> -- 
> 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.

___
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 server

[Chris Caudle]

On Thu, October 26, 2017 9:40 am, Bob kb8tq wrote:
> Since time stamping hardware does exist for 1588, why not simply put the
> effort into folding that into NTP?

According to the Chrony project web page chronyd already includes support
for that.
See "NTP timestamping" section:
https://chrony.tuxfamily.org/comparison.html

-- 
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 server

[Bob kb8tq]

Hi

Since time stamping hardware does exist for 1588, why not simply put the effort 
into
folding that into NTP? Then you have a “generic” solution that addresses a lot 
of the
ambiguity a wide range of cases. It shows up in many of the low end micro’s so 
it’s 
not just a “big box only” solution. It’s not a 100% solution (NTP is not 1588) 
but it 
gets rid of a lot of noise. 

Bob


> On Oct 25, 2017, at 8:53 PM, Nick Sayer via time-nuts  
> wrote:
> 
> I’ve just completed a project (off topic) with the ATSAMS70 chip and learned 
> a lot in a relatively short time, and I really like the result.
> 
> I am considering a new project based on its cousin, the ATSAME70. The E70 has 
> an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 has 
> (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and Atmel 
> Start (the software development framework I’ve been using) purports to have a 
> ready-to-use IP stack (alas, no IPv6, but it’s a starting point at least).
> 
> Where I am going with this is I am considering designing a precision embedded 
> NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got piles of up 
> to a GPIO and USART and the Ethernet port would provide NTP/PTP. The idea 
> behind making it an embedded system would be to try and make it as accurate 
> as it reasonably can be with the hope that (at least on the local segment) it 
> would wind up being more accurate than a Pi Zero doing the same thing. At the 
> very least, you’d expect such a thing to be a whole lot less hassle to set 
> up, given decent firmware.
> 
> This may be a fool’s errand, certainly, but looking at it from here, I would 
> think that such a design might offer accuracy in the microsecond range, but 
> that’s just a tremendously uninformed guess at this point (and what does that 
> accuracy mean to a peer that might itself be incapable of better than 2 
> orders of magnitude coarser?).
> 
> Anybody have any ideas or suggestions along these lines?
> ___
> 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 server

[Gary E. Miller]

Yo Nick!

On Wed, 25 Oct 2017 17:53:46 -0700
Nick Sayer via time-nuts  wrote:

> This may be a fool’s errand, certainly, but looking at it from here,
> I would think that such a design might offer accuracy in the
> microsecond range,

I'm looking at 6 Raspberry Pi's right now, each with a different GPS
model.  Running NTPec and kernel PPS.  Adjacent jitter is from 10 to 35
micro seconds over 100 Base-T.

Local PPS jitter, is from 250 ns to up to 3,000 ns.

The biggest issue is the 186 ns granularity in the kernel system
clock.  Then interrupt latency and the usual Linux stuff.

> Anybody have any ideas or suggestions along these lines?

This may be not time-nutty enough for here.  Feel free to contact
me off list.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpp8WRtok0ml.pgp
Description: OpenPGP digital signature
___
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.