OPUS

OPUS-RS

The raw XYZ positions may be wrong. This can happen if you start recording data too soon so the receiver uses the previous XYZ position. If you create a RINEX file you can edit the XYZ values and resubmit.

If you can't, send the RINEX files to me for a look.

Paul in PA

Maybe try waiting a day and resubmit. Have had similar issues. Seems they're having some backlog problems from what their portal says.
!OPUS backlog ~ your solution reports may be delayed due to capacity problems'.

I sent in a file yesterday to OPUS-RS

that was observed last Saturday. That was over 4 days after observation.
I am in the middle of half a dozen CORS (TxDOT) within 50 miles.
I may have to go back and manually pick my ref. stations and try it that way.
Got this message back:

6014 OPUS-RS cannot find three reference stations within 250 km of
6014 your position and with suitable data for use with your dataset.
6014 OPUS-RS requires at least three reference stations and is
6014 currently limited to a maximum distance of 250 km. If you wish
6014 to use reference stations more than 250 km from your rover station,
6014 you may use the User Selected Base Station feature on the OPUS
6014 Options page.
6014
6014 If your data set is recent, it is likely that data from the nearby
6014 CORS stations have not yet been uploaded to the CORS archive. You
6014 may want to try again later.

OPUS-RS. Received Your Files

RINEX did not include antenna type or height. I know that OPUS does not read that information out of the RINEX file, but someone else processing your file would.

I see you moved at least 10 Km between observations, so at any rate the second position should have been close enough to be within some polygon. It appears the OPUS-RS computer did not have connectivity to all the CORS files.

I'll post when I get an OPUS reply.

The longer the reply time the more likely it will process.

Paul in PA

OPUS-RS Aborted Both Files

For the first you were 154 Km outside of polygon, LOYZ, LOY2, LOY1 and LOY8.
For the second you were 152 Km outside of polygon, LS02, LOYX, LOY2 and LOYO.

For OPUS-RS to only pick 4 CORS with 3 different only 2 hours later indicates a CORS data quality problem.

Do you have some default setting OPUS-RS is remembering? If so go to options and pick nothing.

Paul in PA

OPUS-RS Definite Data Problem

I checked some CORS near you, LSO6 had not data for the past week at least. NCJA, NCRX & NCWR had data so I resubmitted requesting each one separately and all did not meet data quality.

At this point I suggest you re-observe longer for OPUS solutions.

Paul in PA

OPUS-RS Definite Data Problem

> At this point I suggest you re-observe longer for OPUS solutions.
>
> Paul in PA

Bummer. It is awfully good of you to try to help.

I am watching these OPUS posts more closely now as I am planning to leave the RTK-RTN world and enter OPUS/OPUS-RS.

I have a feeling that if you continue to be so helpful here then you and I are going to get to know each other.

Thanks everyone for the help. I guess I'll re-observe and try again.

> Thanks everyone for the help. I guess I'll re-observe and try again.

Please forgive my ignorance here, but will your new observations be 2+ hours instead of 16+ minutes?

Just a suggestion but if you have the ability to plot the DOP for the day your planning your observations you can avoid the times of the day in your area when the DOP will be spiking making for cleaner data and more precise solutions. I use TGO for this purpose. Helps as well for RTK planning. Most of you probably already do this I assume but thought I'd toss it out there. I'll take 16 minutes of clean data over 2 hours of chopped up cycle slips.

Right, carry on and good luck.

My observations were about 1 hr.15min for one file and about 45 min for the other one.

Thanks

2 Hours For OPUS

Landman can take a chance and re-observe for OPUS-RS, but why take a chance. It appears that the nearest CORS has been out of service, why risk a third trip. It appears at least 3 other CORS have quality issues that span at least 3 hours, so planning would not help. My first thought is there is ice buildup on the antennas. I did not check if the CORS have radomes, probably not. In that neck of the woods CORS operators are less mindful of those problems.

I do not know if Landman cannot post process himself but he may have contract issues. I can post process all day long but I still want those independent OPUS/OPUS-RS reports in my file if the client has any questions.

Because I am always on the job long enough, at least one of my files is long enough for OPUS and run 2 L2 receivers. I submit that file first day as a check on my observations. I then use those coordinates to set up my field work and orient my project on the map sheet. I then split that long file and resubmit to OPUS-RS along with my other observations. If almost everything goes bad that can and it has, (batteries, batteries and just a bad GPS day) I may be left with a 17 minute OPUS-RS and an 8 minute OPUS-RS and some L1 observations. I can still live with that.

Paul in PA

2 Hours For OPUS

I don't have the capability of processing L2 files, only L1, so I have to submit the L2s to OPUS.
What I have is one dual frequency that I use for OPUS or OPUS-RS and three ProMark 3s that I process myself in GNSS Solutions using the OPUS solution as control.
This has been working really well for me but it looks like it jumped up and bit me this time.

2 Hours For OPUS

I would wait. I have some from 2/24, 2/25 and 2/27 from different parts of the state that are all getting the same error messages.

Cool Trimble online planning software. Only works with microsoft silverlight though.
https://www.trimble.com/GNSSPlanningOnline/

It might just be cheaper to obtain post processing software, a couple of resurveys that depend on OPUS would come close to paying for it