Integrating Reach RX with own app

[px_nis]

A bit of backstory.
I work at a company doing SaaS project management for utility companies. We have an app, which is used for QA form submission and much more. I am a full stack developer, including the Android app.
In the fall of 2023 we decided to start a project to integrate RTK hardware into our app.
We bought a Reach RX and integrated it into our software.
We weren’t completely happy with the result. The biggest pain-points were the missing tilt compensation, the unreliability of Emlid Flow (more about this below) and having users (many which are not tech savy) using two apps at the same time.
We ended up returning the RX and getting a RS3 instead, which have resulted in a much better user experience.

Fastforward to now. One of our bigger customers have bought a few Reach RX for a different project and therefore we would like to support it again.

I have tried the following solutions:

“Emlid Flow” for NTRIP only. Our app consumes the NMEA stream over bluetooth.
Our original solution and it works, but Emlid Flow looses connection to the RX at random intervals.
Not sure if the app is killed by OS or BT connection is interrupted and not autoreconnected.
No noticeable improvements by setting the Emlid Flow battery config to “unrestricted”.
I know the connection isn’t properly implemented as an Android “Foreground Service”, as theres no status bar notification associated.
This should be the correct implemention to avoid a lot of OS battery optimizations.
We contacted Emlid through their distributor and they told us it was a known problem and they were working on a solution.
Here, more than half a year later, not much have improved.

“Lefebure NTRIP Client” for NTRIP only. Our app consumes the NMEA stream over bluetooth.
This doesn’t work as Lefebure will comsume the NMEA stream as well, blocking our app.
Is there any way to hook into a secondary connection? Like the service connection Emlid Flow uses.

“Lefebure NTRIP Client” for NTRIP and mock locations
This semi-works. The refresh interval is quite slow, but most importantly the horizontal accuracy is stuck at 3.9 meters.
I found other forum threads with the same “3.9” problem, but no solutions.
This seems to be a Lefebure problem, as I tried the same with “GNSS Master” app, which correctly provided horizontal accuracy.
The problem with “GNSS Master” was that I couldn’t get the NTRIP to work.
Given the staleness (very rare updates and ancient website) of the Lefebure app I don’t have much confidence in it being fixed.

I have tested all above on both a Pixel 7 (Android 14) and Samsung Active Tab 3 (Android 13).

I am a bit stuck. The best working solution was with Emlid Flow, but the unreliability was a big annoyance.

We are also planning to soon implement RTK capabilities in our iOS app.
Therefore a shared solution, NOT using mock locations, is preferred, as those are not supported by iOS.

Anyone got any suggestions?

[merryna.anggriani]

Hi @px_nis, Welcome to the community!

When you mention it loses connection, does it mean it loses connection in Emlid Flow or your own app?

Also, do I understand correctly that you use the Emlid Flow and your app on the same phone device?

[px_nis]

Typically I notice, that I am no longer getting precise positions. I open the Emlid Flow app and the Reach RX is no longer listed as connected. I tap the RX under “Receivers > Available” to reconnect. Then I can return to my own app and start getting RTK corrected positions again for a while. This happens at random intervals. anything from 30 sec to half an hour.

As mentioned above, I am not sure if Emlid Flow is restarted by the OS or the BT connection is just interrupted.

Yes, I am using the both apps on the same device. Emlid Flow is running in the background.

[igor.vereninov]

Have you considered implementing an NTRIP client in your own app and then sending corrections over Bluetooth to Reach RX/RS3? It would allow you to fully control the connection just from your app.

[px_nis]

I have, but we are not ready to add the development and maintenance cost. Which is why we are recommending our customers to buy the RS3, as it a self-contained system that we can just listen to. And has tilt compensation.

As mentioned, this is mainly because we a customer have bought some RX for another project.

And honestly, this should be supported. It is pretty minor adjustments to the Emlid Flow to properly implement it as an Android Foreground Service and adding auto-reconnect to the BT connection. Other competitors (like Tremble) offers various support apps to ease third party app development. The official RX documentation recommends the Lefebure app, which is pretty much staleware.

We also heard from the distributor that a RX version with tilt compensation is in development. We might revisit this the NTRIP client if this becomes reality.

[merryna.anggriani]

@px_nis, Thank you for the input and ideas. This is a complex and challenging task, and we don’t have a plan for such development for Bluetooth connection. You can use @igor.vereninov’s suggestion for the implementation.

@px_nis

We also heard from the distributor that a RX version with tilt compensation is in development. We might revisit this the NTRIP client if this becomes reality.

I think maybe there was a misunderstanding. For now, we don’t have a plan to design the RX with tilt.

[px_nis]

In that case, we won’t be implementing a NTRIP client, as tilt compensation is a huge QoL improvement.

But it’s honestly neither a complex or challenging task to improve the BT connectivity (I have done it several times). A good developer could have a PoC done in a day or two. All the complex stuff (NTRIP communication) is already done.

For now our RX customers will just have to jump back and forth between Emlid Flow and our app to maintain the BT connection. We will recommend the RS3 or another brand for future purchases.