We have released Reach Firmware 28 update—this is a stable version available for all devices. Check out RINEX presets for OPUS and popular PPP (Precise Point Positioning) services, advanced raw data logging, and other valuable improvements.
Seamless Compatibility with OPUS or PPP Services
Ready-to-use presets ease your work with OPUS or popular PPP services: AUSPOS, IBGE, CSRS —you can learn more about PPP in our Docs. To record data for a particular PPP service, open ReachView 3 and go to the Logging screen. Choose a preset, and the app will adjust the logs for the required services.
Note that you can process logs from single-band Reach RS+ or Reach M+ receivers only using IBGE and CSRS services. For more details, you can check the step-by-step guide on recording logs for PPP in our Docs section.
If you don’t need presets for PPP services, you can still configure RINEX logging manually—choose the Custom label or use the default setup in the Raw data settings.
Advanced Logging Setup
We have also enhanced the logging configuration. Now you can enable or disable recording the backup UBX log when logging to RINEX.
Among other things, with the latest update, we have delivered the following improvements:
Added the ability to downgrade from Beta to the latest stable release without reflashing—e.g., if you try the next Beta release of Reach Firmware, you can switch back to the Reach Firmware 28 stable version.
Made Reach M+/M2 visible in ReachView 3 without connecting the antenna and being in the hotspot mode.
Improved work with RTCM3 messages—antenna phase center offset is applied if corrections contain an RTCM3 antenna description message.
Configured the output of the last valid heading (COG) in NMEA VTG and RMC messages when there is no movement.
Complete List of Fixes and Improvements
Here is the complete list of changes we’ve implemented in this release.
Improvements
RINEX logging presets for OPUS and popular PPP services.
Enchanced antenna height settings in the raw RINEX log section.
Ability to roll back from Beta to the latest stable release without reflashing.
Improved work with RTCM3 messages—antenna phase center offset is applied if corrections contain an RTCM3 antenna description message.
Configured output of the last valid heading (COG) in NMEA VTG and RMC messages when there is no movement.
Reach M+/M2 visibility in ReachView3/Reach Panel without connecting the antenna and being in the hotspot mode.
Removed 230400 baud rate as an option for Serial input/output on Reach RS2/M2.
Improved procedure of the First time setup—no reboot is required after the setup is completed.
Miscellaneous stability improvements.
Fixes
Fixed issues with the interruption of downloading large log files.
Fixed issues with unsaved GSM upgrades option after reloading the Mobile Data settings page.
Fixed issues when Reach RS2 charge indication shows 99% while being fully charged.
Fixed rare cases when the receiver might be stuck in the scanning Wi-Fi state.
Fixed cases when Reach RS+ might overheat and turn off.
Fixed possible issues with shutting down and rebooting using the ReachView 3 app.
Fixed rare issues with the external modem on Reach Module and Reach RS.
I have updated my RS2 twice. Both times the process seems to have finished and after updating and restarting, it tells me again that version 28 is available and to update again
5hz means 5 observations per second. This option has been around for a while in GNSS Settings. It is possible to work with up to 10hz (10 observations per second) on Emlid receivers, both in RTK and PPK.
As Pedro said, the 5 Hz update rate gives you 5 observations per second.
But I think I know the issue you’re referring to: in the app, the number of recordings was indeed lower than it should have been. Reach Firmware was not responsible for that It’s working as fine as ever.
This was fixed with the latest update of ReachView 3 6.12. So everything is okay with the update rate recording now!
To change the update rate, go to ReachView 3 -> Settings -> GNSS Settings. There you can change the update rate.
Please keep in mind that changing this number will affect the number of data the receiver is handling and recording to the raw data log if you started one.
Algo que sería bueno añadan, o tal vez yo no conozco como hacerlo.
es poder trabajar en PPK continuo, es decir poder tener un equipo como base y el otro como robert tomar punto PPK con datos como nombre de punto y poder indicarle el tiempo de toma de datos.
¿Esto sería posible?
Esto permitiría trabajar a mas distancia y sin estar pendiente de la llegada de correcciones. Luego se procesa.
Configured the output of the last valid heading (COG) in NMEA VTG and RMC messages when there is no movement.
Can I get some more details on this?
My wish list for this is that I would like my M2’s to remember the last known heading in the NMEA string, even after a power cycle.
I will be testing what it can do over the weekend.
I assume the last known heading will be populated in the VTG and RMC NMEA strings once a heading has been recorded. I am also guessing it will only update when a new heading event is generated.
If any one can help me with how this update change has been included, I would be glad to hear from you.
A bit about my application, I have installed Reach M2 onto some large blast hole drills. ATM we save the last known heading in our app as it is not known atm in the NMEA data until the drill moves forward after the system is powered. Why do we do this? When a drill is working, at times the drill needs to be shutdown for shift change and the like. When the drill shuts down, it can not be moved, so it heading it was on can not change until the drill is repowered next. Once they start up we don’t get a heading until the drill moves forward next and that could be a long time if it is in the middle of drilling a hole. Having the last heading in the VTG at all times will help me a lot as I will not have to save the last known heading in my external application.
Thank you for this new feature and great work improving all the time.
If there was any issue, you could probably just use the OPUS preset and tick the box to enable raw logging in .ubx too for your PPK. Then you can do both from the same observation withe the resulting two files.
Let me translate your reply so that everyone understands it. Mind you, I’m using Google Translate so please be aware that there may be something incorrect:
Something that would be good to add, or maybe I don’t know how to do it.
It is to be able to work in continuous PPK, that is to say, to be able to have one team as a base and the other as Robert to take PPK point with data as point name and to be able to indicate the data collection time.
This would be possible?
This would allow working at a greater distance and without being aware of the arrival of corrections. Then it is processed.
I think what you’re referring to is a Stop&Go process for the Emlid Studio. You record the logs on base and rover both, collect the points in RV3 and then process all of this data in Emlid Studio. Voila, your points are fully processed and you don’t need to manually cut the log.
Welcome to the community! I’ll answer your questions.
OPUS works with GPS constellation only. So it will reject the log with GPS and, for example, GLONASS data.
You can record a log with GPS data only and upload it straight to OPUS. You can record the full log with all GNSS constellations if you need it for the other application and then convert it to the log with GPS only. That’s the beauty of the feature: you can choose which one is more suitable for you.
Thanks for describing your workflow! You know, we’re always hungry for more details about the applications you use our receivers in
You’re correct in describing the main idea of the feature: the last valid heading stays in the messages until it gets replaced by the new valid heading. This is true even when the velocity is zero.
However, we don’t write this value to remember after the power-up. For that, I believe you will have to use the external ways, like specifically writing it down within the system for now.
Interestingly enough I have been uploading RINEX 3.03 observation files .21O to OPUS with all the constellations enabled and 95% of the time it works without converting at all.
It’s working as fine as ever.