Hacking the Rigol DHO800/900 Scope

[norbert.kiszka]

Hey Norbert, just wondering — do you prefer us to report bugs here or on the Patreon channel?
I’ve also had a few issues that I mentioned to you in private messages on Patreon.

Hi. Actually I started writing reply to You on there. One of this three issues (AX+B math function) I already fixed, which will be in the next prerelease or release.

About the bug reports, at this moment it doesn't matter. But making this in public, I think is better, because others can see it, test it if they have same issue or not. Or make a point if this also happens in the stock firmware - which changes a lot in the debugging.

This also saves some time for both sides - writing and answering for the bug report with the exact same issue(s) takes time.

Also PM chat on the Patreon platform has some bugs, which is pretty expected there...

Speaking about the Patreon and increadible amount of problems with it, I was thinking about switching it to another similar platform, but now I have better idea. Which is to make my own platform. For many years I was working as a website programmer and sometimes as a graphic web designer - usually companies has their own separate people for this, but they make their work slower than a sloth.

Reporting bugs encountered on the Patreon website is pointless as I said earlier. Making my own page will make possible to make fixes faster than writing bug reports. Also It will help to avoid Patreon fees I already have one small private server in the datacenter, which has more than enough unused computation power.

I already sent a question to the datacenter owners about data transfer limits, because right now I don't even know if there is any. Hitting this limit will decrease connection speed from 100 mbit/s (that was promised many years ago, maybe today it's more) to something very slow. With the 89 users as it is right now, it can be a problem.

This will also allow to connect one of the best issue tracker, which is Redmine and connect users to it. I installed this on a two servers and I used this when I was working with web pages. This is extremely easy to use and quick to find whatever You need in it. Only one problem with it - it uses programming language that Im currently not familiar with - eventually I can just use its SQL database and put there all users data without the need to learn RoR. Every added issue in Redmine is similar to a topic on the forum, in which others can comment.

Patreon has its own API - if this somehow works more or less properly, I will be able to transfer users data. Likely without passwords, but I can generate random new ones and send it via emails for each user.

BTW. I will be able to do some email notification settings in it, because some users may want less notifications, collective notifications or nothing at all. Of course every feature requires time to implement and to test it.

yes, it is only the first channel - 2-4 are working great! So the AFG seems to be fine.
By switching the SD card to the original one with the stock firmware, channel 1 is also working - so probably not a hardware but a problem with the Mod software /firmware (see image attached).

The calibration on the mod version was done with default settings and after around 30 min. Any other options I could try for the calibration ?

As I said, You can try to run self-cal with 50 ohm terminator on this problematic channel.

Also, If You have separate SD card with the stock app which doesn't have this issue, You can extract /rigol/data from it and put it into SD card with my mod, to check if this was caused by calibration data or not.

You can make a local backup of this dir, like in this example:

Code: [Select]

adb shell
# cd /rigol
# cp -R data data_backup_of_something
After making such backup, You can overwrite or replace this directory with the adb push.

Eventually You can also sent me the contents of this dir, so I can use this with fixing or later when I will start to rewrite whole self calibration.

I have feeling that was caused by lowered time delays in a sel-cal loops - most users didn't have any issues with it, beside of two - or more if somebody didn't reported it.

Edit: optimizations in the self cal was introduced in v0.3, not in v0.3.1.

[norbert.kiszka]

When I tried to to reply on PM, Patreon webpage displayed an error as sometimes it does. I reported this about two months ago and they didn't even answer.

The calibration completes, but it shows an ADC gain offset error.

Most important question: did You had text "success" or "error" at the top?

Did You try to run self-cal again and this remained or not?

Did You saved Android system log (logcat) after this issue? Logs are extremely useful to debug problems.

When you use the reference traces and then remove them, sometimes the labels on the left (e.g., R1) remain visible.

This in the list of the know bugs on the Patreon post with the v0.4.2 Prerelease.

I will try to fix this soon. Right now I need to clean up mess in my lab and to fix issues with my laptop - I attached photo of my brand new heatsink for my 12 years old laptop.

I also wanted to ask if it would be possible to start up with the probe already set to 10x by default.

User interface is the worst place to make any changes, because 99% of it was written in Java - this is the one of many reasons why I want to rewrite it. Currently hardcoding it should be much easier.

Anyway I need to make it carefully, because Rigol used more than a single variable for this. If I will not change every one, it can cause problems with the rendering or with the trigger.

I don't know if everybody will want this hardcoded - but I can do a separate version with this one change.

[baciocco]

Thanks Norbert, yes — at the end of the calibration it said “failed” but still showed 100% completed.
When I opened the lower menu, everything looked fine except for one error in ADC gain.

Now, just out of curiosity, I tried running the calibration again and it stops almost immediately — I think it’s again due to ADC gain & offset.

[norbert.kiszka]

I hate bugs that I can't reproduce. It makes way harder to fix them. Often it's very close to impossible,

Anyway, can You downgrade to the v0.4.1 and check if this problem remains?

[norbert.kiszka]

PS. waveform looks very noisy in Your screenshot.

BTW. You can use a web browser (IP of the scope as a address) to make screenshots - it's way easier.

[baciocco]

Hey Norbert, quick update:

After I retried, the scope got very noisy and the calibration failed.

My usual workaround is: exclude ADC gain, run the calibration, then run ADC gain alone — and that normally works.

I saw the same behavior on the previous version; on v3.1 it did not happen.

One question: on a DHO812, does it even make sense to calibrate Channel 3 (the “added” one)? I see the EXT input showing up as Channel 4.

[eurofox]

On my scope with v0.4.1 I get on 4 channels the same values with GI on 25Mhz and 50Mhz.

I'm surprised that the trace is very clean and crisp with the GI on 50Mhz, with respect to performance of the GI.

[norbert.kiszka]

One question: on a DHO812, does it even make sense to calibrate Channel 3 (the “added” one)? I see the EXT input showing up as Channel 4.

  Now I see the reason of the problem... I forget that You have 2 channel scope, so You don't have AFE for the CH3. My mod has almost completely wiped out Rigol license system and number of channels is hardcoded (this was a part of this system).

I even changed calls to the function which was returning number of channels to things like mov x0, #0x4 for the better performance (few ns for each call, which can happen many times per second).

So the app tries to make a self-cal by using unexisting chip 

Definitely You should unselect CH3.

EXT option available is actually a bug that I left by purpose, because it is a rare case when bug becomes as a feature for a reason.

Eventually You can change CH4 into EXT.

Just in case, You can make a backup of the /rigol/data - in the same way as I wrote earlier.

On my scope with v0.4.1 I get on 4 channels the same values with GI on 25Mhz and 50Mhz.

I'm surprised that the trace is very clean and crisp with the GI on 50Mhz, with respect to performance of the GI.

I didn't changed any code for the rendering waveform, because of my lack of knowledge about OpenGL, which is mostly used for 3D rendering - for example in a computer games.

But If You have low mem depth and You will change acquisition to 'fast', timings in the app will be changed and the waveform rendering usually hides less noise.

Speaking of the AFG, when I overclocked (on my scope for the test) PLL from 1.25 GHz to 2 GHz, AFG was working without any issues with the 1.6 times faster sample rate.

To change sample rate I need also change computation of the output frequency. In such case max output frequency can go up to at least 80 MHz.

Of course there is a LC filter at the output and other bandwidth limiting factors like a opamps and other things. But with the limited amplitude, we can have it.

I already know where is a value in the app that sets AFG sample rate. I didn't touched this (beside of the experiments with PLL to downclock AFG back to original), because I didn't want to make a incorrect output frequency.

[baciocco]

I’m now running the calibration with the default boxes checked, except for the two channels that don’t exist, and everything seems to proceed correctly.

However, now the auto signal acquisition doesn’t work anymore on Channel 1 — it keeps saying “no signal detected”, while Channel 2 works perfectly fine.

[norbert.kiszka]

Some time ago I also had issues with the auto - either no signal detected or enabled more channels. First thing that came to my mind was to check if the same exact thing happens in the stock app and it was the same.

So I desperately need to rewrite as much and as fast as possible. Sometimes fixing code that was written without any thinking before is pointless. Without the source code it's also difficult.

[baciocco]

Is there any way to restore or re-initialize Channel 1?
After the calibration it stopped detecting signals (it always says “no signal detected”), while Channel 2 is fine. Maybe the calibration corrupted some offset or gain values?

[norbert.kiszka]

Is there any way to restore or re-initialize Channel 1?
After the calibration it stopped detecting signals (it always says “no signal detected”), while Channel 2 is fine. Maybe the calibration corrupted some offset or gain values?

I doubt this. Try to set CH1 manually and check if it works correctly. Also You can check if restoring settings to default (physical button or start menu) will change behavior of the auto.

[baciocco]

Problem solved — I reinstalled the previous mod (v4.1).
Before that, I did a few tests and noticed that the only way to make the scope detect the signal with the AUTO button was by setting the probe to 1×, but in that case the signal had a large offset.

However, it’s strange — before I touched the auto-calibration to run some tests, everything was fine.
Now I’ve tried reinstalling the latest mod again, but it still doesn’t detect any signal on CH1.

[mr dem]

Hello, is it reasonable to buy and hack the DHO804 70MHZ 4 CHANNEL 12 BIT oscilloscope in 2025 or should I wait and buy it until Rigol releases a 14 bit oscilloscope? Rigol DH0804 was an economical solution since it was hacked and went up to 250 MHz. If they release a new model, can this be hacked?

[dj2280]

Hey Norbert,

i copied the stock calibration files (which are working as shown in the previous image) and did an overwrite of the mod calibration files. The wrong Amplitude in Channel 1 persists. So it seems not to be a Hardware (cause in stock firmware the Channel is working correctly) neither a Calibration (cause even the working calibration files from the stock didn't solve the problem on the mod firmware) problem - or maybe a Calibration interpretation problem in the mod firmware ? I see there is a default folder in the mode version which not exists in the stock firmware?

Attached are the stock and the mod calibration files.

What would you recommend for further debug investigation ?

Best,
Julian

[norbert.kiszka]

I will revert couple changes and I will publish this as a next prerelease (PR-2).

I hope this will fix issues with the offset after self-cal and with the Auto.

Not all compiled code is clear (because all information from source code is lost), but in auto settings (auto buttons and from start menu), there is a moment when time base is temporary changed to 5 us/D. Even before v0.4.2-PR-1 I was thinking about increasing this to something like 5 ms/D or even more. Theoretically that should change Auto to be able to detect signal more precisely.

But this change (m.a. time base) also may cause it to see internal noise as a signal. Beside of little more time needed to finish everything. I will test it on my scope later.

Attached are the stock and the mod calibration files.

Thank You for those files. I tried those from mod-calibration.zip on my scope and as in the attachment, I see even bigger offset. Looks like You have huge hardware DC offset on CH1.

I think I was right with this timings - I guess increasing it back to original value should fix it for 99.9%. In v0.4.2-PR-1 I changed mem depth in default settings, which are used at a self-cal. Acquisition with bigger memory depth takes more time and it can make app to take measurement data little too early.

[mrisco]

At last I have some free time (not much unfortunately) to make a revision of the oscilloscope software, I think that for the moment the GUI remains as it is and now I want to try some modifications to the binary library. I have read that you use some decompilation tools like IDA in Ghidra, I would like to know if it is enough to download them and use them as they are or it is also necessary to look for additional plugins to support the ARM libraries.

Regards.

[norbert.kiszka]

decompilation

There is no single decompiler that You can use to change anything and compile it back. Only working tools to compile the code are: Your own brain, browser to read a ton of CPU instructions documentation and a incredible amount of coffee.

At least 99% of generated code is a pseudocode being unable to compile it back. And this is not yet the best part. Once Ghidra "decompiled" Assembly code which I wrote and it showed completely different logic than it is in reality. On top of that, it's very slow and it has a lot of bugs.

What can be done in C (or C++ which sadly is the case here) in 5 minutes, You can do the same in Assembly in between 5 hours and 5 days. You can't add or remove the instructions like in Smali. Only change them into different one - slowly one after another.

If You are not familiar how the CPU works and how the functions works from the high level language (like C), be my guest: In C You can wrote function call in a matter of seconds. In Assembly, You need to set up CPU registers (usually up to eight) before a each function call - with that You have to make sure that You didn't overwrite some important register - otherwise You can have a very bad day figuring it out what went wrong and why. I think worse than that are the operations on the stack - one mistake and You have SIGSEGV generated completely somewhere else (good luck to find one simple mistake after some hours).

not much unfortunately

There are a lot of structs, which has a information memory location (only). You have to figure out by Yourself what it does for most of it, because almost all of information from the source code is lost.

Reverse engineering of communication with the hardware, often is almost impossible without using modified Linux kernel - to listen one byte, one after another and to get proper timings and to replace it with Your own data to figure out what You can do and what not so much. Unless You don't want to hack AFE, PLL or the front board (knobs, buttons, leds and power management).

Summary: this is not as simple as the regular scope user thinks (yeah, programmers makes a magic in seconds). One day is not enough to make anything useful in the beginning. Thousands of functions - even with the source code (which nobody has, except Rigol or their outsourced company), it's not easy to read this. At least 30% of the code is a dead code, which usually is not helpful.


Im slowly starting to work with rewriting the app, which will have API to communicate with the open source GUI (HTML, CSS, JS and PHP). And this will have possibility to make Your own GUI from scratch in a quite short time.

HTML+CSS is easy to understand for a monkey, as long as the monkey knows English - Because those two languages are almost just pure English. I think this is the easiest and most comfortable way to make or modify existing GUI (or to make a skin change with the help of OS).

Edit: example of GUI made with HTML+CSS+JS is Steam - most people using computer for a games should be familiar with it.

[mrisco]

decompilation

There is no single decompiler that You can use to change anything

Thank you, I don't know to much about decompilation, Android or libraries for Android, well I don't know too much about anything but my superpower is persistence and obstinacy, so lets go and see what can be done. My intention is not to change too much only enable things which are already there.

[norbert.kiszka]

only enable things which are already there.

Even with this, You have to do this in Assembly.

[norbert.kiszka]

Actually those tables are a waste of time. This is like picking a lock for a 100 hours of work instead of using angle grinder.

[norbert.kiszka]

Still a waste of time to do hacking like this. All of this was hacked years ago by Zelea or whatever his name is.

[kd7eir]

Still a waste of time to do hacking like this. All of this was hacked years ago by Zelea or whatever his name is.

If it's a learning experience for them, then it's not a waste of time.

[kd7eir]

It's time to use something smarter than me in the coding area. I have a simple Copilot AI on my Windows PC — what if I asked it to produce more readable code? Hmm, there's a size limit on the code I can paste into the Copilot chat area.

Take a look at the code that was rewritten by Copilot AI with a little help from me:

Some will give you a hard time about this, but using any available tools to make the job easier is a smart move.

[norbert.kiszka]

I did all of my modifications without using AI - not even once. And I didn't have to read or understand those Rigol license functions.

As I said previously, this is like a picking a lock in a already opened doors.