Hacking the Rigol DHO800/900 Scope

[norbert.kiszka]

Btw., after I had lost an usb flash drive (I mean the data after inserting it into my DHO) while trying to save 50MPts waveform off memory to it, I started thinking how to get the data saved on an usb flash into python or excel or whatever..
The CH1 only 50Mpts data saved in .csv is 762MBytes, in .wfm 197MB and in .bin 93MB.
Is there a python lib for messing with DHO800/900 data sets available somewhere?
For example AI recommended to me kindly either read the DS, or to try to ask at EEVblog forum, so I do..

50 milion points gives 100 milion bytes (1 byte = 8 bits). 100 000 000 / (1024 * 1024) = 95.367431640625 MiB (MiB, not MB !!!). If You have exactly that much, it means it is at it was saved by the FPGA.

I guess You are not every day hacker, so probably You don't even know how to manually read first sample (simple hexdump on Linux console is Your friend). With that real world format, I don't know if there are something on GitHub, but even if there is something, it will don't know offset or scale (You have values like from -1 to 1, which You need to multiply by something and offset it), unless You give necessary data.

csv I guess is a Rigol pseudo-csv format - so You need to look only for Rigol tools.

wfm - I really don't know.

Maybe good old sigrok will be able to open and understand one of these and make some magic that You want.

BTW. If You wan't to use single channel only, without LA, You can use this: https://github.com/norbertkiszka/Sparrow_DHO800_DHO900/raw/refs/heads/main/app/dist/Sparrow.apk (repo) to have 125 M points, but only in auto. If You want manual and much more things, Im currently working on it.

[iMo]

Those MBytes are the numbers I see in windows with the files I stored, not somehow calculated..
In the .csv it saved as floating point strings (like 16chars), therefore aprox those 780MB.

[norbert.kiszka]

Those MBytes are the numbers I see in windows

This is one of many reason, why Im not using Windows, but Debian (with Linux as a kernel, but it also works with *BSD).

[iMo]

Those MBytes are the numbers I see in windows

This is one of many reason, why Im not using Windows, but Debian (with Linux as a kernel, but it also works with *BSD).

Yep, you are a happy camper when your files in your linux are just 1/8 of the Windows one.. I have to switch to linux asap ..

This could be a good start:
https://rigolwfm.readthedocs.io/en/latest/0-Basics.html?utm_source=chatgpt.com

[shapirus]

Btw., after I had lost an usb flash drive (I mean the data after inserting it into my DHO) while trying to save 50MPts waveform off memory to it, I started thinking how to get the data saved on an usb flash into python or excel or whatever..
The CH1 only 50Mpts data saved in .csv is 762MBytes, in .wfm 197MB and in .bin 93MB.
Is there a python lib for messing with DHO800/900 data sets available somewhere?
For example AI recommended to me kindly either read the DS, or to try to ask at EEVblog forum, so I do..

The .csv should be easily importable into speadsheet programs (like libreoffice calc or google sheets or ms excel), it's a plain text file with one row per line and columns separated by commas (plus some quoting and escaping techniques). Once imported, you can do whatever you need, including plot visualization or math statistics.

There are many libraries for nearly any language to read CSV files into internal data structures, if you want to write your own data processor.

[iMo]

We messed a lot with .csv from Rigols here already (ie Bode), but we are talking 780MB with a single channel (and 50Mpts == 50million .csv lines).
So we need to master the .bin or .wfm formats which are much smaller.

PS: with more channels it will stay the same volume aproximately, as the mem halves with each channel, afaik..

These are the first lines in the .csv file = 16bytes*50.000.000 in total

Code: [Select]

CH1V,t0 =-5.000000e+01, tInc = 2.000000e-06,
+4.600000e-03,,
+5.600000e-03,,
+3.586666e-03,,

[norbert.kiszka]

We messed a lot with .csv from Rigols here already (ie Bode), but we are talking 780MB with a single channel (and 50Mpts == 50million .csv lines).
So we need to master the .bin or .wfm formats which are much smaller.

PS: with more channels it will stay the same volume aproximately, as the mem halves with each channel, afaik..

You just reminded me, how fast RK3399 (CPU used in those series) really is. handling 100 MB in memory or with PCIE (between FPGA and CPU in those scopes) is not a very big deal (not good not terrible). But they made their app to make it incredibly slow. My analysis of the system and app, gives me a clue, that it was made in India, not in China, since those are more cheap - maybe they don't know what they doing, but it's still very cheap. Boeing doing second version of MCAS was outsourced it in India, which ended with sudden lost of life of 346 people, because both sides didn't care about nothing - just like Rigol.

[shapirus]

We messed a lot with .csv from Rigols here already (ie Bode), but we are talking 780MB with a single channel (and 50Mpts == 50million .csv lines).
So we need to master the .bin or .wfm formats which are much smaller.

The .bin file, judging by the size, must contain a sequence of 50M two-byte records. Plus it should have some header to indicate the sampling interval and perhaps some other info. I would guess that its format should be the same across all Rigol scopes. Internet search gives some results, for example, here someone already parsed it: https://github.com/ngscopeclient/scopehal-apps/issues/287

The .wfm I'm not sure. It may be the same, except with one 32-bit word per sample, or something like that. Of course someone has already solved the task of decoding them too: https://github.com/scottprahl/RigolWFM

[kmoonwalker]

We messed a lot with .csv from Rigols here already (ie Bode), but we are talking 780MB with a single channel (and 50Mpts == 50million .csv lines).
So we need to master the .bin or .wfm formats which are much smaller.

PS: with more channels it will stay the same volume aproximately, as the mem halves with each channel, afaik..

You just reminded me, how fast RK3399 (CPU used in those series) really is. handling 100 MB in memory or with PCIE (between FPGA and CPU in those scopes) is not a very big deal (not good not terrible). But they made their app to make it incredibly slow. My analysis of the system and app, gives me a clue, that it was made in India, not in China, since those are more cheap - maybe they don't know what they doing, but it's still very cheap. Boeing doing second version of MCAS was outsourced it in India, which ended with sudden lost of life of 346 people, because both sides didn't care about nothing - just like Rigol.

You would be surprised how often programming projects are divided into small tasks made by independent (and cheapest) individuals whom often really have no clue or barely grasp the sense of whole project due to secrecy etc
It results in such slow sluggish apps we nowadays have... also frameworks are usually sluggish (but usually not as bad in such devices).

I am kinda a fan - been following your progress from some time - great job so far

[norbert.kiszka]

You would be surprised how often programming projects are divided into small tasks made by independent (and cheapest) individuals whom often really have no clue or barely grasp the sense of whole project due to secrecy etc
It results in such slow sluggish apps we nowadays have... also frameworks are usually sluggish (but usually not as bad in such devices).

I have some years done with huge projects. Most known is National Geographic (previous owner, not Burda) and little bit as an admin. Sometimes there is a single person, after which I needed to spent more time to fix his code that (s)he did. It's impossible to count how many companies get broke, because of that methods with cheap workers and incredible (but heavily related) small tasks.

Just image oscilloscope, which has candy-looking buttons and borders around windows that takes half of the space available on 7'' screen. And it makes math operations on 200 MB data with scripts. More of that, sending 138 bytes to the PLL via SPI takes almost three seconds. Do You know one model like this?

[kmoonwalker]

I suppose your fav one 900 series 

[Songhua]

You would be surprised how often programming projects are divided into small tasks made by independent (and cheapest) individuals whom often really have no clue or barely grasp the sense of whole project due to secrecy etc
It results in such slow sluggish apps we nowadays have... also frameworks are usually sluggish (but usually not as bad in such devices).

I have some years done with huge projects. Most known is National Geographic (previous owner, not Burda) and little bit as an admin. Sometimes there is a single person, after which I needed to spent more time to fix his code that (s)he did. It's impossible to count how many companies get broke, because of that methods with cheap workers and incredible (but heavily related) small tasks.

Just image oscilloscope, which has candy-looking buttons and borders around windows that takes half of the space available on 7'' screen. And it makes math operations on 200 MB data with scripts. More of that, sending 138 bytes to the PLL via SPI takes almost three seconds. Do You know one model like this?

it makes math operations on 200 MB data with scripts.

It's crazy. How hard could it be to optimize the math using C, C++ or Rust?

sending 138 bytes to the PLL via SPI takes almost three seconds.

Light speed 299,792,458m/s, earth diameter 12,756 km. 3 seconds light around the earth -> 70.5 loops on the earth. (But these 138 bytes hasn't reach yet)

[iMo]

No problem of reading 50million csv lines in python, sure. What could be an issue with those .csv files is their size ..
Below a histogram made upon 50MPts coming from my rigol (781MB large csv file).

[tautech]

No problem of reading 50million csv lines in python, sure. What could be an issue with those .csv files is their size ..
Below a histogram made upon 50MPts coming from my rigol (781MB large csv file).

As has always been.

Saving as a smaller .BIN file format has been the way to go with other brands to convert back to CSV on the PC with a converter utility download available directly from the scope.

[Mateusz5]

Hello everyone.

I'm a new Rigol DHO804 users. I saw a several solutions hacks, sparrow app etc. in this topic. I am curious about if someone tried it before to use the DHO800 serias with an USB saleae logic analyzer. It can be possible to reroute the internal app solution UI for example if the version updated to DHO824 the logic analyzer module to work from an USB logic analyzer? It will be really helpfull because it can be extend the capability of the oscilloscope. Really thank you your answers.

[norbert.kiszka]

I don't think so.

There is some hidden (disabled) USB related code, but it's rather USB bus decoding. Maybe some day I will try to make it work.

[Mateusz5]

Because i started to thinking on it. Theoritacally if a backend module or app in android can be work and get the information from the saleae, after it need to bind it to to the UI data somehow, but i not see through clearly the UI solutions. I started to check the sparrow source code but i'm not perfect in java,android system codes. It will be good if can be solved somehow because without HW improvement can be make it work the logic analyzer with a DHO800 serias too.

Thank you the answer norbert.kiszka.

[Songhua]

This is a really nice proposal.

There is an opensource project for protocol analysis called sigrok and It has Android version which can be installed to your osilloscope! https://sigrok.org/wiki/Android (here's the tutorial and source codes)

It's opensource. If it can't be installed. Try to compile 1 apk for ARM64 v8a Android 7.1 platform using Android Studio. Also be sure to embed/compile the corresponding USB kernel module something .ko or .so for pure Linux and anbox and run native Android apps on standalone Linux.

[norbert.kiszka]

It's crazy. How hard could it be to optimize the math using C, C++ or Rust?

All three will be much much faster. But I would prefer C (and sometimes assembler), since it's fastest and I have some knowledge and experience with it.

sending 138 bytes to the PLL via SPI takes almost three seconds.

Light speed 299,792,458m/s, earth diameter 12,756 km. 3 seconds light around the earth -> 70.5 loops on the earth. (But these 138 bytes hasn't reach yet)

You can check it by Yourself: https://github.com/norbertkiszka/Rigol-tool-spi2pll_lxm2582

[Songhua]

In my current development, this is not on the priority list of my changes. I think to test 1.5625 GHz, which should work without decreasing memory depth and it will give "round" time per sample of 640 ps.

It's not really much of a step up from 1.25 GHz though. Still not enough to match the bandwidth of 250MHz with 4-channels.

But I guess it's useful if you modified the front end to 900Mhz bandwidth. :-)

Probably you should push the Rigol DHO924S to 2.0GSa/s. That's because the new osilloscope from OWON ADS924A which might has the same hardware as DHO924S has been out. The ADS800A is being sold in China now.

https://www.owontech.com/digital-oscilloscopes/benchtop-oscilloscopes/ads900a-series-12bits-multifunction-digital.html

The little different between ADS924A and DHO924S is

```markdown
|Spec| ADS924A|DHO924S|
-------------------------------
|Sample Rate| 2G | 1.25G|
|AFG | 30MHz | 25MHz|
|Mem Depth| 100M | 50M|
|Math| Has user defined math | Only simple math|
|Max waveform capture rate| 700,000 wfms/s | 500,000 wfms/s |
```

ADS924A is also running on Android.

If OWON ADS924A uses the same board and ADC chips, 2.0GSa/s should be avaiable and stable.

[norbert.kiszka]

If OWON ADS924A uses the same board and ADC chips, 2.0GSa/s should be avaiable and stable.

Same FPGA, same DDR3 chip, same PLL and same distance from PLL?

My scope can handle 1.8 GHz (1.8 GSa/s) with memory depth limited to 15875 points. More points above that gives waveform like with some cuts from time to time (I can use 125 M, but only first 15 875 are correct). Higher freq. than 1.8 GHz gives complete pandemonium.

There are three possibilities of this: FPGA is too slow or RAM is too slow or distance from PLL is the distance is too great to handle higher frequency. Zynq 7015 has internal memory of 256 KB - maybe that is used for caching samples or there is a delay in changing pages in RAM chip.

BTW. On that image, BNC sockets at the back are kinda misplaced - DHO9xx has AFG at the top.

[norbert.kiszka]

PS. Without teardown photos and/or firmware I can't do too much. I can just guess and nothing more.

If this has exact the same PCB and exact the same FPGA (eventually same or similar RAM chip) and in same time this really can do 2 GSa/a, SD card image would be really helpful.

BTW. Maybe they used different FPGA firmware?

[norbert.kiszka]

Anyway, I finished one part with handling more memory depth manually. That wasn't easy, I can tell.

Now I need to do limits for more than one channel, average acquisition and LA enabled. Unless somebody want's to get corrupted data from the scope.

Edit: I added two more screenshots.

[Fungus]

Does anybody know what the extra RAM chips in the DHO900 are for yet?

[Songhua]

Good job by now.

Nice to see the mem depth 125M is enabled.

Yes without tearing down the Owon ADS900A, we don't know what is inside. We can only guess from the specs. Right now we don't have sources to buy ADS900A but ADS800A is being sold on taobao.com at a decent price like rigol DHO800.

Increasing sampling rate is really important. Nowadays even handheld multimeter/oscilloscope can have 1-2GSa/s. The default Rigol DHO924S 1.25GSa/s is like a joke. Even Siglent cheapest-entry-level SDS800X has 2.0GSa/s, 100M mem depth by default.

BTW, did you test the actual bandwidth of DHO924S after software unlocking the bandwidth (Max 800MHz) using Sine Wave (-3db) test? How is the performance?