Rigol MHO900 Test/Review (MHO954/984)

[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.

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.

I didn't say you are retard.

I said you are deluded as to Rigol's motives as why software is bad.
It is not because scope is so cheap they could not afford better developers. Go look the size of that company...
I explained what I meant.

But you decided it is about fanboying. It is you that wants to be insulted so you can claim I am not to be listened because I have an agenda. In this case agenda is all on your side. And high school mentality. Now get insulted.

I said numerous times before that if people accept all software deficiencies and all they need is one channel 1GHz BW they have no other choice than this scope.
But it is not a good scope by any measure, it is very hit and miss scope with 1GHz BW and price that is not so high.
If you like it and it does the work for you, I am happy.

[norbert.kiszka]

In DHO800/900 default settings makes lowest visible noise - I wonder why.

2 us/div, 50 mV/div and 10 kpts.

[2N3055]

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.

To me it might even look like that measurement is OK and that the actual capture is noisy. Could it be that some filtering they do inside  does not work reliably software vise. That would be good news because it is fixable.
They seem to do a lot "behind the scene" digital filtering and noise shaping. Those can be clever tricks, and can work well but need to be meticulously made and debugged.

[norbert.kiszka]

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.

To me it might even look like that measurement is OK and that the actual capture is noisy. Could it be that some filtering they do inside  does not work reliably software vise. That would be good news because it is fixable.
They seem to do a lot "behind the scene" digital filtering and noise shaping. Those can be clever tricks, and can work well but need to be meticulously made and debugged.

FPGA does acquisitions of those 1000 points and later app does rendering via OpenGL in GPU like in a computer game. Which makes it more efficient, but it's not necessarily the best option for debugging devices.

OpenGL is not my specialization, but in my mod for DHO800/900 (enterprise edition only) I did "fast" and "slow" acquisition modes. This only changes timings between acquisition and rendering. First one, beside of more waveform updates per second, gives much more visible noise. Second one makes waveform rendering more "nice" for the eye.

[2N3055]

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.

To me it might even look like that measurement is OK and that the actual capture is noisy. Could it be that some filtering they do inside  does not work reliably software vise. That would be good news because it is fixable.
They seem to do a lot "behind the scene" digital filtering and noise shaping. Those can be clever tricks, and can work well but need to be meticulously made and debugged.

FPGA does acquisitions of those 1000 points and later app does rendering via OpenGL in GPU like in a computer game. Which makes it more efficient, but it's not necessarily the best option for debugging devices.

OpenGL is not my specialization, but in my mod for DHO800/900 (enterprise edition only) I did "fast" and "slow" acquisition modes. This only changes timings between acquisition and rendering. First one, beside of more waveform updates per second, gives much more visible noise. Second one makes waveform rendering more "nice" for the eye.

I am referring to part of acquisition before they decimate for screen in FPGA. But still able to fix if problems are there.

[rpro]

On the topic of measurement windows,

In the time domain, my DHO804 (and I'd suspect the MHOs do the same) seems to be taking the "raw" subset of the data in memory that corresponds to the span of the (postprocessed) 1000 points shown on the screen and computes the AC-RMS using the raw data. As an example, below I show 3 pics. The first pic shows (part of) a waveform, that is stored in 1M of memory. The measurements panel shows on the scope an AC-RMS of 138.22 mV. 

1. If you take the full buffer (using  ":STOP;:WAVeform:SOUR CHAN1;:WAVeform:MODE RAW;:WAVeform:FORM ASCii" to get it from the scope via SCPI) the stdev is 158.22 mV.

2. If you use the 1000 points being displayed (using "NORM" instead of "RAW" in the SCPI command) you get 212.12 mV.

3. 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 constructed an arb waveform with lots of opportunities to measure the wrong AC-RMS with a 1000 points....In the other 2 pics below, you can see the whole saved waveform (as represented by the (aliasing) display) and a pic with more detail.

 Edit: Failed to upload the first picture. "HalfWaveForm.png".

[Martin72]

To me it might even look like that measurement is OK and that the actual capture is noisy. Could it be that some filtering they do inside  does not work reliably software vise. That would be good news because it is fixable.
They seem to do a lot "behind the scene" digital filtering and noise shaping. Those can be clever tricks, and can work well but need to be meticulously made and debugged.

I have now written to support asking how the values on pages 9 and 10 of the data sheet were arrived at, i.e., under what conditions they were recorded.
Let's see if and what they reply.

[norbert.kiszka]

NOTE: This message has been deleted by the forum moderator Simon for being against the forum rules and/or at the discretion of the moderator as being in the best interests of the forum community and the nature of the thread.
If you believe this to be in error, please contact the moderator involved.
An optional additional explanation is:

[PCK]

I didn't say you are retard.

I said you are deluded as to Rigol's motives as why software is bad.
It is not because scope is so cheap they could not afford better developers. Go look the size of that company...
I explained what I meant.

You don't call someone delusional and then try and gaslight by saying it's okay because you did n't say retard.  Maybe in your country calling someone delusional is not regarded as an insult but I'm sorry it is an insult.

Software quality has nothing to do with size of the company and whether "they can afford it", if that was the case then Microsofts and other multi-billion dollary companies products that I have to deal with on a daily basis would n't be so buggy.

Rigol are not actually a huge company. Software quality has more to do with company culture, existing code base and management rather just pure programing, hiring more programmers tommorrow is n't going to all of a sudden make their software problems go away. Most companies are not run by engineers, it's not a conspiracy where they sit around a table and decide "yeah, lets just make more money by scrimping back on the programmers". 

But you decided it is about fanboying. It is you that wants to be insulted so you can claim I am not to be listened because I have an agenda. In this case agenda is all on your side. And high school mentality. Now get insulted.

It is fanboying, because it seems like you really like pushing the point Rigol are making a consious descision to make the rubbish software just to screw over thier customers.  Have you been inside a new VW car recently, I suppose they choose to make rubbish software too? I don't see non Siglent/Rigol users having these ridiculous arguments. 

I said numerous times before that if people accept all software deficiencies and all they need is one channel 1GHz BW they have no other choice than this scope.

Not in this conversation with me you did n't.

But it is not a good scope by any measure, it is very hit and miss scope with 1GHz BW and price that is not so high.

You are contradicting yourself, it is a very good scope when it comes to bandwidth for the price, you've literally just said that yourself and that is the point I keep on trying to make - this is what I mean by about fanboyism, I'm sorry if it is not your intention but that is how it comes over.

If you like it and it does the work for you, I am happy.

I don't like or dislike it, it's just a tool, I'm just trying to figure out if it does what I need it to do.

[PCK]

3. 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)...

How are you calculating the std dev?  The difference could easily be the case of 32 bit floats vs 64 bit floats, especially with that many data points.

[PCK]

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?

[rpro]

3. 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)...

How are you calculating the std dev?  The difference could easily be the case of 32 bit floats vs 64 bit floats, especially with that many data points.

I am using NumPy in python. (By default, NumPy uses float64 (IEEE 754 double precision) for floating-point operations.) 

[PCK]

3. 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)...

How are you calculating the std dev?  The difference could easily be the case of 32 bit floats vs 64 bit floats, especially with that many data points.

I am using NumPy in python. (By default, NumPy uses float64 (IEEE 754 double precision) for floating-point operations.)

Unfortunately I don't think you can force NumPy to use float32 for the actual calculation.  But you can test this by trying smaller and larger number of points, the % error will increase as the number of points increases.

[rpro]

3. 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)...

How are you calculating the std dev?  The difference could easily be the case of 32 bit floats vs 64 bit floats, especially with that many data points.

I am using NumPy in python. (By default, NumPy uses float64 (IEEE 754 double precision) for floating-point operations.)

Unfortunately I don't think you can force NumPy to use float32 for the actual calculation.  But you can test this by trying smaller and larger number of points, the % error will increase as the number of points increases.

Well, yes you can (using dtype=np.float32, since all math functions in NumPy — like np.sqrt, np.var, etc. — also preserve the array’s dtype), but that didn't help... You essentially get the same answer I showed, 137.73mV. (137.73426 vs 137.73425369387687 to be precise...) .  There is probably a conversion/transformation somewhere that could be improved, but I am ok with a 0.49 mV discrepancy on the scale of a 1Vpp signal....as long as it is using the relevant data collected in memory for measurements, and not just the 1000 points...

[PCK]

3. 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)...

How are you calculating the std dev?  The difference could easily be the case of 32 bit floats vs 64 bit floats, especially with that many data points.

I am using NumPy in python. (By default, NumPy uses float64 (IEEE 754 double precision) for floating-point operations.)

Unfortunately I don't think you can force NumPy to use float32 for the actual calculation.  But you can test this by trying smaller and larger number of points, the % error will increase as the number of points increases.

Well, yes you can (using dtype=np.float32, since all math functions in NumPy — like np.sqrt, np.var, etc. — also preserve the array’s dtype), but that didn't help... You essentially get the same answer I showed, 137.73mV. (137.73426 vs 137.73425369387687 to be precise...) .  There is probably a conversion/transformation somewhere that could be improved, but I am ok with a 0.49 mV discrepancy on the scale of a 1Vpp signal....as long as it is using the relevant data collected in memory for measurements, and not just the 1000 points...

Hmm, I've had descrepencies with NumPy and raw C code in the past so that is not surprising.  There are also situations where if can enable certain optimisations for speed if you don't care about being 100% IEEE compliant, especially when generating vector code.  I don't actually have this scope so cant do the test myself, but as you've said main point is that it's not using screeen data which is good to know.

[2N3055]

I didn't say you are retard.

I said you are deluded as to Rigol's motives as why software is bad.
It is not because scope is so cheap they could not afford better developers. Go look the size of that company...
I explained what I meant.

You don't call someone delusional and then try and gaslight by saying it's okay because you did n't say retard.  Maybe in your country calling someone delusional is not regarded as an insult but I'm sorry it is an insult.

I never thought I would have to explain English to someone from UK, but here it is.

I said you are " deluded about the topic". Which means "holding a false belief against the evidence."
I did not say you are "delusional", which is a mental disorder.

I would not say that because
a:) I don't know you and have no knowledge of your mental health and am not mental health professional.
and
b:) if I actually you knew you actually have mental disorder, than I would actively avoid talking about that. It would be like making fun of disabled person. Horrible.
In which case I would be very polite and not argue..

On that topic, if by any means you took it as I wanted to say to you that "you are delusional" as in "crazy", it was not my intention and if I caused you grief by that misunderstanding, I hereby apologize.

As for the rest I do not contradict myself.
Things can be horrible, good at single thing and still put a smile on people faces if they don't know better or cannot afford anything better.
That does not mean they are great. They only have to be just good enough.

As a comparison, I remember the infamous Yugo. Engine was actually reliable. Gearbox was like fighting the trolls but lasted long time. Change of clutch was 45 minutes. Handles to open the door were made of cheap thin plastic, and would break every six months. They were cheap to buy and easy to change (one screw).
I had toolbox in a booth.  Still, I was young, I had a CAR and life was GOOD. Loved the wretched thing. It was enabler that opened new world for me, no matter how flawed it was. And with a little help from my friends it was actually quite fast for the era (Carlo Abarth actually learned his trade in my hometown, tradition is still there). Realistically, it was a horrible car. Except the speed and that it was a CAR.

[faveri97]

I performed power spectral density estimation of the noise based on the exported .bin data of my MHO98.

My observations:

• The AC RMS numbers are all within the specifications.
• The noise floor is relatively clean up to 200MHz.
• 1/f noise is very prevalent with 1MOhm inputs. It is also clearly visible in the time domain.
• There is obvious digital filtering under full bandwidth and 250MHz bandwidth conditions.
• Overall noise performance is slightly worse than DHO900 which is again worse than DHO4000. Not sure about this one until I have access to my DHO900 again to get the plots...

[Martin72]

I have now written to support asking how the values on pages 9 and 10 of the data sheet were arrived at, i.e., under what conditions they were recorded.
Let's see if and what they reply.

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.

[norbert.kiszka]

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.

[norbert.kiszka]

There is obvious digital filtering under full bandwidth and 250MHz bandwidth conditions.

I think both AFE and ADC has bandwidth of around 1 GHz. Between those two there are two stages of LC filters - I guess it's also around 1 GHz.

In the function (software part in app) which sets up filters (20 MHz, 250 MHz, 350 MHz, 500 MHz, 800 MHz and full), likely it set up filters in AFE and ADC only - I didn't noticed any software filters, beside hi-res, which is not available in every model (but it can have support in FPGA firmware).

[faveri97]

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.

It is unlikely for the FFT function to be able to utilize only the resampled 1kpts data. The specifications say it is 1Mpts (actually it is the closest power of 2, 1048576) maximum, and you can tell from the resolution of the FFT results. The number of FFT points and the sampling rate of the analyzed data are displayed in the caption. The sampling rate of the analyzed data can differ from the main acquisition, though.

However, it is very likely that the FFT results are resampled to 1kpts before displaying them on the screen and performing post-processing functions like peak search. It also uses the "peak detection" downsampling method as seen in the normal waveforms. The consequences are clear if the color grading function is turned on for the FFT results. If the number of FFT points is greater than 1000, you can see two noise floors with different amplitude levels. I think the more meaningful way to implement FFT color grading is to accumulate the results before resampling, like how SDS800X HD and many other scopes do.

[PCK]

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.

I meant the buffer that supplies the displayed data, as opposed to the interpolation on  the sample buffer thats why I was confused by your original reply.  From what I understand rpro is talking about "run" vs "stop" displayed values.  It seems that the there is a small discrepency between the scopes calc and using a PC to do the calc, but less than 0.5%.

[PCK]

I didn't say you are retard.

I said you are deluded as to Rigol's motives as why software is bad.
It is not because scope is so cheap they could not afford better developers. Go look the size of that company...
I explained what I meant.

You don't call someone delusional and then try and gaslight by saying it's okay because you did n't say retard.  Maybe in your country calling someone delusional is not regarded as an insult but I'm sorry it is an insult.

I never thought I would have to explain English to someone from UK, but here it is.

I said you are " deluded about the topic". Which means "holding a false belief against the evidence."
I did not say you are "delusional", which is a mental disorder.

I would not say that because
a:) I don't know you and have no knowledge of your mental health and am not mental health professional.
and
b:) if I actually you knew you actually have mental disorder, than I would actively avoid talking about that. It would be like making fun of disabled person. Horrible.
In which case I would be very polite and not argue..

On that topic, if by any means you took it as I wanted to say to you that "you are delusional" as in "crazy", it was not my intention and if I caused you grief by that misunderstanding, I hereby apologize.

As for the rest I do not contradict myself.
Things can be horrible, good at single thing and still put a smile on people faces if they don't know better or cannot afford anything better.
That does not mean they are great. They only have to be just good enough.

As a comparison, I remember the infamous Yugo. Engine was actually reliable. Gearbox was like fighting the trolls but lasted long time. Change of clutch was 45 minutes. Handles to open the door were made of cheap thin plastic, and would break every six months. They were cheap to buy and easy to change (one screw).
I had toolbox in a booth.  Still, I was young, I had a CAR and life was GOOD. Loved the wretched thing. It was enabler that opened new world for me, no matter how flawed it was. And with a little help from my friends it was actually quite fast for the era (Carlo Abarth actually learned his trade in my hometown, tradition is still there). Realistically, it was a horrible car. Except the speed and that it was a CAR.

Obviously things got heated, there is no point of arguing over silly things like a scope but just a few things to clarify in calm manner and close this off.

In this context "delusional" just means "extremely deluded" in a hyperbolic way, it does n't mean mentally ill and the same vein "being delusional" also does n't mean being mentally ill, "delusional" is hardly ever used as medical term in normal conversion even though it's origins are medial.  However, by calling someone deluded you are saying they are incapable of rational thought, at which point the conversation becomes "ad hominem" and by the same token I should n't have called you a "fanboy", that was a mistake on my behalf.

I think what you mean is that the scope is "unbalanced" and I agree, but I don't think it is rational to call it a "bad" scope.  The proper car anology is a 80's Ferrari, yes it goes fast but it has lots of other limitations, but it's not a "bad" car.

[norbert.kiszka]

Beside of my hate pointed into Rigol company (multiple times stealing somebody code without giving a sh*t to terms and conditions in its licenses), they do quite good hardware for the price. In the same time, their firmware is a joke.

[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.