DIYHiFi.org

Dear all,

I would like to share with You some fun that I'm having these days.

Some time ago I have done some preliminary jitter tests with a nice modern DPO - a Tek 7435.
The victim, my favorite one at the time, was a Hiface unit.
Those tests were only a first stab at the problem which kept me awake: Trying to extract jitter information directly from the SPDIF stream, by using today's sophisticated technology.
For me it's all quite linearly stemming from the old SPDIF MUSINGS thread, where I tried to have a direct look at the SPDIF signal, using a classic spectrum analyzer at that time.
A Specan is a beautiful instrument in itself, but in this special application: looking at a series data stream, not a clock, it's capabilities are quite strained.

In my shots at the time I was able to look down as deep as ~100dBc at a maximum rate. But only at special circumstances: looking at stationary data, pause, stop etc. 100 dBc was perfectly enough to see the ugly sidelobes of the USB devices at that time: asynch USB was just a remote dream..
But with the advent of the first asynch devices, namely the Hiface unit for me, it got very quickly complicated: I reached the measurement limit.
Fortunately, modern communication technology needs adequate instrumentation. Modern oscilloscopes are able to analyze serial data at a level which starts to be satisfying also for the critical audio clock recovery applications.

So, when in our institute we started to search for a new scope, I did not hide my enthusiasm for this particular new capability of these instruments: the jitter analysis.
Finally we decided for a small Lecroy, the WaveRunner 204Mxi-A. It's a more moderate category than the TEK was, but I have found it very much satisfying. And it's on my table.. There will be a WavePro 735Zi arriving too.
So, I would like to use this new little tool to dissect / flog that old horse again: The Hiface USB/ SPDIF unit.

Now down to the measurements.

Pardon me, here I would like to quote what I had already written elsewhere:
(It's just pure laziness!)

"The pivotal point of these jitter tests is the measurement of the Time Interval Error (TIE) value.
A good short description could be found, for example, here:
Jitter & Wander Tutorial

A short definition could be this -
"The time difference between a real clock and an ideal uniform time scale, after a time interval following perfect synchronization between the clock and the scale. "

That is, the Lecroy scope is set to collect a huge amount of data points. (10 -200 million points). This memory should be also very fast - we are putting in data at the maximum sample rate. In this case, at 100psec intervals.
Then the run is stopped, and the data edges are searched for. An algorithm looks at the data structure, defines the UI, and from there recovers the frequency of the fundamental clock embedded in the data.
When this ideal fundamental clock is reconstructed then each individual edge is examined again, and from it's actual crossing time value the corresponding ideal value is subtracted. The resulting difference is what is called TIE.
All this is nicely illustrated in the link above.

-As it is shown there, one can depict a time trend graph, showing how these error values are evolving for each consecutive data transition edge.
This is what the TIE time trend plots are showing.

-Also an FFT can be executed on these values, to show their behavior in the frequency domain. These are the phase noise plots.

-Then histograms can be collected, for all transitions, to see their statistical distribution.

From this then ISI, BER, Rj Pj DDj etc values can be extracted. Here I've calculated only the rms jitter value, like if all jitter were random, Rj."
Obviously, it's not the case generally. But. With respect to a general "industrial" situation, here I can do something:
By stopping the stream, like "stop play" or "pause", then restarting "play" again, I can take histograms with/ without data.
This way the random / deterministic data elements can be, "kind of", separated.

Here it is the way how the TIE trend plot is taken for the Hiface, at this moment.

The Hiface is connected with a short 75ohm BNC cabel to the scope 2nd channel, directly.
The scope is terminated in 50 ohm. Not ideal, but because of the complications of an external 75ohm termination, the results are ~ the same like if it were done with a bias Tee and real 75ohm.
10Gs/sec, 5 Mega sample length is set. (here, later I will keep it at 20 Mega)



The lower, pink trace is the physical scope trace, the classic SPDIF signal. To get the less noise possible, I'm churning up the channel gain. For the TIE reconstruction only the edges are needed, anyway.
I'm triggering on the "B" type preamble, which starts the data blocks / data words.
The "W" type preamble is also shown, a bit more asymmetric. It starts the second channel data.

The upper trace is the Time Interval Error values reconstructed, and correlated to the original SPDIF waveform. A sudden jump is visible at the onset of each "W" preamble. The scale, as shown, is 50ps/dev,
so it's jumping from ~-100psec to +100psec and back. The " bush" of all these big spikes is what could be seen in all the following plots.
It's already something pointing at the Hiface unit: in the background, light green, is the long time average of this same TIE trend plot for my CD player: on long term average is much smoother. (But not in short term)

Here I would like to show a "set" of plots, assembled with some sweat..
For me, at this moment, this "triplet" is the most "illustrative" collection.
The upper trace is the statistical distribution of the Time Interval Error for all edges, plus the
spectral distribution of the FFT converted, reconstructed TIE Trend signal.
The lower trace is the TIE Trend signal (as it evolves in time, it's like if it were a "classic" scope trace, but remember, it's reconstructed from the individual TIE values)
This is an older Hiface unit.

This is the same, for a newer Hiface unit:

It's different, something was changed by M2tech.
Would like to turn back to it later.

By the way, these two set of plots were taken, earlier, by using the TEK DPO7435 scope as well.
So this is like a bit of "sanity check" for me, if they are very much different?

Now, I have opened the older, uglier measuring Hiface unit - and did all the "usual" power supply mods.
That is, all the 3.3V plus 1.8V local switcher supplies are replaced by an external, medium bad linear power supply.
Here it is how it looks:

Don't forget, this is the older unit, should be compared to the upper, first post!
What is visible is that while the HF noise components are getting maybe even worse, the low frequency components in the spectra are getting cleaned up.

Here is a better view of only the spectral differences:

The scale is 100kHz / div, so the two peaks are grouped at ~below 10kHz (15psec) and at around 70-80kHz.(12psec)
Both of these groups are quite cleared up in the mod.
There are a lot of high freq. components remaining, anyway.

Definitely following this thread... nice work.

Plan on doing any RCA versus BNC, attenuator testing, etc. in the future with that setup?

Here it is, if only the 3.3V (clock & FPGA I/O) power supply is changed out, the 1.8V (core) PS is still a switcher.

This plot is zoomed in even more. Lower trace is the original, intact, upper is the -only- 3.3V mod.

As is visible, the core of the FPGA is the source of all the low frequency spikes -2, 4, 6, 10kHz.
The dirty 3.3V switching PS had caused instead all those modulations at around 70-80KHz.

Finally, this is the zoomed-in spectral difference between the original and the full PS mod.

Finally, would like to show a suspect of mine:

I was poking around, what could have been that little factory mod, which has caused that visible change between the original factory units, which has visibly decreased the ugly high frequency behavior.

The only thing which has changed between these units is - the waveform!
Here it is a close up:

They have found out, and eliminated that ugly glitch right in the middle of the rising edge!
(By compensating differently the output driver)

Ciao, George

Gmarsh,

Thanks!
Yes, I would like to continue - next I will try to show how good it can get - or rather, how far I can get for the moment. With a reclocked CDROM driver..
Which is still way off from the - published - values of Jocko with the Art Legato..
How nice it would be, to get it in my "mirino"..
Then my CD player, then the very ugly results of my EMU 1616m card.. just to show that the above values are not at all that bad in the end..
Then yes, we might start to look at cables / at... shhh..

And naturally, every "huntable" object would / could end up here, that I can put my hands on!

Ciao, George

Don't drag me into any of this.

Jocko

_________________
"Because, I hate you guys. I hate you guys so very, very much.

Yours,
General Cartman Lee"

Excellent work.
Thanks for posting, George.
Great toys you have there.

_________________
Carlos Filipe

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction." Albert Einstein

x2

George, keep up the good work