RTK Base Setup - Siting, RTCM output - Example/Howto

Hardware Other Hardware
, ,
1

We now have several RTK GPS options available

One of the things that will influence the quality of your fix (FLOAT vs FIX) is the distance to your BASE, and satellite matches between your ROVER and the BASE.

There are various services out there that will provide you with RTCM corrections via NTRIP. Generally their location accuracy will be high, but they might only have GPS or GPS+GLO or perhaps only L1, or L1/L2, but not L5 and so forth.

If you’re able to get FLOAT but your FIX never happens, or is spotty, and you’re fairly sure the problem is too-long of a baseline, or a lack of overlapping satellite coverage, you might setup a local BASE to improve your chances.

In my case, I had two services available, each about 100 miles away. I’d get RTK FIX from time to time, and FLOAT a lot, but I wanted FIX and it wasn’t reliable.

Those services also didn’t include Galileo and sometimes not even L2 observations.

In any case, I setup my own base and things improved.

Seemingly by default, most bases will “survey in” and establish their own sense of location, and then you get a good RELATIVE RTK fix against the BASE. This is often good enough, and if you’re moving around from site to site, this is most likely as good as you’re going to get with a reasonable budget.

But if you’re mostly in one location, and you need repeatable results - even after a power outage - you need to site your BASE as accurately as you can.

You could hire a surveyor.

Or, the government of Canada offers a PPP service

You log a few hours or a few days of observations, send them in, and you may get your location to within .003m lat/long.

24 hours is good, 48 hours is better.

With an F9P, using UCenter, have it send out the UBX RXM-RAWX and UBX RXM-SFRBX messages.

RTKLIB Explorer covers a lot of this as well.

You can log via UCenter, or I’ve had better luck using the RTKLIB tool “str2str” on a Linux computer (which also includes doing this on a Raspberry Pi, and even on an OpenWRT router with a USB port)

i.e.

str2str -in serial://ttyUSB0:1152000#ubx -t 1 -out file://tmp/baseLog.gps

Log 24 to 48 hours.

Use RTKCONV from the RTKLIB package to convert the RAW UBX captures to RINEX.

You may opt to use an interval, or box it by start/end date - the compressed RINEX needs to be under 300MB to upload to the service.

Upload to the service, await your results. Check the accuracy, and if you’re satisfied, you can then go back into UCenter and establish your fixed position. (see TMODE3)

Entering the fixed position is a little odd since you use the extended/high precision fields for entering Lat/Long and it takes me a few tries to get it right. If I recall, the high-precision fields go from -99 to +99 rather than representing a direct fraction. It modifies the other high precision field for the last little bit.

I have two bases using an F9P. I have another with a UM980 tri-band receiver.

I wasn’t able to figure out how to get the right RAW data out of the UM980 (though I see now maybe I could do it with the RTCM1077 and 1087 messages) so I resorted to using an F9P to capture the initial data to get the position, then swapped the UM980 into place and putting it into fixed mode with the coordinates obtained with the F9P - without changing the antenna, of course.

After that, I’m able to use str2str to make the RTCM information available.

One key thing I’ve learned is - unless your RTKLIB installation has some new code that I don’t - to try to make the output a pass-through, rather than having RTKLIB try to convert the UBX messages into RTCM since in many ways the F9P and UM980 have a few more messages than my copy of rtklib understands.

str2str -in serial://ttyUSB0:115200#rtcm3 -t 1 -out tcpsvr://:9000 -out ntrips://someserver:2101/mymount

This makes my RTCM available on port 9000 for anything on my local network. Or I can use the NTRIP URL if I have an NTRIP server. Remove the ntrips portion if you don’t have an NTRIP server to use.

Put the NTRIP or the TCP client information into Mission Planner for the RTK corrections.

Or, if you have a companion computer, like I do, you can use str2str to feed the corrections to your GPS if you have a good network connection.

str2str -in ntrip://serveraddress:2101/MOUNTPOINT -out serial://ttyACM0
or
str2str -in tcpcli://serveraddress:9000 -out serial://ttyUSB0

Put that into your startup script and have your companion computer supply your GPS with corrections upon startup - you will, of course, need a second port on the GPS to do this, and it needs to accept RTCM on that port.

My F9Ps are connected to the flight controller via serial, leaving the USB port available to plug into the Pi, which becomes ttyACM0

If your wifi coverage/network is good between the ROVER and BASE this gives you a good high bandwidth connection, and frees your telemetry radio link for other things.

2

Very good observations and information above.

You might be interested in this web app that I’ve been working to release. I still need to clean it up a little, but it’s been running my own installation for a couple of months now. It should significantly ease the pain of properly configuring a Zed-F9P and give you a dashboard from which to manage and monitor it.

When I get a chance, I intend to release it along with a video detailing its features and setup. The README is pretty complete (unless you want to post process your data…that section is kinda rough…).

3

For my UM980 base, I wound up configuring it with:

FRESET
UNLOG GPGGA
MODE BASE 40.12345678900 -80.1234567890 100.999999
RTCM1005 10
RTCM1006 10
RTCM1033 10
RTCM1004 1
RTCM1012 1
RTCM1074 1
RTCM1077 1
RTCM1084 1
RTCM1087 1
RTCM1124 1
RTCM1094 1
RTCM1097 1
RTCM1107 1
RTCM1117 1
RTCM1127 1
RTCM1230 1
saveconfig

I piped that directly to the serial port.

In my case, I use “ser2net” on the Linux computer to expose /dev/ttyUSB0 as on a TCP port, so I can then “telnet” to that port and just PASTE the commands into place.

(One BASE is located in the attic of my shop, the other in the attic of a garage, the third in a “in-use” outlet cover box I added next to the chimney - so just plugging the USB cable into my laptop is problematic and inconvenient)

ser2net.yml containing:

connection: &con00115
    accepter: tcp,2000
    enable: on
    options:
      kickolduser: true
      telnet-brk-on-sync: true
    connector: serialdev,
              /dev/ttyUSB0,
              115200n81,local

Then I can “telnet 192.x.x.x 2000” and SEE the current output, as well as PASTE my commands in.

I then stop ser2net, and start up str2str

4

Also curious if you have any observations regarding performance of the UM98x vs Zed-F9P.

5

You might be surprised at how bad this actually is. While it’s fine if you’re using it for a local connection and always connecting to this same fixed base for the given application, it is almost certainly not going to be centimeter level accuracy (despite the reported std-dev - which is not truth data). When I post-processed my own installation, I found that a 24 hour survey-in that reported 7cm std-dev was off by ~1.4m. I found a similar inaccuracy when I post-processed another fixed base installation many miles from here that used a similar self-survey time.

Unrelated to survey-in, why are you sending both MSM4 and MSM7 messages? If your concern is bandwidth, you will certainly gobble it up by sending all of those. In most practical (non-survey grade) applications, MSM4 is plenty. Regardless, unless you have a need for both, you should choose one or the other.

6

I’m not talking about “survey in” - I’m recording the raw observations, post-processing, and then using the post-processed location manually configured as the location.

Undoubtedly not as accurate as I’d hope, but I actually took several days of observations, then fed them through the post processing after dividing them up several times - 30hr here, 30hr there, then intervals over 72hr - and compared both the standard deviations (to make sure I was comparing apples to apples) and then the reported position, in an attempt to get as good as I could get.

Moving from one base (on my garage) to another (on my shop) really skewed my existing fences and missions.

I’m hoping that’s because I didn’t understand enough about the deviations and relative accuracy when I established that first base. I like to think I’ve learned a bit since then…

Now I’ve established my fourth (three active), and I’m considering moving to a UM980 for another base, which unfortunately means a new tri-band antenna and a new survey.

In this case, the antenna will likely be 6-12" from the dual band one (other side of the peak), so if I can get another good survey, I’m anxious to see how that impacts my established fences and missions.

+/- .003m should be ~1/4"

At least by manually setting my fixed position, I can rule out the BASE “moving” after a restart or power outage, which I’d have with a true survey-in.

I am generally more interested in consistent, repeatable results than the absolute location, though having a good absolute location is a good thing, too.

On MSM4 and MSM7 - I wasn’t sure, without checking at the time, which messages the F9P preferred. I have the bandwidth, so I wanted to cover my bases.

What’s needed is a NTRIP caster filter so I can supply MSM4 and MSM7 out of the GPS, but only supply either MSM4 or 7 as needed to the consumer.

That technically could also be done with str2str - certainly if I was feeding it UBX and having it convert to RTCM, but I’m not sure about the new GNSS constellations.

All of this has come a long way from my first attempts at RTK on Ardupilot.

The companion computer is there because I was using an LEA-6T to get the raw L1 data, and then rtklib to process it, which I then fed the output via USB to serial to the flight controller’s GPS input. FIX was achieved a very few times, but not with any consistency, though it DID work.

The M8Ts with RTKLIB were better - especially after I established my first local base.

It wasn’t until I switched to the dual band F9Ps that I started approaching consistent FIX.

On the UM980 vs F9P - I have two BASEs currently about 100’ from each other.

I haven’t attempted to compare the observations from the two directly, though anecdotally I was able to switch from the F9P base to the UM980 base with similar results and accuracy.

Unfortunately, things got in the way and I wasn’t able to run the rover like I intended when I was there. For a different topic, I need to dig into some differences in the navigation between 4.2.3 and 4.4+ Everything was fine, and then I upgraded. :smiley:

7

I misperceived your discussion above regarding post processing or professional survey as optional. We are on the same page regarding survey technique, and it’s refreshing to see someone who grasps the difference between absolute accuracy and relative precision!

As for MSM4 vs 7, if you’re sending both, I think both will be packaged and forwarded by Mission Planner, as well as consumed by ArduPilot and the connected GNSS modules. If bandwidth is a concern, pick one. And if it’s a big concern, choose MSM4. MSM7 is technically superior, but I challenge you to find a real, tangible difference. The F9P doesn’t prefer one over the other. It’ll take all it can ingest.

Regarding constellation choice - if you’ve pared them down, you should also cull out the 107x, 108x, 109x, and 112x messages that correlate to the disabled constellations.

Start a new topic for Rover 4.4+ tuning if you encounter trouble there.