UBX to RTCM timestamp conversion problem
Stefal opened this issue · comments
Some users noticed that when you use the F9P internal rtk engine, a "fix" is difficult when the rtcm stream comes from rtkbase, and easy if it comes directly from the F9P Rtcm messages (without any conversion inside RTKBase).
After some tests, i notices that the F9P rtcm output is on round second, but not always with str2str:
Rtcm from F9P:
Rtcm from str2str:
This article has some details on this issue.
The option -opt -TADJ=1 with str2str fix the issue but rtklibexplorer explains that a bug remains in the official rtklib release. It's a 3 years old article so I don't know if we need to switch from the official str2str to the rtklibexplorer release or not.
Legacy rtklib dosnt update anymore. I think rtklinexplorer is better because the bugs is more probable to get fixed in future
Hi!
rtklib 2.4.3 b33 isn't so old (11 months).
About the rtklibexplorer fork, I'm not sure if it will be maintained, as the author got a new job.
We need to test how a standalone f9p "fix" with the various solutions:
- tomojitakasu str2str
- tomojitakasu str2str + -opt -TADJ=1
- rtklibexplorer str2str
- rtklibexplorer str2str + -opt -TADJ=1
0c6e358 will add -tadj=1 on rtcm and ntrip outputs if a U-blox receiver is detected during the installation or when you use
sudo install.sh --detect-usb-gnss --configure-gnss
The -tadj=1 option works correctly. I'm closing this issue.
Sorry for re-opening this issue.
I've been using RTKBase since a week ago. I found the project pretty useful and amazing. Thanks in advance for this effort. I guess I found an issue that may be related with this thread and I wasn't sure whether to open a new one, so decided to use this one at first.
When I survey with my rover (ZED-F9P) using RTCM messages generated from, for example, Trimble CORS, I use to get fix solutions permanently (every epoch generates a fix solution). But when I use a matched receiver in the base operated with RTKBase, I find that the fix solutions are randomly (and temporarily) replaced by DGPS or Float solutions. Normally, the fix solutions comes back after a short period, maybe 2 seconds or so. Although the fix rate use to remain high, this behavior is somewhat confusing and generates uncertainty about the accuracy of the final result.
I've watched videos in which users show a 100% fix rate when using matched receivers as a base-rover set, so I was expecting to have the same result with my receivers and RTKBase.
Does the option -tadj=1 could be a source of delay in this case? Or maybe the conversion UBX -> RTCM delays the streaming and causes the solution to become unstable?
I will try to make manual tests streaming the RTCM corrections from the receiver directly through the NTRIP caster, but I wonder if this could also be an option within RTKBase.
Regards.
Hello again.
This is a follow-up on the message I posted yesterday. I guess that the issue was the update rate.
I use to set the update rate on my rover to 2 Hz, but since the base station is set by default to 1 Hz, maybe the rover couldn't get a consistent solution receiving RTCM messages at only 1 Hz. So, to solve this, I set the update rate of the base station to 2 Hz. However, I guess that if I set the rate on the rover to 1 Hz would have the same effect.
Hi!
I use my base station at 1Hz and my rover at 5hz without any problem.
There are more than 150 base station running with RTKBase in France, and you're the first one who report this. Your problem is probably elsewhere.
Since the latest release, you can enable your own caster inside RTKBase, maybe you can try that.
If you have more information to share about your issue, please create your own ticket.
Hi.
Thank you for your response. I'll try other solutions.