Simulator Manufacturer Flags Leap Second Issue

Differences between BeiDou and GPS and Galileo in designation of a “day number” for the date of applying leap second later this year could cause problems for GNSS receiver manufacturers, according to UK-based simulator provider Racelogic.

Differences between BeiDou and GPS and Galileo in designation of a “day number” for the date of applying leap second later this year could cause problems for GNSS receiver manufacturers, according to UK-based simulator provider Racelogic.

As the U.S. Navy Observatory explains it, civil time is occasionally adjusted by one-second increments to ensure that the difference between a uniform time scale defined by atomic clocks does not differ from the Earth’s rotational time by more than 0.9 seconds. Coordinated Universal Time (UTC), an atomic time, is the basis for civil time. However, most GNSS time systems do not implement leap seconds, accounting for it in their navigation messages as an offset from UTC. Unlike GPS, Galileo or BeiDou, GLONASS time scale implements leap seconds, like UTC.

“During our preparation of playback scenarios for the upcoming leap second event later this year, we have identified a potential pitfall for GNSS engineers,” says Mark Sampson, the company’s product manager for its LabSat simulators. The difficulty arises from the fact that BeiDou uses a different “day number” for the date to apply the leap second — scheduled to be introduced this year at 23:59:60 on June 30 — compared with GPS and Galileo. GPS and Galileo use 1-7 as week day numbers, and BeiDou uses 0-6, according to Sampson.

Racelogic suggests that, if this fact has been missed during development, then the result is that the leap second may be implemented a day early on GNSS engines that are tracking the BeiDou constellation.

“Indeed, we tested four different Beidou enabled receivers, from four leading GNSS companies, and none of them appeared to handle the Beidou leap second correctly,” said Sampson. “This included an engine which originates from China!”

He said that Racelogic has since been in contact with two of the companies, which confirmed that their hardware does have a bug in the leap second code due to the numbering of the days.

The error presents itself when the receiver is running on the BeiDou constellation alone, and when the date is June 29 this year. In some cases, the BeiDou leap second will be adjusted from two seconds to three seconds from midnight on June 29, which should instead occur on midnight of the 30, Sampson said. This will result in an error for the reported UTC time of one second for the period of this day. In other cases studied by Racelogic, the leap second was not implemented at all when running on Beidou alone.

On some of the receivers that the company tested, however, when GPS is being tracked as well, the GPS leap second message overrides the one coming from BeiDou and applies the leap second correctly.

As for GLONASS, according to a LabSat engineer, “Theoretically the GLONASS ICD [interface control document] contains a long description of how a receiver should behave around the UTC time change (leap second insertion) not to have any gaps in the service, but from what I know many receivers simply lose track and they can stop displaying position for a few minutes.”

In order to help companies test for this problem, Racelogic has generated simulated RF data for the June 29 and 30, starting 15 minutes before midnight. The company has two sets of files — one set contains BeiDou-only signals and the other contains a combination of BeiDou and GPS signals. These scenarios are compatible with the LabSat3 triple-constellation simulator, which is available on a free 15-day loan or can be purchased from Racelogic.
LabSat engineers are also going to record the GLONASS signal on June 30 at midnight to see exactly how the system behaves.
@font-face {
font-family: “Cambria”;
}p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: “Times New Roman”; }div.Section1 { page: Section1; }