> 2) along with the gps time signal, information is broadcast to relate > gps time to utc. whenever there's a step change in these corrections > (such as on midnight 31/12/2008), how does the unit react? 2.1) in > particular, how quickly does the time code reflect the change, and is > the 1pps affected in any way? Check the data sheet on the unit. It probably has a section describing the leap second stuff. They happen infrequently enough that you can usually get the info by other means. I'm sure the next one will be announced here. GPS works on GPS time. The satellites tell you the offset to UTC. I expect that offset kicks over at the magic time, but I wouldn't be surprised by bugs. Somebody may have data from watching the last time we had one. (I was watching a NMEA unit. It inserted the leap second at midnight GPS time rather than midnight UTC.) The PPS is tied to GPS time. I don't expect any quirks from leap seconds. -- These are my opinions, not necessarily my employer's. I hate spam.

Hal Murray wrote: >> 2) along with the gps time signal, information is broadcast to relate >> gps time to utc. whenever there's a step change in these corrections >> (such as on midnight 31/12/2008), how does the unit react? 2.1) in >> particular, how quickly does the time code reflect the change, and is >> the 1pps affected in any way? > > Check the data sheet on the unit. It probably has a section describing the > leap second stuff. It is rarely beyond slogan level, if even mentioned in the datasheets. The manual rarely says much useful on the subject either. It happends from time to time that receivers freezes on leap seconds only for the stupid reasons it was not tested by the vendor. A simple single sat GPS emulator would have helped to trigger the bug, which is sufficient for timing receivers and should work for position receivers too. > They happen infrequently enough that you can usually get the info by other > means. I'm sure the next one will be announced here. There won't be one next new years even, it just became official yesterday. That was expected. > GPS works on GPS time. The satellites tell you the offset to UTC. I expect > that offset kicks over at the magic time, but I wouldn't be surprised by > bugs. Somebody may have data from watching the last time we had one. (I was > watching a NMEA unit. It inserted the leap second at midnight GPS time > rather than midnight UTC.) OUPS! > The PPS is tied to GPS time. I don't expect any quirks from leap seconds. If only listening to PPS and don't care about the time associated with it, you are safe. GPS time or UTC time should work equally well. I think you should fetch the GPS ICD 200 document and read up on the details in the signal structure on how UTC is represented in relationship to the GPS signal. Then imagine all the bugs there can be. There are (at least) three interpretations of when leap-seconds may be inserted: 1) At the end of every month. 2) At the end of every quarter. 3) At the end of every half-year. GPS is operated under the assumption that case 3 holds. There exist equipment assuming that case 2 holds. The actual definition allows for case 1, making case 3 the primary preference and case 2 the secondary preference. Lovely mess, isn't it? Anyway, if I don't recall it incorrectly (OK lazy to check), the GPS signal actually indicate WHEN then upcomming leap second will occur. This reduces to a up-comming leap second flag out of the GPS OEM board which can trigger pre-maturely execution of leap-second algorithm on the timing receiver, as we have seen in the Z3801A for instance. Cheers, Magnus

In message: <4A533C36.1030608@rubidium.dyndns.org> Magnus Danielson <magnus@rubidium.dyndns.org> writes: : There are (at least) three interpretations of when leap-seconds may be : inserted: : 1) At the end of every month. This is the ITU standard. It says that leap seconds can be inserted at the end of each month. Almost no gear allows this, and the gear that does doesn't always do it in a sane way. : 2) At the end of every quarter. This is also ITU standard. These are the secondary times. They have never been used. : 3) At the end of every half-year. These are the primary times. : GPS is operated under the assumption that case 3 holds. Why is this the case? The GPS data just tells you which week the next leap second will happen, as well as the last time a leap second happened. How is it the case that you can say that 3 holds? : There exist equipment assuming that case 2 holds. : The actual definition allows for case 1, making case 3 the primary : preference and case 2 the secondary preference. Yes. : Lovely mess, isn't it? Leap seconds are evil and must die. For such a simple thing, there's so much complication that getting leap seconds right can be rather hard. At least there's no leap second this December... : Anyway, if I don't recall it incorrectly (OK lazy to check), the GPS : signal actually indicate WHEN then upcomming leap second will occur. : This reduces to a up-comming leap second flag out of the GPS OEM board : which can trigger pre-maturely execution of leap-second algorithm on the : timing receiver, as we have seen in the Z3801A for instance. You are correct. There's an indication when the next leap second will happen. The Z3801A uses this to turn on a simple 'leap second pending' which causes a leap second to happen at the next leap second opportunity rather than at the week published. The GPS operators turn on next leap second about 4 or 5 months early, which triggers the bug. Warner

Is there another planned Thunderbolt group buy ? -pete