UPDATE: We now have a much simpler version of this project using CircuitPython and the Adafruit Prop Maker RP2040 Feather.

Here’s a different take on DIY clock projects. Whereas most dwell on visual displays, ours features Adabot’s friendly face speaking the time.

Best of all, you can make this your own…give it your face and voice…or if you can do impressions, how about an Arnold Schwarzenegger or Dave Jones clock? Anything goes!

Parts List

This is a “choose your own adventure” project…you might substitute or add additional parts to the mix. Read through the whole guide (and look through your current parts stash) before planning a shopping list. Here’s some of the essentials:

• Arduino Uno. This project will not work with the Arduino Leonardo, Mega, Due, Netduino, etc. It must be an Uno.
• Wave Shield (assembly required).
• SD card (or microSD w/adapter). This is a great way to re-use older “fun size” cards…it doesn’t require a lot of space!
• Either a DS1307 Real Time Clock or a Data Logging Shield.
• Stacking headers. If using the Data Logging Shield, get two sets!
• Speaker. Either the small 8 Ohm 1W speaker in the shop, or you can add an external amplified speaker for more “oomph.”
• LEDs and resistors (one resistor per LED, 180-220 Ohm for red/yellow/green, 100-150 Ohm for most others).
• Adafruit doesn’t sell individual resistors. You can find small packs at Radio Shack, Fry’s, etc. If you can't find these exact values, slightly higher is totally fine.
• Instead of regular LEDs, our clock face uses LED backlight modules, but you can use whatever suits your design.
• Any sort of momentary button. Tactile switches, arcade buttons, etc.
• A power source. This could be a USB cable connected to a port on your computer, a USB phone charger, a 9V “wall wart” power supply, or a battery pack.
• Soldering paraphernalia: iron, solder, bits of wire, perhaps a breadboard for prototyping.

Start with our Wave Shield tutorial. This will guide you through assembling the shield, downloading and installing libraries and testing the board and SD card.

You’ll probably want to assemble it using stacking headers rather than the regular pin headers included with the shield. It’s up to you…read through the rest of this guide first and come up with a plan for your clock design, and how you might have things wired up.

Troubleshooting

For reference, the photo above shows a properly-assembled Wave Shield. The following are the most common errors encountered with the product:

• The WaveHC library is not properly installed. This tutorial can offer some guidance.
• The SD card is not properly formatted; even if your computer can read/write the card, it’s not necessarily “true” to the SD specification. Try formatting the card in a digital camera if you have one.
• Jumper wires are missing (the five wires near the top edge of the board…pins 2-5 and 10).
• One or more chips are turned the wrong way (notice the arrows pointing to the “bite”), or the DAC and amp chips are swapped.
• Cold solder joints, or solder bridges…especially on the SD card slot connections. Solder should flow smoothly between pin and pad, like tiny Hersheys Kisses®. Reflow any badly-formed joints.

If your Wave Shield still refuses to work, make a new post in the Adafruit Forums. Please provide clear photos of both sides of the board, and completely describe the symptoms (including any error messages in the Serial Console).

You’ll need a library for the realtime clock:

Install RTClib as any other Arduino library; unpack, move folder to Arduino sketchbook/Libraries folder, will be active on next restart.

Next, download the Arduino code and the example WAV files (Adabot’s voice) for the project:

Move the TalkingClock folder to your Arduino sketchbook folder. Restart the Arduino IDE and you should be able to load the sketch and upload it to the board.

The workings of the code are explained on the last page of this guide. Some folks just want to make the clock, that’s cool.

If the RTC hasn't been used before, the TalkingClock sketch will automatically initialize the clock to the date & time the program was compiled.

If you ever need to change the time, here’s a minimal sketch that does the same thing, setting the clock to the compile time:

After running this code on the board, upload the TalkingClock sketch again and it should be speaking the correct time!

What will your clock look like? Chuck Norris? HAL 9000? We like Adabot!

If you’re adept at 3D printing, this adorable Adabot model could perhaps be adapted to the task.

If you’re more craft-inclined, or had a different character in mind, you can come up with your own design that leverages your existing skill set (or provides an opportunity for new ones you always wanted to learn).

I've got a bad habit of making everything a laser cutter job…but really, you could use anything…from papercraft to a teddy bear to a Godzilla toy!

Normally I’d aim for a nice enclosure with all the parts and fasteners hidden as best as possible…but wanted to use a different tack for this one. Putting the electronics in plain view invites questions. “What’s this thing? You made this? Can I make this too? What’s Arduino?”

We can make a tidy board stack using the Data Logging shield. Or the RTC breakout works with just a little more soldering & wires.

To record new voices for the clock, you’ll need a computer with sound input capability (or a USB microphone) and audio software that can edit and save WAV files (such as the free, cross-platform Audacity).

My telephone answering machine speaks timestamps in awkward, stilted English. Maybe you have some talking gadget like this.

Though using high quality voice samples, they were recorded and are played back with no regard to the intonation we as humans apply to the same words when used in different parts of sentences. Probably a cost consideration, to use the smallest ROM possible. But we have a whole SD card at our disposal and can cut loose!

For example, when you or I say “It's 12:12 pm,” the first and second “twelve” have a slightly different inflection…and you’d say “20” differently than the 20 at the start of “21.” To make our spoken time slightly less awkward-sounding, a few repetitious bits of speech are recorded, and the sketch reassembles these with some simple rules.

About half the audio you record will be discarded, but reading this complete script helps capture a more believable inflection for each word — don’t edit down, read each sentence in full, with a pause in-between. Don’t run words together…you’ll need to “Shatnerize” a bit, with a full stop between each word, but otherwise try to keep the same pitch as you would when speaking normally. And avoid the tendency to be “sing-song” with pairs of lines (where pitch alternates up and down on contrasting words); state each sentence as a standalone thing.

For consistency in tone and volume, read the full script in one pass, then edit later. Don’t record, edit and save as you go. The words in bold are kept. The rightmost column lists the corresponding filenames (don’t speak these) that should be assigned to each bold word. For example, read the Shatnerized sentence “It's one o’clock am.” “It’s” is just there to help with the hour inflection; discarded later. The next three words are later copied into new files: h01.wav, m00.wav and am.wav. Trim any silence from the start and end of each word; there's a small gap during playback anyway, as each file is accessed.

I recorded the full session at a high bitrate (44.1 KHz 32-bit float) and cleaned up the sound a little (normalize, etc.) before downsampling to a more manageable 22 KHz 16-bit PCM…this is more than sufficient for voice. Then the essential words were clipped out into their own files…

Sound files should be copied to the root folder of the SD card. To minimize delays between words, start with a freshly-formatted card, copy the WAV files and eject (card access gets progressively slower as the filesystem becomes fragmented).

If you want to make any changes to the design, you’ll need to understand a bit of how the code works. Certain things are dictated by the hardware, others are just programming shenanigans.

If you haven’t coded for the Wave Shield before, you’ll find easier-to-understand examples with the WaveHC library…the PiSpeakHC demo is pretty straightforward. The core parts of the talking clock code are very similar, no need to rehash that (or button debouncing) here.

The explanation needs to move around a bit, this isn’t entirely top-to-bottom.

Near the top of the clock code, before setup(), some pin numbers are #defined:

The mouth LED is “animated” using the Arduino’s analogWrite() function to vary the brightness. As explained on that function’s reference page, this is only available on certain pins (3, 5, 6, 9–11 on the Arduino Uno).

Meanwhile, the Wave Shield is using most of those pins for communicating with the DAC card and SD card (2–5, 10–13). It’s possible to rewire the shield and rewrite the code to use different pins, but that’s a bit of a nuisance and would break compatibility with all of the WaveHC example code! So there’s really no choice, the mouth LED needs to be on digital pin 6.

The analogWrite() reference mentions a problem with pin 6 though: it can’t display a 0% (off) duty cycle. As a workaround, later in the code, we simply set that pin to an INPUT when the mouth is not talking, and the LED will turn off:

(The pin is never explicitly set to OUTPUT in the code…analogWrite() already does that when it’s necessary.)

Save RAM with PROGMEM

The WAV filenames are stored in a global set of tables before the setup() function. The PROGMEM directive is used so these strings are stored in flash memory instead of RAM (which is in very limited supply, especially in any Arduino code dealing with SD cards).

A quirk of PROGMEM makes it necessary first to declare all the strings, then follow with arrays containing references to these strings:

It’s explained a bit more on the Arduino PROGMEM reference page…and in more depth in this Adafruit guide…required reading for anyone dealing with RAM-hungry sketches!

PROGMEM strings can’t be accessed directly, one must use pgm_read_word() to access the pointer:

No Weasels!

The very first thing in the setup() function is a trick we recently learned for avoiding the speaker “pop” at startup:

This shifts the digital-to-analog converter output from its default startup value (0) to the neutral speaker position where most WAVs start (2047) at a controlled rate.

Power Games

There are three GND pins and only one 5V pin on the Arduino. Sometimes it would be nice if there were just a couple extras…usually we use a small breadboard to provide more.

But, as long as the required power is very small (40 mA absolute max…ideally 20 mA or less) it’s totally legit to set an output pin as HIGH or LOW to provide an extra 5V or GND connection.

Pins 7 and 8 provide grounds for the LEDs, and A1 is a ground for the pushbutton.

Having done this…between the Wave Shield, clock, button, LEDs and pins reserved for Serial use…we’ve now exhaused the Arduino’s entire complement of pins.

THEREFORE: if you want to make changes to the clock and need extra control pins (e.g. two separate LEDs for the eyes), then don’t this trick, or use less of it! The LEDs and trigger button can use any of the normal GND pins…the use of I/O pins for this was entirely a matter of proximity and convenience…you’ll simply need to run a wire to a different part of the board is all.

Walking while Chewing Gum

The loop() function is continually polling the button and plays sounds as necessary…the latter is handled by a separate function. Trying to use conventional program flow to keep the random eye blinks going while the code also manages these other tasks would make it really bloated and complex.

A timer interrupt provides a sort of multi-tasking, periodically calling a function to handle the eye blinks.

Timers are a hairy subject. There’s a very limited number of them (0, 1 and 2)…the first is already in use by the Arduino core library to provide PWM and the delay() and millis() functions…the second is used by WaveHC…leaving only Timer 2. Working with timers is not for the meek…it involves reading the ATmega328P datasheet and fiddling around with specific registers and bits:

The eye timing doesn’t require any super-specific frequency like 100.0 Hz. The way this one’s set up provides a 16,000,000 ÷ 1024 ÷ 256 = 61.035 Hz period, and for the sake of timing blinks it’s close enough to think of it as “60-ish Hz.”

An interrupt service routine (ISR)…in this case a Timer/Counter 2 overflow condition…then handles the periodic task:

Dirty Pool

Finally, there’s the matter of modulating the mouth LED brightness in response to the audio being played. This uses a really dirty trick, nothing gentlemanly about it, and it would get you an “F” in a Computer Science class: we access one of the WaveHC library’s internal variables: playpos, a pointer to the value currently being output to the speaker.

The samples are presumed 16-bit. We look at just the high byte, it provides enough resolution for the animation, and track the minimum and maximum range over a very brief interval (however long it takes for 256 iterations of this loop to execute…which may actually be much quicker than 256 values from the WAV, that’s okay).

Normally it’s good form for a C++ class to declare its internal variables as private, so they’re not accessible to outside code. This allows the developer of the class to make drastic internal architectural changes to the library without breaking outside code that relies on it…everything passes through an Officially Sanctioned Set of Methods and/or Variables That (ideally) Will Not Change Across Versions™.

So here we’re exploiting the fact that the WaveHC class variables are all public…we can get in there and peer at what the library’s doing. This is not without risk: if there’s any update to that library that either changes the code’s inner workings or simply declares those members private, our software breaks! This is why it’s bad form. If that should happen, we’d either have to require the use of an older version of the library, or make our own fork that provides a clean and proper interface for similar functionality.