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.

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.


@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

This worked for me! Great work!

1 Like

Any ideas? Tried this solution… Tried narrowing the time window, altering the time tolerance, RINEX version… ect… and it still ends in this


or this every time.
Screenshot 2021-05-30 223638

@anthonyhermanklj can you upload your RINEX file?

1 Like

Files Uploaded to RockCloud https://cloud.rockrobotic.com/project/1560

@anthonyhermanklj I can’t seem to get OPUS to come to a solution either. Could be an OPUS problem.

I was able to get a solution with https://process.gps-solutions.com/.


hm… might ie… :frowning:
Thank you for checking and finding a solution. Can you send me that full report?

That gps-solutions.com site is a great find!
not as user friendly as OPUS but wow what a nice result.


So i am getting the error message like above. Can you go into more detail on changing the start time? I collected data for three hours.

@Lgeren in rtkconv there is a section at the top that lets you specify the start and end time (cutting everything that is before/after.

I would move by 20 minutes from the beginning and end to begin with.

Otherwise we had good luck with gps-solutions.com as well. There are other precise positioning services that I’m taking a look at as well. OPUS can be tricky sometimes.


Anyone else getting errors on OPUS?

1020 OPUS aborted on the submitted data file for one or more of the following
1020 reasons. OPUS cannot process the data file.
1020 1. Collection interval of the data file was not one of the allowed rates.
1020 The intervals that are accepted are 1,2,3,5,10,15,30 seconds.
1020 2. The time of each epoch is offset from one of the above intervals. The
1020 seconds epoch field must coincide with one of the above rates.
1020 3. The data file may have been collected in kinematic mode. OPUS does not
1020 process kinematic data files.
1020 4. Note: OPUS processes data every 30 seconds, and 2+ hour files
1020 collected at the 1 second rate should be changed to 30 seconds.
1020 5. If your data were collected today or yesterday, we may not have
1020 sufficient CORS data - try resubmitting your file tomorrow.

Yes. This is a very typical and general OPUS error.

Did you try and follow the above steps?