OPUS Rant

Just yesterday there was https://surveyorconnect.com/community/threads/static-files-to-opus-whats-your-field-procedure.331767/#post-444140&apos ;">a thread about the same problem. It probably has to do with your collection procedure.

17 hours (or rather 1700hrs GMT, the next day) is how long it takes for the [xxprecisexx] rapid ephemeris to become available. That sometimes allows marginal data to resolve.

Mark Mayer, post: 444248, member: 424 wrote: Just yesterday there was https://surveyorconnect.com/community/threads/static-files-to-opus-whats-your-field-procedure.331767/#post-444140&apos ;">a thread about the same problem. It probably has to do with your collection procedure.

17 hours (or rather 1700hrs GMT, the next day) is how long it takes for the precise ephemeris to become available. That sometimes allows marginal data to resolve.

I think you mean the rapid ephemeris ....

Rankin_File, post: 444251, member: 101 wrote: I think you mean the rapid ephemeris ....

Good catch. And in time for me to change it.

They were selecting OPUS sites themselves weren't they? I tried that also and got the same results. It's 4 hours of collecting. It's not in the system long enough to be evaluating if it's noise or not. I'm assuming OPUS checks how long ago you collected it and blurts out the noisy data blurb automatically if you submit it too soon. I'm hoping that's the case anyway.

Skeeter1996, post: 444256, member: 9224 wrote: They were selecting OPUS sites themselves weren't they? I tried that also and got the same results. It's 4 hours of collecting. It's not in the system long enough to be evaluating if it's noise or not. I'm assuming OPUS checks how long ago you collected it and blurts out the noisy data blurb automatically if you submit it too soon. I'm hoping that's the case anyway.

Skeeter,

Shoot me your RINEX file if you like...LDOGEO AOL

Loyal

Skeeter1996, post: 444256, member: 9224 wrote: They were selecting OPUS sites themselves weren't they? I tried that also and got the same results. It's 4 hours of collecting. It's not in the system long enough to be evaluating if it's noise or not. I'm assuming OPUS checks how long ago you collected it and blurts out the noisy data blurb automatically if you submit it too soon. I'm hoping that's the case anyway.

Occasionally I'll get that message if the first few epocs are wonky. OPUS is kind of fussy and doesn't go into the file very far before aborting. I've had pretty good luck using teqc to parse the files out into 15-30 minute segments and submit them individually for RS solution when I've run into that problem in the past.

Skeeter1996, post: 444243, member: 9224 wrote: I haven't used OPUS in awhile. Use(d) to be a great program. What's up with it now. Every file comes back "Aborted Noisy Data, blah blah, blah." So I assume the Government has improved it now. What do I have to do resubmit in 17 hours?

Noisy Data is one comment you should believe. Learn to look at your data in RINEX format before you submit.

Even if you are submitting in proprietary format, RINEX allows you to see what your receiver thought of the data. Most likely you just turned it on and walked away, so delete the first few minutes and resubmit.

Paul in PA

Data is FINE!

The File crosses GPS Midnight between yesterday and today.

Todays data processes fine using OPUS_S and the Ultra Rapid, yesterdays data is less than 2 hours, and OPUS_RS gagged on it (no surprise out here in the West). It "might" work later today when more CORS data gets to the NGS.

The whole file will process fine tomorrow.

Loyal

I only have older gps, so I never have a problem with OPUS. I mean never. Don't even need to convert to rinex. (Ok, Once it kicked back "too noisy or kinematic". But NRC had no such issue!)

Crossing 0:00 UTC isn't a problem. But is crossing 604799 weeksecond an issue?

Larry Scott, post: 444448, member: 8766 wrote: Crossing 0:00 UTC isn't a problem. But is crossing 604799 weeksecond an issue?

I don' t think either of those are a problem. You are allowed ONE crossing of 0000 UTC in your file. If you cross the end of the week at all, it will add another whole week to the delay before you can process with precise orbit data, but I don't think it has any other effect.

The "crossing of GPS Midnight" is ONLY a problem when you try and submit to OPUS "TOO SOON" (i.e. same day).

OPUS will NOT combine an Ultra-Rapid and RAPID ephemeris together in a single solution (or never has in my experience). You end up with the infamous "noisy data" (the dog ate my homework) error statement.

Loyal

Loyal, post: 444277, member: 228 wrote: Data is FINE!

The File crosses GPS Midnight between yesterday and today.

Todays data processes fine using OPUS_S and the Ultra Rapid, yesterdays data is less than 2 hours, and OPUS_RS gagged on it (no surprise out here in the West). It "might" work later today when more CORS data gets to the NGS.

The whole file will process fine tomorrow.

Loyal

Loyal
You are THE man. File processed fine today. Thanks!!

Crossing UTC midnight would not be a problem if NGS understood their own data.

Each orbit file contains 48 hours of orbit data. I just opened an ultra-rapid _18 orbit for 8/22/2017. Data is at 15 minute intervals from 2017/08/21/18 to 2017/08/23/17-45. In other words a file that crosses "UTC midnight can be processed with the prior day's orbit file as long as it is nowhere near the maximum allowable length.

The OPUS comment assumes a possibly larger file than sent.

Paul in PA