UTC Leap Seconds

The IONUTC log can be used to determine the current offset between GPS and UTC time.

For example, here is an IONUTC log collected from an OEMV3 receiver:

<IONUTC COM1 0 28.0 FINESTEERING 1687 166200.185 00000020 ec21 7009
<     1.676380634307861e-08 2.235174179077148e-08 -1.192092895507812e-07 -1.192092895507812e-07 1.105920000000000e+05 9.830400000000000e+04 -1.310720000000000e+05 -1.966080000000000e+05 1687 319488
0.0000000000000000 1.776356839e-15 1694 7 15 16 0

In this example, the four bold fields represent the following:
1694 - Future week number
7 - Future day number (range is 1-7 where Sunday = 1, Saturday = 7)
15 - Delta time due to leap seconds (current number of leap seconds)
16 - Future delta time due to leap seconds (future number of leap seconds)

These fields can be used as follows:
16 - 15 = 1 --> a positive leap second is pending (ie: +1), and will occur on day 7 of week 1694.

Based on this information, a leap second will be added to UTC on June 30, 2012.  The sequence of dates of the UTC second will be:

2012 June 30, 23h 59m 59s
2012 June 30, 23h 59m 60s
2012 July 1, 0h 0m 0s

For most applications this change in leap seconds will not be noticed.

When the receiver does not have any leap second information, it will use the default leap second value which is 15 seconds in current firmware (3.901 for OEMV, 6.100 for OEM6). Once the receiver obtains the leap second information, the “known leap second” will then be used. Even if the receiver is reset or power cycled, the “known leap second” will always be used.

The UTC offset being used by the receiver is available in the TIME log.

If the receiver gets information regarding the leap second change, it will automatically apply that change when it comes.

The “default leap second” is ONLY used when the receiver has no information regarding leap second.

Let me explain more in 3 different cases

1) Case 1: Receiver has been in operation for a while
In this case, the receiver will have UTC change information, and the receiver shall add the extra second when it comes.

2) Case 2: Receiver has been factory reset ("FRESET") 15 minutes before the leap second change
Assuming continuous tracking, the receiver shall have enough time to acquire the UTC information, and it shall operate the same as the first case.

3) Case 3: Receiver is turned on after the leap second change and it has no UTC information

If the receiver has a GPS only model, the UTC leap second would be wrong until the receiver obtains the UTC information. During this time, the UTC status in the TIME log would be marked as “WARNING” instead of “VALID". After the receiver obtains the UTC information, it will change to to the current value.

If the receiver has a GPS + Glonass model, it will be similar to above case, but you may see the Glonass tracking cutting in and out until the receiver has the valid UTC offset, and this is because the Glonass is based on UTC time system.

OEM6 Firmware Reference Manual:

http://www.novatel.com/assets/Documents/Manuals/om-20000129.pdf

IONUTC log -- See page 397, Section 3.3.53

TIME log -- See page 673, Section 3.3.184