rigol DS1054Z wrong rms measurement on long waveform - Page 1
Forum section: electronics / testgear

author: ziopaper
author_rank: Newbie
timestamp: May 07, 2015, 04:57:45 pm
content: Hello,I have a brand new beautiful DS1054Z.If I measure a sinusoid from a funct generator (500mVrms, 60Hz) the measurement looks correct on the scope if I have a time scale of 10ms/div.expanding the time scale to 500ms/div, the rms measured changes to 725mV (frequency measured also changes to 100Hz)I tried at 12M points, 6M and 60k. Same result. On the expanded time scale, if I stop the scope and enable the delayed sweep time base (pressing on the horizontal scale knob) and zoom in enough, the rms measurement will be correct again. This means that the scope has in memory the correct waveform, with enough details (no aliasing or other problems).So how is it calculating the wrong rms on the long time scale? or is it downsampling to do the calculations? (also the period is wrong, so it is missing the zero crossings)Also I noticed that with so many points, the rms is still calculated very quickly (too quickly?) while a tektronics DPO3000 would take several seconds to display rms of a long waveform at 5M points.Is there anything I am missing?Thanks a lotMarco

author: alsetalokin4017
author_rank: Super Contributor
timestamp: May 08, 2015, 04:14:09 am
content: For the measurements selected from the left menu items, I think the scope only uses what is displayed on the screen, or in the zoom window when you are zooming the horizontal timebase, not the whole sample set in memory. So yes, it's probably a sampling error/aliasing problem when you are showing a great many cycles in the screen or zoom window. I think... maybe.

author: tautech
author_rank: Super Contributor
timestamp: May 08, 2015, 04:36:53 am
content: Trigger level setting?

author: ziopaper
author_rank: Newbie
timestamp: May 08, 2015, 07:29:41 pm
content: trigger is set to edge, auto sweep, dc coupling.I guess is doing the rms on the samples that are shown on the screen...I am not sure why. This is a rather simple function since all the samples are stored in the memory.Any other comments are appreciatedOne of the reasons I have this scope is looking at a switching waveform of a PFC, so I do need to read the rms of a switching waveform over a 60Hz period.this is a bummer. Such a nice scope

author: wraper
author_rank: Unknown
timestamp: May 08, 2015, 07:35:23 pm
content: Quote from: ziopaper on May 08, 2015, 07:29:41 pmTrying to calculate from the whole memory would be damn slow.

author: ziopaper
author_rank: Newbie
timestamp: May 08, 2015, 07:39:46 pm
content: calculating based on random samples gives the wrong answer. This is useless.I would take slow vs useless anytime. Tektronix's one takes 5-10 seconds (not minutes), nothing wrong with itPlease don't tell me "just use the tektronix then". I believe this is an unacceptable bug, doesn't matter how cheap the scope is.I might contact Rigol about a firmware update on the issue

author: tautech
author_rank: Super Contributor
timestamp: May 08, 2015, 08:09:44 pm
content: Quote from: ziopaper on May 08, 2015, 07:29:41 pmAs it should be, but "level" can make a difference on how the scope calculates a result.Screen shot required.

author: ziopaper
author_rank: Newbie
timestamp: May 08, 2015, 08:43:37 pm
content: trigger level did not affect the rms measurementsee attached screenshot for a specific trigger level, at 3 different time base length.60Hz sinusoid, 1V rms from function generatorthanks

author: Sailor
author_rank: Regular Contributor
timestamp: May 09, 2015, 12:01:01 am
content: From those screen shots I'd say that it's pretty obvious that the cause is what I suggested the other day (on that other forum), and which others are suggesting above i.e. the Rigol isonly using the points that it has displayed on the screenfor its computations. The total screen width is only 800 points. The waveform display width is only approx 600 - 640 (just eyeballing it). In your second screen shot I can count ~ 10 cycles per division, so in other words there are only 60 - 64 screen points for 10 cycles i.e. ~6points per cycle. It's inevitable that the computation will be wrong. Look at the first screen shot, I think there's approx 25 cycles in one divisioni.e. 2.5 screen points per cycle. That shot naturally shows the greatest error in the computation. The second has less error, and in the third shot, where you have ~ 60 screen points per cycle, delivers an almost exact value.PS Closer scrutiny indicates ~12 cycles per division in the second shot, and ~30 cycles per division in the first shot - essentially right on the absolute Nyquist limit.

author: ziopaper
author_rank: Newbie
timestamp: May 09, 2015, 12:17:27 am
content: lol, small world.yes, I believe this is what is happening. It doesn't make any sense to implement a function based on the displayed points (since the points are available in memory). Hopefully I can get a firmware update about this. If Rigol cares, fixing this should be very easyI'll keep posting here in case of a positive outcomeThanks Sailor (you confused me talking about integer number of cycles, as this was not the case)

author: ebastler
author_rank: Super Contributor
timestamp: May 09, 2015, 06:35:57 am
content: Quote from: ziopaper on May 09, 2015, 12:17:27 amYes, I'm sure they are already on standby for some firmware-on-demand for you...Honestly, I think Rigol's current implementation has its justification. The one-button measurements provide quick, real-time quantification of what's on the screen. Because they are fast, they are useful for a quick check of the signal, as well as for interactive adjustment of signal levels, frequencies etc.. A measurement that takes 5 to 10 seconds to update would be annoying for the first use case, and useless for the second one.I, too, have sometimes wished for an alternative, in-depth analysis mode that applies to the complete memory (or at least to the signal segment shown on the screen, but using the full sampling resolution from memory). But that is an alternative, maybe additional mode, in my view -- not "the right way to do measurements", with Rigol's current implementation being wrong. We are talking "feature wish" here, not "bug". If I had to choose just one of the two modes in my scope, I would go for the current, fast version any time.And, let's face it: The DS1000Z series are budget, entry-level scopes. Rigol needs to cut some corners to keep the hardware cost down while still providing decent interactive responsiveness. Plus, they would be stupid to give you "everything" in the low-cost model, while still having more expensive instruments in their portfolio...

author: Armxnian
author_rank: Regular Contributor
timestamp: May 09, 2015, 07:15:02 am
content: As mentioned above, the values are calculated by what is displayed on the screen. This can be confirmed by many different tests. Input a 5v signal, and set your scope to 100mv/division, and use the Vmax function. It will display stars because it is unknown. If it displayed 5v, it would be accurate, but it wouldn't make sense, because you're not looking at 5 volts. You can try the frequency measurement as well. Input a sine wave and turn on the hardware counter and the software freq function. At a long enough time base, both will display the same value. But shorten the time base so the displayed wave is less than 1 period, and you will see the stars again. It is more logical (on an oscilloscope) for the value to reflect what is displayed.Some settings also reflect more accurate values than others. Input a 1v signal, and observe it at relatively close settings, like 500mv/div, 1v/div, 2v/div. The software function for Vmax will display 1v for all those settings. But try going up to 10v or higher (x10 probe setting). Even though the signal is still visible on screen, the numerical value will not be 1v. Most likely a limitation of the hardware as to a firmware issue where the hardware isn't communicating correctly with the software.Of course this discrepancy is easy to detect because you know what the actual value of the input signal is, but on the other hand you are looking for values that are incorrect. I've found that more vertical and horizontal settings give the accurate value compared to the wrong value. So if 5 different time bases give you 500rms, and 1 gives you 750rms, then the 5 are sure to be more accurate. You can most certainly find the correct value with quick tweaking.

author: ziopaper
author_rank: Newbie
timestamp: May 12, 2015, 06:37:34 pm
content: Quote from: ebastler on May 09, 2015, 06:35:57 amMost probably not. Or maybe they are. The rep said he will pass my feedback to the eng team. Might be saying it just to make me stop bug him or maybe because my feedback is not bad.Quote from: ebastler on May 09, 2015, 06:35:57 amI am not sure that in their high level ones they do the measurements differently.Myopinionis that if people are checking a 60hz signal with 6M points, on a long time scale, they are using the scope wrong, and if in that case the measuremnt takes a long time, it is their fault. If you are checking a fast changing waveform (repetitive, not slowly changing like in a PFC), than you need the resolution, but you do not need the long time scale, so the total number of points you need can be kept low; also in this case the measurement will not take long if scope is set to a reasonable resolution/time scale for the application.The only case in which I can think (my application, might be missing a lot of other cases) you might need a long time scale (for the low frequency) with high resolution (to capture the details of the high frequency) is something like a PFC. In that case, speed of calculation is secondary compared to having something that makes sense

author: alsetalokin4017
author_rank: Super Contributor
timestamp: May 16, 2015, 05:56:57 am
content: Here's an example of why you might want the Left Menu measurements to use only the displayed screen data rather than the whole buffer. These are two shots of the same gated signal, one at 2 ms/div and the other at 500 ns/div. Note that the Hardware Frequency Counter at top right operates on the entire buffer. The cursor measurements give the correct frequencies by taking the inverse of one period of the displayed signal, either the gated blocks or the fine oscillations inside the blocks. The Hardware counter cannot report an accurate frequency of this higher frequency signal, but the Left Menu frequency measurement operating on the screen display data agrees with the cursor measurement.

author: ziopaper
author_rank: Newbie
timestamp: May 18, 2015, 04:40:04 pm
content: I think we are talking about two different things.I do not think it should use the entire memory buffer. I think it should use all the points of what is visualized, or at least offer the option of choosing.The example you are showing, (correct me if I am wrong), you are zooming (changing the time scale) into a part of the acquired buffer. If the measurement (left menu, same as you are using) was based on all points of the displayed data, it will always give you the correct result. If it is too slow, in case not all points are needed for your application, you can change the number of points being acquired.It donotthink (and I don't know if there are any application in which it would be useful) that it should give a measurement of the entire bufferevenif you are looking at a small part onlythanks

author: ziopaper
author_rank: Newbie
timestamp: May 18, 2015, 04:41:39 pm
content: btw, I checked with the Rigol rep, and he confirmed that also the higher end Rigol scope implement the measurements in the same way, so it is a design decision (without thinking of PFC apparently), not a matter of entry level oscilloscope

author: merlinb
author_rank: Contributor
timestamp: July 24, 2018, 08:45:37 am
content: I just discovered this quirk when compensating my probes. When monitoring the Rigol's own square wave generator (0 to 3V) the RMS measurment reads 2.0V, not 1.5V! (It doesn't matter what the time base / scale is set to).

author: 2N3055
author_rank: Super Contributor
timestamp: July 24, 2018, 09:52:39 am
content: Quote from: merlinb on July 24, 2018, 08:45:37 amIt is correct ..A small quiz for you..Try changing changing channel to AC coupling. What you get then?And image of different scope with clues...Think average voltage VS. average power equivalent voltage.

author: Fungus
author_rank: Super Contributor
timestamp: July 24, 2018, 11:58:47 am
content: Quote from: merlinb on July 24, 2018, 08:45:37 amIt should actually show sqrt(9/2), ie. 2.12VI'll leave the reason why as an exercise for the reader.

author: ebastler
author_rank: Super Contributor
timestamp: July 24, 2018, 12:07:26 pm
content: Quote from: Fungus on July 24, 2018, 11:58:47 amHmm, let me think... Maybe the root of the mean squared voltage is involved in some way...?

author: Fungus
author_rank: Super Contributor
timestamp: July 24, 2018, 12:09:55 pm
content: Quote from: ebastler on July 24, 2018, 12:07:26 pmThat's what the letters 'RMS' stand for, yes.Here's the value as calculated on a (nearly) 100 year old Keuffel and Esser analog device:Edit: Image updated to correct the deliberate mistake. Answer is now exactly 2.12!

author: 2N3055
author_rank: Super Contributor
timestamp: July 24, 2018, 04:28:00 pm
content: I forgot to attach image.....

author: ebastler
author_rank: Super Contributor
timestamp: July 24, 2018, 04:44:52 pm
content: Quote from: Fungus on July 24, 2018, 12:09:55 pmThanks for sharing the slide rule calculation.That particular slide rule has a few years to go until its 100th birthday, however. Can't be older than 1933, the date of the indicated patent:https://patents.google.com/patent/US1934232A/en?oq=us1934232

author: 2N3055
author_rank: Super Contributor
timestamp: July 24, 2018, 05:44:56 pm
content: This one is a youngster than, from the 1971, Russian (CCCP)..

author: Fungus
author_rank: Super Contributor
timestamp: July 24, 2018, 06:25:33 pm
content: Quote from: ebastler on July 24, 2018, 04:44:52 pmRounded off a little bit.The serial number is 525455 sothis chartwould place it around the start of 1935. That matches the patent.I've got another K&E from 1928 somewhere, I just grabbed the nearest one for that photo.(still not 100 years though... you got me there)Quote from: 2N3055 on July 24, 2018, 05:44:56 pmYes. 1971 is about when they started to vanish so that would be among the last ones ever made.

author: merlinb
author_rank: Contributor
timestamp: July 26, 2018, 08:14:14 am
content: Quote from: 2N3055 on July 24, 2018, 09:52:39 amI had to think about that for a while but I see you are right. So my complaint instead is that my 'true RMS' multimeters read 1.5V for the same waveform (on the DC volts setting). This bothers me. I suppose they are discarding the AC component of the waveform before measuring, although that's not really what I would expect from a notionally DC-RMS voltmeter measuring aunipolarwaveform!

author: ebastler
author_rank: Super Contributor
timestamp: July 26, 2018, 08:25:21 am
content: Quote from: merlinb on July 26, 2018, 08:14:14 amWell, theaverageDC voltage on that 0V-to-3V signal is 1.5V indeed. You can interpret it as an AC-only signal (with +- 1.5Vpp) on top of a 1.5V DC offset. For a multimeter, I would indeed expect it to give me the DC offset (i.e. average DC voltage) when I measure the signal in DC mode, and the RMS voltage of the AC-only component when I measure in AC mode. So your multimeter probably performs as it should.The scope gives you more flexibility, as you can choose to measure either theaveragevoltageor the RMSvoltage of the "mixed" 0V-3V signal. The multimeter does not have these two separate settings, I assume, so it opts for the more commonly required readout, namely the average DC.

author: 2N3055
author_rank: Super Contributor
timestamp: July 26, 2018, 08:26:30 am
content: Quote from: merlinb on July 26, 2018, 08:14:14 amWell, meters are usually made to show AC TRMS (~~), DC average(=) (to show dc component directly) and AC+DC TRMS (the real TRMS (~=)). On Brymen 869 you have to cycle through the modes to see all the combinations (it has dual, not triple display). Larger graph screen meters (Uni-T UT181 for instance) can show all 3 at the same time, cutting down on confusion.

author: Fungus
author_rank: Super Contributor
timestamp: July 26, 2018, 08:39:08 am
content: Quote from: merlinb on July 26, 2018, 08:14:14 amThe Rigol can read that, too. Just switch to AC coupling for the channel.hint: RMS isn't the same when a waveform is centered around zero as when it's offset.

author: merlinb
author_rank: Contributor
timestamp: July 26, 2018, 02:20:19 pm
content: Quote from: 2N3055 on July 26, 2018, 08:26:30 amI did not know I could even do this, but you're right! My meter was DC (mean) by default, but there is a DC+AC option in the menu! I always expected the DC range on atrue-RMSmeter to do that by default but I guess that's not the case.