UNAVCO NTRIP epoch alignment problem

Reach Module / M+ / M2 RTK / PPK configuration
1

Hi all, i am in California and i have been testing my Reach RS+ with the UNAVCO NTRIP casters

I have a number of sites where i have created a monument and used a NGS NOAA OPUS receiver to come up with a highly accurate location from the CORS network (i can give more details if needed). so my control points are fresh and within 2cm repeatable. I then bring out one of my Reach units and connect to the nearest UNAVCO caster (CORS station) and wait till i get a fix (which seems to take about 30 min or more). i have tested this on three different sites where i have monuments, the sites are spread out over about 170km. at two of the sites i am around 15km from a CORS station but at one site i am around 4.5km from the nearest CORS station.

here is my problem; all of my readings are off by almost exactly 30cm and off in a very uniform direction from the monument. i have run tests on multiple days on one site and found the offset is fairly uniform. in other words mondays readings were 30cm off to the northeast from the monument location (using the stake out function) and fridays readings were within 1 cm of mondays readings.

i contacted UNAVCO and described my situation and here is the response…

"Our epochs are typically not aligned with any specific epoch. We are slowly moving towards changing this to accommodate surveyors as funding and resources allow. You will have to make the epoch alignments on your end (emphasis added). We do publish positions and velocities for every site so a position at any epoch can be determined. "

I have to say there is allot i know but this area of epochs is outside what i know currently. is there some way to do this at the rover end? i can always shift my rover readings after the fact in qgis to register it all with my control point but i would of course love it to all be correct in the field so i can use the stake out function.

2

I am in California as well. The CORS stations are sending coordinates in NAD83 when your Reach is expecting it in WGS84. The uniform 30cm shift is the difference in the two datums from their points of origin. Currently, there is no way to go around this in the Reachview app as WGS84 is only option available. I asked UNAVCO when NTRIP will be sent in ITRF08 (WGS84) but have not heard back. NAD83 should be becoming obsolete. See this little writeup among others: Saying Goodbye: The Vanishing Reality of NAD83 and NAVD88 - Woolpert

You could also ask Emlid about incorporating other datums into Reachview but…

To mitigate this issue you must do so by post-processing either in GIS if RTK in field with simple transformation of coordinates or in RTKPost (other softwares too) for PPK. I ask what are your requirements of the survey as I too thought NTRIP would be nice in California. However, I found having two reaches (base and rover) to be best solution for me in this corner of globe. A typical survey day would entail setting up base station and log in to nearest CORS site knowing I will be introducing a shift to my base station coordinate. I would then run the survey as normal in RTK. I export my survey data when done and apply a uniform shift to all my surveyed points after correcting my base station through PPK.

In the end I ultimately gave up on utilizing NTRIP in California with my Emlids. Not to say it doesn’t have its utility but PPK both rover and base has served me far better with less potential for error. Hope this helps.

1 Like
3

thanks for your reply your confirming much of what i was beginning to suspect.

total bummer, i had high hopes for a seamless solution. I have a base and a rover pair and have been using them with OPUS for control but that takes a day extra of work per site. i was hopeing for a second option.

so yeah ill have to post shift like you describe. im still a little unclear on whats exactly going on here. they are not outputting in nad83 2011, its just not that far off, i was about to try some shifts with htdp as it looks like its igs08 but in 2005. i guess i need to find out if UNAVCO or NGS has a master list of what the positions are with epoch and velocity for all the California stations. i could then python+HTDP a solution to do it less painlessly.

4

so i guess if i had access to software like field genius or the like then i could enter a X,Y,Z shift to be applied to the corrections on the fly? is that how the cool kids do it? and if so then why isnt that just included in the RTCM message? am i missing a nuance or is this a solvable problem either at the collector software end or at the signal end?

5

Well depends on how you look at it. I was initially bummed when I came to this conclusion but after familiarizing myself with PPK it has been smooth as silk for me. Just depends on your surveying needs. PPK can be cumbersome with lots of points but developments are emerging to aide in this. Lots of control.

I cant upload an excel file but here is link to what you are looking for station access and owner in CA.
http://sopac-csrc.ucsd.edu/wp-content/uploads/2018/06/CRTN_Access.xlsx

And yes you are correct, there are other softwares out there with some more brain power than reachview currently that will achieve what looking for.

6

Thanks for all the great information! RTK_hunter, would you mind going into a bit more detail of your workflow for PPK?

8

Nevermind, just found the Ground Datum thread!

9

I think there needs to be a little more conceptual/fundamental explanation going on here… and please feel free to correct me here if I am wrong. This is all based on the fact that the world is changing shape daily, and tectonic plates move. Coordinates of a point are only good for the moment that they were surveyed (the EPOCH of the solution)

#1 - WGS84 effectively treats the center of mass of the earth as the center. That means each and every point on the earth surface moves a little bit every day. Not much, but nonetheless moving. This movement is significant. It is also common to reference WGS84 at the current time (EPOCH).

#2 - NAD83(2011) tries to reduce this movement of coordinates by using/fixing itself to the North American Tectonic Plate, and referencing the 2010.00 epoch. It still technically moves every year, but less. Because the coordinates all reference the 2010 epoch, a survey next year should find the same location, unless the ground is moving significantly (like near the coast of CA). HTDP - Horizontal Time-Dependent Positioning

NAD83(2011) is so common because most of North America moves < a few mm each year relative to it. It’s easier to assign a NAD83 coordinate to base stations and benchmarks. The alternative is constantly updating a WGS84 coordinate to the location of those references.

RTK uses relative positioning, so adjusting a base station reference coordinate will also adjust the rover coordinates, usually 1:1. When we say base stations are sending coordinates in one frame or another, we really just mean that the base station reference positions are in one coordinate or another. In some software, you have the choice to override those base station coordinates. Your NTRIP network and mine hopefully both give those coordinates in NAD83(2011) Epoch 2010.00.

We have 2 options.

#1. Work in NAD 83(2011) Epoch 2010.00 (because you can’t change the base station positions to WGS84 through reachview). Most surveyors are doing this. Your outputs on the screen will be NAD83 (even though the app thinks everything is WGS84).

#2. Post-process everything in WGS84 at the current time. You’ll need to do a lot of transformations (base stations, benchmarks, etc.) to get this to work, and WGS84 coordinates aren’t that useful today because they’ll be physically moved tomorrow.

I recommend option 1, because most networks and SPCS (state plane coordinate systems) here reference the NAD83 (2011) coordinate system anyway. Also check your OPUS solutions as they give you BOTH (NAD83 AND IGS08(a form of WGS84)). On a final note, check the published positions of those base stations. Parts of CA are moving by more than 4cm per year according to HTDP - Horizontal Time-Dependent Positioning, and that’s in reference to NAD83 (doesn’t move much in most of North America)! OPUS may be using a different and better base station position estimates than your NTRIP network.

NGS Coordinate Conversion and Transformation Tool (NCAT) is a very useful tool for going between XYZ and LLH, and HTDP computations will help you do WGS84 to NAD_83 type time-dependent conversions.

10

wow yeah you got it, except about OPUS, its the same network CORS.

i think if nad83 2011 as the common meet up point. if a monument doesnt have it then i have to use HTDP to find out where the monument would be in nad83 2011 space. its like in economics putting everything in a common currency and year (1984 USD$)

as far as i can tell if you are in an area where there isnt much movement like the midwest then its not worth it to fret about. but along the west coast i can find areas within an hour of my office that move at over 4 cm and then inland an hour they move at only 1cm.

now if someone just wants a reach unit to give them more consistency and or relative accuracy then i also wouldnt fret. i am bummed that the ntrip with unavco solution is off by 30cm…well does it matter? it still beats the heck out of WAAS or averaging a point.

regarding the options you layed out…

#1 yeah i am not sure about this, if i get what your saying. in my case currently i : OPUS -> take the wgs84 (G1762) = iGS08(current epoch) -> enter that into the base station -> what i will see then in the rover is IGS08 corrected. your suggesting that i instead take the NAD83 2011 value. i tried this before and it works but it seems wrong somehow since the UBLOX receiver is telling you your somewhere else. like in my case thats 1.5M in a westerly direction and 50cm ellipsoid difference. ill have to look into this more, i want it to be true!

#2 yeah thats what i do, capture in wgs84 (G1762) = iGS08(current epoch) and then store it in nad83 2011 where apples are apples, from there its a cross walk to state plane. i am mapping as-built mostly so this works for me.

it seems more and more to me that what would be great would be a X,Y,Z shift value that you could enter in the reachview app so that the coordinates being spit out are dynamically shifted, you could easily then change it in the field at the rover end. …this is fun, thanks for the helpful communication all this everyone!

11

If you are using NTRIP to the CORS stations (that likely are sending you their reference positions in NAD_83, then you are using 2 datums IGS08 and NAD83 (BAD). If your NTRIP network is broadcasting base station locations in NAD_83, your reference points need to be in NAD_83 as well. RTKLIB doens’t do conversions on the fly. It only does relative positioning (to a base station at the coordinates that the network broadcasts).

You should be taking the NAD_83 coordinates from the OPUS solution to compare accuracy to a NAD_83 network. You said it yourself that you tried it before and it works, but EMLID doesn’t allow you to select NAD_83 in and out, even though it’s effectively a global shift XYZ of WGS84 at a given time. TECHNICALLY it’s more than a global shift in XYZ, but for practical purposes, I think it’s the same. If it wasn’t, then base stations would be constantly updating their WGS84 position broadcast.

12

No what i am getting from UNAVCO over NTRIP is not nad_83 2011 otherwise i would see it close to those values. i extract both IGS08 and NAD83 2011 from OPUS reports to a shapefile and i am 1.5M from them with NTRIP-UNAVCO while i am 30cm in a easterly direction from the IGS08 value in the current epoch. so likely the corrections i am getting are for something with a location value from 10 years ago but still in the WGS84 datum so to speak. ill poke it with a stick today and see if i can find out more.

13

I thought UNAVCO broadcast in both IGS08 and NAM08. Of those, I thought IGS08 closely resemebled WGS84 (as stated in the table here ITRF2014, WGS84 and NAD83 | GEOG 862: GPS and GNSS for Geospatial Professionals). So getting corrections from that NTRIP station to Reach should not require any transformations. Correct? Looking at Station CBHS ( Calabasas) I see this in the header of the IGS08 data.
NEU Reference position : 34.1385612557 241.3701949895 284.61554 (IGS08/WGS84)

14

Yeah when it comes to your specific network, I cannot comment on what is being used. You’ll need to check your RINEX files or verify some other way.

For what it’s worth, our state network was just adjusted this last month for the first time since 2013 and the average station change was about 2.5 and 1cm in the horizontal/vertical directions in the NAD_83(2011) Epoch 2010.00 coordinate system. It’s not much. 30cm is a lot though.

15

here is what i think, correct me if i am wrong…

they broadcast in IGS08 based on the surveyed location for each CORS station and each of those CORS station locations has a different “born on date” which we call the locations epoch. i just got a message back from UNAVCO and here is what i think i have been looking for…

"UNAVCO does provide a master list of velocities with reference positions and epochs for all sites, which you can download from our ftp site here:
ftp://data-out.unavco.org/pub/products/velocity/pbo.snaps_igs08.vel

A few notes about this file that may be useful:
-It uses ITRF2008 (IGS08) as the reference frame, so you’ll have to convert things to nad83 (2011) if that’s what you use.
-When there are multiple entries for the same site, it means the site has been offset by some event, like an earthquake. The velocity is the same for each site entry, as the velocity is the best estimate based on the full time series and accounting for offsets.
-This really is the master list and includes many stations outside of California."

so i need to shift my NTRIP UNAVCO REACH readings based on the values for the station i used.

1 Like
16

which station are you using?

17

Your Rinex file of the base log will not give you the information of the NTRIP data it is sending to the caster. In California, under the California Real-Time Network (CRTN), NTRIP is in NAD83. If you download that spreadsheet I put in previous post, you will also see all stations in California send NTRIP as NAD83 coordinate.

http://sopac-old.ucsd.edu/crtnDescription.shtml

18

i was using p261 and i was 4.5km away or there abouts.

19

ah, so theyre not broadcasting in IGS08 that is just what the NEU points use for reference frame?

20

This is my current understanding for CRTN. And specifically, the epoch is 2017.50.

image
image.png1044Ă—737 177 KB

21

At this point i am going with what UNAVCO told me, which makes sense given what i just tested in HTDP. when i connect through them i am getting corrections based on igs08 in the epoch of the station.

ill check out SOPAC CRTN again i had thought they were only providing corrections to l1/l2 receivers, but clearly your using so it must work. i also had the understanding that they were not covering the PBO stations (which is what it says in the spreadsheet) but maybe that has changed, i need p261, and those in this group
http://gaia.unavco.org/streamStatus/CurrentSet/BayAreaNorth_20180625_30day.html

1 Like