I’ve also been battling the WiFly to stay connected for about a month now.
This thread spurred me to dig a little deeper into the WiFly library and find out why I would get random hangs of the WiFly module. All I am using it for is to read sensor data and submit an HTTP POST to a remote server, so I’m not using any server functionality whatsoever. The multicast comment made me think that the library may be trying to fire up the HTTP server inside the WiFly module as well, and when receiving a multicast packet, to fall over dead.
Sure enough, I dug into the library, and what I found was the WiFlyDevice.cpp (under the setConfiguration() method) is trying to set a server port to listen on (“set ip localport ”). It was also setting autojoin to 0, and some other things I specifically did not want it to do. Here’s what I did to solve that, and so far so good with not losing connections (though no guarantee this will work for you):
Edit WiFlyDevice::setConfiguration() so that everything is commented out except for the following:
enterCommandMode();
sendCommand(“set comm remote 0”);
Then I use the SPIUartTerminal program in the WiFly examples and run the following:
$$$
reset FACTORY (start from a clean slate. Lots of corruption happened on my card from the shaky library)
set wlan channel 0 (for scanning of all channels)
set wlan ssid (use $ for spaces)
set wlan phrase (Your password)
set wlan hide 1 (to hide the AP password in the command line mode here)
set wlan linkmon 5 (to retry connecting to AP in case of random drop)
set wlan rate 2 (For better range but at a slower speed)
set wlan auth 3 (For mixed WPA1 & WPA2-PSK)
set wlan join 1 (Try to join access point saved above automatically)
set ip flags 0x6 (defaults to 0x7. 0x6 will cause an established TCP conn. to be closed if access to the AP is lost for some reason. This prevents hangs)
set ip protocol 3 (Only act as TCP client right now, not a client/server as default. Server hangs on multicast is the hypothesis as of now)
set comm idle 2 (If inactivity on a socket after 2 seconds, close the connection. Again, try to keep sockets closed when possible)
save (save configuration)
scan (scan for ssid set above)
join # (based on scan command above, join this #)
This should show your WiFly card connected to your access point. Next step is to update to the latest firmware. Just send this:
ftp u
And you should be updated to (as of my writing this) 2.31 firmware.
Now, recompile your program and the modifications to the WiFly library made above, and your card should stay connected. Mine is working great now, but if for some reason it crashes again, I’ll report back so we can keep at it.
As an aside, looking more deeply at the WiFly library, I appreciate that SparkFun created it for us, but it’s not the most solid piece of code I’ve seen, and it assumes a ton (like wanting to run both a client and server). For my project–and I’m sure many of your projects–I will need a lot of solid flexibility with this piece of hardware and I don’t want to have to hand-type the configuration above into the Uart of the WiFly module each time, so I’m considering writing another library for it that will handle this for me. If so, I’ll post it to GitHub and here for others to use and contribute to.
Cheers-
Eric
PS: This doc was indispensable to me. Highly recommended for getting commands directly into the WiFly via the SpiUartTerminal program: http://www.sparkfun.com/datasheets/Wire … SX-um2.pdf