Re: [time-nuts] ADC sample voting algorithm?

[David]

I always try to calculate things like the standard deviation and
peak-to-peak to get some idea if the measurement is valid.

A DSO with infinite persistence or envelope mode is great for tracking
this sort of thing down during development.  Only toy DSOs will lack
both.

On Wed, 05 Oct 2016 22:24:09 -0700, you wrote:

>time-nuts@febo.com said:
>> That’s kind of why I’m going down the road of multiple samples - to see 
>> if
>> there’s anything to it. 
>
>I would hack up some way to grab a clump (say 10) of samples and print them 
>out where you can capture them on a PC and analyze them.
>
>I'd start by looking with the old Mark 1 eyeballs, then write hack code to 
>filter out the good stuff so I can see the bad/interesting cases.
>
>If you have a scope, it might be interesting to trigger on PPS and look at 
>the ADC trigger and input voltage.  If you have a digital scope with the 
>remember forever option, that would catch the delayed interrupt bug that Jim 
>Harman reported.
___
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] Measure GPSDO stability with minimum resources?

[Hal Murray]

j99har...@gmail.com said:
> Unless the oscillator is still warming up, 5 minutes or even 60 is way too
> short a time to look at aging. For aging, you will want to look at the
> change in DAC values over several days at least. 

I think it's worse than that.  You have to hold the temperature constant, and 
maybe even the power supply voltage.  A probe on the crystal can might allow 
you to correct for temperature.




-- 
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] ADC sample voting algorithm?

[Hal Murray]

time-nuts@febo.com said:
> That’s kind of why I’m going down the road of multiple samples - to see if
> there’s anything to it. 

I would hack up some way to grab a clump (say 10) of samples and print them 
out where you can capture them on a PC and analyze them.

I'd start by looking with the old Mark 1 eyeballs, then write hack code to 
filter out the good stuff so I can see the bad/interesting cases.

If you have a scope, it might be interesting to trigger on PPS and look at 
the ADC trigger and input voltage.  If you have a digital scope with the 
remember forever option, that would catch the delayed interrupt bug that Jim 
Harman reported.

---

The simple way to discard occasional bogus samples is to loop until you get 2 
identical samples.



-- 
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] Measure GPSDO stability with minimum resources?

[Bob Stewart]

Hi Jim,
I'm using an interpolated RC/ADC TIC to measure the time interval between the 
1PPS from the receiver to the next OCXO pulse.  I also count the OCXO pulses 
between 1PPS ticks to make sure I'm on 10 MHz.

I've been developing and improving this GPSDO for over 2 years now, so I have a 
good understanding of the qualities of the OCXO, etc.  But, what I know in 
general, and what each OCXO does in specific is a slightly different story.  
So, phase lock first:  I have been checking to see if the phase error to target 
has remained less than +/- 13ns for 500 seconds before declaring "locked" with 
good success.  So, lock detection is not critical, but being able to have more 
confidence, rather than using a set value like this would be nice.  And that's 
the reason I mentioned the 5 minute circular queue experiment.  It does seem to 
give me a nice low number when I can look at a plot and say "that's locked", so 
I may play with it some more.

As you say, aging is an entirely different question.  The OCXOs I use 
eventually retrace out and age at about 1 (20-bit) DAC step per hour; some 
better, some worse, and not always in the same direction.  Being able to 
project this before several months go by would be nice for holdover 
projections.  Doesn't the KS-24361 GPSDO set start making holdover projections 
within a half our of being powered on?  That's the sort of thing I was looking 
for.  

After posting, I realized that integrating the DAC movement while in lock 
wasn't a very good idea, as eventually it's going to reach a rather large 
magnitude.  And that number wouldn't be very useful, as it's not related to any 
time period, other than when time began.  I also realized that since it is 
under PLL control, there aren't going to be any large swings, so I don't need 
any real sort of figure of merit that describes +/- swings, etc.  So, I guess I 
was making this harder than it needed to be.

So, now I'm thinking about going to a 24-hour circular queue that samples every 
5 minutes.  That would be 288 slots, or 1152 bytes, which I can spare.  With 24 
hours of data, I should be able to get some idea as to how quickly it's 
settling down.  The question is how to use that to project retrace and aging 
over the next 24 hours in case of a holdover event?
Bob -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Jim Harman 
 To: Bob Stewart ; Discussion of precise time and frequency 
measurement  
 Sent: Wednesday, October 5, 2016 9:14 PM
 Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?
   

On Wed, Oct 5, 2016 at 6:46 PM, Bob Stewart  wrote:

 What I'm really looking for is a way to do everything in the PIC.  I've been 
experimenting with saving the DAC value in a circular queue every 20 seconds 
for 60 minutes, and plotting the difference value between the head and tail of 
the queue every second.  After posting this question, I took another look at 
the overall behavior and decided to cut the queue size down from 60 minutes to 
5.  

Hi Bob,
Unless the oscillator is still warming up, 5 minutes or even 60 is way too 
short a time to look at aging. For aging, you will want to look at the change 
in DAC values over several days at least. 
Looking at the current value and one in the past will give you a feel for what 
is going on, but then you are discarding all the intermediate data. You really 
want to do a least squares fit using as many data points as you can handle, 
Check Wikipedia under Linear Least Squares for an example.
What sort of phase detector are you using? If you want to see whether the 
system is locked, you may be better off looking at the phase detector 
signal.and declaring a lock if the low pass filtered phase error stays within a 
pre-determined range.

-- 

--Jim Harman


   
___
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] Need Time Help

[Chris Albertson]

There was a time when HAMs where the ones pushing radio technology
forward.  Maybe these guys are doing that and building a digital EME
network on VHF?  We don't know.

We can guess but typically when you start wanting precise time
synchronization it is because of something like TDMA (time division
multiple access) to a shared resource.

On Wed, Oct 5, 2016 at 9:47 AM, Wes  wrote:

> If you are working "real" EME where you, and not a computer plus lookup
> table, are coping the signals, none of these precise timing issues exist.
>
> Wes  N7WS
>
>
> On 10/5/2016 6:18 AM, Peter Torry via time-nuts wrote:
>
>> I must admit to being rather puzzled at the sub microsecond timing
>> requirement as I use ntp to set the W7 clock in my computer and have not
>> had any issues. In fact less than one second is OK for the usual two minute
>> periods that are required to allow for the Faraday rotation. Although I use
>> a GPSDO for a frequency reference I find JT software reasonably tolerant of
>> frequency.  As I may be missing something I would welcome observations on
>> how important the period timing requirement is, you never know I might get
>> more contacts.
>>
>> Regards
>>
>> Peter
>>
>>
>> On 05/10/2016 12:50, Graham / KE9H wrote:
>>
>>> For the group. This ham is trying to work EME. Earth-Moon-Earth
>>> propagation
>>> path. Aka, "moonbounce."
>>>
>>> He is trying to time synchronize a system, where the other station he is
>>> communicating
>>> with can be any other place on the Earth that can also see the Moon.
>>>
>>> So the system time sync is for a little bit tougher case than a local
>>> area
>>> network.
>>>
>>> --- Graham
>>>
>>
> ___
> 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.
>



-- 

Chris Albertson
Redondo Beach, California
___
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] Measure GPSDO stability with minimum resources?

[Jim Harman]

On Wed, Oct 5, 2016 at 6:46 PM, Bob Stewart  wrote:

> What I'm really looking for is a way to do everything in the PIC.  I've
> been experimenting with saving the DAC value in a circular queue every 20
> seconds for 60 minutes, and plotting the difference value between the head
> and tail of the queue every second.  After posting this question, I took
> another look at the overall behavior and decided to cut the queue size down
> from 60 minutes to 5.


Hi Bob,

Unless the oscillator is still warming up, 5 minutes or even 60 is way too
short a time to look at aging. For aging, you will want to look at the
change in DAC values over several days at least.

Looking at the current value and one in the past will give you a feel for
what is going on, but then you are discarding all the intermediate data.
You really want to do a least squares fit using as many data points as you
can handle, Check Wikipedia under Linear Least Squares for an example.

What sort of phase detector are you using? If you want to see whether the
system is locked, you may be better off looking at the phase detector
signal.and declaring a lock if the low pass filtered phase error stays
within a pre-determined range.

-- 

--Jim Harman
___
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] ADC sample voting algorithm?

[Jim Harman]

On Wed, Oct 5, 2016 at 7:45 PM, Nick Sayer via time-nuts  wrote:

> I notice periodically that the phase measurements seem “noisy.” You can
> see that over the course of several seconds the value doesn’t change, then
> it jumps a bunch and then comes right back.
>

Hi Nick,

At one point I had a problem with noisy phase readings where the "noise"
took the form of an occasional reading that was low by up to about 50
counts. These events were quite rare - less often than once per hour on
average. After much head-scratching, it turned out that I had an interrupt
conflict that sometimes caused the PPS interrupt to be delayed, Because the
ADC was triggered inside this routine, the analog signal had drooped a
little before the ADC was triggered.

I was able to completely solve this by setting up the ADC sample/hold and
conversion to be triggered directly by the PPS signal, thus eliminating any
dependency on the interrupt latency. The PPS still generates an interrupt,
but in the interrupt routine, all I have to do is wait for the ADC to
finish, clear the Done bit, and reset the trigger.


-- 

--Jim Harman
___
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] ADC sample voting algorithm?

[Scott Stobbe]

It sounds like once in awhile your sampling something else too. Ground
bounce of a 10 MHz buffer, or something coupling onto your phase detector,
or running your adc at the edge of a timing spec?

How large would the outlier be in mV?

On Wednesday, 5 October 2016, Nick Sayer via time-nuts 
wrote:

> This is tangentially on topic, I suppose. It’s for my GPSDO.
>
> I notice periodically that the phase measurements seem “noisy.” You can
> see that over the course of several seconds the value doesn’t change, then
> it jumps a bunch and then comes right back.
>
> My theory at the moment is that sampling the ADC multiple times in a row
> might help, but then what’s the best way to (quickly) pick which sample to
> use?
>
> The mean would allow a bad sample undue influence.
>
> At the moment, I’ve coded taking 3 samples, averaging them and picking the
> sample that is closest to the mean. If I’m right, and two of the samples
> happen to be very close to each other and a third is an outlier, then that
> seems like it would eliminate it.
>
> I guess what I want is the mode, but with 3 samples, that’s going to be
> poorly defined (if at all).
>
> Anyone have any suggestions (besides a larger sample size)?
> ___
> 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] ADC sample voting algorithm?

[Bob Camp]

Hi

If you are looking at a high impedance source with a “normal” ADC, you need a 
buffer amp. 

If you have a signal that decays, it is generally not a good idea to toss all 
the samples into a 
single bucket. You probably need to do some sort of slope estimation. 

The still better solution is to get an ADC that is not super noisy. Most built 
in ADC’s on 
MCU’s are quite noisy when evaluated against their claimed resolution level. 
Even with a few
thousand samples, this may not improve as much as you would wish for. 

Better still, use a converter with a fast enough slope that the ADC noise is 
not an issue. 

Bob

> On Oct 5, 2016, at 8:22 PM, Nick Sayer via time-nuts  
> wrote:
> 
> 
>> On Oct 5, 2016, at 5:00 PM, Bob Camp  wrote:
>> 
>> Hi
>> 
>> What does the signal you are sampling look like? 
> 
> The last time I actually looked (it was a while ago), it looked reasonable as 
> closely as I could look, but the ADC resolution is something like 1mV per 
> LSB, and I’m not sure I looked that closely.
> 
>> 
>> Does it (maybe) have a bit of noise on it?
>> 
>> If it is the output of a “normal” TDC, then the answer is to sample once.
> 
> I dunno about a “normal” one… This one is the one I got from Jim Harman. The 
> phase difference between the divided-by-10 output and PPS goes through a 
> diode, JFET and then an RC (with a much higher discharge resistor).
> 
> As long as you sample at least 1 µs after the PPS (and it takes at least that 
> long to get into the ISR anyway), it *ought* to be stable for dozens of µs.
> 
> That’s kind of why I’m going down the road of multiple samples - to see if 
> there’s anything to it.
> 
> 
> ___
> 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] time-nuts Digest, Vol 147, Issue 13

[Jim Stone]

Re: TNS-BUF Amplifier

--Jim Robbins wrote:

 Many thanks for your helpful TN work to John A. , Dr. Bruce and John M.
Ordered 3 pieces.

--
I second the thanks and ordered 2 pieces

--Jim Stone

On Wed, Oct 5, 2016 at 9:00 AM,  wrote:

> Send time-nuts mailing list submissions to
> time-nuts@febo.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> or, via email, send a message with subject or body 'help' to
> time-nuts-requ...@febo.com
>
> You can reach the person managing the list at
> time-nuts-ow...@febo.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of time-nuts digest..."
>
>
> Today's Topics:
>
>1. Re: Need Time Help (Mark Spencer)
>2. TNS-BUF Amplifier (James Robbins)
>3. Re: Need Time Help (Chris Caudle)
>
>
> --
>
> Message: 1
> Date: Wed, 5 Oct 2016 07:35:21 -0700
> From: Mark Spencer 
> To: Peter Torry , Discussion of precise time
> and frequency measurement 
> Subject: Re: [time-nuts] Need Time Help
> Message-ID:
> 
> Content-Type: text/plain;   charset=us-ascii
>
> Yes I'd be curious in knowing more about this as well.  I've often
> observed time differences from other stations of several tenths of a second
> when running the JT modes on HF.  Although I am beginner at EME I have made
> a couple of EME (earth moon earth) JT65 contacts on VHF without taking any
> special measures to sync the time on a Windows XP machine beyond using the
> built in features of the operating system to sync to my own local time
> server which was in turned synced to the 1 pps output of a GPS timing
> receiver.
>
> I've also made FSK441 contacts (another related form of amateur radio
> digital communications) in the field without any time reference besides the
> free running clock in my Windows xp laptop.  If there is a significant
> performance improvement to be had with these modes by having time nuts
> levels of timing precision on my computers I'd be very interested to know
> more.
>
> All the best
> Mark S
>
> Sent from my iPhone
>
> > On Oct 5, 2016, at 6:18 AM, Peter Torry via time-nuts <
> time-nuts@febo.com> wrote:
> >
> > I must admit to being rather puzzled at the sub microsecond timing
> requirement as I use ntp to set the W7 clock in my computer and have not
> had any issues. In fact less than one second is OK for the usual two minute
> periods that are required to allow for the Faraday rotation. Although I use
> a GPSDO for a frequency reference I find JT software reasonably tolerant of
> frequency.  As I may be missing something I would welcome observations on
> how important the period timing requirement is, you never know I might get
> more contacts.
> >
> > Regards
> >
> > Peter
> >
> >
> >> On 05/10/2016 12:50, Graham / KE9H wrote:
> >> For the group. This ham is trying to work EME. Earth-Moon-Earth
> propagation
> >> path. Aka, "moonbounce."
> >>
> >> He is trying to time synchronize a system, where the other station he is
> >> communicating
> >> with can be any other place on the Earth that can also see the Moon.
> >>
> >> So the system time sync is for a little bit tougher case than a local
> area
> >> network.
> >>
> >> --- Graham
> >
> > ___
> > 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.
> >
>
>
> --
>
> Message: 2
> Date: Wed, 5 Oct 2016 10:56:05 -0400
> From: "James Robbins" 
> To: 
> Subject: [time-nuts] TNS-BUF Amplifier
> Message-ID: <01c301d21f18$9994aee0$ccbe0ca0$@earthlink.net>
> Content-Type: text/plain;   charset="us-ascii"
>
> Many thanks for your helpful TN work to John A. , Dr. Bruce and John M.
> Ordered 3 pieces.
>
>
>
> 73,
>
> Jim Robbins
>
> N1JR
>
>
>
> --
>
> Message: 3
> Date: Wed, 5 Oct 2016 10:19:10 -0500
> From: "Chris Caudle" 
> To: time-nuts@febo.com
> Subject: Re: [time-nuts] Need Time Help
> Message-ID:
> 
> Content-Type: text/plain;charset=iso-8859-1
>
> On Wed, October 5, 2016 6:14 am, Bob Camp wrote:
> > If you buy a GPS receiver and get it set up for timing, just use it.
> > Then there is no need for NTP at all.
>
> Is there another way to get computer system time set from a GPS receiver
> other than NTP?
> In the case that the system clock is controlled by GPSDO and the seconds
> delineated by PPS, 

Re: [time-nuts] ADC sample voting algorithm?

[Nick Sayer via time-nuts]

> On Oct 5, 2016, at 5:00 PM, Bob Camp  wrote:
> 
> Hi
> 
> What does the signal you are sampling look like? 

The last time I actually looked (it was a while ago), it looked reasonable as 
closely as I could look, but the ADC resolution is something like 1mV per LSB, 
and I’m not sure I looked that closely.

> 
> Does it (maybe) have a bit of noise on it?
> 
> If it is the output of a “normal” TDC, then the answer is to sample once.

I dunno about a “normal” one… This one is the one I got from Jim Harman. The 
phase difference between the divided-by-10 output and PPS goes through a diode, 
JFET and then an RC (with a much higher discharge resistor).

As long as you sample at least 1 µs after the PPS (and it takes at least that 
long to get into the ISR anyway), it *ought* to be stable for dozens of µs.

That’s kind of why I’m going down the road of multiple samples - to see if 
there’s anything to it.


___
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] ADC sample voting algorithm?

[Bob Stewart]

In that case, have you taken the time to look at the math of the sawtooth vs 
measured phase?  If you like, you can send me 20 or 30 sequential data samples 
that contains what appears to be good as well as the bad to look at?  And which 
receiver are you using for this?
Bob -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Nick Sayer via time-nuts 
 To: 
Cc: Discussion of precise time and frequency measurement 
 Sent: Wednesday, October 5, 2016 6:57 PM
 Subject: Re: [time-nuts] ADC sample voting algorithm?
   

> On Oct 5, 2016, at 4:52 PM, Bob Stewart  wrote:
> 
> Hi Nick,
> 
> Are you applying sawtooth correction to your phase measurement? 

Yes, these are post-correction observations. I have some confidence that my 
corrections are scaled appropriately for the ADC values because of their 
stability “most” of the time (meanwhile, the uncorrected values are bouncing 
around inside a 12 ns corridor).

> If not, are you merely seeing a hanging bridge that dissolves into at a 
> normal sort of tick-tock movement?
> 
> Bob
> 
> From: Nick Sayer via time-nuts 
> To: Discussion of precise time and frequency measurement  
> Sent: Wednesday, October 5, 2016 6:45 PM
> Subject: [time-nuts] ADC sample voting algorithm?
> 
> This is tangentially on topic, I suppose. It’s for my GPSDO.
> 
> I notice periodically that the phase measurements seem “noisy.” You can see 
> that over the course of several seconds the value doesn’t change, then it 
> jumps a bunch and then comes right back.
> 
> My theory at the moment is that sampling the ADC multiple times in a row 
> might help, but then what’s the best way to (quickly) pick which sample to 
> use?
> 
> The mean would allow a bad sample undue influence.
> 
> At the moment, I’ve coded taking 3 samples, averaging them and picking the 
> sample that is closest to the mean. If I’m right, and two of the samples 
> happen to be very close to each other and a third is an outlier, then that 
> seems like it would eliminate it.
> 
> I guess what I want is the mode, but with 3 samples, that’s going to be 
> poorly defined (if at all).
> 
> Anyone have any suggestions (besides a larger sample size)?
> ___
> 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] ADC sample voting algorithm?

[Bob Camp]

Hi

What does the signal you are sampling look like? 

Does it (maybe) have a bit of noise on it? 

If it is the output of a “normal” TDC, then the answer is to sample once.

Bob

> On Oct 5, 2016, at 7:45 PM, Nick Sayer via time-nuts  
> wrote:
> 
> This is tangentially on topic, I suppose. It’s for my GPSDO.
> 
> I notice periodically that the phase measurements seem “noisy.” You can see 
> that over the course of several seconds the value doesn’t change, then it 
> jumps a bunch and then comes right back.
> 
> My theory at the moment is that sampling the ADC multiple times in a row 
> might help, but then what’s the best way to (quickly) pick which sample to 
> use?
> 
> The mean would allow a bad sample undue influence.
> 
> At the moment, I’ve coded taking 3 samples, averaging them and picking the 
> sample that is closest to the mean. If I’m right, and two of the samples 
> happen to be very close to each other and a third is an outlier, then that 
> seems like it would eliminate it.
> 
> I guess what I want is the mode, but with 3 samples, that’s going to be 
> poorly defined (if at all).
> 
> Anyone have any suggestions (besides a larger sample size)?
> ___
> 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] ADC sample voting algorithm?

[Bob Stewart]

Hi Nick,
Are you applying sawtooth correction to your phase measurement?  If not, are 
you merely seeing a hanging bridge that dissolves into at a normal sort of 
tick-tock movement?
Bob

  From: Nick Sayer via time-nuts 
 To: Discussion of precise time and frequency measurement  
 Sent: Wednesday, October 5, 2016 6:45 PM
 Subject: [time-nuts] ADC sample voting algorithm?
   
This is tangentially on topic, I suppose. It’s for my GPSDO.

I notice periodically that the phase measurements seem “noisy.” You can see 
that over the course of several seconds the value doesn’t change, then it jumps 
a bunch and then comes right back.

My theory at the moment is that sampling the ADC multiple times in a row might 
help, but then what’s the best way to (quickly) pick which sample to use?

The mean would allow a bad sample undue influence.

At the moment, I’ve coded taking 3 samples, averaging them and picking the 
sample that is closest to the mean. If I’m right, and two of the samples happen 
to be very close to each other and a third is an outlier, then that seems like 
it would eliminate it.

I guess what I want is the mode, but with 3 samples, that’s going to be poorly 
defined (if at all).

Anyone have any suggestions (besides a larger sample size)?
___
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] ADC sample voting algorithm?

[Nick Sayer via time-nuts]

> On Oct 5, 2016, at 4:52 PM, Bob Stewart  wrote:
> 
> Hi Nick,
> 
> Are you applying sawtooth correction to your phase measurement? 

Yes, these are post-correction observations. I have some confidence that my 
corrections are scaled appropriately for the ADC values because of their 
stability “most” of the time (meanwhile, the uncorrected values are bouncing 
around inside a 12 ns corridor).

> If not, are you merely seeing a hanging bridge that dissolves into at a 
> normal sort of tick-tock movement?
> 
> Bob
> 
> From: Nick Sayer via time-nuts 
> To: Discussion of precise time and frequency measurement  
> Sent: Wednesday, October 5, 2016 6:45 PM
> Subject: [time-nuts] ADC sample voting algorithm?
> 
> This is tangentially on topic, I suppose. It’s for my GPSDO.
> 
> I notice periodically that the phase measurements seem “noisy.” You can see 
> that over the course of several seconds the value doesn’t change, then it 
> jumps a bunch and then comes right back.
> 
> My theory at the moment is that sampling the ADC multiple times in a row 
> might help, but then what’s the best way to (quickly) pick which sample to 
> use?
> 
> The mean would allow a bad sample undue influence.
> 
> At the moment, I’ve coded taking 3 samples, averaging them and picking the 
> sample that is closest to the mean. If I’m right, and two of the samples 
> happen to be very close to each other and a third is an outlier, then that 
> seems like it would eliminate it.
> 
> I guess what I want is the mode, but with 3 samples, that’s going to be 
> poorly defined (if at all).
> 
> Anyone have any suggestions (besides a larger sample size)?
> ___
> 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] ADC sample voting algorithm?

[Nick Sayer via time-nuts]

This is tangentially on topic, I suppose. It’s for my GPSDO.

I notice periodically that the phase measurements seem “noisy.” You can see 
that over the course of several seconds the value doesn’t change, then it jumps 
a bunch and then comes right back.

My theory at the moment is that sampling the ADC multiple times in a row might 
help, but then what’s the best way to (quickly) pick which sample to use?

The mean would allow a bad sample undue influence.

At the moment, I’ve coded taking 3 samples, averaging them and picking the 
sample that is closest to the mean. If I’m right, and two of the samples happen 
to be very close to each other and a third is an outlier, then that seems like 
it would eliminate it.

I guess what I want is the mode, but with 3 samples, that’s going to be poorly 
defined (if at all).

Anyone have any suggestions (besides a larger sample size)?
___
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] Need Time Help

[Chris Albertson]

First off you are right, NTP does not run well as it can with only a single
reference.   But that is a general statement and assumes there is some
error in a reference clock.   Certainly if using Internet pool servers as
reference clocks you want to have 5 to 7 of them.  But GPS is so darn good
that NTP will be unable to find the difference between any two GPS
receivers.   GPS is a special case.Remember the NTP can use about a
dozen different kinds of reference clocks, even if today only a few are
used in practice.  (really who uses WWV as a standard for their computer
anymore?)


Of course there are other ways of getting time into a Windows PC then using
NTP.  The most primitive thing possible is to simply "jam set" the PC clock
from a NEMA sentence.  This can be as much as a full second "off" and has a
50% chance of making your PC clock run backward (if it was fast rather then
slow)  but LOADS of software offer to do just this, Lady Heather included.

But if you want something that avoids all those problems and makes the
clock perform reasonable at all times then there really are two options NTP
and PTP.  If you are using a GPS as a reference Either if OK,

The problem is harder then most people think. To avoid jumps in time either
forward or backwards the software must be something that runs continuously
and monitors your clock vs. one or more reference clocks.   Logically there
is no other way.  The correction process must be continuously.   PTP and
NTP do this well enough that I doubt anyone would bother to write something
to compete with them.

Between the two PTP performs best in the special case that you own all of
the hardware on both ends and the communications network.

Most casual users can live with a system that "jam-sets" the clock as they
are just reading the display and don't care if  (say) 14:45:30.345 happens
AFTER 14:45:30.355But if you are doing something like trying to aim a
telescope such a thing will cause it to jump and ruin a time exposure.
But I doubt an EME antenna needs to be pointed with the same arc second
level precision.

The BEST way to get GPS time into a computer, and this is how, I think the
world record accuracy was done is to use a GPSDO in place of the cheap
crystal on the motherboard and then spend many hours comparing the
computer's clock to GPS, sorry I lost the link to this  But this method
gets you fractions of microseconds.  The worst way is to parse NEMA
sentences and jam-set them into the clock.  This gets you to roughly one
second, more or less.

On Wed, Oct 5, 2016 at 8:19 AM, Chris Caudle  wrote:

> On Wed, October 5, 2016 6:14 am, Bob Camp wrote:
> > If you buy a GPS receiver and get it set up for timing, just use it.
> > Then there is no need for NTP at all.
>
> Is there another way to get computer system time set from a GPS receiver
> other than NTP?
> In the case that the system clock is controlled by GPSDO and the seconds
> delineated by PPS, there should be no need for the NTP clock discipline
> code, but I am not aware of any way to inform the NTP daemon that no
> disciplining is needed.  Presumably the code should determine that
> eventually.
>
> In the case that the system clock is free running, the clock discipline is
> still needed, but I found a note in one of the NTP documents (that I can
> no longer locate at the moment) that stated something to the effect that
> NTP did not run well as it could with a single reference, which would seem
> to directly affect the case where a GPS receiver is the only reference.
> That document had only that short note, no details on why or specifics of
> behavior.
>
> --
> 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.
>



-- 

Chris Albertson
Redondo Beach, California
___
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] Measure GPSDO stability with minimum resources?

[Bob Stewart]

I just noticed that my reply didn't go to the list so...
Thanks for the reply.  What I'm really looking for is a way to do everything in 
the PIC.  I've been experimenting with saving the DAC value in a circular queue 
every 20 seconds for 60 minutes, and plotting the difference value between the 
head and tail of the queue every second.  After posting this question, I took 
another look at the overall behavior and decided to cut the queue size down 
from 60 minutes to 5.  At the moment, I'm doing a trial run of integrating the 
difference values starting at the point where I decide that it's locked.  Maybe 
I'll gain enough insight from this to get a better idea on calculating the 
aging rate.  The 5 minute queue seems to give me a good indication of how well 
the PLL is locked.  Maybe saving the integrated values into a longer queue 
that's sampled once every 5 minutes will give me something for aging rate.

Bob -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Jim Harman 
 To: Bob Stewart ; Discussion of precise time and frequency 
measurement  
 Sent: Wednesday, October 5, 2016 4:37 PM
 Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?
   

On Wed, Oct 5, 2016 at 1:37 PM, Bob Stewart  wrote:

For my GPSDO, I need to calculate the OCXO aging for holdover projection 
purposes as well as get some figure of merit for the recent past of the OCXO 
stability. 

Do you have a serial port or some way of generating a logging stream?
If so, one low-overhead way to track the aging is to compute an average DAC 
value and periodically "print" the result to the serial port. I have found that 
a 3-hour average works well for observing aging. Each second you simply add the 
current DAC value to a Long and after 3 hours divide by 10800, print the 
result, reset the total, and repeat. It is helpful to also include the current 
time. This could be extracted from the GPS NMEA data  or simply be seconds 
since startup. If you separate the values with a Tab and end each set of values 
with a newline, you can capture the data with an attached PC, copy/paste to 
Excel, and analyze it there. The trend line feature in Excel's chart will 
compute and display a least square fit to the aging.
If you don't want to keep the monitor connected full time and you have some 
extra RAM or preferably EEPROM, you can store historic average values in a 
circular buffer and print one of the values every second. 288 bytes will store 
18 days worth of 16 bit 3-hour averages. 
My system, based on the one posted here by Lars Walenius some time ago,collects 
144 sets of 5-minute averages (12 hours worth) and another 144 sets of 3-hour 
averages. It spits out one line of logging data each second. The first part of 
each line has the current data, and the second part has either one of the 
5-minute sets or one of the 3-hour sets. So 5 minutes worth of logging data has 
300 lines, showing current data plus 5-minute averages for the past 12 hours 
and 3-hour averages for the past 18 days.
All this, including the GPSDO code, fits comfortably in a 32u4-based Arduino 
Micro, which has 32K of program memory, 2.5K of RAM, and 1K of EEPROM. 



-- 

--Jim Harman


   
___
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] Need Time Help

[Bob Camp]

Hi

Given that this is for intermittent EME use, it’s not a system that has uber
reliability as a requirement. Once you get the antenna up in a reasonable 
location
a GPS is going to be pretty stable and reliable. If you have an EME array 
running, adding a GPS antenna to it probably not a big deal. 

If it *is* a big deal, run a GPSDO and then it’s no longer a problem. The KS
boxes still seem to be out there for < $100 ….

Bob

> On Oct 5, 2016, at 2:32 PM, Gary E. Miller  wrote:
> 
> Yo Bob!
> 
> On Wed, 5 Oct 2016 07:14:30 -0400
> Bob Camp  wrote:
> 
>> If you buy a GPS receiver and get it set up for timing …. just use
>> it. Then there is no need for NTP at all….
> 
> Assuming your GPS never farts and always has a good lock.  A pretty
> good assumption, but not a perfect one.
> 
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>   g...@rellim.com  Tel:+1 541 382 8588
> ___
> 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] Measure GPSDO stability with minimum resources?

[Jim Harman]

On Wed, Oct 5, 2016 at 1:37 PM, Bob Stewart  wrote:

> For my GPSDO, I need to calculate the OCXO aging for holdover projection
> purposes as well as get some figure of merit for the recent past of the
> OCXO stability.


Do you have a serial port or some way of generating a logging stream?

If so, one low-overhead way to track the aging is to compute an average DAC
value and periodically "print" the result to the serial port. I have found
that a 3-hour average works well for observing aging. Each second you
simply add the current DAC value to a Long and after 3 hours divide by
10800, print the result, reset the total, and repeat. It is helpful to also
include the current time. This could be extracted from the GPS NMEA data
 or simply be seconds since startup. If you separate the values with a Tab
and end each set of values with a newline, you can capture the data with an
attached PC, copy/paste to Excel, and analyze it there. The trend line
feature in Excel's chart will compute and display a least square fit to the
aging.

If you don't want to keep the monitor connected full time and you have some
extra RAM or preferably EEPROM, you can store historic average values in a
circular buffer and print one of the values every second. 288 bytes will
store 18 days worth of 16 bit 3-hour averages.

My system, based on the one posted here by Lars Walenius some time
ago,collects 144 sets of 5-minute averages (12 hours worth) and another 144
sets of 3-hour averages. It spits out one line of logging data each second.
The first part of each line has the current data, and the second part has
either one of the 5-minute sets or one of the 3-hour sets. So 5 minutes
worth of logging data has 300 lines, showing current data plus 5-minute
averages for the past 12 hours and 3-hour averages for the past 18 days.

All this, including the GPSDO code, fits comfortably in a 32u4-based
Arduino Micro, which has 32K of program memory, 2.5K of RAM, and 1K of
EEPROM.




-- 

--Jim Harman
___
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] GPSDO Sigma Tau at large observation times

[Tim Lister]

On Wed, Oct 5, 2016 at 11:01 AM, Tom Van Baak  wrote:
> Hello again Estanislao,
>
> Nice set of questions. The short answer is that for a GPSDO,
> - The left side of the ADEV plot will show the difference between the quality 
> of the local oscillator, in your case TCXO vs. OCXO vs. Rb.
> - The middle of the ADEV plot will show the difference in the choice of 
> time-constant or the environmental conditions during the test.
> - The right side of the ADEV will show the quality of the GPS timing receiver.
>
> Also,
> - The left side of the ADEV plot may expose limitations in your measurement 
> equipment or the local low-noise reference that you're using.
> - The right side of the ADEV plot may expose limitations in your local 
> frequency reference. A cesium or H-maser helps here. If you use one GPSDO to 
> test another GPSDO the very right side of the ADEV plot is misleading.
>
> See also the examples here: http://leapsecond.com/pages/gpsdo/

Hi Tom, quick question: I've seen these plots before and they are very
useful to know what to aim at for GPSDO performance. Am I right in
thinking these were measured against a master - the page says " a very
stable 10 MHz reference. " without more details (unless I missed it)

>
> /tvb
>

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

[time-nuts] cleanup

[djl]

Clearing and cleaning. Have stuff fs, pickup, very cheap. 5370a's 5370b, 
3-5320A all with precision osc's 3325a fcn gen, Kode 3100, all working 
5335a counts 1/2, plain xtal, and two J Seamon beaglebones for 5370's, 
unused. BB's are not for sale separately. Pick it all up here,I'm only 2 
mi of good road off I90. Contact me off list at djl ampersand montana 
dot com. There is more stuff here as well. Big sale.

Thanks for your patience.
Don

--
Dr. Don Latham
PO Box 404, Frenchtown, MT, 59834
VOX: 406-626-4304

___
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] GPSDO Sigma Tau at large observation times

[Attila Kinali]

On Wed, 5 Oct 2016 11:01:36 -0700
"Tom Van Baak"  wrote:

> Nice set of questions. The short answer is that for a GPSDO,
> - The left side of the ADEV plot will show the difference between the quality 
> of the local oscillator, in your case TCXO vs. OCXO vs. Rb. 
> - The middle of the ADEV plot will show the difference in the choice of 
> time-constant or the environmental conditions during the test.
> - The right side of the ADEV will show the quality of the GPS timing receiver.
> 
> Also,
> - The left side of the ADEV plot may expose limitations in your measurement 
> equipment or the local low-noise reference that you're using.
> - The right side of the ADEV plot may expose limitations in your local 
> frequency reference. A cesium or H-maser helps here. If you use one GPSDO to 
> test another GPSDO the very right side of the ADEV plot is misleading.

Additional to this, I recommend having a look at Enrico's Chart[1].
It lables all the slopes in the different forms we measure stability
and what noise type they represent, and also their relationship.

Attila Kinali


[1] http://rubiola.org/pdf-static/Enrico's-chart-EFTS.pdf


-- 
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] Need Time Help

[Tim Shoppa]

I agree that the built in Microsoft tools are SNTP only and will not work
at the 15ms level.

I have had excellent success with Windows PC's of many vintages, from XP
through Windows 10, using Meinberg NTPD and the "pool.ntp.org" timeservers.

Tim N3QE

On Tue, Oct 4, 2016 at 12:41 AM, Larry Hower  wrote:

> Hello to the List:
>
> After a long and bitter struggle with XP and WIN 10, I am writing to ask
> for some help in solving some problems we have been having in our attempt
> to establish a very accurate time reference for use in EME activities.
>
> We are hoping to achieve less than 5ms deviation, although anything below
> 15ms will be adequate for now.
>
> Specifically, we want to use a universal reference that will enable amateur
> radio operators in different parts of the world to start and stop their
> transmissions within a few milliseconds of a specific time. For example, I
> transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
> transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.
>
> We are using WSJT-X software. We use standard receivers plus we have tried
> a few SDRs.
>
> Sorry for the oversimplified example but I want to make sure we are all on
> the same page.
>
> As background:
>
> 1. We are using desktops and laptops in separate locations running XP or
> Win 10.
>
> 2. We have used MS clock tools, including use of Boulder time servers,
> tried both host name and IP address, without reaching the goal.
>
> 3. We have set up some Serial GPS units with PPS and some USB GPS receivers
> (no PPS) and can get to about 0.2 sec but it is not trusted or close
> enough.
>
> 4. We have set up a network time server with similar results.
>
> 5. Deviation is measured using WSJT-X
>
> -
>
> *Standard Receivers*
>
> ICOMs (910/9100 and others – non-SDR). Locked to 10MHz external osc
> reference. We have frequency accuracy of 1 to 2 Hertz at 10GHz.
>
>
> *SDRs*
>
> We believe that SDR processing can insert a delay of varying length,
> depending on the software, bandwidth, etc. Our SDR tests seem to have a
> delay of as much as 0.5 sec. And with sometimes variable results. We will
> see how SDRs can be used after we resolve the current issues.
>
>
> *Some time related hardware details*
>
> *1. Global Star 4 USB and Serial Connections*
>
> http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
>
> We have 4 of these. Two are older models with serial connections. We have
> serial ports on some computers (XP and a new high-end laptop running WIN
> 10) so we are able to activate the PPS option. Two of the GStar are newer
> models with USB connections which are not able to use the PPS option.
>
> We have tried NEMATime and NEMATime 2 software on this hardware without
> reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
> sec. Drifts.  Deviation is measured using WSJT-X.
>
>
> *2. TimeNet NTP Device*
>
> http://www.veracityglobal.com/products/networked-video-integ
> ration-devices/timenet.aspx
>
> We have one of these TimNet units and it has been set up at 2 different
> locations on differing computers according to user instructions. We are
> using the TimNet software as DL'd recently from their web site. We get GPS
> “lock” and Time “lock” shown in the user panel but we do not have faith
> that this is carried into the system clock. Occasionally the "lock"
> indicators go blank but the time seems to be updated when the software is
> strted again (the updated is operation is show at the correct time.  We
> think the app needs some work. Deviation is measured using WSJT-X.  See
> later details.
>
>
> *Setup*
>
> The G Star units have been installed at 2 separate locations, tested using
> WSJT-X QRA 64 and WSPR-2 signals on 10.137MHz.
>
> Similar tests with a TimeNet unit at one end and G Stars at the other end.
>
> G Star units were installed on the XP laptops with the PPS option enabled
> and running WSJT-X. These XP units seem to have their time “in sync”. See
> following.
>
>
> *WSJT-X*
>
> We are not sure what, if any, internal delays there are attributable to
> this software. We have been using the same version/build at both ends for
> the tests. The software displays in 0.1 sec increments but will show 0.0sec
> when things appear to be working well. We do not know the actual level of
> precision of the WSJT-X software time measurements. I undersand that WSJT-X
> “reads” the system clock at the start of a period (TX or RX) and displays
> what it finds as the time deviation from the local system clock.
>
>
> *WIN XP*
>
> There are 2 laptops running XP. They seem to match each other re time using
> WSJT-X, both are “out” usually by less than 0.1ms or 0.2ms. We are fairly
> sure that they are working properly but they need to be more accurate
> (<15ms).
>
>
> *WIN 10*
>
> Installed on a number of desktop and laptop computers. Many efforts were
> made to make these system clocks reference the GPS devices.
>
> We became aware 

Re: [time-nuts] Need Time Help

[Gary E. Miller]

Yo Bob!

On Wed, 5 Oct 2016 07:14:30 -0400
Bob Camp  wrote:

> If you buy a GPS receiver and get it set up for timing …. just use
> it. Then there is no need for NTP at all….

Assuming your GPS never farts and always has a good lock.  A pretty
good assumption, but not a perfect one.

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


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

Re: [time-nuts] Need Time Help

[Gary E. Miller]

Yo Chris!

On Wed, 5 Oct 2016 10:19:10 -0500
"Chris Caudle"  wrote:

> On Wed, October 5, 2016 6:14 am, Bob Camp wrote:
> > If you buy a GPS receiver and get it set up for timing, just use it.
> > Then there is no need for NTP at all.  
> 
> Is there another way to get computer system time set from a GPS
> receiver other than NTP?

gpsd.

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


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

Re: [time-nuts] TNS-BUF High Isolation, Low Noise Buffer Amp Available

[John Ackermann N8UR]

It's possible we may have some bare boards, but no guarantees at this point.

On 10/5/2016 2:04 PM, Dan Rae wrote:

For those of us who aren't scared of surface mount stuff, and maybe even
prefer it, will there be any bare boards available?

Dan - ac6ao
___
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] TNS-BUF High Isolation, Low Noise Buffer Amp Available

[Dan Rae]

For those of us who aren't scared of surface mount stuff, and maybe even 
prefer it, will there be any bare boards available?


Dan - ac6ao
___
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] Need Time Help

[Jay Grizzard]

On 2016-10-05 10:22 , Jay Grizzard wrote:

Because NTP normally never actually sets you clock to match a server's
clock.   It adjusts the RATE of your clock so the it cruises on the middle
of the pack of vetted servers.


To be nitpicky, it doesn't actually track towards the median, it tracks
towards a weighted average that takes into account the jitter and root
distance of each peer.

To pick a more meaningful nit, though, the above only happens if none of
your peers are set to 'prefer'. If you have a peer set to 'prefer' (and that
peer survives the clustering algorithm), ntp will track that peer and only
that peer. A *lot* of people have a preferred peer set, so this seems worth
mentioning.

(In general I find that as long as my preferred peer is stable, that I get
much better time having it set that way... otherwise, you get frequency shifts
as peers come and go from the set of selected peers. Preferring a single
stable peer gives me a more stable frequency, but I still list plenty of
other peers to allow for sanity checking of the preferred peer.)



Also your modem is likely not causing an asymmetric delay.  That modern
wetter is is the old phone kind or a fiber optic system only takes you to
the fist router.  The modem likely has the same time of flight in both
directions.


On a connection with active downloads, the modem is almost definitely
causing an asymmetric delay. Especially with bufferbloat being so
common these days, all it takes to give hugely asymmetric performance is
to download a file from a site with a faster pipe than you have.

On my cablemodem at home (55Mbit down, 10Mbit up), if I turn off congestion
management (which is a feature in the custom firmware on my router that is
NOT at all standard/common on mainstream hardware), my incoming latency
will jump to something around 1000ms(!) if I download at max bandwidth,
while my outgoing latency hangs out in the single-digit ms range.

(this is, sadly, the norm today)

On a connection that isn't downloading at the full speed of the connection,
though, your assertion is correct. It just needs that very large asterisk
attached to it. ;)

-j


___
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] GPSDO Sigma Tau at large observation times

[Tom Van Baak]

Hello again Estanislao,

Nice set of questions. The short answer is that for a GPSDO,
- The left side of the ADEV plot will show the difference between the quality 
of the local oscillator, in your case TCXO vs. OCXO vs. Rb. 
- The middle of the ADEV plot will show the difference in the choice of 
time-constant or the environmental conditions during the test.
- The right side of the ADEV will show the quality of the GPS timing receiver.

Also,
- The left side of the ADEV plot may expose limitations in your measurement 
equipment or the local low-noise reference that you're using.
- The right side of the ADEV plot may expose limitations in your local 
frequency reference. A cesium or H-maser helps here. If you use one GPSDO to 
test another GPSDO the very right side of the ADEV plot is misleading.

See also the examples here: http://leapsecond.com/pages/gpsdo/

Now, for your specific question:

> My question is, 
> when you are in the second regime, you are basically measuring the 
> ability of each clock to follow each other (is like there is just one 
> clock!, with the worst one setting the Adev value),

Right. For long tau, a GPSDO is not so much an independent clock as just a 
time-transfer system. As such, ADEV is not an ideal or fair statistic. For 
long-term performance consider using TDEV instead or just the 1- or 2-sigma RMS 
of the phase (time) error. This will better reveal how well the PLL is working.

> does then the 
> sigma-tau becomes meaningless for GPSDOs at time scales larger than the 
> TC of the oscillator being locked to GPS?

Yes and no.

Yes -- it is often meaningless because a GPSDO is really just a PLL. ADEV was 
sort of intended to compare clocks. In the long-term the phase error of a PLL 
is bounded by some rms value and so ever longer tau doesn't change how the 
GPSDO works, but ADEV will keep showing a line dropping like a rock at -1 
slope. So ADEV is kind of misleading at this point. Consider using TDEV instead 
of ADEV. Also make sure your frequency reference is better than your GPS 
receiver for the tau you plot. Use low-noise quartz for short-term; use Cesium 
or H-maser for long-term.

No -- it is still meaningful because the ADEV you see out at 10^4 or 10^5 or 
10^6 becomes very much a function of the quality of your GPS timing receiver 
(and antenna and environment, etc). If you were to expand your experiments to 
use half a dozen different GPS timing receivers you would observe a significant 
difference in rms timing noise, all of which translates to the actual ADEV 
value as it crosses, say, tau 10^5 and 10^6 s.

/tvb

- Original Message - 
From: "Estanislao Aguayo" 
To: "Discussion of precise time and frequency measurement" 
Sent: Wednesday, October 05, 2016 8:57 AM
Subject: [time-nuts] GPSDO Sigma Tau at large observation times


> Hello Time-Nuts,
> 
> My name is Tani Aguayo, I'm a newbie in this exciting precision timing 
> world, and so I have lots of questions. So here I go, first, let me 
> describe my experimental set-up for you.  I've been measuring the Adev 
> of several GPSDOs against each other, and once they are locked with a 
> suitable TC, the Adev plots show two regimes of operation (See 
> attached), the first one, at short time scales, has a lot to do with the 
> oscillator being disciplined characteristics, temperature, pressure.. 
> and there is a second one, where the Adev just drops linearly (in a 
> log-log scale). Each oscillator gets to the second regime earlier or 
> later, depending on the GPS PLL TC. In  the attached plot, the TCs of 
> the units compared, have been carefully selected depending on the 
> individual oscillator behavior. My thinking was that once in this second 
> regime, every unit is following the same clock, with the jitter of the 
> worst clock being compared, and since the sigma-tau makes no sense to me 
> for a single clock, I need some help with this concept. My question is, 
> when you are in the second regime, you are basically measuring the 
> ability of each clock to follow each other (is like there is just one 
> clock!, with the worst one setting the Adev value), does then the 
> sigma-tau becomes meaningless for GPSDOs at time scales larger than the 
> TC of the oscillator being locked to GPS?
> 
> I just wanted to thank the active members of this list, I feel like I'm 
> learning a lot with the different discussions and I wanted to say thank you.
> 
> - Tani Aguayo
> 
> 
> 
>





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

[time-nuts] Measure GPSDO stability with minimum resources?

[Bob Stewart]

For my GPSDO, I need to calculate the OCXO aging for holdover projection 
purposes as well as get some figure of merit for the recent past of the OCXO 
stability.  The latter is so that I can determine that the PLL has (or soon 
will have) a good lock.  I'm developing on a dfPIC33FJ128MC802, and I've used 
about 70% of the code space,  I could probably set aside 4K bytes of data space 
for this calculation.  

I have a rather primitive way of doing part of this, but I was hoping someone 
would steer me to something a bit better.

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] Need Time Help

[Mark Spencer]

In practice I'm not convinced the timing requirements for the JT modes in 
question are even more than a single order of magnitude more severe than the 
when I have been timing 15 second sequences on my wrist watch during manual non 
computer aided weak signal operations.  To recap if some one has data or direct 
personal experience to make the case that extreme levels of timing accuracy 
will help I'd be interested in seeing this.

That being said I do believe it makes sense to fully use what ever timing 
resources one has access to.

All the best
Mark S

Sent from my iPhone

> On Oct 5, 2016, at 9:47 AM, Wes  wrote:
> 
> If you are working "real" EME where you, and not a computer plus lookup 
> table, are coping the signals, none of these precise timing issues exist.
> 
> Wes  N7WS
> 
>> On 10/5/2016 6:18 AM, Peter Torry via time-nuts wrote:
>> I must admit to being rather puzzled at the sub microsecond timing 
>> requirement as I use ntp to set the W7 clock in my computer and have not had 
>> any issues. In fact less than one second is OK for the usual two minute 
>> periods that are required to allow for the Faraday rotation. Although I use 
>> a GPSDO for a frequency reference I find JT software reasonably tolerant of 
>> frequency.  As I may be missing something I would welcome observations on 
>> how important the period timing requirement is, you never know I might get 
>> more contacts.
>> 
>> Regards
>> 
>> Peter
>> 
>> 
>>> On 05/10/2016 12:50, Graham / KE9H wrote:
>>> For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
>>> path. Aka, "moonbounce."
>>> 
>>> He is trying to time synchronize a system, where the other station he is
>>> communicating
>>> with can be any other place on the Earth that can also see the Moon.
>>> 
>>> So the system time sync is for a little bit tougher case than a local area
>>> network.
>>> 
>>> --- Graham
> 
> ___
> 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] Need Time Help

[Wes]

If you are working "real" EME where you, and not a computer plus lookup table, 
are coping the signals, none of these precise timing issues exist.


Wes  N7WS

On 10/5/2016 6:18 AM, Peter Torry via time-nuts wrote:
I must admit to being rather puzzled at the sub microsecond timing requirement 
as I use ntp to set the W7 clock in my computer and have not had any issues. 
In fact less than one second is OK for the usual two minute periods that are 
required to allow for the Faraday rotation. Although I use a GPSDO for a 
frequency reference I find JT software reasonably tolerant of frequency.  As I 
may be missing something I would welcome observations on how important the 
period timing requirement is, you never know I might get more contacts.


Regards

Peter


On 05/10/2016 12:50, Graham / KE9H wrote:

For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."

He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.

So the system time sync is for a little bit tougher case than a local area
network.

--- Graham 


___
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] Need Time Help

[Chris Caudle]

On Wed, October 5, 2016 6:14 am, Bob Camp wrote:
> If you buy a GPS receiver and get it set up for timing, just use it.
> Then there is no need for NTP at all.

Is there another way to get computer system time set from a GPS receiver
other than NTP?
In the case that the system clock is controlled by GPSDO and the seconds
delineated by PPS, there should be no need for the NTP clock discipline
code, but I am not aware of any way to inform the NTP daemon that no
disciplining is needed.  Presumably the code should determine that
eventually.

In the case that the system clock is free running, the clock discipline is
still needed, but I found a note in one of the NTP documents (that I can
no longer locate at the moment) that stated something to the effect that
NTP did not run well as it could with a single reference, which would seem
to directly affect the case where a GPS receiver is the only reference. 
That document had only that short note, no details on why or specifics of
behavior.

-- 
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] TNS-BUF Amplifier

[James Robbins]

Many thanks for your helpful TN work to John A. , Dr. Bruce and John M.
Ordered 3 pieces.

 

73,

Jim Robbins

N1JR

___
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] Need Time Help

[Mark Spencer]

Yes I'd be curious in knowing more about this as well.  I've often observed 
time differences from other stations of several tenths of a second when running 
the JT modes on HF.  Although I am beginner at EME I have made a couple of EME 
(earth moon earth) JT65 contacts on VHF without taking any special measures to 
sync the time on a Windows XP machine beyond using the built in features of the 
operating system to sync to my own local time server which was in turned synced 
to the 1 pps output of a GPS timing receiver.

I've also made FSK441 contacts (another related form of amateur radio digital 
communications) in the field without any time reference besides the free 
running clock in my Windows xp laptop.  If there is a significant performance 
improvement to be had with these modes by having time nuts levels of timing 
precision on my computers I'd be very interested to know more.  

All the best 
Mark S

Sent from my iPhone

> On Oct 5, 2016, at 6:18 AM, Peter Torry via time-nuts  
> wrote:
> 
> I must admit to being rather puzzled at the sub microsecond timing 
> requirement as I use ntp to set the W7 clock in my computer and have not had 
> any issues. In fact less than one second is OK for the usual two minute 
> periods that are required to allow for the Faraday rotation. Although I use a 
> GPSDO for a frequency reference I find JT software reasonably tolerant of 
> frequency.  As I may be missing something I would welcome observations on how 
> important the period timing requirement is, you never know I might get more 
> contacts.
> 
> Regards
> 
> Peter
> 
> 
>> On 05/10/2016 12:50, Graham / KE9H wrote:
>> For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
>> path. Aka, "moonbounce."
>> 
>> He is trying to time synchronize a system, where the other station he is
>> communicating
>> with can be any other place on the Earth that can also see the Moon.
>> 
>> So the system time sync is for a little bit tougher case than a local area
>> network.
>> 
>> --- Graham
> 
> ___
> 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] TNS-BUF High Isolation, Low Noise Buffer Amp Available

[John Ackermann N8UR]

I've previously mentioned a high performance buffer amplifier called the 
"TNS-BUF" that I built based on a design by Dr. Bruce Griffiths with 
further input from John Miles. Key numbers are:


*  Phase noise -140dBc/Hz at 1 Hertz offset, noise floor -175dBc/Hz.
   (PN plot attached)
*  Reverse isolation greater than 100dB; low enough that I can't make a
   trustworthy measurement.
*  Gain from -10 to +7 dB from 1 to 30 MHz; maximum output >18dBm.
*  Nominal 18VDC operation, but works down to 12V with lowered
   maximum output level.

There's information, including performance data and schematic, at
http://www.febo.com/pages/TNS-BUF

There seems to be some interest in an amplifier like this, so TAPR has 
decided to do a limited production run.  The amp is built with surface 
mount parts, so we thought an assembled and tested board was better than 
a kit.  The price will be $119 each.  But we have no idea how much 
interest there is, and we need to build a minimum of 25 units to make 
production feasible.


So, here's the deal:  you can order your TNS-BUF at

http://tapr.org/kits_tns-buf

through *October 20*.  If we receive orders for at least 25 boards by 
then, we will charge credit cards and place the production order with 
our contract manufacturer.  If we don't get 25 orders, we'll cancel the 
project and credit cards will not be charged.  There's no guarantee that 
boards will be available for later order.


We expect about 60 days between placing the manufacturing order and 
receipt of the boards at TAPR.  We'll ship to customers ASAP after 
receipt.  So that means you can expect to receive your order shortly 
after January 1.


So, go to http://tapr.org/kits_tns-buf now to place your order before 
the deadline!


John

___
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] Need Time Help

[Peter Torry via time-nuts]

I must admit to being rather puzzled at the sub microsecond timing 
requirement as I use ntp to set the W7 clock in my computer and have not 
had any issues. In fact less than one second is OK for the usual two 
minute periods that are required to allow for the Faraday rotation. 
Although I use a GPSDO for a frequency reference I find JT software 
reasonably tolerant of frequency.  As I may be missing something I would 
welcome observations on how important the period timing requirement is, 
you never know I might get more contacts.


Regards

Peter


On 05/10/2016 12:50, Graham / KE9H wrote:

For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."

He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.

So the system time sync is for a little bit tougher case than a local area
network.

--- Graham




___
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] Need Time Help

[Graham / KE9H]

For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."

He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.

So the system time sync is for a little bit tougher case than a local area
network.

--- Graham

==

On Wed, Oct 5, 2016 at 6:14 AM, Bob Camp  wrote:

> Hi
>
> If you buy a GPS receiver and get it set up for timing …. just use it.
> Then there is no
> need for NTP at all….
>
> Bob
>
> > On Oct 5, 2016, at 12:33 AM, Chris Albertson 
> wrote:
> >
> > On Tue, Oct 4, 2016 at 6:52 PM, Bob Camp  wrote:
> >
> >> Hi
> >>
> >> If:
> >>
> >> 1) You are a typical Ham in a home environment
> >> 2) All the servers are “out there” on the internet
> >> 3) You have any of the normal modems feeding your home
> >>
> >> You have a very basic issue in terms of path delay. All the servers you
> >> can access
> >> have the *same* asymmetric delay. In that case, no matter how many
> servers
> >> you
> >> add to the ensemble, the situation never gets better. You are always
> stuck
> >> with the
> >> (likely unknown) uplink / downlink delay difference of your modem.
> Exactly
> >> what
> >> that number is depends a *lot* on the modern and the system feeding the
> >> modem.
> >> It is *very* possible to see static delay asymmetry well beyond the 5 ms
> >> that the OP is after.
> >> On most systems there is also a dynamic asymmetry that is related to
> >> loading. That
> >> just makes things harder to work out …..
> >>
> >
> > But this is easy to measure, you buy a GPS receiver and use that as an
> 8th
> > or 6th reference clock along with the 5 or 7 Internet servers then you
> look
> > at the difference between GPS and the Internet servers.  The Internet
> > servers do much better than you'd think.  Not as good as GPS but really
> > good.  Why?
> >
> > Because NTP normally never actually sets you clock to match a server's
> > clock.   It adjusts the RATE of your clock so the it cruises on the
> middle
> > of the pack of vetted servers.  It adjusts your clock over a long period
> to
> > it has the benefit of averaging out lots of random behavior.   The result
> > is that you can keep within a few milliseconds of the GPS even with tens
> of
> > millisecond of delay in the communication path.
> >
> > For people new to NTP, the algorithm has it's hands the system clocks
> > "fast/Slow? lever and never normally moves the clocks hands directly
> >
> > And all those Internet servers do NOT have the same asymmetric delay.
> Well
> > they might but that would be a pathological case.  Typically delays
> really
> > are more symmetric than not (one way trip really is 1/2 the round trip)
> > The clocks that don't meet this assumption are found and removed from the
> > pool.   It works because the dells are NOT the same but random  Ans like
> I
> > said, it is easy enough to measure.  You can see that peer offsets are
> all
> > over the map
> >
> > Also your modem is likely not causing an asymmetric delay.  That modern
> > wetter is is the old phone kind or a fiber optic system only takes you to
> > the fist router.  The modern likely has the same time of flight in both
> > directions.   The delay is cause by a queue some place of packets that
> are
> > aggregated from many users.  These are random  but sort of predictable.
> A
> > packet going across a continent or will see more of this then going to a
> > nearby server
> >
> >
> >> Bob
> >>
> >>> On Oct 4, 2016, at 9:05 PM, Chris Albertson  >
> >> wrote:
> >>>
> >>> The problem, I think with your Internet sync's NTP servers is you are
> >> only
> >>> using one server S.  The most common practice is to use 3 to 5 with 5
> >> being
> >>> about the right number.   If you get Ntp enough Internet servers to
> work
> >>> with it can detect problem like asymmetric path lengths which I'm sure
> is
> >>> you problem.
> >>>
> >>> NTP solved the problem that stumped a few people back in the 1970's of
> >> how
> >>> to sync two clocks when there is a long delay and not constant in there
> >>> communications path.  (Of course the problem is simple if the delay is
> >>> known and well measured)  But the solution required the the average
> path
> >>> delay is the same going in each direction.  worse no software can't
> know
> >>> there is an asymmetric delay.  Well not unless it is using a few
> servers.
> >>> NTP basically finds then ignores the "problem servers".
> >>>
> >>> PTP solves the problem by requiring that all the network hardware has
> >>> special time stamp ability that is designed to work with PTP.  This
> >>> hardware is rare unless the user provides it.  So PTP can't really work
> >> on
> >>> the public Internet.
> >>>
> >>> You CAN do very well, to just a few Millisecond using NTP sync'ing to
> >>> Internet servers, but pick 5 of them or even 7.  and 

Re: [time-nuts] ntp and asymmetric delays

[Magnus Danielson]

On 10/05/2016 01:48 PM, Attila Kinali wrote:

On Tue, 4 Oct 2016 18:05:16 -0700
Chris Albertson  wrote:


The problem, I think with your Internet sync's NTP servers is you are only
using one server S.  The most common practice is to use 3 to 5 with 5 being
about the right number.   If you get Ntp enough Internet servers to work
with it can detect problem like asymmetric path lengths which I'm sure is
you problem.


No they are correctly configured with 3 and 5 servers respectively.
I singled out server S out, because i didn't want to clutter the argument
with too many numbers and because S is common to both machines A and B
and because it's very close in internet terms (with 4.5ms and 2ms respectively).

The full view of A is (the last line is B):

 remote   refid  st t when poll reach   delay   offset  jitter
==
+162.23.41.55.MRS.1 u  357 1024  3774.5550.198   0.293
*162.23.41.10.MRS.1 u  318 1024  3774.403   -0.040   0.123
-131.188.3.223   .PZF.1 u  548 1024  3779.524   -0.654   0.039
+2001:67c:8:abcd .GPS1.   1 u   74 1024  373   12.1630.143   0.168
-81.94.123.1785.158.25.74 2 u  297 1024  3770.985   -0.798   0.158
-2a02:418:f022:: 162.23.41.10 2 u  792 1024  3770.649   -0.727   2.120

And the full view of B is:
 remote   refid  st t when poll reach   delay   offset  jitter
==
*162.23.41.10.MRS.1 u  175 1024  3772.067   -0.033   0.069
+195.186.1.101   195.186.150.242  2 u  504 1024  3771.317   -0.360   0.086
+130.60.204.10   130.60.159.7 4 u  901 1024  3771.5390.932   2.065


Note: 162.23.41.10 (the server S) is one of the three NTP servers run by METAS
and fed by the official PPS of Switzerland.


And no, NTP cannot detect asymmetric network delays. They are completely
indisdinguishable from clock offsets. One can easily show that the
uncertainty in the network delay symmetry is the fundamental accuracy
limit of NTP. As the asymmetry is in general unbounded, the only guarantee
you have is that you are at most off by the RTT (aka delay) of the reference.
(given the reference itself is accurate)


It is trivial to show that any two-way time-transfer mechanism, be it 
NTP, PTP, TWTFST, DTM TT or whatever, cannot unaided separate Time Error 
between two clocks from that of the asymmetry between them. The Round 
Trip Time (RTT) is however guaranteed unbiased under the assumption of 
no (major) frequency difference. PTP adds means by which intermediate 
nodes can provide delay estimations and thus allow cancellation of delay 
in those equipments, but it does not help for asymmetry in path, such as 
different fiber-lengths. Such delays needs to be calibrated.


With lots of observations you can however draw some conclusions of 
likely cause of offsets, but without aiding through calibration, you 
cannot draw a strict conclusion.



You CAN do very well, to just a few Millisecond using NTP sync'ing to
Internet servers, but pick 5 of them or even 7.  and make sure they are
dispersed and not all at the same place.


You want to have them (time wise) as close as possible. Having many servers
does not help as much as having one accurate close by. Actually, once you
have a very close stratum 1, any additional server will _degrade_ the
accuracy of NTP as NTP cannot know which of it's reference servers is
accurate or not (unless specifically configured).


In this case the correct answer to this "problem" would be to set up a
stratum 1 server in either of the colo centers and synchornize to that.
And if i had the hardware, I would do that. But then, being off by only 1ms
is not that bad for an internet facing ntp server where most of the clients
will be on ADSL/VDSL lines which exhibit some 10ms of delay.


Indeed. Asymmetry can build up in places where you do not expect it.
Most systems isn't designed for symmetric delay. Many works fairly 
decent (at low load), but you never know and it's hard to tell.


Cheers,
Magnus
___
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] ntp and asymmetric delays (was: Need Time Help)

[Attila Kinali]

On Tue, 4 Oct 2016 18:05:16 -0700
Chris Albertson  wrote:

> The problem, I think with your Internet sync's NTP servers is you are only
> using one server S.  The most common practice is to use 3 to 5 with 5 being
> about the right number.   If you get Ntp enough Internet servers to work
> with it can detect problem like asymmetric path lengths which I'm sure is
> you problem.

No they are correctly configured with 3 and 5 servers respectively.
I singled out server S out, because i didn't want to clutter the argument
with too many numbers and because S is common to both machines A and B
and because it's very close in internet terms (with 4.5ms and 2ms respectively).

The full view of A is (the last line is B):

 remote   refid  st t when poll reach   delay   offset  jitter
==
+162.23.41.55.MRS.1 u  357 1024  3774.5550.198   0.293
*162.23.41.10.MRS.1 u  318 1024  3774.403   -0.040   0.123
-131.188.3.223   .PZF.1 u  548 1024  3779.524   -0.654   0.039
+2001:67c:8:abcd .GPS1.   1 u   74 1024  373   12.1630.143   0.168
-81.94.123.1785.158.25.74 2 u  297 1024  3770.985   -0.798   0.158
-2a02:418:f022:: 162.23.41.10 2 u  792 1024  3770.649   -0.727   2.120

And the full view of B is:
 remote   refid  st t when poll reach   delay   offset  jitter
==
*162.23.41.10.MRS.1 u  175 1024  3772.067   -0.033   0.069
+195.186.1.101   195.186.150.242  2 u  504 1024  3771.317   -0.360   0.086
+130.60.204.10   130.60.159.7 4 u  901 1024  3771.5390.932   2.065


Note: 162.23.41.10 (the server S) is one of the three NTP servers run by METAS
and fed by the official PPS of Switzerland. 


And no, NTP cannot detect asymmetric network delays. They are completely
indisdinguishable from clock offsets. One can easily show that the
uncertainty in the network delay symmetry is the fundamental accuracy
limit of NTP. As the asymmetry is in general unbounded, the only guarantee
you have is that you are at most off by the RTT (aka delay) of the reference.
(given the reference itself is accurate)

> You CAN do very well, to just a few Millisecond using NTP sync'ing to
> Internet servers, but pick 5 of them or even 7.  and make sure they are
> dispersed and not all at the same place.

You want to have them (time wise) as close as possible. Having many servers
does not help as much as having one accurate close by. Actually, once you
have a very close stratum 1, any additional server will _degrade_ the
accuracy of NTP as NTP cannot know which of it's reference servers is
accurate or not (unless specifically configured).


In this case the correct answer to this "problem" would be to set up a
stratum 1 server in either of the colo centers and synchornize to that.
And if i had the hardware, I would do that. But then, being off by only 1ms
is not that bad for an internet facing ntp server where most of the clients
will be on ADSL/VDSL lines which exhibit some 10ms of delay.

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] Need Time Help

[Bob Camp]

Hi

If you buy a GPS receiver and get it set up for timing …. just use it. Then 
there is no
need for NTP at all….

Bob

> On Oct 5, 2016, at 12:33 AM, Chris Albertson  
> wrote:
> 
> On Tue, Oct 4, 2016 at 6:52 PM, Bob Camp  wrote:
> 
>> Hi
>> 
>> If:
>> 
>> 1) You are a typical Ham in a home environment
>> 2) All the servers are “out there” on the internet
>> 3) You have any of the normal modems feeding your home
>> 
>> You have a very basic issue in terms of path delay. All the servers you
>> can access
>> have the *same* asymmetric delay. In that case, no matter how many servers
>> you
>> add to the ensemble, the situation never gets better. You are always stuck
>> with the
>> (likely unknown) uplink / downlink delay difference of your modem. Exactly
>> what
>> that number is depends a *lot* on the modern and the system feeding the
>> modem.
>> It is *very* possible to see static delay asymmetry well beyond the 5 ms
>> that the OP is after.
>> On most systems there is also a dynamic asymmetry that is related to
>> loading. That
>> just makes things harder to work out …..
>> 
> 
> But this is easy to measure, you buy a GPS receiver and use that as an 8th
> or 6th reference clock along with the 5 or 7 Internet servers then you look
> at the difference between GPS and the Internet servers.  The Internet
> servers do much better than you'd think.  Not as good as GPS but really
> good.  Why?
> 
> Because NTP normally never actually sets you clock to match a server's
> clock.   It adjusts the RATE of your clock so the it cruises on the middle
> of the pack of vetted servers.  It adjusts your clock over a long period to
> it has the benefit of averaging out lots of random behavior.   The result
> is that you can keep within a few milliseconds of the GPS even with tens of
> millisecond of delay in the communication path.
> 
> For people new to NTP, the algorithm has it's hands the system clocks
> "fast/Slow? lever and never normally moves the clocks hands directly
> 
> And all those Internet servers do NOT have the same asymmetric delay.  Well
> they might but that would be a pathological case.  Typically delays really
> are more symmetric than not (one way trip really is 1/2 the round trip)
> The clocks that don't meet this assumption are found and removed from the
> pool.   It works because the dells are NOT the same but random  Ans like I
> said, it is easy enough to measure.  You can see that peer offsets are all
> over the map
> 
> Also your modem is likely not causing an asymmetric delay.  That modern
> wetter is is the old phone kind or a fiber optic system only takes you to
> the fist router.  The modern likely has the same time of flight in both
> directions.   The delay is cause by a queue some place of packets that are
> aggregated from many users.  These are random  but sort of predictable.  A
> packet going across a continent or will see more of this then going to a
> nearby server
> 
> 
>> Bob
>> 
>>> On Oct 4, 2016, at 9:05 PM, Chris Albertson 
>> wrote:
>>> 
>>> The problem, I think with your Internet sync's NTP servers is you are
>> only
>>> using one server S.  The most common practice is to use 3 to 5 with 5
>> being
>>> about the right number.   If you get Ntp enough Internet servers to work
>>> with it can detect problem like asymmetric path lengths which I'm sure is
>>> you problem.
>>> 
>>> NTP solved the problem that stumped a few people back in the 1970's of
>> how
>>> to sync two clocks when there is a long delay and not constant in there
>>> communications path.  (Of course the problem is simple if the delay is
>>> known and well measured)  But the solution required the the average path
>>> delay is the same going in each direction.  worse no software can't know
>>> there is an asymmetric delay.  Well not unless it is using a few servers.
>>> NTP basically finds then ignores the "problem servers".
>>> 
>>> PTP solves the problem by requiring that all the network hardware has
>>> special time stamp ability that is designed to work with PTP.  This
>>> hardware is rare unless the user provides it.  So PTP can't really work
>> on
>>> the public Internet.
>>> 
>>> You CAN do very well, to just a few Millisecond using NTP sync'ing to
>>> Internet servers, but pick 5 of them or even 7.  and make sure they are
>>> dispersed and not all at the same place.
>>> 
>>> On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali  wrote:
>>> 
 On Tue, 4 Oct 2016 15:41:58 +1100
 Larry Hower  wrote:
 
> Ultimately we want sub-millisecond accuracy.
 
 If you want to go that way, you will have to leave windows as
 this operating system does not offer the facilities to get down
 to such a low levelUnless you calibrate the whole path by injecting
 a time pulse into the signal path like Jim Lux and TvB suggested
 
 With linux you can get systems synchronized to better 

Re: [time-nuts] Roughtime

[Hal Murray]

albertson.ch...@gmail.com said:
> But I use a set of five different servers all controlled by different
> organizations and they are geographically distributed.   Also some of these
> are randomly elected "pool" servers.  So even I don't know who I will ask
> for time.   How could anyone corrupt all those servers? 

They don't have to corrupt the servers if they can capture some 
modem/router/whatever box that all of your packets go through.  Classic 
man-in-the-middle.


> And if this ever did become a problem users would simply start using
> cryptographic authentication 

It's a problem now.  Currently, there is no convenient way to do the crypto.  
That's why Roughtime appeared.

When the software is available, somebody will need to set up a collection of 
well run NTP servers.  It's roughly similar to the top level DNS servers.


albertson.ch...@gmail.com said:
> All that said, there is money to be made  by spoofing time.   If I can fool
> a stock broker into accepting trades minutes late I could be rich. 

I think most stock brokers have their own GPS/NTP servers.


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