The Importance of Carefully Choosing CORS
A recent post/question on OPUS-RS combined with a series of recent receiver support calls has prompted me to post this CORS / OPUS warning note. We have sold so many static receivers that if a portion of the CORS network has issues, chances are that we will have several customers in the footprint of the problem. It is easy to call us and I guess I end up being the canary in the mine. Today received three similar calls from a location south and east of Utah today.
For the record, I am going to obfuscate particular details because I don’t want to disclose customer data or point fingers at a particular CORS operator or station. (Other than to say it is not me or one of mine…;))
When you are submitting observation files to OPUS, and allowing OPUS to pick CORS stations to use in solutions, you need to do a little quality control on the chosen stations. The first clue that there might be something up is a high peak-to-peak on a Lat, Lon or Height:
[INDENT]
[/INDENT]
In this case, the ‘Peak-to-Peak’ error for the height is crazy high.OPUS might toss back a note about the quality of the submitted data (or not.) Typically I would suggest waiting a day and reprocessing as closer CORS station data becomes available. In most cases, as we have all found, submitting the same file on a later date results in substantially better results. However, sometimes a customer will have data that still fails miserably after a week.
What is up with these customer observation files that appear to be bad?
There are many stations in the CORS network that suck. The quickest way to pick them out is to go to the station’s page on the NGS CORS site and click on the link to ‘Time Series (Short Term)’ link:
[INDENT]
[/INDENT]
You will be shown a graph of the sites recent daily solutions.
If it looks like this:[INDENT]
[/INDENT]
You absolutely DO NOT want to include it in any OPUS solution. In this particular (unnamed) case, there are three sites in the area that are equally bad.If this were a single station, I would suspect that a large bird had built a nest on the top of a choke ring antenna, or that the cable had a poorly terminated end. However, because three nearby stations (with the same receiver type) share similar plots, I suspect that it is a firmware issue or tracking issue. No matter the case, you can’t personally fix it, so you need to exclude these stations from OPUS solutions.
In addition to crazy plots like the one above, you also need to be wary of sites that have trended far from the published coordinates:
[INDENT]
[/INDENT]
Often several sites in a general areal will all be trending the same direction. This will artificially influence a solution.One of my ‘take-away’ points here (and remember that I am biased) is ‘problem solutions are sometimes a result of the CORS data, not the observation data that you collect with your receiver.’
It has been my experience that if you drop a short note to the NGS and alert them to a failing station, they will very quickly take action. Which makes the CORS system better for everyone. It is worth reporting these anomalies so that they can be fixed as quickly as possible.
M
Log in to reply.