Reach: After flashing I can't update

[Ace]

Hi,

I have an Emlid reach kit, and am trying to get it to work.

It had the older firmware (0.4.9). I flashed the newer V2.3. It comes up, I can
see it create a hotspot, but I’ve had trouble having it connect to a network to
do the auto-update.

It was able to auto-update before with the older firmware, and used to be
able to link to my wifi router. So the hardware should be OK I think.

Today I tried to do something ultra-simple that should have worked. I plugged my macbook pro (OSX version 10.8.5) into my internet router via ethernet cable and shared my internet connection from the network via wifi, on an open network, after setting up the emlid reach using its hotspot and the web-based tool to set up the wifi. I also tested the internet sharing with another wireless computer to confirm I could get to the internet. I also connected to the emlid reach via ssh and confirmed the wpa_supplicant.conf.

Everything looked like it should have worked but I couldn’t get to the reach:

setup emlid reach via hotspot:
root@reach[/etc/wpa_supplicant]# cat wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
config_methods=virtual_push_button virtual_display push_button keypad
update_config=1
fast_reauth=1
device_name=Edison
manufacturer=Intel
model_name=Edison

network={
ssid="fox"
key_mgmt=NONE
}
Plugged ethernet cable into my mac.
shared ethernet over wifi, with ssid ‘fox’ from my macbook pro
-tried using the wifi from a different machine, which got IP address 192.168.2.4 successfully
and could successfully get out to the internet.

Figured out how to see what IP addresses were being served by my DHCP server:
Aug 9 09:55:51 fox.local bootpd[3498]: ACK sent 6506040ndreward 192.168.2.4 pktsize 300
Aug 9 09:55:51 fox.local bootpd[3498]: service time 0.001029 seconds
Aug 9 09:55:51 fox.local bootpd[3498]: service time 0.000002 seconds

Turned on the reach (mac address ending :34:9b):
Aug 9 09:57:06 fox.local bootpd[3498]: DHCP DISCOVER [bridge0]: 1,90:b6:86:3:34:9b
Aug 9 09:57:06 fox.local bootpd[3498]: OFFER sent 192.168.2.3 pktsize 300
Aug 9 09:57:06 fox.local bootpd[3498]: service time 0.001648 seconds
Aug 9 09:57:06 fox.local bootpd[3498]: service time 0.000002 seconds
Aug 9 09:57:06 fox.local bootpd[3498]: DHCP REQUEST [bridge0]: 1,90:b6:86:3:34:9b
Aug 9 09:57:06 fox.local bootpd[3498]: ACK sent 192.168.2.3 pktsize 300
Aug 9 09:57:06 fox.local bootpd[3498]: service time 0.001407 seconds
Aug 9 09:57:06 fox.local bootpd[3498]: service time 0.000003 seconds
Aug 9 09:58:22 fox.local bootpd[3498]: service time 0.000015 seconds

So I see that it tried to connect. An IP address was offered. An ack was received. So
it should have address 192.168.2.3. However, ping fails, and I cant get to it via a web
browser either. So I can’t kick off the update ever.

fox$ ping 192.168.2.3
PING 192.168.2.3 (192.168.2.3): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3

Any ideas on how to further proceed?
I wouldn’t mind just updating the software by hand if there is a way to do so. What I mean is, can I download the file onto a computer with internet access and then scp and put them onto the reach?

End goal: use it as a DGPS with a pixhawk to have cm level precision while flying a mission. I plan to accomplish that first via separate telemetry radios to send the base correction directly to the rover onboard the aircraft. I would like to configure the rover to send the output as NMEA serial hooked into the GPS port of the pixhawk. I’ll be using arducopter 3.3.3 firmware to start with since I’ve made some custom changes to support other project goals.

For now I am just trying to get it to work as a ‘single’ rover as the first step.

thanks!

[TB_RTK]

Not sure what reachview version FW 2.3 carries but for those times i had issues, a couple reboot usually made reach connect to wifi. Only one time i had to reflash reach to get pass the wifi trouble. Right now running 2.7.3 they have worked fine.

[Ace]

thanks. I’ve rebooted plenty of times (gracefully by first shutting down the system when possible).

I wish I could download the 2.7.3 on my macbook pro and simply install it by hand. I don’t care at all about having wifi internet access on the reach devices for my intended use.

By the way, I’ve had the same behavior with both of my reach devices, tested at different times after updating (in other words both not powered at the same time to avoid any potential conflicts).

[TB_RTK]

Just a thought, do you see other wifi networks on your scanner?

[Ace]

Yes. At home there are several belonging to neighbors.

I think where you are going with this is that you think the reach may connect to one of those other ones? I’ve been able to see it come back to a reach hotspot when I dis-configure my wifi network that I want it to connect to though, so it doesn’t look like that is happening to me.

[TB_RTK]

Not excatly. Just something i struggled with back in the days with older wifi router and AP.
When several networks operate in range, their channels overlap causing clients get stuck in wifi mess.
Not sure this is your problem. You could check what channels your wifi is and see if any other is operating in the same range. You should have +/- 3 levels free up and down to the next

[Ace]

Hmm. interesting thought. I can try a different channel. But I’d think my other device (I tried connecting with an Ipad to verify the ethernet sharing was working) would have had the same trouble if that was the issue, and I could connect just fine with it.

[RickJ (Richard Johnson)]

For me, V2.7.3 update went smooth as can be. Better than before.
T-Mobile Android LTE Leon Lite
Firefox

Did not have to power down to reboot.

[Ace]

that’s a good data point, thanks Rick. Wish I could say the same.

[Ace]

OMG what a hassle.

You know what the problem was? My wifi’s SSID first letter was lowercase. That was part of the problem. It seems that it failed to connect because of that.

I happened to fall into this idea because I tried setting up the emlid on my ipad, and I noticed that the emlid’s updater web page auto-changed the first character to upper case. Even though I worked around it to make it lower case, I decided, after it didn’t work, to change the SSID first character to upper case.

The next problem I had was due to sharing my Mac OSX laptop’s internet from the ethernet port to the wifi port, because the Mac’s DHCP server uses the 192.168.2.0 network by default, and this conflicts with the reach’s usb over ethernet port numbering (thanks to another forum post from someone who had a fantastic new wifi router for that tidbit of information).

So I figured out how to modify what my laptop’s DHCP server served for IP addresses (I went round and round with this; it involved changing a plist file as well as modifying the binary file that’s used to execute the network sharing, which is not something I’d recommend doing without a backup). Then it worked and I could connect to the device when it changed addresses after connecting to wifi.

I just now finished the update to 2.7.3-r0!!! YEAY!!! Now I’ll see if I can configure it the way I want.

[just in case anyone wants to do what I did, this post was what helped me:
hints.macworld.com/article.php?story=20090510120814850
]

[Ace]

I tried to get my second reach programmed and I couldn’t get my laptop to properly act as a server again. It worked but DNS didn’t work so the update server was never reached.

I finally updated my normal wifi’s SSID to start with a capital letter and tried that and it worked.

Now I have both devices updated to 2.7.3-r0 FINALLY.

One other thing to note for anyone reading this: I noticed that what displays from the reach depends on the web browser you are using. For example, I was lacking the ability to set the output to NMEA, serial port, etc, and that seemed to be due to using an older safari web browser. It was totally non-obvious. I have yet to have good results even with the current safari web browser running on a new ipad. But now that I’m on my wifi router I will play around with other web browsers and see if I can get something that will work for both the configuration as well as displaying the GPS bars properly.

[TB_RTK]

Would recommend chrome for browser

[RickJ (Richard Johnson)]

One of the first things that we often forget about Linux OS is that file names are case sensitive while Windows are not. To mislead us, many Linux file finder programs are programmed to ignore case.

Glad to see you’re working your way through this. I’ve been fortunate lately with upgrades, so I’m using Firefox with Win10 and T-Mobile LTE Lite. Also, Firefox with Ubuntu 16.04 with reach and RTKNavi.

Sometimes, accessing ReachView page requires http://, sometimes not, depending on Web Browser.

[Ace]

Thanks; I hadn’t considered Chrome.

An update: my brand new ipad actually worked fine with Safari–apparently I just hadn’t waited long enough for a decent GPS signal on prior attempts. After a while, in rover mode, I did see the bars show up as expected. All the other menu items are working too (at least I could configure the serial port and NMEA, which is what I was trying to do).

[Ace]

I’m still not sure about the case being the issue. I went round and round trying to get my 2nd Emlid to update. Finally got it working and thought that the SSID case was the cure (just to be clear for those reading, what I mean is, the first character of the wifi SSID being changed to an upper case letter). However, after updating it could not connect to my wifi network again and made its own hotspot.

My primary use for the wifi was for updating, so since that’s done I’m moving on. But I can’t say that the problem is completely solved if someone else is having the same issue and trying to resolve it.