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

RTKNAVI RTCMv3 rover and IGS SSR corrections NTRIP stream leads to BDS not being used #156

Open
Isaac0H0E opened this issue Sep 28, 2023 · 1 comment

Comments

@Isaac0H0E
Copy link

Isaac0H0E commented Sep 28, 2023

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=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.

RTKNAVI_configuration_file.zip

Best regards

Isaac @ Rokubun.

@Isaac0H0E
Copy link
Author

Isaac0H0E commented Sep 29, 2023

image

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

1 participant