A version of RTKLIB optimized for low cost GNSS receivers, especially u-blox receivers. It is based on RTKLIB 2.4.3 and is kept reasonably closely synced to that branch. This software is provided “AS IS” without any warranties of any kind so please be careful, especially if using it in any kind of real-time application.
Today we came to a estrange situation were if RTKNAVI Windows GUI, versions demo5 b34h as well as Tomoji Takasu 2.4.3 b34, are provided with a Septentrio Mosaic X5 RTCMv3 TCP stream, as rover, plus an IGS RTCMv3 over NTRIP caster feed (products.igs-ip.net:2101), SSRA00CNE1 for instance (but happens with any IGS BDS capable stream), the BeiDou PRNs are never used in the RTKNAVI positioning solution.
After some analysis of the trace files we came to the conclusion that RTKNAV considers that:
2 no ssr orbit correction: 2023/09/28 09:00:00 sat=55 3 no ephemeris 2023/09/28 08:59:59.936 sat=55 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=110 3 no ephemeris 2023/09/28 08:59:59.867 sat=110 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=111 3 no ephemeris 2023/09/28 08:59:59.869 sat=111 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=114 3 no ephemeris 2023/09/28 08:59:59.869 sat=114 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=121 3 no ephemeris 2023/09/28 08:59:59.866 sat=121 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=124 3 no ephemeris 2023/09/28 08:59:59.927 sat=124 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=125 3 no ephemeris 2023/09/28 08:59:59.925 sat=125 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=127 3 no ephemeris 2023/09/28 08:59:59.916 sat=127 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=134 3 no ephemeris 2023/09/28 08:59:59.925 sat=134 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=135 3 no ephemeris 2023/09/28 08:59:59.911 sat=135 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=137 3 no ephemeris 2023/09/28 08:59:59.910 sat=137 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=140 3 no ephemeris 2023/09/28 08:59:59.925 sat=140 3 no broadcast ephemeris: 2023/09/28 09:00:00 sat=142 iode= -1 3 no broadcast clock 2023/09/28 08:59:59.909 sat=142 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=144 3 no ephemeris 2023/09/28 08:59:59.865 sat=144 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=149 3 no ephemeris 2023/09/28 08:59:59.914 sat=149
After a bit of further analysis of RTKNAVI monitor GUI we realized that the reported IOD values for the rover BDS navigation message are all set to either 0 or 1 but if we check the decoded RTCM SSR stream IODs al have sensible values so it is our understanding that RTKNAVI doesn't find SSR corrections because the rover BDS IODs are all set to 0/1 instead of the correct value.
Instead of using RTCM format for the rover we also tried to use SBF over TCP and we obtained the same result, the BDS IODs are all set to 1/0.
This same issue has been reproduced in different days meaning that the RTKNAVI behavior seems to be repeatable irrespective of the moment of the day.
As a last double check we also saw an identical situation using a third party EUREF non Septentrio GNSS base station supporting BDS and transmitting observations and navigation data in RTCMv3.
Isaac0H0E
commented
11 months ago
Dear Tim et al.,
Today we came to a estrange situation were if RTKNAVI Windows GUI, versions demo5 b34h as well as Tomoji Takasu 2.4.3 b34, are provided with a Septentrio Mosaic X5 RTCMv3 TCP stream, as rover, plus an IGS RTCMv3 over NTRIP caster feed (products.igs-ip.net:2101), SSRA00CNE1 for instance (but happens with any IGS BDS capable stream), the BeiDou PRNs are never used in the RTKNAVI positioning solution. After some analysis of the trace files we came to the conclusion that RTKNAV considers that:
2 no ssr orbit correction: 2023/09/28 09:00:00 sat=55 3 no ephemeris 2023/09/28 08:59:59.936 sat=55 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=110 3 no ephemeris 2023/09/28 08:59:59.867 sat=110 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=111 3 no ephemeris 2023/09/28 08:59:59.869 sat=111 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=114 3 no ephemeris 2023/09/28 08:59:59.869 sat=114 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=121 3 no ephemeris 2023/09/28 08:59:59.866 sat=121 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=124 3 no ephemeris 2023/09/28 08:59:59.927 sat=124 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=125 3 no ephemeris 2023/09/28 08:59:59.925 sat=125 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=127 3 no ephemeris 2023/09/28 08:59:59.916 sat=127 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=134 3 no ephemeris 2023/09/28 08:59:59.925 sat=134 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=135 3 no ephemeris 2023/09/28 08:59:59.911 sat=135 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=137 3 no ephemeris 2023/09/28 08:59:59.910 sat=137 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=140 3 no ephemeris 2023/09/28 08:59:59.925 sat=140 3 no broadcast ephemeris: 2023/09/28 09:00:00 sat=142 iode= -1 3 no broadcast clock 2023/09/28 08:59:59.909 sat=142 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=144 3 no ephemeris 2023/09/28 08:59:59.865 sat=144 2 no ssr orbit correction: 2023/09/28 09:00:00 sat=149 3 no ephemeris 2023/09/28 08:59:59.914 sat=149After a bit of further analysis of RTKNAVI monitor GUI we realized that the reported IOD values for the rover BDS navigation message are all set to either 0 or 1 but if we check the decoded RTCM SSR stream IODs al have sensible values so it is our understanding that RTKNAVI doesn't find SSR corrections because the rover BDS IODs are all set to 0/1 instead of the correct value.
Instead of using RTCM format for the rover we also tried to use SBF over TCP and we obtained the same result, the BDS IODs are all set to 1/0.
This same issue has been reproduced in different days meaning that the RTKNAVI behavior seems to be repeatable irrespective of the moment of the day.
As a last double check we also saw an identical situation using a third party EUREF non Septentrio GNSS base station supporting BDS and transmitting observations and navigation data in RTCMv3.
RTKNAVI_configuration_file.zip
Best regards
Isaac @ Rokubun.