tomojitakasu / RTKLIB

2.5k stars 1.59k forks source link

Drops NTRIP GPS signal if RTCM 1004 sync=1 #104

Open MagnusAn opened 9 years ago

MagnusAn commented 9 years ago

I'm having problems to get GPS observations from NTRIP caster that sends both GPS and GLONASS. This seems to generate RTCM 1004 that ends with sync=1 (Synchronos GNSS Flag), and next 1012 is GLONASS with sync=0.

Found this old issue, that seems identical but for RTKLIB 2.2.1: http://gpspp.sakura.ne.jp/rtklib/rtklib_2.2.1_support.htm No.12

GPS data is decoded fine with 2.2.1 (with patch) and 2.2.2. Then from 2.2.3 (with added GLONASS support), I can't get any reading for GPS. GLONASS readings works fine, but GPS data seems to be droppped.

I tried some ugly hacks like apply the old fix by adding "sync=0;" in rtcm3.c decode_head1001, but it doesn't give a stable result and GPS-data start to flicker. Then I tried changing rtcm->obsflag=!sync to rtcm->obsflag=1 in rtcm3.c function decode_type1004. This solve my issue when I only need GPS data, but it drops GLO data instead.

Example stream is: www.igs-ip.net:2101 Mountpoint: ONS11

Am I doing something wrong, or is this an issue? I've seen some screenshots where other people doen't seem to have this problem, but when I try the same stream, I wont work for me.

DavidKelleySCSC commented 9 years ago

This smells like a time sync issue. What version is in use and is the last leap second corrected or patched?

In "uncorrected" code, used past the last leap second (ie now) the RTKLIB code will detect the change in time in GLO as a new new measurement epoch. Because, by convention, GLO is sent after GPS (and as the last measurement the sync bit is set indicating no more measurements), RTKLIB will will this into the OBS_t array and overwrite the GPS data. Hence you "lose" GPS observations.

I have a co worker here that detailed this better with all the function called involved names, will find and post, but that seems to be what you are seeing. Patch the code and the problem should go away. Regards, David Kelley

On 9/3/2015 6:01 AM, MagnusAn wrote:

I'm having problems to get GPS observations from NTRIP caster that sends both GPS and GLONASS. This seems to generate RTCM 1004 that ends with sync=1 (Synchronos GNSS Flag), and next 1012 is GLONASS with sync=0.

Found this old issue, that seems identical but for RTKLIB 2.2.1: http://gpspp.sakura.ne.jp/rtklib/rtklib_2.2.1_support.htm No.12

GPS data is decoded fine with 2.2.1 (with patch) and 2.2.2. Then from 2.2.3 (with added GLONASS support), I can't get any reading for GPS. GLONASS readings works fine, but GPS data seems to be droppped.

I tried some ugly hacks like apply the old fix by adding "sync=0;" in rtcm3.c decode_head1001, but it doesn't give a stable result and GPS-data start to flicker. Then I tried changing rtcm->obsflag=!sync to rtcm->obsflag=1 in rtcm3.c function decode_type1004. This solve my issue when I only need GPS data, but it drops GLO data instead.

Example stream is: www.igs-ip.net:2101 http://www.igs-ip.net:2101 Mountpoint: ONS11

I'm I doing something wrong, or is this a issue? I've seen some screenshots where other people doen't seem to have this problem, but when I try the same stream, I wont work for me.

— Reply to this email directly or view it on GitHub https://github.com/tomojitakasu/RTKLIB/issues/104.

MagnusAn commented 9 years ago

Before I wrote this issue i ran 2.4.3b5 and it won't work. But now I tried 2.4.2_p11, and it works perfectly with both GPS and GLO! I thought that 2.4.3 had the latest patches, but I realized by the dates that 2.4.2_p11 was more recently changed.

Thanks for getting me on the right track! Is this a issue worth keeping for 2.4.3, since it doesn't work?

DavidKelleySCSC commented 9 years ago

Is this a issue worth keeping for 2.4.3, since it doesn't work? That call is up to tomojitakasu but as people keep downloading the Windows stuff, I would think yes. See also https://github.com/tomojitakasu/RTKLIB/issues/97 as the start of that thread relates to a means to change the code base to deal with this and Takasu-sans reply.