Friday, May 10, 2013

Miscellaneous

1. Some time ago I did some (unpaid and unaccredited) work for a kickstarter project that ultimately failed to raise the required funds. My task was to develop a prototype board that can read data from a sensor and post it over WiFi to a web site (cosm.com-like). The board I designed was based on readiymate, piggybacking on its capability to update the software "over the air" (through WiFi), which at the time seemed to be the only board offering this feature. Although a readiymate-based system is not cheap nor sophisticated enough (design and feature-wise) to become a commercial success (like the Nest thermostat, for instance), it relies on easy-to-find off-the-shelf components, it is open source and Arduino-compatible. So, it is easy to modify, adapt, hack and support.

Here are some photos of my readiymate-derivative board, for the record, and also with the hope that someone may find it interesting enough to pick up the pieces and develop it further.















Please contact me if you have a need for this PCB or you want to buy one.















The board (which was not even given a name), has just 2 major components: the ATmega1280 microcontroller (also found in the first generation Arduino Mega) and the WiFly RN171 module.
The sensor module gets plugged in the pair of 6-pin female headers (compatible with the JeeLab's JeeNode, apparently). The button is normally used for switching to setup mode (allowing user-configuration of the board, so it can get the name of the WiFi network and the password), as described in this post.















At some point we considered replacing the ATmega1280 with the cheaper, but as powerful, ATmega1284 (as used in Wise Clock 4), thus saving about $4 per board. Although the bootloader could be easily adapted, due to time constraints we preferred to go with the tested and proven solution (ATmega1280) instead.

A project that comes close (it is actually way ahead of the one shown here) in terms of requirements (size, cost, power etc.) and functionality ("over the air" software updates etc.) is the SparkCore: Wi-Fi for Everything (Arduino compatible).


2. Posterous.com blog site (which hosted some quite interesting microcontroller projects authored by "rossum", as far as I remember) just closed its doors. Could this happen to blogger.com /blogspot.com? I honestly thought that the internet can only grow, and every piece of contribution is recorded forever. Well, I was obviously wrong, if the internet is ever to become a "living" thing, some parts of it must die off occasionally, like branches of a tree, I imagine.


3. I recently discovered some interesting open source clocks that use the same 3216 display as Wise Clock 4:
Both clocks look like well-designed finished products, with elaborate enclosures and lots of features, including playing audio files from SD card (using the Wave Shield).

Saturday, May 4, 2013

Hacking Wise Clock 3/4 - Graphical Audio Spectrum Analyzer

For those who asked how to add hardware and software to their Wise Clock 3 or 4, here is a step-by-step recipe, using the example of a digital vu-meter. The hardware itself is nothing new, based on the MSGEQ7 "graphic equalizer display filter" chip. The minor challenge is adding the multi-band vu-meter application to the existing Wise Clock 3/4 software.

Step 1.
First make sure that the new hardware works on its own. Connect it to an Arduino and test it with a sketch that performs the desired functionality. This sketch will be the base code for your new Wise Clock 4 "app".

In my example, I assembled the circuit shown below, where the MSGEQ7 and the 3216 display are connected to an old seeeduino. The 3216 display is connected to the same digital pins used in Wise Clock 4 (D12, D13, D14, D15). The MSGEQ7 chip uses analog pin A2 and digital pins D2 and D3 (these will  need to be later adapted for Wise Clock 4).















The little green "appendix" connected to the MSGEQ7 board is the IN-ZX-Sound microphone amplifier, which could be replaced with the cheaper and probably better version from Adafruit.

The working vu-meter sketch (compiled and tested in Arduino 1.0) can be found here.


Step 2.
Re-wire the hardware to the Wise Clock 3/4 board, using digital and/or analog pins that are not already taken, like D18, D19 and A0-A7 (check schematic here).

Note: Some "already taken" pins could be re-assigned, but the original functionality that they provide will be lost. For example, you could re-use D20 and D21, which are currently involved in serial communication with the BT module (through SoftwareSerial library, look for USE_SOFTWARE_SERIAL macro in WiseClock.cpp), but then communication with the module will be disabled.

In the example, since the 3216 display is already connected (D12-D15), I only had to find two available digital pins (the only choice being D18 and D19) and one analog pin (A0) to connect the MSGEQ7 chip to the ATmega644/1284.

After soldering the 5 wires (3 signal, Vcc and GND), the hacked WC4 board looks like this. (Note that the yellow wire in the photo is left unconnected.)















Step 3.
Make sure that the code that worked with Arduino (in Step 1) still works with the Wise Clock 4 board (target board "Sanguino" or "Sanguino with Atmega1284/16MHz" in Arduino IDE), after the hardware and software changes.
In my example, because I am using D18 and D19 (also used by JTAG), I had to disable JTAG in the code, using these lines:

uint8_t tmp = 1<<JTD;
MCUCR = tmp;
MCUCR = tmp;

This is the Wise Clock 4 with the display and the attached VU-meter board:















Step 4.
Now we focus completely on the software. To add a new app to the existing Wise Clock sketch, start with creating 2 new files (.h and .cpp) for the new app class. One easy way, for example, is to copy the files AppLife.h and AppLife.cpp and rename those copies AppVu.h and AppVu.cpp, then delete the implementations of the 2 functions (init() and run()) . After updating their content, the 2 new files should look like the ones below.


// file AppVu.h
#ifndef _APP_VU_H_
#define _APP_VU_H_

#include "Arduino.h"

class CAppVu
{
public:
  void init();
  int16_t run();
};

extern CAppVu appVu;

#endif  // _APP_VU_H_




// file AppVu.cpp
#include "AppVu.h"
#include "HT1632.h"

void CAppVu::init()
{
  // todo:
}

int16_t CAppVu::run()
{
  // todo:
}

CAppVu appVu;



Step 5.
Modify WiseClock.cpp to include the new header, add new menu item ("VU"), reference the global single instance of this class (named appVu in this case) etc. Basically, add the following lines (in the appropriate places):


#include "AppVu.h"
...
// add to enum of menu item indexes
#ifdef _APP_VU_H_
MENU_VU,
#endif
...
// add the menu item display string
#ifdef _APP_VU_H_
const char menu_str_vu[] PROGMEM = "VU";
#endif
...
// add to const char * menu[] PROGMEM = {...
#ifdef _APP_VU_H_
menu_str_vu,
#endif
...
// in WiseClock::processButtonSet()
#ifdef _APP_VU_H_
case MENU_VU:
crtApp = APP_VU;
appVu.init();
--item;
isMenuActive = false;
break;
#endif
...
// in WiseClock::runCrtApp()
#ifdef _APP_VU_H_
case APP_VU:
ms = appVu.run();
break;
#endif


In file WiseClock.h add the name of the new app (APP_VU) at the end of the enum:

// names of the possible "applications";
enum { APP_QUOTE, APP_UTC, APP_BIG, APP_LIFE, APP_DEMO, APP_PONG,  APP_PACMAN, APP_LIVED, APP_SCORE, APP_STOPW, APP_CNT_DOWN, APP_WORDS, APP_MSG, APP_STATS, APP_TCLOK, APP_TIX, APP_LINES, APP_SUN, APP_ANIM, APP_LOG_CLEAR, APP_TMP, APP_NEWSD, APP_VU };

After all these changes are done, make sure that the Wise Clock sketch still compiles (even without the functions CAppVu::init() and CAppVu::run() implemented).


Step 6.
Implement the functions init() and run() of the new class (CAppVu::init() and CAppVu::run() in my example). The code for init() should be copied from the function setup() of the prototype sketch (in Step 1).

void CAppVu::init()
{
  // disable JTAG;
  uint8_t tmp = 1<<JTD;
   MCUCR = tmp;
  MCUCR = tmp;

  // MSGEQ7;
  pinMode(analogPin, INPUT);
  pinMode(strobePin, OUTPUT);
  pinMode(resetPin, OUTPUT);
  analogReference(DEFAULT);

  digitalWrite(resetPin, LOW);
  digitalWrite(strobePin, HIGH);

  clearDisplay();
}

The code for run() comes from the loop() function in the prototype sketch of Step 1.

// show 2-columns bars for each of the 7 channels;
int16_t CAppVu::run()
{
clearDisplay();

digitalWrite(resetPin, HIGH);
digitalWrite(resetPin, LOW);

for (int i = 0; i < 7; i++)
{
digitalWrite(strobePin, LOW);
delayMicroseconds(30); // allow output to settle;
spectrumValue[i] = analogRead(analogPin);
digitalWrite(strobePin, HIGH);

  // try to eliminate some noise;
if (spectrumValue[i] < 100)
      spectrumValue[i] = 0;

int x = i*5;
int vu = spectrumValue[i]/64;
  if (vu <= 8)
  {
    ht1632_line(x, 15, x, 15-vu, GREEN);
    ht1632_line(x+1, 15, x+1, 15-vu, GREEN);
  }
  else if (vu <= 12)
  {
    ht1632_line(x, 15, x, 8, GREEN);
    ht1632_line(x+1, 15, x+1, 8, GREEN);
    ht1632_line(x, 7, x, 15-vu, ORANGE);
    ht1632_line(x+1, 7, x+1, 15-vu, ORANGE);
  }
  else
  {
    ht1632_line(x, 15, x, 8, GREEN);
    ht1632_line(x+1, 15, x+1, 8, GREEN);
    ht1632_line(x,  7, x, 4, ORANGE);
    ht1632_line(x+1,7, x+1, 4, ORANGE);
    ht1632_line(x,  3, x, 16-vu, RED);
    ht1632_line(x+1,3, x+1, 16-vu, RED);
  }
}
}

Note that the CAppVu::run() uses a new display function ht1632_line(...), which needs to be added to HT1632.h and cpp.


Step 7.
Compile, upload and test. Then improve, extend, publish and brag about it :)



Homework
Add graphic effects (e.g. display like a 6-inflection point graph), selectable from menu (follow example of the UTC app).


Thursday, April 4, 2013

The Akafugu Nixie Clock

I like Nixie tubes, especially when they are used in clocks, like this one I built a while ago. Although almost all Nixie clocks look the same, sometimes there is one that catches the eye. Such as the case of Agafuku Nixie Clock, designed in (and shipped from) Japan. The first thing to notice is that the final clock built from this kit is complete with enclosure, a rare find in the world of Nixie clock kits. Then, there is the look: simple, yet elegant, compact, yet functional. Obviously, I wanted one. Per, from Akafugu Corporation, graciously accepted to barter their Nixie clock kit for my Wise Clock 4 kit. Following is my brief review.


The Akafugu Nixie clock kit looks professional starting with the box. Here are a few photos to prove that, taken as I was opening the package.



















I was surprised to find a power adapter included!

















The clock's electronics are distributed onto three PCBs, shown in the photo below:
  • the power board (on the left), containing the 5V regulator and the high voltage switching-mode power supply; this board is SMD-only and all parts are pre-soldered;
  • the control board (on the right), which contains the microcontroller and the Nixie driver; this board is mainly through hole, the sole SMD component (pre-soldered) being the RTC (DS3231);
  • the display board (middle of the photo), designed to fit IN12 Russian Nixie tubes; this board also has some SMD parts pre-soldered (LEDs, connectors etc).















Remarkable and original is the fact that two of the PCBs are actually part of the enclosure: the power board is the back panel, the display board being the front panel. For the back panel, this is pulled off by using only SMDs, with no traces or pads on the outside part of the board. Did I mention that the power board comes with all (SMD) parts already soldered?

The inclusion of the boards as part of the case is a novel approach, worth applying to future projects, with obvious advantages (reduces the number of fasteners/screws/standoffs, eliminates the attachments between the PCBs and the front/end panels etc).


I assembled the clock following the detailed instructions provided. Most of the required soldering is on the control board. Some attention must also be paid to positioning of the Nixie tubes on the display board before soldering them. After about an hour of work I had the Akafugu Nixie clock up and running. The result is shown in the photos below.




























Beside being a cool geeky gadget, Akafugu Nixie clock can also be used as a functional alarm clock. The clock's functions are set by using the rotary encoder. Each tube can be lit up by an RGB LED (placed right under). The software, Arduino-compatible, is open source and can be modified using the Arduino IDE, then uploaded through the 6-pin FTDI interface/connector.

An improvement I would do is to allow for the easy replacement of the Nixie tubes, in case one gets burnt out (as it could happen with tubes, in general). This can be achieved by soldering tube socket pins on the display board instead of soldering the tubes directly to the board. I am sure Akafugu thought of this already, but they may have opted against it because it makes the Nixies stick out a bit more. I was actually going to follow up myself with this improvement, but the socket pins I found are too thick (~2mm) to go through the 1.5mm holes.


Overall, I was impressed with how nicely designed and well engineered this clock is. As a kit maker myself, I can appreciate the amount of work that went into creating this kit, from designing the hardware, to choosing the components, to cramming them all in such a compact space, to writing the software. Kudos for making it so easy to assemble, even by a beginner, with spectacular results.


For someone who likes Nixie clocks, the Akafugu Nixie clock is definitely a must-have.
Those who like clocks should add the Akafugu Nixie clock to their collection.
Those who like electronic kits will find the Akafugu Nixie clock kit inspirational.

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.

Monday, December 31, 2012

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.