Measuring Eye patterns using DSO

[pfm]

I realize that a DSO can be used to display eye patterns for testing timing errors. What I am not able to quite understand is what exactly is the trigger input signal. Lets say you want to observe a network data stream or a spdif data stream then what other signal needs to go into the trigger input ?
Can anyone please explain this to me ?
Thanks!

[amspire]

Not a simple question as there are different answers for different protocols. It depends on what you are trying to see.

So some comms is synchronous to a clock so all transitions have fixed timing. Some are controlled by handshake and do not have strict timing - what you are then checking for is identifying the critical part of the handshake, and ignoring the rest.

If you have a protocol with a clock line, it may be enough to trigger off the critical clock edge, and check that any data transition for any data on the line is within the safe region.

It may be you want to trigger off the start of a packet in a single serial comms line. Advanced scopes have advanced pattern based triggers to help you do this, but for simple scopes, it is often a matter of tweaking the trigger holdoff so (hopefully) it starts the next trigger at the start of a new packet.

It comes down to the fact that you have to decide what you need to see, and then find a way to make the scope let you see it.

Richard.

[free_electron]

Thats not what an eye pattern is used for.....

Eye patterns are ised to check the whole interconnect path between two devices.
The scope triggers on both edges and accumulates as many frames as possible and overlays them. You get to see both edges ( rising and falling ) as well as vcc and gnd in one image. The opening of the eye tells you how crisp rise and fall times are. If there is fuzzy stuff in the eye it means you have runt pulses and timing violations. Those need to be looked put for. Certain interconnect systems have specifications of what the eye should look like.
If the eye closes this may be due to undershoot. Of the outlying edge of the eye goes outwards there is overshoot. If the edges cave in you cave too much capacitive loading.

It has nothing to do with protocol or timing ( apart from single bit timing . Timing between bits cannot be seen in an eye pattern as the scope overlays all images ). The only thing you can see is rise and fall time.

It is possible to sync an eye pattern to a clock. Then you can check for data setup and hold time.

[chscholz]

It depends.

As amspire said, if you have packetized data, like in USB2, (or you use an oldfashioned equivalent time sampling scope, or you have a realtime scope with very short acquisition length), you need to make sure that you only use the packets to build eye diagrams by triggering on certain parts of the data stream.

If you have a continuous flow of data like most modern protocols do, the trigger is completely irrelevant. The scope acquires a long waveform, (almost always applies a software CDR to extract the clock if there is no external reference clock), slices the acquired data stream up into bits, builds a persistence map (i.e. the eye diagram) and performs other statistical analysis on the data (jitter breakdown, eye opening at specified BER, etc.)

I realize that a DSO can be used to display eye patterns for testing timing errors. What I am not able to quite understand is what exactly is the trigger input signal. Lets say you want to observe a network data stream or a spdif data stream then what other signal needs to go into the trigger input ?
Can anyone please explain this to me ?
Thanks!

[amspire]

Thats not what an eye pattern is used for.....

Eye patterns are ised to check the whole interconnect path between two devices.
The scope triggers on both edges and accumulates as many frames as possible and overlays them. You get to see both edges ( rising and falling ) as well as vcc and gnd in one image. The opening of the eye tells you how crisp rise and fall times are. If there is fuzzy stuff in the eye it means you have runt pulses and timing violations.

I was talking about looking at the timing of the edges but it is often not as simple as you seem to be saying.

I have to admit that chscholz probably answered much better then my attempt.

Just for example, if you have a protocol where the clock is embedded in the data stream, what are you going to trigger of? If you trigger of the same edges that you are trying to test, then the edges will of course all be perfect. The test would not mean a thing.

Richard.

[pfm]

Ok lets take a specific example. SPDIF. It’s a single wire unidrectional digital data stream. No separate clock line or handshake. It just relentlessly keeps clocking the data out at the rate of the transmitter’s clock. And it is the transmitter’s clock’s quality (frequency stability/accuracy, jitter. wander) that I would like to measure using this stream. Is that what eye patterns are used for as well ? If so how do I go about doing that ?

The SPDIF format does have a repeating bit pattern in it but I don’t suppose any of those $400 scopes(Owon, Instek..) have pattern triggering do they ?

[chscholz]

Yes, they are.

You could try to trigger on edge in you burst. If you set the timebase to a bit more of a UI and move the trigger point off the screen you can get some form of eye diagram. In fact, that's how it used to be done long time ago.

With that you can estimate how "wide" your 0/1 transitions in your eye diagram is (usually done using cursors) 

A step up form this very crude method is to measure the frequency at the 0/1 transition level, track the frequency over time, build a histogram and measure histogram range and/or standard deviation. You can perform a Fourier transform of the frequency track and get information on the spectral content of your frequency (this would be called frequency jitter BTW, you can get period jitter by measuring the period, cycle-to-cycle jitter by measuring the change in period, half-period jitter, TIE and tons of other types of jitter measurements).

A step up from there is to do statistical analysis on the the jitter, i.e. to determine what component of the jitter is bounded {correlated|uncorrelated} and what part is unbounded (aka.  usually assumed to be Gaussian).

You don't need a super high-end scope for that, all you need is to acquire a long acquisition do a bit of math and you are done.

Chris

Ok lets take a specific example. SPDIF. It’s a single wire unidrectional digital data stream. No separate clock line or handshake. It just relentlessly keeps clocking the data out at the rate of the transmitter’s clock. And it is the transmitter’s clock’s quality (frequency stability/accuracy, jitter. wander) that I would like to measure using this stream. Is that what eye patterns are used for as well ? If so how do I go about doing that ?

The SPDIF format does have a repeating bit pattern in it but I don’t suppose any of those $400 scopes(Owon, Instek..) have pattern triggering do they ?

[pfm]

Yes, they are.

You could try to trigger on edge in you burst. If you set the timebase to a bit more of a UI and move the trigger point off the screen you can get some form of eye diagram. In fact, that's how it used to be done long time ago.

Oh ok so trigger on the rising edge of each transition. What I had in mind by "pattern" is like a specific bit sequence. But yes I can see how this can also display a eye pattern on the screen. Two followup questions on this method -
1. This would be the same as continous/realtime eye method that the attachements indicate in your first post, correct ?
2. Most of the times data signals like these have two intervals in a row that are high or low (11 or 00) - typically for bmc or nrz type of data stream. So wouldn't that throw off the frequency calculation. Wouldn't that make the frequency half of the actual, for that instance, and even in the overall capture even if its long wouldn't that manifest as a false frequency 'error' ?

A step up form this very crude method is to measure the frequency at the 0/1 transition level, track the frequency over time, build a histogram and measure histogram range and/or standard deviation. You can perform a Fourier transform of the frequency track and get information on the spectral content of your frequency (this would be called frequency jitter BTW, you can get period jitter by measuring the period, cycle-to-cycle jitter by measuring the change in period, half-period jitter, TIE and tons of other types of jitter measurements).

A step up from there is to do statistical analysis on the the jitter, i.e. to determine what component of the jitter is bounded {correlated|uncorrelated} and what part is unbounded (aka.  usually assumed to be Gaussian).

Good ideas there. How would I get a histogram from the sampled data ?
Spectral content/FFT - So this would be just like any other fft of a signal ? Meaning the fundamental would be the base frequency/rate of the data stream and other components would show up at whatever deviations were from that frequency ? and all those components would be of the same amplitude, right ? because the amplitude remains the same only the freq changes.