Recent issues with OPUS solution

Over the past week we have had almost no luck in getting OPUS to get a solution for our REACH RS2. We have been getting the “6034 ATTENTION!! The quality of the GPS data from the rover or nearby
6034 CORS sites was too noisy and below minimum standards” error. We have initially had the too few error and waited a couple days and then it changes to the noisy error. We updated the Reach RS to the latest firmware and took a 3 hr sample and now we are getting "1021 The year and day-of-year could not be determined from the submitted data set.
1021 The data set may be corrupt. "

We are logging the same as when it worked all the time over the past year. No changes. we take rinex into RTKCONV and only export GPS before uploading. Been doing this for over a year and 4 out of the last 5 projects over the past week have all failed.

Could it be a hardware problem?

Do you agree to share the UBX or the RINEX file here so we can have a look ?

Your L2 band observation seems to have some repetitive and systematic dips in SNR.

So does this point to a hardware issue? It’s barely a year old.

No, that is unlikely. Much more likely to be an environment issue.

Hi John,

Let me chime in into the thread.

I’ve checked your file, and the most possible reason for rejecting log is that time epochs are not adjusted. It looks as shown in the screenshot below:

OPUS requires the RINEX log with even time epochs. I see that there’s a second RINEX file “.obs” that was probably converted from UBX in RTKCONV. Do you have the original UBX log? If so, you can convert it in Emlid Studio with enabled Time rounding option as shown in the screenshot below:

It adjusts RINEX epochs on integer values.

On top of that, you can apply the time adjustment by default in the RINEX logging. For that, you need to update the receiver to the latest 30 Beta 3 firmware version. You can enable Beta updates in the Firmware updates tab.

As for L2 observations, I agree with @wizprod’s assumption. But please note that L2 observations have always lower SNR than L1 ones.

My process is to convert the RINEX in RTKCONV and that is to only remove non GPS observations as that is all OPUS supports I am told. I do not adjust the time, the time is 1s set on the reach device. Does that mean the reach device is not recording in 1s interval appropriately?

No, it doesn’t. Reach uses precise timescale without interpolation by default.

If so, you can avoid the conversion step. You can choose OPUS preset in the Logging tab.

It leaves only GPS satellites, records log with 30 seconds interval, and adjust time epochs. OPUS should accept such log smoothly.


My workflow is for lidar, so I need all the constellations for the PPK process, I only need OPUS to get a good base correction. That is why the RTKCONV to strip out just the GPS for OPUS.

Still not sure why if the reach is set to Rinex 3.03 at 1hz and I don’t touch the timing in the RTKCONV process when the time is not synched.

I’ve tried converting the name.##O file from the Emlid to RINEX using Emlid Studio. After setting the time interval to integers, I still get decimals in my data. I’m not sure if there is an issue there or if it’s me.

I don’t know if it is absolutely needed or if you have organizational criteria to use OPUS, but you could go through NRCan’s PPP instead. You can give it a completely raw file with superfluous constellations and it will digest it correctly, decimating observations and stripping everything but GPS and GLONASS automatically.

If so, you can record the UBX log. It’s possible to convert it in Emlid Studio into two RINEX files: one for the OPUS with adjusted time, GPS only and 30 seconds interval, and the second one for LIDAR with all constellations.

It can be configured as you need. You can set logging interval to 1, 5, or 30 s, or leave it as in the GNSS settings (full rate).

You can use Emlid Studio for conversion and time adjustment. RTKCONV doesn’t have this option as a simple tick mark, it requires -TADJ=0.1 option in Receiver Options field:

It also won’t work while converting from RINEX to RINEX, it works only when you convert from UBX to RINEX.

1 Like

can it do nad83 - navd88? I don’t see that vertical datum as an option?

RIght, I didn’t think about that. No it doesn’t. It will do NATRF2022 when the US adopts it though.

It sounds like it may as well be called NATRF2026, in the US