As reported by GPS World: During preparation of playback scenarios for the upcoming leap-second event taking place in June, engineers at Racelogic
identified a potential pitfall for GNSS engineers.
The difficulty arises from the fact that BeiDou uses a different “day number” for the date to apply the leap second, compared with GPS and Galileo. GPS and Galileo use 1-7 as week day numbers, and BeiDou uses 0-6.
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, said Mark Sampson, product manager for Racelogic.
“We tested four different Beidou enabled receivers, from four leading GNSS companies, and none of them appeared to handle the Beidou leap second correctly. This included an engine which originates from China!” Sampson said. “We have since been in contact with two of these companies, who have 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 of this year. In some cases, the BeiDou leap second will be adjusted from 2 to 3 seconds from midnight on June 29, which should in fact occur on midnight of June 30. This will result in an error for the reported UTC time of 1 second for the period of this day. In other cases, the leap second was not implemented at all when running on BeiDou alone.
“We have also checked the output of a BeiDou signal generator from a different simulator company, and this too uses the 1-7 range for the BeiDou leap-second date instead of the correct 0-6 range,” Sampson said. “This may explain why a number of commercial receivers appear to have been caught out by this issue.”
In order to help companies test for this problem, Racelogic has generated simulated RF data for June 29 and 30, starting 15 minutes before midnight. “We have two sets of files. One set contains BeiDou only signals and the other contains a combination of BeiDou and GPS signals,” Sampson said. “Note that on some of the receivers we have tested, when GPS is being tracked as well, the GPS leap-second message overrides the one coming from BeiDou and applies the leap second correctly.”
The scenarios are compatible with Racelogic’s LabSat3 triple constellation simulator, which is available on a free 15-day loan or can be purchased from Racelogic.
The difficulty arises from the fact that BeiDou uses a different “day number” for the date to apply the leap second, compared with GPS and Galileo. GPS and Galileo use 1-7 as week day numbers, and BeiDou uses 0-6.
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, said Mark Sampson, product manager for Racelogic.
“We tested four different Beidou enabled receivers, from four leading GNSS companies, and none of them appeared to handle the Beidou leap second correctly. This included an engine which originates from China!” Sampson said. “We have since been in contact with two of these companies, who have 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 of this year. In some cases, the BeiDou leap second will be adjusted from 2 to 3 seconds from midnight on June 29, which should in fact occur on midnight of June 30. This will result in an error for the reported UTC time of 1 second for the period of this day. In other cases, the leap second was not implemented at all when running on BeiDou alone.
“We have also checked the output of a BeiDou signal generator from a different simulator company, and this too uses the 1-7 range for the BeiDou leap-second date instead of the correct 0-6 range,” Sampson said. “This may explain why a number of commercial receivers appear to have been caught out by this issue.”
In order to help companies test for this problem, Racelogic has generated simulated RF data for June 29 and 30, starting 15 minutes before midnight. “We have two sets of files. One set contains BeiDou only signals and the other contains a combination of BeiDou and GPS signals,” Sampson said. “Note that on some of the receivers we have tested, when GPS is being tracked as well, the GPS leap-second message overrides the one coming from BeiDou and applies the leap second correctly.”
The scenarios are compatible with Racelogic’s LabSat3 triple constellation simulator, which is available on a free 15-day loan or can be purchased from Racelogic.
No comments:
Post a Comment