Permanent monitoring system: how to schedule solutions sync with a remote server

We are setting up a permanent monitoring system for slow moving landslides using two Reach RS, one as base located in a stable area and the second in the area where we expect movements.

While the system is deployed in the field, it is framed into a VPN with the server located in our office. So, each GPS is accesible as if it were in a local network. We have succeed in remotely plotting the GPS’s coordinates using RTKplot (both reach units stream their solutions over TCP/IP as server and a workstation in the office plots the realtime solutions).

Now this is my ask for support: we are whising to create reports showing Rover’s movement plots (i.e. Rover’s E-N-Up cumulative displacements and baseline cumulative displacements) and to store the solutions on our server. To achieve this goal we would like that each Reach RS periodically (hourly?) sync their logs folder, the one where llh fiels are stored, with a server located in our office.
On our point of view it is important that the “sync” is triggered by each Reach RS so that is done only when there is enough UMTS coverage.
We were whishing to use “crontab” but we found out that the edison board don’t have it and it isn’t possible to use the opkg command to install “crontab” since the command redirects to emlid’s servers.
To your knowledge there is any other option to schedule scripts using the edison boards?

Many thanks,
Marco

Hello Marco,

I think I can add crontab to our repository in the form of cronie with the next release. Let me know if it suits you.

Hi Egor,
Many thanks for your reply.
Cronie would be perfect!

We really appreciate your work: you are always pushing forward in order to accomplish all possible requirements that could make reach units an unique tool. You have a fantastic team.

Ps: when should I expect next release?

Thank you!

@george.staroselskiy pointed out that we do have systemd-timers supported on board. Maybe you can try that as well?

Cronie is now in the repo. To get it, simply run opkg update, then opkg install cronie.

HHi Egor,
I was struggling with systemd services and timers (I’m a Linux noob).
Many thanks for cronie I’ll take advantage of it!

1 Like

Hello. I wanted to try this with our RS2, btu I’m getting “opkg.lock: Permission denied” with user “reach”.
How can I get root access (if it is the problem)?
Best regards and thanks

Hi Gemetris,

You can use only the “reach” user. Root access is not provided.

May I ask you to describe what you want to accomplish in more detail?

Hello.

It’s disapointing! We found out on the web/forum that there should be such a root access.
If not, our plans are compromise.

We wanted to download and install additional packages how described in this topicand others (ddns). But opkg does not work without root, doesn’t it?

Concretely, we need to access the log data remotely or get this log data somehow through 3G/mobile data.
We want to do some long term monitoring without any controller on the field:
For battery optimization (we do not have any power on site), we do not want to use continuous TCP output. We would like to just grab or get log data once (or a bit more) per day.
Because there is no log push function, we would like to configure such a data transfer with additionnal tools (cronjob and ftp or similar).

Another solution would be remote access, but for that we need a 3G corporate access and in switzerland the APN are user/password protected, what does not support ReachView, unfortunately.

Do you have another solution?

Best regards and thanks in advance for your support.

Hello. I’m trying further alternatives like crontab, mount and then rsync, but I’m always needing the root password…
Best regards

Hi @geoguichet,

We can’t provide root access, I’m afraid. I’ll try to explain this in more detail.

Once you change anything in Reach software, it’s becoming difficult to predict how Reach and ReachView will perform. In this case, we can’t see the whole picture on what’s going on with Reach device and we can’t predict how the things you’re running on Reach may affect its operation.

Every time we add new features or fixes, we thoroughly test the code for a long time to make sure it’s stable and to prevent any issues and bugs in Reach’s main functionality.

As an alternative, I can recommend checking for other options. For example, you can output the position data from Reach on any 3rd-party board (such as Arduino or RPi) and then accomplish sending these logs from the board to a server.

It may help you to fulfill your requirements and, at the same time, it also prevents the device from any possible issues.

1 Like

Thanks very much for your reply.

It’s unfortunately not exactly what we expected and it should be mentioned in product description, that root access isn’t allowed any more. Because when you search in forum, you find many information and replies about Reach M+ that mention some system changes (eg opkg packages added) that need root access.
We have choosen the EMLID beacuse we wanted a flexible box with everything inside. The idea is to have the receveiver somewhere on the field without wifi connection.
Without appropriate mobile data/APN configuration settings and without possibility to run ftp, crontab/cronie and to write some config files in order to automate the system, it is unfortunately unusable for our needs.

It is also not our goal to add a computer or modem. It has to be robust, wateproof and if we cannot configure the output, we will loose time and it will get too expensive, big, heavy and need additionnal power.
We believe that EMLID is a good product, but perhaps a little bit young and less flexible/adaptable for some countries/conditions.
We hope it will evolve and any further help or possible correction would be appreciate.

We understand your concerns about support, but there are perhaps some advanced customers that would be able to do some optimisations or updates that could actually help the whole users community.

Best regards

Hi @geoguichet,

As Polina answered you over email, we’ve never provided root access for Reach RS2.
As for Reach RS+ and Reach M+, the root access was allowed in previous firmware versions.

I’m afraid at this stage I can’t advise you anything else on this question. Still, if you have any other Reach-related questions, we’d be glad to assist you with that.

Thank you!