Re: [time-nuts] NEO-7 GPS default 1pps width?

[Leo Bodnar]

Yes, that's exactly how Ublox default PPS setting works.
Pulse is positive - rising edge is "the time."
Leo

On 8 Apr 2018, at 17:00, time-nuts-requ...@febo.com wrote:

> The manual says pulseLenRatio is zero and pulseLenRatioLock is 100,000 (us)
> flags-lockedOtherSet is 1, so I think that means "only generate 100ms 
> pulses when locked"
> 
> Does that align with anyone else's experience?

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

[Leo Bodnar]

Such system already exists, is called IMES, uses L1 band and is supported by 
standard Ublox 8 firmware.

http://gpsworld.com/wirelessindoor-positioningopening-up-indoors-11603/

Leo


> From: Stewart Cobb 
> Peter Reilley suggests a backup to GPS using terrestrial transmitters. This
> idea has been around since the early days of GPS
___
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] Frequency deviations in Europe affect clocks

[Leo Bodnar]

This has been making rounds for quite awhile, I am surprised it has not been 
picked up here.
Leo
==
Frequency deviations in Continental Europe including impact on electric clocks 
steered by frequency
Continental European Power System has been experiencing, since mid-January, 
continuous significant power deviations due to shortage in supply from one 
transmission system operator of the interconnected system.  All actions are 
taken by the TSOs of Continental Europe and by ENTSO-E to resolve the situation.

The power deviations have led to a slight drop in the electric frequency. This 
in turn has also affected those electric clocks that are steered by the 
frequency of the power system and not by a quartz crystal: they show currently 
a delay of 5 minutes. TSOs will set up a compensation program to correct the 
time in the future.

https://www.entsoe.eu/news-events/announcements/announcements-archive/Pages/News/Frequency-deviations-in-Continental-Europe-including-impact-on-electric-clocks-steered-by-frequency.aspx

___
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] LT1016 as a pulse shaper...

[Leo Bodnar]

Not sure how calculated this - the PN chart for PL133-37 shows output jitter 
barely lifting off the input jitter trace.  LT do not say what their input 
jitter is.

Additive jitter for 100MHz 12kHz-20MHz is 80fs for PLL133-37 and 90fs for 
LTC6957 at more than 10 times lower price.

I would trust LT more but all this is still armchair engineering.  The only way 
to know is stick it on the board and check.

Note that PLL133-37 is AC coupled internally so not suitable for short sharp 
spikes or low frequencies. 

Cheers
Leo


On 4 Mar 2018, at 10:20, Bruce Griffiths wrote:
> Somewhat worse than an LTC6957 particularly at low offset frequencies.
> 
> Either that or the manufacturers PN noise measurement method doesn't work 
> well at low offsets.
> 
> Bruce
> 
> On 04 March 2018 at 22:34 Leo Bodnar <l...@leobodnar.com> wrote:
> 
> Ulf,
> 
> What level of jitter would you consider acceptable?
> 
> Try PL133-37, I am using it for sinewave shaping on some of designs - 
> including my 30ps pulser.
> 
> 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] LT1016 as a pulse shaper...

[Leo Bodnar]

Ulf, 

What level of jitter would you consider acceptable?

Try PL133-37, I am using it for sinewave shaping on some of designs - including 
my 30ps pulser.

Leo

On 3 Mar 2018, at 21:56, time-nuts-requ...@febo.com wrote:

> From: Ulf Kylenfall 
> 
> Gentlemen,
> I have so far been using LT1016 as a pulse shaper and also whenever I needed 
> toconvert a sine wave into TTL Logic levels. Some hysteresis and all the 
> decouplingand layout precautions as recommended by LT.
> Are there any similar or better alternatives out there that could be usedthat 
> would provide lower jitter and that are less expenceive?
> Ulf Kylenfall
> SM6GXV

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] HP 5065A super

[Leo Bodnar]

Here is ENIG fact that is not widely known at the moment but which some might 
find useful.

I could not understand why I get better TDR and insertion loss results from 
solder-mask covered microstrip transmission lines than from otherwise identical 
microstrips on the same substrate with soldermask removed and, therefore, 
covered with ENIG.

Gold can't be bad, right? As it turns out, even gold coin has two sides to it.

I have found that Shlepnev and McMorrow conducted extensive research and 
published data, some of which is presented here 
http://www.simberian.com/Presentations/NickelCharacterizationPresentation_emc2011.pdf

In essence, it's not the "G" that is the problem - it is the "N".
Immersion Gold layer is not thick enough to contain whole of the skin effect 
layer (even towards 100GHz) and as signal frequency increases most of the 
signal ends up travelling through Nickel.  
As Shlepnev commented "Nickel is the most mysterious metal in electronics."  It 
has significant effect on insertion loss and risetime degradation.  
"Significant effect" is posh for "bad."

Some mass PCB manufacturers have been known to apply ENIG before soldermasking. 
 This causes even more high speed/frequency problems because all of the copper 
on the outside layers will have Nickel over it - exposed or not.

Probably not a problem for majority of ENIG users but could cause a headache or 
two for unsuspecting.

Leo

> Date: Thu, 22 Feb 2018 19:02:25 +
> From: Mark Sims 
> 
> Yes, have the board done with ENIG gold.  It typically adds around $15 per 
> run of boards.  I do all my boards with ENIG gold... if for no other reason 
> than the gold color makes it very easy to determine when your solder paste 
> properly covers the pads.
> 
> And, as Charles mentioned,  the quality and thickness of the gold can vary 
> depending upon the board house.  I have used gojgo.com for a lot of boards.  
> They do very good, quick work,  are well priced, and they seem to have the 
> best gold finish.
> 
> Hard gold finish is VERY expensive these days.  I've been quoted $250+ for 
> setup charges and per-board costs of over $25.  

___
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] Fast 30ps risetime pulse generator with SMA/2.92mm output

[Leo Bodnar]

I have promised a few people here to let them know when the microwave / SMA 
connector version of my fast risetime pulser is available.
It is available now: 
http://www.leobodnar.com/shop/index.php?main_page=index=124

For those not familiar with what it does - this is a pulse train generator with 
extremely fast risetime of 30ps (10-90% levels).
Falling edge is even faster at about 25-27ps. Pulse edge spacial length is only 
few mm.
Due to very fast edges its spectral content extends from 10MHz to tens of GHz.

Pulser's main purpose is testing bandwidth of time/frequency lab equipment and 
performing TDR/TDT.

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] Performance verification for time counters

[Leo Bodnar]

Poul-Henning, Magnus, et al. thanks for your suggestions - they were not in 
vain.

As promised, I started setting up dual asynchronous sources experiment and 
performed a quick sanity check.  
What I have [unsurprisingly] found is that at this level controlled environment 
is a problem in itself.  
For example, undoing input signal SMA connector by one turn shifted my results 
by around 3.5ps - close to expected figure but still inconvenient.
I'll have to plan the setup before I build and validate it, otherwise the 
results are not trustworthy.

I hope this message makes it to the list - my previous one didn't.  I am 
staying off the list for now.

Thanks
Leo

P.S. I do know about torque wrenches.

On 29 Nov 2017, at 21:51, Poul-Henning Kamp wrote:
> Lock it to the same frequency as your reference signal, but set it
> for pure sine output slightly offset in frequency (10.10/9.90
> MHz), so that your know your TI sweeps the entire window.

___
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] Trimble Mini-T Timing Glitches

[Leo Bodnar]

Completely off-topic comment while on the subject:

I can't see how randomly selected 1ms of data can contain unambiguously 
detectable start of C/A code.
If NAV data bit phase flip occurred within this 1ms of data then correlation 
search will most probably fail.
Yes, the probability of this is only 5% (assuming equal number of 1s and 0s in 
NAV message) but still not zero.
Perhaps the quote should have added "carefully chosen 1ms of data"
At the minimum, one would typically select 2ms of sampled data when they are 
doing a correlation search and then they are guaranteed a full PRN sequence 
somewhere in there.

Leo

> From: Tom Van Baak Thu, 30 Nov 2017 14:43:02 -0800
> In order to find the beginning of a C/A code in the received signal only a
> very limited data record is needed such as 1 ms. If there is no Doppler effect
> on the received signal, then one millisecond of data contains all the 1,023 
> chips.
___
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] Trimble Mini-T Timing Glitches

[Leo Bodnar]

Bob, this is quite an unorthodox description of how GPS works.
You probably want to rephrase that before it gets ripped to shreds.
Leo

From: Bob kb8tq 
>GPS extracts time and location by locking on to various codes in the 
>transmissions. 
One of them happens to run at about a 1 KHz clock rate. A slip on that part of 
the 
process gives you a (modulo) 1 ms clock jump. Certain types of interference may
“help” the receiver make these sorts of mistakes.

___
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] Performance verification for time counters

[Leo Bodnar]

Thank you for great suggestions, I will try to set something up next week 
involving detuned clock or sinewave source.

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] Performance verification for time counters

[Leo Bodnar]

I am looking for an established and widely accepted procedure for verifying 
performance of high resolution time counters.

I have designed a time stamping counter for qualifying 1PPS signal performance 
against external reference (e.g. 10MHz master clock.)

Simple design verification check I am doing at the moment is gating random 
selection of master clock edges back into device's signal input and letting the 
device measure this test signal offset against its reference clock - which, for 
ideal design, should result in zero offset (modulo 100ns.)  My results are 
roughly in line with what I expect to see 
http://leobodnar.com/balloons/NTP/time-sampler-test1.png

Now, what would be recognised procedure for sweeping external input pulse delay 
over few hundred ns in a controlled, measurable and repeatable way? 

I can see few naïve approaches:
1) Using selectively gated (or divided) reference clock followed by adjustable 
delay line.  E.g. something like mechanically adjusted delay lines used in HP 
test sets.  Or, perhaps, calibrated rigid coax sections?  
2) Slightly offset another master clock (e.g. second Rb oscillator) gated in a 
similar way but without delay line, followed by statistical data analysis 
3) Trusted pulse generator with high resolution delay adjustment fed from the 
same master clock as the counter 

I am looking for something with ~10ps accuracy, 100ns+ range, and reasonably 
low jitter (~5ps or better.)  
It is possible that the range needs to be split up (e.g. fixed rigid coax delay 
line followed by a mechanically adjust section.)

This is a low budget fun project so something simple and common sense is 
preferred to "price on application" NIST traceable equipment.

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] Recommendation for cheap GBIP adapter for Linux

[Leo Bodnar]

USB Prologix works fine with pyvisa on both Mac and Windows for me - 
http://pyvisa.readthedocs.io/en/stable/
I am still trying to shake off memories of NI VISA - even python is better.
Leo

On 18 Nov 2017, at 16:14, time-nuts-requ...@febo.com wrote:
> From: Tim Lister
> As mentioned by others the Prologix works fine in e.g. Timelab but is not 
> supported by NI VISA code or things like the linux-gpib code.
> Tim

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

[Leo Bodnar]

I don't know how power feed for active antenna is designed in your equipment.
Sometimes equipment can be back-powered through its GPS antenna port.  This 
might be benign or not.
Get at least an RF DC block for one unit (fancy name for a cap stuck between 
two BNC ports.)

Leo

On 17 Nov 2017, at 20:38, time-nuts-requ...@febo.com wrote:

> From: Jerry Hancock 
> Subject: Re: [time-nuts] Absolute phase
> 
> I figured, what the heck, and just used a BNC T and it’s working.

___
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] ublox NEO-M8T improved by insulated chamber?

[Leo Bodnar]

> Subject: Re: [time-nuts] ublox NEO-M8T improved by insulated chamber?

I have not read IS-GPS for quite awhile so out of curiosity found what I 
believe is the latest one 
https://www.gps.gov/technical/icwg/IRN-IS-200H-001+002+003_rollup.pdf

It states "The OCS shall control the GPS time scale to be within one 
microsecond of UTC (modulo one second).
The NAV data contains the requisite data for relating GPS time to UTC. The 
accuracy of this data during the transmission interval shall be such that it 
relates GPS time (maintained by the MCS of the CS) to UTC (USNO) within 20 
nanoseconds (one sigma)."

My understanding is:  the target difference between UTC and GPS time TOS is 1µs 
or less.  This is just an operational target and does not affect conversion 
accuracy.
The end user is provided required GPS to UTC correction data - in legacy NAV 
and [reasonably] new CNAV messages to perform conversion locally with expected 
accuracy to below 20ns (1 sigma.)
Time conversion accuracy is further diluted by uncertainty of GPS time itself - 
by design (accuracy of data in ephemeris), by receiver implementation 
(correlator resolution, etc) and environment (ionospheric disturbances, 
multipath, etc.)

GPS to UTC correction data contains constant offset and its rate of change for 
LNAV messages and adds extra 2nd order correction (rate of rate of change) for 
CNAV messages.

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] ublox NEO-M8T improved by insulated chamber?

[Leo Bodnar]

Coincidentally, I have been testing relative phase difference of two GPS clocks 
http://www.leobodnar.com/shop/index.php?main_page=product_info=107_id=301
 since Friday. 
They are completely independent, including separate antennas and positioned a 
few yards away from each other so ionospheric disturbances would affect both 
units equally.  Devices use Ublox chipset.

Average phase difference did not change in four days since Friday but there is 
phase wander within around 10ns.
Here is a video of 4 hours worth of data.  One horizontal division is 20ns:

http://leobodnar.com/balloons/NTP/twoGPSclocks.mp4

Cheers
Leo 

> From: Lars Walenius 
> If I look on the NIST database for the last days it seems to be a daily 
> variation of about 8-10ns. Could this be for the same reason as Ole’s 
> variation? Is the daily variations due to not perfect ionosphere correction? 
> Can you get much better than the data in the NIST database for an ordinary 
> timing receiver like the LEA-6T?


___
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] ublox NEO-M8T improved by insulated chamber?

[Leo Bodnar]

> From: MLewis
> Is this coincidence or can reception improve with:
> - a higher temperature module?
> - a more stable module temperature?

Short answer: 
#2

Long answer:
Ublox firmware tracks gradual shifts in its reference frequency (XO, TCXO or 
external input) and adjusts LO base offset to compensate.

However, the time constant of this correction tracking loop is quite high (and 
can be adjusted depending on the reference oscillator type.)

Sudden changes in temperature and, as a result, in reference frequency result 
in correlation level drop (seen as sat signal level level drop) or in total 
loss of tracking and return to acquisition.

In other words, absolute reference frequency offset (i.e. its temperature) is 
not a problem - it is gradually compensated for, but sudden shifts in frequency 
are.

If your design does (hopefully) does not rely on convection for getting rid of 
heat, try filling internal voids with cotton wool.  This will stop turbulent 
(naturally random) and laminar (usually caused by external events) airflows 
from affecting the reference.  Compartmentalising the design is just another 
way of separating the airflows but it does not stop them within the 
compartments.

There are subtler cases where reference frequency source has a sweet spot where 
its stability is greatest (like OCXO) and absolute temperature matters as well 
but this is the first order effect.

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] Holdover, RTC for Pi as NTP GPS source

[Leo Bodnar]

This is, essentially, how modern delta-sigma DACs work while achieving 24-bit 
and higher precision using only a single bit converter internally and a lot of 
clever digital filtering.
Multiple loops are what would be called "higher order" in delta-sigma parlance.
Delta-sigma tech is not poor man's DAC - it has properties that other 
conversion methods can't achieve, e.g. noise shaping and trivial aliases 
rejection.
I suspect delta-sigma body of knowledge can be applied almost wholesale to this 
seemingly silly oscillator concept. 
Did I just repeat something trivial that has been discussed to death here 
before? 
Leo

> From: Bob kb8tq 
> Subject: Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source
> There’s no particular reason to stop at the 100:1 point. You can run multiple 
> loops at the same time and get out to essentially any level of precision. The
> only question is over what averaging interval the precision applies.

___
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

[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

[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

[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

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

[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

[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] Fast Rise/Fall Time Pulser

[Leo Bodnar]

Hi Andrew,

> From its creator's forum posts, it appears to be a high slew rate

It's not a high slew rate, it's a short risetime. There are better technologies 
if you are after high slewrate. Avalanche BJT pulser, for once.

> comparator,


It's not a comparator anymore, it's a laser diode driver for now.

>  that once "triggered" will pass the next pulse of an asynchronous 10 MHz 
> square wave clock (2.5 ppm).

It's not triggered.  It runs at its own 10MHz pace and provides a copy (within 
few ns) of its pulse output at additional SMA connector for those who have 
sampling scopes that don't trigger off the main signal itself.

> The first version used a micro for setting the threshold voltage.

Micro never controlled the threshold voltage.  First version used micro's 
internal oscillator for pulse train but jitter was so excessive that the only 
way to use sampling scopes was through delay line.

>   The micro was removed in the following generation.

Micro is still there.

> It is for generating fast edges for equipment (bandwidth) testing, not for 
> precision timing.

This one is spot on!

> Feel free to correct me if I'm wrong.  I was disappointed with the limited 
> information I could dig-up.
> ~~
> Andrew E. Mileski

Sorry for your disappointment.  All the relevant information necessary for its 
use should be on the webpage.  I am not hiding anything.
You don't really need knowledge of intricacies of its operation to use it and I 
appreciate your frustration with lack of design details.
However, I am happy to answer any questions.

The pulser is so simple that its use is a three-step process:

1) plug USB in
2) plug pulser into BNC scope input
3) sorry, there is no step three

Cheers
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] GPS Arctic graphs

[Leo Bodnar]

Perhaps, completely unrelated and useless information - I had a small balloon 
that flew about 9km off the North Pole at altitude of around 13km while 
reporting its position derived from GPS.
http://leobodnar.com/balloons/B-64/

Telemetry included time, date, coordinates, altitude, number of GPS satellites, 
onboard temperature, battery and solar panel voltages.  
The raw data is still available here 
http://leobodnar.com/balloons/B-64/B-64-telemetry.csv

What can I say which is of interest?  It was very cold, down to -60C at night, 
GPS works everywhere, number of useful satellites increased as you move towards 
the North and the Sun indeed does not set on the North Pole during summer (but 
stays very low to be useful.)

I have used Ublox MAX-8Q for navigation. It was able to cope with low 
temperatures - way below its specified limit but it really did not like sharp 
temperature changes, e.g. during sunset.  Which is expected.
When the Sun sets temperature changes by 10-30C down within few minutes, below 
-45C TCXO finds itslef way way outside its correction zone and starts drifting 
a lot (I suspect even worse than just XO would), tracking engine gives up and 
falls back into acquisition mode and it really drains the batteries. I had a 
tiny local heater for TCXO but can't say how effective it was - probably not 
very.  For power management reasons I have used power saving mode so 
acquisition fall-backs were not welcome.  I was also not able to find a way of 
deferring Ublox download of ephemeris during the night, where the power is 
extraordinarily precious. 

Cheers
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] time-nuts Digest, Vol 143, Issue 25

[Leo Bodnar]

Be also aware that there are outright fakes around.  This one did not have any 
silicon inside.
It made debugging very difficult.

http://leobodnar.com/balloons/files/fake-M8030.jpg

Leo


On 15 Jun 2016, at 10:00, time-nuts-requ...@febo.com wrote:

> Certainly cheap…. BUT
> 
> On the ublox site there is a table indicating that the KT is a standard 
> precision engine. On the same table, the UBX-M8030-KT-FT is required for 
> timing:
> 
> < 
> https://www.u-blox.com/sites/default/files/GNSS-Chips_Linecard_%28UBX-13004716%29.pdf
>  >
> < 
> https://www.u-blox.com/sites/default/files/products/documents/UBX-M8030-KT-FT_ProductSummary_%28UBX-14001605%29.pdf
>  >
> 
> So, they may be cheap, very cheap, but are they really what a TN would want?
> 
> Hope that helps.
> Mike

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