Ok, I did some more digging. Are you accessing this site separate from the CRTN? I forgot I have two real-time accounts one for CRTN and the other UNAVCO. They share some stations but not all and are quasi-related. i was speaking on behalf of my experience with the CRTN which utilizes UNAVCO PBO sites.
I pulled your coordinate file for P261 as well as its velocity. And ran through HTDP. EPOCH is 2005. Lets assume 14 years from then. I see an eastward velocity of -0.0249m/yr and a northward of 0.0033m/yr. Multiply this by 14 years and you are very close to your 30cm, I get 35cm eastward and only 4cm northwardsā¦ ftp://www.ngs.noaa.gov/cors/coord/coord_08/p261_08.coord.txt
If this is the case I stand corrected mostly because of my experience with the CRTN in NAD83. If UNAVCO broadcasts in IGS08 this is great for us Emlid users we would just have to be cognitive of the Epoch. Some more info on how you created your monument might shed some more light.
yes i am accessing unavco at rtgpsout.unavco.org
The port: 2101 (Raw) and 2110 (Processed)
and as i said in the first email UNAVCO said " 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. "
so yeah its confuselateing like you just pointed out the the data sheet says 2005 but the list they sent me (linked above) has down 20110715120000 (Format is YYYYMMDDhhmmss) for p261 and it is different for each station.
you wanted some more info on how i did the monument, ill just copy and paste in this description from an email i sent to a coworker on a different project, same same but with rebar.
I use a IG3s (which i highly recommend) + seco 5119 to create OPUS solutions. i use a LaserTechnology Trupoint 300 (which i do not recommend) to measure accurate point to point horizontal distance. lets just say its sub centimeter accurate. I have the Reach units with tripods and 8 minute calibrated bubbles. all of my equipment is calibrated on the same chrisnik wall jig. in this case 8 min bubbles were always used though in general i use a 40min for most things.
software i use includes QGIS, OPUS, HTDP, Python: (GDAl, pyproj, PyGeodesy, etc.), and the NGS online tools.
I started by creating two monuments about 80 meters apart. one is a very solid piece of pipe hammered in about two feet and the other is a mark on a cement pad. the location over all has some moderate reception occlusion, some trees, and a bit of topography to the east.
i used the IG3s to log 4 hour observations on each monument and then (days later) i picked the best results based on the metrics in the OPUS reports. while the IG3s is running i used the trupoint 300 (attached to a tripod with a 8min bubble) to shoot 5 shots which i averaged and then adjusted to the ellipsoid distance by calculating the elevation factor. the 5 shots were all within mm of each other. I then compared this distance to the ellipsoidal distance from the two OPUS points using NGS Inverse and found them to be 1.38cm apart. in my case, all things considered, i think this is about the best i can achieve given the inputs and conditions.
YUCK! That makes everything a LOT more work, and it sounds like itās site-dependent! Also doesnāt appear network-friendly. I donāt envy your moving land in CA. Here in Iowa itās relatively peaceful.
I never have been clear on the two ports and their NTRIP configs, perhaps this can create differences. Have you tried taking the same point from the two different feeds?
What is the Epoch utilized for the OPUS solutions?
So for stakeout to work with NTRIP connection you would have to adjust your point to the Epoch of the reference station you are planning to utilize? Have you PPKād these points and compared to NTRIP coordinates?
i cant check it now but 2101 had RTCM2 and RTCM3, one of them had binex and one of them had rtx, ill see if i can get a chance soon to look at it again where i am. reach will only work with the RTCM3 correct?
well mystery solvedā¦ sort of. UNAVCO reset some of the stations to help me figure this out (yeah i did not see that coming).
from UNAVCO staff email:
āI have reset the 1005 message positions in the RTCM3 stream for P202, P261 and P264. They are now set to the IGS08 position as of 19 Jan 2019 12:00:00. Now that you know exactly what the RTCM3 positions are referring too maybe this will help resolve the discrepancy.āā¦"Iām guessing that your system is using the 1005 message in the RTCM3 stream. We do update those periodically but when I updated the coordinates for those sites yesterday I used what we refer to as the āfinalā positions from UNAVCO processing which are considered best-of-the-best solutions at a given epoch. What we are probably going to do moving forward is update all our 1005 coordinates once per year to the position on the 1st of January of that year. "
so i went to one of my OPUS monuments, set up the reach unit, leveled with the 8min bubble and started up a hotspot on my phone, and started up the reach unit. i connected to p200-rtcm3 (which they did not reset yet) which is around 13km from the monument. after getting a fix, stakeout showed my solution as almost 0.5 meters off (ublox 7p can do better than that with WAAS). i then reset everything, rebooted and connected to p261_rtcm3 which is about 14km from the monument. after getting a fix stake out showed me as .046cm from the monument, not bad given the factors.
my hope had been to be able to individually adjust (python) my points after the fact based on the epoch of the base station coordinates but that just did not work as there was clearly a shift that would not be solved that way. that was when i emailed them again and they did the reset described above. so in my case, just to play it safe, i will always control to a OPUS point if i am going to use this service and need better than .5 meter network accuracy. i will RTK my OPUS point and then shift everything after the fact in QGIS.
