Leap second support in Güralp Digitisers and Acquisition units
The earth's rotation is gradually slowing in an unpredictable manner. It is affected by, amongst other things, large earthquakes and volcanic eruptions. These alter the distribution of mass around the planet and, because angular momentum must be conserved, the rate of rotation must change, altering the duration of a day. The drag of the tides against the ocean-bottoms also slows the earth, converting some of its angular momentum into heat energy.
This leads to a problem when we try and define the basic unit of time; the second. We would like to have a fixed, constant duration for our standard second but the conventional, historical measurement of time is inextricably linked to a natural day of varying length. The solution is to define a fixed duration for the second but to change the length of the day (actually, it is the year that we change) when necessary. We call time based on the variable rotation of the Earth "Mean Solar Time" and time based on our fixed, standard second "Atomic Time" (TAI).
Because these two time definitions gradually drift out of synchronisation, we use a third definition, "Coordinated Universal Time" or UTC. This clicks along, second by second, with Atomic Time but, to keep it aligned with mean solar time, an extra second - known as a leap second - is added to or subtracted from UTC every few years. (So far, they have only ever been added.) The process is managed by the International Earth Rotation and Reference Systems Service (IERS), who issue a twice-yearly bulletin - "Bulletin C" - which either announces a time step in UTC, or confirms that there will be no time step at the next possible date. You can visit their web site, register and subscribe to this bulletin in order to receive advance notifications of leap seconds. See the IERS bulletins page for more information.
Since the system was set up in 1972, there have been 26 leap seconds; all either at the end of June or the end of December (although the IERS reserve the right to add them at the end of March or September, if necessary.
Güralp digitsers synchronise their internal clocks to GNSS systems such as Navstar/GPS, GLONASS, Galileo and Baidou. This article will focus on Navstar/GPS, which is currently the most common amongst our customers. The GPS system uses its own time standard, known as GPS time (GPST). GPST and UTC coincided in 1980 but have diverged since, because of leap seconds. GPST does not account for leap seconds so GPS receivers have to perform a correction before they can provide UTC as output. To facilitate this, the GPS navigation message, which is transmitted to the receiver by the satellite fleet, includes the difference between GPS time and UTC, known as the UTC offset. As of January 2017, the offset is 17, meaning that GPS time is 17 seconds ahead of UTC. GPS receivers subtract this offset from GPS time to calculate UTC.
Some new GPS units, including the u-blox chip-set used in the latest Güralp receivers, do not show the correct UTC time until after receiving the UTC offset message, which may be after several minutes. Güralp receivers include an additional micro-processor, integrated into the receiver, which stores the current UTC offset and informs the chip-set of the correct value as soon as it powers up.
To signal a leap second to a connected device, such as a digitiser, the GPS receiver inserts the special time "23:59:60" between 23:59:59 and 00:00:00. The last minute of the month has, therefore, 61 seconds, numbered 0 to 60.
DM24s and CD24s
Güralp DM24 and CD24 digitisers (including those in *TD and *TDE instruments) understand leap seconds and will time-stamp their data accordingly. If, for any reason, the GPS message sent at the exact leap second is missed, the digitiser will resynchronise shortly after receiving the next GPS message but a segment of data will then have incorrect time-stamps. To avoid this, you can warn your digitiser about the upcoming leap second with the command
When using high sample rates (200 sps and above), there have been occasional reports of digitisers producing output data before the GPS receiver has finished transmitting the "23:59:60" message. This can result in time-stamps which are one second out. This problem can be avoided by issuing the LEAPSECOND command as described above.
When used with the latest Güralp receivers (those based on the u-blox chip-set), Güralp DM24 and CD24 digitisers will automatically issue this command for you, so no special action is required. Up-to-date digitiser firmware is required for this to work correctly.
To identify u-blox-based GPS receivers, check the status stream after boot-up (or after briefly disconnecting and then reconnecting the receiver). Output like
Affinity systems, EAMs and other Platinum systems (such as NAMs, DM24SxEAMs and *TDE instruments) will periodically check the Internet for notifications of leap seconds. If, however, a system cannot access the Internet, this process will fail. You can manually notify a Platinum system of the upcoming leap second in a number of ways:
- Run the script /etc/cron.weekly/update-libiso8601-leaptable. This script is normally run weekly to update the local copy of the table from the Internet-hosted copy. It requires Internet access but it does not involve changing the firmware build.
- Use a PC to download the file http://www.guralp.com/download/libiso8601/leap-table
and then distribute it manually to your systems, installing it as
You can check that
/usr/share/libiso8601/leap-table is up to date by comparing its checksum to that of the current file. The output from the command
If you have an Internet connection, you can simply run /etc/cron.weekly/update-libiso8601-leaptable
and the check the end of the file
/var/log/messages. You should see a line like
indicating that the file is up to date.
Minimus and Radian
The very latest Güralp digitisers and digital instruments, Minimus and Radian, do not currently have leap second support. They will resynchronise shortly after receiving the next GPS message after the leap second.
GCF and Scream!
Scream's WaveView windows will not show a leap second on the time scale (x-axis). If the displayed data span a leap second, traces will be shown overlapping for a second at the start of the next GCF packet. All features will work as expected.