Article History

Radio-synchronized clocks

This project idea is to create digital clocks that can be placed around a home or small business and are synchronised to a central computer. These devices could also show other information, e.g date, phase of moon, temperature readings, etc.


For each clock:

  1. An appropriately sized display and case.
    • A commercially produced digital clock could be purchased and ‘gutted’.
    • Or make a custom layout.
  2. A programmable micro-controller.
  3. An RF receiver.

For the central computer:

  1. An RF transmitter.
  2. Software that feeds data to all of the units.
  3. (Optionally) A wired or wireless internet connection.
    • NTP time synchronisation.
    • Other data collection over the network (temperature readings, etc).
  4. (Optionally) GPS receiver for time synchronisation.



The ATmel ATmega168 used in the Arduino (and similar devices) looks quite capable.


How to drive so many LED's? The Arduino site has an LED driver tutorial using the Phillips 4794. This chip can drive 8 LED's using four pins (data, clock, strobe, enable) and is easily daisy-chained to drive as many LED's as needed.

Evil Mad Scientist's Peggy 2.0 board has 625 LEDS in a 25×25 array. It uses two 74HC154 4-to-16 demultiplexers to drive the columns, and two STP16DP05 16-bit LED sinks to drive the rows. Like the 4794, these chips are easy to daisy-chain, but drive twice as many LED's each.


I will write a server app that can run on any Linux (or similar?) host. This could be an existing machine on the network, or a small dedicated host if necessary e.g using a Gumstix waysmall.


The radio should have adequate range (50 to 100 m) and preferably have selectable channels. Speed is not a huge problem. Even a few hundred baud would be sufficient for most simple configurations e.g date, time, temperature.

Data format

The data stream will be broken into very simple packets of data. The intention is a format that allows new types of data to be transmitted, while each clock can simply skip data it doesn't handle.

A unique string re-synchronises the clocks before a batch of packets are sent, just in case they have lost their place in the data stream. Clocks should wait until becoming synchronised before interpreting the data stream e.g on power-on.

The data should tend towards a simple, display-orientated representation. But consideration should be made for using the data in multiple ways e.g, the current time should easily allow both a digital display of the digits (seven-segment or dot-matrix) and an analogue display with rings of LED's or actual arms.

As an example of making the data too display-oriented, the time could be sent as individual digits (perhaps BCD-encoded nibbles). This would make it very simple for a microcontroller to display as digits, but would require reconstruction to be used with any other type of display. At the other extreme, the date and time could be sent as the standard UNIX epoch-seconds but would require extensive conversion for display (including timezones, which change from time to time).

Example data stream:

# Sync
FF 00

# Type 00, 4 bytes - the date; 2008-11-14
00 04 07 d8 0b 0e

# Type 01, 3 bytes - the time; 07:45:23
01 03 07 2d 17

# Type 07, 3 bytes - temperature; zone 0 (outside), 13.56°C
07 03 00 0d 38