I am very interested in this below
- 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.
You can find out more details about this workflow in our docs: Stop & Go with ReachView 3.
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.
We’ve just released Reach Firmware 28.1 which improves the stability of Bluetooth connectivity with some Android devices.
A post was split to a new topic: RS2 BT issue
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.
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.
This version(28.1) has not activated the UBX back up? parallel to rinex logs in Raw data
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.
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.
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.
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?