Hacking the Rigol DHO800/900 Scope

[ebastler]

If you want more space for waves, you can use full screen mode. 

Neat! Can you assign a button to toggle between views?

[mrisco]

Neat! Can you assign a button to toggle between views?

Maybe it is possible.

[shapirus]

Damn that's great. It will be a crime not to share

BTW, it's better to keep decompiled sources in git rather than an assembled .apk -- for the very purpose of VCS, that is, to keep history, to be able to see diffs, to be able to cooperate with others via forks and pull requests.

Please consider this.

[ebastler]

It will be a crime not to share
BTW, it's better to keep decompiled sources in git rather than an assembled .apk

It's an interesting question what Rigol will think and possibly do about this. Hosting copies of their copyrighted binaries on a public server is probably violating license terms already. Hosting and sharing decompiled sources might be beyond their pain threshold?

Or maybe they don't care. Who is brave enough to run the experiment? 

You may not resell, decompile, reverse engineer, disassemble, or otherwise convert the Software to a human perceivable form.

https://int.rigol.com/announce/terms

[shapirus]

It will be a crime not to share
BTW, it's better to keep decompiled sources in git rather than an assembled .apk

It's an interesting question what Rigol will think and possibly do about this. Hosting copies of their copyrighted binaries on a public server is probably violating license terms already. Hosting and sharing decompiled sources might be beyond their pain threshold?

Or maybe they don't care. Who is brave enough to run the experiment? 

You may not resell, decompile, reverse engineer, disassemble, or otherwise convert the Software to a human perceivable form.

https://int.rigol.com/announce/terms

That's a good point. Legally, it's questionable at least.

Well, it then could be a private repo with access for trusted forum members .

Another option would be to keep only diffs in the repo.

[mrisco]

If they used GPL code, then they must disclosure the source upon request because GPL license is viral, and can't restrict the use of the code. It is not enough to show a text acknowledgement. There is a large list of Chinese manufactures that use GPL code and do not disclosure the sources, some of them use the phrase "open source" in a promotional way and do not release any source.

[AndyBig]

Or maybe they don't care. Who is brave enough to run the experiment? 

Two months ago I gave here a link to my github

If you want more space for waves, you can use full screen mode. 
I have taken a picture of the oscilloscope and not a capture so that you can see that it is not a clipping.

Have you switched somehow between full screen mode and normal mode while working? Or is it a separate full-screen version of the application?

[mrisco]

New header bar

[mrisco]

Have you switched somehow between full screen mode and normal mode while working? Or is it a separate full-screen version of the application?

It is the same application compiled with some changes as a proof of concept.

[shapirus]

that's impressive indeed.

don't stop :)

[RAPo]

I would move the math-button next to the channel-buttons., so that one large black area comes free where the time info can be placed (starting a bit like a siglent ;-)).

[ebastler]

Or you may want to take a look at the DHO1000/4000 GUI. With its larger screen, it shows four separate Math boxes in the bottom status bar, which show details about each Math function when it's activated. (Also a bit like the Siglents. )

The font is a bit smaller in your modified UI, right? Do you still find it comfortably readable on the built-in screen, or do you mostly use an external monitor?

[ebastler]

If they used GPL code, then they must release the source code of the entire project, and can't restrict the use of the code.

That depends on how they included potential GPL code (or libraries), and what the specific licenses require. If I recall correctly, there is an Open Source Acknowledgement built right into the firmware, so Rigol are not ignorant of their obligations. And I don't think that Acknowledgement states that the whole firmware is open source.

[mrisco]

New header bar

(Attachment Link)

The "New Header" version has been released in the repo.

[Andromedoh]

New header bar

(Attachment Link)

The "New Header" version has been released in the repo.

How do I install it Mrisco? theres no instructions.

[aXit]

Looking at the zynq 7015 pinouts along with the board layout gives some clues to the DDR SDRAM usage.

The DDR3L chip on the DHO800 is connected up to bank 13 (yellow), this will be a DDR memory controller implemented in the FPGA fabric. The gigadevice GDP2BFLM-CA is a 16-bit wide, 2133MT/s device, if clocked at it's rated frequency, that gives 34Gb/s theoretical memory bandwidth.

It looks like bank 35 (magenta) is being used for the ADC interface, 1.25Gsps @ 12-bit is 15Gb/s. Considering the memory is 16-bit wide, and there are also 16 logic analyser inputs, they could just be storing 12-bit samples as 16-bit instead of repacking, bringing the ADC sample bandwidth up to 20Gb/s.

I'm assuming that bank 34 is mostly being used for the differential LA inputs, as well as any other GPIOs/controls (based on some visible single ended signals on the top layer here too).

Bank 112 (blue) are the GTP tranceivers implementing the PCIe device on the RK3399.

The DHO800 unpopulated memory devices (orange) are specifically for the PS / ARM SoC part of the zynq chip. In most zynq applications, this memory would be the system memory for embedded linux running on the PS. In these situations, any high bandwidth data needs to pass from the FPGA fabric (PL) to the PS via some dedicated  AXI buses inside the zynq, and then handled by the PS memory controller, on a separate clock domain. While they technically have the bandwidth (4x buses of 8-16GB/s, depending on clocks), it's likely that just having a synchronous memory device directly on the FPGA fabric is much more suitable for continuously streaming data from an ADC.

It's not clear to me what the PS is being used for in this zynq. Clearly it's not running embedded linux, since the RK3399 is running the host OS, and there's no system memory on the DHO800 series. It could be running some RTOS doing measurements, stats or monitoring (with the limited 256KB of on-chip memory available to it), but I really have no idea.

[PELL]

Haven't been around here quite a time, very glad to see you guys are still working on this scope

I had talked with someone who used to work at Rigol HQ, and he told me: "The PS part of that 7015 isn't used at all, we only use PL for the work". This might be a rumor, but depends on you.

You might ask why not use an Artix or Spartan if they don't use the PS part. I guess that's because those lower-end ZYNQ chips are incredibly cheap in China right now, I am talking about $1 ZYNQ-7010/pcs or $6~7 ZYNQ-7020/pcs (of course not brand new, it is second-hand but tested to make sure it is functional) at online sales.

Rigol certainly did use brand-new chips, but from the example above, you can imagine how cheap if you purchase a bunch of them from Xilinx.

 

[AceyTech]

Looking at the zynq 7015 pinouts along with the board layout gives some clues to the DDR SDRAM usage.

The DDR3L chip on the DHO800 is connected up to bank 13 (yellow), this will be a DDR memory controller implemented in the FPGA fabric. The gigadevice GDP2BFLM-CA is a 16-bit wide, 2133MT/s device, if clocked at it's rated frequency, that gives 34Gb/s theoretical memory bandwidth.

It looks like bank 35 (magenta) is being used for the ADC interface, 1.25Gsps @ 12-bit is 15Gb/s. Considering the memory is 16-bit wide, and there are also 16 logic analyser inputs, they could just be storing 12-bit samples as 16-bit instead of repacking, bringing the ADC sample bandwidth up to 20Gb/s.

I'm assuming that bank 34 is mostly being used for the differential LA inputs, as well as any other GPIOs/controls (based on some visible single ended signals on the top layer here too).

Bank 112 (blue) are the GTP tranceivers implementing the PCIe device on the RK3399.

The DHO800 unpopulated memory devices (orange) are specifically for the PS / ARM SoC part of the zynq chip. In most zynq applications, this memory would be the system memory for embedded linux running on the PS. In these situations, any high bandwidth data needs to pass from the FPGA fabric (PL) to the PS via some dedicated  AXI buses inside the zynq, and then handled by the PS memory controller, on a separate clock domain. While they technically have the bandwidth (4x buses of 8-16GB/s, depending on clocks), it's likely that just having a synchronous memory device directly on the FPGA fabric is much more suitable for continuously streaming data from an ADC.

It's not clear to me what the PS is being used for in this zynq. Clearly it's not running embedded linux, since the RK3399 is running the host OS, and there's no system memory on the DHO800 series. It could be running some RTOS doing measurements, stats or monitoring (with the limited 256KB of on-chip memory available to it), but I really have no idea.

Thanks for your analysis and observations.  Good to have some new eyes looking at the architecture here.

Couple things I've ascertained:  (and have data for)
  --The FPGA is hooked to the SoC(RK3399) via PCIe., and according to what I've noticed, they're only using 2 PCIe channels of the 4 lanes(1/2 & 1/2 on top & bottom)  The traces you circled(in blue) above are only 2 channels, plus the clock pair.
  --There are several DDR3(and DDR3L) parts that have been or are used on the FPGA...  While the GigaDevice parts are listed at 2133, We've seen slower speed parts populated. -like 1800-1900  I'm not sure what speed they're running, off the top of my head.
  -- There IS actually "system memory on the DHO800 series", it's 4GB of DDR4 connected to the RK3399, and is only clocked at 856Mhz

FYI: They have a console UART on PCB next to the FPGA., The logfile has FSBL and "how it's config'd" information.   You might want to poke around at the ZYNC there.

[LEER333]

I seem to have seen Zynq7Z015r DDR3 support up to 1333mb/s

[Harrow]

Is it possible to remove the RIGOL logo in the top left corner to save some space ?

When I learn to do this, I was maybe going to put my own name there. 

[Inssomniak]

Hello all.  I tried the 100mhz/memory depth hack on firmware 1.02 and it initially failed with Key.data not found errors.
I edited the 2 batch files to RKey.data and it finds the files now but it says the key file format is wrong.

How do I get this hack to work on 1.02 firmware? Thanks!

[shapirus]

Hello all.  I tried the 100mhz/memory depth hack on firmware 1.02 and it initially failed with Key.data not found errors.
I edited the 2 batch files to RKey.data and it finds the files now but it says the key file format is wrong.

How do I get this hack to work on 1.02 firmware? Thanks!

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

[Inssomniak]

Thanks! I was trying to use the utility from the first page but didnt see this.
It worked good.

[AceyTech]

To help direct people to the hacking guide location, I've added a link in my signature, like @Andy's

Code: [Select]

   [b][color=purple]
[url=https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076]DHO 800/900 hack instructions by @AndyBig[/url]
   [/color][/b]


[piit79]

I post the apk for the test in the repo: https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/tag/SPGUI0.2.1
But it is in a very early stage.

Awesome work! I really need to try these modified APKs.

By the way, are you (and @AndyBig) aware of the Revanced Manager / ReVanced Patcher / ReVanced Patches projects? They provide a generic framework together with a fronted app and individual patches to allow modifying existing APKs easily directly on the target device. The patches target a particular version of the app and one can select which patches one wants to apply from a list of available patches that is updated regularly from the patches repo. (The highest profile app that can be patched using ReVanced is YouTube, and there are now over 60 patches available for it, including ad blocking.)

It would be incredible if these patches for the Sparrow.apk could be transformed into the format Revanced Patcher / Revanced Manager understands - this would solve the legal issue (no copyrighted material would need to be published) while allowing users to only apply patches they want, and the patches would be kept in one central repository allowing for easier collaboration.

ReVanced Manager allows for using custom patches repository (instead of the default ReVanced Patches), so we could have our own.

I do realize it would require significant investment into development time on top of the actual patching, so I would understand if neither you nor @AndyBig were keen on spending any time on this. I just thought it would be awesome to have the patches in ReVanced, both from user and development perspective.