New Rigol DS1054Z oscilloscope

[metrologist]

I said I understood it was a bug, but what real world measurement fails for you, that is my point? It's a nice anecdote; however, if you were really measuring low-level DC or noise in the low mv range, who would be setting the scale to 160V?

Of course, I could be wrong and this is certainly a nuisance, but I've found it's best to use equipment in ways that enhance its performance rather than in ways magnify its weaknesses. That is true for anything.

BTW, I think in single channel mode, the performance of the scope is outstanding, and that is why I think this bug is nuisance, because it certainly need not be this way.

I don't know if you for some reason refuse to read what I wrote or you're making fun of me...

Not making fun, but I still qualify that I could be wrong. That is why I am asking what real world measurement fails for you?

NO milivolts... Read again.. CH1 AND CH2 on 1V/DIV , probe connected only to CH1

NOTHING on CH2, disconnected, no probe connected...

RMS on CH1 2.07V, RMS on CH2 1.9V !!!

With nothing connected to the CH2 BNC.

Um, I'm talking about what you are complaining about, the RMS reading on CH2, which has nothing connected, so you are measuring very low level noise, no? AND, you said: "6. Set CH2 to20V/div.."

You do realize that is 160V full scale, and the spec is +/-3% of 160V, right? Am I wrong? You should be expecting a straight voltage in the range of -4.8V to +4.8V with the scope set up this way. Am I wrong here? Maybe I am just making a fool of myself. I am not an engineer or anything like that.

CH2 with NOTHING connected to it measures cca 80%  of whatever you are measuring on CH1 ( not flecking micro-volts, but 80 %  of data from CH1.....)

That fails EVERY real world measurement criteria for that channel and particular RMS measurement.....

If I have NOTHING connected to CH2(no probe, BNC is empty), I can't have spillover from CH1  to CH2 of 1.9V RMS... That is 2 DIVs

I thought you set CH2 to 20V/div/ Two divs is 40 volts, right?

But is a serious thing if you need RMS... I can just measure on CH2 and CH3 as a workaround but it is a serous flaw anyways.. And I didn't buy 4CH scope to use it as a 1CH...
I could have gone with 2CH DS2000 series with just a little more money but I needed 4CH for the  things I do...
So I want all channels to work normally.. Of course I will make do with it for the time being.. But it should be fixed eventually..

I don't want this to become an argument of a sorts. I'm persistent because you seem not to understand the problem, and despite your good will to help, you are talking about unconnected things..
I just want to untangle misunderstanding..

All the best..

I still totally understand your perspective. Where I am coming from though is understanding the product specs and limitations that the mfg can impose. You are taking an idealistic point of view, and I totally agree it is a shame because this spillover need not be that way. It may be a trivial matter for Rigol to fix it, or it may involve thousands of man-hours. Rigol is in it to make money, and unless the scope is failing its spec, then they are not bound to fix it, no matter how embarrassing.

And once again, to my point about setting up the instrument in the best possible way to achieve an accurate result should not be dismissed. I'm sure you would do that anyway even without this bug.

[metrologist]

I understand what you folks are saying, but is the number outside the specification? I showed that the same measurement set up more reasonably is within spec. It's the same signal and same measurement.

If you take your trusty high accuracy DVMs and feed them 0.01 volts and have it set to a 100+V range, are you going to complain if one meter says 0.01 and another is 400% off (0.04)?

I totally understand that it is a software bug and could be fixed, but if both channels were closer in value yet still just as far off, then what? It's in spec! (I think anyway...)

+4 digits Can be within spec on a DMM - especially a 4-5-6 digits one. That's least significant digit.

My example was 1 extra digit. But it was most significant digit. And channel 3 set up the same was perfect.

Also, in your example, DMM 1 would usually read higher than DMM 2 but still in spec. In the example channel 2 adds 10 most significant digits only because of CH1. In the same example setting CH1 to GND will get CH2 reading to go from 12 to 2 V RMS.

So no - it has nothing to do with ranges.

I'm sorry, but what I meant was that you are setting CH2 to a 160V range, so most significant digit is 100's. DMM is a bad example since I could not illustrate it well. I did, however, show you how I'd be measuring the signals that you set up, and I get results that are reasonable and within spec (I believe).

[metrologist]

...
6. Set CH2 to20V/div..

On CH1 I get  2.07 VRms and on CH2 that has NOTHING connected I read 37. 9V VRms 

This part is confusing to me, so I will take a look tonight.

You also said that CH2 is set to 1V/div and you measure 1.9V RMS on CH2 with no input.

That's about the same error either way, so I wonder what would the actual RMS measurement be if you were feeding channel 2 with a signal more appropriate for the channel setup, such as 150V, or even 80V, or even 20V just to see if there is any effect. Why would there be?

[2N3055]

...
6. Set CH2 to20V/div..

On CH1 I get  2.07 VRms and on CH2 that has NOTHING connected I read 37. 9V VRms 

This part is confusing to me, so I will take a look tonight.

You also said that CH2 is set to 1V/div and you measure 1.9V RMS on CH2 with no input.

That's about the same error either way, so I wonder what would the actual RMS measurement be if you were feeding channel 2 with a signal more appropriate for the channel setup, such as 150V, or even 80V, or even 20V just to see if there is any effect. Why would there be?

I'm sorry for the confusion.. lets try like this:

setup time base at 100 uS
connect cal to CH1  at 1V/div it'l be about 3 DIVs high and have about 2,06V RMS

CH2 will show 1.88 V RMS, thats two divs worth of data.... If you change V/DIVS on CH2 now, RMS voltage will be multiplied by V/DIVs
so 10V/DIV it'll be 18.8V and on 100mV it'l be 188 mv .. but always at approx.2 DIV of phantom trace data. That is 25% of full screen worth of error... Of course I'm talking only about RMS, no trace visible on the screen

And to make it interesting, if you go to CH1, and play with it's V/DIV, RMS error on CH2 changes... It seems it is connected to vertical size of SHOWN trace of CH1... the bigger CH1 is on the screen, bigger error on CH2...

I understand is not intuitive.. If you have time play with it a bit...

Regards,

[Meka77 wd]

Hi again...

I'm gonna try to explain one last time this RMS issue importancy, for newbies and such...

Let's say we want to check some audio amplifier with our brand new! ds1054z.

What bad can happen?. This is just simple audio work!.

If you trust your ds1054z, you are Mucked big time... 

Best wishes to all.

[metrologist]

Thanks folks for all the efforts. It is all for learning something for me. I'm not sure how we can progress conversations that are simply one-sided. I've said I acknowledge the RMS issue when showing an erroneous measurement on a channel that has no input. One sided because nobody answers why that matters?

Meka is giving a good sample of data that seems reasonable. I would contend that the only sample that matters is the one with the scope showing 20V RMS and the meter 17.5V RMS as a best case, and that is because the tool is being used near its potential. I would not discount the other measurements, however, as they may actually illustrate the problem more specifically.

Anyway, with this best case sample, if we take the meter as absolute truth, is the scope showing data out of spec?

There are two questions in my post here. Dismiss them as you like and continue to parrot your POV, and hence we will not progress. Just keep in mind that I have conceded and acknowledge the issue as you've presented it.

[Meka77 wd]

Thanks folks for all the efforts. It is all for learning something for me. I'm not sure how we can progress conversations that are simply one-sided. I've said I acknowledge the RMS issue when showing an erroneous measurement on a channel that has no input. One sided because nobody answers why that matters?

Meka is giving a good sample of data that seems reasonable. I would contend that the only sample that matters is the one with the scope showing 20V RMS and the meter 17.5V RMS as a best case, and that is because the tool is being used near its potential. I would not discount the other measurements, however, as they may actually illustrate the problem more specifically.

Anyway, with this best case sample, if we take the meter as absolute truth, is the scope showing data out of spec?

There are two questions in my post here. Dismiss them as you like and continue to parrot your POV, and hence we will not progress. Just keep in mind that I have conceded and acknowledge the issue as you've presented it.

It's  absolutely broken in RMS department.

Regards.

[metrologist]

Meka, it does not help to show sxs measurements of two different instruments and just state that the better is your expectation. That is only because I am looking at specs and taking them at face value. I know the ds1054z can do it the same, and that is why I say it's a shame that there is this bug. But again, are those measurements out of spec? Are they, please...?

[Meka77 wd]

Meka, it does not help to show sxs measurements of two different instruments and just state that the better is your expectation. That is only because I am looking at specs and taking them at face value. I know the ds1054z can do it the same, and that is why I say it's a shame that there is this bug. But again, are those measurements out of spec? Are they, please...?

I don't know what Rigol spec about that sh:t, but i have Rigol DS5022M which about 8 years old still works as expected. Please click on my profile and see my other posts about this issue...

Btw. if you want to measure two signals RMS values correctly (mind 8bit ADC of course) regardless your horizontal or vertical settings, workaround setup like Ch1-Ch3 or Ch2-Ch4.
But full four channels... Errr. anything possible 

[edavid]

I've said I acknowledge the RMS issue when showing an erroneous measurement on a channel that has no input. One sided because nobody answers why that matters?

Because we have no idea why it is happening, so we don't know what other situations will also cause erroneous measurements, so we can't trust the RMS function at all.

Anyway, with this best case sample, if we take the meter as absolute truth, is the scope showing data out of spec?

It's a meaningless question, because Rigol does not specify the operation of the RMS function (or most of the other functions of the scope for that matter).  We're left to figure it out for ourselves, which is what we are trying to do here.

[Meka77 wd]

Btw. I'm bored and seems unable to sleep, i just upgraded latest firmware (4.3SP2 > 4.4)...

1.Fastest waveform update i can see is approx. 60kHz at 50ns, dot mode, single ch.

2.Definitely, faster response on menus, settings, FFT and multiple channel situations.

3.FFT works nicer than before

4.Freeze bug gone

5.Math trace shift bug seems absent

6.Serial still works

7.Intensity grading looks and adjusts nicer than before

Unfortunately RMS still pissing allover adjacent channels 

That's it for now.

Regards

Edit: Correction

[technogeeky]

I understand what you folks are saying, but is the number outside the specification? I showed that the same measurement set up more reasonably is within spec. It's the same signal and same measurement.

If you take your trusty high accuracy DVMs and feed them 0.01 volts and have it set to a 100+V range, are you going to complain if one meter says 0.01 and another is 400% off (0.04)?

I totally understand that it is a software bug and could be fixed, but if both channels were closer in value yet still just as far off, then what? It's in spec! (I think anyway...)

I think you're missing the point... I'l try to explain, because his example is too elaborate and confusing..

Try this:

(This is with 10X probes and channels set for them)

1. Set timebase to 100 uSec/div..
2. Enable CH1 and CH2, DC coupling, and trigger on CH1, setup trigger to 1.5V to have a stable trace..
3. Set VRMS measurement on both CH1 and CH2..
4. Plug in the probe ONLY to CH1 and connect it to CAL. DO not connect anything to CH2..
5. Set CH1 to 1V/div..
6. Set CH2 to20V/div..

On CH1 I get  2.07 VRms and on CH2 that has NOTHING connected I read 37. 9V VRms 
It gets even better... now disable CH1... it is still the same... Grounding the coupling or disconnecting the cable will make it go away...


This proves there is a spillover of data from CH1 to CH2 for VRMS... It measures about 10% less than CH1 in raw data, and multiplies that with vertical amplifier ratio.

This is not about how accurate is RMS algorithm and details like such... 
It is about the fact that CH2 is showing you data form ANOTHER channel while you don't have anything connected to it ... 

Another thing, Per Vrms is good only for periodic signals... You need this broken RMS for noise, DC and such...  So yeah I need this fixed...

Regards..

I can duplicate this, and add a step to show the absurdity of it more clearly:



TEST SETUP

• System -> Utility -> System -> Power Set -> Change to Default
• Turn off scope.
• Attach a probe with 10x setting to the calibrator signal and ground
• Turn on scope
• Press AUTO
• Change horizontal timebase to 100us/s (one to the right)
• Change CH1 vertical timebase to 1.00V (DC coupled, should be automatically)
• Enable channel 2
• Change CH2 vertical timebase to 20.0V (four to the right, automatically DC coupled)

Once you have done all of those steps, we can do 2 steps to show how silly this bug is is very clearly:

Test 1:

• Control: The above setup, and the quick measurements list is clear.
• Step 1: Turn on CH2 Vrms quick measurement.
• Step 1a: Note the CH2 value (~ 600-800 mV, fluctuating, reasonable measurement error).
• Step 2: Turn on CH1 Vrms quick measurement.
• Step 2a: Note the CH2 value(38.7 V, not fluctuating at all, though very occasionally it fluctuates to ~ 700mV

Note: The second two attachments are GIFs.

[technogeeky]

Furthermore, you can adjust the CH2 vertical timebase, and you find that the erroneous value reported is just a ratio of the timebase, which itself is the minimum value of the CH1 Vrms (in my case):

CH2 Timebase	Small (mV)	Large (V)	Large/Timebase
1	50	1.93	1.93
2	56	3.86	1.93
5	267	9.67	1.93
10	387	19.3	1.93
20	791	38.6	1.93

Surely the first part of this is not a coincidence. I'm yet to determine if I think the second part (source of the error number is the minimum value of CH2 Vrms.

edit: It really does look like the exact value comes from a ratio between channel 1 and channel 2's MIN statistics reading. (Try turning on statistics and inspecting this yourself).

[Assafl]

Thanks folks for all the efforts. It is all for learning something for me. I'm not sure how we can progress conversations that are simply one-sided. I've said I acknowledge the RMS issue when showing an erroneous measurement on a channel that has no input. One sided because nobody answers why that matters?

Meka is giving a good sample of data that seems reasonable. I would contend that the only sample that matters is the one with the scope showing 20V RMS and the meter 17.5V RMS as a best case, and that is because the tool is being used near its potential. I would not discount the other measurements, however, as they may actually illustrate the problem more specifically.

Anyway, with this best case sample, if we take the meter as absolute truth, is the scope showing data out of spec?

There are two questions in my post here. Dismiss them as you like and continue to parrot your POV, and hence we will not progress. Just keep in mind that I have conceded and acknowledge the issue as you've presented it.

Okay - I apologize for having dismissed your POV* so let's explore it. The scope's vertical DC Gain specs are +-3% FS for >10mV (This is the analog input spec - there is no "calculation specific" spec). We are at 2V RMS so amply satisfy the >10mV criterion (otherwise would be +-4%).

We have 3 (identical) signals on screen; CH1 @ 1V/div; CH2 & CH3 @ 20V/div. Since the Scope has 8 divisions, the FS voltage for CH1 is 8V FS while for CH2 & CH3 it is 160V FS.

CH1: The signal is 3Vpk-pk; so it takes 3/8 V/V FS so DC Gain accuracy is 1/3/8*3% = 8% accuracy
CH2&CH3: The signal is still 3Vpk-pk so it takes 3/160V FS so DC Gain accuracy is 160V/3V*3% = 160%

Indeed the scope operator for CH2 and CH3 should be fired immediately (Oy Vey - that is me). So the error (at max) should be 2.1213V * 1.6 =  3.4V (and indeed CH3 looks awful showing 2.86V RMS - well within Spec) but CH2 is horrific - nowhere near 12.4V which would mean a ~585% error.

Just for exercise: What would be the DC gain error that would result in 12.4V RMS reading? So remember we are at 160V FS and our signal is 3v pk-pk so 3 * 585% /160 =  10.9% DC Gain.

So the analog section does not (assuming the specs are correct) seem to be causing this - as does the fact that it seems to move with the triggering channel.

*In a sort of defense I'll state that - to me - it looked like a calculation issue - if only because the trace for CH2 does NOT look like it is 6X the trace for CH3; if it were a DC Gain error - the trace would have shown this. Hence it reeked of a logic/math error rather than a DC Gain error. Still not okay to dismiss other POVs though...   

[2N3055]

There is no DC error in channel data.. traces look ok... other measurements seem to be ok but I will be checking soon...
It is probably some stupid counter variable, global variable, array index or something stupid like that in RMS calc..
These things are made as running circular buffers, and when you have few of them its easy enough to not move pointer properly...
It might be that they used ready made RMS function or lib and did not implement it properly..

Any ways, should be easy enough to fix..

How do we make Rigol fix it ?  That is the question now...

[Assafl]

There is no DC error in channel data.. traces look ok... other measurements seem to be ok but I will be checking soon...
It is probably some stupid counter variable, global variable, array index or something stupid like that in RMS calc..
These things are made as running circular buffers, and when you have few of them its easy enough to not move pointer properly...
It might be that they used ready made RMS function or lib and did not implement it properly..

Any ways, should be easy enough to fix..

How do we make Rigol fix it ?  That is the question now...

I sent it to Rigol a few days ago. I actually got a response - but before you get hopes high - a response that says where did I get the scope from? So since I got it from Tequipment I assume I'll get a follow up from Rigol NA sometimes in the near or mid or distant future.

[technogeeky]

There is no DC error in channel data.. traces look ok... other measurements seem to be ok but I will be checking soon...
It is probably some stupid counter variable, global variable, array index or something stupid like that in RMS calc..
These things are made as running circular buffers, and when you have few of them its easy enough to not move pointer properly...
It might be that they used ready made RMS function or lib and did not implement it properly..

Any ways, should be easy enough to fix..

How do we make Rigol fix it ?  That is the question now...

It might help if we can isolate an exact source of the particular number we're finding. In my case, I found this common ratio that was a single relationship between CH1 and CH2. (e.g., in my case, 1.93 was the minimum voltage).

[Fungus]

It might help if we can isolate an exact source of the particular number we're finding. In my case, I found this common ratio that was a single relationship between CH1 and CH2. (e.g., in my case, 1.93 was the minimum voltage).

If it's some sort of circular buffer bug then that won't work.

But ... I don't believe it's would be a circular buffer bug though. We know it's working from "on-screen" data and there's really no reason for the on-screen data to be circular, ie. If the display is correct then the RMS should also be correct.

OTOH: Making a precise RMS measurement of a randomly chosen subset of a waveform on screen isn't easy. eg. If somebody puts 2.7 waveforms on screen then which part are we supposed to sum, exactly? 

If it just depended on the number of waves on screen then it would be understandable. It doesn't do that though, it depends on other channels. The only answer I can think of as a programmer is there's an uninitialised variable somewhere, eg. Some value isn't initialized to zero at the start of the sum.

If Rigol is reading this then that's where to start looking.

[Fungus]

This thread has really been sidetracked, there's been hardly any discussion of how great it is that all the major bugs seem to be fixed now.

There's no more lockups, the math is fixed... the scope is now at 99.999999% of its full potential.

(Apart from the user interface paradigm of pushing a twisty knob to do everything)

[canibalimao]

So, just to simplify: the last update is really worth, right?

[Assafl]

This thread has really been sidetracked, there's been hardly any discussion of how great it is that all the major bugs seem to be fixed now.

There's no more lockups, the math is fixed... the scope is now at 99.999999% of its full potential.

(Apart from the user interface paradigm of pushing a twisty knob to do everything)

Koombiah. But then again if it is an easy fix to eck out even better results - why not?

 

[Fungus]

So, just to simplify: the last update is really worth, right?

There doesn't seem to be any downsides to updating.

But ... the old curmudgeon in me would like to say, "If it ain't broke, don't fix it".

Don't upgrade just to see the version number change on screen. There's always a non-zero chance that a failed firmware update will brick a device (any device!)

If the bugs aren't affecting you and you don't need the new XY mode then wait for the next one. You can always apply this update if one day you need to use the math functions (or whatever).

[Fungus]

This thread has really been sidetracked, there's been hardly any discussion of how great it is that all the major bugs seem to be fixed now.

Koombiah. But then again if it is an easy fix to eck out even better results - why not?

Sure, but three days ago the RMS thing even wasn't on the radar. The only things being discussed were the math offset and the measurements freezing.

It's amazing how fast things can change. 

3.FFT works nicer than before

In what way?

[alsetalokin4017]

Long-pressing the 'Measure' button clears all the measures :-)

LOL as soon I get to lab I'm gonna try it... Epic...

I read that in the manual now, press and hold measure to clear all measurements. But if you enable one (I enabled the last one), they all come back grayed out, except the last one enabled. The same thing if I use the All Items Delete button. So how do I get rid of them all and just enable only one again, without excess grayed out clutter coming back?

You use the "Select Item" menu option.

[metrologist]

Thanks!