RS2 OPUS Failure (The data was either very noisy/ kinematic mode)

I tried to process a two hours RS2 observation data and processed it on OPUS.
After several trial, I manage to solve other error but I could not solve this last error:

2005 NOTE: The IGS precise and IGS rapid orbits were not available
2005 at processing time. The IGS ultra-rapid orbit was/will be used to
2005 process the data.
2005
9011 OPUS could not process the data file that was submitted. The data was
9011 either very noisy or it was collected in kinematic mode.Or OPUS software
9011 has issue during this time, please reupload later.

Some suggest to trim the beginning and the end of the data or make the data even time, but none of them work

Do you have suggestion for this error?
I put the link of my .ubx data as attached

UBX sample data

Highly appreciate your time

My first reflex would be to try with another service like NRCAN’s PPP. It will only take a few minutes and if the results come back clean, then you know it’s an issue with OPUS.

Usually code 9011 suggest as stated. If you started logging not having a good position to start with, this usually crops up. When I’m occupying a static point, I always wait at least 1 minute so the unit gets a stable position before I start logging.

Also, if the point is in a high multi-path area, this error code will appear. And as the error code states, the unit might have been either moved or was moving.

1 Like

OPUS error messages aren’t very exact, but your data may not be appropriate for OPUS. For sure you haven’t waited long enough.

You haven’t waited for even the rapid orbits to become available. That’s somewhat important for long baseline processing, but even more important this often means base station data isn’t available. The nearest IGS station is in Bahrain and that data - for your file - isn’t available yet. I don’t know how far OPUS will currently go for base station data, but it looks pretty sparse for you. Even if it will look far enough a 2 hour file really isn’t enough data for it considering that you only have L2C data. Only 9 of the 13 GPS sats you tracked have dual frequency data. OPUS expects them all to have it. It can still work on L2C only files, but expecting it to do so with a minimum observation time file in an area without nearby base stations is probably asking too much.

A service like NRCAN’s PPP is the better choice as it doesn’t have baseline constraints and it can also use GLONASS L1/L2 data. Again patience will improve your accuracy by waiting for at least the rapid orbits (a day or two) if not the final orbits (sometimes up to 3 weeks).

2 Likes

Could OPUS be confused by the 5 hz collection time ? Does it need to be slower?

OPUS automatically decimates the data to 30 sec intervals

https://geodesy.noaa.gov/OPUS/about.jsp

1 Like

I tried with another data which is 8 hours observation with 1hz sample data, I still get the same error.

I also suspect that because my data was taken far away from available CORS data (Abu Dhabi), it might cause an issue.

For now, I am trying to wait until the rapid ephemeris is available and re-launch the processing.

I attached my observation data as follow,
8hr Sample data

Thanks for the feedback everyone,

OPUS is for CONUS only and some outlying areas as Alaska, Puerto Rico, Hawaii and other USA territories.

You can use any PPP service as the derived position of your base or rover is from the clocks and ephemerides of the satellites. You’ll need a long observation time such as 4+ hours minimum for good accuracy

3 Likes

Hi @pramujati,

You are right, processing data collected far from CORS stations in OPUS may cause issues. As Bryan pointed out, OPUS is designed for usage on the territory of the United States.

I’ve checked that your 8 hours log can be processed fine in the NRCAN CSRS-PPP service. If it’s appropriate for you, you can use it for your work.

@kseniia.suzdaltseva Thanks for the feedback,

After 4 days, I tried to re-launch the processing in OPUS and able to get rid of the 2005 error which is the availability of precise ephemeris. However the 9001 error is still there ( The data was either very noisy or it was collected in kinematic mode).

Its true that my station is located far away from available CORS, but strangely I was able to process my static observation taken from different receiver (Septentrio) in OPUS and received a result.
So distance from CORS doesn’t seems the right cause for me, because one receiver worked while RS2 data not. I am still figuring why data captured from RS2 couldn’t be process.

any thought?

What’s your location ? I’d bet maybe you are in Mexico ? OPUS may work there

Hi @pramujati,

OPUS indeed may calculate a solution for a position far away from CORS. However, most likely, you will get quite a low level of precision in this case.

Please note that OPUS is not a PPP service. PPP services apply ephemerides from IGS, while OPUS uses software that computes coordinates using the NOAA CORS Network. That’s why the same PPP service can be used in different countries, while OPUS is designed for the USA only.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.