Every so often my Reach gets into a state where the LED eventually goes solid RED after being green for a few seconds. I have been able to fix this state by reflashing the Reach with the version 2 firmware and then re-upgrading it. I believe some file is getting corrupted during powering off and its not a hardware problem.
Is there a log file some place that I can look at to find the reason for the RED LED status? I’d rather not have to continue to reflash the Reach.
Thanks,
Rob
Here is a zip file of the output from dmesg. (I can ssh to the Reach even though I have a red LED. It also setup the WiFi connection with my WiFi hub successfully.)
All I can add is that when this this kind of thing happened to my Reach many sofware versions ago (v1.x), I would kill the server.py process and run it in the console and I would always get a hint as to the error that way. I’m not speaking for version 2.x though.
Thanks for the idea. I didn’t find a server.py, but I noticed a /usr/bin/reach_setup. I killed the one running and reran it and got this error:
root@reach:/usr/bin# /bin/bash /usr/bin/reach_setup
u-blox test: passed
IMU test: passed
Network mode: client
(1610) wsgi starting up on http://0.0.0.0:5000
Traceback (most recent call last):
File “/usr/bin/reachview”, line 9, in
load_entry_point(‘reachview==2.0.8’, ‘console_scripts’, ‘reachview’)()
File “/usr/lib/python2.7/site-packages/distribute-0.6.32-py2.7.egg/pkg_resources.py”, line 337, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File “/usr/lib/python2.7/site-packages/distribute-0.6.32-py2.7.egg/pkg_resources.py”, line 2311, in load_entry_point
return ep.load()
File “/usr/lib/python2.7/site-packages/distribute-0.6.32-py2.7.egg/pkg_resources.py”, line 2017, in load
entry = import(self.module_name, globals(),globals(), [‘name’])
File “build/lib/reachview/manage.py”, line 7, in
File “build/lib/reachview/app/init.py”, line 21, in create_app
File “build/lib/reachview/app/configuration/init.py”, line 5, in
# package placeholder
File “build/lib/reachview/app/configuration/events.py”, line 6, in
File “build/lib/reachview/app/configuration/configurator.py”, line 453, in
File “build/lib/reachview/app/configuration/configurator.py”, line 362, in apply
File “build/lib/reachview/app/configuration/configurator.py”, line 366, in update_current_configuration
File “build/lib/reachview/app/configuration/configurator.py”, line 187, in update
File “build/lib/reachview/app/configuration/configurator.py”, line 204, in read
reachview.app.configuration.configurator.ConfigurationFileError
The only configuration file I’ve found so far is in:
/usr/bin/RTKLIB/app/rtkrcv/rtk.conf
But, it looks OK from a cursory glance.
I started seeing this same behavior today after running Reach continually for 24 hours straight in base mode while sending base corrections to NTRIP caster.
I found the problem. The /etc/reachview/current_config.json file was 0 bytes. I copied over the /etc/reachview/stable_config.json file over the current_config.json file and rebooted and it worked!
Good find. But this doesn’t describe the cause… Can anyone from Emlid comment? I reflashed and ran successfully continuously for a few days. Then I enabled both RTK input corrections via NTRIP and position output NMEA via TCP. At this point the receiver choked and ended up in the red LED state. It will not boot to any other state than red LED. Looks like I’ll have to reflash or copy the pristine config file per your instructions.
Stable and unstable configurations:
Stable
Mode - single
Base correction - TCP
Corrections input - None
Position output- None
Logs - all on
Unstable
Mode - static
Base correction - TCP
Corrections input - NTRIP
Position output- NMEA via TCP
Logs - all on
My guess is that writes to the config file aren’t being flushed right away and unplugging the Reach prevents the write. I imagine the Reach developers will be able to fix it pretty soon.
If the configuration file gets corrupted, the ReachView app will be broken until the configuration file is fixed. Cycling the power on the Reach has no impact on the problem.
I’ve just had this problem too No changes to the setup I have been using for a while. It was the Rover which was getting corrections from my Reach base via rtk2go. Now busy reflashing and upgrading.
Hi @rrr6399, would you like to explain more how to copy json file?
Is that mean two reach connected together in a laptop or pc, then both of them link by ssh, login into root?
No changes to the setup I have been using for a while. It was the Rover which was getting corrections from my Reach base via rtk2go. Now busy reflashing and upgrading.