Hi Matt,
Yep, OPUS has recently started working with RINEX 3.03. I think it was one of the most long-awaited features.
The legend says, OPUS indeed doesn’t reject the all-constellation logs 
Still, even if it accepts the log, it uses only GPS sats: that’s how it’s supposed to work.
So I’d still suggest disabling all other constellations if you’re planning to record logs for OPUS. This seems quicker.
Hi Everyone,
This version(28.1) has not activated the UBX back up? parallel to rinex logs in Raw data
Hi Bernardo,
The option is there! You just need to turn it on. Go to the settings of the Logging tab and choose Backup source data from RINEX. The UBX will be recorded alongside RINEX.
Hi Polina,
Thanks for description!
I understand this completely. However we have to utilize as many constellations as possible for our LiDAR PPK processing. It’s not the end of the world to do conversions and drop everything but the GPS to do OPUS. We do appreciate the time that the EMLID team has been putting into addressing these issues however and we are certainly looking forward to further refinement of the system.
Hi Matt,
I get you! The more options there are for your workflow, the easier it is to finish your work 
This is why you can go about recording logs for OPUS in any way you’d like: filter other constellations from the start or after the survey.
If you have any feature requests or suggestions for us, feel free to share them! Your feedback is what helps us to move forward.
Are you saying that you can add the other constellations in after you have already made a selection that only includes GPS?
Like you can do that in post?
You can do that by also logging raw ubx data at the same time. Then you have all constellations.
Hi Matt,
You can’t do that if you haven’t logged them from beginning, no. You can, however, log all of the constellations and then convert only the ones you need to the log for further use. This is the explanation I’ve been aiming at 
copy. That’s precisely what we do at the moment. It was nice to have the “This log is for OPUS” checkbox on the 27 firmwares because it made the 1 second collections stop on the 1.000000, 2.00000, 3.00000… Does that behavior carry forward on version 28 while using “Custom” with all constellations? Or is that reserved for only the OPUS option? As that would be unfortunate.
You can choose the logging interval for the Custom settings, too For OPUS log, it’s set to 30 s by default. It’s possible to choose from 1 s, 5 s, 30 s, and the full rate (same as in GNSS settings).
That’s great, but what I’m referring to is when it stops the selection. Prior to version 27 it would do it with some arbitrary number after the decimal 1.134511, 2.239822, … From my understanding that checkbox “this log is for OPUS” made that stop on the 1.0000, 2.0000, 3.0000
Unless I’m missing something.
My question was does that carry over to all collections or is that still ties to the “OPUS” selection in settings?
Yes, when you choose the specific logging interval for your log, the time’s automatically evened out. If you’re working with the full rate, we record the time by the default, without this.
So if you choose, for example, 1 s interval in your Custom settings, you will have logs with even second intervals.
Beautiful! Thanks for answering that. I am sure I could have also just looked at the data for myself, but I greatly appreciate you taking the time.
Matt,
You were too quick to thank me, it seems 
I’ve double-checked the info about logging settings, and looks like I’ve misled you. Sorry about it!
So the correct information is the following: the time is evened out for the OPUS log only. If you use the Custom option, the Logging Intervals just mean that the measurements will have the given interval between them. There won’t be an evened-out second.
Is there a specific workflow of yours that requires the adjusted logs, apart from OPUS? Our default logs are quite precise enough as they are not interpolated.
Our exact workflow utilizes the adjusted logs for all of our devices over 100 at this point all using the RS2 as their main PPK base station…
We use PPK from the RS2 with the satellites from our Rock Robotic R2A to get a solution. So that’s not in jeopardy either way, but when that same RINEX can and will often be used for services like OPUS that’s where we run into issues.
So what you’re telling me is that version 27 fixed this issue for us as I was able to submit RINEX files directly to OPUS from those versions. Now version 28 is going to negate that and we are back to having to convert and remove constellations to use it with OPUS.
Is it possible to have 2 logs created at the same time? 1 for the PPK solution and the other for OPUS?
Thanks for the updates. It looks like U-blox has just recently update their firmware for F9P with some interesting and useful improvements as well. Looks like it should help with fix confidence.
Matt,
I can see how your workflow is prolonged. There are certainly ways to ease the process. I can think of the following.
You can record the log at 1 Hz. In the Custom settings, you can set the Logging Interval the same as the GNSS settings. This log would be working just as fine for OPUS, according to our experience. Even if other constellations are recorded, OPUS can overlook them and just work with GPS.
Time adjustment is saved for OPUS specifically, there are no plans to extend it for all the logs. Originally, this function was introduced for OPUS only. This is made to ensure that you can have the full experience in PPK as time adjustment can exclude some data.
You can record only one log at a time. So it’s either the custom one or the one with the OPUS preset. Still, OPUS should work fine with the custom log on 1 Hz.
