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

[Hal Murray]

noah.ro...@gmail.com said:
> Discovered that my commercial GPS appliances opted to *apply* yesterday's
> pending leap second, which has made for an interesting day. 

Could you please say more?

How are you working around it?

Vendor?  Model?  Can you take the cover off (or peer in through the vents) 
and see what type of GPS receiver they are using?

I assume the gear is recent or the problem would have been discovered the 
last time we had a leap second.  Have you contacted the vendor?  Have they 
confirmed the problem?  Any estimate on when they will ship new firmware?

Has anybody else noticed the problem?  (I tried google news and NANOG but 
didn't find anything.)



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

[Noah]

Trimble Res-SMT-GG GNSS receivers are affected; in my case, they're installed 
in Spectracom SecureSyncs. And yes, the extra second got into system time which 
broke 1 or 2 things. 

--n

> On Jul 20, 2016, at 5:26 PM, Gary E. Miller  wrote:
> 
> 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
___
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] Syncing Tom's PICDivs to 1PPS

[Scott Stobbe]

I think you will have to decided if you want both your xo (presumably 10
MHz) and PPS to be phase aligned to UTC. No matter which way you go you
will have propagation delay across a clock divider. If you just want your
PPS to be on phase, you can steer your xo.

On Thu, Jul 21, 2016 at 12:11 AM, Bob Stewart  wrote:

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

A lot of the newer GPS modules can accept "dead reckoning"  data from external 
sensors and integrate that into their location solutions.  The receiver does 
all the Kalman filtering foo for you.  Also you can get receivers with up to 
50Hz position updates (you have to run the com link at very high speeds to 
accommodate all the data that they send).   This well help minimize the 
"staleness" of the GPS fix versus true position.

Also you can now get affordable real-time kinematic receivers that will give 
you your location relative to another receiver with centimeter accuracy.

-

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

[Scott Stobbe]

If your not bean counting for a commercial product you can take a look at
particle filtering, its like a real-time monte-carlo simulation.

The location estimate in NEMA is also heavily filtered and referenced to
its utc time estimate (PPS). Conceivably could be filtered to a bandwidth
of Fs/2, 500 milliHz.

On Thu, Jul 21, 2016 at 12:00 AM, Chris Albertson  wrote:

> 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 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] Syncing Tom's PICDivs to 1PPS

[Tom Van Baak]

Hi Bob,

Many of the PIC divider programs that I wrote include an arm-sync feature, 
which is useful to capture a 1PPS and align the divider to UTC. The source code 
to most of them are at http://leapsecond.com/pic/src/ and you can use it as a 
model.

These make use of the fact that PIC 12F-series chips have constant ISR latency 
so the alignment is perfect to within one PIC instruction, which is four 10 MHz 
clock cycles. So that's nice, but "perfect" does not mean zero. This is true 
for all dividers I've seen. The hp 5071A cesium clock does not (can not) sync 
to nanosecond perfect alignment either. Even if you used an FPGA, a 10 MHz 
clock still leaves up to 100 ns error in the sync. You get the idea.

If you were doing it all in h/w you could arrange to reset the entire 10^7 
synchronous divider chain to under 1 cycle, and then either re-clock the Nth 
cycle as the 1PPS, or add delays so that N-1th pulse to becomes the 1PPS. It 
all depends on how picky you want to be about gate delays.

In practice what GPSDO often do is artificially steer the OCXO at some 
frequency offset for some duration in order to move the phase of the 1PPS. For 
example, if you run the OCXO fast by 1e-9 for a minute, you have now moved the 
1PPS phase ahead by 60 ns.

That means syncing a GPSDO is a two step process. 1) get it to with one or a 
couple of cycles by zeroing the divider chain, and then 2) get it to within one 
or a couple of ns by steering the OCXO for a calculated duration. This also 
implies that the internal TIC has ns resolution and many hundreds of ns range.

/tvb

- Original Message - 
From: "Bob Stewart" 
To: "Discussion of Precise Time and Frequency Measurement" 
Sent: Wednesday, July 20, 2016 9:11 PM
Subject: [time-nuts] Syncing Tom's PICDivs to 1PPS


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] Syncing Tom's PICDivs to 1PPS

[Edesio Costa e Silva]

Some models support synchronization to a external (PPS) reference. Take a
look at http://leapsecond.com/pic/picdiv.htm

Edésio

On Thu, Jul 21, 2016 at 10:05:15AM -0400, Scott Stobbe wrote:
> I think you will have to decided if you want both your xo (presumably 10
> MHz) and PPS to be phase aligned to UTC. No matter which way you go you
> will have propagation delay across a clock divider. If you just want your
> PPS to be on phase, you can steer your xo.
> 
> On Thu, Jul 21, 2016 at 12:11 AM, Bob Stewart  wrote:
> 
> > 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.
> >
> ___
> 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

[Noah]

> On Jul 21, 2016, at 5:23 AM, Hal Murray  wrote:
> 
> 
> noah.ro...@gmail.com said:
>> Discovered that my commercial GPS appliances opted to *apply* yesterday's
>> pending leap second, which has made for an interesting day.
> 
> Could you please say more?
> 
> How are you working around it?
> 
> Vendor?  Model?  Can you take the cover off (or peer in through the vents) 
> and see what type of GPS receiver they are using?

In earlier email. 

> 
> I assume the gear is recent or the problem would have been discovered the 
> last time we had a leap second.  Have you contacted the vendor?  Have they 
> confirmed the problem?  Any estimate on when they will ship new firmware?

We just finished replacing our previous gear with this a week ago; timing is 
everything. :)  Vendor was contacted yesterday and have supplied a patch this 
morning to reduce the GPS->UTC offset back to 17 until they get a more 
permanent fix from Trimble. I've not installed it yet, but the vendor states 
the patch won't persist across reboots. 

--n
___
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)

[Tom Van Baak]

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

Mark,

Here's another data point for all you modern serial oversampling UART jitter 
people --

The cute little 8-pin 12F675 PIC's that I use for my picPET and picDIV projects 
don't even have a UART. So all RS232/TTL serial output or input is done with 
bit-banging in assembly code. You may laugh at that. But one advantage is that 
serial processing is accurate down to 1 cycle. That is, you can output the 
start bit on the exact cycle you want. And for input, you can timestamp the 
start bit down to 1 cycle.

I agree this approach has limited appeal these days, but my point is that 
old-style bit-banging serial IO does have certain time nut advantages. You can 
effectively treat serial IO like IRIG; that is, both the alignment of the start 
bits (clock edges) and the content of the bytes (ascii data) are used to 
transfer the time.

Again, this is why I can make sub-us measurements of NMEA jitter by just using 
a picPET. The start bit of the first byte of the first NMEA sentence is an edge 
and the picPET happily converts it to a precise UTC timestamp.

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

[time-nuts] NCOCXO anyone?

[Nick Sayer via time-nuts]

Would anyone see any value in a board that had an OH300 with a serial interface 
for tuning?

I had a thought perhaps to make one starting with my GPSDO and just ditching 
the GPS part and possibly adding an RS-232 level converter.  I could 
conceivably bring it all out to a DB9 and emulate an FE-5680 (obviously it's 
long term stability would be poorer without some discipline) or just make my 
own protocol up. 

Sent from my iPhone
___
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)

[Thomas D. Erb]

Here is an interesting discussion of Kalman filtering.



http://math.stackexchange.com/questions/173901/why-use-a-kalman-filter-instead-of-keeping-a-running-average



Thomas D. Erb
t...@electrictime.com /
Electric Time Company, Inc.
Office: 508-359-4396 x 117 / Fax: 508-359-4482
97 West Street Medfield, MA 02052 USA
www.electrictime.com
[Facebook][Twitter][pinterest]
[htmlsig.com]
___
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] 1 second timing error re leap second

[Martyn]

Hello, 

Anyone know if the   M12T or Lea Bloc GPS chips have the same problem as the 
Trimble products

Regards

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

[Tom Van Baak]

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.

Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, not 
so much by rare steps but by dithering. There would be no change to UTC or 
timing infrastructure because the definition of UTC already allows for positive 
or negative leap seconds in any given month.

Every UTC-aware device would 1) know how to reliably insert or delete a leap 
second, because bugs would be found by developers within a month or two, not by 
end-users years or decades in the future, and 2) every UTC-aware device would 
have an often tested direct or indirect path to IERS to know what the sign of 
the leap second will be for the current month.

The leap second would then become a normal part of UTC, a regular monthly 
event, instead of a rare, newsworthy exception. None of the weird bugs we 
continue to see year after year in leap second handling by NTP and OS's and GPS 
receiver firmware would occur.

Historical leap second tables would consist of little more than 12 bits per 
year.

Moreover, in the next decade or two or three, if we slide into an era where 
average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a day, 
there will be zero impact if LSEM is already in place.

/tvb

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

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

[Wojciech Owczarek]

Every year... always makes me wonder, do these vendors even test this 
themselves? I know at least one vendor who disn't have GPS simulators and 
relied on Trimble's built-in test mode - which gives you 13-bit week counters, 
whereas the satellites give you 10-bit counters. So the vendor assumed 13-bit 
and was comparing the current wc to 13-bit that never came. Luckily I found the 
issue months before the event, and only because we purchased GPS simulators - 
which I recommend to anyone running timing services in production.

Oh well, at least this keeps us busy.


  Original Message  
From:noah.ro...@gmail.com
Sent:21 July 2016 5:11 p.m.
To:time-nuts@febo.com
Reply to:time-nuts@febo.com
Cc:hmur...@megapathdsl.net
Subject:Re: [time-nuts] Leap second to be introduced at midnight UTC December 
31 this year



> On Jul 21, 2016, at 5:23 AM, Hal Murray  wrote:
> 
> 
> noah.ro...@gmail.com said:
>> Discovered that my commercial GPS appliances opted to *apply* yesterday's
>> pending leap second, which has made for an interesting day.
> 
> Could you please say more?
> 
> How are you working around it?
> 
> Vendor?  Model?  Can you take the cover off (or peer in through the vents) 
> and see what type of GPS receiver they are using?

In earlier email. 

> 
> I assume the gear is recent or the problem would have been discovered the 
> last time we had a leap second.  Have you contacted the vendor?  Have they 
> confirmed the problem?  Any estimate on when they will ship new firmware?

We just finished replacing our previous gear with this a week ago; timing is 
everything. :)  Vendor was contacted yesterday and have supplied a patch this 
morning to reduce the GPS->UTC offset back to 17 until they get a more 
permanent fix from Trimble. I've not installed it yet, but the vendor states 
the patch won't persist across reboots. 

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

[Rob Seaman]

Hi Tom,

This message is an excellent example of why we invited you to speak at the 
Science of Time symposium ;-)

It was a shame you couldn’t make it, since you would have made an excellent 
meeting even stronger. But future meetings in the series seem very likely and 
let me register an invitation now...

Rob
—

> On Jul 21, 2016, at 10:27 AM, 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.
> 
> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, 
> not so much by rare steps but by dithering. There would be no change to UTC 
> or timing infrastructure because the definition of UTC already allows for 
> positive or negative leap seconds in any given month.
> 
> Every UTC-aware device would 1) know how to reliably insert or delete a leap 
> second, because bugs would be found by developers within a month or two, not 
> by end-users years or decades in the future, and 2) every UTC-aware device 
> would have an often tested direct or indirect path to IERS to know what the 
> sign of the leap second will be for the current month.
> 
> The leap second would then become a normal part of UTC, a regular monthly 
> event, instead of a rare, newsworthy exception. None of the weird bugs we 
> continue to see year after year in leap second handling by NTP and OS's and 
> GPS receiver firmware would occur.
> 
> Historical leap second tables would consist of little more than 12 bits per 
> year.
> 
> Moreover, in the next decade or two or three, if we slide into an era where 
> average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a 
> day, there will be zero impact if LSEM is already in place.
> 
> /tvb
> 
> ___
> LEAPSECS mailing list
> leaps...@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

___
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] 1 second timing error re leap second

[David J Taylor]

Hello,

Anyone know if the   M12T or Lea Bloc GPS chips have the same problem as the 
Trimble products


Regards

Martyn
=

Do you mean ublox LEA6T?  Ublox chips have generally been OK in the past, 
although I've not checked the LEA 6T.


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


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

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

[Jason Ball]

The watch is fine.  Ive intentionally set it to be off time to have it
automatically recover with essentially leap second precision.

On 21 Jul 2016 3:25 p.m., "Mike Cook"  wrote:

> 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.
>
___
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] 1 second timing error re leap second

[Mark Sims]

I saw no problems with Ublox Neo 6M,  LEA-5T,  LEA-6T,  Ublox 7,  or Ublox 8 
receivers.
A Synergy M12+ did not report the leap pending in the @@Bj message, but did in 
the @@Gj message.

-
Anyone know if the M12T or Lea Bloc GPS chips have the same problem as the 
Trimble products

  
___
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 bit bang serial all the time...  it is much easier if to do if you are only 
banging serial output.   Reading serial streams at higher bit rates while doing 
other useful stuff can be challenging... particularly if you don't have a timer 
handy.

 I once coded up a PIC to output a time code / status overlay on a video screen 
(bit banged video/hsync/vsync streams) while sending simultaneously sending 
serial data out another pin.  One's gotta love the PICs rigid 
clocks-per-instruction architecture when coding up things like that.  On 
another product (video capture -> JPEG -> serial stream)  I replaced over 30 
TTL IC's with a single PIC generating various timing and control pulses,  all 
lovingly and precisely bit banged.

Looking closer at the Jupiter-T message timing,  it's obvious that they have it 
timed and aligned down to the bit level (or better).

-
I agree this approach has limited appeal these days, but my point is that 
old-style bit-banging serial IO does have certain time nut advantages   

___
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

[Tom Holmes]

Hi Tom...

Does your proposal allow for a Zero leap second, or does it require either plus 
or minus 1 to work? Seems like you could stay closer to the true value if you 
also have a zero option. Might also cause less consternation for some services, 
like the finance and scientific worlds, that seem to have critical issues when 
an LS appears.

I like your point that by having it occur monthly it forces systems to address 
issues promptly, and maybe that's the argument for the non-zero option.

Tom Holmes, N8ZM


-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement 
Cc: Leap Second Discussion List 
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 
31 this year

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.

Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, not 
so much by rare steps but by dithering. There would be no change to UTC or 
timing infrastructure because the definition of UTC already allows for positive 
or negative leap seconds in any given month.

Every UTC-aware device would 1) know how to reliably insert or delete a leap 
second, because bugs would be found by developers within a month or two, not by 
end-users years or decades in the future, and 2) every UTC-aware device would 
have an often tested direct or indirect path to IERS to know what the sign of 
the leap second will be for the current month.

The leap second would then become a normal part of UTC, a regular monthly 
event, instead of a rare, newsworthy exception. None of the weird bugs we 
continue to see year after year in leap second handling by NTP and OS's and GPS 
receiver firmware would occur.

Historical leap second tables would consist of little more than 12 bits per 
year.

Moreover, in the next decade or two or three, if we slide into an era where 
average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a day, 
there will be zero impact if LSEM is already in place.

/tvb

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

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

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

[Bob Camp]

Hi

If you have a “zero option” then nothing ever gets tested. It always sits at 
zero and gets ignored. If you 
dither back and forth +/- 1 second, it’s tested every month. The faulty system 
that does not follow the
signal gets spotted and fixed.

Bob

> On Jul 21, 2016, at 3:03 PM, Tom Holmes  wrote:
> 
> Hi Tom...
> 
> Does your proposal allow for a Zero leap second, or does it require either 
> plus or minus 1 to work? Seems like you could stay closer to the true value 
> if you also have a zero option. Might also cause less consternation for some 
> services, like the finance and scientific worlds, that seem to have critical 
> issues when an LS appears.
> 
> I like your point that by having it occur monthly it forces systems to 
> address issues promptly, and maybe that's the argument for the non-zero 
> option.
> 
> Tom Holmes, N8ZM
> 
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak
> Sent: Thursday, July 21, 2016 1:28 PM
> To: Discussion of precise time and frequency measurement 
> Cc: Leap Second Discussion List 
> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC 
> December 31 this year
> 
> 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.
> 
> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, 
> not so much by rare steps but by dithering. There would be no change to UTC 
> or timing infrastructure because the definition of UTC already allows for 
> positive or negative leap seconds in any given month.
> 
> Every UTC-aware device would 1) know how to reliably insert or delete a leap 
> second, because bugs would be found by developers within a month or two, not 
> by end-users years or decades in the future, and 2) every UTC-aware device 
> would have an often tested direct or indirect path to IERS to know what the 
> sign of the leap second will be for the current month.
> 
> The leap second would then become a normal part of UTC, a regular monthly 
> event, instead of a rare, newsworthy exception. None of the weird bugs we 
> continue to see year after year in leap second handling by NTP and OS's and 
> GPS receiver firmware would occur.
> 
> Historical leap second tables would consist of little more than 12 bits per 
> year.
> 
> Moreover, in the next decade or two or three, if we slide into an era where 
> average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a 
> day, there will be zero impact if LSEM is already in place.
> 
> /tvb
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
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] LSEM (Leap Second Every Month)

[Brooke Clarke]

Hi Tom:

I like this idea.  I addresses the lesson from Y2K that something done often works much better than something done only 
occasionally.
That's way you see the firetruck at the local store, because it's used all the time and so is more likely to work when 
needed.


--
Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.

 Original Message 

Hi Tom...

Does your proposal allow for a Zero leap second, or does it require either plus 
or minus 1 to work? Seems like you could stay closer to the true value if you 
also have a zero option. Might also cause less consternation for some services, 
like the finance and scientific worlds, that seem to have critical issues when 
an LS appears.

I like your point that by having it occur monthly it forces systems to address 
issues promptly, and maybe that's the argument for the non-zero option.

Tom Holmes, N8ZM


-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement 
Cc: Leap Second Discussion List 
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 
31 this year

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.

Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, not 
so much by rare steps but by dithering. There would be no change to UTC or timing 
infrastructure because the definition of UTC already allows for positive or 
negative leap seconds in any given month.

Every UTC-aware device would 1) know how to reliably insert or delete a leap 
second, because bugs would be found by developers within a month or two, not by 
end-users years or decades in the future, and 2) every UTC-aware device would 
have an often tested direct or indirect path to IERS to know what the sign of 
the leap second will be for the current month.

The leap second would then become a normal part of UTC, a regular monthly 
event, instead of a rare, newsworthy exception. None of the weird bugs we 
continue to see year after year in leap second handling by NTP and OS's and GPS 
receiver firmware would occur.

Historical leap second tables would consist of little more than 12 bits per 
year.

Moreover, in the next decade or two or three, if we slide into an era where 
average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a day, 
there will be zero impact if LSEM is already in place.

/tvb

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

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



___
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

[Steve Allen]

On Thu 2016-07-21T10:27:57 -0700, Tom Van Baak hath writ:
> Time to mention this again...

> Every UTC-aware device would 1) know how to reliably insert or
> delete a leap second, because bugs would be found by developers within
> a month or two, not by end-users years or decades in the future, and
> 2) every UTC-aware device would have an often tested direct or
> indirect path to IERS to know what the sign of the leap second will be
> for the current month.

This idea pushes extra complexity into every implementation of low
level kernel-space software, firmware, and hardware.  That's nice as a
policy for full employment of programmers, but it's hard to justify by
any other metric.  Instead those low level places should be as simple
as possible, and that means making the underlying precision time
scale, and thus any broadcast distributions of a precision time scale,
as simple as possible.

The complexity for translating precision time in seconds (for
machines) to calendar time in days (for humans) belongs in the
less-critical and easier-testable outer layers of software which do
user-space presentation, internationalization, and GUI which can be
broadly shared between many hardware implementations.

--
Steve Allen  WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
___
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

[Adrian Godwin]

I was inclined to agree, cynically reasoning that many implementations
would argue that the leapseconds would average out in most applications and
they could ignore them.

But actually, it would be good for programmers to properly separate the
concepts of elapsed time and clock-time. If elapsed time were handled by
kernels and clock-time handled by a user-mode UTC or calendar process, that
would be a cleaner solution with overhead only where needed (or where the
OS is big enough for it to be a trivial element).


As a side issue, what would be the impact of having frequent
leap-milliseconds instead of infrequent leap-seconds ?

On Thu, Jul 21, 2016 at 8:53 PM, Steve Allen  wrote:

> On Thu 2016-07-21T10:27:57 -0700, Tom Van Baak hath writ:
> > Time to mention this again...
>
> > Every UTC-aware device would 1) know how to reliably insert or
> > delete a leap second, because bugs would be found by developers within
> > a month or two, not by end-users years or decades in the future, and
> > 2) every UTC-aware device would have an often tested direct or
> > indirect path to IERS to know what the sign of the leap second will be
> > for the current month.
>
> This idea pushes extra complexity into every implementation of low
> level kernel-space software, firmware, and hardware.  That's nice as a
> policy for full employment of programmers, but it's hard to justify by
> any other metric.  Instead those low level places should be as simple
> as possible, and that means making the underlying precision time
> scale, and thus any broadcast distributions of a precision time scale,
> as simple as possible.
>
> The complexity for translating precision time in seconds (for
> machines) to calendar time in days (for humans) belongs in the
> less-critical and easier-testable outer layers of software which do
> user-space presentation, internationalization, and GUI which can be
> broadly shared between many hardware implementations.
>
> --
> Steve Allen  WGS-84 (GPS)
> UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat
> +36.99855
> 1156 High Street   Voice: +1 831 459 3046 Lng
> -122.06015
> Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
> ___
> 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] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

[Tom Van Baak]

Steve Allen wrote:
> This idea pushes extra complexity into every implementation of low
> level kernel-space software, firmware, and hardware.  That's nice as a
> policy for full employment of programmers, but it's hard to justify by
> any other metric.  Instead those low level places should be as simple
> as possible, and that means making the underlying precision time
> scale, and thus any broadcast distributions of a precision time scale,
> as simple as possible.
> 
> The complexity for translating precision time in seconds (for
> machines) to calendar time in days (for humans) belongs in the
> less-critical and easier-testable outer layers of software which do
> user-space presentation, internationalization, and GUI which can be
> broadly shared between many hardware implementations.

Hi Steve,

Wow, that's most succinct two paragraph argument I've read for why we shouldn't 
have leap seconds at all. Where were you the past decade when this level of 
passion and clarity in the ITU debate was needed ;-)

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

Re: [time-nuts] LSEM (Leap Second Every Month)

[Jim Palfreyman]

The idea is the same as my local telco and their main exchanges.

Every month they walk up to the main circuit breaker and cut the power to
the entire building. All the UPSs and diesel generators get tested in anger.

This leap second solution is the best I've heard so far.

Personally I now hate leap seconds because it ruins many hours of my
observations at the radio telescope - but if this was implemented it would
force the software problems to be fixed.


Jim Palfreyman


On 22 July 2016 at 06:01, Brooke Clarke  wrote:

> Hi Tom:
>
> I like this idea.  I addresses the lesson from Y2K that something done
> often works much better than something done only occasionally.
> That's way you see the firetruck at the local store, because it's used all
> the time and so is more likely to work when needed.
>
> --
> Have Fun,
>
> Brooke Clarke
> http://www.PRC68.com
> http://www.end2partygovernment.com/2012Issues.html
> The lesser of evils is still evil.
>
>  Original Message 
>
>> Hi Tom...
>>
>> Does your proposal allow for a Zero leap second, or does it require
>> either plus or minus 1 to work? Seems like you could stay closer to the
>> true value if you also have a zero option. Might also cause less
>> consternation for some services, like the finance and scientific worlds,
>> that seem to have critical issues when an LS appears.
>>
>> I like your point that by having it occur monthly it forces systems to
>> address issues promptly, and maybe that's the argument for the non-zero
>> option.
>>
>> Tom Holmes, N8ZM
>>
>>
>> -Original Message-
>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van
>> Baak
>> Sent: Thursday, July 21, 2016 1:28 PM
>> To: Discussion of precise time and frequency measurement <
>> time-nuts@febo.com>
>> Cc: Leap Second Discussion List 
>> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
>> December 31 this year
>>
>> 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.
>>
>> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
>> UTC, not so much by rare steps but by dithering. There would be no change
>> to UTC or timing infrastructure because the definition of UTC already
>> allows for positive or negative leap seconds in any given month.
>>
>> Every UTC-aware device would 1) know how to reliably insert or delete a
>> leap second, because bugs would be found by developers within a month or
>> two, not by end-users years or decades in the future, and 2) every
>> UTC-aware device would have an often tested direct or indirect path to IERS
>> to know what the sign of the leap second will be for the current month.
>>
>> The leap second would then become a normal part of UTC, a regular monthly
>> event, instead of a rare, newsworthy exception. None of the weird bugs we
>> continue to see year after year in leap second handling by NTP and OS's and
>> GPS receiver firmware would occur.
>>
>> Historical leap second tables would consist of little more than 12 bits
>> per year.
>>
>> Moreover, in the next decade or two or three, if we slide into an era
>> where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
>> seconds a day, there will be zero impact if LSEM is already in place.
>>
>> /tvb
>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>>
> ___
> 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

[Tom Van Baak]

Hi Tom,

> Does your proposal allow for a Zero leap second

Nope, LSEM avoids the zero leap second situation. That's the idea: to always 
have a leap second. Either an add or a delete, at the end of every month. The 
beauty is that it wouldn't violate how UTC is already defined. Leap seconds 
would become a monthly normal instead of a rare event; that is, a regular pain 
in the ass instead of an exceptional pain in the ass [1].

Note that UTC would continue to stay within a second of UT1, so no problems 
there either. If you think about it, LSEM, like any fast dithering system, 
would actually create a better average value of UT1 than the existing slow step 
system. But that's not a goal; just a PWM side-effect.

There's more info in the original LSEM proposal and its long thread in the 
archives:

http://six.pairlist.net/pipermail/leapsecs/2010-November/001813.html


> Might also cause less consternation for some services, like the finance and
> scientific worlds, that seem to have critical issues when an LS appears.

add to your list: airplanes, high-speed trains, telesurgery, self-driving cars, 
MRI machines ...

Yes, and that's the key question. And it's only getting worse. LSEM is not a 
random idea or a quick fix. As long as UTC has leap seconds (debatable) or as 
long as technology continues to depend on ever more precise time (likely) we 
have to make the handling of leap seconds as robust as the handling of, say, 
midnight rollover.

I realize it's probably too late in history to deploy. There's no right answer. 
LSEM is food for thought. Lots of people are and have been trying to avoid the 
long-term train wreck that the current definition and implementation of UTC 
will lead to. If you have time, read 15 years of our postings over on the leap 
second mailing list.

I think at this point, we should move the thread over to LEAPSECS alone, and 
give time-nuts a break. The cross-posting is getting confusing.

Thanks,
/tvb

[1] astronomical society specification ;-)


- Original Message - 
From: "Tom Holmes" 
To: "'Discussion of precise time and frequency measurement'" 

Cc: "'Leap Second Discussion List'" 
Sent: Thursday, July 21, 2016 12:03 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnightUTC December 
31 this year


> Hi Tom...
> 
> Does your proposal allow for a Zero leap second, or does it require either 
> plus or minus 1 to work? Seems like you could stay closer to the true value 
> if you also have a zero option. Might also cause less consternation for some 
> services, like the finance and scientific worlds, that seem to have critical 
> issues when an LS appears.
> 
> I like your point that by having it occur monthly it forces systems to 
> address issues promptly, and maybe that's the argument for the non-zero 
> option.
> 
> Tom Holmes, N8ZM
> 
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak
> Sent: Thursday, July 21, 2016 1:28 PM
> To: Discussion of precise time and frequency measurement 
> Cc: Leap Second Discussion List 
> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC 
> December 31 this year
> 
> 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.
> 
> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, 
> not so much by rare steps but by dithering. There would be no change to UTC 
> or timing infrastructure because the definition of UTC already allows for 
> positive or negative leap seconds in any given month.
> 
> Every UTC-aware device would 1) know how to reliably insert or delete a leap 
> second, because bugs would be found by developers within a month or two, not 
> by end-users years or decades in the future, and 2) every UTC-aware device 
> would have an often tested direct or indirect path to IERS to know what the 
> sign of the leap second will be for the current month.
> 
> The leap second would then become a normal part of UTC, a regular monthly 
> event, instead of a rare, newsworthy exception. None of the weird bugs we 
> continue to see year after year in leap second handling by NTP and OS's and 
> GPS receiver firmware would occur.
> 
> Historical leap second tables would consist of little more than 12 bits per 
> year.
> 
> Moreover, in the next decade or two or three, if we slide into an era where 
> average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a 
> day, there will be zero impact if LSEM is already in place.
> 
> /tvb
> 

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

Re: [time-nuts] LSEM (Leap Second Every Month)

[Scott Stobbe]

If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

On Thursday, 21 July 2016, Brooke Clarke  wrote:

> Hi Tom:
>
> I like this idea.  I addresses the lesson from Y2K that something done
> often works much better than something done only occasionally.
> That's way you see the firetruck at the local store, because it's used all
> the time and so is more likely to work when needed.
>
> --
> Have Fun,
>
> Brooke Clarke
> http://www.PRC68.com
> http://www.end2partygovernment.com/2012Issues.html
> The lesser of evils is still evil.
>
>  Original Message 
>
>> Hi Tom...
>>
>> Does your proposal allow for a Zero leap second, or does it require
>> either plus or minus 1 to work? Seems like you could stay closer to the
>> true value if you also have a zero option. Might also cause less
>> consternation for some services, like the finance and scientific worlds,
>> that seem to have critical issues when an LS appears.
>>
>> I like your point that by having it occur monthly it forces systems to
>> address issues promptly, and maybe that's the argument for the non-zero
>> option.
>>
>> Tom Holmes, N8ZM
>>
>>
>> -Original Message-
>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van
>> Baak
>> Sent: Thursday, July 21, 2016 1:28 PM
>> To: Discussion of precise time and frequency measurement <
>> time-nuts@febo.com>
>> Cc: Leap Second Discussion List 
>> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
>> December 31 this year
>>
>> 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.
>>
>> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
>> UTC, not so much by rare steps but by dithering. There would be no change
>> to UTC or timing infrastructure because the definition of UTC already
>> allows for positive or negative leap seconds in any given month.
>>
>> Every UTC-aware device would 1) know how to reliably insert or delete a
>> leap second, because bugs would be found by developers within a month or
>> two, not by end-users years or decades in the future, and 2) every
>> UTC-aware device would have an often tested direct or indirect path to IERS
>> to know what the sign of the leap second will be for the current month.
>>
>> The leap second would then become a normal part of UTC, a regular monthly
>> event, instead of a rare, newsworthy exception. None of the weird bugs we
>> continue to see year after year in leap second handling by NTP and OS's and
>> GPS receiver firmware would occur.
>>
>> Historical leap second tables would consist of little more than 12 bits
>> per year.
>>
>> Moreover, in the next decade or two or three, if we slide into an era
>> where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
>> seconds a day, there will be zero impact if LSEM is already in place.
>>
>> /tvb
>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>>
> ___
> 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] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

[Jay Grizzard]

> This idea pushes extra complexity into every implementation of low
> level kernel-space software, firmware, and hardware.  That's nice as a
> policy for full employment of programmers, but it's hard to justify by
> any other metric.  Instead those low level places should be as simple
> as possible, and that means making the underlying precision time
> scale, and thus any broadcast distributions of a precision time scale,
> as simple as possible.

How does this make those things more complex, though? Those things are
already required to deal with both knowing about and adjusting the time
for leap seconds (both adding and removing, though adding is the only
direction that's ever been *tested*) ... increasing the frequency of the
announcements doesn't really add complexity there, except in places where
the code was already deficient (e.g. doesn't currently handle removing a
leap second, which is a bug).

If you wanted to do precise measurement of time between two dates, you'd
have to know about the number of leap seconds in between, but a) that's
easily done at a higher level than the kernel, and b) we already have to
do that to deal with existing leap seconds, just adding more datapoints to
the math doesn't actually make that more complex.

Am I missing something obvious where this would add complexity that isn't
already there?

-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] LSEM (Leap Second Every Month)

[Bob Stewart]

But would it really solve your problems, Jim?  The problem is essentially that 
periodically, there are two different clock times that represent the same 
moment in time.  For telescopes, stock markets, spread spectrum, time-based 
encryption, etc that's a big problem.  Would it not be better to separate out 
those entities that are more dependent on precision sequence than on clock time 
and accept that they are just going to be different?  Yeah, the talking heads 
on CNBC and Bloomberg would gravely announce that today's stock market was 
opening a second later, but so what?  At least there wouldn't be any more 
questions about exactly when transaction X occurred.

Bob
 -
AE6RV.com

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

  From: Jim Palfreyman 
 To: Discussion of precise time and frequency measurement  
 Sent: Thursday, July 21, 2016 4:38 PM
 Subject: Re: [time-nuts] LSEM (Leap Second Every Month)
   
The idea is the same as my local telco and their main exchanges.

Every month they walk up to the main circuit breaker and cut the power to
the entire building. All the UPSs and diesel generators get tested in anger.

This leap second solution is the best I've heard so far.

Personally I now hate leap seconds because it ruins many hours of my
observations at the radio telescope - but if this was implemented it would
force the software problems to be fixed.


Jim Palfreyman


On 22 July 2016 at 06:01, Brooke Clarke  wrote:

> Hi Tom:
>
> I like this idea.  I addresses the lesson from Y2K that something done
> often works much better than something done only occasionally.
> That's way you see the firetruck at the local store, because it's used all
> the time and so is more likely to work when needed.
>
> --
> Have Fun,
>
> Brooke Clarke
> http://www.PRC68.com
> http://www.end2partygovernment.com/2012Issues.html
> The lesser of evils is still evil.
>
>  Original Message 
>
>> Hi Tom...
>>
>> Does your proposal allow for a Zero leap second, or does it require
>> either plus or minus 1 to work? Seems like you could stay closer to the
>> true value if you also have a zero option. Might also cause less
>> consternation for some services, like the finance and scientific worlds,
>> that seem to have critical issues when an LS appears.
>>
>> I like your point that by having it occur monthly it forces systems to
>> address issues promptly, and maybe that's the argument for the non-zero
>> option.
>>
>> Tom Holmes, N8ZM
>>
>>
>> -Original Message-
>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van
>> Baak
>> Sent: Thursday, July 21, 2016 1:28 PM
>> To: Discussion of precise time and frequency measurement <
>> time-nuts@febo.com>
>> Cc: Leap Second Discussion List 
>> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
>> December 31 this year
>>
>> 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.
>>
>> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
>> UTC, not so much by rare steps but by dithering. There would be no change
>> to UTC or timing infrastructure because the definition of UTC already
>> allows for positive or negative leap seconds in any given month.
>>
>> Every UTC-aware device would 1) know how to reliably insert or delete a
>> leap second, because bugs would be found by developers within a month or
>> two, not by end-users years or decades in the future, and 2) every
>> UTC-aware device would have an often tested direct or indirect path to IERS
>> to know what the sign of the leap second will be for the current month.
>>
>> The leap second would then become a normal part of UTC, a regular monthly
>> event, instead of a rare, newsworthy exception. None of the weird bugs we
>> continue to see year after year in leap second handling by NTP and OS's and
>> GPS receiver firmware would occur.
>>
>> Historical leap second tables would consist of little more than 12 bits
>> per year.
>>
>> Moreover, in the next decade or two or three, if we slide into an era
>> where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
>> seconds a day, there will be zero impact if LSEM is already in place.
>>
>> /tvb
>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>>
> ___

Re: [time-nuts] NCOCXO anyone?

[Tom Van Baak]

Hi Nick,

There may be several threads in the time-nuts archives related to your 
question. The greater concept is a phase microstepper (aka microphase stepper). 
Imagine a small board that takes =10 MHz in and puts ~10 MHz out. Using RS232 
(or SPI or I2C) you control the phase, or even the phase over time, which is to 
say, the frequency offset. Maybe do it with analog (EFC). Maybe do it with 
digital (DDS).

There are highly-prized commercial instruments that do this. But no amateur has 
tried yet. You should be the first. If you think about what we do with steering 
oscillators -- for GPSDO, or for dual-mixers, or for home time scales, or even 
sidereal or mars time -- having a device that cleanly steers phase and 
frequency with simple RS232 would be very useful. For example, it would allow 
anyone to steer a Rb or Cs standard, even though many of these lab instruments 
do not have analog EFC or digital tuning options.

The possibility of this at the amateur level occurred to me when I played with 
Bert's 9913:

http://leapsecond.com/pages/ad9913/

Read especially about the "programmable modulus mode" which can be used to 
avoid truncation errors and achieve perfect long-term phase; kind of like the 
difference between PLL and FLL in a GPSDO's 1PPS.

Look also at how the amazing FE-405 oscillator works:

http://leapsecond.com/pages/fe405/

And the idea of [mis]using a DDS as a high-resolution phase measurement 
technique was confirmed with the PicoPak project:

http://www.wriley.com/PicoPak%20App%20Notes%20Links.htm

So, yes, please take the bait and play with all aspects of your NCOCXO idea.

/tvb

- Original Message - 
From: "Nick Sayer via time-nuts" 
To: "Chris Arnold via time-nuts" 
Sent: Thursday, July 21, 2016 10:05 AM
Subject: [time-nuts] NCOCXO anyone?


> Would anyone see any value in a board that had an OH300 with a serial 
> interface for tuning?
> 
> I had a thought perhaps to make one starting with my GPSDO and just ditching 
> the GPS part and possibly adding an RS-232 level converter.  I could 
> conceivably bring it all out to a DB9 and emulate an FE-5680 (obviously it's 
> long term stability would be poorer without some discipline) or just make my 
> own protocol up. 
> 
> Sent from my iPhone

___
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

[Oz-in-DFW]

On 7/21/2016 2:53 PM, Steve Allen wrote:
> On Thu 2016-07-21T10:27:57 -0700, Tom Van Baak hath writ:
>> Time to mention this again...
>> Every UTC-aware device would 1) know how to reliably insert or
>> delete a leap second, because bugs would be found by developers within
>> a month or two, not by end-users years or decades in the future, and
>> 2) every UTC-aware device would have an often tested direct or
>> indirect path to IERS to know what the sign of the leap second will be
>> for the current month.
> This idea pushes extra complexity into every implementation of low
> level kernel-space software, firmware, and hardware.  
Why?  That would only seem to be true if the leap second decision is
already made there.  Most systems I'm aware do this in presentation
level firmware.
> That's nice as a
> policy for full employment of programmers, but it's hard to justify by
> any other metric.  Instead those low level places should be as simple
> as possible, and that means making the underlying precision time
> scale, and thus any broadcast distributions of a precision time scale,
> as simple as possible.
I think I understand what you are saying, but I'm pretty sure I
disagree.  The vast majority of complexity (and risk) of most software
and testing comes from exceptions and making sure all combinations are
tested. In this case the exception is simplified.  You still need to
detect end of month, but you have regular logic to implement. As a
practical matter this should be easier to code as a fixed time of
execution operation.
> The complexity for translating precision time in seconds (for
> machines) to calendar time in days (for humans) belongs in the
> less-critical and easier-testable outer layers of software which do
> user-space presentation, internationalization, and GUI which can be
> broadly shared between many hardware implementations.
I agree for the most part.  Complexity should be driven as high in the
layer stack as practical.  What about this proposal requires changes
from the place it is already done in a particular system? 

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

Re: [time-nuts] LSEM (Leap Second Every Month)

[Tom Van Baak]

> If UTC time was adjusted every month would stick with one full second? Or
> some smaller quantity?

Hi Scott,

The LSEM month suggestion retains the UTC policy of leaps being exactly +1 or 
-1 second, never larger, never smaller.

There's a world of hurt if anyone even dreamed of shifting UTC by a fraction of 
a second. In fact, one of the main reasons UTC was created in the 70's was to 
put an end to the dreaded fractional jumps in atomic timekeeping during that 
era. Fractional steps atomic frequency and fractional steps in atomic time were 
both tried during 60's. For example:

http://www.leapsecond.com/history/wwvb1966.htm

Eliminating frequency jumps completely (by defining the UTC second to be 
9,192,631,770 Hz cesium), and
changing any steps to be full +1 or -1 second integers (and not fractions) was 
why UTC was created.

/tvb

- Original Message - 
From: "Scott Stobbe" 
To: "Discussion of precise time and frequency measurement" 
Sent: Thursday, July 21, 2016 3:06 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)


> If UTC time was adjusted every month would stick with one full second? Or
> some smaller quantity?
> 
> On Thursday, 21 July 2016, Brooke Clarke  wrote:
> 
>> Hi Tom:
>>
>> I like this idea.  I addresses the lesson from Y2K that something done
>> often works much better than something done only occasionally.
>> That's way you see the firetruck at the local store, because it's used all
>> the time and so is more likely to work when needed.
>>
>> --
>> Have Fun,
>>
>> Brooke Clarke
>> http://www.PRC68.com
>> http://www.end2partygovernment.com/2012Issues.html
>> The lesser of evils is still evil.
>>
>>  Original Message 
>>
>>> Hi Tom...
>>>
>>> Does your proposal allow for a Zero leap second, or does it require
>>> either plus or minus 1 to work? Seems like you could stay closer to the
>>> true value if you also have a zero option. Might also cause less
>>> consternation for some services, like the finance and scientific worlds,
>>> that seem to have critical issues when an LS appears.
>>>
>>> I like your point that by having it occur monthly it forces systems to
>>> address issues promptly, and maybe that's the argument for the non-zero
>>> option.
>>>
>>> Tom Holmes, N8ZM
>>>
>>>
>>> -Original Message-
>>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van
>>> Baak
>>> Sent: Thursday, July 21, 2016 1:28 PM
>>> To: Discussion of precise time and frequency measurement <
>>> time-nuts@febo.com>
>>> Cc: Leap Second Discussion List 
>>> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
>>> December 31 this year
>>>
>>> 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.
>>>
>>> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
>>> UTC, not so much by rare steps but by dithering. There would be no change
>>> to UTC or timing infrastructure because the definition of UTC already
>>> allows for positive or negative leap seconds in any given month.
>>>
>>> Every UTC-aware device would 1) know how to reliably insert or delete a
>>> leap second, because bugs would be found by developers within a month or
>>> two, not by end-users years or decades in the future, and 2) every
>>> UTC-aware device would have an often tested direct or indirect path to IERS
>>> to know what the sign of the leap second will be for the current month.
>>>
>>> The leap second would then become a normal part of UTC, a regular monthly
>>> event, instead of a rare, newsworthy exception. None of the weird bugs we
>>> continue to see year after year in leap second handling by NTP and OS's and
>>> GPS receiver firmware would occur.
>>>
>>> Historical leap second tables would consist of little more than 12 bits
>>> per year.
>>>
>>> Moreover, in the next decade or two or three, if we slide into an era
>>> where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
>>> seconds a day, there will be zero impact if LSEM is already in place.
>>>
>>> /tvb
>>>
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>>
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>>
>>>
>> ___
>> 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] NCOCXO anyone?

[Poul-Henning Kamp]

In message <4763643485B04450A76F7C04BA8CFB63@pc52>, "Tom Van Baak" writes:

>There are highly-prized commercial instruments that do this. But
>no amateur has tried yet.

It would be more precise to say that no amateur has been willing to
talk about their results yet.

I personally know several have tried and failed at various levels
of performance.

My own personal experience, both analog and VHDL, is that there is
a particularly long and noisy way from theory to practice in this
space.

The one thing I have *not* tried, and the only one I think has any
realistic chances, is to use a DDS chip which has a phase modulation
register.

That should get you to a nanosecond without too much trouble.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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] LSEM (Leap Second Every Month)

[Michael Wouters]

Apropos Bob's comments, the problem of ambiguous timestamps during a
leap second, at least with current operating systems, is only made
worse by more frequent leap seconds.

Making critical systems run on a leap second free time scale like TAI,
for example, just shifts the problem to the interface between those
systems and the rest of the world. Admittedly, this interface may be
more tolerant of discrepancies.

Leap seconds have gotta go.

Cheers
Michael


On Fri, Jul 22, 2016 at 8:13 AM, Bob Stewart  wrote:
> But would it really solve your problems, Jim?  The problem is essentially 
> that periodically, there are two different clock times that represent the 
> same moment in time.  For telescopes, stock markets, spread spectrum, 
> time-based encryption, etc that's a big problem.  Would it not be better to 
> separate out those entities that are more dependent on precision sequence 
> than on clock time and accept that they are just going to be different?  
> Yeah, the talking heads on CNBC and Bloomberg would gravely announce that 
> today's stock market was opening a second later, but so what?  At least there 
> wouldn't be any more questions about exactly when transaction X occurred.
>
> Bob
>  -
> AE6RV.com
>
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>
>   From: Jim Palfreyman 
>  To: Discussion of precise time and frequency measurement 
>  Sent: Thursday, July 21, 2016 4:38 PM
>  Subject: Re: [time-nuts] LSEM (Leap Second Every Month)
>
> The idea is the same as my local telco and their main exchanges.
>
> Every month they walk up to the main circuit breaker and cut the power to
> the entire building. All the UPSs and diesel generators get tested in anger.
>
> This leap second solution is the best I've heard so far.
>
> Personally I now hate leap seconds because it ruins many hours of my
> observations at the radio telescope - but if this was implemented it would
> force the software problems to be fixed.
>
>
> Jim Palfreyman
>
>
> On 22 July 2016 at 06:01, Brooke Clarke  wrote:
>
>> Hi Tom:
>>
>> I like this idea.  I addresses the lesson from Y2K that something done
>> often works much better than something done only occasionally.
>> That's way you see the firetruck at the local store, because it's used all
>> the time and so is more likely to work when needed.
>>
>> --
>> Have Fun,
>>
>> Brooke Clarke
>> http://www.PRC68.com
>> http://www.end2partygovernment.com/2012Issues.html
>> The lesser of evils is still evil.
>>
>>  Original Message 
>>
>>> Hi Tom...
>>>
>>> Does your proposal allow for a Zero leap second, or does it require
>>> either plus or minus 1 to work? Seems like you could stay closer to the
>>> true value if you also have a zero option. Might also cause less
>>> consternation for some services, like the finance and scientific worlds,
>>> that seem to have critical issues when an LS appears.
>>>
>>> I like your point that by having it occur monthly it forces systems to
>>> address issues promptly, and maybe that's the argument for the non-zero
>>> option.
>>>
>>> Tom Holmes, N8ZM
>>>
>>>
>>> -Original Message-
>>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van
>>> Baak
>>> Sent: Thursday, July 21, 2016 1:28 PM
>>> To: Discussion of precise time and frequency measurement <
>>> time-nuts@febo.com>
>>> Cc: Leap Second Discussion List 
>>> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
>>> December 31 this year
>>>
>>> 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.
>>>
>>> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
>>> UTC, not so much by rare steps but by dithering. There would be no change
>>> to UTC or timing infrastructure because the definition of UTC already
>>> allows for positive or negative leap seconds in any given month.
>>>
>>> Every UTC-aware device would 1) know how to reliably insert or delete a
>>> leap second, because bugs would be found by developers within a month or
>>> two, not by end-users years or decades in the future, and 2) every
>>> UTC-aware device would have an often tested direct or indirect path to IERS
>>> to know what the sign of the leap second will be for the current month.
>>>
>>> The leap second would then become a normal part of UTC, a regular monthly
>>> event, instead of a rare, newsworthy exception. None of the weird bugs we
>>> continue to see year after year in leap second handling by NTP and OS's and
>>> GPS receiver firmware would occur.
>>>
>>> Historical leap second tables would consist of little more than 12 bits
>>> per year.
>>>
>>> Moreover, in the next decade or two or th

Re: [time-nuts] LSEM (Leap Second Every Month)

[Bob Camp]

Hi

A leap millisecond …. there’s an idea to explain to grandma. If you accept the 
idea that 
we need a leap second ever year or three, it’s not going to be a millisecond. 
Something 
messy would be required if you went below 100 ms. 100 ms would (barely) 
accommodate 
a “once a year” leap second. If it was a 0.1 sec event, you would not get the 
nice “back and forth” 
process for debugging and testing systems quite as often. 

Bob

> On Jul 21, 2016, at 6:06 PM, Scott Stobbe  wrote:
> 
> If UTC time was adjusted every month would stick with one full second? Or
> some smaller quantity?
> 
> On Thursday, 21 July 2016, Brooke Clarke  wrote:
> 
>> Hi Tom:
>> 
>> I like this idea.  I addresses the lesson from Y2K that something done
>> often works much better than something done only occasionally.
>> That's way you see the firetruck at the local store, because it's used all
>> the time and so is more likely to work when needed.
>> 
>> --
>> Have Fun,
>> 
>> Brooke Clarke
>> http://www.PRC68.com
>> http://www.end2partygovernment.com/2012Issues.html
>> The lesser of evils is still evil.
>> 
>>  Original Message 
>> 
>>> Hi Tom...
>>> 
>>> Does your proposal allow for a Zero leap second, or does it require
>>> either plus or minus 1 to work? Seems like you could stay closer to the
>>> true value if you also have a zero option. Might also cause less
>>> consternation for some services, like the finance and scientific worlds,
>>> that seem to have critical issues when an LS appears.
>>> 
>>> I like your point that by having it occur monthly it forces systems to
>>> address issues promptly, and maybe that's the argument for the non-zero
>>> option.
>>> 
>>> Tom Holmes, N8ZM
>>> 
>>> 
>>> -Original Message-
>>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van
>>> Baak
>>> Sent: Thursday, July 21, 2016 1:28 PM
>>> To: Discussion of precise time and frequency measurement <
>>> time-nuts@febo.com>
>>> Cc: Leap Second Discussion List 
>>> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
>>> December 31 this year
>>> 
>>> 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.
>>> 
>>> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
>>> UTC, not so much by rare steps but by dithering. There would be no change
>>> to UTC or timing infrastructure because the definition of UTC already
>>> allows for positive or negative leap seconds in any given month.
>>> 
>>> Every UTC-aware device would 1) know how to reliably insert or delete a
>>> leap second, because bugs would be found by developers within a month or
>>> two, not by end-users years or decades in the future, and 2) every
>>> UTC-aware device would have an often tested direct or indirect path to IERS
>>> to know what the sign of the leap second will be for the current month.
>>> 
>>> The leap second would then become a normal part of UTC, a regular monthly
>>> event, instead of a rare, newsworthy exception. None of the weird bugs we
>>> continue to see year after year in leap second handling by NTP and OS's and
>>> GPS receiver firmware would occur.
>>> 
>>> Historical leap second tables would consist of little more than 12 bits
>>> per year.
>>> 
>>> Moreover, in the next decade or two or three, if we slide into an era
>>> where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
>>> seconds a day, there will be zero impact if LSEM is already in place.
>>> 
>>> /tvb
>>> 
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>> 
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>> 
>>> 
>> ___
>> 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] GPS message jitter (preliminary results)

[Chris Albertson]

Yes, I know about those.  I think the ubloc line has a version that
does this but it is made for the automotive roadmap type display.

I think the way to learn is to jump in and make one.  Start by
re-implementing an example filter then go the next step and the next.

On Thu, Jul 21, 2016 at 7:34 AM, Mark Sims  wrote:
> A lot of the newer GPS modules can accept "dead reckoning"  data from 
> external sensors and integrate that into their location solutions.  The 
> receiver does all the Kalman filtering foo for you.  Also you can get 
> receivers with up to 50Hz position updates (you have to run the com link at 
> very high speeds to accommodate all the data that they send).   This well 
> help minimize the "staleness" of the GPS fix versus true position.
>
> Also you can now get affordable real-time kinematic receivers that will give 
> you your location relative to another receiver with centimeter accuracy.
>
> -
>
>> 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
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



-- 

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

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

[Gregory Maxwell]

On Thu, Jul 21, 2016 at 5:27 PM, 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.

I think dithered leapsecond would be a massive improvement over what
we have now, I'd even pay for travel to send someone to advocate it at
whatever relevant standards meeting was needed.

But I still think it is inferior to no leapseconds at all (and
adjusting timezones after the several thousand years required to make
that needed).  The reason I hold this is three fold:

(1) The complexity to deal with leapseconds remains in LSEM. It won't
be as much of a constant source of failure but correct handling is a
real cost that goes into the engineering millions of
products/projects. Some of the current practical methods of handling
leap seconds (like shutting off/rebooting critical systems or
discarding data) would also be less reasonable with LSEM. They might
be less needed with LSEM but I cannot say that they would be
completely unneeded*.

(2) I'm not aware of any application that cares greatly about the
precise alignment with the _mean_ solar day that doesn't need to go on
and apply location specific corrections.  Those applications could
easily apply the UTC to mean solar adjustment along with their
location specific adjustment.

(3) Obtaining the leap second sign requires a trusted data source.
When UTC has leap seconds a happily ticking atomic clock cannot keep
second level alignment with UTC without some trusted source of data.
Existing mechanisms for distributing leap second information have
communicated false information in several well known events in the
past, and these were accidents not malicious cases. LSEM would improve
this somewhat, since there would always be an update you just need to
learn the sign, so communications failures could be detected and
alarmed. But the need for this trusted input still creates a security
vulnerability window that could be avoided. Systems where their
security/integrity depend on time sync, could be pushed 24 seconds out
of sync in one year by an attacker that can control their leap
observations-- creating error greater than their free running
oscillators might have absent any sync at all.  This is especially
acute in that in a decade or two we might have 1PPB solid state
optical clock chips which are inexpensive and allow for "set once and
run forever without sync" operation for a great many applications --
getting potentially 0.5 ppm of error added on top from the lack of
leap seconds would basically limit the civil time performance of
unsynchronized clocks what you can get from a TCXO bought off mouser
for a couple bucks today.

So: It's my experience that the current handling of leap seconds is a
slow motion disaster. LSEM would be a big improvement-- reducing the
costs to the "intended costs" by eliminating many of the extra costs
created by inadequate testing. But it would not eliminate the base
cost of continuing to have our civil time perturbed by leap seconds to
begin with-- costs that are only increasing as atomic oscillators come
down in price and applications with tight synchronization requirements
become more common.


(*) once a month is not adequate testing to ensure freeness of fringe
race conditions. Meaning that at a minimum large scale life or large
value handling systems that might be impacted would still get the
reboot treatment in LSEM, but now with disruption every month.
___
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] NCOCXO anyone?

[Bob Camp]

Hi


> On Jul 21, 2016, at 7:17 PM, Poul-Henning Kamp  wrote:
> 
> 
> In message <4763643485B04450A76F7C04BA8CFB63@pc52>, "Tom Van Baak" writes:
> 
>> There are highly-prized commercial instruments that do this. But
>> no amateur has tried yet.
> 
> It would be more precise to say that no amateur has been willing to
> talk about their results yet.
> 
> I personally know several have tried and failed at various levels
> of performance.
> 
> My own personal experience, both analog and VHDL, is that there is
> a particularly long and noisy way from theory to practice in this
> space.
> 
> The one thing I have *not* tried, and the only one I think has any
> realistic chances, is to use a DDS chip which has a phase modulation
> register.

If you go the DDS route, it really needs a post filter to make it “fly right”. 
The narrower the
filter, the better it gets. Pretty quickly you are into an ovenized filter.  Is 
that better or worse
than an ovenized phase modulator? Not at all clear.

Bob

> 
> That should get you to a nanosecond without too much trouble.
> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> 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] NCOCXO anyone?

[Nick Sayer via time-nuts]

Oh my. That’s a bit more than I was originally considering… What I had in mind 
was adding a DAC front end to an OCXO so that you could tune the EFC with 
serial commands rather than analog and calling that a product.

A simple version of what you seem to be describing, however, *sounds* to me 
something like this:

The microcontroller has the same phase discriminator system the GPSDO has, 
except that instead of the reference signal coming from a PPS, it comes from an 
input reference. The microcontroller can get a phase difference reading between 
the oscillator output and the reference and in software can tune the oscillator 
DAC output to arrange for a certain rate-of-change, adjustable via serial 
commands.

Does that sound about right?

Perhaps a more traditional PLL approach - using the 4046 PC2 output with an RC 
and simply allowing the controller to sample that makes some sense (calibrating 
it may be painful). I’ll have to do some more thinking about it. :)

> On Jul 21, 2016, at 3:39 PM, Tom Van Baak  wrote:
> 
> Hi Nick,
> 
> There may be several threads in the time-nuts archives related to your 
> question. The greater concept is a phase microstepper (aka microphase 
> stepper). Imagine a small board that takes =10 MHz in and puts ~10 MHz out. 
> Using RS232 (or SPI or I2C) you control the phase, or even the phase over 
> time, which is to say, the frequency offset. Maybe do it with analog (EFC). 
> Maybe do it with digital (DDS).
> 
> There are highly-prized commercial instruments that do this. But no amateur 
> has tried yet. You should be the first. If you think about what we do with 
> steering oscillators -- for GPSDO, or for dual-mixers, or for home time 
> scales, or even sidereal or mars time -- having a device that cleanly steers 
> phase and frequency with simple RS232 would be very useful. For example, it 
> would allow anyone to steer a Rb or Cs standard, even though many of these 
> lab instruments do not have analog EFC or digital tuning options.
> 
> The possibility of this at the amateur level occurred to me when I played 
> with Bert's 9913:
> 
> http://leapsecond.com/pages/ad9913/
> 
> Read especially about the "programmable modulus mode" which can be used to 
> avoid truncation errors and achieve perfect long-term phase; kind of like the 
> difference between PLL and FLL in a GPSDO's 1PPS.
> 
> Look also at how the amazing FE-405 oscillator works:
> 
> http://leapsecond.com/pages/fe405/
> 
> And the idea of [mis]using a DDS as a high-resolution phase measurement 
> technique was confirmed with the PicoPak project:
> 
> http://www.wriley.com/PicoPak%20App%20Notes%20Links.htm
> 
> So, yes, please take the bait and play with all aspects of your NCOCXO idea.
> 
> /tvb
> 
> - Original Message - 
> From: "Nick Sayer via time-nuts" 
> To: "Chris Arnold via time-nuts" 
> Sent: Thursday, July 21, 2016 10:05 AM
> Subject: [time-nuts] NCOCXO anyone?
> 
> 
>> Would anyone see any value in a board that had an OH300 with a serial 
>> interface for tuning?
>> 
>> I had a thought perhaps to make one starting with my GPSDO and just ditching 
>> the GPS part and possibly adding an RS-232 level converter.  I could 
>> conceivably bring it all out to a DB9 and emulate an FE-5680 (obviously it's 
>> long term stability would be poorer without some discipline) or just make my 
>> own protocol up. 
>> 
>> Sent from my iPhone
> 
> ___
> 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] NCOCXO anyone?

[Bob Camp]

Hi

Ideally a phase micro stepper would have an ADEV floor that is lower than 
anything you would run through it. 
That way the ADEV in would be the same as the ADEV out. Since there are things 
out there that are lower
ADEV than an OCXO, that’s not a good thing to put in the middle of the beast. 

Bob


> On Jul 21, 2016, at 7:56 PM, Nick Sayer via time-nuts  
> wrote:
> 
> Oh my. That’s a bit more than I was originally considering… What I had in 
> mind was adding a DAC front end to an OCXO so that you could tune the EFC 
> with serial commands rather than analog and calling that a product.
> 
> A simple version of what you seem to be describing, however, *sounds* to me 
> something like this:
> 
> The microcontroller has the same phase discriminator system the GPSDO has, 
> except that instead of the reference signal coming from a PPS, it comes from 
> an input reference. The microcontroller can get a phase difference reading 
> between the oscillator output and the reference and in software can tune the 
> oscillator DAC output to arrange for a certain rate-of-change, adjustable via 
> serial commands.
> 
> Does that sound about right?
> 
> Perhaps a more traditional PLL approach - using the 4046 PC2 output with an 
> RC and simply allowing the controller to sample that makes some sense 
> (calibrating it may be painful). I’ll have to do some more thinking about it. 
> :)
> 
>> On Jul 21, 2016, at 3:39 PM, Tom Van Baak  wrote:
>> 
>> Hi Nick,
>> 
>> There may be several threads in the time-nuts archives related to your 
>> question. The greater concept is a phase microstepper (aka microphase 
>> stepper). Imagine a small board that takes =10 MHz in and puts ~10 MHz out. 
>> Using RS232 (or SPI or I2C) you control the phase, or even the phase over 
>> time, which is to say, the frequency offset. Maybe do it with analog (EFC). 
>> Maybe do it with digital (DDS).
>> 
>> There are highly-prized commercial instruments that do this. But no amateur 
>> has tried yet. You should be the first. If you think about what we do with 
>> steering oscillators -- for GPSDO, or for dual-mixers, or for home time 
>> scales, or even sidereal or mars time -- having a device that cleanly steers 
>> phase and frequency with simple RS232 would be very useful. For example, it 
>> would allow anyone to steer a Rb or Cs standard, even though many of these 
>> lab instruments do not have analog EFC or digital tuning options.
>> 
>> The possibility of this at the amateur level occurred to me when I played 
>> with Bert's 9913:
>> 
>> http://leapsecond.com/pages/ad9913/
>> 
>> Read especially about the "programmable modulus mode" which can be used to 
>> avoid truncation errors and achieve perfect long-term phase; kind of like 
>> the difference between PLL and FLL in a GPSDO's 1PPS.
>> 
>> Look also at how the amazing FE-405 oscillator works:
>> 
>> http://leapsecond.com/pages/fe405/
>> 
>> And the idea of [mis]using a DDS as a high-resolution phase measurement 
>> technique was confirmed with the PicoPak project:
>> 
>> http://www.wriley.com/PicoPak%20App%20Notes%20Links.htm
>> 
>> So, yes, please take the bait and play with all aspects of your NCOCXO idea.
>> 
>> /tvb
>> 
>> - Original Message - 
>> From: "Nick Sayer via time-nuts" 
>> To: "Chris Arnold via time-nuts" 
>> Sent: Thursday, July 21, 2016 10:05 AM
>> Subject: [time-nuts] NCOCXO anyone?
>> 
>> 
>>> Would anyone see any value in a board that had an OH300 with a serial 
>>> interface for tuning?
>>> 
>>> I had a thought perhaps to make one starting with my GPSDO and just 
>>> ditching the GPS part and possibly adding an RS-232 level converter.  I 
>>> could conceivably bring it all out to a DB9 and emulate an FE-5680 
>>> (obviously it's long term stability would be poorer without some 
>>> discipline) or just make my own protocol up. 
>>> 
>>> Sent from my iPhone
>> 
>> ___
>> 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] NCOCXO anyone?

[Richard (Rick) Karlquist]

On 7/21/2016 4:56 PM, Nick Sayer via time-nuts wrote:

Oh my. That’s a bit more than I was originally considering… What I had in mind 
was adding a DAC front end to an OCXO so that you could tune the EFC with 
serial commands rather than analog and calling that a product.



20 years ago when HP was working on a so called "smart clock"
GPS box, they decided to do what you said, use a DAC to
tune the EFC on the E1938A oscillator.  I
recommended to them NOT to try to do that, but they
didn't listen to me.  At that time, it
was nearly impossible to come up with a DAC, buffer
amplifier, and voltage reference that didn't degrade
the stability of the E1938A, which isn't even as stable
as a 10811.  What you need to ask yourself is:  in
2016, can I finally get analog components that are
an order of magnitude or two better than what was
available in 1996?  I don't know, without researching
it.  Certainly, we can't depend on Moore's law coming
to the rescue.  If anything, that works against analog
IC's by obsoleting older analog processes.

Also in 1996, phase microsteppers were already legacy
technology and didn't have a good reputation for spectral
purity.  Another non-panacea.

Rick
___
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] LSEM (Leap Second Every Month)

[Michael Rothwell]

On Thursday, July 21, 2016, Michael Wouters 
wrote:

> Apropos Bob's comments, the problem of ambiguous timestamps during a
> leap second, at least with current operating systems, is only made
> worse by more frequent leap seconds.
>
> Making critical systems run on a leap second free time scale like TAI,
> for example, just shifts the problem to the interface between those
> systems and the rest of the world. Admittedly, this interface may be
> more tolerant of discrepancies.
>
> Leap seconds have gotta go.


No leap seconds seems preferable to more frequent leap  seconds.


>
> Cheers
> Michael
>
>
> On Fri, Jul 22, 2016 at 8:13 AM, Bob Stewart  > wrote:
> > But would it really solve your problems, Jim?  The problem is
> essentially that periodically, there are two different clock times that
> represent the same moment in time.  For telescopes, stock markets, spread
> spectrum, time-based encryption, etc that's a big problem.  Would it not be
> better to separate out those entities that are more dependent on precision
> sequence than on clock time and accept that they are just going to be
> different?  Yeah, the talking heads on CNBC and Bloomberg would gravely
> announce that today's stock market was opening a second later, but so
> what?  At least there wouldn't be any more questions about exactly when
> transaction X occurred.
> >
> > Bob
> >  -
> > AE6RV.com
> >
> > GFS GPSDO list:
> > groups.yahoo.com/neo/groups/GFS-GPSDOs/info
> >
> >   From: Jim Palfreyman >
> >  To: Discussion of precise time and frequency measurement <
> time-nuts@febo.com >
> >  Sent: Thursday, July 21, 2016 4:38 PM
> >  Subject: Re: [time-nuts] LSEM (Leap Second Every Month)
> >
> > The idea is the same as my local telco and their main exchanges.
> >
> > Every month they walk up to the main circuit breaker and cut the power to
> > the entire building. All the UPSs and diesel generators get tested in
> anger.
> >
> > This leap second solution is the best I've heard so far.
> >
> > Personally I now hate leap seconds because it ruins many hours of my
> > observations at the radio telescope - but if this was implemented it
> would
> > force the software problems to be fixed.
> >
> >
> > Jim Palfreyman
> >
> >
> > On 22 July 2016 at 06:01, Brooke Clarke  > wrote:
> >
> >> Hi Tom:
> >>
> >> I like this idea.  I addresses the lesson from Y2K that something done
> >> often works much better than something done only occasionally.
> >> That's way you see the firetruck at the local store, because it's used
> all
> >> the time and so is more likely to work when needed.
> >>
> >> --
> >> Have Fun,
> >>
> >> Brooke Clarke
> >> http://www.PRC68.com
> >> http://www.end2partygovernment.com/2012Issues.html
> >> The lesser of evils is still evil.
> >>
> >>  Original Message 
> >>
> >>> Hi Tom...
> >>>
> >>> Does your proposal allow for a Zero leap second, or does it require
> >>> either plus or minus 1 to work? Seems like you could stay closer to the
> >>> true value if you also have a zero option. Might also cause less
> >>> consternation for some services, like the finance and scientific
> worlds,
> >>> that seem to have critical issues when an LS appears.
> >>>
> >>> I like your point that by having it occur monthly it forces systems to
> >>> address issues promptly, and maybe that's the argument for the non-zero
> >>> option.
> >>>
> >>> Tom Holmes, N8ZM
> >>>
> >>>
> >>> -Original Message-
> >>> From: time-nuts [mailto:time-nuts-boun...@febo.com ] On
> Behalf Of Tom Van
> >>> Baak
> >>> Sent: Thursday, July 21, 2016 1:28 PM
> >>> To: Discussion of precise time and frequency measurement <
> >>> time-nuts@febo.com >
> >>> Cc: Leap Second Discussion List  >
> >>> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
> >>> December 31 this year
> >>>
> >>> 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.
> >>>
> >>> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
> >>> UTC, not so much by rare steps but by dithering. There would be no
> change
> >>> to UTC or timing infrastructure because the definition of UTC already
> >>> allows for positive or negative leap seconds in any given month.
> >>>
> >>> Every UTC-aware device would 1) know how to reliably insert or delete a
> >>> leap second, because bugs would be found by developers within a month
> or
> >>> two, not by end-users years or decades in the future, and 2) every
> >>> UTC-aware device would have an often tested direct or indirect path to
> IERS
> >>> to know what the sign of the leap second will be for the current month.
> >>>
> >>> The leap second would then become 

Re: [time-nuts] NCOCXO anyone?

[David]

On Thu, 21 Jul 2016 18:47:24 -0700, you wrote:

>On 7/21/2016 4:56 PM, Nick Sayer via time-nuts wrote:
>
>> Oh my. That’s a bit more than I was originally considering… What I had in 
>> mind was adding a DAC front end to an OCXO so that you could tune the EFC 
>> with serial commands rather than analog and calling that a product.
>>
>
>20 years ago when HP was working on a so called "smart clock"
>GPS box, they decided to do what you said, use a DAC to
>tune the EFC on the E1938A oscillator.  I
>recommended to them NOT to try to do that, but they
>didn't listen to me.  At that time, it
>was nearly impossible to come up with a DAC, buffer
>amplifier, and voltage reference that didn't degrade
>the stability of the E1938A, which isn't even as stable
>as a 10811.  What you need to ask yourself is:  in
>2016, can I finally get analog components that are
>an order of magnitude or two better than what was
>available in 1996?  I don't know, without researching
>it.  Certainly, we can't depend on Moore's law coming
>to the rescue.  If anything, that works against analog
>IC's by obsoleting older analog processes.
>
>Also in 1996, phase microsteppers were already legacy
>technology and didn't have a good reputation for spectral
>purity.  Another non-panacea.
>
>Rick

Increased integration has only helped insofar as you can attempt
designs which would have been prohibitive before.

I keep trying to come up with a charge balancing design but what about
Linear Technology's solution from back in 2001?

A Standards Lab Grade 20-Bit DAC with 0.1ppm/°C Drift
http://www.linear.com/docs/4177
___
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] LeoNTP Networked Time Server now available

[David J Taylor]

You might be interested in the LeoNTP Networked Time Server, which is now 
available:


 
https://store.uputronics.com/index.php?route=product/product&product_id=92&search=ntp

  "LeoNTP is a Stratum 1 time server with GPS synchronised clock source 
designed from the ground up with the sole purpose of providing a cost 
effective but highly accurate and extremely high performing networked time 
server. Extremely easy to setup and configurable with flexible power options 
USB/PoE (802.3af) it can provide accurate synchronised time for your LAN, 
WAN, CCTV, PLC, Telephone systems or anywhere accurate standalone time is 
required."


I was invited to try one of these boxes and I can report that it works very 
well, including a period when GPS was lost for several hours.


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


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

Re: [time-nuts] NCOCXO anyone?

[Hal Murray]

rich...@karlquist.com said:
> Also in 1996, phase microsteppers were already legacy technology and didn't
> have a good reputation for spectral purity.  Another non-panacea. 

What is a phase microstepper and/or how does it compare to a DDS?

(Google gets lots of hits, but they all refer to motors.)


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