Difficulty getting live RTK Fixes with 2.1.6

I’m using Reach to get more accurate positions on a hexacopter controlled by a Pixhawk. I let the copter and base receiver sit on the ground for 20 minutes and got no RTK Fix. The positions were converging to reasonable values, but an RTK Fix was never achieved. I hovered at 3 m for a few minutes to see if that helped and it did not. I post-processed the results and was able to get an RTK Fix as shown below:

The SNR is good:

and I believe the geometry looks reasonable:

I just used GPS satellites since I was able to achieve RTK Fixes for another case when I excluded the GLONASS satellites.

Any pointers?

I uploaded all the log files and solutions to here:

Here is a picture of my setup with the copter flying 3m:

It looks like you have good control over the technical aspect and how to properly set up this system.
Is it possible to post a picture with closer look at your device and how you use it?
I would recommend you to try this another time, even though you have good gps geomtry, and see if this make any difference
Did you check for solar interferece at this time?

Also, during the flight, I used “CONTINUOUS” processing mode and during post processing I used FIX and HOLD. That appears to make a big difference as well. I had read that CONTINOUS was more robust, but perhaps its less likely to yield a FIX.

I noticed setting AR=1 from 3 provided more fixes as well. What’s the minimum recommended for that value?

Changing the elevation angle filter to 5 degrees from 15 degrees helped as well.

My experience with fix and hold, is that it will hold on to fix better but give you less accurate reading, depending on how you use it. For this purpose you might use fix and hold if you find most useful.

With AR level, you basically lowering the threshold for when fix is applied to the solution.
If you dont need the accuracy and lowering ar to something els that give you more stable flight, no problem i think.
If not, 3 is the recommended value.

Here is a close up picture:

Cool thanks.
What is that device at the same hight as reach antenna?

A non-RTK GPS. Its used for navigation and the Reach is a backup.

OK, it should not give you any interference. Could be an idea to lower non-gps so any chance of multipath is gone, just to rule that out.

I switched to FIX and Hold today using only GPS satellites and was able to obtain a RTK Fix fairly quickly and it held well even while the copter was hovering at 3m!

If I added the Glonass sats, I could not get anything better than a Floating Fix. I tried increasing the SNR requirements to 40 and elevation angles to 30, but it did not help.


I continue to have difficulty getting RTK Fixes for live data. What is the primary difference between RTKPost for post-processing and and RTKRCV for live processing that would impact the RTK Fix processing? Even if I use the same SNR and Elevation filter for live processing as compared to the post-processing, I do not reliably get fixes. I do get reliable fixes during post-processing.

I did happen to see a quicker fix if I changed the base’s update rate to 5 Hz from 1 Hz, but then I lost the fix once the copter took off.

During postprocessing, I found that I can get the most extensive fixes if I set SNR=40 and Elevation=0 using only GPS satellites. I get less fixes, but a bit more accuracy for my case if I include SBAS sats.

When I flew this morning, the K-Index=1, which should be optimal.

Any feedback and lessons learned would be appreciated.

1 Like

a guess in the wild:
motor/esc’s rf noise mess up your signals…

But, I can get a fix with post-processing though. Any noise from the copter should be built into the collected data.

Just a shot in the dark: Is the RTKRCV and RTKPOST having the same patch level/software version? Possibly one included with ReachView and the other downloaded from somewhere else?

I’m using rtkpost_emlid_b26.exe for postprocessing. RTKRCV is being used by ReachView. I’m not sure what version it is right now. I wonder if there are input configuration differences between the two?

A bug thats not been fixed?

A very common source of the difference in real-time vs ppk is that there is a delay with corrections delivery. When you use raw logs from both devices this delay or even loss of data is not taken into account. Which communication channel are you using for corrections?

I’m using the 3DR 56kbs radios and MAVLINK. I noticed yesterday that when I changed the base station update rate from 1 Hz to 5 Hz that my AR value went from 1.2 to 1000 and I got a fix right away, but I lost it soon after. What is the optimum update rate for the base station and rover?

Any advice is appreciated.

We recommend setting it to 1Hz for reduced bandwidth requirements. Your case with switching to 5Hz looks like buffer overflow issue on the radio. Did you observe high age of differential?

1 Like

No. I’m getting .4 to 1.6 with 5hz. Just got a fix this morning. We’ll see how long it keeps during hover.

I lost RTK Fix right after takeoff.

I had one 10 minute flight where I had a solid RTK Fix and two flights where I had none. After waiting for 5 minutes, the RTK Float fix was very close to the right answer, but for whatever reason, I never was able to duplicate the RTK Fixed Fix from the first flight. I tried 5 Hz and 1 Hz update rates as well.

Here’s the original solution from the one flight I had with the RTK Fix:

Here’s the post-processed solution: