EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: Martin72 on November 02, 2025, 09:13:25 pm
-
Hi,
As announced, here is a dedicated thread for the Rigol MHO984, as the results are slowly but surely getting lost in the general thread.
Basically, I am testing the MHO900 series here, which only differ in terms of bandwidth.
To avoid writing everything again here, here are the links to the corresponding posts.
Arrival and first impressions (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6077007/#msg6077007)
Risetime/Samplerate/Intensity Grading (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6079343/#msg6079343)
Bandwith Measures via FFT Peak Hold (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6080453/#msg6080453)
Fixed Bandwiths 20/250Mhz (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6080557/#msg6080557)
Video of the Fan Noise (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6082185/#msg6082185)
Hidden Testmode (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6082221/#msg6082221)
Update Rate Test (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6082289/#msg6082289)
Further tests will follow as long as I have the scope (I don't know how long I'll be able to keep it at the moment).
These will include a repeat and extension of the update rate test.
As well as:
- AWG, signal test
- Bode plot test
- Decoder test
- Noise floor tests
- Anything else that comes to mind
The results will be presented in this thread, including a summary of my impressions of the Rigol.
I can already say that, despite its similarity to the previous models I have tested from the DHO/MHO series, I like it best, considering the price.
To be continued...
Martin
-
One last test for today, it's already late here...
Accordingly, I was lazy and controlled the scope from the living room. ;)
The web connection is fast, very good.
Noise level measurement:
One channel (CH1, the others behave in the same way), 1 mV per division, 1 ms per division.
Full bandwidth, 20 MHz, I skipped the 250 MHz.
Then 50 ohm input and 1M ohm.
I consider around 124µV to be good for a 1GHz scope(yes it is... ;) ) ; at 1M ohm, the level is lower, which is probably an indication that the bandwidth is more limited at 1M ohm—I will test this soon.*
Then I also used Hi-Res Mode, which significantly reduced the level again, but that's no surprise, as the bandwidth drops to 2.5kHz at 16 bits.
Finally, an FFT up to 1Ghz, in the new Averaging Mode (20x).
I discovered something else that wasn't very nice.
At 100ms/div, it's obvious that you can't display an FFT up to 1Ghz or even more – yet you can still enter a “max” span of 2Ghz in the menu.
This shouldn't be possible; “max” should refer to the current FFT sample rate.
I found similar nonsense in the AWG menu, where there are buttons for kHz, MHz- and GHz...
EDIT:
*Those who can read a data sheet have an advantage:
500 MHz bandwidth at 1 MΩ input.
-
Finally, an FFT up to 1Ghz, in the new Averaging Mode (20x).
That's a game changer... :-+
-
Yes, for Rigol, that and peak mode are finally the features that Rigol (ALL models) had been missing for a long time.
I can well imagine that these modes will now also benefit other models with the same operating system via firmware update (DHO800, 900, 1000, 4000, MHO2000, 5000).
If not, it would be completely incomprehensible.
-
How fast is the pulse from the aux out connector? (rise time)
-
Hello,
What is the noise level at 1 V/div?
Kind regards,
egonotto
-
Hi,
Here they are, noise at 1V, risetime of Aux out...
Risetime measured with 50 ohm load(input).
-
AWG:
I played around with it a little earlier, here are a few comments.
50 MHz is the maximum frequency for this license (very clever of Rigol, by the way), if the waveform is a sine wave, it is 10 MHz for a square wave and 1 MHz for a ramp wave.
The menu is quite straightforward, which corresponds to the sparse feature set.
And then there are a few minor issues in the menu that should be corrected, or rather, a few things are missing.
First, the choice of output impedance:
Hi-Z is clear, but then it doesn't say “50 ohms” like everywhere else on this planet, no, it says “Load”... Great.
This should be corrected.
Then there's the menu for the output level...
The units Vrms, Vpp, and VdBm are missing; instead, there is “kV” as a unit...
This should also be corrected.
There is nothing to complain about in terms of output quality, which is normal standard, with harmonics increasing slightly with rising frequency (FFTs of sine waves).
By the way, you should make sure that the signal is not displayed in full on the screen, as this will cause interference from the ADC due to overdrive.
This is not unusual, but it should be mentioned.
I then left it at 200 mV/div.
Some things in the FFT menu are also a bit confusing, but I'll come back to that later.
-
FFT pics...
-
I can't wait to have a scope that can do 50Mhz sine wave at 10Kv with it's AWG. ;)
Being able to measure Gdbm without a HV probe will also be cool. ;)
-
Please don't, I think a GdBm signal would be a second big bang!
-
AWG:
I played around with it a little earlier, here are a few comments.
50 MHz is the maximum frequency for this license (very clever of Rigol, by the way), if the waveform is a sine wave, it is 10 MHz for a square wave and 1 MHz for a ramp wave.
The menu is quite straightforward, which corresponds to the sparse feature set.
And then there are a few minor issues in the menu that should be corrected, or rather, a few things are missing.
First, the choice of output impedance:
Hi-Z is clear, but then it doesn't say “50 ohms” like everywhere else on this planet, no, it says “Load”... Great.
This should be corrected.
Then there's the menu for the output level...
The units Vrms, Vpp, and VdBm are missing; instead, there is “kV” as a unit...
This should also be corrected.
There is nothing to complain about in terms of output quality, which is normal standard, with harmonics increasing slightly with rising frequency (FFTs of sine waves).
By the way, you should make sure that the signal is not displayed in full on the screen, as this will cause interference from the ADC due to overdrive.
This is not unusual, but it should be mentioned.
I then left it at 200 mV/div.
Some things in the FFT menu are also a bit confusing, but I'll come back to that later.
Equally nonsense values for siggen output are µV and nV...
-
One last test for today, it's already late here...
Accordingly, I was lazy and controlled the scope from the living room. ;)
The web connection is fast, very good.
Noise level measurement:
One channel (CH1, the others behave in the same way), 1 mV per division, 1 ms per division.
Full bandwidth, 20 MHz, I skipped the 250 MHz.
Then 50 ohm input and 1M ohm.
I consider around 124µV to be good for a 1GHz scope(yes it is... ;) ) ; at 1M ohm, the level is lower, which is probably an indication that the bandwidth is more limited at 1M ohm—I will test this soon.*
Then I also used Hi-Res Mode, which significantly reduced the level again, but that's no surprise, as the bandwidth drops to 2.5kHz at 16 bits.
Finally, an FFT up to 1Ghz, in the new Averaging Mode (20x).
I discovered something else that wasn't very nice.
At 100ms/div, it's obvious that you can't display an FFT up to 1Ghz or even more – yet you can still enter a “max” span of 2Ghz in the menu.
This shouldn't be possible; “max” should refer to the current FFT sample rate.
I found similar nonsense in the AWG menu, where there are buttons for kHz, MHz- and GHz...
EDIT:
*Those who can read a data sheet have an advantage:
500 MHz bandwidth at 1 MΩ input.
Hmmm, your "Full bandwidth" noise level is measured at 50MSa/s... careful with the "Auto" settings ;)
-
One last test for today, it's already late here...
Accordingly, I was lazy and controlled the scope from the living room. ;)
The web connection is fast, very good.
Noise level measurement:
One channel (CH1, the others behave in the same way), 1 mV per division, 1 ms per division.
Full bandwidth, 20 MHz, I skipped the 250 MHz.
Then 50 ohm input and 1M ohm.
I consider around 124µV to be good for a 1GHz scope(yes it is... ;) ) ; at 1M ohm, the level is lower, which is probably an indication that the bandwidth is more limited at 1M ohm—I will test this soon.*
Then I also used Hi-Res Mode, which significantly reduced the level again, but that's no surprise, as the bandwidth drops to 2.5kHz at 16 bits.
Finally, an FFT up to 1Ghz, in the new Averaging Mode (20x).
I discovered something else that wasn't very nice.
At 100ms/div, it's obvious that you can't display an FFT up to 1Ghz or even more – yet you can still enter a “max” span of 2Ghz in the menu.
This shouldn't be possible; “max” should refer to the current FFT sample rate.
I found similar nonsense in the AWG menu, where there are buttons for kHz, MHz- and GHz...
EDIT:
*Those who can read a data sheet have an advantage:
500 MHz bandwidth at 1 MΩ input.
Hmmm, your "Full bandwidth" noise level is measured at 50MSa/s... careful with the "Auto" settings ;)
Measured AC RMS noise levels will be accurate even with undersampling.
-
Hmmm, your "Full bandwidth" noise level is measured at 50MSa/s... careful with the "Auto" settings ;)
Yes, on the one hand, “full bandwidth” was probably the wrong term.
On the other hand, “Auto” is the most common setting, as the scope can determine the optimal settings itself—at 1 ms/div, you are no longer looking at signals beyond 25 MHz (50 MSa/s), but rather significantly below that.
On the other hand, it is then no longer full bandwidth.
I tried manually adjusting the memory to increase the sample rate.
The levels then rise significantly.
@egonotto:
We measured the noise levels once, always using the same settings so we could compare them – do you remember where that was?
-
Hello,
as far as I remember:
We usually used 1 ms/div with sufficient memory to get the maximum sampling rate. With the SDS3000X HD, that was 40 MSamples.
Previously, with the Rigol DHO1000, we had provided the input with a 50 Ohm termination (as a short circuit).
At 1 mV/div, this sometimes yields better values.
I would continue to recommend this, although it makes little difference with the SDS3000X HD.
But in general, noise is measured with a short-circuited input.
Best regards,
egonotto
PS: For 1 MOhm measurements, the 50 Ohm short circuit of the input could improve things somewhat. If not, the MHO9 is not so good in terms of noise.
-
Hello,
as far as I remember:
We usually used 1 ms/div with sufficient memory to get the maximum sampling rate. With the SDS3000X HD, that was 40 MSamples.
Previously, with the Rigol DHO1000, we had provided the input with a 50 Ohm termination (as a short circuit).
At 1 mV/div, this sometimes yields better values.
I would continue to recommend this, although it makes little difference with the SDS3000X HD.
But in general, noise is measured with a short-circuited input.
Best regards,
egonotto
PS: For 1 MOhm measurements, the 50 Ohm short circuit of the input could improve things somewhat. If not, the MHO9 is not so good in terms of noise.
That is why we DO NOT put shorting cap on input when measuring noise.
Just an shield on input, in form of one of the metallic caps (with no short to center). With 1MΩ or 50Ω.
Shorting input can mask noise sources that are there. When measuring you would not have anything shorted.
-
With the 1 M input impedance both the open and shorted input can be relevant. When using an 1:1 probe one would be close to a shorted input case as the signal source is usually relatively low impedance (<< 1 M). With an 1:10 probe the input is close to open with some 9 M (and some 10 pF) in series to the input. Here one would still have a little extra capacitance that would be relevant for the higher frequenies.
For low noise cases the 1:1 probe could still be relevant, even though normally rarely used. There are also measurements directly with a BNC cable, that are close to the shorted case.
Because of the input capacitance there may may not be that much difference between the 2 cases when measuring at higher BW or frequency. There may be a difference in the low frequency ( < 100 kHz) range (could be visible in the FFT).
-
Hello,
you want to measure the noise of the device and not what else it picks up.
For nanovoltmeters, there are even expensive shorting plugs available to measure noise.
For example, a low-thermal shorting plug for 34420A costs US$ 265.
If you measure the noise of the PicoScope 4262 without a short circuit, do you get the promised 8.5 uV?
Best regards,
egonotto
-
Hello,
you want to measure the noise of the device and not what else it picks up.
For nanovoltmeters, there are even expensive shorting plugs available to measure noise.
For example, a low-thermal shorting plug for 34420A costs US$ 265.
If you measure the noise of the PicoScope 4262 without a short circuit, do you get the promised 8.5 uV?
Best regards,
egonotto
That is why you put a shield on BNC but not a short.
Anything that gets coupled in input form inside the scope IS instrument noise.
On occasion we put 50Ω pass trough terminator on input because that is how we would use it in application.
This is how PicoScope 4262 was measured for that 8,5 µV RMS, not with a short. I documented it where I published that number
Without terminator on input it would have more noise and that IS the point.
For pure instrument noise, BNC shielding cap (without shorting pin) and internal 1MΩ and internal 50Ω termination is way to go.
For an instrument that does not have internal 50 Ω, an external 50Ω terminator on input can interpolate what would it be with 50Ω.
If you short the input, that will show too rosy picture for scopes that have a lot of noise pickup in input stages.
It would not make a difference for scopes that have noise sources elsewhere.
-
Hello,
Thank you for your reply. How big is the difference between measuring with a shielding cap and measuring with 50 ohms?
But what do you think about the short-circuit plug for nanovoltmeters?
Kind regards,
egonotto
-
The use case for nanovoltmeters is to allow you to null out offsets, not to reduce noise (though it would do that to a certain extent too).
I think 50R termination is a reasonable condition for measuring wideband noise on a scope, as any probes used would likely have 50R output Z, or if passive, have enough capacitance to be in that ballpark at higher frequencies anyway.
Low frequency noise is another matter though, maybe worth comparing with and without termination at 1Mohm/20MHz limit
-
I repeated yesterday's measurements, except that I closed the input with a BNC cap.
This did not change the measured values, which remain at 280µV/250µV (50R/1M) at 1mV/Div.
-
I wonder how Rigol determined the values in the data sheet.
Magnova provided exemplary specifications for their values (all channels active, 1GSa/s each, 5ms/div, open inputs).
-
Hello,
among all the data sheets that specify noise, Magnova was the only one that stated how it was measured. I also find it very strange when, for example, it says 154.2 mV. I would then specify 160 mV.
Kind regards,
egonotto
-
What's the noise level with the internal 250MHz limiter enabled?
How does it compare with full bandwidth noise?
-
Here are the values for full, 250MHz, and 20MHz, with a 50-ohm input and shielded BNC connector...
(https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2692603;image)
(https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2692607;image)
(https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2692611;image)
-
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.
-
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.
-
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
-
Hi,
Here is a small table showing memory points and the maximum number of frames that can be recorded.
(https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2693465;image)
Does your device have 500 MSamples?
No, it only has the standard 100Mpoints, which I can't change because it's not my scope. ;)
-
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.
-
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.)
-
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)
-
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. :)
-
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. :P
-
Shortly thereafter, it was successfully completed. :phew:
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.
-
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
-
Hi,
I created a test file for the SDS6000X.
Will you make it available too?
-
Hello,
it's the file segments.7z at the very top above the images.
Best regards,
egonotto
-
Ah, my old eyes...
-
Last for today...
-
(https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2692611;image)
Not sure why you'd sample at 4GSa/sec with the 20MHz bandwidth limiter on. ???
Enable hires mode and it will vanish. :)
-
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.
-
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.
-
Hi,
Here is a small table showing memory points and the maximum number of frames that can be recorded.
(https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2693465;image)
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.
-
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.
-
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.
-
...
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.
-
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.
-
Can you show the software you used to retrieve data and calculate results, so others can test in same exact way?
Thanks.
-
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?
-
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.
-
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...
-
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.
-
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.
-
Shortly thereafter, it was successfully completed. :phew:
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.
-
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.
-
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.
-
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.
-
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
-
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.
https://www.youtube.com/watch?v=2y0E4PasLPY (https://www.youtube.com/watch?v=2y0E4PasLPY)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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 .
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
In DHO800/900 default settings makes lowest visible noise - I wonder why.
2 us/div, 50 mV/div and 10 kpts.
-
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.
-
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.
-
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.
-
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".
-
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.
-
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:
-
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.
-
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.
-
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?
-
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.)
-
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.
-
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...
-
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.
-
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.
-
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...
-
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.
-
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.
-
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).
-
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.
-
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%.
-
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.
-
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.
-
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.
-
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.
-
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 :-//
-
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....
-
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?
-
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. 8)
Martin
-
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.
-
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.
-
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(fmax*T), where fmax 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 (fmin = 4MHz) is llikely in a region, though, where 1/f noise does not yet dominate the observed noise power.
-
Make your own records...
-
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.
-
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.
-
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.
-
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...
-
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
-
Finally, a counterexample of what it could look like.
-
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
-
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.
-
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.)
-
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.
-
Finally, a counterexample of what it could look like.
Wow, Martin what is that?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
Look this my final message to you as you don't seem to have the ability actually comprehend what is being discuessed and just hurl insults.
As with your previous "proof", your current "proof" is nothing to do with what rpro's findings are, the scope itself gives different readings and those numbers mathematically prove it's not using the screen data, the numbers are there to see in plain sight.
-
I did two tests with only one change, which is interpolation of the screen data. RMS values are different between sinc and linear interpolation
In the case where the intersecting number of RAW points is less than NORM points, it appears to be using the NORM points (see attached). But please try your test again with a 1M points (take a look again at the pics in Reply #111, I am re-attaching the table). With a signal like a high frequency sinc pulse train, AM modulated, if you can debug in-process, please dump if possible the points the scope is using to compute the AC-RMS in that case, and see if you can tie out with the displayed AC-RMS.
-
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.
You can "see" the effects of sinc and linear interpolation. Look at the start (bottom) of leading rising edge of waveform.
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2698187 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2698187)
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2698191 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2698191)
Best
-
Quite typical for a internet troll who is afraid of proofs.
It would be nice if only tests were discussed here in the dedicated test thread.
There is a general MHO900 thread and now a hack thread (even if there is nothing in it), so you could continue there.
-
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.
Out of respect to Martin72 I don't want to pollute the thead with arguments so I'm just going to say this just to clear things up.
I don't think we are fundamentally disagreeing on anything, the argument comes down to what is deemed acceptable and what is n't.
I never discounted what you said previously or what you are saying now and as in our previous conversation if the 1/3rd priced scope does it better and meets a customers needs they should just buy that scope. The whole point of these discussions (even if they get heated) is so people can make thier own conlusions based on the available data being presented here for their own use case.
Obviously the implementation is not very good if you are working with that kind waveform buf if you need the scopes bandwidth/memory capabilities you're going to have to live with its limitations. A quick python script to download 500Mpts and a very accurate calculation can be made. Is it a pain? Yes. Should you buy this scope if you are going to do this on daily basis? Of course not, time=money and your accumulated time over the lifetime of the scope should justify getting a more expensive scope.
-
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.
Out of respect to Martin72 I don't want to pollute the thead with arguments so I'm just going to say this just to clear things up.
I don't think we are fundamentally disagreeing on anything, the argument comes down to what is deemed acceptable and what is n't.
I never discounted what you said previously or what you are saying now and as in our previous conversation if the 1/3rd priced scope does it better and meets a customers needs they should just buy that scope. The whole point of these discussions (even if they get heated) is so people can make thier own conlusions based on the available data being presented here for their own use case.
Obviously the implementation is not very good if you are working with that kind waveform buf if you need the scopes bandwidth/memory capabilities you're going to have to live with its limitations. A quick python script to download 500Mpts and a very accurate calculation can be made. Is it a pain? Yes. Should you buy this scope if you are going to do this on daily basis? Of course not, time=money and your accumulated time over the lifetime of the scope should justify getting a more expensive scope.
My response is follow up technical question reported before that MHO900 has broken AC RMS implementation and me trying to give a procedure to verify that. You are simply continuing with philosophical attitude that you think this scope is so cheap it does not really have to work properly. I disagree.
Difference is that I am trying to contribute to technical discussion to verify that AC RMS does or does not work well.
In either case it is either good or there is a bug to report to Rigol to eventually fix it.
And even if I go with your argument of acceptable ( which is actually how any instrument and measurement works, it is called error budget and measurement uncertainty) you need to actually establish what that error level is before we submit it to acceptance.
So, as a token of respect to Martin, please make a measurement with the scope the way I explained and please report back what you got as result.
That would have been appropriate response to my post.
-
You can "see" the effects of sinc and linear interpolation. Look at the start (bottom) of leading rising edge of waveform.
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2698187 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2698187)
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2698191 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2698191)
Exactly this is the point. If the measurements will use something else than screen points, it will be no difference in results, but there is noticeable difference every time with each available measurement.
hack thread (even if there is nothing in it)
First of all, why You insinuate nothing is there, when there is hacked firmware, which I did? And why we should move not related to hacking discussion to move there? Are You a mod or something?
Edit: here it is:
V0.0.1 is released (https://buymeacoffee.com/norbert.kiszka/e/479030).
Changelog:
- Unlocked all options.
- Unlocked bandwidth 1 GHz (for all MHO900 models).
- Added bandwidth manual options (separately for each channel): 350 MHz, 500 MHz, 800 MHz.
- Optimizations.
- Minimum time base changed to 200 ps.
I did two tests with only one change, which is interpolation of the screen data. RMS values are different between sinc and linear interpolation
In the case where the intersecting number of RAW points is less than NORM points, it appears to be using the NORM points (see attached). But please try your test again with a 1M points (take a look again at the pics in Reply #111, I am re-attaching the table). With a signal like a high frequency sinc pulse train, AM modulated, if you can debug in-process, please dump if possible the points the scope is using to compute the AC-RMS in that case, and see if you can tie out with the displayed AC-RMS.
I think I provided enough proofs. I spent many months with reverse engineering Rigol firmware, including app communication with FPGA and waveform rendering - so why I need to make exactly same thing again and waste my time?
-
You can "see" the effects of sinc and linear interpolation. Look at the start (bottom) of leading rising edge of waveform.
Best
The conversation with rpro is not about run mode, the numbers in his analysis show that in stop mode AC RMS calculation over a window does n't use the screen data for the calculation but also does n't seem to be on the full dataset as there is ~0.8% error vs calculating the data on a PC.
-
I wonder how difficult is to download Ghidra and decompile Rigol firmware? It's literally 30 minutes, in which 25 minutes is automated analysis and decompilation. But instead it's better to debate and make assumptions without seeing the code.
-
My response is follow up technical question reported before that MHO900 has broken AC RMS implementation and me trying to give a procedure to verify that. You are simply continuing with philosophical attitude that you think this scope is so cheap it does not really have to work properly. I disagree.
Difference is that I am trying to contribute to technical discussion to verify that AC RMS does or does not work well.
In either case it is either good or there is a bug to report to Rigol to eventually fix it.
And even if I go with your argument of acceptable ( which is actually how any instrument and measurement works, it is called error budget and measurement uncertainty) you need to actually establish what that error level is before we submit it to acceptance.
So, as a token of respect to Martin, please make a measurement with the scope the way I explained and please report back what you got as result.
That would have been appropriate response to my post.
Sorry I did n't see the part where you asked me to run some tests but when the scope actually arives in two weeks (unless I cancel the order) I'd be more than happy to run whatever tests you want but it's likely you will have you the information you need before then.
Based on rpro's numbers I doubt the tests will be a pass, especially if you want analysis in run mode. The run mode numbers will probably never improve but for stop mode you may get lucky but there are no guarentees with Rigol and I would not buy any scope with known issues on the hope that it wlll be fixed in the future. I know from a purely engineering point of view cost should not be a factor, but the hard reality is that what would be a unacceptable at $4K can become tolerable at $1K.
-
My response is follow up technical question reported before that MHO900 has broken AC RMS implementation and me trying to give a procedure to verify that. You are simply continuing with philosophical attitude that you think this scope is so cheap it does not really have to work properly. I disagree.
Difference is that I am trying to contribute to technical discussion to verify that AC RMS does or does not work well.
In either case it is either good or there is a bug to report to Rigol to eventually fix it.
And even if I go with your argument of acceptable ( which is actually how any instrument and measurement works, it is called error budget and measurement uncertainty) you need to actually establish what that error level is before we submit it to acceptance.
So, as a token of respect to Martin, please make a measurement with the scope the way I explained and please report back what you got as result.
That would have been appropriate response to my post.
Sorry I did n't see the part where you asked me to run some tests but when the scope actually arives in two weeks (unless I cancel the order) I'd be more than happy to run whatever tests you want but it's likely you will have you the information you need before then.
Based on rpro's numbers I doubt the tests will be a pass, especially if you want analysis in run mode. The run mode numbers will probably never improve but for stop mode you may get lucky but there are no guarentees with Rigol and I would not buy any scope with known issues on the hope that it wlll be fixed in the future. I know from a purely engineering point of view cost should not be a factor, but the hard reality is that what would be a unacceptable at $4K can become tolerable at $1K.
What I am saying this is nothing advanced. It is something 400 USD scopes do right.
-
I wonder how difficult is to download Ghidra and decompile Rigol firmware? It's literally 30 minutes, in which 25 minutes is automated analysis and decompilation. But instead it's better to debate and make assumptions without seeing the code.
Maybe you could just calm down a bit, the thread has become pointless.
-
I wonder how difficult is to download Ghidra and decompile Rigol firmware? It's literally 30 minutes, in which 25 minutes is automated analysis and decompilation. But instead it's better to debate and make assumptions without seeing the code.
Maybe you could just calm down a bit, the thread has become pointless.
I am calm. Right now Im just watching how they make debate about firmware without decompiling its code or doing proper tests. I don't have nerves to talk with low IQ people, so Im out from this exact conversation.
-
Video of the Fan Noise (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6082185/#msg6082185)
Hello,
@Martin72 ,the MSO98 that I have gotten has a aggressive high pitch noise from the area where the power-supply and plugs (LAN, USB, etc.) are located, very likely the coils of the DC/DC converters.
Is that present on other units as well?
Best Regards, Seppel
-
Is that present on other units as well?
I was running my DHO924S quite long time without fan (PLL and FPGA was powered but not running actively) and it was very hard to notice anything - practically silent. With running it normally but with different fan, it's good enough.
-
Looks like this DUT is a Twin-T Passive Notch Filter, maybe with Polystyrene Capacitors :-+
Hi Mike,
Yepp, it´s "yours":
Back when we were still using the 2000Xplus, I implemented your circuit as a circuit board with 0.1% resistors. ;)
@Seppel:
I haven't heard anything about that, but I'll keep an eye out for it.
-
I did two tests with only one change, which is interpolation of the screen data. RMS values are different between sinc and linear interpolation
In the case where the intersecting number of RAW points is less than NORM points, it appears to be using the NORM points (see attached). But please try your test again with a 1M points (take a look again at the pics in Reply #111, I am re-attaching the table). With a signal like a high frequency sinc pulse train, AM modulated, if you can debug in-process, please dump if possible the points the scope is using to compute the AC-RMS in that case, and see if you can tie out with the displayed AC-RMS.
If you have pyvisa and python installed, here is a minimalist script (43 lines including blank lines) to try with the MHO (hopefully it works with the MHO as it works with my DHO804...).
import pyvisa, numpy as np
import matplotlib.pyplot as plt
import math
#Since np.eng_fmt doesn't exist in numpy ver. 1.25.4, I use eng_fmt() as defined below:
eng_fmt = lambda x, sig=3: "0." + "0"*sig + "e+00" if float(x)==0 else \
(lambda v: f"{v/10**(e:=int(math.floor(math.log10(abs(v))/3)*3)):.{sig}f}e{e:+03d}")(float(x))
#eng_fmt = lambda x: x #use to skip "Eng format" on output...
r = pyvisa.ResourceManager().open_resource("TCPIP0::192.168.0.11::INSTR") #Change to scope IP address as needed.
r.write_termination = r.read_termination = '\n'
def Meas_WaveForm(WFtype):
r.write(":STOP;:WAVeform:SOUR CHAN1;:WAVeform:MODE " + WFtype + ";:WAVeform:FORM ASCii")
pre = [float(x) for x in r.query(":WAVeform:PREamble?").split(',')]
pts = int(pre[2]); dx, x0, xr = pre[4], pre[5], int(pre[6])
t = x0 + (np.arange(pts) - xr) * dx
y = np.fromstring(r.query(":WAVeform:DATA?"), sep=',', dtype=float, count=pts)
plt.plot(t,y);plt.title("Data: " + WFtype);plt.show()
stdev = np.std(y)
Vpp = np.ptp(y)
print(f'{WFtype}: {pts}, {eng_fmt(stdev)}, {eng_fmt(Vpp)}')
return t, y, pts
print("Mode: Pts, Stdev(V), Vpp(V)")
t_raw, y_raw, pts_raw = Meas_WaveForm('RAW')
t_norm, y_norm, pts_norm = Meas_WaveForm('NORM')
z = [y_raw[i] for i in range(len(t_raw)) if t_norm[0] <= t_raw[i] <= t_norm[-1]]
print(f'Mem in NORM-WF-time-Span: {len(z)}, {eng_fmt(np.std(z))}, {eng_fmt(np.ptp(z))}')
r.write('MEASure:ITEM ACRMS,CHANnel1')
scope_rms = r.query('MEASure:ITEM? ACRMS,CHANnel1 ')
r.write('MEASure:ITEM VPP,CHANnel1')
scope_vpp = r.query('MEASure:ITEM? VPP,CHANnel1 ')
print(f'AC-RMS and Vpp on Scope: {eng_fmt(scope_rms)}, {eng_fmt(scope_vpp)}' )
-
I wonder how difficult is to download Ghidra and decompile Rigol firmware? It's literally 30 minutes, in which 25 minutes is automated analysis and decompilation. But instead it's better to debate and make assumptions without seeing the code.
Maybe you could just calm down a bit, the thread has become pointless.
I am calm. Right now Im just watching how they make debate about firmware without decompiling its code or doing proper tests. I don't have nerves to talk with low IQ people, so Im out from this exact conversation.
I'll be generous and assume it's your poor English and not that you are an arrogant arse!
-
I wonder how difficult is to download Ghidra and decompile Rigol firmware? It's literally 30 minutes, in which 25 minutes is automated analysis and decompilation. But instead it's better to debate and make assumptions without seeing the code.
Maybe you could just calm down a bit, the thread has become pointless.
I am calm. Right now Im just watching how they make debate about firmware without decompiling its code or doing proper tests. I don't have nerves to talk with low IQ people, so Im out from this exact conversation.
I'll be generous and assume it's your poor English and not that you are an arrogant arse!
Sometimes it's poor English and sometimes it's cognitive bias - especially confirmation bias. Like somebody bought a oscilloscope or a smartphone for the big amount of money and such person will ignore everybody who will try to say it has any disadventages (ekhm ekhm, Apple and Americans...).
When we do any analysis, we should be objective, not subjective. For example I can say that I hate Rigol company. But how good or bad are they scopes? It depends how You look into that - hardware is extremely good for such low price. I could be biased (no reply for emails and other things) and say otherwise. A lot of people are extremely cognitive biased. Everybody is more or less, but not everybody is trying to fight with it.
If somebody is even slightly biased, (s)he can interpret measurements results to fulfill expectations instead of facing reality. Especially when it's not double checked with other methods.
-
I would be very pleased if this could now come to an end and all the off-topic posts could be moved elsewhere.
I find this very annoying.
-
I find this very annoying.
For me very annoying is when somebody focused of being right, publishing his founding about the Rigol scope and insist with it while proofs are saying otherwise. This thing has name, which is confirmation bias - quite common with Rigol scope users.
-
It will take weeks before my MHO98 arrives, but following this and the other thread is especially demoralizing… I’m debating whether I did the right thing in purchasing this scope or not.
Incidentally, I do have a good Linear Audio -70db 1KHz Twin T notch filter that I will use to attempt to replicate the Bode plot test with.
-
Happy Christmas everybody!
You both made your point, now get over it and let’s move on.
And keep hacking :popcorn:
-
It will take weeks before my MHO98 arrives, but following this and the other thread is especially demoralizing… I’m debating whether I did the right thing in purchasing this scope or not.
Incidentally, I do have a good Linear Audio -70db 1KHz Twin T notch filter that I will use to attempt to replicate the Bode plot test with.
There are two ways you can build/service something. You can build/service it so that it works about as well as such a design can theoretically work and then there's building/servicing the thing so that it's as cheap as possible. It seems that Rigol has chosen the latter approach. Particularly on the SW side.
If you are happy with saving $$$ , then you have chosen well enough. If you wanted an instrument made by and for engineers then you'd be better off looking at some of the opensource crowd funded projects or more professional offerings. For example, Dave did a review on the Haasoscope Pro recently. It's a USB scope which can reach 2Ghz. It's priced similarly to the Rigol and it is also 12-bit, but it has only 2 channels, no AWG (IIRC), and less memory.
-
Somebody has a 7 day cooling off period so please do proceed.
-
It will take weeks before my MHO98 arrives, but following this and the other thread is especially demoralizing… I’m debating whether I did the right thing in purchasing this scope or not.
I haven't finished testing the MHO900 yet, but I've tested it enough to be able to draw an almost final conclusion.
When you consider the bare facts, you have to admit that the MHO900 series stands pretty much alone in terms of what it offers, at least on paper.
Up to 1 GHz bandwidth, up to 500 Mpts memory, up to 4 GS/s sample rate, plus a built-in 2-channel AWG up to 100 MHz...
This is unique in this price range, that's a fact.
You can buy an MHO934 and “upgrade” it to an MHO984, which has 1 GHz bandwidth—that's crazy.
From the side, no other product can hold a candle to the MHO900 at the moment.
But Rigol is Rigol, and at first glance everything looks great, but at second glance it's different.
But I'll get to that when I've finished my tests.
-
If you have pyvisa and python installed, here is a minimalist script (43 lines including blank lines) to try with the MHO (hopefully it works with the MHO as it works with my DHO804...).
import pyvisa, numpy as np
import matplotlib.pyplot as plt
import math
#Since np.eng_fmt doesn't exist in numpy ver. 1.25.4, I use eng_fmt() as defined below:
eng_fmt = lambda x, sig=3: "0." + "0"*sig + "e+00" if float(x)==0 else \
(lambda v: f"{v/10**(e:=int(math.floor(math.log10(abs(v))/3)*3)):.{sig}f}e{e:+03d}")(float(x))
#eng_fmt = lambda x: x #use to skip "Eng format" on output...
r = pyvisa.ResourceManager().open_resource("TCPIP0::192.168.0.11::INSTR") #Change to scope IP address as needed.
r.write_termination = r.read_termination = '\n'
def Meas_WaveForm(WFtype):
r.write(":STOP;:WAVeform:SOUR CHAN1;:WAVeform:MODE " + WFtype + ";:WAVeform:FORM ASCii")
pre = [float(x) for x in r.query(":WAVeform:PREamble?").split(',')]
pts = int(pre[2]); dx, x0, xr = pre[4], pre[5], int(pre[6])
t = x0 + (np.arange(pts) - xr) * dx
y = np.fromstring(r.query(":WAVeform:DATA?"), sep=',', dtype=float, count=pts)
plt.plot(t,y);plt.title("Data: " + WFtype);plt.show()
stdev = np.std(y)
Vpp = np.ptp(y)
print(f'{WFtype}: {pts}, {eng_fmt(stdev)}, {eng_fmt(Vpp)}')
return t, y, pts
print("Mode: Pts, Stdev(V), Vpp(V)")
t_raw, y_raw, pts_raw = Meas_WaveForm('RAW')
t_norm, y_norm, pts_norm = Meas_WaveForm('NORM')
z = [y_raw[i] for i in range(len(t_raw)) if t_norm[0] <= t_raw[i] <= t_norm[-1]]
print(f'Mem in NORM-WF-time-Span: {len(z)}, {eng_fmt(np.std(z))}, {eng_fmt(np.ptp(z))}')
r.write('MEASure:ITEM ACRMS,CHANnel1')
scope_rms = r.query('MEASure:ITEM? ACRMS,CHANnel1 ')
r.write('MEASure:ITEM VPP,CHANnel1')
scope_vpp = r.query('MEASure:ITEM? VPP,CHANnel1 ')
print(f'AC-RMS and Vpp on Scope: {eng_fmt(scope_rms)}, {eng_fmt(scope_vpp)}' )
For what its worth, assuming the MHO behaves like the DHO (and hence the relevance), the MSO5000 has a similar behavior to the DHO, for when the number of RAW points falling within the NORMAL points time-interval-span exceeds 1000.
Essentially using the script above (slightly modified for the MSO) I get, as an example, the attached results.
(Again, it is possible that the scopes (DHO and MSO) are actually recursively estimating AC-RMS and other measures using small batches (1000 points), one at the time (a la Kalman), or averaging samples we don't see, before displaying the current values. I don't like Rigol's software as compared to other's, but it is not doing something that would be completly crazy, like only using screen data when and if there are far more collected available (relevant) data points. Of that I am reasonably convinced, given the numerical evidence I have been shown. If it were the case that Rigol has somehow figured out how to estimate ACRMS and (some) other measures from just the final 1000 screen points taken a-priori, matching the std-error of 100K's samples, then that fact alone would be truly amazing (nevermind the scopes!)...)
-
I seem to vaguely remember that the early Rigol scopes would do calculation on what was on the screen, so if you wanted a duty cycle of your PWM "zomming in" to 1 waveform or 2 got you better accuracy. I'm pretty sure than for PWM duty if a full cycle was not on the screen it would not calculate.
-
It will take weeks before my MHO98 arrives, but following this and the other thread is especially demoralizing… I’m debating whether I did the right thing in purchasing this scope or not.
.....
Hello,
Even though it's not great in terms of noise and analysis options, it's still an excellent bargain with two function generators with decent output voltage, good bandwidth, and a digital probe.
When compared to the more expensive Siglent SDS2000X HD and Batronix Magnova, for example, it comes out on top in a few areas.
Best regards,
egonotto
-
I seem to vaguely remember that the early Rigol scopes would do calculation on what was on the screen, so if you wanted a duty cycle of your PWM "zomming in" to 1 waveform or 2 got you better accuracy. I'm pretty sure than for PWM duty if a full cycle was not on the screen it would not calculate.
That's how the DS1054Z worked - all calculations/measurements were done with on-screen data.
Anything that didn't have complete data on the screen would fail.
if you wanted a duty cycle of your PWM "zomming in" to 1 waveform or 2 got you better accuracy.
Correct. Knowledge was power.
Knowing (and more importantly, accepting) how it worked would get you better results.
This isn't the case with the DHO800 though. AFAIK it uses all available memory (ie. Whatever's displayed as the memory size at the top of the screen at any moment).
-
This isn't the case with the DHO800 though. AFAIK it uses all available memory (ie. Whatever's displayed as the memory size at the top of the screen at any moment).
To add to that: Can you set things up so that tiny peaks are lost in that buffer through decimation or whatever? Of course.
Anybody who blindly trusts voltage numbers on an oscilloscope screen is doing it wrong. I'm sure there's somebody here who has a sig to that effect.
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
You will always be able to find ways to cause this "error" if you try hard enough.
On any 'scope.
It's a fact of life in any system that samples data at regular time intervals.
See the section "sample theory" in the Siglent user manual for more details.
(https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2698859;image)
-
I seem to vaguely remember that the early Rigol scopes would do calculation on what was on the screen, so if you wanted a duty cycle of your PWM "zomming in" to 1 waveform or 2 got you better accuracy. I'm pretty sure than for PWM duty if a full cycle was not on the screen it would not calculate.
That's how the DS1054Z worked - all calculations/measurements were done with on-screen data.
Anything that didn't have complete data on the screen would fail.
if you wanted a duty cycle of your PWM "zomming in" to 1 waveform or 2 got you better accuracy.
Correct. Knowledge was power.
Knowing (and more importantly, accepting) how it worked would get you better results.
This isn't the case with the DHO800 though. AFAIK it uses all available memory (ie. Whatever's displayed as the memory size at the top of the screen at any moment).
So you're saying that MHO98/900 decode from screen and the DHO800/900 decode from memory? If i got that correctly, what's the point in having 500M on MHO if they only use the screen info to decode? really disappointed
-
You will always be able to find ways to cause this "error" if you try hard enough.
On any 'scope.
So you are saying something that should trivially work and it does not is Ok, because we can devise pathological conditions where even properly functioning other equipment will break. Weird....
If you want to discuss performance of the scope here, verify (way I have explained) that AC RMS is wrong or right. And what are its limits.
The performance evaluation of the scope is exactly that: showing what scope can and cannot do, what it is good at and where it sucks. So people can make decision.
For model how it is done take a look at Performa01 scope evaluations.
-
So you're saying that MHO98/900 decode from screen and the DHO800/900 decode from memory?
The discussion is not about decoding but about how the scopes calculates AC-RMS. It looks like it's not doing this over the whole measured data.
Also I figure that the behavior of the MHO900, DHO800/900 and MSO5000 is similar or identical regarding this topic.
-
I seem to vaguely remember that the early Rigol scopes would do calculation on what was on the screen, so if you wanted a duty cycle of your PWM "zomming in" to 1 waveform or 2 got you better accuracy. I'm pretty sure than for PWM duty if a full cycle was not on the screen it would not calculate.
Yes, but that worked only on that trivial example.
If you have a device that does things in bursts over longer period, you couldn't measure that.
To make sure we understand each other, all scopes measure from time interval defined by what is on the screen.
Difference was that DS1000Z actually used screen pixel data.
So if you had 100 edges on the screen, it would be one big block of yellow and measurements would go nuts..
Keysight 3000T also used decimated data, but 32000 or something like that, that assured that same thing didn't happen until you are pushing it. But it also didn't do good job if you pushed it a bit.
And then there are scopes that will use 10, 40 or 100 MPts for measurements...
It is obvious they are not all created equal in this regard. Whether it is important, depends on type of work.
-
So you're saying that MHO98/900 decode from screen and the DHO800/900 decode from memory?
The discussion is not about decoding but about how the scopes calculates AC-RMS. It looks like it's not doing this over the whole measured data.
Also I figure that the behavior of the MHO900, DHO800/900 and MSO5000 is similar or identical regarding this topic.
The topic says "...Test/Review..." not specifically AC-RMS so I'm in the right place and since the talk a few posts back mention information on screen my observation/question is relevant.
Anyway everybody knows the oscilloscopes need the signal to fill the most space on screen as possible to display a more accurate value. Since no signal is 100% stable and precise, there's always some kind of averaging going on and that's one of the reasons why we never get an exact same value realtime. Other reason could be noise injected on the signal for whatever reason, and as you know noise could falsify the readings.
-
The topic says "...Test/Review..." not specifically AC-RMS so I'm in the right place and since the talk a few posts back mention information on screen my observation/question is relevant.
You quoted a statement about PWM measurements on the DS1054Z and derived an assumption about the decoding on the MHO900.
I wanted to point out that the lengthy discussion within this thread did in no way support this assumption.
-
Anyway everybody knows the oscilloscopes need the signal to fill the most space on screen as possible to display a more accurate value. Since no signal is 100% stable and precise, there's always some kind of averaging going on and that's one of the reasons why we never get an exact same value realtime. Other reason could be noise injected on the signal for whatever reason, and as you know noise could falsify the readings.
Absolutely everything you said here is simple truism, wrong or irrelevant to actual AC RMS discussion here.
I know you try to help but please read what other posted before responding.
-
Anyway everybody knows the oscilloscopes need the signal to fill the most space on screen as possible to display a more accurate value. Since no signal is 100% stable and precise, there's always some kind of averaging going on and that's one of the reasons why we never get an exact same value realtime. Other reason could be noise injected on the signal for whatever reason, and as you know noise could falsify the readings.
Absolutely everything you said here is simple truism, wrong or irrelevant to actual AC RMS discussion here.
I know you try to help but please read what other posted before responding.
Okay, I'll think about it.
-
The discussion is not about decoding but about how the scopes calculates AC-RMS. It looks like it's not doing this over the whole measured data.
Also I figure that the behavior of the MHO900, DHO800/900 and MSO5000 is similar or identical regarding this topic.
Yes, the DHO800 doesn't use all the RAW memory data, but (provided you have set the memory high enough) it "effectively" uses the subset of the RAW data in the time span of the displayed waveform, and I find that useful for real world signals. So, for example, if you do a Single capture of a transient waveform, like a startup-transient, you can change the timebase and horizontal position to display the portion of the waveform you may want to see and measure, and the measured AC-RMS will give a reading close to the std-dev of (potentially millions of) points that correspond to the time spanned by the waveform that is being currently displayed. Note that in the case where the resulting number of relevant RAW points is <= than that of the displayed data, then AC-RMS just uses the displayed data (aka NORMAL points).
If you have access to a DHO, you can perform a nice test by setting up a high frequency sinc-pulse train (which has the useful property of having same amplitude harmonics--in practice over a wide BW range, at least) and AM modulating it with a sine wave, to also check the case where you are displaying just a partial lobe, and see if it is measuring the AC-RMS of all of the RAW points, etc. Setting this up, or any other suggestive waveform, you can run the script I posted to get points from the scope and compare numbers.
-
So you're saying that MHO98/900 decode from screen and the DHO800/900 decode from memory? If i got that correctly, what's the point in having 500M on MHO if they only use the screen info to decode? really disappointed
I don't know what the MHO98/900 do because I haven't got one but I'd be shocked if they've gone back to doing it "on screen".
-
To make sure we understand each other, all scopes measure from time interval defined by what is on the screen.
No, AFAIK it's only Siglents that can't zoom out, Rigols generally have a bit of data either side as well.
I assumed they used the full captured amount (protocol decoding certainly does).
It's easy to test: Capture a wave that doesn't fit completely on screen but does fit in the captured memory and see if it measures the frequency correctly (or duty cycle, or whatever)
-
I'm just having a brain freeze... :P
The “All Measure” window—how do you display it?
I managed to do it on my old DHO800, but here on the MHO900, I'm really struggling with it.
-
To make sure we understand each other, all scopes measure from time interval defined by what is on the screen.
No, AFAIK it's only Siglents that can't zoom out, Rigols generally have a bit of data either side as well.
I assumed they used the full captured amount (protocol decoding certainly does).
It's easy to test: Capture a wave that doesn't fit completely on screen but does fit in the captured memory and see if it measures the frequency correctly (or duty cycle, or whatever)
You should not write messages without reading and understanding what is the topic.
Read again what I said. And if then you still don't understand, please ask for explanation.
Writing random stuff with no connection to topic makes you sound confused..
-
To make sure we understand each other, all scopes measure from time interval defined by what is on the screen.
No, AFAIK it's only Siglents that can't zoom out, Rigols generally have a bit of data either side as well.
I assumed they used the full captured amount (protocol decoding certainly does).
It's easy to test: Capture a wave that doesn't fit completely on screen but does fit in the captured memory and see if it measures the frequency correctly (or duty cycle, or whatever)
You should not write messages without reading and understanding what is the topic.
Read again what I said. And if then you still don't understand, please ask for explanation.
Writing random stuff with no connection to topic makes you sound confused..
I'm the one who's confused. As a buyer, I'm trying to figure out if the MHO is a good deal or if there are critical bugs or poor feature implementations, unacceptable in a $1000 oscilloscope.
You guys are the oscilloscope gurus, but sometimes I get really confused by the lack of consensus among the experts. I don't know which way to go. Do you understand what I mean?
-
Unfortunately, this secondary thread which was supposed to sum up test results and reviews only, is getting polluted just like the other one. :-[
-
At the request of a user, here is a measurement of when the decimation of values begins.
I used the maximum possible memory capacity of 100 Mpts here—MHO98 users could use up to 500 Mpts (or users with “unlocked” MHO900).
Settings: Sine wave 1 MHz, 200 mVrms with 100 mV DC offset, 50 ohms.
Images from 200 ns to 200 ms/div.
From 10 ms/div onwards, the measured values become slightly different; at 100 ms/div, they are definitely incorrect.
It should be noted that this is not a flaw, because at some point, accurate measurements come to an end.
In this case, it is quite late, which is not bad.
However, this also reveals the disadvantage that the measured values are arranged vertically—if you want to display the statistics for all parameters, you have to scroll.
-
Just for fun, I did the same thing with the Magnova Scope....No words.
-
OK, so I had a few hours to kill this afternoon and decided to a look at what is actually going on with regards to processing & RMS measurement in the scope by looking at the decompiled code from the firmware from the rigol web site.
Note this is just from the firmware, I don't have a scope to test, with that said:
Firstly, in the scope there is only one stream, data coming from the FPGA and that is always used for processing measurements - display data is derived from this stream. The FPGA does interpolation on the data when the number of samples for time_base < screen_width (and maybe on other conditons too, did n't have time to look deeper).
The measurement system works in the background on blocks of data based on the timebase in a loop on on a single thead thread in the background (so max one CPU core), maximum block size seems to be 1Mpts as there is logic to for >1Mpts but I'm not sure exactly how it i handled at this time.
If the number of points are < 10K it is upsampled to 100K with a simple linear interpolation (not sure why you'd want that to do that)
The actual AC RMS calculation seems to be wrong, I am no mathmatician but I would expect AC RMS to be:
mean = sum(x) / N
rms = sqrt(sum((x-mean)^2) / N)
However what it seams to do is:
mean = sum((x-offset) ^ 2) / N <-- "offset" is passed to the function
rms = sqrt(sum((x-mean)^2) / N)
It also creates a histogram of the sample data (but only for the top 11 bits of the 16bit data) and then goes ahead and just discards it. The "rms = sqrt(sum((x-mean)^2) / N)" calculation is also really slow executing due to calling a power function rather than doing a simple (x*x) instruction. In general the whole code is really poor but I will not go into the details as this is a measurement thread.
So the AC RMS does indeed look to be broken and some measurments with very low timebases may have issues with ripple due to sin(x)/x, however higher timebases should not be an problem.
PS, sorry did n't have time reply to any thing directed towards me, no time, will do so tomorrow evening.
Edit:
Actually I made a made a mistake here, see below.
-
mean = sum((x-offset) ^ 2) / N <-- "offset" is passed to the function
rms = sqrt(sum((x-mean)^2) / N)
If these are unsigned values from ADC, an offset make sense.
-
mean = sum((x-offset) ^ 2) / N <-- "offset" is passed to the function
rms = sqrt(sum((x-mean)^2) / N)
If these are unsigned values from ADC, an offset make sense.
The problem I thought was that it is not doing a sqrt on the squared numbers, but actually I was wrong, I was reading the wrong line.
What it actually does is actual RMS calculation twice, one where it takes away an offset passed in as variable and then again based on the mean:
for (iStack_40070 = 0; iStack_40070 < param_2; iStack_40070 = iStack_40070 + 1) {
uVar3 = (ulong)*puStack_40050;
lStack_40058 = lStack_40058 + uVar3;
aiStack_40028[uVar3 & 0xff80] = aiStack_40028[uVar3 & 0xff80] + 1;
dStack_40060 = dStack_40060 + (double)(long)(((long)param_3 - uVar3) * ((long)param_3 - uVar 3));
puStack_40050 = puStack_40050 + 1;
}
lVar1 = 0;
if ((long)param_2 != 0) {
lVar1 = lStack_40058 / (long)param_2;
}
puStack_40050 = param_1;
for (iStack_4007c = 0; iStack_4007c < param_2; iStack_4007c = iStack_4007c + 1) {
fVar5 = (float)NEON_ucvtf((uint)*puStack_40050);
dVar4 = (double)FUN_00423868(fVar5 - (float)lVar1,2); <--- POW function
dStack_40068 = dStack_40068 + dVar4;
puStack_40050 = puStack_40050 + 1;
}
fVar5 = FUN_00458fb8((float)(dStack_40068 / (double)(long)param_2)); <--- SQRT function
*(float *)(param_5 + 0x10) = fVar5;
*(float *)(param_5 + 0x14) = (float)SQRT(dStack_40060 / (double)(long)param_2);
So it does it twice, with two different methods and for added fun it uses an optimisation in one and not the other.
I will have to see where that offset is coming from, looking at code like this give me headache. If the offset value not being right could could count towards descrepencies, but for all the crappyness it looks to be right :-//
-
Is there actually a reason why this very interesting topic is being discussed here and not where it would be more appropriate, namely in the “big” general MHO900/98 thread?
I started this thread so that measured results wouldn't get lost in the other thread because they would be buried by other posts.
But now exactly the same thing is happening here, and I find that rather suboptimal. :(
In other words, please continue this discussion in the other thread.
Thanks,
Martin
-
Is there actually a reason why this very interesting topic is being discussed here and not where it would be more appropriate, namely in the “big” general MHO900/98 thread?
I started this thread so that measured results wouldn't get lost in the other thread because they would be buried by other posts.
But now exactly the same thing is happening here, and I find that rather suboptimal. :(
In other words, please continue this discussion in the other thread.
Thanks,
Martin
I thought it was relavent considering people are talking about the RMS measurement issues, anyhow the information is here if anyone else wants to investigate it more on another thread, no more posts on the subject from me.
-
Is there actually a reason why this very interesting topic is being discussed here and not where it would be more appropriate, namely in the “big” general MHO900/98 thread?
I started this thread so that measured results wouldn't get lost in the other thread because they would be buried by other posts.
I'm afraid it's only natural to want to follow up directly when something questionable is encountered. You should probably have done what Performa01 did in his evaluation thread: Reserve the first 10–20 replies at the beginning of the thread for the test results and allow the discussion to evolve in later replies. If new findings emerge, you can update/augment the results in the messages at the beginning of the thread.
-
Is there actually a reason why this very interesting topic is being discussed here and not where it would be more appropriate, namely in the “big” general MHO900/98 thread?
I started this thread so that measured results wouldn't get lost in the other thread because they would be buried by other posts.
I'm afraid it's only natural to want to follow up directly when something questionable is encountered. You should probably have done what Performa01 did in his evaluation thread: Reserve the first 10–20 replies at the beginning of the thread for the test results and allow the discussion to evolve in later replies. If new findings emerge, you can update/augment the results in the messages at the beginning of the thread.
100%
Although being the OP of a thread allows you some power to link posts with additional findings in the OP and/or create a POI list to help readers easily find things.
-
Hi,
I now know how long I can keep the scope... ;)
This coming weekend, I will test the decoder functions and possibly do a two-tone test.
If you can think of anything else you would like to know before then, feel free to post it here.
Martin
-
At the request of a user, here is a measurement of when the decimation of values begins.
I used the maximum possible memory capacity of 100 Mpts here—MHO98 users could use up to 500 Mpts (or users with “unlocked” MHO900).
Settings: Sine wave 1 MHz, 200 mVrms with 100 mV DC offset, 50 ohms.
Images from 200 ns to 200 ms/div.
From 10 ms/div onwards, the measured values become slightly different; at 100 ms/div, they are definitely incorrect.
It should be noted that this is not a flaw, because at some point, accurate measurements come to an end.
Can you repeat same AC RMS test with non-integer ratio frequency like 0.971MHz?
-
I'll keep that in mind, sure.
-
That was a good idea, because the measured values deviate early on.
At 50µs/s, the frequency and voltage are already incorrect, and at 10ms/div they are clearly wrong.
(Previous measurements with 1 MHz:
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6103897/#msg6103897 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6103897/#msg6103897) )
-
Hm, interesting. At 50ms/div, the sampling rate drops significantly to 125MSa/s but there should be still 128 data points for each period. Which raises the question why the frequency measurement collapses there. I know, I would test it myself, but I'm ultra-lazy, so does this change when zooming in and how does the signal look when zoomed in?
Might be also interesting to enable statistics for the frequency.
-
That was a good idea, because the measured values deviate early on.
At 50µs/s, the frequency and voltage are already incorrect, and at 10ms/div they are clearly wrong.
(Previous measurements with 1 MHz:
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6103897/#msg6103897 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6103897/#msg6103897) )
This is a good test for anyone with a modern DSO, even if just to get some experience with what AC RMS, STD, and Cycle RMS means. One can see on the display that if fractional parts of the waveform are displayed, then the RMS calculations can be affected, and when many cycles of the waveform are captured then the fractional part has less effect.
Best
-
I know, I would test it myself, but I'm ultra-lazy, so does this change when zooming in and how does the signal look when zoomed in?
Admit it, you put it back in the box and stored it away... ;)
But I did it, 50 ms/div, and everything is not displayed correctly.
Then I zoomed in “live” to 200 ns using the zoom function (which is unfortunately hidden in the menu), and the results were correct.
Roughly the same thing happens when you stop at 50 ms/div, for example, and then “zoom in” using time base reduction.
-
Admit it, you put it back in the box and stored it away... ;)
It's actually currently in its bag in the shelve. It's my "theoretically portable" scope after all ;)
Then I zoomed in “live” to 200 ns using the zoom function (which is unfortunately hidden in the menu), and the results were correct.
Thanks for testing. These examples might not be your everyday use case but this is slightly underwhelming.
I would usually expect that a scope performs the measurement for all captures data or at least all data that was captured in the currently displayed time range.
I.e. if there are hundreds of periods measured for the currently displayed time range, the count or its increase per trigger should reflect that number of periods.
I guess they are using some tricks there to increase the update rate but the number of counts in the statistic is also much too small when stopped and when taking into account that only the displayed range is used for the measurement.
I guess they sacrificed usefulness of the measurement functions for large data sets to increase the "snappiness".
Side note: there is a setting to use the pressing the of horizontal knob to enable/disable the Zoom mode instead of Vernier.
-
Side note: there is a setting to use the pressing the of horizontal knob to enable/disable the Zoom mode instead of Vernier.
Yes, but a dedicated button for that wouldn't have hurt them either.
-
Yes, but a dedicated button for that wouldn't have hurt them either.
To be fair, my SDS5034X doesn't have a dedicated Zoom button, either. Actually, there pressing the horizontal knob is used as well, but there is no option to use Vernier instead.
-
OK, generally speaking, a dedicated button for this would be useful, regardless of the manufacturer. ;)
-
Roughly the same thing happens when you stop at 50 ms/div, for example, and then “zoom in” using time base reduction.
"Zoom" mode on my DHO800 seems to switch it to doing calculations on the whole, undecimated buffer.
Updates get a lot slower as a result.
-
"Zoom" mode on my DHO800 seems to switch it to doing calculations on the whole, undecimated buffer.
Updates get a lot slower as a result.
If that is true, it's a weird design decision. Doesn't seem to be mentioned in the user manual, either.
-
I wonder what Rigols’ response would be if one of you create a support ticket for this.
-
I wonder what Rigols’ response would be if one of you create a support ticket for this.
Is there actually something like this? I reported the LA threshold bug some weeks ago and even got a further query on this, but I didn't get any information about a support ticket being created or whatever and now there is just silence.
-
That probably depends on who processes the inquiries at Rigol.
I received a quick response regarding the performance verification report, but also a quick answer to my question about whether the hacks offered for sale here have been agreed upon with Rigol.
They have not:
This is definitely not agreed by Rigol. We do not offer any service for any Rigol products after being hacked.
;)
-
I’m actually disappointed by you informing Rigol of the existence of hacks here.
-
I’m actually disappointed by you informing Rigol of the existence of hacks here.
Why ?
You instead have official confirmation hacked instruments will not be supported as one might expect from any manufacturer.
-
Don’t make me laugh.
We all know that beforehand.
Martin knew perfectly well there is no such agreement.
Very low level behaviour.
@Tautech,
I expect you to report what TV84 or whoever it was that cracked the Siglent licenses to Siglent as well, because that is the exact same thing, legally.
Did you ?
-
Don’t make me laugh.
We all know that beforehand.
Martin knew perfectly well there is no such agreement.
Very low level behaviour.
@Tautech,
I expect you to report what TV84 or whoever it was that cracked the Siglent licenses to Siglent as well, because that is the exact same thing, legally.
Did you ?
There is zero evidence TV84 had anything to do with the online script for Siglent hacks.
Although he and member janekivi (IIRC) explored Siglent FW releases and did OS investigations.....just as any smart programmer might do....and for many different brands.
If Siglent were worried they would have attempted to close doors years ago as they have for V2 licensing.....SDS5000X was previously V1 licensing but moved to V2 and the door was shut.
But that's not to say any licensing algorithm is totally secure.....
I called Dave out on this earlier today and Siglent's response to his hacking efforts:
.............
He gets banned for hacking, perhaps even cracking: bad karma, and anyone posting any crack/license generator, whatever cracking-related, even for free, should be banned too.
History of what's happened here on EEVblog is also good to know.
Hacks were not posted back in the old days but links to online hacks have always been.
Rigup and RigLOL are 2 old examples.
Dave only needs protect his forum and personal liability at any cost.
The only thing we don't allow here is actual copyrighted/cracked material being uploaded to this server. Anyone is free to post a link to a third party website if they so choose.
Lecroy once threatened legal action against me if I didn't remove this thread:
https://www.eevblog.com/forum/testgear/lecroy-options-recovery/ (https://www.eevblog.com/forum/testgear/lecroy-options-recovery/)
I told them very politely that I would not do that, and that pursuing that would be very bad for their reputation. I didn't hear from them again.
Yeah well you're not exactly squeaky clean when it comes to hacking. :P
I well remember the SDS1102X-E you got for review that you captured the boot log and found the way to make it the 200 MHz model which resulted in Siglent only releasing SDS1202X-E to the west and you having the one and only SDS1102X-E outside Asia.
-
So you didn’t report the fact that there was a hack to circumvent the Siglent licenses…
But you find it normal when it happens to a competitor…
Btw, the same goes for Rigol; they also could have changed whatever in the MHO900 series to make it harder to decode or crack, just as you said Siglent could.
Well, apparently Rigol chose not to either.
If it was not TV84, your surely reported the exact individual to Siglent for breaking their licenses, right ?
(Of course you did not, you just want it to happen to a competitor)
-
Btw, the same goes for Rigol; they also could have changed whatever in the MHO900 series to make it harder to decode or crack, just as you said Siglent could.
Well, apparently Rigol chose not to either.
Rigol is totally aware of the hacking. I've spoken to people at Rigol who said so (they're probably reading this now - they read EEVBLOG, too).
They could turn off ADB access at any time if they wanted to.
-
@Sorama
That was just a general question with no particular reference, so you can calm down again. ;)
-
@Sorama
That was just a general question with no particular reference, so you can calm down again. ;)
A question you knew the answer already.
You said you referenced the hack on eevblog forum.
Did you ask Siglent if you got still support after you hacked your/their SA?
-
So you didn’t report the fact that there was a hack to circumvent the Siglent licenses…
But you find it normal when it happens to a competitor…
Btw, the same goes for Rigol; they also could have changed whatever in the MHO900 series to make it harder to decode or crack, just as you said Siglent could.
Well, apparently Rigol chose not to either.
If it was not TV84, your surely reported the exact individual to Siglent for breaking their licenses, right ?
(Of course you did not, you just want it to happen to a competitor)
Have you ever considered marketing strategies and the importance of capturing customers for them to become brand followers and their possible future spend ?
Maybe you should give this some thought....
OTOH these sorts of things mean little to me as I can offer some of the best brand support available and have customers return time after time.......not all hack or are even interested in doing so these days as you can get so so so much for your spend.
The EE is very spoilt for the choices available these days.....
-
So you didn’t report the fact that there was a hack to circumvent the Siglent licenses…
But you find it normal when it happens to a competitor…
Btw, the same goes for Rigol; they also could have changed whatever in the MHO900 series to make it harder to decode or crack, just as you said Siglent could.
Well, apparently Rigol chose not to either.
If it was not TV84, your surely reported the exact individual to Siglent for breaking their licenses, right ?
(Of course you did not, you just want it to happen to a competitor)
Have you ever considered marketing strategies and the importance of capturing customers for them to become brand followers and their possible future spend ?
Maybe you should give this some thought....
OTOH these sorts of things mean little to me as I can offer some of the best brand support available and have customers return time after time.......not all hack or are even interested in doing so these days as you can get so so so much for your spend.
The EE is very spoilt for the choices available these days.....
Just like the banned Norbert who will convince potential customers to buy Rigol as his hack (just like the Siglent hack) will attract those people.
There is no difference in what Norbert did and what the people here on eevblog did wrt the license script.
Yes Norbert asks money for it, because he also offers other features, speed and bug fixing.
He would be crazy not to.
-
So you didn’t report the fact that there was a hack to circumvent the Siglent licenses…
But you find it normal when it happens to a competitor…
Btw, the same goes for Rigol; they also could have changed whatever in the MHO900 series to make it harder to decode or crack, just as you said Siglent could.
Well, apparently Rigol chose not to either.
If it was not TV84, your surely reported the exact individual to Siglent for breaking their licenses, right ?
(Of course you did not, you just want it to happen to a competitor)
Have you ever considered marketing strategies and the importance of capturing customers for them to become brand followers and their possible future spend ?
Maybe you should give this some thought....
OTOH these sorts of things mean little to me as I can offer some of the best brand support available and have customers return time after time.......not all hack or are even interested in doing so these days as you can get so so so much for your spend.
The EE is very spoilt for the choices available these days.....
Just like the banned Norbert who will convince potential customers to buy Rigol as his hack (just like the Siglent hack) will attract those people.
There is no difference in what Norbert did and what the people here on eevblog did wrt the license script.
Yes Norbert asks money for it, because he also offers other features, speed and bug fixing.
He would be crazy not to.
Other brands actually fix instrument shortcomings with firmware updates for zero additional cost. :P
-
That was a good idea, because the measured values deviate early on.
At 50µs/s, the frequency and voltage are already incorrect, and at 10ms/div they are clearly wrong.
(Previous measurements with 1 MHz:
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6103897/#msg6103897 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6103897/#msg6103897) )
This is a good test for anyone with a modern DSO, even if just to get some experience with what AC RMS, STD, and Cycle RMS means. One can see on the display that if fractional parts of the waveform are displayed, then the RMS calculations can be affected, and when many cycles of the waveform are captured then the fractional part has less effect.
Theoretically, that should be the case. Unfortunately, the screenshots show the opposite: More cycles in the window -> larger error :( :-//
IMO, the screenshots are also inconsistent with the idea that only 1,000 decimated screen samples would be used for the measurements. If that were the case, how could it measure a frequency of 1.0 MHz (1 µs period) at 5 ms/div where the decimated screen sampling period is as large as 50 µs (20 kSa/s sample rate)? At this sample rate, 971 kHz would alias to 9 kHz, and that is the frequency/period that would be measured from the decimated screen samples (at best).
-
So you didn’t report the fact that there was a hack to circumvent the Siglent licenses…
But you find it normal when it happens to a competitor…
Btw, the same goes for Rigol; they also could have changed whatever in the MHO900 series to make it harder to decode or crack, just as you said Siglent could.
Well, apparently Rigol chose not to either.
If it was not TV84, your surely reported the exact individual to Siglent for breaking their licenses, right ?
(Of course you did not, you just want it to happen to a competitor)
Have you ever considered marketing strategies and the importance of capturing customers for them to become brand followers and their possible future spend ?
Maybe you should give this some thought....
OTOH these sorts of things mean little to me as I can offer some of the best brand support available and have customers return time after time.......not all hack or are even interested in doing so these days as you can get so so so much for your spend.
The EE is very spoilt for the choices available these days.....
Just like the banned Norbert who will convince potential customers to buy Rigol as his hack (just like the Siglent hack) will attract those people.
There is no difference in what Norbert did and what the people here on eevblog did wrt the license script.
Yes Norbert asks money for it, because he also offers other features, speed and bug fixing.
He would be crazy not to.
Other brands actually fix instrument shortcomings with firmware updates for zero additional cost. :P
And Rigol doesn’t.
So Norbert did and while he did not get money from selling scopes, he’s asking a leaf of bread for his weeks of work.
We better be grateful that he is even willing to do so.
-
So you didn’t report the fact that there was a hack to circumvent the Siglent licenses…
But you find it normal when it happens to a competitor…
Btw, the same goes for Rigol; they also could have changed whatever in the MHO900 series to make it harder to decode or crack, just as you said Siglent could.
Well, apparently Rigol chose not to either.
If it was not TV84, your surely reported the exact individual to Siglent for breaking their licenses, right ?
(Of course you did not, you just want it to happen to a competitor)
Have you ever considered marketing strategies and the importance of capturing customers for them to become brand followers and their possible future spend ?
Maybe you should give this some thought....
OTOH these sorts of things mean little to me as I can offer some of the best brand support available and have customers return time after time.......not all hack or are even interested in doing so these days as you can get so so so much for your spend.
The EE is very spoilt for the choices available these days.....
Just like the banned Norbert who will convince potential customers to buy Rigol as his hack (just like the Siglent hack) will attract those people.
There is no difference in what Norbert did and what the people here on eevblog did wrt the license script.
Yes Norbert asks money for it, because he also offers other features, speed and bug fixing.
He would be crazy not to.
Other brands actually fix instrument shortcomings with firmware updates for zero additional cost. :P
And Rigol doesn’t.
So Norbert did and while he did not get money from selling scopes, he’s asking a leaf of bread for his weeks of work.
We better be grateful that he is even willing to do so.
So the end result is a scope that costs more to operate correctly.
How much confidence does that give you in the brand ?
-
How much confidence does that give you in the brand ?
A valid point, and knowing what I know now, it would give me pause if I were planning to spend 'a lot', and twice so if that purchase were set within a commercial or research context.
But as a hobbyist with modest pretensions, you might be surprised. I may actually be more drawn to an ecosystem with an 'open' aspect to it (acknowledging that it's unofficial, unsupported and could evaporate tomorrow), where there's perhaps one or two individuals who are responding to fix and 'new feature' requests on the time scale of just a few days. And how many vendors allow Joe Hobbyist to speak directly with their product manager/developers?
I'd been considering letting my DHO1074 go but on the back of Norbert's work, I now shan't.
-
We all know what to think about Rigols (lack of) support.
It is no different with R&S or Keysight (I thought) wrt non professionals.
And Norbert is asking just a few cents for making it right.
-
We all know what to think about Rigols (lack of) support.
It is no different with R&S or Keysight (I thought) wrt non professionals.
And Norbert is asking just a few cents for making it right.
And with that, let's end this side thread, because Martin will be offended again that you're messing up his thread and "diverting from the topic without contributing anything." Please.
-
How much confidence does that give you in the brand ?
A valid point, and knowing what I know now, it would give me pause if I were planning to spend 'a lot', and twice so if that purchase were set within a commercial or research context.
But as a hobbyist with modest pretensions, you might be surprised. I may actually be more drawn to an ecosystem with an 'open' aspect to it (acknowledging that it's unofficial, unsupported and could evaporate tomorrow), where there's perhaps one or two individuals who are responding to fix and 'new feature' requests on the time scale of just a few days. And how many vendors allow Joe Hobbyist to speak directly with their product manager/developers?
I'd been considering letting my DHO1074 go but on the back of Norbert's work, I now shan't.
They will listen to valuable feedback from dudes that really know a thing or two !
Not wishlist poo, things that are either wrong or should be fixed and things that experienced users expect.
Seen it and offered suggestions that have changed complete product ranges but what would I know as only a reseller ! :P
Anyone can make an impact today with the product open source declarations now available and craft your own improvements/hacks for most products.
Eg:
https://int.siglent.com/u_file/download/24_06_03/SDS1000X%20HD&SDS3000X%20HD&SDS800X%20HD_Open%20Source%20Acknowledgment_EN01A.pdf
-
That was a good idea, because the measured values deviate early on.
At 50µs/s, the frequency and voltage are already incorrect, and at 10ms/div they are clearly wrong.
(Previous measurements with 1 MHz:
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6103897/#msg6103897 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6103897/#msg6103897) )
This is a good test for anyone with a modern DSO, even if just to get some experience with what AC RMS, STD, and Cycle RMS means. One can see on the display that if fractional parts of the waveform are displayed, then the RMS calculations can be affected, and when many cycles of the waveform are captured then the fractional part has less effect.
Theoretically, that should be the case. Unfortunately, the screenshots show the opposite: More cycles in the window -> larger error :( :-//
IMO, the screenshots are also inconsistent with the idea that only 1,000 decimated screen samples would be used for the measurements. If that were the case, how could it measure a frequency of 1.0 MHz (1 µs period) at 5 ms/div where the decimated screen sampling period is as large as 50 µs (20 kSa/s sample rate)? At this sample rate, 971 kHz would alias to 9 kHz, and that is the frequency/period that would be measured from the decimated screen samples (at best).
Not to get bogged down in this quagmire, maybe a new thread which can address the various behaviors of DSOs wrt to different types of waveforms. How these waveforms are represented, both displayed and numerically, could be useful information.
Best
-
Yes Norbert asks money for it, because he also offers other features, speed and bug fixing.
He would be crazy not to.
Show me video proof of those improvements, I only see talk and a few screenshots about it, but no real demonstration of those improvements. Also why there's no review from those who bought the mods?
-
Theoretically, that should be the case. Unfortunately, the screenshots show the opposite: More cycles in the window -> larger error :( :-//
"More cycles in the window" usually corresponds to a drop in sample rate.
Look at the sample rates in the images, they go down to 50 MSa/sec:
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6106031/#msg6106031 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6106031/#msg6106031)
-
How much confidence does that give you in the brand ?
From one side I agree with you how it sounds
On another hand I seen he also changed some ways how scope works so it is not limited to fixing some obvious bugs.
There are some things one could wish for Siglent too - it is more that Siglent made its firmware more "rounded" and Rigol done really bad job simply "asking" for someone to work this out...
And yes both approaches are discussable and Rigol should made a lot more to fix their stuff but regardless of unlocking things etc for me ideal scope would be kinda composed from good design frontend with some processing unit that we could conncet to PC to unlock more from it (kinda like old LeCroy scopes were when you upgraded CPU or whole mobo kit to i5 and got something in another class so concluding I think that Rigol not only treats persons like Norbert as marketing + factor for sale but also as modders whom can show them a way for different solutions (and I really think best move for them would be to simply pay them and use their talents but big companies are kinda slow in momentum and slower the bigger they get - best example is how fast Batronix implements things compared to others)
-
That was a good idea, because the measured values deviate early on.
At 50µs/s, the frequency and voltage are already incorrect, and at 10ms/div they are clearly wrong.
(Previous measurements with 1 MHz:
https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6103897/#msg6103897 (https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/msg6103897/#msg6103897) )
Sine wave AC RMS goes from ~200mV to ~280mV as if underlying data is now a square wave. AC RMS value should be less even with severe undersampling. Something fishy is going on with AC RMS calculation...
-
There are a few other things that seem strange in terms of why it was done this way and not differently.
For example, the display mode can only ever be vector... Why?
The same goes for interpolation.
With the DHO800, one could have argued that because it was very cheap, it had fewer settings.
But this is true of the entire 12-bit series, right up to the very expensive MHO5000.
Batronix wants the scope back soon, so hopefully I'll manage to complete the tests I wanted to do before then.
-
Rigol is totally aware of the hacking. I've spoken to people at Rigol who said so (they're probably reading this now - they read EEVBLOG, too).
Yeah but why stir the pot? Everyone already knew the answer wrt to support, its already clear. They may read the forum but not every thread and every post. Disappointing.
Show me video proof of those improvements, I only see talk and a few screenshots about it, but no real demonstration of those improvements. Also why there's no review from those who bought the mods?
Don't you think if just one person paid and got scammed they'd come here to complain? Its an odd POV.
https://www.eevblog.com/forum/testgear/rigol-hdo1000-and-hdo4000-12bit-oscilloscopes-launched-in-china/msg6100747/#msg6100747 (https://www.eevblog.com/forum/testgear/rigol-hdo1000-and-hdo4000-12bit-oscilloscopes-launched-in-china/msg6100747/#msg6100747)
And recent update is here: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mho900-scope/msg6108239/#msg6108239 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mho900-scope/msg6108239/#msg6108239)
-
How do I get a hold of Norbert Kiszka?? sounds like the guy I need to contact
Hi there I was looking to purchase the limited edition of the Rigol MHO98 but it turned out I was to late so I can now only purchase the MHO984 the only problem is that everything is an option with this unit, so I was wondering if anyone has a hack or know of a hack that I could easily do to the MHO984 to give me most of those features or options on the MHO98 I would definitely be willing to pay within reason for such a thing, please let me know Thank you.
-
How do I get a hold of Norbert Kiszka?? sounds like the guy I need to contact
Hi there I was looking to purchase the limited edition of the Rigol MHO98 but it turned out I was to late so I can now only purchase the MHO984 the only problem is that everything is an option with this unit, so I was wondering if anyone has a hack or know of a hack that I could easily do to the MHO984 to give me most of those features or options on the MHO98 I would definitely be willing to pay within reason for such a thing, please let me know Thank you.
Its in the second post (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mho900-scope/msg6101901/#msg6101901) in the thread above
-
XY Mode....
I almost forgot, but thanks to the posts in the other thread (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/msg6110059/#msg6110059), I didn't.
The menu for this is very clear, so you can't go wrong. ;)
And it's true that setting persistence and intensity in the display menu has no effect on the XY displays.
Only when color grading is activated does the display change color—for whatever reason.
On the other hand, I like the option of displaying the XY display on its own, and full-screen mode can also be activated.
This, in turn, makes me want to play some oscilloscope music... 8)
(Source: Batronix demo board, 5 kHz sine wave, fed into the board's BP filter, tap before (Ch1) and after the BP (Ch2))
-
Martin thank you so much, what is your opinion on the XY mode?
-
Hello,
I really like the fact that XY mode is displayed in full screen. I find this very useful in connection with a curve tracer.
Best regards,
egonotto
PS: Perhaps the MHO98 could be expanded into a nice curve tracer, as the function generators reach up to 20 V.
-
XY Mode, oscilloscope music...
That's the best I could get out of it; more is not possible.
The whole thing lacks detail, and it's a shame that you can't adjust the intensity.
Otherwise, the display is quite smooth.
https://www.youtube.com/watch?v=CASJSKcHdHc (https://www.youtube.com/watch?v=CASJSKcHdHc)
Settings: 1ms/div, 10kpt, 1MSa/s, Hires Mode
-
It's also a shame that they stretch the horizontal. Circles aren't circles anymore! If they're gonna change the aspect ratio, can't they add divisions so it's not distorted?
-
XY Mode, oscilloscope music...
That's the best I could get out of it; more is not possible.
The whole thing lacks detail, and it's a shame that you can't adjust the intensity.
Otherwise, the display is quite smooth.
https://www.youtube.com/watch?v=CASJSKcHdHc (https://www.youtube.com/watch?v=CASJSKcHdHc)
Settings: 1ms/div, 10kpt, 1MSa/s, Hires Mode
Did Rigol eliminate the "advanced XY options" menu items? I mean the menu items that are available on the DHO, by turning on "TestMode", where you can adjust XY intensity, wave width, persistence, etc. A step backwards if that menu is gone....
-
That was a good point, and lo and behold, this mode is also available on the MHO900. :-+
However, it should be implemented in the “normal” menu, rather than hidden in the developer options. ::)
I didn't notice any major changes during my brief test earlier, but I'll check again later, because the scope was very, very slow and unresponsive when XY mode was active.
I'll have to check that again later, too.
Decoding:
I don't have much time left with the MHO900, so I quickly tested the decoding with an I²C signal from the Batronix demo board.
One thing that is a bit annoying when adjusting the settings in the menu is that the previously set thresholds change again when selecting other menu items; they then shift to 16V and 10V, for example, which makes no sense at all.
The display without a table is a bit confusing when ASCII is selected as the display mode.
What I like is that you can “turn off” the window with the channels and then display the table in its entirety, similar to the FFT display.
What I don't like is the “Copy Trigger” function.
With Siglent Scopes, you can choose between “Copy to Trigger” or “Copy from Trigger.” Here, it's called Copy Trigger, which means Copy from Trigger.
If you do that, the thresholds are reduced by a factor of 10—which doesn't make any sense either.
So, stay away from it...
You can stop and zoom out, then you will see more packets in the table, so I assume that decoding is not only done from the screen.
What I noticed during this time was that the data stream/decoded display regularly fails.
You can also see the “blank spots” when you zoom out further. I'm still trying to figure out why this is happening.
Next weekend will be the last one with the Rigol, after that it will be gone again.
Martin
-
Advanced XY settings are available only in hidden "TestMode".
Rendering is also almost the same as in DHO800/900. The same 1000 screen points.
-
We already clarified that, see previous post.
What remains to be done is to test whether it has a noticeable effect; yesterday it didn't work for some reason.
-
That had been bothering me, so I had been playing around with the advanced settings earlier.
Maybe it's due to the test signal (5 kHz sine input, BP output), but not much happens—except that I can make the signal “thinner.”
If I can manage it somehow on the final weekend, I'll try the advanced settings again with the “oscilloscope music.”
-
The horizontal stretching makes the vertical portion of the lines look thicker than they should. The full-screen XY mode is a fail.
-
Two Tone Test....
2-channel frequency generator (SDG6052X) connected to the Rigol via splitter (-6dB attenuation) and -20dB external attenuators.
Frequencies: 10+10.1kHz, 100+100.kHz, 1+1.01Mhz, 10+10.01Mhz
Level first -26dBm, then -3dBm, finally +6dBm.
FFT mode averaging 10times
Martin
-
Due to the maximum number of images per post, here are the 10 MHz...
-
Here is the revised and expanded waveform update rate test.
I have now expanded it to 1 ms and up to 4 channels.
The consistency in the upper part of the table is remarkable, but this is no surprise because it is in (not changeable) vector mode.
The interpolation cannot be changed either, so that overall, a compact table was created. ;)
I will send it back soon, then I will draw a conclusion.
Martin
(https://www.eevblog.com/forum/testgear/rigol-mho900-testreview-(mho984)/?action=dlattach;attach=2708027;image)
-
The interpolation cannot be changed
It can be hacked to linear for 99.9%. I did the same with DHO800/900 firmware (selection in acquisition settings).
-
I know it's possible, but let's stick to the official delivery status.
-
So, tomorrow the MHO984 will go back to Batronix—at this point, I would like to express my sincere thanks to them once again. They didn't have to do it, as it would turn the device into a used one, but they did it anyway. :-+
I think it will then become a demo unit, so that someone else can borrow it before buying one.
Conclusion:
If, like me, you owned a DHO800, a DHO4000, and even had an MHO5000 here for testing, you won't be particularly surprised when you encounter the MHO900 for the first time.
All models have the same UI, which usually offers the same features, meaning that it makes little difference whether you buy the cheapest model (DHO800) or an expensive one (MHO5000); apart from the number of decoder types, you will not gain any further advantages.
On the contrary, the DHOs lack the internal AWG, the Bode plot, and the logic analyzing function.
One positive thing I noticed about the MHO900 is that some bugs have apparently been fixed and additional features that I had previously missed in the other models have been implemented.
For example, the Bode plot is now functional, the FFT has been significantly improved with the peak and average functions, and the different coefficients have been fixed.
But Rigol wouldn't be Rigol if they hadn't stopped halfway again.
For example, a marker function would be desirable for the FFT, as would manual selection of memory points.
In the case of Bode, the lack of settings for scaling is downright unforgivable, and switching between log/lin has no effect. Ultimately, the scaling with the strange horizontal lines makes no sense at all.
I suspect that the person who integrated this into the system at Bode doesn't really know what they've done.
Then there's “Light” again. I think the full-screen function is great, especially for such a small screen. It's worth its weight in gold and should definitely be emulated by all manufacturers who still offer scopes with 7" screens.
Unfortunately, the window display is still as inconsistent as before, meaning that you cannot move or enlarge/reduce the windows as you wish.
On the other hand, you can display a window on its own, even if it contains a math function, such as FFT, because you can choose whether math is generated from the current screen content or from memory—very good.
Speaking of the screen...
Overall, I find the display of the waveforms to be somewhat “cartoonish” in appearance.
You would expect 12-bit scopes to have a fine line display, especially with such a small display that still has a high resolution.
And 1024x600 is a high resolution for a 7" display.
Instead, it's rather “thick” and usually a bit blurry.
What's more, the interpolation and display mode are fixed and cannot be changed – I'm sure there's a reason for that...
Is this a good or bad scope?
Neither, I would say.
There are a few things I just don't like, and some things that are a no-go for me.
But basically, it's a usable scope, no question about it.
Because there's one thing you mustn't forget:
For the money, you won't find anything comparable in terms of key specifications anywhere else.
That's a fact that cannot be disputed.
Even if you leave the entry-level model MHO934 as it is, 350 MHz, 4 GS/s max, 100 Mpts memory, and 50 Ohm inputs for just under €1000 simply cannot be beaten.
If we assume the current reality, it looks like you buy an MHO934 and hack it to the top model.
That means for just under €1,000, you get a bandwidth of 1 GHz, 500 MB of memory, an internal 100 MHz 2-channel generator... It's crazy. :scared:
The fact that Rigol's MHO900 model renders many of their 12-bit scopes obsolete is their problem; I stopped trying to understand Rigol's model policy a long time ago.
Personally, I would definitely prefer the SDS800X HD from Siglent in the 7“ class because it simply comes across as more ”professional" with a much more mature UI and features.
It also costs significantly less. For the price of an MHO934, I can buy an SDS800X HD plus an external (and much better quality) AWG (SDG1000X) and would ultimately get much more benefit.
But it doesn't have the bandwidth and memory of an MHO900.
If that's more important to you, then there's currently no way around the MHO900, and that's likely to remain the case for a long time to come.
So:
I like the MHO900, but it wouldn't be my first choice.
In the “Rigol world,” however, it's likely to be the ultimate temptation for Rigol fans. :-+
Thanks for reading. I will post links to the individual tests in the next few days. Otherwise, this thread will remain open for questions and answers about the tests.
Finally, here are the pros (+), neutrals (o), and cons (-)—always from my point of view, of course, which should not be forgotten.
+ Compact design
+ Max 1Ghz bandwidth, 4GSa/s max, 500Mpts max
+ HDMI output
+ Fast integrated web server
+ 50 Ohm inputs
+ Generally fast thanks to 6-core SoC
+ Significantly improved FFT function/features compared to other Rigol models
+ Bode plot is now functional
+ Full screen mode
+ Math function selectable between screen and memory
+ Measurement parameters can now be changed as desired in terms of source; previously, the parameters had to be deleted and redefined in terms of source.
+ (Optional) internal 2-channel AWG with 100 MHz bandwidth
+ Unmatched price/performance ratio based purely on key data
o Noticeably loud fan
o Glossy screen
o Long boot time
o Average background noise from front end
o Limited control over window functions
- FFT function: No markers
- FFT function: No manual memorypoints selectable
- Bode plot function: No scaling options
- Bode plot function: Log/Lin switch does not work
- Bode plot function: Scaling display unusual
- Various bugs in the menus
- No interpolation selection possible
- No display mode selection possible
- Drastic reduction in bandwidth/sample rate with 3 or more active channels (affects MHO984/MHO098)
- Intensity grading: no setting options for color grade
- XY mode: No intensity adjustment possible
- XY mode: Display is stretched
- Screen display generally not “suitable” for a native 12-bit system, looks more like 8-bit.
- Waveform update rates: Maximum slightly above 26,000 Wfms/s
- No customizable colors for channels, math functions, references
Martin
-
Thanks for the detailed review. The MHO900 series definitely looks like an oddball in many ways. It definitely has no equivalent price-wise with those specs, and yet it seems a bit half-baked, which, again at this price, is absolutely logical.
I think I'll personally pass - for my use cases, I'll probably stick to an older, higher bandwidth/sample rate, 8-bit scope, and will get a 12-bit scope with lower bandwidth but better firmware and noise floor.
-
I am a bit disappointed, there's only the hope that sometime soon Rigol releases a firmware update to address some of these very valid points....
-
I received my MHO98 today and thought I'd give this a try..
This is with TestMode on, and after tweaking the persistence settings a little ... I mean, it's still no CRO, but I was actually kind of surprised at how legible some of it was.
https://youtu.be/baEWYIbRm1I?si=8Ziyt3fYgZAiM-Ue
Settings: 2ms/div, 10kpt, 500kSa/s, Peak Mode
-
Your findings seem pretty much in line with what I've seen so far with mine - Batronix and Rigol should be thanking you for how much effort has been put into your testing!
I was on the fence a bit about cancelling my MHO98 order given the mixed impressions here, but then it arrived and I saw how damn small it was - the portability plus the features it has that my other scopes don't (500MPoints, 1/2ch BW, 50ohm inputs) means I'm going to keep it. Will probably still use my RTB2k (once I fix the front end yet again...) as a daily driver because of the much more usable screen resolution/size, low fan noise and the 10s boot time; the Rigol will come out when I need it specifically or want to use a scope away from the bench.
-
I received my MHO98 today and thought I'd give this a try..
This is with TestMode on, and after tweaking the persistence settings a little ... I mean, it's still no CRO, but I was actually kind of surprised at how legible some of it was.
https://youtu.be/baEWYIbRm1I?si=8Ziyt3fYgZAiM-Ue
Settings: 2ms/div, 10kpt, 500kSa/s, Peak Mode
Cool, that's better. But I think Siglent scopes still do that better.
-
There are various examples that confirm your assumption:
https://www.eevblog.com/forum/testgear/oscilloscope-music-on-dsos-post-your-results/msg5446613/#msg5446613 (https://www.eevblog.com/forum/testgear/oscilloscope-music-on-dsos-post-your-results/msg5446613/#msg5446613)
@pizzigri:
I am a bit disappointed
I'm less concerned because a) I've known Rigol a little longer and b) the price is still hot.
Some bugs that I noticed three years ago have been fixed in the MHO900, so there is hope that work will continue on this, albeit rather slowly. ;)
Batronix and Rigol should be thanking you for how much effort has been put into your testing!
Thanks, but Batronix not so much, because they lent me the scope.
Rigol, on the other hand...
I did something I hadn't done in six years and sent them the list of negative points from my post as suggestions for improvement.
And I offered to test the possible updates. ;)
Let's see if I get a response.
-
Sine wave AC RMS goes from ~200mV to ~280mV as if underlying data is now a square wave. AC RMS value should be less even with severe undersampling. Something fishy is going on with AC RMS calculation...
In understood that there is consent that some kind of decimation is happening if there is "too much data" captured to increase the refresh rate. This decimation influences most measurements this way or the other. It was already stated that the behavior changes as soon as the zoom mode is activated (no decimation, slower refresh rate).
I haven't really tried to investigate myself though and I would still consider this unexpected behavior and would prefer if there was a setting "fast measurements" (or something like that) to switch on/off this decimation explicitly.
-
Adding some FFT capture, performing an IMD two tone testing over an ssb transceiver. 3rd products are < 30db under PEP output.
Peaks 1,2: modulation tones. Peaks 3,5: 3rd intermodulation products. Peaks 4,6: 5th intermodulation products.
Test gear:
- Rigol MHO984
- -50db hf sampler
- Siglent SDG2042X Upgraded
- DUT: Icom 725. two tone test (14.1Mhz modulated with 790Hz + 1900Hz) at 100W pep SSB.