Play WAV files from SD card with Wise Clock 3/4 board

The video below shows another hack for Wise Clock 3/4, playing a WAV file directly (not using extra hardware) from SD card, with the help of the TMRpcm library.



The TMRpcm software uses the standard SD library (coming with Arduino IDE 1.0 and later) to read WAV files from SD card. To output the audio while buffering the content of the SD file, TMRpcm uses ISR triggered by internal timer. The buzzer/speaker can be connected only to certain pins of the processor. For ATmega1284/ATmega644 (used in Wise Clock 3/4), these pins are D3, D4, D12, D13, D14 and D15, as shown in the definition below (from sanguino core file pins_arduino.c).

From the perspective of TMRpcm library, the buzzer in Wise Clock 4 is connected to the "wrong" pins, D22 and D23, which are not eligible for this trick. I chose to connect another speaker to pin D13, but that's already taken by the display (CS, pin 1). So I had to cut the trace from D13 to the display, and connect pin 1 of the display to D18 (another choice was D19, the only other available I/O left).

From now on it's only software.

• modify this line in HT1632.cpp:

    #define HT1632_CS 18 //  Chip Select (pin 1 of display connector)

• add line

     #define SPEAKER_PIN1  13

Then follow from step 4 of this previous post.

Unfortunately, this will not work with Wise Clock 4 software as is, and the main reason is the timer interrupts used by TMRpcm library, which disrupt the "SPI-like" commands for the display.

The video above may seem like another Wise Clock "app", but it is just a "cheating" sketch running standalone, shown below.


#include "Arduino.h"
#include "Wire.h"
#include "DS3231.h"
#include "HT1632.h"
#include "AlarmClock.h"
#include "WiseClock.h"
#include "SD.h"
#include "TMRpcm.h"
#define SD_ChipSelectPin   4
#define AudioPin          13  // must be PWM pin

TMRpcm tmrpcm;

//**********************
void setup()
{
  Serial.begin(9600);

  // disable JTAG (to use pin D18);
  uint8_t tmp = 1<
  MCUCR = tmp;
  MCUCR = tmp;

  ht1632_setup();

  SD.begin(SD_ChipSelectPin);
  tmrpcm.speakerPin = AudioPin;
}

//*********************
void loop()
{
  alarmClock.isAlarmEnabled = true;
  alarmClock.getTimeFromRTC();

  Serial.print("Time is: ");
  Serial.print(alarmClock.hour, DEC);
  Serial.print(":");
  Serial.print(alarmClock.minute, DEC);
  Serial.print(":");
  Serial.println(alarmClock.second, DEC);
  
  if (!tmrpcm.isPlaying())
  {
    ht1632_putTinyString(0, 0, "Playing", RED);
    wiseClock.displayTime(8, false);
    tmrpcm.play("dancing.wav");
  }
  delay(2000);
}

The display is statically updated once, before the WAV file starts playing.

It would probably be possible to update the display between playing short WAV files (with interrupts disabled right after each file is played). But that may open a door to other set of problems, since the display is practically frozen for the duration of the file playing. On the other hand, the I2C (through Wire library) works just fine (that's because I2C is hardware driven), so getting the current time from RTC while playing music is not an issue.

Conclusion
Although in theory would be possible to integrate TMRpcm library in the Wise Clock software (to play WAV files from SD card while the clock functionality is not affected), in practice that would take a lot of programming effort. A much easier and cheaper way to include audio into Wise Clock 4 (hardware and software) would be through the use of serially controlled audio-playback specialized modules, like this one (or maybe even the radio/MP3 module I reviewed here, if I ever find it in my pile of stuff).

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:

• Xronos Alarm clock - ATmega644, sound with adafruit Wave Shield;
• Open Clock project - Arduino with ATmega328, touch screen, sound with Wave Shield;

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

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

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.

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.