Today i just lost a log file from my reach.
Yesterday i made a flight using my reach. After the flight i collected all my logfiles succesfully. I downloaded my raw data logged both on my rover and base. Today i was about process my files and i got error unzipping my rover log.
I got my rover reach module, fired it up and realized that i cannot list my log file from yesterday, only the two after, as i fired up the module to download my logs.
My module is logging automatically after boot up and i always unplug the power to end my logs. This method works 10/10.
After that (or after the whole day surveying) i fire up the module to download my files.
Some answers before questions:
-yes, i have benn logging. I got my log file, but is is broken
-no, i did not delete the log file from my device. it has plenty of space to store them and anytime i need them, i can download it again.
My question is, how can i reach the log files on the Edison file system. I think there must be somewhere.
Fire up Putty, filezilla or other SSH software. Fill in reach IP address and user/pass is emlidreach.
See if you can find your log then
emlidreach/emlidreach does not allow me to login. I use putty.
I got the latest firmware on the reach.
( password: emlidreach )
Might wanna try user/pass: reach or root
user = root password= emlidreach
and port 22
I got it!
The log file is in the file system stored as ZIP.
Downloaded it and still broken.
Error during unzip or broken files after? tried different unzipping software?
During unzip. I tried windows and total commander.
Broken ZIP file.
Sounds like a valid error but would give it another try with 7zip or winrar
Just tried. Runs to error anyways.
I think there is another error. My base log is 6MB and this rover file is only 3.
I will go with GPCs.
Hmm, I have just had my first zero bytes log file on a Reach RTK. Doesn’t appear in the web interface and when I access via SSH it is an empty file.
I will now stop logging before pulling the power plug. It is a pain
Here i have another zero size ZIP log file. Raw data logging only.
This time, trying to avoid this i logged in to my rover ReachView page and stopped logging with the radio button. Waited to ‘process’ the log and after that i plugged the power on my rover.
Still got a zero size log file and lost data for a 30 minute survey. Really don’t know what to do here.
ReachView version: v2.8.0-r0
I think I can shed some light on this.
The web (and app) interface to the logging page does not show the true status of logging until it has updated the list of log files on the reach. Until that point it shows logging is off.
It is possible to see this, while the log files are being read and try to change the status to on. If you do this you have just turned logging off. (if it was on already but not showing because the list was updating). In retrospect this was likely the cause of my zero length or missing files.
It can take quite a while to get an updated log file list.
My workaround here is to delete as many (all) of the files held on the reach as possible. So that the list doesn’t take long to update.
Longer term I suggest emlid break the loop in their app. to update the log status outside of the get log files list loop.
@csomy I would be interested if you think this might have been the cause of your file issues.
@csomyy When you ssh’d into Reach, did you look for log files which were not zipped? You may find that the original log files are still and only the zip file is bad.
Thank for your Post.
As i open the logging page, it says “Fetching logfiles”. Until this is shown i do not push the logging on/off button. I can se that the button statuses are updated only after the file list.
After these file losses i even reload the whole page after the module comes up and wait for the data double time.
I don’t think that this is the real problem here, but thank for your opinion.
Didn’t find anything, but ZIP files. Should i look better?
Double checked. .UBX files exist only under ongoing log. After ‘stop’ the file is being processed, and .UBX file is removed from the file system.
Oh, that’s too bad. I had a zip file problem once and was lucky that the unzipped log files were still there in the same directory.