So the WiFly arrived in the mail and the hunt began for a guide on getting it up and running.
The device came from Sparkfun so it was kinda-sorta but not really ready to use.
Pro tip: If you get this from Sparkfun you will probably want to get some 2mm 10pin XBee Socket things and a Breakout Board for XBee Module. The pins on the Sparkfun-packaged WiFly module are meant for XBee; they do not play nice with breadboards.
After getting the WiFly pinned-up I found a few guides. None of them worked. It’s quite possible that some initial flailing put the board into some funky state, but the guides were a problem in other ways.
For one, they all seemed to refer to either a different WiFly module version or an older version of the firmware. For another, the all used a library. What I wanted was something no-frills, bare-bones, this-is-how-it-works example.
To be fair, these guides and their libraries were a big help. Digging through the library code I could (in most cases) see what specific commands was sent to the WiFly. Long-term, a library makes a great deal of sense. My code (below, as a gist file) is a bit hacky a literal. That’s perfectly good because it works and it’s easy to follow. However, you do not want to build anything complex on top of this example. (If anything it will make you appreciate a good WiFly library.)
You will want the user guide, WiFly Command Reference, Advanced Features & Applications User’s Guide – RN-WIFLYCR-UG Version 1.2r 4/30/13 .
The default firmware version is 4.00. The default IP address when run as an ad-hoc access point is 1.2.3.4. You can telnet there on port 2000.
If you think you’ve hosed the settings you can do a factory reset by booting up the board with pin 8 (AKA GPIO9) set high (3.3V) and then toggling power to that pin five times. (This is one of the many useful things you can learn from the user guide.)
A simple test to see if your board boots is to power it up (3.3V, don’t forget) with pin 8 set high. This will boot it into what’s called “soft AP” mode. You should then be able to see this in your wireless network browser thing where it will appear as yet another local access point. The default SSID will clue you in to the model.
where XX is the last byte of the module’s MAC address.
The code is for a Teensy 3.1. Serial 3 is used to talk with the WiFly; the default serial goes over USB and appears in the Arduino IDE serial monitor.
Teensy GND and Vin are wired to + and – on the breadboard.
Teensy pins 7 and 8 (RX3 and TX3) are connected to the WiFly pins 2 and 3 (TXD and RXD).
The WiFly has breadboard + running to pin 1 (VDD 3V3) and – to pin 10 (GND).
This set up was taken from Setting up the WiFly RN-XV with a Teensy 3.0; a big thanks to James Gregson for his write-up. There’s a picture there that should give you an idea on how to wire things up.
One difference is that the sketch here does not use any LCD. All feed back comes via the Arduino serial monitor.
A bigger difference is that the WiFly configuration is done via Arduino code instead of being hand-typed into the serial monitor.
Note that this sketch is not using the WiFly in AP mode. Do not wire up WiFly pin 8 (unless you need to do a physical factory reset).
Also note that this sketch assumes the WiFly is running version 4.00 of the WiFly firmware. The behavior of a few things is different than what I found described in older examples using the WiFly (such as the telnet address).
The goal of was to see how to set up a WiFly VX RN (AKA RN171XV) to automatically connect to a local wireless access point and acquire an IP address using DHCP.
The hardware connection to the WiFly can be quite simple. Run wires to TX and RX, power, and ground, and you’re ready to talk serial. (The board has more pins but this sketch does not involve them. Read through the user guide to get an idea of what’s possible.)
Once powered up with a serial connection you can send commands and data. To change the configuration you need to send the special string “$$$”. The WiFly should respond with “CMD” to indicate you are in command mode.
Now you can send commands. Most commands take the form of “get
set ip dhcp 1 means use DHCP. A vaue of 0 means do not use DHCP (in which case you would want to then also set the WiFly IP address yourself).
set wlan phrase <passphrase-for-the-SSID> specifies your AP password, if needed, for WPA or WPA2. If your are use WEP you need to use set wlan key <key>.
set wlan ssid <SSID> indicates the SSID of the access point to connect to.
set wlan auth 4 says what authentication mode to use. See the user guide for the various values; 4 means WPA2-PSK.
set wlan join 1 says to join the network with the given SSID name. Again, look at the user guide to see the other possible values. There are some interesting options you can use when perhaps you do not have all the details of a given network.
set sys autoconn 1 says to auto-connect when ready. (As you may have guessed there are other values with assorted behavior you can use here.)
exit takes the WiFly out of command mode and back to data mode.
The commands are stored in an array; an empty string is used to indicate the end of the command list so that the sendCommands() method knows when to stop. This format worked well for adding and deleting commands trying out some things while not having to track the number of items in the array each time the list changed.
The commands are sent in setup(). The loop() function just watches for input on either the USB serial or the WiFly serial and passes them on.
The sketch expects to find a second file named “settings.h” in the sketch folder. Use this to set the SSID and pass phrase for your own wireless network.
When you run the sketch from the Arduino IDE (which should also have Teensyduino installed) wait until it is loaded and then bring up the serial monitor. Make sure you’ve set the board to Teensy 3.1 and the USB type to “serial”.
You should see the initial countdown text and then the command string sent to the WiFly. When that’s done you should be able to telnet to the device over your local network.
You can then enter command mode using “$$$” and poke around. For example get ip will sow the IP settings. get everything shows, well, everything. Use exit to get back to data mode.
The business of using a fixed delay to wait while a command takes effect is cheesy at best. The better way (and something done by assorted libraries) is to send the command then watch the output until the prompt appears. It would be nice, too, to be able to load a set of commands from a separate file if you wanted to be able to boot up with different settings. Even that is not quite right; you can save settings using the save <filename> command and load them back using (surprise!) load <filename>. This way you could plausibly prime the board with assorted config files and then load whatever one you think best.
But these are all things for a different, more ambitious, sketch.
The next write-up will show you how to set the board to use UPD to send OSC