Mission Planner-3DR radio Failing - How To?


Can someone advise. I’ve followed the tutorials meticulously, have the latest/beta version of everything and can get a fix through mission planner via tcp but can’t get the corrections to come through via 3DR radio

Setup is (when working via TCP):

RTK settings:
kinematic mode
Fix-and-hold GPS AR mode
GLONASS AR mode off

Correction Input
IP of base
Port 9000
Format RTCM3

Position output

Basemode - OFF

Correction input - OFF
Position output -OFF
Base mode

Mission Planner:
All subtle parameter changes exactly per tutorial
Inject GPS:
TCP client
Port 9000

Again, corrections get through and fix is obtained

When we change to corrections coming in via 3DR radio the only thing we change is
Correction Input
Format RTCM3

And we still see input in mission planner but in rover view there are no corrections visible and no fix

You missed changing the Base mode from TCP to UART., but maybe you did that and just forgot to include it in your post.

uh no explain more

the base reach connects to laptop (running MP and with 3RD radio plugged in) via wifi per “reccommended configuration” diagram in docs) - shouldn’t it stay as tcp server then -no?

maybe someone could post screen shots of every reach view page for both base and rover and MP gps inject window showing their working setup?

am surei i’m just missing 1 setting:/

Oh, pardon me. I didn’t realize that you were feeding through mission planner. Unfortunately I have no experience with mission planner. I will let someone else respond about that.

Maybe it going to far backward for you, but when I had trouble with the radios, I went back to basics:
  • tried sending simple keystrokes from each radio until I confirmed that I could receive from both ends.
  • hooked up base to the transmit end of the radio and made sure that corrections were being received properly by the receive (rover) end of the radio
  • then hooked up rover to the receive radio and everything worked well.


I have the same problems, also my ReachView App is different from the tutorial.
The tutorial should be more explanatory it is a little confusing, it is not entirely clear what are you doing and where.

For example what are the settings for the rover, it seems that the tutorial covers the base station part only.

On the app looking different - just make sure you’ve updated to the latest version

But ja again - could someone who has it all working maybe just post screen shots of their config for all pages for both rover and base and mission planner GPS inject screen?

Would super helpful in eliminating whatever the 1 random setting I have wrong is!

You will need to tell ardupilot to inject to your GPS, to do so change the GPS_INJECT_TO parameter in mission Planner.
reach has at least four known bugs that mess up integration with ardupilot. I already corrected them, on my public github repository but Emlid has not merged the fixes yet, so reach does not integrate that well with ardupilot:

  • hdop is messed up so dual GPS does not work (although recommended by Emlid)
  • horizontal and vertical accuracy information is also messed up (again affects dual GPS)
  • speed accuracy information is missing
  • Ground course calculation is bogus wrong signal and 90deg offset, (EKF will get confused merging the information with a compass)
  • GPS timestamps are messed up in versions prior to reach 2.5.2

On Monday if I get some time I can post screenshots, but like I said, even when you inject data, it still does not work correctly until those bugs get solved. Apply pressure on Emlid, maybe then they will merge the fixes, and it will start to work like advertised.

@r4space i fixed the app.

So this means that the RTK GPS wont work with Ardupilot as it is.

If dual GPS is not working, can the system work with only the emlid module as primary GPS? How can i inject the base correction then?

Also does this affects the compass operation?

On dual GPS with GPS_AUTO_SWITCH == 1 it gets very confused with the compass and does strange stuff, for me it started oscillating on the yaw axis, whenever switching GPS. It also almost never uses reach because it compares the hdop from the standard GPS with the vdop of reach (bug explained above), and ends up almost only using the standard GPS because vdop its typically bigger than hdop.

With GPS_AUTO_SWITCH == 2 (GPS Blending) then it uses Reach but blends in the other GPS because Reach stops delivering accuracy information as soon as it gets a RTK fix. So when reach is fully locked the autopilot actually thinks that the solution quality degrades and starts giving more weight to the other GPS, again a reach bug.
This method did conceal/diminish the yaw oscillation caused be the ground course calculation bug.

Missing speed accuracy information also makes it harder for the autopilot to blend the two GPSs. It would be nice to see it implemented. The ERB driver in the Ardupilot code already flags it as valid although it is not. But that will stop being a bug as soon as Emlid implements it on the reach side :slight_smile:

When using reach as primary and single GPS source (against Emlid recommendation) should work, but the EKF will get confused by the buggy hdop/vdop and missing accuracy information, and give too much weight to the IMU and too less to the GPS corrections. I must admit I did not try this combination. I only tested the two other ones above.

Try it out, and tell us how it goes :slight_smile:

1 Like

This is crazy, uh would you (or Emlid) like to comment/advise - I’ve already lost a week to fighting with this, how likely is it that I’m actually going to get this to work or do I cut my losses and go looking at a different solution?

Recommendations? Here+ or Piksi?

Welcome to the club. :frowning: How much time do you tink I’ve wasted debuging the issue and correcting the code ?
And waiting for Emlid to react ?

If you want to fix it. try these out :

According to Emlid this is how you compile it:

And this is my struggle to get a one liner simple fix into the source code:

I hope they improve (Emlid), but until now, they’re just slow and buggy.



Did you try connecting two Reach units with a radio link without ArduPilot? This will confirm you have everything setup correctly outside of Mission Planner configuration.

The ArduPilot tutorial has the screenshots of the settings for both base and rover. What’s wrong with them?

We appreciate the pull requests with your fixes, but can’t merge and release them immediately after you push. The team working on Reach is right now focused on other issues and features, but that does not mean we are ignoring your work. Those fixes will be properly tested and released in the coming weeks.

Not sure yet what’s wrong, we followed the instructions exactly hence assuming we must have done something wrong in some of the settings that are not discussed in the instructions…

Again, it works fine via wifi but not via 3DR radios

It’s OK that you can not release. I have now fixed the makefile and can therefore compile and install my patches on the Edison.

I also warned the rest of the Ardupilot developers about the bugs in the code, so they will not have to go through the same pains I had.

I will continue to work on integrating Reach into Ardupilot … but it would be nice if you guys helped me out. Please provide speed accuracy information, the next time your team works on the ERB protocol. I’m not getting paid to do this :slight_smile:

So 1 problem down:

BAUD rate for radios MUST be 57600 and NOT the 34800 in tutorials, for operation with v2 3DR radios.

Obviously, you do need the radios to be configured to be on the same baud rate. But, we’ll fix the screenshots, so that they have matching radio configurations.

Of course, was not setting them to different rates (and I don’t remember them being different in screenshots) but given that reach uses its own protocol it was not too surprising to think emlid might require a different baud (to the 57600 we all normally use for 3DR radios).

All of which is simply to point out to anyone following this thread in the future: For 3DR radios connected to Reach’s use the normal 57600.

Not sure what 34800 is for but nether it nor any other baud work with the 3DR radios and Reach

What I meant was that Radios also need to be configured to use a certain baud rate. There is no standard for them being 57600 by default. Since the value can be changed, that is not really something you can rely on, so their settings should be checked as well.

We will add this info to the docs.

1 Like

Hi, In my current setup i use Reach gps as primary gps. From the original GPS unit (the one that came with pixhawk i use only the compass)

I made some ground tests with this and it is working. I will get it into the air in the next few days and see what happens. From what i observed the corrections are sent from the base to the drone and the static position is accurate. I did some movements and i didn’t found any problems.

I am not sure why Reach does not recommend this. I somebody have more information why please share it. One downside is that you need 2 radio modules if you want to have telemetry and base corrections for the gps. But from the other hand you eliminate bunch of elements that can fail or at least bring a big delay to the system. We have the Mission Planner connected to the base through WiFi, then the mission planner sends the corrections, the pixhawk takes it, inject them in the primary gps and then we should have the more accurate position.


1 Like