RTKLIB and leap second

[zuliani71]

Dear group,
can you help me to understand how rtklib handles the leap second issue? Currently most GNSS networks provide RTK streams with RTCM TYPE 14 enabled. That type helps with the GPS time. Is rtklib able to recognize that type?
Bye
David

[tomojitakasu]

The new leap second info is not always obtained in any way. The current version handles the leap seconds by using a hard-coded UTC-GPST table in rtklib/src/rtkcmn.c. If a new leap second expected, user should update RTKLIB to a new version.

[astrodanco]

I do hope you don’t mean that DELTA TLS from the receiver (raw->nav.leaps) is never used. (It is undersood that until and unless that comes in from the data stream, RTKLIB must rely on a hard-coded value.)

I did notice that there didn’t seem to be anywhere in the RAW structure to place DELTA TLS F or WN SUB LS F info for the pending near future leap second. I wonder if RTKLIB could/should somehow make use of those when/where available?

[zuliani71]

Hi tomojitakasu, thanks for answering. Currently I brodcast RTCM messages over NTRIP from our GNSS permanent site network (we use a GNSMART Caster). I usually issue the the following RTCM2.3 types:

• 3,22
• 18/19
• 14
  14 is the GPS Time of Week used by different professional GNSS receivers as a time reference just to skipp the leap issue. Is rtklib able to recognize type 14? Importing inside rtklib the RTCM mountpoints with type 14 enabled always lead the observations to a wrong date (it jumps from year 2014 to year 1994).
  David

[zuliani71]

Hi astrodanco,
sorry but I don't know the terms you've used: DELTA TLS and WN SUB

David

[astrodanco]

sorry but I don't know the terms you've used: DELTA TLS and WN SUB

From IS-GPS-200E: “…value of the delta time due to leap seconds (tLSF), together with the week number (WNLSF) and the day number (DN) at the end of which the leap second becomes effective. "

Sorry, I can’t get the delta symbol to display properly and the subscripts may not either. GPS signal page 18 of subframe 4, delta symbol, “t”, subscript “LSF” and “WN” subscript “LSF”

[DavidKelleySCSC]

I believe he means: DELTA TLS = the current leap seconds offset (often called tLS as well)
as for "WN SUB LS F" I do not know but as all this exists in the sub frame messages of the nav data, perhaps it means that. Consult the ~200 systems spec and you will see these values, the key point is that a time, in GPS weeks and TOW is send out well in advance of the moment of change, and because the value can move +- the new offset to becomes effect is sent. From this the rover knows when to change over with extreme precision, but of course a few lower cost rovers do this poorly.
I looked for that term on-line and I found a rather nice explanation of the general process from Spirent at the below link that may help:
http://www.spirent.cn/~/media/Application%20notes/Positioning/Simulating_UTC_Leap_Second_Insertion_Events_AppNote.pdf
I would echo astrodanco's comment that this would be good to add to the raw struc. Even if you do not want to process the message content, a placeholder value would be of help.

[tomojitakasu]

The leap seconds information is not always available in real-time receiver streams. The lack of leap second information is not fatal. It is usually only used for UTC-GPST conversion. So current RTKLIB does not import any external sources of leap seconds. Of course, miss-understanding is critical for GLONASS data handling. RTCM MT14 is already supported but the current version seems to have a 10-bit-week rollover problem. It will be fixed in future patches.

[tomojitakasu]

RTCM MT14 week rollover problem is fixed in 2.4.2 p10. See No.119.
http://www.rtklib.com/rtklib_support.htm

[DavidKelleySCSC]

[Posted July 1st when I noticed I was using several older copies of RTKLIB...]

Can we get yesterday's Leap Sec event added and then the Borlan code respun for the windows side? Know how to fix this in the raw code, but the RTKLIB GUI is a great tool for every day use.
I am somewhat embarrassed to say I can not update and build the Windows GUI tools here. If I am just behind the times and this was added early this please ,please let me know what release point it was point in at.

From tomojitakasu
The current version handles the leap seconds by using a hard-coded UTC-GPST table in rtklib/src/rtkcmn.c.

const static double leaps[][7]={ /* leap seconds {y,m,d,h,m,s,utc-gpst,...} */
Please Add: --> (2015,7,0,0,0, -17) <--
{2012,7,1,0,0,0,-16},
{2009,1,1,0,0,0,-15},
{2006,1,1,0,0,0,-14}, . . .