[time-nuts] Transmitting a time sync signal - what's the trick?

Matthew Smith matt at smiffytech.com
Wed Feb 27 00:35:10 EST 2008


Thanks for your response, Hal.

> The bit rate isn't the problem.  You can easily correct for any constant 
> delay.

I still can't quite get my head round this bit.  I have to synchronise
to a packet, but by the time that I've received and recognised the
packet, the moment is past.  Or do I just add Xms to the time, where X
is the time it takes to process the packet?

> The problem is noise/jitter.  Do you have a central controller scheduling 
> things or do you have etherent/aloha type collisions and retransmissions and 
> such to add to the noise?

Originally there were going to be collisions, but I have changed my
thinking so that nodes will listen to traffic to see if it is an
appropriate time to speak and will then only do so after having a
request to talk acknowledged by the master.  Time signals will go out
during time slots where nobody but the master is allowed to talk (they
can ask to talk as soon as the time signal has been received).

The time server will be a single board PC running OpenBSD and ntpd,
taking NMEA data and PPS from a Trimble ACE II GPS module.  The NMEA and
PPS outputs of the GPS will also be fanned out to a microcontroller
(DS89C430 - I've got a couple of samples kicking around in my drawer)
which will be in charge of radio communications.  Yet another serial
port of the PC will be connected to the microcontroller to act as a
bridge to data from the LAN to the wireless devices.

I'm using the microcontroller as I don't want to have anything to do
with real-time programming on the PC - just too much to learn, no time
to learn it.

The wireless devices will be based on small AVRs (probably).  Most will
be 'dumb' and will just turn relays on and off (outside lights) or be
driving clock movements.  Only a few nodes will be able to talk, and
most of those will only do so when polled by the master (temperature
sensors and the like).  At the moment, I have only got the one that
watches for anyone coming through the front gate as able to talk
directly, via request to talk.

So, to cut a long story short, collisions should not be able to happen.

The time server will be running NTP to all the other 'normal' computers
in the place (I've already got this happening, but the server is just
Stratum 3, sync'd to pool.ntp.org), but NTP just looks far too
complicated to implement on the little microcontrollers which is why I
was trying to work out how to get a mark in an asynchronous system - so
that I could set time with two simple packets.

Cheers

M






-- 
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy



More information about the time-nuts mailing list