Jitter: Part 7 – Data Jitter

#7 in a series of articles about wander and jitter

Back in a previous posting, we looked at this plot:

Fig 1. If you have random jitter, then the probability of it having an error in the timing of the clock event has Gaussian distribution. It’s most likely that the event will happen at the correct time – and there is a decreasing probability that the timing error will be increasingly wrong.

The plot in Figure 1 shows the probability of a timing error when you have random jitter. The highest probability is that the clock event will happen at the correct time, with no error. As the error increases (either earlier or later) the probability of that happening decreases – with a Gaussian distribution.

As we already saw, this means that (if the system had an infinite bandwidth, but random jitter) the incoming signal would look something like the bottom plot in Figure 2 when it should look like the top plot in the same Figure.

Fig 2. A simple representation of the time smearing caused by random jitter

However, Figure 1 doesn’t really give us enough information. It tells us something about the timing error of a single event – but we need to know more.

 

Sidebar: Encoding, Transmitting, and Decoding a bi-phase mark

Let’s say that you wanted to transmit the sequence of bits 01011000 through a system that used the bi-phase mark protocol (like S-PDIF, for example). Let’s walk through this, step by step, using the following 7 diagrams.

 

Fig 3. The original 8 bits that you want to transmit through the system.

 

Fig 4. The bits encoded for the bi-phase mark. Remember that a 1 is encoded as a high/low voltage combination or a low/high. A 0 is encoded as a low/low or a high/high. This is sent over the wire by the transmitter and is (in theory) received at the receiver. So, the receiver gets this pulse wave and nothing else…

 

Fig 5. The receiver picks a threshold (the black horizontal line) somewhere between the high and the low voltages and looks to see when the voltage signal crosses it. Every time it does, the receiver marks a clock event (the ticks along the “Time” axis along the bottom.

 

Fig 6. Since this has been happening for a while, the receiver is able to interpolate and put some extra clock events in (the green lines) – guessing that these are probably in the correct places.

 

Fig 7. The receiver then makes a clock that “ticks” between the detected clock events. These are represented in this figure as the vertical black lines between the dotted ones. It will use these moments in time to check to see whether the voltage is high or low at that moment.

 

Fig 8. The receiver detects whether the voltage is high (H) or low (L) at the new clock “ticks” that it has made in Fig 7.

 

Fig 9. It then pairs the low’s and high’s into groups of 2 (we will not discuss how it knows when to start – that’s another discussion). If it sees the same values in a pair (two “high” or two “low” values) then this is a 0. If it sees two different values in the pair, then it’s a 1.

 

At this point, the receiver has two pieces of information:

  • the binary string of values – 01011000
  • a series of clock “ticks” that matches double the bit rate of the incoming signal

 

How do we get a data error?

The probability plot in Figure 1 shows the distribution of timing errors for a single clock event. What it does not show is how that relates to the consecutive events. Let’s look at that.

Let’s say that you have two consecutive clock events, represented in Figure 10, below, as the vertical Blue and Green lines. If you have jitter, then there is some probability that those events will be either early or late. If the jitter is random jitter, then the distribution of those probabilities are Gaussian and might look something like the pretty “bell curves” in Figure 10.

Basically, this means that the clock event that should happen at the time of the vertical blue line might happen anywhere in time that is covered by the blue bell curve. This is similarly true for the clock event marked with the green lines.

 

Fig 10. Two consecutive clock events, showing a probability (with a Gaussian distribution) of the event being either early or late.

If we were to represent this as the actual pulse wave, it would look something like Figure 11, below.

 

Fig 11. An artist’s representation of the pulse wave with the transitions smearing in time, as shown in Figure 10.

 

You will see some red arrows in both Figure 10 and Figure 11. These indicate the time between detected clock events, which the receiver decides is the “safe” time to detect whether the voltage of the carrier signal is “high” or “low”. As you can probably see in both of these plots, the signal at the moments indicated by the red arrows is obviously high or low – you won’t make a mistake if you look at the carrier signal at those times.

 

However, what if the noise level is higher, and therefore the jitter is worse?

In this case, the actual clock events don’t move in time – but their probability curves widen – meaning that the error can be earlier or later than it was before. This is shown in Figure 12, below.

 

Fig 12. Two consecutive clock events, showing a probability (with a Gaussian distribution) of the event being either early or late. Note, however, that the error in this case can be larger than that shown in Figure 10.

If you look directly above the red arrow in Figure 12, you will see that both the blue line and the green line are there… This means that there is some probability that the first clock event (the blue one) could come AFTER the second (the green one). That time reversal could happen any time in the range covered by the red area in the plot.

An artist’s representation of this in time is shown in Figure 13, below. Notice that there is no “safe” place to detect whether the carrier signal’s voltage is high or low.

Fig 13. An artist’s representation of the pulse wave with the transitions smearing in time, as shown in Figure 12.

 

If this happens, then the sequence that should be interpreted as 1-0 becomes 0-1 or vice versa. Remember that this is happening at the carrier signal’s cell rate – not the audio bit rate (which is one-half of the cell rate because there are two cells per bit) – so this will result in an error – but let’s take a look at what kind of error…

The table below shows a sequence of 3 binary values on the left. The next column shows the sequence of High and Low values that would represent that sequence, with two values in red – which we assume are reversed. The third column shows the resulting sequence. The right-most column shows the resulting binary sequence that would be decoded, including the error. If the binary sequence is different from the original, I display the result in red.

You will notice that some errors in the encoded signal do not result in an error in the decoded sequence. (HH and LL are reversed to be HH and LL.)

You will also notice that I’ve marked some results as “Invalid”. This happens in a case where the cells from two adjacent bits are the same. In this case, the decoder will recognise that an error has occurred.

Original Encoded Including error Decoded
000 HH LL HH HH LL HH 000
HH LL HH HL HL HH 110
HH LL HH HH LL HH 000
HH LL HH HH LH LH 011
HH LL HH HH LL HH 000
001 HH LL HL HH LL HL 001
HH LL HL HL HL HL 111
HH LL HL HH LL HL 001
HH LL HL HH LH LL 010
HH LL HL HH LL LH Invalid
010 HH LH LL HH LH LL 010
HH LH LL HL HH LL 100
HH LH LL HH HL LL Invalid
HH LH LL HH LL HH 000
HH LH LL HH LH LL 010
100 HL HH LL LH HH LL Invalid
HL HH LL HH LH LL 010
HL HH LL HL HH LL 100
HL HH LL HL HL HL 111
HL HH LL HL HH LL 100
011 HH LH LH HH LH LH 011
HH LH LH HL HH LH 101
HH LH LH HH HL LH Invalid
HH LH LH HH LL HH 000
HH LH LH HH LH HL Invalid
110 HL HL HH LH HL HH Invalid
HL HL HH HH LL HH 000
HL HL HH HL LH HH Invalid
HL HL HH HL HH LH 101
HL HL HH HL HL HH 110
111 HL HL HL LH HL HL Invalid
HL HL HL HH LL HL 001
HL HL HL HL LH HL Invalid
HL HL HL HL HH LL 100
HL HL HL HL HL LH Invalid

 

How often might we get an error?

As you can see in the table above, for the 5 possible errors in the encoded stream, the binary sequence can have either 2, 3, or 4 errors (or invalid cases), depending on the sequence of the original signal.

If we take a carrier wave that has random jitter, then its distribution is Gaussian. If it’s truly Gaussian, then the worst-case peak-to-peak error that’s possible is infinity.  Of course, if you measure the peak-to-peak error of the times of clock events in a carrier wave (a range of time), it will not be infinity – it will be a finite value.

We can also measure the RMS error of the times of clock events in a carrier wave, which will be a smaller range of time than the peak-to-peak value.

We can then calculate the ratio of the peak-to-peak value to the RMS value. (This is similar to calculating the crest factor – but we use the peak-to-peak value instead of the peak value.) This will give you and indication of the width of the “bell curve”. The closer the peak-to-peak value is to the RMS value (the lower the ratio) the wider the curve and the more likely it is that we will get bit errors.

The value of the peak-to-peak error divided by the RMS error can be used to calculate the probability of getting a data error, as follows:

Peak-to-Peak error / RMS error Bit Error Rate
12.7 1 x 10-9
13.4 1 x 10-10
14.1  1 x 10-11
14.7  1 x 10-12
15.3  1 x 10-13

 

The Bit Error Rate is a prediction of how many errors per bit we’ll get in the carrier signal. (It is important to remember that this table shows a probability – not a guarantee. Also, remember that it shows the probability of Data Errors in the carrier stream – not the audio signal.)

So, for example, if we have an audio signal with a sampling rate of 192 kHz, then we have 192,000 kHz * 32 bits per audio sample * 2 channels * 2 cells per bit = 24,576,000 cells per second in the S-PDIF signal. If we have a BER (Bit Error Rate) of 1 x 10-9 (for example) then we will get (on average) a cell reversal approximately every 41 seconds (because, at a cell rate of 24,576,000 cells per second, it will take about 41 seconds to get to 109 cells). Examples of other results (for 192 kHz and 44.1 kHz) are shown in the tables below.

Bit Error Rate Time per error (192 kHz)
1 x 10-9 41 seconds
1 x 10-10 6.78 minutes
1 x 10-11 67.8 minutes
1 x 10-12 11.3 hours
1 x 10-13 4.7 days

 

 

Bit Error Rate Time per error (44.1 kHz)
1 x 10-9 2.95 minutes
1 x 10-10 29.53 minutes
1 x 10-11 4.92 hours
1 x 10-12 2.05 days
1 x 10-13 20.5 days

You may have raised an eyebrow with the equation above – when I assumed that there are 32 bits per sample. I have done this because, even when you have a 16-bit audio signal, that information is packed into a 32-bit long “word” inside an S-PDIF signal. This is leaving out some details, but it’s true enough for the purposes of this discussion.

 

Finally, it is VERY important to remember that many digital audio transmission systems include error correction. So, just because you get a data error in the carrier stream does not mean that you will get a bit error in the audio signal.