ReachView v2.9.3 - RTK performance boost

Hey guys,

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

Bug fixes

  • 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:

  • 1 Hz 1002(GPS), 0.5 Hz 1010(GLONASS), 0.5 Hz 1097(Galileo), 0.1 Hz 1006(base position)

We are looking forward to your test results and feedback!

Best regards,
Emlid team

Update 04.10.2017

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!

Update 20.10.2017

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! :slight_smile:

We’ve finally managed to publish our native app to the iOS App store :tada:

Just search the store for “ReachView” or click this link. Please enjoy!

Update 01.11.2017

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.


Hear! Hear!

drooly Can’t wait to try it out! The fleet has been assembled for update:


I even got a personal email saying the update addressed a bug I found. Love your service. And looking forward to learning how to make better use of the equipment as I am just new still.

Keep up the good work.


A post was split to a new topic: Reach cases

And what LORA air data rate do you set?
The lowest possible or the next level up?

I think you may have broken FLOAT while trying to focus on FIX. In the past float would be 1 or two cycles out, but now FLOAT is worse than SINGLE.

Still cannot enter decimals for antenna height or height if using a manual base position using chrome on ios10 and reachview 2.9.0.

Looks like I am not getting a numeric keypad but a tone dial keypad with options like pause, wait, * and # but no decimal point.

1 Like

@Simon_Allen could you please share the logs for analysis?

is this also your suggestion for wifi and correction over internet?

or does higher updates rate make advantages for rtk?


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.

Regards, Ben

1 Like

Hi Egor (@egor.fedorov),

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.

Here is a link to a set of example log files.

Regards, Ben

1 Like

Thanks Ben.
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?

1 Like

Please provide Reboot/Restart button. Thanks

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:

  1. Is an update to 2.9.0 imminent or is it ready for production use.
  2. 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.

Thanks for the help and great support.

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?

DO NOT 'upgrade to 2.9.0.
This is from rover using Reach Base (with clear sky view on known location)

ANd this is the RS Base itself receiving corrections from an Australian Gov network receiver 10Km away.

Something ain’t right with 2.9.0

1 Like

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.