[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] GPS message jitter (preliminary results)
I might have been the one who brought up the problem of the NMEA message not being right on the UTC send tick. But now I'm thinking of another problem this might create. It is slightly off topic because it has to do with location. Let's say I have a mobile robot (or a self driving car) that wants to know where it is. I have a three axis gyro, three axis accelerometer and a three axis magnetometer (acting as a magnetic compass. I also have rotational encoders on the wheels to count millimeters of travel. In theory I can dead recon from any known point but all of those sensors drift or are otherwise imperfect. So I add GPS. GPS's problem is it's on order 10 meter level accuracy and I need centimeters or better. The combination works. Each sensor makes up for the faults in the others. But up until now I have forgotten that the NMEA location data is likely some tens or hundreds of milliseconds old before it is output on the wire. This "noise" was hidden in the large location uncertainty inherent in GPS. Accounting for this should make my GPS more accurate. Now an off topic question that I bet many in this group can answer. I'm a total novice when it comes to Kalman Filters. I need to expertly combine all this data using one. Anyone got a good (hopefully on-line) tutorial or a cheap book on Amazon. (yes I used Google, got 1,000+ hits) I'm trying to do this myself and have found I forgot most of my Linear Algebra (it's been 30 years) and I doubt I ever really understood Kalman Filters completely On Tue, Jul 19, 2016 at 10:20 AM, Mark Sims wrote: > I ran some tests on the message timing of some V.KEL gps receivers in both > NMEA and binary mode. These receivers are the cheapest ones I have (3 for > $15 - $20, shipped). They use a SIRF III chip and have an on-board ceramic > patch antenna. They performed amazingly well. No problems tracking sats > indoors in a very poor location. Message jitter was less than 20 msecs > peak-peak, standard deviation less than 2 milliseconds. ADEVs at tau 1 > after an overnight run in NMEA mode (hardware serial port) were in the 1E-7 > range!They also have a 1PPS signal on the connector so no need to go > digging for a place to bodge on a wire like with some of the other cheap GPS > modules out there. > > V.KEL also makes a Ublox based version of the module (around $22 for one)... > mine reports that it has a Ublox 7 chip, though V.KEL's part number implies > that it a Ublox 6. > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Seiko watch "leap second enabled"
While I was googling for reports of other misbehaving GPS chips, I discovered the existence of the worlds first leap second enabled wrist watch. Seiko introduced the Astron models 8X53, 8X82, 7X52 which automatically check for a leap second on ……. « Seiko Astron enters the leap second data receiving mode after the first GPS signal is received on or after June 1st and December 1st. » (User Manual) D’OH!… Maybe one of Homer’s inventions. If any of you have one, have you checked how it has reacted? "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
> Le 20 juil. 2016 à 22:10, Gary E. Miller a écrit : > > Yo Martin! > > On Wed, 20 Jul 2016 21:37:02 +0200 > Martin Burnicki wrote: > >> So when the GPS receiver always just *showed* information on the >> current UTC data set then this is OK. However, the *time* it has >> *output* should not have jumped back and forth by 1 second. > > I have a report of a Venus8, with BeiDou, that jumped NMEA time by one > second on the 19th. > > The NMEA offset data is fun: > >https://dan.drown.org/bbb/latest/remote-statistics.NMEA.png possibly related the the issue reported back in january 2015. "Back in January it was reported here that the Venus 8 timing modules from Skytraq as used in the LTE-Lite, had a firmware bug that was causing the leap second to be applied as soon as the warning was seen in the GPS stream. I had bought one from Navspark and once I reported the issue they shipped me a replacement receiver as soon as the F/W update was available. I would have preferred the new F/W, but I got a free receiver as they did not want me to return the bugged one. " > > But some other, different, models of Venus8 did not. > > I'm trying to get more information. > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPS message jitter (preliminary results)
To answer about how they get good timing. Many times you run a loop that runs off a timer at say exact 1000 times per second. Having something like a 1KHz loop gives very deterministic timing. Lots of ways to do it. One is to run some RTOS. I had to make all the axis of a machine tool move at exact timing to cut a curve. Not hard just have decide to do it. I'm sure most engineers looked at the NMEA spec and read "with the second" and stopped at that. > On Jul 20, 2016, at 5:40 PM, Bob Camp wrote: > > HI > >> On Jul 20, 2016, at 7:51 PM, Mark Sims wrote: >> >> I added the ability of Lady Heather to calculate the time offset of the >> timing message from "wall clock" time. It calculates the difference between >> the system clock time to the time that the (end of) the timing message >> arrived. The result is only as good as your system clock, so the system >> clock really needs to be synced to something like NTP (otherwise it does a >> decent job of showing how much your system clock is drifting). Heather can >> plot the results and calculate xDEVs on both the message jitter and the >> message offset time in real time. >> >> On another note, I did some jitter measurements on Jupiter-T and Jupiter-T >> Pico receivers.I can't imagine how they do it, but those things are >> insanely good. Running at 9600 baud, their message jitter into a hardware >> serial port is less than a millisecond peak-peak! Somebody paid a LOT of >> attention to getting the message timing consistent… > > Just pre-load it all into a big shift register and let the PPS output gate > the clock to the beast. There’s not a lot of doubt about what the label on > the next second going out will be :) > > Bob > >> >> >> >> ___ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] KO4BB out of space
KO4BB.com ran out of disk space. Apparently the Control Panel indicated I was using 120GB out of 160 available, but it was off by about 40GB... About 90GB of that are manuals. A good bit of the extra are duplicate files that resulted from the site hosting transfer a couple of years ago that I had planned to clean up at some point. I was just not planning to do that NOW!!! The problem has been temporarily fixed, I have freed 10GB and hopefully I will have made more space (or bought more space...) over the week end. Thank you for your patience and your support. Didier KO4BB ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPS message jitter (preliminary results)
HI > On Jul 20, 2016, at 7:51 PM, Mark Sims wrote: > > I added the ability of Lady Heather to calculate the time offset of the > timing message from "wall clock" time. It calculates the difference between > the system clock time to the time that the (end of) the timing message > arrived. The result is only as good as your system clock, so the system > clock really needs to be synced to something like NTP (otherwise it does a > decent job of showing how much your system clock is drifting). Heather can > plot the results and calculate xDEVs on both the message jitter and the > message offset time in real time. > > On another note, I did some jitter measurements on Jupiter-T and Jupiter-T > Pico receivers.I can't imagine how they do it, but those things are > insanely good. Running at 9600 baud, their message jitter into a hardware > serial port is less than a millisecond peak-peak! Somebody paid a LOT of > attention to getting the message timing consistent… Just pre-load it all into a big shift register and let the PPS output gate the clock to the beast. There’s not a lot of doubt about what the label on the next second going out will be :) Bob > > > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] GPS message jitter (preliminary results)
I added the ability of Lady Heather to calculate the time offset of the timing message from "wall clock" time. It calculates the difference between the system clock time to the time that the (end of) the timing message arrived. The result is only as good as your system clock, so the system clock really needs to be synced to something like NTP (otherwise it does a decent job of showing how much your system clock is drifting). Heather can plot the results and calculate xDEVs on both the message jitter and the message offset time in real time. On another note, I did some jitter measurements on Jupiter-T and Jupiter-T Pico receivers.I can't imagine how they do it, but those things are insanely good. Running at 9600 baud, their message jitter into a hardware serial port is less than a millisecond peak-peak! Somebody paid a LOT of attention to getting the message timing consistent... ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Yo Noah! On Wed, 20 Jul 2016 17:12:14 -0400 Noah wrote: > First time poster; just subbed. Not a time hobbies the; my team @ > work runs NTP infrastructure. So , that's a brief intro out of the > way... Yes, a few of us NTP people here. We are several orders of magnitude coarser tham a true time-nut. > > Discovered that my commercial GPS appliances opted to *apply* > yesterday's pending leap second, which has made for an interesting > day. Got any details? GPS model? Did it get past your NTP into system time? I'm passing this info onto NTPsec devel folks. Time to 'Name and Shame". RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgp02nwNI62MY.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
On Wed, Jul 20, 2016 at 09:37:02PM +0200, Martin Burnicki wrote: > The UTC/leapsecond data sent by the satellites contains the UTC offset > before and after the leap second event time. This has been 17/17 until > recently, and is 17/18 now. > > The GPS satellites didn't start all at the same time to send the new > data set, so there was a period of time where some sats sent 17/17 while > some others already sent 17/18. > > So when the GPS receiver always just *showed* information on the current > UTC data set then this is OK. However, the *time* it has *output* should > not have jumped back and forth by 1 second. I don't actually know what the time it's outputting is (this particular chip I'm grabbing stats from, but not time), but I'm pretty certain that nothing should be returning '18' yet. In specific, from the docs for the 'UTC Offset' field in the Trimble docs for the TSIP primary timing packet (0x8F-AB): This field represents the *current* integer leap second offset between GPS and UTC (emphasis mine) However, even if it was outputting the correct thing in the timing packets, that only applies if the GPS is set to report UTC time rather than GPS time (which is selectable on Trimble chips). You should be able to get GPS time from the output and add the UTC offset to get UTC time, but that won't work with the data this chip is currently outputting. Even if reporting 18 is correct, though, Trimble still has a problem, because my Thunderbolt is still reporting 17, and I'm pretty sure they're not both right (same company, same protocol, different values). Either that, or Trimble provides a "UTC Offset" field with every timing packet that they don't actually intend for anyone to use for anything, but that would just be weird. -j ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
First time poster; just subbed. Not a time hobbies the; my team @ work runs NTP infrastructure. So , that's a brief intro out of the way... Discovered that my commercial GPS appliances opted to *apply* yesterday's pending leap second, which has made for an interesting day. --n >> On Jul 19, 2016, at 8:39 PM, Jay Grizzard >> wrote: >> >> On Tue, Jul 19, 2016 at 11:39:29PM +, Mark Sims wrote: >> The GPS satellites are now reporting the pending leapsecond... >> >> The Z3801A has it messed up... it says the leap will occur on 30 Sep >> 2016 (73 days). The Z3801A has two different messages that report the >> leap day... both are wrong. > > I think some (modern!) Trimble gear may also has a problem. I have an ICM > SMT 360 board that's (slowly) flipping back and forth between showing a UTC > offset of 17 seconds and an offset of 18 seconds. This is their currently > shipping timekeeping chip, so it's surprising, but I don't know how else > to explain the behavior outside of a firmware bug. > > (I've sent an email to Trimble support, but haven't heard anything back yet.) > > -j > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Yo Martin! On Wed, 20 Jul 2016 21:37:02 +0200 Martin Burnicki wrote: > So when the GPS receiver always just *showed* information on the > current UTC data set then this is OK. However, the *time* it has > *output* should not have jumped back and forth by 1 second. I have a report of a Venus8, with BeiDou, that jumped NMEA time by one second on the 19th. The NMEA offset data is fun: https://dan.drown.org/bbb/latest/remote-statistics.NMEA.png But some other, different, models of Venus8 did not. I'm trying to get more information. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpSkg15MMSsW.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Motorla Oldie
On 7/19/2016 5:09 PM, Pete Lancashire wrote: > Saw this guy at GoodWill, but they wanted $25 for it so didn't get it. > > Model: A11121Z115 > > http://petelancashire.com/gallery/main.php?g2_itemId=7196 > > http://petelancashire.com/gallery/main.php?g2_itemId=7200 > > -pete > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. Looks like a PVT-6. I sold a bunch of them used in the late 80's for $15 ea. Poor acquisition time and sensitivity when compared to current gen cheapies. -- mailto:o...@ozindfw.net Oz POB 93167 Southlake, TX 76092 (Near DFW Airport) ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Lucent KS-24361 REF-0
I got in a Z3812A (aka Lucent KS-24361 REF-0) and installed a Motorola UT+ in it following the excellent guide by Peter Garde (google is your friend) and have it working as a standalone GPSDO...basically it now a REF1 unit). The mod mostly involves moving half a dozen 0 ohm resistors (I chopped out the resistors... too lazy to unsolder them... and used wire wrap wire to replace them)) The gps receiver was around $20 from RDR Electronics. Yes, you could emulate the Motorola receiver with a newer model, but that is a LOT of work to do correctly for very little benefit (I've never seen a receiver that offers Motorola emulation get it entirely correct). Or you could use Dan's GPS message faker hack, but lose the ability to fully control the ref0 via SCPI commands / Lady Heather and would wind up spending the same amount as adding in the GPS receiver. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Lucent KS-24361 REF-0
Yes I was looking forward to seeing his "Tria" drop in Oncore replacement but it looks like he moved on to other projects. Original message From: paul swed Date:07/20/2016 2:08 PM (GMT-05:00) To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Lucent KS-24361 REF-0 Have not heard from Dan in a while. I did test various arduinos with his software and it all worked just fine. The system stability really depended on the quality of the GPS pps used. Regards Paul WB8TSL On Wed, Jul 20, 2016 at 12:11 PM, Gregory Beat wrote: > Dan Watson spent considerable time (2015) on standalone Lucent KS-24361 > REF-0 > with a "new" GPS board that would be "backward" compatible. > Not sure where he is fir project in 2016 (availability of OSHPark boards). > http://syncchannel.blogspot.com/2015/10/denuo-gps-retrofit-board.html > > Sent from iPad Air > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Jay Grizzard wrote: > On Tue, Jul 19, 2016 at 11:39:29PM +, Mark Sims wrote: >> The GPS satellites are now reporting the pending leapsecond... >> >> The Z3801A has it messed up... it says the leap will occur on 30 Sep >> 2016 (73 days). The Z3801A has two different messages that report the >> leap day... both are wrong. > > I think some (modern!) Trimble gear may also has a problem. I have an ICM > SMT 360 board that's (slowly) flipping back and forth between showing a UTC > offset of 17 seconds and an offset of 18 seconds. This is their currently > shipping timekeeping chip, so it's surprising, but I don't know how else > to explain the behavior outside of a firmware bug. The UTC/leapsecond data sent by the satellites contains the UTC offset before and after the leap second event time. This has been 17/17 until recently, and is 17/18 now. The GPS satellites didn't start all at the same time to send the new data set, so there was a period of time where some sats sent 17/17 while some others already sent 17/18. So when the GPS receiver always just *showed* information on the current UTC data set then this is OK. However, the *time* it has *output* should not have jumped back and forth by 1 second. Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Lucent KS-24361 REF-0
Have not heard from Dan in a while. I did test various arduinos with his software and it all worked just fine. The system stability really depended on the quality of the GPS pps used. Regards Paul WB8TSL On Wed, Jul 20, 2016 at 12:11 PM, Gregory Beat wrote: > Dan Watson spent considerable time (2015) on standalone Lucent KS-24361 > REF-0 > with a "new" GPS board that would be "backward" compatible. > Not sure where he is fir project in 2016 (availability of OSHPark boards). > http://syncchannel.blogspot.com/2015/10/denuo-gps-retrofit-board.html > > Sent from iPad Air > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
On Tue, Jul 19, 2016 at 11:39:29PM +, Mark Sims wrote: > The GPS satellites are now reporting the pending leapsecond... > > The Z3801A has it messed up... it says the leap will occur on 30 Sep > 2016 (73 days). The Z3801A has two different messages that report the > leap day... both are wrong. I think some (modern!) Trimble gear may also has a problem. I have an ICM SMT 360 board that's (slowly) flipping back and forth between showing a UTC offset of 17 seconds and an offset of 18 seconds. This is their currently shipping timekeeping chip, so it's surprising, but I don't know how else to explain the behavior outside of a firmware bug. (I've sent an email to Trimble support, but haven't heard anything back yet.) -j ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Lucent KS-24361 REF-0
Dan Watson spent considerable time (2015) on standalone Lucent KS-24361 REF-0 with a "new" GPS board that would be "backward" compatible. Not sure where he is fir project in 2016 (availability of OSHPark boards). http://syncchannel.blogspot.com/2015/10/denuo-gps-retrofit-board.html Sent from iPad Air ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
> On Jul 20, 2016, at 12:25 AM, Tom Van Baak wrote: > > Hi Gary, > >> 2.1 A positive or negative leap-second should be the last second of a UTC >> month, >> but first preference should be given to the end of December and June, >> and second preference to the end of March and September. > > Sounds correct. The point is to never to hardcode a "preference". You code > against a spec. And the spec is simple: > > "A positive or negative leap-second should be the last second of a UTC month" > Even that’s weasel-worded. If they mean it, they should say it *will* or it *must* be the last second of a UTC month. Words have meanings. :D ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Agilent 53132 Power module
My Agilent 53132 power module went bad, does any one have one for sale or info or schematic. Thanks Bert Kehren ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Gary E. Miller wrote: > Yo time-nuts@febo.com! > > On Tue, 19 Jul 2016 23:18:18 -0700 > Hal Murray , time-nuts@febo.com wrote: > >> g...@rellim.com said: In general there's a common belief that a leap second can only occur at the end of June or December. This is false. Don't ever hardcode this assumption. >> >>> NTP Classic thinks otherwise: >>> http://bugs.ntp.org/show_bug.cgi?id=3D1090 >> >> If you read the fine print in that bug, you will see that it's a work >> around for a bug in the HP firmware that is the core of this >> discussion. If it's known that certain devices out there have a certain bug then it's fine IMO to try to fix this in the device-specific part of the code, i.e. in ntpd's particular refclock driver. As Hal has already mentioned, I wouldn't consider the refclock driver as belonging to the core functionality, just because it is part of the code tree. > Yes, I know the problem being solved. Like today, the leap second being > broadcast sooner than ntpd expects, so it picks the wrong month. If the NTP specs say a leap second pending flag must not be set earlier than month or 1 day before the leap second occurs then the upstream software should account for this, regardless whether it's an upstream NTP server, or a refclock driver. >From ntpd's point of view: - If it receives a leap second announcement, in which case should the announcement be accepted; in which cases (buggy upstream sources) rejected? - When should ntpd start to pass a leap second pending flag on to its clients? - When should ntpd start to pass a leap second pending flag down to the OS kernel, so that the kernel can handle the leap second? If the leap second warning is passed too early then there's a good chance for confusion. If ntpd already has a current leap second file then it already knows about the upcoming leap second now, but it still doesn't pass a leap second pending flag to its clients, or to the OS kernel. Beside this there's still another point: - What should ntpd do if there are different upstream sources which disagree about an upcoming leap second? In current ntpd versions: - A leap second file has precedence unless it is outdated. - If no valid leap second file is available then a leap second warning from a refclock is accepted. - If no valid leap second file is available then a leap second warning from upstream NTP server is only accepted if a majority of servers provide it. >> I don't think there is anything in the core of ntpd that restricts >> leap seconds to Jun/Dec. If there was, it would have filtered out >> the above problem. There has been such a check before ntpd 4.2.6, but the code has been removed in current versions. > How about this: > > ntpd/refclock_hpgps.c, line 544: > > /* See http://bugs.ntp.org/1090 > * Ignore leap announcements unless June or December. > * Better would be to use :GPSTime? to find the month, > * but that seems too likely to introduce other bugs. > */ > case '+': > if ((month==6) || (month==12)) > > >> Things get interesting if you are shipping code today that will last >> for 10 or 20 years. My HP Z3801A has software dates from 1995 so 20 >> years isn't unreasonable. Of course, they were retired from >> commercial use a long time ago, so maybe it's OK if the firmware has >> bugs. > > 20 years? My house is 40 years old. In an IoT world people would like > to not throw away capital equipment every decade. > > But i'm prolly spitting into the wind... > >> I don't know any software projects that handle this sort of thing >> cleanly. (My exposure is limited.) > > gpsd filters out all but June and December. So sort of cleanly, but > clearly work needed. I notice ntpd also filters out leap warnings for > the first short bit of the month. That might be worth doing too. On systems which support this (Linux, *BSD, etc.) ntpd just passes a leap second pending flag to the kernel, and the kernel handles the leap second. However, ntpd has to keep track of its internal leap second flag which it sends out to the clients. So only if it polls the kernel status *after* the leap second has occurred and sees that the kernel's leap second flag has been cleared, ntpd can clear its internal leap second flag which it sends to the clients. So there's a chance that ntpd sends a leap second flag to client during a short interval after the leap second until it has polled the kernel status again and found that the leap second has passed by. So if clients accept a leap second flag in advance then it's important that there's some interval at the beginning of a month where they don't. > If a giant asteroid hits earth, and we need a negative leap second in > March, there will be a lot of urgent patching to do. Yes. Specifically, the German long wave transmitter doesn't have the possibility t
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Magnus, Magnus Danielson wrote: > Now, what annoys me is that the IERS message says that the leap second > is scheduled for January: > > 8<--- > > Paris, 6 July 2016 > > Bulletin C 52 > > To authorities responsible for the measurement and distribution of time > > >UTC TIME STEP > on the 1st of January 2017 > > > A positive leap second will be introduced at the end of December 2016. > The sequence of dates of the UTC second markers will be: > > 2016 December 31, 23h 59m 59s > 2016 December 31, 23h 59m 60s > 2017 January 1, 0h 0m 0s > --->8 > > It is unfortunate that it says UTC TIME STEP on the 1st of January 2017, > as it is scheduled for 31 December 2016. Hm, the leap second is inserted at the end of December 31 (which is also said by the message text), but as a consequence the beginning of January 1 is delayed by 1 second, so IMO this statement might be correct, even though it's not formulated very clearly. > This is a new habbit of IERS, and it is unfortunate and not helpful. > Older Bullentin C used the more correct reference to end of June or end > of December. Hm, the oldest bulletin C I found on the IERS web site already has the same statement: https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.10 I find it amusing that until ~2011, if no leap second was scheduled, the message text said: "NO *positive* leap second will be introduced ..." If you're nitpicking you could have expected that eventually a *negative* leap second was to be scheduled. ;-) Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Hi Hal, I guess you know this but... > I wasn't considering refclocks to be "core" in that context. Got a better > word? > Have you found any similar code that isn't in one of the refclocks? ntp_loopfilter.c used to have code that restricted the months for leap seconds. The new core ntpd code doesn't do this check, though if you have an up-to-date leapseconds file, it will veto bad suggestions. David. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
On Wed, Jul 20, 2016 at 01:05:59AM -0700, Hal Murray wrote: > g...@rellim.com said: > > Yes, I know the problem being solved. Like today, the leap second being > > broadcast sooner than ntpd expects, so it picks the wrong month. > Do you know of any ntp servers that have picked the wrong month? When I was writing up my leap second measurements, I went looking for reports of leap seconds in unusual months (i.e. not in June/Decembet) and managed to find the following: http://lists.ntp.org/pipermail/questions/2007-October/015655.html http://lists.ntp.org/pipermail/questions/2012-August/033611.html http://lists.ntp.org/pipermail/questions/2013-July/035664.html For the first, I think Windows was involved? For the second, I'm not sure how many people accidently leaped. For the last, there was definitely one leap. David. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Hal Murray wrote: > g...@rellim.com said: >>> I don't think there is anything in the core of ntpd that restricts >>> leap seconds to Jun/Dec. If there was, it would have filtered out >>> the above problem. >> How about this: >> ntpd/refclock_hpgps.c, line 544: > > I wasn't considering refclocks to be "core" in that context. Got a better > word? > > Have you found any similar code that isn't in one of the refclocks? ntpd versions before 4.2.6 also had a plausibilty check, which even had a bug when checking for end of June. See: http://bugs.ntp.org/show_bug.cgi?id=525#c0 > g...@rellim.com said: >> 20 years? My house is 40 years old. In an IoT world people would like to >> not throw away capital equipment every decade. > > Your house gets a new roof occasionally. The IoT world hasn't figured out > how to handle firmware updates and/or people haven't adapted to throwing out > gear that looks OK physically but has bugs, especially if the bugs don't > break the main function of the device. Firmware updates? Why would anyone need this? ;-)) > g...@rellim.com said: >> gpsd filters out all but June and December. So sort of cleanly, but clearly >> work needed. ... > > The sort of "cleanly" I had in mind would be at the project management level. > Handwave. Each project should keep track of the assumptions in their code > that may not be correct many years in the future. That list should be > reviewed occasionally, say every year or few years. Agreed. > It also has to be documented in a way that downstream users know what they > are getting involved with. This is a good example. Tom is arguing for > do-it-right according to the specs. I'm arguing for defensive programming > since we have already seen bugs in other gear. I'd say the best solution would be a combination of both. > If you were packaging ntpd > into a box which would you want? Will your box last long enough to see a > leap second in Mar or Sep? Is your box going to connect to old/buggy gear? > Does your startup have enough funding to consider issues like this, or people > smart enough to understand the tangle? +1 Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
g...@rellim.com said: > Yes, I know the problem being solved. Like today, the leap second being > broadcast sooner than ntpd expects, so it picks the wrong month. Do you know of any ntp servers that have picked the wrong month? g...@rellim.com said: >> I don't think there is anything in the core of ntpd that restricts >> leap seconds to Jun/Dec. If there was, it would have filtered out >> the above problem. > How about this: > ntpd/refclock_hpgps.c, line 544: I wasn't considering refclocks to be "core" in that context. Got a better word? Have you found any similar code that isn't in one of the refclocks? g...@rellim.com said: > 20 years? My house is 40 years old. In an IoT world people would like to > not throw away capital equipment every decade. Your house gets a new roof occasionally. The IoT world hasn't figured out how to handle firmware updates and/or people haven't adapted to throwing out gear that looks OK physically but has bugs, especially if the bugs don't break the main function of the device. g...@rellim.com said: > gpsd filters out all but June and December. So sort of cleanly, but clearly > work needed. ... The sort of "cleanly" I had in mind would be at the project management level. Handwave. Each project should keep track of the assumptions in their code that may not be correct many years in the future. That list should be reviewed occasionally, say every year or few years. It also has to be documented in a way that downstream users know what they are getting involved with. This is a good example. Tom is arguing for do-it-right according to the specs. I'm arguing for defensive programming since we have already seen bugs in other gear. If you were packaging ntpd into a box which would you want? Will your box last long enough to see a leap second in Mar or Sep? Is your box going to connect to old/buggy gear? Does your startup have enough funding to consider issues like this, or people smart enough to understand the tangle? -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] How does sawtooth compensation work?
Hello Michael > Thinking out loud, I wonder how bad L1-only, post-processed, would be for > time-nuts use? Especially with a timing-grade antenna (e.g. the common > Trimble Bullet). Dual frequency is great when your receiver has the potential > to move, you have to resolve carrier phase ambiguity quickly, or you don't > have a reference station (CORS) nearby. (O.T. I was out hiking in Washington > state recently, and *accidentally* happened upon my local CORS station, so I > guess that's no issue for me :-)). But for many time-nuts, I wonder how badly > a timing-grade antenna, something with raw carrier phase output (which you > get very cheaply these days), and a stable enough local clock to allow you > average out local weather. > There was a related discussion a month ago https://www.febo.com/pipermail/time-nuts/2016-June/098484.html and I posted a plot https://www.febo.com/pipermail/time-nuts/attachments/20160616/cb2801b0/attachment.png which might be helpful. As you can see, the improvement from raw 1 pps to a full carrier-phase solution with IGS rapid orbits and clock solutions is not enormous, just a factor of 4 in stability. BIPM does a bit better with TAI PPP, eg ftp://ftp2.bipm.org/pub/tai/publication/timelinks/taippp/1606/ maybe 30% or so. (To be completely fair, the raw 1 pps is from a $10K GPS receiver with a very good sawtooth correction so there may be a bit more of an improvement at averaging times less than 1000 s or so) There are a few more plots of L1 receiver performance at: http://www.openttp.org/scripts/blog.php > For time-nut use, I don't see any harm in using post-processing for > evaluation/measurement of clocks. This is exactly how most of the clocks contributing to UTC are linked together across the world. Cheers Michael On Wed, Jul 20, 2016 at 9:41 AM, Michael wrote: > Thanks Tom, Bob, and Mark (wrote my response to Tom first, but didn't hit > send)! > > I've actually been collecting some *ancient* dual-frequency geodetic gear to > play with, some of which have external clock inputs (or should be hackable). > I've read a lot, but I wasn't sure what people were typically referring to on > this list. Thanks for the overview...that helps me connect the dots between > the time-nuts and survey/geodetic GPS worlds. > > For time-nut use, I don't see any harm in using post-processing for > evaluation/measurement of clocks. Won't get you something usable in > real-time, for sure, but if you're already collecting weeks of data, don't > see any harm in waiting for precise orbit and clock solutions to become > available for post processing. And it might tell me how far off you are in a > 24-hour PPP solution. Which I guess means you'd need to be very stable in the > <=24hr region. > > Thinking out loud, I wonder how bad L1-only, post-processed, would be for > time-nuts use? Especially with a timing-grade antenna (e.g. the common > Trimble Bullet). Dual frequency is great when your receiver has the potential > to move, you have to resolve carrier phase ambiguity quickly, or you don't > have a reference station (CORS) nearby. (O.T. I was out hiking in Washington > state recently, and *accidentally* happened upon my local CORS station, so I > guess that's no issue for me :-)). But for many time-nuts, I wonder how badly > a timing-grade antenna, something with raw carrier phase output (which you > get very cheaply these days), and a stable enough local clock to allow you > average out local weather. > > I guess while it's fascinating to me...wonder if it has any use in practice > compared to a simple, autonomous, real-time, L1-only receiver? I mean, I'm > interested in measuring my local tropospheric and ionospheric delays. But > then again, I am an aspiring time-(and maybe GPS)-nut :). > > Michael > >> Hi Michael, >> >> About #3 below... >> >> There are dozens of technical papers about all this in the PTTI, FCS, UFFC, >> EFTF journals. Google for words like: GPS carrier-phase dual-frequency >> time-transfer geodetic-receiver IGS precise point positioning PPP >> >> I don't have a link to a handy 1-page summary, but someone else on the list >> might. Otherwise skim the first ten papers you find and you'll pick up the >> concepts of high-precision time transfer. >> >> The basic idea is that high-end geodetic-grade receivers often have an >> external 10 or 20 MHz clock input (and maybe no internal clock at all). You >> give it your best lab clock and all then all GPS signal processing and SV >> measurements are based on your fancy clock. The output of the receiver is a >> stream of these measurements, not necessarily a physical 1PPS or 10 MHz (as >> with a GPSDO). >> >> So you can see there's no such thing as sawtooth error here, because you're >> not transferring some internal clock to some external clock via a TIC; there >> is only the one clock; your clock. >> >> All this measurement data is then post-processed, hours or days later, so >> tha
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Hi Gary, > 2.1 A positive or negative leap-second should be the last second of a UTC > month, > but first preference should be given to the end of December and June, > and second preference to the end of March and September. Sounds correct. The point is to never to hardcode a "preference". You code against a spec. And the spec is simple: "A positive or negative leap-second should be the last second of a UTC month" It would appear that assuming the preference was actually a rule is what causes the Z3801A f/w to mis-report the next leap second as September instead of December. Back in the late 90's, when the 58503/Z3801 code was written, this made sense. Leap second annoucenements were not made half a year in advance back then. /tvb - Original Message - From: "Gary E. Miller" To: "Tom Van Baak" Cc: "Discussion of precise time and frequency measurement" Sent: Tuesday, July 19, 2016 10:36 PM Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year Yo Tom! > > IERS is free to schedule a leap second at the end of any month. And > > it may be an insert or a delete. Assume nothing more or less in your > > code. Code and test and document for positive and negative leap > > seconds equally. > > Got a reference for that? I know many people that will insist > otherwise. Never mind, I think I found a reference that is commonly quoted: CCIR Recommendation 460-4 (1986). http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en 2. Leap-seconds 2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September. But it is marked Superceded. I'm guessing that is replaced by 460-6? http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en It says the same thing in section 2.1 Nothing says it has to be those 4 months... I have some code comments in gpsd to fix... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Yo time-nuts@febo.com! On Tue, 19 Jul 2016 23:18:18 -0700 Hal Murray , time-nuts@febo.com wrote: > g...@rellim.com said: > >> In general there's a common belief that a leap second can only > >> occur at the end of June or December. This is false. Don't ever > >> hardcode this assumption. > > > NTP Classic thinks otherwise: > > http://bugs.ntp.org/show_bug.cgi?id=3D1090 > > If you read the fine print in that bug, you will see that it's a work > around for a bug in the HP firmware that is the core of this > discussion. Yes, I know the problem being solved. Like today, the leap second being broadcast sooner than ntpd expects, so it picks the wrong month. > I don't think there is anything in the core of ntpd that restricts > leap seconds to Jun/Dec. If there was, it would have filtered out > the above problem. How about this: ntpd/refclock_hpgps.c, line 544: /* See http://bugs.ntp.org/1090 * Ignore leap announcements unless June or December. * Better would be to use :GPSTime? to find the month, * but that seems too likely to introduce other bugs. */ case '+': if ((month==6) || (month==12)) > Things get interesting if you are shipping code today that will last > for 10 or 20 years. My HP Z3801A has software dates from 1995 so 20 > years isn't unreasonable. Of course, they were retired from > commercial use a long time ago, so maybe it's OK if the firmware has > bugs. 20 years? My house is 40 years old. In an IoT world people would like to not throw away capital equipment every decade. But i'm prolly spitting into the wind... > I don't know any software projects that handle this sort of thing > cleanly. (My exposure is limited.) gpsd filters out all but June and December. So sort of cleanly, but clearly work needed. I notice ntpd also filters out leap warnings for the first short bit of the month. That might be worth doing too. I'm sure something else will crop up before 2017. If a giant asteroid hits earth, and we need a negative leap second in March, there will be a lot of urgent patching to do. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpOOCjNb7TtZ.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Gary, On 07/20/2016 07:36 AM, Gary E. Miller wrote: Yo Tom! IERS is free to schedule a leap second at the end of any month. And it may be an insert or a delete. Assume nothing more or less in your code. Code and test and document for positive and negative leap seconds equally. Got a reference for that? I know many people that will insist otherwise. Never mind, I think I found a reference that is commonly quoted: CCIR Recommendation 460-4 (1986). http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en 2. Leap-seconds 2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September. But it is marked Superceded. I'm guessing that is replaced by 460-6? http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en It says the same thing in section 2.1 Nothing says it has to be those 4 months... No, but the wording do say that those four month is preferred. For those that is curious: http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf 8<--- 2 Leap-seconds 2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September. 2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month (see Annex 3). 2.3 The IERS should decide upon and announce the introduction of a leap-second, such an announcement to be made at least eight weeks in advance. --->8 Thus, any month can be scheduled, but there is a preference to end of half-year and then end of quarter. The main preference is used in practice, which is in good accordance with the rules, the Z3801A designers over-eagerly included also the remaining two end-of-quarter. I have some code comments in gpsd to fix... Yes, but it can take a long time before it would bite you. Beware of GPS-receivers such as Z3801A which now give the time of leap second 3 month to early, and beware that eventually end of March and end of September might become legal points even for a Z3801A. Now, what annoys me is that the IERS message says that the leap second is scheduled for January: 8<--- Paris, 6 July 2016 Bulletin C 52 To authorities responsible for the measurement and distribution of time UTC TIME STEP on the 1st of January 2017 A positive leap second will be introduced at the end of December 2016. The sequence of dates of the UTC second markers will be: 2016 December 31, 23h 59m 59s 2016 December 31, 23h 59m 60s 2017 January 1, 0h 0m 0s --->8 It is unfortunate that it says UTC TIME STEP on the 1st of January 2017, as it is scheduled for 31 December 2016. This is a new habbit of IERS, and it is unfortunate and not helpful. Older Bullentin C used the more correct reference to end of June or end of December. Ah well. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.