RTN elevation question - rookie

But just was curious what someone’s immediate thoughts were on as to why once it became “fixed”, it would set me 2’ low of a published county benchmark referenced to navd88, and when I lose lock “float” I’m hitting right on.

It might be referenced to NAVD88, but it might actually be NGVD29. Hitting right on in "float" is just a coincidence. Check the county benchmark against another county benchmark.

My “immediate” response would be to re examine the published county benchmark data source.  The exact 2 feet disparity at coast side might suggests you are referencing a tidal datum elevation.

Native1, There are so many things that might have caused what you saw that it is impossible to diagnose yet. Consider these as you look for the answer.

• Know your RTN service.
• They should be able to tell you how the network was working when you were active.
• They will also be able to give you the stats on the performance of their stations and the network as a whole.
• On the coast, you may have been outside the perimeter of the network. A good network will give an accuracy of about 1 part per 10 million but revert to 1 ppm outside the network.
• On the coast, you may have an antenna that is sensitive to multipath from the water.
• Near the coast, there is usually a sea breeze. During warm weather, this will cause convection over the land with ionized clouds or squalls in the area, which can be a serious cause of multipath.
• Having observed it twice with similar troubling results, it may well be worthwhile to take a few hours of a static session and submit it to OPUS or to a post-processor your RTN service may provide. A successful result from OPUS will provide you with a "truth" to which you can compare.
• Another real-time technique that sometimes answers questions is to change the height of the antenna and reobserve. If all is working the (fixed) results from the two HIs should agree.

There are times when a float solution can be closer to the truth than a fixed solution in multipath situations. It is pretty rare but does happen.

Good luck,
JAC

I think he nailed most of it. Find out from the RTN provider what they are tied to. Aka what hz datum and vertical datum. Dont know where you are but the BM What Datum vertically is it on. Ngvd29 or navd88 or some local smoosed datum. All datums horizontal and vertical are not the same. Not all BM have been observed and if it was a say NGS data sheet is it susceptible to subsidence?  Here the difference between navd88 and ngvd29 is about a foot. East coast of Virginia but that’s rough depending on exactly where in the state. I would go to NGS site and watch a few old webinars or old training videos. Horizontal datums and vertical datums.  Great knowledge to have. Like the understanding of geodetic vertical datum vs tidal datum. You will need to get some of this information in your head as you learn rtk and rtk on a rtn. Remember gps is a measurement tool. Just like a total station etc. get an understanding of what its doing what are the weaknesses and strengths.  What are the gps error sources. Ngs has a guidline on rtk and rtn. Surveying. Not all RTN are equal so what works in one area may not in another. Here north zone is pretty tight south zone is well i use base and rover for repeatability. Watch your service coverage aka cell coverage when weak latency can cause issues. Read up on multi path.  Near far. Understand your particular brand of entertainment in how it works and how to use it in a positive way. Be over cautious at first. REDUNDANCY is your friend. TIME is your friend.  Check re check and check again. 

In addition to the above, you should visit the CRTN website and download the PDF references linked there, particularly the one detailing the difference between NAVD88 and COH.  That's not the source of your 2 feet, but you ought to know what you're getting from the NTRIP server if you're going to be using the network.

@jim-frame Wow. Yall have a lot of movement to deal with often.  I guess yall have to track velocities often for a lot of jobs. With that type of movement going on does it affect control over a long site project. Like projects that last a year or more. I guess it would have to be watched. And such.  To much for my P brain.

It may be a datum setting in your field software. On mine I tried a couple settings in CA zone 3 and got 1.8 ft difference around San Jose. The software I use has a NAD83 and a NAD83 NoTrans setting. The No trans setting is the correct one to use and the NAD83 setting is incorrect. The software nomenclature for NAD83 has kept up with the iterations of the center of the earth and the no trans left NAD83 where it started and what most of the published control is tied to. 

I guess yall have to track velocities often for a lot of jobs.

I don't do any layout with the RTN, so I only use the numbers shown on the RTN DC for recon -- everything else gets post-processed, and I use a total station to set corner monuments.  But I would guess that the kind of projects you're talking about would best be addressed by establishing control at the outset and then localizing (horizontal) on that control for all future work.

Vertical movement is another matter, some places around here have a lot of it and you have to stay on top of it.  Most of my geodetic work is directed at doing just that.

CRTN does not provide a network solution.  You need to make sure you are using the best single base solution for your project.  While it is a great free service, it does not have staff dedicated to answering questions.  It is basically an add on to their CSRN's research CORS, most of which are run by Gage (formerly Unavco)  I have found that they are helpful but you are probably not going to get a lot of answers ont the details of your connection.

I have never quite figured out their heights.  I'm not sure if they are broadcasting corrections based on the ARP, L1 phase center or the monument.  The CRTN access sheet references the monument height, but the difference to the APR can very greatly between mount types.  To be honest, I have found that it is actually cheaper to pay Leica and use Smartnet if I'm worried about vertical.

As for the 2 feet difference, it could just be chance that your float solution hits the record better than the fixed solution.  I would really look into datum issues.  Try collecting raw data and post processing it using the CSRN's CORS.  If this really is a multi-path issue, it just goes to show why a temporal separation between repeat observations is necessary for critical work.

I spent a little more time testing the theory that a translated datum was used vs. the non-translated NAD83 datum of any realization and any geoid computation. I input an NGS control point into the field software using published state plane zone 6 coordinates near the ocean and the published height using the no translated NAD83 datum then reconfigured to what the software calls NAD83. The North and height change by about 2 feet and the east changes about 4 ft. If this is the issue the northing and easting should also not agree with published by a few feet as well as height. Perhaps the "BM" does not have survey accurate north and east coordinates to compare with. You could check into a mark that does to validate this. And then try a different datum setting if its off. When I was survey manager, we would receive this height complaint and more often than not this was the issue. Also always check more than one published mark. Stuff happens. 

CRTN does not provide a network solution.

Yeah this is a big one. An RTN is not necessarily "a VRS".

We've been bitten by that a few times here in WA, where we are able to select from a list of both single-base and networked mountpoints.

A crew will see a single-base mountpoint at the top of the list (usually due to oddball settings in the controller, or just a bad list sorting) and they choose that one rather than finding the network-solution mountpoint...even though the single-base is physically located 50+ km away. And if it's a new job where we don't have anything to check into yet...gonna have a bad time when we go to process.

And it bears repeating that not all BMs are created equally, or adjusted in the same way, or observed by the same methods....or referenced to the same datum.

Thanks for the replies,

some interesting points made.

My first guess was some sort of Datum issue - 2’ off/rifht on/2’ off when it’d switch between float and fixed.

With Surveypro, I’m not seeing other sensible choices except Nad83 - state plane - zone 6. 

I did try a different geoid model, and several different CORS bases and got the same answers.

I tried to translate everything to the BM -vertical only. But it wouldn’t go. I needed a horizontal aspect too, and I didn’t want to fudge the other data in the job.

So I’ll have to go back and mess with it.

the chief wasn’t into it and I only had maybe  15 minutes to mess with that day. 
I’ll go back solo soon and try to figure that one out.

I tried to translate everything to the BM -vertical only. But it wouldn’t go. I needed a horizontal aspect too, and I didn’t want to fudge the other data in the job.

Unless Survey Pro (sounds like that is what you are using?) has changed, you ought to be able to apply a vertical-shift site calibration using the benchmark as a vertical-only constraint, or manually plug in zeroed-out values for the horizontal plus a single shift/no tilt for the vertical.

Lots of good advice above. Only thing I can add is when working on the coast you may want to use a “NEAR” or single baseline solution. Network solutions like “VRS” or “IMAX” don’t not work as well due to the ‘all on one side’ geometry. Also, the vertical component degrades slower as the distance from your ‘near’ station increases than your horizontal component. Once you get things working and tested, don’t be so quick to trust ‘elevations by others’.