High peak-to-peak values in OPUS solution for RS2 base

[diehl.theo (Theo Diehl)]

Hi folks, I completed my first RS2 surveying run last week and just got around to uploading my raw data to OPUS for an accurate base station position. Everything is looking good on my report except my peak-to-peak values. Any ideas for what could cause these values, as I understand it these could be indicating error in my solution. Thanks!

[svetlana.nikolenko]

Hi Theo,

Is there any chance you can share the log with us? It’s hard to say something surely without checking the data quality.

If it contains sensitive info, please send it to support@emlid.com.

[EBE111057 (Bryan Enfinger)]

Hi Theo ! Your report doesn’t look good. This usually indicates a lot of things. See

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

If you select the extended report before submitting to PP, this will give the baseline residuals to your point. I always select this extended report as it gives additional information to any problems. If you have large errors in the baselines, it could be your site conditions or issues at the CORS themselves.

I’d try resubmitting with the extended report.

[diehl.theo (Theo Diehl)]

Hi Svetlana,

Here is a link to my logs:

https://drive.google.com/drive/folders/1gTeFXqt0xSqoA3r0TC5oQNHC_MlkE9bX?usp=sharing

One folder contains the raw RINEX logs collected from the base station over a period of ~6 hrs. I turned on all GNSS constellations in the field so I could collect RTK fixed points with a LoRa-connected rover, and filtered out everything but GPS observations using RTKLIB before uploading to OPUS. The other folder contains my .obs file that I submitted to OPUS.

Thanks for your help.

[diehl.theo (Theo Diehl)]

Thanks for the advice. I ran the extended report and think I may have found the culprit. One of the CORS stations was throwing off the average, I set a new OPUS solution to exclude that CORS station and came to a much lower peak-to-peak:

Positioning from original OPUS solution

Positioning from new OPUS solution

Less than ideal fixed ambiguities but my peak-to-peak is significantly reduced. I notice that my Y peak-to-peak is still a bit high (.185m), as well as ellipsoid and orthometric heights. Is this acceptable or does something still appear off?

[EBE111057 (Bryan Enfinger)]

Yep, they’re still not ideal but considerably better. When you select another CORS for PP, be careful of the baseline length. Try and keep lengths below 60km, less than 50km would be better. Longer baseline lengths = longer observation times. You can go here and pick any CORS in your area of interest and view the station logs

https://www.ngs.noaa.gov/CORS/

Looking at the station logs gives a good indicator of the quality of the station. Many times station log quality is the reason for typical OPUS failures. This is the first thing I look at if the data PP failure occurs.

[EBE111057 (Bryan Enfinger)]

Here’s a link of the time series of logging for CORS “COLA” . Just pick the time series logs. Short and long time series are available. Any peaks in the observation data for the corresponding time of the CORS will increase the possibility of OPUS failures. The peaks will indicate times of bad data collection due to atmospheric or cycle slips issues that may have occurred for whatever reason.

https://www.ngs.noaa.gov/cgi-cors/corsage_2.prl?site=Cola&dump_app_trace=false&db_debug=false

[kseniia.suzdaltseva]

Hi Theo,

Glad to hear that Bryan’s suggestions helped you to obtain better results!

As I see from the report, OPUS used a rapid ephemeris for processing. I’d recommend you process the data once again with a precise ephemeris and check if you can get better precision. The precise ephemeris should be available within a couple of weeks from the day of the survey.

Also, I’ve noticed that the SNR level drops periodically at the L2 frequency:

Usually, it happens if the satellite signals are affected by RF noise. I’d suggest checking if there are some electronics or power lines nearby that can produce it and keep the device far from them, if possible.

[diehl.theo (Theo Diehl)]

Hi Kseniia,

Thanks very much for the response. Can you explain how I would apply precise ephemeris to the OPUS solution? I’m familiar with setting up ephemeris clock files in RTKPOST, but I’m not sure how to add that to an .obs file submitted to OPUS.

Regarding the noise in the signals, I’m thinking I may know why that is happening, but would like to hear your thoughts: I’m using a DJI Phantom 4 RTK drone with the DRTK-2 base station, which was set up about 50 feet away from the RS2 base station. This was my first run using all this equipment so excuse me if this seems like something that I obviously shouldn’t do. Is it possible that this would be producing some interference?

[kseniia.suzdaltseva]

Can you explain how I would apply precise ephemeris to the OPUS solution?

The precise ephemeris will be applied by OPUS automatically once it is available.

Is it possible that this would be producing some interference?

The drone motors and other electronics indeed produce RF noise, but it shouldn’t significantly influence Reach RS2 if it is located at a 50 feet distance from the drone.

For now, it’s hard to say if the SNR drops at L2 that I see in the log can lead to the higher peak-to-peak values in the OPUS solution. That’s why I’d suggest checking if you can get better accuracy with precise ephemeris first. If the issue persists when using nearby CORS and precise ephemeris, we’ll need to look into your setup and environmental conditions to understand why it might happen.