Wordclock 0.4

I did some updates to the software of the wordclock. It couldn’t really cope with interference, and since it relies on updates from the DCF77 receiver every minute it doesn’t really work as soon as something interferes. I was a little surprised how much the signal is affected by everyday things. TVs, for instance, at least the CRT kind, which is still widely used. My main problem turned out to be the lights of my aquariums, which are neon tubes. They too affect the radio signal, which I confirmed with a “normal” radio controlled clock.

To account for these issues I modified the code to display the time from the Arduinos internal clock. This internal clock is not very accurate, from what I gathered on the Internet it is off by a couple of seconds after only a day or so. For that reason I use the radio clock signal to set the internal clock when it gets a clean signal, which should be every day at night when all interfering sources are turned off. That way the RTC chip i mentioned earlier in this post is not really necessary.

I updated the main article about the clock to reflect these changes, the new software is available for download there as well.

Keep serial pins free!

This weekend I did some final troubleshooting on my first wordclock. I had the problem that every time the display was updated all LEDs flickered a little. Very annoying, especially when there is no change.

Finally it hit me: I had connected the 74HC595 chips to the pins 1, 2 and 3. I guess I just wanted to “start” somewhere. What I didn’t account for, is that Arduinos serial port is accessible via pins 0 and 1. They are even labeled with RX and TX. So, everytime I sent data to my computer over the serial line it also went out on pin 1, which is connected to the 74HC595, hence the flickering.

Long answer short: Don’t use pins 0 and 1. Except for serial connections of course.

Improving accuracy

Thanks to the readonly old Arduino forum I noticed only today that the author of the DCF77 code I am currently using published an update, nearly a year ago.

He wrapped it in a nice library, which makes it a lot easier to use. Sadly it doesn’t work on version 1.0 of the Arduino UI, so I reverted to version 0022 for now. There are newer “old” versions of the UI, but I had this version still installed.

This is the example from the library:

#include "Dcf77.h"
 
Dcf77 dcf77(0); 
 
void setup() {
  Serial.begin(9600);
}
 
void loop() {
  const char *v = dcf77.getDateTime();
  if (strcmp (v,"DCF77POLL") != 0) {
    Serial.println(v);  
  }
}

The library takes care of parity and plausability checks, so I don’t have to worry about that anymore. The downside is that it produces the current time far less frequent than the code I’m using now, but when it returns one it is correct.

I’m still leaning toward adding a realtime clock to the clock. This way I can rely on the RTC for the current time and correct it now and then when I get a signal from the DCF receiver.

Circuit board for the wordclock

Yesterday I was playing with Fritzing to create a circuit board for the wordclock. Building it on the breadboard was easy, but the auto routing on the PCB-layout drove me nuts. Today I tried it again, loaded the file, repositioned the components on the circuit board a little and guess what … it worked on the first try. This is how the circuit board in the next version of the wordclock may look like:

It is designed for an Arduino Mini Pro, which is by far the cheapest Arduino variant I could find and which is sufficient for this purpose. U1, U2 and U3 will hold the 74HC595 ICs, J3, J4 and J5 will connect the LEDs. J2 is the connection for the DCF77 receiver.

I guess next I’ll have to learn how to etch my own circuit boards.

Breakthrough

This evening I managed to get a breakthrough while I was working on the wordclock. The clock kept showing a completely wrong time now and then, followed by the correct time a minute later.

So I loaded the test program for the DCF receiver again and monitored the output on the serial console over a longer time (one or two hours or so). I noticed that the receiver actually gave incomplete information once in a while. To rectify this I did two things: Continue reading Breakthrough

Controlling the LEDs with a 74HC595 chip

I finally got the 74HC595 chips and decided to do a dry run on a breadboard. I used the schematic I made earlier with Fritzing and just rebuilt it, with a couple of LEDs on every chip. I used the code from this blog as a base and it worked on the first try. Now I have to adapt this code for my purposes.

Don’t panic, the test setup looks worse than it is 🙂

Working on the front plate

I started my second try on the front plate. Printing directly on the card board didn’t work out that well, so this time I printed it mirror inverted on a DIN A3 paper (the same size as the card board) and used spray glue to attach it to the card board. Then I used a crafting knife to cut out the characters, as before. This turns out to work pretty well, I guess the paper gives the card board even a little more stability.

Nevertheless this is a hell of work, the next time I’m doing something like this I have to come up with a better Idea for the front plate.

Thoughts on connecting the LEDs

This is a summary of some thoughts I had on connecting the LEDs to the Arduino. When I read about charlieplexing I was amazed how many LEDs I could control with so few pins on the Arduino. Then I realized the downside of this technique: Essentially I can only light a single LED at a given time. Sure, there are a couple that can be lit simultaneously when they don’t share any pins, but setting those up would be a nightmare. So I started to group the words. Which words have to be lit when? Continue reading Thoughts on connecting the LEDs