New Reach RS Owner Problems with PPK

Reach RS2 / RS2+ RTK / PPK configuration
1

Hello all,

I am a new owner of a Reach RS2 and RS+. I am having problems with my PPK output in that is is not too accurate.

I did get RTK to work by placing RS2 on a known point and then using stakeout mode to find another known point. This actually blew my mind as I could not find the point with a map in hand so I used RTK to find it.

Next I tried to learn PPK and now I am having problems.

I tried two different times and got bad results.

This last time I logged for 2 hours on a known point and then used a CORS station which is around 40km away. I wanted to see how close PPK would be to what the points coordinates were.

I am doing this is a closed airport, so there is all open sky around me.

I used CORS NJCM for my Base.

The known points data is:

NAD83(2011) 39 21 36.67824, 074 27 25.36127 Ellipsoid Height -32.371
This converted to 39.3601884000 -74.4570447972

My PPK result is: 39.360192746 74.457047047 -31.8985
image

In the beginning of the log there are all 5’s for Quality for the first 1/2 hour.
Then there are 2’s for Quality for the next 1/2 hour and then 1’s for the next half hour.

I am not sure though if the logs from the CORS were for the correct time.

I logged from 6:21 PM EST

I downloaded from the CORS 18:00 (6PM) UTC with the option for -5GMT from UFCORS.

Any help is greatly appreciated in advance.

2

Hi Jamieson,

Can you post the logs you used fir your ppk analysis (if the site won’t let you, you can use a file transfer service). It will let others double check your results.

If you are getting Q=5 [single] solution for 30min, then your base file does not completely overlap your rover observables and you should download an extra hour before the period you downloaded.

Also the statistics that are shown in RTK plot are dependent on your RTKPlot settings. For example, if in your options the origin is set at the average and you are displaying all of your position outputs, it is including your single and float results in the average. If you set Q=1 in the display, it will show the average of your fix solutions. You could also try running the ppk as Static and with output as Single in RTKPost. When that completes you can view the position file and you will see only the best solved output.

2 Likes
3

Hi Jamieson,

I agree with @Africawaterdoc, we need your raw data to draw any conclusions

5

Ok thanks for your help and here is a link to Google Drive with the Reach Logs and also the CORS logs.

Reach:
https://drive.google.com/drive/folders/15VHLFI7ZtjlqXshv4oa9cCPBbvomrQYH?usp=sharing

CORS:
https://drive.google.com/drive/folders/1kndcUS94lyXUbrBARhnhAK_K4MI0oQl1?usp=sharing

6

Hi Jamieson,

I’ve downloaded the data, thank you! I’ll take a look at it and will get back to you.

7

Hi Jamieson,

What was the height of the RS2 ARP over the NAD83 monument you set up on? Your obs file for the RS2 lists it as 0.0, but I’m seeing a reasonable discrepancy in the height over ellipsoid on the ppk analysis that’s in the range of the RS2 being mounted on a tripod.

8

The pole was 1.5 meters and the Reach added 134mm, so I was using 1.634 meters.

I have been running the logs over and over with different settings. I also am running different logs taken in the same general area. The majority are all Float. There is nothing obvious that I see that could be causing interference. It is an old closed airport. All buildings and the control tower are long gone. It’s just open fields, tarmacs and runways.

I guess I will have to find another area to get logs to see if I can at least start to get the majority Fixed.

Here is the area I am in with the monuments marked. Its about as open sky as you can get in a city.

image
image2101×1262 701 KB

9

I tried using a different CORS station. This one was a bit far at around 70 km, but was listed as as a 1 second rate instead of the closer one that was 5 second or higher. (I cannot tell as the rate is color coded and I am color blind/confused especially with red and green).

I now got 90% Fixed, with the majority of float being in the beginning of the log.

But now the coordinates given are off by a good deal.

The known coordinate I am using is: 39.3601884000, -74.4570447972 converted from the data sheet below.

image
image608×626 20.8 KB

image
image1118×690 18.8 KB

Should I just use the known point and make my RS2 the base and then use my RS+ as the rover?
I happen to be in the worst place in my state (New Jersey) that places me perfectly far away from all the CORS stations.

10

Are you sure these are correct / correctly converted?
When I load the CORS obs file, even a Single-solution of the point is far away from the above coordinates.
Are you sure you have the right point looked up ?

I also get what your RTKplot screenshot says, and that is using other bases than the one you attached.

11

I am sorry. The last example was just me trying a different area nearby just to see if I could start to get Fix instead of Float for the majority of my logs. I mixed up my logs.

The 2nd example in RTK with the RS2 on the known point from my first example to start this thread) (Collected for 1 minute 48 seconds with my RS+) using Lora) was 39.35721062, -74.45690587 and my PPK result was 39.357210735, -74.456906136 with ~90% Fix.

I will try again this week and will try using 3 different CORS Stations, but they are all far away ay 45, 70,80 kms.

12

Instead of relying on long baseline CORS, why not harness the simplicity of a PPP solution like NRCAN’S service? It works everywhere, doesn’t rely on an external reference, and will give you very good precision and accuracy if you observe for long enough.

If you put your RS2 on the field for 4 hours, you’d be in low centimetric territory. Even with a 2h observation I usually get sub-5cm.

1 Like
13

If you want accuracy to be within 2-3 cm, you have to wait for the precise product, which is usually at least 14 days

14

Hi Jamieson,

I took a few cracks at your data with RTKLIB and here are my results.

First, I’m using RTKPOST demo5 version b34b from rtkexplorer.com. As I was analyzing you files, to help out I defined expected error circles based on the specs of the RS2 and the baseline. Your baseline is approximately 41.5km which gives a horizontal error of:

4mm + 41.5km*0.5(mm/km) = 24.75mm CEP (50%)
This is equivalent to 51.5mm R95%

Vertical error:

8mm +41.5km*1(mm/km) = 49.5mm CEP (50%)
This is equivalent to 102.9mm R95%

Quick note: I’m using the assumption that the RS2 specs are defined as CEP 50%[circular error probable 50%], as this is how it is specified in the Ublox F9P spec sheet. CEP 50% is essentially stating that statistically 50% of the measurements should fall within the defined range. Converting CEP to R95% where 95% of the measurements should statistically fall within the error range gives a more realistic picture of validating the results.

My first run gave me the following output:
% program : RTKPOST ver.demo5 b34b
% inp file : C:\Users\WDAGUtilityAccount\Desktop\REACHRS2-20210508T085810Z-001\REACHRS2\OEMBase-raw_202105042223_heightAdded.obs
% inp file : C:\Users\WDAGUtilityAccount\Desktop\CORS05042021-20210508T085829Z-001\CORS05042021\njcm1240.21o
% inp file : C:\Users\WDAGUtilityAccount\Desktop\CORS05042021-20210508T085829Z-001\CORS05042021\njcm1240.21n
% obs start : 2021/05/04 22:24:02.0 GPST (week2156 253442.0s)
% obs end : 2021/05/05 00:31:20.0 GPST (week2156 261080.0s)
% pos mode : Static
% freqs : L1+L2/E5b
% solution : Forward
% elev mask : 10.0 deg
% dynamics : on
% tidecorr : off
% ionos opt : OFF
% tropo opt : OFF
% ephemeris : Broadcast
% navi sys : GPS GLONASS
% amb res : Continuous
% amb glo :
% val thres : 3.0
% antenna1 : EML_REACH_RS2 NONE ( 0.0000 0.0000 1.5000)
% antenna2 : LEIAR10 NONE ( 0.0000 0.0000 0.0000)
% ref pos : 39.100665835 -74.802895660 -25.3065
%
% (lat/lon/height=WGS84/ellipsoidal,Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp,ns=# of satellites)
% GPST latitude(deg) longitude(deg) height(m) Q ns sdn(m) sde(m) sdu(m)
2021/05/04 22:24:02.000 39.360188173 -74.457045059 -32.4036 1 8 0.0004 0.0003 0.0006

I pasted the position file so that you can see my RTKLIB Settings. Only settings that don’t show up here, I chose to interpolate the base (since the interval is high) and chose that the output would only be a ‘single’ point (instead of all epochs).

Putting these values into NGS NCAT gave:
[NGS datasheet values]

Zone 18N
N 4,356,888.877
E 546,776.280

RTKLIB Values

Zone 18N Difference Square
N 4,356,888.852 25.000 625.00
E 546,776.257 23.000 529.00
Sum 1,154.00
Delta 33.97 mm

This delta is higher than the CEP50%, but less than R95% and doesn’t consider errors in the setup over the BM. So this is a valid result for that baseline length.

For height, the Delta is 32.6mm, which is within the CEP50% for a baseline of that length.

I did a few more runs with using GPS only, Precise Ephemeris, Changed Iono to Broadcast and and ran (1) Tropo as Estimate ZTD (better), and (2) Tropo as none (best). And looked at the height only. These gave deltas of 20.3mm and 2.6mm, both of which improved on the height. I didn’t run the latitudes and longitudes through NCAT to compare the horizontal improvements for those settings, but at a glance they seemed good. If you need better precision, you likely would need multiple baselines and a least squares method (software) or a smaller baseline. I also agree with the other guys, that NRCAN would probably give you just as accurate a position if you have the time to wait for the precise product.

Unfortunately, I don’t have time to screenshot all of my settings, but here is the configuration file that you can load into RTKLIB (probably needs the b34b version):
BestRun.zip (1.7 KB) .

Main point, I hope this gives you hope that it is possible to post process this baseline from that CORS site. This was a lot of info that I was trying to type fast, so let me know if something wasn’t clear or if I glossed over a point.

Best-

2 Likes
15

Thank you very much!!!
I highly appreciate your time and knowledge.

To the poster who inquired about PPP, I am going to use PPP, but I am trying to be able to be competent in RTK, PPK and PPP in order to get the most out of my purchase.

I am getting near to being able to start my drone mapping of beach erosion for the municipality that I work for. I now have to learn how to use the BaamTech PPK kit on my Phantom 4 Pro.

While absolute accuracy is not needed at this point, I feel that I should be able to attempt to obtain it if necessary for the future.

For my own knowledge, if I obtain my own point in my mapping area and use this for all of my mapping, my relative accuracy should be good?

16

Is my problem with the majority FLOATs because my CORS station is using NAD83 (2011) and I used the RTKLib option to get coordinates from the RINEX header and the header uses NAD 83 (2011)?

If so, would I convert or transform the coordinates from NAD83(2011) to WGS84?

I am now learning RTK, and I have run into this problem as I am using a known point with a datasheet that uses NAD83(2011).

17

No, NAD83 (2011) wouldn’t be the problem causing the majority float situation. The when the RTK software solves the double difference equations using a base and rover, what those equations actually output is a baseline vector from the base to the rover (simply meaning it gives the distance from the base to the rover in 3 dimensions). So if your base is in NAD83, then the rover’s position is the base position plus the difference found by RTK and the result will be in NAD83

Is this the same dataset you previously posted?

What version of RTKLIB are you using?

One option would be for you to screenshot each page of your RTKPOST options so I can review your settings.

18

Is this the same dataset you previously posted?

No, this time I was trying to learn RTK. I used a US National Geodetic Survey Monument which gives its position in NAD83(2011).

What version of RTKLIB are you using?

rtklib-qt-win-v2.3.4b33+5ad5e4f

Unfortunately, my ignorance in things geodetic combined with reading too may things that I have not fully understood has me more confused than ever with both PPK and RTK. Add in that all of the known points I have access to are in NAD83(2011) along with the CORS stations and it adds another layer of difficulty for me.
My end goal is to be able to:
Use RTK to place GCPs for drone mapping
Use PPK to use a new PPK kit I had installed on my DJI Phantom 4 Pro from Baamtech

So I will need to have to be able to use both RTK and PPK.

What I really need is just a workflow for each that I can follow. I still have yet to try to learn Baamtech’s PPK software since I really want to be able to know how to use my Emlid units correctly first.

I am not sure if I should make a new thread on RTK since this one is about PPK.

I am open to all and any suggestions on a workflow for each.

21

Hi Jamieson,

I got 100% in Fix with the logs you shared when switching from the Forward processing type to Combined in the latest version of our RTKLib. It closes the gap between fixes by tackling the job forward and backward and combining the results. If you get any significant shifts using this workflow, please share the coordinates of the calculated and known point in WGS84.

For my own knowledge, if I obtain my own point in my mapping area and use this for all of my mapping, my relative accuracy should be good?

For relative accuracy, it’s enough to place the base on an unknown point and average its position in Single. If you get a point with a PPP service and enter its coordinates on your base, you will get absolute accuracy.

Would I convert or transform the coordinates from NAD83(2011) to WGS84?

The coordinate system chosen in the ReachView 3 doesn’t influence the raw data log. So, RTKLib will read the RINEX header correctly.

So I will need to have to be able to use both RTK and PPK. What I really need is just a workflow for each that I can follow.

I can hardly be of much help with the PPK in Baamtech software. For GCPs collection with your Reach RS2 and Reach RS+, you can follow our detailed guide on Placing GCPs in RTK mode. Please note that multi-band receivers require multi-band corrections. So, Reach RS2 can work as a base for Reach RS+, but not vice versa.

22

Thank you very much.

24

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.