Hacking the Rigol DHO800/900 Scope

[Omega64]

Hello dudes,
not sure if I'll buy a DHO1074 (currently available with a super discount) or a DHO9x4S. In the thread about the Bode Plot function of the latter, it seems that it's buggy, even with the latest firmware updates. I can wait (have 2 other higher end oscilloscopes, a Tektronix and a Siglent, the Rigol would be an extra) but I'd have preferred to exploit the discount I can get now (and probably around Black Friday).

350MHz probes apart, is it 100% certain that the DHO914S and DHO924S have exactly the same identical hardware, and that the former can be completely hacked into the latter?

Cheers.

[swperk]

I've attached photos of the performance of my bandwidth upgraded DHO914S. I can see no difference (other than the probes) between mine and an "official" DHO924S.

I used a Leo Bodnar fast rise time pulse generator into a 50 ohm pass-through terminator to measure a 1.3 ns rise time. I used the "analog scope" formula of 0.35/rise time to calculate an approximately 269 MHz bandwidth. Then I used a calibrated signal generator to find the -3 dB point using 100 MHz as a reference level. The 620 mV p-p measured at 100 MHz was reduced to 620 mV / SQRT(2), or about 438 mV p-p at 305 MHz. Looks like the bandwidth formula for this scope should be revised to BW = 0.4/rise time.

[Mechatrommer]

0.35/rt for gaussian scope. Otherwise 0.45/rt..

[Fungus]

I've attached photos of the performance of my bandwidth upgraded DHO914S. I can see no difference (other than the probes) between mine and an "official" DHO924S.

There's no difference internally but the DHO924 comes with better probes.

Looks like the bandwidth formula for this scope should be revised to BW = 0.4/rise time.

Use 0.45 for DSOs:

https://www.tek.com/en/support/faqs/how-bandwidth-related-rise-time-oscilloscopes

[ebastler]

0.35/rt for gaussian scope. Otherwise 0.45/rt..

"Gaussian scope" is a misnomer, I think. A Gaussian filter is a bandpass with a Gaussian-shaped frequency response (and hence also a Gaussian-shaped impulse response); not used in scope front ends to my knowledge. The 0.35 conversion factor between risetime and bandwidth applies to first- or second-order lowpass filters; 0.45 is the "rule of thumb" for the steeper filters often used today.

[ebastler]

Misnomer? Are you saying tektronix is stupid?

Could you give a reference please? Where does Tektronix talk about "Gaussian oscilloscopes" or Gaussian filters in the front end?

[ebastler]

Could you give a reference please? Where does Tektronix talk about "Gaussian oscilloscopes" or Gaussian filters in the front end?

Why today somebody else has to do someone's else homework?   https://www.tek.com/en/support/faqs/how-bandwidth-related-rise-time-oscilloscopes#:~:text=Historically%2C%20oscilloscope%20frequency%20response%20tended,Bandwidth%20x%20rise%20time%20%3D%200.45.

And where exactly does that short text talk about "Gaussian scopes" or "Gaussian anything"?

Mate, I understand the 0.35 vs. 0.45 factors, and I summarized that just a couple of posts above. My point is that your terminology is wrong and misleading. ("Misnomer", you know? A wrong or inaccurate use of a term.) This has nothing to do with Gaussian filters.

[Mechatrommer]

I meant keysight/hp ... read!... https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://f.hubspotusercontent40.net/hubfs/281197/Keysight_Evaluating_Oscilloscopes_AppNote_CControls.pdf&ved=2ahUKEwj07rStk8iCAxUfi2MGHXCfBQUQFnoECAoQBg&usg=AOvVaw0xDwW53v3efGuzk-2vb-CF

[ebastler]

I meant keysight/hp ... read!... https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://f.hubspotusercontent40.net/hubfs/281197/Keysight_Evaluating_Oscilloscopes_AppNote_CControls.pdf&ved=2ahUKEwj07rStk8iCAxUfi2MGHXCfBQUQFnoECAoQBg&usg=AOvVaw0xDwW53v3efGuzk-2vb-CF

That's a strange one... I would actually call their definition of "Gaussian frequency response" a misnomer too. ("A low-pass frequency response that has a slow roll-off characteristic that begins at approximately 1/3 the –3 dB frequency".)

Every other text I have seen defines a "Gaussian frequency response" very specifically as a frequency response that follows Gauss' "bell curve", i.e. g(f) ~ exp (-f²/a). This specific frequency response is not required to obtain the 0.35/risetime relationship, and it is not present in typical scope front ends.

All actual derivations of the 0.35 factor which I have come across assume a plain old first-order or second-order lowpass filter. Probably a real Gaussian filter would give a similar factor. But focusing the whole bandwidth discussion on Gaussian filters, as Keysight does, seems misleading to me.

[gf]

That's a strange one... I would actually call their definition of "Gaussian frequency response" a misnomer too. ("A low-pass frequency response that has a slow roll-off characteristic that begins at approximately 1/3 the –3 dB frequency".)

Every other text I have seen defines a "Gaussian frequency response" very specifically as a frequency response that follows Gauss' "bell curve", i.e. g(f) ~ exp (-f²/a). This specific frequency response is not required to obtain the 0.35/risetime relationship, and it is not present in typical scope front ends.

All actual derivations of the 0.35 factor which I have come across assume a plain old first-order or second-order lowpass filter. Probably a real Gaussian filter would give a similar factor. But focusing the whole bandwidth discussion on Gaussian filters, as Keysight does, seems misleading to me.

Primarily, a Gaussian filter has a Gaussian impuse response, and that results in a lowpass filter (not bandpass as you said in a previous post). The magnitude of the frequency response also has a Gaussian bell shape, centered at 0Hz (if you consider both, positive and negative frequencies in the Fourier frequency domain). And the corresponding log magnitude (-> decibel scale) is a quadratic function of frequency.

[ Generally, bandpass filters can be derived from their corresponding lowpass prototypes. So Gaussian bandpass filters do exist as well. However, a Gaussian bandpass does not have a Gaussian impulse response (it's a cosine wave with Gaussian envelope). ]

The risetime * bandwidth product of an ideal Gaussian (lowpass) filter is 0.332.

A filter with Gaussian impulse response has the shortest rise time which is possible without overshoot in the step response. There exist filters with same bandwidth and shorter rise times, but they do overshoot. A "maximally flat" frequency response will always overshoot.

A true Gaussian response can only be approximated, in both domains, analog and digital. At least in the analog domain, never expect a perfect approximation. In the digital domain, the approximation accuracy is, of course, just a matter of the number of FIR filter taps you are willing to spend.

[ebastler]

Primarily, a Gaussian filter has a Gaussian impuse response, and that results in a lowpass filter (not bandpass as you said in a previous post). The magnitude of the frequency response also has a Gaussian bell shape, centered at 0Hz (if you consider both, positive and negative frequencies in the Fourier frequency domain).

[ Generally, bandpass filters can be derived from their corresponding lowpass prototypes. So Gaussian bandpass filters do exist as well. However, a Gaussian bandpass does not have a Gaussian impulse response (it's a cosine wave with Gaussian envelope). ]

Right, thanks for the correction. But do we agree that Keysight's definition of "Gaussian frequency response" is rather misleading? -- Anyway, it seems that their main message, at the end of the application note, is simply: "Some cheap competitors have a really messy frequency response. Buy a Keysight." 

[gf]

Right, thanks for the correction. But do we agree that Keysight's definition of "Gaussian frequency response" is rather misleading?

Read it as "approximately Gaussian". As long as you don't quantify the deviation, it's always correct. You can also consider Bessel as an approximation for Gaussian (although the design goal of Bessel is a different one).

[Martin72]

Looks like the bandwidth formula for this scope should be revised to BW = 0.4/rise time.

I had also first determined the rise time with the Bodnar pulser and then calculated the bandwidth with the 0.45/rt formula.
Then I measured the actual bandwidth with a generator, which worked well.

[Omega64]

I've attached photos of the performance of my bandwidth upgraded DHO914S. I can see no difference (other than the probes) between mine and an "official" DHO924S.

There's no difference internally but the DHO924 comes with better probes.

Better probes objectively, but maybe not in reality when used on a shared 1.25GS/s ADC: won't the 350MHz probes only cause more aliasing, except when using just one channel?

[Fungus]

Better probes objectively, but maybe not in reality when used on a shared 1.25GS/s ADC: won't the 350MHz probes only cause more aliasing, except when using just one channel?

I compared the rise times on my hacked "200Mhz" DSO804 with 150Mhz probes vs. 50-Ohm BNC. It made very little difference.

Based on that I assume the real-world bandwidth difference between the 150Mhz and 350Mhz probes will be negligible on these 'scopes.

Maybe the 350Mhz probes aren't really a bonus from the probing point of view. Does anybody know if they feel better?

[zelea2]

I don't have a DHO800 scope yet but I'm ordering one soon   

I've ordered a DHO804 from Aliexpress https://www.aliexpress.com/item/1005005962731116.html for only £321 (chinese singles day).
To my surprise I've got the scope only 3 days later without having to pay any other VAT or customs fees (probably was shipped from UK not China). Brilliant deal!

I've plugged it to my LAN network, pulled the Key.data and vendor.bin files (via adb) and installed these 2 licenses: BW7T10.lic  RLU.lic to increase the front end bandwidth and the memory depth.
The whole process was painless and took less than 5 min.

I've also noticed an SSH server running on the scope. Does anyone know what's the default root password?

[gf]

I had also first determined the rise time with the Bodnar pulser and then calculated the bandwidth with the 0.45/rt formula.
Then I measured the actual bandwidth with a generator, which worked well.

Was the Bodnar pulser directly connected to the 1M Ohm input (-> 50 Ohm || C_in), or via feed-through terminator (-> 25 Ohm || C_in) ?

[tautech]

I had also first determined the rise time with the Bodnar pulser and then calculated the bandwidth with the 0.45/rt formula.
Then I measured the actual bandwidth with a generator, which worked well.

Was the Bodnar pulser directly connected to the 1M Ohm input (-> 50 Ohm || C_in), or via feed-through terminator (-> 25 Ohm || C_in) ?

https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5106120/#msg5106120

[Martin72]

Yepp,
It's one from Huber&Suhner.
https://www.ebay.com/itm/266252468369

[Serg65536]

With the new firmware V 1.02 I have a good and a little bit of a bad news. (DHO800 CN page or direct link)
1) Now I can use DHO924 as a main firmware, zero offset could be removed by the calibration. And the voltage accuracy is great also.
2) Now ADC Gain self test is turned on by default.
3) AFE zero self cal procedure increases the DC offset badly. To restore it you can push old cal files and repeat default calibration.


Now it's time to hack it more.
PS: push original old *.cal files (without default *.cal files), if your calibration fails.

[Mechatrommer]

1) Now I can use DHO924 as a main firmware, zero offset could be removed by the calibration. And the voltage accuracy is great also.

great! but where is the AFG (bode plot) function?

[Serg65536]

1) Now I can use DHO924 as a main firmware, zero offset could be removed by the calibration. And the voltage accuracy is great also.

great! but where is the AFG (bode plot) function?

I use DHO924 vendor.bin without "S" postfix.

[Martin72]

And the voltage accuracy is great also.

5mV/div is interesting..

[swperk]

Where can I download firmware version 1.02? The Rigol NA site has only 1.01.

[Martin72]

I wouldn´t do this until rigolna list it too.
You may see the problems I had with this yesterday.
I can still remember my MSO5000 days.
Not every firmware update was listed everywhere back then, some Chinese versions turned out to be beta status and didn't even make it onto the American and European websites.
There is no need for it at the moment, I would wait.