-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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. |
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? |
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:
|
Hi astrodanco, David |
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” |
I believe he means: DELTA TLS = the current leap seconds offset (often called tLS as well) |
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. |
RTCM MT14 week rollover problem is fixed in 2.4.2 p10. See No.119. |
[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.
const static double leaps[][7]={ /* leap seconds {y,m,d,h,m,s,utc-gpst,...} */ |
- 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
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
The text was updated successfully, but these errors were encountered: