OPUS aborting message
I submitted a 35 minute GPS session to OPUS RS and received the following response:
6029 After the single baseline analysis, fewer than 3 useable
6029 reference stations remain. Aborting.
Can any of you tell me what that means? This was an urban canyon site. There are numerous reference stations in the vicinity.
I also sent the file to Javad's DPOS service and received a solution about 3 hours after a morning data collection session.
Thanks for your help.
JA, PLS SoCal
I always get that message from opus if I send a rapid static in the same day as the session. Give it 24hrs.
Rather than 24 hours, the magic time for a session that ends before 0000 UTC (USA evening) may be about noon EST on the next day or a little after.
The message is : "After the single baseline analysis, fewer than 3 useable reference stations remain. Aborting."
Most of those available CORS (reference stations) may not have yet been downloaded to the CORS reference bin or more likely have been downloaded and not yet checked out and filtered to be suitable for smooth operation in the RSGPS program that OPUS-RS uses. OPUS-RS requires clean L1, C1/P1, L2 & C2/P2 data. If you have ever checked your own data, you can see that as a satellite becomes visible, the L1 observation can precede the L2 observation and then the first few C1/P1 & C2/P2 observations can be incorrect values until everything is resolved. From time to time I have had to filter out some of those bad observations in my own RINEX files. Also to keep in mind is that OPUS-RS first starts with data well before your observation file and continues past your end time. This gives OPUS-RS a longer time frame to create a very good atmospheric model so your rover site can be resolved in a sorter time frame. The need to create that good atmospheric model is also why OPUS-RS wants your rover to be within the outer perimeter of your reference station polygon. Again, mostly from the past I have files where all the closest CORS were to one side or the other and I could get a better solution by forcing OPUS-RS to use a farther away CORS that enlarged my polygon to surround my rover.
The above message also means because of the poor base information, OPUS-RS has not tried to do anything with your file.
BTW, the L1, C1/P1, L2 & C2/P2 data is the raw calculated distance from the satellite antenna to your rover antenna in meters, and they are different due to the different atmospheric delays due to differing signal wavelengths. Satellites directly over head have the highest angular elevation and the shortest distances.
Paul in PA
Thank you for that information. I am humbled by the depth of your knowledge. I am not of the makeup to get into a topic that deeply. Never studied a RINEX file, never have, probably never will, given my jerryattrick status. You know, old dogs...
Anyway, I have always been sensitive to the timing of file availability with OPUS over the years. I have an option in the JAVAD service and regularly send data to both just because I can.
This session was early on St. Patrick's Day this year and I have sent the file to OPUS each day since, including today, with the same error. Data should have been available by now, surely. The site is in downtown Los Angeles and the ocean to the Southwest does limit the potential polygons from that direction. Thank you for making that point. It makes perfect sense.
Results are very close between the two services. One big difference is that I can get a solution within minutes, once in a while, with JAVAD. The collection in question finished at about 8:00 AM and I had a JAVAD solution before 10:00 AM, the same day. Sent from my iPhone.
Again, Paul, you are the man! Thanks for your input, all of you.
JA, PLS , SoCal