Reach Firmware 28 Update Features Enhanced RINEX Logging

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 :see_no_evil: 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?

1 Like

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.

@sbm,

Right you are! We’re certainly on it :slight_smile:

A post was split to a new topic: RS2 reboots after the update

OPUS worked with version 27 and 27.1 and now with version 28 I get these types of errors without converting the file to RINEX 2.10 in RTK CONV and doing the same behavior as before.

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

It was working great, and now it’s broken again…

Hi Matt,

This is something we will need to investigate. We always double-check our firmware before making a release. In particular, we’ve been testing the logs in OPUS with good results. So if something is not working right for you here, we’ll need to take a closer look.

Can you please share your logs with me? I’ll check if I can see anything amiss in them.

I don’t believe there is anything amiss with the logs, it simply doesn’t work because it’s not an OPUS specific log (it’s custom). What I’m referring to is in version 27 the way we set up our logging for our LiDAR would also work without conversion for OPUS. Now with version 28 it is back to needing conversion to work. Once converted it works fine, it was certainly nice to be able to skip that step though with version 27 and 27.1

Hi Matt,

I get you. We’ve been adjusting the logging settings for the most comfortable use with OPUS specifically. There are a few reasons for that, one is that we don’t recommend using time-adjusted logs in any other application but with OPUS. It can lead to result inconsistency due to the nature of the adjustment.

However, I see how your workflow is affected at the moment. We’ll consult with the devs about it and whether we can suggest any alternative workflow for you. Still, there won’t be fast changes as we intend the presets workflow to be present for PPP’s sake.

Edit. Reworked the reply to be more specific.

Hello everyone! We’ve released Reach Firmware 28.2!

Here is the list of changes:

  • Updated the default port for the Local NTRIP caster to 2101 and the mountpoint name to REACH
  • Enhanced communication with ReachView 3 app when connecting Reach to another network
  • Improved LoRa module stability
  • Improved stability of Bluetooth connection
  • Fixed LED behavior on Reach M+/M2: a green LED becomes solid only when time sync is completed and the device is fully operational
15 Likes

Hi everybody! Today we’ve released Reach Firmware 28.3!

Here is the list of changes:

  • Overall performance improvements
  • Fixed some cases with sudden Reach RS2 reboots when working with SIM cards
  • Increased charge current when using USB-C ↔ USB-C charger on Reach RS2
15 Likes

That’s great news. One of our RS2 units would always reboot if the mobile signal was low, hopefully it will be sorted now.

Hi Rory,

Can you please contact us at support@emlid.com with this issue? We’d like to investigate it in more detail.

Hi there! There is the Reach Firmware 28.4 coming out with a few fixes:

  • Fixed Reach RS+/ Reach M+ representation as an audio Bluetooth device on some phones
  • Fixed some issues with shutdown and reboot from ReachView 3 app
  • Fixed some cases of Reach RS+ sudden shutdowns
  • Improved L2 signal stability on some Reach RS2 receivers
6 Likes

Hi Polina,

I sent the logs a while back but happy to export again. I have moved the sim to another RS2 which doesn’t have the issue. Unfortunately the sim lock came off the original base when removing it in the field and I couldn’t find it, any idea where I can get one?

Rory,

It’ll be great to test the unit on a new firmware version before exporting them. If you can use the SIM, that is :sweat_smile: I’m pretty sure you can get one of the covers from the closest electronic shop after checking it out with the closest dealer to you. As I know, it’s rather easy to insert the cover back in the slot.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.