Friday, February 22, 2013

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.

3 comments:

  1. Hi Florinc
    First of all I think that the Wise Clock 4 is relay something outstanding job!
    And thank you for sharing.
    I built a Wise Clock 4 by hard wiring it all and using the 40 dip of the 644P and the 1284P.
    No problems bootloaders installed code runs without any issues.

    So I decided to build my own variant of the Wise Clock 4 using as much SMD as I was able to.
    So designed up some board and had them made load them with all the parts.
    Not we are down to the issues I built a board with the 644P in a 44 pin TQFP package.
    I down load the sanguino bootloader for the 644P and it worked without an issue.
    I moved on to the 1284P 44 pin TQFP and down load the sanguino bootloader without an issue but when I try and upload a sketch I get a varavaction error.
    Have you used the TQFP package?
    Any ideas?
    Geckospot Nixie

    ReplyDelete
    Replies
    1. Thanks.
      I did not try the SMD versions of 644 and 1284. In theory, they should work the same, since they are pin-compatible.
      I never heard of "varavaction error". But if you mean "verification error", yes, that's somehow normal, take a look at this post:
      http://timewitharduino.blogspot.ca/2012/03/wise-clock-4-with-atmega1284.html

      Delete
  2. Sorry for that I did miss spell that and I knew it and forgot to go back and fix it.
    Yes I was talking about “verification errors”
    I just don’t understand why the sanguino bootloader will not work with the TQFP 1284P.
    It works with the 40 dip without an issue.
    On the 40 dip board I can load and run all Wise Clock sketch.
    What part does the bootloader play in the sketch?
    I found a bootloader the Mighty-1284P project, loader “optiboot_atmega1284p” that works.
    So I changed the board file to make a custom board and burn the bootloader to the 1284P and was able to upload sketch.
    But now the issue I can upload the older Wise Clock 4 the small one and it runs without issue reads the Micro SD card and all.
    But if I upload the Wise Clock 120707 that sketch will not run at all that I can see.
    Does Wise Clock 120707 sketch out put debug data on the serial port?
    I did not try and look for any.
    I may need to put some in.
    Geckospot Nixie

    ReplyDelete