Rigol MHO900 Test/Review (MHO954/984)

[PCK]

Maybe it is doing something clever with the 1000 points to recover the right RMS, but a straight forward std-deviation of the Mem data in the window span looks close to the (DHO804) scope reading. The std-dev of the 1000 points (done the same way) looks different. Attached is another example.

I could believe it if there was a 5% difference but the values are just too close.  You could always downsample your sample data to say 10,0000 points see what difference it makes. 

[kmoonwalker]

my bet would be on some rounding at some stage of calculating making this visible - perhaps it slowed down operation in their implementation or they used incorrect number representation at that stage 

[rpro]

Maybe it is doing something clever with the 1000 points to recover the right RMS, but a straight forward std-deviation of the Mem data in the window span looks close to the (DHO804) scope reading. The std-dev of the 1000 points (done the same way) looks different. Attached is another example.

I could believe it if there was a 5% difference but the values are just too close.  You could always downsample your sample data to say 10,0000 points see what difference it makes.

An example of 200 random samples with increasing sizes....

[2N3055]

Let's devise a test vector then to verify if Stdev is right.
Create a pulse waveform with 25% on time, 25% duty cycle. 1V P-P. From 0 V to 1V.
Frequency not important. Let's say 100kHz.

Put 10 periods on screen and measure Stdev.
Then start making timebase longer. Make sure memory is long enough so sampling rate does not drop.
Put 40, 50, 100 periods on screen.
At one point you will see solid block on the screen.
What was happening to Stdev?

[Martin72]

I've actually already received a reply, which was very quick.
I'll post something about it after work, then my deviations, or those of others, will probably no longer be so surprising.
Because the settings are not the same.
I'll try it out later.

Well, I'm now well versed in the specifications...
Rigol sent me a (probably not yet published) “Performance Verification Guide” for the MHO900. I haven't found anything like this for the Rigol 12-bit scopes, except for the DHO1000, for which there is also one.
And the settings for the random noise test are completely different from what I had been using.
Time base 20µs, memory 1MPt....
Then, as usual, ACrms as the measured value – and then everything fits easily...
The only question is, is that “honest”....
I'll go through the entire Noise Test Report soon, just for fun, even though I already know that nothing will go wrong with these settings.

Martin

[Fungus]

It is unlikely for the FFT function to be able to utilize only the resampled 1kpts data.

I'm going with "impossible".

As in: Not happening. Somebody is mistaken.

[Kleinstein]

With only 1 Mpoints and 4 GSPS there would be not as much low frequency noise. For a practical use it is still realistic and thus makes sense for the test. The horizontal setting should not make any difference unless going slower, so that the sampling rate needs to be reduced.

One could try keeping the fixed 20 µs/div and increase the number of samples. Normally this should not change much (only a little more at the lower frequency end). If the noise suddenly jumps up, there is likely an issue in how AC.RMS is caculated.

[gf]

With only 1 Mpoints and 4 GSPS there would be not as much low frequency noise. For a practical use it is still realistic and thus makes sense for the test. The horizontal setting should not make any difference unless going slower, so that the sampling rate needs to be reduced.

One could try keeping the fixed 20 µs/div and increase the number of samples. Normally this should not change much (only a little more at the lower frequency end). If the noise suddenly jumps up, there is likely an issue in how AC.RMS is caculated.

For white noise, the number of samples should not make a big difference, as long it ls "large".

For bandwidth-limited but otherwise ideal 1/f noise, the measured noise power P = K*ln(f_max*T), where f_max is the upper bandwidth limit, T is the duration of the observation interval, and K is as constant. So in the presence of 1/f noise, the measured AC RMS is expected to increase when you keep sample rate constant and incrase the number of samples, which increases the measurement interval T.

1/f noise is perfidious, as noise power has no upper limit. When you make the measurement interval longer and longer, approaching infinity, the measured noise power approaches infinity as well. It does not converge to a finite limit.

1 Mpoints and 4 GSPS (f_min = 4MHz) is llikely in a region, though, where 1/f noise does not yet dominate the observed noise power.

[Martin72]

Make your own records...

[rpro]

If you select the 124,874 RAW points from the memory buffer that correspond to the span of the display, you get 137.73 mV.  Why not exactly 138.22?  I am not sure (though the discrepancy is in the noise of the accuracy)...

I guess it's the way the FPGA firmware makes the interpolation - either linear or sinc.

If You are using my mod (enterprise edition only), You can change auto interpolation to linear and check the same signal.

Would n't interpolation only apply to displayed data?

Nope. Let me repeat myself again: Whole scope app uses (always 1000) screen points to do all the staff - even FFT. Original points can be exported to the file and looks like this is the only time when app will get original samples from FPGA.

Measurements are done in app. Not in FPGA.

Maybe it is doing something clever with the 1000 points to recover the right RMS, but a straight forward std-deviation of the Mem data in the window span looks close to the (DHO804) scope reading. The std-dev of the 1000 points (done the same way) looks different. Attached is another example.

I experimented a bit further (with the DHO804) and noticed the following:

1. With the scope stopped (and no further acquisitions) the scope returns—under NORMAL mode via SCPI—always the points that correspond to what is visible on the screen, as one would expect.

2. Accordingly, if only part of a stopped waveform is made visible at a given timebase (e.g., by shifting the horizontal position far enough), the scope returns—under NORMAL mode—only the points corresponding to the displayed portion, which can be far fewer than 1,000.

3. In either scenario, the std-dev of the RAW points within the currently displayed waveform's time-span is close to the scope’s current AC-RMS reading, whereas the std-dev of the NORMAL points can be quite different.

So, it appears that the scope is effectively—or at least for practical purposes—using the full set of memory points, but then selecting only those that fall within the displayed waveform's time-interval window. Since this behavior still holds even when the number of NORMAL points can be made to be very small (≪ 1,000), I doubt the scope under normal circumstances is relying on the NORMAL data—it exposes—to compute AC-RMS. Thankfully.

[norbert.kiszka]

I doubt the scope under normal circumstances is relying on the NORMAL data—it exposes—to compute AC-RMS.

This is about "measurements" or about "DVM"? This second one is working on FPGA side.

[rpro]

I doubt the scope under normal circumstances is relying on the NORMAL data—it exposes—to compute AC-RMS.

This is about "measurements" or about "DVM"? This second one is working on FPGA side.

AC RMS measurement.

[Martin72]

Hi,
Due to the limited number of images, the post will be split into two parts.
Bode Plot Measure....
The good news is that the Bode plot has apparently been “fixed” and now looks as expected, which was not the case with the MHO5000.
End of the good news...
The menu is the same as on the larger MHO5000, i.e., just as simple and minimalistic.
You can choose between curve or table display—but not both, which is why I consider the table display rather pointless.
The maximum number of points is 100, the maximum frequency is 30 MHz – for whatever reason.
I then recorded plots from the filters of the Batronix demo board, low pass and band pass, as well as a notch filter with a frequency around 1.55 kHz.
As I said, the progress is that the curves look correct.
The scaling is somewhat unfavorable, especially with regard to the phase display, but the amplitude is also too coarse for the notch, for example—but that's not my fault...

[Martin72]

I was slowed down by a Gateway Error 502...
As I said, some of the displays are unfavorable, and the worst thing is that you can't change them.
You can't change the vertical scaling, neither for the amplitude nor for the phase.
That's bad, to put it mildly.
But that's not all...
You can choose between logarithmic or linear display, but nothing changes.
The horizontal division is also strange.
The full width is not used for a narrowband frequency selection, so you can't resolve any deeper; only when you set a wide frequency range is the horizontal bandwidth fully utilized.
The cursor functions are disabled in Bode Mode; the only thing you can do is move a white vertical line back and forth.
So:
-Only one output, other scopes have at least two.
-The maximum frequency of the AWG cannot be used; it is limited to 30 MHz.
-No adjustment options for amplitude and phase scaling
-Log/Lin switching has no effect
-Unconventional horizontal resolution
-No close-range measurement possible; there must always be a minimum factor of 10 between the start and stop frequencies (e.g., 100/1 kHz or 500 Hz/5 kHz, etc.)
-Very few adjustment options overall

That makes it another typical Rigol classic—it works somehow, but it's half-baked.

Martin

[Martin72]

Finally, a counterexample of what it could look like.

[mawyatt]

I was slowed down by a Gateway Error 502...
As I said, some of the displays are unfavorable, and the worst thing is that you can't change them.
You can't change the vertical scaling, neither for the amplitude nor for the phase.
That's bad, to put it mildly.
But that's not all...
You can choose between logarithmic or linear display, but nothing changes.
The horizontal division is also strange.
The full width is not used for a narrowband frequency selection, so you can't resolve any deeper; only when you set a wide frequency range is the horizontal bandwidth fully utilized.
The cursor functions are disabled in Bode Mode; the only thing you can do is move a white vertical line back and forth.
So:
-Only one output, other scopes have at least two.
-The maximum frequency of the AWG cannot be used; it is limited to 30 MHz.
-No adjustment options for amplitude and phase scaling
-Log/Lin switching has no effect
-Unconventional horizontal resolution
-No close-range measurement possible; there must always be a minimum factor of 10 between the start and stop frequencies (e.g., 100/1 kHz or 500 Hz/5 kHz, etc.)
-Very few adjustment options overall

That makes it another typical Rigol classic—it works somehow, but it's half-baked.

Martin

That's just a shame, we were really anticipating something much better!! Rigol had a change and seems to have dropped the ball again!! Maybe the 2 firmware gurus on here can bail them out!!

Looks like this DUT is a Twin-T Passive Notch Filter, maybe with Polystyrene Capacitors

Best

[PCK]

I experimented a bit further (with the DHO804) and noticed the following:

1. With the scope stopped (and no further acquisitions) the scope returns—under NORMAL mode via SCPI—always the points that correspond to what is visible on the screen, as one would expect.

2. Accordingly, if only part of a stopped waveform is made visible at a given timebase (e.g., by shifting the horizontal position far enough), the scope returns—under NORMAL mode—only the points corresponding to the displayed portion, which can be far fewer than 1,000.

3. In either scenario, the std-dev of the RAW points within the currently displayed waveform's time-span is close to the scope’s current AC-RMS reading, whereas the std-dev of the NORMAL points can be quite different.

So, it appears that the scope is effectively—or at least for practical purposes—using the full set of memory points, but then selecting only those that fall within the displayed waveform's time-interval window. Since this behavior still holds even when the number of NORMAL points can be made to be very small (≪ 1,000), I doubt the scope under normal circumstances is relying on the NORMAL data—it exposes—to compute AC-RMS. Thankfully.

Thanks for your work, that is good to know, I will do some experiments of my own and share here when I have a unit to test.  My guess is they decided to carry on using screen data for real time data since that is how they always did it when scopes had limited CPU power and they have an existing codebase that they used. Although the SOC in this unit is old it probably has enough grunt to do a lot better but (good) software is expensive to develop so we have what have.

[rpro]

I experimented a bit further (with the DHO804) and noticed the following:

1. With the scope stopped (and no further acquisitions) the scope returns—under NORMAL mode via SCPI—always the points that correspond to what is visible on the screen, as one would expect.

2. Accordingly, if only part of a stopped waveform is made visible at a given timebase (e.g., by shifting the horizontal position far enough), the scope returns—under NORMAL mode—only the points corresponding to the displayed portion, which can be far fewer than 1,000.

3. In either scenario, the std-dev of the RAW points within the currently displayed waveform's time-span is close to the scope’s current AC-RMS reading, whereas the std-dev of the NORMAL points can be quite different.

So, it appears that the scope is effectively—or at least for practical purposes—using the full set of memory points, but then selecting only those that fall within the displayed waveform's time-interval window. Since this behavior still holds even when the number of NORMAL points can be made to be very small (≪ 1,000), I doubt the scope under normal circumstances is relying on the NORMAL data—it exposes—to compute AC-RMS. Thankfully.

Thanks for your work, that is good to know, I will do some experiments of my own and share here when I have a unit to test.  My guess is they decided to carry on using screen data for real time data since that is how they always did it when scopes had limited CPU power and they have an existing codebase that they used. Although the SOC in this unit is old it probably has enough grunt to do a lot better but (good) software is expensive to develop so we have what have.

Sorry, to be clear, the DHO804 scope is always (effectively at least) using a subset of the RAW points stored in memory to calculate the AC-RMS reading it displays as "AC RMS" measurement, not screen data points (aka NORM points).  The selected subset used for calculation are those (usually denser) RAW points that do fall in the same time-interval span of the NORMAL points currently displayed on the screen, but not the NORMAL volt. values themselves.

(Why do I say "effectively"? Because, for example, there is a possibility that the scope is actually using multiple 1000 point batch samples of the RAW subset, one at the time (like a Kalman Filter could) to recursively estimate the AC-RMS and some other measurements, and displays only the (processed) current batch, which also makes it available as the current NORM points.)       

[norbert.kiszka]

And You based this on pure observation or by reverse engineering the scope app?

From my observations all measurements are using those 1000 screen points. It's most noticeable when You change interpolation.

[pizzigri]

Finally, a counterexample of what it could look like.

Wow, Martin what is that?

[PCK]

I experimented a bit further (with the DHO804) and noticed the following:

1. With the scope stopped (and no further acquisitions) the scope returns—under NORMAL mode via SCPI—always the points that correspond to what is visible on the screen, as one would expect.

2. Accordingly, if only part of a stopped waveform is made visible at a given timebase (e.g., by shifting the horizontal position far enough), the scope returns—under NORMAL mode—only the points corresponding to the displayed portion, which can be far fewer than 1,000.

3. In either scenario, the std-dev of the RAW points within the currently displayed waveform's time-span is close to the scope’s current AC-RMS reading, whereas the std-dev of the NORMAL points can be quite different.

So, it appears that the scope is effectively—or at least for practical purposes—using the full set of memory points, but then selecting only those that fall within the displayed waveform's time-interval window. Since this behavior still holds even when the number of NORMAL points can be made to be very small (≪ 1,000), I doubt the scope under normal circumstances is relying on the NORMAL data—it exposes—to compute AC-RMS. Thankfully.

Thanks for your work, that is good to know, I will do some experiments of my own and share here when I have a unit to test.  My guess is they decided to carry on using screen data for real time data since that is how they always did it when scopes had limited CPU power and they have an existing codebase that they used. Although the SOC in this unit is old it probably has enough grunt to do a lot better but (good) software is expensive to develop so we have what have.

Sorry, to be clear, the DHO804 scope is always (effectively at least) using a subset of the RAW points stored in memory to calculate the AC-RMS reading it displays as "AC RMS" measurement, not screen data points (aka NORM points).  The selected subset used for calculation are those (usually denser) RAW points that do fall in the same time-interval span of the NORMAL points currently displayed on the screen, but not the NORMAL volt. values themselves.

(Why do I say "effectively"? Because, for example, there is a possibility that the scope is actually using multiple 1000 point batch samples of the RAW subset, one at the time (like a Kalman Filter could) to recursively estimate the AC-RMS and some other measurements, and displays only the (processed) current batch, which also makes it available as the current NORM points.)       

You are right of course, I did some quick calculations and the number of points in the RAW subset even with 32-bit float would give an error of ~0.01% and in your last example you are seeing ~ 0.8%.  However I don't think they do anything as sophisticated as suggested as even 5000 points would probably give around ~1% depending on the complexity of the waveform.  With a fixed amount of points the error would increase as the number of samples increased, however they could vary by some fixed ratio to maintain reasonable accuracy. 

It's likely they re-use existing code bases wherever possible from their older scopes which if I'm not mistaken where Zync based which have much less CPU power (one or two cores at less than 1Ghz) but they could definitely get things more accurate in real time with some effort.  However even in stop mode calculating the whole dataset for 500Mpts is going to be slow, so I can see why they would use a subset as 1% for this class of scope is fine imo.

[norbert.kiszka]

It's likely they re-use existing code bases

You are so great software engineer and You were not able to do a simple reverse engineering?

You told us that You have "30+" years of experience. Something is odd here.

[PCK]

It's likely they re-use existing code bases

You are so great software engineer and You were not able to do a simple reverse engineering?

You told us that You have "30+" years of experience. Something is odd here.

<sigh>

The only thing that is odd is that you only seem to have one tool in your toolbox, why would I go to the trouble reverse engineering something when I can quickly come to the conclusion by doing simple maths?  The simple maths that proves that your 1000 point assertion is incorrect despite your reverse engineering.

That is what 30+ years of experience gets you, wisdom, which you seem to be completely lacking.

So seriously, stop embarassing yourself and don't direct any more messages at me.

[norbert.kiszka]

Your "simple math" actually is not correct.

I did two tests with only one change, which is interpolation of the screen data. RMS values are different between sinc and linear interpolation, so this is perfect proof of You being completely wrong.

So seriously, stop embarassing yourself

Quite typical for a internet troll who is afraid of proofs.

[2N3055]

You are right of course, I did some quick calculations and the number of points in the RAW subset even with 32-bit float would give an error of ~0.01% and in your last example you are seeing ~ 0.8%.  However I don't think they do anything as sophisticated as suggested as even 5000 points would probably give around ~1% depending on the complexity of the waveform.  With a fixed amount of points the error would increase as the number of samples increased, however they could vary by some fixed ratio to maintain reasonable accuracy. 

It's likely they re-use existing code bases wherever possible from their older scopes which if I'm not mistaken where Zync based which have much less CPU power (one or two cores at less than 1Ghz) but they could definitely get things more accurate in real time with some effort.  However even in stop mode calculating the whole dataset for 500Mpts is going to be slow, so I can see why they would use a subset as 1% for this class of scope is fine imo.

It is not ok when scope that is 1/3 of the price uses 10Mpts for calculations. Measuring complex signals is actually the name of the game. For pure sine signal I don't need RMS measured, it is mathematically connected with P-P value.

Let me remind you what I wrote:  RMS (AC or AC+DC) is vulnerable to crest factor errors.

While there was large discrepancy found measuring scope internal noise that started this question of RMS measurements, that is very wrong type of signal to verify RMS is functioning properly, because of everchanging BW and internal shenanigans it might be changing all the time. Also noise can be measured even when undersampling with only 1000 points from 100Mpts. You just need to sample repetitively for some time. You need to use periodic complex signal for test, to expose "holes in vision"....

So,external known signal needs to be used.
Secondly, signal has to have large crest factor to reveal potential problems.

One scenario where old DS1000Z was making large errors was for instance PWM signal that had large amplitude and low duty cycle. Like signal changing from 0 to 5V but at 2% ON duty cycle. If you had 10-20 of those pulses on the screen it still calculated about right. If you make timebase longer to capture 1000 cycles, it would start having large errors, despite sample rate did not drop and it had long memory enabled.
While on the other hand other scopes had measurement largely not changing until there was drop of timing resolution because of sampling.
With signals that have large crest factors and more complex shape than PWM it was even more visible, but those signals are hard to replicate for everybody and therefore hard to compare the results.
In attachment an Arb signal at 100ns/div and 200µs/div, 2000X time spread. All measurements include AWG errors and fact that both AWG and scope were on for few minutes only, so still drifting slightly.