Hacking the Rigol DHO800/900 Scope

[Njk]

FYI - my small hw mod.. 

That's why I don't like that DHOs. This amount of graphics seems appropriate for at least 10" screen. And this external PSU with a mobile phone connector all the way remind user that he's dealing with something very cheap

[Njk]

If you are referring to the noise quantified in e.g. µV rms, why would it be any different? It's the exact same data, acquired with the same amplification setting. The data are just rendered differently (namely zoomed-in) on the screen.

Yes it's rendered differently. If you simply increased the zoom level, the noise would be increased proportionally, which is not the case

[RAPo]

Oke + again, thanks.

...
Yes, I have already raised the bottom edge of the results above the X-axis. I just haven't posted this updated version yet, I want to resolve the issue with the color coding of the channels in the results, based on the fair comments made here.

[ebastler]

If you are referring to the noise quantified in e.g. µV rms, why would it be any different? It's the exact same data, acquired with the same amplification setting. The data are just rendered differently (namely zoomed-in) on the screen.

Yes it's rendered differently. If you simply increased the zoom level, the noise would be increased proportionally, which is not the case

We seem to have our wires crossed here. My take is: Say the physical amplifier setting 1 mV/div and there is an RMS noise of 50 µV on the acquired signal. If you now enable zoom in software to go to 500 µV/div, it will still be 50 µV RMS noise -- it will just be shown larger on the screen.

Are you contradicting the above and think that clever filtering is required to keep the noise at 50 µV? Or are you saying that the noise does not become visually larger on the screen, and that its µV RMS value is actually getting lower as you zoom in?

[Vovas]

Is it possible to extend FFT?

[TheoB]

What we should see as the noise background?
When I terminate ch4, for example, with 50ohm terminator and I look at the noise I see 340uVpp BW OFF, and 225uVpp BW 20MHz, DC at 500kSa/s and 1Mpts (after upgrade to 1.04).

Peak-to-peak is not a very meaningful or comparable metric for Gaussian-like noise because the probability distribution is unbounded. Instead, measure the standard deviation (some scopes call it AC RMS).

BW 20MHz     Avg. 39uV AC RMS, drops down to 33uV after some time (due to Avg math?)

BW OFF         Avg. 60uV AC RMS, drops down to 50uV after some time (due to Avg math?)

FYI - after the 824 mod:

DC at 500kSa/s and 1Mpts

BW 20MHz     Avg. 53.6uV AC RMS

BW OFF         Avg. 110uV  AC RMS

DC at 500kSa/s and 100kpts

BW 20MHz     Avg. 24.7uV AC RMS

BW OFF         Avg. 49.7uV  AC RMS

The noise is mostly from the lower frequencies:

The scope measures 52.2uV rms.
Below 4MHz noise is dominated by 1/f (flicker) noise. Above that the noisefloor of my scope is -170dBV/sqrt(Hz) at 1mV/div all the way to about 250MHz (BW limit as I upgraded from DHO804 to DHO924 thanks to all the kind hackers on this forum  ).
Lower vertical settings does not matter as it's only display scaling. The bandwidth becomes limited to 20MHz if 200uV/div is selected. That's what I show on the right.
The noise is measured with a brickwall/boxcar filter using dho-remote

Here I captured the noise all the way down to 1.25Hz:

Termination with 50 Ohm (left) only matters for the flicker noise. Above a few MHz the white noise is the same.
This second plot suffers from noise folding. All 250MHz bandwidth noise is folded to 625kHz which makes the noise increase by 26dB (in case someone wonders why the noise traces do not match  ).
If you see changes then I would not be surprised that it is caused by the lower end of the spectrum below 4MHz. That's the part that is not very well under control in semiconductors. The noise is believed to come from semiconductor interface traps. And from experience I know that that noise can be much higher just for some samples. A manufacturer could select on that, but that's more for the higher tier brands.

[AndyBig]

PS: you may try an another experiment which may support my suspicion - simply let run the scope for couple of hours and make the selfcal. Then let the scope cool down for a day or so and after the powering it on look at the 500uV range (DC) with 50ohm terminator in the BNC. Look at what the initial offset and noise will be and how it moves/changes with time (as the scope heats up)..

I did the following experiment.
The oscilloscope worked for about 4 hours, after which I calibrated it and immediately measured the noise level:
DC at 500kSa/s and 1Mpts

• BW 20MHz Avg. 22.597 uV AC RMS
• BW OFF     Avg. 48.554 uV AC RMS

DC at 500kSa/s and 100kpts

• BW 20MHz Avg. 22.546 uV AC RMS
• BW OFF     Avg. 48.580 uV AC RMS

After that, I turned off the oscilloscope for about 5 hours. After turning it on, I immediately measured the noise level:
DC at 500kSa/s and 1Mpts

• BW 20MHz Avg. 22.819 uV AC RMS
• BW OFF     Avg. 48.190 uV AC RMS

DC at 500kSa/s and 100kpts

• BW 20MHz Avg. 22.554 uV AC RMS
• BW OFF     Avg. 47.472 uV AC RMS

I left the oscilloscope turned on for about 2 hours and measured the noise again:
DC at 500kSa/s and 1Mpts

• BW 20MHz Avg. 22.736 uV AC RMS
• BW OFF     Avg. 48.686 uV AC RMS

DC at 500kSa/s and 100kpts

• BW 20MHz Avg. 22.484 uV AC RMS
• BW OFF     Avg. 48.592 uV AC RMS

Do you disable ROLL in horizontal scanning? Or does your scanning automatically switch to ROLL at 1Mpts?

[iMo]

All my previous measurements were made with "WAVEFORM VIEW(ROLL), and it was rolling, indeed.
It set itself automatically in that rolling mode.

With manually set "WAVEFORM VIEW" the situation is as follows:

500kSa/s, 1Mpts, none averaging, DC

BW OFF        37.2uV      Avg. AC.RMS
BW 20MHz    24.3uV      Avg. AC.RMS

500kSa/s, 100kpts, none averaging, DC

BW OFF        37.1uV      Avg. AC.RMS
BW 20MHz    24.2uV      Avg. AC.RMS

[AndyBig]

All my previous measurements were made with "WAVEFORM VIEW(ROLL), and it was rolling, indeed.
It set itself automatically in that rolling mode.

With manually set "WAVEFORM VIEW" the situation is as follows:

500kSa/s, 1Mpts, none averaging, DC

BW OFF        37.2uV      Avg. AC.RMS
BW 20MHz    24.3uV      Avg. AC.RMS

500kSa/s, 100kpts, none averaging, DC

BW OFF        37.1uV      Avg. AC.RMS
BW 20MHz    24.2uV      Avg. AC.RMS

Well, that's a completely different matter

[iMo]

..Well, that's a completely different matter

I've asked DeepSeek on the typical noise floor of today's oscilloscopes (with 50ohm termination), and, within its reasoning he/she/it mentioned EEVBLOG:

Wait, another approach: check the EEVblog forum or similar resources. From what I remember, Dave Jones mentioned that a typical 1 GHz scope might have around 1 mVrms noise when terminated in 50Ω.

Cool thing the DS.. 

[AndyBig]

..Well, that's a completely different matter

I've asked DeepSeek on the typical noise floor of today's oscilloscopes (with 50ohm termination), and, within its reasoning he/she/it mentioned EEVBLOG:

Wait, another approach: check the EEVblog forum or similar resources. From what I remember, Dave Jones mentioned that a typical 1 GHz scope might have around 1 mVrms noise when terminated in 50Ω.

Cool thing the DS.. 

Heh, I asked the AI ​​that helps me edit the code (Cursor AI) and here's his answer:

The typical noise level (Vertical Noise) for modern digital oscilloscopes with bandwidth up to 500 MHz is usually in the range of:

• For 8-bit oscilloscopes: 0.5 - 1.0 mV RMS at 1 mV/div setting
• For 10-bit oscilloscopes: 0.15 - 0.3 mV RMS at 1 mV/div setting
• For 12-bit oscilloscopes: 0.05 - 0.1 mV RMS at 1 mV/div setting

For example:

• Rigol DS7054 (500 MHz, 10-bit): ≤ 0.4 mV RMS at 1 mV/div
• Tektronix MSO5 (500 MHz, 12-bit): ≤ 0.1 mV RMS at 1 mV/div
• Keysight DSOX3054T (500 MHz, 8-bit): ≤ 0.8 mV RMS at 1 mV/div

The noise level depends on:

• Vertical resolution (number of bits)
• Input coupling (AC/DC)
• Bandwidth limit settings
• Vertical scale setting
• Probe attenuation
• Environmental conditions

He didn't mention Eevblog, but he did give Rigol as an example

[iMo]

Now, why the rolling waveview is 2-3x higher rms than the none-rolling? DS told me it is because of a different signal processing of the data off the buffers, or something like that.. ??

PS: btw., the coolest stuff with DS is its DeepThink's reasoning, I like it..
And Dave should be carefull what he says and writes as on that the future Mankind Wisdom will be based 

[TurboTom]

I guess at these slow time base settings that enable the rolling display mode, the 1/f noise becomes predominant, hence the slower the timebase setting, the higher the RMS noise to be measured. IMO, it would make good sense to agree on an instrument setup for noise measurement "ranking" to produce comparable results.

[iMo]

But the sampling rate and time base in the rolling are the same as with the none-rolling, afaik, at least in our above examples (500kSa/s, 1MPts, 100ms, BW 20MHz)..

At 1mV/div the same - rolling 38.2uV, none-rolling 24.5uV (ac.rms)

Closer into the 1/f area (10kSa/s, 1Mpts, 10s, 1mV/div, BW 20MHz):

rolling 45uV ac.rms, not rolling 24uV ac.rms

[AndyBig]

I have the impression that the measurements are not calculated based on the ADC readings, but on the signal displayed on the screen.

[iMo]

Yup, but why are the pictures on the screen fatter with rolling than with none-rolling?

[TurboTom]

Yes, you are correct -- I could duplicate that. I attached two screenshots of a noise measurement @100ms/div, "Auto" mem depth, open input on CH1, 50Ohms terminator on CH4. A considerable difference can be ovserved in the measurement (69µV "normal" vs. 118µV "roll mode" at the open input channel). What's peculiar is that the measurements are taken much more quickly in roll mode, i.e. the measurement counter is running at a much higher speed. I assume that in normal mode, the measurement is taken only after a complete trace has been recorded (makes sense...) while in roll mode, maybe a measurement is taken everytime a division has been filled (assumption based on the measurement counter speed).

Anyway, still approximately the same RMS noise should be measured, the result in "normal mode" should rather be slightly higher due to the broader measurement window and lower frequency 1/f component that should contribute to the reading. When zooming in on the stopped trace, both normal and roll mode traces look pretty much similar, there's no hint that a different acquisition mode may lead to the contradicting results.

I guess Rigol messed soemthing up here and you found a real bug in the measurement "engine". The question arises, if this roll mode measurement is buggy, how reliable are the others? 

[iMo]

Would be interesting to compare it with other similar scopes..

[ebastler]

Heh, I asked the AI ​​that helps me edit the code (Cursor AI) and here's his answer:

For example:

• Rigol DS7054 (500 MHz, 10-bit): ≤ 0.4 mV RMS at 1 mV/div
• Tektronix MSO5 (500 MHz, 12-bit): ≤ 0.1 mV RMS at 1 mV/div
• Keysight DSOX3054T (500 MHz, 8-bit): ≤ 0.8 mV RMS at 1 mV/div

He didn't mention Eevblog, but he did give Rigol as an example

Now if only the data the AI gave you had some connection with reality...

There is no published noise spec for the Rigol, and I could not find any numbers during a quick search -- hence no idea where that number came from. Tektronix and Keysight do publish specs, and they differ from the AI data: The Tek MSO5 is worse than claimed, 0.2 mV RMS noise at 500 GHz, 50 Ohms, in High-Res mode -- presumably even worse without High-Res. In contrast, the Keysight is better than stated, specified at 0.3 mV RMS for 1 GHz bandwidth.

Which AI did you use -- ChatGPT, trying to please its users as usual, by never admitting that it doesn't know an answer?

[AndyBig]

Which AI did you use -- ChatGPT, trying to please its users as usual, by never admitting that it doesn't know an answer?

I used claude-3.5-sonnet. Although all AIs are capable of generating nonsense when they don't know the answer )

[iMo]

FYI - here is the thinking and the answer of DS/DT to my Q re the roll vs. none-roll waveview noise difference.. 

[AndyBig]

FYI - here is the thinking and the answer of DS/DT to my Q re the roll vs. none-roll waveview noise difference.. 

It's interesting to read his reasoning, but in the end it's clear that nothing is clear )

[AndyBig]

I think I've solved the problem with displaying channels in measurements. For people who have difficulty distinguishing colors, you can enable the mode with displaying channel names (this is the default mode after turning on the oscilloscope). And those who distinguish colors well and want to reduce the width of the measurement panel can switch to color coding of results, without channel names. Switching between these two modes is done in the standard menu, which is called by clicking on the measurement item. I just added another item to the end of this menu to switch between names and colors.
I also darkened the background a little and made it less transparent so that the blue color of the fourth channel is readable on it.

https://youtu.be/Jm-stwADROI

[RAPo]

This is coming nicely together, Andy, thanks for your continuing effort.
Maybe it is a personal thing, but I don't like the space between the measurement items where the signals peep through.
Is it possible to have one 'block' and each item separated by a gray line?

[TurboTom]

I'ld also like to express my respect and gratitude for this amazing effort of yours, Andy! IMO it's very generous to offer such an extensive job to the public free of charge.

I don't know how others think about it, but since a long time I disliked the seven-segment style font of the hardware frequency counter function. Do you think it's possible to replace that font with something that better blends in with the other U/I typefaces? I experimented with replacing the "digital_numbers.ttf" font directly on the scope with some sans serif font under the same name but didn't succeed.

Moreover, IMO it would be a substantial improvement if it's possible to detach the frquency counter window from the other measurements and place it arbitrarily on the screen, independent of the "result" box.

Thanks so much and all the best,
Thomas