I’ve completed OPUS rapid static captures w an emlid RS2+ over several high order survey monuments in an effort to test the accuracy. The emlid - opus positions & elevations all end up approx 3 feet off the published monument data. Not the same amount for each capture, but approx 3 feet. The horizontal is always off to the south east of the monument. Can anyone suggest what could be causing this discrepancy; the emlid should produce data within several inches, or sub foot, for a rapid static capture, at least, certainly not 3’. I have the logging settings set to produce an OPUS RINEX file and my pole height is alway exactly 2 meters.
1 Like
It is likely a difference in datums from the OPUS solution and the established survey monument. Can you share your monument location file and OPUS solution to see?
5 Likes
Sounds like an NAD83/WGS84(ITRFxx) offset. Somewhere along the line you’ve got your datums mixed up.
As RTK_Hunter says, more info is needed.
2 Likes
Thanks Hunter for trying to advise me. I uploaded 3 screen captures below of the requested data reports; I don’t know how to insert screen captures into this reply. I’m standing by for direction to depict the screen captures another way The monument and the opus data are both WGS84 lat & long coords
From the monument datasheet, it’s not WGS84. Horizontal datum is nad83, 1994 realization, and vertical datum is NGVD29.
You’ll have to translate your OPUS results to these for them to match. I’m no expert on US datums, but there’s some info out there for sure:
For your vertical shift, read this. It’s not exactly local, but their value is over 3 feet. For your horizontal shift, I don’t really know if there should be a huge difference between nad83/94 and nad83(2011). Someone local could tell you in a second.
3 Likes
Hi @kenforestry,
Found the same info about the CS in the monument datasheet as Gabriel:
So, it indeed looks like the reason for the shift is that the horizontal and vertical datums don’t match. To transform the coordinates into the same datum, a GIS app or an online converter can help. As I see, the conversion between NAVD88 and NGVD29 is supported in the NOAA vertical datum converter.
3 Likes
Using NCAT (NGS conversion software) and making a guess at what would best fit NAD83(94) the coordinates do match sub-foot in 3 dimensions.
If you really want to test the accuracy a more modern control point would be better. If it is still there and usable the one below at least has NAD83(2011) coordinates.
6 Likes
Hmmm… What do you fill in here? Dependent on this it will solve for your location at the antenna reference point or on the ground which is what you want.
1 Like
Everyone, thank you so much for the conversion advice; I applied conversions to both the vertical & horizontal figures for the several emlid captures I did on 3 monuments and now accuracy varies from 4" to 7" for OPUS rapid static captures. Jbonde, thank you for that NGS data sheet. I did a 2 hr capture, with the emlid, on that very monument. I used the NDOT LOIS data sheets, along with the NGS data sheet. In fact there are 29 lois reports for that monument; most with diff figures. I spent hours today, after the forum advised me, determining the most accurate lois reports. This one below. After subtracting the 3.6’ NVD27 to NVD88 conversion, the emlid - OPUS elevation is off just 7" from the LOIS report. I’ll reply to the forum to report the average emlid vert and horiz error from the 6 captures over 3 monuments.
, a little less than the NGS report.
1 Like
Hi @kenforestry,
Thanks for sharing the results! Glad to know the conversion helped.
Just wanted to add that we usually recommend collecting data for OPUS for at least 4 hours and processing it in Static. It can help obtain even better accuracy.
1 Like
Nice - Is this what you are considering your 2m pole height and not the bottom of antenna to be sure? 65mm is about 2.5"…
yes, the 2 meters includes the 134 mm from the bottom of the antenna up. Total height to your point= 2m, including the 134mm. Everyone, for 7 rapid static captures, I get an average emlid-opus error of 5". As advised, I’ll try some 4 hour captures. thanks for advising me conversions; I use the NCAT conversion page
OPUS asks for the height to the Antenna Reference Point. In GNSS terminology, there are two different values that can be asked: ARP (antenna reference point, the bottom of the receiver in your case), and APC (antenna phase center). From what I understand you gave OPUS the APC so you’d need to subtract 134mm from your 2m just like @RTK_Hunter guessed (unless the pole under the receiver is indeed 2m to the ARP and something just got lost in translation).
5 Likes
thank you so much for that info; which makes sense since OPUS asks for the antenna type, which means it knows about that 134mm. There goes some of that 5" of error; I’ll resubmit the rinex files. However, when we submit rinex files to the Canadian CSRS PPP website, that site doesn’t ask for antenna type, so 2 meters is appropriate for that submission. We’ve found that a small no of emlid Rinex files, including a 2-hr capture, would not process thru opus. Thankfully, we were able to process the rinex thru CSRS and the accuracy, for our test, appear close to opus, even tho CSRS is 2500 miles distant. I’ll be providing training for my agency on the emlid, so I really appreciate the help I got from the forum.
Normally for NRCan PPP, the system reads the antenna information from the RINEX header so you do need to enter your ARP measurement. In Reachview 3, there should be a preset in the raw data logging settings to format the RINEX file so it can be ingested correctly by PPP. It will add antenna type in the header along with instrument height to the ARP.
1 Like
Gabriel, Thank you for that explanation; I’d not thought that CSRS might read the header files to determine the emlid’s ARP. I’m confident csrs is doing that after wondering why it doesn’t query me for an antenna height. I’ll just adjust our pole height to be 2 meters to the bottom of the emlid, which will allow us to submit rinex files to both opus & CSRS without making an adjustment. Both sites should add the 134mm to the calculations. I’ll reply back when I complete some 4-hr static captures to report the emlid accuracy. Ken
Yes, online services usually can read the antenna type field in the RINEX header, but some still require that as user input because, depending on the receiver manufacturer, the info is not even in the header, it is just a blank field. This is a way to ensure accordance between the user and the computing service regarding the antenna that was used.
2 Likes
I should add that I’ve had to subtract 2m from the ellipsoid height CSRS reports, so, apparently, it’s not reading the antenna height from the header, just the ARP. once I adjust the ellipsoid hgt I add the geoid 18 height for the gps site, using this site: https://geodesy.noaa.gov/GEOID/GEOID18/computation.html
to obtain the ortho elevation. I’ll do some 4-hr emlid static captures and report back the accuracy
Make sure your settings include what’s described here, namely that the use antenna height checkbox is enabled. If it is, the info should be present in the RINEX header. I use PPP all the time and it works flawlessly.