Trouble getting Fix; limited range

I’ve had an ongoing, but seemingly intermittent problem with my Reach RS units. Using a Base and Rover, I have trouble getting a Fix-- sometimes it seems like I get a better result when I change both Base and Rover to another frequency. That sometimes works for a little while but then I have to change frequencies again. Sometimes I can only get a Fix when the Rover is line-of-sight in view of the Base. Sometimes my range is limited to about 250 m. Sometimes I can’t get a fix at all – or I will get a fix again within 30 m of the Base. Attached is a link to the last round of logs from this week. At one point during the attached logs I switched my “base” and “rover” units to see if I would get a better result, but the result was about the same-- limited distance / line-of-sight only / trouble getting a Fix.

Hi Brian, welcome to the forum! There are quite a few things that may contribute to what you are experiencing. Some of them are settings and some are environment. Could you please post snippets of the following screens?


  • RTK Settings
  • Base Mode


  • RTK Settings
  • Correction Input

Also, what is your environment like? Vegetation, hills and structures?

How are you mounting your receivers?

1 Like

Attached are screenshots of my settings.
I’m usually surveying at mine sites without vegetation and still have problems not getting a fix.
I mount the base on a tripod. This week it was mounted at a high elevation overlooking the mine.
Rover is on a rod.
I have a trouble sometimes getting a fix even line-of-sight with no vegetation.
This week as soon as I’d get more than 250 m away from the base I’d lose it. If not line-of-sight, I’d lose it. If in trees, I’d lose it. Sometimes still IN line-of-sight, no obstructions, closer than 250 m, I’d lose it. If I’m 30 m away from the base I’m ok. My theory is I’ve got a bad connection to the antenna on one of the receivers, but checking here first.

2020 04 30 Emlid review of my settings.pdf (234.8 KB)

1 Like

after having downloaded your data, a few questions arise:

  • Why do you have so many files? Can you specify 1 rover file and 1 base file where this happens, so we can try to easily reproduce?
  • Is there a specific reason why you are running 5hz collection rate? 1hz is plenty when doing static point collection
  • On the files I have looked at you have a massive amount of cycle slips and bad SNR. what does your environment look like? Can you post some pictures?
  • Any reason you don’t enable all constellations possible on the RS?
  • Is it the Fix you loose or the LoRa stream? What does the correction delay indicate?
  • The multiple files represent one project, where I was rebooting the units several times to try to get the units to work together. But I will choose one set of files, which are at this link:

  • Ok, as you suggest I will switch to 1 hz rate

  • You ask about environment — it is an open mine site. I place the base up high and often have direct line-of-sight with the base. I am attaching a screenshot. Open area.

  • Ok, I will enable all constellations but I don’t think this is the problem.

  • “Is it the Fix you loose or the LoRa stream? What does the correction delay indicate?” Answer: the rover goes into “FLOAT” and the AR is less than 3.0. I stand there for a long time waiting for the AR to go above 3.0, but even when it does it goes to maybe 4+ or 5+ and I collect the point then… but later find the point is not accurate even then. The base satellites (grey bars) bounce down to zero from time to time but then come back. The rover satellites (colored bars) are strong. I try many different frequencies for the base and rover in case I am getting interference-- sometimes this works for a short time, but not for long. Tell me if there is a way to tell for sure if it is the LoRa I am losing, or the Fix as you say in your question above.

Can you upload the UBX files for matching base and rover?

UBX files here–

Thank you. Which one is rover? I assume the 1835 file?

Enabling all the constellations may not be a good idea if you are truly wanting to shoot RTK. Having everything on is good for backup when planning to PPK, but if there are poor satellites and the SnR value doesn’t exactly capture them they could cause an instability on that end.

On the other end it could easily be the LoRa radio communication as well. I would set the frequency to the lowest value possible in order to get the most penetrating signal.

This could definitely be a cause of the loss of fix. It would be better to analyze the base while connected to it. This leads back to understanding what constellations to pull out. If you are averaging in a point let it collect for 10-15 minutes and watch it about 5 minutes in. If you see a certain constellation radically bouncing up and down then cut it. I would start with GPS only and add a constellation at a time. Once you done it a couple of times it is not a hassle, but is a big factor in making sure you get the best accuracy possible with the conditions at the time.

Have you tried the base in different positions? If you find a spot with the rover that fits the criteria and has a good fix just set another point and manually enter it so that you stay on the same control pattern.

Is there another base on site, maybe for machine control?

The 1835 is the rover, yes.

Agree on that, log all constellations, use what make sense for RTK. This should also be considered when set the elevation mask and SNR mask.

I have processed the data, 93% fix rate.
So my suspecision are now 2 things:

  • Something wrong LoRa reception og transmission. Have you tried swapping antennas? You should get quite a bit more than 300 meters line-of-sight. You could also try another frequency. Maybe something in the mine is already working on that band.
  • Rover data has a lot of cycle-slips. Consider not walking too close to mine walls and so on at any time with an L1-only receiver, and stay away from heavy machinery in operation.

Michael-- Yes we’re doing RTK and not PPK. When I connect to the base direclty the satellite signal is not jumping. Only when connected to the rover, do the satellites from the base jump. So I could do PPK I think but I’m trying to solve my RTK problem. I agree it is probably a LoRa problem. I have tried many different frequencies and agree lower would be better in theory but at this point I have tried frequencies all through the range. Different base positions — yes I have tried that already many times.

My personal theory for awhile is that I do have an antenna hardware problem. But tell me about slips— do slips come from bad LoRa connection or are slips not related to that?

Cycle-slips are essential the receiver losing sight of the satellite, to a such degree that the internal tracking of it gets reset.
If that happens on too many satellites at the same time, you loose the fix.
That is why it important to not go under tree’s, right next to walls, or put the rover-rod horizontal during transit from point to point, unless you want to re-init the fix (which could take several minutes on L1).
It is completely unrelated to LoRa and RTK. However, RTK and PPK GNSS requires quite high and continuous signal quality in general.
Here is a screenshot illustrating the issue. On top, your base, below, your rover:

Ok, so slips is one problem. The points that I survey are often far apart. I travel in a vehicle and the rod with rover on top gets into a horizontal position when traveling from one place to another. But when I get to the point I want to survey— sometimes I stand there for a very long time and never get the fix back. Also there is the jumping of the base satellites (grey bars as seen through the rover). So maybe I also have a LoRa problem?

Also, can you help me by checking these two .UBX files as well? These files are with the units reversed. So, if the base is still solid but the rover is slipping in these files, then the slip problem is completely how I am handling the rover in the field.

Do you have the base correction file from the rover (RTCM file)? That is a good way of knowing if the jumping is because of loss-of-signal from the Base, or if the jumping of bars is “just” a cosmetic issue in Reachview.

Look how bad GLONASS is… Overall the rover was only working off about 14 satellites consistently despite whatever Reachview reported. That should have been plenty except for the obvious disruption in the middle 1/8th.

Yeah, would really useful if Reachview would only show the sats that are within the masks setup for RTK use.

1 Like

RTCM file:

Zero sized file, that one? :smiley: