California CRTN Users-A few questions

Sorry, can't offer any help on the CRTN.

We've noticed movement in our Michigan monuments, and we're a long way from CA.

And the MI CORS RTN is using MYCS1 values instead of the published values on the NGS Datasheets (MYCS2).

May not make a huge difference, but it's just one more thing that adds to error/inconsistency. Add that in with HTDP since epoch 2010.00, and maybe there's some change in position?

Posted by: @shelby-h-griggs-pls

I don't often use the CRTN, BUT working on a couple California projects currently that I will use that RTN. The CRTN official spreadsheet shows coordinates to the monument (which is different than any other RTN I have ever used, but I am sure there must be a good reason). I would assume the broadcast positions are to the ARP since they are different, however either that isn't clear or I missed the memo.

When I look at the two values, in my mind the broadcast RTN stream actually seems to apply the difference between the monument and ARP in the opposite direction so all those 8.3mm SCIGN mounts appear to have a coordinate 16.6mm different than the published monument Hae.

Maybe I am looking at it all wrong? Can any experienced users of the system confirm that broadcast data stream is actually to the ARP?

Work in the Redlands, CA area also results in first order vertical marks measured with the RTN to be around 0.1 meters lower than NGS published. That may be true, but any thoughts on adjusting vertically to monuments there vs CRTN values + Geoid model would be appreciated.

Starting tomorrow, I will be in Lakeport, CA area and will see how vertical fits in this area, so may have questions again about that.

As a general rule most of my projects no longer get adjusted to local hard monuments as here on the entire west coast it seems there is too much movement both horizontally and vertically to trust even HARN/HPGN monuments any longer, let alone BM's from 50+ years ago.

SHG

Were you using GISA? Let me put you in contact with my colleague, Kevin M. Kelly. His email is @esri.com, firstname_lastname. Hopefully, he'll have some information for you. Please tell him I referred you!?ÿ

Melita

I don't know why an RTN would broadcast anything other than the ARP or APC, simply for compatibility's sake. Most field software can utilize the NGS absolute antenna calibration files.

We have a couple offices in CA that run on the CRTN regularly, I'll give them a shout tomorrow and see if they have any info to share.

@rover83 thanks, look forward to any info you can provide. I don't know why a RTN would publish coordinates to the mark either rather than ARP, but the CRTN does. I guess I can't complain too much, it is free, but the CRTN is by far the worst RTN I have ever tried to use. Stations down regularly, no network solution, most stations GPS only, oddball published coordinates, etc.. It has been a few years since I last tried to use it and I had forgotten about some of the issues. For California being one of the biggest states in the USA, they are way way behind on what a statewide RTN should be IMO.

SHG

@mkennedy Melita, thanks for the name. No I did not use that station. I will reach out to your colleague.

SHG

I don't trust the vertical of the station near me, UCD1.?ÿ I've never taken the time to analyze the situation, but it just never seems right.?ÿ I always use a passive mark for elevation whenever it's important.

Well, unfortunately I have struck out. Our local CA guru is out for the week. Too bad, I was down there running some training a couple weeks ago and could have picked his brain about it then.

I did talk to another one of our techs who also expressed frustration with CRTN, and he thought that the discrepancy could be due to broadcast positions being on 2017.50 epoch. But I'm not so sure, looking at their coordinate comparison spreadsheet. Doesn't look like much difference from 2010.00, although it varies across the state.

Only other thing I could think of is that the gear used could make a difference as well. I know that Trimble will generate a virtual base station or a vector to a physical base station depending on how the survey style is set up, and how the network operators have configured it. Any chance that this is on the equipment side?

Posted by: @rover83

I know that Trimble will generate a virtual base station or a vector to a physical base station depending on how the survey style is set up, and how the network operators have configured it.

I believe that CRTN is single-base only.?ÿ My (limited) understanding of VRS technology is that the rover has to transmit its location to the server, and I don't think CRTN has that capability.

Did you contact Dr. Bock and the CSRC/CRTN team?

Yehuda Bock <[email protected]>'

gregory.helmer <[email protected]>

Rich Maher <[email protected]>

@rover83 Thanks for the effort!

@jim-frame correct on single base, no network solutions.

@spmpls yes, I am in direct e-mail contact with Dr. Bock. Still scratching my head a bit, I think probably correct solutions, BUT still trying to figure out if the broadcast is to the ARP or the monument. I will likely have a few more e-mails back and forth, but on the correct path now.

SHG

After a few e-mails with Dr. Bock, and a bunch more sleuthing, it does appear that the CRTN is in fact broadcasting the monument heights rather than the ARP heights. They also broadcast the antenna height which on a SCGIN mount is 8.3 mm. My software (Leica) and I would guess all others take the broadcast height and erroneously subtract the antenna height to give a "monument height", unfortunately since the broadcast data is the monument height that puts the monument height reported by the software below actual by the antenna measure up. A couple of the mounts have heights 35 millimeters below the ARP, so this is a real mess. I was told the reason for publishing to the "monument" height is so they could recover the vertical to sub millimeter level, BUT unless you change the mount, it seems the ARP is fixed to sub millimeter level too and a lot more standard.

Still looking into this, but that is current findings. RTCM message Type 106 is being sent out with the monument heights and the antenna height. My understanding is that Message Type 106 is defined as the ARP height and my Leica software is taking it as so and subtracting the broadcast antenna height to produce a bogus monument height.

I might still be confused by this, but it sure looks like the above is what is happening.

On another note, I don't know if antenna height was coming across when I was in the field or not? From home lots of miles away I can get a code only solution and the antenna height and receiver type are blank on my collector, yet those fill in correctly on the Oregon RTN node a few hundred meters away today. I wished I had noticed what was happening in the field, it is entirely possible my rover software did not account for antenna types when getting a real time solution. These observations were made today in real time, I find no record in the stored data of antenna type at the CORS, but maybe it is hidden someplace in a menu?

SHG

I was typing a new post (below in italics) and noticed my old one from four years ago asking basically the same thing. I have confirmed that CRTN coordinates are to the monument. What I still am unclear on is if the antenna type is broadcast and the height. Four years later still wondering if any practicing surveyor is using the CRTN and making it work correctly in the field with Leica (or I suppose any other brand of equipment?)

Looking for help with using the California CRTN network. I understand it is single baseline; the coordinates broadcast are to the geodetic monument (not L1PC or ARP). As far as I can tell the antenna height generally 0.0083 meters nor the antenna type are in the RTCM 3.3 stream.

If you use this network, how does your controller software handle the base station? I am using Leica Captivate and trying to figure out how to force the software to account for the antenna type and the antenna height.

Every other RTN I have used takes care of the that on the server-side correcting to L1PC so that the rover computes the correct position. I do see where I can specify the antenna type of the base on the rover but haven't tried that yet because I don't yet have the entire NGS library of antennas loaded (another little wrinkle I am working on).

Look, I get it that there are some brilliant folks including PHD's figuring out things in California and they have reasons I am sure, but I am struggling to figure out how to use by a surveyor in the field. The main reason I think they broadcast to the geodetic monument is it doesn't change with different mounts and antennas, but unless I am missing something it is nonstandard as far as implementation of an RTN and how that works on a rover.

I don't use this network often, last time was four years ago and if I recall correctly I manually adjusted the CORS back in the office which then post processed the rover data to move the rover points to the correct place, but if I can figure out how to use this network to give correct answers in the field that would be a much better solution.

I hope I am just not understanding something that is simple that I need to do.

SHG

So here is something simple that I do to get excellent and consistent data from CRTN using their CORS network.

I'm in SD County and have used CRTN since 2016 and it has been an excellent base and coverage has steadily improved over the years. In 2016 most days PDOP was 1.3-2.0 with 6-16 sats. By 2025 most days PDOP is 0.9-1.3 with 12-20 sats. When I start a job I connect to CRTN as my base then localize to whatever county published mons and elevations are in the area. When I return months and sometimes years later I localize again and my new rover data has always fit my old points within 0.05' Horiz & 0.1' Vert. That is repeatability and my job is anchored to physical published mons in the area, not to an electronic network that can and has changed its output over these 10 years.

Basically the coord and elevation of a CORS point don't matter to me as long as it dosen't change in the middle of the day while I'm connected to it :-). Also if there are improvements, sewer, stormdrain, curbs, etc. then I match whatever datum they are on. I do not confuse folks by bringing in an electronic elevation based on a point 15-20 kms away.

Seems like the main question is: are the resulting coordinates correct or not?

If they are then the system is working correctly, if they are not then it's a bogus way to collect data. 

So, are they or aren't they? 

Well which egghead gets to determine the "correct" coordinates and the "correct" elevation and the "correct" epoch and the "correct" definition of the foot?

And more importantly, does changing my data to some eggheads version of "correct" data move anything on the ground? 

The answer of course is NO. 

Now as far as the county map checkers are concerned, there is nothing bogus about collecting data that fits the existing recorded maps and improvement plans using the existing published coordinates and elevations around the property being surveyed and showing the datum being used on the map. Our maps get recorded just fine and can easily be retraced and/or checked using any of the county published control mons in the area.

Well, the "correct" position should be defined by the OP. What does he want to hold. Typically, we will run control today on NAD83(2011) tied to CORS stations with vertical NAVD88 tied to bench marks. 

There are a number of ways to check if the control being used is within an error budget for the project. We will send data to RTX, tie it to nearby CORS, or even HARN if the HARN point is a first order bench which most of them are in this area. It should be fairly painless to check the RTN numbers. 

If no one cares about the "real world" accuracy of the control, buy all means a here location will get you one any projection for bearing and distance accuracy even if the Geographic location is off a bit. 

Being in California means the geographic velocity changes are probably extreme, how an RTN handles that may be a very interesting subject. 

@landbutcher464mhz that isn't ideal on my project. Wide area mapping covering an area of about 50 miles x 175 miles along the California coast, I have nothing to match to and even if I did it would necessitate a bunch of localizations. I want to get current correct positions from the CRTN on my rover without treating the network as a random unknown base station.