Using RS3 as Base, No correction input

Scenario:

  • I’m using one of my RS3’s as a static base to send local RTK corrections to a rover and to a drone for mapping.
  • There is no source of external Corrections.
  • There is no pre-existing known location to set up on. So I have no coordinates to enter.
  • I may or may not return to the location on subsequent days.
  • RINEX files are logged for both the base & rover.
  • When I configure the RS3 base, it is set in Average SINGLE & it averages itself for 10 mins at startup. It is then left on that same spot for the day, simply turning on the Correction Output.
  • The project outputs will all be PPK’d via EmlidStudio & RedToolbox.

My question is this:

  • When I initially set up the base, do I need to take the newly averaged coordinates, switch the Base RS3 to Manual mode and input the averaged coordinates as a fixed location for it? Or can I leave it to do it’s own thing in Average SINGLE.

What effect will either scenario have on the PPK’d results?

To my mind, the results shouldn’t be any different between inputing the averaged coordinates there & then, and just leaving the base as it was when it finished completing it’s averaging. I’ve checked the RS3 help pages, but all the scenarios are either manual known point, or Fixed via an external NTRIP source.

Can someone confirm that I’m doing the right thing…

  • For an unknown spot, RS3 acting as local ntrip source = Average SINGLE mode on the Base with its own averaged location.
1 Like

Hi Nick,

When you set up your base as a standalone receiver without any corrections, the receiver has a SINGLE solution so you can use indeed only average SINGLE. The averaged position will have an accuracy of several meters, so adding the same coordinates manually won’t make any changes.

We have this guide about using average SINGLE for base setup. It contains some more thoughts about the configuration.

4 Likes

Thanks Kormel - That’s what I thought I should be doing, but wanted to double check.

There’s so much other info within the forums where people are using fixed points, with known coords, that I’d begun to wonder if I’d missed having to manually enter the coords.

Given that I’ll be PPK’ing the static base point later, is there an optimum time for that first Averaging period before starting NTRIP?

I’m currently running the averaging at 10mins. I’m still recording the RINEX logs for the post processing against a CORS station after that, so a log path is available for the whole time it’s acting as a local ntrip source. Is there a benefit to longer initial averaging - ie will a longer initial average mean that there’d be less chance of FLOAT/SINGLE results in the PPK’d data when I process the drone files?

I would be recording all those positions relative to that base position on the ground as you are, then retrospectively applying the shift to it’s known point once you have separately processed that.

This is normally done by via what’s colloquially known as PPP (AUSPOS for example does not use PPP techniques and is a network differential solution) but if you subsequently feed enough of your base data into one of the services it will provide you with a known point.

Emlids guide for this is here:

How to correct collected points with a new base position? - Support tips - Emlid Community Forum

1 Like

Hi Wombo,

How is this differing from using EmlidStudio (ES) with a National Geo Service CORS Base Rinex to obtain first the corrected STATIC processed base position, then using that new position to update the Rover readings (via ES Stop & Go) and the Drone images (Via ES Drone, or RedToolbox)?

I’m trying to understand the different methods, because they all seem the same, but all have their little differences.

They’re most likely two different datums to begin with so it will depend on which one matches your target datum, if either. Understand what they are correcting with and how they are pushing them.

There are many ways to skin the cat, but it seems you have a lot of moving parts happening and (at least outwardly here) unknowns in relation to the CORS base, and processing on processing, that together could increase risk of blunders and/or propagating or compounding errors. Or maybe not.

I personally like to keep things simple and have high confidence in my base position accuracy and datum. The positioning services carry out their processing for you with a great deal of rigor using more sophisticated tools, procedures and standards and you can be confident in the results.
And best of all it’s much easier than all the other messing around, simply upload a file.

But you do need to feed them sufficient data for the uncertainty that you need, and you have to wait before you get that stake in the ground so it may not work for you.

As an example, CORS stations in Australia are required to have their positions calibrated and certified by our national authority using (admittedly extensive) AUSPOS processing. They do not have their positions established using adjacent CORS stations in the network.

Hi Nick,

As the receiver has a SINGLE solution, using longer averaging times won’t increase the accuracy.

Yes, the workflows are indeed different, but the goal is the same—getting the accurate coordinates for the desired point. And, as Wombo mentioned, it’s also possible to adjust the base position after the survey.