Software user

The WiFiChron code, with support for ESP8266, nearly reached the program memory limit of ATmega328, yet still missing a few features, the most important being the much needed debugging capability. Naturally, the next step in WiFiChron 's evolution was to upgrade to Atmega644P/1284P. Since there was no room on the board for the 40-pin DIP package, I settled for the SMD version. The schematic is shown below. Although functional, the board I designed is far from perfect: requires pull-up resistors for buttons; I relied on software pull-up, but that does not work in the current Sanguino library; requires a couple of more decoupling capacitors; (I soldered all these extra parts on the bottom side of the PCB, as shown in the next photo. The 595 shift-register is soldered on the bottom by design. The next revision will have the currently missing parts in the SMD package.) The WiFiChron-1284 board has the same dimensions as the previous revision , and it still fits in the Serpac A20 box....

The peculiar feature of the "May 2015" revision of WiFiChron board is that it was designed to use software serial to communicate with either the XBee or ESP module. The reason is related to debugging. I wanted to be able to send messages to the serial monitor while (software serially) communicating with the serial device. This solution works well for XBee ( GPSBee , BTBee ), but not for ESP8266, only because the software takes more than the available 2K of RAM in this case (WiFi + software serial). The immediate fix to use the ESP module is to connect its Rx/Tx lines to Rx/Tx of the processor. The existing connections can be left uncut, since they are not used in the sketch for ESP8266 . The wiring should be like in the photo below. The "permanent" fix would be re-designing the board to use ATmega1284 SMD (DIP-40 would not fit). Talking about 1284,  take a look at Farit's WiseClock4 mod. He used the WiseClock4 board, but completely re-wrote the software, in...

Update Sep 18, 2017:   Here is the latest revision of the PCB included in the kit. Update Oct 8, 2015 : The latest revision of the PCB (pictured here and here ) has hardware support for XBee (which also covers GPSBee, WiFiBee and BTBee). With this kit you build a clock like the ones shown in the photos below. Last one, courtesy of Nick, features an yellow/amber display. There are two buying options: 1. use or make your own enclosure  (US$47, free shipping to North America) 2. enclosure included ( Serpac A20 , transparent front panel, screws, back panel hand-drilled with 3 holes for buttons and rectangular opening for the USB connector )  (US$61, free shipping to North America) The kit includes the following electronic parts: main PCB display adapter PCB ATmega328 with 8MHz bootloader, programmed with a clock sketch + 28-pin socket 74HC595 shift register + 16-pin socket HDSP-2534 8-character alphanumeric display + 4 x 6-pin machined headers DS3231 + ...

With the new ESP8266 module, adding WiFi to any Arduino project became a lot cheaper. This module has a serial interface; therefore it only requires connecting 4 pins: Tx, Rx, 3V3 and Ground, as shown in this image. A few peculiar facts about ESP8266: default serial baud rate is 57600; since this rate is too high for SoftwareSerial library, a hardware port should be used; requires 3V3 for power and level shifting for Rx signal (5V to 3V3); physical interface is a 2x4 pin male header; firmware can be upgraded to a version that allows 9600 baud rate; can be used either as client or server. The first two characteristics makes it a perfect candidate for a module with an XBee footprint, as is WiFly , for example. It took me about half an hour to do it, following these steps. cut a piece of 2-mm perfboard to the XBee dimensions; solder two 10-pin the 2-mm-spaced male headers on the sides; desolder (using wick) the 2x4 header; mechanically attach the header-less ESP8266 module to the XBee p...

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

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

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

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

This was a bit of a struggle, working with the XBee-footprinted WiFly RN-XV module  from Roving Networks. The goal was to get some data from the RSS feeds, kind of what this project had achieved. First, I tried to set up the RN-XV module following this crash course  (and using ladyada's XBee adapter  with the FTDI cable). Everything went fine except connecting to my home WiFi network: I kept getting "AUTH-ERR". Eventually, after many tries, the module joined the network. I thought this is caused by the weak WiFi signal and other people may experience a similar scenario (which should be dealt with by the software). Then I found with this software library, which, of course, did not work in my special case. After I started tweaking it and read the RN-XV manual once again, I found the explanation: WPA (which I am currently using) handshaking takes more than 1,000ms (1 second), which is the default timeout for the module. The solution was to increase this timeout (to 50...