We are rolling out yet another update, and it is kind of huge. This is one of the biggest updates we’ve made to our navigation engine, RTKLIB, in terms of general performance improvements. This update focuses on two things. First is making solution more stable in an environment where the link is not entirely reliable(meaning LoRa and other radios). Second is restoring fixed solution after losing it in a bad, multipath-prone environment. This provided some amazing results in our tests, and should get your fix the “stuck in float” state several Reach users reported. Apart from that, we’ve fixed some small-time bugs, more details below:
Phase-bias is reset on large residuals, making going back to fixed mode much easier, eliminating solution drifting off
We can now use observations from different epochs, increasing solution reliability in case of correction link data loss
RCH-806 - Sometimes downloading logs failed until you perform a refresh
RCH-799 - Point view inside survey projects would not show big heights
RCH-671 - Reconnecting USB on Reach RS stops the data until new settings are applied
You can now enable more constellations while using the LoRa radios, with time to first fix significantly shortened. Different update rate on different messages doesn’t lead to erroneous behavior anymore.
We have found the following base message combination to work really well in our tests:
We are looking forward to your test results and feedback!
The problem reported by @Simon_Allen and @BenLewis has been fixed and the update shipped as v2.9.1. You can use the QZSS corrections again. Thanks for the immediate feedback and details!
We’ve released a new minor update, v2.9.2. This one includes several bugfixes and LoRa frequency band constraints for Australia.
RCH-747 Fixed NTRIP correction input screen crashing with several casters with unhealthy mountpoint info.
RCH-833 QZSS RTCM3 message rate will now mirror that of 1002 to avoid problems @BenLewis and @Simon_Allen have talked about in the comments to this post.
RCH-840 LoRa will now automatically adjust to local radio regulations. After getting its location, Reach will enforce a frequency band and adjust settings if needed. You can view the available frequencies in the configuration menu. We are starting off with Australia with more countries to come.
One more thing!
We’ve finally managed to publish our native app to the iOS App store
Just search the store for “ReachView” or click this link. Please enjoy!
ReachView v2.9.3 has been released. It fixes the bluetooth output getting overfilled with data in some configurations and app interface freezes when data from serial output was not being read.
We look forward to testing these out. Well done and as always, thank you for listening to the community. That is one thing that I hope never changes with Emlid. Your commitment to working with and listening to the people that use your devices is a business model that should be copied by others.
100% aligned with Luke. Your reactivity and the quality of your listening is amazing. And so are your products. The decision to buy your Reach is one of the few I do not regret in drone / mapping area. Thanks.
My understanding is that the data rate should be set as high as possible to maximize bandwidth. However, the longer the baseline length (distance between base and rover) the more problematic the connection will be. To improve the robustness of the connection over longer distances the data rate must be dropped. So there is a trade off between baseline length and data throughput.
I’m really impressed with how responsive Emlid is to customer feedback. I like the frequent updates. Please keep them coming. Having said that I have a problem with this latest update.
I upgraded to v2.9.0 three days ago. I’ve used the system every day since then and I’ve not been able to get a fix. For me, something in this latest release has broken.
Prior to this release I had been experimenting with the settings quite a bit. I got to the point where I was getting some pretty good results. Now with this latest update, in the same location, with my previous settings and with the new recommended settings, I can’t get a fix.
Here is a screenshot of what a typical location plot now looks like.
Funny I always think of it in reverse.
Set the air data rate as low as possible, to maximise the range. But my question was aimed at understanding the LORA intrinsics. If I go up one level. Say the RS reckons it can squeeze all my messages into a 4K rate if I go to 9K will I get a faster update rate? I ask this as my correction message age seems to vary from 1 to 4 secs.
So if there is more room does Lora error correct and effectively be more reliable than a slower data rate?
I am using two Reach RS units on a job site and am wondering whether to upgrade to v2.9.0 or to wait for an update given some of the initial feedback. I dont have the time right now to become a beta tester.
I am in the U.S. (California) and have had reliable fix solutions using GPS satellites only… I did have the problem of once a fix was lost a reboot was required to avoid a long wait for the fix to be re-established.
So two questions:
Is an update to 2.9.0 imminent or is it ready for production use.
In the US - does adding Glonass or SBAS improve the speed to achieve a fix solution and the stability of that solution in marginal satellite reception areas.
See my earlier post. Any Updates on the status of Reachview v2.9.0. I have seen a number of issues on the blog and am wondering whether to install it. Because I have 2.8.0 working OK right now and am on an active construction site - I cant afford the time to upgrade and then downgrade if their are new issues. Has anyone else tried it out yet?
Thanks Simon. The forum has been pretty quiet regarding v2.9.0 and I am not sure what Emlid is doing about the issues already reported by you and others. The announcement sounded very promising but I know software mods are risky in terms of unintended consequences.