Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter

[1audio]

I will be testing the TI demo board for their best ADC chip. It looks to be quite well done. I'll patch it through the Juli@ card.

The RME card I have seems to have a dsp that wants to touch the digital input for some reason. And its mixer may be changing levels etc. Not sure how to move that all aside.

The software looks really interesting. Do you have a cross correlation for the FFT? Here are some references into how its used for phase noise measurement. http://www.holzworth.com/Aux_docs/Ho...at_Feb2011.pdf http://www.amlj.com/files/products%2...-technique.pdf I can find more but you should be able to get the basic idea.

[Bunpei]

I have some questions on this measurement method.
I'd be very happy if any of you could give me answers.

Originally Posted by 1audio

The most useful is probably measuring at the main analog output. This process was documented pretty thoroughly by J Dunn, ...

I understand that this method is originally designed to measure a jitter inherent in S/PDIF interface by employing the worst case binary pattern in the test signal. Ian's project does not involve S/PDIF interface. His input and output signals are I2S. Moreover, the Julian Dunn method requires a combination of both transport and DAC. The performance of transport and DAC may affect the result very much.
Is the method adequate to characterize Ian's board?

Originally Posted by 1audio

3) A good analog to digital converter that won't limit the measurements. I use an ESI Juli@ card. The host PC can affect things and you will need to do some calibration to be sure of what you are seeing with the system.

According to ESI's web page, the dynamic range of 24-bit/192kHz ADC is 114dB. Your measurement results show those noise floors are approximately between -140 dB and -150 dB. Can we regard the noise floor values obtained are reasonable?

My last concern is that the method is not sensitive enough to Ian's project.

[HpW]

Originally Posted by 1audio

I will be testing the TI demo board for their best ADC chip. It looks to be quite well done. I'll patch it through the Juli@ card.

The RME card I have seems to have a dsp that wants to touch the digital input for some reason. And its mixer may be changing levels etc. Not sure how to move that all aside.

The software looks really interesting. Do you have a cross correlation for the FFT? Here are some references into how its used for phase noise measurement. http://www.holzworth.com/Aux_docs/Ho...at_Feb2011.pdf http://www.amlj.com/files/products%2...-technique.pdf I can find more but you should be able to get the basic idea.

Hi,

thank you for the cross-correlation links! I am currently investigation on this. My current finding is, if you use only 1024 FFT you will have this noise figures and averaging will not help that much. The thing changes dramatically if you use a 65k FFT. With my test currently on my web, I used a 2^25 FFT. Any way, you may not go below to the theoretic the noise floor of a given ADC (16 bit about -144; 24bit about -180 db).

Hp

[1audio]

Originally Posted by Bunpei

I understand that this method is originally designed to measure a jitter inherent in S/PDIF interface by employing the worst case binary pattern in the test signal. Ian's project does not involve S/PDIF interface. His input and output signals are I2S. Moreover, the Julian Dunn method requires a combination of both transport and DAC. The performance of transport and DAC may affect the result very much.
Is the method adequate to characterize Ian's board?

Prism has demonstrated that this is a good method for looking at all sources of jitter. The fundamentals are valid for measuring very low levels of jitter, down to the limits of the DAC used. However you need to validate and calibrate the measurements to know where the limits are.

Originally Posted by Bunpei

According to ESI's web page, the dynamic range of 24-bit/192kHz ADC is 114dB. Your measurement results show those noise floors are approximately between -140 dB and -150 dB. Can we regard the noise floor values obtained are reasonable?

Noise is much more complicated an issue than a single number. The dynamic range number needs to reflect the bandwidth used. A narrower bandwidth in the measurement will result in a lower noise to the limits of the system. The ultra high resolution FFT's have "bandwidths" in the fractional Hertz range. There is very little energy in the small piece that is being measured, which is why the numbers are so low.

Originally Posted by Bunpei

My last concern is that the method is not sensitive enough to Ian's project.

Again its not that simple. Even if Ian's project ends with femtosecond resolution, if no DAC can realize that jitter it really doesn't matter. What will matter is getting the really low jitter through the dac to the analog domain. Its also easier to measure there.

Measuring really low jitter on the clocks otherwise requires a reference oscillator (difficult to obtain and expensive) a low noise RF mixer, some other rf and baseband bits and pieces and a good FFT. Its also very sensitive to setup since you are looking for noise as much as 170 dB below the carrier level. Many external things will degrade the measurements. I tried it with a pair of Wenzel oscillators and even reorienting them on the bench made a difference. Its also possible to see the effect of gravity on the crystal with that setup.

The important issue is whether the goal is a number or are you measuring for diagnostic reasons? I have found the method used above useful for finding problems and improving the system performance. The pictures show that you can see meaningful differences between devices that are very good. Upgrades for the oscillator and power supply of the Juli@ card will probably help. My pending experiments with the TI board should shed some light on where the limits are in this process.

[1audio]

Originally Posted by HpW

Hi,

thank you for the cross-correlation links! I am currently investigation on this. My current finding is, if you use only 1024 FFT you will have this noise figures and averaging will not help that much. The thing changes dramatically if you use a 65k FFT. With my test currently on my web, I used a 2^25 FFT. Any way, you may not go below to the theoretic the noise floor of a given ADC (16 bit about -144; 24bit about -180 db).

Hp

The cross correlation is a trick for removing the reference oscillators noise contribution. If the noise component in both mixer outputs has a common element the correlation will leave that as it removes the non-correlated part. The method usually requires two separate reference oscillators which will have different instantaneous noise. The common noise comes from the DUT and will remain as the non-correlated noise goes away. I agree an 1024 point fft is not enough but the preprocessing of the signal reduces the demands on the fft step.

[iancanada]

I collected quite a few oscillators and XOs so far. I just post some pictures of them.

I look for not only the clocks with good expected low jitter performance, but also normal clocks and clock solutions. Since now I have the FIFO platform, I could feel the ‘pure’ clock with particular jitter parameters, rather than the combination of jitter accumulation of PLL of SPDIF receiver (secondary pll for some applications), the SPDIF transmission and the source clock.

I just want to feel different clocks, as well as how and how much in difference between good and normal.

The collection is still going on. Some of them still under waiting for the back order delivery. It will take me some time to go through all of them. However, how to get the right evaluation is a question.

Ian

[iancanada]

Originally Posted by 1audio

Ian asked me how I measure jitter. It can get pretty involved but here are the basics.

The last two plots are an Auraliti PK100 analog output which looks a little different. The first plot is the same 8 KHz span as stereophile uses for these tests, the second is a zoomed version showing the close in phase noise, what my homework has been for the last year.

Is this your homework for last year? You did good job Demian! And you are drawing my interesting.

Ian

[iancanada]

Originally Posted by iancanada

I did try this rubidium clock on my CD transport but the result was not as good as I thought. Sine to square converter was another issue. Of course it has perfect frequency stability, but it dosn't mean the low jitter perfermance. It seems the actual performance was not as good as the phase noise plot from the FE-5680 PDF file. I don't know why.

I still couldn’t give up my FE-5680. I suspect the sine to square converter was one of the problems.

I don’t like the AC coupled 74XX04(14) sine to square converter. Because additive jitter introduced by both TTL/CMOS buffer and the feedback from its output.

I found a very nice low phase noise clock fanout buffer for sine to LVTTL clock convertion, CDC3RL02, with only –149 dBc/Hz at 10-kHz Offset Phase Noise , or – 0.37-ps (RMS) Output Jitter. It seems perfect for buffering the rubidium clock output. However, when I got the samples, I was surprised. It’s not a normal concept IC, it’s just a wafer DIE with some BGA underneath. I have no any idea about it although I’m quite confident with my hand SMT skill.

Another idea is LVDS buffer. LVDS usually has much higher speed and less additive jitter comparing to the LVTTL buffer. But I have to convert the un-balanced rubidium clock (from a 50 ohm coaxial cable) into a balanced clock, balun is the solution(two grounds could be isolated as well). Then, feed the differential clock into 65LVDS2(or FIN1002) with 1/2 Vcc bias. I attached the schematics just for reference. I built the circuit on a small PCB. It works fine. The output waveform looks good. I’ll use it for the rubidium clock listening test later on.

High speed comparator is an alternative option. But I don’t know which one is better.

Ian

[1audio]

Your problem isn't additive jitter. Rubidiums are not going to easily generate audio clock frequencies and they will have significant spurs that may be ignored or hidden the plots. Here is a very good one with info on how they work: PRS10 - Rubidium Frequency Standard If you look into DDS's e.g: AD9912.pdf you will see that they don't have the same performance for every frequency and they can have some "ugly" output frequencies. This is the chip FEI uses in some of their Rubidiums: AD9830 you will see that there are a lot spurs in its output. It turns out that FEI uses a filter on the output to rediuce the spurs. You could build a crystal oscillator at the target frequency and lock it to the Rubidium's output to clean it up, but I would question whether the improved stability will contribute to better sound and the extra power supplies etc. can only degrade the sound.

Here is some info on working with a Rubidium http://www.vk3um.com/Reference%20Dat...e%20IC-910.pdf

For converting the output Wenzel has some good suggestions: Oscillator Waveform Conversion

[iancanada]

Originally Posted by 1audio

Rubidiums are not going to easily generate audio clock frequencies and they will have significant spurs that may be ignored or hidden the plots. If you look into DDS's e.g: AD9912.pdf you will see that they don't have the same performance for every frequency and they can have some "ugly" output frequencies. This is the chip FEI uses in some of their Rubidiums: AD9830 you will see that there are a lot spurs in its output. It turns out that FEI uses a filter on the output to rediuce the spurs. You could build a crystal oscillator at the target frequency and lock it to the Rubidium's output to clean it up, but I would question whether the improved stability will contribute to better sound and the extra power supplies etc. can only degrade the sound.

I did some listening test on my FE-5680A rubidium clock. And now, I think I have to accept your point.

The FE-5680A and the sine square convertor were powered by two battery packages separately to avoid PSU noise and other issues. The LVDS wave convertor was working very well, much better than the AC coupled 74HCU04 I used before.

Actually the sound of FE-5680A was pretty controversial. It was quite musical and the low range (bass) was very good. The details were not bad as well. But if you listen to it with careful, the problems were obviously there, the bad stereo imaging and the strange 3D feeling. Comparing with the reference clock, the background was not that clean and the sound was bit louder and nosier. It looks like that this rubidium clock has some remarkable features, but at the same time, also something far from perfect. I suspect, just as you pointed out, it might caused by some "ugly" output frequencies which shows as some the spurs on the phase noise plot.

I will remove this FE-5680A from my testing list and do not waste my time on it any more. Some new generation rubidium clock or rubidium based clock solution might be suitable for the audio application, but not include this one.