Getting an OPUS solution with RINEX from Reach RS2

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

3 posts were split to a new topic: OPUS solution is lower by 134mm compared to known elevation

So if I understand you correctly, you were able to keep the GPS, GNSS, AND GALILEO selected but then using rtkconv you removed them to use with OPUS?

NGS OPUS works best when you can collect a static, RINEX 2.11 file (GPS and GLONASS only). A 15 or 30 second update rate. You must collect a 2 hour file for use with OPUS Static and at least 15 minutes if you are able to use Rapid-Static (OPUS-RS). There are constraints to using Rapid-Static (see NGS webpage for them) and there now is a map to see if you are likely to be able to use OPUS-RS.

1 Like

Did you wait for 48 hours before resubmitting file?

Yes, exactly.

BTW the other hardship is that you can’t specify lower than 1hz logging rate, which means that unless you decimate the data (I also ran into problems here) you can only submit about 6-8 hours of obs data to OPUS.

The reason for that is OPUS won’t accept files >100MB, and 1hz data longer than about 8 hours creates files >100MB.

Just FYI

2 posts were split to a new topic: RS2 OPUS processing issues

I’d like to formally request a 0.2Hz (5s) recording interval
15s interval would be better, but I will settle for 5s (0.2Hz) as well for static data.

I’m a little tired of decimating the data with Teqc or rtklib.
If I can simply log data at a 5s interval, it will cure a lot of my problems.

Thanks so much dev team - looking great so far

2 Likes

Hi @geohawk,

Thanks for your suggestion!

We’re working on adding this functionality in future releases of our app.

4 Likes

Thank you @liudmila.slepova !
Very much appreciate it.

1 Like

Any updates on adding this feature?

1 Like

Hi Seth,

It’s on our roadmap. However, I can’t give any ETAs for now. We’ll post an update once there’s news.

Has anyone found a consistent way to get an OPUS solution with the RS2 RINEX data?

I’ve had some success in the past with using gfzrnx to convert from RINEX 3.03 to 2.11 and use only GPS. But, there are many times where I just keep getting errors.

./gfzrnx_osx -finp Football\ field/raw_202005260133_RINEX-3_03/raw_202005260133.obs -fout Football\ field/NoMarker.20O -vo 2 -satsys G -f

Error I get:
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
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

Can anyone post the exact commands they use to convert their files?

Thank you!