What is the datum of the readings read and export from the RS2 in the ReachView app - EPSG 4326 or CSRS Epoch 2017.50? Am using base correction from an NTRIP service (the California Realtime Network, http://sopac-csrc.ucsd.edu/index.php/crtn/, where the RTCM streams contain CSRS Epoch 2017.50 (NAD83) coordinates and station metadata (antenna and receiver models, antenna height and reference point).) During surveys, in Project Info, Projection is 4326. Need to know which one as input to GeoCue’s ASPSuite image geo-tagging utility.
Emlid Reach products use WGS84.
Are you saying that even though the base correction is CSRS Epoch 2017.50 (NAD83), the reading of the GNSS receiver location in ReachView, and the files that are exported, are in 4326 (WGS 84)?
Where are you seeing the Epoch as corrections? CSRS Epoch 2017.50 is specific to California and I believe it uses a GEOID model. Reachview uses the WGS84 ellipsoid.
From Base Corrections screen. Correction Input > NTRIP from http://sopac-csrc.ucsd.edu/index.php/crtn/, where the RTCM streams contain CSRS Epoch 2017.50 (NAD83) coordinates.
Okay, that’s a completely different animal. You’re not using an Emlid for corrections, you are using service. Somebody else will have to answer that as I never use a service.
Neither have I; fist time using all of this. 
OK, thanks!
Was just thinking… Are you getting those corrections to your base or directly to the rover? If the rover then I don’t know, but if to the base then I think all it is doing is giving your base a corrected coordinate and your Reach base is providing RTK corrections in WGS84 to the rover. Maybe that’s the difference.
Hmm, I couldn’t answer that. This is the reason for this post… Used a Loki PPK antenna/controller on a drone. Data from the Emlid (RS2 location, .obs, & .nav) are input to their ASPSuite app to geotag the images for subsequent creation of point cloud & ortho in Pix4D. What I am trying to troubleshoot is why the target centers shown in the resulting ortho & the RS2 measured checkpoints are not lining up in the GeoCue LP360 control report utility. The orange dot in these images are the point readings (average of 20 fix readings) from the RS2, yet they do not align with then target centers. Ideas as to why?
Does this sound right?
- GCP’s from network corrected RS2.
- Images geotagged via PPK solution from corrected RS2 logs and the uncorrected Loki logs.
- You picked the green mark.
- The program assumed the orange mark.
If that’s the case then honestly the proximity of the orange mark to the actual target is pretty good if they are not using any locating AI. If you had not PPK’d your getoags you could have been 10ft+ off. That’s why we have to tag the GCP’s.
Yes, process that sounds right. The results are poor though. X RMSE = .124 m (s.b. ~ .02 m); Y RMSE = .034 m (OK); Z RMSE = 1.27 m (way off; s.b. ~ 3x of XY~ .09). GeoCue says there’s a bias somewhere, but we haven’t yet figured out where the errors are. Reference the attached LP 360 Control Report. PPK Test 2 LP 360 Report GCPs used in Pix4D.pdf (22.0 KB)
If the reference station coordinates are in NAD83, you must transform them to WGS84 !!! NAD83 uses the GRS80 reference ellipsoid and the ellipsoid parameters differ from the WGS84
How? Given ReachView > Correction Input > NTRIP (the CSRS Epoch 2017.50(NAD83)) , with ReachView > Survey Projection = EPSG:4326.
Where in the ReachView app does one configure the conversion? ReachView > Correction Input > Base Correction On > NTRIP URL, port, mount point does not offer any way to do a conversion while the receiver is capturing satellite data.
rechview does not do this type of transformation, I recommend that you look for a cors that is referred to wgs84 or use SurvCe or Fieldgenius to do the transformation.
I use this NTRIP as the CSRS is the official geodetic datum in California, as published by the California Spatial Reference Center (CSRC) according to the Public Resources Code (PRC) Sections 8850-8861. It is rigorously aligned to the current definition of the National Spatial Reference System (NSRS) through a set of coordinate transformations from ITRF2014 to NAD83(2011), published by the NOAA/NOS National Geodetic Survey (NGS). Additionally, the one paid service in my region with a CORS is based on NAD83. Does not seem to be any options.
If this all is really the case then I am surprised that the errors are so small and consistent. I’m still not 100% sure on exactly how your setup was configured. Do you have one or two RS2’s?
Either way you could try doing your PPK with one of the stations available on the NOAA site. They publish all the history so that you can go back and do it again without having to refly.
NAD83 is not a geocentric system while WGS84 is. The difference between one system and another for the 1987 epoc is 0.01m and for the 2017 season the displacement is greater than two meters. I would put a local base on wgs84 to do their jobs and refer to NAD83 and then all processed points are converted to NAD83. I have a language barrier problem to explain better, sorry
3 Likes
your results are shaped by your control so your output is in CSRS Epoch 2017.50 (NAD83) when you use the CRN via NTRIP.
1 Like