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

UBX to RTCM timestamp conversion problem #80

Closed
Stefal opened this issue Jul 3, 2020 · 9 comments
Closed

UBX to RTCM timestamp conversion problem #80

Stefal opened this issue Jul 3, 2020 · 9 comments

Comments

@Stefal
Copy link
Owner

Stefal commented Jul 3, 2020

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:
image

Rtcm from str2str:
image

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.

@iceberg1369
Copy link

Legacy rtklib dosnt update anymore. I think rtklinexplorer is better because the bugs is more probable to get fixed in future

@Stefal
Copy link
Owner Author

Stefal commented Jul 3, 2020

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

@Stefal
Copy link
Owner Author

Stefal commented Jul 12, 2020

I've added an entry in the forms to add receiver dependent options: 653efcf

image

@Stefal
Copy link
Owner Author

Stefal commented Jul 15, 2020

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

@Stefal
Copy link
Owner Author

Stefal commented Dec 31, 2020

The -tadj=1 option works correctly. I'm closing this issue.

@Stefal Stefal closed this as completed Dec 31, 2020
@geofis
Copy link

geofis commented Sep 10, 2021

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.

@geofis
Copy link

geofis commented Sep 11, 2021

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.

@Stefal
Copy link
Owner Author

Stefal commented Sep 11, 2021

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.

@geofis
Copy link

geofis commented Sep 12, 2021

Hi.

Thank you for your response. I'll try other solutions.

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

3 participants