OPUS Solutions with Emlid Reach RS2 Base Station

The ROCK R1A Survey package includes the Emlid Reach RS2 GNSS receiver as its base station. From time to time you may need to get an OPUS solution using the logged RINEX data on the device. OPUS can sometimes have trouble with the Emlid Reach RS2 data. Below is a solution that has worked for me:

  1. Download RTKLIB from Emlid (or the open source version)

  2. Open RTKCONV

  3. Select the RINEX file you downloaded from your EMLID Reach RS2
    Select to output as RINEX with an interval of 1s
    Select the output directory and name the new obs

  4. Click Options…
    Set the following options and select ‘OK’

  5. Click Convert

Upload this data to OPUS and be sure to select the EML_REACH_RS2 antenna.

Other problems encountered:

  1. From time to time I get an error:

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.
9011
Blockquote

To fix this, cut some observations off of the beginning and end of the file:

Hey Alex, would it be prudent to just set the Rinex 3 format as Rinex 2.1 in Reachview 3? Have you tried that and if so, did it resolve with OPUS?

Hey Eric,

Yes, I have tried logging directly as RINEX 2.1. I’ve had similar results with Opus regarding the interval and the size of the file logged.

Has there been a solution to this? Seems daft we can’t get a proper setup on the Reach to process though OPUS. I’ve been working on different combinations and can’t seem to get one through. The odd thing is the errors I’m getting are as if there isn’t enough elapsed time from capture to processing, but it’s been past midnight. I know it used to be 24 hours before processing through OPUS, but I thought they had switched it to once it’s past midnight you can submit. Is the 24 hour rule still the way?

@AreDub this is what OPUS says:

Wait a day before submitting your file: OPUS will use the best CORS and orbits available at the time you upload your data. While most CORS are archived within 30-minutes past the hour, some aren’t available until the next day. If you process your data in less than 24 hours after collection, OPUS will use Ultra-Rapid orbits. Rapid orbits, available at 17:00 UTC the next day, will offer a slight improvement in your accuracy. Final orbits, available weeks later, offer only slight benefit to solutions in areas with usable CORS nearby.

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

@Alex Still getting the same return. Data collection was completed around 10:50PM Wednesday night. OPUS is still aborting as of this morning when I try. Weird thing, I ran one last night for a couple of hours (No changes in base station settings) and OPUS now says it has a 20 second collection rate. Very weird, as it’s still set to 1 second.

@AreDub OPUS can be challenging at times. Are you using the RTKCONV steps from above ^?

@alex I shouldn’t have to according to the settings that Emlid has provided on their site. The first file I have collected is “working” according to the errors I’m receiving from OPUS, it’s just too soon for data for some reason. For the second file to have a 20 second collection rate is very weird. I’ve had issues in the past with large files which I’ve decimated in TEQC, but nothing like this.

I’ve ran the most recent 2 hour session through RTKCONV but no file is generated. It appears to be working, but no file is kicked out.

Ah Yes @AreDub we 100% agree, we should not have too. But after seeing users of EMLID struggle through countless OPUS posts on EMLIDs own forum, we dove down and found a reliable way to make the RS2 work for OPUS. We hope emlid can see this and make changes to the firmware to assure this works out of the box, but this has not been our experience.

The above workflow works and is usable. Thanks @Alex :slight_smile:

1 Like