Rover does not boot if base is powered up

Reach Module / M+ / M2 Hardware integration
1

I had the issue that (only) my rover module would not boot up, but get stuck with the violet LED and is not reachable. That happens always when the base module is powered up and telemetry is connected. Please tell me if you need logs / vids and I get some. It`s 100% consistent.

The rover will then automatically reset to “single_default” and stopped. Very annoying…

Telemetry is 868MHz jDrones, air baud 57600, serial baud 38400. Rover output serial at 38400 / NMEA for Pixhawk.

If there is a solution please let me know :slight_smile:

2

Andreas,

Could you please test configuration where you connect only GND and 5V lines to the radio, but do not connect other lines (tx,rx etc…). If it does not boot and shows violet led, than you are having power issues. If it stops booting when TX and RX lines are added than it probably is trying to interpret data coming from the radio as user input during boot.

If you could help us debug this further it will greatly help us provide a fast fix to the issue.

3

Andreas,

We have found the issue and it is related to Edison getting some data on the UART during boot. It will be fixed. For now radio has to be silent until Reach is booted.

4

Thank you for the update!
Sorry, I had no time today to do more testing myself.

If that happens to all users then it`s quiet a bug! It took me a long time to figure out why my module sometimes (apperently randomly) was not booting. Testing takes even longer since every possible error takes a minute or to to test.

I write a short warning in the Github wiki. Otherwise more people are going to pull their hair…

5

This matches the issues that I was seeing as well. Happy to hear that you were able to reproduce it and a patch will be sent out.

6

Yep.

Thanks for sending a pull request to the docs, will merge it shortly!

7

It seemed to be fixed with v0.0.2, I`ve tested it a couple times. But as of today, the bug has returned.

Settings are still the same. Unit sat on the bench for a couple days. Same problem, rover gets stuck with violet led if base is powered on…

BTW: please give us the led blinking pattern meanings already. Thanks!

8

Also, the settings and saved settings reset and change all the time back to the single_default settings for the rover. Really anoying as well.

9

Andreas, this bug was not fixed with v0.0.2, you were just lucky not to see it. We are rushing new image update that will resolve this issue.

10

Could you please give more details on when/how this happens? This sort of feedback is really appreciated.

11

Every time the rover does not boot up, the settings go back to single_default. Most of the time I can just change back to kinematic_default, but not always.

Sometimes if I change settings in the app view on the pc/smartphone, the screen hangs up. That`s usually when the settings reset. Sometimes even the base goes back to “rover” mode.

12

Andreas, Nic,

Just wanted to let you know that we are testing an updated firmware that solves this issue. Sorry for the delay. If everything goes well it will be released within two days.

It turned out harder to fix than we initially thought because it is tied to low level stuff happening in the loader.

13

We have released new image that solves this and some other bugs, download link in the docs has been updated.

14

Does this update fix automatic base coordinated?

15

Weston,

Not yet.

We have two levels of updates:

  • In-app update trough ReachView. It lets us deliver new functions to you such as automated base coordinates, new protocols, UI features etc…

  • System level/OS upgrade has to be delivered by reflashing. Some issues can only be fixed by this method. For example the one mentioned in this post.

This bug was critical and we very focused on it mostly and had to put development of new features on hold. Now we are through it and keep working on improving Reach :slight_smile:

16

Hi @igor.vereninov, I already flash one of my Reach units with the fresh image (ReachImage_v1.1.zip) but when I try to connect my PC to Reach hotspot (reach:a3:36), I receive a message from my PC that password is invalid, also I try from my mobile and the system answer is identically (password is invalid) then could you confirm if is the password to access is

emlidreach

Thanks

17

Hi @Grek,

I have just downloaded the image, reflashed Reach and connected to wi-fi hotspot with password “emlidreach”. Everything just works. Maybe you have caps lock / wrong language settings?

18

Hi @igor.vereninov after post the message I try to go back with the previus version of the reach image that I downloaded on 14-12-2015, well I made all the flashing procedure… and I got the conection to the reach hotspot and my PC get connection with reach, after that I typed the address 192.168.42.1 and Intels page open and allow me to change the setings to my local network, then I made those changes I wait for wifi connection and It works… Then I reflash to the latest version again but unfortunaltelly no access behaviour still happen.
But here doesnt finish my troubleshooting, then I follow the USB ethernet access procedure on http://docs.emlid.com/reach/software-development/#connecting-to-reach-via-ssh and then @egor.fedorov on the post Reach is not creating Wi-Fi hotspot - #7 by Kyle_Gardner but I got the following answer when I type:

sudo wpa_cli status
Password:
Failed to connect to non-global ctrl_ifname: (null) error: No such file or directory

here the password that I use was reach
So Could you help to me to solved?
BR
JGrek

19

Thanks for the debugging work! While flashing the new image, have you waited until led turns green without removing power or you plugged it out right after Intel Flash tool showed “success”? I am trying to find out what we are doing differently.

20

Hi @igor.vereninov … yes off course I wait till led turns solid green without disconnect the usb cable during all the process…uhm could you guide tome where on which file i can check which password reach is waiting for?