Crew went out couple of days ago and collected 4+ hours of data on 2 separate points.
I submit to OPUS and get this message:
"OPUS could not process the data file that was submitted. The data was either very noisy or it was collected in kinematic mode."
I can't see where the crew did anything wrong. They used the exact same settings from 3 weeks ago for another job, which processed very well. I looked in the DC to make sure the "session" were started the way they were supposed to be and I can't find anything in error.
Is a 10s logging interval too much data for OPUS?
> "OPUS could not process the data file that was submitted. The data was either very noisy or it was collected in kinematic mode."
Can you open the data in your processing software. You should be able to see an occupation view that shows the satellites you were receiving from.
If there were trees, buildings, birds, alien spacecraft, etc... blocking signals, you might actually have data that is so spotty (noisy) that you get this message.
Rob,
If you're not in a huge rush, email the RINEX files (LDOGEO at aol dot com) and I'll take a look at them tonight, and also run them through TEQC.
Loyal
We get that message occasionally, resend the next day and all is well.
Okay sports fans, here's what I think “MAY BE” happening with SOME of these OPUS submissions that are kicking back.
I suspect that OPUS has a bit of a problem COMBINING the Ultra-Rapid and Rapid orbits in the same solution, OR, possibly just doesn't like data that spans from “yesterday” into “TODAY.” Basically, you are trying to get a solution TOO SOON, and if you wait a few hours (or in some cases until the next day), the SAME file(s) process just dandy.
Files (observations) that cross from “yesterday” into “TODAY,” seem to be the biggest offenders. Here in the West, we often work until 8 or 9 pm in the field (Mountain Time Zone), which is 2-3 hours into the NEXT GPS day! During Daylight Saving Time, 6 pm is the magic number, and we NEVER “pick up” before that.
I tried submitting my Base Station data from yesterday just now (runs about 17 minutes into TODAY), and got the “noisy/kinematic error,” but it processed FINE last night, when I trimmed “TODAY's” data off the tail end of it (which I always do when I need a “quick” solution). By now we should be talking Rapid-n-Rapid for the entire observation, so maybe it's just the GPS-DAY thing that blows things up.
Just a SWAG
Loyal
OPUS will not process data collected with 4700's this week. Anyone else having problems? Data collected with an R6 or R8 works fine.
Trimble 4700s were very good to me (sold my last one earlier this month for a lot more than I thought it would bring:-D ), so if you want to send me your file (DAT is fine) I will take a look and see if there is a solution or an obvious problem.
Contact me via the e-mail link (the envelope icon by my name) and I will reply with directions on how to get to my web-based file uploader.
GB
Thank you for the offer GB. We discovered we had to download the most current Rhinex converter from Trimble. Once we installed the new version, we were able to submit the Opus data for post processing. There must be an internal time out clock in some of our surveying software, much as TGO not post processing static surveys any longer. I have avoided Trimble's attempt to force us to invest in TBC yet once again.... Thank you so much for the offer.