Radio-synchronized clocks

Contents:

Components
Hardware
- Microcontroller
- Displays
- Server
- Radio
Data format

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.

Components

For each clock:

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

For the central computer:

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

Hardware

Microcontroller

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

Displays

7-segment LED or LCD display
Dot-matrix LED or LCD
Simulation of 12 or 24 hour clock face using LEDs; 24 + 60 + 60 = 144 LED's

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.

Server

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.

Radio

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.

315/434 MHz transmitters and receivers - only two frequencies, 2400 or 4800 bps, ~150 m range in the open. Very cheap and simple.
Nordic transceivers - 2.4GHz band with 125 channels, 250kbps or 2Mbps, ~60 m range in the open. Moderately priced but could have problems with interference from WiFi and our cordless phone.
Xbee modules - 2.4GHz band with 12 or 16 channels, 250kbps, 100-1500m range depending on model. Similar price to the Nordic modules, but has a lot more infrastructure (IEEE 802.15.4) behind them. They even encrypt the data!

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.

The first byte of a packet is a type value.
- The clocks will collect and display the pieces of data they are programmed to handle.
The second byte is the length; the number of bytes to follow in the packet.
- The length value allows a clock to skip an unknown packet type.
The rest of the packet is the payload.

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