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

Use corrected pseduorange instead of raw? #19

Open
jt3232 opened this issue Sep 21, 2021 · 4 comments
Open

Use corrected pseduorange instead of raw? #19

jt3232 opened this issue Sep 21, 2021 · 4 comments
Labels
enhancement New feature or request

Comments

@jt3232
Copy link

jt3232 commented Sep 21, 2021

This program is lovely.

I have discovered that the pseudoranges are not very useful unless they are adjusted with the clock offset. Should/could we correct the pseudoranges on this program so that they are correct and will not give anyone the wrong idea?

It would be as simple as receiving the monitor_pvt.proto file, grabbing the user clock offset, and subtracting it from all pseudoranges.

Jaxon

@acebrianjuan
Copy link
Owner

Hi Jaxon (@jt3232),

This program is lovely.

Thank you very much! I am glad that you like it! :-)

I have discovered that the pseudoranges are not very useful unless they are adjusted with the clock offset. Should/could we correct the pseudoranges on this program so that they are correct and will not give anyone the wrong idea?

Yes, it can be done.

Just bear in mind that the purpose of gnss-sdr-monitor is to be a "viewer" of the GNSS-SDR internals, therefore the data that is streamed by the receiver is displayed "as is" in its rawest possible form. So I try to stick to this philosophy as much as I can, but contributions and feature requests from the community are very welcome too.

Would you care to elaborate why the raw pseudoranges are not useful/correct the way they are currently presented and how your suggestion would improve that?

I do appreciate your feedback.

Regards,
Álvaro

@acebrianjuan acebrianjuan added the enhancement New feature or request label Sep 21, 2021
@jt3232
Copy link
Author

jt3232 commented Sep 21, 2021

Thanks for the reply. Here are my thoughts:

The pseudoranges are perfect in the fact that they show the relative pseudoranges of each satellite. Thus, a user can determine which satellite is closer or farther away. However, these values can be extremely off from the actual value. In my case, using 4 different HackRF Ones, I have seen the pseudoranges more than 3000km off from the corrected value. Each HRF1 could be significantly different from each other, because they all have different clock offsets. Thus, if you adjust them all with their clock offset, the values will be significantly more meaningful as you can start to compare them relative to different receivers.

In my case, I thought the extremely significant difference in pseudoranges meant the HRF1s were not good enough for high precision purposes. However, they had accurate and similar positions amongst themselves.

I am rambling on here, but if someone like me comes along again and wants to verify the pseudoranges they see from the monitor program, they can rest assured knowing the values are very close to other receivers.

I could probably write something to make this happen, but I wanted to gauge interest to see if it would be worth it or not first.

Jaxon

P.S. I understand that you would want to keep the data in its rawest form.

@jt3232
Copy link
Author

jt3232 commented Sep 21, 2021

Okay, I may be wrong on this.

@jt3232
Copy link
Author

jt3232 commented Sep 21, 2021

There appears to be a setting called enable_rx_clock_correction on GNSS-SDR. This will change the pseudorange value. However, it appears that it does not make the pseudorange any more accurate.

My thought is that if that should have been correct, then changing the value by using the user_clk_error might not be the right way to go.

However, again, the user_clk_error is 0 when using that configuration parameter. Thus subtracting it won't change the pseudorange value in that instance.

I am conflicted here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants