[LEAPSECS] Trivial leap second "problem" example

From: Ed Davies <ls_at_EDAVIES.NILDRAM.CO.UK>
Date: Thu, 30 Jan 2003 18:42:57 +0000

Markus Kuhn wrote:
>...
> Who needs to know about a leap second more than half a year in advance
> but has no access to a time signal broadcasting service (the better ones
> of which all carry leap second announcement information today)?
>...

Here's an example of a real but trivial nuisance, rather than an actual
problem as such, caused by leap seconds.

A company which I do work for from time to time manufactures logging
devices used primarily in gliding but also in other aviation and
sport activities. The device is based around a Hitachi HD6303
processor (like a Motorola 6800) with RAM, a real-time clock, pressure
transducer (for altitude measurement) and serial port used for upload
and to receive input from a "domestic" GPS receiver.

Somewhere around 2000 of the loggers have been sold. It originally
was created purely as a barograph (pressure altitude recorder) in
late 1980s then extended to record position information from a GPS
in 1993.

Every so-many seconds (user settable) the device records the pressure
altitude and listens for position and other information in NMEA 0183
format from the GPS. If it gets a position it records it with the
altitude. The basic timing of the trace recording is done using the
logger's own clock.

In order to "calibrate" the logger's clock, every half hour it also
records the UTC date and time as reported by the GPS receiver.

Of course, the UTC date/time output by the GPS receiver is delayed
slightly, by nearly a second with modern receivers and by nearly
two seconds for older receivers like the Garmin GPS-100 (as
verified by comparing the NMEA output with the display of a clock
driven by a broadcast time standard). But so is the position
information and for gliding competition purposes the exact time of
a position is more likely to be important than the exact time of an
altitude measurement. Also, the pressure altitude is recorded
before the logger starts listening for a position NMEA sentence so
tends to be, on average, half a second earlier than transmission
time of the corresponding position and therefore pretty close to
synchronous with it's validity time.

Later, when the trace is uploaded the differences between the GPS
derived UTC date/times and the logger's own date/times are calculated
and the average is taken across the whole trace. This average is
then used to correct the times of all the samples to UTC.

If a leap second happened in the middle of the trace then it's effect
would be averaged out in this process - not too much of a loss.

As a double check, I also put in some code to report a warning if
the differences between logger clock time and GPS reported UTC varied
too much throughout a trace. The question arises: how much is "too
much". Well, early GPS receivers (Garmin GPS-100) only output
position information every two seconds so we had to allow for the
possibility of some date/time samples "catching" a slightly earlier
or later beat from the GPS. Also the clock of the logger might drift
slightly - much less than one second in the length of a flight. This
implies a tolerance of three seconds. But if a leap second happened
there'd be another second to consider, too. Hmm, anything else?
Dunno, better make it five seconds then.

In other words, consideration of leap seconds makes us reduce the
sensitivity of a check for other potential problems (like the logger
clock speed being significantly out or somebody trying to fiddle the
trace in some way).

You might ask, why not take leap seconds into account in doing the
calculations after upload? Well, that would be possible but this
information is not readily available on the scruffy old DOS PC's
typically floating about in gliding club club-houses. We could ask
the users to enter the information but it seems like an awful lot
of hassle for tiny gain.

More significantly, I haven't tested the system when a leap second
happens. I did record the output of my Garmin 100 over a leap
second a few years ago just to see what happens and could try playing
that back into a logger but it doesn't follow that the exact timing
of the output from the GPS would be right.

In case anybody's interested, the GPS was reporting even or odd
numbered seconds before midnight then a few seconds after midnight it
switched to reporting the opposite.

At least with the epsilon proposal the unusual case would be
available once a day for testing - as well as having a tiny enough
effect to ignore compared with the inaccuracies of most clocks in
widespread use.

Ed Davies.
Received on Thu Jan 30 2003 - 10:54:54 PST