Discipline a rubidium driven net4501 with a Garmin LVC 18?

[Christian C. Gruber]

Hi,

out of curiosity I want to build a ntp timeserver. I can remember some
epxerimets I carried out with a DCF77 receiver and a Cobalt Qube years
ago, however this never really worked out.

My plan is to buy a soekris net4501
(http://soekris.eu/shop/net4501/net4501_30_board_only_en.html) and
modify it to use a 10MHz signal from a rubidium source via a clock-block
(http://www.tapr.org/kits_clock-block.html). I read that a rubidium
source is not really necessary, but since I'm a chemist I'd like to have
something "atomic" in there that keeps my time when the GPS satellites
drop from the sky. I found some tested rubidium sources at
http://www.tenmhz.com/LPRO.htm, does anyone have experience with this
seller? Are these units better than the one from China sold on eBay?

Furthermore I'd like to get a 1PPS input from GPS as others already did.
However, I would like to use one of these Garmin GPS 18 LVC units (as on
http://time.qnan.org/) that usually work fine and provide a 1PPS signal
together with a NMEA output and connect it to the net4501 internal
serial port instead of the FatPPS (as John did:
http://www.febo.com/pages/soekris/). Is there a way to get
Poul-Hennings`s NTPns working with the GPS 18 as a PPS source?

Is there any specific reason why a 1PPS signal from another source (like
a Thunderbolt GPS disciplined clock) together with a FatPPS board would
give better results as my Garmin approach?

Altogether, this would cost about 450EUR [129EUR (net4501) + 49EUR
(clock-block) + 176EUR (rubidium standard) + 100EUR (used Garmin GPS 18
LVC)] excl. shipping and small stuff for a rather good time server, what
do you think?

Best regards and thanks for your help,
Christian

--
Christian C. Gruber
cg-p4IKZgolXtbQT0dZR+***@public.gmane.org

[Mark Sims]

Many...  but a lot boils down to the fact that the Tbolt is designed from the ground up to be a time (and frequency) source.  Its 1PPS output can be stable to within a few nanoseconds and the frequency to a few parts per trillion.  The Garmin 1PPS output is spec'd at 1 microsecond,  plus you get no frequency source.

The LPRO seller is almost certainly getting his LPROs from the Chinese recyclers,  just like everybody else.  You can get a complete LPRO kit delivered to Germany for $80 (or less).  Tbolts for a few dollars more.  Ebay is your friend.

Search for RUBIDIUM and you will also find a guy selling a divider card that takes the LPRO output and generates several clocks,  including 1 Hz...  cheaper and more versatile than the FATPPS



-----------------------------
Is there any specific reason why a 1PPS signal from another source (like
a Thunderbolt GPS disciplined clock) together with a FatPPS board would
give better results as my Garmin approach?

[Mark Sims]

While checking on the current Tbolt prices,  I noticed some guy was selling a complete (receiver+antenna+supply) Trimble kit for $1500 plus shipping...  and two people have already bought them!  And these probably don't have the good oscillator.  Will wonders never cease?

The next highest kit was $250,  with others available for $160 (Buy-It-Now).  Checking completed auctions,  they actually sell for $130 to $160 with shipping included.

----------------------------------------

[Jason Rabel]

Nothing wrong with wanting to use a Rb as the clock source for the board. I *almost* decided to go that route since I had a spare
LPRO sitting around. But I realized that I would never need that long of hold-over so it would kind of be a waste. I've been looking
at some cheap ($20 USD) 1PPM TCXO on ebay... Which would be a decent upgrade from the stock crystal rated at 50PPM.

> Furthermore I'd like to get a 1PPS input from GPS as others already did.
> However, I would like to use one of these Garmin GPS 18 LVC units (as on
> http://time.qnan.org/) that usually work fine and provide a 1PPS signal
> together with a NMEA output and connect it to the net4501 internal
> serial port instead of the FatPPS (as John did:
> http://www.febo.com/pages/soekris/). Is there a way to get
> Poul-Hennings`s NTPns working with the GPS 18 as a PPS source?

I'm not 100% sure, but I *think* there is a basic PPS driver with NTPns? On my box I set the course time on boot-up via ntpdate,
then when NTPns starts it has something decent to work with (if the time is too far off I think it throws an alarm).

You can get Motorola Oncore UT+ or even M12+T receivers on eBay relatively cheap. With a little effort they *will* fix inside the
soekris box so you can just have a connector on the back for your antenna. The UT+ receivers *will* work with NTPns.

You can checkout my first build here:
http://www.extremeoverclocking.com/articles/howto/Building_S1_NTP_Server_1.html

> Is there any specific reason why a 1PPS signal from another source (like
> a Thunderbolt GPS disciplined clock) together with a FatPPS board would
> give better results as my Garmin approach?

I *think* the PPS output from a Thunderbolt is not the raw GPS PPS but rather a deterministic one? Someone will have to verify /
debunk that though. However you are also kind of doubling up on the oscillators since when a Thunderbolt looses signal it will
flywheel off it's internal OCXO.

I have a pre-built image of NanoBSD w/NTPns (and I think regular NTP is on there too) that I did a while back, feel free to give it
a whirl:

http://www.rabel.org/ntpns/ntpns_NanoBSD_7.tar.bz2

You might have to change some of the startup paramaters & ntpns configurations depending on how you wire up everything to the GPIO
pins and whatnot.

[e***@public.gmane.org]

Hi Jason,

Have a look on ebay.....280567398921.....
quite good TCXO.

Rgds Ernie.







-----Original Message-----
From: Jason Rabel <jason-dHZPyzGKGX5sbwx/***@public.gmane.org>
To: time-nuts-***@public.gmane.org
Sent: Fri, Oct 15, 2010 9:10 pm
Subject: Re: [time-nuts] Discipline a rubidium driven net4501 with a Garmin LVC 18?


Nothing wrong with wanting to use a Rb as the clock source for the board. I
almost* decided to go that route since I had a spare
PRO sitting around. But I realized that I would never need that long of
old-over so it would kind of be a waste. I've been looking
t some cheap ($20 USD) 1PPM TCXO on ebay... Which would be a decent upgrade
rom the stock crystal rated at 50PPM.
> Furthermore I'd like to get a 1PPS input from GPS as others already did.
However, I would like to use one of these Garmin GPS 18 LVC units (as on
http://time.qnan.org/) that usually work fine and provide a 1PPS signal
together with a NMEA output and connect it to the net4501 internal
serial port instead of the FatPPS (as John did:
http://www.febo.com/pages/soekris/). Is there a way to get
Poul-Hennings`s NTPns working with the GPS 18 as a PPS source?
I'm not 100% sure, but I *think* there is a basic PPS driver with NTPns? On my
ox I set the course time on boot-up via ntpdate,
hen when NTPns starts it has something decent to work with (if the time is too
ar off I think it throws an alarm).
You can get Motorola Oncore UT+ or even M12+T receivers on eBay relatively
heap. With a little effort they *will* fix inside the
oekris box so you can just have a connector on the back for your antenna. The
T+ receivers *will* work with NTPns.
You can checkout my first build here:
ttp://www.extremeoverclocking.com/articles/howto/Building_S1_NTP_Server_1.html
> Is there any specific reason why a 1PPS signal from another source (like
a Thunderbolt GPS disciplined clock) together with a FatPPS board would
give better results as my Garmin approach?
I *think* the PPS output from a Thunderbolt is not the raw GPS PPS but rather a
eterministic one? Someone will have to verify /
ebunk that though. However you are also kind of doubling up on the oscillators
ince when a Thunderbolt looses signal it will
lywheel off it's internal OCXO.
I have a pre-built image of NanoBSD w/NTPns (and I think regular NTP is on there
oo) that I did a while back, feel free to give it
whirl:
http://www.rabel.org/ntpns/ntpns_NanoBSD_7.tar.bz2
You might have to change some of the startup paramaters & ntpns configurations
epending on how you wire up everything to the GPIO
ins and whatnot.

_______________________________________________
ime-nuts mailing list -- time-nuts-***@public.gmane.org
o unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
nd follow the instructions there.

[Jason Rabel]

Sometimes when I see insanely high purchases for items when there are near-identical listings it makes me suspicious that perhaps
the buyer was using a second account to make a "fake" purchase. Possibly to either add more positive ratings or maybe artificially
make people think an item is worth that (over)value?

Jason


> While checking on the current Tbolt prices, I noticed some guy was selling a complete (receiver+antenna+supply) Trimble kit for
$1500 plus shipping... > and two people have already bought them! And these probably don't have the good oscillator. Will wonders
never cease?

> The next highest kit was $250, with others available for $160 (Buy-It-Now). Checking completed auctions, they actually sell for
$130 to $160 with
> shipping included.

[e***@public.gmane.org]

There is a second line Make Offer, maybe he sold three based on a reasonable offer. Bert Kehren





-----Original Message-----
From: Jason Rabel <jason-dHZPyzGKGX5sbwx/***@public.gmane.org>
To: time-nuts-***@public.gmane.org
Sent: Fri, Oct 15, 2010 3:38 pm
Subject: Re: [time-nuts] Is $1500 for a Thunderbolt a bit too much?


Sometimes when I see insanely high purchases for items when there are
ear-identical listings it makes me suspicious that perhaps
he buyer was using a second account to make a "fake" purchase. Possibly to
ither add more positive ratings or maybe artificially
ake people think an item is worth that (over)value?
Jason

While checking on the current Tbolt prices, I noticed some guy was selling a
omplete (receiver+antenna+supply) Trimble kit for
1500 plus shipping... > and two people have already bought them! And these
robably don't have the good oscillator. Will wonders
ever cease?
> The next highest kit was $250, with others available for $160 (Buy-It-Now).
hecking completed auctions, they actually sell for
130 to $160 with
shipping included.

______________________________________________
ime-nuts mailing list -- time-nuts-***@public.gmane.org
o unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
nd follow the instructions there.

[Charles P. Steinmetz]

Bert wrote:

>There is a second line Make Offer, maybe he sold three based on a
>reasonable offer.

The purchase history indicates that the 2 sales were at $1500 and the
seller has declined one offer and let 4 others expire.

Note that the listing is for a Thunderbolt E and a full "plug and
play" kit of ancillaries (including a crappy little wall wart power
supply) rather than the older, standard Thunderbolt that I believe
most of us have (not that I think that makes it worth $1500).

Best regards,

Charles

[Max Robinson]

Regards.

Max. K 4 O D S.

Email: max-1+***@public.gmane.org

Transistor site http://www.funwithtransistors.net
Vacuum tube site: http://www.funwithtubes.net
Music site: http://www.maxsmusicplace.com

To subscribe to the fun with transistors group send an email to.
funwithtransistors-subscribe-***@public.gmane.org

To subscribe to the fun with tubes group send an email to,
funwithtubes-subscribe-***@public.gmane.org

----- Original Message -----
From: "Jason Rabel" <jason-dHZPyzGKGX5sbwx/***@public.gmane.org>
To: <time-nuts-***@public.gmane.org>
Sent: Friday, October 15, 2010 2:38 PM
Subject: Re: [time-nuts] Is $1500 for a Thunderbolt a bit too much?


> Sometimes when I see insanely high purchases for items when there are
> near-identical listings it makes me suspicious that perhaps
> the buyer was using a second account to make a "fake" purchase. Possibly
> to either add more positive ratings or maybe artificially
> make people think an item is worth that (over)value?
>
> Jason
>
>
>> While checking on the current Tbolt prices, I noticed some guy was
>> selling a complete (receiver+antenna+supply) Trimble kit for
> $1500 plus shipping... > and two people have already bought them! And
> these probably don't have the good oscillator. Will wonders
> never cease?
>
>> The next highest kit was $250, with others available for $160
>> (Buy-It-Now). Checking completed auctions, they actually sell for
> $130 to $160 with
>> shipping included.
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>

[Max Robinson]

Sorry for the blank message. Think I clicked the wrong button.

Isn't anybody going to point out the elephant standing in the middle of the
room?

Jason wrote.

>> While checking on the current Tbolt prices, I noticed some guy was
>> selling a complete (receiver+antenna+supply) Trimble kit for
> $1500 plus shipping...
...
>> The next highest kit was $250,

If 250 is higher than 1500 then I must have forgotten something I learned in
school.

Max. K 4 O D S.

Email: max-1+***@public.gmane.org

Transistor site http://www.funwithtransistors.net
Vacuum tube site: http://www.funwithtubes.net
Music site: http://www.maxsmusicplace.com

To subscribe to the fun with transistors group send an email to.
funwithtransistors-subscribe-***@public.gmane.org

To subscribe to the fun with tubes group send an email to,
funwithtubes-subscribe-***@public.gmane.org

----- Original Message -----
From: "Jason Rabel" <jason-dHZPyzGKGX5sbwx/***@public.gmane.org>
To: <time-nuts-***@public.gmane.org>
Sent: Friday, October 15, 2010 2:38 PM
Subject: Re: [time-nuts] Is $1500 for a Thunderbolt a bit too much?


> Sometimes when I see insanely high purchases for items when there are
> near-identical listings it makes me suspicious that perhaps
> the buyer was using a second account to make a "fake" purchase. Possibly
> to either add more positive ratings or maybe artificially
> make people think an item is worth that (over)value?
>
> Jason
>
>
>> While checking on the current Tbolt prices, I noticed some guy was
>> selling a complete (receiver+antenna+supply) Trimble kit for
> $1500 plus shipping... > and two people have already bought them! And
> these probably don't have the good oscillator. Will wonders
> never cease?
>
>> The next highest kit was $250, with others available for $160
>> (Buy-It-Now). Checking completed auctions, they actually sell for
> $130 to $160 with
>> shipping included.
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>

[Charles P. Steinmetz]

Max wrote:

>>>The next highest kit was $250,
>
>If 250 is higher than 1500 then I must have forgotten something I
>learned in school.

Your math is fine -- it's English usage that you seem to have
forgotten. "Next highest" -- i.e., highest but for the one that was
initially identified as the highest. You seem to be thinking of "next higher."

Also, I don't believe it was Jason who posted the bit you quoted --
if memory serves, it was Mark.

Best regards,

Charles

[Hal Murray]

> Search for RUBIDIUM and you will also find a guy selling a divider card that
> takes the LPRO output and generates several clocks,  including 1 Hz...
>  cheaper and more versatile than the FATPPS

A 1 Hz clock derived from a rubidium isn't synchronized to UTC second ticks.

The PPS pulse out of a TBolt is only 10 microseconds wide. Some
hardware/software won't see that. The FATPPS makes that wide enough to work
with most setups. I used a diode + R + C kludge. It fits inside the TBolt.


--
These are my opinions, not necessarily my employer's. I hate spam.

[Richard W. Solomon]

Search ?? Where ?? Archives, Google, Evil Empire ...

73, Dick, W1KSZ


-----Original Message-----
>From: Hal Murray <***@megapathdsl.net>
>Sent: Oct 15, 2010 8:15 PM
>To: Discussion of precise time and frequency measurement <time-***@febo.com>
>Subject: Re: [time-nuts] Discipline a rubidium driven net4501 with a Garmin LVC 18?
>
>
>> Search for RUBIDIUM and you will also find a guy selling a divider card that
>> takes the LPRO output and generates several clocks,  including 1 Hz...
>>  cheaper and more versatile than the FATPPS
>
>A 1 Hz clock derived from a rubidium isn't synchronized to UTC second ticks.
>
>The PPS pulse out of a TBolt is only 10 microseconds wide. Some
>hardware/software won't see that. The FATPPS makes that wide enough to work
>with most setups. I used a diode + R + C kludge. It fits inside the TBolt.
>
>
>--
>These are my opinions, not necessarily my employer's. I hate spam.
>
>
>
>
>_______________________________________________
>time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/ti

[e***@public.gmane.org]

E-pay....


-----Original Message-----
From: Richard W. Solomon <w1ksz-***@public.gmane.org>
To: Discussion of precise time and frequency measurement <time-nuts-***@public.gmane.org>
Sent: Sat, Oct 16, 2010 8:47 pm
Subject: Re: [time-nuts] Discipline a rubidium driven net4501 with a Garmin LVC 18?


Search ?? Where ?? Archives, Google, Evil Empire ...
73, Dick, W1KSZ

----Original Message-----
From: Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org>
Sent: Oct 15, 2010 8:15 PM
To: Discussion of precise time and frequency measurement <time-nuts-***@public.gmane.org>
Subject: Re: [time-nuts] Discipline a rubidium driven net4501 with a Garmin LVC
8?


> Search for RUBIDIUM and you will also find a guy selling a divider card that
> takes the LPRO output and generates several clocks, including 1 Hz...
> cheaper and more versatile than the FATPPS

A 1 Hz clock derived from a rubidium isn't synchronized to UTC second ticks.

The PPS pulse out of a TBolt is only 10 microseconds wide. Some
hardware/software won't see that. The FATPPS makes that wide enough to work
with most setups. I used a diode + R + C kludge. It fits inside the TBolt.


--
These are my opinions, not necessarily my employer's. I hate spam.




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

______________________________________________
ime-nuts mailing list -- time-nuts-***@public.gmane.org
o unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
nd follow the instructions there.

[Hal Murray]

> Why in the hell would anybody build a 50 channel receiver? At most you
> MIGHT see 12 usable GPS sats... I don't think that I've seen over 10. WAAS
> should be fairly useless for a timing receiver.

I can think of a couple of reasons. I'm sure there are more.

One would be marketing type bragging rights. I can scan more channels than
you.

Another area would be cold-start time. If you have to search N slots, more
searchers runing in parallel is likely to speed things up.


--
These are my opinions. I hate spam.

[Jim Lux]

On 5/11/12 2:38 AM, Hal Murray wrote:
>
>> Why in the hell would anybody build a 50 channel receiver? At most you
>> MIGHT see 12 usable GPS sats... I don't think that I've seen over 10. WAAS
>> should be fairly useless for a timing receiver.
>
> I can think of a couple of reasons. I'm sure there are more.
>
> One would be marketing type bragging rights. I can scan more channels than
> you.
>
> Another area would be cold-start time. If you have to search N slots, more
> searchers runing in parallel is likely to speed things up.
>
>
Searchers and trackers are often different logic, these days..

Searching is very efficiently done with a FFT correlator, because you
can search all lags simultaneously with NlogN effort as opposed to
O(N/2) effort with a sequential search. Same for Doppler.

But once you've acquired, you track with a conventional
Early/Prompt/Late scheme.

When you get into full-up implementations, where there is coupling
between the tracking loops (think of a 2 frequency receiver.. L1 and L5
will have related doppler), there are other "economies of scale" possible.

[b***@public.gmane.org]

> On 5/11/12 2:38 AM, Hal Murray wrote:
>>
>>> Why in the hell would anybody build a 50 channel receiver? At most you
>>> MIGHT see 12 usable GPS sats... I don't think that I've seen over 10.
>>> WAAS
>>> should be fairly useless for a timing receiver.
>>
>> I can think of a couple of reasons. I'm sure there are more.
>>
>> One would be marketing type bragging rights. I can scan more channels
>> than
>> you.
>>
>> Another area would be cold-start time. If you have to search N slots,
>> more
>> searchers runing in parallel is likely to speed things up.
>>
>>
> Searchers and trackers are often different logic, these days..
>
> Searching is very efficiently done with a FFT correlator, because you
> can search all lags simultaneously with NlogN effort as opposed to
> O(N/2) effort with a sequential search. Same for Doppler.
>
> But once you've acquired, you track with a conventional
> Early/Prompt/Late scheme.
>
> When you get into full-up implementations, where there is coupling
> between the tracking loops (think of a 2 frequency receiver.. L1 and L5
> will have related doppler), there are other "economies of scale" possible.

Here is an example of tracking loops coupled even more.

http://www.javad.com/downloads/jns/papers/coop_tracking.pdf

--

Björn

[S***@public.gmane.org]

Hi guys,

here is some data from the Trimble Resolution-SMT connected to the SAASM
1PPS input of our CSAC GPSDO. It ran overnight, and I am showing the data
after the unit settled down and went into position hold mode.

Plotter shows standard deviation of about 7.1ns on the raw data (yellow
trace) and peaks of about +/-18ns. The blue trace is the result of a short
low-pass filter on the data with about 100s time constant or so.

The MADEV shows 1E-08 at 1 second, with a pretty much straight line down to
almost 1E-013 at 10K seconds.

The data-set is in nanoseconds, and it was not normalized, so the numbers
shown in plotter are also in nanoseconds, and must be interpreted as such.

The CSAC GPSDO shows no holdover during this testing, so the GPS did not
miss more than 60 seconds worth of 1PPS pulses at any time.

This data is without sawtooth correction applied, so assuming that sawtooth
correction will improve the numbers, this is not too bad.

bye,
Said

[Mark Sims]

One nasty thing about these receivers is that they seem to be useless as a general purpose GPS receiver. Once they have a saved position (even if you erase the old one) it does not update the lat/lon/alt values (even if you put the receiver into 3D mode). It does not even update lat/lot/alt values when doing a survey. Perhaps I'm missing something? Anybody know how to get updated lat/lon/alts out of these things?

[David J Taylor]

> I see the Trimble Resolution SMT Timing GPS OEM board 66974-35 on a
> well-known auction site from a weel-know seller "fluke.i", at quite a
> good price, and free UK post. Is it any good - as good it seems to be.
> Any experience?

Just to report back that I eventually got round to powering up one of the
two units I bought, having found an SMB connector, and having decided to
"wire-wrap" the 8-pin connector (a non-standard spacing), and having
decided to power the unit from 5V USB through a 16-ohm dropper to get the
3.3V it needs!

Initially, it didn't seem to be working, as there was no serial output and
the LED I had connected via a 1.5K to PPS output wasn't flashing.
However, when I put the 'scope on the PPS signal, it locked and showed a
pulse of just over 100 microseconds. Much shorter than I had expected
(but I hadn't read the manual in detail). The timing was within a
fraction of a microsecond of other PPS sources. On disconnecting the
power, and re-applying it, the PPS signal returned after about 45 seconds.

So on that basis, I'm happy. I've not tried it as a source for NTP.

http://i.ebayimg.com/00/s/NDI0WDY0MA==/$(KGrHqZHJ!4E9qHIuLeNBPkC5j4p8Q~~60_3.JPG

No programming needed, I just powered it up.

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor-***@public.gmane.org

[Mark Sims]

Well, the connector is a standard connector... it's just 2mm/0.070" spacing.

I would not trust a dropping resistor. The current consumption on these units does not appear to be constant... the temperature plot varies depending upon what it is doing (i.e. gets warmer when acquiring satellites, etc).I also wire wrapped to mine. Those wires were then wrapped to a 14 pin wire-wrap socket. I plugged a 3.3V TO-220 LDO regulator (big smoke free hint: their pinouts are not IN-GND-OUT) into the socket and powered it off a 5V wall wart (5V to the antenna power pin). For RS-232 out, I used a RS-232 level converter cable (http://www.ebay.co.uk/itm/ws/eBayISAPI.dll?ViewItem&item=221005883442) and shoved the single-pin headers on the end of that cable onto the wire wrap socket pins. It took about 10 minutes to get it all connected and running.

Note that these units do not speak TSIP by default. They are a special version that acts like a Motorola receiver. You have to reconfigure them if you want to use Lady Heather (who now speaks to Resolution-T and -SMT).

[Hal Murray]

holrum-***@public.gmane.org said:
> Then at the half way point, something strange happened...

I've seen quite a few GPS receivers do strange things. My straw man is
software bugs under poor signal conditions that don't get tested much.

Another possibility would be a glitch on the power rail(s). It's really hard
to get power-up reset and brownout reset right.


--
These are my opinions. I hate spam.

[Hal Murray]

holrum-***@public.gmane.org said:
> I am building a board to convert the output of the Adafruit Ultimate GPS
> module to RS-232. The GPS has a 1-PPS output. What is the preferred com
> port pin for feeding 1-PPS into NTP via an RS-232 connector?

DCD, Pin 1 on DB-9 (DE-9)




--
These are my opinions. I hate spam.

[David J Taylor]

From: Hal Murray

holrum-***@public.gmane.org said:
> I am building a board to convert the output of the Adafruit Ultimate GPS
> module to RS-232. The GPS has a 1-PPS output. What is the preferred com
> port pin for feeding 1-PPS into NTP via an RS-232 connector?

DCD, Pin 1 on DB-9 (DE-9)
==============================================

.. but /do/ try it without the convertor first - the lower 3.3V levels may
be quite adequate for direct connection. Of course, if you are sending over
a long cable proper RS-232 levels will provide better signal integrity.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor-***@public.gmane.org

[Chris Albertson]

On Sun, Aug 18, 2013 at 10:58 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org>wrote:

>
> holrum-***@public.gmane.org said:
> > I am building a board to convert the output of the Adafruit Ultimate GPS
> > module to RS-232. The GPS has a 1-PPS output. What is the preferred
> com
> > port pin for feeding 1-PPS into NTP via an RS-232 connector?
>
> DCD, Pin 1 on DB-9 (DE-9)


Yes, this is right. But watch the polarity. It is easy to get it wrong.
In RS-232 the controls pins are different from the data pins.

--

Chris Albertson
Redondo Beach, California

[Mark Sims]

The board is for another project. It requires real RS-232 levels. There is a MAX3232 chip on it. Since the GPS has a 1PPS output, I figured that I might as well bring it out. There is no documentation on the pulse width or polarity... it is what it is... I'm probably hooking it straight to the '232 chip without any massaging.

There is also one more available RS232 input pin on the chip. Any preferences for RTS or DTR? There is a jumper for powering the board from the RI pin (pin 9) of the RS-232 connector.
---------------------
Yes, this is right. But watch the polarity. It is easy to get it wrong.
In RS-232 the controls pins are different from the data pins.

[Mark C. Stephens]

I did an article here: http://www.vk2hmc.net/blog/?p=583

About 1/2 way down the difference between TX/RX and control RS232 signals is explained.

--marki

-----Original Message-----
From: time-nuts-bounces-***@public.gmane.org [mailto:time-nuts-bounces-***@public.gmane.org] On Behalf Of Mark Sims
Sent: Monday, 19 August 2013 4:51 PM
To: time-nuts-***@public.gmane.org
Subject: [time-nuts] NTP/1-PPS/RS232 question

The board is for another project. It requires real RS-232 levels. There is a MAX3232 chip on it. Since the GPS has a 1PPS output, I figured that I might as well bring it out. There is no documentation on the pulse width or polarity... it is what it is... I'm probably hooking it straight to the '232 chip without any massaging.

There is also one more available RS232 input pin on the chip. Any preferences for RTS or DTR? There is a jumper for powering the board from the RI pin (pin 9) of the RS-232 connector.
---------------------
Yes, this is right. But watch the polarity. It is easy to get it wrong.
In RS-232 the controls pins are different from the data pins.


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

[Hal Murray]

holrum-***@public.gmane.org said:
> There is also one more available RS232 input pin on the chip. Any
> preferences for RTS or DTR? There is a jumper for powering the board from
> the RI pin (pin 9) of the RS-232 connector.

I have a few PCI cards with jumpers to provide either +5 or +12 to pin 9.
(Before USB, this was a common way to provide power for things like bar code
scanners.)



--
These are my opinions. I hate spam.

[Hal Murray]

holrum-***@public.gmane.org said:
> The 1PPS signal is normally low and pulses high for 100 milliseconds. The
> RS-232 adapter board that I built feeds this into an RS-232 transmitter chip
> (MAX3232), so on the interface connector CD will be at +V and pulse down to
> -V. Is this what stock NTP likes?

There is a fudge option to select either rising or falling edge. The default
is rising edge, so you will need to turn on flag2. Check the page for the
driver you are going to use.



--
These are my opinions. I hate spam.

[Hal Murray]

holrum-***@public.gmane.org said:
> I'm not sure how the Arduino environment handles interrupts, but in C you
> need to declare any variables altered by an interrupt as "volatile" so that
> the compiler optimization routines know not to assume they contain known
> values.

Good point.

> Also any code that accesses them needs to do so with interrupts turned
> off... otherwise you can wind up with corrupted values.

Not quite. That may be the simplest way, but you can also use inter-process
communications type tricks. The classic for a two byte counter is to read
high-low-high and try again if the high values don't match. That assumes the
interrupt routine updates low then (maybe) high.



--
These are my opinions. I hate spam.

[Orin Eman]

On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:

>
> holrum-***@public.gmane.org said:
> > I'm not sure how the Arduino environment handles interrupts, but in C
> you
> > need to declare any variables altered by an interrupt as "volatile" so
> that
> > the compiler optimization routines know not to assume they contain known
> > values.
>
> Good point.
>
> > Also any code that accesses them needs to do so with interrupts turned
> > off... otherwise you can wind up with corrupted values.
>
> Not quite. That may be the simplest way, but you can also use
> inter-process
> communications type tricks. The classic for a two byte counter is to read
> high-low-high and try again if the high values don't match. That assumes
> the
> interrupt routine updates low then (maybe) high.



You have to read hardware counter registers on some PIC chips that way.
You have to read the documentation carefully to work out how to correctly
read 16bit counters on an 8 bit CPU.

The order the interrupt routine updates the counter shouldn't matter since
it's atomic as far as the mainline code is concerned.

Orin.

[Chris Albertson]

On Wed, Apr 9, 2014 at 9:39 AM, Orin Eman <orin.eman-***@public.gmane.org> wrote:

> On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org>
> wrote:
>



> The order the interrupt routine updates the counter shouldn't matter since
> it's atomic as far as the mainline code is concerned.
>
>
In my case it's the other way around, the 16 bit counter is updated by
pin-5 and it is "atomic" It is done in the chip's hardware.

Actaully I don't care much about an "off by one" count because the problem
is corrected in the next second. If I happen to miss a count one second
the very next second this shows up as an extra count. I notice that
something like this happens every few hundred seconds.

The PI controller algorithm is very simple and acts as a kind of filter.
It all works in integer math and the DAC is only 16-bits so this kind of
error s "lost between the bits". I don't care if the DAC's value is off
by .04 because it can only be set on full counts.

The goal was to keep the first version of the code SIMPLE. One problem I
want to avoid is where I measure a board with a micrometer and then cut it
with an axe. When you know you are cutting an axe, you don't even need a
tape measure.

Later I add some sophistication back in and measure the effect. Heck at
this point I have a capacitor based TIC that I am completely IGNORING.
The point is to see what each added layer of complexity buys.

--

Chris Albertson
Redondo Beach, California

[Chris Albertson]

On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:

>
> > Also any code that accesses them needs to do so with interrupts turned
> > off... otherwise you can wind up with corrupted values.
>

Forgot if I made this point but in a GPSDO when the interrupt is caused by
the PPS, the interrupts are in effect off for 0.99999 seconds after each
interrupt. The software can assume an interrupt will never happen less
then one second after an interrupt. So the software does all the variable
access within millisecond after each interrupt.

These micro controllers are actually much easier to deal with than a
general purpose multi-tasking operating system. There is far less
non-determinism.


--

Chris Albertson
Redondo Beach, California

[Orin Eman]

On Wed, Apr 9, 2014 at 11:03 AM, Chris Albertson
<albertson.chris-***@public.gmane.org>wrote:

> On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org>
> wrote:
>
> >
> > > Also any code that accesses them needs to do so with interrupts turned
> > > off... otherwise you can wind up with corrupted values.
> >
>
> Forgot if I made this point but in a GPSDO when the interrupt is caused by
> the PPS, the interrupts are in effect off for 0.99999 seconds after each
> interrupt. The software can assume an interrupt will never happen less
> then one second after an interrupt. So the software does all the variable
> access within millisecond after each interrupt.
>
> These micro controllers are actually much easier to deal with than a
> general purpose multi-tasking operating system. There is far less
> non-determinism.



Indeed. I was just thinking the same thing. It's much easier to deal with
an interrupt routine updating variables than multiple threads fighting over
them... I just had to replace a mutex lock with an atomic exchange to
avoid a deadlock in my code at work.

Orin.

[Hal Murray]

holrum-***@public.gmane.org said:
> Ahh, but with Lady Heather you can specify the time zone offset (down to
> the second) and the when the daylight savings time switchovers occur. And
> from experience, I can tell you that the code to do it is a royal pain in
> the ass... not all that hard to do, but a pain to test.

Part of the problem is that "when the daylight savings time switchovers
occur" changes over time. The problem is a whole lot easier if all you are
interested in is converting the current UTC to the current local time.

The *nix world uses the time-zone database. I assume it is available on
Windows too.
https://en.wikipedia.org/wiki/Tz_database


--
These are my opinions. I hate spam.

[cheater00 .]

On 9 May 2014 21:01, "Hal Murray" <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>
>
> holrum-***@public.gmane.org said:
> > Ahh, but with Lady Heather you can specify the time zone offset (down
to
> > the second) and the when the daylight savings time switchovers occur.
And
> > from experience, I can tell you that the code to do it is a royal pain
in
> > the ass... not all that hard to do, but a pain to test.
>
> Part of the problem is that "when the daylight savings time switchovers
> occur" changes over time. The problem is a whole lot easier if all you
are
> interested in is converting the current UTC to the current local time.
>
> The *nix world uses the time-zone database. I assume it is available on
> Windows too.
> https://en.wikipedia.org/wiki/Tz_database

That is the Olson Timezone Database, aka tzdata. I wrote a compiler for it
once, the format is very fun to parse and there are some great things to be
learned. Specifically figuring all edge cases was a fun exercise.

[Hal Murray]

***@hotmail.com said:
> Basically the solenoid nudged the pendulum

There was an article in Scientific American many years ago. They used a
magnet mounted on the end of a stick attached to the pendulum arm. The arc
of the magnet swung through a hole in the middle of a solenoid coil. A pulse
on the coil at the right time provided the nudge with no physical contact.


--
These are my opinions. I hate spam.



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

[DaveH]

Science Madness has a PDF of the book - Projects for the Amateur Scientist
by SciAm columnist C.L. Stong.

The pendulum is on page 290

http://www.sciencemadness.org/library/books/projects_for_the_amateur_scienti
st.pdf


Dave

> -----Original Message-----
> From: time-nuts [mailto:time-nuts-***@febo.com] On Behalf
> Of Hal Murray
> Sent: Saturday, January 10, 2015 15:09
> To: Discussion of precise time and frequency measurement
> Cc: ***@megapathdsl.net
> Subject: Re: [time-nuts] Mechanical 1PPS Oscillator Disciplining
>
>
> ***@hotmail.com said:
> > Basically the solenoid nudged the pendulum
>
> There was an article in Scientific American many years ago.
> They used a
> magnet mounted on the end of a stick attached to the pendulum
> arm. The arc
> of the magnet swung through a hole in the middle of a
> solenoid coil. A pulse
> on the coil at the right time provided the nudge with no
> physical contact.
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Jim Lux]

On 1/10/15 3:08 PM, Hal Murray wrote:
>
> ***@hotmail.com said:
>> Basically the solenoid nudged the pendulum
>
> There was an article in Scientific American many years ago. They used a
> magnet mounted on the end of a stick attached to the pendulum arm. The arc
> of the magnet swung through a hole in the middle of a solenoid coil. A pulse
> on the coil at the right time provided the nudge with no physical contact.
>
>
or a coil under the pendulum bob, which is ferrous, a technique used in
some large Foucault pendulums

I didn't realize you can actually buy them as a sort of catalog item..

http://www.academypendulums.com/

They put the drive at the top.

The most fascinating thing is the list of 122 pendulums they've installed
http://www.academypendulums.com/foucault-pendulum-displays.html
and some of the places they are.. there's a goodly number of museums, of
course, but some other things..Wineries, Banks, Malls?

the one in the Smithsonian was removed some years ago..


Very simple design
the schematic (and the user manual including tuning instructions) is on
the website under "manuals"

Just a photodetector driving a solenoid, which apparently draws 300 mA
from a 120VAC line.

I haven't found details on the coil or armature design, but plenty of
pictures.




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

[Hal Murray]

> My tbolt is reporting 29 currently active PRNs...
>> 27 Sats in the sky.

Have you checked the satellite numbers/svid?

They squeeze the WAAS satellites into the same number space.

Are TBolts new enough to know about WAAS?


--
These are my opinions. I hate spam.



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

[Bob Camp]

Hi


> On Jul 10, 2015, at 1:27 PM, Hal Murray <***@megapathdsl.net> wrote:
>
>> My tbolt is reporting 29 currently active PRNs...
>>> 27 Sats in the sky.
>
> Have you checked the satellite numbers/svid?
>
> They squeeze the WAAS satellites into the same number space.
>
> Are TBolts new enough to know about WAAS?


The normal TBolt that we use does not understand WAAS. Some of the later
boards that came out under the same name *might*.

Bob

>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@hotmail.com said:
> Somewhat time-nut related... the project main application needed
> millisecond consistent (not necessarily accurate) time stamps on a
> world-wide network. That was in the pre-gps, pre-fiber, pre-historic
> before-times. I don't think that they ever quite got there.

World wide seismology took off in the early 1970s as background for nuclear
underground non-testing treaties. Both the US and the USSR had to be sure
they could detect the opponents tests and distinguish tests from earthquakes.
We had seismic stations scattered around the globe.

Does anybody know how they distributed time back then and/or how accurately
they could do it?

Google says the speed of sound in rock is 6-8 km/s so 10 ms error would be
100 meters. That seems like a reasonable ballpark.



--
These are my opinions. I hate spam.



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

[Howard Davidson]

http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1964-07.pdf


On 10/13/2015 10:12 PM, Hal Murray wrote:
> ***@hotmail.com said:
>> Somewhat time-nut related... the project main application needed
>> millisecond consistent (not necessarily accurate) time stamps on a
>> world-wide network. That was in the pre-gps, pre-fiber, pre-historic
>> before-times. I don't think that they ever quite got there.
> World wide seismology took off in the early 1970s as background for nuclear
> underground non-testing treaties. Both the US and the USSR had to be sure
> they could detect the opponents tests and distinguish tests from earthquakes.
> We had seismic stations scattered around the globe.
>
> Does anybody know how they distributed time back then and/or how accurately
> they could do it?
>
> Google says the speed of sound in rock is 6-8 km/s so 10 ms error would be
> 100 meters. That seems like a reasonable ballpark.
>
>
>

--
Howard L. Davidson
***@att.net

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

[Alan Melia]

Well I dont know if it was used for that but the16kHz VLF station at Rugby
call-sign GBR was rebuilt in 1967 and the output tank circuit stiffened to
provide better phase stability specifically foe international time standard
comparison. The transmitter was used for initial comparisons between NPL and
NBS (later NIST) time standards. It was also the starting point for the
Omega nav system. Prior to that accurate time data was passed over twisted
pairs in UK and probably Europe.

Alan
G3NYK
----- Original Message -----
From: "Hal Murray" <***@megapathdsl.net>
To: "Discussion of precise time and frequency measurement"
<time-***@febo.com>
Cc: <***@megapathdsl.net>
Sent: Wednesday, October 14, 2015 6:12 AM
Subject: [time-nuts] How did they distribute time in the old days?


>
> ***@hotmail.com said:
>> Somewhat time-nut related... the project main application needed
>> millisecond consistent (not necessarily accurate) time stamps on a
>> world-wide network. That was in the pre-gps, pre-fiber, pre-historic
>> before-times. I don't think that they ever quite got there.
>
> World wide seismology took off in the early 1970s as background for
> nuclear
> underground non-testing treaties. Both the US and the USSR had to be sure
> they could detect the opponents tests and distinguish tests from
> earthquakes.
> We had seismic stations scattered around the globe.
>
> Does anybody know how they distributed time back then and/or how
> accurately
> they could do it?
>
> Google says the speed of sound in rock is 6-8 km/s so 10 ms error would be
> 100 meters. That seems like a reasonable ballpark.
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Will]

Hi,

They used (late 1970's) WWV or WWVH to sync up the time. There was
fancy system that used a neon on a rotating disc rather like an early
depth sounder. Neon flashed with seconds beep. There was a way of
rotating the field that drove the disk to advance/delay the system to
set it fairly accurately.

Cheers,
Will

On 14/10/15 18:12, Hal Murray wrote:
> ***@hotmail.com said:
>> Somewhat time-nut related... the project main application needed
>> millisecond consistent (not necessarily accurate) time stamps on a
>> world-wide network. That was in the pre-gps, pre-fiber, pre-historic
>> before-times. I don't think that they ever quite got there.
> World wide seismology took off in the early 1970s as background for nuclear
> underground non-testing treaties. Both the US and the USSR had to be sure
> they could detect the opponents tests and distinguish tests from earthquakes.
> We had seismic stations scattered around the globe.
>
> Does anybody know how they distributed time back then and/or how accurately
> they could do it?
>
> Google says the speed of sound in rock is 6-8 km/s so 10 ms error would be
> 100 meters. That seems like a reasonable ballpark.
>
>
>

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

[billriches]

Not milisecond time distribution but time related!

In the early half of the 1900s Western Union was in the time business. They
would rent businesses such as banks, office buildings, etc clocks for a few
dollars a month. These were pendulum wall clocks that had 2 #6 dry cell
batteries inside that would wind them every hour or so. The clocks were
connected to the WU telegraph line and for a minute before and after the
top of the hour all traffic on the circuit would stop. Exactly at the top
of the hour they would push a pulse of 50 ? volts or so over the line and it
would reset the clock to the top of the hour.

Eventually WU decided to get out of the time business and stopped the
service and they said all the customers could keep their clocks. It was
said that at the end of that day many clocks were seen going home with some
of the workers!

I purchased one of these clocks about 15 years ago from a North New Jersey
junk dealer who had obtained several hundred of them. My clock has a 1929
scratch mark inside and
is still ticking away. These clocks were made by the Self Winding Clock
Company and more information can be seen in the book "American Clocks Volume
2 " by Tran Duy Ly (page 177). It loses or gains about a minute a month
depending on the moon phase or sunspots. You can see a pic of the clock on
qrz.com under my call sign.

73,

Bill, WA2DVU
Cape May



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

[Jim Harman]

The Western Union clocks were still in use at broadcast stations in the
early 1970s. One problem was that the reset pulse and resulting jump in
time would come exactly on the hour, when you were trying to synchronize
with a network news broadcast that began at the network's version of 00:00.

ABC and I presume the other networks would send a tone 10 seconds before
their program started, By listening to the network on the "Cue" channel,
you would have a pretty good idea of when the news would start.

Another system in wide use around then and still somewhat today for
controlling the clocks in a large building was sold by Simplex. The
building would have a master clock (set manually by the custodian or
whoever) that pumped out tones at about 3 KHz over the power lines. These
signals would come out a couple of minutes before the hour, presumably to
avoid problems with events scheduled on the hour. The slave clocks were
designed to run a little fast, and would wait at 58:00 until they received
a tone to restart. I believe there was a special tone that would make the
clock run "fast forward," to deal with longer adjustments for power outages
and DST.

One drawback of this system is that the tones sometimes leak into audio
equipment, and in a quiet room they are often audible through the
fluorescent light ballasts.

On Wed, Oct 14, 2015 at 12:42 PM, Nick Sayer via time-nuts <
time-***@febo.com> wrote:

>
>
>
> The WU standard time service goes back further than the turn of the 20th
> century. It started in 1870.
>
> --

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

[bownes]

And to tie this back to the UPS thread, at university, the Simplex clock sync signal made our Vax 11/730 TOD clock run waaaay fast.
I never figured out if it was using line frequency zero crossings for seconds or if it was leaking as DEC fixed it not long after it was installed. (And it was moved to a different phase of the power system than the clocks...)



> On Oct 14, 2015, at 15:55, Jim Harman <***@gmail.com> wrote:
>
> The Western Union clocks were still in use at broadcast stations in the
> early 1970s. One problem was that the reset pulse and resulting jump in
> time would come exactly on the hour, when you were trying to synchronize
> with a network news broadcast that began at the network's version of 00:00.
>
> ABC and I presume the other networks would send a tone 10 seconds before
> their program started, By listening to the network on the "Cue" channel,
> you would have a pretty good idea of when the news would start.
>
> Another system in wide use around then and still somewhat today for
> controlling the clocks in a large building was sold by Simplex. The
> building would have a master clock (set manually by the custodian or
> whoever) that pumped out tones at about 3 KHz over the power lines. These
> signals would come out a couple of minutes before the hour, presumably to
> avoid problems with events scheduled on the hour. The slave clocks were
> designed to run a little fast, and would wait at 58:00 until they received
> a tone to restart. I believe there was a special tone that would make the
> clock run "fast forward," to deal with longer adjustments for power outages
> and DST.
>
> One drawback of this system is that the tones sometimes leak into audio
> equipment, and in a quiet room they are often audible through the
> fluorescent light ballasts.
>
> On Wed, Oct 14, 2015 at 12:42 PM, Nick Sayer via time-nuts <
> time-***@febo.com> wrote:
>
>>
>>
>>
>> The WU standard time service goes back further than the turn of the 20th
>> century. It started in 1870.
>>
>> --
>
> --Jim Harman
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Bownes]

Precise time (and time zones) and the relationship with the telegraph were
a side effect of the railroads. You need to keep time (and keep on time) in
order to avoid collisions on single tracked main lines.

On Wed, Oct 14, 2015 at 12:42 PM, Nick Sayer via time-nuts <
time-***@febo.com> wrote:

>
> > On Oct 14, 2015, at 4:42 AM, billriches <***@verizon.net> wrote:
> >
> > Not milisecond time distribution but time related!
> >
> > In the early half of the 1900s Western Union was in the time business.
> They
> > would rent businesses such as banks, office buildings, etc clocks for a
> few
> > dollars a month. These were pendulum wall clocks that had 2 #6 dry cell
> > batteries inside that would wind them every hour or so. The clocks were
> > connected to the WU telegraph line and for a minute before and after the
> > top of the hour all traffic on the circuit would stop. Exactly at the
> top
> > of the hour they would push a pulse of 50 ? volts or so over the line
> and it
> > would reset the clock to the top of the hour.
>
> The WU standard time service goes back further than the turn of the 20th
> century. It started in 1870.
>
> I’ve always wanted to get my hands on one of those clocks and come up with
> a circuit to recreate the synchronization signal for it, probably with a
> Raspberry Pi running ntpd and a big ol’ MOSFET. The problem is that at this
> point, those clocks are quite expensive once they’re reconditioned.
>
> My understanding (perhaps incorrect) was that the sync pulse was once
> daily and, as you said, would cause the hands to “snap” to 12. The trailing
> edge of the pulse was synchronized and would release the clock to operate
> normally.
>
> That they had something as accurate and widespread as it was so early is
> astonishing.
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Adrian Godwin]

I have a synchronome clock built for the British Post Office.

I find that the 10V or so that a USB to serial adapter can produce can
trigger the solenoid, if allowed to charge a capacitor for the intervening
minute. The effect is that I can print a single character once a minute at
a low bit rate and, with a few components but no power supply beyond USB,
step the clock.

A better solution would include a microcontroller to remember where the
hands had stepped to, for automatic recovery after a stoppage.


On Fri, Oct 16, 2015 at 1:25 AM, Brooke Clarke <***@pacific.net> wrote:

> Hi Don:
>
> I've got a number of SWCC clocks and 3V doesn't work for any of them.
> I've done a number of experiments and a higher voltage and series resistor
> makes a huge improvement.
>
>
> Mail_Attachment --
> Have Fun,
>
> Brooke Clarke
> http://www.PRC68.com
> http://www.end2partygovernment.com/2012Issues.html
> http://www.prc68.com/I/DietNutrition.html
> Don Couch wrote:
>
>> Hi, Brooke,
>>
>> My self winding clock synchronizes fine on three volts. I built a
>> synchronizer using a PIC controller with a 32KHz quartz crystal, running on
>> three volts. You might want to carefully check the coil and connections on
>> yours. By the way, the winding coils also are running on three volts.
>>
>> Don Couch
>>
>> On 10/14/2015 11:02 AM, Brooke Clarke wrote:
>>
>>> Hi Nick:
>>>
>>> One of my Self Winding Clock Co. (WU) clocks was taken down yesterday
>>> for painting.
>>> When put up one of the Ken's Clock Synchronizers was installed and the
>>> hands moved to align with the heart shaped cam it uses, but it never worked.
>>> The problem was it used a 4.5 Volt signal which can develop the current
>>> needed to pull the sync electromagnet the time constant is far too slow.
>>> I'm going to add a high voltage circuit with series resistor to get the
>>> time constant down one or two orders of magnitude. The key to this is a
>>> PCB I make that holds 5 each 9V batteries connected in series, so I'll use
>>> one, two or more of them to get the time constant down.
>>> http://www.prc68.com/P/45VS.html
>>>
>>> Before I had the 45 Volt Stick I was considering getting the needed high
>>> voltage by charging a cap a minute or two before the top of the hour and
>>> discharging it through a resistor. Here's a video showing that would work.
>>> http://www.prc68.com/I/SWCC.shtml#Experiments_Feb_2014_
>>>
>>> Mail_Attachment --
>>> Have Fun,
>>>
>>> Brooke Clarke
>>> http://www.PRC68.com
>>> http://www.end2partygovernment.com/2012Issues.html
>>> http://www.prc68.com/I/DietNutrition.html
>>> Nick Sayer via time-nuts wrote:
>>>
>>>> On Oct 14, 2015, at 4:42 AM, billriches <***@verizon.net>
>>>>> wrote:
>>>>>
>>>>> Not milisecond time distribution but time related!
>>>>>
>>>>> In the early half of the 1900s Western Union was in the time
>>>>> business. They
>>>>> would rent businesses such as banks, office buildings, etc clocks for
>>>>> a few
>>>>> dollars a month. These were pendulum wall clocks that had 2 #6 dry
>>>>> cell
>>>>> batteries inside that would wind them every hour or so. The clocks were
>>>>> connected to the WU telegraph line and for a minute before and after
>>>>> the
>>>>> top of the hour all traffic on the circuit would stop. Exactly at the
>>>>> top
>>>>> of the hour they would push a pulse of 50 ? volts or so over the line
>>>>> and it
>>>>> would reset the clock to the top of the hour.
>>>>>
>>>> The WU standard time service goes back further than the turn of the
>>>> 20th century. It started in 1870.
>>>>
>>>> I’ve always wanted to get my hands on one of those clocks and come up
>>>> with a circuit to recreate the synchronization signal for it, probably with
>>>> a Raspberry Pi running ntpd and a big ol’ MOSFET. The problem is that at
>>>> this point, those clocks are quite expensive once they’re reconditioned.
>>>>
>>>> My understanding (perhaps incorrect) was that the sync pulse was once
>>>> daily and, as you said, would cause the hands to “snap” to 12. The trailing
>>>> edge of the pulse was synchronized and would release the clock to operate
>>>> normally.
>>>>
>>>> That they had something as accurate and widespread as it was so early
>>>> is astonishing.
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-***@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-***@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-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Luke Mester]

The SWCC clock time synch coils were wired in series. Voltage varied with
the number of clocks in the circuit. It takes about 300ma to drive the
coil. Do a Google search for "swcc synchronizing coil voltage" to see a
thread where I talk about this on the NAWCC clock message board. Also the
clocks have a mechanical lock out mechanism that will prevent synch if the
minute hand is more than a few minutes on either side of the hour. Send a
pulse too early or late & you'll hear the click but the time won't be
reset. And yes, it is amazing how many years ago people came up with time
sync systems. Some of the early systems used pneumatics to distribute the
time sync!

On Thu, Oct 15, 2015 at 8:25 PM, Brooke Clarke <***@pacific.net> wrote:

> Hi Don:
>
> I've got a number of SWCC clocks and 3V doesn't work for any of them.
> I've done a number of experiments and a higher voltage and series resistor
> makes a huge improvement.
>
>
> Mail_Attachment --
> Have Fun,
>
> Brooke Clarke
> http://www.PRC68.com
> http://www.end2partygovernment.com/2012Issues.html
> http://www.prc68.com/I/DietNutrition.html
> Don Couch wrote:
>
>> Hi, Brooke,
>>
>> My self winding clock synchronizes fine on three volts. I built a
>> synchronizer using a PIC controller with a 32KHz quartz crystal, running on
>> three volts. You might want to carefully check the coil and connections on
>> yours. By the way, the winding coils also are running on three volts.
>>
>> Don Couch
>>
>> On 10/14/2015 11:02 AM, Brooke Clarke wrote:
>>
>>> Hi Nick:
>>>
>>> One of my Self Winding Clock Co. (WU) clocks was taken down yesterday
>>> for painting.
>>> When put up one of the Ken's Clock Synchronizers was installed and the
>>> hands moved to align with the heart shaped cam it uses, but it never worked.
>>> The problem was it used a 4.5 Volt signal which can develop the current
>>> needed to pull the sync electromagnet the time constant is far too slow.
>>> I'm going to add a high voltage circuit with series resistor to get the
>>> time constant down one or two orders of magnitude. The key to this is a
>>> PCB I make that holds 5 each 9V batteries connected in series, so I'll use
>>> one, two or more of them to get the time constant down.
>>> http://www.prc68.com/P/45VS.html
>>>
>>> Before I had the 45 Volt Stick I was considering getting the needed high
>>> voltage by charging a cap a minute or two before the top of the hour and
>>> discharging it through a resistor. Here's a video showing that would work.
>>> http://www.prc68.com/I/SWCC.shtml#Experiments_Feb_2014_
>>>
>>> Mail_Attachment --
>>> Have Fun,
>>>
>>> Brooke Clarke
>>> http://www.PRC68.com
>>> http://www.end2partygovernment.com/2012Issues.html
>>> http://www.prc68.com/I/DietNutrition.html
>>> Nick Sayer via time-nuts wrote:
>>>
>>>> On Oct 14, 2015, at 4:42 AM, billriches <***@verizon.net>
>>>>> wrote:
>>>>>
>>>>> Not milisecond time distribution but time related!
>>>>>
>>>>> In the early half of the 1900s Western Union was in the time
>>>>> business. They
>>>>> would rent businesses such as banks, office buildings, etc clocks for
>>>>> a few
>>>>> dollars a month. These were pendulum wall clocks that had 2 #6 dry
>>>>> cell
>>>>> batteries inside that would wind them every hour or so. The clocks were
>>>>> connected to the WU telegraph line and for a minute before and after
>>>>> the
>>>>> top of the hour all traffic on the circuit would stop. Exactly at the
>>>>> top
>>>>> of the hour they would push a pulse of 50 ? volts or so over the line
>>>>> and it
>>>>> would reset the clock to the top of the hour.
>>>>>
>>>> The WU standard time service goes back further than the turn of the
>>>> 20th century. It started in 1870.
>>>>
>>>> I’ve always wanted to get my hands on one of those clocks and come up
>>>> with a circuit to recreate the synchronization signal for it, probably with
>>>> a Raspberry Pi running ntpd and a big ol’ MOSFET. The problem is that at
>>>> this point, those clocks are quite expensive once they’re reconditioned.
>>>>
>>>> My understanding (perhaps incorrect) was that the sync pulse was once
>>>> daily and, as you said, would cause the hands to “snap” to 12. The trailing
>>>> edge of the pulse was synchronized and would release the clock to operate
>>>> normally.
>>>>
>>>> That they had something as accurate and widespread as it was so early
>>>> is astonishing.
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-***@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-***@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-***@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-***@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



--
Luke Mester
http://mesterhome.com/
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Harris]

I heard of a system used in Melbourne between two major stations using
pulses in a pipe of water to sync. I suppose that pulses travel much faster
in water being incompressible, so better accuracy!


Tom Harris <***@gmail.com>

On 20 October 2015 at 07:00, Brian Inglis <***@systematicsw.ab.ca>
wrote:

> On 2015-10-15 08:32, Tom Van Baak wrote:
>
>> Nick Sayer writes:
>>
>>> The WU standard time service goes back further than the turn of the 20th
>>> century. It started in 1870.
>>>
>>
> Also, for a screen full of irresistible SWCC photos, try this:
>> https://www.google.com/search?tbm=isch&q=self-winding+clock+company
>>
>> My understanding (perhaps incorrect) was that the sync pulse was once
>>> daily and, as you said,
>>> would cause the hands to “snap” to 12. The trailing edge of the pulse
>>> was synchronized and would
>>> release the clock to operate normally.
>>>
>>> That they had something as accurate and widespread as it was so early is
>>> astonishing.
>>>
>>
>> Oh, Padawan, that's just the tip of the iceberg when it comes to the deep
>> and fascinating history of precise timekeeping.
>>
>
> Recently restored (after a building fire where some were lost) to working
> 19 Art Nouveau master/slave clocks from 1910:
> http://www.gsaarchives.net/2013/04/mackintosh-clocks-feature-on-bbc-news/
> more pictures in linked articles from BBC
> --
> Take care. Thanks, Brian Inglis
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tim Shoppa]

As recently as 1987, there was poor to no absolute time synchronization at
the world's underground neutrino detectors. When light and neutrino fronts
from supernova SN1987A arrived, the best they were able to put absolute
timestamps on neutrino events was about 1 minute.

Even after the neutrino arrivals they may have been able to back-correct
timestamps on the Kamiokande data to within milliseconds, but a power
failure a few days after SN1987A detection prevented this.

The timescales that the Kamiokande and IMB neutrino detectors were
originally designed to measure? Circa 10 to the 31st years!

Today the realtime neutrino detectors are tied together into a network to
look for neutrino bursts in realtime, and even determine direction to point
optical telescopes. The neutrino burst for a SN1987A type event precedes
the optical detectability by a few hours.

Tim N3QE

On Wednesday, October 14, 2015, Hal Murray <***@megapathdsl.net> wrote:

>
> ***@hotmail.com said:
> > Somewhat time-nut related... the project main application needed
> > millisecond consistent (not necessarily accurate) time stamps on a
> > world-wide network. That was in the pre-gps, pre-fiber, pre-historic
> > before-times. I don't think that they ever quite got there.
>
> World wide seismology took off in the early 1970s as background for nuclear
> underground non-testing treaties. Both the US and the USSR had to be sure
> they could detect the opponents tests and distinguish tests from
> earthquakes.
> We had seismic stations scattered around the globe.
>
> Does anybody know how they distributed time back then and/or how accurately
> they could do it?
>
> Google says the speed of sound in rock is 6-8 km/s so 10 ms error would be
> 100 meters. That seems like a reasonable ballpark.
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@hotmail.com said:
> The GPS spec implies the satellites have a fixed frequency offset to
> compensate for relativistic effects. But do they actually dynamically and/
> or individually adjust the frequency to adjust for orbit variations and
> eccentricities?

I think the orbits are circular so the frequency won't depend on the orbital
position.

The next question is does the math in the receiver have to correct for
changes due to elevation? Does it become relevant if you are trying for
survey grade results?

--
These are my opinions. I hate spam.



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

[Tom Van Baak]

Hal,

Right. The orbits are nominally circular -- but not exactly. The set of orbital parameters cover these details. A quick google search suggests the eccentricity for GPS is around 0.01. Still, that's enough to cause +/- 23 ns of accumulated phase error per orbit. I'm pretty sure the receivers take care of this math, since eccentricity is a key part of any orbit model. I wish we could see the source code to a GPS timing receiver.

I'm not sure I understand your elevation question. Are you talking about elevation as in mountain vs. sea level altitude? Or elevation as in satellite Az/El?

GPS satellites in view are about 20,000 km (overhead) to about 25,000 km (horizon) away, so the signal gets to you within about 65 to 85 ms. Whether you apply the full 4.5e-10 relativistic correction or no correction to the SV clock at all, it makes only a 1 cm time-of-arrival difference. That's why I said for trilateral navigation purposes, the relativistic effects are in the noise. For UTC time-transfer, however, an uncorrected 4.5e-10 frequency error would continuously accumulate, giving 38 us/day phase error, the number you often hear.

About survey grade -- I suspect the post-processing takes into account anything you can think of, from the shape of the antennas to space weather to the phase of the moon (literally).

/tvb

----- Original Message -----
From: "Hal Murray" <***@megapathdsl.net>
To: "Discussion of precise time and frequency measurement" <time-***@febo.com>
Cc: <***@megapathdsl.net>
Sent: Saturday, November 28, 2015 2:37 PM
Subject: Re: [time-nuts] Einstein Special on PBS


>
> ***@hotmail.com said:
>> The GPS spec implies the satellites have a fixed frequency offset to
>> compensate for relativistic effects. But do they actually dynamically and/
>> or individually adjust the frequency to adjust for orbit variations and
>> eccentricities?
>
> I think the orbits are circular so the frequency won't depend on the orbital
> position.
>
> The next question is does the math in the receiver have to correct for
> changes due to elevation? Does it become relevant if you are trying for
> survey grade results?
>
> --
> These are my opinions. I hate spam.
>

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

[Bob Camp]

Hi

> On Nov 29, 2015, at 11:31 AM, Tom Van Baak <***@LeapSecond.com> wrote:
>
> Hal,
>
> Right. The orbits are nominally circular -- but not exactly. The set of orbital parameters cover these details. A quick google search suggests the eccentricity for GPS is around 0.01. Still, that's enough to cause +/- 23 ns of accumulated phase error per orbit. I'm pretty sure the receivers take care of this math, since eccentricity is a key part of any orbit model. I wish we could see the source code to a GPS timing receiver.
>
> I'm not sure I understand your elevation question. Are you talking about elevation as in mountain vs. sea level altitude? Or elevation as in satellite Az/El?
>
> GPS satellites in view are about 20,000 km (overhead) to about 25,000 km (horizon) away, so the signal gets to you within about 65 to 85 ms. Whether you apply the full 4.5e-10 relativistic correction or no correction to the SV clock at all, it makes only a 1 cm time-of-arrival difference. That's why I said for trilateral navigation purposes, the relativistic effects are in the noise. For UTC time-transfer, however, an uncorrected 4.5e-10 frequency error would continuously accumulate, giving 38 us/day phase error, the number you often hear.
>
> About survey grade -- I suspect the post-processing takes into account anything you can think of, from the shape of the antennas to space weather to the phase of the moon (literally).

Most survey work is done as a “delta from known references”. It’s much like common view time transfer. That alone takes care of a whole raft of things.

If you dig into the gravity stuff, they get into questions like “do we put in a term for the gravitational effects of Pluto? Yes, there are Gravity Nuts….

Bob


>
> /tvb
>
> ----- Original Message -----
> From: "Hal Murray" <***@megapathdsl.net>
> To: "Discussion of precise time and frequency measurement" <time-***@febo.com>
> Cc: <***@megapathdsl.net>
> Sent: Saturday, November 28, 2015 2:37 PM
> Subject: Re: [time-nuts] Einstein Special on PBS
>
>
>>
>> ***@hotmail.com said:
>>> The GPS spec implies the satellites have a fixed frequency offset to
>>> compensate for relativistic effects. But do they actually dynamically and/
>>> or individually adjust the frequency to adjust for orbit variations and
>>> eccentricities?
>>
>> I think the orbits are circular so the frequency won't depend on the orbital
>> position.
>>
>> The next question is does the math in the receiver have to correct for
>> changes due to elevation? Does it become relevant if you are trying for
>> survey grade results?
>>
>> --
>> These are my opinions. I hate spam.
>>
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@hotmail.com said:
> I find it hard to believe that only time-nuts GPSDOs saw any problems.

Has anybody seen troubles on other than TBolts?

> Will be interesting to see...

Yup.



--
These are my opinions. I hate spam.



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

[Luc Gaudin]

Hello,

The issue was known on the Thunderbold for the older firmware version up to firmware v3.00.
The product will not report the correct extended GPS week number after the Feb,13th 2016.
After the rollover to week #860, the thunderbolt will not make position for 2 hours, because the Ephemeris data on the GPS receiver being consider incorrect.
The module will work fine after this 2 hours.

Regards,

Luc

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

[Nigel Vander Houwen]

Luc,

Do you have a reference for this?

Nigel

> On Feb 15, 2016, at 01:22, Luc Gaudin <***@naelcom.com> wrote:
>
> Hello,
>
> The issue was known on the Thunderbold for the older firmware version up to firmware v3.00.
> The product will not report the correct extended GPS week number after the Feb,13th 2016.
> After the rollover to week #860, the thunderbolt will not make position for 2 hours, because the Ephemeris data on the GPS receiver being consider incorrect.
> The module will work fine after this 2 hours.
>
> Regards,
>
> Luc
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Camp]

Hi


…. also….

If it is a rollover bug, does it come back when the unit is power cycled or is there some magic in a
eprom that locks it to the correct era? (all of mine seem to be past FW 3.00)

Bob

> On Feb 15, 2016, at 11:57 AM, Nigel Vander Houwen <timenuts-***@nigelvh.com> wrote:
>
> Luc,
>
> Do you have a reference for this?
>
> Nigel
>
>> On Feb 15, 2016, at 01:22, Luc Gaudin <***@naelcom.com> wrote:
>>
>> Hello,
>>
>> The issue was known on the Thunderbold for the older firmware version up to firmware v3.00.
>> The product will not report the correct extended GPS week number after the Feb,13th 2016.
>> After the rollover to week #860, the thunderbolt will not make position for 2 hours, because the Ephemeris data on the GPS receiver being consider incorrect.
>> The module will work fine after this 2 hours.
>>
>> Regards,
>>
>> Luc
>>
>> _______________________________________________
>> time-nuts mailing list -- time-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Luc Gaudin]

Hi,

The affected part number are :
38223-61 Thunderbolt v2.10
38223-61 Thunderbolt v2.12
39448-61 Thunderbolt v2.22
48050-61 Thunderbolt II v3.00

Regards,

Luc

-----Message d'origine-----
De : time-nuts [mailto:time-nuts-***@febo.com] De la part de Nigel Vander Houwen
Envoyé : lundi 15 février 2016 17:58
À : Discussion of precise time and frequency measurement
Objet : Re: [time-nuts] Trimble Thunderbolt error

Luc,

Do you have a reference for this?

Nigel

> On Feb 15, 2016, at 01:22, Luc Gaudin <***@naelcom.com> wrote:
>
> Hello,
>
> The issue was known on the Thunderbold for the older firmware version up to firmware v3.00.
> The product will not report the correct extended GPS week number after the Feb,13th 2016.
> After the rollover to week #860, the thunderbolt will not make position for 2 hours, because the Ephemeris data on the GPS receiver being consider incorrect.
> The module will work fine after this 2 hours.
>
> Regards,
>
> Luc
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@hotmail.com said:
> I've seen reports that GPS and GLONASS fixes can be off well over 50 meters
> when referenced to the same map model.

Was that difference stable, or does it wander over time?

Was that with a good antenna, or down in the trees or an urban canyon?


--
These are my opinions. I hate spam.



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

[Hal Murray]

***@hotmail.com said:
> The receiver is reporting the correct UTC offset and appears to be working
> properly... it's just that the time is one second off from what 7 other
> models of receivers are reporting...

I'm pretty sure that I've seen one GPS unit that was off by a second. I'm
pretty sure it didn't get fixed by waiting a while. But I don't remember
which type it was so this is just a rumor.

I think I was using NMEA mode rather than a vendor specific binary mode.


--
These are my opinions. I hate spam.



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

[Bob Stewart]

Hal, thanks for reminding me of what I ran into on the LEA-6T modules. When you first power them on, they are often a second off in time. It's not until the NAV-TIMEUTC->valid field returns a set validUTC flag that the time can be counted on. But it usually doesn't take more than a minute or two after power-on that the flag gets set and the time jumps to valid time.

Bob

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

--------------------------------------------
On Wed, 6/1/16, Hal Murray <***@megapathdsl.net> wrote:

Subject: Re: [time-nuts] Ublox Neo-6M time error.
To: "Discussion of precise time and frequency measurement" <time-***@febo.com>
Cc: ***@megapathdsl.net
Date: Wednesday, June 1, 2016, 2:09 AM


***@hotmail.com
said:
> The receiver is reporting the correct UTC offset and
appears to be working
> properly... it's just that the time is one second off
from what 7 other
> models of receivers are reporting...

I'm pretty sure that I've seen one GPS unit that was off by
a second.  I'm
pretty sure it didn't get fixed by waiting a while. 
But I don't remember
which type it was so this is just a rumor.

I think I was using NMEA mode rather than a vendor specific
binary mode.


--
These are my opinions.  I hate spam.



_______________________________________________
time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mark Sims]

I have no idea... I can't run Ucenter. It requires an internet connection to run (or at least register). All my current Windoze boxes are XP, and there's no way in hell I'm connecting an XP box to the internet. Other GPS makers don't have such a requirement to use their software, so I avoid using Ublox products.

I'm pretty sure the issue is the "when does the time message come out in relation to the 1PPS" question. It seems Ublox is the odd man out compared to the 11 other receivers from 6 different makers that I have tested.

Oh, and whoever thought sending out sawtooth corrections after the 1PPS was a good idea needs to treated to a severe atomic wedgie...

-------------------
> What does u-center report for the NEO-6M?
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Keenan Tims]

FYI, u-center works fine in Wine. It also works (and installs)
perfectly in a Windows VM without any network access. So I don't know
what problem you're having, but I don't think it's caused by ublox.

On 1 June 2016 at 14:02, Mark Sims <***@hotmail.com> wrote:
> I have no idea... I can't run Ucenter. It requires an internet connection to run (or at least register). All my current Windoze boxes are XP, and there's no way in hell I'm connecting an XP box to the internet. Other GPS makers don't have such a requirement to use their software, so I avoid using Ublox products.
>
> I'm pretty sure the issue is the "when does the time message come out in relation to the 1PPS" question. It seems Ublox is the odd man out compared to the 11 other receivers from 6 different makers that I have tested.
>
> Oh, and whoever thought sending out sawtooth corrections after the 1PPS was a good idea needs to treated to a severe atomic wedgie...
>
> -------------------
>> What does u-center report for the NEO-6M?
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mark Sims]

Versions past 8.16 no longer run on XP. For versions 7 (and earlier) Ublox only offered a Windows downloader program to download the actual program. That was what I ran into earlier. I just downloaded the 8.16 version and it does work under XP and does not need a net connection.

BTW, the Neo-6M documentation on the receiver version info message is wrong. They say it should return a packet a least 70 bytes long (with software version, firmware version, rom version, and optional feature versions). The Neo-6M only returns 40 bytes (software version, firmware version).

----------------------
> So I don't know what problem you're having, but I don't think it's caused by ublox.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@hotmail.com said:
> The Z3801A has it messed up... it says the leap will occur on 30 Sep 2016
> (73 days). The Z3801A has two different messages that report the leap
> day... both are wrong.

Which messages are you looking at?

There is a leap-pending flag in the T2 message. I don't see it on yet.

ntpd has a hack filter to ignore it unless the month is June or December.
That's leftover from 2008. I looked in my old log files. It didn't come on
until July 28, late in the day UTC.


--
These are my opinions. I hate spam.



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

[Mark Sims]

I get the Z3801A leap pending flag from the #T1 or #T2 time stamp in the :PTIM:TCOD? response. For the date, either :PTIM:LEAP:DATE? or :PTIM:LEAP:GPST? depending upon the unit type.

And now for some more receiver leapsecond shenanagins:

The Ublox receivers work well. You can calculate the day of the leapsecond from almanac info (gps week and day-of-week) returned in the 0x0B 0x02 leapsecond message.

The Trimble receivers have a leap pending flag in the primary timing message. They also have a message (0x58, subcode 5) that returns the data needed to calculate the date of the leapsecond. However, the GPS week number it returns is not compensated for week rollovers. You need to do that yourself. Also, don't send the original (non-SMT) Resolution-T receiver the 0x38 message to request the 0x58 message. Doing that causes the receiver to get confused for at least three seconds.

The Motorola VP/UT/M12 receivers send the leap pending flag in the @@Bj message. It is supposed to work in all Motorola receivers, but the M12+ always reports no leap pending. The M12's have an @@Gj message that reports the date of the leapsecond, It says 2017/01/01, not 2016/12/31.

None of the other receivers have messages that report leapsecond related info.
-----------------------
> Which messages are you looking at?
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@hotmail.com said:
> I get the Z3801A leap pending flag from the #T1 or #T2 time stamp in the
> :PTIM:TCOD? response.

I see it now. Started a bit after an hour UTC into the new day.

57589 4546.033 127.127.26.1 T22016072001154730+0038 64 0

So either I didn't look carefully enough or it hadn't arrived yet when I was
looking around to compose my previous message.



--
These are my opinions. I hate spam.



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

[Hal Murray]

***@hotmail.com said:
> Here are the results of measuring the difference between the time code in a
> GPS receiver time message and the arrival time of the last byte of the
> message. Negative values mean that the receiver sends the timing message
> after the 1PPS pulse that it describes. The table also shows the standard
> deviation of the message arrival times.

Neat. Thanks.

***@hotmail.com said:
(slight snippage to avoid line wraps)
> Z3812A ... 1450.5 0.6 (ramps 950 .. 1950 over 1000 secs)
> Z3801A ... 1341.5 2.0 (ramps 941 .. 1841 over 1000 secs)

Those ramps don't make sense to me. Mine are consistently right on.

Are you using T1 or T2 format? t1 is the default. I'm using T2. (Seems
unlikely it would make a difference, but stranger things have happened.)




--
These are my opinions. I hate spam.



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

[Mark Sims]

Heather will take either time format, but requests the receiver to send T2 format.

I originally thought the SCPI receivers would be right on time due to my original measurements of their message jitter, but when I started measureing the actual message arrival times... surprise, surprise, surprise! I think the issue is due to the fact that they use Motorola receivers and those ramp the time the message comes out (1 msec per second).

The other surprise was the Jupiter-T message is 1.2 seconds after the 1PPS... that's just plain wrong... it reports the correct leap-second offset, but maybe they are off by a second internally? Maybe premature application of the leap pending? Maybe it's always just plain wrong?

Attached is a plot of the evil Z3801A in action...
------------------------

Those ramps don't make sense to me. Mine are consistently right on.
Are you using T1 or T2 format? t1 is the default. I'm using T2. (Seems unlikely it would make a difference, but stranger things have happened.)

[Hal Murray]

***@hotmail.com said:
> I originally thought the SCPI receivers would be right on time due to
> my original measurements of their message jitter, but when I started
> measureing the actual message arrival times... surprise, surprise, surprise!
> I think the issue is due to the fact that they use Motorola receivers and
> those ramp the time the message comes out (1 msec per second).

One of us is confused. Do you have a scope?

I have 2 different programs. Both agree that the arrival time is stable.

Attached is a histogram. There is no PPS on the system collecting the data
so there is 200 micro-sec peak-peak of noise on the reference clock. But
most of that is due to daily temperature swings and I don't have enough data
to cover that yet.

If you don't find anything, I'll clean up a program so you can run it on your
hardware.

[Hal Murray]

***@hotmail.com said:
> te a histogram of the values (along with the average and standard
> deviation). I'm now using the peak histogram bin(s) to determine the
> message offset time. The histogram technique has the advantage of ignoring
> outlier points that can be caused by the system being tied up / interrupted
> doing other things (like shoving a Windows 10 upgrade up your systems' rear
> I/O port ;-()

How do you determine the bin size?

ntpd has an interesting filter in that area. For refclocks where it has many
samples, it sorts them, then discards roughly 1/3 of them as outliers. The
code is simple. Compute the average then check the first and last samples to
see which is farther away. Drop it, iterate.

--
These are my opinions. I hate spam.



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

[Mark Sims]

Easy, I have a 40000 value array. It keeps count of the number of times each 0.1 msec step between -2000 .. 2000 msecs was seen. If two or more bins wind up with the same max count, I report the average of those bin times, otherwise it's the bin with the highest count. I also dump the counts to a file for later plotting.


-------------------------


> How do you determine the bin size?
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@hotmail.com said:
> A couple of people have asked about the poor message arrival time
> performance of the popular Adafruit Ultimate GPS receiver. I modified
> Lady Heather to analyze the message arrival times using a histogram
> instead of a simple average. When I looked at the histogram data
> (.01 msec resolution), I was rather shocked... With an hour of data,
> most receivers have maybe a couple dozen bins hit, with the peak bin
> several hundred counts above the next lower peak. The Adafruit had
> over 1800 bins hit, with the peak bin having six hits. ...

Have you tried bigger bins? 10 microseconds was too small for me. 100
worked well.

The SiRF chips are famous for horrible timing. The arrival times were spread
over 100 ms, but it was a slow wander rather than random jitter. The pattern
was a sawtooth, but the period was hours to many hours. Something like that
could lead to what you are seeing.

The old Garmin GPS-18 was reasonably good. The new GPS-18x has the same
horrible pattern as the SiRF.




--
These are my opinions. I hate spam.



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

[Hal Murray]

***@hotmail.com said:
> You might want to try a modern GPS receiver. I have some cheap (< $10-20)
> GPS modules with on board patch antennas that work indoors, sitting on the
> floor of the bottom level of a two story stucco-over-wire mesh house, away
> from windows, surrounded on all sides by tall trees, with the patch
> antenna face down on the floor. They acquire and track sats quite well.

Brands an/or models? Do they have PPS? (or typical USB...)



--
These are my opinions. I hate spam.



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

[Hal Murray]

***@hotmail.com said:
> I did a little math on the dates and it looks like the rollover happened in
> the last couple of days...

Thanks for the heads up.

Mine started on Aug 17th

/var/log/ntp/clockstats.20160817:57617 2.033 127.127.26.1
T219970101000002300103
8 64 0

That's from ntpd's clockstats which only logs every 64 samples.

Is there a date code in the serial number (or anyplace else)? I have 2
units. One has rolled over. The other hasn't (yet).
HEWLETT-PACKARD,Z3801A,3542A01377,3543-A
HEWLETT-PACKARD,Z3801A,3542A04389,3543-A

--------

Years ago, I powered up a unit that been off for a long time. It came up
with the wrong date. Feeding it the date before it got lock solved the
problem. (Or something like that.) Has anybody tried that yet?

--
These are my opinions. I hate spam.



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

[Hal Murray]

I had one that screwed up. I power cycled and set the date. It's happy now.


I'm not sure of the exact recipe to tell it the right date. After feeding it
a date of roughly today, the status screen jumped to Jan 2007. After it
found a few satellites and such, it jumped to Sep 2016.


--
These are my opinions. I hate spam.



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

[Mark Sims]

Happy until the next power glitch... the setting does not seem to persist between boots. There may also be other conditions that causes it to forget your date.

And when setting the date, you should disconnect the antenna first, then power on. Once the unit starts tracking satellites you can no longer enter the date.


---------------

> I had one that screwed up. I power cycled and set the date. It's happy now.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[paul swed]

Mark,
From some earlier threads on rollovers. Do you even need to set the time at
all?
Granted not great if the 3801 is a time source, but if its just frequency
do you care?
Thanks
Paul
WB8TSL

On Tue, Sep 6, 2016 at 11:30 AM, Mark Sims <***@hotmail.com> wrote:

> Happy until the next power glitch... the setting does not seem to persist
> between boots. There may also be other conditions that causes it to
> forget your date.
>
> And when setting the date, you should disconnect the antenna first, then
> power on. Once the unit starts tracking satellites you can no longer enter
> the date.
>
>
> ---------------
>
> > I had one that screwed up. I power cycled and set the date. It's happy
> now.
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

Paul,

IIRC, we've never heard reports of GPSDO pulse or frequency outputs being affected by rollovers. In GPS there are internal rollovers every 1, 256, and 1024 weeks but the 1PPS and 10 MHz outputs are not dependent on any of these events. The same is true for leap seconds; they may be mishandled by some GPS receivers, but they have no effect on 1PPS or 10 MHz outputs.

/tvb

----- Original Message -----
From: "paul swed" <***@gmail.com>
To: "Discussion of precise time and frequency measurement" <time-***@febo.com>
Sent: Thursday, September 08, 2016 8:16 AM
Subject: Re: [time-nuts] Z3801A gps week rollover


> Mark,
> From some earlier threads on rollovers. Do you even need to set the time at
> all?
> Granted not great if the 3801 is a time source, but if its just frequency
> do you care?
> Thanks
> Paul
> WB8TSL
>
> On Tue, Sep 6, 2016 at 11:30 AM, Mark Sims <***@hotmail.com> wrote:
>
>> Happy until the next power glitch... the setting does not seem to persist
>> between boots. There may also be other conditions that causes it to
>> forget your date.
>>
>> And when setting the date, you should disconnect the antenna first, then
>> power on. Once the unit starts tracking satellites you can no longer enter
>> the date.
>>
>>
>> ---------------
>>
>> > I had one that screwed up. I power cycled and set the date. It's happy
>> now.
>> _______________________________________________
>> time-nuts mailing list -- time-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[paul swed]

Tom,
Right on the pps and frequency. I should have been far more clear date and
time.
I fired up my 3801 and it locked up just fine. Need to check its message to
see whats its putting out.
I will say that I added 2 AA batteries that seem to be lasting for several
years easily and they keep the memory in the GPS engine going and maybe
that keeps the date and time correct so that once you have corrected the
date and time maybe it sticks.
Regards
Paul.

On Thu, Sep 8, 2016 at 1:05 PM, Tom Van Baak <***@leapsecond.com> wrote:

> Paul,
>
> IIRC, we've never heard reports of GPSDO pulse or frequency outputs being
> affected by rollovers. In GPS there are internal rollovers every 1, 256,
> and 1024 weeks but the 1PPS and 10 MHz outputs are not dependent on any of
> these events. The same is true for leap seconds; they may be mishandled by
> some GPS receivers, but they have no effect on 1PPS or 10 MHz outputs.
>
> /tvb
>
> ----- Original Message -----
> From: "paul swed" <***@gmail.com>
> To: "Discussion of precise time and frequency measurement" <
> time-***@febo.com>
> Sent: Thursday, September 08, 2016 8:16 AM
> Subject: Re: [time-nuts] Z3801A gps week rollover
>
>
> > Mark,
> > From some earlier threads on rollovers. Do you even need to set the time
> at
> > all?
> > Granted not great if the 3801 is a time source, but if its just frequency
> > do you care?
> > Thanks
> > Paul
> > WB8TSL
> >
> > On Tue, Sep 6, 2016 at 11:30 AM, Mark Sims <***@hotmail.com> wrote:
> >
> >> Happy until the next power glitch... the setting does not seem to
> persist
> >> between boots. There may also be other conditions that causes it to
> >> forget your date.
> >>
> >> And when setting the date, you should disconnect the antenna first, then
> >> power on. Once the unit starts tracking satellites you can no longer
> enter
> >> the date.
> >>
> >>
> >> ---------------
> >>
> >> > I had one that screwed up. I power cycled and set the date. It's
> happy
> >> now.
> >> _______________________________________________
> >> time-nuts mailing list -- time-***@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-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mark Sims]

Yes, rollovers should not be a problem and should only affect the date display.

However, I have seen devices/software that use GPS fail to work because of what appears to be an invalid date. It seems that they are validating the data from the receiver and if, for instance, the date is before when the device was made or software was written assumes the GPS has failed. I don't know of any GPSDO's that fail to work, but I do know of systems that use them that fail because of the rollover.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Peter Vince]

Can I just ask why the Z3801As are having week roll-over problems now - I
didn't think it was 2048 weeks since GPS "zero-hour" until late on the 6th
of April 2019?

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

[Bob Camp]

Hi

After the first batch of GPS devices rolled over, the manufacturers came up with a “fix”
for the problem. If the date came out to a number *before* the firmware was issued,
it was corrected forward in time. This only works over a single span of GPS dates.
Depending on when the firmware you have was issued, the failure can occur at any time.

Bob

> On Sep 8, 2016, at 4:34 PM, Peter Vince <***@gmail.com> wrote:
>
> Can I just ask why the Z3801As are having week roll-over problems now - I
> didn't think it was 2048 weeks since GPS "zero-hour" until late on the 6th
> of April 2019?
>
> Peter
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@gmail.com said:
> Can I just ask why the Z3801As are having week roll-over problems now - I
> didn't think it was 2048 weeks since GPS "zero-hour" until late on the 6th
> of April 2019?

It's probably 1024 weeks since a date was built into the firmware.

It's like the year 2000 problem. If you aren't worried about old people and
I tell you somebody was born in 03, you can assume that's 2003 rather than
1903. For GPS, a handy value for the cutoff is the date the firmware was
built. Any date that looks like it is older than the firmware is probably
off by a rollover.


--
These are my opinions. I hate spam.



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

[Peter Vince]

That makes sense - thanks guys!

Peter


On 8 September 2016 at 22:53, Hal Murray <***@megapathdsl.net> wrote:

>
> ***@gmail.com said:
> > Can I just ask why the Z3801As are having week roll-over problems now -
> I
> > didn't think it was 2048 weeks since GPS "zero-hour" until late on the
> 6th
> > of April 2019?
>
> It's probably 1024 weeks since a date was built into the firmware.
>
> It's like the year 2000 problem. If you aren't worried about old people
> and
> I tell you somebody was born in 03, you can assume that's 2003 rather than
> 1903. For GPS, a handy value for the cutoff is the date the firmware was
> built. Any date that looks like it is older than the firmware is probably
> off by a rollover.
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Magnus Danielson]

Hi,

On 09/08/2016 11:53 PM, Hal Murray wrote:
>
> ***@gmail.com said:
>> Can I just ask why the Z3801As are having week roll-over problems now - I
>> didn't think it was 2048 weeks since GPS "zero-hour" until late on the 6th
>> of April 2019?
>
> It's probably 1024 weeks since a date was built into the firmware.
>
> It's like the year 2000 problem. If you aren't worried about old people and
> I tell you somebody was born in 03, you can assume that's 2003 rather than
> 1903. For GPS, a handy value for the cutoff is the date the firmware was
> built. Any date that looks like it is older than the firmware is probably
> off by a rollover.

We had this discussion in NTP context, and people where saying "We won't
fix receiver problems" and where not helpful. When I explained how GPS
time actually worked and just showing how the receivers was attempting
to correct the GPS signal behaviors they realized that 1024 week
wrap-around is more of a GPS generic problem and accepting time modulus
1024 weeks was not too hard. I don't know if that ever made it into the
code thought.

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

[Bob Camp]

Hi


> On Sep 9, 2016, at 3:06 AM, Magnus Danielson <***@rubidium.dyndns.org> wrote:
>
> Hi,
>
> On 09/08/2016 11:53 PM, Hal Murray wrote:
>>
>> ***@gmail.com said:
>>> Can I just ask why the Z3801As are having week roll-over problems now - I
>>> didn't think it was 2048 weeks since GPS "zero-hour" until late on the 6th
>>> of April 2019?
>>
>> It's probably 1024 weeks since a date was built into the firmware.
>>
>> It's like the year 2000 problem. If you aren't worried about old people and
>> I tell you somebody was born in 03, you can assume that's 2003 rather than
>> 1903. For GPS, a handy value for the cutoff is the date the firmware was
>> built. Any date that looks like it is older than the firmware is probably
>> off by a rollover.
>
> We had this discussion in NTP context, and people where saying "We won't fix receiver problems" and where not helpful. When I explained how GPS time actually worked and just showing how the receivers was attempting to correct the GPS signal behaviors they realized that 1024 week wrap-around is more of a GPS generic problem and accepting time modulus 1024 weeks was not too hard. I don't know if that ever made it into the code thought.

The bigger problem for NTP is when the leap second correction process is thrown off by the “time warp”. When leap seconds get fixed in
mid-August rather than the end of June … not a good thing.

Bob

>
> Cheers,
> Magnus
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Magnus Danielson]

On 09/09/2016 01:17 PM, Bob Camp wrote:
> Hi
>
>
>> On Sep 9, 2016, at 3:06 AM, Magnus Danielson <***@rubidium.dyndns.org> wrote:
>>
>> Hi,
>>
>> On 09/08/2016 11:53 PM, Hal Murray wrote:
>>>
>>> ***@gmail.com said:
>>>> Can I just ask why the Z3801As are having week roll-over problems now - I
>>>> didn't think it was 2048 weeks since GPS "zero-hour" until late on the 6th
>>>> of April 2019?
>>>
>>> It's probably 1024 weeks since a date was built into the firmware.
>>>
>>> It's like the year 2000 problem. If you aren't worried about old people and
>>> I tell you somebody was born in 03, you can assume that's 2003 rather than
>>> 1903. For GPS, a handy value for the cutoff is the date the firmware was
>>> built. Any date that looks like it is older than the firmware is probably
>>> off by a rollover.
>>
>> We had this discussion in NTP context, and people where saying "We won't fix receiver problems" and where not helpful. When I explained how GPS time actually worked and just showing how the receivers was attempting to correct the GPS signal behaviors they realized that 1024 week wrap-around is more of a GPS generic problem and accepting time modulus 1024 weeks was not too hard. I don't know if that ever made it into the code thought.
>
> The bigger problem for NTP is when the leap second correction process is thrown off by the “time warp”. When leap seconds get fixed in
> mid-August rather than the end of June … not a good thing.

Uhm, not same bug.

The UTC offset message is expressed in GPS-week modulo 256, so if it is
off modulo 1024 does not care, it can adjust leap-second corrections
correctly even if it's can display the correct date.

Naturally, you can implement this incorrectly.

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

[Art Sepin]

Timing product manufacturers used a variety of OEM GPS timing receivers over the years including the Motorola Oncore series. The 1024 Week-Roll-Over dates for Oncore receivers, computed from the firmware version compile date, are listed here:

http://www.synergy-gps.com/images/stories/pdf/motorola%20oncore%201024%20week%20roll.pdf

Synergy is adding 8 channel Motorola binary commands to our u-Blox based SSR-6Tf OEM timing receiver that plugs into an Oncore 8 channel slot - available "soon."

Art Sepin

-----Original Message-----
From: time-nuts [mailto:time-nuts-***@febo.com] On Behalf Of Hal Murray
Sent: Thursday, September 08, 2016 2:54 PM
To: Discussion of precise time and frequency measurement <time-***@febo.com>
Cc: ***@megapathdsl.net
Subject: Re: [time-nuts] Z3801A gps week rollover


***@gmail.com said:
> Can I just ask why the Z3801As are having week roll-over problems now
> - I didn't think it was 2048 weeks since GPS "zero-hour" until late on
> the 6th of April 2019?

It's probably 1024 weeks since a date was built into the firmware.

It's like the year 2000 problem. If you aren't worried about old people and I tell you somebody was born in 03, you can assume that's 2003 rather than 1903. For GPS, a handy value for the cutoff is the date the firmware was built. Any date that looks like it is older than the firmware is probably off by a rollover.


--
These are my opinions. I hate spam.



_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.febo.com%2fcgi-bin%2fmailman%2flistinfo%2ftime-nuts&data=01%7c01%7cart%40synergy-gps.com%7c408bcd4a64434c427d9208d3d832af29%7cc81f9fdec0e04d8c95779afaa0cad9ed%7c1&sdata=jhAM9HQSsGEdLO%2bD6Z4ul5ddcmMTeibYI8J2UGgesYU%3d
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@hotmail.com said:
> Happy until the next power glitch... the setting does not seem to persist
> between boots. There may also be other conditions that causes it to forget
> your date.

I just power cycled mine. It came back correct without setting the date.

I've assumed there is a tiny battery on the GPS board and that it is very old
by now so it may not last very long.

The first try was only a few seconds. I tried again, waiting longer. Maybe
a minute but I didn't time it. It worked again.

-----

There seem to be two internal versions of time. I have a hack that asks for
the time, then displays a status page, the sleeps for a while in a loop. The
T2 time is different from the status page time. It also looks like the
status page time is a second or two behind.

# T22016090900002893+0143
>> Power-up: GPS acquisition Holdover Uncertainty
Tracking: 0 Not Tracking: 6 UTC 11:59:56 [?] 01 Jan
2007

# T22016090900005893+0146
>> Power-up: GPS acquisition Holdover Uncertainty
Tracking: 0 Not Tracking: 6 UTC 12:00:09 [?] 01 Jan
2007

# T22016090900012893+0144
>> Power-up: GPS acquisition Holdover Uncertainty
Tracking: 0 Not Tracking: 6 UTC 12:00:39 [?] 01 Jan
2007

# T22016090900015893+0147
>> Power-up: GPS acquisition Holdover Uncertainty
Tracking: 0 Not Tracking: 6 UTC 12:01:09 [?] 01 Jan
2007

# T22016090900022893+0145
>> Power-up: GPS acquisition Holdover Uncertainty
Tracking: 1 Not Tracking: 7 UTC 03:28:35 [?] 09 Sep
2016

# T22016090900025893+0148
>> Power-up: coarse freq adj [TI -95.91 ms] Holdover Uncertainty
Tracking: 2 Not Tracking: 6 UTC 03:29:04 [?] 09 Sep
2016

# T22016090900032763+0142
>> Power-up: fine freq adj [TI +101.0 ns] Holdover Uncertainty
Tracking: 3 Not Tracking: 5 UTC 03:29:34 [?] 09 Sep
2016

# T22016090900035763+0145
>> Power-up: phase alignment [TI +128.0 ns] Holdover Uncertainty
Tracking: 4 Not Tracking: 4 UTC 03:30:04 [?] 09 Sep
2016

# T22016090903303241+003C
>> Locked to GPS: stabilizing frequency TFOM 4 FFOM
1
Tracking: 4 Not Tracking: 4 UTC 03:30:31 09 Sep
2016

# T22016090903310241+003A
>> Locked to GPS: stabilizing frequency TFOM 4 FFOM
1
Tracking: 3 Not Tracking: 5 UTC 03:31:01 09 Sep
2016

# T22016090903313241+003D
>> Locked to GPS: stabilizing frequency TFOM 4 FFOM
1
Tracking: 3 Not Tracking: 6 UTC 03:31:31 09 Sep
2016

# T22016090903320241+003B
>> Locked to GPS: stabilizing frequency TFOM 4 FFOM
1
Tracking: 3 Not Tracking: 6 UTC 03:32:01 09 Sep
2016

# T22016090903323241+003E
>> Locked to GPS: stabilizing frequency TFOM 4 FFOM
1
Tracking: 3 Not Tracking: 6 UTC 03:32:31 09 Sep
2016

# T22016090903330231+003B
>> Locked to GPS: stabilizing frequency TFOM 3 FFOM
1
Tracking: 3 Not Tracking: 6 UTC 03:33:01 09 Sep
2016




--
These are my opinions. I hate spam.



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

[Mark Sims]

The Z3801A status page takes 3 seconds to process/send. Not surprising that the time is a bit off. Lady Heather only requests the SYST:STAT message once per minute (at hh:mm:33 seconds) because it blocks the unit from doing anything else while it is handling it. The main things extracted from the status screen are the satellite positions and signal levels.

The Z3801A T1/T2 message times are correct. The end of the message that sends the T2 time arrives around 20 msecs before the 1PPS pulse.

I don't see a battery anywhere... there might be a capacitor, but, if so, it is not a large super-cap type unit.

--------------

> There seem to be two internal versions of time
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[paul swed]

The gps rcvr does not have a batter but will indeed support an external
battery.
I attached 2 AA batteries in a external easily replaceable holder and ran
the 2 wires to the receiver 10 pin plug. (At least I think it was 10)
I change the batteries every 2 years not so much for voltage as concern for
leakage. Then use the old battery in my wireless mouse.

On Fri, Sep 9, 2016 at 12:51 AM, Mark Sims <***@hotmail.com> wrote:

> The Z3801A status page takes 3 seconds to process/send. Not surprising
> that the time is a bit off. Lady Heather only requests the SYST:STAT
> message once per minute (at hh:mm:33 seconds) because it blocks the unit
> from doing anything else while it is handling it. The main things
> extracted from the status screen are the satellite positions and signal
> levels.
>
> The Z3801A T1/T2 message times are correct. The end of the message that
> sends the T2 time arrives around 20 msecs before the 1PPS pulse.
>
> I don't see a battery anywhere... there might be a capacitor, but, if so,
> it is not a large super-cap type unit.
>
> --------------
>
> > There seem to be two internal versions of time
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mark Sims]

You might want to try some lithium AA cells. They start out around 1.65V. They are MUCH less prone to leakage than any "alkaleak" battery and have a very long shelf-life (i.e. good for low drain memory backups). As always, when adding a backup battery to a GPS, verify that the battery connection pin is not trying to charge an external super-cap or nicad.

----------------------

> I change the batteries every 2 years not so much for voltage as concern for
leakage. Then use the old battery in my wireless mouse.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Charles Steinmetz]

Mark wrote:
> You might want to try some lithium AA cells. They start out around 1.65V. They are MUCH less prone to leakage than any "alkaleak" battery and have a very long shelf-life (i.e. good for low drain memory backups).

Not only that, they have considerably greater energy density and a much
flatter discharge curve than alkalines, and are better at high discharge
rates as well. I haven't used alkaline AA, AAA, or 9-volt batteries for
more than 10 years now. One of the major mfrs at one time made lithium
"C" cells. I still have a stash of them in cold storage, but I haven't
seen them for sale for some time. I looked for lithium "D" cells, but
never found any.

NB: We're (at least, I'm) talking about lithium *primary* batteries,
not rechargeable lithium batteries. The usual chemistry is LiFeS2. For
data, see:

<http://data.energizer.com/PDFs/lithiuml91l92_appman.pdf>

Best regards,

Charles


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

[Hal Murray]

> Here's another way to do it for a wall clock display... set up an
> oscillator/divider (or even a 555 timer) to generate a frequency close to,
> but faster than 65536 Hz. Setup a 16 bit counter clocked by that signal.
> When the 1PPS signal arrives, start the counter. After 65536 pulses the
> counter will overflow... stop the counter (and set up for the next 1PPS
> trigger) when that happens. The Q0 output (lowest bit) from the counter
> will be a burst of 32768 pulses that repeats once a second. Use that to
> drive your clock. The slight pause between bursts of 32768 pulses will not
> be noticed on the clock display.

Neat hack. Thanks.

You can do it with a tiny micro. Some of them come with builtin R-C
oscillators so the parts count would be really low.


--
These are my opinions. I hate spam.



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

[Hal Murray]

> it did when my Z3801A did a false leap-second at the end of September.

Was there a similar problem/opportunity at the end of Oct? Should we watch
at the end of Nov (last chance for a while)?

What did the Z3801A do? Was the bug in the Z3801A or in an ancient version
of ntpd without the fix I added (ages ago) to handle the leap second getting
announced more than a month early?


--
These are my opinions. I hate spam.



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

[Hal Murray]

***@gmail.com said:
> Sorry Don, I beg to differ. The effects are often not noticeable in these
> days of digital television, but the noise-floor can definitely be seen to
> rise dramatically on a spectrum analyser.

Right. But I think that's because the sun is lining up with the satellite
rather than the ionosphere is getting trashed and messing up propagation.


--
These are my opinions. I hate spam.



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