OPUS error 9011
I’m in my weekly “hurry up and wait” mode again today. I have a 10 hour RINEX file collected during the usual Wednesday Field expedition, which of course laps about 2 hours into Thursday (GPS time). I pretty much go through this every week.
OPUS error No.9011
9011 OPUS could not process the data file that was submitted. The data was
9011 either very noisy or it was collected in kinematic mode.
9011
This code shows up for various reasons, INCLUDING the obvious (bad data), but I only see it when I am trying to submit data that crosses GPS-Midnight, too soon after the observation. I suspect that this is because the IGS RAPID Orbits are NOT [yet] available for the “second day.” Or in some [rare] cases the NGS doesn’t have ALL of the requisite CORS data for the “second day”. I certainly understand that OPUS can NOT process data they don’t have, BUT a more accurate and informative “error message” would be nice.
The IGS RAPID Orbits have a 17-41 hour latency, and are usually available @ 17:00 UTC on the following day (“third day” in the case of a two day observation). So our Wednesday observations that lap an hour or two into Thursday, can not be processed until about 11:00-12:00 MDT on Friday. I ASSUME that OPUS is setup such that it will not combine a Rapid Orbit set (Wednesday) with an Ultra-Rapid Orbit set (Thursday), hence the “error” and delay.
In the Winter we are usually seeing only a few minutes (usually less than 30) of overlap, but in the Summer 2-3 hours is not uncommon. That’s enough data to be worth waiting for. If I NEED a quick solution, I can always trim the tail end of the RINEX file, and OPUS will happily process the [day-1] data on Thursday, BUT that means I will have to resubmit on Friday (about Noon), and tweak the data set a little based on the complete solution.
Ah well… another half hour or so and it will work!
This will be the THIRD observation on this Station (2008, 2010, and this week), so it will move from a Secondary Base Network Station, to PRIMARY Base Network Station in the County Surveyor’s NAD83(2011) database. That is assuming of course that the numbers look good (which I’m pretty sure they will).
Loyal
- 4 Replies
As you know from our previous emails awhile back, I experienced the same problem. I was out wednesday and collected some 8 hr datsets that also crossed GPS midnight so I will wait until later today or tomorrow to submit to OPUS.
I agree, Loyal. Their error messages could be much more informative. I think it would make their life easier as well, since people wouldn’t be bugging them about error messages that don’t seem to apply. I have seen messages that had no relation whatsoever to what happened.
High Noon…
Mountain Daylight Time appears to be the magic number this week (was last week too).
Loyal
At Least They Got Rid Of This Message
“OPUS file ends before it begins.” Saw that one several times in the past.
NGS speak for “The dog ate my homework”
Paul in PA
Log in to reply.