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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
