I'm trying to do an OPUS-Share on a triangulation station (EV9284) that was placed in 1978. Since then, what was probably a Pine sapling at the time has grown to a tree about 50' in height, 23 feet south of the station, with some limbs overhanging the station. I was able to trim the reachable limbs, but I didn't have a pole saw to get the higher ones. I occupied the station with a Trimble 5700/Zephyr Geodetic for about 4 1/2 hours.
The results were surprisingly sucktastic, with my Lat error being 0.043 meters and the Long error reaching 0.319 meters. I understand OPUS will not accept it as a share if the Lat/Long exceeds 4 cm, so my Long really screws me.
I pulled it up in WinTEQC and looked at the QC for the observation and it stinks as expected. I'm still figuring out TEQC but the best I can see to do is to remove the really crappy SVs. I'm not seeing a way to perhaps edit out periods when a specific SV is bad, but keep the rest of its record. Is this possible in TEQC? Or should I just give up on it and move on?
And along those lines, does anyone have any pointers to good TEQC tutorials? So far I've been mostly using the Help function and I'd like to learn more about editing and specifically how to fix cycle slips. I've read forums discussions when people mentioned fixing slips, but I'm not seeing how that can be done.
Thanks for any guidance you can provide....
Tom
The percent observations used is only 45% with 71% of the ambiguities fixed. Values that low indicate that there is not much you can do to improve things. My only suggestion is to select other nearby CORS stations for additional OPUS solutions.
I'm far from expert, but I would have little hope for saving this file. I think the advice is that taking out bad Sat records does little that OPUS can't handle itself.
The recent solar flare may have had an impact here, so a preoccupation could conceivably be better despite the tree,but it does sound like a difficult location.
I look forward to any advice Paul in PA has.
Before I started messing with the "raw" data file, I would suggest selecting DIFFERENT CORS sites around your Remote Station, and taking a look at the Peak-Peak Variances that different combinations return. Not all CORS (coordinate estimates) are created equal. Also, take a look at the Short Term plots of the various CORS within [say] 150 kilometers, and select ONLY CORS that have similar variances (computed v. predicted).
Loyal
The OPUS extended output includes a section (see linked image) that provides data regarding each SV. It can be used to see whether any SV data should be excluded. That said, the OPUS processor would most likely exclude bad data when performing its solution. It does attempt to use as much data as possible.
But the real advice, IMO, is to forget this site. Your observations show, yet again, that bad sites yield bad solutions. I am not familiar with modern commercial processing packages. Old versions of the Trimble SW included planning software allowing you to enter masks where obstructions existed and I believe show you the resulting reduction in DOP values.
Cheers,
DMM
Thanks for all your suggestions. I'll play around with other CORS sites and see if I can improve it much. But the error is so large I don't hold out much hope. Yeah, it was a pretty bad site, but I didn't realize it until I saw it. I thought the tree would be further away from the station.
Tom
You might also try shaving the first 30 minutes off of the RINEX file, and seeing what that does for your "percentage of observations used."
Loyal
If you are inclined to do a science experiment, I can create a project in OPUS Projects. Loyal suggested above to include CORS stations that have decent short-term plots. Having 10 or so CORS stations may provide a slightly better solution. It looks like your observation was just before the geomagnetic storms hit, so there may be a chance of improving the positional accuracy.
I can either create the project and give you the project ID to submit the OPUS solution, or you can send me a RINEX file and I can submit it.
Check if the guy who owns the tree also owns a chainsaw.
Paul in PA
Paul in PA, post: 446217, member: 236 wrote: Check if the guy who owns the tree also owns a chainsaw.
Paul in PA
Looks to me like that point would be in the Angeles National Forest.
That could be a bit of a problem (although I'm sure that the USFS owns plenty of chainsaws).
😉
I really don't think anyone wants a tree cut down just to get a GPS shot, private or public lands.
Based upon the suggestions here I deleted the four most crappy satellites and forced OPUS to use some different CORS sites. I was able to drop my Long error from 31.9 cm to 19.8 cm. But my Lat error increased from 4.3 cm to 9.6 cm. So, sorta an improvement. If I'm looking at an OPUS Share error limit of 4 cm, it just doesn't look like I have enough room to tweak this to make it work that way. I can still submit to GPS on BMs as a handheld and submit pictures, including the damn tree.
You are correct, this is indeed within the Angeles National Forest. Given how ravaged this particular forest has been by bark beetles I was very judicious in the trimming I did. And since my livelihood doesn't depend on getting a good fix at this site, I believe I'll just let the tree be.
Gene, I appreciate your offer, but in all honestly I really haven't learned enough about "GPSery" to take you up on it. I'm still dragging my sorry ass up the learning curve. For example, I still need to figure out how to read CORS sites for quality (in between messing with TEQC). And you are correct, my measurements were just prior to the geostorm mess, and that could be a contributing factor.
Thanks again all!
Tom
If you want to know how good the location is do a couple of GPS points in the open and tie the monument, if CORS pts are within 20 miles a half hour would be fine on the two tie pts
CORS data availability sometimes gets improved even after rapid solutions are done, and another improvement can sometimes come with precise orbit data in a couple weeks. Try resubmitting after JPL posts precise orbits.
Tom,
What Loyal is talking about is to look at the short-term time series plots for the CORS stations used by OPUS. For example, here are the 90-day plots for LORS and AZU1. Your OP shows "CLAR" as a base station, but NGS doesn't recognize it as a valid CORS station.
You can see the latest plots by going here https://www.ngs.noaa.gov/CORS/ and entering the CORS station name, and clicking on Time Series (short-term). They can indicate problems with a particular CORS station. For example, there is a data gap and one poor solution for AZU1 between Julian day 232 and 238.
Paul in PA, post: 446217, member: 236 wrote: Check if the guy who owns the tree also owns a chainsaw.
Paul in PA
Now thats funny!
Sent from my iPhone using Tapatalk
Tom,
What Loyal is talking about is to look at the short-term time series plots for the CORS stations used by OPUS. For example, here are the 90-day plots for LORS and AZU1. Your OP shows "CLAR" as a base station, but NGS doesn't recognize it as a valid CORS station.
You can see the latest plots by going here https://www.ngs.noaa.gov/CORS/ and entering the CORS station name, and clicking on Time Series (short-term). They can indicate problems with a particular CORS station. For example, there is a data gap and one poor solution for AZU1 between Julian day 232 and 238.
Why are you trying to do an OPUS Share? I mean what is the point if the site is questionable because of a large tree obstructing the sky?
Sent from my iPhone using Tapatalk
As can be seen from the data sheet, the published elevation is by VERT ANG (vertical angle) in NGVD29 and transformed to NAVD88 via VERTCON. As such it is not useful in the GPS on BM campaign. It is NOT a BM and as BushAxe says, why submit bad data?
Look at your peak-to-peak difference in the ellipsoid height. It is 3.6 DECIMETERS!
Looking at your OPUS result (2203.8 m ) and the VERT ANG based height ( 2204.6 m ) we have a better check than I would have thought. Still it is an eight decimeter difference. "Better" because I would expect the VERT ANG based height to not be as good.
Cheers,
DMM
BushAxe, I'm doing this stuff as a rather strange hobby, submitting under the GPS on Bench Marks program. Ultimately I'm planning on submitting on some BMs in lacking areas that will feed into the new Geoid model. Before that though, I need to figure out how to do all this stuff. As part of my learning process I selected a number of fairly uninteresting BMs to do dry runs on, including the submission process to OPUS Share. The main criteria for me in selecting these trial BMs was that I could drive pretty much to them, and they needed to have a high elevation since, you know, it's hot out now. If I have to sit on my ass for four hours I want to have a nice spot! When I picked this spot online I didn't realize it was now under a tree. Once I actually saw where it was I thought it unlikely I'd get good results, but as part of the learning process I needed to see just how bad a configuration like that could be. Now I know. Pretty bad.
Gene, thanks so much for that explanation on CORS quality. It was really helpful. I'll pull up some more CORS sites and have a look at them now that I know what to look for.
Tom