Hi all

We have had our Reach RS for awhile now. We have had 3 surveyors have a go at trying to use them our goal is just to be able to get RTK accuracy for GCPs when flying our various UAVs

We have two Reach RS units, one is assigned and set up as a Base. This Base unit is then put on a tripod over a know position.

The second unit is set up as a rover and is attached to a pole.

We have tried using the system in several locations from an urban environment (the roof of the office) to open areas with clear view of the sky.

we can not seem to get the rover to ever be in a “FIX” in the urban environment most of the time we would get “SINGLE” and occasionally get “FLOAT” out of the city in a open environment we will be in “FLOAT” the whole time. WE have plenty of satellites (24 sats above a 15* Mask) both rover and base seem to be able to see the same number of sats most of the time.

We have tried most settings (collectively we are on about 40 man hours trying so far)

The Problem seems to be we can not achieve the AR Ratio (seemed to be hovering 1-1.5) to get a fix

Have we got a faulty unit?



1 Like

Could you provide a raw. ubx log for base and rover with this issue?

Most likely the issue is with the correction link. If you barely have float, then the corrections are not coming through. Either the conditions for radio communications are bad and you should try something more simple first, just to figure it out, or you have too much messages configured for base output. In that case, LoRa driver will discard the data it can send. Try using GPS, GLONASS and Galileo observations at 0.5 Hz and base position at 0.1 Hz. This works good with the built-in radios.

The above is a link to ubx files for a couple of the tests we have done.

Here are plots of satellite elevation with the color as SNR (green = good)

I am only showing the reception of the USA GPS satellites here. You should be looking for 5 or 6 green on both the base and rover at the same time. The first two plots are almost good enough, but not quite. The third one is on the verge of being good, and the last one is pretty good.

I don’t know which were base and which were rover, but I think you should have got a fix around 5:10, and if it was lost the next opportunity for a fix looks like around 5:30.


in the second two we had plenty of green bars, in status view. with both gps and Glonass constellations. however, we can not achieve fix. the first two are the Rover and base on the roof of our building in the city. the second two are the base and rover out of the city with a much clearer sky and few if any multi-pathing issues.

still can’t get a fix for more than a couple of seconds with AR hovering around 1.5

The graphics above are what each receiver saw, not what was actually processed during RTK, so we still have to prove the communication was getting through.

For that, please upload your RTCM3 files to the dropbox, and also the solution files if you don’t mind, so we can compare RTK vs PPK solutions.

Also be aware that you need a group of satellites in the “green” from a single satellite system (usually GPS). You could have all of these “green”: 3 GPS, 3 GLO, 1 QZSS, 2 GAL = 9 satellites, and that is not going to fix because there is not enough of one satellite system to do it. Once you get enough satellites to fix, then all those other green satellites will be quite helpful in holding that fix for you.

Send those extra logs, and we’ll see what @TB_RTK comes up with in the post-processing.

This could be the problem…

the only logs i can get are UBX, RINEX-3, and NMEA

RTCM3 is ON but it seems no log files are being generated

OK, just upload what you have then and we’ll see if it helps.


The logs you have uploaded do not contain the right information. The raw logs only contain the observation data before sending, while what I want to investigate is the correction link.

Please provide the following:

  • Full settings screenshots on both devices
  • Raw, base and solution logs found on the Rover unit
  • Raw and solution log from the Base unit
  • A photo or detailed description of your testing setup will be very helpful

Well today I have tried to do yet another log to prove to you how unreliable the data is.

took me over 10 minutes to even connect my phone to the base. which i have set up for simplicity on the roof of our office building. I simply don’t have the time to go further away today. My laptop and phone both have full wifi signal. despite clear view of the sky it took three attempts to get the base to get a single position (3 minute average, it would restart at between 50-80%) Now can’t even connect to the rover despite being right next to it.

we have been wasting time on this for months now, with no more than about 5 seconds of fix and trying pretty much every combination of settings.

we simply can not trust a unit to work when it is this hard just to connect to it.

i will post my logs when i can actually get into the Rover to get the logs

the screen I am looking at for over 10 minutes just to connect
took 3 attempts to give a position for just a 3 minute average

I am trying to log all information. just to prove that this does not work.

more settings these are the same as on the rover, if i could connect to the rover.

more settings

more settings, we have tried different combinations of constellations normally available in our area (western Australia)

plenty of sats, none green though

when I eventually get to connect with the rover I will provide similar screen shots

we have tried many different combinations for RTCM3 Messages as suggested on many different forum posts

ok finally connected to the Rover to at least get some screen shots I have been observing the screen for the last 10 minutes.
I actually got FIX… twice, for about 2 seconds before going back to float.

I will leave these logging for a few hours and then up load the logs they produce.

Again with these settings we have tried a number of different settings, including things like Fix and Hold, turning glonass ar on and off. changing the mask ect. with no large difference.

It looks like you have Egor’s attention, which is great, so don’t let me detract from what he says.

I had a quick look at your screenshots, and the first thing that stands out is the SNR ratio is too low on your base. I know the signals fluctuate quite a bit at any given time, so the picture may not be representative of your average SNR. Is it possible to swap positions between the base and the rover to see if the low SNR is common to the base unit itself or if it is common to the location of the base?

Another thing you could do is turn off every satellite system except for GPS and SBAS and set the update rate to 1Hz and keep in Kinematic mode with GPS AR set to Fix-and-hold. As long as you can maintain 5 green satellites on the SNR chart (for base and rover), you should see a slow steady climb in AR ratio until fix and it should hold there. If you can get that working, then you can start adding other sat systems and speed up the update rate.

With regard to your waiting and connection troubles, I’ll tell you that the other day I experienced something like what you described. I had two Reach modules on a vehicle and parked at a new place (in the middle of town). There were long delays in getting connected, and I had to make repeated attempts and it would get stuck or sluggish to respond. So I drove away and came back to the same place several minutes later and it connected just fine, and went away and came back several more times and the connection worked great. I put my connection troubles down to WiFi interference, and I assumed that the hotspot had changed to a less congested WiFi channel or the interference that was present had stopped.

1 Like

link to the Log files from the Base for todays logging

and this is the link to the rover log files

the rover although it was switched on was unreachable for quite a while. and then eventually ran out of batteries.

1 Like

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.


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!


Thank you very much for your help.

unfortunately we simply do not have the time to sit down and faf about with setting and post mission analysis from this end. we wanted a system that could would work straight out of the box.

we have already used a lot of man hours to try to get a solution.

When we are out in the field we need a system that we can trust will give us accurate results. something all our surveyors can have confidence in when talking to our clients.

Unfortunately this process is too unreliable and there for not a process we can trust, to assist in our data collection.

1 Like