RS2 Lora corrections

I have been using 2 RS2 for a couple of years now and need to get some clarity on accuracy of these units with no NTRIP service. I use 1 unit as the base and the rover is mounted on a geophysics device. If I average my base for 20 to 30mins and broadcast corrections over Lora radio, I was under the impression that this would provide relatively accurate results to 0.5m or so. I am finding that the unit accuracy is more like 2m to 3m in this configuration.
As most of my surveys take place in fields with no known points and NTrip is not an option due to cost. How long should I be averaging to achieve 0.5m accuracy or better.

1 Like

Hi James,

Using averaged single for your base point, your rover points are never going to be globally accurate. But as I understand it, your rover point should be relatively accurate to your base point.
For example, if you average on a point with your base for 30 minutes, and then send corrections to a rover from that point, and then next week, you set up the base and rover on the same points as before, and you use the same base point coordinates as the first time, you should be getting “relative to the base” the same coordinate for the rover as before.
Is that what you are doing?


You need to understand relative accuracy vs positional accuracy. It sounds like you are looking for positional accuracy. If so the way to do that is log static data at the base then submit to a post processing application like opus then translate your rover points to the new base location.

The rover is always related to the base.
Under your scenario its makes no difference if you average for 1 second or an hour. You are only getting relative accuracy. You will have to observe longer (static files) preferably multiple times and post process to get positional accuracy.


Hi Dave
I am never back at the same location. I am trying to get an accurate position on my base to send accurate correction positioning to the rover on the geophysics instrument. I must pass accurate positional info as there is no way of post processing the data from this device.

1 Like

Hi Jim
I have no way of post processing the data, as once the corrections are sent to the geophys instrument they are hardbaked into the survey data. I must send positionally acurate corrections.

Hi James.

As I stated earlier, if you show up at a site and set up a base to send RTK corrections to a rover, if that base position is not known, there is no way to “make” it align with a coordinate system by using “Average Single”. You can let it average for hours, and it will not know where it is precisely relative to a known coordinate system. You can use an average single observation point to send corrections to a rover, and that rover’s position will be precise “relative” to the base. But the base doesn’t know exactly where it is with relation to a coordinate system, so there no way for the rover’s position to be precise to a known coordinate system either.

If you cannot determine the position of the base by either an RTK workflow, and there is no way to post process that base position later by either a PPK workflow from a CORS log, or PPP workflow. then you are going to be precise relative to a coordinate system to only about a couple of meters at best.

If all you need to know is the position of the rover point relative to where the base point is, but not relative to a coordinate system, then you are okay. Hopefully this makes sense. Have a look at the Emlid tutorials. They define how to use the system.


I dont understand why you cant adjust your final results later. Under your scenario you would have to go out a few days ahead of time and log static data at the base location then post process that data for a true position. Then on day of survey enter the post processed base cords.

1 Like

Once the positioning is into the Geophysical survey software I have no access to that data.
I could potentially put a correction to the output file Geotiff but I not sure how that is done

Thanks Dave.
Is there not a possibility to get accurate positioning from the NTRIP Emlid Caster.?
Although I tested that today and it sent no corrections.!

Hi James, how far are your worksites from your home or office? Emlid caster could work great for you. Emlid caster is only a relay for your own corrections. So you would need to set up your base on a known position (that has access to internet) and your base would then stream corrections to emlid caster. Then emlid caster will relay those corrections to your rover. If your home or office is within 30km from your worksites you could make a more permanent mount there for your base or create your own benchmark where you would set up a tripod. You would then use NRCAN PPP or OPUS and a long observation to give you the location of your installation or benchmark. If your home or office isn’t near your worksites, but if your worksites are near each other but farther than Lora can work, then you could create a benchmark as a known location in the middle of your worksites as a location for the base. You would then have to figure out security for your base when deployed and internet so that it can send corrections to emlid caster which can then stream to your rover.

1 Like

James. let’s back up a little. Can you explain what you are trying to achieve with your kit? Are trying to tie the positions you collect to a coordinate system or are you trying to record positions of objects relative to each other?


Hi Dave
I am trying to provide accurate locations of subsurface anomalies. So that archaeologists can dig is the correct locations preferably within 25cm. If my ‘images’ geotiff’s are offset when I import into QGIS the stakeout points will be misplaced.

1 Like

Thanks James.

What coordinate system are you referencing your data to?

How will the archaeologists locate or reference your points when on site?


Do you have known NGS monuments in your area that you can locate to back in a position for your base?
Without doing static data and processing your position will be off. If you shoot a known point from your base then you can inverse the two and calculate a fairly close point. Then fire up your base with the keyed in position.

What we haven’t understood yet is how what I guess is your ground penetrating radar receives position data from RS2. Can it sync its scan data with a position file a posteriori or is the only way to apply geolocation done in real-time through the serial/bluetooth output on RS2?

If the former is possible, then you can use a post-processing sequence like PPP, to get a good base station position, then post-process the rover log before importing it in your software.

If only the latter is possible, you absolutely have to tie in a common reference frame (between your scan and what the diggers will use). One way would be to connect the base with an NTRIP service so it always has good accuracy. The other is to install a semi-permanent reference at the site and provide its coordinates to every user. Absolute accuracy becomes unneeded as long as everyone uses that reference and the same coordinates. A long steel rod driven in the ground is good enough.


This reminds me of the old days, NAD27, no GNSS and also lack of passive control. Many miles to terrestrial traverse by EDM to a published mark.

Back in the early days of my dad’s business, we referenced all our surveys by astronomic north/grid north (NAD27).
In order to have an accurate azimuth whether by solar or stellar observation, the process required a geographic position usually scaled from USGS quadrangle maps. If care was taken in the scaling, you could realistically have a <100’ accurate position if the traverse was tied to a local road intersection or other prominent feature on the map. After the azimuth was determined, we converted the scaled geographic position to NAD27 state plane coordinates. This was long before the availability of the internet and the beginning of the desktop computer as well as the handheld HP 35. We were fortunate to have two late 60’s mini mainframe computers (i.e. Pacific Data Systems PDS 1020’s) we did all our survey computations on.

After conversion to state plane coordinates, we were effectively “tied” to the state plane system. However our coordinates were only “relative” to our scaled position.

Fast forward to the early 90’s when GPS receivers became economically available and the new NAD83 datum, we have consistently referenced all our surveys to the NSRS (National Spatial Reference System). What’s so amazing is all that the old surveys done in the 70’s and 80’s are fairly accurate spatially in reference to the new surveys performed since the 90’s.

Horizontal positions varied, but were well within the 100’ approximate position scaled, azimuths determined by astronomic observations were basically below the 1 minute angular accuracy and in some cases were even below the 30 second angular accuracy comparing to NAD83 datum/state projection azimuths.

Gabriel 's advice by setting a permanent mark is excellent. We always “hide” control marks on each project even using GNSS. If everyone uses the same passive control mark then everything located will be tied to the same local system regardless of absolute accuracy. Then sometime in the future, all positions determined from the local passive mark can be adjusted to an accurate absolute position.


I would think that for a project like James (the OP) is describing, unless they are dealing with property boundary lines and ownership issues on the project, just establishing a point of reference and tying all markers to that would make life on the project much easier for everyone.


In these cases, I set up the base unit and let it log. If you chose to do RTK over Lora then as others have stated you have “relative accuracy”. But I just do the survey on my rover (no connections) and come back the next day and do PPK on your Base unit. Now that you have good coordinates (absolute accuracy) for your Base, you use the “new” correct coordinates to now do PPK on your ROVER points using the RS2 Base log as reference. If you flying a drone, then you would use the same Base file with the NEW ppk coordinates to do PPK on your drone images. The same would apply to Lidar, or any other sensor that supports PPK. This is why PPK is for the most part, my standard protocol. Hope this helps.

I believe in the OP’s case, whatever device/software he is using is baking in the corrections in the field with no opportunity to PPK later. Thus all the recommendations to just set up a local reference network that all trades can use for reference.

I like this as I have used this method in an engineering project yrs ago.