RTPK Elevations vs Base Processed RTK Elevation from 6 Mile Baseline

Matt Johnson

Well-Known Member
5PLS
I would start with setting it to auto repeat points for about 2 hours at one location, maybe at your house if it is far away from the office. The RTPK interval does not matter.
 

Wes Hand

Active Member
The project I sent has 33 shots at the same location. 1st shot rtk and rtpk love each other. After that first shot it grew. Wide open skies. No canopy.

Auto store and auto start was on. Rtk was set to 300 seconds and rtpk was 2 minutes.
 
Last edited:

Matt Johnson

Well-Known Member
5PLS
The project I sent has 33 shots at the same location. 1st shot rtk and rtpk love each other. After that first shot it grew. Wide open skies. No canopy.

Auto store and auto start was on. Rtk was set to 300 seconds and rtpk was 2 minutes.

Did you compute the Survey Statistics for RTK and RTPK so that the precision can be compared?
 

Sam Glenn

Member
I talked with Josh(@nusouthsc ) today regarding this issue. My office is located about 9 miles from his office base setup so i felt this was a perfect setup to run some test since the problem is at >5miles. I have uploaded the project to support. The project name is RTPK Test. The serial number of my unit js 796.

There are 46 shots in this project and if i take each of these shots and average them down to one point, the difference between the RTK and RTPK is 0.066’Hand 0.069’V.
This test was ran over a 2.5 hour period. The relative accuracy report shows some wider margins out to 0.2’H and V but i don’t know the validity of that report without some input from Javad.

I hope this helps sort out any issues. Let me know if you have any questions or issues with the uploaded project.
 

nusouthsc

Active Member
I sent another project called NuSouth RTPK Test Serial# 00783. Shots 1-100 are from the office base at 9.88 mi. Shots 200+ were taken from the network. As you will see from the office base the precisions were not great. From the network the precisions were fantastic. I have also provided a link below to anyone else that would like to view it.


I certainly hope we can come to a resolution on this as I still do not know what to trust.
Thank you.
 

Matt Johnson

Well-Known Member
5PLS
I see in both these projects the bases and rovers are not aligned to north. Due to absolute calibration being used with RTPK, the receivers need to be aligned to north. In the last test I did on this issue there was 0.05' of horizontal error introduced between the RTK and RTPK when they are not aligned to north.
 

nusouthsc

Active Member
Matt,
I’ll try this again oriented better. However, this issue just showed up where it had not previously. And in some of the points the difference was nearing 0.20. Also, when I switched to the RTN I was using the same orientation and the agreement was very acceptable. Any idea why it wouldn’t show up using the RTN?
 

Adam Plumley

Active Member
JAVAD GNSS
Matt,
I’ll try this again oriented better. However, this issue just showed up where it had not previously. And in some of the points the difference was nearing 0.20. Also, when I switched to the RTN I was using the same orientation and the agreement was very acceptable. Any idea why it wouldn’t show up using the RTN?
Becuase the rtn base is virtual and very close to the rover.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
Here we investigated what LONG baselines for RTPK are. So we took 3 receivers: Triumph-LS as a stationary rover and two Triumph-3 receiver as a bases. TLS was in open. First T3 was a stationary base (Base 1) at 30 meters apart from TLS. Second T3 receiver (Base 2) was moved 1, 3, 5, 7, 10, 15 km apart. 15 minutes observations at every location. Then exactly the same 15 minutes datasets were processed: Base 1 - TLS, Base 2 - TLS. Splitting parameters were 30 sec, 1 min, 2 min, 3, min, 4 min, 5 minutes.
 

Attachments

  • Survey statistics-2022-04-07.zip
    1.8 MB · Views: 74
Last edited:

Jim Frame

Well-Known Member
Can you upload this document as a PDF? I don't have Microsoft Word, and LibreOffice apparently can't interpret it correctly.
 

Attachments

  • t.jpg
    t.jpg
    169 KB · Views: 49

nusouthsc

Active Member
Here you are
Alexey,
This is great data to have and I feel like I have seen much the same results. However, it has been my suspicion throughout this dialogue that the RTK was the problem. I have not done extensive testing but I have had several situations at greater than 20 miles that the RTPK values have matched RTN values beautifully. Is there a way we can determine the source of the error I am seeing? Thank you again for your great work.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
I believe the best way to determine the source of errors in your case would be repeating this test with your local base
 

Adam

Well-Known Member
5PLS
I did a test with a 23 mile baseline. RTPK hit within 6 Penny's of the rtn location reliably and repeatedly. RTK was .$.35. if working over 5 or 6 miles I would definitely rely on RTPK over RTK.
 

nusouthsc

Active Member
I did a test with a 23 mile baseline. RTPK hit within 6 Penny's of the rtn location reliably and repeatedly. RTK was .$.35. if working over 5 or 6 miles I would definitely rely on RTPK over RTK.
Adam,
That has been our procedure since this issue arose.The only issue with that is when you have a good RTK shot with variety and no RTPK and knowing every other shot on the job has been missing RTPK 0.15’. So essentially the RTK is “close” but not great.

Today I ran a shot at 3 miles from the base and I was 0.08’ from RTPK in the totally wide open. The RTPK was almost perfect compared to RTN point. I let RTK run for 25 min to see if it ever would agree. We are seeing the RTK solution degrade almost immediately now. If we go over a few miles we wont have hardly any shots agree.

This issue seemed to arise when we upgraded to 4.0. Not certain thats the case but it seems about the same time. All I know is something changed. I appreciate everyones input and hopefully it can be resolved.
 
Top