Rigol HDO1000 and HDO4000 12bit oscilloscopes launched in China

[thm_w]

I did a experimental version. As for now, only as a apk file. Later I will do a .GEL file.

Thank you for that. Could you help with the install process?
I did the stuff mentioned here: https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions/4
but stuck at this point:

Code: [Select]

C:\Downloads>adb install -g -r "Auklet.apk"
Performing Streamed Install
adb: failed to install Auklet.apk: Failure [INSTALL_FAILED_SHARED_USER_INCOMPATIBLE: Package couldn't be installed in /data/app/com.rigol.scope-1: Package com.rigol.scope has no signatures that match those in shared user android.uid.system; ignoring!]
Or is there a way to run it without installing it.

[norbert.kiszka]

adb: failed to install Auklet.apk: Failure [INSTALL_FAILED_SHARED_USER_INCOMPATIBLE: Package couldn't be installed in /data/app/com.rigol.scope-1: Package com.rigol.scope has no signatures that match those in shared user android.uid.system; ignoring!

That's exactly why I needed some dumps from the DHO1000/4000 to make a .GEL file which has Android hacks included. Which I did the same with DHO800/900.

Originally code in Android Package Manager checks if it's a app declared as a system app and checks if this has same encryption signature (key) as the whole system was signed.

There are two possibilities - either hack this PM or remove this:

Code: [Select]

android:sharedUserId="android.uid.system"
from the file AndroidManifest.xml in apk.

This second one not always works and if it will be installed, it will not have "system" privileges, which in this case means no screenshots from the app directly.


I was expecting DHO1000 and DHO4000 to use same exact system compilation, only with different framebuffer resolution, but I wasn't 100% sure.

DHO800 and DHO900 advantage is with everything being on a SD card - in case of worst case scenario, it can be fixed externally after removing it.

From what I know DHO1000 and DHO4000 uses MMC chip soldered directly on PCB and I didn't have any real contents from it, until recently - literally I was waiting 24h for anybody who will dump at least contents from /system/framework just to compare it with DHO800/900 and eventually make a new hack for it - if it's the same, I can use same prepared file, but if it's not, I have to make a new one.

[thm_w]

Ah, sorry about this, stuck at rigol logo. If you get time to dig me out of this hole I appreciate it, but can wait until you finish your other work, no rush. Not sure if I should delete the -2 folders or remove them some other way.

Code: [Select]

rk3399_rigol:/ # pm uninstall com.rigol.scope
Success
rk3399_rigol:/data/app # pm uninstall --user 0 com.rigol.scope
Success
rk3399_rigol:/data/app # ls
com.rigol.en.floatbrowser-2 com.rigol.floatbrowser-2 com.rigol.launcher-2 com.rigol.webcontrol-2

F:\dho1000_backup\rigol\app>adb install -g -r "Auklet.apk"
Performing Streamed Install
Success

rk3399_rigol:/rigol # cd /data/app/
com.rigol.en.floatbrowser-2/            com.rigol.scope-1/
com.rigol.floatbrowser-2/               com.rigol.webcontrol-2/
com.rigol.launcher-2/

I attached the rigol data folder, I'll send a PM with the mmcblk2 link.

[norbert.kiszka]

This framework folder is identical between DHO800/900, Your and from previous person. Which means I can use the same hacked services.jar as I did with DHO800/900.

Before I will make the first .GEL, I will just upload services.jar, updated apk (with 50 ohm switch for DHO1000) and short instruction how to install it properly via adb.


From Your logcat:

Code: [Select]

PackageManager: Failed to parse /system/app/Auklet: Package com.rigol.scope at /system/app/Auklet ignored: updated version 1008000 better than this 1008000
Before installing it (with hacked PM or without), You should delete old app folders as below - also You can backup it just in case.

Code: [Select]

adb shell rm -rf /system/app/Auklet*
BTW. I think those mmc images (likely I only need to update DT at least for different LCD panel) should work on my scope, so I will be able to do a more reliable tests with .GEL without any worry to brick somebody scope (only in MMC memory...).

[norbert.kiszka]

It's published also with the instructions.

Tomorrow I will try to make my DHO924S to "think" that he is DHO1000 with those dumped images and I will prepare and test .GEL file.

[norbert.kiszka]

I took a quick look at the Dave photos and looks like DHO1000 has exactly 4 times more memory for FPGA than DHO800/900. I think there is a huge chance to make a 200 Mpts instead of 100 Mpts.

Theoretically even 400 Mpts. It all depends on the FPGA firmware (app just sends required depth and other things). So I need to make two one additional experimental apks - at worst case scenario it will not work (or it will overwrite part of the memory - which will be visible on the waveform) after setting such depth.

BTW I found similar memory which probably will allow to use it in DHO800/900 to gain more sample rate without limited memory to not more than 15 kpts. With this limit I had everything working properly up to around 2.1 GSa/s (PLL 2.1 GHz) - right now I don't remember exact frequency.

[thm_w]

Appreciate the help, its loading now.

- 20M, 70M, 100M, 200M filter is working. 250M and OFF options are there but don't seem to extend the BW, so maybe they've limited it elsewhere.
- Power analysis appears working
- Logo gone is nice
- 50R relay works, and resistor is inside (50R measured from BNC), but 50R SelfCal box is greyed out, so has some offset

[norbert.kiszka]

so maybe they've limited it elsewhere.

I guess LC filters between AFE and ADC are around 200-250 MHz.

I found and I added 400 MHz filter for DHO800/900 by manipulating bits in one flag, but LC filters are at ~270 MHz. I have one channel with desoldered filters (~1 GHz bandwidth). But even with other channels I see significantly smaller noise when I change OFF to 400 MHz.

Maybe try it with some high frequency noise source or measure rise time if there is any change - I suggest to look into average value (reset stats after changing filter).

but 50R SelfCal box is greyed out, so has some offset

I will take a look into "greying out" code

[norbert.kiszka]

After a quick research I found in this Utility view (programatically speaking) one "license" function (it was checking many ID's for some reason) and I hacked it to always return 1 - after this 50Ω is available and checked by default.

It's the only one change in v0.0.3 - let me know if this works.

[skander36]

...

That's exactly why I needed some dumps from the DHO1000/4000 to make a .GEL file which has Android hacks included.

 ...

I have put from yesterday also the mmcblk2 dump in the same location. I have sent you PM.

[norbert.kiszka]

...

That's exactly why I needed some dumps from the DHO1000/4000 to make a .GEL file which has Android hacks included.

 ...

I have put from yesterday also the mmcblk2 dump in the same location. I have sent you PM.

Thank You. I noticed this earlier - I thought You uploaded this and forget to notice I also sent You PM.

[thm_w]

The 50R can now be checked off, I ran self cal and now no offset on 50R mode. Nice work.

The 2.13 version has full BW which is how I noticed above. So the front end does not need to be modified, at least for 450MHz, but that would be interesting to try your modification in the future. Its something rigol changed to limit the BW in 2.14.

I was wrong before, if I set 20MHz, then set OFF, it goes to some intermediate state that looks very similar to 20MHz. So its setting some AFE values but maybe not all of them, or maybe not the correct ones.

If I set 200MHz then OFF there is no change, so whatever its doing is the same there.
If I look at the log its not calling DrvChannel_SetAfeBandLimit() in the case of 250MHz or OFF.

Code: [Select]

- Press 20MHz:
10-30 00:21:05.541  1307  1374 E [NK.SCOPE]: [drv_channel.cpp][DrvChannel_SetAfeBandLimit][1650]:CH1: CC_TRIM_MUX4：0, CC2_TRIM_MUX4: 0, BW_TRIM_MUX4: 5
10-30 00:21:05.544  1307  1374 E [NK.SCOPE]: [drv_channel.cpp][DrvChannel_SetBandLimit][1600]:DrvChannel_SetBandLimit:20M

- Press 200MHz:
10-30 00:23:54.658  1307  1374 E [NK.SCOPE]: [drv_channel.cpp][DrvChannel_SetAfeBandLimit][1650]:CH1: CC_TRIM_MUX4：3, CC2_TRIM_MUX4: 1, BW_TRIM_MUX4: 27
10-30 00:23:54.661  1307  1374 E [NK.SCOPE]: [drv_channel.cpp][DrvChannel_SetBandLimit][1233]:DrvChannel_SetBandLimit:200M

- Press OFF or 250MHz, does not call function:
10-30 00:30:30.235  1307  1374 E [NK.SCOPE]: [vertical_offset.cpp][ApiChannel_SetOffset][37]:ApiChannel_SetOffset offset=40000
10-30 00:30:30.239  1307  1374 E [NK.SCOPE]: [drv_scope.cpp][ConfigHorizontal][2691]: >>>> WavePlay main>>>>
10-30 00:30:30.241  1307  1374 E [NK.SCOPE]: [drv_scope.cpp][ConfigHorizontal][2692]:WavePlay:ChnMode     :1

So maybe its a change in there or DrvChannel_SetBandLimit(unsigned int, unsigned int, unsigned int)

I see some switch statements referring to "1000" and "4000" I guess that its how it differentiates the model.

Code: [Select]

case 3:
    if (iVar3 == 1000) {
LAB_002de780:
...
LAB_002de9d0:
      DrvChannel_SetAfeBandLimit
                (param_1,iVar3,iVar4,*(int *)(lVar8 + uVar7 * 0x60 + (ulong)(uVar15 | 0x350000)));
    }
    else {
      if (iVar3 == 4000) {
...  //HDO4000?
      }
      if (iVar3 == 2000) goto LAB_002de780;  //HDO2000?
    }
    if (lVar11 < 1000000000) {
      if ((lVar11 != 250000000) && (lVar11 == 500000000)) { 
        uVar15 = 0xb;
        goto LAB_002ded94;
      }

[norbert.kiszka]

Looks like I need to investigate bandwidth ID's between functions. I didn't modified one function, because same function in DHO800/900 was problematic for me at the beginning, but finally I modified it. I think the problem is here - let me check this.

[norbert.kiszka]

Now I see that OFF and 250 MHz options doesn't call function which sends data to the AFE.

I need to figure out where to make a jumps to bypass some conditions.

[norbert.kiszka]

It's fixed with some extras.

Please confirm if it's ok or not so much.


BTW. After some optimizations would be nice to see waveform update rate - how much faster it is right now vs. stock app.

[norbert.kiszka]

On the side note I noticed there is a lot of BW filters in AFE and ADC.

For example DHO800/900 has 125 MHz and MHO900 has 350 MHz and 500 MHz. Also MHO2000 has 350 MHz.

I need to make sure, but I think all of them has same AFE and ADC IC's.

It will be a lot of work to combine it together into one series mod. But I think it should be worth it.

And with some experiments with communication with those, maybe even more. Enum in UI part (compiled Java) has a huge number of BW filters.

[thm_w]

It's fixed with some extras.

Incredible work, norbert has unlocked 1GHz!:


The 20MHz has some higher frequency leakage until switching to 70MHz then back to 20MHz, but I don't really care, this is amazing as it is.
As you said the AFE seems to have many filter options. I remember the older TI AFE they used before had only a few.

BTW. After some optimizations would be nice to see waveform update rate - how much faster it is right now vs. stock app.

I can't measure it currently, I'll bring some better equipment next week.

edit: -3dB in 50R mode measured at 900MHz using tinySA (not a clean sine source but should be close)

[voltsandjolts]

I took a quick look at the Dave photos and looks like DHO1000 has exactly 4 times more memory for FPGA than DHO800/900. I think there is a huge chance to make a 200 Mpts instead of 100 Mpts.

Theoretically even 400 Mpts. It all depends on the FPGA firmware (app just sends required depth and other things).

The DHO1000 series ("max" 100MPts) seem to use the same FPGA and DDR as the DHO4000 series, which has 500MPts.
https://youtu.be/qEpkVa_ysaw?t=411

[norbert.kiszka]

Incredible work, norbert has unlocked 1GHz!:

I was almost sure that DHO1000 has LC filters (SMD components close to ADC) calculated either for 200 MHz (-3 dB) or 800 MHz.

In earlier version (v0.0.3) I didn't read deassembled and decompiled code too much and I thought those 1000/4000 conditions are somehow related to actual hardware differences. After second look, it was clear that it's disabling possibility to use some filters.

The 20MHz has some higher frequency leakage until switching to 70MHz then back to 20MHz

I have to see if there is any call to ADC filters related to this. I still wonder how many more filters I will be able to "make". My DHO924S has exact the same AFE and ADC chip (with desoldered LC filters it has 1 GHz bandwith).

Some people was thinking that Im some idiot because "You can't measure such high bandwidth on a 1.25 GSa/s scope". But I know how ADC works and I know how I can measure bandwidth even beyond sample rate - maybe it's not very precise, but it is possible.

The DHO1000 series ("max" 100MPts) seem to use the same FPGA and DDR as the DHO4000 series, which has 500MPts.
https://youtu.be/qEpkVa_ysaw?t=411

Sounds like a plan to me

Im not 100% sure about FPGA being exactly the same - in the code it loads different FPGA firmware, which is selected by the "hdcode" which almost certainly is different between DHO1000 and DHO4000.

Of course hack of loading different image is simple - either copy file or make a symbolic link (Windows users probably don't know what are hard and symbolic links).

[skander36]

...

almost certainly is different between DHO1000 and DHO4000.

...

Is different because it has to use both ADC's in DHO4000.
This is why vendor.bin method can't be used, it doubled or halves measurement values. But visually you can observe the same amplitude until 900 MHz using one channel.
Also this mod activate 500 Mpts of memory so it can a base for you to try to activate it with your mod, although I am not sure if there are really 500 Mpts on DHO1000 board.

P.S. Modified MB with Mpts

[voltsandjolts]

According to Dave's video that I linked, the FPGA IC is the same and the DDR is equivalent, to the DHO4000.
Dave states that at the video time I linked.
Yes, the FPGA bitstream will be different - so maybe Rigol hardcoded a 100Mpts limit in the DHO1000 bitstream?

Dave Photo Albums with HDO1K and 4K:
https://www.flickr.com/photos/eevblog/albums/with/72177720307943576

[indeterminate]

The 1000 & 4000 both use 4x Micron MT41K256M16TW-107:P dram chips
IC DRAM 4GBIT PAR 96FBGA
organized as 256M x 16

[skander36]

...

Minor typo there; you meant 500Mpts (not MB). There is 2GB total memory attached to FPGA (on DHO1K and 4K).

Yes you are right. I've modified in post.
With vendor.bin mod when you choose 500 Mpts in acquisition menu, the acquisition will slow more that whith 100 Mpts, as with any other scope when you increase memory to similar level.

[gf]

Some people was thinking that Im some idiot because "You can't measure such high bandwidth on a 1.25 GSa/s scope". But I know how ADC works and I know how I can measure bandwidth even beyond sample rate - maybe it's not very precise, but it is possible.

The sample rate is, of course, not the problem if you measure a CW test signal. But do DHO800/900 have a true 50 Ohm input? An external terminator forms a lowpass with the input capacitance of the hi-Z input, and 25 Ohm || 15...10pF gives roughly 400...600 Mhz cutoff.

[norbert.kiszka]

Some people was thinking that Im some idiot because "You can't measure such high bandwidth on a 1.25 GSa/s scope". But I know how ADC works and I know how I can measure bandwidth even beyond sample rate - maybe it's not very precise, but it is possible.

The sample rate is, of course, not the problem if you measure a CW test signal. But do DHO800/900 have a true 50 Ohm input? An external terminator forms a lowpass with the input capacitance of the hi-Z input, and 25 Ohm || 15...10pF gives roughly 400...600 Mhz cutoff.

I told it here hundreds times. I have modified one channel - including added permanently 50 ohm by soldering four resistors into soldering pads of a BNC socket.

Also I was providing square wave from logic gate soldered directly into BNC plug.