Rigol's New DHO800 Oscilloscope unbox & teardown

[2N3055]

Be aware that peak detect is only effective if the ADC (and peak detector) is running fast enough. The same is true for high-res and random sampling. On the 924 this would not be the case anymore with 4 channels enabled. A switchable (analog) low-pass filter would certainly help, as would ETS (for periodic signals). I do not know if either is available on the Rigol.

They are not using filter (there is at least one for switching between models).
ETS is not available on these scope as no dot mode either...
On Siglent dot mode functions as a RIS and you can actually get great results for stable repetitive signals.

Complex 18kHz signal sampled at 200KS/s.
In vector mode (this is only mode Rigol has)
In Dot mode it reconstructs signal accurately.
Even SDS1000X-E can do this.

[2N3055]

Be aware that peak detect is only effective if the ADC (and peak detector) is running fast enough.

On Keysight peak detection mode will actually decrease sampling rate at certain timebases.
Peak detector mode is anyways a crutch, you cannot use FFT and measurements with it.
It destroys signal details, it is useful only to show signal envelope on screen.

[Mechatrommer]

Be aware that peak detect is only effective if the ADC (and peak detector) is running fast enough. The same is true for high-res and random sampling. On the 924 this would not be the case anymore with 4 channels enabled. A switchable (analog) low-pass filter would certainly help, as would ETS (for periodic signals). I do not know if either is available on the Rigol.

fair enough. with 4 channels on, the ADC already running fast enough but get divided to 312.5MSa/s for each channel, so there is no more room for ADC to contruct min-max data.. attached is 167MHz signal on 1 channel 1.25GSa/s (signal.jpg), with 4 channels turned on (no_limit.jpg), aliasing occured (312.5MSa/s) Peak and Normal acquisition not much difference at this ADC's fastest rate (shared). turning on 20MHz BW limit we can still see aliasing (20mhz_limit.jpg). so your theoritical utopia for no aliasing rule is a "Brickwall Filter" at sample rate / 2.5, how easy is that to make in HW? no ETS in DHO800 and DS1000Z..

btw, i tried touch pen that came with my EraSynth and NanoVNA, both cannot work on DHO800's screen too bad.. (pen.jpg) fwiw...

[Fungus]

btw, i tried touch pen that came with my EraSynth and NanoVNA, both cannot work on DHO800's screen too bad.. (pen.jpg) fwiw...

There's pens for resistive screens and pens for capacitive screens. You have to get the right type. 

[tautech]

Using a mouse is more effective but wait, for this need you only have 1 USB A port and it seems from reports a USB hub will freeze the scope.
We live in interesting times.

[TimFox]

btw, i tried touch pen that came with my EraSynth and NanoVNA, both cannot work on DHO800's screen too bad.. (pen.jpg) fwiw...

There's pens for resistive screens and pens for capacitive screens. You have to get the right type. 

The stylus I use with an iPad works on the Rigol touchscreen.

[Fungus]

Using a mouse is more effective but wait, for this need you only have 1 USB A port and it seems from reports a USB hub will freeze the scope.

I've been using a mouse and USB stick on a cheap hub all week with no problems.


I just got a nicer hub and that works, too.

[Someone]

Be aware that peak detect is only effective if the ADC (and peak detector) is running fast enough.

On Keysight peak detection mode will actually decrease sampling rate at certain timebases.
Peak detector mode is anyways a crutch, you cannot use FFT and measurements with it.
It destroys signal details, it is useful only to show signal envelope on screen.

I think people are confusing the several "sample rates" within a scope. The ADC sampling rate and acquisition sampling rate (which is the data stored to memory) are not always equal. And what happens between those steps is not consistent between difference scopes/brands.

The megazoom "issue" that you've pointed to (out of context) is those scopes reducing the acquisition sample rate when in non-8bit modes, (peak detect, averaging, high resolution) as the acquisition rate changes to fill the available aquitision memory (keeping the horizontal timebase the same). The ADCs keep running at their full rate for all acquisition modes, just as the Rigol do, tuning on more channels increases the multiplex to the ADCs and drops the per channel ADC sample rate (XXGS/s to 0.5*XXGS/s).

switchabl is correct that the ADC sample rate is determining the peak detect capture window (unless some scopes have analog domain peak detect?).

[kirill_maker]

Well, it can show RF signal on VHS VCR - its nice! But now I've stumbled on - why 2nd head isn't showing and not reacting to adjust of tape path - maybe its dead? Can I hook it up to video head directly - or output level will be to low for dho804?

[TurboTom]

...
I think people are confusing the several "sample rates" within a scope. The ADC sampling rate and acquisition sampling rate (which is the data stored to memory) are not always equal. And what happens between those steps is not consistent between difference scopes/brands.

The megazoom "issue" that you've pointed to (out of context) is those scopes reducing the acquisition sample rate when in non-8bit modes, (peak detect, averaging, high resolution) as the acquisition rate changes to fill the available aquitision memory (keeping the horizontal timebase the same). The ADCs keep running at their full rate for all acquisition modes, just as the Rigol do, tuning on more channels increases the multiplex to the ADCs and drops the per channel ADC sample rate (XXGS/s to 0.5*XXGS/s).

switchabl is correct that the ADC sample rate is determining the peak detect capture window (unless some scopes have analog domain peak detect?).

With "normal" sampling configuration, the DHO900 is actually boxcar averaging when the "Shadow Memory Sampling Rate" is lower than the ADC rate which apparently stays the same all the time (only activating additional channels multiplexes this sample rate over the enabled channels). See here: https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5109618/#msg5109618

[Mechatrommer]

...
I think people are confusing the several "sample rates" within a scope. The ADC sampling rate and acquisition sampling rate (which is the data stored to memory) are not always equal. And what happens between those steps is not consistent between difference scopes/brands.

The megazoom "issue" that you've pointed to (out of context) is those scopes reducing the acquisition sample rate when in non-8bit modes, (peak detect, averaging, high resolution) as the acquisition rate changes to fill the available aquitision memory (keeping the horizontal timebase the same). The ADCs keep running at their full rate for all acquisition modes, just as the Rigol do, tuning on more channels increases the multiplex to the ADCs and drops the per channel ADC sample rate (XXGS/s to 0.5*XXGS/s).

switchabl is correct that the ADC sample rate is determining the peak detect capture window (unless some scopes have analog domain peak detect?).

With "normal" sampling configuration, the DHO900 is actually boxcar averaging when the "Shadow Memory Sampling Rate" is lower than the ADC rate which apparently stays the same all the time (only activating additional channels multiplexes this sample rate over the enabled channels). See here: https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5109618/#msg5109618

how do you know its boxcar averaging?

[wasedadoc]

Well, it can show RF signal on VHS VCR - its nice! But now I've stumbled on - why 2nd head isn't showing and not reacting to adjust of tape path - maybe its dead? Can I hook it up to video head directly - or output level will be to low for dho804?

Try looking at the direct output from the rotary transformer for the head of the working channel.  Can you see its signal?

But each head is for one field (20ms 625/50).  Your 'scope trace does not show significant difference between alternate fields but the gaps between them are longer than I would expect.

[kirill_maker]

I've tried to adjust switching point on servo board - to try switching time, that's why gap can look not right for filed time. Yes, I will try on input of head amp.

[Fungus]

Can I hook it up to video head directly - or output level will be to low for dho804?

It's 12 bits and goes down to microvolts... try it and see!

...the gaps between them are longer than I would expect.

I don't think it's all gap, I think it's just very low signal level at the top of the screen that looks like a gap.

[kirill_maker]

I've created dedicated topic for it: https://www.eevblog.com/forum/repair/salora-sv-8800-(aka-mitsubishi-hs-b1020)-vhs-vcr-repair/ - because we are in Rigol topic
I mean that i've adjusted maximum time for working head, that's why gap is not 50% of field. Yes gap = low signal - I just mean that it looks like gap compare to normal signal level.
Thanks!

[TurboTom]

how do you know its boxcar averaging?

This is quite easy: When doing a single shot trace of preset sample count and analyze the individual samples, you can easily see the quntization of the values (like the "bins" in a histogram). At 1.25MSa/s, 1V/div you will find a quantization of approx. 2.31mv, which, assuming a quantization of 12bits (as per Rigol's specs), results in a total peak-to-peak range of approx. 9.5V which easily matches the 8 vertical divisions (8V) of visible vertical range.

The same test with a sampling rate of 100kSa/s has a quantization of approx. 0.2875mV which leads to a resolution in the ballpark of 15 bits. Since in a single shot, the calculation of a classic "isotemporal" average isn't possible, and the sampling engine itself can still be kept running at its "native" speed, it's a reasonable approach to average the "raw" samples that fall between two "shadow memory" (software) samples, into each adjacent s/w sample, resulting in the observed increase in resolution. And that's just boxcar averaging.

So to cut a long story short, just the fact to find a higher than hardware resolution in down-sampled single shot traces indicates that some kind of boxcar averaging has been applied to decimate the ADC raw data.

[Someone]

how do you know its boxcar averaging?

This is quite easy: When doing a single shot trace of preset sample count and analyze the individual samples, you can easily see the quntization of the values (like the "bins" in a histogram). At 1.25MSa/s, 1V/div you will find a quantization of approx. 2.31mv, which, assuming a quantization of 12bits (as per Rigol's specs), results in a total peak-to-peak range of approx. 9.5V which easily matches the 8 vertical divisions (8V) of visible vertical range.

The same test with a sampling rate of 100kSa/s has a quantization of approx. 0.2875mV which leads to a resolution in the ballpark of 15 bits. Since in a single shot, the calculation of a classic "isotemporal" average isn't possible, and the sampling engine itself can still be kept running at its "native" speed, it's a reasonable approach to average the "raw" samples that fall between two "shadow memory" (software) samples, into each adjacent s/w sample, resulting in the observed increase in resolution. And that's just boxcar averaging.

So to cut a long story short, just the fact to find a higher than hardware resolution in down-sampled single shot traces indicates that some kind of boxcar averaging has been applied to decimate the ADC raw data.

The basic question still stands, you have shown the quantisation levels improve with a lower acquisition sample rate but that only indicates some form of filtering. Boxcar is cheap/easy so probably the case, but it is not know to be boxcar yet (measure the frequency response out into aliasing to be sure which filter is used).

[Mechatrommer]

how do you know its boxcar averaging?

This is quite easy: When doing a single shot trace of preset sample count and analyze the individual samples, you can easily see the quntization of the values (like the "bins" in a histogram). At 1.25MSa/s, 1V/div you will find a quantization of approx. 2.31mv, which, assuming a quantization of 12bits (as per Rigol's specs), results in a total peak-to-peak range of approx. 9.5V which easily matches the 8 vertical divisions (8V) of visible vertical range.

The same test with a sampling rate of 100kSa/s has a quantization of approx. 0.2875mV which leads to a resolution in the ballpark of 15 bits. Since in a single shot, the calculation of a classic "isotemporal" average isn't possible, and the sampling engine itself can still be kept running at its "native" speed, it's a reasonable approach to average the "raw" samples that fall between two "shadow memory" (software) samples, into each adjacent s/w sample, resulting in the observed increase in resolution. And that's just boxcar averaging.

So to cut a long story short, just the fact to find a higher than hardware resolution in down-sampled single shot traces indicates that some kind of boxcar averaging has been applied to decimate the ADC raw data.

The basic question still stands, you have shown the quantisation levels improve with a lower acquisition sample rate but that only indicates some form of filtering. Boxcar is cheap/easy so probably the case, but it is not know to be boxcar yet (measure the frequency response out into aliasing to be sure which filter is used).

i tested with his setting, i dont see any boxcar (or running) averaging.. https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5124315/#msg5124315

[TurboTom]

The basic question still stands, you have shown the quantisation levels improve with a lower acquisition sample rate but that only indicates some form of filtering. Boxcar is cheap/easy so probably the case, but it is not know to be boxcar yet (measure the frequency response out into aliasing to be sure which filter is used).

Generally speaking, you are correct. But do you seriously suggest that Rigol implemented a more sophisticated decimating approach that includes trends of sample batches or other advanced filtering?  Whatsoever, I cannot do any testing anymore since "my" specimen of the DHO914S is on its return route to the distributor.

[Andromedoh]

Are there any mods to these scopes yet to unlock bandwidth etc? I wonder if it's possible to copy the contents of the SD card to a faster card to perhaps improve boot times? In the eevblog video he said he couldn't read the contents of the card, maybe there is some software that will do a low-level copy of the content?

[Fungus]

Are there any mods to these scopes yet to unlock bandwidth etc? I wonder if it's possible to copy the contents of the SD card to a faster card to perhaps improve boot times? In the eevblog video he said he couldn't read the contents of the card, maybe there is some software that will do a low-level copy of the content?

Try the hacking thread:

https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/

[Andromedoh]

Thanks, I'm new here

[ptluis]

Using a mouse is more effective but wait, for this need you only have 1 USB A port and it seems from reports a USB hub will freeze the scope.

I've been using a mouse and USB stick on a cheap hub all week with no problems.


I just got a nicer hub and that works, too.

Did you manage to unlock the 50 Mpts memory depth?

[Mechatrommer]

on to DHO800's LiteOn PSU... (beware this is non-reversible invasive action to tear down)
only 3 wires to USB3 connector, black (gnd), blue?, red?. so what kind of PD is this? when not connected to DSO, blue is 4.11V, red is 0V, once connected whether on or off, blue is 1.68V, red is 15V. i tried $1.50 USB3 DC pigtail to power DSO from SMPS PSU... if 12V, current is 3A, if 15V, current is 2.37A during operation (at boot up , its half that). so its a preferable fact that PSU/DSO is not that complicated to handle/diy, fwiw...

[KedasProbe]

I just got started doing some tests with my DHO914S

Using mouse combined with HDMI out is workable, using the web could lag up to 2 sec but could be fast enough, it's not a fixed latency.

I do use the phone or tablet to take screenshots, take screenshot and then long press in browser download image on phone. (they are in jpg though not png, that should be an easy change)

-AWG: starting from 25kHz up to  50kHz it can't make up its mind about which rise time it is going to use, see screenshot.
min 7.3ns max 11ns

-I connected the trigger out to the input, looks like a delay of 419ns (see screenshot)
The cursors are the jitter range 6ns

-I don't have a fast edge pulse generator but the DG4000 sync out gives me 2.14ns  (160Mhz)
(I don't know what the rise time is of the DG4000 sync out, 1ns?, so 250Mhz BW seems possible)


P.S my tek2465 died today, spark noises and smoke cloud, I wasn't completely surprised . I guess it couldn't handle the mental pressure of a third oscilloscope.