First test of 2 RS2 units and Lora- discouraging results

Reach RS2 / RS2+ RTK / PPK configuration
1

Had my first test with 2 RS2 units using Lora. I started with total station work on a 5 acre parcel establishing control points around and in the unit. I wanted to tie a couple of section corners about 1/2 mile away, using the units.

I followed the instructions for setting up my base and rover units to communicate. Set my base on one of my control points in an open field for max sky visibility. Used my rover to collect solutions on two nearby control points that had good sky, got an immediate fix and collected 325 consecutive samples (fixed) on each, both showing Easting and Northing RMS less than .04 survey feet.

The section and quarter corners were next. They had more problematic sky, (under winter hardwoods) however I was able to get 150 consecutive samples (fixed) on the 1/4 corner corner RMS < .04 pretty easily. For the section corner I had to wait about 15 minutes but then was able to obtain 115 consecutive samples (fixed) on the Section corner, RMS < .04.

I downloaded the GPS points into my survey (including the assumed base station coordinates) (NAD83/Washington North US foot) and then translated and rotated using the base control point and my best open sky rover control point. the results were discouraging. The parcelā€™s control points were off as much as by .9 feet compared to the total station results (500ā€™ apart). The Section corner was off by 1 ft. and the 1/4 corner was off by 4 feet based upon a previous survey. Looks like I will need to traverse out to the section and 1/4 corner to verify.

Hereā€™s my question? Am I missing something? Do I need to need to tighten up some settings in order to obtain better results? If so where should I start? Thanks for your input.

1 Like
2

Can you show us the environment of the error-points?

1 Like
3

Hello, you have to transform the LLH coordinates of your base to NAD83 to be able to work with rechview 3 in NAD83.
The comparison between a topocentric system (total station) and a geodesic one will have differences due to the cartographic projection

4

As in a photo of the setup points?

5

That seems to be automatic after setting up the project as Nad83 WA. The assumed average position was collected for 5 minutes and reported as NAD83 coordinates on both the the ReachView 3 app and the base coordinates that I dug out from the CSV file.

6

I was under the impression that if I obtained a fixed solution, I could expect centimeter resultsā€¦

7

It is not like this ! after averaging 5 minutes the LLH coordinates must be transformed to NAD83 LLH and inserted to the RS2 base

8

True Agrimgalina, the averaged base coordinates are reported as LLH in base mode. However it does convert to NAD83 in the CSV file. I am not needing to report exact coordinates, only relative ones. No baselines in this survey are longer than 1000 meters and 3 of them are within 150 meters. I do not believe that the projection can cause as much of a discrepancy as I am seeing in expected position.

9

You must first convert the base coordinates to NAD83 so that later Rechview 3 can work in NAD83. it does not matter if it is relative or absolute. The coordinates that you see in rechview 3 will be referred to in WGS84 and not NAD 83. In other posts I explained the differences between wgs84 and nad83.

10

can you recommend a good conversion app?

11

https://www.ngs.noaa.gov/NCAT/

1 Like
12

Thanks for you input Agrimgalina. Conversion could be a problem for my work as I am often unable to connect to the internet in outlying areas. As absolute coordinates are usually not needed for my work would it be simpler to use WGS84 EPSG:4326 as my survey project coordinate of choice?

13

you can work in wgs84 and then in the office do the transformation from one frame to another. There are several free programs

2 Likes
14

First, I want to point out, I am not a surveyor. I do have some basic understanding of the principals. I am good with GPS though.

When you setup your base on one of your Total Station control points, did you manually enter the base data Lat/Lon/Alt from your Total station data or did you do an average like stated in the later post? If averaging, your data will never be close to your Total Station. Without post processing GPS data, it is only as accurate as your base data as all points surveyed are relevant to that.

15

I probably didnā€™t explain it well enough, but I was mainly interested in checking the relative value of the rover positions against my more certain total station positions. The idea being that in obtaining a fixed solution for a given point, I could trust that position. I did that by doing my GPS rover survey, importing the CSV file into my survey and then translating and rotating those GPS coordinates using my best match between 2 points.
I think the problem lies in that 2 GPS observations were on points with less than perfect sky (winter hardwoods). I am confused though because I managed to get fixed solutions on both those points with standard deviations less than .04ā€™.
Do I need to raise my elevation and SNR masks? Not sure.

16

You didnā€™t answer my question. When you setup your base, did you do an average or manually enter the coordinates?

17

I have the same question. I also have a question regarding what you said here:

I just want to make sure that means you had setup a project in Reachview 3 using EPSG:2285 (if Iā€™m not mistaken), exported the points you surveyed in that project, and then imported them into whatever processing software youā€™re using.

As for how the base coordinates were entered in the Reachview project, how was that achieved? Manually entering the values from the survey mark report in NAD83?

From what I understand, you were not concerned with absolute accuracy and just wanted to check your points relative to the base. Usually, it should be pretty good but my main concern is that conditions werenā€™t good enough for that because of tree cover. Is this a comparison with another set of RTK receivers? Have you been able to achieve good results with other GNSS gear?

19

Hi @plsurveying60,

Let me elaborate on the points collection workflow to make it clearer.

  • Get LLH base station coordinates

  • Enter them in the ReachView 3 Base mode tab on a base unit

  • Choose the LoRa radio option on both base and rover

  • Create a project in the ReachView 3 app

  • Collect points with a rover. With the LoRa radio, you can work on up to 8 km distance if thereā€™s a line of sight between the base and rover.

In case you work in NAD83/Washington North US foot, the base coordinates should be entered in NAD83. In case an incorrect coordinate system was used on any step, it might cause a shift in the coordinates.

May I ask you to comment on the following points? It will help me to understand the issue fully:

  • What is the coordinate system of the points you got with the total station?

  • Are your base unit coordinates entered in the Base mode tab in NAD83 (in degrees)?

2 Likes
20

Hi Keseniia,

This is the first time I have been able to use 2 RS2 units communicating over Lora radio. I have set up the units correctly to communicate corrections to the rover.

First, let me explain my reason for this project: The job was to survey a 5 acre tract, with control points tied within a 1500 meter radius. So, a relatively small area. It offered up all kinds of sky, from completely open to sitting in the middle of winter hardwoods and scattered deciduous trees. My intention was to gain confidence in the roverā€™s ability to deal with the challenges of various sky conditions. The initial survey was done by total station, ground distances recorded in US survey feet. Coordinates were calculated and plotted in Autocad.

I set up my base in an open field in the middle of the 5 acre tract (about the middle of the survey), averaged 5 minutes of single observations and the RS2 recorded an assumed base point. LLH, . I averaged 3 minutes of fixed status observations on each control point (except for one section corner where I was only able to get one minute of continuous fixed points).

Iā€™ve been told LLH needs to be converted into NAD83 if thatā€™s what my projects are set up as. However in this case, I was only interested in the relative accuracies of each observation and not on the absolute accuracy. I understand that there could be a small discrepancy using a projected datum to compare to ground distance obtained coordinates, however the project was so limited in scope and size, that I would guess it to be minimal. I exported my CSV file and brought in into my Autocad project. Found 2 of my best open sky rover observations and fixed and rotated the entire csv file. Then I looked at the the GPS positions for the control points that were more challenging and thatā€™s where the disappointment lay. I had thought, probably erroneously that if the rover was collecting fixed positions, then I could trust the outcome. One of the observations under canopy was 4ā€™ off.

I have done some more work in this project, greatly increasing the sample of control points I can observe. I will let you know the results of this when I get the chance to occupy them.

If you have any suggestions for obtaining better relative accuracy, let me know. Otherwise I feel I will not be able to trust the results of an observation unless I am in a great sky environment.

A second question regarding conversion of LLH base coordinates to NAD 83. (In the situations that merit it). If this cannot be done in the field due to lack of internet connection, how would you suggest I proceed? Record in WGS84 for my area? And convert to NAD83 later? How would I do that if my intent was to establish points using Lora base and reciever, and my stakeout points were in NAD83?

Thanks for your time, Keseniia.

21

Update on my second try at this. This time I had 8 control points that I sat the rover on, including 2 under heavy deciduous forest canopy. The other 6 had varying degrees of canopy but a fair amount of clear sky. I obtained excellent results on all points except for the one I had to struggle with to get a fixed result. That control point was under deciduous winter canopy on the edge of a clearing. There were a lot of openings in the canopy except that there was one large evergreen that probably blocked 33% of the sky just behind the point. I waited about 10 minutes before I got a fixed position, but I did get a full minute of fixed observations. This position ended being off by 6ā€™. All others were within 0.08 feet including the one that was in heavy deciduous canopy and the one that I thought would have given me the most trouble.

So overall pleased with the results. However, disappointed that I got a fixed solution for a challenging point. I would have hoped that if Reach reports a fixed a fixed solution I could trust it. I much rather not get a report of a fixed solution in cases like this. Any ideas on how I should tighten things up to make sure that a fixed position is what it says it is? Raise the elevation and SNR masks?

Thanks for your input.

3 Likes