I have same problem here. New to flashing, but seemed to go OK. Short on time to do testing now.
It seems to me like this update slowed down the time Reach takes to apply settings. I flashed the firmware twice because the Reach was not starting up its initial hotspot when it should have. The second time I waited and it finally applied. Although after configuring the edison, it did not join the network, it created one of it’s own, which confuses me greatly.
Hi @igor.vereninov, Well bad news for now… I reflash the second one and I got the same behaviour… 
, I made the procedure three times using GUI twice and one with windows CLI.
If I get access using ethernet over USB I got acces to linux platform but when I made the procedure suggested by @egor.fedorov I got the same message that I already write before…
Now reagarding to the others ReachTeammates 
I think there is some little bug on the new image.
Thanks in advance for your analysis.
I was able to reproduce your issue after reflashing it several times. My Reach has created hotspot with a name “EDISON-66-AC” instead of “reach:66:ac” right after flashing and password “emlidreach” would not let me connect.
The solution was to reboot, Reach has created a hotspot with name “reach:66:ac” and I have connected without any issues. (Tried Win8, Mac, Android, IOS). It seems like this issues is only present if you do not reboot the device after flashing.
Can you confirm that?
Hi @igor.vereninov… uhmm well after several flashing procedures (7 times)… the behavior is the same… regarding to your topic the hotspot model was showed just only 2 times… after that the reboot was done but wifi connection was not possible. At this point I ask you a guidance to check inside of which file of the system are located the password expected for the system… Could you provide to me the path and the indications to search the file to continue the troubleshooting? Thanks (By the way merry christmas and happy new year 2016)
I duplicated the hotspot “EDISON-66-AC” type name. Paid more attention to flash procedure and waited for rebooting after flashing. Now, the two Reach units show up as “reach:66:ac” name formats. However, I still cannot connect. The units appear to be in normal Wi-Fi Hotspot mode. But still cannot get password “emlidreach” accepted. This occurred with Android, Win7, and Ubuntu Linux 14.04.
I’m still trying to see what is happening. Is there someway I may have messed up the password?
I second the appreciation of the effort that everyone at Emlid and other contributors have put into this project.
I’m in the same boat as @Grek. I had a working setup with the original firmware. After installing the new firmware, I get the “Reach:75:1f” hotspot to show up, but it will not accept the “emlidreach” password. I’ve tried on mac and win7 and also reflashed the firmware again, let it sit, rebooted, etc with no success. Any ideas? I haven’t tried it on the second unit.
Does anyone have a link to the original firmware? I can’t seem to find it.
Found the original image here: http://files.emlid.com/data/public/reach
I was able to properly connect after flashing the original image. Subsequently flashing the latest image gives the same result of not accepting the password. Going back to the original image unless someone else has suggestions.
New image? Im confused now, do we have to upload a new firmware already? Wasnt it supposed to be software updates over the app?
From another post:
[quote=“ivereninov, post:15, topic:1288, full:true”]
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. **
[/quote]
Hi,
i can confirm, that after flashing the Reach Module, the “EDISON-XX-XX” hotspot came up.
A powercycle (reboot) did solved this, and the “reach:xx:xx” hotspot did appear and it is connectable with the password “emlidreach”.
Flashing was tested under OSX 10.11.2 and Ubuntu 12.04.
hello,
I still have the problem “Rover does not boot if base is powered up”.
I’m running image 1.2.
I thought this issue was resolved. Am I right/wrong?
Hi!
This issue indeed was resolved. Can you describe your setup and rover Reach LED statuses?
led status precision:
- Radio (with correction )5V on
- power up Reach
- Leds: Blue\Purple (around 100ms)
- leds: off/off (around 100ms)
- leds: blue/Pink (pink falshing around 200ms 3 times)
- leds: Blue/ Pink (around 10seconds)
leds color is cycling 3 time from 3) to 6)
then leds keep Blue/Pink forever
Egor
This still happens. My set up with rfd900 radios on uart acts this way have to turn the rover on 1st have the latest updates installed. I posted this a few days ago and got no response.
Thanks
Jim
Just in case, the image version is 1.2?
yes, version 1.2 (both Base and rover) that’s the first thnig I have verified…)
This is definitely a power issue. There is not enough to supply the radio unit as well. You can try the following:
- Try a different USB cable
- Try a different power source, it would be great if you tried one with 2A output.
I already use a 12V 5A.
The Radio is not connected with the USB but through the DF13