New Rigol DS1054Z oscilloscope

[Fungus]

And you certainly don't know the mechanism how it gets it's RMS reading wrong.

I don't know how quantum physics works but I managed to be born and stay alive long enough to type this message.

[Assafl]

So almost 50% higher RMS reading on second channel on your own screenshot is nitpicking?

It's not 50% when you get a reasonable number of pulses on screen

It's never 50% on the "Per.VRMS" reading.

Does it tell you how many pulses are reasonable enough so you can trust it?

Reminds me of EE101 lab. First year in undergrad the lab supervisor made sure we would never trust a scope (or any other T&M) ever again. Simply spoken - until you understand exactly what the scope does everything it shows is meaningless. Everything.

And in this case it IS meaningless, because:

until you understand exactly what the scope does everything it shows is meaningless.

And you certainly don't know the mechanism how it gets it's RMS reading wrong.

Actually you do - Fungus fully screen-shot the process he used to characterize the scopes' operation and show how the edges of the displayed traces affected the measurement. Now he knows when to use RMS - a long sample of a random audio input for example or PerRMS - when he wants to measure the RMS value of a 1 cycle of a repetitive signal.

Fungus did a swell job on this. Hats off to him!

[wraper]

Actually you do - Fungus fully screen-shot the process he used to characterize the scopes' operation and show how the edges of the displayed traces affected the measurement. Now he knows when to use RMS - a long sample of a random audio input for example or PerRMS - when he wants to measure the RMS value of a 1 cycle of a repetitive signal.

No you don't. All he did is measured only one particular signal at different timebases. It is as far as the moon from being characterized. What happens if there is sine wave, triangle and what else at different amplitudes and frequencies?

[JPortici]

This sub-discussion about a spelling error is actually very good lesson to show non-English speakers about how the English speaking market treats spelling errors.
In countries where a spelling bee is a cultural icon, spelling is one of the fundamentals of trust. This lack of trust will continue to contaminate whatever Rigol is or will be doing right - until they resolve it.

I'm italian

[Assafl]

Actually you do - Fungus fully screen-shot the process he used to characterize the scopes' operation and show how the edges of the displayed traces affected the measurement. Now he knows when to use RMS - a long sample of a random audio input for example or PerRMS - when he wants to measure the RMS value of a 1 cycle of a repetitive signal.

No you don't. All he did is measured only one particular signal at different timebases. It is as far as the moon from being characterized. What happens if there is sine wave, triangle and what else at different amplitudes and frequencies?

If the edges are so important then you characterize it specifically for your use case (if you depend on the measurement for anything important).

Do you really expect to hook up anything and just trust it? We never trusted Fluke nor Tektronix nor HP (those were the only things we had in the Navy lab), nor Anritsu or HP or Tabor (in the university lab) or even the expensive stuff like Bruel & Kjaer. Why would you trust a Rigol any more than that???

[wraper]

Do you really expect to hook up anything and just trust it? We never trusted Fluke nor Tektronix nor HP (those were the only things we had in the Navy lab), nor Anritsu or HP or Tabor (in the university lab) or even the expensive stuff like Bruel & Kjaer. Why would you trust a Rigol any more than that???

Do you expect anyone with sane mind to use broken feature for anything even remotely serious, by characterizing amount of it's brokenness? (unless you are on a Mars and this is you're only scope). What is broken, must be fixed and not considered small nuisance that probably can be characterized.

[Assafl]

This sub-discussion about a spelling error is actually very good lesson to show non-English speakers about how the English speaking market treats spelling errors.
In countries where a spelling bee is a cultural icon, spelling is one of the fundamentals of trust. This lack of trust will continue to contaminate whatever Rigol is or will be doing right - until they resolve it.

I'm italian

LOL. I am Israeli and also have the spelling bug - I can spot an error in the newspaper on the floor. It just seems to float.

Chasing spelling, bad grammar, and GUI logic issues takes a heck of a lot of time in managing a product developed offshore. In my previous company we had an engineer who set the default timezone of our system to be his birth hometown of Yekaterinburg - which (obviously) ended up being of concern to our US customers.

 

[Assafl]

Do you really expect to hook up anything and just trust it? We never trusted Fluke nor Tektronix nor HP (those were the only things we had in the Navy lab), nor Anritsu or HP or Tabor (in the university lab) or even the expensive stuff like Bruel & Kjaer. Why would you trust a Rigol any more than that???

Do you expect anyone with sane mind to use broken feature for anything even remotely serious, by characterizing amount of it's brokenness? (unless you are on a Mars and this is you're only scope). What is broken, must be fixed and not considered small nuisance that probably can be characterized.

Well - As engineers we like to dwell in the comfort of the digital domain, where numbers are numbers and interfaces work well.

I can't talk to all disciplines of electronics design but my topics were analog: undersea acoustics (B&K and ITC transducers, lots of B&K Amplifiers, Recorders, HP and Tek visualizations - scopes), RF (Mainly Anritsu, EESof - before HP bought them, and HP signal generators, Mini-circuits and others) and Power electronics (transformers and mainly Fluke stuff).

For all of them we would meticulously characterize prior to running a field test. Before building an antenna. Before getting the navy to send out ships for a test. Why - because they all had limits. Call it broken. Call it functionality problems. Whatever. Once you are in the analog realm everything rings with Gibbs. Every square wave badly formed by non perfect semiconductors is further rounded by your probe and scope. Everything is broken. Yes.

If understanding that everything is broken helps someone out there avoid a mistake - I'll buy in to the concept. Everything is broken. Now as engineers, let's understand the compromises and use the properly characterized (albeit - broken) tool for the job.

[Fungus]

properly characterized

This is the key.

We've just characterized the Rigol's RMS readings. That's progress.

PS: I'm still waiting to see if people can do the same tests on other 'scopes. Where are the GW Instek boys when you need them?

[wraper]

And now please characterize dependence between CH2 RMS reading from the signal captured on CH1, because it is there. Call it digital crosstalk.

[Meka77 wd]

Hi everyone...

@Fungus, you have 4.3SP1 firmare on your scope i think. Can you do this simple test for me and send screenshots.

First connect your probes on probe calibration terminal:

1. Set your probes at 10x, and on the scope comp. 10x also (both channels DC coupled),
2. Set scope time base 500us,
3. Select for both channels RMS measurement from left vertical menu (not Per.Vrms),
4. Set Cursor Mode:Auto/ Auto Item:Quick2 (indicates Ch2 RMS, it may Quick1 select accordingly),
5. Set Ch2 10V/per.div and position -30V,
6. Set Trigger on Ch2,
7. Please take a screenshot with quickprint button,
8. Set Ch1 to AC Coupling,
9. Take another screenshot,
10. Now set Ch1 Coupling to GND and take last screenshot.

I have 4.3SP2 firmware and these are my screenshots...

[wraper]

Turning on AC coupling gives completely different numbers.



nb. The correct RMS for a 3V square wave should be 2.12V  (3/sqrt(2))

Learn how RMS works. 1.5V is correct value.

[alsetalokin4017]

Turning on AC coupling gives completely different numbers.

(image snipped)

nb. The correct RMS for a 3V square wave should be 2.12V  (3/sqrt(2))

Learn how RMS works. 1.5V is correct value.

That's right. The Vp/sqrt(2) is for a 50 percent duty cycle positive pulse train. For the bipolar square wave VRMS = Vpeak.
Derivations here:
http://masteringelectronicsdesign.com/how-to-derive-the-rms-value-of-pulse-and-square-waveforms/

[Fungus]

Hi everyone...

@Fungus, you have 4.3SP1 firmare on your scope i think. Can you do this simple test for me and send screenshots.

First connect your probes on probe calibration terminal:

I have 4.3SP2 firmware and these are my screenshots...

Mine are very similar.

[Fungus]

Following on from the previous test: We know the Rigol works from 'on-screen' data so what happens if you maximize the waveform on screen?

Answer: All the readings are now very accurate!

Here's the same set of tests. The "RMS" readings are now 2.13, 2.13, 2.11  (should be about 2.12 for a 3V square wave)

[wraper]

So Per.Vrms is broken too 

[Meka77 wd]

Thanks @Fungus. But your cursor setting is not what i told (it must Cursor/Mode:Auto-Auto Item: QuickX (ch2 RMS))

And you are not seeing big picture, when you set the ch1 coupling to GND, your ch2 RMS measurement error is gone...

Sadly it seems 4.3SP1 have this RMS bug too. 

[Assafl]

Hi everyone...

@Fungus, you have 4.3SP1 firmare on your scope i think. Can you do this simple test for me and send screenshots.

First connect your probes on probe calibration terminal:

1. Set your probes at 10x, and on the scope comp. 10x also (both channels DC coupled),
2. Set scope time base 500us,
3. Select for both channels RMS measurement from left vertical menu (not Per.Vrms),
4. Set Cursor Mode:Auto/ Auto Item:Quick2 (indicates Ch2 RMS, it may Quick1 select accordingly),
5. Set Ch2 10V/per.div and position -30V,
6. Set Trigger on Ch2,
7. Please take a screenshot with quickprint button,
8. Set Ch1 to AC Coupling,
9. Take another screenshot,
10. Now set Ch1 Coupling to GND and take last screenshot.

I have 4.3SP2 firmware and these are my screenshots...

I concur the findings. Interesting. Tried the same with Ch1 and Ch3 - but didn't get the same results - are you getting this behavior for any combination of channels?

[alsetalokin4017]

OK... based on JohnPen's posts I have pulled the trigger and updated my scope to the current firmware  00.04.04.00.07.

I am very happy to report that the Math Horizontal Error at 500 ns/div seems to be GONE !! The Math trace now displays correct time relationships to the input signals.

I am still testing for the Measurements Fail bug. This one was totally random in the time it took to fail so it may take me a while to be confident that it is gone.

The interface doesn't seem quite as sluggish as it was before, but that might just be subjective.

Color me a happy scoposcopist! Yay Rigol!

Now if we could only get rid of that "Pluses" thing.....

[Assafl]

So Per.Vrms is broken too 

Yes - if the vertical range is such that does not allow it to figure out what 1 cycle looks like - it shows zero. Zero is indeed wrong. But we now know that in Rigol Land, 0 stands for "0" but also for "couldn't quite latch on so I'll say 0".

BTW - It would have been more useful to say N/A to let us know it could not find a cycle, rather than a misleading 0.

A corollary - if you increase the Y axis even more - the error in Vrms calculation increases. That is also "broken". 

[Meka77 wd]

Comparing DS1000Z vs. DS2000A regarding RMS bug...

 

Thanks for your patience.

[Meka77 wd]

I concur the findings. Interesting. Tried the same with Ch1 and Ch3 - but didn't get the same results - are you getting this behavior for any combination of channels?

Thank you for checking this.

If you gonna try other channels, try like this;

Ch1 =leaks=> Ch2, Ch2 =leaks=> Ch3, Ch3 =leaks=> Ch4 

Just fantastic!

OK... based on JohnPen's posts I have pulled the trigger and updated my scope to the current firmware  00.04.04.00.07.

I am very happy to report that the Math Horizontal Error at 500 ns/div seems to be GONE !! The Math trace now displays correct time relationships to the input signals.

I am still testing for the Measurements Fail bug. This one was totally random in the time it took to fail so it may take me a while to be confident that it is gone.

The interface doesn't seem quite as sluggish as it was before, but that might just be subjective.

Color me a happy scoposcopist! Yay Rigol!

Now if we could only get rid of that "Pluses" thing.....

Btw. can you test RMS sht., if its okay i'm gonna flash it too. Thanks!

[Assafl]

I concur the findings. Interesting. Tried the same with Ch1 and Ch3 - but didn't get the same results - are you getting this behavior for any combination of channels?

Thank you for checking this.

If you gonna try other channels, try like this;

Ch1 =leaks=> Ch2, Ch2 =leaks=> Ch3, Ch3 =leaks=> Ch4 

Just fantastic!

Indeed - it does indeed. What a curious bug. As a programming bug why would it happen between inputs 1&2; 2&3 and 3&4 and not 1&3 or 1&4? It is almost as if it some RMS aggregating capacitor that needs a few more mSec to discharge and zero out...

Few comments about the bug - If one wants to measure RMS voltage of two channels as accurate as possible simultaneously - choose 1&4. Also, as usual, have the trace take up as much vertical space as practical (always good, and PerRMS will work for repetitive signals too!).   

Edit - one thing I noticed - you do not need the cursor at all to reproduce the bug. Just two channels, hook up the trigger to the first channel and play with the y-div of the second channel. It is crystal clear...

[2N3055]

I tried and confirmed that nothing is needed except :
1. two consecutive channels, (1&2 for instance)
2. connect with probes to cal out..
3. press auto setup
4. enable RMS on both...

Funny thing if you disable channel 1, trace is gone, it shows channel as off, but RMS for CH1 is still calculated and CH2 RMS has error...
Only if you set coupling to GND or disconnect cable on CH1 it goes away.

If I were to speculate, it is a problem how they handle data for RMS calc.. RMS is calculated as a running filter on a circular buffer... multiplexed between channels.. could be that  some data in some buffer leaks to a next channel or something like that..
Anyways, annoying...

No other problems though...

[Fungus]

A corollary - if you increase the Y axis even more - the error in Vrms calculation increases. That is also "broken".

If the trace goes off screen it will fail because the 8-bit ADC will be saturated to readings of 0 & 256.

There's nothing anybody can do about that.