Rapid Static error message, what does it mean?

You don't say where you are from, but it could be that you are in an area of the country that doesn't have enough CORS to support OPUS RS.

Give it a day and re-send it and it most likely will work.

I'm from Southside VA, Gretna more precisely

I would have guessed that you would be OK down there, but OPUS RS does require a minimum number of CORS surrounding the site within certain distances. I'd look at the layout of CORS around you and see what it looks like.

You can look at this map and see that there are some weak spots on Southside:

http://www.ngs.noaa.gov/OPUSI/Plots/Gmap/OPUSRS_sigmap.shtml

What It May Mean

Is you are not patient enough.

OPUS-RS provides very good solutions in limited time GPS observations. It does not guarantee fast solutions.

If you need solution results within hours after observations then you must take the time to do a 2 hour plus OPUS. OPUS can give you a usable position from almost any combination of 3 CORS, not necessarily close to you. Two hours is the minimum standard time to get enough L1/L2 observations to separately work out the atmospheric corrections at all 4 sites, the 3 CORS and your GPS.

OPUS-RS has a different methodology to resolve shorter times of observations. OPUS-RS requires CORS stations that are close to your GPS site and are also scattered around it, N, S, E & W such that it can calculate atmospheric corrections at each CORS and using that data to approximate the atmospheric conditions at your GPS site.
While you may submit only 15 minutes of data, OPUS-RS starts off with CORS data well before and ends well after your personal observation in order to establish the CORS atmospheric conditions. All selected CORS are then used in a solution from CORS to CORS. Atmospheric conditions move in a normal pattern, so with the scatter of atmospheric values an good approximation can be made for the Rover site. OPUS-RS uses the raw GPS position within your submitted RINEX file for that Rover site. Having then established an atmospheric correction, OPUS-RS then reprocesses all CORS along with your Rover data to resolve the Rover location.

Because of the double processing OPUS-RS uses more computer resources than OPUS and to eliminate wasting those resources on poor data OPUS-RS takes a look at your RINEX data prior to beginning the solution process. If the first few minutes are bad, OPUS-RS stops scanning your file and you get an error message. OPUS-RS is also looking at the CORS RINEX files. CORS data as submitted sometimes contains errors or data that does not meet standards and should be filtered out. That filtering does not always occur as some users might hope. Since the filtering also requires computer resources it is scheduled for off peak user hours. Assume for instance that it is scheduled after midnight EST after the OPUS queue is empty. That happens to be 5 hours after UTC midnight so it is a reasonable time to assume most CORS data has been submitted and minor transfer glitches resolved. Based on that an expectation of an OPUS-RS solution within same day is highly unreasonable.

In addition OPUS-RS requires more than just the L1/L2 data that OPUS uses. OPUS-RS also uses C1/P1 and C2/P2 observations. These observations are the ranging distances in meters from each satellite to the GPS antenna, and while GPS lock occurs based on the L1/L2 data, the ranging distances require longer observation times and calculations. Taking a look at your Rover RINEX file in a text editor and you can see these distance values in the 20 to 24,000,000 meter range. Before those numbers are resolved the RINEX file may contain no or garbage values. The individual satellite observations containing this garbage data should be removed. That is your job, not the NGS's. In addition by collecting data too soon after start several minutes of all satellites data may be garbage, in that case it is your job to trim those minutes from your file. While a CORS station is operating 24/7 at least twice each day each satellite appears low on the horizon, at 10° mask L1/L2 can be resolved but there is a tremendous amount of atmosphere for that signal to pass through. so at least twice each day every satellite starts off with some crummy C1/P1 & C2/P2 CORS observations. It is up to NGS to take care of that, among so may other things.

In addition many state networks pass through the states hands before going to NGS which presents the opportunity for delays and glitches.

Should you have only a 15 minute observation and the first 2 minutes are bad, do not hesitate to trim it and submit to OPUS-RS. The stated minimum goal is 15 minutes which is actually computed as O.01 days, 0.01*24*60 = 14.4 minutes or 14.5 minutes. The absolute cutoff however is 0.005 days or 7.5 minutes. I have submitted files that short on bad data days and gotten useable results.

So do not assume short observation time means a faster turnaround, quite the opposite. What OPUS-RS does is give you more observations in a day, or useable observations on those small short time on site jobs. The later is most of what I do.

Typically though I try to have at least one observation of OPUS length. It gives me that same day position to begin analyzing my project. On the second day I typically break that OPUS into 2 or 3 OPUS-RS files along with other OPUS-RS files for other position sand use that for my final coordinates.

Paul in PA

WAIT 24 HIOURS AND SUBMIT YOUR FILE AGAIN

TIME WILL SORT THIS OUT MOST LIKELY RESUBMIT IT again after 24 hours