EEVblog #683 - Rigol DS1000Z & DS2000 Oscilloscope Jitter Problems

[sergey]

Tanks Sergey. Of course should not be difference in FFT if you measure the same signal. AC coupled trigger supposed to be for triggering and not supposed to change the signal digitization in the measurement path. So something is smelling fishy.
The FFT charts have a small  frequency span though, can you do it over a couple MHz (place center of the chart to 1MHz)

EDIT: It can also be seen the AC coupled track is worse in noise going as much as 20dB worse by the right side of the chart.

I's not AC couple trigger, it's AC coupled signal. AC coupled trigger doesn't make any difference to the signal. AC coupled signal allows me to see the noise in a smaller scale, but has some strange effect on the FFT. Probably FFT tries to decompose the DC offset, leading to loads of harmonics.

Also, i'm not really familiar with the FFT function and seems it only depends on the timebase of the signal itself. Meaning, reducing the timebase moves the center point of the spectrum and affects on the horizontal scale as well. Doesn't seem it's possible to move the spectrum window separately from the signal itself. Or i'm missing something.

Anyway, tried my best to get some wider span recording with 1.75MHz as the center. Hope it makes sense

P.S. Can easily do some extra measurements if there'll be some instructions about how exactly to use FFT of the scope.

[MarkL]

Thanks Sergey. Even with the 20MHz bandwidth limit it is still 12dB or more worse noise than my homebrewed PLL. Would be interesting to look at the spectral chart.

The way i'm measuring it is not actually totally nice -- there's a piece of wire from the cap to the probe, plus i'm using the ground lead (not the springy needle). That gives some additional noise. Not sure it could be 12dB tho.

I don't have anything better to get a spectral chart than built-in FFT function, which i've attached. There are two images -- first one is with DC channel coupling, second one is with AC channel coupling. Not sure it's expected to be such a difference in FFT?

You should use a different window, like Hanning, to do this measurement.  You're using rectangle and it's causing a lot of leakage across the frequency domain.  You would typically use rectangle for impulse waveforms.

Also the triggering should not affect the FFT.  As a matter of fact, as long as you have a signal, it does not even need to be triggered for FFT (as long as averaging is not on).

[sergey]

You should use a different window, like Hanning, to do this measurement.  You're using rectangle and it's causing a lot of leakage across the frequency domain.  You would typically use rectangle for impulse waveforms.

Also the triggering should not affect the FFT.  As a matter of fact, as long as you have a signal, it does not even need to be triggered for FFT (as long as averaging is not on).

Good to know

Here are some FFTs with Hamming window.

And just to clarify again: it's not trigger which causes the difference, it's coupling of signal itself which gives issues. But as said, it could be just DC offset being decomposed into harminics. Kind of makes sense.

EDIT: Would it make sense to use some averaging? Seems there's some uncorrelated noise which almost goes away with averaging of 8-16.

[MarkL]

Also, i'm not really familiar with the FFT function and seems it only depends on the timebase of the signal itself. Meaning, reducing the timebase moves the center point of the spectrum and affects on the horizontal scale as well. Doesn't seem it's possible to move the spectrum window separately from the signal itself. Or i'm missing something.

Anyway, tried my best to get some wider span recording with 1.75MHz as the center. Hope it makes sense

P.S. Can easily do some extra measurements if there'll be some instructions about how exactly to use FFT of the scope.

I don't have this scope, but in reading the manual I think the center and span of the FFT can be adjusted by selecting the MATH channel and then adjusting the horizontal position and horizontal scale.  My best interpretation anyway; it's poorly worded.

[sergey]

I don't have this scope, but in reading the manual I think the center and span of the FFT can be adjusted by selecting the MATH channel and then adjusting the horizontal position and horizontal scale.  My best interpretation anyway; it's poorly worded.

Yes, to some degree. Can go from like 100KHz to 800KHz for the given signal time base. It's really doggy thing in my opinion. Well, what could we expect from a builtin software FFT?

[MarkL]

You should use a different window, like Hanning, to do this measurement.  You're using rectangle and it's causing a lot of leakage across the frequency domain.  You would typically use rectangle for impulse waveforms.

Also the triggering should not affect the FFT.  As a matter of fact, as long as you have a signal, it does not even need to be triggered for FFT (as long as averaging is not on).

Good to know

Here are some FFTs with Hamming window.

And just to clarify again: it's not trigger which causes the difference, it's coupling of signal itself which gives issues. But as said, it could be just DC offset being decomposed into harminics. Kind of makes sense.

EDIT: Would it make sense to use some averaging? Seems there's some uncorrelated noise which almost goes away with averaging of 8-16.

Looks a little better, but I think you need some better resolution for the FFT.  You can try selecting Chan1 (not Math) and reducing the sweep speed to squash the waveform horizontally.  It will probably end up resetting some of the FFT display settings, but again I'm not sure how Rigol behaves.

With a lower sweep speed you might be able to resolve some of those hills into sharper peaks, but this is also very dependent on how many points Rigol uses for FFT, which again I don't know and I don't see on a spec sheet.

[MarkL]

You might have better luck saving the waveform to the USB drive, but I didn't try it.  If this still doesn't do it for you, I can try and clean up the octave code a little.

Thanks MarkL, please do not bother, sounds like a learning problem for which I do not have time, but I will try saving on the USB drive.

Do you want to try the good clock source that I build - I can send it to you (you can PM me your email). You will need SMT soldering equipment though to remove the existing coupling capacitors on the scope's board to inject the new clock.

Thanks for the offer, Bud.

I have the equipment to tackle anything SMT, but once I do that I can't in good conscience try to return the scope, which at the moment is where it's headed with the brain-dead beta.  The PLL doesn't quite bother me so much as the keypad locking up, and bugs galore wherever I turn.

But if I do start unsoldering components, I'll probably end up giving it away anyway.  There's someone I know who just started as an EE undergrad.

Let me give it some thought if there are no other takers.

[sergey]

Looks a little better, but I think you need some better resolution for the FFT.  You can try selecting Chan1 (not Math) and reducing the sweep speed to squash the waveform horizontally.  It will probably end up resetting some of the FFT display settings, but again I'm not sure how Rigol behaves.

With a lower sweep speed you might be able to resolve some of those hills into sharper peaks, but this is also very dependent on how many points Rigol uses for FFT, which again I don't know and I don't see on a spec sheet.

That'd reduce resolution of the FFT for as long as i concerned. That's because on Rigols all the math functions are done in software, and seems it uses data from the framebuffer (think Dave covered this with better explanation in one of his video, where he showed a trap for young players where A+B didn't work correct when one of the traces wend out of the visible area of the screen).

So afraid we're quite close to what we can expect from this FFT..

[MarkL]

EDIT: Would it make sense to use some averaging? Seems there's some uncorrelated noise which almost goes away with averaging of 8-16.

Ooops I didn't address this question -

Averaging will improve the waveform display, but I have also seen it introduce some weird side affects into FFTs that are likely implementation dependent.  I usually don't use averaging for that reason.

If you turn on averaging and it does more than just lower the noise floor of the FFT, like create additional spurs, don't use it.

[sergey]

Averaging will improve the waveform display, but I have also seen it introduce some weird side affects into FFTs that are likely implementation dependent.  I usually don't use averaging for that reason.

If you turn on averaging and it does more than just lower the noise floor of the FFT, like create additional spurs, don't use it.

Hah, tried and indeed it's weird. So yes, don't recommend it

[MarkL]

Ok, so Bud, can you see what you were looking for (or perhaps the lack of it) in sergey's captures?

[Bud]

Let me give it some thought if there are no other takers.

OK on that , MarkL.

I wonder if you have access to the ADC chip (pins 17-20) to measure its internal PLL spectrum, which is judging by limited information in the datasheet should lock to the ADC clock, which currently is bad.

http://www.hittite.com/content/documents/data_sheet/hmcad1511.pdf

This could be the way garbage is propagated all down the stream into the scope. Who knows if it may have to do with the scope keys lock ups.

PS: may be I should stop using the garbage word, 'cause this may be offensive to real innocent garbage, out of which a lot of good things can be made. Rigol's clock is worse than that. May be I should call it the "chaos clock".

Definition from Webster dictionary:
"Chaos:  complete confusion and disorder : a state in which behavior and events are not controlled by anything"

Cant say any better.

[MarkL]

I wonder if you have access to the ADC chip (pins 17-20) to measure its internal PLL spectrum, which is judging by limited information in the datasheet should lock to the ADC clock, which currently is bad.

http://www.hittite.com/content/documents/data_sheet/hmcad1511.pdf

This could be the way garbage is propagated all down the stream into the scope. Who knows if it may have to do with the scope keys lock ups.

PS: may be I should stop using the garbage word, 'cause this may be offensive to real innocent garbage, out of which a lot of good things can be made. Rigol's clock is worse than that. May be I should call it the "chaos clock".

Definition from Webster dictionary:
"Chaos:  complete confusion and disorder : a state in which behavior and events are not controlled by anything"

Cant say any better.

That would be interesting to look at.  Great idea.

Just glancing at it under the microscope it's going to be harder to get the diff probe in there because the heatsink and the heatsink clip are in the way.  I'll see what I can do.  Probably later this evening.

The ADC PLL could be smoothing out some of the modulation in the incoming clock.  I was wondering why the close-in peaks next to the main carrier on the SA vs. the FFT of a 10MHz signal were so much lower.  We'll see.

I sincerely doubt any of the sample clock weirdness has anything to do with the keypad lockups.  The keypad is under control of the main processor and it has its own clock.

Since we all have our theories, I'll put mine forward and say that they added code to the keypad driver to look for some held-in combination when the thing is booting and they blew it.  Why else would you mess with a working keypad driver.  But who knows.  Total conjecture on my part.

[marmad]

Since we all have our theories, I'll put mine forward and say that they added code to the keypad driver to look for some held-in combination when the thing is booting and they blew it.  Why else would you mess with a working keypad driver.  But who knows.  Total conjecture on my part.

The DSO is still fully-functional when it boots with the keypad locked, responding to any and all SCPI commands - even the IEEE 488.2 common command *RST - which will reset the DSO to it's factory settings (but doesn't start the keypad working). The scope is acting as if the :SYSTem:LOCKed command has been turned on, although it reports (via SCPI) that the LOCK is OFF.

[MarkL]

I wonder if you have access to the ADC chip (pins 17-20) to measure its internal PLL spectrum, which is judging by limited information in the datasheet should lock to the ADC clock, which currently is bad.

DWS1054Z single channel sampling at 1GS/s.  LCLK = 500MHz, FCLK = 125MHZ as expected.

It looks like the ADC PLL is faithfully following the input clock.  No surprises here.

The good thing is that it doesn't completely throw the ADC PLL into chaos.

PS - Analyzer offset now set properly for your amplitude viewing pleasure.


EDIT:  Added FCLK and LCLK in the time domain.  Scope BW = 1GHz, so maybe there's some detail we're not seeing.  But I would expect a better FCLK signal.  Maybe it's not terminated properly.  These traces were taken with a 1.7GHz differential probe.

The probe input was double checked with a clean 100MHz signal afterwards.  It is NOT the probe.

[rs20]

...
It looks like the ADC PLL is faithfully following the input clock.  No surprises here.
...

Just curious, if we saw a PLL with 500 MHz output locked to a jittery 125 MHz input, shouldn't a 100ppm error on input frequency lead to a 100ppm error on output frequency? Yet, we're seeing a 127 kHz side-peak on 125 MHz signal (100ppm frequency error) leading to a 125 kHz side-peak on 500 MHz (25 ppm). To be fair, I don't have any decent intuition on how jitter is supposed to look on spectrum analysers, but can someone explain how the frequency scale is being translated 375 MHz rather than scaled 4x here?

[orin]

Since we all have our theories, I'll put mine forward and say that they added code to the keypad driver to look for some held-in combination when the thing is booting and they blew it.  Why else would you mess with a working keypad driver.  But who knows.  Total conjecture on my part.

I suppose that's possible, but my money would be on an uninitialized variable in the keypad initialization code.  Leave the scope off for a while and the RAM tends to boot up in a certain state; on some scopes that state causes the hang.  Restart the scope and the RAM tends to keep the last value stored which would seem to enable the keypad.  If the source were in front of me, it would be the first place I'd look anyway.

Orin.

[Bud]

MarkL - thanks a bunch for the work you have done, we are fortunate to have you here with all your nice test equipment, except the Rigol scope which is itself being under test.

So we can now say the RCC (Rigol Chaos Clock) is not limited to just channel input signal sampling and is propagated to the downstream bus, causing whatever damage. By other words, until Rigol delivers the proper fix,

YOU GUYS CANNOT TRUST YOUR RIGOL SCOPE

Such a fix would be a change that will get the ADF4360-7 PLL (ADC clock source) to generate the proper 1GHz signal. I have attached a side by side screenshots again what it is now and what it has to be. Can this be done without a hardware change - I personally doubt but that is IMHO.

Here is what the ADC datasheet says in regards to clock:

...The quality of the input clock is extremely important for high-speed, high-resolution ADCs
...If the clock is generated by other circuitry, it should be re-timed with a low jitter master clock as the last operation before it is applied to the ADC clock input.

[Bud]

To be fair, I don't have any decent intuition on how jitter is supposed to look on spectrum analysers,

Jitter can be mathematically calculated from spectral data by integrating the area under the spectrum curve over a given frequency range, there is a ADI document explaining this:

http://www.analog.com/static/imported-files/tutorials/MT-008.pdf

Using this technique, one can see in the last attachment I posted, by looking at the area under the curves that Rigol existing jitter on the left picture is huge compare to a proper clock source on the right one.

[motocoder]

Since we all have our theories, I'll put mine forward and say that they added code to the keypad driver to look for some held-in combination when the thing is booting and they blew it.  Why else would you mess with a working keypad driver.  But who knows.  Total conjecture on my part.

I suppose that's possible, but my money would be on an uninitialized variable in the keypad initialization code.  Leave the scope off for a while and the RAM tends to boot up in a certain state; on some scopes that state causes the hang.  Restart the scope and the RAM tends to keep the last value stored which would seem to enable the keypad.  If the source were in front of me, it would be the first place I'd look anyway.

Orin.

Just about any C compiler is going to flag that, though.

[orin]

Since we all have our theories, I'll put mine forward and say that they added code to the keypad driver to look for some held-in combination when the thing is booting and they blew it.  Why else would you mess with a working keypad driver.  But who knows.  Total conjecture on my part.

I suppose that's possible, but my money would be on an uninitialized variable in the keypad initialization code.  Leave the scope off for a while and the RAM tends to boot up in a certain state; on some scopes that state causes the hang.  Restart the scope and the RAM tends to keep the last value stored which would seem to enable the keypad.  If the source were in front of me, it would be the first place I'd look anyway.

Orin.

Just about any C compiler is going to flag that, though.

Unfortunately, the warning often gets turned off due to false positives.  What to do?  Add unnecessary initializations or turn the warning off/reduce the warning level?  Or leave the warning on and initialize the variable in debug builds only...?  I've seen it all and it's still the first place I'd look.

Orin.

[Bud]

Ok, so Bud, can you see what you were looking for (or perhaps the lack of it) in sergey's captures?

Yes, thanks to Sergey for his time spent on testing. While the PLL in it did not seem to have a pronounced problem as the DS1000 did and seems to be locked, the voltage on the CP pin is much noisier than on my home brewed PLL, which may indicate suboptimal configuration for the PLL in DS2000. I would not be surprised knowing how crappy the DS1000 PLL programming was, that Rigol did not obey ADI's specifications/recommendations and knowing that ADI simulator generates totally different loop filter component values for the 100kHz PLL comparison frequency. Mind that in DS2000 Rigol used the same 4360-7 PLL which is rated for 1.8GHz max and not for 2GHz.

Also there is weirdness in FFT for DC vs AC coupled channel input, with AC coupled being worse in noise, and FFT also has unknown spurs. But that may be a separate issue.

[sergey]

Can this be done without a hardware change - I personally doubt but that is IMHO.

Just curious: would that hardware modifications be limited to replacing passives with appropriate values (which is easy to do in the service center, and if one doesn't want to bother with sending the scope can do soldering himself) or the circuit itself is to be modified (meaning for clean solution without bodge wires and so it'll be required to change the whole board in the scope) ?

[nfmax]

I don't have one of these 'scopes, but I wonder if the PLL non-locking issue, which seems so obvious to some but it is clearly not present everywhere, arises at bottom from a bit of unauthorised 'equivalent' part substitution along Rigol's supply chain? Maybe the engineering prototypes all work just fine. It would explain the request for access to units known to suffer from the problem.

[sergey]

I don't have one of these 'scopes, but I wonder if the PLL non-locking issue, which seems so obvious to some but it is clearly not present everywhere, arises at bottom from a bit of unauthorised 'equivalent' part substitution along Rigol's supply chain? Maybe the engineering prototypes all work just fine. It would explain the request for access to units known to suffer from the problem.

Did i miss something or there's no reports about properly locked PLL in DS1000z series? I don't have issues with PLL because i'm using DS2000 series. We were just comparing behavior of this two guys because their PLL schematic is quite the same.