Hacking the Rigol DHO800/900 Scope

[shapirus]

SO at this point on the DHO804, what is the best method to increase its bandwidth/memory depth?

https://github.com/zelea2/rigol_vendor_bin

[norbert.kiszka]

SO at this point on the DHO804, what is the best method to increase its bandwidth/memory depth?  I saw a method early on in the thread that had a youtube video showing it, but then I saw something about a firmware update that may have invalidated that method?  I'm thinking about ordering on of these so I want to get the low down on the latest method that it solid.  It sounds like in the DHO8 series that the 804 is the one.

You want to upgrade it to DHO814 or to DHO924?

In this second case, You need to change HW number and probably reflash FPGA (that is my today discovery).

[AceyTech]

SO at this point on the DHO804, what is the best method to increase its bandwidth/memory depth?  I saw a method early on in the thread that had a youtube video showing it, but then I saw something about a firmware update that may have invalidated that method?  I'm thinking about ordering on of these so I want to get the low down on the latest method that it solid.  It sounds like in the DHO8 series that the 804 is the one.

Hi there!!  It's not obvious to find the newest/greatest guide, sorry.  -but @Andybig wrote up a guide many pages ago that is step by step, using a couple different approaches, and very complete. 
It is your best chance for success.  See here--
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076

Have fun hackin'   

p.s., the DHO804 offers "the best bang for the buck", since it  has everything a DHO900 has currently, except the additional hardware that the S models have.

[norbert.kiszka]

By the way...

[AceyTech]

You want to upgrade it to DHO814 or to DHO924?

In this second case, You need to change HW number and probably reflash FPGA (that is my today discovery).

Please don't say that.  Users don't reflash the FPGA.   FPGA's lose their memory on power-down/reboot.
The system loads(I.e., programs) the FPGA via SPI Flash.  The CPU can send a *.bin to upgrade that flash so it loads it subsequently.

[shapirus]

By the way...

That's something. Does it actually work?

[S2084]

By the way...

That's something. Does it actually work?

Of course not!!!  I did this two months ago..... nothing works there....  even the sensitivity does not change.... horizontal scan too, sampling frequency is always 625.....

[norbert.kiszka]

By the way...

That's something. Does it actually work?

Kinda... Everything from 10M to 100M gives 10M.

[shapirus]

Kinda... Everything from 10M to 100M gives 10M.

What method was that? Technically the scope is capable of 50M all right. My DHO804 stores 50M points: I can capture 40ms worth of samples at 1.25 GSa/s and, when acquisition is stopped, zoom all the way to 2 ns/div at any point of the captured interval.

Your screenshot made me wonder if it can do 100M somehow.

[norbert.kiszka]

Kinda... Everything from 10M to 100M gives 10M.

What method was that? Technically the scope is capable of 50M all right. My DHO804 stores 50M points: I can capture 40ms worth of samples at 1.25 GSa/s and, when acquisition is stopped, zoom all the way to 2 ns/div at any point of the captured interval.

Your screenshot made me wonder if it can do 100M somehow.

I changed vendor.bin. Model name HDO1074, serial number also from photo in this forum and I generated lic files for DHO1000 with this: https://github.com/zelea2/rigol_vendor_bin/

[norbert.kiszka]

Call me crazy, but right now I want to do 4.1 G Sa/s...

More crazy thing is, I know how to do this   

Currently there is no magic smoke, but after one minute play I see trigger works only in single mode - probably I changed too much files for experiments.

[norbert.kiszka]

This is more or less normal:



This is changed:



So looks like sample rate wasn't changed at all (measured frequency went higher and rise time is lower), but now probably I know where I should look for it.

However... With same generator measured rise time is 2.55 ns vs 1.02 ns. Frequency is 17.71 MHz vs 56.66 MHz. According to change in measured frequency, sample rate is 1.25 (4/1.25) but rise time has different ratio... Maybe because of interpolation.

[shapirus]

So looks like sample rate wasn't changed at all (measured frequency went higher and rise time is lower), but now probably I know where I should look for it.

Also note how the displayed waveform in the second screenshot is zoomed out, while timebase is set to 10 ns/div, whereas it should have been zoomed in, as the other screenshot has 20 ns/div. This isn't right.

[norbert.kiszka]

So looks like sample rate wasn't changed at all (measured frequency went higher and rise time is lower), but now probably I know where I should look for it.

Also note how the displayed waveform in the second screenshot is zoomed out, while timebase is set to 10 ns/div, whereas it should have been zoomed in, as the other screenshot has 20 ns/div. This isn't right.

Because I changed time base couple times...

[shapirus]

Because I changed time base couple times...

When you change time base, the displayed waveform must properly fit in the respective number of horizontal divisions.

Was the signal the same in those two screenshots?

In the first screenshot the displayed waveform's period takes slightly less than 3 divisions. 3 div = 60 ns, frequency with 60 ns period is 16.6 MHz, and it's slightly less than 3 div, so the counter shows 17.7 MHz correctly.

In the second screenshot the counter still shows the same 17.7 MHz, but the displayed waveform's period is slightly less than 2 div; 1 div = 10 ns, the cursors measure it right: 18 ns. Then, 1 / 18 ns ~= 55.5 MHz, meaning that the scope failed to render the horizontal scale properly, but it still counted the zero crossings right (which apparently happens in a whole separate part of the system and doesn't depend on what's actually displayed).

[norbert.kiszka]

Because I changed time base couple times...

When you change time base, the displayed waveform must properly fit in the respective number of horizontal divisions.

Was the signal the same in those two screenshots?

In the first screenshot the displayed waveform's period takes slightly less than 3 divisions. 3 div = 60 ns, frequency with 60 ns period is 16.6 MHz, and it's slightly less than 3 div, so the counter shows 17.7 MHz correctly.

In the second screenshot the counter still shows the same 17.7 MHz, but the displayed waveform's period is slightly less than 2 div; 1 div = 10 ns, the cursors measure it right: 18 ns. Then, 1 / 18 ns ~= 55.5 MHz, meaning that the scope failed to render the horizontal scale properly, but it still counted the zero crossings right (which apparently happens in a whole separate part of the system and doesn't depend on what's actually displayed).

When I figured out this app is capable up to 40 G Sa/s (maybe even more) my laptop died because I forget to connect it back (I needed power supply for a generator and I used same power cord). After that I decided to do a quick experiment, which You have seen on screenshots. Right now Im going to try anything above 1.25 in a similar way (more changes).

Still Im not sure why rise time was changed by different ratio.

[AndyBig]

right now I want to do 4.1 G Sa/s...

To do this you will have to solder a second ADC.

[norbert.kiszka]

right now I want to do 4.1 G Sa/s...

To do this you will have to solder a second ADC.

This ADC as far as I know is capable to do at least 2G.

[AndyBig]

This ADC as far I know is capable to do at least 2G.

More like a maximum of 2G. Therefore, for 4G you need a second ADC.

[norbert.kiszka]

This ADC as far I know is capable to do at least 2G.

More like a maximum of 2G. Therefore, for 4G you need a second ADC.

Thats also good.

[AndyBig]

This ADC as far I know is capable to do at least 2G.

More like a maximum of 2G. Therefore, for 4G you need a second ADC.

Thats also good.

But this does not mean at all that on 8xx/9xx hardware it will produce 2G

[ebastler]

But this does not mean at all that on 8xx/9xx hardware it will produce 2G

When I first learned about the 1.25 GSa/s sampling rate on the DHO800/900 series, I thought they might be deliberately throttled to keep some differentiating features for the DHO1000. But then it became known that Rigol had to cripple the DHO900 series by cutting its analog sampling rate in half whenever the digital channels are used. (Which happen to consume half the data rate, capturing 16-bit words at 625 MSa/s.)

This lets me assume that there is indeed a limitation in the overall data rate (analog + digital channels combined) which the scope can process, and that the limit is not set by the ADC. The DRAM or its interface to the FPGA is a likely suspect.

[gabiz_ro]

Please don't say that.  Users don't reflash the FPGA.   FPGA's lose their memory on power-down/reboot.
The system loads(I.e., programs) the FPGA via SPI Flash.  The CPU can send a *.bin to upgrade that flash so it loads it subsequently.

Not 100% sure about that.
System indeed program program SPI flash, but only some part.
I have checked before and SPI flash content was matched with boot and selftest bin programmed by system but area starting from 0x0 is not matched with anything.
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5332511/#msg5332511
user empeka provide dump from 914
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5332670/#msg5332670
Result of comparation.
 https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5332712/#msg5332712

It may be a different version of firmware or maybe not and firmware is different.

[AceyTech]

Please don't say that.  Users don't reflash the FPGA.   FPGA's lose their memory on power-down/reboot.
The system loads(I.e., programs) the FPGA via SPI Flash.  The CPU can send a *.bin to upgrade that flash so it loads it subsequently.

Not 100% sure about that.
System indeed program program SPI flash, but only some part.
I have checked before and SPI flash content was matched with boot and selftest bin programmed by system but area starting from 0x0 is not matched with anything.

It may be a different version of firmware or maybe not and firmware is different.

Agreed, it's hard to tell what that 0x00 bit is/was supposed to point at. 

My hypothesis: they have one "working", one "update" and one "factory" copy of the FPGA configuration. 

It used to be standard practice in embedded designs I worked on, to keep multiple copies in case an update goes bad. If the update is good, and boots normal, then the "working" and "update" copies can be revised.  Then a "restore to factory" copy hidden away that can be restored in case of corruption, etc.  Saves on tech support inquiries and RMA's.

I'm not sure exactly how Rigol chose to do it., but I think you proved that they loaded the SPI with multiple copies.  I remember thanking your post.

And then; This could just be Rigol software guys not cleaning up behind themselves.  They have multiple copies of files littered everywhere on the SDCard.

[AceyTech]

It may be a different version of firmware or maybe not and firmware is different.

BTW, sorry.  I'm not sure I follow this statement.. Maybe i'm tired from Daylight "Savings" time cutting my sleep.