Re: [time-nuts] Holdover: Z3801A vs KS-24361

[Bob kb8tq]

Hi

There isn’t much you can really see on a GPSDO comparing it to a normal OCXO. 
The OCXO simply is not accurate enough. You need something like a Cs standard,
a different GPSDO, or a good Rb for the reference. (Yes, if you have a hydrogen 
maser, you *can* use that ….). 

First thing to check is the DAC readings on the unit ….

Bob

> On Apr 15, 2018, at 6:59 AM, Hal Murray  wrote:
> 
> 
> kb...@n1k.org said:
>>> A  KS-24361 says:
>>> Predict  394.1 us/initial 24 hrs
>> That would suggest the unit is unlocked. It should be below 10 us. Just as
>> with the 3801, the estimate is a bit fuzzy. You should be able to see issues
>> in the data on the Z3809/Z3810. 
> 
> It says it is locked and has been locked for days.
>>> Locked to GPS  TFOM 3  FFOM 0
> 
> I used this as a learning exercise for my new TICC.  Something is clearly 
> fishy.
> 
> The reference for the TICC is the crystal in a HP 5334B with the good-crystal 
> option.  It's not calibrated, but there isn't any GPS logic to jerk it 
> around.  I assume the swing is due to temperature.  I corrected the slope of 
> the graph by hand.
> 
> Here is a day+ of data:
>  http://users.megapathdsl.net/~hmurray/time-nuts/TICC/TICC-KS.png
> 
> Here is a zoomed in chunk:
>  http://users.megapathdsl.net/~hmurray/time-nuts/TICC/TICC-KS-2.png
> 
> 
> -- 
> 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] Holdover: Z3801A vs KS-24361

[Hal Murray]

kb...@n1k.org said:
>> A  KS-24361 says:
>>  Predict  394.1 us/initial 24 hrs
> That would suggest the unit is unlocked. It should be below 10 us. Just as
> with the 3801, the estimate is a bit fuzzy. You should be able to see issues
> in the data on the Z3809/Z3810. 

It says it is locked and has been locked for days.
  >> Locked to GPS  TFOM 3  FFOM 0

I used this as a learning exercise for my new TICC.  Something is clearly 
fishy.

The reference for the TICC is the crystal in a HP 5334B with the good-crystal 
option.  It's not calibrated, but there isn't any GPS logic to jerk it 
around.  I assume the swing is due to temperature.  I corrected the slope of 
the graph by hand.

Here is a day+ of data:
  http://users.megapathdsl.net/~hmurray/time-nuts/TICC/TICC-KS.png

Here is a zoomed in chunk:
  http://users.megapathdsl.net/~hmurray/time-nuts/TICC/TICC-KS-2.png


-- 
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] Holdover: Z3801A vs KS-24361

[Mark Sims]

SS is signal strength.  CN is carrier to noise ratio.   They basically indicate 
the same thing, but their scale may be different.   You can't compare the 
absolute magnitude of the values from different types  of receivers,  only do 
relative comparisons.   Other receivers can report dBc, etc.  And Trimble 
devices can report AMU (amplitude measurement units).  Some Trimble devices 
don't support dBc readings.  By switching a Tbolt between AMU and dBc, I worked 
out a table that Lady Heather uses to convert AMU to dBc to that those devices 
can display the more common dBc values.  On the Trimble devices you set the 
signal level mask in AMUs.

---

> the Satellite Status area has a header of SS on the Z3801A and C/N on  the KS
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover: Z3801A vs KS-24361

[Bob kb8tq]

Hi



> On Apr 12, 2018, at 1:30 AM, Hal Murray  wrote:
> 
> On that Status page, A Z3801A says:
>  Predict  2.5 us/initial 24 hrs

That sounds about right for a 3801. The prediction is something better than
a wild guess and not what one would call a solid number.


> 
> A  KS-24361 says:
>  Predict  394.1 us/initial 24 hrs

That would suggest the unit is unlocked. It should be below 10 us. Just as with
the 3801, the estimate is a bit fuzzy. You should be able to see issues in the 
data
on the Z3809/Z3810.

 A prediction of < 1 can pop up on occasion, on either unit. More typical 
estimates
are in the “couple of us” range. If you yank the antenna, it still does a 
respectable 
~5 us / 24 hrs or so either way. 

> 
> Both have been running for weeks.
> 
> Is anybody seeing similar?

no

> 
> 
> Also, the Satellite Status area has a header of SS on the Z3801A and C/N on 
> the KS.  Does anybody know the units and/or what that is actually measuring?

There are tables that translate the Motorola (and some of the other brands) 
status 
numbers into rough dbc/ Hz. I would not count on the numbers on a 20+ year old
design lining up directly with the latest and greatest modern module. 
Apparently 
the SNR calculations are a bit weird.

Bob

> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

[time-nuts] Holdover: Z3801A vs KS-24361

[Hal Murray]

On that Status page, A Z3801A says:
  Predict  2.5 us/initial 24 hrs

A  KS-24361 says:
  Predict  394.1 us/initial 24 hrs

Both have been running for weeks.

Is anybody seeing similar?


Also, the Satellite Status area has a header of SS on the Z3801A and C/N on 
the KS.  Does anybody know the units and/or what that is actually measuring?

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

[Attila Kinali]

Hoi Leo,

On Thu, 2 Nov 2017 21:45:56 +
Leo Bodnar  wrote:

> I suspect delta-sigma body of knowledge can be applied almost wholesale to 
> this seemingly silly oscillator concept. 
> Did I just repeat something trivial that has been discussed to death here 
> before? 

Trivial? Yes. Well known? No. I know too many engineers who treat
delta-sigma modulators as kind of black magic and don't even want
to touch them. Yes, the math behind it is a bit intricate. There are
things that we cannot even calculate (only simulate), but a second
order D-S modulator will get you quite far and is easy to do.

If anyone wants reading material on that topic, let me know.

Attila Kinali

-- 
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering.  -- The Doctor
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Bob kb8tq]

Hi

I believe you indeed have tied this back to a number of papers ….

Bob

> On Nov 2, 2017, at 5:45 PM, Leo Bodnar <l...@leobodnar.com> wrote:
> 
> This is, essentially, how modern delta-sigma DACs work while achieving 24-bit 
> and higher precision using only a single bit converter internally and a lot 
> of clever digital filtering.
> Multiple loops are what would be called "higher order" in delta-sigma 
> parlance.
> Delta-sigma tech is not poor man's DAC - it has properties that other 
> conversion methods can't achieve, e.g. noise shaping and trivial aliases 
> rejection.
> I suspect delta-sigma body of knowledge can be applied almost wholesale to 
> this seemingly silly oscillator concept. 
> Did I just repeat something trivial that has been discussed to death here 
> before? 
> Leo
> 
>> From: Bob kb8tq <kb...@n1k.org>
>> Subject: Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source
>> There’s no particular reason to stop at the 100:1 point. You can run 
>> multiple 
>> loops at the same time and get out to essentially any level of precision. The
>> only question is over what averaging interval the precision applies.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Leo Bodnar]

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

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

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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Bob kb8tq]

Hi

There’s no particular reason to stop at the 100:1 point. You can run multiple 
loops at the same time and get out to essentially any level of precision. The
only question is over what averaging interval the precision applies. In some 
cases this elastic definition does just fine. 

Bob

> On Nov 2, 2017, at 3:32 PM, Tom Van Baak  wrote:
> 
>>> The DS3231 has an 8 bit register that will change its frequency in
>>> increments of about 0.1ppm. Thus you could discipline it to get its pps
>>> aligned with your reference.
>> 
>> That sounds like you just designed the worst GPSDO ever.
> 
> You could argue that the worst GPSDO ever is an operating system running NTP 
> ;-) A PC running NTP at +/- 10 us is a thousand times worse in time accuracy 
> and a million times worse in frequency stability than a TBolt GPSDO.
> 
> But back to the DS3231. If the 0.1 ppm increment sounds too coarse to you, 
> then just step between N-1 / N / N+1, similar to how PWM works. Don't laugh. 
> Some microcontrollers also have programmable oscillator tuning and I tested 
> this on a PIC -- microstepping 100 times a second -- as part of my "best 
> worst GPSDO" project.
> 
> http://leapsecond.com/pic/src/pg41.asm
> 
> /tvb
> 
> ___
> 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] Holdover, RTC for Pi as NTP GPS source

[Tom Van Baak]

>> The DS3231 has an 8 bit register that will change its frequency in
>> increments of about 0.1ppm. Thus you could discipline it to get its pps
>> aligned with your reference.
> 
> That sounds like you just designed the worst GPSDO ever.

You could argue that the worst GPSDO ever is an operating system running NTP 
;-) A PC running NTP at +/- 10 us is a thousand times worse in time accuracy 
and a million times worse in frequency stability than a TBolt GPSDO.

But back to the DS3231. If the 0.1 ppm increment sounds too coarse to you, then 
just step between N-1 / N / N+1, similar to how PWM works. Don't laugh. Some 
microcontrollers also have programmable oscillator tuning and I tested this on 
a PIC -- microstepping 100 times a second -- as part of my "best worst GPSDO" 
project.

http://leapsecond.com/pic/src/pg41.asm

/tvb

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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Jim Harman]

On Thu, Nov 2, 2017 at 9:04 AM, Chris Caudle  wrote:

>
>
> That sounds like you just designed the worst GPSDO ever.
>
> --
> Chris Caudle
>
> Yes but the price and power consumption are right. I guess it all depends
on your application...
-- 

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

[Chris Caudle]

On Wed, November 1, 2017 7:16 pm, Jim Harman wrote:
> The DS3231 has an 8 bit register that will change its frequency in
> increments of about 0.1ppm. Thus you could discipline it to get its pps
> aligned with your reference.

That sounds like you just designed the worst GPSDO ever.

-- 
Chris Caudle


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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Chris Caudle]

On Thu, November 2, 2017 5:19 am, Hal Murray wrote:
> I'd let the RTC free run, feed its PPS to a "clock" program, and then feed
> the offset to ntpd via SHM.

I would just get a GPS that doesn't shut off the PPS when it loses lock
and that has a decent TCXO for the clock.  Or just use a rubidium and call
it close enough.

-- 
Chris Caudle


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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Hal Murray]

mlewis...@rogers.com said:
> - GPS module's secondary PPS disciplining the RTC-counter-divider PPS by
> resetting the RTC's counter/divider (I'm assuming there's one that will
> rest fast enough to sync; I've never looked into these...) 

How many RTCs accept an external PPS?

Your plan sounds complicated.

  If the external PPS comes in roughly the middle of the
  RTC second, how does the RTC decide whether to go
  forward or backwards?

  Does your GPS disable its PPS when it isn't locked?  If not, you need 
additional logic to mask it so the RTC doesn't track a drifting GPS.

I'd let the RTC free run, feed its PPS to a "clock" program, and then feed 
the offset to ntpd via SHM.




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

[Hal Murray]

tpie...@gmail.com said:
> Forget about accurate time from the RTC's registers.  The slowness and
> variably in I2C is quite poor and most of them don't even have sub-second
> resolution when read or written. 

If your RTC has a PPS output, you can read the registers to get the coarse 
time, then wait for the PPS to tick to get the low order bits.


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

[Trent Piepho]

Some of the DS chips have a square wave input that can be fed from a GPS
PPS and the RTC will discipline itself.  It can also produce a PPS when the
GPS stops.

The question is, is NTP's holdover on the system clock better than NTP
disciplining the system clock with an RTC PPS.  I'd guess not.

Forget about accurate time from the RTC's registers.  The slowness and
variably in I2C is quite poor and most of them don't even have sub-second
resolution when read or written.


On Nov 1, 2017 4:22 PM, "MLewis"  wrote:

Is this a workable or worthwhile strategy?:
- RTC providing date & time to second to system on boot
- RTC frequency output driving a counter/divider to produce PPS
- GPS module providing UTC PPS
- GPS module's secondary PPS disciplining the RTC-counter-divider PPS by
resetting the RTC's counter/divider (I'm assuming there's one that will
rest fast enough to sync; I've never looked into these...)

If GPS PPS is lost, then the RTC counter/divider is producing a recently
disciplined PPS.

Valid or invalid?

And the DS3231 has:
- a 32K output, and
- an Active-Low-Interrupt/SQW output that can be set to PPS.
It's unclear to me how to sync the DS3231 PPS to the GPS PPS, or if that
can be done.

Thanks,

Michael


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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Jim Harman]

On Wed, Nov 1, 2017 at 7:21 PM, MLewis  wrote:

>
> And the DS3231 has:
> - a 32K output, and
> - an Active-Low-Interrupt/SQW output that can be set to PPS.
> It's unclear to me how to sync the DS3231 PPS to the GPS PPS, or if that
> can be done.
>
>
>
The DS3231 has an 8 bit register that will change its frequency in
increments of about 0.1ppm. Thus you could discipline it to get its pps
aligned with your reference.

With an adjustment range of +/- 127, that's a maximum offset of 12.7 ppm.
In the worst case you would have to move its pps 0.5 sec, which by my
calculation would take about 41.667 seconds or about 11.5 hours.

-- 

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

[Bob kb8tq]

Hi

The normal NTP kernel does a pretty good job in “flywheel” mode. For modest 
outages, it’s quite adequate. 

Bob

> On Nov 1, 2017, at 7:21 PM, MLewis  wrote:
> 
> Is this a workable or worthwhile strategy?:
> - RTC providing date & time to second to system on boot
> - RTC frequency output driving a counter/divider to produce PPS
> - GPS module providing UTC PPS
> - GPS module's secondary PPS disciplining the RTC-counter-divider PPS by 
> resetting the RTC's counter/divider (I'm assuming there's one that will rest 
> fast enough to sync; I've never looked into these...)
> 
> If GPS PPS is lost, then the RTC counter/divider is producing a recently 
> disciplined PPS.
> 
> Valid or invalid?
> 
> And the DS3231 has:
> - a 32K output, and
> - an Active-Low-Interrupt/SQW output that can be set to PPS.
> It's unclear to me how to sync the DS3231 PPS to the GPS PPS, or if that can 
> be done.
> 
> Thanks,
> 
> Michael
> 
> ___
> 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] Holdover, RTC for Pi as NTP GPS source

[MLewis]

Is this a workable or worthwhile strategy?:
- RTC providing date & time to second to system on boot
- RTC frequency output driving a counter/divider to produce PPS
- GPS module providing UTC PPS
- GPS module's secondary PPS disciplining the RTC-counter-divider PPS by 
resetting the RTC's counter/divider (I'm assuming there's one that will 
rest fast enough to sync; I've never looked into these...)


If GPS PPS is lost, then the RTC counter/divider is producing a recently 
disciplined PPS.


Valid or invalid?

And the DS3231 has:
- a 32K output, and
- an Active-Low-Interrupt/SQW output that can be set to PPS.
It's unclear to me how to sync the DS3231 PPS to the GPS PPS, or if that 
can be done.


Thanks,

Michael

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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[William H. Fite]

For this apparatus, a lepton is a lepton is a lepton. If the standard model
is complete/correct and neutrinos are massless, they can be ignored as a
potential threat to our project. They'll just zip through on their way to
wherever. The likelihood of a particle interaction is so minute that we can
disregard it. However, if the Super-Kamiokande group convincingly
demonstrates that neutrinos have mass >0. then they must also possess
magnetic moment. Therein lies the potential for variation in the error term
of our measurements.

Or so it seems to me.


On Wednesday, November 1, 2017, Magnus Danielson  wrote:

> Super-lumious or non-speeding neutrinos?
>
> Cheers,
> Magnus
>
> On 11/01/2017 04:30 PM, William H. Fite wrote:
>
>> Oh crap, I forgot about neutrinos.
>>
>> On Wednesday, November 1, 2017, William H. Fite > > wrote:
>>
>> Inside a three-meter thick sphere of lead and mu-metal, pressure
>> pulled down to .01 mTorr , temperature regulated to .001
>> degree C, operating in total darkness and absolute silence, aligned
>> with the galactic axis of rotation, and situated 20 light years from
>> the nearest star.
>>
>> That should satisfy even the most obsessive TN.
>>
>>
>>
>> On Wednesday, November 1, 2017, Magnus Danielson
>> > > wrote:
>>
>> Hi,
>>
>> On 11/01/2017 04:03 PM, jimlux wrote:
>>
>> On 11/1/17 7:37 AM, Magnus Danielson wrote:
>>
>> Hi,
>>
>>Silly people
>>
>> want a relative comfortable temperature and well,
>> building A/C is typically bang/bang regulated so you get
>> what you paid for.
>>
>>
>> wouldn't a true time-nut be in a basically isothermal cave
>> at 10C far underground, and just follow the classic mother's
>> advice "put on a sweater if you feel cold"
>>
>>
>> None of the NMI labs I've seen does this, but please, go ahead.
>>
>> Several of them was just underground, but not that cold.
>>
>> The two labs that where underground was relatively comfortable
>> temperatures. :)
>>
>> 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.
>>
>>
>>
>> -- Patriotism is supporting your country all the time, and your
>> government when it deserves it.
>> --Mark Twain
>>
>> There is no one thing that is true. They're all true.
>> --Ernest Hemingway
>>
>> We may be surprised at the people we find in heaven. God has a soft
>> spot for sinners. His standards are quite low.
>> --Desmond Tutu
>>
>>
>>
>> --
>> Patriotism is supporting your country all the time, and your government
>> when it deserves it.
>> --Mark Twain
>>
>> There is no one thing that is true. They're all true.
>> --Ernest Hemingway
>>
>> We may be surprised at the people we find in heaven. God has a soft spot
>> for sinners. His standards are quite low.
>> --Desmond Tutu
>>
>>

-- 
Patriotism is supporting your country all the time, and your government
when it deserves it.
--Mark Twain

There is no one thing that is true. They're all true.
--Ernest Hemingway

We may be surprised at the people we find in heaven. God has a soft spot
for sinners. His standards are quite low.
--Desmond Tutu
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Magnus Danielson]

Super-lumious or non-speeding neutrinos?

Cheers,
Magnus

On 11/01/2017 04:30 PM, William H. Fite wrote:

Oh crap, I forgot about neutrinos.

On Wednesday, November 1, 2017, William H. Fite > wrote:


Inside a three-meter thick sphere of lead and mu-metal, pressure
pulled down to .01 mTorr , temperature regulated to .001
degree C, operating in total darkness and absolute silence, aligned
with the galactic axis of rotation, and situated 20 light years from
the nearest star.

That should satisfy even the most obsessive TN.



On Wednesday, November 1, 2017, Magnus Danielson
> wrote:

Hi,

On 11/01/2017 04:03 PM, jimlux wrote:

On 11/1/17 7:37 AM, Magnus Danielson wrote:

Hi,

   Silly people

want a relative comfortable temperature and well,
building A/C is typically bang/bang regulated so you get
what you paid for.


wouldn't a true time-nut be in a basically isothermal cave
at 10C far underground, and just follow the classic mother's
advice "put on a sweater if you feel cold"


None of the NMI labs I've seen does this, but please, go ahead.

Several of them was just underground, but not that cold.

The two labs that where underground was relatively comfortable
temperatures. :)

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.



-- 
Patriotism is supporting your country all the time, and your

government when it deserves it.
--Mark Twain

There is no one thing that is true. They're all true.
--Ernest Hemingway

We may be surprised at the people we find in heaven. God has a soft
spot for sinners. His standards are quite low.
--Desmond Tutu



--
Patriotism is supporting your country all the time, and your government 
when it deserves it.

--Mark Twain

There is no one thing that is true. They're all true.
--Ernest Hemingway

We may be surprised at the people we find in heaven. God has a soft spot 
for sinners. His standards are quite low.

--Desmond Tutu


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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Magnus Danielson]

That sloppy temperaturestabilization???

Also, we would need to care about the lead-poisoning of the mu-metal and 
the needed re-alignment... ehm... ah well.


Cheers,
Magnus

On 11/01/2017 04:29 PM, William H. Fite wrote:
Inside a three-meter thick sphere of lead and mu-metal, pressure pulled 
down to .01 mTorr , temperature regulated to .001 degree C, 
operating in total darkness and absolute silence, aligned with the 
galactic axis of rotation, and situated 20 light years from the nearest 
star.


That should satisfy even the most obsessive TN.



On Wednesday, November 1, 2017, Magnus Danielson 
> wrote:


Hi,

On 11/01/2017 04:03 PM, jimlux wrote:

On 11/1/17 7:37 AM, Magnus Danielson wrote:

Hi,

   Silly people

want a relative comfortable temperature and well, building
A/C is typically bang/bang regulated so you get what you
paid for.


wouldn't a true time-nut be in a basically isothermal cave at
10C far underground, and just follow the classic mother's advice
"put on a sweater if you feel cold"


None of the NMI labs I've seen does this, but please, go ahead.

Several of them was just underground, but not that cold.

The two labs that where underground was relatively comfortable
temperatures. :)

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.



--
Patriotism is supporting your country all the time, and your government 
when it deserves it.

--Mark Twain

There is no one thing that is true. They're all true.
--Ernest Hemingway

We may be surprised at the people we find in heaven. God has a soft spot 
for sinners. His standards are quite low.

--Desmond Tutu


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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[MLewis]

This GPS/Pi server, with possibly a second copy, are intended to be the 
sole NTP sources for a local network. No going out to the internet.


My intent was to discipline the RTC, so it's current when needed. If I 
had to do a cold boot without GPS available, I'd want the RTC to be current.


I hadn't considered  'just riding through using the NTP estimate of the 
current system clock frequency', having assumed that a disciplined RTC 
would be a better source.


Hadn't heard about that issue with NTPsec.

I haven't looked at chrony. Something else to read tonight.

Thanks,

Michael

On 01/11/2017 4:57 PM, Chris Caudle wrote:

On Wed, November 1, 2017 3:17 pm, MLewis wrote:

hadn't got there yet

Your RTC is not likely to be tightly synchronized to NTP time, so there is
a high probability that trying to use RTC as a secondary time source will
actually make the system worse than just riding through using the NTP
estimate of the current system clock frequency.  If ntpd will even use it
as a secondary clock, and not reject it because it is too far off from the
preferred GPS source.

Is this system not connected to other NTP servers over the network?
NTPsec does not work very well in the case of only one GPS device
available to set time, that is documented as one of the use cases which
NTPsec does not currently handle well.  If there are no other servers
available for comparison you will probably want to use chrony.  If there
are other servers available then trying to switch over to the RTC will
definitely make your ntp server perform worse than just leaving well
enough alone.



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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Hal Murray]

>> How are you planning on making ntp use the RTC as a secondary
>> time source?  I don't see that as a supported refclk driver.

> hadn't got there yet likely using NTPsec, as the codebase is available if a
> driver or generic  driver won't work 

The PPS driver expects the pulse to be on the second.  You won't get that 
from a RTC.

If I was doing it, I use the SHM driver.  Then you can do all your work in a 
separate program and feed an offset to ntpd.

I haven't looked at RTC chips recently.  You want a pulse that you can feed 
to the kernel's PPS capture logic.  60Hz works on a PC.  32KHz is probably 
too fast.  (might be worth a try)  You might have to add a divider.

If you use the GPS HAT from Adafruit, it has a prototyping area where you 
could drop in a RTC and wire it up to various GPIO pins.  DIP package would 
be convenient.  The Ethernet on the PI is via USB, so it's crappy for making 
a nutty-good NTP server.  But the PI is convenient and good enough for all 
but nutty uses.


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

[Chris Caudle]

On Wed, November 1, 2017 3:17 pm, MLewis wrote:
> hadn't got there yet

Your RTC is not likely to be tightly synchronized to NTP time, so there is
a high probability that trying to use RTC as a secondary time source will
actually make the system worse than just riding through using the NTP
estimate of the current system clock frequency.  If ntpd will even use it
as a secondary clock, and not reject it because it is too far off from the
preferred GPS source.

Is this system not connected to other NTP servers over the network? 
NTPsec does not work very well in the case of only one GPS device
available to set time, that is documented as one of the use cases which
NTPsec does not currently handle well.  If there are no other servers
available for comparison you will probably want to use chrony.  If there
are other servers available then trying to switch over to the RTC will
definitely make your ntp server perform worse than just leaving well
enough alone.

-- 
Chris C


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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[MLewis]

hadn't got there yet
likely using NTPsec, as the codebase is available if a driver or generic 
driver won't work

https://docs.ntpsec.org/latest/driver_howto.html

On 01/11/2017 12:38 PM, Chris Caudle wrote:

On Tue, October 31, 2017 9:27 pm, MLewis wrote:

I'm intending to add a "precision" (well, precision to the Pi world) RTC
to my Pi 3 to use for a holdover source when it hasn't got PPS from the
GPS module.

How are you planning on making ntp use the RTC as a secondary time source?
  I don't see that as a supported refclk driver.



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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[ewkehren via time-nuts]

Tbolt is a good oneBert Kehren


Sent from my Galaxy Tab® A
 Original message From: David J Taylor via time-nuts 
<time-nuts@febo.com> Date: 11/1/17  12:07 PM  (GMT-05:00) To: 
time-nuts@febo.com Subject: Re: [time-nuts] Holdover, RTC for Pi as NTP GPS 
source 
From: Mark Sims

I have an analytical balance that reads down to micrograms.   The weigh 
chamber is surrounded by three layers of IR absorbing glass so that radiated 
body heat does not induce convection currents in the air.   I worked on a 
balance that had nanogram resolution (mostly wishful thinking in that spec). 
It operated in a vacuum.  30 bit mass-to-digital converters are rather 
finicky beasties.

It does not take all that good of a temperature sensor to detect changes in 
room temperature due to body heat (or fetching a beer from the fridge in the 
next room).  You are basically a 100 watt space heater... even larger for 
the more corpulent folks.
==

Temperature is indeed the killer.  My best Raspberry Pis for time-keeping 
are RasPi-1 and RasPi-4, both of which are in an unheated cupboard not 
exposed to sunlight, on the north side of the house with indoor patch GPS 
antennas.

  http://www.satsignal.eu/mrtg/performance_ntp.php

Cheers,
David
-- 
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 

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

[David J Taylor via time-nuts]

From: David C. Partridge 


? RasPi-4? Not released until 2019 AFAIK ...  I have RasPi-3
===

My Raspberry Pi #1 and Raspberry Pi #4.  See:

 http://www.satsignal.eu/mrtg/performance_ntp.php

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[David C. Partridge]

? RasPi-4? Not released until 2019 AFAIK ...  I have RasPi-3

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of David J Taylor 
via time-nuts
Sent: 01 November 2017 16:08
To: time-nuts@febo.com
Subject: Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

From: Mark Sims

I have an analytical balance that reads down to micrograms.   The weigh 
chamber is surrounded by three layers of IR absorbing glass so that radiated 
body heat does not induce convection currents in the air.   I worked on a 
balance that had nanogram resolution (mostly wishful thinking in that spec). 
It operated in a vacuum.  30 bit mass-to-digital converters are rather finicky 
beasties.

It does not take all that good of a temperature sensor to detect changes in 
room temperature due to body heat (or fetching a beer from the fridge in the 
next room).  You are basically a 100 watt space heater... even larger for the 
more corpulent folks.
==

Temperature is indeed the killer.  My best Raspberry Pis for time-keeping are 
RasPi-1 and RasPi-4, both of which are in an unheated cupboard not exposed to 
sunlight, on the north side of the house with indoor patch GPS antennas.

  http://www.satsignal.eu/mrtg/performance_ntp.php

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 

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

[David J Taylor via time-nuts]

From: Mark Sims

I have an analytical balance that reads down to micrograms.   The weigh 
chamber is surrounded by three layers of IR absorbing glass so that radiated 
body heat does not induce convection currents in the air.   I worked on a 
balance that had nanogram resolution (mostly wishful thinking in that spec). 
It operated in a vacuum.  30 bit mass-to-digital converters are rather 
finicky beasties.


It does not take all that good of a temperature sensor to detect changes in 
room temperature due to body heat (or fetching a beer from the fridge in the 
next room).  You are basically a 100 watt space heater... even larger for 
the more corpulent folks.

==

Temperature is indeed the killer.  My best Raspberry Pis for time-keeping 
are RasPi-1 and RasPi-4, both of which are in an unheated cupboard not 
exposed to sunlight, on the north side of the house with indoor patch GPS 
antennas.


 http://www.satsignal.eu/mrtg/performance_ntp.php

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


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

[Mark Sims]

I have an analytical balance that reads down to micrograms.   The weigh chamber 
is surrounded by three layers of IR absorbing glass so that radiated body heat 
does not induce convection currents in the air.   I worked on a balance that 
had nanogram resolution (mostly wishful thinking in that spec).  It operated in 
a vacuum.  30 bit mass-to-digital converters are rather finicky beasties.

It does not take all that good of a temperature sensor to detect changes in 
room temperature due to body heat (or fetching a beer from the fridge in the 
next room).  You are basically a 100 watt space heater... even larger for the 
more corpulent folks.   



> Surely he'd want to be in an isolating suit to avoid introducing a nasty
warm body into his nice stable cave ?
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[William H. Fite]

Oh crap, I forgot about neutrinos.

On Wednesday, November 1, 2017, William H. Fite  wrote:

> Inside a three-meter thick sphere of lead and mu-metal, pressure pulled
> down to .01 mTorr , temperature regulated to .001 degree C,
> operating in total darkness and absolute silence, aligned with the galactic
> axis of rotation, and situated 20 light years from the nearest star.
>
> That should satisfy even the most obsessive TN.
>
>
>
> On Wednesday, November 1, 2017, Magnus Danielson <
> mag...@rubidium.dyndns.org
> > wrote:
>
>> Hi,
>>
>> On 11/01/2017 04:03 PM, jimlux wrote:
>>
>>> On 11/1/17 7:37 AM, Magnus Danielson wrote:
>>>
 Hi,

   Silly people
>>>
 want a relative comfortable temperature and well, building A/C is
 typically bang/bang regulated so you get what you paid for.


>>> wouldn't a true time-nut be in a basically isothermal cave at 10C far
>>> underground, and just follow the classic mother's advice "put on a sweater
>>> if you feel cold"
>>>
>>
>> None of the NMI labs I've seen does this, but please, go ahead.
>>
>> Several of them was just underground, but not that cold.
>>
>> The two labs that where underground was relatively comfortable
>> temperatures. :)
>>
>> Cheers,
>> Magnus
>> ___
>> 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.
>>
>
>
> --
> Patriotism is supporting your country all the time, and your government
> when it deserves it.
> --Mark Twain
>
> There is no one thing that is true. They're all true.
> --Ernest Hemingway
>
> We may be surprised at the people we find in heaven. God has a soft spot
> for sinners. His standards are quite low.
> --Desmond Tutu
>
>

-- 
Patriotism is supporting your country all the time, and your government
when it deserves it.
--Mark Twain

There is no one thing that is true. They're all true.
--Ernest Hemingway

We may be surprised at the people we find in heaven. God has a soft spot
for sinners. His standards are quite low.
--Desmond Tutu
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[William H. Fite]

Inside a three-meter thick sphere of lead and mu-metal, pressure pulled
down to .01 mTorr , temperature regulated to .001 degree C,
operating in total darkness and absolute silence, aligned with the galactic
axis of rotation, and situated 20 light years from the nearest star.

That should satisfy even the most obsessive TN.



On Wednesday, November 1, 2017, Magnus Danielson 
wrote:

> Hi,
>
> On 11/01/2017 04:03 PM, jimlux wrote:
>
>> On 11/1/17 7:37 AM, Magnus Danielson wrote:
>>
>>> Hi,
>>>
>>>   Silly people
>>
>>> want a relative comfortable temperature and well, building A/C is
>>> typically bang/bang regulated so you get what you paid for.
>>>
>>>
>> wouldn't a true time-nut be in a basically isothermal cave at 10C far
>> underground, and just follow the classic mother's advice "put on a sweater
>> if you feel cold"
>>
>
> None of the NMI labs I've seen does this, but please, go ahead.
>
> Several of them was just underground, but not that cold.
>
> The two labs that where underground was relatively comfortable
> temperatures. :)
>
> Cheers,
> Magnus
> ___
> 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.
>


-- 
Patriotism is supporting your country all the time, and your government
when it deserves it.
--Mark Twain

There is no one thing that is true. They're all true.
--Ernest Hemingway

We may be surprised at the people we find in heaven. God has a soft spot
for sinners. His standards are quite low.
--Desmond Tutu
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Magnus Danielson]

Hi,

On 11/01/2017 04:03 PM, jimlux wrote:

On 11/1/17 7:37 AM, Magnus Danielson wrote:

Hi,


  Silly people
want a relative comfortable temperature and well, building A/C is 
typically bang/bang regulated so you get what you paid for.




wouldn't a true time-nut be in a basically isothermal cave at 10C far 
underground, and just follow the classic mother's advice "put on a 
sweater if you feel cold"


None of the NMI labs I've seen does this, but please, go ahead.

Several of them was just underground, but not that cold.

The two labs that where underground was relatively comfortable 
temperatures. :)


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.

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Adrian Godwin]

Surely he'd want to be in an isolating suit to avoid introducing a nasty
warm body into his nice stable cave ?


On Wed, Nov 1, 2017 at 3:03 PM, jimlux  wrote:

> On 11/1/17 7:37 AM, Magnus Danielson wrote:
>
>> Hi,
>>
>>  Silly people
>
>> want a relative comfortable temperature and well, building A/C is
>> typically bang/bang regulated so you get what you paid for.
>>
>>
>
>
> wouldn't a true time-nut be in a basically isothermal cave at 10C far
> underground, and just follow the classic mother's advice "put on a sweater
> if you feel cold"
>
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[jimlux]

On 11/1/17 7:37 AM, Magnus Danielson wrote:

Hi,


 Silly people
want a relative comfortable temperature and well, building A/C is 
typically bang/bang regulated so you get what you paid for.






wouldn't a true time-nut be in a basically isothermal cave at 10C far 
underground, and just follow the classic mother's advice "put on a 
sweater if you feel cold"



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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[Magnus Danielson]

Hi,

This is also true for labs. One NMI lab I visited had issues with their 
5071As and H-maser clocks. It took some time to correlate it, but it 
turned out to correlate with the florescent lamps in the lab and people 
walking in and out. Changing these lamps to milder labs removed that 
disturbance, so people needing things like light can be a problem even 
for higher end grade labs.


The draft has been a re-occurring problem that we have seen, so it was 
really nice to show that simple blockage of air helped to significantly 
reduce that impact. Again, people walking up to the lab-bench was an issue.


A third example was a couple of students doing stability measures. They 
had a long-term measurement that all of a sudden became much flatter, 
and they asked me what it could be. They had started the measurement at 
15:00 and three hours late the semi-cyclic variation in phase stopped 
and things became much more quiet. I could then quickly conclude that it 
was the A/C for the building turned off, not to heat it during night. 
They didn't believe me, so I popped out the board and showed how the 
air-stream passed directly over the crystal metal housing and hence had 
a good thermal connection to the surrounding air temperature. I later 
had them put a few strands of foam-tape over the crystal, and they 
measured the same stable behavior over the full work-day. Silly people 
want a relative comfortable temperature and well, building A/C is 
typically bang/bang regulated so you get what you paid for.


Cheers,
Magnus

On 11/01/2017 02:17 PM, Bob kb8tq wrote:

Hi



On Nov 1, 2017, at 12:14 AM, MLewis  wrote:

(I suspect this is drifting from the original thread too much, so new subject)

Temperature ranges from 65F to 78F, with the potential for drafts, but is more 
typically 76F.


The gotcha in a real environment often involves people. They walk by (creating 
a draft). They
turn on all the lights and equipment. They open or close the blinds to let in 
or block the sun.
They tend to do this in an unpredictable / chaotic fashion. All of this makes a 
correction
process based on “normal operation” a bit difficult. Something goes wrong, and 
the unit
goes into holdover. People suddenly start dashing around and the temperature is 
not
what it has been ….

Bob




I read about the NTPsec runs with insulating a Pi and running a load generating 
program to better maintain a stable core temperature.
Just today I've put my GPS module inside a case for an RF shield that is also 
semi insulated. It's feeding LH on a PC while I do the next step.
The Pi 3 is going inside a large enough tea tin and that will be lined with 
insulation.
I'm wondering about insulating the RTC...

The low cost for a 'precision' RTC means it is cheap to test.

I'd completely discounted coasting with the system clock, as I have fixed in my 
head the variable loads on my production machine mean that Window's time lags 
variable amounts, as the CPU load is variable with variable burst loads every 
1/8 of a second.

Michael

On 31/10/2017 11:45 PM, Hal Murray wrote:

I'm intending to add a "precision" (well, precision to the Pi world) RTC  to
my Pi 3 to use for a holdover source when it hasn't got PPS from the  GPS
module.
An RTC that +/- 3 PPM over 24 hours would be great for holdovers of one  to
20 minutes.

Run some experiments to collect some data and play with the numbers.

How stable is the temperature in your environment?

The key to keeping sane time on a PC or Raspberry PI is to calibrate the
crystal.  Most CPUs have a register that counts at the CPU clock frequency -
or something in that range.  Most systems smear the clock to keep the FCC
happy...

Most OSes keep time by watching that register and dividing by the clock rate.
  The actual clock rate doesn't usually match the number printed on the
crystal.  It's close, but ntpd can easily measure the error and tell the
kernel so the kernel can use the right value.  If you turn on loopstats, ntpd
will log it and you can graph it.

If you are writing an embedded system, you will want that sort of logic too.

My guess is that in the under 30 minute range, you will get better results by
just coasting with the system clock rather that using a RTC.  It would be an
interesting experiment.  Implement both clocking schemes and compare them.







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


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

[Bob kb8tq]

Hi


> On Nov 1, 2017, at 12:14 AM, MLewis  wrote:
> 
> (I suspect this is drifting from the original thread too much, so new subject)
> 
> Temperature ranges from 65F to 78F, with the potential for drafts, but is 
> more typically 76F.

The gotcha in a real environment often involves people. They walk by (creating 
a draft). They 
turn on all the lights and equipment. They open or close the blinds to let in 
or block the sun. 
They tend to do this in an unpredictable / chaotic fashion. All of this makes a 
correction 
process based on “normal operation” a bit difficult. Something goes wrong, and 
the unit
goes into holdover. People suddenly start dashing around and the temperature is 
not 
what it has been ….

Bob


> 
> I read about the NTPsec runs with insulating a Pi and running a load 
> generating program to better maintain a stable core temperature.
> Just today I've put my GPS module inside a case for an RF shield that is also 
> semi insulated. It's feeding LH on a PC while I do the next step.
> The Pi 3 is going inside a large enough tea tin and that will be lined with 
> insulation.
> I'm wondering about insulating the RTC...
> 
> The low cost for a 'precision' RTC means it is cheap to test.
> 
> I'd completely discounted coasting with the system clock, as I have fixed in 
> my head the variable loads on my production machine mean that Window's time 
> lags variable amounts, as the CPU load is variable with variable burst loads 
> every 1/8 of a second.
> 
> Michael
> 
> On 31/10/2017 11:45 PM, Hal Murray wrote:
>>> I'm intending to add a "precision" (well, precision to the Pi world) RTC  to
>>> my Pi 3 to use for a holdover source when it hasn't got PPS from the  GPS
>>> module.
>>> An RTC that +/- 3 PPM over 24 hours would be great for holdovers of one  to
>>> 20 minutes.
>> Run some experiments to collect some data and play with the numbers.
>> 
>> How stable is the temperature in your environment?
>> 
>> The key to keeping sane time on a PC or Raspberry PI is to calibrate the
>> crystal.  Most CPUs have a register that counts at the CPU clock frequency -
>> or something in that range.  Most systems smear the clock to keep the FCC
>> happy...
>> 
>> Most OSes keep time by watching that register and dividing by the clock rate.
>>  The actual clock rate doesn't usually match the number printed on the
>> crystal.  It's close, but ntpd can easily measure the error and tell the
>> kernel so the kernel can use the right value.  If you turn on loopstats, ntpd
>> will log it and you can graph it.
>> 
>> If you are writing an embedded system, you will want that sort of logic too.
>> 
>> My guess is that in the under 30 minute range, you will get better results by
>> just coasting with the system clock rather that using a RTC.  It would be an
>> interesting experiment.  Implement both clocking schemes and compare them.
>> 
>> 
>> 
>> 
>> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source

[MLewis]

(I suspect this is drifting from the original thread too much, so new 
subject)


Temperature ranges from 65F to 78F, with the potential for drafts, but 
is more typically 76F.


I read about the NTPsec runs with insulating a Pi and running a load 
generating program to better maintain a stable core temperature.
Just today I've put my GPS module inside a case for an RF shield that is 
also semi insulated. It's feeding LH on a PC while I do the next step.
The Pi 3 is going inside a large enough tea tin and that will be lined 
with insulation.

I'm wondering about insulating the RTC...

The low cost for a 'precision' RTC means it is cheap to test.

I'd completely discounted coasting with the system clock, as I have 
fixed in my head the variable loads on my production machine mean that 
Window's time lags variable amounts, as the CPU load is variable with 
variable burst loads every 1/8 of a second.


Michael

On 31/10/2017 11:45 PM, Hal Murray wrote:

I'm intending to add a "precision" (well, precision to the Pi world) RTC  to
my Pi 3 to use for a holdover source when it hasn't got PPS from the  GPS
module.
An RTC that +/- 3 PPM over 24 hours would be great for holdovers of one  to
20 minutes.

Run some experiments to collect some data and play with the numbers.

How stable is the temperature in your environment?

The key to keeping sane time on a PC or Raspberry PI is to calibrate the
crystal.  Most CPUs have a register that counts at the CPU clock frequency -
or something in that range.  Most systems smear the clock to keep the FCC
happy...

Most OSes keep time by watching that register and dividing by the clock rate.
  The actual clock rate doesn't usually match the number printed on the
crystal.  It's close, but ntpd can easily measure the error and tell the
kernel so the kernel can use the right value.  If you turn on loopstats, ntpd
will log it and you can graph it.

If you are writing an embedded system, you will want that sort of logic too.

My guess is that in the under 30 minute range, you will get better results by
just coasting with the system clock rather that using a RTC.  It would be an
interesting experiment.  Implement both clocking schemes and compare them.







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

Re: [time-nuts] Holdover

[lincoln]

Hello Bob,
At work we make internet clock that are governed by a number of ITU and 
IEEE standards. As others have stated correctly, there is no standard. There 
are a number of behaviors that can be configured depending on application.

1. Always a PPS out, TOD string carries a valid or "do not use" flag - 
default, actually used about 1/3 of the time
2. Output only when clock is "synced" , That is  the error is small and 
the slope of the changes made is small, for at least 4 observational windows. 
3. Like number 2 but adds the notion of Holdover. That is when sync is 
broken, if you had been synced for "enough" time, keep output if you hold over 
counter has not expired. 

Now what to do when your source is re-established..
If the offset is large, or if the PPS has been squelched, or the 
reference source has changed, jam the 1pps, and steer from there. 
If the offset is small, ( some µs, ) steer the 1pps , with the max rate 
of steering set by how much we can screw up the frequency, default is 10 ppb  

Loop bandwidth is set by the source, PTP / IEEE 1588 sources bandwidth 
can be as narrow as  1~3 mHz , GNSS has much wider bandwidth, 

All of the clock class mappings, limits and thresholds are configurable 
at some level.  

Link



On Aug 15, 2016, at 21:35 , Bob Stewart  wrote:

> It's been pointed out to me that I didn't understand the function of the 1PPS 
> of a time standard.  I confess that somehow I had confused the term to be 
> timing standard; which would be an entirely different thing.  But, this is 
> time-nuts, so I should have realized...
> Anyway, is there a standard, or at least an accepted practice, for how 
> holdover is handled in a time standard?  Not "how it's done", as in 
> algorithms, but what is expected by the user.  I can see at least 2 ways: 
> time warping (which would be especially bad if the time standard had gotten 
> ahead in time) and nudging back to the correct time.  The case of warping is 
> obvious.  But, are there other methods, and is there some standard for how 
> quickly the time output of the time standard, and of course the 1PPS pulse, 
> is nudged back to the correct time?
> Bob - AE6RV
> -
> AE6RV.com
> 
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
> ___
> 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] Holdover

[Magnus Danielson]

Hi,

You do the jamming when you have a reference again.

You have three possibilities when the reference/GPS comes back:

1) Re-acquire frequency and phase lock directly

The time error between the generated PPS and the reference PPS is 
directly applied to the control loop which then will start to track in.


This works, but if you have been in hold-over for a long time, the 
trace-in might take quite some time.


To overcome this, heuristics can be used to increase the loop bandwidth, 
as the trace-in time depends heavily on it. Then the heuristics also 
needs to adjust the bandwidth back to narrow-band.
Shifting of bandwidth needs to be done with care, and there is an art to 
design the loop for it and the heuristics to work well. A Kalman filter 
could be used, but just tossing your trust to the Kalman as if it is a 
silver bullet is quite foolish, the Kalman needs it's heuristics and 
design to do well, so well, I'm not sure the difference is very large in 
the end.


2) Jam phase into about right phase and then re-acquire frequency and 
phase from there.


Here you start with detecting that the phase is way out there, so throw 
a wrench into the machinery to re-set the counters and thus push the 
generated PPS into about the same phase. For a 10 MHz clock you select 
the 100 ns cycle that fits and you can with easy methods be within +/- 
100 ns and with a little bit care be within +/- 50 ns by such a jamming 
action.


The effect of the jamming is that you have the phase about where you 
want it, but a phase error will remain. Just close the loop with the 
remaining phase error and any frequency error will also be need to be 
captured.


The benefit is that you don't need to back out as much in bandwidth and 
the process goes quicker.


3) Jam phase and frequency and then re-acquire frequency and phase.

Just as you jam the phase, you then measure the frequency error and 
re-set the frequency state. You then measure the frequency during some 
time, set it and then close the loop.


Again you have the benefit of the phase-jam, but the frequency 
measurement time is similar to the closing of the loop and well, your 
milage vary depending how well you do the heuristics.


A re-occuring theme is that there is heuristics controlling the process, 
and that can be both a help and a threat to system properties.

Let's just say that one needs to work on it and many details.

Cheers,
Magnus


On 08/17/2016 10:06 AM, Azelio Boriani wrote:

...the Z3801A requires the device to be in holdover... with the GPS
PPS already acquired: I think that the "jam sync" must be done against
some reference...

On Wed, Aug 17, 2016 at 4:49 AM, Mark Sims  wrote:

The Trimble GPSDOs and most of the SCPI ones (like the Z3801A) have "jam sync" 
commands that force the receiver to do an immediate time sync (the Z3801A requires the 
device to be in holdover before it will accept a jam sync).  Some also have commands 
where you an also specify thresholds where the receiver alarms and/or does an automatic 
jam sync and thresholds for loss-of-signal time before the device goes into holdover mode.

---

I have selected a somewhat more intricate setup in which you can set a
re-assignment limit, so when the phase error is outside of that limit,
you turn the output off, jumps the phase difference, and then starts to
track in from there. The reason being that at some time deviation, the
time it takes to track in the phase error is too large to be practical
so turning of and jump has less impact.
___
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] Holdover

[Azelio Boriani]

...the Z3801A requires the device to be in holdover... with the GPS
PPS already acquired: I think that the "jam sync" must be done against
some reference...

On Wed, Aug 17, 2016 at 4:49 AM, Mark Sims  wrote:
> The Trimble GPSDOs and most of the SCPI ones (like the Z3801A) have "jam 
> sync" commands that force the receiver to do an immediate time sync (the 
> Z3801A requires the device to be in holdover before it will accept a jam 
> sync).  Some also have commands where you an also specify thresholds where 
> the receiver alarms and/or does an automatic jam sync and thresholds for 
> loss-of-signal time before the device goes into holdover mode.
>
> ---
>
> I have selected a somewhat more intricate setup in which you can set a
> re-assignment limit, so when the phase error is outside of that limit,
> you turn the output off, jumps the phase difference, and then starts to
> track in from there. The reason being that at some time deviation, the
> time it takes to track in the phase error is too large to be practical
> so turning of and jump has less impact.
> ___
> 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] Holdover

[Bob Stewart]

Hi Magnus,
I don't remember seeing such a report.  Could you tell me where to find a copy? 
 I've got a lot of code-space left on this PIC, so assuming I can get the 
hardware to cooperate, much is possible.

Bob -
AE6RV.com

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

  From: Magnus Danielson <mag...@rubidium.se>
 To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
measurement <time-nuts@febo.com> 
Cc: mag...@rubidium.se
 Sent: Wednesday, August 17, 2016 1:05 AM
 Subject: Re: [time-nuts] Holdover
   
Bob,

That is what seem to work well in commercial products, including my designs.
Have you seen the RAI report on GPSDOs? I think we discussed it before, 
that will be a relevant reading.

Not all system implements 3), and it is a bit complex, so consider it an 
option to add, but not necessarily always used. Sometimes you don't want 
to do that.

Cheers,
Magnus

On 08/17/2016 02:08 AM, Bob Stewart wrote:
> Thanks Magnus!
>
> These look like good guidelines.  I'll see what I can come up with.
>
> Bob
>
> -
> AE6RV.com
>
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>
>
> 
> *From:* Magnus Danielson <mag...@rubidium.dyndns.org>
> *To:* time-nuts@febo.com
> *Cc:* mag...@rubidium.se
> *Sent:* Tuesday, August 16, 2016 6:49 PM
> *Subject:* Re: [time-nuts] Holdover
>
> Bob,
>
> On 08/16/2016 11:31 PM, Bob Stewart wrote:
>> Hi Attila,
>> In my unit, which is a frequency standard, I chose to tell the
> receiver to stop sending 1PPS pulses when it loses sync to the sats.
> And since the 1PPS is no longer coming, the PLL does nothing and the DAC
> doesn't change.  (Let's avoid the question of aging correction for
> now.)  So, I'm wondering where to go and what to do if I want to get
> time from my unit.  Clearly I could just tell the receiver to continue
> to send 1PPS pulses and sync to those - marking the time as unreliable.
> When the receiver synced back up, then it would warp the time output,
> the 1PPS would warp in phase, and the PLL would correct the phase error.
>>
>> So, that's one way, but probably not a desirable way.  My interest was
> in the option of using the OCXO to create the time, which clearly gives
> a better option when the receiver syncs back up to the sats.  Is there a
> published standard for this, or is this something that everyone (except
> the newbie) knows so well that it's not worth discussing?
>
> There is no standard, but a few basic ways to go about which seems
> reasonable and used by most is:
>
> 1) As you go into hold-over, keep producing PPS etc
> 2) As you leave hold-over, attempt to adjust the phase back.
> 3) If your system been in hold-over for a longer time, say that it
> reasonably deviates outside of +/- 10 us (or some other limit), alarm
> and turn output off
>
> I have selected a somewhat more intricate setup in which you can set a
> re-assignment limit, so when the phase error is outside of that limit,
> you turn the output off, jumps the phase difference, and then starts to
> track in from there. The reason being that at some time deviation, the
> time it takes to track in the phase error is too large to be practical
> so turning of and jump has less impact.
>
> Cheers,
> Magnus
>
>> Bob
>>  -
>> AE6RV.com
>>
>> GFS GPSDO list:
>> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>>
>>      From: Attila Kinali <att...@kinali.ch <mailto:att...@kinali.ch>>
>>  To: Bob Stewart <b...@evoria.net <mailto:b...@evoria.net>>; Discussion
> of precise time and frequency measurement <time-nuts@febo.com
> <mailto:time-nuts@febo.com>>
>>  Sent: Tuesday, August 16, 2016 3:46 PM
>>  Subject: Re: [time-nuts] Holdover
>>
>> On Tue, 16 Aug 2016 04:35:40 + (UTC)
>> Bob Stewart <b...@evoria.net <mailto:b...@evoria.net>> wrote:
>>
>>> It's been pointed out to me that I didn't understand the function of
>>> the 1PPS of a time standard.  I confess that somehow I had confused the
>>> term to be timing standard; which would be an entirely different thing.
>>> But, this is time-nuts, so I should have realized...
>>> Anyway, is there a standard, or at least an accepted practice, for how
>>> holdover is handled in a time standard?
>>
>> There are many ways how to do that and which one you choose depends
>> on the app

Re: [time-nuts] Holdover

[Bob Stewart]

Thanks Chris.  Those are more considerations that I hadn't thought of.  I begin 
to see why there's no "standard".

Bob
 -
AE6RV.com

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

  From: Chris Albertson <albertson.ch...@gmail.com>
 To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
measurement <time-nuts@febo.com> 
 Sent: Tuesday, August 16, 2016 7:59 PM
 Subject: Re: [time-nuts] Holdover
   


What to do during and right after holdover depends on the reason you have a 
time standard.  If it is for maintaining a lab standard, then just shut down as 
you can't perform your primary function.  It you have this standard because you 
are required to time stamp financial transactions then you have to keep going 
until you estimate some error threshold then stop.  If you are using it to aim 
a telescope then again, stop using it the estimated error is enough that you'd 
miss your targets.    It depends on the use case.
I remember aiming a telescope when our best source of time was NTP over a 
dial-up phone modem in the days before always-on Internet  This was in the 
1980's and it worked well enough.  The normal case was "outage" as the modem 
connection was short and only a few times per day.  But was good enough to 
re-calibrate a local  clock 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] Holdover

[Magnus Danielson]

Bob,

That is what seem to work well in commercial products, including my designs.
Have you seen the RAI report on GPSDOs? I think we discussed it before, 
that will be a relevant reading.


Not all system implements 3), and it is a bit complex, so consider it an 
option to add, but not necessarily always used. Sometimes you don't want 
to do that.


Cheers,
Magnus

On 08/17/2016 02:08 AM, Bob Stewart wrote:

Thanks Magnus!

These look like good guidelines.  I'll see what I can come up with.

Bob

-
AE6RV.com

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



*From:* Magnus Danielson <mag...@rubidium.dyndns.org>
*To:* time-nuts@febo.com
*Cc:* mag...@rubidium.se
*Sent:* Tuesday, August 16, 2016 6:49 PM
*Subject:* Re: [time-nuts] Holdover

Bob,

On 08/16/2016 11:31 PM, Bob Stewart wrote:

Hi Attila,
In my unit, which is a frequency standard, I chose to tell the

receiver to stop sending 1PPS pulses when it loses sync to the sats.
And since the 1PPS is no longer coming, the PLL does nothing and the DAC
doesn't change.  (Let's avoid the question of aging correction for
now.)  So, I'm wondering where to go and what to do if I want to get
time from my unit.  Clearly I could just tell the receiver to continue
to send 1PPS pulses and sync to those - marking the time as unreliable.
When the receiver synced back up, then it would warp the time output,
the 1PPS would warp in phase, and the PLL would correct the phase error.


So, that's one way, but probably not a desirable way.  My interest was

in the option of using the OCXO to create the time, which clearly gives
a better option when the receiver syncs back up to the sats.  Is there a
published standard for this, or is this something that everyone (except
the newbie) knows so well that it's not worth discussing?

There is no standard, but a few basic ways to go about which seems
reasonable and used by most is:

1) As you go into hold-over, keep producing PPS etc
2) As you leave hold-over, attempt to adjust the phase back.
3) If your system been in hold-over for a longer time, say that it
reasonably deviates outside of +/- 10 us (or some other limit), alarm
and turn output off

I have selected a somewhat more intricate setup in which you can set a
re-assignment limit, so when the phase error is outside of that limit,
you turn the output off, jumps the phase difference, and then starts to
track in from there. The reason being that at some time deviation, the
time it takes to track in the phase error is too large to be practical
so turning of and jump has less impact.

Cheers,
Magnus


Bob
 -
AE6RV.com

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

 From: Attila Kinali <att...@kinali.ch <mailto:att...@kinali.ch>>
 To: Bob Stewart <b...@evoria.net <mailto:b...@evoria.net>>; Discussion

of precise time and frequency measurement <time-nuts@febo.com
<mailto:time-nuts@febo.com>>

 Sent: Tuesday, August 16, 2016 3:46 PM
 Subject: Re: [time-nuts] Holdover

On Tue, 16 Aug 2016 04:35:40 + (UTC)
Bob Stewart <b...@evoria.net <mailto:b...@evoria.net>> wrote:


It's been pointed out to me that I didn't understand the function of
the 1PPS of a time standard.  I confess that somehow I had confused the
term to be timing standard; which would be an entirely different thing.
But, this is time-nuts, so I should have realized...
Anyway, is there a standard, or at least an accepted practice, for how
holdover is handled in a time standard?


There are many ways how to do that and which one you choose depends
on the application and its requirements. You can find everything between
"jump imediatly" and "just keep the frequency stable and don't care about
alignment".

   Attila Kinali


___
time-nuts mailing list -- time-nuts@febo.com <mailto: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] Holdover

[Bob Stewart]

Thanks Magnus!

These look like good guidelines.  I'll see what I can come up with.
Bob
 -
AE6RV.com

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

  From: Magnus Danielson <mag...@rubidium.dyndns.org>
 To: time-nuts@febo.com 
Cc: mag...@rubidium.se
 Sent: Tuesday, August 16, 2016 6:49 PM
 Subject: Re: [time-nuts] Holdover
   
Bob,

On 08/16/2016 11:31 PM, Bob Stewart wrote:
> Hi Attila,
> In my unit, which is a frequency standard, I chose to tell the receiver to 
> stop sending 1PPS pulses when it loses sync to the sats.  And since the 1PPS 
> is no longer coming, the PLL does nothing and the DAC doesn't change.  (Let's 
> avoid the question of aging correction for now.)  So, I'm wondering where to 
> go and what to do if I want to get time from my unit.  Clearly I could just 
> tell the receiver to continue to send 1PPS pulses and sync to those - marking 
> the time as unreliable.  When the receiver synced back up, then it would warp 
> the time output, the 1PPS would warp in phase, and the PLL would correct the 
> phase error.
>
> So, that's one way, but probably not a desirable way.  My interest was in the 
> option of using the OCXO to create the time, which clearly gives a better 
> option when the receiver syncs back up to the sats.  Is there a published 
> standard for this, or is this something that everyone (except the newbie) 
> knows so well that it's not worth discussing?

There is no standard, but a few basic ways to go about which seems 
reasonable and used by most is:

1) As you go into hold-over, keep producing PPS etc
2) As you leave hold-over, attempt to adjust the phase back.
3) If your system been in hold-over for a longer time, say that it 
reasonably deviates outside of +/- 10 us (or some other limit), alarm 
and turn output off

I have selected a somewhat more intricate setup in which you can set a 
re-assignment limit, so when the phase error is outside of that limit, 
you turn the output off, jumps the phase difference, and then starts to 
track in from there. The reason being that at some time deviation, the 
time it takes to track in the phase error is too large to be practical 
so turning of and jump has less impact.

Cheers,
Magnus

> Bob
>  -
> AE6RV.com
>
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>
>      From: Attila Kinali <att...@kinali.ch>
>  To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
>measurement <time-nuts@febo.com>
>  Sent: Tuesday, August 16, 2016 3:46 PM
>  Subject: Re: [time-nuts] Holdover
>
> On Tue, 16 Aug 2016 04:35:40 + (UTC)
> Bob Stewart <b...@evoria.net> wrote:
>
>> It's been pointed out to me that I didn't understand the function of
>> the 1PPS of a time standard.  I confess that somehow I had confused the
>> term to be timing standard; which would be an entirely different thing.
>> But, this is time-nuts, so I should have realized...
>> Anyway, is there a standard, or at least an accepted practice, for how
>> holdover is handled in a time standard?
>
> There are many ways how to do that and which one you choose depends
> on the application and its requirements. You can find everything between
> "jump imediatly" and "just keep the frequency stable and don't care about
> alignment".
>
>                Attila Kinali
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


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

Re: [time-nuts] Holdover

[Chris Albertson]

What to do during and right after holdover depends on the reason you have a
time standard.  If it is for maintaining a lab standard, then just shut
down as you can't perform your primary function.  It you have this standard
because you are required to time stamp financial transactions then you have
to keep going until you estimate some error threshold then stop.  If you
are using it to aim a telescope then again, stop using it the estimated
error is enough that you'd miss your targets.It depends on the use case.

I remember aiming a telescope when our best source of time was NTP over a
dial-up phone modem in the days before always-on Internet  This was in the
1980's and it worked well enough.  The normal case was "outage" as the
modem connection was short and only a few times per day.  But was good
enough to re-calibrate a local  clock

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

[Mark Sims]

The Trimble GPSDOs and most of the SCPI ones (like the Z3801A) have "jam sync" 
commands that force the receiver to do an immediate time sync (the Z3801A 
requires the device to be in holdover before it will accept a jam sync).  Some 
also have commands where you an also specify thresholds where the receiver 
alarms and/or does an automatic jam sync and thresholds for loss-of-signal time 
before the device goes into holdover mode.

---

I have selected a somewhat more intricate setup in which you can set a 
re-assignment limit, so when the phase error is outside of that limit, 
you turn the output off, jumps the phase difference, and then starts to 
track in from there. The reason being that at some time deviation, the 
time it takes to track in the phase error is too large to be practical 
so turning of and jump has less impact.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover

[Magnus Danielson]

Bob,

On 08/16/2016 11:31 PM, Bob Stewart wrote:

Hi Attila,
In my unit, which is a frequency standard, I chose to tell the receiver to stop 
sending 1PPS pulses when it loses sync to the sats.  And since the 1PPS is no 
longer coming, the PLL does nothing and the DAC doesn't change.  (Let's avoid 
the question of aging correction for now.)  So, I'm wondering where to go and 
what to do if I want to get time from my unit.  Clearly I could just tell the 
receiver to continue to send 1PPS pulses and sync to those - marking the time 
as unreliable.  When the receiver synced back up, then it would warp the time 
output, the 1PPS would warp in phase, and the PLL would correct the phase error.

So, that's one way, but probably not a desirable way.  My interest was in the 
option of using the OCXO to create the time, which clearly gives a better 
option when the receiver syncs back up to the sats.  Is there a published 
standard for this, or is this something that everyone (except the newbie) knows 
so well that it's not worth discussing?


There is no standard, but a few basic ways to go about which seems 
reasonable and used by most is:


1) As you go into hold-over, keep producing PPS etc
2) As you leave hold-over, attempt to adjust the phase back.
3) If your system been in hold-over for a longer time, say that it 
reasonably deviates outside of +/- 10 us (or some other limit), alarm 
and turn output off


I have selected a somewhat more intricate setup in which you can set a 
re-assignment limit, so when the phase error is outside of that limit, 
you turn the output off, jumps the phase difference, and then starts to 
track in from there. The reason being that at some time deviation, the 
time it takes to track in the phase error is too large to be practical 
so turning of and jump has less impact.


Cheers,
Magnus


Bob
 -
AE6RV.com

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

  From: Attila Kinali <att...@kinali.ch>
 To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
measurement <time-nuts@febo.com>
 Sent: Tuesday, August 16, 2016 3:46 PM
 Subject: Re: [time-nuts] Holdover

On Tue, 16 Aug 2016 04:35:40 + (UTC)
Bob Stewart <b...@evoria.net> wrote:


It's been pointed out to me that I didn't understand the function of
the 1PPS of a time standard.  I confess that somehow I had confused the
term to be timing standard; which would be an entirely different thing.
But, this is time-nuts, so I should have realized...
Anyway, is there a standard, or at least an accepted practice, for how
holdover is handled in a time standard?


There are many ways how to do that and which one you choose depends
on the application and its requirements. You can find everything between
"jump imediatly" and "just keep the frequency stable and don't care about
alignment".

Attila Kinali


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

Re: [time-nuts] Holdover

[Bob Stewart]

Hi Attila,
said "Ie you need to figure out what you want to do with those PPS, then figure 
out what the desired behaviour during hold-over and recovery is and from that 
you can design the frequency standard."
What is the most usual method for *time standards*?  I'm satisfied with how my 
unit works as a frequency standard.
Bob
 -
AE6RV.com

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

  From: Attila Kinali <att...@kinali.ch>
 To: Bob Stewart <b...@evoria.net> 
Cc: Discussion of Precise Time and Frequency Measurement <time-nuts@febo.com>
 Sent: Tuesday, August 16, 2016 4:37 PM
 Subject: Re: [time-nuts] Holdover
   
On Tue, 16 Aug 2016 21:31:17 + (UTC)
Bob Stewart <b...@evoria.net> wrote:

> So, that's one way, but probably not a desirable way.  My interest was in 
> the option of using the OCXO to create the time, which clearly gives a 
> better option when the receiver syncs back up to the sats.  Is there a 
> published standard for this, or is this something that everyone (except the 
> newbie) knows so well that it's not worth discussing?

No, there is no standard[1]. A system like this is always tailored to
the consumer of the PPS pulses and its requirements. Ie you need to
figure out what you want to do with those PPS, then figure out what
the desired behaviour during hold-over and recovery is and from that
you can design the frequency standard.

            Attila Kinali 


[1] https://m.xkcd.com/927/

-- 
Malek's Law:
        Any simple idea will be worded in the most complicated way.

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

Re: [time-nuts] Holdover

[Bob Stewart]

Hi Attila,
In my unit, which is a frequency standard, I chose to tell the receiver to stop 
sending 1PPS pulses when it loses sync to the sats.  And since the 1PPS is no 
longer coming, the PLL does nothing and the DAC doesn't change.  (Let's avoid 
the question of aging correction for now.)  So, I'm wondering where to go and 
what to do if I want to get time from my unit.  Clearly I could just tell the 
receiver to continue to send 1PPS pulses and sync to those - marking the time 
as unreliable.  When the receiver synced back up, then it would warp the time 
output, the 1PPS would warp in phase, and the PLL would correct the phase 
error.  

So, that's one way, but probably not a desirable way.  My interest was in the 
option of using the OCXO to create the time, which clearly gives a better 
option when the receiver syncs back up to the sats.  Is there a published 
standard for this, or is this something that everyone (except the newbie) knows 
so well that it's not worth discussing?

Bob
 -
AE6RV.com

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

  From: Attila Kinali <att...@kinali.ch>
 To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
measurement <time-nuts@febo.com> 
 Sent: Tuesday, August 16, 2016 3:46 PM
 Subject: Re: [time-nuts] Holdover
   
On Tue, 16 Aug 2016 04:35:40 + (UTC)
Bob Stewart <b...@evoria.net> wrote:

> It's been pointed out to me that I didn't understand the function of
> the 1PPS of a time standard.  I confess that somehow I had confused the
> term to be timing standard; which would be an entirely different thing. 
> But, this is time-nuts, so I should have realized...
> Anyway, is there a standard, or at least an accepted practice, for how 
> holdover is handled in a time standard?  

There are many ways how to do that and which one you choose depends
on the application and its requirements. You can find everything between
"jump imediatly" and "just keep the frequency stable and don't care about
alignment".

                Attila Kinali

-- 
Malek's Law:
        Any simple idea will be worded in the most complicated way.

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

Re: [time-nuts] Holdover

[Attila Kinali]

On Tue, 16 Aug 2016 21:31:17 + (UTC)
Bob Stewart  wrote:

> So, that's one way, but probably not a desirable way.  My interest was in 
> the option of using the OCXO to create the time, which clearly gives a 
> better option when the receiver syncs back up to the sats.  Is there a 
> published standard for this, or is this something that everyone (except the 
> newbie) knows so well that it's not worth discussing?

No, there is no standard[1]. A system like this is always tailored to
the consumer of the PPS pulses and its requirements. Ie you need to
figure out what you want to do with those PPS, then figure out what
the desired behaviour during hold-over and recovery is and from that
you can design the frequency standard.

Attila Kinali 


[1] https://m.xkcd.com/927/

-- 
Malek's Law:
Any simple idea will be worded in the most complicated way.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover

[Attila Kinali]

On Tue, 16 Aug 2016 04:35:40 + (UTC)
Bob Stewart  wrote:

> It's been pointed out to me that I didn't understand the function of
> the 1PPS of a time standard.  I confess that somehow I had confused the
> term to be timing standard; which would be an entirely different thing. 
> But, this is time-nuts, so I should have realized...
> Anyway, is there a standard, or at least an accepted practice, for how 
> holdover is handled in a time standard?  

There are many ways how to do that and which one you choose depends
on the application and its requirements. You can find everything between
"jump imediatly" and "just keep the frequency stable and don't care about
alignment".

Attila Kinali

-- 
Malek's Law:
Any simple idea will be worded in the most complicated way.
___
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] Holdover

[Bob Stewart]

It's been pointed out to me that I didn't understand the function of the 1PPS 
of a time standard.  I confess that somehow I had confused the term to be 
timing standard; which would be an entirely different thing.  But, this is 
time-nuts, so I should have realized...
Anyway, is there a standard, or at least an accepted practice, for how holdover 
is handled in a time standard?  Not "how it's done", as in algorithms, but what 
is expected by the user.  I can see at least 2 ways: time warping (which would 
be especially bad if the time standard had gotten ahead in time) and nudging 
back to the correct time.  The case of warping is obvious.  But, are there 
other methods, and is there some standard for how quickly the time output of 
the time standard, and of course the 1PPS pulse, is nudged back to the correct 
time?
Bob - AE6RV
 -
AE6RV.com

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

Re: [time-nuts] Holdover recovery

[Azelio Boriani]

Yes, very interesting, good to have. I see differences: the most
notable is the plot of page 12 on the original italian version that is
missing on the ITU paper, that goes with the figure 4 on page 7 (of
the ITU one).

On Tue, Apr 5, 2016 at 12:57 AM, Magnus Danielson
 wrote:
> Hi,
>
> I had not seen the ITU-R version, nice.
> I have their paper and shared it with Hal on the side.
>
> This ITU-R version seems about the same, but I've got their names on it. I
> got a copy of their paper in english without their names on it, which might
> have been their input contribution to ITU-R. I then demanded a version with
> their names on it, so that I could share it, within a day I had that. When
> someone covered this aspect, why not spread it and they get the credit for
> it?
>
> I've visited them and seen this setup.
>
> Cheers,
> Magnus - who just got back to lodging/dorm-room after discussing things with
> Attila
>
>
> On 04/05/2016 12:01 AM, Logan Cummings wrote:
>>
>> My Italian is not very good, but I think this is the English translation
>> via ITU:
>>
>> https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2253-2012-PDF-E.pdf
>>
>> -Logan
>>
>> On Mon, Apr 4, 2016 at 1:10 PM,  wrote:
>>
>>> Here the italian version:
>>>
>>> http://www.crit.rai.it/eletel/2012-1/121-2.pdf
>>>
>>> Luciano
>>> www.timeok.it
>>>
>>>
>>> On Mon 04/04/16 21:28 , Magnus Danielson 
>>> wrote:
>>>
 Hi Hal,

 On 04/04/2016 05:39 AM, Hal Murray wrote:
>
>
> Has anybody studied what happens when a GPSDO comes out of holdover?
>>>
>>> Has
>
> anybody seen any specs? I don't think I have.
>
> I think you have a choice of quick recovery for time or frequency, but

 you
>
> can't get both.
>
> Suppose your setup has been in holdover for a while. The frequency is
> slightly off. The time offset of the PPS pulse will be the integral of

 the
>
> frequency offset.
>
> What happens when you come out of holdover? If you fix the frequency,

 the
>
> PPS will stay off.
>
> Suppose the PPS has drifted by 1 ns. If you correct that in 1 second,

 the
>
> frequency will need to be off by 1E9 during that second.


 The RAI laboratory in Torino have made such tests and published
 measurements and recommendations. For a long time it was only available
 in italian, but there is now an english version available.

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



 Links:
 --
 [1]

>>>
>>> http://webmail.timeok.it/parse.php?redirect=https://www.febo.com/cgi-bin/ma

 ilman/listinfo/time-nuts

>>> Message sent via Atmail Open - http://atmail.org/
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover recovery

[Magnus Danielson]

Hi,

I had not seen the ITU-R version, nice.
I have their paper and shared it with Hal on the side.

This ITU-R version seems about the same, but I've got their names on it. 
I got a copy of their paper in english without their names on it, which 
might have been their input contribution to ITU-R. I then demanded a 
version with their names on it, so that I could share it, within a day I 
had that. When someone covered this aspect, why not spread it and they 
get the credit for it?


I've visited them and seen this setup.

Cheers,
Magnus - who just got back to lodging/dorm-room after discussing things 
with Attila


On 04/05/2016 12:01 AM, Logan Cummings wrote:

My Italian is not very good, but I think this is the English translation
via ITU:

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2253-2012-PDF-E.pdf

-Logan

On Mon, Apr 4, 2016 at 1:10 PM,  wrote:


Here the italian version:

http://www.crit.rai.it/eletel/2012-1/121-2.pdf

Luciano
www.timeok.it


On Mon 04/04/16 21:28 , Magnus Danielson 
wrote:


Hi Hal,

On 04/04/2016 05:39 AM, Hal Murray wrote:


Has anybody studied what happens when a GPSDO comes out of holdover?

Has

anybody seen any specs? I don't think I have.

I think you have a choice of quick recovery for time or frequency, but

you

can't get both.

Suppose your setup has been in holdover for a while. The frequency is
slightly off. The time offset of the PPS pulse will be the integral of

the

frequency offset.

What happens when you come out of holdover? If you fix the frequency,

the

PPS will stay off.

Suppose the PPS has drifted by 1 ns. If you correct that in 1 second,

the

frequency will need to be off by 1E9 during that second.


The RAI laboratory in Torino have made such tests and published
measurements and recommendations. For a long time it was only available
in italian, but there is now an english version available.

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



Links:
--
[1]


http://webmail.timeok.it/parse.php?redirect=https://www.febo.com/cgi-bin/ma

ilman/listinfo/time-nuts


Message sent via Atmail Open - http://atmail.org/
___
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] Holdover recovery

[Bob Camp]

Hi

On a surplus cell phone GPSDO it’s going to be:

1) System has been down for a while (= something failed) 
2) System is now working ( = something was fixed)
3) The primary system spec must now be met (+/- 100 ns time alignment).
4) The secondary system spec should be met (+/- 5x10^-8 frequency) 
5) Get it done now.

Both the time alignment and frequency specs are highly system dependent. The 
time
offset is likely to be aligned in a modulo 100 ns step. It then is fine tuned 
over some 
time period to take out the rest of the error. If it’s done over a 50 second 
period, they
can do it at a 1x10^-9 frequency offset (but probably don’t …. more likely it’s 
a higher 
offset at the start of the period).

Bob


> On Apr 3, 2016, at 11:39 PM, Hal Murray  wrote:
> 
> 
> Has anybody studied what happens when a GPSDO comes out of holdover?  Has 
> anybody seen any specs?  I don't think I have.
> 
> I think you have a choice of quick recovery for time or frequency, but you 
> can't get both.
> 
> Suppose your setup has been in holdover for a while.  The frequency is 
> slightly off.  The time offset of the PPS pulse will be the integral of the 
> frequency offset.
> 
> What happens when you come out of holdover?  If you fix the frequency, the 
> PPS will stay off.
> 
> Suppose the PPS has drifted by 1 ns.  If you correct that in 1 second, the 
> frequency will need to be off by 1E9 during that second.
> 
> 
> -- 
> 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] Holdover recovery

[Logan Cummings]

My Italian is not very good, but I think this is the English translation
via ITU:

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2253-2012-PDF-E.pdf

-Logan

On Mon, Apr 4, 2016 at 1:10 PM,  wrote:

> Here the italian version:
>
> http://www.crit.rai.it/eletel/2012-1/121-2.pdf
>
> Luciano
> www.timeok.it
>
>
> On Mon 04/04/16 21:28 , Magnus Danielson 
> wrote:
>
> > Hi Hal,
> >
> > On 04/04/2016 05:39 AM, Hal Murray wrote:
> > >
> > > Has anybody studied what happens when a GPSDO comes out of holdover?
> Has
> > > anybody seen any specs? I don't think I have.
> > >
> > > I think you have a choice of quick recovery for time or frequency, but
> > you
> > > can't get both.
> > >
> > > Suppose your setup has been in holdover for a while. The frequency is
> > > slightly off. The time offset of the PPS pulse will be the integral of
> > the
> > > frequency offset.
> > >
> > > What happens when you come out of holdover? If you fix the frequency,
> > the
> > > PPS will stay off.
> > >
> > > Suppose the PPS has drifted by 1 ns. If you correct that in 1 second,
> > the
> > > frequency will need to be off by 1E9 during that second.
> >
> > The RAI laboratory in Torino have made such tests and published
> > measurements and recommendations. For a long time it was only available
> > in italian, but there is now an english version available.
> >
> > Cheers,
> > Magnus
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [1]
> > and follow the instructions there.
> >
> >
> >
> > Links:
> > --
> > [1]
> >
> http://webmail.timeok.it/parse.php?redirect=https://www.febo.com/cgi-bin/ma
> > ilman/listinfo/time-nuts
> >
> Message sent via Atmail Open - http://atmail.org/
> ___
> 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] Holdover recovery

[Azelio Boriani]

The only english text I'm able to find is:

Analysis of the GPS frequency reference stability

Laboratory analysis of the dynamic
behaviour of some GPS receivers has
allowed to identify a criticality in their
use as ‘clocks’ to synchronize DVB-T
SFN networks. To fix this criticality, the
Research Centre has defined a new criterion
for the design of GPS equipment
for use in broadcasting applications.
This criterion is proposed as an Italian
contribution to the ITU


On Mon, Apr 4, 2016 at 10:10 PM,   wrote:
> Here the italian version:
>
> http://www.crit.rai.it/eletel/2012-1/121-2.pdf
>
> Luciano
> www.timeok.it
>
>
> On Mon 04/04/16 21:28 , Magnus Danielson  wrote:
>
>> Hi Hal,
>>
>> On 04/04/2016 05:39 AM, Hal Murray wrote:
>> >
>> > Has anybody studied what happens when a GPSDO comes out of holdover? Has
>> > anybody seen any specs? I don't think I have.
>> >
>> > I think you have a choice of quick recovery for time or frequency, but
>> you
>> > can't get both.
>> >
>> > Suppose your setup has been in holdover for a while. The frequency is
>> > slightly off. The time offset of the PPS pulse will be the integral of
>> the
>> > frequency offset.
>> >
>> > What happens when you come out of holdover? If you fix the frequency,
>> the
>> > PPS will stay off.
>> >
>> > Suppose the PPS has drifted by 1 ns. If you correct that in 1 second,
>> the
>> > frequency will need to be off by 1E9 during that second.
>>
>> The RAI laboratory in Torino have made such tests and published
>> measurements and recommendations. For a long time it was only available
>> in italian, but there is now an english version available.
>>
>> Cheers,
>> Magnus
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [1]
>> and follow the instructions there.
>>
>>
>>
>> Links:
>> --
>> [1]
>> http://webmail.timeok.it/parse.php?redirect=https://www.febo.com/cgi-bin/ma
>> ilman/listinfo/time-nuts
>>
> Message sent via Atmail Open - http://atmail.org/
> ___
> 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] Holdover recovery

[timeok]

Here the italian version:

http://www.crit.rai.it/eletel/2012-1/121-2.pdf

Luciano
www.timeok.it


On Mon 04/04/16 21:28 , Magnus Danielson  wrote:

> Hi Hal,
> 
> On 04/04/2016 05:39 AM, Hal Murray wrote:
> >
> > Has anybody studied what happens when a GPSDO comes out of holdover? Has
> > anybody seen any specs? I don't think I have.
> >
> > I think you have a choice of quick recovery for time or frequency, but
> you
> > can't get both.
> >
> > Suppose your setup has been in holdover for a while. The frequency is
> > slightly off. The time offset of the PPS pulse will be the integral of
> the
> > frequency offset.
> >
> > What happens when you come out of holdover? If you fix the frequency,
> the
> > PPS will stay off.
> >
> > Suppose the PPS has drifted by 1 ns. If you correct that in 1 second,
> the
> > frequency will need to be off by 1E9 during that second.
> 
> The RAI laboratory in Torino have made such tests and published 
> measurements and recommendations. For a long time it was only available 
> in italian, but there is now an english version available.
> 
> Cheers,
> Magnus
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [1]
> and follow the instructions there.
> 
> 
> 
> Links:
> --
> [1]
> http://webmail.timeok.it/parse.php?redirect=https://www.febo.com/cgi-bin/ma
> ilman/listinfo/time-nuts
> 
Message sent via Atmail Open - http://atmail.org/
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover recovery

[Azelio Boriani]

In italian:

Can't find it in english...

On Mon, Apr 4, 2016 at 9:28 PM, Magnus Danielson
 wrote:
> Hi Hal,
>
> On 04/04/2016 05:39 AM, Hal Murray wrote:
>>
>>
>> Has anybody studied what happens when a GPSDO comes out of holdover?  Has
>> anybody seen any specs?  I don't think I have.
>>
>> I think you have a choice of quick recovery for time or frequency, but you
>> can't get both.
>>
>> Suppose your setup has been in holdover for a while.  The frequency is
>> slightly off.  The time offset of the PPS pulse will be the integral of
>> the
>> frequency offset.
>>
>> What happens when you come out of holdover?  If you fix the frequency, the
>> PPS will stay off.
>>
>> Suppose the PPS has drifted by 1 ns.  If you correct that in 1 second, the
>> frequency will need to be off by 1E9 during that second.
>
>
> The RAI laboratory in Torino have made such tests and published measurements
> and recommendations. For a long time it was only available in italian, but
> there is now an english version available.
>
> 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 mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover recovery

[Magnus Danielson]

Hi Hal,

On 04/04/2016 05:39 AM, Hal Murray wrote:


Has anybody studied what happens when a GPSDO comes out of holdover?  Has
anybody seen any specs?  I don't think I have.

I think you have a choice of quick recovery for time or frequency, but you
can't get both.

Suppose your setup has been in holdover for a while.  The frequency is
slightly off.  The time offset of the PPS pulse will be the integral of the
frequency offset.

What happens when you come out of holdover?  If you fix the frequency, the
PPS will stay off.

Suppose the PPS has drifted by 1 ns.  If you correct that in 1 second, the
frequency will need to be off by 1E9 during that second.


The RAI laboratory in Torino have made such tests and published 
measurements and recommendations. For a long time it was only available 
in italian, but there is now an english version available.


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.

Re: [time-nuts] Holdover recovery

[jimlux]

On 4/3/16 8:39 PM, Hal Murray wrote:


Has anybody studied what happens when a GPSDO comes out of holdover?  Has
anybody seen any specs?  I don't think I have.

I think you have a choice of quick recovery for time or frequency, but you
can't get both.

Suppose your setup has been in holdover for a while.  The frequency is
slightly off.  The time offset of the PPS pulse will be the integral of the
frequency offset.

What happens when you come out of holdover?  If you fix the frequency, the
PPS will stay off.

Suppose the PPS has drifted by 1 ns.  If you correct that in 1 second, the
frequency will need to be off by 1E9 during that second.



This is something we've been developing some algorithms for. (and I 
think NTP does this already).. depending on whether you were high or low 
in frequency, you need to smoothly bring the frequency back, with some 
overshoot (to "catch up").


I think it really boils down so some simple requirements:

Time (aka phase) must always be monotonically increasing
Time and frequency (which is the derivative of time) and some number of 
higher order derivatives must be continuous.

The maximum error is bounded to some number.



As you've noted, going for the minimum error in time might lead to a 
discontinuity in frequency.


We have an interesting problem in that we want to discipline a clock 
which is inherently of high accuracy to a reference that is poorer in 
accuracy, but which is defined as the "master" so we need to follow it. 
 The usual NTP and similar time discipline algorithms are really 
predicated on a "flow down" from more accurate to less accurate.



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

Re: [time-nuts] Holdover recovery

[Mike Cook]

> Le 4 avr. 2016 à 05:39, Hal Murray  a écrit :
> 
> 
> Has anybody studied what happens when a GPSDO comes out of holdover?  Has 
> anybody seen any specs?  I don't think I have.
> 
> I think you have a choice of quick recovery for time or frequency, but you 
> can't get both.
> 
> Suppose your setup has been in holdover for a while.  The frequency is 
> slightly off.  The time offset of the PPS pulse will be the integral of the 
> frequency offset.
> 
> What happens when you come out of holdover?  If you fix the frequency, the 
> PPS will stay off.
> 
> Suppose the PPS has drifted by 1 ns.  If you correct that in 1 second, the 
> frequency will need to be off by 1E9 during that second.
> 

I guess it is implementation dependent. I have observed this on Tbolt and PRS10 
a while back but the graphs have transformed into unfindium.
Something else on the redo list. I think what really happens is that the PPS 
lock is made on the nearest cycle when the GPS signal is recovered and then the 
frequency is adjusted using subsequent GPS data according to whatever the 
PLL/FLL constants were in effect at the time. So getting back to correct 
frequency could take a long time.

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

"The main function of a modern police force is filling in forms."
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Holdover recovery

[Tim Shoppa]

The chinese GPSDO's famous on E-bay are not really phase locked to begin
with, they are only frequency locked and often with a small frequency
offset. I don't think any of your questions apply to this kind of unit. See
e.g. http://www.ke5fx.com/gpscomp.htm

Units that have been spec'ed for holdover in terms of time delta, make
phase the number one priority and will gladly "oversteer" frequency to get
the phase to match back up after holdover and then settling down again,.
e.g. http://leapsecond.com/pages/z3801a-efc/

In recovery from a holdover where something went clearly wrong - the
holdover specs of the unit were greatly exceeded - they declare themselves
unlocked, and will do a phase jump and enter a "frequency lock" mode until
oscillator parameters are relearned and they again declare themselves
locked.

Tim N3QE

On Sun, Apr 3, 2016 at 11:39 PM, Hal Murray  wrote:

>
> Has anybody studied what happens when a GPSDO comes out of holdover?  Has
> anybody seen any specs?  I don't think I have.
>
> I think you have a choice of quick recovery for time or frequency, but you
> can't get both.
>
> Suppose your setup has been in holdover for a while.  The frequency is
> slightly off.  The time offset of the PPS pulse will be the integral of the
> frequency offset.
>
> What happens when you come out of holdover?  If you fix the frequency, the
> PPS will stay off.
>
> Suppose the PPS has drifted by 1 ns.  If you correct that in 1 second, the
> frequency will need to be off by 1E9 during that second.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Holdover recovery

[Hal Murray]

Has anybody studied what happens when a GPSDO comes out of holdover?  Has 
anybody seen any specs?  I don't think I have.

I think you have a choice of quick recovery for time or frequency, but you 
can't get both.

Suppose your setup has been in holdover for a while.  The frequency is 
slightly off.  The time offset of the PPS pulse will be the integral of the 
frequency offset.

What happens when you come out of holdover?  If you fix the frequency, the 
PPS will stay off.

Suppose the PPS has drifted by 1 ns.  If you correct that in 1 second, the 
frequency will need to be off by 1E9 during that second.


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