Questions for improving the AR validation ratio


I’m getting started with the Reach modules, I think that it is quite common, but I cannot get an AR validation rate higher than 3, so therefore no Fix, Here I share my setup and bellow it I ask some questions on how I could improve that. I would really appreciate any help.

  • Only one reach device as a rover, getting RTCM3 messages from a public NTRIP caster.
  • The rover is located from the NTRIP station from around 500m.
  • Backplate of metal of 7x7 cm.
  • Open sky.
  • RTK settings:
    .Position mode: static
    . GPS AR mode: Fix & hold.
    . Glonass AR mode: off.
    . Elevation mask angle: 15
    . SNR mask: 35
    . Max acceleration: Vertical: 1m/s2 Horizontal: 1m/s2
  • Region: Mediterranean coast of Spain.

My application needs an accuracy of less than a meter, and each time that is taken a GPS point the rover will be in a static position.

1- Looking at my setup/settings, do you know how I could improve the AR validation rate?
2- Would having my own base station sending the RTCM3 messages to the rover improve the AR validation rate?
(instead of using a cartographic public server, like I did in the last test).
3- Would reducing the AR validation rate value that triggers to get the FIX, allow to get less precision but easier to get a Fix state?(since I need less than a meter of accuracy).
4- What do you think about this amplifiers that you can buy in Thalysman shop? Might be a way to improve the satellite reception:

Again thanks for your time, I hope I can continue improving the results and stability of the Reach modules.

Try following changes:
Beside running the latest Reachview version.
-Continuous mode
-Gps-Sbas only and add one more system at the time
-Make sure you check if ntrip has VRS and if so, enable return message.
-7x7 grounplate should do, but i would check if a large one does improve signals
-You might get a more stable fix with your own base nearby. You could enable Glonass AR if that system is usable in your area
-Lowering AR value just lowering the threshold. You should keep it as it is.
-I would try investigating all other options before you start buying new things. One small thing might corrupt your setting to get fix.



I tried your suggestions with the settings, the public NTRIP station that I’m connecting supports VRS as well (before I was selecting manually the closest station), so I enabled the return message.

I got the best results with the satellites: GPS, GLONASS, SBAS.

But still is mostly all the time in Float, gets Fix for some seconds and comes back to float.

Something that I forgot to mention in the previous message, is the update rate: 1Hz, can that value influence into the AR Validation Ratio? (my age of differential is around 1 second - 2 seconds).

In any case, the next test will be with my own Base station sending to a NTRIP caster, and the rover connected to it using 4G.

Any idea on how to improve the stability will be very welcome:)


Could you share log from rover with correction?
1Hz should work just fine

Hello, here I attach the logs. (41.1 KB) (522.1 KB) (158 Bytes) (145.1 KB)


Ntrip data were missing so could not process that. Base have 1min drop outs now and then, not sure about that but is it getting enough power?
Are correction from Ntrip going directly to rover or via base?


I guess the one minute drop might be changes of parameters or restarting the device.

I think yes, was getting enough power, connected to an external USB battery almost fully charged.

The rover is connected directly to an NTRIP server(public cartographic service). VRS capability.

I need to get into the log analysis tools in order to know what I’m attaching for getting feedback, let me check them
and get back to you.


I was able to take a look into the logs with RTK_plot, and the log that I sent is correct.

TB_RTK, what makes you think that the rover was not getting enough power?

On the other side where you saw that there is 1 minute drop?

The next test in any case should be with my own base station I’ll try to do it tomorrow.


It could be anything but as you explained, reconfigure and rebooting reach would cause this.

I assume the one file from rover was the raw file, and the other are from base?

All the files are stored as the logs of the Rover, since there is no Reach device as base, it generates 4 files,
I understand that are the raw gps values, the corrections(coming from the base), the additional corrections(since there is no additional base should be nothing) and the solution(the corrected values).

I might miss something since I’m starting, but how I can see if the problem is either

  • The satellite constellation
  • The antenna reception?


Sorry my bad, thought you were restarting your base, but you actually said device.
Gonna look through your files again.

Well the base is your correction data that seems fine except for random dropouts you will need to find the cause of
Rover lacks enough satellites with good snr. So i would say there is an noise issu here and/or in combination of setup you have got. What does the rover gear look like?

Left showing rover, and ntrip to the right


interesting thanks, from the graphs I conclude that even there are drops at the NTRIP messages sent from the base(that makes loosing Float to Single), the biggest problem here is that there is a high SNR on the rover, as you said.

The set-up of the rover is simple, the metal back plate of 7x7cm, and the antenna as far from the device as possible. My challenge, I want to do the antenna/device as a wearable.

I’ll make more tests with the rover to see if I can get better SNR.


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