Rigol MHO900 Test/Review (MHO954/984)

[Fungus]

What's the noise level with the internal 250MHz limiter enabled?

How does it compare with full bandwidth noise?

[Martin72]

Here are the values for full, 250MHz, and 20MHz, with a 50-ohm input and shielded BNC connector...

[Hydron]

So it's twice the datasheet spec?? If so that's a bit disappointing!

Have you tried measuring with an external 50 termination on the BNC (scope in 50 ohm mode) to represent a 50 ohm impedance source?

Edit: running the numbers reducing the source impedance shouldn't have much effect compared to the added noise from the scope.

[Martin72]

Hi,
At least 10µV less with additional 50Ohm termination...
Still well above the specification – as long as you don't know how Rigol measured it.
But then there was a pleasant surprise—at least for me. Perhaps the other DHO models are now the same as the MHO900 thanks to a firmware update.
Now you can switch between measurements as you like, which wasn't possible before.
I then decided to measure the other channels at maximum sample rate as well.
There is a small catch, though.
At first, I wondered why I only had a maximum of 2GSa/s after switching from Ch1 to Ch2 (and turning off CH1).
Solution:
The trigger...
It was still set to Ch1 as the source, which causes the sample rate and bandwidth to drop.
After I set it to CH2, I then had the 4GSa/s.

[egonotto]

Hello,

in terms of noise, that's very bad.

But I'm still not fully familiar with the capabilities of the MHO98.
What about segmented memory? How much memory is available and how much space must there be between the segments so that all segments are captured?
And how quickly can data be transferred to a PC?

Does your device have 500 MSamples?

Best regards,
egonotto

[Martin72]

Hi,

Here is a small table showing memory points and the maximum number of frames that can be recorded.

Does your device have 500 MSamples?

No, it only has the standard 100Mpoints, which I can't change because it's not my scope.

[Kleinstein]

For the noise data is woth notig that the noise with 250 MHz BW is quite a bit lower than with full BW  (95 µV compared to 280 µV). This is way more than roughly a factor of 2 expected from the BW ratio for white noise.
The noise with the 250 MHz BW limit is not so far of the specs (that are for the 500 µV range).

On the other side the 20 MHz case has still roughly half the noise of the 250 MHz case. So there is some low frequency noise as expected, but is is not the main point for the higher than normal noise level. With the 20 MHz BW the noise in the 1 mV range is even already better than the specs for the 0.2 mV range - so the LF noise part may be on the low side. Some scattering in the LF noise is not such a surprise and the specs can allow for this.

Part of the extra noise with full BW and sampling rate could be from how the signals of the 2 ADCs are combined. If not at exactly the same gain / offset there can be some extra noise from this. I don't know the scope, but there may be some kind of service call to redo the trim for this part. I may help to do a reset/reboot of the scope after it is warmed up. So a trim on turn on could be done on a warmed up scope.

[Martin72]

This scope also has a self-calibration function.
In normal mode, you cannot see what is being calibrated, but in the special “test mode” (press and hold “About”) you can see what is being calibrated—and what else could be calibrated.
(Footnote: Apparently, the temperature display has been removed, for whatever reason.)

[Fungus]

There is a small catch, though.
At first, I wondered why I only had a maximum of 2GSa/s after switching from Ch1 to Ch2 (and turning off CH1).
Solution:
The trigger...
It was still set to Ch1 as the source, which causes the sample rate and bandwidth to drop.
After I set it to CH2, I then had the 4GSa/s.

Every oscilloscope I ever used does that.

(not many, admittedly... but a few)

[Fungus]

This scope also has a self-calibration function.
In normal mode, you cannot see what is being calibrated, but in the special “test mode” (press and hold “About”) you can see what is being calibrated—and what else could be calibrated.

The old DHO800 does that. 

[Martin72]

I know it could also display temperatures.

Every oscilloscope I ever used does that.

I've seen this with other brands too, but it doesn't make it any better.
If I deliberately switch off a channel, it no longer makes sense to trigger it.
It would be different if I were just hiding the channel, as you can do with some Siglent models, for example.

Right now, I'm waiting for the self-calibration to finish—it's been running for an hour, only with the default values.

[Martin72]

Shortly thereafter, it was successfully completed.
Then I wanted to calibrate the points that had not yet been calibrated.
However, this failed after a short time.
Perhaps there is a reason why these points are not calibrated in normal cases.
Be that as it may, I will not pursue this further; without a precise description of what is being calibrated, there is no point in continuing.
What I don't like is that during calibration, the intensity level is increased to 100% and is not reduced back to the previous value after calibration.

[egonotto]

Hello,

To check the minimum distance between the segments of the MHO900, I created a test file for the SDS6000X. The file segments.csv can be loaded into the SDS6000X using EasyWaveX.
There are two different pulses.
The distance between the pulses can be changed by adjusting the frequency.
For me, 100 kHz still worked well. The pulse spacing is then 5 us. If the MHO900 can still detect this cleanly, then that is much better than with the DHO1074. The Siglent SDS3000X HD has no problems with this.
When I increase the frequency to 1 MHz, I can no longer distinguish the pulses.

So if the MHO900 still has no problems at a 5 µs interval, I would have to change the test file.

Best regards,
egonotto

[Martin72]

Hi,

I created a test file for the SDS6000X.

Will you make it available too?

[egonotto]

Hello,

it's the file segments.7z at the very top above the images.

Best regards,
egonotto

[Martin72]

Ah, my old eyes...

[Martin72]

Last for today...

[Fungus]

Not sure why you'd sample at 4GSa/sec with the 20MHz bandwidth limiter on. 

Enable hires mode and it will vanish. 

[Martin72]

Not sure why you'd sample at 4GSa/sec with the 20MHz bandwidth limiter on.

Equal conditions for full, 250Mhz, 20Mhz Limiter...
Without equal conditions, comparisons are meaningless.

[faveri97]

Here are the values for full, 250MHz, and 20MHz, with a 50-ohm input and shielded BNC connector...

This is very strange. I did not recall a noise level well above the specs during the tests with my MHO98.

It turns out that the AC RMS measurement results of the noise floor are possibly not accurate when the time/div is higher than some threshold. I did my tests with 10us/div, and the results are very different.

I repeated the test with this setup in the thread: single channel, 4Gsps, 50Mpts, 1mV/div, 20MHz bandwidth limit, 50-ohm input, BNC connector shielded.

When the time/div is lower or equal to 25us/div (using vernier timebase control), the measured AC RMS noise is around 26uV. However, it jumps to 117uV if the time/div is greater than 25us/div and stays at this level.

Then, I dumped the captured data and calculated the AC RMS values myself. For the 50Mpts data from memory, the calculated AC RMS value is 26uV for both timebase settings. For the 1kpts data form screen, the calculated value is 83uV for 20us/div and 91uV for 50us/div. This can be explained by the "peak-detection" downsampling (creating 1k bins of the captured data for the displayed duration and alternately calculating the minimum and maximum values) of the captured data, which causes a non-linear increase of signal power if aliasing occurs.

In conclusion, I can not reproduce the results of the on-screen measurement function and the results are possibly wrong when time/div is greater than 25us/div. I think this has something to do with the undocumented preprocessing of the captured data before display and measurement.

[smk]

Hi,

Here is a small table showing memory points and the maximum number of frames that can be recorded.

Does your device have 500 MSamples?

No, it only has the standard 100Mpoints, which I can't change because it's not my scope.

With the 500Mpt option there are 4 more settings available: 125Mpt, 200Mpt, 250Mp and 500Mpt.
With these frame sizes a total of 1Gpt of sample memory is available, just like with the 100Mpt and 50Mpt frame sizes.

[2N3055]

Here are the values for full, 250MHz, and 20MHz, with a 50-ohm input and shielded BNC connector...

This is very strange. I did not recall a noise level well above the specs during the tests with my MHO98.

It turns out that the AC RMS measurement results of the noise floor are possibly not accurate when the time/div is higher than some threshold. I did my tests with 10us/div, and the results are very different.

I repeated the test with this setup in the thread: single channel, 4Gsps, 50Mpts, 1mV/div, 20MHz bandwidth limit, 50-ohm input, BNC connector shielded.

When the time/div is lower or equal to 25us/div (using vernier timebase control), the measured AC RMS noise is around 26uV. However, it jumps to 117uV if the time/div is greater than 25us/div and stays at this level.

Then, I dumped the captured data and calculated the AC RMS values myself. For the 50Mpts data from memory, the calculated AC RMS value is 26uV for both timebase settings. For the 1kpts data form screen, the calculated value is 83uV for 20us/div and 91uV for 50us/div. This can be explained by the "peak-detection" downsampling (creating 1k bins of the captured data for the displayed duration and alternately calculating the minimum and maximum values) of the captured data, which causes a non-linear increase of signal power if aliasing occurs.

In conclusion, I can not reproduce the results of the on-screen measurement function and the results are possibly wrong when time/div is greater than 25us/div. I think this has something to do with the undocumented preprocessing of the captured data before display and measurement.

There is a reason why we measure at at least 1ms/DIV.
Time base defines what lowest frequency will exist in a whole capture.
If our whole capture is 500µs long (50µs/div) then, for instance, in that capture there cannot be any signals that have frequency that is lower than what fits into that captured time.
And one single period of low frequency signal will not be enough to reliably estimate how often that low frequency component appears/repeats.
So let's say you need to have at least 10x periods to reliably detect the signal..
That means that you need to have 10ms of data to measure contribution of 100Hz frequency component to some accuracy.
Measuring at 50µs/div means that you are not measuring at all anything less than 2 kHz and you are not measuring right contribution to noise energy on anything less than 10-20kHz..
Hence, when you are doing 20 MHz LPF and by virtue of short time base additionally HPF anything from 1/f region, you are going to have very optimistic noise estimates.
1ms/div proved to be good enough estimate of scope noise performance without being too long timbase. That allows you to run some averages and get good data.

That being said, there might be problem with Stdev measurement itself.
I used to have DS1000Z that had similar problems with RMS measurements and that was the reason I sold it. If I cannot trust the measurements, it is not measurement instrument.

Funny enough, similar problems were reported few years ago at release of new Rigol DHO series, where people also had random large variation in results. I called for deeper investigation then, but was viciously attacked for it. Denial was strong. So I let it be. Maybe this is simply that same problem that was never fixed.

[faveri97]

There is a reason why we measure at at least 1ms/DIV.
Time base defines what lowest frequency will exist in a whole capture.
If our whole capture is 500µs/div (50µs/div) then, for instance, in that capture there cannot be any signals that have frequency that is lower than what fits into that captured time.
And one single period of low frequency signal will not be enough to reliably estimate how often that low frequency component appears/repeats.
So let's say you need to have at least 10x periods to reliably detect the signal..
That means that you need to have 10ms of data to measure contribution of 100Hz frequency component to some accuracy.
Measuring at 50µs/div means that you are not measuring at all anything less than 2 kHz and you are not measuring right contribution to noise energy on anything less than 10-20kHz..
Hence, when you are doing 20 MHz LPF and by virtue of short time base additionally HPF anything from 1/f region, you are going to have very optimistic noise estimates.
1ms/div proved to be good enough estimate of scope noise performance without being too long timbase. That allows you to run some averages and get good data.

That being said, there might be problem with Stdev measurement itself.
I used to have DS1000Z that had similar problems with RMS measurements and that was the reason I sold it. If I cannot trust the measurements, it is not measurement instrument.

Funny enough, similar problems were reported few years ago at release of new Rigol DHO series, where people also had random large variation in results. I called for deeper investigation then, but was viciously attacked for it. Denial was strong. So I let it be. Maybe this is simply that same problem that was never fixed.

True. Noise measurements should be performed with a time window long enough to cover the lower frequencies. The 1/f noise is significantly lower with 50-ohm inputs compared to 1M-ohm inputs, but can still potentially lead to inaccurate results.

For MHO98 (and many other scopes which perform measurements based on the on-screen data or otherwise preprocessed data), the measurement results can not be trusted especially when there is heavy downsampling involved during the calculation. I think it can be done right but clearly MHO98 did not.

With these precautions in mind, I measured the AC RMS noise level of MHO98 with the following test setup: single channel, 4Gsps, 500Mpts (125ms), 1mV/div, 50-ohm input, BNC connector shielded, AC RMS calculated on the dumped 500Mpts data from memory.

• Full bandwidth: 120.3uV
• 250MHz bandwidth: 51.0uV
• 20MHz bandwidth: 26.2uV

The results are within the specs.

[2N3055]

...
With these precautions in mind, I measured the AC RMS noise level of MHO98 with the following test setup: single channel, 4Gsps, 500Mpts (125ms), 1mV/div, 50-ohm input, BNC connector shielded, AC RMS calculated on the dumped 500Mpts data from memory.

• Full bandwidth: 120.3uV
• 250MHz bandwidth: 51.0uV
• 20MHz bandwidth: 26.2uV

The results are within the specs.

And these numbers seem realistic.

[Fungus]

I used to have DS1000Z that had similar problems with RMS measurements and that was the reason I sold it.

The DS1000Z did all measurements "on screen" with 1200 data points, it was easy to fool the system or find a pathological capture.

If I cannot trust the measurements, it is not measurement instrument.

I think you'll find a lot of dissent on whether or not an oscilloscope is a "measurement instrument". Most of them have measurement specs in the +/-5% range.