Rigol DHO804 Test and Compare Thread

[Martin72]

I assume all current tests are done with DHO800 at 100MHz and DHO900 at 250MHz.

I assume so, because mathematically (0.35 /risetime) mine is currently at 100Mhz...125Mhz and in the "options" menu I also see a (nowhere to buy) limited bandwidth upgrade.
@Fungus:
I find that interesting that you don't have that....
Had you already determined the bandwidth of your scope ?

[Mechatrommer]

on to FFT plot (external PC SW and DSO's built in) DS1054Z vs DHO800...
signal source, EraSynth Micro 50/100/200MHz 0 and -50dBm output (output level not accurate due to uncertified front end amplifier part replacement sometime ago)

nomen:
left column (DS1054Z data)
right column (DHO800 data)

top row (noise floor) at 20mV/div, 1mV/div (DS1054Z), 500uV/div (DHO800)
2nd top row (50MHz 0dBm, -50dBm)
next row (100MHz 0dBm, -50dBm)
next row (200MHz 0dBm, -50dBm)

scope's built in FFT conclusion:
DS1054Z: less usefull
DHO800: usefull

fwiw, imho.

[iMo]

..
It does have capability to become good buy, when Rigol actually makes it work properly.
I can see future in which that statement might be true. But right now, today, no.
..

That is the key question here - the "capability to become good buy"..
What the prospective buyers (like me) want to know is whether there is the "capability" actually existent. They want to know whether the current issues are because of the state of the current software implementation and could be fixed, or, that the current issues are there because of the hardware limitation which is the final state and cannot be improved..

[Fungus]

Had you already determined the bandwidth of your scope ?

I don't have a fancy pulse generator like you guys but I've seen rise times around 4.8ns which would be ~70Mhz.

[2N3055]

..
It does have capability to become good buy, when Rigol actually makes it work properly.
I can see future in which that statement might be true. But right now, today, no.
..

That is the key question here - the "capability to become good buy"..
What the prospective buyers (like me) want to know is whether there is the "capability" actually existent. They want to know whether the current issues are because of the state of the current software implementation and could be fixed, or, that the current issues are there because of the hardware limitation which is the final state and cannot be improved..

If you want a prediction (educated guess or whatever) i haven't got a crystal ball.
I have no clue when or even if Rigol will fix problems, which ones they will ignore or even if they can fix all the stuf.
I know even less if they will enhance it with new features (like R&S, Keysight and Siglent do) and if they do to what extent.

But yeah, avoid DHO900, for that one I have enough data points to be able to make that recommendation.
For DHO800/1000/4000 I cannot see showstoppers to discount them up front. Them I would give a chance to prove themselves.

But in that particular lengthy post of mine is only answer to that pivotal question: don't buy experimental preproduction  batches of products. Wait at least few months to see how it progresses..
That is only way to know for sure.
I'm not a gambling man. That is all the advice I have...

[TurboTom]

...
i tried the test you described. i got same bin size of around 2.2-2.4mV (very close to 12bits using your metric of 9.5Vpp) for both sample rate, so my setup is nowhere near your 20500 bins. maybe you've set other parameters/setting in your scope? Average acquisition maybe? or different FW? attached are my data and running FW version...

Thanks for repeating my tests. That's an interesting finding! I remember I did one more step after taking the "single shot" and saving the CSV of the sample memory: I zoomed into the trace data vertically to the maximum "linear" scale, this is five increments of the vertical encoder. So it must have been zoomed to the 20mV/div range. I assumed (which obviously was the wrong thing to do) that during this process, the sample data in the "shadow memory" won't be altered since this zooming process is completely reversible.

As it appears now, the sampling / decimation engine is way more complex than initially anticipated and moreover, it's questionable what data really gets stored when the user selects memory or screen as the source for the CSV to be generated. I'm sorry I cannot contribute to the testing anymore since my DHO914S is on its return trip to the distributor. Or maybe I should say I'm happy for this since this way, it saves me a lot of time  .

[Martin72]

What pleased me is that both the large DHO4000 and the small DHO 800 have the same software platform.
As you may remember, I had the 4000 here for testing in February of this year.
And after 8 months, I receive the DHO804 and have to soberly note that nothing has changed since then.
I find that very sad - For the 4000 owners.

[Mechatrommer]

Had you already determined the bandwidth of your scope ?

I don't have a fancy pulse generator like you guys but I've seen rise times around 4.8ns which would be ~70Mhz.

if you have Uni-T UTG962 AWG, its Sync output terminated can give 1ns risetime, you can use that to check DHO800 https://www.eevblog.com/forum/projects/yet-another-fast-edge-pulse-generator/msg3615705/#msg3615705. here (attached) i just tested it on DHO800...

[Martin72]

This roughly coincides with my risetime:

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

[Fungus]

if you have Uni-T UTG962 AWG, its Sync output terminated can give 1ns risetime, you can use that to check DHO800

Oh, that's handy...

If I do that I get 3.5ns rise time - it's 100MHz bandwidth right now! 


(But no mention of it in the options...)

[Fungus]

If I do that I get 3.5ns rise time - it's 100MHz bandwidth right now! 

I wonder if that's a bug in the options page - it says "Storage depth option" when it should really say "Bandwidth option".

FWIW I just turned mine into a 924 and I got a 1.5ns rise time using the siggen: 


So it looks like I did have a pulse generator, I just didn't know it. 

[Fungus]

Does anybody here own a DHO814?

If so, could you post the 814's vendor.bin... it's really easy to extract over Ethernet.

[tautech]

FWIW I just turned mine into a 924 ...............

Did that fix any bugs ?

[Martin72]

FWIW I just turned mine into a 924

Interesting, how did you do it ?
Do you have more memory now (50Mpts instead of 25Mpts) ?
Can you set the horizontal smaller than 5ns/div ?

[Fungus]

could you post the 814's vendor.bin...

https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5062843/#msg5062843

Thanks! Now I have a HDO800 with 2.3ns rise time. 


Self-cal worked OK. All we need now is a 50MSample memory hack.

[Fungus]

FWIW I just turned mine into a 924

Interesting, how did you do it ?

Download adb command line tools here: https://developer.android.com/tools/releases/platform-tools

(nb. You only need three files from that: adb.exe and AdbWin*.dll)

Now do this:

adb connect 192.168.1.205:55555            (or whatever your IP address is)
adb pull /rigol/data/vendor.bin            (keep this file safe - it's your vendor.bin)

Download the HDO924 vendor.bin from here

adb push vendor.bin /rigol/data
adb reboot                                                (do NOT power cycle it, there seems to be a delay before the file is written)

To switch it back just push your original vendor.bin

Do you have more memory now (50Mpts instead of 25Mpts) ?

I only had 25Mpts. I'm guessing that 924 didn't have the 50Mpts memory option.

[Martin72]

Ah,
Now I understand - you had first gone to the 924 and then "back" to the 814 ?

I'm guessing that 924 didn't have the 50Mpts memory option.

The 50Mpts are standard for the 900 series.

[Fungus]

The 50Mpts are standard for the 900 series.

I tried it again and yes, there's 50Mpts in 924 mode:


It seems like there's a delay between pushing the file and it being written to flash. If you power off and on the change might not work (and bricking is possible? I don't know if the Android file system is atomic or not)

If you do "adb reboot" it syncs the file system and works every time.

[Mechatrommer]

could you post the 814's vendor.bin...

https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5062843/#msg5062843

Thanks! Now I have a HDO800 with 2.3ns rise time. 
..snip..

Self-cal worked OK. All we need now is a 50MSample memory hack.

Now I understand - you had first gone to the 924 and then "back" to the 814 ?

why need to change back to 814 when 924 is much better spec? is there anything i'm not aware of? i will upgrade my scope to 924 when i settled tinkering with standard 804, backup the sd card and do the upgrade later.

[Fungus]

why need to change back to 814 when 924 is much better spec? is there anything i'm not aware of? i will upgrade my scope to 924 when i settled tinkering with standard 804, backup the sd card and do the upgrade later.

I don't want this on the screen (or any LA-specific features in the menus if there are any):


I'm sure there must be a way to enable bandwidth/memory without that.

I'm trying to find out how to decrypt vendor.bin so I can do a diff on them.

[Mechatrommer]

why need to change back to 814 when 924 is much better spec? is there anything i'm not aware of? i will upgrade my scope to 924 when i settled tinkering with standard 804, backup the sd card and do the upgrade later.

I don't want this on the screen:

so thats image for 924S? but you will lose 230MHz BW, i will just ignore that if i cant find 924 image or workaround imho.

[Fungus]

so thats image for 924S? but you will lose 230MHz BW, i will just ignore that if i cant find 924 image or workaround imho.

The current plan is to get as many vendor.bin files as I can and diff them all.

[iMo]

..
I don't want this on the screen (or any LA-specific features in the menus if there are any)
..

A small squared black sticker glued on the LCD would fix it.. 

[rpro]

I don't want this on the screen (or any LA-specific features in the menus if there are any):

On the DHO804, with vendor.bin 924, when you click/tap on the LA icon you get a small window saying "Please Insert LA Probe", that disappears on its own. Other than that, I can not find any traces of the LA in the menus (e.g. as sources for (logic) triggers, decoder, measurements, cursors, or math channels.) The code must be checking for the presence of the LA probe (and/or some other hardware clue) before it populates the menus.

[Martin72]

I have now started to go through the Batronix demo board, i.e. the examples given in the manual.
I also do this only with the two "small", dho804 and sds1104X-E.
Note that both scopes are set the same, nevertheless, on the siglent screen is "more going on" in the sense of more signals on the screen.
This is not a rating, just an observation.
The first trigger example "Pulsewidth" mastered both to the satisfaction, but already with the second I have a problem:
Interval trigger, is there an equivalent with the rigol ?
Siglent has this trigger, accordingly I could perform the example.
Not well visible on the photo:
To get about the same brightness as with the siglent, I had to set the corresponding "sliders" on the rigol to almost full stop.
This is also just an observation, not a judgement.
@Fungus:
I noticed earlier, I now also have the "Storage Depth" as a limit in the options menu, instead of the bandwidth.
I think this was "replaced" when we updated our firmware.