NTRIP Strategy

I’m curious about a workflow strategy when using an RTK drone in combination with an RS2 that I have not seen discussed before.

It seems to me you would have 2 options.

First, you could simply stream NTRIP corrections directly from a hotspot or data enabled smart device to RC to drone. (no use of RS2)

Or, you could collect an averaged point on site with an RS2, then use that point to use the RS2 as a base and stream NTRIP corrections to hotspot to drone using Emlid Caster or Local NTRIP.

Which would provide the best results?

NTRIP to rover to collect your control then to drone once the rover is off. if they use the same profile only one can be connected at a time on our network. Considering they are running the exact same network and GNSS settings I don’t know how much more relative accuracy you can get. If we need to PPK we just get the logs from the same network off their website.

1 Like

Perhaps either method would result in basically the same precision because ultimately the baseline is the same?

The difference is that with the RS2 method, you could average a point over a given time which should then provide superior precision which would then be broadcast to the drone providing short baselines.

Thus, my question!

Our network is also running VRS if that makes any difference.

The biggest question is what accuracy or precision do you really need.

RTK is great because it is precise to itself, the challenge is to make it accurate to a known benchmark.

A local short baseline from a base on a known benchmark will always give you the highest performance, but is it really worth the hassle of setting up each time for the data you want to retrieve?

VRS is also great, but only commercially available.

Edit** I am not a surveyor I just learn from them, I just plant accurate and precise potatoes.

8 Likes

Another subject. But yes. Rather than force the RTK camera positions to adapt to the benchmark through SFM processing would be to apply the measured offset and shift the entire camera network as a whole thereby retaining the good relationship already established but aligning it to the benchmark. @michaelL and I were just discussing this elsewhere recently.

1 Like

Who doesn’t appreciate a precisely planted potato! :grin:

5 Likes

Hello everyone

Speaking of NTRIP, Drone and fixes
Have you tried the Local NTRIP feature of Firmware 28.2?
I tried to make the connection with a Phantom 4 RTK, but it did not work and I have not tried it again :rofl:

greetings to all

There is a dedicated thread for that.
https://community.emlid.com/t/feature-request-rs2-ntrip-caster-via-wifi-for-dji-rtk-drone/26523/166

2 Likes

Hi Dave,

Summing up everything said above, the accuracy depends on a baseline, not on a corrections source. So, the main profit of having your own base is a possibility to keep baseline short.

Also, the local NTRIP Caster on Reach RS2 helps if there is no Internet in your area.

3 Likes

Hi Bernardo,

According to other users’ tests, It should work. If it doesn’t, let’s investigate that! Please create a separate thread for that if you need help.

1 Like

Ntrip to rover for GCP collection and placing of base station mark, setup the base over known point and output to local ntrip.

1 Like

If you get out of data range I understand the base but why would you need a base and local NTRIP if you have NTRIP to run the rover in the first place? Why not just run the drone on the same license.

If short baselines are king; If you transition to the local base NTRIP scenario, wouldn’t you be shortening the baseline to the source of correction significantly?

1 Like

…but for the sake of this scenario the point that you set the base up on is from the longer baseline right? At what baseline distance would a local base make a noticeable difference? What about VRS? Nothing like answering questions with questions, lol.

that’s true… But, if you establish a quality point and set up on that, you are then going to get error calculations from right on site rather than some kilometers away. I agree that if the baseline to the CORS station is not too long, then the difference will probably not be relevant. Also, if your point is off, you are going to make everything off. But if it’s a good point, then in theory, it should be superior.

Just looking at the specs and my lack of knowledge on the calculation - I get local 1.4cm vertical and a 10 mile CORS at 2.5cm?

Shorter baselines are where it’s at, less hotspots to worry about, sometimes you can sit on a hill and just get enough reception to ping a base but not reliable enough to run your uav rtk through it.

Gotta think worse case and setup for that rather than the assumption everything will be sweet, running in to a bit of that mentality at the moment at work and it’s biting them in the ass, proper preparation prevents piss poor performance

This is why we do PPK logging whether we are planning to use the RTK values or not. If RTK isn’t available then we just use the PPK. UAV surveys are all about relative accuracy. Anyone busting their brains trying to achieve absolute accuracy straight out of the drone is wasting their time. Micro adjustments have to be made to every set of data that we touch in order to match what is surveyed on the ground so I don’t think a 1-2 cm variance is going to make any difference at all in the UAV world. Especially in regards to vertical because if you are within decimeter of a spot 99% of the time your elevation is going to be within millimeters if not the same.

1 Like

Not sure setting up on a known point for a smaller baseline and less vertical error (around 30mm difference in my cases generally) is busting your brain :joy:

Work smarter not harder, having to retag 4-8000 images for ppk or setup a local base, use local ntrip and have rtk tagged images that don’t need post processing, I don’t know about you but I’ve got weeks of work waiting to be done, wasting a couple of days doing ppk processing is puzzling.

You have an rs2 and local ntrip, not sure the statement “if rtk isn’t available” really holds water these days