03-21-2012 09:58 AM
Is there a way to simulate the upcoming leap second on June 30, 2012 using the GPS Toolkit? The almanac format used by the toolkit does not support sufficient information to schedule the leap. Simulating the leap would only require changing a few bits in Page 4 Subframe 18 (UTC parameters in the transmitted almanac). Is there perhaps a way to edit the GPS data bitstream before modulation?
03-21-2012 10:39 AM
Currently, the provision for direct input of Leap second into the toolkit is not there.
Its taken via the Ephemeris file. Can you try changing the value in the ephemeris file and try ?If you also want the date change etc., those may need to be done in the ephemeris and almanac files as well.
Let me know if that works.
Would you mind sharing a little bit about your application ? I would be very interesting in learning about it.
03-21-2012 01:06 PM
My application is to test the behavior of a GPS receiver during the transition across the leap second. Leaps occur so infrequently that many systems have never experienced one and their behavior is not well characterized. Essentially, there are logical flows that have not been exercised and an excellent reason to use a simulator to verify them.
The first leap since 2008 is scheduled for the end of the day June 30, 2012, where the TAI-UTC offset will transition from 34 to 35 seconds and the GPS time-UTC offset will transition from 15 to 16 seconds.
Here is a link to a competitor's information on the subject:
Unfortunately, the ephemeris and almanac file formats used by the GPS Toolkit only include a value for the current leap second count. They do not allow us to specify the date and time of a leap nor do they have a way to specify whether the leap is forward or backward (unlikely, but possible).
In the satellite navigation message, subframe 4 page 18 contains the UTC parameters, among other things. The key values are WN_LSF, DN, delta_t_LS, and delta_t_LSF. The leap is already being announced in current satellite transmissions. The current values are WN_LSF=158 (GPS system week 1694 modulo 256, starting June 24, 2012), DN=7 (day=Saturday, June 30), delta_t_LS=15 (GPS/UTC offset before the leap), and delta_t_LSF=16 (offset after the leap).
The toolkit probably just fills in both delta_t_LS and delta_t_LSF with the leap count from the almanac file. Since both values are the same, the synthesized message indicates no leap is scheduled. To test a receiver across the leap transition, one would need to set the simulation date to, say, noon UTC on June 30 and then substitute the values above into the subframe 4 page 18 data. The GPS receiver should insert an extra second at the end of the day such that the UTC time follows the sequence 23:59:58, 23:59:59, 23:59:60, 00:00:00, 00:00:01... Some GPS receivers might repeat 23:59:59 rather than calling the extra second 23:59:60, but all the times before and after should match. As you can imagine, this behavior can wreak havoc on timekeeping systems, hence the desire to test before it happens in the real world.
So, since the GPS Toolkit does not provide an interface to set the leap date and value, I'm hoping that there might be an intermediate step in the processing when the GPS navigation messages can be modified before modulation.
03-26-2012 10:21 AM
Apologies for the delay in the response. Its a tricky situation. You are correct about the limitations of the ephemeris and almanac files not providing the parameters like T_LSF etc. In the absence of those the toolkit does not give much significance to the changing leap second problem.
There is currently no plan on an official release of the toolkit.
But, can you please drop me an email at sastry.vadlamani[AT]ni.com. We can discuss to see if a couple of VIs be provided that can enable you to test this problem.
I look forward to an email from you.