Some rtklib questions

Reach RS2 / RS2+ RTK / PPK configuration
1

I’ld like to better get used to RTKLib and understand/interprete it’s output.
(Main reason is I hope to do some additional tests to verify signal quality, as advised in Cycle slips? or not?)

I tried various sessions of postprocessing with different parameters to at least get similar results like other kind people who are helping out. For some reason, I often seem to choose sub-optimal settings.

Question1:
How to choose correct settings? Is it based on experience and interpretation of the setup/signal quality, or is it just trial/error/choose the ‘best’? (or reject what’s definitely wrong)
(Lately I’ve seen better results (fix-ratio) with L1-only vs L1+L2)

All screenshots below are from processing the logs of the thread I referred to above.
the blue (solution2)-data always is from the in-field-real-time solution logged by RS2 itself.
Note about the data: The RTCM-stream was provided by VRS over 3G connection, and the latter had outages up to 30 seconds.

Question 2:
During outage of the RTCM stream, the age of differential, is similar between the real-time and the post-processed data, as expected. But in a significant amount of the cases, it looks like the post-processed data somehow ‘finds data’ and it’s age of differential drops to 0. Is there an explanation for this? or is it a possible bug?
image image

Question 3:
While changing the parameters to get a ‘better fix ratio’, I only get more false fixes (compared to the in-field-solution which looks like the correct path). I don’t know if it’s coincidence, but this false fix is often obtained a very short time after the behaviour described in the previous question. (even with an outage of 2 seconds, where the post-processing doesn’t see the outage - maybe the data did arrive, just not in time…), and although it’s a false fix, it’s perfectly parallel with the true solution. Is this just because of the limited number of usable satellites?

image
image1445×641 19 KB

Question 4:
In RTKPost I can choose between L1/2/5, and in RTKPlot L1/2/7. Are 5 and 7 the same?
Also the PP-tutorial says Beidou is using L1&L7, but I only get data in RTKPlot for L2&L7

Question5:
The number of satellites in the real-time solution file is consistently ca 10 higher than when doing PP. Does the number have another meaning (also the ones filtered by SNR/elevation?), or is it really using more satellites?

PS. Sorry for the long post, tried to keep it organised (and I thought is was better than creating 5 topics)

2 Likes
3

Hi Andy,

In most cases, the standard settings from our guide should be enough. If the logs’ quality is poor, there are some settings you can play with to achieve better results.

The simplest ones are SNR and elevation masks that can help you exclude weak signals from calculations. Also, some frequencies indeed might be more affected than others. For example, L2-frequencies have a lower SNR than L1 in general. So, if data isn’t so good and you have a high SNR mask, L1-only results might be better than L1+L2.

The advanced settings such as Filter type and Integer Ambiguity Resolution can be changed as well. However, please note that it’s too hard to obtain the same results in PPK and RTK since these methods use different algorithms.

I can assume it might be because of the Integer ambiguity resolution type. We usually suggest using Fix-and-Hold or Continous modes. They are different, but both of them use several epochs to calculate a solution to make results less noisy. If you want to learn more about this option, I’d suggest reading the article from rtklibexplorer.

Did you enter the base’s coordinates during post-processing? It could happen if you left the “From RINEX header” option in the Positions Options tab. RINEX header doesn’t contain the real base position, and it’s just an averaged position. So, your PPK results just probably shifted.

RTKLib has its own notation of frequencies’ names. Just because there are frequencies from different constellations with the same name. For example, L7 stands for Beidou sats. However, in RTKPost, all frequencies our devices track are included in the L1+L2 option.

I know, it might be confusing a bit. Probably, we’ll find the solution for this in the future.

As I said above, RTK and PPK algorithms differ. So, they may use a different number of sats for calculations.

2 Likes
5

Thanks for the feedback. I’m often hitting the issue that PP- en RT-algorithms are different. I guess the combination of the non-static rover and it’s use in non-ideal locations is often meeting the limits of the RTKLib PP-algorithms.

No I didn’t enter the base position (was also a VRS), but I did verify it was correctly included in the rinex-header. Also only certain time-periods of the entire log was shifted, not the complete track.

7

Hi Andy,

Would you mind sharing the files for processing with me?

8

I tried to find the files I used when I started the topic, but I cannot find the rinex files with actual position in it, so I’ starting to doubt my statements.
I think it were the same logs refered in Cycle slips? or not? ( logs )

Anyway, I took some other random data and processed (same kind of VRS-NTrip-corrections and lot’s of cycle slips as well), but I saw similar results:
In blue the real-time position (almost constant fix result), the other line is the result of PP

image
image728×825 31.8 KB

As you can see some PP-‘Fixed’ trajectories are shifted towards North-West and some are shifted East. If it’s just the base, everything should have been shifted in the same direction I think. Correct?

As you can easily see from the position view, at the end the solution did converge to a correct fix, but the fixes at the beginning seem to be invalid (probably due to the cycle slips).

image
image997×646 55.3 KB

Here are the logs for these screenshots

9

What happens if you process the rover log in Single mode, so with no base correction?

10

Interesting idea… looks pretty good (red) vs the RTK-solution (mainly blue)

image
image1309×1087 35.8 KB

image
image1603×1042 60 KB

11

So the conclusion might be that RTKPost doesn’t like VRS-based correction?

12

How should VRS be handled differently? I thought it’s just a virtual base-station with carrier-phase info corrected/synced over the bases of the network.
Normally the NTRIP provider only calculates a new VSR-base when moving >5km away from the current base. In this case this shouldn’t be a problem. However I see some large values in the differential age, so maybe multple NTRIP sessions (and bases) ended up in the RTCM3-stream because of internet-connectivity issues.

And this could indeed explain the differently shifted segments.
Any way to see this in the RTCM-stream? (or could be detected by RTKConv?)
I thought RTKLib didn’t properly handle the huge amount of cycle-slips, but the ‘jumping base’ could be a more reasonable explanation.

tnx @wizprod, you really ask the good questions :slight_smile:

13

Tried finding a base-station nearby (I have just tried with VLIS of Euref (EUREF Permanent GNSS Network ) ) and processing your Base against it. Then you will see multiple positions.

VRS
VRS1478×1024 179 KB

15

Is there a way for RTKLib to handle ‘change of base’?
I’ll remember this as an advantage when choosing NRS-mountpoints instead of VRS, especially on not-so-stable internet connections.

16

As some way of learning I tried to produce the same results myself, so I downloaded the daily data from this same station and extrated it to a crx-file. I used RTKPost from emlid like this:
-observations from base (after converting the RTCM3-log of by NTRip provider)
-downloaded crx as corrections
-nav-file I generated with RTKCONV from the rover raw data during that same moment
image

I do get a similar view as yours, but all positions remain ‘single’ solution. (I tried with mode kinematic and static).
The statusbar also says it’s using a baseline of ca 40.9km, so I finds the reference-base (VLIS) position from the rinex. My guess is that RTKLib doesn’t find any correction data.
I downloaded the file for 2020/08/18 which I think is correct.
I never heard of the ‘COMPACT RINEX FORMAT’ (crx?), should I perform an additional conversion the get the real observations?

17

https://terras.gsi.go.jp/ja/crx2rnx.html

you can use this to uncompress

1 Like
19

Hi Andy,

For now, there is no such function in RTKLib. I need to research how base changing in VRS logs can be handled.

The only workaround, for now, is processing such logs in pieces. However, you should know the exact time spans for that.

21

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.