OPUS ABORT - About 5 hours after capturing data, a time parsed extract of an observation file was sent to OPUS for processing. Received this error. Is the error because OPUS is unable yet to process the data, or is there something wrong with what I sent them? The time period is 10 minutes, so I am fine with messages in lines 9999.
opus -RS requires a full 15min min, but your probability of success increases dramatically after 2 hours of observation. daily quantification of this is available on the NGS website.
why dont you just send the whole 5 hours?
Because the 1.5 hour session covers 3 different targets. OPUS gets confused with multiple sites in one session. Target 1 of 30 minutes comes back with the same abort message, sans 15 minute statement. Target 2 consisting of 15 minutes of data does likewise. Am I getting these aborts because the files were submitted too soon after capture or for other reasons?
John
OPUS isnt confused, it just doesnt work that way. if you have a single 1.5 hour log file then you need to chop it into pieces for each of your points. if you move your antenna/receiver at all during the occupation of each of the points, OPUS may reject your work for that point (its happened to me). so you will need to do your chopping of your 1.5 hour session file very carefully i would imagine.
and i would be hesitant to read the error messages to tightly. the standard response with OPUS error messages like that is give it 24 hours and then resubmit.
OPUS only works with GPS so you might as well turn off the other constellations. and i dont think it uses the SBAS nav message either but i have never checked.
OPUS works really well when you have a clear view of the sky. in california oak woodland with moderate cover it works but i never do a <2hr occupation unless its just a back up point or double check. heavy canopy, then forget it.
RTKCONV.EXE easily parses observation files to specified start and end times. “Successful” report back from OPUS this evening. However, it came with the warning below. Is there a better way than trial and error with resubmissions excluding a base station to find the problem one?
Yeah i have had that warning a couple of times in the past and it didnt go away. i think in one case i had a log that was say 45min long and i chopped the ends off by 10min and resubmitted and got something better. but now i just occupy longer so i dont end up risking it be a total bust.
i think there are clues in the OPUS report you might be able to try but i have never needed to figure that out, sorry i cant help there.
you might find some of this document helpfull…
Looking forward to reading the best practices in the morning. Thanks for sharing!
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.