Trimble Business Center — Have confidence in your data. Start free trial.

AI Assistant

Notifications

Clear all

OPUS-RS aborting

Summarize Topic

GNSS & Geodesy

Last Post by bm-nolan 2 years ago

5 Posts

4 Users

0 Reactions

1,704 Views

RSS

big-al

(@big-al)

Posts: 831

Free

Topic starter

Translate ▼

A little over a week ago (Saturday 11/16/24) I collected base station data with a Carlson BRx7 receiver at a point in an open area (good visibility of satellites). Downloaded the BIN file and used Hemisphere's RinexDesktop application to convert the BIN file to RINEX .24o file. I then submitted to NGS OPUS-RS for a base point solution.

I received in response an email "OPUS-RS aborting". The text of that email (below) provides a few clues. I did notice that the solution attempt only used about 60% of the available observations. What is the "network quality indicator" and what would be a good value vs. a bad value?

Sometimes, waiting seems to be the cure, and so I have now submitted five times over the last week, all with the following result.

Therefore, I went to the site again yesterday (Saturday 11/23/24) and collected another static file over the same base point. Only difference was the height to the ARP. Same process, i.e. BIN to RINEX, and it processed fine. Used about 92 percent of available observations.

I'm attaching both files for reference. I would appreciate any suggestions as to what may have gone wrong.

Thanks, Al

Saturday 11-16-24 Rinex file

Saturday 11-23-24 Rinex file

--------------------------------------------------------------------

FILE: 20241116_EGREMONT.24o OP1732502129891

RSGPS OUTPUT

VERSION= rsgps version 1.38 2017 05 26

Run Date and Time = 2024 11 24 21 36 2

Project Directory = /var/tmp/opus_local/RS273/24321/

Solution Mode = network

W-Ratio test indicates SUCCESS!

Observations Used/Available= 8120 13624

Network Quality Indicator= 23.66

RMS= 0.465

Posted : November 24, 2024 9:11 pm

tnygaard

(@tnygaard)

Posts: 24

Free

Translate ▼

Hi Al,

Couple things to consider:

Your vehicle being too close with flat surfaces at just the right angle etc could cause multipath
Had an issue years ago with a reference station in the wide open we installed - could not get data to process during morning hours. Ended up going to that site one morning and discovered a buzzard was on the dome with spread wings - other birds or a hawk are possible too
Potential radio interference near airports or military bases (just a possibility)

Best regards,

Terry

Posted : November 26, 2024 10:38 am

big-al

(@big-al)

Posts: 831

Free

Topic starter

Translate ▼

Terry,

Thanks for the response. I don't think there were any issues with multipath due to flat surfaces (buildings) or with radio interference due to airports or military bases. I hadn't considered the possibility of birds perching on top of the base antenna. I'm going to chalk this up to a bird for now. Again, thanks for the response.

Posted : December 3, 2024 12:36 pm

OleManRiver

(@olemanriver)

Posts: 2769

Member P&R, Founder

Translate ▼

I have had some issues at times. Send both files with a detailed email to the NGS email on the OPUS page. They usually like to get that info to see if it is something on their end or not. I had one site that gave me fits and after a month or so I sent all the files back to OPUS that had aborted and bam they all of a sudden worked.

Posted : December 3, 2024 12:55 pm

bm-nolan

(@bm-nolan)

Posts: 23

Free

Translate ▼

I have noticed with OPUS it sometimes fails on static files for no real reason, I suspect it is some limitation in their engine. If you have a file like this I would try uploading it to the Canadian NRCAN-PPP service. I often have files that won't process in OPUS will process through PPP. You won't have the right N/E as PPP only uses Canadian UTM zones. But the Latitude and Longitude can be converted to state planes.

Posted : December 12, 2024 2:16 pm