How to Adjust a Base Station to a common Reference Frame so the RTCM messages (MT1005 and 1006) use the correct location. See also this article on the Translation of ECEF in a small network.
This is an advanced topic and presumes that terms like datum and frame of reference are known to the reader to some degree. Some interesting material are found at the bottom of the page for further reading. Articles on how to convert between LLH and ECEF coordinate systems can be found here.
What is the need?
Often SNIP networks are made up of GNSS Base Stations are operated by other parties in some form of loose federation. Each party will have selected a different ECEF location based on the datum that suited their needs. Some ECEF positions will also be set to roll up the current accumulated ground velocities at defined points in time, but most do not. [Because the local user all share that common velocity] Various misunderstandings regarding which datum was used causes errors in the expected results.
At other times, errors and mistake can occur in the ECEF value programmed into the GNSS devices that then appears in the RTCM 1005 or 1006 messages. [For several years the popular “AZUSA” Base Station we often use here was known to be off by about ~8 centimeters in the reported location] At still other times, a station may be reconfigured to accumulate data during a power up time and thereafter use the resulting average as its ECEF position. This practice has value when the Base Station is semi-mobile, but generally results in increased error when used for long term stationary locations.
If you are aware of the coordinate used and the transformations required, this may not be an major issue to you (“fix it in post” as they say). If you are working at the meter or decimeter level of accuracy, this may not be an issue for you. If you are working in a seismically stable location (read: not Southern California), this may not be an issue for you. And you may not be using a NEAR mountPt system, where switching between two Base Stations each with different coordinate realizations, can cause unexpected and unwanted jumps in rover positions in the middle of a planting row.
But even if some of the above does not apply to any of your use cases, you will still want to assure yourself that the network you are using is aligned to a common set of values. If you have a choice in this matter, we would recommend that you use the current IGS08 reference fame (which can be considered “the same” as the current WGS84, but only to a fraction of a centimeter).
What to check for
With RTKLIB:
This is best done by comparing all the Base Stations in the network in set-wise pairs to confirm in each case that Station A (acting as a rover), when using Corrections from Station B, converges (in a fixed RTK mode) to overly the point that Station A sends in its RTCM 1005/1006 message. This can be done quickly using various 3rd party RTK filtering tools such as RTKLIB. If any two streams cannot produce solutions, using each other as the Base, that overlap each other, you have a problem to correct.
When using this method, it is vital to understand the details of the reference frame that the Base Station (Station B here) is using, as the rover position (Station A) will be expressed relative this this point. As will be shown in the example, if you move the location of Station B, all the devices that depend on it move proportionally as well. This is the essence of the RTK double difference method. A “silly” example of this can found here.
With OPUS:
Comparisons can also be done with decimated long term observations submitted to tools like OPUS and using final orbital data. The normal process is to gather several hours of data (enable logging on the stream of interest in SNIP), convert the raw RTCM3.x data to a RINEX document, decimating the observations to every 10~30 seconds for a period of at least four hours. Submit the resulting file to OPUS and await a return email with the results. Some alternatives to OPUS can be found here (thanks to Eric Gakstatter for developing this list).
Today, OPUS will provide values in both an NAD_83 reference frame and an IGS08 one.
A typical output (an excerpt) looks like this:
REF FRAME: NAD_83(2011)(EPOCH:2010.0000) IGS08 (EPOCH:2018.1055)
X: -2472978.774(m) 0.007(m) -2472979.762(m) 0.007(m)
Y: -4671339.285(m) 0.003(m) -4671337.777(m) 0.003(m)
Z: 3558107.904(m) 0.014(m) 3558107.924(m) 0.014(m)
LAT: 34 7 33.65447 0.012(m) 34 7 33.67085 0.012(m)
E LON: 242 6 12.69382 0.007(m) 242 6 12.63218 0.007(m)
W LON: 117 53 47.30618 0.007(m) 117 53 47.36782 0.007(m)
EL HGT: 145.492(m) 0.007(m) 144.783(m) 0.007(m)
ORTHO HGT: 179.126(m) 0.012(m) [ H = h-N (N = GEOID12B HGT)]
The above data is for the ASZU data steam. You can what each stream is sending by looking at SNIP‘s RTCM message viewer or by watching the stream during the startup phase. At about 180 seconds after any stream has connected, you will see lines like these:
[AZU1_RTCM3]: Station location loaded from ECEF msg:
In ECEF X:-2472979.4215, Y:-4671338.1096, Z:3558107.8057 Antenna Offset Height: 0.0000m
In DD.ddd Lat: +34.12601811°, Long: -117.89648611°, Height: 144.828m, Antenna Offset Height: 0.0000m
In DMS.ss Lat: +34° 07' 33.66521'', Long: -117° 53' 47.34999'', Height: 144.828m, Antenna Offset Height: 0.0000m
Use whichever system of units which you prefer and compare them with your source of truth. In this case we are setting up a Base Station for long term use and will rely on the OPUS IGS08 values.
What Do We See…
A small bit of math will reveal that there are some differences between the two values (what AZUS is sending and what OPUS states is the current IGS08 value set). Taken as a vector, the RTCM reported position varies from the OPUS position by 49.05cm (the NAD-83 one varies by 1.3455cm, and is of course dominated by the 1+ meter divergence of NAD83 from WGS84 over time). A failure to understand this could result in an incorrect position by nearly half a meter!
There are many different valid reference frames and realizations that a Base Station may care to use, any one of which could explain this. Left for the interested reader is the task to look up the realization which UNAVCO who operates this station has used. [See http://pboweb.unavco.org/shared/scripts/stations/?checkkey=AZU1]
For this task we do not care about the reasoning that went into the selection of another reference frame. Our goal here is simply to align them to the reference frame that we desire. This involves moving X by -34.05cm, Y by +33.26cm and Z by 11.83cm. Observe that the RTCM message provides for a precision of 0.1 mm in this regard. In places where a user can enter this data for SNIP a 10x level of additional precision is provided to mitigate rounding.
How do we fix it?
This is discussed further in a “worked” small network example where 5 stations from three different providers are translated and offset to a common IGS08 reference fame using SNIP’s PFAT system.
We use one of the provided translation dialogs to shift the ECEF value to align with IGS08 as shown in the image below. Because in this case we know the XYZ value we desire, we can enter them directly. [Aside: If we know the LLH value, or the offset vector that is wanted, the same point can be entered in those ways. As any of the values is edited, the resulting values in the other boxes are updated. Large shifts are noted and the user is asked to confirm]
Here we simply copy and paste the XYZ values from the OPUS report into the SNIP‘s Translate ECEF dialog box as show below (click to enlarge). Observe that the Height (which is computed from the XYZ values display a bit more precision that the above report displayed. This, and other values, are rounded when sent to the 0.1 mm precision defined by the RTCM 3.x messages.
Once entered and enabled by saving the new values, SNIP will send these values every time the Base Station sends its older value in another reference fame. The translation is then activated every time this stream is run, created permanent solution (unless disabled using the PFAT controls).
This process is expanded on on further in this article (link tbd). The controls found in the ECEF Translation dialog are explain further in this dialog (link tbd).
Before and After
The console display can also used confirm the changes.
Before:
[AZU1_RTCM3]: Station location loaded from ECEF msg:
In ECEF X:-2472979.4215, Y:-4671338.1096, Z:3558107.8057 Antenna Offset Height: 0.0000m
In DD.ddd Lat: +34.12601811°, Long: -117.89648611°, Height: 144.828m, Antenna Offset Height: 0.0000m
In DMS.ss Lat: +34° 07' 33.66521'', Long: -117° 53' 47.34999'', Height: 144.828m, Antenna Offset Height: 0.0000m
After:
[AZU1_RTCM3]: Station location loaded from ECEF msg:
In ECEF X:-2472979.7620, Y:-4671337.7770, Z:3558107.9240 Antenna Offset Height: 0.0000m
In DD.ddd Lat: +34.12601968°, Long: -117.89649106°, Height: 144.783m, Antenna Offset Height: 0.0000m
In DMS.ss Lat: +34° 07' 33.67084'', Long: -117° 53' 47.36781'', Height: 144.783m, Antenna Offset Height: 0.0000m
Note: PFAT Translation of the ECEC value is a feature only available on paid models of SNIP.
More Information on Coordinates and Reference Frames
This is a rather complex subject but here are few links to educate further.
http://clynchg3c.com/Technote/maps/Datumintr.pdf
http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf
ftp://igscb.igs.org/pub/resource/pubs/IGS08_The_IGS_Realization_of_ITRF2008.pdf
https://www.ngs.noaa.gov/CORS/coords.shtml
http://www.unoosa.org/pdf/icg/2012/5_3.pdf
https://www.e-education.psu.edu/geog862/node/1804
http://www.nrcan.gc.ca/earth-sciences/geomatics/geodetic-reference-systems/9052