When trying to process a RINEX file from the Reach RS+ to OPUS I am getting the following message. Anyone else experiencing this? I was expecting the .23O file from the receiver to be a standard RINEX? For the record I also put it into Emlid Studio and converted it to RINEX, still didn’t take.
PROBLEM: OPUS doesn39t recognize the internal format of your data file reac1234.00o as RINEX, or as any format it could translate to RINEX.WHAT TO DO: translate your data file to RINEX yourself before uploading. Ask your receiver manufacturer for format conversion software, usually available for free.
That is what I suspected also but OPUS has the RS+ Antenna selection listed as “INTEGRATED GPS/QZSS L1C/A, L2C”
I have OPUS accepting my files now but it’s saying that they no longer accept acquisitions less than two hours. This was a six hour acquisition. The only thing I can think of is it spanned a day.
2.12 OBSERVATION DATA M (MIXED) RINEX VERSION / TYPE
ES 1.4 20230127 223420 UTC PGM / RUN BY / DATE
input_format: RINEX, option: -TADJ=0.1 COMMENT
MARKER NAME
MARKER NUMBER
OBSERVER / AGENCY
EMLID REACH RS+ REC # / TYPE / VERS
ANT # / TYPE
1307207.4517 -4708550.8015 4085225.3864 APPROX POSITION XYZ
0.6619 0.0000 0.0000 ANTENNA: DELTA H/E/N
1 1 WAVELENGTH FACT L1/2
4 CA LA DA SA # / TYPES OF OBSERV
30.000 INTERVAL
2023 1 26 22 9 30.0020000 GPS TIME OF FIRST OBS
2023 1 27 4 28 0.0030000 GPS TIME OF LAST OBS
END OF HEADER
I get that, read it also but OPUS is taking my file. It’s hung up on not being a two hour acquisition or longer. If you look at the start of acquisition it’s just a few minutes shy of changing days, the time between observations is definitely 6+ hours.
9999 Error: Datasets less than two hours in duration no longer accepted to OPUS-S.
9999
9999 Your data file appears to span less than 2 hours. OPUS guidelines require a
9999 minimum data span of 2 hours and strongly recommend 4 hours to achieve
9999 best accuracies. Datasets less than two hours in duration are no longer
9999 allowed in OPUS-S. Please re-submit your data to OPUS-RS.
9999 If your file is actually over 2 hours, check for formatting compliance
9999
Opus does indeed REQUIRE dual frequency data. The error messages from OPUS are infamously not descriptive. One web site (igage.com - several years back) described the OPUS error messages as being completely random in nature. A problem comes up, just randomly pick one of a dozen possibilities and report it. Doesn’t matter what the real problem is. That’s pretty much what happens. You can not rely on a error message from OPUS to be realistic.
Rest assured though that PAGES (the underlying OPUS software) can NOT process single frequency data. Yes there are single frequency antenna models which can be selected like say the NovAtel 501, but OPUS does REQUIRE dual frequency GPS data. Without it you will get a random error message.
It uses single or dual-frequency GPS and GLONASS data for solution computation and supports both Static and Kinematic modes. Maybe it will work for you.
Thanks for the suggestions, I did use the CSRS system but the accuracy was not very good.
I have settled into a solution that meets my needs with the equipment I currently have. I decided to obtain my control points using the RS+ by correcting them against a local NTRIP node in real time in the field using a hotspot connection over the internet. RTK this way is far easier than PPK in my opinion and provides cm level accuracy I am looking for. This solution should work until I research and purchase a more suitable base for my application and just delegate the RS+ as a rover. I’m having a bit of buyer’s remorse. I also purchased the necessary components to setup my own NTRIP node that I will publish to the RTK2go caster. Being in New Jersey where everything comes at a cost, all the transmitters within 70 km of the border including ones in NY, PA, and DE are run by a private company that charges for the service and is far too expensive for smaller startup operations like ours. I have tested the RS+ with NTRIP corrections using RTK2go by finding government supported known markers and measuring them with the RS+. I was able to achieve cm accuracy.
I did use the CSRS system but the accuracy was not very good
CSRS-PPP indeed provides only about 30 cm accuracy for single-band receivers. So, using NTRIP corrections is a good solution in case you have only the rover unit.
This solution should work until I research and purchase a more suitable base for my application and just delegate the RS+ as a rover.
If you plan to use a multi-band base, you’ll be able to find its accurate position with PPP or OPUS. And you can use our Reach RS2+ bases with Reach RS+ rovers. But it doesn’t give the benefits of a multi-band setup since Reach RS+ uses L1 corrections only. So if you’d like to work on longer baselines or near obstacles like trees or buildings, it’s better to use a couple of multi-band receivers.
Well that’s not good news, I guess I am stuck using NTRIP for everything, unless of course I use a RS2 as a rover collecting raw data and submitting it for PPK corrections. Which leaves me with a useless RS+. One could argue to use a RS2 as a base connected to a NTRIP node, then use the RS2 as the NTRIP caster for the RS+ surveying points. But is there any value to that? Does it make a difference if I have an on-site base correcting using NTRIP and use a rover with the RS2 as a caster, or just use the RS+ connecting directly to the NTRIP node? Maybe sell the RS+ and get a dual band GNSS system, which is probably what I should have done in the first place. I’m sorry to say I have gone from buyer’s remorse to total dissatisfaction with the RS+, but I have myself to blame. Emlid’s sales pitch for the RS+ is very good.
I just sent a file in today to OPUS and was rejected because they say ‘data was collected at 60 second intervals’ which is not supported. I powered up the RS2 to check my setting and they were set to record at 5 sec. intervals. In fact, there is no 60 sec. rate available on the app, 30 sec. being the highest.
Two weeks before they kicked it back because the unit was either ‘in RTK mode or there was too much noise’ The RTK issue I can definitely rule out, the ‘noise’ issue, not so much
You’re welcome Beartow, I hope it helps. When I was attaching it to the message, a warning came up that another member (Tracy.Love) had posted it earlier in Feb. 2020. But I went ahead and posted it anyways, thinking it might be of help to someone. I just ran across it on Mark’s website recently, cause I was making a purchase on there.
I’m not sure why I would bother with OPUS. in the past several days I setup my own NTRIP node with a dual band antenna, running uBlox. I did a test run on a spot that was previously tested and known to be accurate. I acquired data for 14 hours, converted it to RINEX and uploaded it to both the Canadian system and OPUS. OPUS failed with four different error messages. I finally got OPUS to accept the file only to receive a message stating:
9005 ERROR! OPUS terminated in one of the processing modules.
9005 The dataset submitted to OPUS cannot be processed. The file
9005 contains data that is very noisy and probably has many data gaps.
9005
The file I submitted to CSRS came back in about 10 minutes with a full report and was able to resolve the location within +/- .009 and .006 m (Latitude and Longitude) and +/- 3.23 cm on elevation although I believe that is because I was unable to figure out how to set the antenna calibration.
Checking CSRS’s results with my previous known result for the same mark shows nearly a perfect match.
Trying to use OPUS amounts to about 15 hours of my life I will never get back. I will stick to CSRS.
OPUS PAGES is a good processor when no issues occur, however clean data is what it expects. It’s only good for dual freq receiver’s.
You have to consider the purpose of NGS, to maintain the National Spatial Reference System (NSRS). Thus every thing they do, perform and the development of measurement techniques, is as close to being perfect as possible. They developed OPUS to ensure the user has as perfect a geodetic position as possible, if using their instructions. They’ve had over 125 years experience in development of the NSRS and advise land surveyors in measurement techniques, whether using GNSS or measuring a calibration baseline using terrestrial techniques. They are experts in the technology of measurement, no one comes close.
That’s why OPUS expects good clean data, not noisy data. It’s as perfect a processor as can get, although I will disagree with the statement.
Buy yourself a good post processing software, you’ll learn a lot why OPUS is sooo picky. It’ll help you to understand the processing principal for GNSS data reduction.
I guess you didn’t read my post completely. I did buy an excellent antenna and receiver. The data isn’t noisy, and I do have good PPS. And I do understand the processing principal for GNSS data reduction. The data was collected over a L1/L2 band antenna and an excellent receiver. It was acquired for more than 12 hours and was very stable and clean. I had typically 30 satellites throughout the process. There is nothing wrong with the data. Thank you for the lecture. And really, 125 years of experience? I had no idea that GNSS was available back in the day. OPUS is a poorly maintained government process which has significant problems. Not that I want to, but I will stick to the Canadians.
I was just explaining why OPUS is so picky. NGS did not have GNSS back then .
You need to read the history of the Coast &Geodetic Survey (NGS)
If OPUS is not excepting your data , there’s something wrong with your data. Do you have a clear view of the sky with no obstructions ? Are you sure you end the session at the point, i.e. did you shut the unit off there at the point ? There’s a number of things that could go wrong.
Did you look at the surrounding CORS data to see if their data is okay ? OPUS is notorious for pulling the closet data from a station where there may be only 10 minutes of data.
