[time-nuts] seeking a time/clock software architecture

Jim Lux jimlux at earthlink.net
Fri Sep 23 15:03:02 UTC 2011


Here's  topic that I hope will provoke some useful discussion (and maybe 
the problem has already been solved?)

I'm working with a software defined radio (SDR) for spacecraft which 
conforms to a new architecture standard for such radios ( referred to as 
STRS) (and I'm also one of the authors of the standard, so I really do 
have to eat my own dogfood)

The standard currently defines a "time API" with some simple features to 
set and get time, nominally defined in terms of a transformation from 
some base clock (i.e. there's a default transformation of the form 
reported time = k1 * raw clock + k2).  In the current standard, "time" 
is carried around as 32 bit seconds + 32 bit nanoseconds (which is, at 
least familiar to most people, being similar to POSIX seconds + 
microseconds from gettimeofday())


A radio might have multiple oscillators/clocks (clock defined as 
oscillator and counter), with different stabilities and rates. There is 
typically hardware that allows taking a "snapshot" of one raw clock 
based on another (i.e. I could have a 66MHz clock divided by 66E6 that 
latches another 49 MHz clock).  In some cases, the base oscillator of 
the clock or trigger event is a received radio signal (GPS 1pps or PN 
code epochs are one example.  Internally derived carrier frequency 
offset of a received signal is another)

In the following discussion, I've used "raw clock" to mean base 
oscillator +counter, and "time" to mean a number in some desired units 
that can be derived from a raw clock.

Most of what I discuss below has been covered one way or another in the 
literature and on this list, but now I'm faced with putting it all into 
some form of "recommended practice" or defining an API.  To the maximum 
extent possible, I'd love to adopt what people currently use (or what 
people WISH would be used).

Here's what I'm looking for help, discussion, comments on.

1) I see the basic architectural model as having a base 
oscillator/counter (raw clock) followed by some "transformation" which 
gives you a time.  "Setting the time" is really defining some parameter 
of that transformation.   What sort of standards are there for defining 
the form of that transformation?  Obviously, there's the straightforward 
polynomial, perhaps with some scaling factors to make the coefficients 
"better conditioned" (e.g. if I want "seconds" out, and I've got 66MHz 
ticks in, there's all those 66E6 factors running around).  What other 
scheme might there be?

2) There is usually a need to have the output time synchronized to some 
external source of "time" and that external source may be of poorer 
quality than your internal oscillators.  For example, I may have an 
atomic standard in my box, but I need to report time in terms of what 
I'm given by the spacecraft, which has a non-temperature compensated 
crystal that cyclically varies by 100ppm over a 100 minute time span. 
So my transformation needs to be adjusted all the time in response to 
(presumably) a series of "at the tone, the time is" hacks from my host. 
    (imagine this as keeping the display on your cesium clock 
synchronized to the wind up alarm clock next to your bed)

Is there a standard description of how to do this, or the framework 
within which it should be done? This is sort of like NTP (or PTP), but 
they tend to assume that the source of time hacks is better than the 
local clock.


3) For most applications, the "output time" needs to be continuous and, 
usually, monotonic, even in the face of rate and offset adjustments. 
What standard schemes are there for transitioning from one set of 
transformation parameters to another?  In my current implementation, we 
have defined the transformation as a polynomial, and a transition is 
defined as a time (in the future) and a new set of polynomial 
coefficients.  When you ask for "time", if it's before the transition, 
you use the old set and if it's after, you use the new set.  If you pick 
the coefficients and time correctly, you can get a seamless change 
(continuous to whatever order you want, as long as you have enough terms 
in the polynomial... sort of like cubic splines).  Is some sort of 
piecewise linear/cubic spline scheme what we really want to do?  Or is 
there a better way?

4) The operation of synchronizing a second time to a first time can be 
described as adjusting the transformation parameters of a second 
clock+transformation so that the output matches the output of a first 
clock+transformation. (no reason why the two clocks couldn't happen to 
be the same underlying clock, in which case it's trivially 
transformation2=transformation1)  Is this a good definition?

5) What's a good way to report the uncertainty or error of a "time" (or 
the underlying raw clock or base oscillator)?  I'm looking for an 
implementation or basis of an API here. It should accommodate some way 
to deal with statistical properties. At the simplest, one could report a 
instantaneous standard deviation/uncertainty or a bounding max/min 
error. I can imagine more complex ones.  If one thinks of the polynomial 
transformation described above, each of the terms of the polynomial 
might have an uncertainty associated with it.  You might be real sure of 
the fixed offset at an instant (at the tone, as it were), but the rate 
estimate might have some uncertainty, so the overall time uncertainty 
grows, the farther you get from the instant.  One might also have 
"perfect" knowledge of the coefficients, but the underlying oscillator 
has some uncertainty, so the time derived from that oscillator has an 
uncertainty.

When it gets to actual implementation, is there any standardized way to 
do this (e.g. report timing uncertainty as a double precision fractional 
uncertainty, or as a 32 bit picoseconds, or what?).  There are 
techniques defined in various time protocols, but they tend to be tied 
to the underlying implementation, so is there a  more generalized 
approach that could be proposed?




Here's looking to an interesting discussion...

Jim



More information about the time-nuts mailing list