OK, I’ve processed your log files above as per the docs except as noted, and I used a fresh copy of the RTKLIB software downloaded from the links in the docs.
rtkconv.exe - Converting from raw to RINEX:
In settings, I added Scan Obs Types as recommended in the RTKLIB manual.
rtkplot.exe - Viewing the RINEX data graphically:
In settings, I set: Cycle-Slip to LLI Flag; Ephemeris to ON; and checked every satellite system.
The base observation was:
- ~3 hours long
- included these satellite systems: GPS, GLO, QZSS, SBAS
- updating at 5Hz
Below, where you see a red line, it is a cycle slip which is not good. What is not good is that it takes time to recover from it, which is to say that a cycle slip can delay or disrupt the fix. So, the first thing is to try and find a straight section of orange with no red. There must be a minimum of 5 satellites of the same constellation (all G or all R, etc.) that all have straight orange with no red. The SBAS satellites can be included as well ( e.g. 128).
Here is the satellite visibility graph (Sat Vis):
From the above, I get three really long periods of time with at least six satellites and they are:
- 00:32 → 01:19
- 6 satellites: G05, G13, G15, G17, G28, G30
- 01:10 → 01:36
- 7 satellites: G05, G13, G15, G17, G19, G28, 128
- 01:57 → 03:12
- 6 satellites: G13, G15, G17, G19, G24, 128
Now, switching over to the elevation graph (SNR/MP/EL) for G satellites. The SBAS 128 satellite did not have good enough SNR, so I didn’t show a graph for it. Anyhow, now we look for a period of time with a minimum of 5 satellites preferably showing GREEN which indicates the strongest signal-to-noise ratio (SNR):
Unfortunately there is very little green here, so we will use green and orange (45+dB and 40-45dB). We are looking within the periods of time mentioned above for 5+ satellites green and orange and preferably for 5 minutes or more. This is what I saw:
- 00:54 → 00:58
- 01:08 → 01:17
- 02:49 → 02:57
I pushed my stated parameters a little bit to get those numbers. You can see that our windows of opportunity have narrowed quite a lot. Now we must look at the rover and do the same thing.
The rover observation was:
- ~1.5 hours long
- included these satellite systems: GPS, GLO, QZSS, SBAS
- updating at 5Hz
Here is the satellite visibility graph (Sat Vis):
From the above, I get five short to moderate periods of time with at least five satellites and they are:
- 01:40 → 01:57
- 5 satellites: G13, G15, G17, G19, G28
- 01:50 → 02:11
- 5 satellites: G13, G15, G17, G19, G24
- 02:06 → 02:20
- 6 satellites: R07, R08, R09, R16, R18, R19
- 02:21 → 02:41
- 5 satellites: R08, R09, R16, R18, R19
You will notice that these last two time periods are for the GLONASS system. Unfortunately, the base observations did not produce any favorable GLONASS results as per my criteria, so this limits our opportunity for an RTK fix to the upper two time periods.
Here is the elevation graph (SNR/MP/EL) for G satellites:
It is the same story here with very little green, so we are looking for green and orange again, and these are the time periods I found:
- 02:29 → 02:43
- 02:59 → 03:03
Final analysis:
Now we compare the time periods between the base and rover, and the closest ones are:
- rover: 02:29 → 02:43
- base: 02:49 → 02:57
- rover: 02:59 → 03:03
Unfortunately there is no overlap whatsoever. If we had even 5 minutes of overlap to work with, then we would have been able to say that a fix should occur at this time. So, by coarse visual analysis I can not confidently say that this set of log files should produce a good fix.
At the same time I’m not saying that this log can’t produce a good fix, it is just not obvious to me based on the factors I know of that will produce a good fix.
- 5+ satellites in common
- those satellites all from one constellation (e.g. GPS only or GLO only)
- all satellites with 40+dB SNR
- the satellites are spread out in the sky (e.g. not all in a cluster directly overhead)
- minimum 5 minutes of good data with no cycle slips
One other thing I should mention is that what I just mentioned above is what I believe is needed to acquire the fix. Once the fix is acquired, some degradation of those parameters is tolerable. For example, if one of the main satellites drops out, that fix can still be maintained with the assistance of other satellites; perhaps it could one from the same constellation that has recently come into view, or perhaps it could be one from other constellations (GAL, QZSS, etc.), or it could be several of those.
The other thing is you should take this analysis with a grain of sand. It is not absolute, because there are still other factors at play. My analysis was done with a coarse view of the data, so there could be more opportunities for a fix or there could be less. I am also by far not the most knowledgeable person to be doing this analysis.
Disclaimers now aside, I will post-process the logs and we’ll see what the outcome is.
rtkpost.exe - post-processing from RINEX to a solution file
Here are the settings I used:
Positioning Mode set to Kinematic
Frequencies / set to L1
All satellite systems were turned ON (checked)
Integer Ambiguity Res set to Fix and Hold
/ AR Filter set to ON
For lack of a known point as a base coordinate, for Base Station location, I used RINEX Header Position.
rtkplot.exe - analyzing the position file after post-processing is complete
This is the outcome. I think we will all be surprised by the result (GREEN = fix; YELLOW = float):
The top graph shows the number of satellites used and the bottom graph shows the ambiguity resolution ratio. In rtkpost.exe options - Setting2 tab, the default setting for Min Ratio to Fix Ambiguity is 3. When it the ratio rises above 3, then RTKLIB switches from float to fix mode.
We see that almost instantly the solution is fixed. This means if we go back and look to the start of the rover log, there is some good portion of the logs that got overlooked in the analysis. The very start has some movement and there is a strange jump in satellite elevation, so those couple of minutes should be ignored. It could be that the GPS time was updated or maybe a new ephemeris was loaded and that caused the jump. Anyhow, lets just take a moment to understand what helped this early fix happen.
The first thing is that rtkpost.exe has the advantage of already having the ephemeris data loaded, and the Reach RS rover that was just turned on must wait for it to be received from the satellites, or on this case you had RTCM3 ephemeris messages enabled which would speed that up, but waste bandwidth afterward. The second thing is that our settings for rtkpost.exe are not the same as were set in the Reach RS rover. The comparison is:
- Minimum satellite elevation above horizon (Elevation Mask)
- rtkpost.exe, 15 : Reach RS, 25
- Minimum signal to noise ratio (SNR Mask)
- rtkpost.exe, none : Reach RS, 35
So let’s make it a bit more fair by adjust those last two settings in rtkplot.exe to match the settings that were used on the Reach RS.
Here is the graph of the number of satellites used and the bottom graph shows the ambiguity resolution ratio (GREEN=fix; YELLOW=float):
Now we have lost the fix almost entirely. So for this particular log, one or both of those settings were pretty crucial to the outcome. I’ll leave it as an exercise for you to determine which it was.
Before we say that is it, I’m going to try one more option. That is post-processing the base corrections as received by the rover instead of using the base’s raw log. This will make our result even closer to that of the solution of the Reach RS.
The RTCM3 correction data received by the rover was:
- ~1.5 hours long
- included these satellite systems: GPS, GLO, SBAS
- updating at 1Hz
Here is the result of post-processing with the rover’s received RTCM3 corrections and settings as close as I can make it to how the Reach RS was set:
- Elevation mask: 25
- SNR mask: 35
- Integer Ambiguity Res: Continuous
See the age of differential? With your Reach RS so close together, you should get good reception at max speed that was set (18kb/s). The tall spiked indicate a problem. The frequency is set at 1Hz on your base, and the rover is getting the messages at 1Hz, but everywhere there is a spike longer than about 2 seconds that indicates a problem.
Quick math: Your RTCM3 log was 1918692 bytes long, and the length of time was 1h:35m. That equates to 20.1kb/s which is actually a little faster than advertised for max LoRa bandwidth. This means the data link was fully saturated which caused RTCM3 message delivery delays. To eliminate unnecessary data transmission and reduce the saturation of radio bandwidth, choose the settings recommended here:
And here is another run also using the RTCM3 corrections, but with the settings tweaked:
- Elevation mask: 15
- SNR mask: 30
- Integer Ambiguity Res: Fix and Hold
So the above settings produced 38 minutes of solid fix, plus a little more. Which is pretty good. Now, if the RTCM3 messages had been set as mentioned above then it is likely that the result could have been even better.
Now, here is a post-processed solution (PPK) like it would be done at the office:
- Elevation mask: 15
- SNR mask: 30
- Integer Ambiguity Res: Continuous
- Filter type: Combined (instead of only Forward)
Continuous mode is constantly evaluating itself, which is better suited for PPK, I think. Fix-and-hold is purposely a bit over-confident which helps get through troubled times while holding onto that fix. That I think is better for RTK. Anyhow this last solution is 75% fixed and here’s is where the fix is concentrated:
It is all mostly in a 2cm by 6cm rectangle which is really good for what we had to work with.
Conclusion:
If the overall SNR is low, then consider dropping the SNR mask a bit to let more satellites contribute to the solultion. Make sure the radio is set so that it is not overworked. Use fix-and-hold AR mode when doing RTK for more fixes. Consider using continuous AR mode when doing PPK for more confidence and a tighter group of fixes. Try your best to keep the SNR up in the green if you can. Turn the rover on as early as possible so that it can listen for ephemeris data from the satellites and be able to fix quicker.
One other point to mention is that I had thought the GLONASS data was not good enough to provide a fix, but in fact it was. I ran post-processing without GPS satellites and GLONASS was able to fix early on. I also did the reverse by eliminating GLONASS, and GPS was able to fix early on as well.
Also, in this whole post, I have only focused on acquiring a fix and I have not touched upon the quality of the fix that was produced. The quality of the result is a whole other subject to look into, as surely some portions in those graphs that are showing as fixed should be discarded, and some should be kept.
I hope that helped! If anyone wants to add anything or discuss a point, feel free!