I’ve just bought a Reach RS3 to help me to survey a number of remote historic mining sites in the UK. I’ll be using the RS3 as both a Rover (for obtaining point positioning data for buildings and for GCP’s/CP’s) and also as a base to provide local NTRIP correction for a DJI RTK Enterprise UAS.
I had been hoping to utilise a fairly local NTRIP caster that is available on rtk2go, but have found in the test Emlid-Flow surveys Ive done, when the rtk2go NTRIP is enabled, that the height data recorded is consistently incorrect - which leads me to believe there’s an issue with the rtk2go ntrip station.
Is there any way to extract the original WGS84 positioning from the Emlid Flow projects - ie to remove the erroneous NTRIP corrections from the survey so that the points can be re-corrected via Emlid Studio PPK with RINEX files downloaded from my local OSGB CORS base stations instead? (ie to set the existing surveys so that they’re as if they had been recorded without the NTRIP connected.)
The error came to light when I recently accompanied another UAV pilot with a Trimble DA2. The heights I obtained from my RS3 & the DA2 where:
[I’ve also cross checked with a location I regularly fly from and the takeoff height is routinely reported as 214.2m (MSL) by the UAV logging (Airdata), the RS3 in Single mode reports it’s height as between 213 & 215m (ODN geoid) (265.49m ellipsoid) without ntrip, and as 221.815m (ODN geoid) (271.818m ellipsoid) with NTRIP input.]
Remember that RTK2GO is an “open-source” NTRIP “provider”. Everyone can contribute with their own data, and there is zero guarantee that the base-positions are properly tied into the national/state references. I would go so far as to say that none of the stations are.
Certainly, you just take the rover Rinex/Ubx file from the receiver. However, it only works if you haven’t used the tilt-function, and instead have manually leveled the rover-pole.
I’m aware they’re open source, but as the NTRIP source was from a University site I’d rather hoped they’d have had some idea of what they where doing and it’ would have been a reliable source! But we all live & learn - that’s why I’m testing & benchmarking my own systems first so I know I can rely on them.
Tilt was off & the pole manually aligned, so that’s a good start.
Which option do I process it through on Emlid Studio? I have a RINEX file for the same time period from an OSGB CORS station that was less than a mile away.
Stop & Go?
RS3 .24O into Rover
CORS RINEX into BASE
RS3 .24P into Navigation
That processes and shows me a ground track for the time I was measuring the GCP’s. But when I try to process the Project export CSV with FIX, Float or Single checked, Emlid Studio simply sits there saying “Preparing” and doesn’t proceed to give me any output - cancel doesn’t work & I have to force quit the program
Forgive me if I’m asking daft or simple questions - I’m new to the whole GNSS/NTRIP processing and I’ve been trying to get up to speed & absorbing a lot of info which is leaving me with my head spinning! I’m sure in a month or two it’ll all seem second nature, but right now the fog isn’t lifting very quickly!
Reach in Single is in the WGS84 datum. This explains the elevation difference when the Reach RS3 receives correction from the NTRIP service (assuming it’s broadcasting corrections in ETS89).
The error came to light when I recently accompanied another UAV pilot with a Trimble DA2. The heights I obtained from my RS3 & the DA2 were:
The values show that the difference is almost consistent by around 9.5 meters. This looks like a systematic error, probably during the setup.
If you could tell me all the details about your workflow, maybe we can resolve the elevation issues. However, as mentioned by @wizprod, RTK2Go is an “open-source” NTRIP “provider”, so reliability and consistency could be an issue.
Which option do I process it through on Emlid Studio? I have a RINEX file for the same time period from an OSGB CORS station that was less than a mile away.
You are right about the Stop and Go and the needed files for post-processing.
That processes and shows me a ground track for the time I was measuring the GCP’s. But when I try to process the Project export CSV with FIX, Float or Single checked, Emlid Studio simply sits there saying “Preparing” and doesn’t proceed to give me any output - cancel doesn’t work & I have to force quit the program
I can look at the data to see what’s going on. Since this contains private and sensitive information, you can send it to us via email at support@emlid.com, and I’d be glad to give you a walk-through of the whole post-processing workflow afterward.
Forgive me if I’m asking daft or simple questions - I’m new to the whole GNSS/NTRIP processing and I’ve been trying to get up to speed & absorbing a lot of info which is leaving me with my head spinning!
No worries at all. Everyone was a beginner once. We’re always glad to help, so please don’t think every question is daft or simple.
I’m doing some further testing to try and get my head around what is going on, and how to isolate the root of the error. I did measure three points in my back garden using the RS3 in a variety of project CRS to try and eliminate project setup as the source. I found that for 3 measured points within a 3m radius of each other, the elevation of the lowest point was always reported as being higher than the other two every time the NTRIP service was connected. The points recorded in SINGLE where consistent with the height I expected from that recorded for the take-off point elevation in UAV logs at that spot over several years.
I’m going to set up the RS3 on a single point and get an averaged fix (~1hr) for the location, then take a reading with the NTRIP service (without moving the RS3) and see what happens to the elevation once it’s connected. I think I’ll find the elevation increases, which means that either the NTRIP service isn’t in ETRS89, or its own height is set incorrectly.
I really appreciate your feedback and a walkthrough of the PP workflow would be brilliant. I’ll send you an e-mail when I’ve had a chance to get some more readings in a more structured manner That’s probably going to be after the Easter Weekend now though - hope you have a Happy Easter!
I’ve sent an email message to support marked for your attention. I’ve included details of a dropbox folder with the files. Any help would be appreciated.
FWIW, I’ve done some more testing and the NTRIP caster that I used seems to have been the cause of the offset in height as I’ve been able to repeat the issue whenever I use the NTRIP service. The height data in my testing is in the correct range if a different (but more distant) NTRIP is used, or if no NTRIP is used at all.
I want to mention that Nick and I are communicating via email. We found out that the base from RTK2Go seems to be why the elevation differs from the known points.
If anyone has questions or encounters the same issue, please feel free to create a new thread in the forum or email us at support@emlid.com. Thank you!
That’s probably going to be after the Easter Weekend now though - hope you have a Happy Easter!