I would like my android app to be able to configure/start/stop/monitor the RTK server and then download the raw output file so that we can do post-processing later on. The app should also be able to delete the raw output files.
Both the ReachView and SSH interactive command line are not adapted to this purpose. Is there currently any other option?
I would rather have a simple REST API to expose the functionalities. So that i can build in my app UI the control for the RTK server. I can think of 2 implementation strategy:
extend the ReachView
build a different repo ReachAPI
Has Emlid any roadmap covering those needs?
Our organisation can also consider allocating some resources to contribute via PR on the existing public repos.
I’ve been trying the socket.io in an android app to connect to a Reach. The response from Reach makes the java client crash. See below the TCP trace.
The issue of the java client is that it’s trying to parse the message as a socketIO payload by casting the “557753357632” number as an integer, which throws a exception.
I feel that the function triggered at the connect event needs to be overwrite to not parse the body.
The java lib you use is only compatible with socket.io v1 and up. At the moment we use v0.9.6. We will update socket.io lib to the newest version, but it will take some time.
By sniffing the connection, i can see the websocket command reach ReachView but then nothing is happening. Is the ReachView Flask server outputing log in the filesystem so i can troubleshoot the issue?
Glad you’ve figured it out on your own. I am not sure I could be of any help with this library anyway
Btw, if you are working on as open source app, you are welcome to share the sources here. If you need any help with the protocol logic, or anything else, don’t hesitate to contact me.
We are looking to build our own app which communicates with the Reach RS2.
If we have to build this without an API it would mean that we have to reverse engineer the messages send over the wifi.
This would cost us a lot of time, and essentially it would mean that we build a custom API layer on top of the current communication protocol.
To avoid double work I would love to make this “api” layer open source, and develop it with the help of your engineers.
Is there a possibility we could co-develop this api together?