Red LED on Reach, where is the log file for the error?


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.



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.) (14.8 KB)

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 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, 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
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/”, 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/”, line 2311, in load_entry_point
return ep.load()
File “/usr/lib/python2.7/site-packages/distribute-0.6.32-py2.7.egg/”, line 2017, in load
entry = import(self.module_name, globals(),globals(), [‘name’])
File “build/lib/reachview/”, line 7, in
File “build/lib/reachview/app/”, line 21, in create_app

File “build/lib/reachview/app/configuration/”, line 5, in
# package placeholder
File “build/lib/reachview/app/configuration/”, line 6, in
File “build/lib/reachview/app/configuration/”, line 453, in
File “build/lib/reachview/app/configuration/”, line 362, in apply
File “build/lib/reachview/app/configuration/”, line 366, in update_current_configuration
File “build/lib/reachview/app/configuration/”, line 187, in update
File “build/lib/reachview/app/configuration/”, line 204, in read

The only configuration file I’ve found so far is in:
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:

Mode - single
Base correction - TCP
Corrections input - None
Position output- None
Logs - all on

Mode - static
Base correction - TCP
Corrections input - NTRIP
Position output- NMEA via TCP
Logs - all on

ReachView 2.1.6
Image v2.1

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.

@savvy0816 Does this type of configuration always break the app? Or it was one time only?

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 :frowning: 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.

Guys, thanks for the report. We found the cause of the issue and a fix for it will be a part of the next update.

1 Like

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?

This error has been fixed in 2.2.0: