Local NTrip

Using Reach RS2+ as a base for a DJI drone (M300).

When setting up as Local NTrip, I understand you dont need an active internet connection.
I understand how to set this up and configure the drone to receive rtk corrections from the Emlid, but I don’t fully understand how this actually works?

How does this work and is the accuracy affected?

Does the emlid need to be setup over a known point?
Does any base configuration need to be completed in emlid flow first (location, height etc).


1 Like

Being a direct Wi-Fi connection to the receiver itself is no different than a home Wi-Fi or mobile data. It’s just a network connection the allows corrections to be passed through to the rover (drone). In my experience deviations drop almost in half in comparison to a cloud NTRIP (VRS) just 15-20km away. I’m getting 1,1,2cm vs 2,2,3cm and the fixes are almost instantaneous and have never dropped (unless a piece of hardware died :wink: ).


What I mean is, how do the corrections work? Are the done within the RS2 itself?

With standard ntrip, the base location, height etc is known.

Do we need to configure the base in emlid flow before activating local ntrip?

Are corrections passed onto the drone in wgs 84 / ellipsoidal height?


Essentially the RS2 is the same as the Trimble (probably) CORS operated by the State or private operator where you are. You still need to either average in a point, shoot RTK and then occupy it in Flow or manually enter the coordinate with the correct dimensional and positional information. The corrections are whatever you have the base/project set to.


Dave here on the forum has an excellent tutorial about hooking up to the RS2 for local (on site) NTRIP RTN.

I’ll see if I can find it. It helped me a lot as I was having difficulty also when I got my UAV.

1 Like

Here’s one, but it’s not the one I remember. This one is also excellent:


Brilliant, thanks @EBE111057 :+1:

I’ll give this a try tomorrow.

1 Like

Looking at that guide, its just showing the basics of connecting the base to the drone.
That bit I already know.

What im looking for is a more detailed workflow that @michaelL is referring to.
I think, because im in the UK, marking points using a geoid height when the drone is expecting an ellipsoidal height, ill need to mark a known point for the base and adjust its height in order for the drone to receive the right corrections.

I’ll feedback shortly once I’ve experimented.



Generally, yes.

If a known point is not available, and you can’t create one yourself by connecting to an RTK network, or have the time to do a PPP workflow, you can average a point and use that as the base coordinate. But this would only give you relative accuracy not tied to a particular CRS.

The drone is expecting to receive corrections in reference to a lat/lon ellipsoid ht. coordinate from the base.


Another possibility you might want to look into, is to collect using your Base data on a unknown point for a minimum of 2hrs while running your mission and run that data through Opus afterwards. Then post process your data with the known point from Opus and shift your collected data with a aftermarket software called REDtoolbox. I haven’t personally used the software, but that is what they list it as capable of doing on their website. REDtoolbox – REDcatch GmbH
REDtoolbox v3 - Shift RTK coordinates in jpgs EXIF information to match your GCPs. - YouTube
They offer a two week trial, so you could test it before buying.


I can vouch for RedToolbox.


I do use RedCatch tool box, it’s a useful tool and food support from the developer too.

I was hoping to figure out the local ntrip method to save having to ppk data.

1 Like

Hi Jason,

Local NTRIP allows passing the corrections between your Reach RS2+ base and controller over a Wi-Fi network. It works like TCP.

Yes. The base coordinates are transmitted in the RTCM3 messages. The rover relies on them for calculations. That’s why configuring the base before the survey is important to achieve a centimeter-accurate position on the rover.

As Dave mentioned, you can use one of the following ways to place the base:

  • A benchmark with known coordinates
  • Get corrections from the NTRIP service and use Average Fix
  • Use PPP services

They are sent in the same datum as the base coordinates. So if you set the base position to WGS 84, the corrections, and therefore the drone’s position, will be in WGS 84 as well.

But I think in the UK, ETRS89 is a more popular option. What coordinate system do you need for drone mapping?

1 Like

Thanks @julia.shestakova
ETRS89 is fine, but DJI drones expects to see ellipsoidal heights.
I think in my case, I wil be using OSGB36 + ODN, which is a Geoid height so elevation value is going to confuse the M300 and altitudes will be off.

I found this really useful thread by @cameron.baker which I think is the solution:

Jason, glad you have a handle on it.

Just a note that if you make a base point that is the ellipsoid ht +/- the geiod like in Cameron’s workflow, you will be in good shape for smaller sites. The larger the site is, the less accurate your heights will be because that geoid offset is not always linear. So, if you are a mile away from your base point, using the geoid offset from the base will not be as accurate as using the ellipsoid height at the rover and converting that point using a geoid offset for that particular point. Hope that makes sense.

If the area is relatively small, or a larger area that is fairly contiguous geoid wise, then the difference should be negligible.


Thanks @dpitman.
In my case, the rover is the dji drone. I dont have the ability to configure it.

I guess the other option would be to set everything to ellipsoidal heights, and convert in post processing.


I understand. If you do the geoid offest to the base coordinate in Cameron’s workflow for the base point, the drone is going to include that offset on every camera position, which is what you want if doing it this way. My point is that if you instead used the ellipsoid height without the offset on the base and therefore the drone, and post-processed in the geoid on each camera position, that is a more accurate method. But depending on the area, it will probably be a negligible difference. On a large area, it can be a larger difference in accuracy.


Hi Jason,

I agree with Dave. Transforming the data in post-processing is a more accurate option. Heights in ETRS89 are ellipsoidal. So you can use them directly. It’ll allow you to get drone coordinates and heights in ETRS89 as well. And then, you can transform them to OSGB36 + ODN heights in the photogrammetric software.

If you have only orthometric heights, you can follow the steps from this post to set them on the Reach RS2+ base. In this case, Emlid Flow will recalculate the heights to ellipsoidal.


Understood. That would mean collecting ground control points also in etrs89 and converting them also?

I’ll test this out!