According to latest doc, OPUS should support RINEX 3: https://geodesy.noaa.gov/OPUS/about.jsp
Any update on the underlying issues with the RINEX 3.03 files exported from RS2 for OPUS? I encountered same 1020 error (5 possible reasons) with 3.03, but successfully obtained solution after converting to 2.11.
Hi David,
We suggest recording RINEX 2.XX for working with OPUS in our guide. This way, it’s possible to get successful results consistently. There are no issues with it. So please keep the RINEX log on 2.XX versions for the OPUS processing for now.
Plans of updating the guide since there are new options for the raw data in the most recent firmware push?
Thanks @polina.buriak. I understand the current workaround for OPUS, but since they now support RINEX 3, I was hoping there were plans to investigate the underlying issues with the RINEX 3.03 files created by ReachView. These work fine with CSRS-PPP, and it would be much simpler for users, like the students I teach, to export a single file rather than having to convert with RTKCONV for OPUS (and fiddling with settings). I would love to help diagnose issues with RS2 files and OPUS, but unfortunately, I don’t have time right now.
From Dec 2020 IGS RINEX charter (https://www.igs.org/wg/rinex/):
Given the needs of both the IGS and GNSS communities and the strengths of RINEX 3, all stations are encouraged to use RINEX 3 for their data submissions. RINEX 2.11 file submissions should be limited to cases of older equipment not supporting RINEX 3 file generation, to support specific application programs, and/or for parallel storage during a station’s transition phase.
Hi Seth,
We’re going to include new logging options to the OPUS guide. We’re working on the update!
Hi David,
Currently, the requirements for the RINEX 3.03 of the OPUS are not entirely clear. As we generate the standard RINEX file, it’s hard to understand what could be the issue here at the moment. However, we’ll take that into consideration and investigate this case. I can’t promise a fast process, though.
At the moment, you can use the 2.XX version of the OPUS as we’ve discussed. To minimize the number of required iterations, it’s possible to record one UBX file and then convert it to all required formats later.
Have you tried with non-QT edition of RTKconv? I also have problems with Ezsurv reading the Rinex’ from RTKconv-QT. However, when using the ones from github, I have no problems.
Hey guys,
I just wanted to follow up here. We were working with our version of RTKLib QT apps. We’ll investigate if there’s anything we can do with the RINEX 3.03 being accepted in OPUS.
However, for now, the workaround would be to use the RINEX 2.11 as suggested in our guide. Once there’s any update on this that we can share with you, I’ll reach out.
Thanks!
Hi everyone,
Here I am with the news! I’m excited about giving you the solution for this.
As you probably know, we’ve released the new Reach Firmware 27. There we’ve tweaked the logging settings and added the “This log is for OPUS” option. Now, if you use it, even your RINEX 3.03 log will be processed in the software 
Be careful, though. This option, useful as it is for the OPUS, can actually be a disservice when trying to process logs in Emlid Studio: it may provide unnecessary lagging. So keep it going only for actual OPUS processing.
I’m guessing the request to add this information to docs. So I’ll be proactive to tell you that we’re on it 
Hope you’ll find this option handy and practical! We’re open to your feedback on it, as always.
How much lagging would be expected from using this option? I guess we are only talking about under a second to fit it to the nearest integer?
David,
Hoped you’d plan to test it! We’re ready to hear your thoughts 
Christian,
I’ve formed my previous comment in a misleading way, sorry. This fitting happens on the unit, not in Emlid Studio. What the software struggles with is the ready logs. As Emlid Studio mostly works with the uneven epochs, it’s hard for it to handle the evened out well. So we suggest keeping the OPUS log for OPUS only.
May I ask why Emlid does not record the logs in even second intervals? All my other GPS brand receivers record in even rounded off second intervals. I have not had a problem in uploading to OPUS using RINEX files converted from Topcon, Leica, Trimble and Sokkia. Only with Emlid have I encountered uneven second intervals. So it leads to the question, is there something wrong with the boards of Emlid units that you try to adjust the converted RINEX files to interpolate it to even second intervals?
Hi Juan,
The way our devices record the raw data is within the industrial standards. You can enable the log at any time period so we can’t ensure it is started in an even second. That’s why our logs are not even on them as well. There are no issues behind it.
What you get is a precise log without an additional interpolation of the data. Still, it’s possible to do it if you have a need for it. This option is available in post-processing with RTKLib as well. We’ve described it in one of the posts, I’ll leave a link to it for a brief consultation.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
