I am trying to convert some CORS data to Ashtech format so I can process the data with Winprism. The Ashtech Rinex2 converter does not recognize the observation file that I download from the CORS site. We ran 2 receivers for 5 hours on 2 points. They are within 20 kilometers of one CORS station. One receiver was on a 1st order Airport Station. When I submitted the data to OPUS the position OPUS reported back was 0.968 meters from the published station. I would like to be able to use the CORS station in my network. I tried the Rinex conversion program that is on the ASHTECH FTP site and got the same results. Any suggestions?
Steve Corley
1. Did you un-GZip it?
2. You have to download all three files from the CORS, the n, o and s files, not just the o.
The files were in a PKZIP format and were downloaded from the UF web site at a 10 second epoch interval. All 3 files and the precise ephemerus file were included.
Steve, a while back another chap had issues with using data from the user friendly CORS setup with ZIP compression. I have seen this too with IE 5.xxxx on a few occasions....
Take one of your Ashtech files, convert it to RINEX, and then RENAME the ephemeris file (.01n) to whatever the CORS ephemeris file should have been...Then try converting from Rinex to Ashtech...I have seen instances where the ephemeris file was corrupted either in the download or zip process and just wouldn't convert to Ashtech format....
ALSO, open the .01o file with wordpad and see if the "marker name" in the rinex header is a 4 letter name or if it is longer than 4 characters....We saw a Trimble cors station (Concord, NH) that had a site name longer than 4 characters, and we had to truncate the name to 4 to get the rinex to ashtech conversion to work.....bob
Modified By Robert Bills on 11/27/2001 at 4:23 PM
Hello Steve,
Please send me your rover files for which you are wanting CORS data. Also, from which CORS site were you requesting data?
What receivers and, if any, handheld controlers were used for this survey?
Please include information indicting which receiver was located on the Airport Station. Is there an identifier or PID for this station?
Linda
lmalcom@magellangps.com
We tried to bring in data on 10 second intervals for our recent CORS experiment. Even on stations where the sample rate was 5 seconds (where the software only had to drop every other epoch) the data was still messed up. I would strongly suggest using the data "AS IS". I don't know much more about it than that, but maybe that will help.
Shawn
My guess as to the .968 meter difference between OPUS and published coordinates is due to mixing NAD 83 and ITRF coordinates. This is usually the problem when you get a difference of about a meter. OPUS always gives you both NAD 83 and ITRF coordinates. If you compare the published NAD 83 position with the OPUS ITRF position you will get about a meter difference.
Steve,
I have had problems with the interpolated data several times. A guy from the NGS sent me this message:
"The interpolation program does have a problem when it finds an epoch that doesn't have a time stamp that reflects the epoch interval. This happens some times when we
get a bad line of data from the receiver at the site. Unfortunately the only current fix is to go in to the file and delete that epoch then run our interpo program on
the new file."
As Shawn suggested, try dowloading the data AS IS (30 second rec. time) and see if it converts correctly. This has worked for me, although you obviously don't get as much data in your solution.