Rigol DS1000Z series (ds1054z, ds1074z, ds1104z and -s models) Bugs/Wish List

[Ducttape]

A feature I'd like on my Rigol would be the ability to easily (e.g. a long button press, simultaneous button presses, etc.) put zero volts at the bottom of the display and the trigger time to the left. Come to think of it, might as well be able to specify any corner while we're at it.

In case it's not obvious, this is for times where my signal is only positive and I don't care about pre-trigger data. Doesn't waste screen space.

[MrWolf]

I'll take that as a "no"....

Probably there is something. If it interests you maybe you should test it and report if find anything.

But what if... Rigols firmware IS a bug?

[Fungus]

I'll take that as a "no"....

Probably there is something. If it interests you maybe you should test it and report if find anything.

Oh, sure! I'll spend $400 on a Picoscope just for that.

[metrologist]

Mr. Wolf,

Other than you complaining about the meas value "jumping around" what is the problem with the first measurement you posted just above? Compared to pico with 50 samples, the phase offset seems within reason.

This is a measuring tool and I understand the class of tool that it is, so it is important to me to distinguish the difference between a poor methodology and an actual bug within the context of this class of tool. I use measuring calipers all the time and have an inexpensive plastic set that are no where near as precise as my hardened and ground Starrett that actually did cost almost two orders of magnitude more. So you have this range of 400 dollar scope, 4,000 dollar scope, 40,000 dollar scope and I have no illusions this Rigol is going to compete with the latter.

[Fungus]

So you have this range of 400 dollar scope, 4,000 dollar scope, 40,000 dollar scope and I have no illusions this Rigol is going to compete with the latter.

And let's remember that the Pico are far more expensive then the Rigols (for far less hardware!)

[metrologist]

If Pico could wirelessly connect to my phone or tablet, then I would not need to buy another computer or laptop. That would be cool

[JPortici]

So you have this range of 400 dollar scope, 4,000 dollar scope, 40,000 dollar scope and I have no illusions this Rigol is going to compete with the latter.

And let's remember that the Pico are far more expensive then the Rigols (for far less hardware!)

without forgetting that most if not all of the money goes into a better version of the important part of the hardware... you know, the front end, acquisition and memory. and the crappiest of the picos is still better in the software, can't say that for the rigol with its load of hardware

[Fungus]

without forgetting that most if not all of the money goes into a better version of the important part of the hardware... you know, the front end, acquisition and memory. and the crappiest of the picos is still better in the software, can't say that for the rigol with its load of hardware

Yet weirdly enough Picos are despised around here.

Hands up who owns one...?

[MrWolf]

Other than you complaining about the meas value "jumping around" what is the problem with the first measurement you posted just above? Compared to pico with 50 samples, the phase offset seems within reason.

Jumping around is the problem. It just got lucky I pressed stop at the right moment.

Did new test with improved logic:

Signal gen puts out 2x10MHz, with nasty little 3.6 degree phase shift.
Measurements done 2x per DUT, swapping cables to look for possible issues.
For both units I tried to get best possible result.
If something could be done better in case of Rigol - please specify.

Pico: 100MS/s, 20k points, 1000x averaging: 3.15 +- 0.08014 & -3.266 +- 0.07538

Rigol: 500MS/s, 12M points, 1024x averaging: 0.1133 & -3.487
(Current values seem to be identical but actually they are jumping all the time in discrete manner and not centered around 2.880, it's reflected in average values)
Edit: proof attached (DS1104Z_10MHz_jumping_proof.png).

Screenshots attached.

So you have this range of 400 dollar scope, 4,000 dollar scope, 40,000 dollar scope and I have no illusions this Rigol is going to compete with the latter.

Hm, but currently I'm comparing it with my very old scopes that are out of production by now and were in same price range once... meaning 2x cheaper than DS1052E when it did come out...

[MrWolf]

Yet weirdly enough Picos are despised around here.

How's that weird? It's s*it for room decoration

[David Hess]

It's bashing time again. Now I got 100% solid proof that this  box is doing its "measurements" basically off the screen (pixels!?), not the datapoints. But while I'm putting screenshots together - heres a little warmup. It's this error I found earlier:

I thought that the Rigol operates this way was pretty well established.  It also leads to odd behavior where changing the trace positioning, volt/div, and time/div alters the automatic measurements in bizarre ways.

Is it bad that those on-screen measurements are performed on screen data? What is the trade-off, no automatic on-screen measurements and manual on-screen measurement?

It means that the processing used to generate the display and especially the index graded high acquisition rate display alters or completely corrupts the automatic measurements.  For example RMS measurements of anything except a clean waveform do not work correctly at all.

If he can't see that $400 is unbelievable value for so much 'scope, warts and all, then it's his own problem. It's like buying a Ford Fiesta then complaining it won't fit a piano in the back and go 200mph.

I might have accepted this argument if Rigol was not simultaneously deceptive about the capabilities of the instrument.  In case this is misunderstood let me make it plainer; they lie several times in the documentation and they do the same thing for the DS1000E series.  This company cannot be trusted.

[MrWolf]

I thought that the Rigol operates this way was pretty well established.

Doing calc only from data on the screen does not automatically mean that calc will be so wrong. It could take X actual datapoints related to screen, average long enough and get results no worse than ETS.
But even doing it from pixels does not explain some stuff...

Look screenshot:
"DS1104Z_10kHz_phase_error.png"
Two perfect 10kHz sines out of 1.2GS/s gen, no phase diff. Waveforms are drawn no problem. 1024x averaging does its job. However auto-cursors are jumping around like rabbits even to places where are no wfm pixels! Delay/Pha1 Min/Max get impossible values.

I might have accepted this argument if Rigol was not simultaneously deceptive about the capabilities of the instrument.

Actually instrument itself also lies like theres no tomorrow...
Now it's 2x10kHz square wave, no phase. Gen specs:
Rise/fall times 9 ns 10% ~ 90%, 1 Vpp, 50?Load

"DS1104Z_10kHz_5ns_500MS.png"
At 5ns timebase Z shows that gen is operating better than spec. For cross check theres same thing with Pico running at 4GS/s ETS:
"2205MSO_10kHz_5ns_4GS.png"

Now lets look at same wfm at the stage where duty cycle could be calculated:
"DS1104Z_10kHz_10us_500MS__lies.png"
Slight WTF moment. It's says running at 500MS/s. User would assume this is perfectly adequate for rise time measurements ant trust BS it puts out. It's wrong by 50 times! 
For comparison here's same from Pico:
"2205MSO_10kHz_20us_50MS.png"
Little old soapbox honestly says it's running only at 50MS/s and cannot calculate rise time for specific waveform.

Probably most correct way of using this Z "instrument" for analog stuff is screen+cursors unless they fix it. After all FFT has "memory" source option which makes it somewhat useful compared to screensaver function on "screen" source.
Maybe some measurements could also grow "memory" source and start actually mean something.
Overall it's not that bad - design is good. Great body with many knobs poking out. UI is generally ok. Hardware is adequate since it CAN display correct wfm. Just that specific dude(s) doing complex measurements part f*cked up a little....

[NorthGuy]

Pico runs on PC with computing power many times more than Rigol's. Even with all this power, it might have problems with 12M points, but you don't give it that much. Would it be reasonable to expect the Rigol to do the math on all 12M points and display the results reasonably fast. Of course not. Engineering is always a compromise. So, they decided to take a sample (what you see on the screen) and calculate on it. This gives them reasonable responsiveness.

And this is not really that bad if you take into account how it's working. For example, you could zoom in to get more accurate rise times. Or you could spend 15 seconds to load all the 24M data from Rigol onto PC and then perform the calculations you need.

[tautech]

I'll take that as a "no"....

Probably there is something. If it interests you maybe you should test it and report if find anything.

But what if... Rigols firmware IS a bug?

rf-loop did some study on similar problems 2 years ago:
https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/

[Fungus]

Or you could spend 15 seconds to load all the 24M data from Rigol onto PC and then perform the calculations you need.

Yep. Rigols have a connector on the back that lets you use them much like a Picoscope.

But they cost less, and they have a screen and knobs if you want to use them.

[Howardlong]

While I understand your concerns, to me this sounds much more about understanding how your instrument works, and being aware of its limitations.

I ran your tests on three scopes, an Tek MDO3054, Keysight MSOX3054A and a Rigol MSO1074Z-S, taking care to closely reproduce your tests including memory depth and averaging etc where specified. Not only did they all behave significantly differently in terms of results, but I came to the conclusion that the tests themselves were built to highlight particular characteristics using rather specific edge cases. I am sure we could equally well come up with similarly specifically designed cases putting the Pico in the same court.

Putting in two identical sine waves and asking for the phase difference is quite computationally demanding, it's essentially attempting to do multiple correlations between the two signals to find the best one and using that to give phase difference. I'm not surprised it's done off a subsample.

Regarding the rise time thing, I agree though that it would be better if the screen said something like "<400ns" like the Keysight scopes do in similar situations. In fact, out of Statistics mode, the Rigol does present it as "<200ns", so I assume it's simply run out of screen real estate. The Tek, though, is already known to be terrible at this. The Pico doesn't tell you anything at all.

I don't think the sample rate is a lie though. When the scope is stopped, you can zoom in and your measurements will be recalculated on the same data but at a higher sampling rate. It's a like using a ruler to get a quick coarse measurement and then use your micrometer for a finer resolution.

So in short I'd say it's as much about understanding and learning how your instruments work as anything else. This includes knowing both their limitations and how to use them. Although we all want to trust our instruments, part of being an good engineer is knowing when something doesn't look right, and being able to question, understand and explain it: i.e., a good workman doesn't blame his tools and all that (well, not most of the time anyway).

[Fungus]

So in short I'd say it's as much about understanding and learning how your instruments work as anything else.

Agree 100%. MrWolf is making mountains out of molehills and pointing the finger at the DS1054Z when most other low-end scopes will probably do similar things of you take them to the limits. If you want that sort of perfection then buy a $40,000 'scope.

[Howardlong]

So in short I'd say it's as much about understanding and learning how your instruments work as anything else.

Agree 100%. MrWolf is making mountains out of molehills and pointing the finger at the DS1054Z when most other low-end scopes will probably do similar things of you take them to the limits. If you want that sort of perfection then buy a $40,000 'scope.

I'm pretty sure even then you'll need to know how to drive it and interpret the results properly.

[MrWolf]

Regarding the rise time thing, I agree though that it would be better if the screen said something like "<400ns" like the Keysight scopes do in similar situations. In fact, out of Statistics mode, the Rigol does present it as "<200ns", so I assume it's simply run out of screen real estate. The Tek, though, is already known to be terrible at this. The Pico doesn't tell you anything at all.

Well... not "better", "correct"! Also "realestate" excuse do not work with "Dly1" and "Pha1". Here it clearly states "-" sign. So it means to display what it displays.
Its funny how engineers (I presume) are defending plain erroneous readings with various "humanitarian" excuses. Engineering is not for humanitarians with soft underbellys. It exact business.

All talks (by some) about how cheap it is and therefore cannot programmed correctly is plain incompetent. I have tens of years software experience and I can state that s*it programming costs more
for everyone involved. So you either find good workers or fold your stuff eventually... unless youre monopoly or govt of course ...or your sales strategy is endless steam of noobs who just need pro looking deco item 

I don't think the sample rate is a lie though. When the scope is stopped, you can zoom in and your measurements will be recalculated on the same data but at a higher sampling rate.

Excellent info. Then I apologize - was mislead by erroneous readings.
Moreover - then it can be fixed and indeed hardware dudes were doing good job 

So in short I'd say it's as much about understanding and learning how your instruments work as anything else.

Up to a point... In this case there are blatant UI and programming errors. Some of them are trivial to fix. "Cheapness" is not excuse. Even 10$ multimeters are to expected to display "out of range" where appropriate, not some BS values.

Would be interesting if some of the "humanitarian" engineers here were so kind also when their own dev team produced stuff like this 

[Karel]

Just some general info about the Rigol DS100Z series. As far as I know/experienced, most calculations & decoding are done
with the data that's actually visible on the screen, not with the raw captured data which can be as big as 24Mpts.
So, what's the difference between the raw waveform data (with sample rates up to 1GHz and and a size up to 24Mpts)
and the display data?

The difference is that the display data is always downsampled to 1200pts (100pts per horizontal division).

Those 1200pts are used for serial decoding, FFT and (I haven't tried my self yet) probably also for all other measurements.

How is this downsampling done? Only Rigol knows. They claim it's a special (patented/secret?) algorithm.

This is a big limitation but understandable because of the priceclass of the instrument. Zooming in (horizontally) improves
things but doesn't let you be able to see, for example, a long serial transmission.

So, if you want to do analysis with higher resolution, the only solution (with Rigol) is to download all 24Mpts to
a pc and do the analysis offline.

And here's the sad thing, there's a "time difference" bug in the Rigol firmware that causes a random time difference
of +/- 100nS between different channels:

https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg862373/#msg862373

It has been reported to, and confirmed by, Rigol a long time ago (Februari 2016) but in the
subsequent firmware updates, they didn't solve it.

[MrWolf]

The difference is that the display data is always downsampled to 1200pts (100pts per horizontal division).

Actually they now offer "memory" source option for FFT. It becomes slow as diseased opossum but actually manages to show something meaningful. Same could be done with other measurements. Maybe time for T-shirts "memory based measurements for masses!"

This is a big limitation but understandable because of the priceclass of the instrument.

Well if it would really be 1200pts - not so bad. Better than one could do with cursors. So step up from CRO from example. But let's if that has anything to do with reality... Analyze some screenshots from my post:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg1088384/#msg1088384

1200pts reso presumed
601px wide screen area => 600px wfm measured (graticule is 1px too wide)
10us/div * 12div = 120000ns wide data
120000ns/1200 = 100ns/pt
120000ns/600 = 200ns/px

"DS1104Z_10kHz_phase_error.png"

3px max wfm width => 600ns => +-300ns "play" on data,
but ok lets write that down to graph aliasing... but:

Dly1-2:
Max: 400ns
Min: -800ns
=> +-600ns "play" in data => +- 6pt (+- 3px)

"DS1104Z_10kHz_10us_500MS__lies.png"

Rise:
400ns => 4pt => 2px

measured 1px max wfm width 10%-90% => 200ns (from pix) & 100ns (presumed from pts) & <1ns (actual signal)

So here it is seen that practical resolution for measurements is actually just about 300pt(px) horizontal,
actually 2x worse that could be done with cursors.

So heres a formula:

practical resolution = timebase div / 25

Probably worse if calculated in scientific manner.

[Fungus]

Just some general info about the Rigol DS100Z series. As far as I know/experienced, most calculations & decoding are done
with the data that's actually visible on the screen, not with the raw captured data which can be as big as 24Mpts.
So, what's the difference between the raw waveform data (with sample rates up to 1GHz and and a size up to 24Mpts)
and the display data?

The difference is that the display data is always downsampled to 1200pts (100pts per horizontal division).

Those 1200pts are used for serial decoding, FFT and (I haven't tried my self yet) probably also for all other measurements.

We don't know that with 100% certainty but that's what we observe and it makes sense to do it that way.

How is this downsampling done? Only Rigol knows. They claim it's a special (patented/secret?) algorithm.

That would be the main job of the FPGA in these oscilloscopes - to whizz through the sample memory and crunch the 24Mb of data down to screen size. The waveform update rate, etc., will depend purely on the processing power of the FPGA. I doubt there's any big industrial secrets in the process.

The main CPU can then work on those screen pixels to display them, make measurements, etc. It probably doesn't have direct access to the sample memory, it will all go through the FPGA.

Actually they now offer "memory" source option for FFT. It becomes slow as diseased opossum but actually manages to show something meaningful.

I assume they're shuffling the data into main CPU memory via the FPGA and doing the FFT there. Some enterprising programmer managed to slip that code into the firmware, we should thank him instead of complaining!

Same could be done with other measurements.

Then you could spend all your time complaining it was too slow, right? 

[kwass]

Same could be done with other measurements.

Then you could spend all your time complaining it was too slow, right? 

I think that the delay would be perfectly acceptable if the decode worked this way.   

[MrWolf]

Then you could spend all your time complaining it was too slow, right? 

Well I'm just learning about my new DSO. Seems indeed it's some new kind of DSO, I will name it SCREEN SAMPLING DSO, yeah    Sadly in the manual does not teach how to account for differences compared to normal DSO operation. You see I've used only normal ones so far and when buying this one was looking only at analog bw, memory sample rate and channel count. But there's another and unique param - "screen sampling rate" - very important for risetime auto-calc!

So now I must create helper formulas and tables to navigate around it's limitations. Would much prefer for it just to be slow. Slow computes well with measurement instrument. Readings off by 4 orders of magnitude do not (in the situation where normal DSO wouldnt be even stretched).

We don't know that with 100% certainty but that's what we observe and it makes sense to do it that way.

Let's observe some raw data then. I adore raw data, it makes s*it float
Reports attached below.

Short summary:
Fed 10Vpp, 32768Hz 50% duty square signal into Rigol DS1000Z and my old PicoScope 2205 MSO (25MHz, 2ch+16ch, 2013 out of prod model).
In case of normal DSO it can be seen readings reflect the nature of signal rather well. Lowest sampling rate observed at the 5ms timebase was 0.9804MS/s.
However in the case of "screen sampling" DSO it can be seen that despite hardware superiority it's readings are up to 4 orders of magnitude off. Despite running at massive 125MS/s at 5ms timebase in reality it's "screen sampling rate" for risetime calculation is only 0.005MS/s. Does a bit better with period calculation, only by about order of magnitude off.
So clearly it cannot be used anything like normal DSO. But then manual should reflect it. Customer is not to be expected reading forums for weeks when buying equipment.

[David Hess]

This discussion clears up a mystery for me; why does Rigol include a delay feature and misleadingly refer to it as delayed sweep when it is not.  It can only delay within the admittedly ample acquisition record and it does not produce a new acquisition; instead it decimates an old acquisition to produce a new display record from the acquisition record.  My ancient 2230 can do that (1) and the Tektronix 2230 is the oldest digital storage oscilloscope I would consider a real DSO! (2) Other DSOs including ones that have real delayed acquisition or sweep call this horizontal magnification and it works independent of a delayed sweep.

I am increasingly convinced that the Rigol is even worse than I originally thought.  All of my ancient CRT DSOs have a higher resolution vector CRT screen, make measurements on the 16 bit acquisition record without ambiguities so averaging actually improves resolution, support real delayed acquisitions or sweep, and if you count the Rigol's display record as its true record length which seems reasonable since *that* is what its measurements and decoding use, they have tiny record lengths which are still several times that of the Rigol.

If Rigol is doing the display processing in the processor instead of the FPGA unlike other DPO type DSOs, then this also explains its high acquisition rate; its record length is effectively only 1200 points!  That is a clever engineering trade off but it should not come at the expense of other functions.

(1) The Tektronix 2230 and 2232 inexplicably have a function to compress a 4k acquisition record into a 1k display record in real time.  When used, the time/div is multiplied by 4.  I have no idea why this function was included but I have occasionally used it to good effect.

(2) My criteria for a "real" DSO includes peak detection and the Tektronix 2230 has the earliest implementation that I know of.  This is why I never considered Rigol's earlier DSOs like the DS1000E series to be more than toys.