Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTKLIB and leap second #37

Closed
zuliani71 opened this issue Jul 17, 2014 · 9 comments
Closed

RTKLIB and leap second #37

zuliani71 opened this issue Jul 17, 2014 · 9 comments

Comments

@zuliani71
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link
Author

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
Copy link
Author

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

David

@astrodanco
Copy link

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
Copy link

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
Copy link
Owner

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
Copy link
Owner

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

This was referenced Jan 27, 2015
@DavidKelleySCSC
Copy link

[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}, . . .

olivierdalang pushed a commit to olivierdalang/RTKLIB that referenced this issue Apr 26, 2020
- Fix potential mem leak in obs/nav (Issue tomojitakasu#37)
- Fix minor bug in rtkrcv makefile
- Switch all Embarcadero project versions from 18.2 to 18.4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants