I am preparing to work on a site out of any internet connectivity and need to collect GCPs, for a LiDAR flight. I have one RS3 so only working with rover and trying to rely on the CORS as base. I tried testing the following workflow and my corrected RMS had a huge shift 17 cm turned to 2.8m. The result was my data being shifted farther from my RTK data of the same points I used to compare.
Workflow used:
Start Logging on Reach RS3
Collect Points in Survey project with Emlid Flow app
Stop Logging in after the survey is done and download them
Download the log from the NTRIP station, which matches the time period on the rover
use the Stop & Go with Emlid Flow in Emlid Studio Inputs
Rover .24O file from Rinex logging download
BASE: .24o from Local CORS ntrip data
Navigation .24n From CORS ntrip data
Processed Solution: .pos file from above generation
Project from Emlid flow: survey project csv (Float and Single for Data quality option.)
Took corrected csv, imported to same survey project on flow, and re-exported new csv to put into local map to compare to my rtk data of the same points to test this ppk workflow
I think this Navigation File should be from the Rover and not the Base?
Also, some CORS when you go back and get the data from the archive only log in 30s intervals. So if this is the case, you will notice a high RMS if you have done short observations at each point.
What’s your occupation times and distance to nearest CORS ?
Short baselines are ideal for post processing, i.e. you need a base in the project area.
Usually, long occupations of each GCP will ensure accurate positioning.
Long baselines with short observations WILL NOT give accurate positions.
Using commercial post processing software with adequate observations will give you the confidence in your final solution if using multiple CORS that have reasonable baselines. Using this, you have closed observation polygons where you can actually know your GNSS traverse closures.
So my baseline here is 3,600 meter (for the site I will eventually work its like 500 meters, lucky to have one at my site but no cell service), I did 3 minutes averages for each point .
I never achieved a fix (Looks like maybe that’s expected with reach when not receiving corrections)
I will look into 4 and 5, im thinking I do need to go that route outside of Emlid Studio.
Am I barking up the wrong tree in expecting that I can manage to use just one Rover (RS3) and post process those points using CORS to refine that to cm? My work has slowly taken me farther into need to understand surveying more, so admittedly I have a lot to learn.
Yes, you can use a single rover for cm work for either static or using RTN if cellular coverage is good. If using RTN, log data also, enough time to post process if needed.
There’s nothing wrong with Emlid Studio as I have used it occasionally, but the software has no multiple baseline processing or adjustments. If using Studio, make sure your fix quality is at least 98% and that you have multiple ways to verify the computed position. Using Studio single baseline processing, you have no guarantee of the position accuracy of the computed point without verification. If after post processing using Studio, verifying from another base and reoccupying each point again will give you confidence in your final data.
NGS OPUS is an excellent tool for single rover use. Just make sure you have adequate observation time for each point. Using 10-30km baselines to CORS, you should occupy no less than 30 minutes. If using longer baselines, occupy no less than 1 hour. This is a sure fire way to guarantee accurate positions. Make sure all observation points have good clear sky conditions.
I despise revisiting a site for lack of data. If you think you need 30 minutes, occupy for 45 minutes. Commercial post processing software will make your job easier and give you confidence in your data.
I may be barking up the wrong tree here…but the differences look systematic - that is they are of the same basic magnitude and direction. When I see that I always ask myself if I’ve made an error in something that would lead to a systematic error…chosen CRS vs CORS CRS…something that would give rise to a systematic error.
In general, using CORS data to perform Stop&Go in Emlid Studio is a fair workflow, and you can obtain accurate coordinates for the collected points. But I agree with Bryan that it’s better to work with short baselines.
The .24P is the mixed navigation file containing data for all the satellite constellations. However, the .24N has data only for GPS.
If I understand correctly from your description, you have three sets of points: the original CSV, the corrected CSV from Stop&Go, and the points collected with RTK. If everything works smoothly, the points from Stop&Go and RTK should match. The points in the original CSV are expected to be different as they were collected with a SINGLE solution, so they have meter-level accuracy.
I’d like to check your data to investigate the reason for the difference and the high RMS values. Can you please share the recorded logs from Reach, the files from the CORS, and the CSVs with me? As they may contain confidential information, you can also email them to support@emlid.com. Thanks!
