EEVblog #683 - Rigol DS1000Z & DS2000 Oscilloscope Jitter Problems

[Bud]

Yes there is a common issue with DS 2000 . The AC coupling trigger jitter.

[Orange]

Yes there is a common issue with DS 2000 . The AC coupling trigger jitter.

Where are talking about the PLL jitter issue in this topic. The AC coupling jitter issue has nothing to do with PLL instability in the DS1000z. I'm not sure why you bring this up. Are you simply trolling now ?

[Bud]

Only yours and mine are worse after beta?

That is sufficient to say the beta did not correct the issue.

[MarkL]

MarkL, i'll check tomorrow if i can get second scope here. If not i'll try to probe itself without blowing it up

As for instability in the clock, my first thought after watching the video was whether using external low-drifting clock (like rubidium standard) would do any difference to the jitter issue on ds1000z series.

If you have the opportunity for additional equipment, I would go for a spectrum analyzer too.  Bud described a probing technique to minimize loading the output, here:

  https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg561375/#msg561375

But at these frequencies even an insulated loop laid over one of the output capacitors would couple enough energy to examine the spectrum envelope.

Rubidium standards have PLLs in them too, so long as you know your output is stable.  I have one of the ever-so-popular FE5680A, and while long term it's very stable, it does exhibit a little more short-term jitter than a crystal oscillator.  Still fine for what we're doing here, though.

[Bud]

I have parts on order and will assemble a good clock source and can ship to anyone who is willing to test it on their scope.

[Bud]

Yes there is a common issue with DS 2000 . The AC coupling trigger jitter.

Where are talking about the PLL jitter issue in this topic. The AC coupling jitter issue has nothing to do with PLL instability in the DS1000z. I'm not sure why you bring this up. Are you simply trolling now ?

I will let people judge based on contribution who is trolling.

[motocoder]

Totally agree. In my case, Chris and team "upgraded" the firmware on my scope while they had it at their facility to use in investigating a network bug. So I had no choice in the matter. My only plan for this scope is to sell it. First that was delayed waiting for Chris and Steve to return it. Now that is delayed waiting for a firmware that doesn't randomly lock up the scope (WORSE than the situation before I sent it in for "repair").

Are you saying you can't simply downgrade the firmware via the bootloader method on the DS2000? Afaik, this would be a first for the DS2000 series.

I don't really know about the bootloader history/availability on the DS1000Z series (there is no reference to it that I can find), but if what you're saying is true, it negates the Rigol published and long-circulated document, "DS2000 DS4000 DS6000 Firmware Upgrade Procedure".

Nope, I just assumed (and I think we all know what happens when you do that) that the problem applied to any scope running a recent beta, and I was a bit fearful to try a downgrade, have it fail and render the scope useless. But I overcame my fear and tried it. It downgraded to 00.03.01.00.04 with no issues, so I'm a happy camper again.

Chris and Steve - sorry for my previous comments based on my faulty assumption.

[Bud]

Well the PLL in a DS2000 runs at 2GHz, the one in the DS1000z on 1 GHz, also we don't know the loop filter component values of the DS2000 and we don't know how the chip is programmed.
But I really doubt there is a similar problem that needs fixing on the DS2000 since is no jitter on these beauties.

We do know the resistors values in the loop filter on DS2000 are the same as on DS1000. This can be seen in the above photos and from what MarkL measured on his DS1000. Then, because of the mathematical formulas for loop filters the capacitors have to be also be the same as in DS1000. Therfore the loop filter is the same . Guess what, loop filters are designed for a specific internal detector frequency. That means good deal of programming is the same on both models.

[Teneyes]

Just to Summarize ; I understand there are 3 jitter occurrences
                                      DS1000       DS2000
  1. DC Trigger (5us delay)          Yes           No       
  2. AC Trigger                      Yes          Yes
  3. Trigger Output                  Yes          Yes

And that the PLL affects #1

[Bud]

Please offer a reasonable explanation why AC coupled trigger issue had not been addressed for two years and all of a sudden a fix was announced in beta when we pointed out to the problem with the PLL.

And please offer a reasonable explanation why Rigol was quick to announce DS2000 will be also updated for AC coupled trigger issue.

Here is my reasonable explanation: AC coupled  trigger is somehow derived from the clock. Garbage clock, garbage AC trigger. The 5uS issue in DS2000 may have been masked because the clock is 2GHz. What is the exact dependency I certainly not have enough information to say.

[Bud]

Only yours and mine are worse after beta?

That is sufficient to say the beta did not correct the issue.

And by the way, from MarkL's Spectrum Analyzer data it did not correct for him either, just made it less pronounced. So whoever thinks it fixed the issue for them are sitting on a time bomb ticking to explode.

[marmad]

Please offer a reasonable explanation why AC coupled trigger issue had not been addressed for two years and all of a sudden a fix was announced in beta when we pointed out to the problem with the PLL.

And please offer a reasonable explanation why Rigol was quick to announce DS2000 will be also updated for AC coupled trigger issue.

Well, I don't know if the problems are related, but the answer to these questions is blatantly obvious. Dave made a video decrying the bug(s) which has garnered a bunch of attention - period. To cite this as evidence of anything else is silly.

[MarkL]

Although not as definitive, you might also be able to examine a long-point FFT taken with the scope of a known stable source (like a crystal oscillator).  If the sample clock is unstable you should see modulation in the FFT.  I'm not familiar with how many points the various Rigol models use for it's internal FFT calculations, so I would download the long raw waveform capture and process it externally.  Obviously this doesn't involve taking the scope apart, and it might be a good starting point that would show if there's any egregious problem.  However, it's still not proof the PLL is locked.

Thought I'd provide an example of what you might see in a raw FFT from the DS1054Z running beta.  If you did just the jitter test, as I first did, you might think it fixed.  But look at the FFT of a 10MHz source.  Note the similarity to the spectrum analyzer screen shot beta_main_carrier_640x480.jpg previously posted:

  https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg560788/#msg560788

You can see the same modulation in the main carrier.  Plus a mess of other spurs, but it's not clear at this point where those are coming from.

For comparison, also included is the same source with a raw FFT from an Agilent.

The Rigol is a 1.1Mpt capture and the Agilent is 4MPts.  1.1MPt was all I could get out of the Rigol without additional contortions.  Its SCPI Ethernet implementation is quite buggy.

The source does have those spurs at +/- 2MHz @ -70dBc.  And ignore the absolute amplitude on the Rigol capture.  It's supposed to be dBV, but I think the channel units are not converting right when grabbing the raw data.

EDIT:  Oh, and Rigol was 1GS/s, Agilent 5GS/s.  Each had 1 channel running.

[Teneyes]

Please offer a reasonable explanation why AC coupled trigger issue had not been addressed

Well, I don't know if the problems are related, but the answer to these questions is blatantly obvious. Dave made a video decrying the bug(s) which has garnered a bunch of attention - period.

I agree , Dave Jones has a bit of influence. 
Is it a case of 'The squeaky wheel gets the Oil' ?
There are lots of complaints
Also when a bug propagates on to the next model,  shows lack of ?

When Dave Jones shows my E-mail to Rigol from July 2013 in #685 could shame Rigol,
( more like manage sales/profits)

As Marman has asked once , will Rigol make this an important FW release in order to include the block of Hacks and downgrades?

Looking back at the FW of the DS1052,  Rigol must have learnt something.

[(In)Sanity]

Is it a case of 'The squeaky wheel gets the Oil' ?

The squeaky wheel doesn't get the oil in today's society,  it gets replaced by an inexpensive Chinese equivalent.

Jeff

[Bud]

OK Digikey was quick as usual and a ADF4360-7 based 1 GHz clock board now is up and running. I configured 2.5MHz PFD (same as beta) and calculated my own loop filter. Attached are side by side screenshots what MarkL captured on his beta (left) and my PLL clock (right), scaled to a same frequency span. No comments.

Sure enough an LED connected to the PLL MUXOUT pin (which was programmed for Digital Lock Detect) turns on , indicating the PLL is locked to the reference. The voltage on the CP (loop filter) pin is DC 1.1V with a small <3mV rms noise.

If the left stuff is what Rigol will be pushing on their final update, based on the optimistic posts from Rigol NA, I wish you guys good luck with your scopes.

Those who are still concerned we can discuss next steps.

[Bud]

MarkL, i'll check tomorrow if i can get second scope here. If not i'll try to probe itself without blowing it up

As for instability in the clock, my first thought after watching the video was whether using external low-drifting clock (like rubidium standard) would do any difference to the jitter issue on ds1000z series.

Thank you Sergey, will wait for your test results.
As to external clock, rubidium standards put out 10-15MHz , so you cannot just use one for the scope, you may still need to use a PLL and reference it from that low frequency standard. For the 1Ghz clock i just built i used a low jitter integrated TCXO. Sufficient for the purpose.

[sergey]

Thank you Sergey, will wait for your test results.
As to external clock, rubidium standards put out 10-15MHz , so you cannot just use one for the scope, you may still need to use a PLL and reference it from that low frequency standard. For the 1Ghz clock i just built i used a low jitter integrated TCXO. Sufficient for the purpose.

So, bad news are -- i couldn't have get access to an extra scope, so used self-probing. Also i don't have access to the spectrum analyzer, can only do FFT in the scope itself. Don't think it's so much accurate and useful? Good news is that my scope is still operational

What i did is soldered a small piece of wire to the cap which seems to be connected to pin 24 of the PLL. Unless i'm wrong it's bottom pin on the left side of the chip. Attached the picture so one could doublecheck i got the pinout correct (extra eyes never hurts, you know

Now, not sure how to make a nice screenshot on the scope so i made photos with my creepy camera (so excuse me for the crudity of the model) and also saved traces with the scope. Never used them before and couldn't find an application in few minutes.

Anyway, hope it gives some bit of information.

P.S. Scope is still open so can do some additional non-destructive tests.

[Bud]

Thank you Sergey. Can you turn on 20MHz bandwidht limit on the channel input and see how much noise goes away.
The screenshot shows 2.35 v DC which is close to 2.5v limit in the datasheet but still within the spec. Seems to have pretty noticeable ~100kHz spikes which most likely come from PFD. I will measure my PLL using same 500mV/ vertical gain to see how noise track compared with yours.

Also can you try turning AC trigger coupling on and see if that causes any changes to the voltage on CP pin.

[sergey]

I made a mistake previous time -- silly me didn't connect the probe ground assuming it's not needed since the ground is all the same. I was wrong

With probe ground  properly connected spikes amplitude goes down to 180-200mV. AC trigger doesn't seems to make anything noticeable (apart form trickier trigger coz of jitter, used single shot of a long timeframe for comparison and didn't see huge difference).

With 20MHz bandwidth limit the noise is down to about 50-60mV.

EDIT: Just clarify: there's no difference with both noise and DC level of the CP pin between DC and AC trigger coupling.

[Bud]

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.

MarkL, what did you use to download large waveform samples? I tried a software praised in another thread but i only get 1k samples or something, though i set a large memory buffer on the scope. Is a SCPI command for it?

[MarkL]

MarkL, what did you use to download large waveform samples? I tried a software praised in another thread but i only get 1k samples or something, though i set a large memory buffer on the scope. Is a SCPI command for it?

It's a program I wrote in Linux octave with its optional sockets package.  It's still incomplete and was originally written for the Agilent scope and works fine for it, but now it's a total structural mess to accommodate quirks in the Rigol.  And it doesn't work consistently on the Rigol.  I would try the other package you have first since that no doubt can handle the Rigol weirdness better.

I was stuck at 1200 points also.  Here are the relevant oddities I discovered for a large download:

- You can't buffer multiple commands into the SCPI port.  One command at a time and wait for the response (if any).

- You can only change the memory record size when the capture is running.

- If you set the scope to anything larger than 1.2MPts (1200000) it sometimes returns a 0 point result.

- You have to set the ending waveform point, otherwise it defaults to 1200 points returned.

- You can't set the ending point to 1200000, otherwise you get 0 points.  I used 1100000 (:WAVeform:STOP 1100000).

- Even if you do capture more than 1.2MPt, I couldn't get it to return much more than 1100000 points anyway (when it didn't return 0).  I think setting the start and stopping points would eventually allow retrieval of the entire memory but I didn't bother doing it.  1.1MPts was enough to show what I wanted.

So, the crucial things to do are:

  :run
  :ACQuire:MDEPth 1200000
  :stop
  :WAVeform:STOP 1100000

Waveform is captured at this point.  I used the following to do the raw download:

  :WAVeform:mode raw
  :WAVeform:PREamble?
  :waveform:data?

Once set up, maybe your package can do the download since the preamble is correct at this point.

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.


If anyone is going to start diving deep into SCPI bugs, please start a new thread or perhaps take it to the Bugs/Anomalies thread.

[sergey]

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?

[Bud]

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.

[Bud]

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.