EEVblog #683 - Rigol DS1000Z & DS2000 Oscilloscope Jitter Problems

[MarkL]

...
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?

In general, jitter on a spectrum analyzer will appear as a widening of the main carrier frequency due to random noise or periodic influences.

My interpretation of the case we have here is that the jitter has at least some modulation components.  Those close-in peaks near the carrier are related to the *frequency* of the modulation (not the amplitude), like you would see in FM modulation.  It appears it has a modulation frequency involving 62kHz and 125kHz (and possibly others) with a small deviation.

Because the close-in peaks are related to the frequency of the modulation, it's why you also see them at the same spacing after the carrier has been divided by four from LCLK to FCLK.  For each divide by two you should also see them drop by 6dB, which is also the case here (11.99dB - almost too perfect...).

Maybe Bud or other reader has a further or different interpretation.  One thing for sure is the input clock shouldn't be doing this, but I don't see anything in the ADC output clocks that can't be explained.  That's why I say it's tracking the "garbage in".


If you're curious and looking for an intuitive feel, set up a signal generator with an FM input, maybe 10MHz carrier, 20kHz modulation, and 300Hz deviation, and feed it into a couple of cascaded flip flops each set up to divide by 2.  Look at the output on a spectrum analyzer or scope FFT.  It's pretty interesting to see what effects the modulation parameters have on the spectrum, and see how the division works.

[MarkL]

Did i miss something or there's no reports about properly locked PLL in DS1000z series?

I haven't seen any reports.  It's only easy to prove it's *not* locked with the 5us jitter.

Without access to the LOCK bit, it's harder to say it *is* locked unless you look at the clock directly on a spectrum analyzer, or indirectly by doing a long point FFT of a stable signal as I previously described.

If someone wants to create a quick program using one of the various packages that does a long point FFT (like 1 or 2Mpts), we could pass that around and get an idea which models do or don't have clock problems, including the DS2k series.

[Bud]

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) ?

As far as the PLL is concerned, it is the loop filter components (3 caps, 2 resistors) that woul need to be replaced. I could tell now what they should be but the problem is with Rigol PLL programming. As i said a few posts back, they do not follow manufacturer's (Analog Devices) recommendations and program values in it that do not make sense. Based on information from ADI you cannot relay on the simulator if you do this. I used the ADI simulator when i built my PLL, as you can see it works perfectly, and i can tell what the loop filter should be but until Rigol reads the PLL datasheet and honors manufacturer specifications and does programming properly, the new loop filter will not work if i publish it.

In my opinion Rigol should redesign the PLL both programming and loop filter, and if this will require loop filter change  they should bite the bullet and recall the defective product for upgrade in service centers. Mind you my fellow EEBlogers, there is a product out there with the ABC and the holy grail of digitizing - ADC clock - being totally screwed.

[Bud]

MarkL - nice idea and may be useful for checking other Rigol scope models

[xnaron]

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.

It's probably unlikely that Rigol will comment on any of this reverse engineering of their scopes.  The proof will be in whether the final firmware fixes the issue.  I am hopeful it will as I want to trust my Rigol scope.

[sergey]

I am hopeful it will as I want to trust my Rigol scope.

Better to have second one just to be sure

And i also loved MarkL's idea. Unfortunately, i wouldn't have time for until next week, but then might try looking into it. No promises tho!

[MarkL]

And i also loved MarkL's idea. Unfortunately, i wouldn't have time for until next week, but then might try looking into it. No promises tho!

I just checked and it works fine to save large captures to the USB drive.  So you don't need to deal with the network or the scope plugged into a USB host and all the fun drivers that go with those.

Under "Acquire" you would set the scope to do 1.2MPts for a DS1054Z (or somewhere around that if other models have different lengths).  120k isn't enough, and any more than 1M or 2M doesn't provide additional information.  The scope needs to be in "Run" to change the record length.

Whatever stable input you're capturing, make sure it's also happening at the maximum sample rate of the scope (1GS/s for DS1054Z).

Under "Storage" select "Storage > Waves", and do the save.  I stopped the scope before doing the actual save, but I'm not sure that's necessary.

I'm certain I saw a posting by someone who developed a program that reads Rigol .wfm files but I can't find it at the moment.  For a quick and dirty hack to validate the data I just chopped the header information off the front and read the data bytes directly into octave (matlab).  The data bytes start at 0x0C7E for the files it made for me, but this is NOT clean, and NOT the right way to do it.

[ted572]

And i also loved MarkL's idea. Unfortunately, i wouldn't have time for until next week, but then might try looking into it. No promises tho!

I'm certain I saw a posting by someone who developed a program that reads Rigol .wfm files but I can't find it at the moment.  For a quick and dirty hack to validate the data I just chopped the header information off the front and read the data bytes directly into octave (matlab).  The data bytes start at 0x0C7E for the files it made for me, but this is NOT clean, and NOT the right way to do it.

Try MATLAB release 7.5 R2007b or newer.

[EEVblog]

Well I was just about to do a video upgrading my unit and seeing what happens, but Rigol have pulled the firmware.
So won't be able to do jack before they release a new version, that includes finishing my review (supporters have already seen 1hr of footage).

[Monkeh]

Well I was just about to do a video upgrading my unit and seeing what happens, but Rigol have pulled the firmware.
So won't be able to do jack before they release a new version, that includes finishing my review (supporters have already seen 1hr of footage).

If you would like a copy of the fabulously broken firmware, I do have one..

E: Eh, sent it.

[leppie]

I applied the fix and it works fine on the MSO1074Z I have.

I did too, but as the other person said, the version says SP3, and every time it still detects the update file. Is this correct behavior?

Yes.

Yesterday, I had the beta firmware still on the USB, but for some reason it is not picking up the update as it did previously... 

Is anyone getting this now?

This makes me wonder if the next firmware will even be detected... I hope they havent screwed something up big time.

[RoTTe]

Hi folks!

New unit, arrived today (the signal comes from a FE5680B 20MHz 2.8Vpp):

Model: DS1054Z
Software version: 00.04.02.SP3
Board Version: 0.1.1

The jitter from 5us is there. Not the worst case, but there. The AC thing too, is bad, but there is something weird there. If you touch the trigger level you can "clean" the signal, maybe I'm doing something strange but I just checking the whole thing step to step.

[MarkL]

Hi folks!

New unit, arrived today (the signal comes from a FE5680B 20MHz 2.8Vpp):

Model: DS1054Z
Software version: 00.04.02.SP3
Board Version: 0.1.1

The jitter from 5us is there. Not the worst case, but there. The AC thing too, is bad, but there is something weird there. If you touch the trigger level you can "clean" the signal, maybe I'm doing something strange but I just checking the whole thing step to step.

This actually looks pretty good to me.  Nothing like some of the other examples of 5us jitter with the released code.

Would you mind doing a 1.2MPt capture of that waveform, save it as a .WFM, and put it somewhere for me?  You can PM me with the drop URL.

In the absence of a generally available program, I'd like to try indirectly analyzing some of these sample clocks.  Anyone else who is still hanging out in this thread after 46 pages is welcome to do the same.  Sergey, Bud, poida_pie, ...

Please include what signal you're capturing, model, and HW/SW vers.  I'll post back to the thread with the long point FFT areas of interest.  Remember - it needs to be a stable source like a crystal oscillator, and taken at the highest possible sample rate of the scope.  A source anywhere from 10MHz to 100MHz would be fine.

EDIT: Actually, if you could include two different sources it would be better.  We can then rule out issues in the source (with a fair amount of certainty, anyway).

EDIT #2: Thinking about this a little more, the higher the frequency of the test source the better, if you have multiple choices.  For each decade away from the internal sample frequency, perturbations from the sample clock get buried another 20dB.  100MHz would make most anything stand out if you have it.  But I'll take anything.

[RoTTe]

This actually looks pretty good to me.  Nothing like some of the other examples of 5us jitter with the released code.

Would you mind doing a 1.2MPt capture of that waveform, save it as a .WFM, and put it somewhere for me?  You can PM me with the drop URL.

In the absence of a generally available program, I'd like to try indirectly analyzing some of these sample clocks.  Anyone else who is still hanging out in this thread after 46 pages is welcome to do the same.  Sergey, Bud, poida_pie, ...

Please include what signal you're capturing, model, and HW/SW vers.  I'll post back to the thread with the long point FFT areas of interest.  Remember - it needs to be a stable source like a crystal oscillator, and taken at the highest possible sample rate of the scope.  A source anywhere from 10MHz to 100MHz would be fine.

EDIT: Actually, if you could include two different sources it would be better.  We can then rule out issues in the source (with a fair amount of certainty, anyway).

The FE5680B is warming. I'll edit the post when I've the data.

Edit: PM sent.

[MarkL]

Ok, a couple of people sent me captures.  I'll edit and append to this post with more.  And I'll edit the post to get the images in-line with the comments (haven't done that before...)

A note on the plots:  It should be obvious x is frequency.  Y is in dB of the raw ADC units (0 to 255).  It's not calibrated to the vertical setting since we're only interested in the shape of the waveform and relative db of the peaks.


From pa3bca:
  Waveform 1: 10 MHz from a Rigol DG1032Z generator
  Waveform 2: 10 MHz from a GPS disciplined OCXO
  Firmware version is 00.02.03.SP5, no idea abt the HW board version.
  This 1074Z has NO 5us trigger issues!

Looks pretty clean to me too.

Waveform 1:


Waveform 2:



From RoTTe:
  The generator is a FE5680B, the 20MHz have some DC bias (2.30Vpp), and the 60MHz is a little attenuated (2.8Vpp).
  Model: DS1054Z
  Software version: 00.04.02.SP3
  Board Version: 0.1.1

So, this one's PLL is not locked, but the instability isn't too severe.  Note the 100kHz spacing originating from the PFD, which is what we should find in all the scopes running this version.

20MHz sine (stopped):


60MHz sine (stopped):



From nuno:

Scope: DS1104Z-S , sw 00.04.00

  16.wfm: 1 channel capture @ 1Gsps, source is 16.000 MHz crystal on AVR microcontroller, measured across the crystal's pins with the GND spring, channel with AC coupling (original signal has an offset)
  25.wfm: 1 channel capture @ 1Gsps, source is oscilloscope's own function gen, sine @ 25MHz 1Vpp

This 1104 looks fine to me.  The 16.wfm is a little noisy, but the main carrier does not appear to have any modulation in it.  25.wfm is also good, but it's probably using the same clock source internally for sampling and generation, and could have synchronized away any issues.  But since 16.wfm is ok, I think it's ok.

16.wfm:


25.wfm:



From Bud:
  DS2072A Hardware v2.0, Firmware 00.03.00.SP1

  F=280MHz via a 280MHz bandpass filter to reduce source spurious/harmonics
  Source 1: HP 8753C VNA (low phase noise)
  Source 2: HP 8656B signal gen

  Scope memory depth 1.4Mpts
  Sampling frequency 2Gsa/S

  Sergey's tests before showed anomalies dc vs ac coupling, so just in case I made two waveforms from 8753C

  The 280MHz frequency choice was just because I have a good bandpass filter for that frequency. But it is also close to the 300MHz scope bandwidth limit (in fact I measured 400MHz 3dB bandwidth on that scope).

These look like there might be a tiny bit of 200kHz modulation in the clock.  But I'm also noticing the close-ups of the main carrier show that there is a slight difference in the offset between the two sources which may imply it's in the source.

I'm undecided on this one.

Bud: Being a precision RF guy, you probably know these sources very well.  Your comments?  Have you looked at your Rigol's internal clock with a swept analyzer?

8656B_280MHz_0dBm_Dc_coupling:


8753C_280MHz_0dBm_ac_coupling:


8753C_280MHz_0dBm_dc_coupling:


8656B_280MHz_0dBm_Dc_coupling_closeup:


8753C_280MHz_0dBm_dc_coupling_closeup:


8753C_280MHz_0dBm_ac_coupling_closeup:



From leppie:

  DS1054Z - beta FW, mine like poda-pie's is very bad after beta FW, jitter goes away in offset intervals of ~33us (was 10us before beta FW)
  24Mhz crystal, no trigger offset

Only one capture provided.  I'm not sure without comparing against a second source.

Just kidding.  Wow, what can I say.  It's not even centered on 24MHz.  You win the award for best stegosaurus.

In measuring those modulation spikes they are 35.8kHz apart (almost 1/33us), but I'll bet they drift so the jitter offset is going to drift too.

24.wfm:



From poida_pie:

  signal source: Rigol DG1022, 20MHz sine, 1v p/p into 50 ohm terminated BNC at scope.
  Vertical gain 0.2V/div
  DS1054Z sample rate: 1G
  DS2072 sample rate: 2G

We have a runner up for instability.  I don't think it's quite as bad as leppie's because the modulation peaks are a little less broad.  But we're talking about the finer points of bad.

There is a different modulation frequency of 42.7kHz on this DS1054Z.  This is not surprising since when the PLL isn't locked variations in the loop filter components and the PLL itself are in play.  Temperature is going to matter too.

The DS2072 looks like fine with maybe a little more phase noise than the others, but that could be the source.

20Mhz_DS1054Z:


20Mhz_DS2072:



From sergey:

  Oscilloscope is DS2072
  Rigol DG1022A source
  Set up to 5MHz, HighZ. This all together with highZ input of the scope and genuine rigol coax cable shouldn't give any reflection issues.

As with the other DS2k series, the sample clock look fine to me.  5MHz is a little low for seeing perturbations in the clock (recall that for each decade away from the sampling clock we lose 20dB), but anything major will certainly show up.

Sergey sent me a 1.4Mpt and a 56Mpt capture of the 5MHz signal.  The 56Mpt capture provides resolution down to about 36Hz (and also took about a minute to process).  It's overkill for what we're looking for, but I thought it was interesting to include so people can observe how increasing the number of waveform sample points used in an FFT can dramatically improve the amount of detail you can see.

10us_1.4Mpts_2MHz_span (about the same span we've been using on the others):


10us_1.4Mpts_120kHz_span:


10us_56Mpts_120kHz_span:

[ferdinandkeil]

I'm certain I saw a posting by someone who developed a program that reads Rigol .wfm files but I can't find it at the moment.  For a quick and dirty hack to validate the data I just chopped the header information off the front and read the data bytes directly into octave (matlab).  The data bytes start at 0x0C7E for the files it made for me, but this is NOT clean, and NOT the right way to do it.

I think this is the program you were looking for: http://meteleskublesku.cz/wfm_view/

[pa3bca]

I think this is the program you were looking for: http://meteleskublesku.cz/wfm_view/

Only this program cannot read (my) 1074Z .WFM files. It gives an obscure error when I open a WFM file.
I have used it before but that was with .WFM files from my 2072A.

[marmad]

I think this is the program you were looking for: http://meteleskublesku.cz/wfm_view/

Only this program cannot read (my) 1074Z .WFM files. It gives an obscure error when I open a WFM file.
I have used it before but that was with .WFM files from my 2072A.

I would be surprised if you used it with your DS2072A without modifying the header. He wrote that for DS1052E WFM files, which have quite different headers compared to the UltraVision formats (unless Rigol modified the DS2000 WFM format in a later version of the FW - which is always possible). I've been able to get it to work with the DS2000, but only after changing the header to emulate a DS1052E (that was a couple FW versions ago).

[pa3bca]

Ha you are right. I get an "unknown trigger mode" error with a 2072 wfm.
My memory is failing    ,i probably used it with wfms from my DS1052E

[Bud]

From RoTTe:
 ..
So, this one's PLL is not locked, but the instability isn't too severe.  Note the 100kHz spacing originating from the PFD, which is what we should find in all the scopes running this version.

Looks pretty bad, the "classic" original PLL problem.

[sergey]

So, this one's PLL is not locked, but the instability isn't too severe.  Note the 100kHz spacing originating from the PFD, which is what we should find in all the scopes running this version.

So this 100KHz is something what exists in both 1000 and 2000 series.

Do you want me to do some wavwform captures from 2000 series for you btw?

EDIT: Well, more like a question if it's a waveform of the LOCK pin of the PLL needed or something else?

[RoTTe]

From RoTTe:
 ..
So, this one's PLL is not locked, but the instability isn't too severe.  Note the 100kHz spacing originating from the PFD, which is what we should find in all the scopes running this version.

Looks pretty bad, the "classic" original PLL problem.

Eh! It's better than my chinese multimeter!. And if you think that its bad wait to see the Atten 1102CML at the office, crappy as hell (all the GUI freeze at random intervals).

Now seriously, I bought this before this was known -for the general public- (two month of lead time). I'm tempted like a small child to broke the warranty sticker, solder four wires and plug the BusPirate or something like that and reprogram the PLL on the fly with the 5mA setting ( or whatever I want ). Two things stop me from doing that: One client hitting my door like Leonidas at 300 waiting for his PCBs and the lead time of another one if the fecal matter hits the fan with this new shinny and beauty thing (something can go wrong murphy said, and I need this NOW).

I'm thinking from another approach from the software side, but this need a lot of know how from firmware struct, and these things take time. I hope Rigol will solve this -from software-, If the worst case scenario is having to rebuild all PLL stage I'll do it. I love playing with these things.

[sergey]

I think this is the program you were looking for: http://meteleskublesku.cz/wfm_view/

Well, only windows and no sources. Seems i'll still need to write my own reader as an evening project

[Michal_S]

I think this is the program you were looking for: http://meteleskublesku.cz/wfm_view/

Well, only windows and no sources. Seems i'll still need to write my own reader as an evening project

Please do, if you can.
I've been trying to do something on my own, using pyRigolWFM sources as a base, and Hex Workshop for reverse engineering the new format. Vertical, horizontal scales, vertical offset, sample count, sampling rate, channel labels, samples were quite easy to find. However, this seems not enough to calculate the waveform from raw data. The origin of the raw data varies with vertical scale and offset settings (it's not always 127 as one might guess), and I don't know how to get this origin, for example.  I took a look at Rigol programming manual for DS1000Z, you can get YORIGin and other parameters necessary to calculate voltage waveform using SCPI commands. I tried to find the same numbers in the WFM file, but no success. If YOrigin, YRef, YInc are in the file, they are not there as simple float/uint values (as the other data that I already located are) :/ Maybe YOrigin can be derived from Vertical Scale and offset settings, but I think then only Rigol knows how...
As I'm heading for importing the data as digital data for import to Sigrok, I may settle on just using the RAW values directly, but of course it would be great to be able to calculate voltage values for other uses.

[marmad]

I think this is the program you were looking for: http://meteleskublesku.cz/wfm_view/

Well, only windows and no sources. Seems i'll still need to write my own reader as an evening project

An evening? Good luck with that!