Software and Multimedia R&D.

Neurogami ®

Dance Noise.
Out now.

Get it here ...

Setting up a WiFly RN-XV board

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.)

Fun facts

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.

  • WiFly-GSX-XX for RN131G/C
  • WiFly-EXZ-XX for RN171

where XX is the last byte of the module’s MAC address.

Getting started

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 Sketch

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 ” or “set ”. In this case the goal is to set the board for DHCP, an AP name and pass phrase, and some connection options.

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.

Here’s the code:

/*
An example sketch to show how to configure a WiFly RN XV with a Teensy 3.1.
For this example, the Teensy board was mounted on a breadboard, powered over USB.
Teensy GND and Vin are wired to + and - on the breadboard.
Teensy pins 7 and 8 (RX3 and TX3) are connected to the WiFly's 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 "
http://jamesgregson.blogspot.com/2013/03/setting-up-wifly-rn-xv-with-teensy-30.html
A big thanks to James Gregson for his write-up.
One difference here is that this sketch does not use any LCD. All feed back comes
from the Arduino serial monitor.
The 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.
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.
The goal of this sketch was to see how to set up a WiFly VX RN (AKA RN171XV) to
connect to a local wireless access point and acquire an IP address using DHCP.
There are assorted WiFly demo sketches on the 'Net but they all seemed not-quite-right
for me. In many cases the demo sketches relied on libraries that wrapped calls to
the WiFly board. Not only did none of these work for me, but the use of a library
obscured the details of what was actually happening, and I wanted to know just what steps
were needed and how things worked.
In the long run a wrapper library would be a Good Thing, since it abstracts a lot of tedious
stuff as well as making things more robust. For example, in this example the configuration
commands are sent and then a fixed delay is used to allow time for the command to take effect.
A far better approach (and one used by every WiFly library I saw) would be to send a command
and then watch the return data for the "OK" prompt. Even better, look for "ERR" and handle
things nicely.
However, the code here is simple, works (for me, at least :) ), and should help illustrate
what you need to do.
A few factoids you may find useful:
* If you boot the WiFly with pin 8 high (i.e. connected to 3V) then the device goes into soft AP mode.
* The default IP address is 1.2.3.4 and you can telnet in at port 2000
* If you find that nothing is behaving as expected you can do a factory reset by toggling power to
pin 8 five times. (This is sometimes referred to as GPIO9). You need to first power up with GPIO9
set high, then toggle it five times.
* Make sure you are using the correct user guide for your WiFly model.
For this example I used "WiFly Command Reference, Advanced Features & Applications User’s Guide"
"RN-WIFLYCR-UG Version 1.2r 4/30/13"
This link might work:
http://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en557989
* If and when you get your device appearing on your network (or as an AP) the SSID will clue
you in about the model.
WiFly-GSX-XX for RN131G/C
WiFly-EXZ-XX for RN171
where XX is the last byte of the module’s MAC address
*/
// <Arduino.h> is needed so that "settings.h" can refer to the String type.
#include <Arduino.h>
#include "settings.h"
/*
"settings.h" needs to live in the same folder as this sketch and define two strings:
String ssid = "YourAccessPointSSID";
String passPhrase = "YourCoolSeekretPassword";
*/
int led = 13; // The LED pin on Teensy 3.1
int commandDelay = 5000; // Hacky, yes.
// Used to buffer Serial stuff
String content = "";
char character;
String content3 = "";
char character3;
// The commands to send to get the WiFly set up.
// The goal was to have a relatively simple
// way to write a list commands that you
// could add to or remove from and not
// have to keep changing some variable tracking
// the number of commands.
// You may have to use a different wlan command depending on
// the security (if any) of your access point.
String cmds[] = {
"set ip dhcp 1", // 0 means don't get IP form DHCP server. 1 means grab one va DHCP
"set wlan phrase " + passPhrase,
"set wlan ssid " + ssid,
"set wlan auth 4",
"set wlan join 1",
"set sys autoconn 1",
"ext", // Leave command mode
"" // Required. Indicates the last item when
};
/************************************************************************/
// Read the String array until an empty string.
// Too hacky? Is there a better way to loop over the array of command strings?
// In any event, it works well enough.
void sendCommands(String cmds[]) {
Serial.println("Send command strings ...");
int i = 0;
while( cmds[i].length() > 0 ) {
Serial.println( cmds[i] );
Serial3.println( cmds[i] );
delay(commandDelay);
while(Serial3.available()) {
character = Serial3.read();
content.concat(character);
}
if (content != "") { Serial.print(content); }
i++;
}
Serial.println("Command strings are done.");
}
/************************************************************************/
// Useful to show that at least something is happening in case no text output appears.
// E.g. if you wonder if you fried the board or something.
void blink() {
delay(100);
digitalWrite(led, HIGH);
delay(100);
digitalWrite(led, LOW);
delay(100);
}
/************************************************************************/
void setup() {
pinMode(led, OUTPUT); // THIS IS IMPORTANT, or else you never see the light
Serial3.begin(9600); // UART, RX (D0), TX (D1) are connected to WiFly
Serial.begin(9600); // Be sure to set USB serial in the IDE.
blink();
// A short delay so you have time to start up the serial monitor
// and see that the sketch is, in fact, running while not missing
// any useful info
delay(5000);
Serial.println("15");
delay(5000);
Serial.println("10");
delay(5000);
Serial.println("5");
delay(5000);
Serial.println("Are we ready?");
blink();
Serial.println("Send money ..");
Serial3.write("$$$"); // Go into command mode.
delay(250); // The WiFly needs a short delay after the cmd signal
Serial3.println("");
sendCommands(cmds);
delay(3000);
}
/************************************************************************/
void loop() {
// Copped from http://stackoverflow.com/questions/5697047/convert-serial-read-into-a-useable-string-using-arduino
String content = "";
char character;
String content3 = "";
char character3;
while(Serial3.available()) {
character = Serial3.read();
content.concat(character);
}
if (content != "") {
Serial.print(content);
}
while(Serial.available()) {
character3 = Serial.read();
content3.concat(character3);
}
if (content3 != "") {
Serial3.println(content3);
}
blink();
}

Stuff

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.

Next up

The next write-up will show you how to set the board to use UPD to send OSC

Listen




Love me on Spotify!11!1