[time-nuts] Syncing Tom's PICDivs to 1PPS

[Bob Stewart]

For my next GPSDO board revision, I would like to include one of Tom's PICDiv 
devices to give a much better 1PPS out than the Ublox receivers are capable of. 
 This means that it has to be started (or slewed to be) exactly on time.  So I 
was wondering if anyone had experimented in controlling the startup of one of 
these PICDivs to make them in sync, and if you'd be willing to share your 
solution before I start digging into it.  I haven't yet looked at the source 
code for any of these devices, but it's my understanding that this feature 
isn't provided, and is deemed to be difficult due to the input divider making 
for a large steering step.  Even a suggestion as to which of the chips would be 
the best candidate would be much appreciated.  I'm looking for a method that's 
deterministic, rather than starving the PICDiv of clock cycles and waiting for 
the 1PPS to match a conveniently correct 1PPS from the Ublox.

Bob - AE6RV
 -
AE6RV.com

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

Re: [time-nuts] GPS message jitter (preliminary results)

[Chris Albertson]

I might have been the one who brought up the problem of the NMEA
message not being right on the UTC send tick.   But now I'm thinking
of another problem this might create.   It is slightly off topic
because it has to do with location.

Let's say I have a mobile robot (or a self driving car) that wants to
know where it is.  I have a three axis gyro, three axis accelerometer
and a three axis magnetometer (acting as a magnetic compass.  I also
have rotational encoders on the wheels to count millimeters of travel.
In theory I can dead recon from any known point but all of those
sensors drift or are otherwise imperfect.   So I add GPS.  GPS's
problem is it's on order 10 meter level accuracy and I need
centimeters or better.  The combination works.  Each sensor makes up
for the faults in the others.

But up until now I have forgotten that the NMEA location data is
likely some tens or hundreds of milliseconds old before it is output
on the wire.   This "noise" was hidden in the large location
uncertainty inherent in GPS.   Accounting for this should make my GPS
more accurate.

Now an off topic question that I bet many in this group can answer.
I'm a total novice when it comes to Kalman Filters.  I need to
expertly combine all this data using one.   Anyone got a good
(hopefully on-line) tutorial or a cheap book on Amazon. (yes I used
Google, got 1,000+ hits)  I'm trying to do this myself and have found
I forgot most of my Linear Algebra (it's been 30 years) and I doubt I
ever really understood Kalman Filters completely

On Tue, Jul 19, 2016 at 10:20 AM, Mark Sims  wrote:
> I ran some tests on the message timing of some V.KEL gps receivers in both 
> NMEA and binary mode.  These receivers are the cheapest ones I have (3 for 
> $15 - $20, shipped).   They use a SIRF III chip and have an on-board ceramic 
> patch antenna.  They performed amazingly well.  No problems tracking sats 
> indoors in a very poor location.   Message jitter was less than 20 msecs 
> peak-peak,  standard deviation less than 2 milliseconds.   ADEVs at tau 1 
> after an overnight run in NMEA mode (hardware serial port) were in the 1E-7 
> range!They also have a 1PPS signal on the connector so no need to go 
> digging for a place to bodge on a wire like with some of the other cheap GPS 
> modules out there.
>
> V.KEL also makes a Ublox based version of the module (around $22 for one)... 
> mine reports that it has a Ublox 7 chip, though V.KEL's part number implies 
> that it a Ublox 6.
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



-- 

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

[time-nuts] Seiko watch "leap second enabled"

[Mike Cook]

While I was googling for reports of other misbehaving GPS chips, I discovered 
the existence of the worlds first leap second enabled wrist watch.
Seiko introduced the Astron models 8X53, 8X82, 7X52 which automatically check 
for a leap second on ……. 

«  Seiko Astron enters the leap second data receiving mode after the first GPS 
signal is received on or after June 1st and December 1st. »  (User Manual)

D’OH!…

Maybe one of Homer’s inventions.

If any of you have one, have you checked how it has reacted?


"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
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

[Mike Cook]

> Le 20 juil. 2016 à 22:10, Gary E. Miller  a écrit :
> 
> Yo Martin!
> 
> On Wed, 20 Jul 2016 21:37:02 +0200
> Martin Burnicki  wrote:
> 
>> 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.
> 
> I have a report of a Venus8, with BeiDou, that jumped NMEA time by one
> second on the 19th.
> 
> The NMEA offset data is fun:
> 
>https://dan.drown.org/bbb/latest/remote-statistics.NMEA.png

possibly related the the issue reported back in january 2015.

"Back in January it was reported here that the Venus 8 timing modules from 
Skytraq as used in the LTE-Lite, had a firmware bug that was causing the leap 
second to be applied as soon as the warning was seen in the GPS stream. I had 
bought one from Navspark  and once I reported the issue they shipped me a 
replacement receiver as soon as the F/W update was available. I would have 
preferred the new F/W, but I got a free receiver as they did not want me to 
return the bugged one. "

> 
> But some other, different, models of Venus8 did not.
> 
> I'm trying to get more information.
> 
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>   g...@rellim.com  Tel:+1 541 382 8588
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
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 (preliminary results)

[albertson . chris]

To answer about how they get good timing. Many times you run a loop that runs 
off a timer at say exact 1000 times per second. Having something like a 1KHz 
loop gives very deterministic timing. Lots of ways to do it. One is to run some 
RTOS. I had to make all the axis of a machine tool move at exact timing to cut 
a curve. Not hard just have decide to do it. I'm sure most engineers looked at 
the NMEA spec and read "with the second" and stopped at that. 

> On Jul 20, 2016, at 5:40 PM, Bob Camp  wrote:
> 
> HI
> 
>> On Jul 20, 2016, at 7:51 PM, Mark Sims  wrote:
>> 
>> I added the ability of Lady Heather to calculate the time offset of the 
>> timing message from "wall clock" time.  It calculates the difference between 
>>  the system clock time to the time that the (end of) the timing message 
>> arrived.   The result is only as good as your system clock, so the system 
>> clock really needs to be synced to something like NTP (otherwise it does a 
>> decent job of showing how much your system clock is drifting).  Heather can 
>> plot the results and calculate xDEVs on both the message jitter and the 
>> message offset time in real time.
>> 
>> On another note,  I did some jitter measurements on  Jupiter-T and Jupiter-T 
>> Pico receivers.I can't imagine how they do it, but those things are 
>> insanely good.   Running at 9600 baud,  their message jitter into a hardware 
>> serial port is less than a millisecond peak-peak!  Somebody paid a LOT of 
>> attention to getting the message timing consistent…
> 
> Just pre-load it all into a big shift register and let the PPS output gate 
> the clock to the beast.  There’s not a lot of doubt about what the label on 
> the next second going out will be :)
> 
> Bob
> 
>> 
>> 
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] KO4BB out of space

[Didier Juges]

KO4BB.com ran out of disk space.


Apparently the Control Panel indicated I was using 120GB out of 160
available, but it was off by about 40GB...


About 90GB of that are manuals.


A good bit of the extra are duplicate files that resulted from the site
hosting transfer a couple of years ago that I had planned to clean up at
some point. I was just not planning to do that NOW!!!


The problem has been temporarily fixed, I have freed 10GB and hopefully I
will have made more space (or bought more space...) over the week end.


Thank you for your patience and your support.


Didier KO4BB
___
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 (preliminary results)

[Bob Camp]

HI

> On Jul 20, 2016, at 7:51 PM, Mark Sims  wrote:
> 
> I added the ability of Lady Heather to calculate the time offset of the 
> timing message from "wall clock" time.  It calculates the difference between  
> the system clock time to the time that the (end of) the timing message 
> arrived.   The result is only as good as your system clock, so the system 
> clock really needs to be synced to something like NTP (otherwise it does a 
> decent job of showing how much your system clock is drifting).  Heather can 
> plot the results and calculate xDEVs on both the message jitter and the 
> message offset time in real time.
> 
> On another note,  I did some jitter measurements on  Jupiter-T and Jupiter-T 
> Pico receivers.I can't imagine how they do it, but those things are 
> insanely good.   Running at 9600 baud,  their message jitter into a hardware 
> serial port is less than a millisecond peak-peak!  Somebody paid a LOT of 
> attention to getting the message timing consistent…

Just pre-load it all into a big shift register and let the PPS output gate the 
clock to the beast.  There’s not a lot of doubt about what the label on the 
next second going out will be :)

Bob

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

___
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] GPS message jitter (preliminary results)

[Mark Sims]

I added the ability of Lady Heather to calculate the time offset of the timing 
message from "wall clock" time.  It calculates the difference between  the 
system clock time to the time that the (end of) the timing message arrived.   
The result is only as good as your system clock, so the system clock really 
needs to be synced to something like NTP (otherwise it does a decent job of 
showing how much your system clock is drifting).  Heather can plot the results 
and calculate xDEVs on both the message jitter and the message offset time in 
real time.

On another note,  I did some jitter measurements on  Jupiter-T and Jupiter-T 
Pico receivers.I can't imagine how they do it, but those things are 
insanely good.   Running at 9600 baud,  their message jitter into a hardware 
serial port is less than a millisecond peak-peak!  Somebody paid a LOT of 
attention to getting the message timing consistent...


  
___
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

[Gary E. Miller]

Yo Noah!

On Wed, 20 Jul 2016 17:12:14 -0400
Noah  wrote:

> First time poster; just subbed. Not a time hobbies the; my team @
> work runs NTP infrastructure. So , that's a brief intro out of the
> way...

Yes, a few of us NTP people here.  We are several orders of magnitude
coarser tham a true time-nut.
> 
> Discovered that my commercial GPS appliances opted to *apply*
> yesterday's pending leap second, which has made for an interesting
> day.

Got any details?  GPS model?  Did it get past your NTP into system time?

I'm passing this info onto NTPsec devel folks.  Time to 'Name and Shame".

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


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

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

[Jay Grizzard]

On Wed, Jul 20, 2016 at 09:37:02PM +0200, Martin Burnicki wrote:
> 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.

I don't actually know what the time it's outputting is (this particular
chip I'm grabbing stats from, but not time), but I'm pretty certain that
nothing should be returning '18' yet. In specific, from the docs for the
'UTC Offset' field in the Trimble docs for the TSIP primary timing packet
(0x8F-AB):

This field represents the *current* integer leap second offset between
GPS and UTC

(emphasis mine)

However, even if it was outputting the correct thing in the timing packets, 
that only applies if the GPS is set to report UTC time rather than GPS time
(which is selectable on Trimble chips).  You should be able to get GPS 
time from the output and add the UTC offset to get UTC time, but that won't
work with the data this chip is currently outputting.

Even if reporting 18 is correct, though, Trimble still has a problem,
because my Thunderbolt is still reporting 17, and I'm pretty sure they're
not both right (same company, same protocol, different values). Either that,
or Trimble provides a "UTC Offset" field with every timing packet that they
don't actually intend for anyone to use for anything, but that would just
be weird.

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

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

[Noah]

First time poster; just subbed. Not a time hobbies the; my team @ work runs NTP 
infrastructure. So , that's a brief intro out of the way...

Discovered that my commercial GPS appliances opted to *apply* yesterday's 
pending leap second, which has made for an interesting day.

--n

>> On Jul 19, 2016, at 8:39 PM, 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.
> 
> (I've sent an email to Trimble support, but haven't heard anything back yet.)
> 
> -j
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
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] Motorla Oldie

[Oz-in-DFW]

On 7/19/2016 5:09 PM, Pete Lancashire wrote:
> Saw this guy at GoodWill, but they wanted $25 for it so didn't get it.
>
> Model: A11121Z115
>
> http://petelancashire.com/gallery/main.php?g2_itemId=7196
>
> http://petelancashire.com/gallery/main.php?g2_itemId=7200
>
> -pete
> ___
> 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.

Looks like a PVT-6.  I sold a bunch of them used in the late 80's for
$15 ea.  Poor acquisition time and sensitivity when compared to current
gen cheapies.

-- 
mailto:o...@ozindfw.net
Oz
POB 93167 
Southlake, TX 76092 (Near DFW Airport) 



___
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] Lucent KS-24361 REF-0

[Mark Sims]

I got in a Z3812A (aka Lucent KS-24361 REF-0) and installed a Motorola UT+ in 
it following the excellent guide by Peter Garde (google is your friend) and 
have it working as a standalone GPSDO...basically it now a REF1 unit).  The 
mod mostly involves moving half a dozen 0 ohm resistors (I chopped out the 
resistors... too lazy to unsolder them...  and used wire wrap wire to replace 
them))  The gps receiver was around $20 from RDR Electronics.

Yes, you could emulate the Motorola receiver with a newer model,  but that is a 
LOT of work to do correctly for very little benefit (I've never seen a receiver 
that offers Motorola emulation get it entirely correct).  Or you could use 
Dan's GPS message faker hack,  but lose the ability to fully control the ref0 
via SCPI commands / Lady Heather and would wind up spending the same amount as 
adding in the GPS receiver. 



  
___
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] Lucent KS-24361 REF-0

[Joe Orsak]

Yes I was looking forward to seeing his "Tria" drop in Oncore replacement but 
it looks like he moved on to other projects. 


 Original message 
From: paul swed  
Date:07/20/2016  2:08 PM  (GMT-05:00) 
To: Discussion of precise time and frequency measurement  
Subject: Re: [time-nuts] Lucent KS-24361 REF-0 

Have not heard from Dan in a while.
I did test various arduinos with his software and it all worked just fine.
The system stability really depended on the quality of the GPS pps used.
Regards
Paul
WB8TSL

On Wed, Jul 20, 2016 at 12:11 PM, Gregory Beat  wrote:

> Dan Watson spent considerable time (2015) on standalone Lucent KS-24361
> REF-0
> with a "new" GPS board that would be "backward" compatible.
> Not sure where he is fir project in 2016 (availability of OSHPark boards).
> http://syncchannel.blogspot.com/2015/10/denuo-gps-retrofit-board.html
>
> Sent from iPad Air
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] 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] Lucent KS-24361 REF-0

[paul swed]

Have not heard from Dan in a while.
I did test various arduinos with his software and it all worked just fine.
The system stability really depended on the quality of the GPS pps used.
Regards
Paul
WB8TSL

On Wed, Jul 20, 2016 at 12:11 PM, Gregory Beat  wrote:

> Dan Watson spent considerable time (2015) on standalone Lucent KS-24361
> REF-0
> with a "new" GPS board that would be "backward" compatible.
> Not sure where he is fir project in 2016 (availability of OSHPark boards).
> http://syncchannel.blogspot.com/2015/10/denuo-gps-retrofit-board.html
>
> Sent from iPad Air
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Jay Grizzard]

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.

(I've sent an email to Trimble support, but haven't heard anything back yet.)

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

Re: [time-nuts] Lucent KS-24361 REF-0

[Gregory Beat]

Dan Watson spent considerable time (2015) on standalone Lucent KS-24361 REF-0
with a "new" GPS board that would be "backward" compatible.
Not sure where he is fir project in 2016 (availability of OSHPark boards).
http://syncchannel.blogspot.com/2015/10/denuo-gps-retrofit-board.html

Sent from iPad Air
___
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

[Nick Sayer via time-nuts]

> On Jul 20, 2016, at 12:25 AM, Tom Van Baak  wrote:
> 
> Hi Gary,
> 
>> 2.1 A positive or negative leap-second should be the last second of a UTC 
>> month,
>> but first preference should be given to the end of December and June,
>> and second preference to the end of March and September.
> 
> Sounds correct. The point is to never to hardcode a "preference". You code 
> against a spec. And the spec is simple:
> 
> "A positive or negative leap-second should be the last second of a UTC month"
> 

Even that’s weasel-worded. If they mean it, they should say it *will* or it 
*must* be the last second of a UTC month.

Words have meanings. :D

___
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] Agilent 53132 Power module

[Bert Kehren via time-nuts]

My Agilent 53132 power module went bad, does any one have one for sale or  
info or schematic.
Thanks   Bert Kehren
___
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 

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

[David Malone]

Hi Hal,

I guess you know this but...

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

ntp_loopfilter.c used to have code that restricted the months for
leap seconds. The new core ntpd code doesn't do this check, though
if you have an up-to-date leapseconds file, it will veto bad
suggestions.

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

[David Malone]

On Wed, Jul 20, 2016 at 01:05:59AM -0700, Hal Murray wrote:
> g...@rellim.com said:
> > Yes, I know the problem being solved.  Like today, the leap second being
> > broadcast sooner than ntpd expects, so it picks the wrong month. 

> Do you know of any ntp servers that have picked the wrong month?

When I was writing up my leap second measurements, I went looking
for reports of leap seconds in unusual months (i.e. not in
June/Decembet) and managed to find the following:

http://lists.ntp.org/pipermail/questions/2007-October/015655.html
http://lists.ntp.org/pipermail/questions/2012-August/033611.html
http://lists.ntp.org/pipermail/questions/2013-July/035664.html

For the first, I think Windows was involved?  For the second, I'm
not sure how many people accidently leaped. For the last, there was
definitely one leap.

David.
___
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] Leap second to be introduced at midnight UTC December 31 this year

[Hal Murray]

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

Do you know of any ntp servers that have picked the wrong month?


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?


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.


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.

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





-- 
These are my opinions.  I hate spam.



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

Re: [time-nuts] How does sawtooth compensation work?

[Michael Wouters]

Hello Michael
> Thinking out loud, I wonder how bad L1-only, post-processed, would be for 
> time-nuts use? Especially with a timing-grade antenna (e.g. the common 
> Trimble Bullet). Dual frequency is great when your receiver has the potential 
> to move, you have to resolve carrier phase ambiguity quickly, or you don't 
> have a reference station (CORS) nearby. (O.T. I was out hiking in Washington 
> state recently, and *accidentally* happened upon my local CORS station, so I 
> guess that's no issue for me :-)). But for many time-nuts, I wonder how badly 
> a timing-grade antenna, something with raw carrier phase output (which you 
> get very cheaply these days), and a stable enough local clock to allow you 
> average out local weather.
>

There was a related discussion a month ago
https://www.febo.com/pipermail/time-nuts/2016-June/098484.html
and I posted a plot
https://www.febo.com/pipermail/time-nuts/attachments/20160616/cb2801b0/attachment.png
which might be helpful.

As you can see, the improvement from raw 1 pps to a full carrier-phase
solution with IGS rapid orbits and clock solutions is not enormous,
just a factor of 4 in stability. BIPM does a bit better with TAI PPP,
eg ftp://ftp2.bipm.org/pub/tai/publication/timelinks/taippp/1606/
maybe 30% or so. (To be completely fair, the raw 1 pps is from a $10K
GPS receiver with a very good sawtooth correction so there may be a
bit more of an improvement at averaging times less than 1000 s or so)

There are a few more plots of L1 receiver performance at:
http://www.openttp.org/scripts/blog.php

> For time-nut use, I don't see any harm in using post-processing for 
> evaluation/measurement of clocks.

This is exactly how most of the clocks contributing to UTC are linked
together across the world.

Cheers
Michael

On Wed, Jul 20, 2016 at 9:41 AM, Michael  wrote:
> Thanks Tom, Bob, and Mark (wrote my response to Tom first, but didn't hit 
> send)!
>
> I've actually been collecting some *ancient* dual-frequency geodetic gear to 
> play with, some of which have external clock inputs (or should be hackable). 
> I've read a lot, but I wasn't sure what people were typically referring to on 
> this list. Thanks for the overview...that helps me connect the dots between 
> the time-nuts and survey/geodetic GPS worlds.
>
> For time-nut use, I don't see any harm in using post-processing for 
> evaluation/measurement of clocks. Won't get you something usable in 
> real-time, for sure, but if you're already collecting weeks of data, don't 
> see any harm in waiting for precise orbit and clock solutions to become 
> available for post processing. And it might tell me how far off you are in a 
> 24-hour PPP solution. Which I guess means you'd need to be very stable in the 
> <=24hr region.
>
> Thinking out loud, I wonder how bad L1-only, post-processed, would be for 
> time-nuts use? Especially with a timing-grade antenna (e.g. the common 
> Trimble Bullet). Dual frequency is great when your receiver has the potential 
> to move, you have to resolve carrier phase ambiguity quickly, or you don't 
> have a reference station (CORS) nearby. (O.T. I was out hiking in Washington 
> state recently, and *accidentally* happened upon my local CORS station, so I 
> guess that's no issue for me :-)). But for many time-nuts, I wonder how badly 
> a timing-grade antenna, something with raw carrier phase output (which you 
> get very cheaply these days), and a stable enough local clock to allow you 
> average out local weather.
>
> I guess while it's fascinating to me...wonder if it has any use in practice 
> compared to a simple, autonomous, real-time, L1-only receiver? I mean, I'm 
> interested in measuring my local tropospheric and ionospheric delays. But 
> then again, I am an aspiring time-(and maybe GPS)-nut :).
>
> Michael
>
>> Hi Michael,
>>
>> About #3 below...
>>
>> There are dozens of technical papers about all this in the PTTI, FCS, UFFC, 
>> EFTF journals. Google for words like: GPS carrier-phase dual-frequency 
>> time-transfer geodetic-receiver IGS precise point positioning PPP
>>
>> I don't have a link to a handy 1-page summary, but someone else on the list 
>> might. Otherwise skim the first ten papers you find and you'll pick up the 
>> concepts of high-precision time transfer.
>>
>> The basic idea is that high-end geodetic-grade receivers often have an 
>> external 10 or 20 MHz clock input (and maybe no internal clock at all). You 
>> give it your best lab clock and all then all GPS signal processing and SV 
>> measurements are based on your fancy clock. The output of the receiver is a 
>> stream of these measurements, not necessarily a physical 1PPS or 10 MHz (as 
>> with a GPSDO).
>>
>> So you can see there's no such thing as sawtooth error here, because you're 
>> not transferring some internal clock to some external clock via a TIC; there 
>> is only the one clock; your clock.
>>
>> All this measurement data is then post-processed, hours 

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

[Tom Van Baak]

Hi Gary,

> 2.1 A positive or negative leap-second should be the last second of a UTC 
> month,
> but first preference should be given to the end of December and June,
> and second preference to the end of March and September.

Sounds correct. The point is to never to hardcode a "preference". You code 
against a spec. And the spec is simple:

"A positive or negative leap-second should be the last second of a UTC month"

It would appear that assuming the preference was actually a rule is what causes 
the Z3801A f/w to mis-report the next leap second as September instead of 
December. Back in the late 90's, when the 58503/Z3801 code was written, this 
made sense. Leap second annoucenements were not made half a year in advance 
back then.

/tvb

- Original Message - 
From: "Gary E. Miller" 
To: "Tom Van Baak" 
Cc: "Discussion of precise time and frequency measurement" 
Sent: Tuesday, July 19, 2016 10:36 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 
31 this year

Yo Tom!

> > IERS is free to schedule a leap second at the end of any month. And
> > it may be an insert or a delete. Assume nothing more or less in your
> > code. Code and test and document for positive and negative leap
> > seconds equally.  
> 
> Got a reference for that?  I know many people that will insist
> otherwise.

Never mind, I think I found a reference that is commonly quoted:

CCIR Recommendation 460-4 (1986).

http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en

2. Leap-seconds
2.1 A positive or negative leap-second should be the last second
of a UTC month, but first preference should be given to the end of
December and June, and second preference to the end of March and
September.

But it is marked Superceded.  I'm guessing that is replaced by 460-6?

http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en

It says the same thing in section 2.1

Nothing says it has to be those 4 months...

I have some code comments in gpsd to fix...

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

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

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

[Gary E. Miller]

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.

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

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

/* 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.  I'm
sure something else will crop up before 2017.

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.

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


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

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

[Magnus Danielson]

Gary,

On 07/20/2016 07:36 AM, Gary E. Miller wrote:

Yo Tom!


IERS is free to schedule a leap second at the end of any month. And
it may be an insert or a delete. Assume nothing more or less in your
code. Code and test and document for positive and negative leap
seconds equally.


Got a reference for that?  I know many people that will insist
otherwise.


Never mind, I think I found a reference that is commonly quoted:

CCIR Recommendation 460-4 (1986).

http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en

2.  Leap-seconds
2.1 A positive or negative leap-second should be the last second
of a UTC month, but first preference should be given to the end of
December and June, and second preference to the end of March and
September.

But it is marked Superceded.  I'm guessing that is replaced by 460-6?

http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en

It says the same thing in section 2.1

Nothing says it has to be those 4 months...


No, but the wording do say that those four month is preferred. For those 
that is curious:

http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf

8<---
2   Leap-seconds

2.1	A positive or negative leap-second should be the last second of a 
UTC month, but first preference should be given to the end of December 
and June, and second preference to the end of March and September.


2.2	A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of 
the first day of the following month. In the case of a negative 
leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s 
of the first day of the following month (see Annex 3).


2.3	The IERS should decide upon and announce the introduction of a 
leap-second, such an announcement to be made at least eight weeks in 
advance.

--->8

Thus, any month can be scheduled, but there is a preference to end of 
half-year and then end of quarter. The main preference is used in 
practice, which is in good accordance with the rules, the Z3801A 
designers over-eagerly included also the remaining two end-of-quarter.



I have some code comments in gpsd to fix...


Yes, but it can take a long time before it would bite you.
Beware of GPS-receivers such as Z3801A which now give the time of leap 
second 3 month to early, and beware that eventually end of March and end 
of September might become legal points even for a Z3801A.


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.


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.


Ah well.

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