Wise time with Arduino

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

2013-05-15T20:13:00.003-04:00

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

2013-05-10T10:45:00.000-04:00

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.

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

2013-05-04T18:16:00.002-04:00

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

2013-04-04T11:28:00.001-04:00

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

2013-02-22T12:13:00.000-05:00

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

2012-12-31T16:55:00.001-05:00

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

2012-10-16T20:39:00.001-04:00

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

2012-10-09T22:20:00.000-04:00

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

2012-09-06T10:53:00.001-04:00

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)

From customer email

2012-08-26T10:47:00.000-04:00

Just wanted to let you know I finished putting together my Wise Clock 4 and it looks and works great! Only took me about 6 months to get started it J. Thanks for putting together such a nice kit. I didn’t install an xbee on it yet but hope to experiment with that sometime this year. I really like all the different modes – and have to read up on what they all do. Is there a good link you can point me to that describes them? Hope you are still working on new clock ideas. Think I saw your name as a supporter of the word clock out on kickstarter?

Bill

On the 3216 LED display from Sure Electronics:

I did look at the clocking relationships on the scope.
The clock to data hold timing on the HC164 was marginal, 2ns, versus -2ns typical and 4ns minimum. Meaning it will probably work, but it's not certain. CLK, DATA and WR are buffered through 2 sections of an HC04, with a delay of 11ns, but CS_OUT is not, so with every successive board in a chain this timing degrades. They ran out of HC04 gates. Installing the 10pf capacitor at C1 might help, but it's not ideal.

Don

The zip file did the trick. I now have them both up and running.

I've attached a pic for your viewing.

Brian

Just wanted to let you know that I received my kit yesterday and have already put it together. I was surprised, having not done any soldering in a long time, that it went together easily and worked on the first try!

Michael

Big Thank YOU guys!

Wise Clock 4 - Status update

2012-08-09T22:00:00.002-04:00

It's been a slow (and hot, temperature-wise) summer, spent mostly answering customer (and other arduino fellows asking for help) emails, with almost no notable achievements.

Improved the design of the Wise Clock 4 board by adding support for the JY-MCU bluetooth module (didn't receive the boards yet).
Created the software framework for a Scheduler (subject of a future post); this should support features like multiple alarms, job activation at given times etc.
Beside his great contribution to the code, MikeM found a fix for the SoftwareSerial bug on ATmega1284P (D20 and D21 did not work because JTAG is enabled); he also sent this photo of his stack of Wise Clock 4s with dual 5mm LED displays.

Added to my to-do list:

Android app to remote-control Wise Clock 4;
remote sensors to start and stop the chronometer function of the clock (request from Javier);
join a WiFi network in a user-friendly, easy-to-configure, manner;
automatic adjustment of the display brightness with an LDR, as suggested by Adam, who already hacked his Wise Clock 4, as shown below.

I also got a bit angry with Sure Electronics for the (mechanical) change on their latest revision of the 3216 LED display: the vertical distance between the holes is about 3mm greater. I thought I would have to give away the small stock of laser-cut plates I had, since they would not fit anymore. Turns out that there is a non-wasteful solution though: enlarge the holes with a small file (which I do myself to all displays, until I finish the old stock of plexiglass plates).

As always, any comments, suggestions and contributions are appreciated.

Wise Clock 4 with the 5mm 3216 LED display

2012-07-07T10:03:00.003-04:00

The Wise Clock 4 board was designed to be plugged directly into the 3mm 32x16 LED display from Sure Electronics. I am often asked how it would connect to the 5mm 32x16 LED display.
The photos below will give the answer to this question.

First, the 2x8-pin female header provided with the kit needs to be replaced with a 2x8-pin male header (or two 8-pin male headers side-by-side). Place the header on the top side, as shown in the picture above.
Ideally, a "shrouded 2x8-pin header" (like this) should be used here, since that will also force the ribbon cable connector to be inserted with the right orientation (notice that the peg is closer the FTDI connector).

Then connect the board to the display using the ribbon cable (coming with the display), as shown in the next photo, and very importantly, paying attention to the orientation of the connector.

In case you wanted to chain a second display, just connect, with a second ribbon cable, the OUT connector of the first with the IN connector of the second.

The Wise Clock 4 software is able to correctly handle the second display if you modify this line in file HT1632.h, from

#define NUM_DISPLAYS 1

#define NUM_DISPLAYS 2

When fully lit, the current consumption of the displays are around 500mA. The best way to power them, especially when chained, would be through the terminal block, with the the red and black wires (as shown). In this case, the Wise Clock 4 board is powered from the display (through the ribbon cable), so you don't need to use an USB cable.

The easier alternative is to use the USB cable. This will provide power to the display(s) as well, but the voltage to the second display may drop below 5V, thus making it less bright, or even behaving erratically. Also, keep in mind that the USB port on a PC may not be able to supply the current for two displays (1A or so). If you notice problems with the second display, first step is to check the voltage to be around 5V.

NOTE: Make sure you use a 5V regulated power source. Anything above 6V will fry the board, and probably the display too. Also, make sure your power source is adequate for the power consumption. Use at least a 2A (10W) power source.

Animation on Wise Clock 3/4

2012-06-29T17:56:00.000-04:00

Mr Ruud did it again :) He took this video showing a few more features he added.

1. ANIMATIONS

It is now possible to create your own animations which are stored on the SD card.

The APPS menu entry ANIM allows for continously showing one or all animations files.

Animation files are named: anim0.wc3 - anim9.wc3.

There are also 4 special animation files named: time00.wc3, time15.wc3, time30.wc3 and time45.wc3.

If ANIM+ is selected in the SETUP menu and the BIG mode is active then every quarter the correponding animation is shown once with a random speed.

Besides the four time*.wc3 animation file, there are currently 4 sample animations: anim1.wc3 - anim4.wc3.

You may create your own animations (there is NO programming involved) by creating individual screens in Excel and then use a small conversion program to create the *.wc3 file.

As the animations are stored on the SD card you can make them as big as you like.

2. LOGGING

If the LOG+ menu is selected in the SETUP menu then the following items will be logged in the wc3log.csv file:

every hour the current temperature is logged both in Celsius and Fahrenheit (32.5 degrees is stored as 325)

all entries created in the time clock (TCLOK) app are now stored in the log file

The wc3log.csv file is an ASCII Comma Separated Values file, which can be opened in Excel for further analysis (or for creating graphs etc).

The average log record is about 25 bytes long. The temperature logging will take 24 x 25 bytes = 600 per day. (So the 2 Megabyte log file will be full after about 9 years.)

A warning message ("log= @ End") will be shown when the log file is almost full, an error message ("log= FULL!") will appear if no more records can be written to the log file.

The SETUP menu entry CLRLG allows for clearing the complete log file, it will take about 10 minutes to clear a 2 megabyte log file.

Mike M. integrated all of the above changes with a previous version that works with FAT32. This code is available here.

Wise Clock 4 with integrated Bluetooth

2012-06-01T18:23:00.001-04:00

Wise Clock 4 can now hold a Bluetooth module outside of the XBee socket, as shown in the pictures below.

The communication with the BT module uses SoftwareSerial on pins D20/PC4 (Tx) and D21/PC5 (Rx).
The module is powered with 3V3 and the Rx line is level-shifted.

I bought a few of these Bluetooth modules from different sources, mostly ebay. Some of them did not work: my PC's Bluetooth could not "discover" them. Once SMD-soldered to the board, it is very difficult to figure out what's wrong and even de-solder and remove them. My advice for anyone using these modules is to check them before soldering them to any board/breakout. An easy way to do this is to solder wires on pins 12 (Vcc) and pin 13 (ground), as shown in the photo below (left), power with 3.3V, then try to pair it with a Bluetooth host (PC, Android; iPhone won't work since it requires an Apple-approved chip).

The module's relevant pins are shown in the diagram below (photo from ebay seller):

I did not test this myself (the experiment may cost about $7), but it seems that these Bluetooth modules only tolerate approx 3.3V and powering with 5V will fry them.

If you already have an Wise Clock 3/4 and want to add Bluetooth functionality (simultaneous to WiFi or XBee), you can add this module to the clock. Connections are through 4 wires: Rx/Tx go to D20/D21 (pins 26 and 27 of the processor), VCC to 5V, GND to ground. Note that this module has on-board power adapter for 3.3V and level-shifter for the logic lines.

DWex mod

2012-05-30T11:18:00.001-04:00

From Gerard:

Hi Florin,
I had some spare time and moved on with the software mods on the DWex.
The mods are:
- display is always on (means you need to power by NiMH or wall supply)
- small animation after reset (test all the LED's)
- small animation at full 5' (solid) minutes
Feel free to distribute/publish the mods if you feel appropriate.
Best Regards
gerard, DL8SEL

The sketch is available for download here.

Thank you Gerard. Keep up the great work!

Wise Clock 4 with remote "Alarm stop" button

2012-04-19T18:55:00.002-04:00

The Ramos project brought the novel idea of a wireless alarm-stop button: instead of just reaching out to press on the top of your nightstand alarm clock, you now have to actually get out of the bed and walk to a remote corner of your dwelling to click on a keypad. No chance you will return to sleep afterward :)

This remote alarm-stop feature for Wise Clock 4 can be implemented in several different ways, all of them using of the on-board XBee socket:

through a Bluetooth module;
through WiFi, using the Roving Networks WiFly module;
through XBee radios.

The cheapest and easiest would be the Bluetooth solution, providing that you already have a BT device (e.g. Android phone/tablet) to communicate with. In pseudo-code, it should look like this:

if (alarm is ON)
{
while (Serial1.available())

{

read characters received;

if (it is the expected string)

{

set alarm OFF;

}

The WiFi solution would require a second WiFi device (phone/tablet) to access a web site, or maybe they could talk directly (sockets), using their IP addresses.

The solution based on XBee relies on direct communication between two XBee radios. One would have to build the remote device, probably around an Arduino, with a keypad and an XBee.

Guest post: Wise Clock 3/4 Apr-2012 software release

2012-04-19T17:36:00.004-04:00

Updated Apr 20/2012
David M. mentioned an important detail: if you try to compile with Arduino 1.0 on Mac OSX you will get the error "You can't have a cpp file with the same name as the sketch". The quick fix is to change the name of the file WiseClock4.ino (to TheClock.ino, for example). Interestingly, although it makes sense, this error does not show in Windows.
-------------------------------------------------------------------

Here is the email I received from Mike, who took on the challenge to fix and improve the code for Wise Clock 3/4, available here. Thanks Mike, keep up the great work!

My note: If you don't feel very confident about upgrading the software on Wise Clock 3/4, please do not do it.

I combined WiseClock3/WiseClock4 into one distribution, creating a WiseClockVer.h file with a
   #define _WISE_CLOCK_VER 3
line. HT1632.cpp and Buttons.h include WiseClockVer.h, and use lines like
#if _WISE_CLOCK_VER > 3
#define HT1632_CLK      15      // clock pin (pin 2 of display connector)
#else
#define HT1632_CLK      11      // clock pin (pin 2 of display connector)
#endif
That way the same distribution can be used for Wise Clock 3 or Wise Clock 4, and only one line has to be changed.

I found some places where over 100 bytes of data are copied into msgLine, overflowing the buffer. Rather than just increasing the size of QUO_MSG_LEN, I changed all references to QUO_MSG_LEN to use MAX_MSG_LEN instead.

When reading a quote line a prefix character of Control-R (^R) will display the quote in red. A prefix character of Control-O (^O) will display the quote in orange.

I removed all floating-point operations in favor of scaled integers. For AppPong I scaled by 256, for temperature I scaled by 4 as the DS3231 is only accurate to 0.25 degrees. I found that when the high and low temperatures were scaled by 10 and displaying farenheit that today's high could be 0.1 degree lower than the current temperature due to round-off errors. These errors are avoided by saving the temperature scaled by 4 instead of 10.

I added a DST flag to indicate Daylight Savings Time is in affect. DST+ sets the flag and advances the hour by one, DST- clears the flag and retards the hour by one. The DST settings in the message file are still honored, setting the flag and incrementing the hour (if the DST flag is clear) or clearing the flag and decrementing the hour (if the DST flag is set) at the appropriate time.
The DST flag is used in the UTC code so the UTC offset is set once. There is no need to change the UTC offset when Daylight Savings Time starts or ends.

I changed the sign of the UTC offset, so '-5' is now correct for Eastern Standard Time. UTC + offset = current time.
Negative UTC offsets could not be restored properly, as -5 when retrieved would come back unsigned as 250. I worked around the problem by adding 24 when saving to EEPROM and subtracting 24 when reading the EEPROM.

I changed the resolution of AppTimeLived's makeTime() from seconds to minutes. The displayed seconds are calculated by taking the delta of the current second specified birth second, so makeTime() does not need the extra accuracy. This change allows the offset to be calculated from 1900 instead of 1950. With a second resolution and base of 1950 makeTime() would wrap in 2018. With a minute resolution and a base of 1900 makeTime() won't wrap for another ~4000 years.

I changed the DEMO mode so it cycles through several display modes. The number of minutes to display each mode is selected on the first screen after DEMO is selected, going from 0 minutes to 9 minutes. Ten seconds is added to the cycle time, so selecting "0" goes to a new display every ten seconds.
The original lines Demo is only displayed for ten seconds, regardless of the selected cycle time. The LIFE demo is displayed for fifteen seconds.
I was going to have AppWords as one of the demos, but I'd have to in-line most of AppWords' initialization code in the demo code, so I didn't bother.

I changed AppLife so it now wraps over the edges of the display.

I went through AppPong so all display offsets are relative to X_MAX and Y_MAX. As mentioned earlier, floating point math was replaced by scaled integers. The height of the bat is now a #define and set to 5 instead of the previous version's hard-coded 6. I settled on a color scheme -- ball and pitch are green, score is red, bats are orange. I fixed some bugs in the ball prediction code and the 'flip' code (used to put 'english' on the ball). I changed the 'miss' code to only miss by a few pixels.

The removal of the floating point freed up a lot of space.
It's [the whole sketch] less than 58K bytes.

I'm running the clock now. The only issue is the year's high temperature needs to be re-initialized. It was scaled by 10, now we expect it to be scaled by 4. The nightly comparison won't save a new high temperature because the old one now is 2.5 times higher than it should be. New clocks won't have the problem, but upgrading an existing one will. The yearly low temperature isn't a problem because the scaled-by-four temp will be lower than the scaled-by-ten temp (unless your low is less than 0 C). The work-around is easy, just set the year back by one overnight. In the morning the yearly high/low temp will be reset. The yearly high/low is only displayed in the "STATS" app anyway.

I corrected the life neighbor calculations. The neighbor calculation used to be the sum of the colors for the eight neighbors. This works when only green (1) is used, but when the colors are randomized the neighbor calculations are wrong, as some neighbors could be red (2) or orange (3). I changed the color selection to use green for birth, orange for steady-state, red for dead. The neighbor calculation now looks at the least significant bit of the color. Green and Orange both have the lsb set, so this works well.

A quote-line can now be any length. The quote buffer is replenished when processing is within 24 characters from the end of the buffer and the line was truncated. Additional characters are tacked on to the end of the remaining 24, with no interruption. This will repeat until the entire line has been processed, no matter how long the line is. Reminders and Messages are still limited to 100 characters, and the lines in the Words files are still limited to 175 characters.

Scrolling message sign with Bluetooth

2012-04-08T10:41:00.004-04:00

A simple application for Bluetooth was suggested a while back by fellow arduinoer evanrich (who also created a home for his project on github): a scrolling sign using several cascaded 3216 displays and controlled through Bluetooth from an Android phone. His intention was to use it as a wireless sign that can be put in the back of the car to tell drivers to get off his tail.

I gave it a try myself, using Wise Clock 4 with Bluetooth and two 3216 displays, as shown in this photo (the blue LED on the BTBee is power, the orange one is communication status).

The code is a modified version of the one posted here.

This message sign, especially if it is made with the larger (5mm) 3216 displays, can be also used in waiting rooms, call centers, stores etc, to show dynamic and easily-changeable messages.

Related posts:

Wise Clock 4 with Bluetooth

2012-04-05T23:47:00.010-04:00

Another thing that was supposed to be easy, but it wasn't: Arduino communicating with Windows XP through Bluetooth.

Like everybody, I purchased the cheap and ubiquitous Bluetooth module from dealextreme.
I soldered it myself on the XBee-footprinted PCB (bare BTBee from IteadStudio), for a total price of about $8 (compare that to at least $15 as these Bluetooth XBees go for).

Without knowing much about Bluetooth, I plugged this new "BTBee" module in Wise Clock 4 expecting it to be "discovered" by XP (which has an USB Bluetooth dongle). Discovered it was: the name "linvor" appeared in the list of BT devices, with two serial ports attached to it.

Communication between XP and BT module is performed through the serial ports, I figured. Tried CoolTermWin, HyperTerminal, Putty, on both ports, nothing seemed to work. Time to read the documentation (which always reminds me of that joke). I learned that others had similar problems, and some have solved them by installing new BT drivers. The best advice came from this post. Putty did not work for me, so I stuck with what I had, namely HyperTerminal.

So here is my own step-by-step tutorial on how to make an Arduino communicate with Windows XP via a Bluetooth module.
Note: From the Bluetooth perspective, Wise Clock 4 I used for my testing is similar to Arduino.

1. Upload this simple sketch that "echos" what it reads from Bluetooth and also broadcasts a message periodically. The communication between Arduino and the BT module is serial, with a baud rate of 9600, according to the documentation.

#if ARDUINO < 100
#include
#else
#include
#endif

void setup()

{
Serial.begin(9600);
}

void loop()
{
while (Serial.available())
{
// get char from bluetooth;
char inChar = (char) Serial.read();
// output it back, between brackets;
Serial.print('[');
Serial.print(inChar);
Serial.print(']');
}
// broadcast message;
Serial.print("millis() from Arduino: ");
Serial.println(millis());
delay(2000);
}

2. Power Arduino, with the BT module connected, and let it run the sketch.

3. Make the BT module (on the Arduino) visible to XP, by adding it to the list of Bluetooth devices. For this, click on the "Bluetooth Devices" icon in the tray (bottom right corner of the XP's desktop). You will see this box.

Next, you will see the BT device added to the list, under the name "linvor".

Then select the last option, "Don't use a passkey". Although it makes little sense at this point (since you know that the passkey is 1234, according to the documentation), it is very important to not use a passkey here.

The last step of the wizard shows the two ports that have been added. Write down the "Outgoing COM port", since this is the one we will be using for communication (step 4).

4. Open HyperTerminal to establish the 2-way communication between XP and Arduino, via Bluetooth.
Select, from the list, the COM port specified as "outgoing" for the BT device.

Next, you will be shown this pop-up.

After you click on it, you are prompted to enter the passkey, the one you (reluctantly) skipped in the process of setting up the BT device. Type "1234", as specified in the BT module documentation.

After hitting "Next", you are shown this last confirmation box.

In the same time, the HyperTerminal starts displaying the message coming from Arduino.

Note that, when the COM port was opened in Auto mode, no parameters (baud rate etc) being specified.
Interestingly, after the communication is established, the baud rate is reported as 2400 for some unexplained reason.
You can also type characters in HyperTerminal and they will be echoed back, between brackets, by Arduino.

Optionally, if you want to see what you typed (before the echoing from Arduino takes place), you can enable local echo, by selecting "Properties", then "ASCII Setup".

Once the communication between XP (HyperTerminal) and Arduino is established via Bluetooth, the "Status" LED (if you have it soldered) is on continuously. When the BT module is not communicating, the "Status" LED is blinking at a frequency of about 2Hz.

The next time a HyperTerminal session is opened, XP remembers the BT device and the communication params (ports, passkey) and does not ask to set it up again. (I guess that's why it is called "pairing", although this word does not appear anywhere in the process.)

Time to write some serious applications using Bluetooth:)

BookClock revisited (time setting from buttons)

2012-04-04T21:47:00.002-04:00

By popular demand, I added time setting capabilities to BookClock. Time and date can now be set from two buttons, called "Menu" ("H/M" in the photo) and "Plus" ("+").

Press "Menu" to select between hours and minutes. Press "Plus" to increment the blinking selection. When done, just let it time out (about 4 seconds) and the time will be saved in the RTC.
Hold down "Menu" until the date, formatted as yy/mm/dd, is displayed. Press "Menu" again to select either year, month or day, then press "Plus" to increment the blinking value.

The time-setting code is copied and adapted from IllyClock and uses the same state-machine mechanism.
I connected the two buttons to D16 ("Plus") and D17 ("Menu").

The code, compilable on both Arduino 23 and 1.0, can be downloaded from here.

Wise Clock 4 with ATmega1284

2012-03-26T09:11:00.001-04:00

I thought that replacing the ATmega644P with its bigger brother ATmega1284P in Wise Clock 4 would be trivial. How wrong I was.

The first step was to burn the bootloader. After a bit of research, here is what I found out:

USBtinyISP from adafruit cannot program chips with more than 64K of flash (see this thread);
if you don't want to start from scratch (that is, compile the source code and figuring the fuses) there are at least 3 sources: ryanmsutton, maniacbug and calunium;
USBtinyISP half-works: it writes to the flash, but reading back for verification purpose fails because of a bug in the firmware; I ignored the verification error;
although burning the bootloader (any of the three mentioned above) seemed successful, uploading any sketch afterwards always failed;
the setup from ryanmsutton did not work for me (I guess the fuses are wrong; then the core files also point to the arduino folder, instead of the sanguino, as it should be);
with the bootloader from calunium (atmega1284p_16MHz.hex) I was able to upload sketches; these are the settings in boards.txt I used:

atmega1284.name=Sanguino W/ ATmega1284p 16mhz
atmega1284.upload.protocol=stk500v1
atmega1284.upload.maximum_size=129024
atmega1284.upload.speed=57600
atmega1284.bootloader.low_fuses=0xFF
atmega1284.bootloader.high_fuses=0x98
atmega1284.bootloader.extended_fuses=0xFD
atmega1284.bootloader.path=atmega
atmega1284.bootloader.file=atmega1284p_16MHz.hex
atmega1284.bootloader.unlock_bits=0x3F
atmega1284.bootloader.lock_bits=0x0F
atmega1284.build.mcu=atmega1284p
atmega1284.build.f_cpu=16000000L
atmega1284.build.core=sanguino

Note the upload protocol (stk500v1), note the fuses and note the core folder (last line).

To compile the code for Sanguino with ATmega1284P, some macros must be updated as well, by adding
defined(__AVR_ATmega1284P__) to any defined(__ATmega644P__)

like this:

#if defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega1284P__) // sanguino

In the end, the program space is about 126K (compared to 62K in ATmega644P) and the available RAM is 16K (compared to only 4K in Atmega644P). Not a bad upgrade for only a few bucks more.

Note: ATmega1284 is not defined in avrdude.conf shipped with Arduino 22 or 23 (folder \arduino-22\hardware\tools\avr), but it is defined in Arduino 1.0.

Troubleshooting guide for Wise Clock 3/4

2012-03-25T10:46:00.004-04:00

This should really be a chapter of the assembling instructions for Wise Clock 3/4. Until I integrate everything into a single document, it is just another post that begged to be written (long ago, as a matter of fact).

1. Right after power up, the clock should make a beeping sound. If that does not happen, here are possible causes:

missing input 5V power; the optional power LED may be useful in this case, turned on when the power is present;
reset pin may be shorted to ground (the processor won't execute any code);
processor may not be powered: check that pin 10 has 5V and pin 11 is connected to ground;
faulty or missing the 16MHz clock for the processor; check crystal connections to the pins; if everything looks good electrically, try to upload a sketch; it that still doesn't work, test by replacing the processor or replacing the crystal;
buzzer may be disconnected; check connections between processor's pins and buzzer, shorts to the ground, terminal soldering.

2. The display does not light up at all (assuming the display is not defective):

faults in the connections to the display (right-hand header): look for shorts between neighbor pins in the display header; look for shorts between any signal pins in the display connector and ground;
output header (left-hand) display header may have shorts between neighbor pins or pins shorted to the ground;
the board's female connectors may be misaligned (shifted by one) when plugged in the display's male headers.

3. Getting SD card error in "Quote" mode:

faulty SD card; check the SD card itself by reading it in a PC; must be formatted FAT16 (therefore 2GB or smaller);
the required text files may be missing; check for their presence in the root directory;
SD card may not be powered; check 3V3 power on the third pin from the left (second pin from the left is connected to the ground);
check voltage divider resistors R5, R6, R7 (under the processor) and make sure they are 4K7.

4. Pressing a buttons (Set, Menu or Plus) does not trigger the expected action:

button itself may be defective, either always open (there is no contact between button's terminals when button is pressed) or always closed (short between terminals); verify with a multimeter that the button works correctly;
look for potential shorts between the "active" terminal (connected to the processor pins D0, D1 and D2/D3, see schematic) and ground.

5. Communication error when trying to upload a sketch:

make sure you plugged the FTDI cable/breakout the correct way/orientation, with the Ground/Black terminal to the right;
check the Rx/Tx connections to the processor (pins 14 and 15); make sure that they are not cut or shorted to the ground;
"stk500_getsync(): not in sync: resp=0x00 error" usually indicates that the upload speed is incorrect; for the ATmega644P processor, the upload speed must be 38400 (defined as atmega644.upload.speed=38400 in boards.txt); for the ATmega1284P processor, the upload speed is 57600;
if you get "avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check", temporarily modify the signature in file hardware/tools/avr/avr/etc/avrdude.conf with one of these (depending on your processor):

signature = 0x1e 0x96 0x0a; // for ATmega644P
signature = 0x1e 0x97 0x05; // for ATmega1284P

Stand for ClockTHREE

2012-03-19T09:09:00.000-04:00

Some time ago I received, as a gift, this smart and very useful stand from fellow clock enthusiast Nicholas in San Diego. He designed it and made it specifically for ClockTHREE. Simple yet elegant, this is essential if you want your C3 on the desk or table.

I did not have the chance to appreciate it until now, with an older ClockTHREE borrowed from a friend (I gave it to him as a gift). Here is the C3 on the stand, a perfect fit!

Thank you Nicholas! Keep up the great work!

Wise Clock 4 - "Time Lived" menu option

2012-03-18T15:00:00.000-04:00

At the request of AlexT, I implemented a new feature in Wise Clock 4, which allows the display of time lived (since birth) in different formats (years/months/days/hours/minutes/seconds, days only, hours only, minutes only).

The above photo shows the year/month/day on the top row and the hours/minutes/seconds on the bottom row.

Lifetime in Wise Clock 4 from florinc on Vimeo.

The birth date and time are read from the file message.txt on the SD card.

I was inclined to use the Time library, but I found it a little bulky for my needs and also unsuitable for dates before 1970. Then, I copied and modified the function makeTime() to convert a datetime to seconds, and I wrote my own diffTime() function to calculate the difference (in years, months, days etc) between two dates.

Alternating between display modes is done by pressing the SET (middle) button.

This code will be included in the next release of Wise Clock 4 software.

Wise Clock 4 Dual screen chronometer

2012-03-13T22:50:00.003-04:00

This chronometer, inspired by the Doomsday clock by Wyolum, is made with a Wise Clock 4 board (available for sale here) and two 3216 displays from Sure Electronics.

Its main feature is the odometer-style rolling of the digits when they change.
The time is updated once a second, based on the 1Hz interrupt signal from DS3231, as described here.

As shown in the video, one button is used to change the display brightness, another button is used for changing the font, and the third is used for switching between rolling style and static style.

By using the bigger (5mm) 3216 displays with the same setup and software, this clock can be easily read from a distance of at least 100 feet (30 meters).

Source code is available here. The current version does not allow setting up the time and date from buttons.