Hacking the Rigol DHO800/900 Scope

[AndyBig]

Depth of my 804 running as 914 with option lics

Sequence the ch's 1-4 on, set 1 to 50M
1 50
2 25
3 10
4 10

Is that 95M total?

No, how much memory is in total is shown by the maximum number, that is, 50M

Individual ch's
1 up to 50
2 up to 25
3 up to 25
4 up to 25

Why 2-3-4 can't do 50M on their own ?

Do you also switch the trigger to the active channel? It’s just that if the trigger is switched on to another channel, then it eats up memory in the same way as a separate channel.

[AceyTech]

Why ZYNC FPGA?
Here's a theory in question form:  Can you implement PCIe in a FPGA without using a CPU core?

Of course, this can be done. There are no difficulties with such implementations.
FPGA is enough for PСIe and there are ready-made IP blocks for this...

Interesting, good to know, Thanks!  I was hoping that was a suitable answer to your "Why the hell is ZYNC even in this circuit?" question. 

This seems to be a typical architecture I've noticed in scopes like these.  It looks to me like they're treating the FPGA as a peripheral to the SoC.  The FPGA can capture real-time in the background while the SoC handles all the user/system I/O.

How do they use the CPU core? The fact is that the hardware DDR3 controller is connected only to the processor, not to the FPGA part.

Really? Looks like the GigaDevice DDR3's are connected to the FPGA, not the SoC. (1ea in the 800, 3ea in the 900 models.)

Because it is the only-FPGA  chip that is needed here, not the CPU or SOC.

Are you suggesting they should design the scope with only FPGA, no CPU/SoC?  If it were possible, it sure would boot faster!

[maxspb69]

You misunderstood me. In the place where the ZYNC-7000 is installed, a processor is not needed.

ZINC 7000 is 2-core CPU + little ARTIX FPGA. The real CPU for postprocessing data is located in another SOC - Rockchip. It is not clear why they need CPU in ZYNC in this case? But most likely the reason is that ARTIX FPGA is more expensive than ZYNC-7000, and ZYNC-7000 can replace a small volume of ARTIX. That’s why they used it, the reason is purely economic, it seems to me.
In the more expensive HDO1000 and HDO4000, in this place there is  an ARTIX-100, which is more fitted in this place of the oscilloscope circuit.

[zelea2]

Step-by-step guide:

• download the generator from here https://github.com/zelea2/rigol_vendor_bin
• ...

I've simplified the procedure and compiled the generator for ARM64.
All you need to do now is transfer the executable generate_all_options to the scope in /rigol/data and run it from there.
It will create all the option.lic files which will be installed after reboot. No need to use SCPI commands anymore.

The COMP/EMBD/AUTO options are all related to protocol decoding and they show in the About/Options screen.

[Randy222]

I was poking around some on the Android side today. Like usual, things appear to be mostly defaults, seems Rigol did not want to invest time in tuning the OS which makes almost everything run better.

I did not do any timer wrapping to get real test data, found some git stuff that made sense, but you might notice some things being a bit snappier after the changes.
DHO Android elevator is set CFQ, the only option in this kernel build.

So, park this in the rigol start script so it persists reboot, you can always add or remove too.

Code: [Select]

sysctl -w kernel.perf_cpu_time_max_percent=5
sysctl -w kernel.sched_child_runs_first=1
sysctl -w kernel.sched_min_granularity_ns=2500000
sysctl -w kernel.sched_migration_cost_ns=1000000
sysctl -w kernel.sched_nr_migrate=128
sysctl -w kernel.sched_wakeup_granularity_ns=10000000
sysctl -w vm.dirty_background_ratio=10
sysctl -w vm.dirty_writeback_centisecs=1000
sysctl -w vm.stat_interval=10
sysctl -w vm.swappiness=100
sysctl -w vm.vfs_cache_pressure=60

reference: https://github.com/hollowsxd/ktweak/blob/master/README.md

[Randy222]

Individual ch's
1 up to 50
2 up to 25
3 up to 25
4 up to 25

Why 2-3-4 can't do 50M on their own ?

Do you also switch the trigger to the active channel? It’s just that if the trigger is switched on to another channel, then it eats up memory in the same way as a separate channel.

I just tried, so yep. Ch1 50M, set trigger to Ch2, Ch1 downgrades to 25M.

[shapirus]

Code: [Select]

sysctl -w vm.swappiness=100


Why? I would rather have this one set to zero.
But is there any swap enabled, anyway?

[Randy222]

Was looking at some stats from top command on 804

The rigol scope app chews up about 40-45% cpu sitting idle (stop, no ch active)
Add ch1 with the 1kHz front signal, +~10%
add FFT to it, ~55-60% cpu

All four ch active with FFT on all of them, scope app takes cpu to ~80%

I wonder how the 900 does with it's added functionality.

[Randy222]

Code: [Select]

sysctl -w vm.swappiness=100


Why? I would rather have this one set to zero.
But is there any swap enabled, anyway?

The notes were just that old systems used 60, newer droids linux use 100 to be "fair".
toybox top indicates 502,908k for Swap. Zero used however. There's approx 40% free Mem, so seeing used swap is not likely, hence vm.swappiness really doesn't matter here.

Code: [Select]

When vm.swappiness is set to 100, the priorities would be equal (anon_prio=100, file_prio=200-100=100). Setting vm.swappiness to zero will prevent the kernel from evicting anonymous pages in favour of pages from the file cache.

[shapirus]

There's approx 40% free Mem, so seeing used swap is not likely, hence vm.swappiness really doesn't matter here.

It actually does. Linux is notorious for using swap even when RAM is far from being exhausted, which may sometimes be desirable with very fast storage and a mix of frequently and infrequently accessed pages, but this is clearly not the case with this scope.
How much it will want to move the infrequently accessed pages to swap is controlled by the vm.swappiness parameter.

[Randy222]

There's approx 40% free Mem, so seeing used swap is not likely, hence vm.swappiness really doesn't matter here.

It actually does. Linux is notorious for using swap even when RAM is far from being exhausted, which may sometimes be desirable with very fast storage and a mix of frequently and infrequently accessed pages, but this is clearly not the case with this scope.
How much it will want to move the infrequently accessed pages to swap is controlled by the vm.swappiness parameter.

Yes, linux still uses swap regardless of swappiness #. The user # actually sets two parameters.
But in this specific case, DHO droid 800-900 series, the setting really does not matter. At 100 the two parameters are 100 100, so 50/50, aka "fair". A 90-10 or 100-0 or 75-25, really makes has no performance diff. If when it decides to swap (and how), not gonna make any diff on this DHO droid.

I think some of the online discussions around swappiness being a setting of "agressiveness" relating to "swap" is a bit misleading. The setting has more to do with the two actual kernel parameters in code derived from the vm.swappiness value.

So in light of this dicsussion, can just leave out the change to swappiness setting. 100, 60(default), 0, does not matter here.

[shapirus]

I have found that there are some predefined authorized keys for ssh access in /data/ssh/authorized_keys with the following usernames/emails:

Code: [Select]

adil@ubuntu-SSD
sj03955@rigol.com
android@rigol.com

I guess the devs had no intention of creating backdoors, but I'm going to disable these on mine, hope they aren't needed for normal operation.

update: this file is restored on reboot, and for some reason my public key doesn't work when I add it there (before reboot too). Weird.

update2: the SSH server on the scope is old as mammoth's dung, so more recent clients need the following options, which may be specified in the command line (until support for them is finally dropped):

Code: [Select]

$ ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa root@<ip>


[gabiz_ro]

Until you have directly connected scope to internet who can access via ssh your scope?
Easy to do from LAN but you are behind a router or modem.Only if you set a rule on that or add scope to DMZ or other thing this can be done.

[shapirus]

Until you have directly connected scope to internet who can access via ssh your scope?
Easy to do from LAN but you are behind a router or modem.Only if you set a rule on that or add scope to DMZ or other thing this can be done.

It's my professional deformation :)

Yes in this particular case it doesn't really matter, but in general you don't want such things in any of your devices regardless of how they are connected to network. They will bite you sooner or later.

[Randy222]

I have found that there are some predefined authorized keys for ssh access in /data/ssh/authorized_keys with the following usernames/emails:

Code: [Select]

adil@ubuntu-SSD
sj03955@rigol.com
android@rigol.com

I guess the devs had no intention of creating backdoors, but I'm going to disable these on mine, hope they aren't needed for normal operation.

update: this file is restored on reboot, and for some reason my public key doesn't work when I add it there (before reboot too). Weird.

update2: the SSH server on the scope is old as mammoth's dung, so more recent clients need the following options, which may be specified in the command line (until support for them is finally dropped):

Code: [Select]

$ ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa root@<ip>


There's no way to carve out sub topics within a thread.

SSH access for DHO has already been well documented here on EEVb.

Std edit requires you to first remount as rw.

or, you put your keys in the ssh user data keys files, the system copies those over to the rw partition during boot.
Also, SSH is missing two env variables, ANDROID_ROOT and ANDROID_DATA, which are needed to avoid pesky err messages.

And as mentioned, unless you expose DHO SSH to internet, then the Rigol users defined are no risk. You can add '#' to front of their keys, or remove them.
I have seen with other legit devices, such practice can be used for remote support reasons. I guess Rigol does not do that?

It's my professional deformation

Yes in this particular case it doesn't really matter, but in general you don't want such things in any of your devices regardless of how they are connected to network. They will bite you sooner or later.

Actually, would bite Rigol. If non-authorized access happens using those Rigol user keys, then that means Rigol has compromised private key, so perhaps more of an issue for Rigol.

[shapirus]

I've simplified the procedure and compiled the generator for ARM64.
All you need to do now is transfer the executable generate_all_options to the scope in /rigol/data and run it from there.
It will create all the option.lic files which will be installed after reboot. No need to use SCPI commands anymore.

The COMP/EMBD/AUTO options are all related to protocol decoding and they show in the About/Options screen.

I can confirm that this works on DHO804.
BW is reported as 100M now (in Utility/About), 50Mpts is now available too.
For some reason however I don't see them as options in Utility/Options:



They weren't there before generating the licenses, either. The only difference on this screen is that the second option changed from "limited" to "forever".

Rise time that I'm testing with my pulse generator based on CD74AC00E (5Vpp) has also improved: 2.8ns before, 2.4ns now -- as measured by the scope's own measurement function. I don't know if it measures it correctly -- if I use cursors and set the starting point at where the signal is just starting to rise, then it'll be over 3ns. I don't know what is the right way to measure it, i.e., at which levels relative to low and high states. Also this IC is far from being the fastest, so I don't really know at which point I'm hitting its actual rise time and not the scope's limitation (however I definitely hit the latter at the stock 70MHz BW).

Now I want to turn the scope into a DHO924 and see what happens.

Update: yes it works just fine, using zelea2's vendor.bin utility. Change model, regenerate option licenses, done. Really appreciate the work of everyone who put their time and effort into R&D. Rise time is now ~2.2ns, and now I believe this is the IC's actual performance, so of course now I need to build a faster pulse generator :).

p.s. at first glance, no self-calibration is required after all this: no DC offset, voltage readings also look good.

[zelea2]

I have found that there are some predefined authorized keys for ssh access in /data/ssh/authorized_keys with the following usernames/emails:

update: this file is restored on reboot, and for some reason my public key doesn't work when I add it there (before reboot too). Weird.

Yes it is copied at boot from the read only system file.
Read this: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5310781/#msg5310781

[shapirus]

Yes it is copied at boot from the read only system file.
Read this: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5310781/#msg5310781

Yeah thanks, I saw that later. Actually there isn't much point in using SSH, it seems, as adb shell over TCP does the job just as well, at least as long as we don't leave LAN.

[zelea2]

Yes you can do the same things with adb/root and with ssh.
For me the advantage is less typing with ssh (just one command) and also all my aliases are loaded when I log in.
The other advantage is that I can mount the scope's FS with "shell link" (aka sshfs) and copy/move files to/from
the scope with just a key press.

[Burntronic]

The other advantage is that I can mount the scope's FS with "shell link" (aka sshfs) and copy/move files to/from
the scope with just a key press.

You might try adbfs instead, e.g.:

https://github.com/isieo/adbFS
https://github.com/spion/adbfs-rootless

[Fungus]

The other advantage is that I can mount the scope's FS with "shell link" (aka sshfs) and copy/move files to/from
the scope with just a key press.

You can do that with FTP.

(I use WinSCP to access the files on the 'scope)

[zelea2]

You can do that with FTP.

It's good that we have choices, I still prefer sshfs because that gives me root access across the entire FS.
FTP points by default to /data/UserSomething and adbfs is something else to install.

[DVX]

Apologies if this has already been covered in this thread. My DHO804 arrived today, it has firmware 00.01.01. After applying Serg65536's hack as detailed at https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5148330/#msg5148330 the BW shows 100M and storage depth is forever, so this worked OK. While the scope was connected to my network an upgrade message appeared, clicking on the upgrade icon, shows a new firmware is available. Has anyone applied this upgrade and is the BW and storage depth hack retained? There are no details shown for the new firmware via the upgrade icon. 

 

[Randy222]

Apologies if this has already been covered in this thread. My DHO804 arrived today, it has firmware 00.01.01. After applying Serg65536's hack as detailed at https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5148330/#msg5148330 the BW shows 100M and storage depth is forever, so this worked OK. While the scope was connected to my network an upgrade message appeared, clicking on the upgrade icon, shows a new firmware is available. Has anyone applied this upgrade and is the BW and storage depth hack retained? There are no details shown for the new firmware via the upgrade icon.

Apply the 00.01.02.00.02 FW update package.
After that you go back a few posts/pages from here and use the new easy method to "open up" your 804.

[AndyBig]

I wonder how difficult it is to disassemble an apk, change something in it and compile it back so that it works. Has anyone done this? Is this even feasible?