-
-
Notifications
You must be signed in to change notification settings - Fork 122
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
UBX to RTCM timestamp conversion problem #80
Comments
Legacy rtklib dosnt update anymore. I think rtklinexplorer is better because the bugs is more probable to get fixed in future |
Hi! We need to test how a standalone f9p "fix" with the various solutions:
|
I've added an entry in the forms to add receiver dependent options: 653efcf |
0c6e358 will add |
The |
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 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! 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. |
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.The text was updated successfully, but these errors were encountered: