rtklibexplorer / RTKLIB

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.
http://rtkexplorer.com/
Other
675 stars 263 forks source link

RTKCONV - satellite number error - in rtkconv.trace #113

Closed StefanCiesilski closed 1 year ago

StefanCiesilski commented 2 years ago

Hello, i use rtkconv.exe from demo5_b34f1 to convert the raw observation file from a dji phantom 4 rtk. The file is in rtcm3. Debug level 2

In the rtkconv.trace is this error:

2 rtcm3 1045 satellite number error: prn=37 2 scan_file: sys=0 code=1C type=15 2 scan_file: sys=0 code=2W type=15

I add the file. Is it a real error?

Thanks for looking

rtkconv.zip 100_0038_PPKRAW.zip

vbnhu commented 2 years ago

I also noticed an error with RTKCONV (demo5 b34f1): the time between measurement epochs is 1 second in the .obs file even though my raw .ubx file is with 5Hz. I tried the conversion with demo5 b34c, where everything seems to be working fine, resulting in a 5Hz .obs.

rtklibexplorer commented 2 years ago

Re DJI navigation message:

I believe this is a problem with the DJI raw navigation messages which I have seen before. Here is my response to a similar inquiry :

"As far as I can tell the RTKLIB code is OK and the issue is in the raw data file. For example I see messages for Galileo sat #41 which RTKLIB rejects since it is an invalid satellite number. I can manually decode this field from the raw binary file and confirm that it is coded that way in the message. I have also verified that RTKLIB is correctly decoding 1045 messages from other sources.

Something else though that may be related to the problem you are seeing is that the 1045 RTCM3 message is for the F/NAV ephemeris data which is used for the Galileo E5a signal. Your receiver is tracking the E5b signals and should be sending the 1046 RTCM3 messages which have the I/NAV messages for E5b. The ephemeris data itself should mostly be independent of the signal but there are some clock values that are not, so part of the problem may be that RTKLIB is not smart enough to know that the 1045 messages have incomplete ephemeris data for the E5b signal, is leaving some values uninitialized since they are not in the 1045 message, but then not rejecting the satellite from the solution since it recorded that it has ephemeris data for that satellite.

Is there an option to enable the 1046 message out of your receiver? I don't believe it can even generate a valid 1045 message since it is supposed to include the F/NAV message data which is only transmitted on E5a.

To add more confusion, it looks like the 1045 and 1046 messages were only finalized quite recently and there was confusion about their definition before that. Here's a link regarding RTKLIB and these two messages which describes the confusion but claims RTKLIB should properly support the 1046 message starting in 2018:

https://github.com/tomojitakasu/RTKLIB/issues/233

Here's an explanation of the I/NAV and the F/NAV messages from Navipedia:

https://gssc.esa.int/navipedia/index.php/Galileo_Navigation_Message

and here's a link of the latest list of RTCM3 messages from April 2020 which describes the difference between 1045 and 1046

https://www.use-snip.com/kb/knowledge-base/rtcm-3-message-list/

rtklibexplorer commented 2 years ago

Re 1 sec epochs:

This is an unfortunate side effect of a choice I made to change the default settings for RTKCONV in the b34f release to resolve an issue other users were having with the default settings when using the "Interval" option. I will sort this out properly in the next release but for now I have added an rtkconv.ini file to the b34f release to override the default setting with the previous value. To resolve the issue without downloading the new zip file, you can either copy the rtkconv.ini file from a previous release, or change the "Time Tolerance" option in the Options menu from 1.0 to the original value of 0.005. Note that you must select the "Interval" box on the main RTKCONV window first to enable access to this setting.

By the way, I appreciate the detailed feedback. There are far too many possible configurations in RTKLIB for me to test them all in each release so I do rely on feedback from users to find and correct the issues that I miss.

vbnhu commented 2 years ago

Thanks a lot! The rtkconv.ini solution works (also it is possible to manually edit the .ini file)! On the other hand the "Time Tolerance" option remains grey and read only in the Options menu regardless what I click or select.

StefanCiesilski commented 2 years ago

Thanks a lot!