Re: [time-nuts] Meinberg (Rode & Schwartz), ED170MP GPS Receiver

[Martin Burnicki]

Time wrote:
> Does anyone have any information for the Meinberg (Rode & Schwartz), ED170MP
> GPS Receiver?

If you send email to techsupp...@meinberg.de then I'm sure my colleagues
of the support group can help. It would be good if you specify a little
bit more detailed which information you're interested in.

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

Re: [time-nuts] WWVB Antenna revisited/Spectracom 8182

[Martin Burnicki]

paul swed write:
> I'll add to the comments the spectracoms are phase tracking receivers and
> do not work on the new BPSK  signal.

When the German PTB made effort to increase the accuracy and reliability
of the DCF77 long wave receiver in the 1980s, they implemented thus in a
way that old receivers of the original AM modulation would not be affected:
https://www.ptb.de/cms/en/ptb/fachabteilungen/abt4/fb-44/ag-442/dissemination-of-legal-time/dcf77/dcf77-phase-modulation.html

If I remember correctly then there were some discussions with folks a
NIST when they were going to introduce their new modulation scheme, but
even though the guys at NIST knew that their approach would break
existing receivers, they implemented it anyway that way, even though
other (compatible) ways would have been available. :-(

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

Re: [time-nuts] On the IETF leap-seconds.list SHA1

[Martin Burnicki]

Am 21.12.2017 um 07:37 schrieb Hal Murray:
>> I am still unable to access the NIST ftp-site linked earlier in this thread.
> 
> There have been several URLs mentioned.
> 
> If you want:
>   ftp://time.nist.gov/pub/leap-seconds.list
> Try 
>   ftp://ftp.nist.gov/pub/time/leap-seconds.list
> 
> Any attempts at web/ftp-ing to time.nist.gov are very likely to not work.
> Don't waste your time trying.  That's their rotating DNS for NTP servers.
> 
> I think the original plan was to have all the NTP sites mirror the FTP info 
> but it didn't work out.
> 
> 

Indeed, originally the NIST version of the leap second file was made
publicly available via FTP access to each of the NIST time servers.

However, according to a note on
https://www.nist.gov/pml/time-and-frequency-division/services/internet-time-service-its

FTP access to the time servers has been phased out, and all of the
public files including the leap second file have been moved to these
public FTP sites:

ftp://ftp.nist.gov/pub/time (directory listing)
ftp://ftp.nist.gov/pub/time/leap-seconds.list (leap second file)

and

ftp://ftp.boulder.nist.gov/pub/time (directory listing)
ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list (leap second file)

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

Re: [time-nuts] On the IETF leap-seconds.list SHA1

[Martin Burnicki]

Martin Burnicki wrote:
> See also a summary at
> https://www.meinbergglobal.com/download/burnicki/the_ntp_leap_second_file.pdf

I saw that the leapseconds file provided by USNO is outdated, and FTP
access to the NIST sites has changed, so I've just updated the PDF
accordingly.

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

Re: [time-nuts] On the IETF leap-seconds.list SHA1

[Martin Burnicki]

Martin Burnicki wrote:
> According to an email from Judah Levine (NIST) the current version of
> the leap second file is available via anonymous FTP from all public NIST
> NTP servers. A list of these servers and the status of each server is
> available at
> http://tf.nist.gov/tf-cgi/servers.cgi
> 
> which is linked to from
> http://tf.nist.gov/

I just saw that the main page http://tf.nist.gov/ has moved. It's now
https://www.nist.gov/pml/time-and-frequency-division  or
https://www.nist.gov/pml/time-and-frequency-division/services/internet-time-service-its

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

Re: [time-nuts] On the IETF leap-seconds.list SHA1

[Martin Burnicki]

Anders Wallin wrote:
> Thanks,
> I added the IANA URL to my list, and sent them an e-mail.
> I can't seem to reach the nist ftp-server - does it work for anyone?

Please note the global address time.nist.gov is resolved to a number of
public servers in a round-robin sequence. Some of the servers may not be
reachable due to a high load, and others might resolve to IPv6 addresses
and thus can only be reached if there is a direct IPv6 or IPv6-over-IPv4
tunnel to the internet.

According to an email from Judah Levine (NIST) the current version of
the leap second file is available via anonymous FTP from all public NIST
NTP servers. A list of these servers and the status of each server is
available at
http://tf.nist.gov/tf-cgi/servers.cgi

which is linked to from
http://tf.nist.gov/

See also the PDF I mentioned in the email I just sent a minute ago.

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

Re: [time-nuts] On the IETF leap-seconds.list SHA1

[Martin Burnicki]

John Hawkinson wrote:
> Umm, the presence of a copy of the IANA TZ distribution at 
> https://www.ietf.org/timezones/ is not evidence of an "IETF leap-seconds 
> list." This is bizarre, and probably a web server configuration error that 
> even exists. The IETF is not involved in this list. I guess this shows why 
> Google is an unreliable indicator of authority.
> 
> https://www.ietf.org/timezones/data/leap-seconds.list
> is not a URL anyone should be depending on.
> 
> https://data.iana.org/time-zones/code/leap-seconds.list
> is perhaps a better URL for the file in the tz distribution, but I'd 
> hestitate to call it canonical. Start at https://www.iana.org/time-zones.
> 
> But then the tz database isn't an authorative source, either. Per the NEWS 
> file:
> 
> The 'leapseconds' file is now generated automatically from a
> new file 'leap-seconds.list', which is a copy of
> .
> A new source file 'leapseconds.awk' implements this.
> The goal is simplification of the future maintenance of 'leapseconds'.
> 
> That is, it's just a copy of NIST's file.

In fact, when NIST or IERS have provided a new leap-seconds.list file
then it is picked up somewhat later by the TZ database maintainers, and
updated in the TZ database.

The IERS page only provides the content of the last recently released TZ
database package, so the updated leap-seconds.list file will only appear
on the IERS page after a new version of the TZ database has been
released, whenever that happens.

So there may be a significant delay until an updated leap-seconds.list
file becomes available at the IETF web site, and I strongly suggest to
pick that file up from either
ftp://time.nist.gov/pub/leap-seconds.list

or
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list

See also a summary at
https://www.meinbergglobal.com/download/burnicki/the_ntp_leap_second_file.pdf

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

Re: [time-nuts] Test WWV timecube against Cesium, Rubidium, MASER or other precision time (UT-1) metrology

[Martin Burnicki]

Hal Murray wrote:
> 
> kb...@n1k.org said:
>> To get the accuracy into the 1 ms range on WWV, you would need a pretty good
>> idea of the path length between you and WWV. 
> 
> Dave  Mills has a program to compute delays.
> 
>  * By default it prints out a summer (F2 average virtual height 350 km) and
>  * winter (F2 average virtual height 250 km) number.  The results will be
>  * quite approximate but are about as good as you can do with HF time anyway.
>  * You might pick a number between the values to use, or use the summer
>  * value in the summer and switch to the winter value when the static
>  * above 10 MHz starts to drop off in the fall.  You can also use the
>  * -h switch if you want to specify your own virtual height.
> 
> What's the height difference between night and day?
> 
> This was google's first response.
>   https://opensource.apple.com/source/ntp/ntp-136/clockstuff/propdelay.c

Hm, this file is part of the standard NTP source code package available
here:
http://support.ntp.org/bin/view/Main/SoftwareDownloads

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

[time-nuts] The "atomic second" turns 50

[Martin Burnicki]

The "atomic second" turns 50
https://idw-online.de/de/news682346
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] NTP linked PC clock is slightly ahead of Lady Heather GPS time

[Martin Burnicki]

Hi Rob,

Rob Kimberley wrote:> I'm using the Meinberg NTP Distribution here with
their NTP Monitor prog on Win10-64, and two GPS NTP servers.> > Config
settings: -> >server 192.168.1.120 iburst minpoll 4 maxpoll 5>
server 192.168.1.121 iburst minpoll 4 maxpoll 5> > Consistent sub
millisecond results. I've also found that Win10 actually performs way
better than Win7.
This is because with Windows 8 and newer there is a new API call to read
the system time with 100 ns resolution. The older API provides only 1 ms
resolution.

ntpd uses the new API, if available.

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

Re: [time-nuts] Ships fooled in GPS spoofing attack suggest Russian cyberweapon

[Martin Burnicki]

Hi Björn,

bg wrote:
> Hi Martin,
> No there was also a SDR hack to spoof.
> http://www.rtl-sdr.com/cheating-at-pokemon-go-with-a-hackrf-and-gps-spoofing/

This sounds indeed like a nice way to test if a real spoofing approach
is working properly, so it could also be used to do really evil things.

But of course it's a nice way to demonstrate how easy it's possible.

Thanks for the pointer.

Martin

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

Re: [time-nuts] Ships fooled in GPS spoofing attack suggest Russian cyberweapon

[Martin Burnicki]

Clint Jay wrote:
> No, this was not the software hack, it was done with some rather nice
> Rohde&Schwarz test equipment.

Ah, OK, of course that's also possible.

However, what I found was much simpler:
https://devs-lab.com/how-to-play-pokemon-go-without-moving-no-root-required.html

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

Re: [time-nuts] Ships fooled in GPS spoofing attack suggest Russian cyberweapon

[Martin Burnicki]

Clint Jay wrote:
> Absolutely, their use of it was for something trivial and my reason for
> using that example was to show how 'simple' and available the technology is
> if a couple of students could do it with lab equipment that anyone can buy
> (obviously you'd need deep pockets).

I just searched for "Pokémon GO GPS spoofing" on the 'net.

Looks like this was just a hack in Android where apps were provided with
a spoofed position from the hack instead of the true position determined
by the GPS/GNSS receiver.

So this is quite a different thing than spoofing the real GPS signals,
and it only affects the devices which have that hack installed.

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

Re: [time-nuts] Ships fooled in GPS spoofing attack suggest Russian cyberweapon

[Martin Burnicki]

Clint Jay wrote:
> Absolutely, their use of it was for something trivial and my reason for
> using that example was to show how 'simple' and available the technology is
> if a couple of students could do it with lab equipment that anyone can buy
> (obviously you'd need deep pockets).
> 
> That it can "so easily" be spoofed (it's not a trivial hack to spoof and
> would, as far as I can see, take good knowledge of how GPS works and skill
> to implement) is worrying and it could have disastrous consequences if
> anyone decided to use it for malicious means but I'd be surprised if there
> wasn't a turnkey solution available to anyone who has the funds.

I absolutely agree.

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

Re: [time-nuts] Ships fooled in GPS spoofing attack suggest Russian cyberweapon

[Martin Burnicki]

Clint Jay wrote:
> It might have been a hoax but I'm sure I saw it demonstrated by a couple of
> students who used it to fool Pokémon go...

Yes, I read about that, too. However, related to Pokémon go it's just
fun, but related to serious application it can cause quite some damage.

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

Re: [time-nuts] Ships fooled in GPS spoofing attack suggest Russian cyberweapon

[Martin Burnicki]

Clint Jay wrote:
> Didn't someone demonstrate this using some rather expensive but 'off the
> shelf' Rohde & Schwarz lab gear a year or so ago?

https://news.utexas.edu/2013/07/29/ut-austin-researchers-successfully-spoof-an-80-million-yacht-at-sea

https://sofrep.com/46818/gps-spoofing-how-iran-tricked-us-patrol-boats-into-capture/

Martin

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

[time-nuts] Article at gpsworld.com: NASA describes expected impact of total eclipse on GPS

[Martin Burnicki]

This may be interesting for time nuts:

NASA describes expected impact of total eclipse on GPS
http://gpsworld.com/nasa-describes-expected-impact-of-total-eclipse-on-gps/

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

Re: [time-nuts] SOPHOS discussion of GPS jamming and eLoran

[Martin Burnicki]

Dave B via time-nuts wrote:
> Or...
> 
> http://bit.ly/2hGKTgXThat goes to:-

There are 2 problems I see with this kind of link:

1.) A user doesn't see where the link takes him before he has clicked on
the link, so he can easily be taken to a "bad" web site.

2.) These short links eventually expire after some time, so if you find
an email with the short link later in the ML archive then the short link
may not work anymore, even though the original link may still be valid.

Martin

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

Re: [time-nuts] Can Lady Heather set PC time directly from a TrimbleThunderbolt?

[Martin Burnicki]

Chris,

Chris Albertson wrote:
> I'm not a fan of Meinberg because of the way they market freely
> available software.

I'm sorry you feel this way.

We at Meinberg have supported the NTP project for many years, by
donations of money and hardware, testing, submitting bug reports and
patches. There've been also enhancements like the initial leap second
handling code in the Windows port of ntpd, workarounds for limitations
in Windows to increase the possible accuracy under Windows, etc.

Quite some years ago there was no easy way to install ntpd under
Windows, so one of my colleagues had the idea to put a GUI setup program
together which makes installation under Windows as simple as possible
even for inexperienced users.

When we started this, we also discussed with the other NTP developers
and agreed that we would and should provide the installer via the
Meinberg download page, where we clearly say that the setup program
provides a precompiled version built from the public source code that is
available at ntp.org.

The installer is also free of charge, and there are no duties implied by
using it.

So once more, I feel sorry that you have such a bad feeling about this,
which has just been introduced to make NTP more popular even for users
who are not time nuts.

If you know how to do it you can still build your own binaries from the
original source code.

Martin

(who is biased since working at Meinberg)

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

Re: [time-nuts] Can Lady Heather set PC time directly from a TrimbleThunderbolt?

[Martin Burnicki]

Adrian Godwin wrote:
> Could Lady Heather provide an NTP server so a local NTP client could access
> the GPS time ? Or is that an overcomplicated way to do it?

If LH can adjust the system time (I don't know if it can) then you could
in addition install ntpd and configure the "local clock" 127.127.1.0 as
the only reference time source.

Then ntpd does not adjust the system time but makes the adjusted system
time available to NTP clients on the network.

Martin

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

Re: [time-nuts] Manual and Software for R&S (Meinberg) ED170MP GPS Receiver?

[Martin Burnicki]

Dave,

Dave Hallidy wrote:
> All-
> 
> I just acquired a Rohde & Schwarz (actually a Meinberg) ED170MP GPS Receiver
> (and antenna) and I'd like to get it going.
> 
> Can someone here point me to the manual and any software for it?

Please contact techsupp...@meinberg.de for help. I'm sure our support
guys can help you.

Martin (working @Meinberg)

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

Re: [time-nuts] Observations of NTP during the leap second

[Martin Burnicki]

Deirdre O'Byrne wrote:
> My setup is a raspberry pi running Linux 4.1.19 and ntpd version 4.2.6p5.
> It's being fed a PPS signal from a GPS receiver, and also checks the time
> against the ntp pool.
> 
> For the second starting at 23:59:58.0 UTC, NTP was reporting second number
> 0xdc12c4fe, and had its leap second flag set.
> 
> For the second starting at 23:59:59.0 UTC, NTP was reporting second number
> 0xdc12c4ff, and the leap second flag was *not* set!
> 
> For the second starting at 23:59:60.0 UTC, NTP was again reporting second
> number 0xdc12c4ff, and the leap second flag was not set.
> 
> For the second starting at 00:00:00.0 UTC, NTP was reporting second number
> 0xdc12c500, and the leap second flag was not set.
> 
> I would have thought NTP would have the leap second flag set at least until
> 23:59:60.0.

This was a bug in in ntpd 4.2.6, which has been fixed in 4.2.8. See:
http://bugs.ntp.org/show_bug.cgi?id=2250

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

Re: [time-nuts] A (slightly) different apu2 question

[Martin Burnicki]

Wojciech Owczarek wrote:
>>
>>
>> NTP does not require softstamps.  NTP can be (and I believe it has been in
>> a product) modified to use "PTP" hardware (hardstamps) and  reasonably
>> current releases can run with "drivestamps" (sampled in the NIC driver)
>> between cooperating endpoints.
> 
> 
> Of course it does not *require* software timestamps, I never said that, it
> is just the fact that most people use it with software timestamps, even if
> the NIC permits hardware timestamps. You need a secondary servo to sync the
> NIC to O/S clock if you want to serve that (or consume that) - or sync the
> NIC to external 1PPS. What you call a "drivestamp", I call a software
> timestamp. If it's not a function of the silicon, it's software. All I
> meant was that there is some unexploited potential.

Just a few thoughts regarding NTP vs. PTP:

IMO NTP can yield pretty good results even over WAN connections
*without* the requirement of special hardware which supports
timestamping of network packets, including special switches and routers,
even over WAN connections, and in the presence of network jitter. For
example from one of my workstation running Linux, here in Germany:

   remoterefid st t when poll reach   delay   offset  jitter

*SHM(0)  .shm0. 0 l48  3770.000   -0.001   0.000
 lt-martin.py.me .MRS.  1 u9   64  3770.095   -0.005   0.020
 ntp-master-1.py .PPS.  1 u   58   64  3770.191   -0.019   0.013
 ptbtime1.ptb.de .PTB.  1 u   11  128  377   11.9270.256  74.533
 ptbtime2.ptb.de .PTB.  1 u   16  128  377   11.7060.085  79.565
 ptbtime3.ptb.de .PTB.  1 u   35  128  377   11.5900.058  74.049
 time-b.timefreq .ACTS. 1 u  103  128  377  198.358   -1.377  91.992

where

- SHM is a local GPS PCI card

- lt-martin and ntp-master-1 are GPS controlled NTP servers on the local
network

- ptbtime{1,2,3} are the public NTP servers operated by the German
metrology institute PTB, reached via 7 network hops

- time-b.timefreq is a public server in the U.S., reached via 9 network
hops, including a trans-atlantic connection.


Of course, PTP can do *much* better if special hardware is being used.

We have made tests here at Meinberg where we could demonstrate that NTP
yields the same level of accuracy as PTP with a patched ntpd which
supports hardware time stamping of NTP packets. We used an own time
stamp unit which can also time stamp NTP packets.

There are 2 problems with this, though:

1.) While the PTP folks have been requesting support for time stamping
PTP packets in NIC chips as well as specific PTP support by switches and
routers for a long time, this hasn't happened for NTP.

So today we have indeed NIC chips which time stamp PTP packets, and
switches which are PTP-aware and measure the propagation delay of PTP
packets (in transparent clock mode) so that the PTP daemon can
compensate this delay and eliminate the network jitter.

There's no such thing for NTP.

2.) In the original approach introduced by PTP an outgoing packet is
time stamped by the NIC, and then a "followup" packet is sent which
contains that time stamp ("twostep" mode). This eliminates the
processing delay between the time a packet is sent out by the daemon
until it goes onto the network cable.

NTP doesn't support this feature, and introduction of this feature would
either break compatibility of the existing NTP protocol, or would
require the definition of a new protocol version, e.g. NTPv5.
(BTW, I'm aware of ntpd's "interleave" mode, but IMO that's just a hack,
and doesn't even work with normal client/server packet exchanges).

Of course PTP has a "onestep" mode today where a time stamp is taken as
soon as the packet goes out on the wire, and that time stamp is inserted
into the same packet on the fly, so no followup packet is required.

However, this requires even more sophisticated hardware which explicitly
supports this, and even if this was available for NTP this still
wouldn't solve problem of NTP time stamping support missing in NICs and
switches.

So I think NTP still meets the requirements of many users, without
requirement for specific hardware, while PTP can be used to yield a much
higher level of accuracy if you have dedicated hardware available.

Martin

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

[time-nuts] Technical Paper: GPS Receiver Impact from the UTC Offset (UTCO) Anomaly of 25-26 January 2016

[Martin Burnicki]

There's now a paper with an analysis of the problem available:
http://www.gps.gov/systems/gps/performance/2016-UTC-offset-anomaly-impact.pdf

Martin

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

Re: [time-nuts] Need Time Help

[Martin Burnicki]

You can find some information here :
https://www.meinberg.de/download/burnicki/time_synchronization_accuracy_with_ntp.pdf
Please note the resolution of the system time in Win XP is only about 16 ms. 
The NTP service tries to extrapolate the system time to yield better 
resolution, but applications suffer from 16 ms anyway. 

Martin 

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

Re: [time-nuts] What's the best Windows 10 ntp client?

[Martin Burnicki]

Clay Autery wrote:
> NTP Time Server Monitor by Meinberg.

Sorry, no.

As the name suggests this is only a *monitor* program for NTP service
(ntpd). You can use it to start/stop the NTP service, have a graphical
presentation of the loopstats files optionally generated by ntpd, etc.

So this is a nice optional addon for ntpd, but you need ntpd to actually
synchronize the system time. The monitor program doesn't do that.

Martin (working @meinberg)

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

Re: [time-nuts] What's the best Windows 10 ntp client?

[Martin Burnicki]

Dr. David Kirkby wrote:
> At my amateur radio club we have Internet access via a WiFi dongle with a Pay 
> As You Go card. A Windows 10 PC is only powered up while we are there, so on 
> around 2-4 hours per week. 
> 
> Does anyone have any thoughts on what might be the most suitable software to 
> run on our Windows 10 PC to set the time correct? 

It depends on the accuracy requirements you have. Getting high accuracy
under Windows can be pretty tricky.

Some days ago tvb asked me off-list about details on timekeeping under
different Windows versions, and I've put some information together here:
https://www.meinbergglobal.com/download/burnicki/time_synchronization_accuracy_with_ntp.pdf

I've also put some measurement results together, which you can find here:
https://www.meinbergglobal.com/download/burnickintp_and_windows_history.pdf

These articles are PDF exports from Meinberg-internal wiki pages, so
they may not be particularly well formatted. Sorry for that.

> Someone installed "Dimension 4" 
> 
> http://www.thinkman.com/dimension4/

I've never tried this.

> As far as I can see, this takes the time from one single NTP server, which I 
> believe is not a good idea.  However,  given we only run the PC on 2-4 hours 
> per week,  maybe no ntp client will work well,  but I would have thought 
> using multiple servers being better than one. 
> 
> I am wondering if anyone has any better suggestions for software. .

Again, it depends on the accuracy requirements you have. The NTP daemon
(ntpd) from ntp.org has been designed for long-term operation. It tries
to determine the clock drift of the local computer, and compensate it.

The Windows port also includes a couple of workarounds for limitations
in the Windows kernel, and IMO yields very good results under the given
conditions.

Martin

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

Re: [time-nuts] Using the HP 58503a to correct your PC clock

[Martin Burnicki]

Ron,

Ron Ott wrote:
> The Meinberg page I'm reading has NTP downloads for Windows XP and newer and 
> for older versions of Windows. If you meant a special version of NTP for 
> Windows 7, I didn't see mention of it.

Why do you think "Windows XP and newer" doesn't include Windows 7, 8,
and 10?

Martin (working @Meinberg)

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

Re: [time-nuts] Looking to find an antenna for a TrueTime XL-DC

[Martin Burnicki]

Alexander Pummer wrote:
> Meinberg https://www.meinbergglobal.com/ makes complete down and up
> converter for GPS remote antennas

That's true, but they have been designed for the frontend assembled in
Meinberg GPS receivers. I doubt they work with Truetime devices.

Martin (working @Meinberg)

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

Re: [time-nuts] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

[Martin Burnicki]

Bob,

Bob Camp wrote:
> Hi
> 
> The practical problem with any change to leap seconds is transition from what 
> we have
> to the “new system”. Anything other than dropping them altogether involves a 
> *lot* of 
> coordination. You pretty much have to pick a date and bring everything onto 
> the new
> standard then. For testing purposes your time sources should “advertise” the 
> new 
> information ahead of that date. As a practical point, that means a new field 
> in the data. 
> In the case of GPS and other space based systems, that’s not going to happen. 

But if you

- stick with the leap seconds with UTC as-is
- let the kernel alternatively run on TAI instead of UTC
- keep existing API calls as they are, returning UTC
- introduce new API calls which tell if the kernel runs UTC or TAI
  and let you query the TAI time stamps

then both kernels and applications could make a change over to the new
timekeeping seamlessly.

I agree this wouldn't fix all problems you may have with leap seconds,
but it would at least avoid problems like "the kernel hangs when the
system time is stepped back by 1 s to account for a leap second".

Martin

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

Re: [time-nuts] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

[Martin Burnicki]

Tom Van Baak wrote:
> Time to mention this again...
> 
> If we adopted the LSEM (Leap Second Every Month) model then none of
> this would be a problem. The idea is not to decide *if* there will be
> leap second, but to force every month to have a leap second. The IERS
> decision is then what the *sign* of the leap second should be this
> month.

Although this approach sound good, it would cause major problems for
users of the German longwave transmitter DCF-77. The data format only
has a "leap second pending flag", which means a leap second is to be
inserted. AFAIK there is no spec to announce a negative leap second via
DCF-77.

Martin

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

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Martin Burnicki]

Jay Grizzard wrote:
> On Tue, Jul 19, 2016 at 11:39:29PM +, Mark Sims wrote:
>> The GPS satellites are now reporting the pending leapsecond...
>>
>> 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.   
> 
> I think some (modern!) Trimble gear may also has a problem. I have an ICM 
> SMT 360 board that's (slowly) flipping back and forth between showing a UTC
> offset of 17 seconds and an offset of 18 seconds. This is their currently
> shipping timekeeping chip, so it's surprising, but I don't know how else
> to explain the behavior outside of a firmware bug.

The UTC/leapsecond data sent by the satellites contains the UTC offset
before and after the leap second event time. This has been 17/17 until
recently, and is 17/18 now.

The GPS satellites didn't start all at the same time to send the new
data set, so there was a period of time where some sats sent 17/17 while
some others already sent 17/18.

So when the GPS receiver always just *showed* information on the current
UTC data set then this is OK. However, the *time* it has *output* should
not have jumped back and forth by 1 second.

Martin

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

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Martin Burnicki]

Gary E. Miller wrote:
> Yo time-nuts@febo.com!
> 
> On Tue, 19 Jul 2016 23:18:18 -0700
> Hal Murray , time-nuts@febo.com wrote:
> 
>> g...@rellim.com said:
 In general there's a common belief that a leap second can only
 occur at the end of June or December. This is false. Don't ever
 hardcode this assumption.  
>>
>>> NTP Classic thinks otherwise:
>>> http://bugs.ntp.org/show_bug.cgi?id=3D1090   
>>
>> If you read the fine print in that bug, you will see that it's a work
>> around for a bug in the HP firmware that is the core of this
>> discussion.

If it's known that certain devices out there have a certain bug then
it's fine IMO to try to fix this in the device-specific part of the
code, i.e. in ntpd's particular refclock driver. As Hal has already
mentioned, I wouldn't consider the refclock driver as belonging to the
core functionality, just because it is part of the code tree.

> Yes, I know the problem being solved.  Like today, the leap second being
> broadcast sooner than ntpd expects, so it picks the wrong month.

If the NTP specs say a leap second pending flag must not be set earlier
than month or 1 day before the leap second occurs then the upstream
software should account for this, regardless whether it's an upstream
NTP server, or a refclock driver.

>From ntpd's point of view:

- If it receives a leap second announcement, in which case should the
announcement be accepted; in which cases (buggy upstream sources) rejected?

- When should ntpd start to pass a leap second pending flag on to its
clients?

- When should ntpd start to pass a leap second pending flag down to the
OS kernel, so that the kernel can handle the leap second?

If the leap second warning is passed too early then there's a good
chance for confusion. If ntpd already has a current leap second file
then it already knows about the upcoming leap second now, but it still
doesn't pass a leap second pending flag to its clients, or to the OS kernel.

Beside this there's still another point:

- What should ntpd do if there are different upstream sources which
disagree about an upcoming leap second?

In current ntpd versions:

- A leap second file has precedence unless it is outdated.

- If no valid leap second file is available then a leap second warning
from a refclock is accepted.

- If no valid leap second file is available then a leap second warning
from upstream NTP server is only accepted if a majority of servers
provide it.

>> I don't think there is anything in the core of ntpd that restricts
>> leap seconds to Jun/Dec.  If there was, it would have filtered out
>> the above problem.

There has been such a check before ntpd 4.2.6, but the code has been
removed in current versions.

> How about this:
> 
> ntpd/refclock_hpgps.c, line 544:
> 
> /* See http://bugs.ntp.org/1090
>  * Ignore leap announcements unless June or December.
>  * Better would be to use :GPSTime? to find the month,
>  * but that seems too likely to introduce other bugs.
>  */
> case '+':
> if ((month==6) || (month==12))
> 
> 
>> Things get interesting if you are shipping code today that will last
>> for 10 or 20 years.  My HP Z3801A has software dates from 1995 so 20
>> years isn't unreasonable.  Of course, they were retired from
>> commercial use a long time ago, so maybe it's OK if the firmware has
>> bugs.
> 
> 20 years?  My house is 40 years old.  In an IoT world people would like
> to not throw away capital equipment every decade.
> 
> But i'm prolly spitting into the wind...
> 
>> I don't know any software projects that handle this sort of thing
>> cleanly. (My exposure is limited.)
> 
> gpsd filters out all but June and December.  So sort of cleanly, but
> clearly work needed.  I notice ntpd also filters out leap warnings for
> the first short bit of the month.  That might be worth doing too.

On systems which support this (Linux, *BSD, etc.) ntpd just passes a
leap second pending flag to the kernel, and the kernel handles the leap
second. However, ntpd has to keep track of its internal leap second flag
which it sends out to the clients.

So only if it polls the kernel status *after* the leap second has
occurred and sees that the kernel's leap second flag has been cleared,
ntpd can clear its internal leap second flag which it sends to the clients.

So there's a chance that ntpd sends a leap second flag to client during
a short interval after the leap second until it has polled the kernel
status again and found that the leap second has passed by.

So if clients accept a leap second flag in advance then it's important
that there's some interval at the beginning of a month where they don't.

> If a giant asteroid hits earth, and we need a negative leap second in 
> March, there will be a lot of urgent patching to do.

Yes. Specifically, the German long wave transmitter doesn't have the
possibility t

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Martin Burnicki]

Magnus,

Magnus Danielson wrote:
> Now, what annoys me is that the IERS message says that the leap second
> is scheduled for January:
> 
> 8<---
> 
>   Paris, 6 July 2016
> 
>   Bulletin C 52
> 
>  To authorities responsible for the measurement and distribution of time
> 
> 
>UTC TIME STEP
> on the 1st of January 2017
> 
> 
>  A positive leap second will be introduced at the end of December 2016.
>  The sequence of dates of the UTC second markers will be:   
>
>   2016 December 31, 23h 59m 59s
>   2016 December 31, 23h 59m 60s
>   2017 January   1,  0h  0m  0s
> --->8
> 
> It is unfortunate that it says UTC TIME STEP on the 1st of January 2017,
> as it is scheduled for 31 December 2016.

Hm, the leap second is inserted at the end of December 31 (which is also
said by the message text), but as a consequence the beginning of January
1 is delayed by 1 second, so IMO this statement might be correct, even
though it's not formulated very clearly.

> This is a new habbit of IERS, and it is unfortunate and not helpful.
> Older Bullentin C used the more correct reference to end of June or end
> of December.

Hm, the oldest bulletin C I found on the IERS web site already has the
same statement:
https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.10

I find it amusing that until ~2011, if no leap second was scheduled, the
message text said:

"NO *positive* leap second will be introduced ..."

If you're nitpicking you could have expected that eventually a
*negative* leap second was to be scheduled. ;-)

Martin

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

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Martin Burnicki]

Hal Murray wrote:
> g...@rellim.com said:
>>> I don't think there is anything in the core of ntpd that restricts
>>> leap seconds to Jun/Dec.  If there was, it would have filtered out
>>> the above problem.
>> How about this: 
>> ntpd/refclock_hpgps.c, line 544:
> 
> I wasn't considering refclocks to be "core" in that context.  Got a better 
> word?
> 
> Have you found any similar code that isn't in one of the refclocks?

ntpd versions before 4.2.6 also had a plausibilty check, which even had
a bug when checking for end of June. See:
http://bugs.ntp.org/show_bug.cgi?id=525#c0

> g...@rellim.com said:
>> 20 years?  My house is 40 years old.  In an IoT world people would like to
>> not throw away capital equipment every decade. 
> 
> Your house gets a new roof occasionally.  The IoT world hasn't figured out 
> how to handle firmware updates and/or people haven't adapted to throwing out 
> gear that looks OK physically but has bugs, especially if the bugs don't 
> break the main function of the device.

Firmware updates? Why would anyone need this? ;-))

> g...@rellim.com said:
>> gpsd filters out all but June and December.  So sort of cleanly, but clearly
>> work needed.  ...
> 
> The sort of "cleanly" I had in mind would be at the project management level. 
>  Handwave.  Each project should keep track of the assumptions in their code 
> that may not be correct many years in the future.  That list should be 
> reviewed occasionally, say every year or few years.

Agreed.

> It also has to be documented in a way that downstream users know what they 
> are getting involved with.  This is a good example.  Tom is arguing for 
> do-it-right according to the specs.  I'm arguing for defensive programming 
> since we have already seen bugs in other gear.

I'd say the best solution would be a combination of both.

> If you were packaging ntpd 
> into a box which would you want?  Will your box last long enough to see a 
> leap second in Mar or Sep?  Is your box going to connect to old/buggy gear?  
> Does your startup have enough funding to consider issues like this, or people 
> smart enough to understand the tangle?

+1

Martin

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

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

[Martin Burnicki]

John Ackermann N8UR wrote:
> Long ago I measured the impact of the linux low_latency flag on a 16550 UART. 
>  I don't know where that data is sitting now, but I remember that it made a 
> significant difference.
>
>> On Jul 18, 2016, at 9:59 PM, Hal Murray  wrote:
>>
>>
>> jim...@earthlink.net said:
>>> except that virtually every UART in use today has some sort of buffering
>>> (whether a FIFO or double buffering) between the CPU interface and the  bits
>>> on the wire, which completely desynchronizes the bits on the wire  from the
>>> CPU interface.
>>
>> The idea was to reduce the CPU load processing interrupts by batching things 
>> up.
>>
>> Some of those chips generate an interrupt when the see a return or line-feed 
>> character.
>>
>> Most of them have an option to disable that batching.  On Linux the 
>> setserial 
>> command has a low_latency option.  I haven't measured the difference.  It 
>> would be a fun experiment.

AFAIK the low_latency flag just sets the UART's FIFO threshold to 1,
i.e. the UART generates an IRQ when the 1st character came in. If you
don't set this flag then the FIFO threshold is set to something different.

A *very* quick search on the Linux source code seems to indicate the
default threshold is 16 in current kernels, but if I remember correctly
then it was 4 or 8 in earlier kernel versions.

If you need to timestamp the 1st character of the serial time string
then things are easy. For example, for Meinberg time strings the
on-rtime character is the 1st character, STX (0x02), and subsequent
characters are sent without gap. So it doesn't matter much if you get an
IRQ after the 1st character, and compensate for 1 character only, or the
IRQ occurs after the 8th character, and you compensate for 8 characters.
But of course you need to know the current FIFO threshold.

I think if you need to timestamp e.g. the CR of LF at the end of a
string which eventually has even variable length then the timing may
vary depending on the actual string length.

E.g., with a FIFO threshold of 16 the first IRQ is generated when 16
characters have been received, but if the whole string is e.g. only 30
characters then only 14 characters follow after the first part, and the
FIFO threshold (16) is never reached by that single string. I'm not sure
if the UART then generates an IRQ anyway after some kind of timeout, but
this seems to make exact timing quite a bit more tricky.

Martin

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

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Martin Burnicki]

Hal Murray wrote:
> 
> michael.c...@sfr.fr said:
>> The relevant NTP leap-seconds-list file can be downloaded with anonymous ftp
>> from the pub directory at time.nist.gov.  (The leap-seconds-list file is a
>> symbolic link to the data file leap-seconds.3676924800 in the same
>> directory. ) 
> 
> The NIST servers at that "host" don't work very well for FTP.  That host name 
> rotates across their NTP servers and a lot of those sites don't have a FTP 
> server on that machine.
> 
> Some of the sites work.
>   ftp://utcnist.colorado.edu/pub/
> 
> The IETF has a copy, but it hasn't been updated yet.
>   http://www.ietf.org/timezones/data/

No, because it's extracted from the TZ database. The leap second file in
the TZ DB is only updated when the next TZ DB version is released after
a new leap second file has been released.

Just recently a patch has been submitted for the TZ DB to update the
leap second file.

> USNO has a similar version:
>   ftp://tycho.usno.navy.mil/pub/ntp/
> Sometimes it doesn't work.  ??
> 
> Meinberg has a version:
>   http://www.meinberg.de/download/ntp/leap-seconds.list

which is a copy of the IERS file available at
https://hpiers.obspm.fr/iers/bul/bulc/ntp/

I've put some information on leap second files together in a PDF:
https://www.meinberg.de/download/burnicki/the_ntp_leap_second_file.pdf

BTW, some GPS satellites began recently to broadcast the leap second
information. The "mbgstatus" program for Meinberg PCI cards reports:

---
t0t: 1906|405504.000, A0: 0 A1: -1.77636e-15
WNlsf: 1929, DN: 7, offs: 17/18
UTC offset transition from 17s to 18s due to leap second
insertion at UTC midnight at the end of 2016-12-31.
---

Martin

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

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

[Martin Burnicki]

Mark, Chris,

Chris Albertson wrote:
> Can't you take care of this in the build system?  I never go near
> Windows, the last version I used was Win 95.  But on other systems I
> always use something like the GNU Auto tools cmake or whatever and
> part of the process is to check for the availability of each system
> call and library and then the source is built using what's on that
> specific machine.   I'd guess that there is something like this in
> Windows.  Is GNU Autoconf ported to Windows?  If so then use
> QueryPerformanceCounter() if it is available.  It seems much cleaner
> to that care of this kind off thing in the build process

The QueryPerformanceCounter() (QPC) call is available on all Windows
Versions since Windows NT. I'm not sure if it was supported on Windows
9x, though. The windows 9x versions were more like DOS with a graphical
user interface.

QPC is implemented in the Windows Hardware Abstraction Layer (HAL). At
least Windows versions around XP were shipped with different versions of
the HAL DLL, and the Windows installer determined during installation
which version to use. The different versions used different timers on
the particular PC, and depending on the timer which was actually used
(TSC, HPET, PMTIMER, ...) the QPC call worked with different clock
frequencies and thus provided different resolution.

When Windows XP was current then current CPU types both from Intel and
AMD had problems with the TSC since the TSC clock frequency could change
when the CPU clock frequency changed due to power savings, and TSCs
might not have been synchronized across different cores in the same
physical CPU.

This is why you could force Windows XP always to use the PMTIMER which
is part of the ACPI support chipset, and if I remember correctly the SP3
for Windows XP did this automatically to avoid problems with the TSC.
You can use the QueryPerformanceFrequency() call to determine the clock
frequency of the timer used for QPC, and the frequency typically tells
you which timer/counter circuit or the PC it actually is.

One important point is that the TSC can be read very much faster than
one of the other timers/counters since its just reading a CPU register,
while other circuits are part of the chip set and need to be accessed
via a peripheral bus.

Modern Windows versions determine much more reliably if the TSC can be
used without problems, or not, and use it, if appropriate.

Modern Windows versions (Windows 8 an newer) also provide some new API
calls which return the system time with higher resolution/precision than
original API calls.

For example, the original API call GetSystemTimeAsFileTime() only had a
coarse resolution of 0.5 to ~ 16 ms, depending on the Windows version
and some conditions. Now there's a new API call
GetSystemTimePreciseAsFileTime() which always provides 100 ns
precision/resolution. Similar with some other call for which there are
"Precise" variant available now.

A common practice is to check at runtime if a "Precise" call is
supported by the OS version under which the application is currently
running.

For example, at program startup try to import the symbol
GetSystemTimePreciseAsFileTime and set up a function pointer with it. If
the symbol can't be imported (e.g. if running on windows XP) set the
pointer to GetSystemTimeAsFileTime, and get system time stamps only by
calls via that pointer. So you have a single executable which benefits
from the "Precise" call if available, and falls back to the standard
call if it's not available.

This page
https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408%28v=vs.85%29.aspx

provides a good overview of the available functions.

Martin

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

Re: [time-nuts] GPS disciplined Mars clock

[Martin Burnicki]

Joe Fitzgerald schrieb:
> 
> What organization is in charge of inserting leap seconds into the
> Martian time scale?

IMRS - International Mars Rotation Service ;-)


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

Re: [time-nuts] GENIUS by Stephen Hawking (PBS TV), with 5071A cesium clocks

[Martin Burnicki]

Hi Tom,

Tom Van Baak wrote:
> The TV show is tomorrow, Wednesday evening. 8/9 PM, or something like that.
> 
> Here are fresh web pages with background information, photos, and plots:
> 
> http://leapsecond.com/great2016a/
> 
> http://leapsecond.com/great2016a/photos.htm
> 
> I have no idea how minor my role is in the actual TV episode, but if nothing 
> else, the above two pages will share some time nuts sort of details of the 
> clock experiment itself. If you have any questions let me know.

Very nice stuff, and great that you've been involved in the show.
Unfortunately it looks like I can't watch the episodes here in Germany. :-(

Anyway, I'll see if the videos appear somewhere on the internet some
time. ;-)

Martin

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

Re: [time-nuts] help

[Martin Burnicki]

Am 3. Mai 2016 18:06:49 MESZ, schrieb Hendrik Dietrich :
>
>Picking up the time from a DAYTIME Server is easier to implement than 
>NTP, these respond just with a string containing date and time.

If you don't want to run NTP then eventually you sould use the "time" protocol 
rather than daytime . 

"time" returns UTC,  but IIRC then daytime can even return some local time,  
and the string format may depend on / vary wit the server you are contacting. 
It's more for human interaction. 

Martin 

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

Re: [time-nuts] WWVB format change in 2012

[Martin Burnicki]

Bob Camp wrote:
> Hi
> 
> WWVB and WWV (like any radio uncorrected radio system) has fairly predictable 
> shifts
> associated with the day / night ionosphere. One *could* fix that issue with a 
> table
> based on station location. I do not know of any library of code that does 
> that already. 
> 
> The next “layer” of trouble comes from how the low cost receivers are 
> implemented. The
> common issue is local noise. The common solution is a narrowband crystal 
> filter in front
> of the receiver. The bandwidth of that filter (and to some extent it’s 
> temperature dependance) place
> a “best case” limit on performance in the 10’s to 100’s of ms range depending 
> on the 
> exact details. There are higher performance receivers (but not a lot of them) 
> that do get into
> the single digit ms range. At that point the propagation issue mentioned 
> above needs some
> work. 
> 
> Further complicating things is the distance factor. A user in Denver with 
> ground wave “view” 
> of the transmitter will do *much* better than the numbers above. A user in 
> Miami or Bangor ME 
> may be very lucky to get close to the numbers above on an intermittent basis. 

I'm basically familiar with the ground wave / sky wave problem. Quite
some time ago I had found a PDF on the 'net with some explanations,
measurements, and a U.S. map showing e.g. which regions were mostly
affected by temporary cancellation due to interference of the sky and
groundwave with the same amplitude.

If I remember correctly this was an old publication from NIST or so.
Eventually it's hard to find by search machines since it wasn't a
generated PDF with text, but just a scan of an old printed article.

Unfortunately I hadn't saved a copy, and now I'm unable to find it.
Anybody has a hint what this could have been?


Thanks,

Martin

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

Re: [time-nuts] GPS Outage

[Martin Burnicki]

Hal,

Hal Murray wrote:
> 
> martin.burni...@burnicki.net said:
>>> Strange that at least 3 independant firmware trees/development teams should
>>> chose the same magic wk860.
> 
>> I don't find it strange. If the next firmware version is based on the
>> previous version and none of the developers has stumbled across this
>> potential problem earlier ... 
> 
> That sounds like poor software engineering.  Or poor engineering management.
> 
> The wk860 is supposed to represent the build time of the software ...

Do you *know* this, or are you just *assuming* this? ;-)

> so it will 
> work for 20 years from when it was built rather than 20 years from when the 
> 10 bit week counter last rolled over or 20 years from when the constant was 
> last updated.

There are also approaches where the proper extension of a week number
doesn't just work within a single 1024 week cycle with some hardcoded
limit, like this simple example:

if ( wn < 860 )
  wn += 1024;

There may always be pieces of code which generate a faulty result under
certain conditions, and no stumbles across this even in reviews until it
really happens.

I'm not aware of *any* project where each single line of code is checked
once again whenever a new release is rolled out.

Martin

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

Re: [time-nuts] GPS Outage

[Martin Burnicki]

Björn wrote:
> "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."
> 
> Have the Motorola Oncore/Navman/Jupiter receivers also been checked for this 
> condition? 

Hm, if this is a bug in the Trimble firmware, why should Motorola or
other brands be affected?

I don't remember I have heard about *this* problem with other GPS
receiver models.

> Strange that at least 3 independant firmware trees/development teams should 
> chose the same magic wk860.

I don't find it strange. If the next firmware version is based on the
previous version and none of the developers has stumbled across this
potential problem earlier ...

Martin

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

Re: [time-nuts] GPS Outage

[Martin Burnicki]

Mark Sims wrote:
>> When is some organization going to explain what happened in February for 
>> almost two hours starting at 00:16 GMT?  That subject has gone silent.  Rob, 
>> NC0B
> I heard back from NAVCEN.  They said it was a Trimble issue and that Trimble 
> would contact me (they didn't).   But that does not jive with reports of 
> failures in Motorola, Navman, etc receivers.

I think we need to distinguish here.

The January 26 issue was due to faulty data sent by the satellites,
which caused GPS receivers to apply a wrong UTC correction which caused
the UTC time to be off by 13.7 us.

As explained by Luc Gaudin from http://naelcom.com (who obviously sell
Trimble GPS receivers) the February 13 issue was indeed just a Trimble
firmware problem. See:
https://www.febo.com/pipermail/time-nuts/2016-February/096042.html
https://www.febo.com/pipermail/time-nuts/2016-February/096050.html

Martin

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

Re: [time-nuts] Next step up from basic GPS/PPS timekeeping

[Martin Burnicki]

Pete Stephenson wrote:
> On Wed, Feb 24, 2016 at 3:22 PM, Neil Green  wrote:
>> I currently operate a stratum 1 NTP server in the NTP pool using a U-Blox 
>> Max-7Q GPS module with PPS attached to, variously, a Raspberry Pi via GPIO 
>> or a Celeron mini PC via serial DB-9. The machine does nothing but serve 
>> time to the pool. Operating systems of choice are Debian or FreeBSD.
>>
>>
>> What would be my next step up be, hardware-wise, in terms of improving 
>> precision, stability, etc? A GPSDO? Budget is limited as far as these things 
>> go - about £150 UK/$210 US.
> 
> For what purpose?
> 
> In my experience, NTP is able to sync other systems to within 10-100
> microseconds of an NTP server on a LAN. The vagaries of the internet
> mean that it's unlikely for NTP clients to sync any closer than a few
> tens of milliseconds.

It can be better, but that's not guaranteed. I'm located in Germany and
have a setup measuring the offset of some NTP servers in the U.S.
against a built-in GPS card, and the offset is below 2 ms most of the time.

Martin

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

Re: [time-nuts] GPS jumps of -13.7 us?

[Martin Burnicki]

NeT MonK wrote:
> On Fri, Jan 29, 2016 at 3:29 PM, Chris Caudle  wrote:
> 
>> On Fri, January 29, 2016 1:32 am, NeT MonK wrote:
>>> As a side effect of those glitch in the GPS matrix, the utc_valid_flag
>> was
>>> not anymore set in the stream of the primary master clock, just before my
>>> secondary starts to become active (loss of primary stream) which leads to
>>> linux server  ptp slave to readjust of +36 seconds and jump backward -36
>>> seconds as far as the flags was coming back.
>>
>> The difference between UTC and TAI is 36 seconds.
>>
>> Are you running ptpd or linuxptp on your Linux servers?
>> It sounds like the ptp agent running on your servers interpreted the lack
>> of UTC valid flag to mean that the timestamps were now in TAI, so the
>> server kernel applied the TAI to UTC offset to the time received via PTP.
> 
> 
> Dear Chris,
> 
> I run sfptpd  which is a fork of linux ptpd daemon adapted to solarflare
> network adapter.
> I will have to fine tune it in order to be more resilient in such scenario.

Hm, the task of the PTP slave software is to discipline the PC's *UTC*
time, but this sounds like it even accepts the time from the PTP
(grand)master if the master has *not* set utc_valid flag to 1, i.e. the
master tells the slave it has no idea about the correct UTC time, but
the slave accepts the uncorrected time anyway.

Maybe in this case the slave software should rather generate an error
and discard the PTP source, instead of accepting and using the pure TAI
time, which causes the PC's system time to go wrong.

> But i guess it's not very often the gps system as such incident.

Of course this is not primarily related to GPS. I'd expect is could
under some other confitions that the utc_valid flag is cleared.

Please not with GPS and UTC correction it's somewhat similar. The GPS
satellites also provide the UTC correction data set, but if you start a
GPS receiver in cold boot mode, i.e. without any satellite data already
saved in non-volatile memory, the GPS receiver is unable to convert GPS
time to UTC, until it has received a UTC parameter set from the
satellites. This can take up to 12 minutes since these parameters are
sent repeatedly every 12 minuts.

Without UTC correction parameters the receiver can be used for
navigation, but not for timing. If a timing GPS receiver would declare
itself "synchronized" in this state then the time which is output would
be GPS time only, not UTC, and a time discipline software which accepted
the time from the GPS in this state would also set the PC system time
wrong by 17 seconds, since this is the current difference between UTC
and GPS system time.

Martin

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

Re: [time-nuts] GPS jumps of -13.7 us?

[Martin Burnicki]

Hello Net Monk,

NeT MonK wrote:
> I have subscribed to this list following this incident as far as it was the
> first of the few results of search in Google for three days ago.
> 
> On my linux platform of hundreds serveurs,  I had incident because of this,
> on servers which only  use of ptp.
> I have two sources grand master clock one I control (a meinberg appliance)
> and act as passive and the second is just a Cisco relaying the ptp stream
> from the market.
> 
> As a side effect of those glitch in the GPS matrix, the utc_valid_flag was
> not anymore set in the stream of the primary master clock, just before my
> secondary starts to become active (loss of primary stream) which leads to
> linux server  ptp slave to readjust of +36 seconds and jump backward -36
> seconds as far as the flags was coming back.
> 
> Am I the only one who suffered the loss of the utc_valid_flag in ptp stream
> ? And what appliance would behave like this ? As far I can tell my
> secondary meinberg appliance aside a few oscillator recalibration message
> in the console log behaved very nicely.
> 
> But I have no view of the primary master source and kind of hardware they
> use.

The time stamps sent in the PTP messages on the network are usually TAI,
not UTC. The PTP announce message contains a UTC offset field telling
the current time difference, and a flag indicating if the UTC parameter
is valid.

Currently the difference between TAI and UTC is 36 seconds, so if the
grandmaster sends no valid UTC offset, or utc_valid flag is not set,
then a client probably just evaluates the raw TAI time, and thus its
time steps by 36 seconds until it receives a PTP announcement message
with valid UTC parameters again.

I don't know the details of your PTP setup, but we (at Meinberg) have
already had another customer some time ago where a Cisco switch acting
as boundary clock didn't send UTC data reliably when the grandmaster was
switched.

So eventually you should contact Cisco and see if there is an update
available for the switch where this is fixed.

Martin

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

Re: [time-nuts] GPS jumps of -13.7 us?

[Martin Burnicki]

Magnus Danielson wrote:
> It's interesting to see how consistent these errors are.
> On the other hand, it is interesting to see how it varies even for the
> same PRN. Look at how PRN 09 varies between +0.002 us and -13.696 us.

Hm, I think basically it doesn't vary. We fortunately just saw the point
in time where it was corrected.

During the problem all affected satellites sent the same, wrong data
set, and obviously a new proper data set was uploaded to or activated on
these satellites, so the stopped sending faulty data and switched to
sending correct data *once*.

Martin

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

Re: [time-nuts] GPS jumps of -13.7 us?

[Martin Burnicki]

brian wrote:
> This may be a dumb question, but I am new to using LadyHeather with my
> Thunderbolt (previously it had been slaved to driving a clock display
> but that broke, which made me get around to installing a serial card in
> my linux box)...
> 
> Are these "events" something I should be able to see in LH?  If so what
> should I be looking for? I see a pair of off-setting events in the
> graphs (a sharp negative spike in DAC Voltage & PPS, followed later by
> a sharp positive spike of the same magnitude),  but not sure if I am
> seeing what I want to see, of if this is actually what I am looking
> for.

It depends on what you mean by "events".

The problem should not affect normal GPS time, so navigation should not
have been affected since only the conversion from GPS time to UTC was
messed up.

If you use the PPS output which normally corresponds to the changeover
of the UTC second then the PPS slope should have stepped by 13.7 us or
not, depending on if and when the GPS receiver accepted the faulty UTC
correction data set from on of the satellites which broadcast it.

If you use the 1 PPS signal to discipline an oscillator thenit depends
on how the oscillator control loop deals with such time step, whether it
silently follows the step, or if it generates some kind of alarm due to
this unusual step.

In this case the problem was visible when you looked at the current UTC
correction parameters decoded from the satellites' nav messages.

For example, using a Meinberg GPS180PEX card with its Linux driver you
can see the following status:

martin@pc-martin:~> mbgstatus -vvv /dev/mbgclock0

mbgstatus v3.4.99 copyright Meinberg 2001-2015

GPS180PEX 029511026220 (FW 2.04, ASIC 8.06) at port 0xE000, irq 16
Normal Operation, 9 sats in view, 9 sats used
Osc type: TCXO, DAC cal: -550, fine: +666
Date/time:  Th, 2016-01-28 08:19:53.05 UTC, st: 0x14
Local HR time:  2016-01-28 08:19:53.0548183 UTC, st: 0x0014
Status info: Input signal available
Status info: Time is synchronized
Status info: Receiver position has been verified
Last sync:  Th, 2016-01-28 08:19:00.00 UTC, st: 0x14
Receiver Position:
  x: 3885686m y: 631143m z: 5001726m
  lat: +51.9824 lon: +9.2258 alt: 167m
  latitude:  N  51 deg 58 min 56.47 sec
  longitude: E   9 deg 13 min 33.05 sec
CSUM: 1615, valid: 0001
t0t: 1881|503808.000, A0: -9.31323e-10 A1: 3.55271e-15
WNlsf: 1851, DN: 3, offs: 17/17
UTC offset parameter: 17s, no leap second announced.

where the line starting with "t0t" prints the UTC correction data which
was faulty in this case.

While the problem occurred I ran this command periodically and grepped
the t0t line only, so at the "recovery" time you cold see this:

t0t: 1792|0.000, A0: -1.3696e-05 A1: 1.24345e-14
t0t: 1792|0.000, A0: -1.3696e-05 A1: 1.24345e-14
t0t: 1792|0.000, A0: -1.3696e-05 A1: 1.24345e-14
t0t: 1792|0.000, A0: -1.3696e-05 A1: 1.24345e-14
t0t: 1881|319488.000, A0: 0 A1: 1.24345e-14
t0t: 1881|319488.000, A0: 0 A1: 1.24345e-14
t0t: 1881|319488.000, A0: 0 A1: 1.24345e-14
t0t: 1881|319488.000, A0: 0 A1: 1.24345e-14
t0t: 1881|319488.000, A0: 0 A1: 1.24345e-14

Please note the week number here is the fully expanded week number:

1792 == 0x700, i.e. the 8 bit truncated value is 0, which is wrong
1881 == 0x759, i.e. the 8 bit truncated value is 0x59 == 89 correctly

Unfortunately I don't know if the thunderbold can output this kind of
data, and if LH can display it. I've not played with those, yet.

Martin

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

Re: [time-nuts] GPS PRN 32

[Martin Burnicki]

Magnus Danielson wrote:
> Charles,
> 
> Considering how the UTC parameters (IS-GPS-200H, Table 20-IX and section
> 20.3.3.5.2.4) got upset for some of the SVNs, the correction from GPS
> time (as corrected for that PRN) into UTC got a shift of almost 13,7 us.
> As a GPS receiver receives information, solves for position and time
> (fixed timing receivers naturally only for time), correct into GPS time
> and then into UTC you end up with having to select the information from
> one of the GPS satellites for translating the GPS time into UTC time.
> Depending on the state of that GPS receiver, it may or may not select
> this bad info, and it may change selection at any time. That's why we
> have observed receivers of the same brand and same FW fail at different
> times, but starting having problems at the same trigger time. While
> there can be receivers that have some form of protection from this
> particular problem, I guess many don't, and in this case, the specifics
> of the receiver FW and the actual state of the receiver may have cause
> the full range of heavy to no impact. I would be careful to make to much
> judgment of various receivers because of this. It is clear that it's a
> serous hit to at least most of them.

Absolute correct, IMO.

> I remember the impacts from PRN 31 and PRN 32. The re-occuring GPS WN
> wrapping issue is another. This instance is rather unique in it being
> related to the ground infrastructure seems to have provided bad upload.
> 
> There is an intense amount of work behind the scenes. Some patience will
> be needed before even a minimalistic statement can be found.

Now there's a statement available. See my other post.

Martin

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

Re: [time-nuts] GPS jumps of -13.7 us?

[Martin Burnicki]

Paul Boven schrieb:
> Hi everyone,
> 
> Has anyone else seen GPS time jump by -13.7 usec today?
> I just heard from several geographically quite distributed radio
> observatories that they have seen their GPS receiver(s) jump compared to
> their in-house standards.

We have now received an official statement from USCG:

-Original Message-
> From: Hamilton, Stephen R CIV
> Sent: Wednesday, January 27, 2016 8:13 PM
> To: 'cg...@cgls.uscg.mil'
> Subject: FW: Official Press Release - GPS Ground System Anomaly
> 
> All CGSIC:
> 
> Air Force Official Press Release - GPS Ground System Anomaly
> 
>On 26 January at 12:49 a.m. MST, the 2nd Space Operations Squadron at the
> 50th Space Wing, Schriever Air Force Base, Colo., verified users were
> experiencing GPS timing issues.  Further investigation revealed an issue in
> the Global Positioning System ground software which only affected the time
> on legacy L-band signals. This change occurred when the oldest vehicle, SVN
> 23, was removed from the constellation. While the core navigation systems
> were working normally, the coordinated universal time timing signal was off
> by 13 microseconds which exceeded the design specifications. The issue was
> resolved at 6:10 a.m. MST, however global users may have experienced GPS
> timing issues for several hours.  U.S. Strategic Command's Commercial
> Integration Cell, operating out of the Joint Space Operations Center,
> effectively served as the portal to determine the scope of commercial user
> impacts.  Additionally, the Joint Space Operations Center at Vandenberg AFB
> has not received any reports of issues with GPS-aided munitions, and has
> determined that the timing error is not attributable to any type of outside
> interference such as jamming or spoofing.  Operator procedures were modified
> to preclude a repeat of this issue until the ground system software is
> corrected, and the 50th Space Wing will conduct an Operational Review Board
> to review procedures and impacts on users. Commercial and Civil users who
> experienced impacts can contact the U.S. Coast Guard Navigation Center at
> (703) 313-5900.
> V/R
> Rick Hamilton
> CGSIC Executive Secretariat
> GPS Information Analysis Team Lead
> U.S. Coast Guard Navigation Center
> 703-313-5930

Martin

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

Re: [time-nuts] GPS jumps of -13.7 us?

[Martin Burnicki]

Magnus Danielson wrote:
> Hi,
> 
> On 01/26/2016 11:46 PM, Martin Burnicki wrote:
>> Paul Boven wrote:
>>> Hi everyone,
>>>
>>> Has anyone else seen GPS time jump by -13.7 usec today?
>>> I just heard from several geographically quite distributed radio
>>> observatories that they have seen their GPS receiver(s) jump compared to
>>> their in-house standards.
>>
>> We were able to track this down today at Meinberg.
>>
>> The problem was that some satellites were sending invalid UTC correction
>> parameters. The UTC correction parameter set not only contains current
>> leap second information but also coefficients (A0, A1, WNt, tot) for a
>> polynomial used to compensate the fractional difference between GPS time
>> and UTC(USNO).
>>
>> Normally A0 (the constant offset) is very small, close to 0. WNt and tot
>> give the week number (truncated to 8 bits) and second-of-week for which
>> A0 is valid, i.e. the reference time for the time correction parameters.
>> WNt is currently about 89.
>>
>> Today the faulty satellites sent about 13.7 microseconds for A0, and WNt
>> as well as tot were both 0. So when the GPS receiver updated its UTC
>> correction parameters from a faulty satellite the UTC correction jumped
>> from close to 0 to about 13.7 microseconds, which let the UTC time step,
>> and when the GPS receiver received the UTC parameter set from a healthy
>> satellite the UTC time stepped back.
>>
>> We have recorded a few of the faulty subframe words. If someone is
>> interested I can provide more detailed information. However, I'm
>> currently out of the office and don't have the information here right
>> now.
> 
> You know I want more details. ;-)
> 
> I did see the report you guys sent to the USCG, good work there and good
> report.

Thanks.

After we had received the first reports about GPS receiver showing a 13
us time offset one of my colleagues who maintains the firmware of our
GPS receivers started to investigate. Looking at the data sets decoded
from the satellites he saw that temporarily the UTC correction parameter
jumped from one or 2 nanoseconds to more than 13 microseconds.

So he added some debug code which let the GPS receiver sent the
satellite number plus the raw subframe words 7 and 8 as hex numbers to a
monitor program which logged them to a file.

Then we looked at the raw data, decoded the bits manually and found that
some satellites were suspicious UTC correction data with a valid checksum.

Here are some subframe words 7 and 8 captured starting around 2016-01-26
12:00 UTC from subframe 4 page 18, and the decoded parameters
according to Figure 20-1, sheet 8 of IS-GPS-200H (printed page 83, PDF
page 96)
http://www.gps.gov/technical/icwg/IS-GPS-200H.pdf

svsfw7   sfw8wnt|tot  a0 bitsa0[us]
09 0x31B3 0x23800017 --> 00|00: 0xC68E  -13.696 *
07 0x3FEA 0x3FD3967B --> 89|319488: 0x   -0.001
02 0x3FD5 0x3FD39644 --> 89|319488: 0x   -0.001
06 0x318C 0x23800028 --> 00|00: 0xC68E  -13.696 *
23 0x318C 0x23800028 --> 00|00: 0xC68E  -13.696 *
30 0x 0x00139664 --> 89|319488: 0x   +0.000
05 0x003F 0x0013965B --> 89|319488: 0x   +0.000
16 0x 0x00139664 --> 89|319488: 0x   +0.000
26 0x318C 0x23800028 --> 00|00: 0xC68E  -13.696 *
07 0x3FEA 0x3FD3967B --> 89|319488: 0x   -0.001
09 0x31B3 0x23800017 --> 00|00: 0xC68E  -13.696 *
02 0x3FD5 0x3FD39644 --> 89|319488: 0x   -0.001
30 0x 0x00139664 --> 89|319488: 0x   +0.000
05 0x003F 0x0013965B --> 89|319488: 0x   +0.000
06 0x003F 0x0098D67D --> 89|405504: 0x0002   +0.002
23 0x318C 0x23800028 --> 00|00: 0xC68E  -13.696 *
16 0x 0x00139664 --> 89|319488: 0x   +0.000
07 0x3FEA 0x3FD3967B --> 89|319488: 0x   -0.001
09 0x 0x0098D642 --> 89|405504: 0x0002   +0.002
30 0x 0x00139664 --> 89|319488: 0x   +0.000
02 0x3FD5 0x3FD39644 --> 89|319488: 0x   -0.001
05 0x003F 0x0013965B --> 89|319488: 0x   +0.000
23 0x318C 0x23800028 --> 00|00: 0xC68E  -13.696 *
06 0x003F 0x0098D67D --> 89|405504: 0x0002   +0.002
16 0x 0x00139664 --> 89|319488: 0x   +0.000
07 0x3FEA 0x3FD3967B --> 89|319488: 0x   -0.001
09 0x003F 0x0098D67D --> 89|405504: 0x0002   +0.002
30 0x 0x00139664 --> 89|319488: 0x   +0.000
05 0x003F 0x0013965B --> 89|319488: 0x   +0.000
02 0x003F 0x0098D67D --> 89|405504: 0x0002   +0.002
06 0x003F 0x0098D67D --> 89|405504: 0x0002   +0.002

Re: [time-nuts] GPS jumps of -13.7 us?

[Martin Burnicki]

Paul Boven wrote:
> Hi everyone,
> 
> Has anyone else seen GPS time jump by -13.7 usec today?
> I just heard from several geographically quite distributed radio
> observatories that they have seen their GPS receiver(s) jump compared to
> their in-house standards.

We were able to track this down today at Meinberg.

The problem was that some satellites were sending invalid UTC correction
parameters. The UTC correction parameter set not only contains current
leap second information but also coefficients (A0, A1, WNt, tot) for a
polynomial used to compensate the fractional difference between GPS time
and UTC(USNO).

Normally A0 (the constant offset) is very small, close to 0. WNt and tot
give the week number (truncated to 8 bits) and second-of-week for which
A0 is valid, i.e. the reference time for the time correction parameters.
WNt is currently about 89.

Today the faulty satellites sent about 13.7 microseconds for A0, and WNt
as well as tot were both 0. So when the GPS receiver updated its UTC
correction parameters from a faulty satellite the UTC correction jumped
from close to 0 to about 13.7 microseconds, which let the UTC time step,
and when the GPS receiver received the UTC parameter set from a healthy
satellite the UTC time stepped back.

We have recorded a few of the faulty subframe words. If someone is
interested I can provide more detailed information. However, I'm
currently out of the office and don't have the information here right now.

Martin

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

Re: [time-nuts] Rohde & Schwarz GPSDO

[Martin Burnicki]

Magnus Danielson wrote:
> Hi,
> 
> On 10/09/2015 09:35 PM, Rami Vainio wrote:
>> On 7.10.2015 14:45, Arthur Dent wrote:
>>> I believe that like a lot of the Meinberg receivers that
>>> this uses a down converter to give an IF frequency of
>>> 35.4 MHz. If you don't have the converter that apparently
>>> isn't included with the receiver you have a $300 paperweight.
>>> You might want to check with the seller before bidding.
>>
>> Hi, here is quick and dirty way to make your own LNC to Meinberg 166 (I
>> got it with no antenna and broken 10MHz oscillator):
>> https://www.dropbox.com/sh/n4lob51pzs236wb/AABy7DVGxX4EIaazizGaAx5Na?dl=0
> 
> A friend has one of those boxes, as I gave it to him.
> One of the Meinberg brothers did the actual DSP code in it.
> 
> I know of very few vendors (Meinberg and Trimble) of GPSDOs that does
> both the GPS and DO parts, and if you take on the effort to do the GPS
> side, then you get a better system understanding. Most GPSDOs builds on
> OEM modules.
> 
> As I recall, this is a one-channel receiver with analogue Early, Prompt
> and Late correlator integrators, where the Altera produces the chips and
> the DSP does all the nav-stuff.
> 
> Martin might remember more (or just ask).

Yes, the GPS166 was the first GPS receiver developed by Meinberg at the
beginning of the 1990s. It was just a single channel receiver where GPS
reception (correlators etc.) was done by a DSP, and decoding and
evaluation was done by a Siemens 80C166 microcontroller which was a
brandnew, sophisticated 16 bit CPU with a lot of useful peripherals
(counter/timer/compare/capture registers, GPIO) built-in.

Since the design was targeting stationary installations for time
synchronization, the GPS166 was already designed with a down converter
built into the antenna, so you could use very long standard coaxial
cable like RG58 between the antenna and the receiver. For stationary
installations it also didn't matter that the device could only track a
single satellite.

The satellite signals were used to discipline an on-board oscillator
(TCXO or OCXO), and that oscillator was used to drive a counter chain
using one of the 80C166's timers to implement the on-board time.

All output signals were derived from that counter chain, and the
counter/compare units provided by the CPU were used to generate an exact
1 PPS output signal, etc., directly coupled to the on-board time.

The resulting accuracy was better than 1 microsecond, and this was much
better than the accuracy you could achieve with usual radio clocks at
that time.

The subsequent GPS receiver models by Meinberg (GPS167 etc.) used some
special correlator chip which then became available, but the correlators
were fully controlled by our own firmware. Those devices could track up
to 6 satellites in parallel. This was limited by the CPU power of the
80C167 processor used for those devices which still had to do the
decoding of satellite data.

Current GPS receiver models run an ARM processor with correlators
implemented in an FPGA, so thes devices are much more powerful.

Unfortunately the design of the original GPS166 converter/antenna was
not applicable to multichannel receivers like the GPS167 and later
series, so the converter had to be modified.

This is the reason why you can't use a GPS166 antenna with GPS167 and
newer receivers and vice versa, however the GPS167 antenna is still
compatible with the antennae shipped with newer GPS receiver models.

Martin

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

Re: [time-nuts] Rohde & Schwarz GPSDO

[Martin Burnicki]

Björn wrote:
> You might get some oscillator information by looking at the Meinberg site.
> 
> https://www.meinbergglobal.com/english/specs/gpsopt.htm
> 
> Is this a badged Meinberg unit or a R&S built on the Meinberg GPScard?

This device has been manufactured by Meinberg, for R&S.

Martin

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

Re: [time-nuts] Rohde & Schwarz GPSDO

[Martin Burnicki]

Bob Camp wrote:
> Hi
> 
> One thing you can expect - some sort of issue with the GPS rollover issue. 
> Can it be fixed on this or that unit? That’s going to be highly variable 
> model to
> model. Not much of an issue for a frequency standard, but a pain for NTP.

No need to worry, there is no problem with GPS rollovers.

The built in GPS receiver has been developed by Meinberg, and I wrote
parts of the firmware which evaluates the satellite data.

Handling of the week number in these receivers is *not* by simply adding
another 1024 weeks if the truncated wn is below a certain limit.

Instead, the wn is extended to 16 bit internally and simply incremented
on each 10 bit rollover into the next epoch.

If the device's backup battery fails and thus the epoch number is lost
you can simply set the internal date to the current date, so the
extended week number is computed and the device outputs the correct date
and time.

Martin

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

Re: [time-nuts] Serial Ballpoint issue again

[Martin Burnicki]

David C. Partridge wrote:
> I just installed Windows 10 (yes I know how rash), and now my Thunderbolt is
> being detected as a Microsoft Serial Ballpoint Mouse (yes, just like before
> inder Windows 7).  I had set something up on Windows 7 in the boot.ini to
> stop this, but for the life on me I can't remember what it was.
> 
> Please could someone who's got this setup on Windows 7 remind me what the
> magic incantionation is.

The boot option /NoSerialMice should do the trick. See:
https://support.microsoft.com/en-en/kb/131976

However, unklike mentioned in the above article, you can't just edit a
boot.ini file in current Windows versions. Instead you have to run the
bcdedit utility shipped with Windows. See:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff545492%28v=vs.85%29.aspx

Haven't tried this under Windows 10, yet, but hope it still works.

Martin

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

[time-nuts] NTP 4.2.8p3 installer for Windows available

[Martin Burnicki]

Hello everybody,

just wanted to let you know that the NTP installer for Windows provided 
by Meinberg has been updated:

https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable

This installer provides the current NTP 4.2.8p3 stable version as well 
as openSSL DLL 1.0.1p, which has been released yesterday.


If you have already installed NTP for Windows you can select the 
"Upgrade files only" option during installation so everything else is 
left unchanged.


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

Re: [time-nuts] End Of The World

[Martin Burnicki]

Frister wrote:

My NTP server did a double 59 on the terminal. for anybody who is interested
I captured the event :
https://youtu.be/OpNci29CI7E


I think you need to be careful if you just watch the time in a loop with 
a "sleep 1". Due to slightly varying sleep intervals the time when the 
"date" command is called may interfere with the second boundary of the 
system time, so you may observe missing or duplicate times anyway.


Eventually the following command shows less ambiguous results:

while true; do date -u +'%F %T.%N'; sleep 0.25; done

E.g.:

2015-07-02 09:46:01.236101917
2015-07-02 09:46:01.490039978
2015-07-02 09:46:01.743952328
2015-07-02 09:46:01.997539363
2015-07-02 09:46:02.251356539
2015-07-02 09:46:02.505238060
2015-07-02 09:46:02.759204117
2015-07-02 09:46:03.013218510
2015-07-02 09:46:03.267194076
2015-07-02 09:46:03.521256275
2015-07-02 09:46:03.775118487
2015-07-02 09:46:04.029012022
2015-07-02 09:46:04.283006237
2015-07-02 09:46:04.537024946
2015-07-02 09:46:04.790874099

Usually you get 4 timestamps per second, but eventually there may be 
only 3 or so, depending on the accuracy of the sleep intervals. In any 
case you have the fractions of the second to *see* that there is 
eventually a second :03.9 where you expected :04.0, or 
vice versa.


Martin

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

Re: [time-nuts] End Of The World

[Martin Burnicki]

Bob Camp wrote:

Well it sounds like there are (so far) no major reports of extreme behavior. 
There still seem to be
*lots* of reports of systems that do not handle things gracefully. I wonder if 
the data above is
specific to a chip set (which it probably is) or to how Glonass  handles leap 
seconds (yikes !!!).


As said in my previous email, it was a NVD8C-CSM v3.1 module 
specifically set to GLONASS-only mode.


I'm assuming the problem is specific to GLONASS.

The GPS satellites sends their data frames in 6 second intervals aligned 
with GPS time which is linear, with constant offset to TAI, so the data 
frames are not affected by a leap second.


It's been quite a while that I looked at some GLONASS specs, but if I 
remember correctly the data frames sent by GLONASS satellites are 
aligned with UTC. So if a leap second is inserted or deleted there *is* 
some interruption in the sequence of the data frames.


So it's much more difficult for receivers to keep tracking GLONASS 
satellites than GPS satellites over a leap second, and I'm not 
specifically surprised that GLONASS receiver at least loose sync when a 
leap second occurs.


Martin

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

Re: [time-nuts] End Of The World

[Martin Burnicki]

Bob Camp schrieb:

Hi

So are we all still here? Any portion of the group blasted into non-existance 
by the leap second please speak up :)

===

Any observations of anomalous behavior yet?


From a NVD8C-CSM v3.1 module in Glonass-only mode:

$GPZDA,235958.00,30,06,2015,00,00*65
$GPGGA,235959.00,5158.9396,N,00913.5513,E,1,10,00.7,119.5,M,47.2,M,,*53
$GPRMC,235959.00,A,5158.9396,N,00913.5513,E,00.00,144.5,300615,,,A*5F
$GPGSV,1,1,04,33,26,210,00,37,29,164,00,39,29,160,00,40,17,127,00*76
$GLGSV,3,1,10,68,36,066,46,69,74,335,41,70,26,270,49,77,17,018,35*61
$GLGSV,3,2,10,78,34,075,43,79,18,125,40,83,06,190,38,84,43,230,42*6F
$GLGSV,3,3,10,85,42,304,45,86,07,344,38*68
$GLGSA,A,3,68,69,79,83,85,84,77,78,70,86,,,01.4,00.7,01.2*1C
$PORZD,A,002.7*39
$GPZDA,235959.00,30,06,2015,00,00*64
$GPGGA,00.00,5158.9396,N,00913.5513,E,1,10,00.7,119.5,M,47.2,M,,*52
$GPRMC,00.00,A,5158.9396,N,00913.5513,E,00.00,144.5,010715,,,A*5D
$GPGSV,1,1,04,33,26,210,00,37,29,164,00,39,29,160,00,40,17,127,00*76
$GLGSV,3,1,10,68,36,066,46,69,74,335,40,70,26,270,49,77,17,018,36*63
$GLGSV,3,2,10,78,34,075,43,79,18,125,41,83,06,190,39,84,43,230,42*6F
$GLGSV,3,3,10,85,42,304,46,86,07,344,37*64
$GLGSA,A,3,68,69,79,83,85,84,77,78,70,86,,,01.4,00.7,01.2*1C
$PORZD,A,002.7*39
$GLGBS,00.00,2.0,1.8,5.2*51
$GPZDA,00.00,01,07,2015,00,00*66
$GPGGA,01.00,5158.9396,N,00913.5513,E,1,10,00.7,119.5,M,47.2,M,,*53
$GPRMC,01.00,A,5158.9396,N,00913.5513,E,00.00,144.5,010715,,,A*5C
$GPGSV,1,1,04,33,26,210,00,37,29,164,00,39,29,160,00,40,17,127,00*76
$GLGSV,3,1,10,68,36,066,44,69,74,335,39,70,26,270,47,77,17,018,34*63
$GLGSV,3,2,10,78,34,075,42,79,18,125,39,83,06,190,37,84,43,230,41*6C
$GLGSV,3,3,10,85,42,304,44,86,07,344,36*67
$GLGSA,A,3,68,69,79,83,85,84,77,78,70,86,,,01.4,00.7,01.2*1C
$PORZD,A,002.7*39
$GPZDA,01.00,01,07,2015,00,00*67
RestartK<ÕÎ$GPGGA,00.00,.,N,0.,E,0,,,-18.0,M,18.0,M,,*5E
$GPRMC,00.00,V,.,N,0.,E,00.00,000.0N*46
$GPGSV,1,1,00*79
$GLGSV,1,1,00*65
$GPGSA,A,1,,,*1E
$PORZD,V,999.9*2B
$GPGBS,00.00,,,*6F
$ALVER,NVS,CSM23,0207*72
$POTST,ID,0268501855,ANT,1,RFG,0,RFR,0*3E
$GPGGA,01.00,.,N,0.,E,0,,,-18.0,M,18.0,M,,*5F
$GPRMC,01.00,V,.,N,0.,E,00.00,000.0N*47
$GPGSV,1,1,00*79
$GLGSV,1,1,00*65
$GPGSA,A,1,,,*1E
$PORZD,V,999.9*2B
$GPZDA,01.0000,00*67
$GPGGA,02.00,.,N,0.,E,0,,,-18.0,M,18.0,M,,*5C
$GPRMC,02.00,V,.,N,0.,E,00.00,000.0N*44

The module restarted itself when the leap second occurred.

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

Re: [time-nuts] Tour of METAS (Swiss Federal Institute of Metrology) time lab: any questions or requests?

[Martin Burnicki]

Poul-Henning Kamp wrote:

Ask them how/why the HBG transmitter screwed up the 2006 leapsecond ?


If I remember correctly then the transmitter would have needed to be 
overhauled, which would have been very expensive.


Since the German DCF77 transmitter can also be received in Switzerland 
and DCF77 receivers were much more common than HBG receivers the 
decision was taken to finish HBG transmission.


Martin

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

Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix

[Martin Burnicki]

Brian Inglis wrote:

The next rollover is about April 2019, but this can happen any time
an older receiver's internal date representation used for GPS to UTC
conversion overflows. Looks like Tymserve 2100 picked about Sep 1995
for its date epoch so it hits now.

Newer GPS receivers support the extra 3 bits added to GPS extended
week allowing 8192 weeks (157 years) between rollovers - 2137 is the
next big rollover problem, but NavStar will likely not be sending the
same data on the same frequency then.


There are also GPS receivers out there which use (and have been using) 
an extended week number internally instead of hardcoded limit for the 10 
bit week number.


As long as there's a backup battery is OK then there's nothing to do for 
the user to get the correct epoch. If the backup battery is disconnected 
or fails then you can just send the current date to the device, and the 
firmware computes the extended week number, including the epoch of the 
GPS week number.


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

Re: [time-nuts] June 30 2015 leap second

[Martin Burnicki]

d0ct0r wrote:

Today, I did the check the settings for my BC637 card. I was surprised
that its overwrite my manual setting for the Leap Event by following
information:

Time Settings:

  Mode   : GPS
  Time Format: Binary
  Year   : 1995
  Local Offset   : 0.0
  Propagation Delay  : 0
  Current Leap Seconds   : 16
  Scheduled Leap Event Time  : 876614400
  Scheduled Leap Event Flag  : Insertion
  GPS Time Format: UTC Format
  IEEE Daylight Savings Flag : Enable



Why are you wondering? This should be the expected result if your card 
receives and decodes the data from the GPS satellites.



"Sun, 12 Oct 1997 00:00:00 GMT". Its weird. I am going to re-insert it
and will check it again later.

New Time Settings are:

  Mode   : GPS
  Time Format: Binary
  Year   : 2015
  Local Offset   : 0.0
  Propagation Delay  : 0
  Current Leap Seconds   : 16
  Scheduled Leap Event Time  : 1435708799
  Scheduled Leap Event Flag  : Insertion
  GPS Time Format: UTC Format
  IEEE Daylight Savings Flag : Enable


I'd expect these will be overwritten again during GPS reception.

However, as far as I can see the UTC parameters currently sent by the 
satellites still haven't been updated to reflect the upcoming leap 
second, so the date derived from the old week number in this parameter 
set is ambiguous. Also the event flag (insertion vs. deletion) can't be 
determined from the curent parameters. I'd expect that this is just an 
interpreting problem in the user interface.



Also, my NTP, which rely on that card,  didn't get the value for leap
second event yet:

# ntpq -c rv

associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer,
version="ntpd 4.2.6p5@1.2349 Mon Sep 22 20:41:39 UTC 2014 (14)",
processor="x86_64", system="Linux/3.2.0-74-generic", leap=00, stratum=1,
precision=-23, rootdelay=0.000, rootdisp=8248.907, refid=BTFP,
reftime=d85e7526.957a1b17  Mon, Jan 12 2015 11:30:30.583,
clock=d85ec544.e1effe31  Mon, Jan 12 2015 17:12:20.882, peer=0, tc=4,
mintc=3, offset=3.757, frequency=-243.698, sys_jitter=0.000,
clk_jitter=1.328, clk_wander=15.616


What would you expect to see? Ntpd accepts and forwards leap second 
announcements only one day before the leap second event.


If ntpd would accept a leap second warning right now and set the "leap" 
variable accordingly then all its NTP clients would try to insert a leap 
second at the end of January. I don't think this is what you want.


By the way, are you sure the driver /127.127.x.0) you are using to let 
ntpd get the time from your PCI card supports passing on the leap second 
warning to ntpd?


Martin

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

Re: [time-nuts] June 30 2015 leap second

[Martin Burnicki]

Tom Van Baak wrote:

I haven't looked at the raw data, but using the windows apps:
a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not.
lady heather is not


Interesting.  I don't see any leap-pending from a Z3801A.  (or a KS-24361)


Hi Hal,

It's not that simple. There are many different levels of leap second 
notification.

1) IERS updates their ftp site (for bots) and sends email (for humans) 
indicating when the next leap second will occur. Days or weeks (and sometimes 
months) later,

2) GPS ground control uploads almanac information to the satellites with 
updated UTC parameters. Four values in page 18 of subframe 4 give the current 
UTC leap second delta and also an optional future UTC delta, with a GPS week 
(LS_f) and day number (DN) when that future delta will be current. By 
definition the leap second will occur at the end of a UTC (not GPS) day.

In this way GPS can provide up to 256 weeks (~4.9 years) of advanced
leap second information and support positive or negative leap
seconds.


Yes, and since the GPS UTC parameters just provide the difference to GPS 
time (in seconds) before and after the leap event time, they could even 
announce a leap event where more than 1 second is inserted or deleted at 
once. ;-)


I'm not aware of any other timing system that could handle this, though.


Note there is no "leap second warning" *bit* in the GPS
spec, per se.

3) Starting up to 12.5 minutes later, GPS receivers will see page 18 of 
subframe 4 from some or all SV and thus know not only the current UTC offset, 
bit when/if a different UTC offset will be valid in the distant future. Prior 
to this (e.g., cold start) there is no certainty of either the UTC offset or 
leap second state.

4a) Since UTC and leap seconds are not needed for navigation, some GPS 
receivers do not bother to tell the user about leap seconds at all.

4b) Some GPS receivers only give the user a leap second warning and so they 
must wait until the month in which the leap second is to be applied before they 
issue the warning. That means they may sit on the internal leap second 
information for many months.

4c) Other GPS receivers give the future date of the next leap second (if any). 
This is not a warning bit, but just the date/time of the next leap second.

4d) Especially dangerous are any GPS receivers that report only a leap second 
warning bit, but don't tell you which month it will occur.

5) Host software (e.g., GPSDO firmware, operating system, drivers, or apps) 
take this information and must only operate on it at the end of the appropriate 
UTC month. Hardcoded rules for June and December are frowned upon.

It would be nice if we pooled together our resources and made a list of which 
GPS/GNSS receivers are 4a, 4b, 4c, or 4d.


It also depends on *how* the leap second warning is made available. If 
an application can read the GPS UTC parameter set then it can compute it 
as soon as the sats start to broadcast it.


There are formats of time string output by GPS receivers which only 
include the leap second warning 1 hour or 1 day before the event.


NMEA sentences don't include it at all, AFAIK. Binary messages may, 
depending on the manufacturer.


IRIG time code signals also don't provide a leap second *warning* flag, 
except the IEEE codes 1344 and C37.118, which only output this 10 
seconds or 1 minute (don't remember exactly without looking) before the 
event.


Martin

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

Re: [time-nuts] June 30 2015 leap second

[Martin Burnicki]

Tom Van Baak wrote:

Keep in mind that this system drives you to having pretty bad time for the
better part of a whole day, on purpose... I realize that when the


Hi Didier,

The google article never claims the smear spans an entire day. I
think you may be confusing references to the leap smear with a DIY
digital clock someone on the list wanted to build (and they proposed
using a slow 86400 second slew).

The google code is "lie(t) = (1.0 - cos(pi * t / w)) / 2.0" and they
are wise not to publish the actual window value, w. If it were me I'd
make it somewhere between a couple of seconds or couple of minutes
but I too would not make it a published or hardcoded constant.


Hm, the article says, "It also made sure the updates were sufficiently 
small so that any software running on the servers that were doing 
synchronization actions or had Chubby locks wouldn't lose those locks or 
abandon any operations."


So I think they smeared it over more than just a few minutes. I'd expect 
some hours, so standard NTP clients would just notify this as clock 
drift (oscillator frequency offset) which they'd have to compensate. 
Since ntpd's control loop is pretty slow it wouldn't respond quickly to 
smears over a few seconds our hours.



Here's the link again:
http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

Again, I don't know what value they use, or even if they use the same
value from one leap second to the next. If any of you have inside
contacts with google and can find out let me know, off-list.

>

Regardless, it should be possible to experimentally determine the
smear duration by repeatedly using some google service that returns
time-stamps during the day, hours, minutes, or seconds before and
after June 30. It would make a nice posting for a time nut, or a
research paper for a high school student or undergrad: Experimental
Confirmation of Google's Leap Smear Algorithm.


Yes, interesting idea!

Martin

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

Re: [time-nuts] June 30 2015 leap second

[Martin Burnicki]

Gregory Maxwell wrote:

On Fri, Jan 9, 2015 at 3:21 PM, Martin Burnicki
 wrote:

Systems which are simply time clients can receive the leap second warning
via the usual protocols like NTP or PTP/IEEE1588.


Indeed, they can. Even when there hasn't been a leap-second.
Practically all internet (and otherwise?) time distribution is
unauthenticated, the leap second itself is unauthenticated.


... and even the time you get via NTP or PTP is usually not 
authenticated. So you can trust the time and leap second warning, or you 
shouldn't trust either.



It's fragile enough that there have been accidental false leap-second events.


Yes, for example if there have been GPS receivers which decoded the UTC 
parameters incorrectly, and started to announce a leap second when there 
wasn't one (end of September).


That's why, for example, ntpd's leap second handling code has been 
changed in v4.2.6 to accept a leap second warning only if the warning is 
received from a majority of the configured servers.


If you want to be sure you can also provide ntpd with a leap second file 
which is then (in current versions) considered as authentic source for 
leap second information.


Martin

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

Re: [time-nuts] June 30 2015 leap second

[Martin Burnicki]

d0ct0r wrote:


Reading about "leap seconds" for the past two days, I found that common
solution for it - just encode "leap second event" proactively and wait
for it.
Of course that possible only if device has that option. For example,
BC637PCI has a menu item "7. Program Leap Event Seconds". Which I did.

Now, if I do the request for time settings, its shows me following:

Time Settings:

  Mode   : GPS
  Time Format: Binary
  Year   : 2015
  Local Offset   : 0.0
  Propagation Delay  : 0
  Current Leap Seconds   : 16
  Scheduled Leap Event Time  : 1435708799
  Scheduled Leap Event Flag  : Insertion
  GPS Time Format: UTC Format
  IEEE Daylight Savings Flag : Enable


"Scheduled Leap Event Time" - is so-called UNIX time. However, I am not
sure where its take number "16" (Current Leap Seconds). Its definitely
was not programmed there by me.


16 s is the current difference between GPS system time and UTC, which 
will increase to 17 after the next leap second. It is part of the UTC 
data set broadcasted by the satellites.


I'd expect that in a few days the GPS satellites start broadcasting the 
leap second announcement, and then yourGPS receiver should also find out 
by itself *when* the leap second will occur, and what the UTC offset 
will be thereafter.


When I looked this morning the sats did't broadcast this information, yet.


Concerning of my clock project, I am thinking about best approach how to
set up leap second procedure. I mean which time exactly I'll need to do
correction for my clock (set time on RTC module). There is two options,
I think. One: to reset RTC at July 1, 00:00:00 and set it back to June
30, 23:59:00. Or, at July 1, 00:00:01, set RTC back to July 1 00:00:00
and then at July 1 00:00:01 reset RTC with occurrance of raising edge of
1PPS. I would prefer to play with July 1, because in this case I don't
need to do much calculations to transfer RTC time to number of seconds,
decrement it by 1 second, transfer it back to BCD format and write it
back to RTC. Instead, I'll need just read/write RTC register which keeps
number of seconds inside.


As said, once the sats start broadcasting this information your software 
should be able to read the time and leap second status from the PCI 
card, if the API supports this.


How you can handle this to set your clock depends on the capabilites of 
your clock, and its API.


Martin

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

Re: [time-nuts] June 30 2015 leap second

[Martin Burnicki]

Tom Van Baak wrote:

I couldn't help noticing that Debian just issued an update
to tzone, so that means Linux systems now know about the
leap second.

-Chuck Harris



Hi Chuck,

"Linux systems now know about the leap second" -- this is a very
dangerous assumption. And one reason why leap seconds have gotten out
of hand the past decade.

Just because you observe one tz update from Debian does not imply
that all "Linux systems" on planet earth (or in space) magically know
about leap seconds. There must be millions (billions?) of embedded or
isolated systems -- from web servers to desktops to military systems
to gadgets to Raspberry Pi's to mobile phones, that have not, and
will not ever receive this update.


And that's where the new tzdist protocol comes into the game, which can 
be used to supply leap second information to time *servers* which need 
to send leap second warnings to their clients.


Systems which are simply time clients can receive the leap second 
warning via the usual protocols like NTP or PTP/IEEE1588. Of cours it 
must be sure that the information is also *evaluated* by the client 
software.


Martin

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

[time-nuts] GUI installer with ntp-4.2.8 for Windows now available

[Martin Burnicki]

Folks,

a new GUI installer with ntp-4.2.8 for Windows is now available at 
Meinberg's NTP download page:

http://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable

This also includes the current version v1.0.1j of the openSSL DLL, which 
also fixes some openSSL vulnerabilities.


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

Re: [time-nuts] DCF77/PZF correlation after outage

[Martin Burnicki]

Ben,

Ben Stienstra wrote:

Thanks for your reply. The correlation coefficient is almost back at
the normal level. I will search some old logs to see if previous
outages also shows the same behaviour. It could be perfectly normal.


Martin, I have combined all the data i have from the previous firmware
version (v5) and the current (v6). At other outages the correlation
coefficient did come up to >95% almost as fast as the field strength
(not days). The last reboot log shows 10 minutes until 'NTP sync to PZF'.

>

DCF Outage 2014-01-25:
http://imgur.com/xinzUGL

DCF Outage 2013-06-20:
http://imgur.com/QMYEOkR

In the image below you'll find the field strength and correlation over
the past 10 months. Field strength in the summer was higher than in the
winter. The low corr. at the beginning of the graph was when the antenna
was not yet outside and aligned.
http://imgur.com/sZnfSxz


I'd also expect that the correlation comes back quickly after an outage.

Although I've been involved in the development of the first DCF77 
correlation receivers many years ago the firmware of these receivers is 
actually maintained by other guys, one of which is still on Easter holidays.


I've forwarded your observations to the firmware maintainers, so they 
can try to find out what happened. However, this may take some days.




I'll continue monitoring and when the next outage occurs, let's see what
happens. I'll contact support instead of the time-nuts list :)


Great. Usually Meinberg support is pretty responsive.

Take care, I'm biased. ;-)

Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

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

Re: [time-nuts] DCF77/PZF correlation after outage

[Martin Burnicki]

Ben,

sorry for the late reply due to the Easter holidays.

Ben wrote:

Hi Group,

At the 14th of april 2014 between 17:00 and 18:00 hours UTC there was a
DCF77 outage.

I have a NTP server with DCF77/PZF receiver (lantime m200) which i
monitor. I noticed that the PZF correlation is slowly comming back to
nomal (>90%) level, instead of after a few minutes just like the field
strength level. Below are links to my graph and the Kiel VLF monitor graph.

Field strength and PZF Correlation graph:
http://imgur.com/gdosBhs


Hm, the description embedded in the graph says the *yellow* line shows 
the *correlation* which is immediately coming back after the outage, as 
expected.


The blue line sould be the "field strength", which is indeed increasing 
very slowly. I'm not sure how you have extracted the field strength from 
the M200, but this is probably only some AGC control value which just 
needs to be sufficient to yield proper correlation. There is no 
parameter available in the LANTIME which reports the true DCF77 field 
strength.



Kiel VLF monitor graph:
http://imgur.com/DC9yDrQ


Several devices running here at the factory (Meinberg) have also 
observed the short outage.


Please keep in mind that unlike the British MSF the German DCF77 
transmitter usually has no scheduled outages, and as far as I know is 
only put out of operation for a short time if there is a really heavy 
thunderstorm.



I hope someone has an explanation or suggestion I can learn from :)


Best regards,

Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

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

Re: [time-nuts] NTP and Windows 7

[Martin Burnicki]

Hal,

Hal Murray wrote:


martin.burni...@burnicki.net said:

Please note under Windows you should configure all upstream servers with  a
line reading



server aa.bb.cc.dd iburst minpoll 6 maxpoll 6


There are lots of times when reducing maxpoll is reasonable, but I think an
unqualified suggestion is not appropriate.


I don't think my suggestion was unqualified. ;-)

We have already discussed this in the NTP newsgroup/questions mailing list.

Here is a loopstats graph from a Windows XP system running ntpd 4.2.6p5 
without limitation of maxpoll:


http://people.ntp.org/burnicki/windows/ntpd-4.2.6p5-WinXP-no_poll_limit.pdf

And if you limit maxpoll to 6 in the same installation the results look 
like this:

http://people.ntp.org/burnicki/windows/ntpd-4.2.6p5-WinXP-poll_6.pdf


A loopstats graph from another test with ntp-dev running on Windows 7 
without limitation of the polling interval are here:

http://people.ntp.org/burnicki/windows/ntpd-4.2.7-Win7-poll4-max.pdf

And similarly, with limitation of the polling interval to 6:
http://people.ntp.org/burnicki/windows/ntpd-4.2.7-Win7-poll4-6.pdf

In the examples above I had minpoll set to 4, just to see how the fix 
for NTP bug 2328 behaves, and you can clearly see that time 
synchronization is degraded if the polling interval is *below* 6 since 
the workaround doesn't work properly, as mentioned in the bug report.


So I wouldn't suggest anyway to set minpoll below 6.


maxpoll of 6 polls every 64 seconds.  The default maxpoll is 10, or 1024
seconds, so that's a 16x[1] increased load on the servers.  Some/many people
would consider that to be abusive use of a resource.

If you are using your servers, you can do whatever you want.  If you are
using your ISP's servers or a friends, then whatever they agree to is fine.
The NIST servers are already heavily/over loaded.  I'm not sure if the pool
could stand a 16x increase in load.


I agree that limiting maxpoll isn't the best choice if you can avoid it.

However, by default ntpd starts at minpoll 6 anyway, it determines 
automatically if the polling interval can be increased towards 10, or be 
decreased again towards 6.


You can see how the interval is decreased automatically in the loopstats 
for 4.2.6/Win XP, if the time discipline becomes too bad.


So public services should anyway account for clients sticking a the 
default lowest poll interval, namely 6.


And of course it is generally not a good idea to let each laptop get its 
time directly from the primary servers at NIST or PTB, but this is a 
different problem.


Martin

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

Re: [time-nuts] NTP and Windows 7

[Martin Burnicki]

John Nelson wrote:

Greetings from Wales. I'm not sure whether this august forum is the
appropriate place to ask a question about PC timekeeping, but in the hope
that someone can point me in the right direction I'll ask anyway ;-)

I have just replaced Windows XP with Windows 7. The PC involved (a fairly
elderly 2.4GHz Core2 machine) runs an application called 'PlanePlotter'
which requires accurate timekeeping and mandates Meinberg's NTP software.
Using the UK pool.ntp.org servers as a reference source this has worked very
well under XP for several years and the clock was seldom more than a few
milliseconds out. Under Windows 7, however, the clock can be anything up to
0.2s awry and the offset is very erratic. The daily loopstats graph looks
like a section through a mountain range.

I have carefully checked all settings and combed the internet for
suggestions but can see no reason for the sharply degraded performance. Is
there something about Windows 7 that degrades the performance of NTP? Or is
there anything subtle I can check?


The latest Windows bug which came to our attention is that some Windows 
versions don't apply small time adjustments at all. For example, if NTP 
applies an adjustment less than 16 ticks to the Windows time this is 
simply ignored by Windows. However, NTP expects the adjustment to have 
some effect, but if there is no effect then the next time comparison 
yields a much larger difference than expected, and thus causes another 
adjustment which is probably larger than necessary. As a summary this 
can cause large swings in the time adjustment values.


A developer version of the NTP package contains a workaround for this 
Windows bug. The report and fix are discussed here:


NTP Bug 2328 - Vista/Win7 time keeping inaccurate and erratic
https://bugs.ntp.org/show_bug.cgi?id=2328

The problem is also explained on the Microsoft support page:

SetSystemTimeAdjustment May Lose Adjustments Less than 16
http://support.microsoft.com/kb/2537623

Even though the MS report only mentions Windows 7, the Windows Server 
2008 kernel is similar to Windows 7 and has probably the same bug. So if 
you want to give it a try you can download a NTP developer version here 
which includes a workaround:

http://people.ntp.org/burnicki/windows/

(The latest ntp-dev version also contains this fix, so alternatively you 
can use that one, as siuggested by David Taylor)


You should try the release version first. Just unzip the ZIP archive, 
stop the NTP service, copy all extracted files over the files in your 
NTP installation directory (e.g. C:\Program Files (x86)\NTP\bin\), and 
restart the NTP service.



We have found that this version has greatly improved the resulting 
accuracy on Windows 7 and Windows Server 2008 installations.


Please note under Windows you should configure all upstream servers with 
a line reading


server aa.bb.cc.dd iburst minpoll 6 maxpoll 6

where aa.bb.cc.dd has to be replaced with the host name or IP address of 
your NTP server.


Generally you should use a polling interval as short as possible under 
windows to let let ntpd apply adjustments quickly.


However, please don't use polling intervals below 6 with the developer 
version since this prevents the workaround from working correctly as 
discussed in the bug report.


Also, higher polling intervals can cause problems under Windows. See:

NTP Bug 2341 - ntpd fails to keep up with clock drift at poll > 7
http://bugs.ntp.org/show_bug.cgi?id=2341

So our advice is to use "minpoll 6 maxpoll 6" as indicated in the 
example above.


The patched ntpd has caused no drawbacks on any Windows machines, but 
has improved accuracy on a number of installations.


The directory
http://people.ntp.org/burnicki/windows/
contains also some loopstats graphs as PDF files which show the improvement:
http://people.ntp.org/burnicki/windows/bug2328_workaround.pdf
http://people.ntp.org/burnicki/windows/bug2328_workaround_fine.pdf

Martin

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

Re: [time-nuts] Lady heather plus NTP server?

[Martin Burnicki]

Chuck Forsberg WA7KGX wrote:

I did a quick comparison between Lady Heather under Wine+Linux,
Lady Heather under Win7, and WWV.

The NTP time on my office machine agrees with WWV on 5 MHz
as closely as my eyes and ears can tell.  Linux is running its default
NTP, Win7 is running Meinberg (as I recall).


Windows is a lousy timekeeper, and the Windows port of the NTP software 
includes a number of workarounds for deficiencies in the Windows kernel.


If the offset reported by "ntpq -p" on the Windows machine is more than 
just a few milliseconds then the following hints may be helpful.



The latest Windows bug which came to our attention is that some Windows 
versions don't apply small time adjustments at all. For example, if NTP 
applies an adjustment less than 16 ticks to the Windows time this is 
simply ignored by Windows. However, NTP expects the adjustment to have 
some effect, but if there is no effect then the next time comparison 
yields a much larger difference than expected, and thus causes another 
adjustment which is probably larger than necessary. As a summary this 
can cause large swings in the time adjustment values.


Newer developer version of the NTP package contain a workaround for this 
Windows bug. The report and fix are discussed here:


NTP Bug 2328 - Vista/Win7 time keeping inaccurate and erratic
https://bugs.ntp.org/show_bug.cgi?id=2328

The problem is also explained on the Microsoft support page:

SetSystemTimeAdjustment May Lose Adjustments Less than 16
http://support.microsoft.com/kb/2537623

Even though the MS report only mentions Windows 7, the Windows Server 
2008 kernel is similar to Windows 7 and has probably the same bug. So if 
you want to give it a try you can download a NTP developer version here 
which includes a workaround:

http://support.ntp.org/people/burnicki/windows/

You should try the release version first. Just unzip the ZIP archive, 
stop the NTP service, copy all extracted files over the files in your 
NTP installation directory (e.g. C:\Program Files (x86)\NTP\bin\), and 
restart the NTP service.


We have found that this version has greatly improved the resulting 
accuracy on Windows 7 and Windows Server 2008 installations.


Please note under Windows you should configure all upstream servers with 
a line reading


server aa.bb.cc.dd iburst minpoll 6 maxpoll 6

where aa.bb.cc.dd has to be replaced with the host name or IP address of 
your NTP server.


Generally you should use a polling interval as short as possible under 
windows to let let ntpd apply adjustments quickly.


However, please don't use polling intervals below 6 with the developer 
version since this prevents the workaround from working correctly as 
discussed in the bug report.


Also, higher polling intervals can cause problems under Windows. See:

NTP Bug 2341 - ntpd fails to keep up with clock drift at poll > 7
http://bugs.ntp.org/show_bug.cgi?id=2341

So our advice is to use "minpoll 6 maxpoll 6" as indicated in the 
example above.


The patched ntpd has caused no drawbacks on any Windows machines, but 
has improved accuracy on a number of installations.



Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

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

Re: [time-nuts] Warped back to 1993

[Martin Burnicki]

Bob Camp wrote:

Hi

The issue with the fudge option is that you need to engage it at
exactly the right point. Put another way, there's a period between it
failing and your entering a fudge that the NTP server is down.


The question is whether you know in advance *when* the problem will occur.

If you observe that your GPS sends a wrong date you are already after 
the point where the bug started to occur, so you can safely add a fudge 
value to get this working for the next 1024 weeks.



With a
couple lines of auto correct code in there, it would (essentially)
never fail. If you are running a GPS, you enable the auto-correction
and forget about it. My guess is that many GPS devices will
eventually suffer from the wrap around. The  only way they could
avoid it would be some sort of external correction (like continuous
firmware updates) or a "no reverse" on the year. Both approaches have
their drawbacks…..


Unless you know the source code of the firmware you can only assume what 
is the reason for the wrong date being sent. I'm not sure whether a 
piece of software like ntpd should try to work around all possible kinds 
of firmware bugs in all possible types of GPS receivers.


Martin

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

Re: [time-nuts] Warped back to 1993

[Martin Burnicki]

Bob Camp wrote:

Hi

… and since NTP is open source, doing the hack is not dependent on getting a 
new firmware image for the GPS.


Hacking ntpd is one possibility, with the risk that a workaround for 
some broken GPS receiver also affects GPS receivers which are working 
correctly.


At least in some of ntpd's refclock drivers you can configure a fixed 
offset using a "fudge time1 ..." command., e.g. for the parse driver


fudge 127.127.8.0 time1 7200

would add a 7200 s offset to the time from the refclock. As far as I 
know this also works for larger offsets, at least with the parse driver, 
and this possibly can also be used to fix a constant offset for broken 
GPS receivers, depending of the refclock driver used.


Anyway, I think it's worth a try, and it would not require any code 
change in ntpd or the firmware.


Martin

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

Re: [time-nuts] Warped back to 1993

[Martin Burnicki]

bg wrote:

As has been discussed here before.

The GPS firmware programmer finalizing his stuff at GPS week X
(approaching 1024) will make sure his receiver will survive until X
weeks into the next era. What X is is hard for the end user to know.
1024 weeks is long time beyond normal warranties.


Right, this is one possible reason.


I have seen era predictions based on # of leap seconds. But that
particular implementation did not fare well with long leapsecondless
periods we had.


I remember a discussion about this way to guess the epoch. Depending on 
the implementation and the intervals between leap seconds about 15 years 
ago, and looking at the large intervals between the last leap seconds, 
this may also fail.


A much simpler way to handle this is to provide a way where the user can 
enter the current date, and the firmware determines the correct epoch 
and week number.


This also had to be done only once if a receiver was powered up from 
scratch. If the receiver knows it has already been operating at a date 
after one or more rollovers it can easily get the right epoch.


Martin

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

Re: [time-nuts] ***SPAM*** TED Talk: Todd Humphreys: How to fool a GPS

[Martin Burnicki]

Hal Murray wrote:

http://www.ted.com/talks/todd_humphreys_how_to_fool_a_gps.html

Good overview leading up to GPS Spoofing.

It's a year or so old so it doesn't cover any of the recent spoofing demos.


This is indeed a good summary of GPS applications and potential risks.

Thanks for the pointer!

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