Rigol MHO900 Test/Review (MHO954/984)

[voltsandjolts]

Can you show the software you used to retrieve data and calculate results, so others can test in same exact way?
Thanks.

[Fungus]

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.

I'd believe those numbers.

My DHO800 does full-memory measurements/decodes on undecimated data only when you're in zoom mode. You have to zoom out to get maximum memory then turn on zoom. It's a lot slower update rate for the values.

I imagine the MHO900 does the same.

What happens if you do that on an MHO98? Do you get the values shown above?

[faveri97]

Can you show the software you used to retrieve data and calculate results, so others can test in same exact way?
Thanks.

I'm using a proprietary software (Mathematica) to do the calculations. But this should also be easily done using other solutions.

• Save the single-channel captured data in the .bin format.
• Import the file as an array of 32-bit floating point numbers and discard the first 43 elements (header information).
• Calculate the standard deviation of the remaining data. The result is in Volts.

I'd believe those numbers.

My DHO800 does full-memory measurements/decodes on undecimated data only when you're in zoom mode. You have to zoom out to get maximum memory then turn on zoom. It's a lot slower update rate for the values.

I imagine the MHO900 does the same.

What happens if you do that on an MHO98? Do you get the values shown above?

No. I still get the wrong results if the time/div is large enough no matter the measurement region is "Main" or "Zoom". As a sidenote, they introduced a new measurement region "Cursor", allowing gated measurements between two cursors. However, it does not seem to work in the zoom mode.

After some usage of the scope, I suddenly found that the measurements are showing the correct ~26uV value. I rebooted the scope and it's around 46uV again. I can not get the 117uV as in the posted screenshot anymore. I found that removing and re-adding the measurement item fixes the problem. There is definitely some bugs going on.

[2N3055]

After some usage of the scope, I suddenly found that the measurements are showing the correct ~26uV value. I rebooted the scope and it's around 46uV again. I can not get the 117uV as in the posted screenshot anymore. I found that removing and re-adding the measurement item fixes the problem. There is definitely some bugs going on.

That definitely sounds like an original bug I was talking about that was reported back then on DHO800...

[PCK]

I wonder how rigol are doing the calculations?

Although the ARM cores support 64bit floats, 32bit floating point is still faster on these CPUs plus NEON SIMD also only supports 32-bit floats.  It may be that they implemented the calculations using 32-bit floats for faster updates, however with 32bit floating point with large datasets you are going to run into accuracy problems.

Ideally you have two implementations one where you use 32 bit small data sets and another 64 bit implementation for large data sets (millions of data points).

Just speculation, it could be that everything is coded with 64-bit floats and it's just other non-numerical bugs.

[Martin72]

Incorrect measurements, incorrect values...
When I look at the first image from Reply26, where the noise is almost as thick as a finger, then the 280 micro volts measured there are probably correct.

[norbert.kiszka]

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.

From my reverse engineering (probably all Rigol scopes uses exact same scope app with some changes - they don't make new ones):

ADC Phase - as the name suggests, it's probably phase shift between ADCs.

Data line - line between ADC and FPGA is LVDS for 99.9%

AFE Zero - no idea. It sounds like a thing we call as a "DC offset", but checkboxes with channel number are doing that.

ADC Gain - I think this is selected by default. It calibrates gain, because even if You have perfectly calibrated offsets, still You can see 0.5 V being measured as a 1 V...

Speaking about the last one. I have modified DHO924S. Beside of removed LC filters in one channel (and couple more things), I changed termination resistors 2x35ohm+1x85ohm to the 2x25ohm+50ohm. After that change, not only I had different offset (which was not consistent when I changed sensitivity) but also gain was very wrong. After self-cal with default settings it was perfectly normal as it was before - beside of the little lower overshots and little lower noise.

[PCK]

My DHO800 does full-memory measurements/decodes on undecimated data only when you're in zoom mode. You have to zoom out to get maximum memory then turn on zoom. It's a lot slower update rate for the values.

For 500 megapoints, assuming 20 cycles per point and assuming the faster 2Ghz core it would take 5 seconds to do the calculation.

[norbert.kiszka]

I wonder how rigol are doing the calculations?

Although the ARM cores support 64bit floats, 32bit floating point is still faster on these CPUs plus NEON SIMD also only supports 32-bit floats.  It may be that they implemented the calculations using 32-bit floats for faster updates, however with 32bit floating point with large datasets you are going to run into accuracy problems.

Ideally you have two implementations one where you use 32 bit small data sets and another 64 bit implementation for large data sets (millions of data points).

Just speculation, it could be that everything is coded with 64-bit floats and it's just other non-numerical bugs.

They used both float vars and double vars. Neon instructions are used a lot, but likely it was all done by the compiler (Clang, not GCC). They never used compiler optimizations enabled in their firmwares... Im almost sure that they don't know about that thing.

Whole thing was coded by multiple people for sure. And for sure most of them barely knows how to make a (good) code.

[PCK]

They used both float vars and double vars. Neon instructions are used a lot, but likely it was all done by the compiler (Clang, not GCC). They never used compiler optimizations enabled in their firmwares... Im almost sure that they don't know about that thing.

Whole thing was coded by multiple people for sure. And for sure most of them barely knows how to make a (good) code.

Again this is speculation but knowing how code is written, they probably have legacy code to do the calculations from older scopes when CPU power was limited and the number of data points was never this large so was written with 32bit floats - which for the general use case, even for this scope is fine.

Without ranting, most code these days is terrible when it comes to performance because new programmers have never needed to code in a resource constrained environment.  Plus quality programmers are expensive, I don't blame Rigol since cheaper scope = cheaper programers. 

However you see bugs in higher end scopes too and I find software in general has become worse and will probably get even more worse when you replace programmers with AI generated code.

[mawyatt]

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.

Maybe not a "reference measurement instrument" like a quality DMM, but many are using these newer DSOs for "measurements". Look at how folks are quoting and comparing things like AC rms noise, noise floor, bandwidth, signal level, distortion/harmonic level and so on, and many DSOs have built-in Self-Cal which improves these point-of-use measurements.

Then you have the FFT, Bode (FRA), Counter, DVM, Power Analysis, and so on features, all of which rely on some form of "measurement".  We often compare our DSOs to what we consider our in-house "reference measurement instruments" just for sanity checks before any serious "measurements".

We've found that a quality DMM (KS34465A, DMM6500), and modern good AWG (SDG2042X, SDG6022X) and a inexpensive GPSDO (BH3SAP) as good enough "measurement reference sources" for checking up on our in-house DSOs.

Anyway, the +-5% seems conservative for most "measurements", and of course depends on the "measurement'" task performed.

Best

[norbert.kiszka]

They used both float vars and double vars. Neon instructions are used a lot, but likely it was all done by the compiler (Clang, not GCC). They never used compiler optimizations enabled in their firmwares... Im almost sure that they don't know about that thing.

Whole thing was coded by multiple people for sure. And for sure most of them barely knows how to make a (good) code.

Again this is speculation but knowing how code is written, they probably have legacy code to do the calculations from older scopes when CPU power was limited and the number of data points was never this large so was written with 32bit floats - which for the general use case, even for this scope is fine.

Without ranting, most code these days is terrible when it comes to performance because new programmers have never needed to code in a resource constrained environment.  Plus quality programmers are expensive, I don't blame Rigol since cheaper scope = cheaper programers. 

However you see bugs in higher end scopes too and I find software in general has become worse and will probably get even more worse when you replace programmers with AI generated code.

As some people say:

Everything is open source if You can read Assembly.

I spent many months with reverse engineer Rigol firmware. OS, drivers for the Rigol devices, PLL and the app.

Try to figure out how I did 4-5 times more memory depth in four Rigol scope series and how I created completely different OS for two of them.

[Fungus]

Frequency measurements (including FFT peaks) should be accurate - this is a time-domain instrument.

Voltage measurements? Less so.

When it comes to voltage: I view it mainly as a "ballpark range" device that lets me see if things get better or worse as I modify a circuit. ie. Precision over accuracy.

[norbert.kiszka]

My DHO800 does full-memory measurements/decodes on undecimated data only when you're in zoom mode. You have to zoom out to get maximum memory then turn on zoom. It's a lot slower update rate for the values.

I think this is a very wrong assumption.

DHO4000, DHO1000, DHO800, DHO900 and MHO900 does acquisitions both in FPGA and in CPU. On the FPGA side it makes as mach samples as it was set in the app. But... from those samples, it creates another points, exactly 1000 of them (even if the app requested less than 1 kpts - it's interpolated by the FPGA) - for what You see on the screen.

All measurements uses those "screen" 1000 points.

You don't need to decompile the code to know it's very very bad. They did this with one idea - just make it work.

Turn on the "Indicator" in some measurements and You will figure out this very quickly. For example rise time uses data from other measurements, which is "Vupper", "Vmid" and "Vlower" - which does very bad job. Try to change "%" to "Abs" in the settings, put manually calculated values (90%, 50% and 10%) and You will see huge difference.

[2N3055]

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.

Maybe not a "reference measurement instrument" like a quality DMM, but many are using these newer DSOs for "measurements". Look at how folks are quoting and comparing things like AC rms noise, noise floor, bandwidth, signal level, distortion/harmonic level and so on, and many DSOs have built-in Self-Cal which improves these point-of-use measurements.

Then you have the FFT, Bode (FRA), Counter, DVM, Power Analysis, and so on features, all of which rely on some form of "measurement".  We often compare our DSOs to what we consider our in-house "reference measurement instruments" just for sanity checks before any serious "measurements".

We've found that a quality DMM (KS34465A, DMM6500), and modern good AWG (SDG2042X, SDG6022X) and a inexpensive GPSDO (BH3SAP) as good enough "measurement reference sources" for checking up on our in-house DSOs.

Anyway, the +-5% seems conservative for most "measurements", and of course depends on the "measurement'" task performed.

Best

I didn't respond because I find that statement "Most of them have measurement specs in the +/-5% range." wrong both in definition and values.
If we are talking about timing and timing measurements, we are talking about 10-20ppm timebase accuracy in cheapest serious scope easily.
I have several scopes with relative timing accurate to single digit ps values, with time bases with 2-3ppm accuracy, and one with OCXO with sub ppm accuracy.
DC accuracies are in 1,5 - 3% level. etc..
As for BW flatness that is expressed in dB.

So yeah, if I can for the same money to get instrument that will measure dozens of parameters, and do it right, I will take that one before one that can only show same thing as CRT scope with cursor measurement. But that is me. Other people do their own thing.

[2N3055]

My DHO800 does full-memory measurements/decodes on undecimated data only when you're in zoom mode. You have to zoom out to get maximum memory then turn on zoom. It's a lot slower update rate for the values.

I think this is a very wrong assumption.

DHO4000, DHO1000, DHO800, DHO900 and MHO900 does acquisitions both in FPGA and in CPU. On the FPGA side it makes as mach samples as it was set in the app. But... from those samples, it creates another points, exactly 1000 of them (even if the app requested less than 1 kpts - it's interpolated by the FPGA) - for what You see on the screen.

All measurements uses those "screen" 1000 points.

You don't need to decompile the code to know it's very very bad. They did this with one idea - just make it work.

Turn on the "Indicator" in some measurements and You will figure out this very quickly. For example rise time uses data from other measurements, which is "Vupper", "Vmid" and "Vlower" - which does very bad job. Try to change "%" to "Abs" in the settings, put manually calculated values (90%, 50% and 10%) and You will see huge difference.

Norbert, are you sure it does that exactly?
I ask because that was EXACTLY what they did on DS1000Z.

[norbert.kiszka]

My DHO800 does full-memory measurements/decodes on undecimated data only when you're in zoom mode. You have to zoom out to get maximum memory then turn on zoom. It's a lot slower update rate for the values.

I think this is a very wrong assumption.

DHO4000, DHO1000, DHO800, DHO900 and MHO900 does acquisitions both in FPGA and in CPU. On the FPGA side it makes as mach samples as it was set in the app. But... from those samples, it creates another points, exactly 1000 of them (even if the app requested less than 1 kpts - it's interpolated by the FPGA) - for what You see on the screen.

All measurements uses those "screen" 1000 points.

You don't need to decompile the code to know it's very very bad. They did this with one idea - just make it work.

Turn on the "Indicator" in some measurements and You will figure out this very quickly. For example rise time uses data from other measurements, which is "Vupper", "Vmid" and "Vlower" - which does very bad job. Try to change "%" to "Abs" in the settings, put manually calculated values (90%, 50% and 10%) and You will see huge difference.

Norbert, are you sure it does that exactly?
I ask because that was EXACTLY what they did on DS1000Z.

Im sure for 1000%.

In the second attachment, You can see changed "RIGOL.SCOPE" to the "NK.SCOPE". If somebody want's to know why I did this: I did this because I can.

[gf]

My DHO800 does full-memory measurements/decodes on undecimated data only when you're in zoom mode. You have to zoom out to get maximum memory then turn on zoom. It's a lot slower update rate for the values.

I think this is a very wrong assumption.

DHO4000, DHO1000, DHO800, DHO900 and MHO900 does acquisitions both in FPGA and in CPU. On the FPGA side it makes as mach samples as it was set in the app. But... from those samples, it creates another points, exactly 1000 of them (even if the app requested less than 1 kpts - it's interpolated by the FPGA) - for what You see on the screen.

All measurements uses those "screen" 1000 points.

You don't need to decompile the code to know it's very very bad. They did this with one idea - just make it work.

Turn on the "Indicator" in some measurements and You will figure out this very quickly. For example rise time uses data from other measurements, which is "Vupper", "Vmid" and "Vlower" - which does very bad job. Try to change "%" to "Abs" in the settings, put manually calculated values (90%, 50% and 10%) and You will see huge difference.

Norbert, are you sure it does that exactly?
I ask because that was EXACTLY what they did on DS1000Z.

Im sure for 1000%.

In the second attachment, You can see changed "RIGOL.SCOPE" to the "NK.SCOPE". If somebody want's to know why I did this: I did this because I can.

Does it mean that the app never accesses the captured samples directly?
What about FFT? Is it calculated in the FPGA as well, and only for the 1000 screen points?

[PCK]

So yeah, if I can for the same money to get instrument that will measure dozens of parameters, and do it right, I will take that one before one that can only show same thing as CRT scope with cursor measurement. But that is me. Other people do their own thing.

Any scope is working on what it can "see" anyway, if there is stuff going on outside its bandwidth how accurate is it really?  I think most people will use this as a 1 channel high bandwidth scope for those times when you need it, it also functions as a reasonable spectrum analyser. 

The hardware seems fine, but as ever software is the problem but I think hardware people don't realise how expensive *good* niche software developers are, so as ever you get what you pay for.  At least you can export the data and to do accurate calculations, but if you're doing this often you then need to make a value judgement of the cost of your time vs a more expensive scope.

[PCK]

Does it mean that the app never accesses the captured samples directly?
What about FFT? Is it calculated in the FPGA as well, and only for the 1000 screen points?

It's in the manual max points for FFT is 1 Mpts .

[norbert.kiszka]

If You try to test like 12 MHz square wave with different time base settings and manual memory depth, it looks like FFT is using screen points only. At least in DHO800/900.

[2N3055]

So yeah, if I can for the same money to get instrument that will measure dozens of parameters, and do it right, I will take that one before one that can only show same thing as CRT scope with cursor measurement. But that is me. Other people do their own thing.

Any scope is working on what it can "see" anyway, if there is stuff going on outside its bandwidth how accurate is it really?  I think most people will use this as a 1 channel high bandwidth scope for those times when you need it, it also functions as a reasonable spectrum analyser. 

The hardware seems fine, but as ever software is the problem but I think hardware people don't realise how expensive *good* niche software developers are, so as ever you get what you pay for.  At least you can export the data and to do accurate calculations, but if you're doing this often you then need to make a value judgement of the cost of your time vs a more expensive scope.

I don't understand. I am talking that when scope gets 10 Mpoints it can measure on all that. Not on 1000 point decimated for screen. Siglent scopes also process only time interval that is on screen. But it samples 10Mpoint and calculates Stdev (AC RMS) on all that. With high accuracy. For screen it separately decimate for screen only.
And other companies make also inexpensive scopes (cheaper than this one) that measure correctly. How they can get good software?

You are deluded. Rigol is the company that deliberately does this. It saves on software to extract profit there. Counting on people to not expect much because cheap.

[PCK]

So yeah, if I can for the same money to get instrument that will measure dozens of parameters, and do it right, I will take that one before one that can only show same thing as CRT scope with cursor measurement. But that is me. Other people do their own thing.

Any scope is working on what it can "see" anyway, if there is stuff going on outside its bandwidth how accurate is it really?  I think most people will use this as a 1 channel high bandwidth scope for those times when you need it, it also functions as a reasonable spectrum analyser. 

The hardware seems fine, but as ever software is the problem but I think hardware people don't realise how expensive *good* niche software developers are, so as ever you get what you pay for.  At least you can export the data and to do accurate calculations, but if you're doing this often you then need to make a value judgement of the cost of your time vs a more expensive scope.

I don't understand. I am talking that when scope gets 10 Mpoints it can measure on all that. Not on 1000 point decimated for screen. Siglent scopes also process only time interval that is on screen. But it samples 10Mpoint and calculates Stdev (AC RMS) on all that. With high accuracy. For screen it separately decimate for screen only.
And other companies make also inexpensive scopes (cheaper than this one) that measure correctly. How they can get good software?

You are deluded. Rigol is the company that deliberately does this. It saves on software to extract profit there. Counting on people to not expect much because cheap.

Why does everyone resort to insults on this site? How old are you? We are not in the school yard arguing about which console is best.  I don't care about the stupid Siglent/Rigol riverally here.

My point was about why someone would be interested in this with its limitations.  The sole reason for buying this scope is the bandwidth because at the end of the day your calculation over 10Mpoints is going to be useless if your signal has been attenuated due to lack of bandwidth.  The 350Mhz version of this scope for example is a terrible value proposition.

If you don't need the bandwidth then just buy another scope which matches your needs, if you cant live with the software limitations but need the bandwidth expect to pay much much more, it's pretty simple. 

[norbert.kiszka]

So yeah, if I can for the same money to get instrument that will measure dozens of parameters, and do it right, I will take that one before one that can only show same thing as CRT scope with cursor measurement. But that is me. Other people do their own thing.

Any scope is working on what it can "see" anyway, if there is stuff going on outside its bandwidth how accurate is it really?  I think most people will use this as a 1 channel high bandwidth scope for those times when you need it, it also functions as a reasonable spectrum analyser. 

The hardware seems fine, but as ever software is the problem but I think hardware people don't realise how expensive *good* niche software developers are, so as ever you get what you pay for.  At least you can export the data and to do accurate calculations, but if you're doing this often you then need to make a value judgement of the cost of your time vs a more expensive scope.

I don't understand. I am talking that when scope gets 10 Mpoints it can measure on all that. Not on 1000 point decimated for screen. Siglent scopes also process only time interval that is on screen. But it samples 10Mpoint and calculates Stdev (AC RMS) on all that. With high accuracy. For screen it separately decimate for screen only.
And other companies make also inexpensive scopes (cheaper than this one) that measure correctly. How they can get good software?

You are deluded. Rigol is the company that deliberately does this. It saves on software to extract profit there. Counting on people to not expect much because cheap.

Good software requires proper design (pure thinking how to do things), proper selection of used languages, properly chosen OS, properly chosen compiler, properly set compiler flags, proper and clean code and proper tests. What I personally see, Rigol didn't made any of those.

I was going to hack MSO900 app, to make 1 GHz for every model (and one more feature), then add some features into my existing mod of DHO800/900 and after that I have a plan to make a new app, partially from scratch - by linking existing .so lib - just to make a faster and easier start.

About two days ago, I needed to dump some data which was sent from the app to UART (in DHO1000/4000), but it was difficult to do this on my scope, so... believe or not, I linked this lib with a very short C code and it was working properly on my laptop - with ARMv8 emulation.

Before I do hacks for this MHO900 I need to fix my own scope first... Looks like everybody has hardware related problems with Rigol scopes - soon or later.

[Martin72]

Hi,
There have been so many posts here that I've lost track...
I took another picture, using the same settings as before, and the measurement is 280µV, just like before.
If you use the cursors, they show the same thing.
So this noise floor would be significantly above the specification in the datasheet and poor in general.
Or is the rigol displaying something “wrong” and therefore measuring something wrong? That's the thread I somehow lost after two pages of new posts.