Connect with us

AES3/SPDIF jitter measurement

Discussion in 'Electronic Design' started by ted, Sep 19, 2003.

Scroll to continue with content
  1. ted

    ted Guest

    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


  2. Noise is the amplitude uncertainity.
    Jitter is the uncertainity of the slope.
    A generic way to measure jitter is the eye-diagram.

  3. Mike

    Mike Guest

    It depends on what kind of jitter you're talking about.

    I don't have the AES3 specifications, but I did find this paper:

    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 --
  4. ted

    ted Guest


    Thanks for your concise answer
    The article was very useful
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day