Sub-$500 DSOs for Jitter Measurement

[pfm]

Hi,
one of things I'd like to be able to do with a basic DSO (sub-$500 like SDS7102) is make jitter measurements on digital data streams and clocks, specifically SPDIF and I2S audio data streams and clocks. Typically these streams should have not have a bitrate/frequency of more than 6-9Mhz. By "jitter measurement" I mean histogram type results that show the deviation and also fft that shows the spectral content of the jitter.
So are there any scopes in the sub-$500 category that would work for this purpose ? I guess that jitter noise floor is the spec to look for, correct ? But for cheaper scopes manufacturers dont give out that number or just give some irrelevant number - like the core clock jitter.

If the scopes dont have such a feature built in I am ok with just doing a fast real time sampling and exporting the data out for analysis using a third party or diy (I know programming) software.

Please advise.
Thanks.

[ve7xen]

I'm not sure any remotely low-end scopes have in-depth jitter analysis capabilities. It's typically a (not inexpensive) add-on feature only available on higher end instruments, as it's normally only relevant on high-speed systems these days. You can get an idea of the jitter amplitude by using 'infinite persistence' in many DSOs these days (ie. an eye diagram), but this doesn't provide any information on the time function of the jitter. Such analysis, I believe, requires some fairly in-depth signal processing on the captured data, especially if you need to do clock recovery as in SPDIF. Which I guess is good news for you if you're willing to write it - what you'll want out of the scope is as fast a sample rate (high timing resolution) and memory depth (many sequential clock transitions) you can get and most importantly, a way to export the captured data. Your scope's timebase (ie. sample jitter) needs to be better than the DUT in this situation I believe, which might be trivial or might require a scope with an external timebase input or one way, way out of your meager budget. Alternately you might be able to use the scope's second channel with a stable timebase and use it to re-timestamp the samples in software, rather than trusting the scope's built in timebase. Trigger jitter should be very low on modern scopes, I don't think it's a big factor.

At 1Gsps and with 10Msample memory the SDS7102 will give you 1ns resolution over a 10ms measurement period, which should allow you to measure the jitter frequency spectrum down to 200Hz. With correlation in your signal processing you might be able to get more frequency data out of it from multiple captures.

IANAEEPhd.

[pfm]

.. might require a scope with an external timebase input or one way, way out of your meager budget. Alternately you might be able to use the scope's second channel with a stable timebase and use it to re-timestamp the samples in software, rather than trusting the scope's built in timebase.

could you please explain the second channel timebase and re-timestamp part ? I didn't quite follow.



73 de KC0GVT.

[ejeffrey]

The idea there would be that you would put your desired signal on channel 1, and feed a very stable 10 MHz (for example) clock to channel 2.  Any timebase jitter on the scope will show up in the reference signal where you can measure it and subtract out from the measured signal.  I wouldn't expect this to be necessary.  I2S and SPDIF are not exactly high performance protocols.  I would be very surprised if even a budget scope had a bad enough time base to worry about.

[ve7xen]

The idea there would be that you would put your desired signal on channel 1, and feed a very stable 10 MHz (for example) clock to channel 2.  Any timebase jitter on the scope will show up in the reference signal where you can measure it and subtract out from the measured signal.  I wouldn't expect this to be necessary.  I2S and SPDIF are not exactly high performance protocols.  I would be very surprised if even a budget scope had a bad enough time base to worry about.

Yeah that's what I was thinking. I detected a hint of audiophile ambitions in the original request though, so a rather over-engineered option was provided . Some of these guys go nuts over clock jitter (but few try to measure it, so if that's what you're after pfm, kudos to you!).

[AndyC_772]

I should admit, I did once get sucked into an online debate about jitter on SPDIF interfaces, and I committed a cardinal sin: I backed up my assertions with actual evidence from scientific measurement. I hooked up a couple of devices to a scope, measured the jitter, and presented cold, hard facts instead of the more traditional uninformed guesswork.

It didn't go down well! Who'd have thought that a well-reviewed CD player would deliver a much, much worse quality of digital output than a relatively low cost wireless media player?     

[SeanB]

Jitter is totally ignored until it becomes large enough to interfere with the input data sampling when it then just stops working. If you have a digital satellite receiver look at the error rates and watch how bad they have to get before the picture degrades to blocks and then nothing.

[AndyC_772]

I dare you to post that on an audiophile forum!

I think the basic premise is that an audio DAC works by locking a PLL onto the SPDIF stream to recover the bits, and therefore any jitter in that stream must translate into jitter at the DAC chip itself.

I don't think the concept of the dual-port RAM or FIFO has really sunk in amongst the audiophool community.

[ve7xen]

In I2S it is perhaps more relevant as the DAC's sample clock is directly provided by the I2S master, so any jitter on it will modulate the output (without a resampler, which introduces its own issues). It's still probably not significant to be measurable, let alone audible, but the technical argument is valid as I understand it. I don't have the signal theory to quantify it in real terms, however.

SPDIF is always reclocked so if the PLL is tuned properly I don't think short-term jitter from the source should appear in the output clock? I wonder about the time constants though, the necessities of making the loop work well at x MHz may let lots of jitter through in lower frequencies, like AF...

I'm pretty curious to see measurements. If you come up with a technique that works, please do post your results and technique here, no matter what you're testing! I have a few audio widgets I'd be interested to compare out of curiousity around these things.

[pfm]

The idea there would be that you would put your desired signal on channel 1, and feed a very stable 10 MHz (for example) clock to channel 2.  Any timebase jitter on the scope will show up in the reference signal where you can measure it and subtract out from the measured signal.

Ok so the idea is to apply a reference(sort of) clock with low and/or known jitter on the second channel to figure out how much the intrinsic jitter of the scope is, correct ?

I would like to able to measure down to less than 50ps (picosec). Is that an unrealistic expectation ?

I am afraid I might hijack my own thread but I will give in -
I am by no means an audiophool (I am the one who is usually poking fun at their $3000 cables and green cd paint), I just have a not-so-fancy audio system but the effect of jitter on sound does intrigue me. My understanding is that modern day equipment may be less prone to it. In the early days with bad clocks, 1-bit-delta-sigma converters and plls that cant remove jitter from the audio band (20hz-20Khz) the effect was much more obvious.

To put it in very simple terms - Jitter is the modern day equivalent of wow and flutter in old turntables and tapes, except at much higher frequency. Its like the turntable or tape motor speed is varying say 10000 times per second. That causes the 'digital' sound signature that many people dont like. So there is truth to it no doubt. Just bits getting through somehow is not enough. They need to arrive at the right time. The biggest bone of contention is 'how much jitter' is a problem ? 20ps ? 200ps ? 2000ps ? There are formal studies and papers, not just basement scientists/labs telling their story, search for "audibility of jitter" you will find some.

However, the notion that there is no difference in sound between 50ps jitter v/s 5000ps jitter is not true. If you want to see some real world measurements and examples you could go here - http://www.stereophile.com/features/368/index.html

[AndyC_772]

I'm curious. Where are you planning to make this measurement?

A few years ago I designed an audio DAC in which the actual DAC IC has its clock connected directly to the output of a VCXO. There's no route by which any jitter in the SPDIF stream could affect it.

My professional background is in the communications industry rather than audio, so maybe there's a reason why audio engineers wouldn't do this. Or maybe I've come up with something genuinely new and unique in the industry? Certainly I've never seen this done in a piece of hi-fi kit, but there's no reason not to. I've been listening to the result every day for the last few years, and it's the best sounding piece of equipment I own.

[ve7xen]

Ok so the idea is to apply a reference(sort of) clock with low and/or known jitter on the second channel to figure out how much the intrinsic jitter of the scope is, correct ?

You don't just need to know the average amount of jitter intrinsic to the scope, if you want to compensate for it you need to know the time offset of any given sample so you can subtract it out.

I would like to able to measure down to less than 50ps (picosec). Is that an unrealistic expectation ?

Not for $500 I don't think. You might be able to get a surplus TIC (e.g. SR620) that can do this for your budget. Also perhaps KO4BB's PICTIC project would work, it has 18.75ps max resolution. You'd need some way to generate a phase-locked jitter-free clock to compare to, however. Keep in mind you'll only get average jitter magnitude this way and not the time domain information you were asking about.

A few years ago I designed an audio DAC in which the actual DAC IC has its clock connected directly to the output of a VCXO. There's no route by which any jitter in the SPDIF stream could affect it.

As far as I understand, any practical SPDIF receiver needs to lock its DAC clock to the SPDIF stream, or do asynchronous resampling. The former will allow jitter to 'leak' into the output clock, the latter requires fairly costly hardware and its own host of issues. Not doing either means your clocks will slip and you'll need to insert or drop samples which is probably worse than letting some jitter in..

[pfm]

I'm curious. Where are you planning to make this measurement?

A few years ago I designed an audio DAC in which the actual DAC IC has its clock connected directly to the output of a VCXO. There's no route by which any jitter in the SPDIF stream could affect it.

I plan on doing the measurement at the spdif output of the source (cd player, digital media player,..)

Thats how all DACs are done - vcxo becomes the mclk. The source of jitter would be the PLL that controls the VCXO, and the vcxo itself. Not just its intrinsic jitter but the pll will simply let all jitter above its loop bandwidth cutoff to simply pass through unabated. That was pretty much the case up until now. Then the WM8804/5 spdif receiver came along that has only 50ps intrinsic jitter and can filter jitter all the way down to 100hz. That pretty good (relatively) but with an average quality vcxo you could still end up with ~100ps total jitter.
So if your source is crappy then your system would benefit a lot from a better spdif receving arrangement. If not, you might not see much improvement.

[AndyC_772]

As far as I understand, any practical SPDIF receiver needs to lock its DAC clock to the SPDIF stream, or do asynchronous resampling. The former will allow jitter to 'leak' into the output clock, the latter requires fairly costly hardware and its own host of issues. Not doing either means your clocks will slip and you'll need to insert or drop samples which is probably worse than letting some jitter in..

It needs the DAC clock to run at the same long-term average speed as the input data, that's all.

In my case, the "PLL" is a piece of logic which wakes up every few seconds, checks the level in a FIFO, and makes a small adjustment to the VCXO speed if (and only if) necessary before going back to sleep again.

I get the impression conventional thinking is that the clock at the DAC must somehow be directly related to and derived from the timing of the edges between the data bits, and that its timing must therefore vary from one sample to the next in a way which is determined by the input data stream. This is simply not the case.

[pfm]

In my case, the "PLL" is a piece of logic which wakes up every few seconds, checks the level in a FIFO, and makes a small adjustment to the VCXO speed if (and only if) necessary before going back to sleep again.

ah..didn't realize you had a fifo going there. That would be the way to do it. Well, Kudos to you for implementing that. I would be quite interested in learing more about your project. Would you mind sharing ? PM or email me if you'd like.

[ve7xen]

I get the impression conventional thinking is that the clock at the DAC must somehow be directly related to and derived from the timing of the edges between the data bits, and that its timing must therefore vary from one sample to the next in a way which is determined by the input data stream. This is simply not the case.

I don't think anyone thinks that at all. Disciplining a VCXO based on the input data rate is a fine solution indeed, but requires a relatively costly VCXO and the necessary (low noise! or you're introducing jitter yourself) DAC to control it. Also harder to generalize into something you're going to get baked into an IC due to VCXO tuning parameters, how good or bad a clock you need to lock to etc. You don't need direct coincidence for every edge, but you do need to lock tightly enough that you don't go out of sync, which I assume usually means you're going to let audio frequency jitter pass right through unless the loop is tuned for high quality oscillators - which standard receivers won't be. Recovering the received clock is the cheap solution, so that's what the consumer audio gear does.

Audiophiles in the know just tend to avoid SPDIF entirely rather than trying to develop a fancy solution to the clock recovery problem, though I have seen a few. Some of the better more modern receivers are supposed to be pretty good too - but as is typical, I haven't seen measurements.

[pfm]

about avoiding spdif - thats a good example why you may still not be able to escape reclocking entirely. Even if alternatives like say I2S are used and the source has less than desirable clock then you are still in the same spot - you still want/have to reclock.

wish the digital audio/video world could have just made a "Master Clock INPUT" standard on all equipment. Then you stick one good stable clock into that pin and you are done! No recovery or cleanup needed! Most pro equipment does I guess ? Or maybe thats what you were referring to when you said avoid spdif.

[AndyC_772]

You don't need direct coincidence for every edge, but you do need to lock tightly enough that you don't go out of sync, which I assume usually means you're going to let audio frequency jitter pass right through unless the loop is tuned for high quality oscillators - which standard receivers won't be.

Not really, you just need a buffer that can store a few samples. Provided the long-term average clock rate of the VCXO matches that of the input stream, the FIFO never overflows or underruns. Provided the loop controlling the VCXO can keep the FIFO level valid, it can respond as slowly as you like - in my case, several orders of magnitude below the audio band.

[ve7xen]

Sorry, I was referring to the PLL clock recovery method in that quote. Which can do the same thing as your VCXO, but needs some magic tricks to lock in an acceptable time but still have a slow response. How do you lock your VCXO at startup? Just wait the n seconds or do something more intelligent?

[AndyC_772]

It's laughably simple, actually: every couple of seconds the VCXO control voltage is set proportional to the number of samples in the FIFO.

[Smokey]

Check out time interval analyzers.
http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_nkw=TIME+INTERVAL+ANALYZER&_sop=12