Getting an OPUS solution with RINEX from Reach RS2

Has anyone try to get a OPUS solution using the .obs files from a RINEX 3.03 using the RS2?
Also, on OPUS you need to select a antenna name. What is the name for the RS2?
We are trying to get the right settings to PPK with eMotion and OPUS.

If anyone has a practical setting using PPK with the RS2 please PM me.

Thanks!

Hi @avelez,

We recommend using the following configurations to log RINEX data on Reach RS2 for OPUS:

  • In the RTK Settings tab, choose Static Positioning mode, enable GPS only and set up the update rate to 1 Hz
  • Go to Logging tab and select RINEX 2.10 raw data format
  • Enable raw data recording and log the data for more than 2,5 hours. According to OPUS, it’s better to use raw data logged for 4 hours at least

We’re in process of getting antenna calibration details, so please select the “NONE” option in the meantime. As for antenna height, please consider it as a pole height plus 134 mm.

4 Likes

Tatiana, Minimum of 2.5 hours is too long when a drone mission is only 15-20 minutes. Is 30 minute recording sufficient?

John,

2.5h is indeed long, but it’s the requirement of OPUS.

2 Likes

2.5 is not a OPUS requirement. there are two flavors of OPUS; rapid static and static. rapid static is for observations from 15min to 2 hours and static is for everything over 2 hours. i use a CHC/igage unit to do OPUS work and i always do more than 2 hours per control point but you can get CM grade results from rapid static. read the online docs at NGS to understand the difference. if you do more than 2 hours your probability of success goes up. look at the NGS site and check out the daily solution success rate…

image

5 Likes

Tatiana, Surprised to have received this “abort” message from OPUS. A RINEX 2.10 file was uploaded, static mode, w/1 Hz sampling, & NONE for antenna. Corrections Input was from California Spatial Resource Center CGPS: P276
Site Name: LDoradoHilCN2005. Know why I received this error and, how can it be overcome? Thanks.
FILE: raw_202001202029.obs OP1579634711563

1009 WARNING! No antenna type was selected. No antenna offsets or
1009 pattern will be applied. Coordinates with reduced accuracy
1009 will be returned for the antenna phase center.
1009
6029 After the single baseline analysis, fewer than 3 useable
6029 reference stations remain. Aborting.
6029

what do you mean by this?

The CSRS is responsible for maintaining the state’s Real Time Network. P276 is the caster closest to a project I’m working on. http://sopac-csrc.ucsd.edu/index.php/csrc/

maybe im just not getting it here. the rinex file you need to send to OPUS is your logged data from your rover (for a single point). from what you are saying it makes me think you are sending the correction file from p267.

(caveat: i have no direct experience with gettting the RS2 to work with OPUS)

No, I’m sending the rover’s file.

have you checked if your rinex file has even second intervals? time logged does not have decimal part? there was a thread about this uneven second logging time and its solution was also discussed there.

Hi John,

Could you share the RINEX file you tried with OPUS?

Hi Juan,

OPUS works fine with the time specified with a decimal part, we’ve checked that.

Hi Tatiana, the file I uploaded to OPUS is the raw_202001202029.obs in raw_202001202029_RINEX-2_10.zip. Looking forward to your assessment.
base_202001202029_RTCM3.zip (1.2 MB) raw_202001202029_RINEX-2_10.zip (4.9 MB) raw_202001202029_ubx.zip (6.4 MB) solution_202001202029_XYZ.zip (64.3 KB) PPK Test 4-CSV.zip (1.9 KB)

Am wondering if this may be the problem…I captured the home point location of the drone and two other checkpoints in one logging session. OPUS though says that the antenna must remain unmoved throughout the observation session. Is it possible to edit he .obs file to keep the first position and delete the other two positions for resending up to OPUS? Still looking forward to your assessment of the data I posted. :slight_smile:

With help from a Facebook colleague, I was able to acquire a successful OPUS report. He stripped out readings from the 2nd & 3rd checkpoints in the .obs file. Now learned that the session for use with the PPK receiver on the sUAS must be just for the home point, and not include other checkpoints. Issue resolved.

1 Like

Hi @jmonaco,

Good to know you’ve figured it out! :slightly_smiling_face:

Just want to point out that you can cut the log by time in the RTKConv tool while converting UBX data to RINEX:

4 Likes

4 posts were split to a new topic: Using RINEX files from RS2 for PPP in OPUS

UPDATE
I fiddled with the settings, and was able to obtain a valid OPUS solution with the following workflow:

RTK Settings

  1. Positioning mode: Static
  2. GNSS Select: GPS only, (deselect everything else)
  3. Update Rate: 1 Hz

Logging

  1. Raw data: Rinex 2.10
  2. Raw data: ON

These settings returned a viable solution from OPUS.
I’d much rather collect GPS, GLO and GAL simultaneously.

Hi Tatiana,
I’ve also encountered an error with OPUS for some static data.
I configured the system according to your recommendations above (1s, static, logging enable) and when I uploaded 6.5h of data, OPUS rejected it for filesize issues (the rinex file is 128MB and OPUS aborts on files >100MB)
So, I ran the rinex through rtklib’s conversion tool and reduced the observation interval to 15s.
UPDATE by stripping GNSS & GALILEO using rtkconv, a 1Hz observation rate worked (Rinex 2.11)
This was met with an error (see below)

I tried using the German GFZRNX and reduced the filesize but received the same error
I tried using TEQC by both narrowing the window (to reduce file size) and decimating the data to 15s using -O.dec 15 which was met with the same OPUS error (aborting)

any ideas what might be wrong here?
Thanks for any/all help

-----OPUS abort message below-----

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.
1020

Hi John,

Do you have to EMLID RS2 units? (Base-rover).

Or one rover connecting to the CRTN?

Jose