What is the exact definition for timing jitter as measured on a
AES3/SPDIF data stream?
Most of the web references discuss the topic, but I have found no
reference on exactly how it is measured, or how it is defined (in a
precise way that is)
For example if jitter is stated as 6nS peak, what does it mean
exactly. Is it the maximum time interval between two adjacent word
clock edges, or is it averaged over a long time?
Could anybody explain? No simple explanations please, I understand the
basics, I would appreciete a precise definition of what jitter is and
how it can be measured (or web pointers). I already have some AES
documents, but don't quite seem to explain it well.
Thanks all in advance
ted
It depends on what kind of jitter you're talking about.
I don't have the AES3 specifications, but I did find this paper:
http://www.nanophon.com/audio/towards.pdf
The authors are apparently part of a working group trying to redefine the
AES jitter specifications. Their final results look more like a SONET
specification, reduced to the audio sampling frequency range.
On page 6, they quote the AES specification section 6.2.5:
"Data transitions shall occur within ±20 ns of an ideal jitter-free clock
measured at the half voltage points."
That seems pretty clear, except that you'll never find a real ideal clock.
Even if you could, assuming that the jitter has a Normal distribution there
is no peak-to-peak value. A couple years ago I generated plots of
peak-to-peak jitter versus measurement time for SONET and Ethernet clock
generators; if you plot the square of the peak-to-peak jitter vs the number
of measurements you've taken, you'll find that the peak-to-peak value
increases linearly vs log of the number of samples - there is no maximum
peak-to-peak value. I ran from 1000 measurements to tens of millions, and
the plot remained linear.
It would make sense to specify a peak-to-peak value if the specification
contained a time period over which the jitter measurement was made (or,
equivalently, a number of clock periods). From what I can see in this
paper, that is not the case. Not having the specification, I could be wrong
(and I didn't read closely, so I may have missed it).
In any event, the authors go on from there to talk about intrinsic jitter,
jitter accumulation, jitter transfer function, jitter tolerance, filtering
masks, and on and on. Looks more and more like SONET.
Returning to your question, my interpretation of your "timing jitter" is
that it's essentially the same as what I quoted above. In that case, you
need a separate (comparatively stable) clock source to measure against.
Typically, this is the master clock for the system, which is then used as
the clock source at the start of the data stream. To measure your jitter,
trigger on the master clock and watch the data on the screen.
Note that this won't work if you're measuring jitter on a "received" data
stream, like that you'd probably get from a digital playback device. In
that case, there is some clock reference that's used to spin the motor,
then the receiver locks to the data stream coming from the device. The
master clock in this case may not have a nice relationship to the data, and
the reference clock used for the data recovery circuit is no longer used
once data recovery begins. Essentially, that means that everything down the
line adapts to the speed of the data stream.
This makes your measurement more difficult, but not impossible. I don't
know what audio guys do to solve the measurement problem, but a common
solution in the SONET world is to use a low noise, low bandwidth PLL to
lock to the data stream. As the data stream jitters, the low bandwidth PLL
rejects most of the jitter, and remains at the nominal data frequency. The
PLL clock can then be used as the "ideal jitter-free" clock (with
appropriate hand-waving and sacrifices to the Jitter Gods). The PLL can't
reject jitter below the PLL bandwidth, so at low jitter frequencies the
"ideal jitter-free" clock tracks the jitter, and your measurements with
respect to the clock become smaller and smaller. The trick is to choose the
PLL bandwidth to be low enough that the jitter below that frequency is
irrelevant, but not so low that the PLL can't track the slow variations in
the motor speed. The authors of the paper show a proposed jitter weighting
transfer function in figure 15 on page 19. If you choose your PLL bandwidth
to be the same as the jitter weighting transfer function bandwidth, then
your PLL can do the filtering for you, simplifying the measurements.
-- Mike --
