[time-nuts] Need Time Help

jimlux jimlux at earthlink.net
Tue Oct 4 10:32:20 EDT 2016


On 10/4/16 6:26 AM, Graham / KE9H wrote:
> Larry:
>
> You have multiple problems, with the way you are trying to define
> "time-error."
>
> I think you are defining it as the time error of the signal coming out of
> your receivers/decoders.
>
> You are blending all the error/delay sources together, and you need to
> break them apart, since each one will have a different solution, or method
> of management
>
> First, the reflector has already jumped in and helped you with the
> definition of absolute time.  You can get single digit millisecond accuracy
> (with some caviats and bewares) from NTP, for stations at different
> locations.  You should be able to get single digit microsecond accuracy (or
> better) with an appropriate GPS based timing systems. You can not get these
> levels of accuracy out of the native time system on Windows. That is more
> like single digit seconds.
>
> Second, you have some serious signal processing latency delays in your
> receivers/demodulators/decoders.  Depending on how the designer has dealt
> with streaming and buffering, particularly with the (buffered) connections
> between the stages, these processing latency delays may be constant or
> variable, or perhaps adjustable.  The Windows Sound system is horrible from
> a latency/stability standpoint. You are probably feeding your back-end
> demodulators/decoders through it. You will need to break apart your system
> (transmit and receive) into modules or stages, and characterize each one
> for latency. Beware of (uncontrolled) buffers at the interfaces. You
> generally need to pick a reference point, such as the antenna port, and
> correct everything to that reference point.
>
> Third, you seem to be running a portion of the (SDR) receivers and the
> demodulators/decoders on computers with Operating Systems. (Like WIndows
> OS, which is NOT a real-time operating system.)  That means that the
> response time of the system to a request for computing resources can be
> quite variable. (microseconds to tens of milliseconds typical, with rare
> excursions into the single digit seconds.)  The solution to this problem is
> to either run on a very lightly loaded computer, or switch to a real time
> OS, such as Linux with a real-time kernel. This does not cure the problem,
> but does put bounds on it.
>
> --- Graham / KE9H




One way that seems to work fairly well, as long as you can post process 
(or your "turnaround latency" can be in the "seconds" bucket).. is to 
record a time reference signal that is added to the original RF signal. 
A pilot tone, or a modulated tone, somewhat away from your desired 
signal, generated by a high quality time reference (maybe you have an 
XO, and you phase modulate it with the 1pps from your GPS receiver).

Then, in your downconverted, digitized, and filtered data, you look for 
the time reference and use that as what you need, rather than trying to 
back out all the (non-deterministic) delays through the audio processing 
chain.

By the way, Windows *can* be very good on synchronizing audio: otherwise 
audio and video wouldn't play together in media, high performance gaming 
wouldn't work, etc.  The problem is that it is a royal, giant, pain to 
get it to work.  You need a lot of knowledge and experience with exactly 
how Windows handles the media streams, all those countless APIs, etc. 
And it is different for each version of Windows.  (Realistically, Linux 
and Mac OS X are no better: the nature of the difficulties is different, 
but they're still there)



The typical amateur radio spectrogram program or demodulator probably 
doesn't do that: they use a simple FIFO pipeline, and make no claim that 
what's on the screen matches what's at the antenna at a particular 
instant, as long as the order and duration is correct eventually.  If 
you're decoding CW with CW skimmer or decoding PSK31, you probably 
aren't doing full break-in between the dots and dashes or characters: a 
few tenths of a second random lag doesn't make any difference 
(especially since the signal you're receiving is over a 
non-deterministic delay skywave path)


My philosophy (and the one that wound up embedded in our design of a 
Software Defined Radio framework for space radios) is that software 
handles the *management* of timing critical processing implemented in a 
FPGA.  Sample accurate timing is done basically in hardware, and 
software (running on whatever OS - we use RTEMS which is pretty good 
Real Time, but...) talks to the hardware using a model which says, in 
effect, don't try to synchronize across this interface at resolutions 
finer than 1 millisecond.  (For non Real Time OS, I'd try for 10s of 
milliseconds)

For a simple instance, we latch a a free running counter driven from an 
OCXO with the GPS 1pps. That's in hardware.  The software just has to 
guarantee that it reads the latch at least once a second and we can 
collect the data we're interested in. If it can't guarantee that, that 
it can figure out what happened if we miss a latch event (i.e. the count 
looks like it increased by twice the expected increment) or we read too 
often (the count didn't change).

Then, if we need an event to occur at a precise time, we can calculate 
(in our own sweet non-deterministic time) what counter value that time 
would correspond to.  We load that into another register, which is 
compared with the free running counter, and the equality triggers the event.

Obviously, we need to schedule the future event sufficiently far into 
the future that we have time to do the calculations. But figuring out a 
"worst case bounded maximum time" is a lot easier than "must calculate 
everytime within 1 millisecond" hard real time kind of constraint.

We can also be very fancy in our model of "time vs counter reading".  We 
can, for instance, use the last 10,000 1pps tick latched values to 
estimate the future clock rate and drift (essentially what GPSDO 
algorithms do).  Or, we can be simple: use the delta between two 
successive ticks as the estimate of the clock rate, assume it's 
unchanging, and go from there.

One of the fascinating problems that arises for us (and will arise for 
you) is that you might need to synchronize a good clock against a bad 
one.  That is, in order to have events occur in multiple places at the 
same "time", you essentially need to predict the behavior of the worst 
clock in the system, and then have everyone else follow that.


I'd also comment that testing of such a system is challenging: you need 
to generate a test signal that occurs at a precisely known time, and see 
if your system captures it, and it shows up at the right sample time. 
So the latency of your test equipment (hardware again) needs to be 
understood and known.





More information about the time-nuts mailing list