Hacking the Rigol DHO800/900 Scope

[shapirus]

I don't know how others think about it, but since a long time I disliked the seven-segment style font of the hardware frequency counter function. Do you think it's possible to replace that font with something that better blends in with the other U/I typefaces?

That said, though, it should be visually different in some way, because, unlike other measurements that involve, so to speak, postprocessing, frequency counter is special, because it comes raw from a deeper level, probably the zero crossing detector or something like that.

Moreover, IMO it would be a substantial improvement if it's possible to detach the frquency counter window from the other measurements and place it arbitrarily on the screen, independent of the "result" box.

Yes!

[AndyBig]

This is coming nicely together, Andy, thanks for your continuing effort.
Maybe it is a personal thing, but I don't like the space between the measurement items where the signals peep through.
Is it possible to have one 'block' and each item separated by a gray line?

Thank you! Yes, I myself am struck by this gap between the elements of the measurement results. I will probably really try to increase the height of the elements a little due to these gaps. And I will outline each element with a gray line. Or there will be only one line at the bottom of the element, I will have to see how it will look better.
But this is in the next version, and for now I am posting the release with the current changes - https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod/releases/tag/a005_00.01.04.00.02

I'ld also like to express my respect and gratitude for this amazing effort of yours, Andy! IMO it's very generous to offer such an extensive job to the public free of charge.

Thank you! Well, I don't refuse voluntary donations ) True, they are only possible within my country... But for a monthly subscription to the AI ​​in VS Code, which helps me modify the application, donations have already accumulated ))

I don't know how others think about it, but since a long time I disliked the seven-segment style font of the hardware frequency counter function. Do you think it's possible to replace that font with something that better blends in with the other U/I typefaces? I experimented with replacing the "digital_numbers.ttf" font directly on the scope with some sans serif font under the same name but didn't succeed.

I think that replacing the font is not a big problem. But honestly, I don't see anything bad in the current segment font. A kind of analogue of a meter with the appropriate stylization

Moreover, IMO it would be a substantial improvement if it's possible to detach the frquency counter window from the other measurements and place it arbitrarily on the screen, independent of the "result" box.
Thanks so much and all the best,
Thomas

This, I think, will be quite difficult to do, although theoretically possible. I'm not sure I can implement it

[Carbedd]

While I wait for my 804, it should arrive next week, I remain more and more positively impressed by the work of some members.

👏👏👏👏

[iMo]

I would perhaps recommend to start using Andy's github for issuing your suggestions for improvements and/or bugs as well (ie in parallel with the discussion here). Thus he will get all on the same place and organized.

[RAPo]

Could you elaborate?
Do you make a VS-Code plugin? If so please give a pointer?

Thank you! Well, I don't refuse voluntary donations ) True, they are only possible within my country... But for a monthly subscription to the AI ​​in VS Code, which helps me modify the application, donations have already accumulated ))

[AndyBig]

Could you elaborate?
Do you make a VS-Code plugin? If so please give a pointer?

Thank you! Well, I don't refuse voluntary donations ) True, they are only possible within my country... But for a monthly subscription to the AI ​​in VS Code, which helps me modify the application, donations have already accumulated ))

No, I use a paid extension for VS Code - Cursor AI. This extension helps a lot to understand the decompiled sources of the oscilloscope application
More precisely, this is not an extension for VS Code, but a separate VS Code distribution with integrated AI.

[RAPo]

Are you referring to Helixform? or this tool?
if so, how can I use this to financially help you?

No, I use a paid extension for VS Code - Cursor AI. This extension helps a lot to understand the decompiled sources of the oscilloscope application
More precisely, this is not an extension for VS Code, but a separate VS Code distribution with integrated AI.

[Obiwantje]

This might be a silly question - I am running Sparrow05 and just noticed that the timezone is wrong on the display - For the life of me I can't seem to find where to change this?

[AndyBig]

Are you referring to Helixform? or this tool?
if so, how can I use this to financially help you?

No, I use a paid extension for VS Code - Cursor AI. This extension helps a lot to understand the decompiled sources of the oscilloscope application
More precisely, this is not an extension for VS Code, but a separate VS Code distribution with integrated AI.

Yes, I'm talking about this tool - https://www.cursor.com/
Thanks for the offer, I don't need help yet But I'll keep your offer in mind, thanks again

This might be a silly question - I am running Sparrow05 and just noticed that the timezone is wrong on the display - For the life of me I can't seem to find where to change this?

To do this, you need to edit the oscilloscope startup script. This script is hardcoded to the time of Shanghai, China.
Here is a good tip on how to do this without breaking the oscilloscope - https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5783681/#msg5783681

[Antgue]

Hi to all and congratulations for wonderfull job.
I bought dso804 and i would like to add the signal generator for bode plot funcion.
As i see, maybe need to add a small board on the main, someone have some good pics for try to copy it?
Thanks in anvance
Antonio

[Antgue]

Mentre aspetto il mio 804, dovrebbe arrivare la settimana prossima, rimango sempre più positivamente colpito dal lavoro di alcuni membri. 👏👏👏👏👏

Pure io sono in attesa di consegna

[AndyBig]

Hi to all and congratulations for wonderfull job.
I bought dso804 and i would like to add the signal generator for bode plot funcion.
As i see, maybe need to add a small board on the main, someone have some good pics for try to copy it?
Thanks in anvance
Antonio

There is even a circuit diagram of this generator, reconstructed from the board by one of the users.

[TurboTom]

FYI - here is the thinking and the answer of DS/DT to my Q re the roll vs. none-roll waveview noise difference.. 

Just out of peculiarity, I did some more tests regarding the roll mode noise issue. First, I compared the normal mode to the roll mode peak-to-peak noise, and -- surprise, surprise -- they are very similar. In fact, noise in normal mode is slightly higher due to the wider measurement window and the correponding bigger effect of the 1/f component, see sttached screenshots.

Then I checked the effect of the roll speed. Once again, I found something unexpected: The slower the timebase is set, the higher the measured AC RMS noise. What's quite surprising is that the update rate of the measurenment counter in roll mode stays at the same speed, regardless of the timebase setting. Provided Rigol doesn't use the complete (screen shadow) memory / screen contents to calculate this figure, but only the newly shifted in data, this means, the number of samples that contribute to the sandard deviation calculation gets smaller, the slower the timebase is running.

Due to the possibly higher "granularity" of the smaller sample count, and since the count is in the denominator of the standard deviation calculation, this may lead to higher "indicated" RMS levels, which may even be mathematically correct. If Rigol always used the full screen contents (or the same window width that's being used in normal mode) for the AC RMS calculation, and not only the newly acquired data subset, this whole problem shouldn't exist. But I'm not a statistician and I'm not completely sure if this take is correct. At least, it seems Rigol somehow messed up the math of RMS / AC RMS measurement in roll mode.

P.S. During this testing episode, I noticed that the choice of the region of a measurement is only globally possible -- I cannot apply a measurement of one channel to the main screen while I apply another measurement of a different channel to the zoom window, the setting will always change for both measurements... I guess the price of this scope implies some disadvantages

[ebastler]

Mentre aspetto il mio 804, dovrebbe arrivare la settimana prossima, rimango sempre più positivamente colpito dal lavoro di alcuni membri. 👏👏👏👏👏

Pure io sono in attesa di consegna

@Carbedd, @Antgue: You might have noticed that English language is used throughout this forum. When you post here, could you please make the effort and run your text through a translator? That way, you have to do the translation once -- rather than every reader who does not speak Italian (and does not want to ignore you) having to do that for himself. Thanks!

[iMo]

FYI - here is the thinking and the answer of DS/DT to my Q re the roll vs. none-roll waveview noise difference.. 

Just out of peculiarity, I did some more tests regarding the roll mode noise issue.

It would be interesting to test this further by manually capturing and calculating RMS values from exported data at different time bases to see if the discrepancies hold up..

[Carbedd]

Sorry, just done 😇

[norbert.kiszka]

The noise is believed to come from semiconductor interface traps.

If You remove driver module (Linux kernel module, comment out line with insmod spi2afe_gpio.ko) of a AFE (SPI communication with IC in AFE for every channel), noise drops significantly (couple times, I don't remember exact values) - I posted this about month ago. Also I recreated this module from reverse engineering if somebody wants to do some experiments with it (GPL licence, free of charge - Im not same idiot like Rigol company).

Also, If You compare photos of DHO800/DHO900 and DHO4000, it looks like most of noise comes from AFE power supply which is DC/DC converter in case of DHO800/DHO900 and ultra-low noise LDO in case of DHO4000. That's why we have bandwidth limited to 250 MHz. After removing LC filters, bandwidth is increased to above 1 GHz, but noise is quite big - still it's useful, but only when measuring digital signals or with average acquisition enabled. I have plans to do modifications and experiments with it, after I do other things...

There is even a circuit diagram of this generator, reconstructed from the board by one of the users.

There is even working source code with two drivers for this AFG. To be more precise, I did it.

[Antgue]

There is even working source code with two drivers for this AFG. To be more precise, I did it.

If it's public, it's possible to have some info about it?
I don't find how buy this original "generator board" and i'm evaluating if build it or change my dho804 in dho914s
Many thanks

[norbert.kiszka]

Rigol drivers in kernel 4.4.179: https://github.com/norbertkiszka/rigol-orangerigol-linux_4.4.179/tree/main/drivers/rigol (only most important drivers - to handle input data and AFG).

Rigol drivers in kernel 5.10.209: https://github.com/norbertkiszka/Linux-5.10-Rockchip/tree/develop-5.10/drivers/rigol (as above and without AFE, but with some cleanup in code).

In 4.4.179 touchscreen driver was taken from 5.x.

In 5.10.209 xdma drivers (two versions to chose with Kconfig) was moved into more appropriate location: https://github.com/norbertkiszka/Linux-5.10-Rockchip/tree/develop-5.10/drivers/xilinx/xdma

As I said before, all of it was done by reverse engineering. AFG drivers works correctly for 100% - I even tested it with voltmeter (relays).

Anyway, it looks like only voltage dividers and power on/off is controlled by this two drives, but data is sent by FPGA (in real time), which makes sense, because RK3399 is too slow to handle all channels, measurements and AFG at the same time.

For 99% my project "Orange Rigol" will be moved into kernel 5.10, because it's more efficient and it has more bug fixes. I wonder why Rigol didn't use kernel 5.x... Maybe they were too lazy to work with it (to make changes needed to have fully working RK3399).

[Antgue]

Many thanks, i'll try it when i'll solved the missing AFG hardware.
Unfortunately i'm expert in hardware, but not in software and  maybe i'll disturb you again.
Greetings

[iMo]

..If You remove driver module (Linux kernel module, comment out line with insmod spi2afe_gpio.ko) of a AFE (SPI communication with IC in AFE for every channel), noise drops significantly (couple times, I don't remember exact values) - I posted this about month ago. ..

What would be interesting: to start play with "the AFE settings", if available.
What I mean - gentle, incremental changes in some relevant numbers there..
Removing the drivers could be the next step before the replacing of the original OS..   

[norbert.kiszka]

..If You remove driver module (Linux kernel module, comment out line with insmod spi2afe_gpio.ko) of a AFE (SPI communication with IC in AFE for every channel), noise drops significantly (couple times, I don't remember exact values) - I posted this about month ago. ..

What would be interesting: to start play with "the AFE settings", if available.
What I mean - gentle, incremental changes in some relevant numbers there..
Removing the drivers could be the next step before the replacing of the original OS..   

Those are very simple drivers, both original and my "remake", which is recreation 1:1 (beside of hdcode_gpio driver which is writable in my case). In case of AFE and PLL loop, that two drivers use GPIO pins to emulate SPI bus in one direction only. Created device file (/dev/spi_simulate and /dev/spi_3wires_lxm2582), takes data (every write into that file), "dissasembles" it into every single bit and sends it as it is. If You want to play with AFE, You need to decompile libscope-auklet.so.

In case of PLL, used IC is LXM2582 and datasheet is available. To overclock this scope (sample rate), most likely we need to overclock and overvoltage RAM by editing devicetree (decompiled DT can be compiled back as it is). Also heatsink for memory modules is necessary in that case.

[LEER333]

The DHO8/9 and DHO1000 hardware looks the same, but the DHO1000 is 2GSa/s and the DHO8/9 is only 1.25GSa/s, so it would be nice to switch to 2GSa/s sampling as well

[AndyBig]

The DHO8/9 and DHO1000 hardware looks the same, but the DHO1000 is 2GSa/s and the DHO8/9 is only 1.25GSa/s, so it would be nice to switch to 2GSa/s sampling as well

No, they have different hardware and there is no easy way to increase the sampling rate of 800/900.

[norbert.kiszka]

The DHO8/9 and DHO1000 hardware looks the same, but the DHO1000 is 2GSa/s and the DHO8/9 is only 1.25GSa/s, so it would be nice to switch to 2GSa/s sampling as well

I think 1.4 GSa/s or 1.6 GSa/s is more real limit of overclocking FPGA and DDR3 memory.