Guys, I suspected as much - that testing the analogue waveform is somewhat fruitless & I had said as much in another thread that was promptly closed down after SPDIF scope shots were rejected
http://www.diyaudio.com/forums/everything-else/171506-what-can-measurements-show-not-show.html
I'm interested in your graphs George, please explain!
Last edited:
Yes an ASRC will nicely mess thing up - even the sonics in a lot of cases - I have posted about this elsewhere!
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 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 each 25psecs. But it can be 100 psecs as well, will work very good anyway.
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 executed on these values, to show their behaviour in the frequency domain. These are the phase noise plots shown here.
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.
Exactly these statistical parameters are the famous "numbers" what we all are after.
For me, the real value is in being able to see how the TIE behaves in time..
Ciao, George
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 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 each 25psecs. But it can be 100 psecs as well, will work very good anyway.
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 executed on these values, to show their behaviour in the frequency domain. These are the phase noise plots shown here.
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.
Exactly these statistical parameters are the famous "numbers" what we all are after.
For me, the real value is in being able to see how the TIE behaves in time..
Ciao, George
Bit offtopic. Got an old timing analyser for this. Starts a counter at an edge and stops it on the next. Counter value is used as index into a memory location (number of counter values is equal to number of memory locations). Before the counter is started, a configurable delay can be set. So you can `zoom in`
So the memory value is read, increased by one and placed back in the memory. Then do this some million times, and then display the memory contents as histogram on the display. Gives you a nice histogram and an indication of jitter. Can see the difference between a good and a bad clock, but the resolution is not good enough to see difference between good and really good..
But you can also measure more than one delta, e.g. the output of an early 1bit dac. Gives you 6 histograms or so.
So the memory value is read, increased by one and placed back in the memory. Then do this some million times, and then display the memory contents as histogram on the display. Gives you a nice histogram and an indication of jitter. Can see the difference between a good and a bad clock, but the resolution is not good enough to see difference between good and really good..
But you can also measure more than one delta, e.g. the output of an early 1bit dac. Gives you 6 histograms or so.
Guido,
Similar to your analyzer is the tipical TDC, time to digital converter, which is used a lot in physics.
Time to digital converter - Wikipedia, the free encyclopedia
And yes, it can be used to collect the same histograms, like the TIE histograms here. We used these to measure jitter in our experiments a lot of time. Typically these have 45 psec resolution, that is the finest binning.
But there is an important point: seemingly also the scope would have a similar resolution, 25 - 40 - 100 psecs. But. An interpolating algorithm is used, so the crossing time can be extrapolated by a much better precision.
The higher level scopes are good down to 1psec jitter resolution, the best ones are having like 500 femtosec jitter noise floor.
I have seen the built in 50psec rise time square signal generator's jitter: it was gaussian, 1sigma was 1.5psec. In the above histograms it would be a thin line.
Another point: a TDC like instrument collects only histograms, you loose the "private" information of the individual edges, so no time trend reconstruction. Also no FFT of it, no phase noise plots.
Again: a TDC has to be started / stopped at each time. That is, triggered. Also this procedure, producing the trigger, is producing it's own jitter contribution. Not by accident the discriminators used for it are a topic on it's own.
Also conventional scope "eye diagrams" are having the scope trigger jitter included.
In the plots above this is not existent: there was only one trigger at the beginning.
Ciao, George
Similar to your analyzer is the tipical TDC, time to digital converter, which is used a lot in physics.
Time to digital converter - Wikipedia, the free encyclopedia
And yes, it can be used to collect the same histograms, like the TIE histograms here. We used these to measure jitter in our experiments a lot of time. Typically these have 45 psec resolution, that is the finest binning.
But there is an important point: seemingly also the scope would have a similar resolution, 25 - 40 - 100 psecs. But. An interpolating algorithm is used, so the crossing time can be extrapolated by a much better precision.
The higher level scopes are good down to 1psec jitter resolution, the best ones are having like 500 femtosec jitter noise floor.
I have seen the built in 50psec rise time square signal generator's jitter: it was gaussian, 1sigma was 1.5psec. In the above histograms it would be a thin line.
Another point: a TDC like instrument collects only histograms, you loose the "private" information of the individual edges, so no time trend reconstruction. Also no FFT of it, no phase noise plots.
Again: a TDC has to be started / stopped at each time. That is, triggered. Also this procedure, producing the trigger, is producing it's own jitter contribution. Not by accident the discriminators used for it are a topic on it's own.
Also conventional scope "eye diagrams" are having the scope trigger jitter included.
In the plots above this is not existent: there was only one trigger at the beginning.
Ciao, George
Last edited:
Thanks George,
So in looking at the TIE spectrum plots can I ask some questions:
- the close in phase noise is different between the old & new - is this purely a reflection of the Q of the crystal & the PS i/f noise - any other factors?
- what is the jitter around the 1.5mHz area possibly related to?
- Are the differences between the units more than would be expected due to manufacturing tolerances?
So in looking at the TIE spectrum plots can I ask some questions:
- the close in phase noise is different between the old & new - is this purely a reflection of the Q of the crystal & the PS i/f noise - any other factors?
- what is the jitter around the 1.5mHz area possibly related to?
- Are the differences between the units more than would be expected due to manufacturing tolerances?
I have mentioned the scope shot done by jkeny in this thread:
http://www.diyaudio.com/forums/digi...sb-spdif-24-192khz-asynch-13.html#post2042096
Compare this to the recovered TIE trend plots here..
http://www.diyaudio.com/forums/digi...sb-spdif-24-192khz-asynch-13.html#post2042096
Compare this to the recovered TIE trend plots here..
Attachments
Yes, George, that's what I found & have been saying here - it's also audibly better - but then why would anybody believe me?
~1.5MHz.. also I was thinking of that.
The spdif bit rate at 44.1khz is 2.8224 MHz. Half of it is 1.4112 MHz, and that is the strongest frequency line if you look at an SPDIF data stream on a spectrum analyzer.
So probably this is the jitter caused by clocking out the data..
The tall line at the bottom of the spectrum is the ~80kHz power supply noise.
The spdif bit rate at 44.1khz is 2.8224 MHz. Half of it is 1.4112 MHz, and that is the strongest frequency line if you look at an SPDIF data stream on a spectrum analyzer.
So probably this is the jitter caused by clocking out the data..
The tall line at the bottom of the spectrum is the ~80kHz power supply noise.
Thanks George,
Following on from my previous PS scope shot, here's one so far unseen - this is based on removing the 5V USB supply & replacing with a 5V battery as well as powering the laptop with a bench supply (the previous shot was using a Dell Inspiron laptop powered by it's PS brick & the 5V being supplied from USB). Sorry for the quality
Following on from my previous PS scope shot, here's one so far unseen - this is based on removing the 5V USB supply & replacing with a 5V battery as well as powering the laptop with a bench supply (the previous shot was using a Dell Inspiron laptop powered by it's PS brick & the 5V being supplied from USB). Sorry for the quality
An externally hosted image should be here but it was not working when we last tested it.
Last edited:
Well, first, I don't have any equipment from Benchmark. Mistyping on one of our parts?
Second, both of the DACs I actually use measure better than -115dB to the noise floor and THDs below 0.002%. They sound excellent when the gain structure is set competently. One local musician (who is uncharacteristically interested in sound and sound technology) was so delighted with the sound, he's insisting that the mastering of his next album be checked on this system before he OKs it for release.
I'm not much impressed by internet stories and ex cathedra proclamations from self-appointed gurus with, ahem, honesty issues. I'm pretty data-driven.
yes, my typo - tiredness from a very disturbed night's sleep!
OK you've got measurements but don't expect us to believe anecdotal stories of subjective impressions as evidence
Well you might be interested in Gary Pimm's analysis of the Behringer DXC2496 http://www.pimmlabs.com/web/behringer.htm - pretty much slates the analogue section & says get rid of it
Last edited:
I would have to look back at my notes if I can find them or repeat the measurement
Unfamiliar with it.
I'll probably change over the analog output to the passive circuit published by Jan Didden as soon as I have a few weeks at home. With well-established levels, restricted bandwidth, and a healthy voltage level, I seriously doubt that the output section is the limiting factor; that's why 3/4 of Gary's page concentrates (rightly, IMO) on the input section where this is not the case.
edit: If you're talking about the DCX input receiver (not the case for my other DAC), I have had problems at spdif levels, but far fewer with higher voltages. It's never done the "dull sound" thing, and I've only had it go frying eggs once. The high output of the Hiface is an advantage here.
- Status
- Not open for further replies.