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.
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).
Log in to reply.