OK. I’ve read the forums, but feel like I am missing something stupid.
Recently obtained a single Reach R3. No issues with RTK, using an NTRIP I can get great results compared against benchmarks. I have used a Trimble R10 for many years in RTK mode with no issues.
The main goal of this instrument will be to collect PPK in areas with limited/no cell coverage using the R3 as a receiver and use CORS stations to survey ground control points for UAV surveys. We typically have to hike our gear in so the compact R3 is great for this (in theory)
I have tried a bunch of times over the last few days; I have logged for an hour, and then downloaded CORS data from different nearby stations, and brought it all into Stop and Go (I even tried converting the CORS data to RINEX v. 3 instead of the default v. 2). I also tried a VRS deom my KeyNet subscription. No matter what, I can’t do better than getting float or single, however even then I can’t get the points in my CSV File to work. What am I missing???
Files are attached here: This includes my RAW RINEX Files (I think, new to Emlid) and the closest cors stations; the time and sampling rate doesn’t seem to change the results I have tried UTC and UTC-4, As is, 1 second sampling etc. I get around 0.1% fix. The odd thing is I had corrections for the first few minutes (via NTRIP), then wanted to try PPK. All the same point. Even w/o corrections I still had ‘Single’ in the Emlid Flow App, but I get float when I process in stop and go. Project CSV File included as well.
Rover Logs show what appears to be sampling every 0.2s. (48.0s, 48.2s, 48.4s, etc.)
CORS Logs are sampled every 5s. (40s, 45s, 50s, etc.)
Based on this, the issue appears to be that no data in each log corresponds to the sample taken, so cannot be solved.
The reason for the 3 first points having a fix is likely due to having the solution at the time. NTRIP services usually provide corrections at higher sampling rate, like each second, logs are often stored at a lower rate (where I am, it is usually 30s).
You want to take observations for a longer duration and this will depend on the sky you have. Based on the PDOP, there must be some obstructions, so you are looking at least 60s per point perhaps. Especially if your CORS samples are so low, this would be 12 samples assuming they match.
Can you explain the thinking on this a little more? In my experience it doesn’t matter when the sampling occurred because the software is building a track and the rover is picking data from the track, not a single point in time. I’ve also never seen a CORS suitable for Surveying that broadcast last than 1Hz. Maybe I’m just confused by relating the signals to seconds instead of Hertz?
Regardless, here is what I got using my default config.
I second Michael’s comment here. We never had to worry about that. The only thing is to remember to have a few seconds of averaging for each point or else Emlid Studio won’t be able to work in Stop & Go.
As far as the track being mostly float, it could have to do with the CORS data updating too sparsely if it’s really 0.2Hz. I’ve never seen that myself.
Thanks Everyone
I just did a test in my driveway; the longer point setting/averaging I had missed. I recorded points averaging from 5 sec to 5 minutes. That at least allowed me to see the points in the CSV processed as ‘Single’, which is progress. I need to wait a bit as it looks like the CORS stations update ~hourly. I’ll respond back if I make any progress then.
Thanks everyone, it definitely is a case of log for a while before collecting points (I did 10 minutes in two tests, record individual points for a minute or more and then when processing be prepared to try more than one CORS Station. Ended up finding decent success comparing to RTK values. PPK worked using both CORS and a VRS provided by a commercially available service.
One annoyance is that even though my project was using GEOID18 to NAVD88, the processed elevations coming out of stop and go are all relative to the ellipsoid.
One thing to note is that from the 1st until about the 4th, space weather was garbage. That being said, it seems evident the main culprit was not enough averaging due the cors base logging at 5 sec versus 1s.
Hi everyone, it’s nice to see the discussion in this thread! Also, @oakley.bryan welcome to the community!
Regarding this, you can create a project in Emlid Flow using NAVD88(GEOID18) Height and import the CSV file resulting from the PPK. When you export back the CSV, the points will have the NAVD88(GEOID18) Height. You can also check our support tip regarding this in this link.
