Saving logs to external SD

Is it possible to define a directory in the external SD for saving logs?

In ReachView, no.

At the command line, yes:

Disclaimer: I have not tried this myself yet. It is just one method which should work. There are several other methods which could be better or more redundant. This is a manual process to be followed each time you want to record your logs on an external storage device. To be clear, this is an example of ‘live recording’ on the external storage.

  • In ReachView, turn off all logging and point collection.
  • Insert USB OTG adapter into Reach USB port
  • Insert USB storage device or USB card reader with SD card or similar
  • SSH into Reach device as the ‘root’ user; password ‘emlidreach’
  • find name of your storage device with partition number ( for example: /dev/sdx1 )
  • mount that storage device in the root directory (for example: mount /dev/sdx1 root )
  • In ReachView, you may enable logging and/or point collection

When finished logging:

  • SSH into Reach device again
  • unmount the storage device ( for example: umount /dev/sdx1 )
  • unplug the USB storage device
  • Finished!

I meant from within ReachView and for Reach RTK. I find it is very unfortunate that this is not possible, I hope this option will be implemented in the future, logs can be large and the user should decide where to write.
Regarding your command line instructions, when you say:
"Insert USB OTG adapter into Reach USB port"
then power would be lost.

Thanks anyway

OK, I’m confused now. You spoke of an external SD. Where else would you put it other than in a USB SD card reader?

From that I gather that you have the Reach module. If you had a Reach RS, then it would remain powered by the internal battery. For your Reach module, when using the USB OTG adapter, you must power the Reach module via the DF13 connector. Sorry, I guess I could have mentioned that detail.

I agree with you there. There is really a lot of space available for logging, but if you are doing it for extended periods or continuously, then yes I can see the need for external data storage. If it is not on the feature wish list now, then I’m sure it will be soon :wink:

Let me suggest one more thing. If the position log is all you need, then ReachView can be set to output it’s position via Bluetooth, Serial (UART or USB), or TCP (WiFi or USB). All you need is another device to save the position data. It could be anything, like a laptop, a Raspberry PI, or a data logger.

Although that could be a workaround, note it is unnecessarily complicated: ReachView runs on an Android device with an external SD, so the most straightforward is let the the user select where to save files, not having to set up another communication link.
Also, what I want is to post-process RINEX files acquired with one single Emlid Reach RTK using a nearby permanent base station (no need of Emlid Reach RS for this case) to improve accuracy.
(I probably should have mentioned this from the beginning). I guess I thus need to save log files
(please correct me if I’m wrong).

I was assuming that you wanted to capture log files in excess of 2GB and that you needed a larger storage attached to Reach.

Now I understand that you want the ReachView app to be able to save the raw data log in real time to a local folder on your Android device (which could be an SD card).

That is fine. Maybe that feature will become available some day.


I fail to see a motivation here. The 2GBs we provide can store several days of logs.

It would help in some cases not having to boot up the Reach module to access the log file. I’d rather leave my gear in my truck and carry an SD card inside to my computer.

I fail to see a motivation here. The 2GBs we provide can store several days of logs.

Several days is really not very long considering that there are numerous monitoring applications that require months++ of operation. I have seen an example of monitoring slope movements in the forums, and I am working on glacier motions over seasonal and longer timescales. The ability to log data to a larger-capacity drive is a necessity!

I’m also working to log glacier motion over long(er) timescales (6 months or more at a go), and am planning to make use of the external log possibilities. I think the SSH possibility is a good one for now, providing power via UART and logging to a USB via the OTG. However, I have a few key questions:

  1. Will this produce the raw logs on the USB, or only the position logs?
  2. If power supply is cut, then reconnected, will the the Reach (RTK) default to logging over the USB, or will it revert back to only logging locally. This is important for solar applications where, for example, intermittent snow may mean the battery drains for a period. It’s also important for logistical considerations (do I need to take the laptop in the field to fully program each Reach in-situ, or can I set up the drive mounting beforehand, then reconnect power when in position).
  3. Are the on-board logs also created (providing sufficient space is available), or will the unit only log externally?

Thanks for any thoughts on the above.


  1. All logs are recorded in the /root/logs directory, so if you mount your USB drive at /root or /root/logs, then you will get all the enabled logs, including raw and position.
  1. No, the above method is manual, and must be performed every boot. However, it would be trivial to put a line in the /etc/fstab file which mounts the USB drive at boot time.
  1. In this method the logs would only be written to the USB and not written internally. To write to both simultaneously would require a different approach.

Thanks bide, I’ve tested this out (also adding a line for fstab, with nofail options in case the media isn’t attached). So far this worked very well through several reboot cycles.

1 Like

That’s great! Your modification should probably survive a software update as well, but no guarantees!

If you post your fstab line entry here, it may help some others as well. :slight_smile:

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.