User-friendly configuration of a Wi-Fi device

My previous post enumerated a few methods for configuring a device to connect to the home Wi-Fi network.
One of the friendliest way was number 4 (Creating a temporary ad-hoc Wi-Fi network). This method was chosen by Twine and also by HeatMeter and Belkin WeMo.

In normal use, the device connects to the home Wi-Fi network as a client, then sends (http GET/POST) the collected data to a web server.

Sometimes, when the device needs to be configured, it creates its own Wi-Fi network and runs a local web server. At this moment it allows other Wi-Fi devices (PC, smart phone etc) to connect, as clients, to the local web server and send configuration data, specifically the name of the home Wi-Fi network and the password. Once this configuration data is acquired and stored internally (in eeprom), the device returns to its normal state and uses it to connect to the home Wi-Fi network.
The configuration mode is selected by the user. One simple method is by holding down a button after a reset. Another is by placing the device (which has on-board accelerometer or even a tilt sensor) in a specific orientation (as done by Twine).

Below are diagrams I drew to show these two modes of operation (configuration mode and regular use mode).

The steps are:
1.After reset, if a switch is pressed by the user, the board enters the configuration mode. This makes  the Wi-Fi module a Wi-Fi server.

2.The user connects to it from laptop. Then user is presented with a web page that contains a form allowing the selection of the Wi-Fi networks that were detected, and the password.

3.These 2 elements (network name and password) are then saved in the eeprom. They will be used later to access the Wi-Fi network any time the sensor data gets sent to the collection web server.

Steps:
1.Data is read from the sensor.

2.Sensor data is sent as an http POST request through the Wi-Fi module.

3.Wi-Fi module posts the sensor data to the web server.

A nice feature for a network-connected device is that it can get program upgrades remotely, "over the air" in the case of Wi-Fi. This requires a bootloader that can connect to the internet and checks if a new version of the program is available for download on a given web server. The Readiymate team wrote such a bootloader for ATmega1280/2560 (the processor(s) found on Arduino Mega).

The next diagram shows how the remote program upgrade would work.

The steps are:
1.Bootloader makes an http GET request through the Wi-Fi module.

2.Wi-Fi module passes the request the web server used for “program updates”.

3.Web server starts streaming the latest program file (sketch).

4.The sketch is uploaded into the program memory.

User interaction when connecting WiFi devices to network

I spent some time recently analyzing methods for passing the WiFi parameters (network name and password) to a device, in user-friendly manner and on the cheap (that is, by using minimum extra hardware).

This challenge (of selecting the WiFi and entering the network password) was already solved in many different ways, from using the remote control to select characters displayed on the TV screen (as done by Apple TV, XBox etc), to creating an ad-hoc WiFi network (as done by WiFi thermostats, Twine and others).

The bottom line is that every WiFi device must somehow present the users with an interface that allows them to type in the network password. How this is solved determines the user-friendliness of the device and influences the final cost of the product as well.

Here are the methods I found so far. I am sure this list will be extended and improved with details, hopefully also based on the readers' comments and feedback.

1. SD card that includes a text file with network name and password
The user edits the text file on any computer. The SD card is then transferred onto the device. After the device is powered, the settings are stored internally and the SD card can be permanently removed. 
Pros:
- user-friendly and almost fool-proof;
- easy to implement in software;
- SD card may be also used for storing other data (backup in case of network disconnect, power outage etc);
Cons:
- need access to a PC (any text editor would work);
- adds about $6 to the total cost of the device (SD socket, SD card);
- device may need to be shipped with a an SD card USB adapter (adds another $2).

2. Bluetooth – The user interface is provided by a smart phones that communicates with the device through Bluetooth.
Pros:
- very user-friendly user interface through the smart phone app (e.g. Android), that uses a full keyboard and a complete feedback (similar to text editor);
- easy to develop the software for Bluetooth communication for the device;
Cons:
- adds $5 to the cost of the device (BT module);
- a simple application (e.g. BlueTerminal) needs to be downloaded by the user on the smart phone;
- may not work with iPhone, which requires Apple-licensed BT modules.

3. Using QR code that ships with the device - patented, licence-able technology; to investigate further (price, complexity etc.);

Pros:
- (maybe) user friendly, with minimal user interaction: smart phone app leads to a web site that requires the user to input the password;
Cons:
- pay royalties;
- need smart phone with camera and software app for QR codes.

4. Creating a temporary ad-hoc Wifi network (as used by some smart WiFi enabled thermostats)
Pros:
- easy to use web interface;
Cons:
- need a computer that can connect to the existing WiFi;
- requires development of the web site (for inputting the password);
- requires a way to switch the device between the setup mode and regular operation (when already connected to the WiFi). (Note: The above mentioned Twine uses an accelerometer chip for this purpose.)

5. Include an LCD screen with touch sensor or buttons (as in Nest).

Pros:
- all inclusive solution, no other equipment required to interface with the user;
Cons:
- adds to the final cost (at least $4);
- may be cumbersome to use, since the display is quite limited in space;
- makes the device bigger;
- software to handle the user interaction can be quite complicated (for such a simple task);
- waste of resources, since the LCD screen and buttons/touch may be used only for this purpose (user input).

6. Use a wired (custom, non-PC) input terminal, with screen and keyboard, that communicates on serial (RS232, RS485, TTL) interface with the device.

Pros:
- simpler software (processing the commands received on the serial interface);
- does not require extra hardware on the device itself;
Cons:
- need to provide the terminal hardware as well (OK solution when the device installation is done by a trained person).

7. Use an infrared (TV, VCR, stereo etc) remote control
Pros:
- ubiquitous, everybody is guaranteed to have one around;
- software is relatively easy to develop;
Cons:
- user interface not friendly; it would require some user feedback (display);

8. NFC (Near Field Communication) - to be researched
Pros:
- friendly user interface through the smart phone;
Cons:
- requires a smart phone;
- need to develop app for smart phone.



9. Direct connection to PC through USB/FTDI cable - as done by the readiymate board
Pros:
- the simplest to implement method: the board's microcontroller listens to and interprets the serial commands from PC;
- change the network name and password through either the serial monitor (command mode style) or through a GUI app that translates button clicks into serial commands;
Cons:
- requires on board FTDI chip (adds about $5 to the board's cost);
- requires development of the PC (GUI) app that talks to the board;
- also requires the user to download and install the app on the PC.

Raspberry Pi AlaMode

The great team of Wyolum announced that their Raspberry Pi AlaMode is available for pre-order.
This board, shown in the photo below, is Wyolum's answer to interfacing any number of hardware shields, sensors and servos to the Raspberry Pi.


AlaMode is an Arduino compatible board that plugs right on top of the Raspberry Pi computer. It also gives you:

• extremely accurate real time clock DS3231 with backup battery
• micro SD slot
• direct headers for plugging in servos
• safe voltage translation between the Raspberry Pi and Arduino.

Stock ticker with Wise Clock 4 and WiFly

I should have titled this "Adventures in WiFly land - Part 2", a continuation of this post, but really there was no adventure. Things worked smoothly from the start. The main "challenge" was parsing the http response on the fly, since the (truncated) response string itself is about 1500 bytes (3/4 of the RAM in a 328), which is the size of WiFly's receiving buffer.



The code (download from here) performs these steps:

• send http request to yahoo site, specifying the stock symbol;
• read the http response and find the token that identifies the stock price, in this case "last:";
• read the next few characters that represent the stock price;
• display the symbol and the price on the 3216 display.

This crude version is based on the WiFly_WebClient sample code from sparkfun. For display, it uses the HT1632 (header and c) files that are part of Wise Clock 4 library (but also supplied in the zip file). The software should work with any Arduino connected to a serial WiFly and a 3216 display from Sure Electronics.

The plan is to integrate this code as a new application in the Wise Clock 4 software. Stock symbols should be user-configurable and read from the SD card (as opposed to being hardcoded as they are now).
Also, the direction of the stock move, read from the http response as well (after the token "change"), could be shown in red for "down" and in green for "up".

Post data to cosm.com with WiseClock4 + WiFly

Last weekend I re-discovered cosm.com, formerly known as pachube.com.
After spending a lot less time than I had planned (since things went so smoothly), I was about to post details about the experience; then I saw this fresh post on sparkfun, which pretty much explains everything one needs to know about creating an account and sending data.

The main difference between sparkfun's setup and mine is the connection to internet: I used the WiFly module plugged into the WiseClock4 board. Therefore, the code is a little bit different too: I used the great WiFly library, which even comes with a (little dated) "pachube client" example. All one needs to do is provide the right parameters (app key, network ssid, password etc) in credentials.h, then change all references from "pachube" to "cosm".

As a quick experiment, I read the value from (disconnected) A0 every 25 seconds, and this is how the cosm graph looks like:

A user-friendly cosm-client device based on WiseClock4 with WiFly (which, by the way, seems to be the cheapest way to connect to a WiFi network) would read the configuration parameters from a file on SD card (then, for security reasons, delete the file and store those parameters in eeprom) or provide a way to receive these parameters (ssid, password, app key etc) from a smart phone through bluetooth.

(To be continued)