Re: [time-nuts] PPS sync

[Hal Murray]

je...@hanler.com said:
> It’s interesting how it jumps around from PPS to PPS.  

You can work out what the offset will look like.

Assume your clock is roughly 10 MHz.  So you divide by 10,000,000 to get a 
PPS.  If your clock is 2.001 HZ fast, then you need to divide by 10,000,002.  
That gets close, but it will drift by 0.001 HZ or 1 ms per second.  So every 
1000 seconds you will have to skip an extra cycle.

If you plot the offset, you get a ramp going down.  If your clock is 
10,000,001.999 you get a ramp going up.  (I hope I got the sign right.)

It gets more complicated if your clock is not near an integral number of 
cycles/second.  Suppose it is 10,000,002.501.  Now you have to skip an extra 
cycle every other second.  You get 2 lines offset by a half-second.

That all assumes you have a good GPS antenna and such so that there isn't 
much noise/jitter on the calculated time.

If the temperature on your crystal is changing, you can get hanging bridges.

Neat graphs here:
  http://www.leapsecond.com/pages/m12/sawtooth.htm


-- 
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] PPS sync

[Jerry Hancock]

That makes complete sense, it’s not disciplining anything, just pumping out the 
PPS and reporting the variance.  I don’t know why I didn’t think of it.

It’s interesting how it jumps around from PPS to PPS. 

Thank you,

Jerry


> On Jun 7, 2017, at 2:57 AM, Hal Murray  wrote:
> 
> 
> je...@hanler.com said:
>> Chris, I think you are onto something.  Running Lady Heather on this unit I
>> see a line under “receiver” with the term “SawT” and a parameter of 24ns.
>> So if we combine this information with what you teach below, it’s starting
>> to look like maybe the M12 unit is doing something different than the
>> Lucent.
> 
> The M12 is a timing receiver.  The Lucent is a GPSDO.
> 
> The Lucent will adjust the osc so it runs at 10 MHz and the phase is such 
> that the PPS lines up with UTC.
> 
> The M12 tells you the offset rather then adjusting the osc so the offset is 0.
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] PPS sync

[Hal Murray]

je...@hanler.com said:
> Chris, I think you are onto something.  Running Lady Heather on this unit I
> see a line under “receiver” with the term “SawT” and a parameter of 
> 24ns.
> So if we combine this information with what you teach below, it’s starting
> to look like maybe the M12 unit is doing something different than the
> Lucent.

The M12 is a timing receiver.  The Lucent is a GPSDO.

The Lucent will adjust the osc so it runs at 10 MHz and the phase is such 
that the PPS lines up with UTC.

The M12 tells you the offset rather then adjusting the osc so the offset is 0.



-- 
These are my opinions.  I hate spam.



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

[time-nuts] PPS sync

[Mark Sims]

Yes, that is the sawtooth correction parameter.  If a receiver reports the 
sawtooth correction value, but not a GPSDO EFC dac setting,  Heather plots the 
sawtooth value as the GD plot and shows it where the DAC value is normally 
shown.

Sawtooth values are seldom simple ramps.   They represent the difference 
between the GPS PPS signal and (usually) the GPS CPU clock.   They have all 
sorts of interesting structure to them (like the infamous "hanging bridges") 
The magnitude of the sawtooth range depends upon the GPS CPU.  Older devices 
may have a +/- 30 ns range and newer ones like the Venus timing receivers are 
in the +/- 6 ns range.

A GPSDO usually derives its PPS output by dividing the 10 MHz OCXO output down. 
  The GPSDO control loop removes the sawtooth error.   A good GPSDO takes 
advantage of the sawtooth correction message from the receiver to minimize the 
effects of the sawtooth error on  the control loop.   The Thunderbolt locks the 
GPS receiver clocks to the 10 MHz OCXO and does not have any sawtooth error to 
compensate for.

---

> Mark Sims, can you comment on the SawT parameter, I assumed being reported by 
> the M12 GPS, displayed on Lady Heather?
___
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] PPS sync

[Jerry Hancock]

Chris, I think you are onto something.  Running Lady Heather on this unit I see 
a line under “receiver” with the term “SawT” and a parameter of 24ns.  So if we 
combine this information with what you teach below, it’s starting to look like 
maybe the M12 unit is doing something different than the Lucent.  I am watching 
it today and I see 5 PPS that vary from the lucent pulse (used as a trigger) 
each about +20ns until it resets. 

Mark Sims, can you comment on the SawT parameter, I assumed being reported by 
the M12 GPS, displayed on Lady Heather?

Thanks 


> On Jun 5, 2017, at 10:15 AM, Chris Albertson  
> wrote:
> 
> I did not finish the sawtooth explanation.  One of the units is designed
> such that the PPS is always on the raising edge of an internal 10MHz clock.
>   If the 10MHz clock were perfect this means the maximum error is 1/2
> cycle.   The software in the GPS choose site best edge to minimize error.
> the jump you see it when it selects a different cycle and jumpsThe
> software tracks the error and outputs an estimate of the root on the serial
> channel.
> 
> You can verify this by plotting the sawtooth correction vs.time and see
> that it lines up with your observation of the jump back to zero error.
> 
> There might still be errors cause by other things, like improper self
> survey but the results you reported are exactly like what one would expect
> from a unit that uses an oscillator edge to trigger PPS.  It other words
> what you see is a design feature not an error.
> 
> On Mon, Jun 5, 2017 at 6:40 AM, Jerry Hancock  wrote:
> 
>> It was off 7.5KM, that’s a little beyond groggy, no?  More like a trip to
>> Vegas.
>> 
>> I’ll let it rerun the survey and see if it gets closer.
>> 
>>> On Jun 4, 2017, at 9:50 PM, Mark Sims  wrote:
>>> 
>>> Be careful when using one unit's location to set a different model's
>> location...  particularly the altitude.   Some devices report altitude in
>> MSL, others in AGL... and different units may use different models for the
>> ellipsoid.   You are always better off using coordinates generated by the
>> particular device (either the built-in self survey or something like Lady
>> Heather's precision survey).
>>> 
>>> I did some tests while developing Lady Heather's precision survey code.
>> I got pretty consistent lat/lon/alt results on the same units but
>> consistent offsets between different models of receivers.
>>> 
>>> I would suggest letting the Motorola re-surevy itself...  it may have
>> been a bit groggy after first being powered up after a few years of
>> sleep... I know I am...
>>> 
>>> ---
>>> 
 I then set the M12 reference location to the Lucent location as I know
>> it to be correct.
>>> ___
>>> 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.
>> 
> 
> 
> 
> -- 
> 
> 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.

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

[Chris Albertson]

I did not finish the sawtooth explanation.  One of the units is designed
such that the PPS is always on the raising edge of an internal 10MHz clock.
   If the 10MHz clock were perfect this means the maximum error is 1/2
cycle.   The software in the GPS choose site best edge to minimize error.
 the jump you see it when it selects a different cycle and jumpsThe
software tracks the error and outputs an estimate of the root on the serial
channel.

You can verify this by plotting the sawtooth correction vs.time and see
that it lines up with your observation of the jump back to zero error.

There might still be errors cause by other things, like improper self
survey but the results you reported are exactly like what one would expect
from a unit that uses an oscillator edge to trigger PPS.  It other words
what you see is a design feature not an error.

On Mon, Jun 5, 2017 at 6:40 AM, Jerry Hancock  wrote:

> It was off 7.5KM, that’s a little beyond groggy, no?  More like a trip to
> Vegas.
>
> I’ll let it rerun the survey and see if it gets closer.
>
> > On Jun 4, 2017, at 9:50 PM, Mark Sims  wrote:
> >
> > Be careful when using one unit's location to set a different model's
> location...  particularly the altitude.   Some devices report altitude in
> MSL, others in AGL... and different units may use different models for the
> ellipsoid.   You are always better off using coordinates generated by the
> particular device (either the built-in self survey or something like Lady
> Heather's precision survey).
> >
> > I did some tests while developing Lady Heather's precision survey code.
>  I got pretty consistent lat/lon/alt results on the same units but
> consistent offsets between different models of receivers.
> >
> > I would suggest letting the Motorola re-surevy itself...  it may have
> been a bit groggy after first being powered up after a few years of
> sleep... I know I am...
> >
> > ---
> >
> >> I then set the M12 reference location to the Lucent location as I know
> it to be correct.
> > ___
> > 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.
>



-- 

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] PPS sync

[Jerry Hancock]

It was off 7.5KM, that’s a little beyond groggy, no?  More like a trip to Vegas.

I’ll let it rerun the survey and see if it gets closer.

> On Jun 4, 2017, at 9:50 PM, Mark Sims  wrote:
> 
> Be careful when using one unit's location to set a different model's 
> location...  particularly the altitude.   Some devices report altitude in 
> MSL, others in AGL... and different units may use different models for the 
> ellipsoid.   You are always better off using coordinates generated by the 
> particular device (either the built-in self survey or something like Lady 
> Heather's precision survey).
> 
> I did some tests while developing Lady Heather's precision survey code.   I 
> got pretty consistent lat/lon/alt results on the same units but consistent 
> offsets between different models of receivers.
> 
> I would suggest letting the Motorola re-surevy itself...  it may have been a 
> bit groggy after first being powered up after a few years of sleep... I know 
> I am...
> 
> ---
> 
>> I then set the M12 reference location to the Lucent location as I know it to 
>> be correct.
> ___
> 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] PPS sync

[Mark Sims]

Be careful when using one unit's location to set a different model's 
location...  particularly the altitude.   Some devices report altitude in MSL, 
others in AGL... and different units may use different models for the 
ellipsoid.   You are always better off using coordinates generated by the 
particular device (either the built-in self survey or something like Lady 
Heather's precision survey).

I did some tests while developing Lady Heather's precision survey code.   I got 
pretty consistent lat/lon/alt results on the same units but consistent offsets 
between different models of receivers.

I would suggest letting the Motorola re-surevy itself...  it may have been a 
bit groggy after first being powered up after a few years of sleep... I know I 
am...

---

> I then set the M12 reference location to the Lucent location as I know it to 
> be correct.
___
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] PPS sync

[Chris Albertson]

One of the GPS units is likely sending a saw-tooth message out the serial
line that exactly describes the 0 to 100ns drift.   This is why they call
it "saw tooth" the function ramps up slowly then falls to zero.  A device
like a GPSDO that uses the PPS would need access to the serial data to read
the sawtooth correction,

On Sun, Jun 4, 2017 at 9:36 PM, Jerry Hancock  wrote:

> 1) I have my TAPR M12 Kit working now next to my lucent RFTG-U REF0/1
> pair.  I was comparing the PPS outputs triggering on the Lucent as channel
> 1 and the M12 as channel 2.  I can’t tell which is moving around but the
> symptoms are that at T0 (not the top of the minute or hour) they are in
> sync within a nanosecond.  From T1 to T20 they move progressively out of
> sync until hitting around 100ns and then snapping back to being in sync. I
> would think that if both were moving that it wouldn’t be that consistent,
> no?
>
> Since I can’t tell which is moving, most likely both,  I plan to take the
> disciplined 10Mhz out of the Lucent and divide it down with my TAPR TADD-2
> to 1PPS.  I would think that would be more stable on a PPS by PPS basis and
> compare again.
>
> Any other ideas?
>
> 2)  When I first fired up the M12 and let it do a survey, it was off for
> some reason by 7KM.  I then set the M12 reference location to the Lucent
> location as I know it to be correct.  I was thinking though, would the PPS
> phase comparison in 1, above, be impacted by the reference locations being
> off?  Both GPS cables are the same length.  The only thing I don’t know is
> the internal processing delay of the units.  The SynTac software allows you
> to take this into consideration for PPS timing when using the M12.
> Interesting unit by the way.  Lots of configuration options exposed with
> the Syntac software.  Not that I would replace Lady Heather or anything,
> I’m just using it while I get some of these issues figured out.
>
> Jerry
> ___
> 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.

[time-nuts] PPS sync

[Jerry Hancock]

1) I have my TAPR M12 Kit working now next to my lucent RFTG-U REF0/1 pair.  I 
was comparing the PPS outputs triggering on the Lucent as channel 1 and the M12 
as channel 2.  I can’t tell which is moving around but the symptoms are that at 
T0 (not the top of the minute or hour) they are in sync within a nanosecond.  
From T1 to T20 they move progressively out of sync until hitting around 100ns 
and then snapping back to being in sync. I would think that if both were moving 
that it wouldn’t be that consistent, no?

Since I can’t tell which is moving, most likely both,  I plan to take the 
disciplined 10Mhz out of the Lucent and divide it down with my TAPR TADD-2 to 
1PPS.  I would think that would be more stable on a PPS by PPS basis and 
compare again. 

Any other ideas?

2)  When I first fired up the M12 and let it do a survey, it was off for some 
reason by 7KM.  I then set the M12 reference location to the Lucent location as 
I know it to be correct.  I was thinking though, would the PPS phase comparison 
in 1, above, be impacted by the reference locations being off?  Both GPS cables 
are the same length.  The only thing I don’t know is the internal processing 
delay of the units.  The SynTac software allows you to take this into 
consideration for PPS timing when using the M12.  Interesting unit by the way.  
Lots of configuration options exposed with the Syntac software.  Not that I 
would replace Lady Heather or anything, I’m just using it while I get some of 
these issues figured out.

Jerry
___
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] PPS sync from NTP

[Steve Rooke]

I was thinking about what has been recently discussed about the
possibility of measuring frequency via time-stamping samples
referenced to NTP and crunching the numbers. On a different vein, it
would be possible to make a PC output PPS from the internal clock
synchronised to NTP. OK, all the existing arguments about the accuracy
and stability of this still exist but it should then be possible to
sync a ocxo with this PPS to make a frequency standard suitable for a
number of uses, although not up to TN standards, agreed

73,
Steve ZL3TUV
-- 
Steve Rooke - ZL3TUV  G8KVD
Omnium finis imminet

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