OPUS-RS

I also submitted to OPUS RS yesterday and have yet to get a reply. When I tried to resubmit OPUS said that I was still in the que. Have to wait and see.

> I also submitted to OPUS RS yesterday and have yet to get a reply. When I tried to resubmit OPUS said that I was still in the que. Have to wait and see.

Glad to hear I wasn't the only one. Maybe the site is down for maintenance. Someone said there was a mirror site for days when the regular site is down. Anyone know the URL for that? I tried to Google it but to no avail.

Resubmit The Same File To OPUS-RS

And it should tell you, you are still in the queue.

Because OPUS-RS requires 4 clean observables, L1, L2, P1/C1 and P2. The later are sometimes missing from otherwise suitable observations of L1 and L2 suitable for OPUS-S. To get a resubmittal of CORS data sometimes requires some human intervention with the CORS operator. That is lmuch less likely to happen over weekends. The humans at NGS may be totally unaware of the problem if you do not bring it to their attention. NGS may have to filter the specific CORS files to obtain clean data and that can also take some time. I am not even concerned until the second day passes.

If you are in fact in a hurry then your recourse is to download from the 3 nearest CORS and Post Process yourself. I have at times downloaded 9 CORS and used the OPUS-RS processecong software "rsgps" to get solutions. It does not work well until the data is clean.

In addition your submitted files may not contain clean or even lacks some P1 & P2 data. OPUS-RS won't even check your file until it has clean data to compare it against.

Convert your observations to RINEX format, open them with a text processor and check your P1 & P2 data yourself. In order for OPUS-RS to use short time files to give you better precision than longer time OPUS-S files that extra data is required. It if it is not there and good you will eventually get back a report to that effect.

Lastly I recall a recent NANU that software was going to be updated. That usually happens on weekends, so the queue may be open but only storing all submissions until the processing computers are reopened. In order to keep yourself aware of such situations you should sign up with the US Coast Guard to receive daily GPS updates and NANUs. Being in responsible charge means knowing everything that affects your work.

Paul in PA

Add This Site To Your Favorites

US Coast Guard NavCenter

http://www.navcen.uscg.gov/?pageName=GPS

You can sign up for notices here.

Also check the existing advisories and NANUs.

I checked and saw that the updates I mentioned were to the NANU software and that was in fact completed on 6/22/2011.

Paul in PA

You broke OPUS! lol

So that's why I haven't received my results from OPUS yet this morning. You broke OPUS! lol I got tired of waiting and started post- processing a few minutes ago when I saw this post. Glad to see it's not just me.

Resubmit The Same File To OPUS-RS

Clean data?

Resubmit The Same File To OPUS-RS

> And it should tell you, you are still in the queue.
>
> Because OPUS-RS requires 4 clean observables, L1, L2, P1/C1 and P2. The later are sometimes missing from otherwise suitable observations of L1 and L2 suitable for OPUS-S. To get a resubmittal of CORS data sometimes requires some human intervention with the CORS operator. That is lmuch less likely to happen over weekends. The humans at NGS may be totally unaware of the problem if you do not bring it to their attention. NGS may have to filter the specific CORS files to obtain clean data and that can also take some time. I am not even concerned until the second day passes.
>
> If you are in fact in a hurry then your recourse is to download from the 3 nearest CORS and Post Process yourself. I have at times downloaded 9 CORS and used the OPUS-RS processecong software "rsgps" to get solutions. It does not work well until the data is clean.
>
> In addition your submitted files may not contain clean or even lacks some P1 & P2 data. OPUS-RS won't even check your file until it has clean data to compare it against.
>
> Convert your observations to RINEX format, open them with a text processor and check your P1 & P2 data yourself. In order for OPUS-RS to use short time files to give you better precision than longer time OPUS-S files that extra data is required. It if it is not there and good you will eventually get back a report to that effect.
>
> Lastly I recall a recent NANU that software was going to be updated. That usually happens on weekends, so the queue may be open but only storing all submissions until the processing computers are reopened. In order to keep yourself aware of such situations you should sign up with the US Coast Guard to receive daily GPS updates and NANUs. Being in responsible charge means knowing everything that affects your work.
>
> Paul in PA

Paul,

I did post process it myself before I posted this, no problem. I didn't want to wait any longer. I just wanted to see if anyone else was experiencing the same problem, since I don't submit to OPUS-RS very often, this being the second time. I also wanted to see what OPUS came up with compared to my solution.

Yes, Clean Data

I am not sure of the date of your observation, but I downloaded 1 hour from TXKA for yesterday and I note this. The data appeared to be all there but the C1 varied from the P2 by an order of 6 meters across the range of satellites. For those unfamiliar with C1/P1 and P2 data it is the calculated range in meters from the antenna to each satellite. 20,000,000 meters for a satellite directly overhead to 26,000,000 meters for one low on the horizon. That high a difference indicates a significant ionospheric delay. What was the sky like yesterday? I also noticed some L1 only data, which if significant causes OPUS-RS to reject the observation. Generally in clean data for OPUS all L1 only observations should be deleted. However that L1 data may be perfectly acceptable to your own post processing software.

Before OPUS-RS processes your site observation it looks for enough CORS with clean data within a certain range of your reported raw position. It calculates an atmospheric correction value for your position that it uses to quickly resolve your position. When I did "rsgps" calculations on my home computer I could see that sometimes every ambiguity could be resolved in the first 3 epochs. However if your observation data reports an incorrect raw position (which happens if you start storing data too soon after a cold start up) OPUS-RS could be looking at CORS sites far removed from where it should. Sometimes you will still get a position that is reported as outside the polygon. If that is the case you can insert correct XYZ coordinates in your RINEX and resubmit. OPUS-RS will select better CORS and you will generally get a more precise position.

OPUS-S are long range positions that can be very independant of the CORS geometry. OPUS-RS relies on good CORS geometry to give you a better solution with less
data. With the number of CORS in Texas you are in an ideal OPUS-RS environment.

Paul in PA

Yes, Clean Data

Lets be clear here, OPUS will not hold your file in a queue until "clean data" is available. It will simply shoot you back an email telling you not enough stations have data available to compute you a position.