I’m a new Emlid RS3 user. Did duplicate setup today with RS3 and Emlid Flow vs Trimble RS8 and Trimble Access data collector. Same rod/pole height measured to bottom of antenna mount (as both software define ht) - Same NTRIP login/mountpoint and CRTN base - Measured 7 common points, where X,Y coordinates compare to within 1cm however Z (elevations) are typically about 0.25-0.30 feet different (RS3 is lower). I assume someone has encountered this before. Any guidance.
Hi @gary.ifland,
Do you use US Survey feet as units of measure (not just Feet) in your Emlid Flow project? Please share your CSV with measurements and coordinates of points for comparison with me.
1 Like
Yes, US Survey Ft. Below are a sample subset of common points and measured elevations in US FT.
Trimble RS8: NTRIP - DAY 1
TA1 - 14.746
TA4 - 7.929
TA5 - 9.123
TA7 -24.341
Trimble RS8: OPUS (20 minute) - DAY 2
TA1 - 14.862
Trimble RS8 - NTRIP - DAY 2
TA1 - 14.797
TA4 - 8.069
TA7 - 24.396
NGS-BM - 24.25
Emlid RS3 - NTRIP - DAY 2
TA1 - 14.607
TA4 - 7.747
TA5 - 8.973
TA7 - 24.178
NGS BM - 24.013
My earlier post said Emlid Reach RS3 data was 0.25’-0.30’ lower, but that was incorrect. You can see here the range is roughly 0.14’ to 0.26’, but it does seem relatively consistent. I can just raise the RS3 data by 0.20 feet and get them all to match closer, I just don’t like that as a typical solution.
Read a few posts about ARP and how CRTN may be reporting monument height on NTRIP ch 1006. Both software (Trimble Access & Emlid Flow) ask for same rod/height. Trimble = bottom of anntena mount (which in my case is top of survey pole) and Emlid Flow ask for top of survey pole. I used exactly the same pole/height for all NTRIP surveys.
The Antenna Reference Point (bottom of mount) of the Trimble is
0.06490m
=0.212926509’
https://trimbletools.com/cgi-bin/Antenna.ini/display_antenna?antenna=R8+GNSS/SPS88x
Also, what height is in the NGS BM records?
Datasheet for NGS BM = 23.1
I’m aware of the ARP of 0.21’ but not sure where/how that is entered or accounted for in Access. Seems Trimble should have it working properly with CRTN broadcast. At least I always assumed that. I’m going to do another test in the next few days. Will post my findings if different.
Secondary Test on a local position results seem to confirm first.
NTRIP Service from CRTN using same exact profile (port address and and mountpoint) approximately 17km distant.
Coordinate System for NTRIP = CSRS Epoch 2017.50 (NAD83) -CA ZONE 3, COH
#1) Trimble R8s with Trimble Access (v2017.24 - latest) with initialization gained - FIXED vertical precision = 0.064’, VDOP = 1.8, Antenna Height = 6.062 measured to Bottom of Antenna mount + vertical offset of 0.213 = 6.275’ - COORDINATE SYSTEM SETTING - US SPC NAD83 (CA ZONE 3 0403) - GEOID 12B
#2) Emlid Reach RS3 using Emlid Flow (v9.7) with FIX
vertical precision = 0.047’ Antenna Pole = 6.062 measured to bottom of Antenna Mount. (True antenna Height = 6.502) - COORDINATE SYSTEM SETTING - US SPC NAD83(2011) (CA ZONE 3 0403) - GEOID 18
Both sets of data confirm accurate setup measurements.
#1) Z= 557.399
#2) Z= 557.168
Difference = 0.231, Again, the Emlid RS3 is lower. One interesting find is that the BASE is reported at 0.0m in Emlid Flow, Somewhere I read that the NTRIP RTCM 106 messaging broadcasts both the monument heights and the antenna height. Could that be an issue for how Emlid reads the base info and therefore ellipsoid HT?
I do realize that different datums and geoids can have effect, however I’ve done Geoid12/18 comparisons and they are 0.02’ in this location, I also realize that CRTN publishes COH ellipsoid and not NAVD88, but that is same for both NTRIP transmissions, so it should have no relative impact.
The only solution I can see it that the software system MUST handle the NTRIP data differently. Is it possible that the Trimble System is the one with the error?
Think the Trimble software is maybe already compensating for the 0.213’ Antenna Phase Center to Antenna Reference Point (BOTTOM of R8s)(APC-> ARP)???
What if you don’t factor in the 0.213’?
I’m not inputting that. It’s just how it shows in raw data.
I’d be thinking some amount of this might be the difference between Geoids, however I came across this Technical Detail from NOAA about Geoid18. It looks like, if you happen to have the wrong version of Geoid18, your height could have an error up to 6.25cm, which I think could get you most of the way there.
Maybe its worthwhile checking which version Emlid is using? I doubt its the answer, but it might be something.
I saw that too. Should be using the same geoid, but he seems fine with the 0.02’ difference? Why not use geoid18 (and same CS) for BOTH to rule that out?
I know its not ideal putting the receiver directly on the ground… but try putting both on the NGS BM to see what you get… compare to the record USING THE SAME CS and ortho height (geoid) for both. You know the APC for both to subtract from each of the readings.
Hi @gary.ifland,
Sorry that my reply took so long.
Do you know some benchmarks with known coordinates in your area? Could you please do one more test on it? This will help us eliminate the influence of a 3rd-party receiver on the investigation.
To conduct a test, please do the following:
- Provide Reach RS3 with a clear sky view. Configure receiving corrections from CRTN.
- Enable raw data debug option, and start logging. We will need raw data log in UBX, correction log in RTCM3, and position log in LLH
- Collect the benchmark with Reach RS3.
- Keep the logs recording for 10–15 minutes and stop logging.
- Download the logs, generate a full system report from the receiver, and send all the data (logs, CSV, and report) to us at support@emlid.com.
I’ll take a look at the files, process the data, and compare RTK and PPK results. I believe it’ll help us get a better understanding of where the mismatch comes from.
1 Like
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.