EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: sebyon on September 23, 2023, 03:54:38 am
-
Placeholder thread for hacking the Rigol DHO800/900 scope.
The general discussion thread can be found here.
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/ (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/)
@hubertyoung has provided a DHO804 FW1.14 image with the DHO924 vendor file preloaded. It can be extracted using 7zip then flash using HDD Raw Copy Tool (compressed image).
https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8 (https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8)
@Luc7777 provided some guidelines on how has has achieved this.
Hi,
- This is what I've done:
1. Run the Win32 Disk Imager
2. Backup the SD
3. Flash the SD with the image from the link
4. Run the claibartation (offset gone) - device identifies as DHO804
5. Connect the scope to ethernet
6 Run adb:
6.1 adb devices
6.2 adb connect 192.xxx.x.xxx:55555
6.3 "adb pull /rigol/data/vendor.bin"
6.4 backup the generated vendor bin file from the adb folder to a new location
6.5 copy in the adb folder the DHO924 image
6.6 "adb push vendor.bin /rigol/data"
MOD EDIT:
Here is the latest instructions:
https://www.youtube.com/watch?v=Az9lXMGV_jM (https://www.youtube.com/watch?v=Az9lXMGV_jM)
DHO800/DHO900 UNLOCK TOOLS
1) Install GOLang distribution
2) In the "run_DHO_Tools.bat":
- set the GO installation directory path
- set the IpAddress variable (your scope's address is on the IO tab of the "Utility" window)
- change options list, if DHO900
- change scopeID, if DHO900
- if you don't want to create a backup file and pull it to the computer, delete line 35, or make it comment like this:
rem call "adb\05 make Backup And pull it - adb rm updateGEL, sh buildGEL, pull.bat"
3) Run the "run_DHO_Tools.bat"
4) Send the generated SCPI commands to the scope via the SCPI browser tab, opened by the script. Common command view:
:SYSTem:OPTion:INSTall DHOX00-<option>@XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Scope reboot is not needed.
5) Check BW limit on the "About" tab and the memory depth (for the DHO804) on the "Options" tab of the "Utility" window.
PS: To remove installed options use the "adb\03 adb remove ALL options.bat" file or the ":SYSTem:OPTion:UNINstall" command from p268 of the DHO800/DHO900 Programming Guide.
UPDATE REASON: extending the description text.
-
From here:
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5072767/#msg5072767 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5072767/#msg5072767)
Here is the DHO804 FW1.14 image (Thanks to @hubertyoung) with the DHO924 vendor file preloaded. Extract using 7zip then flash using HDD Raw Copy Tool (compressed image). If there is an vertical offset then use self cal or extended self cal.
https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8 (https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8)
and
Here is the DHO804 FW1.14 image (Thanks to @hubertyoung) with the DHO924 vendor file preloaded. Extract using 7zip then flash using HDD Raw Copy Tool (compressed image). If there is an vertical offset then use self cal or extended self cal.
https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8 (https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8)
Hi,
- This is what I've done:
1. Run the Win32 Disk Imager
2. Backup the SD
3. Flash the SD with the image from the link
4. Run the claibartation (offset gone) - device identifies as DHO804
5. Connect the scope to ethernet
6 Run adb:
6.1 adb devices
6.2 adb connect 192.xxx.x.xxx:55555
6.3 "adb pull /rigol/data/vendor.bin"
6.4 backup the generated vendor bin file from the adb folder to a new location
6.5 copy in the adb folder the DHO924 image
6.6 "adb push vendor.bin /rigol/data"
-
initial thoughts for hacking external awg support, link to a prior discussion. just to layout the main options:
well yes, there is the choice of hacking the firmware alone, to trigger some actions that then communicates over one of the general purpose digital interfaces on the scope (whether that is via the ethernet, or usb, or something else). the advantage of that is then should not require any hardware mods / hacking whatsoever. which gives itself a potential to keep a viable product warranty...
then there's the idea of minimally hacking the pcb awg section there, to install some low level mcu digital interface within the scope....
[more]...
this was after some people had been asking about the real internal awg module
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5045164/?topicseen#msg5045164 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5045164/?topicseen#msg5045164)
-
For use with the DHO900 (and hopefully the DHO800 after a few mods?) I've created a new v3.1 of the 16-channel LA clone board that is cheaper to make and easier to hand-solder:
https://climbers.net/sbc/clone-pla2216-logic-probe-analyzer/ (https://climbers.net/sbc/clone-pla2216-logic-probe-analyzer/)
The PCB has dual footprints for the quad-channel SN65LVDS391, so you can use SOIC or TSSOP packages depending on which is cheaper (or available in stock).
KiCad source files included, as are GERBERs and BOMs for LCSC & Mouser. Should be around US$15 incl components and PCB.
!! I haven't tested it !! Just waiting for the components to arrive...
The DHO800 at a minimum will need a hole cut into the front panel for the 50-way IDC connector, and a socket soldered onto the motherboard. Some people have said the 2 missing memory chips are required to use the logic analyser functionality, but I don't think that has been confirmed yet? The missing chips are GigaDevice GDP2BFLM-CA, 96-ball FBGA:
https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230704/DS-00823-GDP2BFLM-Rev1.1.pdf (https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230704/DS-00823-GDP2BFLM-Rev1.1.pdf)
-
I've started an attempt to clone the plugin AFG module from a DHO900.
In theory this could be used to add the same AFG functionality to a hacked DHO800. At a minimum 2x5-pin and 2x20-pin 1.27mm SMD headers would need to be soldered to the motherboard, and possibly other missing components.
I've gone as far as I can just working from photos: the attached DHO900 AFG.zip contains KiCad schematic & PCB layout, hi-res photos and spreadsheet of the major components. Hopefully other people with the actual AFG hardware will be mad enough to continue the effort, tracing the tracks and measuring the capacitors & inductors.
It is a busy board with a lot of passives, but I haven't seen any expensive/custom components yet.
-
This vendor.bin thing was shown a year ago in the DHO1000 thread (HDO1000 at the time).
The vendor_dho924.zip that is being shared contains the following info:
00000000 File CRC32: A2A69654 [00000008-000000D3] CRC OK
00000004 File Length: 204 Size OK
-----------------------------------------------------------
00000008 NameSize: 4
0000000C Name: E_CFG_MODEL_RAW
00000010 FieldSize: 56
00000014 CRC32: 0ADE0274 [0000001C-0000004B] CRC OK
00000018 DataSize: 44 Size OK
0000001C Data: DHO924
-----------------------------------------------------------
0000004C NameSize: 4
00000050 Name: E_CFG_SN_RAW
00000054 FieldSize: 56
00000058 CRC32: 6184E52C [00000060-0000008F] CRC OK
0000005C DataSize: 44 Size OK
00000060 Data: DHO9A252500008
-----------------------------------------------------------
00000090 NameSize: 4
00000094 Name: E_CFG_MAC
00000098 FieldSize: 56
0000009C CRC32: 8292C492 [000000A4-000000D3] CRC OK
000000A0 DataSize: 44 Size OK
000000A4 Data: 0019AFA00004
File processed OK
I've been away from DHO investigations as, I think, all is done since DHO1000 came out.
With that in mind, I ask if people have tried to just change the model in their vendor.bin to DHO924 and see if that is enough for a model conversion? Given previous Rigol cases I think it should not be necessary to flash whole new CF 924 images.
But I might be wrong...
As in the past, there should be a SCPI command to change params in vendor.bin:
:VENDor:CONFigure
If anyone with a DHO8xx wants to try this SCPI method, I can try to revive my dusty tool and create the command file.
-
With that in mind, I ask if people have tried to just change the model in their vendor.bin to DHO924 and see if that is enough for a model conversion? Given previous Rigol cases I think it should not be necessary to flash whole new CF 924 images.
For the first batch of DHO804/814s with firmware version 01.14: yes, replacing only the vendor.bin will be enough.
The issue here is that newer DHO804/814s ship with firmware version 01.00, simply replacing the vendor.bin will cause a 5mV-10mV offset to appear, and it can't be eliminated by self-cal.
Thanks to @hubertyoung, we now have access to SD card images with firmware version 01.14, we can basically "downgrade" the newer scopes back to the state it was in during the first batch, which is easily hackable.
Sidenote: Someone has claimed that he managed to perform the hack on firmware version 01.00, but he refuses to provide the method, so I don't know if there's any credibility to his claims.
I am curious about how the vendor.bin is decrypted, and it seems that you mentioned a method for changing the content of it with the SCPI command? It is certainly interesting.
-
But isn't v01.14 a newer version than v01.00? :-// :o
What about just replacing the cal files and let the FW do the self cal? Maybe the "newer" cal files are so off that the self cal can't correct them...
I just think that it has to be an easier way.
-
Some people have said the 2 missing memory chips are required to use the logic analyser functionality, but I don't think that has been confirmed yet?
I think what has been confirmed is that (a) the DHO900 models have these chips populated, and (b) the DHO800 models can be upgraded to 50 Mpts memory via just a software hack, i.e. the extra memory chips are not required for sample storage. That's what led to the assumption that the extra memory supports the logic analyser functionality.
-
I think what has been confirmed is that (a) the DHO900 models have these chips populated, and (b) the DHO800 models can be upgraded to 50 Mpts memory via just a software hack, i.e. the extra memory chips are not required for sample storage. That's what led to the assumption that the extra memory supports the logic analyser functionality.
True, but there's something that doesn't make much sense: Why does Rigol add two 256MBits * 16 RAM chips to sample 16 digital channels while one of these chips would have been more than sufficient for this job. Considering the ADC delivers a 12bit datastream at 1.25GSa/s and a single such RAM chip, interfaced via the Zync FPGA/SoC is well fast enough to cope with this data rate, we may in future DHO900 units only see one of the additional footprints populated with a RAM or .... there may be hacking possibilities that as yet nobody has on their list. At least, all the front end hardware including ADC and ADC sampling clock PLL are capable of 2GSa/s. And two such RAM chips, if you swap the ADC / MSO data streams, and the FPGA section of the Zync has enough I/O connectivity ... well I guess you know what I mean ;D
Of course that's something that isn't done at home easily, but maybe even Rigol has plans for a further uprated model based on this hardware. Pure speculation... ;)
-
Considering the ADC delivers a 12bit datastream at 1.25GSa/s and a single such RAM chip, interfaced via the Zync FPGA/SoC is well fast enough to cope with this data rate, we may in future DHO900 units only see one of the additional footprints populated with a RAM or .... there may be hacking possibilities that as yet nobody has on their list. At least, all the front end hardware including ADC and ADC sampling clock PLL are capable of 2GSa/s. And two such RAM chips, if you swap the ADC / MSO data streams, and the FPGA section of the Zync has enough I/O connectivity ... well I guess you know what I mean ;D
Well, there is that strange mismatch in the DHO924 specs, with four channels at 250 MHz bandwidth and still only 1.25 GSamples/s. They even ship four fast probes with it, which one can't fully use.
Maybe the DHO800/900 was indeed designed with a higher sample rate in mind. Then either some technical challenge got in the way late during development, or product management intervened and wanted to protect the more expensive product lines for the time being. The latter is a more likely explanation in my opinion, and might mean that we will see faster sampling a year from now, maybe even software-upgradable in the current scopes... ::)
-
The maximum you can get out of one ADC for all channels can be seen with the DHO1000.
This model is really "reduced by half" compared to the DHO4000 with its 2 ADCs.
It is interesting to see why the bandwidth of the DHO900 is 250Mhz and not 200Mhz like the DHO1000, which seems more "natural".
-
Maybe the DHO800/900 was indeed designed with a higher sample rate in mind. Then either some technical challenge got in the way late during development, or product management intervened and wanted to protect the more expensive product lines for the time being. The latter is a more likely explanation in my opinion, and might mean that we will see faster sampling a year from now, maybe even software-upgradable in the current scopes... ::)
The latter is indeed the most likely explaination. But it does also have a different FPGA which could potentially impact that.
-
But isn't v01.14 a newer version than v01.00? :-// :o
I don't get that either. Mine is 1.00
-
For use with the DHO900 (and hopefully the DHO800 after a few mods?) I've created a new v3.1 of the 16-channel LA clone board that is cheaper to make and easier to hand-solder:
https://climbers.net/sbc/clone-pla2216-logic-probe-analyzer/ (https://climbers.net/sbc/clone-pla2216-logic-probe-analyzer/)
The PCB has dual footprints for the quad-channel SN65LVDS391, so you can use SOIC or TSSOP packages depending on which is cheaper (or available in stock).
KiCad source files included, as are GERBERs and BOMs for LCSC & Mouser. Should be around US$15 incl components and PCB.
!! I haven't tested it !! Just waiting for the components to arrive...
The DHO800 at a minimum will need a hole cut into the front panel for the 50-way IDC connector, and a socket soldered onto the motherboard. Some people have said the 2 missing memory chips are required to use the logic analyser functionality, but I don't think that has been confirmed yet? The missing chips are GigaDevice GDP2BFLM-CA, 96-ball FBGA:
https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230704/DS-00823-GDP2BFLM-Rev1.1.pdf (https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230704/DS-00823-GDP2BFLM-Rev1.1.pdf)
I suspect that few will go to the effort to hack their DHO800 to this extent, but the probe should be popular with DHO900 owners given the Rigol probe costs a crazy $400.
-
Maybe the DHO800/900 was indeed designed with a higher sample rate in mind. Then either some technical challenge got in the way late during development, or product management intervened and wanted to protect the more expensive product lines for the time being. The latter is a more likely explanation in my opinion
I think it's more likely it was the FPGA that decided it.
The cheaper FPGA in these probably can't keep with the 2GHz sample rate.
It is interesting to see why the bandwidth of the DHO900 is 250Mhz and not 200Mhz like the DHO1000, which seems more "natural".
This is definitely strange. I'm hoping my DHO800 can be set to 125Mhz, it seems like the sweet spot for this ADC on a 4-channel 'scope.
-
Considering the ADC delivers a 12bit datastream at 1.25GSa/s and a single such RAM chip, interfaced via the Zync FPGA/SoC is well fast enough to cope with this data rate, we may in future DHO900 units only see one of the additional footprints populated with a RAM or .... there may be hacking possibilities that as yet nobody has on their list. At least, all the front end hardware including ADC and ADC sampling clock PLL are capable of 2GSa/s. And two such RAM chips, if you swap the ADC / MSO data streams, and the FPGA section of the Zync has enough I/O connectivity ... well I guess you know what I mean ;D
Well, there is that strange mismatch in the DHO924 specs, with four channels at 250 MHz bandwidth and still only 1.25 GSamples/s. They even ship four fast probes with it, which one can't fully use.
Maybe the DHO800/900 was indeed designed with a higher sample rate in mind. Then either some technical challenge got in the way late during development, or product management intervened and wanted to protect the more expensive product lines for the time being. The latter is a more likely explanation in my opinion, and might mean that we will see faster sampling a year from now, maybe even software-upgradable in the current scopes... ::)
Honestly probably more of a development / cost thing. Probably cheaper to throw in a slightly overkill probe on the top DHO900 scope if someone is willing to pay for all the features than commission a probe new to spec for only one line. The PVP2350 (the 350MHz probes included with the DHO924) is the standard probe for the MSO5000.
-
Well, there is that strange mismatch in the DHO924 specs, with four channels at 250 MHz bandwidth and still only 1.25 GSamples/s. They even ship four fast probes with it, which one can't fully use. [...]
Honestly probably more of a development / cost thing. Probably cheaper to throw in a slightly overkill probe on the top DHO900 scope if someone is willing to pay for all the features than commission a probe new to spec for only one line. The PVP2350 (the 350MHz probes included with the DHO924) is the standard probe for the MSO5000.
Oh, I was not referring to the 350 MHz spec on the probes, but to the fact that Rigol gives you four of them. The sampling rate drops to ~300 MHz when using more than two channels, so two fast probes and two of the cheaper 150 MHz type would have been enough. ;)
Yes, I realize that having two different pairs of probes would be a hassle, so I appreciate that Rigol provides four PVP2350s. Decent value for money for the $100 surcharge they ask for the 924 model -- if only the scope could fully use the probes...
-
I was sniffing Dave's DHO800 dump file and found references to 2 other models whose initial letters were swapped. Should they be the same models but launched in another country? maybe yes maybe no.
They are HDO800 and HDO900, included are also DHO800 and DHO900
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
01D6DB8D0 48 44 4F 38 30 30 00 48 44 HDO800 HD
01D6DB8E0 4F 39 30 30 00 44 48 4F 38 30 30 00 44 48 4F 39 O900 DHO800 DHO9
01D6DB8F0 30 30 00
I also found references to codes assigned to options available or not on the oscilloscope and a type of .lic file
Maybe it will be possible to activate the options through these codes and generate such licenses the same way we did on the DS1054Z model
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
01D6DB7F0 42 4E 44 00 42 57 37 54 BND BW7T
01D6DB800 31 30 00 45 4D 42 44 00 43 4F 4D 50 00 42 57 31 10 EMBD COMP BW1
01D6DB810 35 54 32 35 00 41 55 54 4F 00 42 4F 44 45 00 42 5T25 AUTO BODE B
01D6DB820 57 37 54 32 30 00 42 57 31 30 54 32 30 00 52 4C W7T20 BW10T20 RL
01D6DB830 55 00 42 57 32 54 34 00 42 57 32 54 38 00 42 57 U BW2T4 BW2T8 BW
01D6DB840 34 54 38 00 41 45 52 4F 00 46 4C 45 58 00 41 55 4T8 AERO FLEX AU
01D6DB850 44 49 4F 00 2E 6C 69 63 00 40 00 55 6E 6B 6E 6F DIO .lic @ Unkno
01D6DB860 77 6E 00 46 6F 72 65 76 65 72 00 64 61 79 73 00 wn Forever days
-
The HDO was Rigol's initial designation before having to change to DHO.
Regarding the lics generation, look into the HDO/DHO1000/4000 thread. It's all there so there is no need to reinvent the wheel.
-
I was sniffing Dave's DHO800 dump file and found references to 2 other models whose initial letters were swapped. Should they be the same models but launched in another country? maybe yes maybe no.
They were called "HDO" when they were announced but that turned out to be a trademark (of Lecroy?) or something so they changed it to "DHO".
The firmware probably works both ways.
-
The HDO was Rigol's initial designation before having to change to DHO.
Regarding the lics generation, look into the HDO/DHO1000/4000 thread. It's all there so there is no need to reinvent the wheel.
Nice! :-+
-
I also found references to codes assigned to options available or not on the oscilloscope and a type of .lic file
Does it have power analysis?
Maybe it will be possible to activate the options through these codes and generate such licenses the same way we did on the DS1054Z model
Let's hope so. Ideally I want my DHO800 to be 125Mhz bandwidth and 50Mpts of memory but without the extra AWG/LA menus of the DHO900.
-
I was sniffing Dave's DHO800 dump file and found references to 2 other models whose initial letters were swapped. Should they be the same models but launched in another country? maybe yes maybe no.
They were called "HDO" when they were announced but that turned out to be a trademark (of Lecroy?) or something so they changed it to "DHO".
The firmware probably works both ways.
So, probably some code leftovers.
-
I also found references to codes assigned to options available or not on the oscilloscope and a type of .lic file
Does it have power analysis?
Maybe it will be possible to activate the options through these codes and generate such licenses the same way we did on the DS1054Z model
Let's hope so. Ideally I want my DHO800 to be 125Mhz bandwidth and 50Mpts of memory but without the extra AWG/LA menus of the DHO900.
I don't have the scope (yet) so I can't tell you what each code means. Sorry
-
So, probably some code leftovers.
So that firmware updates will be compatible with pre-release 'scopes.
-
I don't have the scope (yet) so I can't tell you what each code means. Sorry
Me either. :D
I'm 100% sure it'll be possible, it's just a question of how many hoops need to be jumped through.
-
The HDO was Rigol's initial designation before having to change to DHO.
Regarding the lics generation, look into the HDO/DHO1000/4000 thread. It's all there so there is no need to reinvent the wheel.
Fungus see what tv84 wrote :-+ If the same process works on DHO800/900 it would be easy to activate just what we need.
-
The HDO was Rigol's initial designation before having to change to DHO.
Regarding the lics generation, look into the HDO/DHO1000/4000 thread. It's all there so there is no need to reinvent the wheel.
Fungus see what tv84 wrote :-+ If the same process works on DHO800/900 it would be easy to activate just what we need.
I had tried the method for HDO1000/4000 scope and managed to unlock the 70MHz to 100MHz upgrade on my DHO804, and @hubertyoung managed to add the BODE option with the every same methpod. Therefore, I can confirmed that the existing method still works perfectly fine.
-
I was sniffing Dave's DHO800 dump file and found references to 2 other models whose initial letters were swapped. Should they be the same models but launched in another country? maybe yes maybe no.
They were called "HDO" when they were announced but that turned out to be a trademark (of Lecroy?) or something so they changed it to "DHO".
The firmware probably works both ways.
While messing around with my DHO804, I happened to somehow made it identify it self as HDO1074, which is interesting.
https://lh3.google.com/u/0/d/1xLgXzNZY_h51uqBLpfh9jRs5dM9yPVog=w3840-h1984-iv1 (https://lh3.google.com/u/0/d/1xLgXzNZY_h51uqBLpfh9jRs5dM9yPVog=w3840-h1984-iv1)
-
I had tried the method for HDO1000/4000 scope and managed to unlock the 70MHz to 100MHz upgrade on my DHO804, and @hubertyoung managed to add the BODE option with the every same methpod. Therefore, I can confirmed that the existing method still works perfectly fine.
What about 50mpts memory? That's not an official option so it might need a different method.
(same with 125MHz bandwidth...)
-
Hi all, attached is the DHO tool I created, I hope it will be more helpful to you guys.
You can now use the latest firmware version and upgrade with it, which will no longer have the problem of zero potential offset. Its only drawback is that upgrading from the 800 series to the 900 series may not be correct across series.
-
The forum setting cannot exceed 5Mb, which is embarrassing.
This Pack A
The version has been updated
v1.0.2
-
This is Pack B
-
Theoretically, DHO800 series upgrade to DHO900 or DHO1000, the system in addition to checking the device model recorded in the Vendor .bin, RigolAPP also detects some bit bits on the hardware motherboard, so to perfectly skip this detection must build a driver to hook out the bit information read from the hardware. I firmly believe that the whole detection is no more.
-
Theoretically, DHO800 series upgrade to DHO900 or DHO1000, the system in addition to checking the device model recorded in the Vendor .bin, RigolAPP also detects some bit bits on the hardware motherboard, so to perfectly skip this detection must build a driver to hook out the bit information read from the hardware. I firmly believe that the whole detection is no more.
Thanks a lot for your hard work!
I tried writing the idendity to 924 on my 804. However, the drift still presents and can not be eliminated by self-cal. Did I missed something? Many thanks.
-
Theoretically, DHO800 series upgrade to DHO900 or DHO1000, the system in addition to checking the device model recorded in the Vendor .bin, RigolAPP also detects some bit bits on the hardware motherboard, so to perfectly skip this detection must build a driver to hook out the bit information read from the hardware. I firmly believe that the whole detection is no more.
Thanks a lot for your hard work!
I tried writing the idendity to 924 on my 804. However, the drift still presents and can not be eliminated by self-cal. Did I missed something? Many thanks.
I emphasized, there is still one step left to do, different series of upgrades 800\900\1000 we need to develop a hook driver to mount to the device to let the system detect that hardware you specified to complete this step will end all hacks, but this work takes time, please wait....
-
Hero arrived!
-
RigolAPP also detects some bit bits on the hardware motherboard, so to perfectly skip this detection must build a driver to hook out the bit information read from the hardware. I firmly believe that the whole detection is no more.
What does the app do with those bits? In what form are they related to model and/or options?
-
RigolAPP also detects some bit bits on the hardware motherboard, so to perfectly skip this detection must build a driver to hook out the bit information read from the hardware. I firmly believe that the whole detection is no more.
What does the app do with those bits? In what form are they related to model and/or options?
so easy, it is the hardware version:
model hardware version
DHO804 and DHO814 12
DHO802 DHO812 4
DHO914S DHO924S DHO914 DHO924 8
DHO1072 9
DHO4000 0
RIGOL manages the driver location for the hardware version : /rigol/driver/hdcode_gpio.ko
root@rigol:~/rigol/driver# modinfo hdcode_gpio.ko
filename: /rigol/driver/hdcode_gpio.ko
license: GPL
description: gpio-hdcode devices driver
author: rigol sn03950
depends:
intree: Y
vermagic: 4.4.126 SMP preempt mod_unload modversions aarch64
All secrets have been revealed, I wish you guys fun.
:-DD
-
What does the app do with those bits? In what form are they related to model and/or options?
so easy, it is the hardware version:
model hardware version
DHO804 and DHO814 12
DHO802 DHO812 4
DHO914S DHO924S DHO914 DHO924 8
DHO1072 9
DHO4000 0
Can't you change the table in software? Is the version configured in the OTP SOC area or in a Rigol ASIC?
-
What does the app do with those bits? In what form are they related to model and/or options?
so easy, it is the hardware version:
model hardware version
DHO804 and DHO814 12
DHO802 DHO812 4
DHO914S DHO924S DHO914 DHO924 8
DHO1072 9
DHO4000 0
Can't you change the table in software? Is the version configured in the OTP SOC area or in a Rigol ASIC?
The RK3399 chip corresponds to the GPIO in the hardware version number:
bit0= GPIO0_A4 PIN 4
bit1= GPIO0_B0 PIN 8
bit2= GPIO0_B3 PIN 11
bit3= GPIO0_B4 PIN 12
I don't have a cross-compilation environment for RK3399 here, if anyone can compile a hdcode_gpio.ko by themselves to replace the original factory, you can achieve hardware version number customization.
-
The version number could be in a form of solder bridges on the pcb somewhere as well..
The RK3399 just reads its inputs pins and gets the version number from "somewhere".
-
The RK3399 chip corresponds to the GPIO in the hardware version number:
bit0= GPIO0_A4 PIN 4
bit1= GPIO0_B0 PIN 8
bit2= GPIO0_B3 PIN 11
bit3= GPIO0_B4 PIN 12
I don't have a cross-compilation environment for RK3399 here, if anyone can compile a hdcode_gpio.ko by themselves to replace the original factory, you can achieve hardware version number customization.
If you lift the PIN 11, all is good, right? :)
Please share the original file here.
-
The RK3399 chip corresponds to the GPIO in the hardware version number:
bit0= GPIO0_A4 PIN 4
bit1= GPIO0_B0 PIN 8
bit2= GPIO0_B3 PIN 11
bit3= GPIO0_B4 PIN 12
I don't have a cross-compilation environment for RK3399 here, if anyone can compile a hdcode_gpio.ko by themselves to replace the original factory, you can achieve hardware version number customization.
If you lift the PIN 11, all is good, right? :)
Please share the original file here.
If the GPIO is dangling instead of grounded, or if there is an internal pulldown, there may be a problem.
The only thing I'm not sure about now is whether the GPIO input is fixed resistors or wires or connected to the internal logic circuitry of the FPGA? Capable friends can track RK3399 chip pins by themselves:
GPIO0_A4 4PIN
GPIO0_B0 8PIN
GPIO0_B3 11PIN
GPIO0_B4 12PIN
-
driver location for the hardware version : /rigol/driver/hdcode_gpio.ko
root@rigol:~/rigol/driver# modinfo hdcode_gpio.ko
filename: /rigol/driver/hdcode_gpio.ko
license: GPL
description: gpio-hdcode devices driver
author: rigol sn03950
depends:
intree: Y
vermagic: 4.4.126 SMP preempt mod_unload modversions aarch64
All secrets have been revealed,
hang on... does not this indicate that rigol has this kernel module under gpl license? and also 'intree' to mean it is indeed kernel tree?
because under gpl terms it's necessary to provide the full source code (for this kernel module), at least by writing when requested. or by some other mechanism(s).
so to obtain this kmod code, it remains still. but rigol should be legally obliged to provide it to any customers (at least those who purchased the oscilloscope in 1st instance, and then those customers are subsequently not obliged to sign nda, they are in turn themselves free to openly redistribute it).
this is assuming it is correct infos there (about the gpl license, and it being intree). that this is not been honestly mistaken. and it assumes rigol respects the terms of the linux kernel, and the terms of the gpl license?
:-//
-
The version number could be in a form of solder bridges on the pcb somewhere as well..
The RK3399 just reads its inputs pins and gets the version number from "somewhere".
Maybe.you are right.. 8)
-
this is assuming it is correct infos there (about the gpl license, and it being intree). that this is not been honestly mistaken. and it assumes rigol respects the terms of the linux kernel, and the terms of the gpl license?
Correct. And I would say they will send you the code.
They sent all the GPL code for the MSO5000 to @Olliver. And he has it on his Github page...
-
ah right... so this is just to identify the hardware alone. it's not general device drivers. sorry my mistake. however at least that can be done easily (with the source code, tweak and rebuild new kmod).
-
Can anyone give an overview over the H/W variants of the 800/900 series scopes? E.g. which ones do have hardware capabilites preinstalled for the AWG and stuff like that.
Are all DHO900 series scopes identical hardware-wise, since all of them have the LA connector preinstalled as well as the AWG output at the back? I'd like to avoid having to cut into the case, so I'd go for the DHO914 in that case, as long as all the DHO924S features can be hacked software-wise.
-
this is assuming it is correct infos there (about the gpl license, and it being intree). that this is not been honestly mistaken. and it assumes rigol respects the terms of the linux kernel, and the terms of the gpl license?
Correct. And I would say they will send you the code.
They sent all the GPL code for the MSO5000 to @Olliver. And he has it on his Github page...
As long as you have experience in Linux driver development, find a .ko driver template and implement the following functions:
gpio_hdcode_drv_open
gpio_hdcode_drv_ioctl
gpio_hdcode_drv_read
gpio_hdcode_init
gpio_hdcode_exit
And refactor and modify the gpio_hdcode_drv_read function, the following is the important location source code of hdcode_gpio.ko:
ssize_t __fastcall gpio_hdcode_drv_read(file *file, unsigned __int8 *buf, size_t len, loff_t *f_pos)
{
size_t v5; // x19
__int64 v6; // x0
int v7; // w20
__int64 v8; // x0
int v9; // w20
__int64 v10; // x0
__int64 v11; // x0
unsigned __int64 v12; // x1
bool v13; // cc
__int64 v15; // x0
_BYTE v17[4]; // [xsp+33h] [xbp+33h] BYREF
v5 = len;
v6 = ((__int64 (__fastcall *)(__int64, unsigned __int8 *, size_t, loff_t *))gpio_to_desc)(4LL, buf, len, f_pos);
v7 = ((__int64 (__fastcall *)(__int64))gpiod_get_raw_value)(v6) & 1;
v8 = ((__int64 (__fastcall *)(__int64))gpio_to_desc)(8LL);
v9 = v7 & 0xFFFFFFFD | (2 * (((__int64 (__fastcall *)(__int64))gpiod_get_raw_value)(v8) & 1));
v10 = ((__int64 (__fastcall *)(__int64))gpio_to_desc)(11LL);
LOBYTE(v9) = v9 & 0xFB | (4 * (((__int64 (__fastcall *)(__int64))gpiod_get_raw_value)(v10) & 1));
v11 = ((__int64 (__fastcall *)(__int64))gpio_to_desc)(12LL);
v17[0] = v9 & 0xF7 | (8 * (((__int64 (__fastcall *)(__int64))gpiod_get_raw_value)(v11) & 1));
v12 = *(_QWORD *)(_ReadStatusReg(ARM64_SYSREG(3, 0, 4, 1, 0)) + 8);
if ( __CFADD__(buf, v5) )
v13 = 1;
else
v13 = (unsigned __int64)&buf[v5] > v12;
if ( !v13 )
{
((void (__fastcall *)(_BYTE *, size_t, __int64))_check_object_size)(v17, v5, 1LL);
v15 = ((__int64 (__fastcall *)(unsigned __int8 *, _BYTE *, size_t))_arch_copy_to_user)(buf, v17, v5);
}
else
{
v15 = v5;
}
if ( v15 )
{
v5 = -14LL;
((void (__fastcall *)(const char *))printk)("copy failed\n");
}
return v5;
}
-
This might be the config resistors for the 924..
Let us compare it with Dave's 814 teardown shots..
Looks the same..
-
This might be the config resistors for the 924..
Let us compare it with Dave's 814 teardown shots..
I've carefully compared the 800 and 900 series teardown HD pictures before, and I didn't find the HDCode setting bits. :(
According to the previous analysis results, PIN4~PIN12 should be near the mark point of the first pin of the chip.
-
..Hmm, then you have to fake the source there in the above snippet..
Where would you put the bits then? When not on pcb, I would put it into the fpga..
FPGA reads the bitstream and the bits are there. And I can reuse those 4 signals for something else as well..
-
..Hmm, then you have to fake the source there in the above snippet..
Maybe,set the resistor in the RK3399 PCB buttom layer, but this is just guessing. it is better to directly construct a driver module to fake it.
-
..Hmm, then you have to fake the source there in the above snippet..
Where would you put the bits then? When not on pcb, I would put it into the fpga..
FPGA reads the bitstream and the bits are there. And I can reuse those 4 signals for something else as well..
This is quite possible because I've looked at the files under \rigol\FPGA\ .bit .bin and they do have differences. for this case, the FPGA bitstream files of the DHO914 and DHO804 can be compared.
-
Yea, but messing with the fpga's bitstream is quite difficult. Nobody will ever touch it, I would guess..
-
Yea, but messing with the fpga's bitstream is quite difficult. Nobody will ever touch it, I would guess..
It's a nightmare!! |O |O
I'd rather download the huge and complex RK3399 cross-compilation environment.
-
Perhaps you could HEX Edit the entire sequence above (NOPing the reading of the 4 bits) with a simple MOV of the number I want into the W20 at the end.. (sorry for my rather naive approach I was using many many decades back, but I could not resist the temptation..) ;D :palm:
-
This is quite possible because I've looked at the files under \rigol\FPGA\ .bit .bin and they do have differences. for this case, the FPGA bitstream files of the DHO914 and DHO804 can be compared.
It's perfectly understandable that they are different BUT, if the bits were in the FPGA, I guess we just would have to insert the 900 .bit in the 800 package and flash it once. Once you do that, the device thinks it's a 9xx. ;) The only thing possibly missing would be the vendor.bin change.
-
It's perfectly understandable that they are different BUT, if the bits were in the FPGA, I guess we just would have to insert the 900 .bit in the 800 package and flash it once. Once you do that, the device thinks it's a 9xx. ;) The only thing possibly missing would be the vendor.bin change.
Yes, those hacks are easy but I don't want my 800 to think it's a 900. I want it to think it's an 800 with 125Mhz and 50MPts. :)
The 900 puts a lot of useless extra menus on screen that I can't ever use. I'd prefer it not to.
(Still waiting for mine so I can play around with it...)
-
This is quite possible because I've looked at the files under \rigol\FPGA\ .bit .bin and they do have differences. for this case, the FPGA bitstream files of the DHO914 and DHO804 can be compared.
It's perfectly understandable that they are different BUT, if the bits were in the FPGA, I guess we just would have to insert the 900 .bit in the 800 package and flash it once. Once you do that, the device thinks it's a 9xx. ;) The only thing possibly missing would be the vendor.bin change.
Use the DHO Tool I published to modify the hardware identity ID inside the vendor.bin.
-
Can anyone give an overview over the H/W variants of the 800/900 series scopes? E.g. which ones do have hardware capabilites preinstalled for the AWG and stuff like that.
Are all DHO900 series scopes identical hardware-wise, since all of them have the LA connector preinstalled as well as the AWG output at the back? I'd like to avoid having to cut into the case, so I'd go for the DHO914 in that case, as long as all the DHO924S features can be hacked software-wise.
In brief, the motherboard of all the 800/900 series are the same, just the 800 series is missing a few components.
All the 900 series have the LA connector on the front, while the 800 series don't have that connector soldered on the motherboard.
Only the 914S/924S models have the AFG module hardware inside, the 914/924 don't (at least that is my assumption).
The DHO924/DHO924S come with 350MHz probe, but the 914 and 800 series come with 150MHz probes.
-
Are all DHO900 series scopes identical hardware-wise, since all of them have the LA connector preinstalled as well as the AWG output at the back?
No, the AWG is a daughterboard which is only installed on the S models.
-
Thanks for all the good work in this thread.
As I opted for the DHO942S (not yet arrived), I'm not that interested in adding additional options to hack a DHO800 upwards.
However, I'm curious to know if there are glimpses of functionalities not advertised i.e. extra decoding options above the advertised set.
Any info on that?
-
I'm curious to know if there are glimpses of functionalities not advertised i.e. extra decoding options above the advertised set.
They might have power analysis functions like the 4000 series does.
-
..In brief, the motherboard of all the 800/900 series are the same, just the 800 series is missing a few components. ..
Have you check it on the level of resistors/jumpers/bridges/capacitors/inductors etc?
That is what this thread is about..
-
..In brief, the motherboard of all the 800/900 series are the same, just the 800 series is missing a few components. ..
Have you check it on the level of resistors/jumpers/bridges/capacitors/inductors etc?
That is what this thread is about..
I'm not sure the PCB is different. If the device selection was by hardware jumpers then why does vendor.bin override it?
This code might be unused:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1883821;image)
-
..In brief, the motherboard of all the 800/900 series are the same, just the 800 series is missing a few components. ..
Have you check it on the level of resistors/jumpers/bridges/capacitors/inductors etc?
That is what this thread is about..
I'm not sure the PCB is different..
Again, the question is whether all the 800/900 boards are the same (except the AWG, LA, probes type). If one claimed "the all 800/900 series boards are the same", I would certainly ask him whether he doublechecked that at the level of _each_ component on the board, including pcb traces etc. This thread is about hacking a complex device, not about general chat about this scope (there are another 2 threads on that general chat).
-
I'm not sure the PCB is different..
Again, the question is whether all the 800/900 boards are the same (except the AWG, LA, probes type)
I think they'll be the same.
The massive clue that they're the exact same PCB is that the HDO800 has all the components for the logic analyzer installed except for the external connector. If they were going to run a separate production line for each model they'd have left those components off the DHO800 boards to save money.
I've carefully compared the 800 and 900 series teardown HD pictures before, and I didn't find the HDCode setting bits. :(
I don't think they're there. I think it's all configured in vendor.bin
-
The 900 series come with 350MHz probes (or just the 924/924S ?), but the 800 series come with 150MHz probes.
Datasheets say:
- DHO814/DHO804: Passive Probe x4 (150 MHz) PVP3150
- DHO812/DHO802: Passive Probe x2 (150 MHz) PVP3150
- DHO924/DHO924S: Passive Probe x4 (350 MHz) PVP2350
- DHO914/DHO914S: Passive Probe x4 (150 MHz) PVP3150
-
I don't think they're there. I think it's all configured in vendor.bin
your conclusion is not correct, HDCode's reading is not in the vendor.bin, I have tracked the entire process of reading HDCODE, and have confirmed that it reads information from the GPIO port.
-
I have tracked the entire process of reading HDCODE, and have confirmed that it reads information from the GPIO port.
OK, but what does it do with that number?
-
I have tracked the entire process of reading HDCODE, and have confirmed that it reads information from the GPIO port.
OK, but what does it do with that number?
Have you carefully read the analysis content in front of this thread, HDCODE is a 4-bit binary code,
HDCODE 1000 = Hardware version is 8
HDCODE 1100 = Hardware version is 12.
You should be familiar with similar computer coding.
-
I have tracked the entire process of reading HDCODE, and have confirmed that it reads information from the GPIO port.
OK, but what does it do with that number?
Have you carefully read the analysis content in front of this thread, HDCODE is a 4-bit binary code,
HDCODE 1000 = Hardware version is 8
HDCODE 1100 = Hardware version is 12.
You should be familiar with similar computer coding.
Yes, I know all that...
The question is what does it do with that number? People have turned their DHO800s into DHO900s with vendor.bin so the firmware doesn't appear to do much with HDCODE.
-
Here are links from the 800 thread, some comments about config, software, app, android stuff:
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046544/#msg5046544 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046544/#msg5046544)
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008)
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5049184/#msg5049184 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5049184/#msg5049184)
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5058679/#msg5058679 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5058679/#msg5058679)
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5058826/#msg5058826 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5058826/#msg5058826)
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5059366/#msg5059366 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5059366/#msg5059366)
However did not trawl through the 1000 / 4000 thread. So that remains missing here, from these quotes.
-
Oh, looks like the serial console is just left enabled?!
Could you please run this and share the output?
getprop
Here you go!
rk3399_rigol:/ $ getprop
getprop
[UserVolumeLabel]: [RockChips]
[camera2.portability.force_api]: [1]
[crashlogd.processing.ongoing]: [0]
[crashlogd.token]: [1]
[dalvik.vm.appimageformat]: [lz4]
[dalvik.vm.boot-dex2oat-threads]: [2]
[dalvik.vm.dex2oat-Xms]: [64m]
[dalvik.vm.dex2oat-Xmx]: [512m]
[dalvik.vm.dex2oat-threads]: [2]
[dalvik.vm.heapgrowthlimit]: [192m]
[dalvik.vm.heapmaxfree]: [8m]
[dalvik.vm.heapminfree]: [512k]
[dalvik.vm.heapsize]: [512m]
[dalvik.vm.heapstartsize]: [16m]
[dalvik.vm.heaptargetutilization]: [0.75]
[dalvik.vm.image-dex2oat-Xms]: [64m]
[dalvik.vm.image-dex2oat-Xmx]: [64m]
[dalvik.vm.image-dex2oat-threads]: [2]
[dalvik.vm.isa.arm.features]: [default]
[dalvik.vm.isa.arm.variant]: [cortex-a53.a57]
[dalvik.vm.isa.arm64.features]: [default]
[dalvik.vm.isa.arm64.variant]: [cortex-a53]
[dalvik.vm.lockprof.threshold]: [500]
[dalvik.vm.stack-trace-file]: [/data/anr/traces.txt]
[dalvik.vm.usejit]: [true]
[dalvik.vm.usejitprofiles]: [true]
[debug.atrace.tags.enableflags]: [0]
[debug.force_rtl]: [0]
[debug.nfc.fw_download]: [false]
[debug.nfc.se]: [false]
[dev.bootcomplete]: [1]
[init.svc.adbd]: [running]
[init.svc.akmd]: [stopped]
[init.svc.ap_log_srv]: [stopped]
[init.svc.ap_logfs]: [stopped]
[init.svc.apk_logfs]: [running]
[init.svc.audioserver]: [running]
[init.svc.bootanim]: [stopped]
[init.svc.console]: [running]
[init.svc.crashlogd]: [running]
[init.svc.daemonssh]: [running]
[init.svc.debuggerd]: [running]
[init.svc.debuggerd64]: [running]
[init.svc.drm]: [running]
[init.svc.drmservice]: [stopped]
[init.svc.earlylogs]: [stopped]
[init.svc.gatekeeperd]: [running]
[init.svc.healthd]: [running]
[init.svc.installd]: [running]
[init.svc.keystore]: [running]
[init.svc.lmkd]: [running]
[init.svc.log-watch]: [running]
[init.svc.logd]: [running]
[init.svc.logd-reinit]: [stopped]
[init.svc.media]: [running]
[init.svc.mediacodec]: [running]
[init.svc.mediadrm]: [running]
[init.svc.mediaextractor]: [running]
[init.svc.netd]: [running]
[init.svc.perfprofd]: [running]
[init.svc.ril-daemon]: [stopped]
[init.svc.servicemanager]: [running]
[init.svc.startApp]: [stopped]
[init.svc.su_daemon]: [running]
[init.svc.surfaceflinger]: [running]
[init.svc.ueventd]: [running]
[init.svc.up_eth0]: [stopped]
[init.svc.vold]: [running]
[init.svc.zygote]: [running]
[init.svc.zygote_secondary]: [running]
[keyguard.no_require_sim]: [true]
[log.tag.WifiHAL]: [D]
[logd.logpersistd.enable]: [true]
[media.audio.slice]: [0]
[net.bt.name]: [Android]
[net.change]: [net.qtaguid_enabled]
[net.hostname]: [android-11e19a77c1de3ca5]
[net.qtaguid_enabled]: [1]
[net.tcp.default_init_rwnd]: [60]
[persist.core.enabled]: [0]
[persist.crashlogd.root]: [/data/logs]
[persist.demo.hdmirotates]: [true]
[persist.intel.logger.rot_cnt]: [20]
[persist.intel.logger.rot_size]: [5000]
[persist.internet.adb.enable]: [1]
[persist.net.ethernet.mode]: [normal]
[persist.rigol.boot.record]: [48]
[persist.rigol.fpga.boot.addr]: [0x400000]
[persist.service.apklogfs.enable]: [1]
[persist.service.aplogfs.enable]: [0]
[persist.sys.alarm.fixed]: [300000]
[persist.sys.alarm.strategy]: [fixed2]
[persist.sys.color.main]: [RGB-8bit]
[persist.sys.dalvik.vm.lib.2]: [libart.so]
[persist.sys.first_booting]: [false]
[persist.sys.framebuffer.main]: [1024x600@60]
[persist.sys.hid]: []
[persist.sys.profiler_ms]: [0]
[persist.sys.root_access]: [1]
[persist.sys.rotation.efull]: [true]
[persist.sys.strictmode.visual]: [false]
[persist.sys.timezone]: [Asia/Shanghai]
[persist.sys.ui.hw]: [true]
[persist.sys.usb.config]: [mtp,adb]
[persist.sys.webview.vmsize]: [118564800]
[persist.tegra.nvmmlite]: [1]
[pm.dexopt.ab-ota]: [speed-profile]
[pm.dexopt.bg-dexopt]: [speed-profile]
[pm.dexopt.boot]: [verify-profile]
[pm.dexopt.core-app]: [speed]
[pm.dexopt.first-boot]: [interpret-only]
[pm.dexopt.forced-dexopt]: [speed]
[pm.dexopt.install]: [interpret-only]
[pm.dexopt.nsys-library]: [speed]
[pm.dexopt.shared-apk]: [speed]
[ril.function.dataonly]: [1]
[rild.libargs]: [-d /dev/ttyACM0]
[rild.libpath]: [/system/lib/libril-rk29-dataonly.so]
[ro.adb.secure]: [0]
[ro.allow.mock.location]: [0]
[ro.audio.monitorOrientation]: [true]
[ro.baseband]: [N/A]
[ro.board.platform]: [rk3399]
[ro.boot.baseband]: [N/A]
[ro.boot.console]: [ttyFIQ0]
[ro.boot.hardware]: [rk30board]
[ro.boot.mode]: [emmc]
[ro.boot.noril]: [true]
[ro.boot.oem_unlocked]: [0]
[ro.boot.selinux]: [disabled]
[ro.bootimage.build.date]: [Wed Aug 23 11:39:22 CST 2023]
[ro.bootimage.build.date.utc]: [1692761962]
[ro.bootimage.build.fingerprint]: [Android/rk3399_rigol/rk3399_rigol:7.1.2/NHG47K/adil08231139:userdebug/dev-keys]
[ro.bootloader]: [unknown]
[ro.bootmode]: [emmc]
[ro.bt.bdaddr_path]: [/data/misc/bluetooth/bdaddr]
[ro.build.characteristics]: [tablet]
[ro.build.date]: [Wed Aug 23 11:39:22 CST 2023]
[ro.build.date.utc]: [1692761962]
[ro.build.description]: [rk3399_rigol-userdebug 7.1.2 NHG47K eng.adil.20230823.113922 dev-keys]
[ro.build.display.id]: [rk3399_rigol-userdebug 7.1.2 NHG47K eng.adil.20230823.113922 dev-keys]
[ro.build.fingerprint]: [Android/rk3399_rigol/rk3399_rigol:7.1.2/NHG47K/adil08231139:userdebug/dev-keys]
[ro.build.flavor]: [rk3399_rigol-userdebug]
[ro.build.host]: [ubuntu]
[ro.build.id]: [NHG47K]
[ro.build.product]: [rk3399_rigol]
[ro.build.tags]: [dev-keys]
[ro.build.type]: [userdebug]
[ro.build.user]: [adil]
[ro.build.version.all_codenames]: [REL]
[ro.build.version.base_os]: []
[ro.build.version.codename]: [REL]
[ro.build.version.incremental]: [eng.adil.20230823.113922]
[ro.build.version.preview_sdk]: [0]
[ro.build.version.release]: [7.1.2]
[ro.build.version.sdk]: [25]
[ro.build.version.security_patch]: [2019-10-05]
[ro.carrier]: [unknown]
[ro.com.android.dataroaming]: [true]
[ro.config.alarm_alert]: [Alarm_Classic.ogg]
[ro.config.enable.remotecontrol]: [false]
[ro.config.notification_sound]: [pixiedust.ogg]
[ro.config.ringtone]: [Ring_Synth_04.ogg]
[ro.crypto.state]: [unencrypted]
[ro.dalvik.vm.native.bridge]: [0]
[ro.debuggable]: [1]
[ro.default.size]: [100]
[ro.device_owner]: [false]
[ro.enable_boot_charger_mode]: [0]
[ro.expect.recovery_id]: [0xd433ae56b13e30da0aee31b12bb7a704e313580a000000000000000000000000]
[ro.factory.hasGPS]: [false]
[ro.factory.hasUMS]: [false]
[ro.factory.storage_suppntfs]: [true]
[ro.factory.tool]: [0]
[ro.factory.without_battery]: [false]
[ro.hardware]: [rk30board]
[ro.hwui.disable_scissor_opt]: [true]
[ro.hwui.drop_shadow_cache_size]: [6]
[ro.hwui.gradient_cache_size]: [1]
[ro.hwui.layer_cache_size]: [48]
[ro.hwui.path_cache_size]: [32]
[ro.hwui.r_buffer_cache_size]: [8]
[ro.hwui.text_large_cache_height]: [1024]
[ro.hwui.text_large_cache_width]: [2048]
[ro.hwui.text_small_cache_height]: [1024]
[ro.hwui.text_small_cache_width]: [1024]
[ro.hwui.texture_cache_flushrate]: [0.4]
[ro.hwui.texture_cache_size]: [72]
[ro.intel.logger]: [/system/vendor/bin/logcatext]
[ro.opengles.version]: [196610]
[ro.product.board]: [rk30sdk]
[ro.product.brand]: [Android]
[ro.product.cpu.abi]: [arm64-v8a]
[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: [arm64-v8a]
[ro.product.device]: [rk3399_rigol]
[ro.product.first_api_level]: [25]
[ro.product.locale]: [en-US]
[ro.product.manufacturer]: [Rigol ([url=http://www.rigol.com]www.rigol.com[/url])]
[ro.product.model]: [rk3399_rigol]
[ro.product.name]: [rk3399_rigol]
[ro.product.usbfactory]: [rockchip_usb]
[ro.radio.noril]: [true]
[ro.revision]: [0]
[ro.rigol.ota.build]: [0]
[ro.rigol.product.aliasname]: [sparrow]
[ro.rigol.system.version]: [1.1.3]
[ro.ril.ecclist]: [112,911]
[ro.rk.LowBatteryBrightness]: [true]
[ro.rk.MassStorage]: [false]
[ro.rk.bt_enable]: [true]
[ro.rk.def_brightness]: [200]
[ro.rk.flash_enable]: [true]
[ro.rk.hdmi_enable]: [true]
[ro.rk.homepage_base]: [http://www.google.com/webhp?client={CID}&source=android-home]
[ro.rk.install_non_market_apps]: [false]
[ro.rk.screenoff_time]: [60000]
[ro.rk.screenshot_enable]: [true]
[ro.rk.soc]: [rk3399]
[ro.rk.systembar.tabletUI]: [false]
[ro.rk.systembar.voiceicon]: [true]
[ro.rksdk.version]: [RK30_ANDROID7.1.2-SDK-v1.00.00]
[ro.runtime.firstboot]: [1358470234680]
[ro.safemode.disabled]: [true]
[ro.secure]: [1]
[ro.serialno]: [RW8GIY5R55]
[ro.service.default_logfs]: [apklogfs]
[ro.sf.fakerotation]: [false]
[ro.sf.hwrotation]: [0]
[ro.sf.lcd_density]: [228]
[ro.support.lossless.bitstream]: [true]
[ro.sys.sdcardfs]: [true]
[ro.target.product]: [tablet]
[ro.tether.denied]: [false]
[ro.udisk.visible]: [true]
[ro.wifi.channels]: []
[ro.zygote]: [zygote64_32]
[security.perf_harden]: [1]
[selinux.reload_policy]: [1]
[service.adb.tcp.port]: [55555]
[service.bootanim.exit]: [1]
[sf.power.control]: [8847360]
[sys.boot_completed]: [1]
[sys.bootvideo.closed]: [1]
[sys.device_locked.status]: [0]
[sys.dropbox.max_size_kb]: [4096]
[sys.dump.binder_stats.anr]: [1]
[sys.dump.binder_stats.uiwdt]: [1]
[sys.ggralloc.commit]: [commit-id:1c1bd71]
[sys.ggralloc.version]: [1.0.6]
[sys.ghwc.commit]: [commit-id:3212866]
[sys.ghwc.version]: [0.66-rk3399-MID]
[sys.gmali.fbdc_target]: [0]
[sys.gmali.version]: [r18p0-01rel0-x-6@0]
[sys.gralloc.disable_afbc]: [1]
[sys.hwc.compose_policy]: [6]
[sys.hwc.device.aux]: []
[sys.hwc.device.main]: [DSI]
[sys.hwc.device.primary]: [DSI]
[sys.logbootcomplete]: [1]
[sys.resolution.changed]: [false]
[sys.rga.version]: [v1.0-20180420]
[sys.rkadb.root]: [0]
[sys.secureboot]: [false]
[sys.serialno]: [RW8GIY5R55]
[sys.status.hidebar_enable]: [false]
[sys.sysctl.extra_free_kbytes]: [7200]
[sys.usb.config]: [mtp,adb]
[sys.usb.configfs]: [1]
[sys.usb.controller]: [fe800000.dwc3]
[sys.wallpaper.rgb565]: [0]
[testing.mediascanner.skiplist]: [/mnt/shell/emulated/Android/]
[vold.has_adoptable]: [1]
[vold.post_fs_data_done]: [1]
[wifi.interface]: [wlan0]
[wifi.supplicant_scan_interval]: [15]
[wlan.driver.status]: [unloaded]
-
Here are the partitions in the SD card image, RigolDHO800-SDcard-dump.img:- offset=281018368,sizelimit=134217728: Ext4 Android backup/recovery partition
- offset=415236096,sizelimit=2147483648: Ext4 Android filesystem system named system (startup stuff)
- offset=2562719744,sizelimit=16777216: Ext4, empty
- offset=2584248320,sizelimit=524288000: Ext4 filesystem named rigol, contains interesting Rigol stuff
- offset=3225419776,sizelimit=28494004224: Ext4 filesystem, rest of the Android filesystem
Thanks for figuring out the offsets. Some more details on the partitions:
offset=415236096,sizelimit=2147483648: => /system partition which contains the Android framework (="operatingsystem" without kernel)
offset=2584248320,sizelimit=524288000: => Rigol proprietary partition. DHO800_DHO900_Update.GEL is a tar.gz file which seems to contain the parts of that partition. There seems also some calibration data stored in the data folder. There is also a 148 byte Key.data file.
(Attachment Link)
app/Sparrow.apk contains libscope-auklet.so which has quite some interesting strings embedded.
offset=3225419776,sizelimit=28494004224: => userdata partition. This is where on an Android system all user generated data is stored. logs/tools_log contains there some interesting logfiles.
-
more experience with Linux-based integration than Android, the difference being in the userspace, but I really don't see why the bootup should take 45 seconds
Bumped the other day into this parallel between Linux and Android partitions layout and boot process. It's a bird-eye view, in the premise of replacing Android with Linux on a mobile platform:
https://forum.xda-developers.com/t/info-android-device-partitions-and-filesystems.3586565/
https://forum.xda-developers.com/t/info-boot-process-android-vs-linux.3785254/
https://forum.xda-developers.com/t/info-is-it-possible-to-install-windows-ios-or-linux-on-android-device.3763961/
-
Out of curiosity I looked at the firmware update.
It is a *.GEL file that you can open with 7ZIP without problem.
The file within can then be extracted again with 7ZIP and you get the folder structure of the whole update file.
The update routine includes this folder with the update scripts:
Directory of DHO800_DHO900(Software)Update\Root\shell
13/09/2023 17:44 <DIR> .
13/09/2023 17:08 <DIR> ..
29/03/2023 09:37 512 bootApp.sh
29/03/2023 09:37 659 copy_logs_to_udisk.sh
20/06/2023 12:47 8,079 do_extract.sh
08/06/2023 03:46 1,798 do_update.sh
29/03/2023 09:37 645 force_update_gel.sh
29/03/2023 09:37 1,027 load_pcie.sh
20/06/2023 12:47 1,427 reload_fpga.sh
05/07/2023 08:16 97 restartScope.sh
20/06/2023 12:47 5,362 start_rigol_app.sh
9 File(s) 19,606 bytes
The main app is the Sparow.apk. Looking at it with a HEX-Editor, I found this:
License file detected
License invalid. Remaining attempts: 1
License invalid. Remaining attempts: 2
License invalid. Remaining attempts: 3
License invalid. Remaining attempts: 4
License invalid. Remaining attempts: 5
License invalid. Remaining attempts: 6
License invalid. Remaining attempts: 7
License invalid. Remaining attempts: 8
License invalid. Remaining attempts: 9
...
This function requires the following license:
...
Also, it seems that the licenses are stored in "LICENSE.txt".
It should be possible to edit "copy_logs_to_udisk.sh":
#!/system/bin/bash
echo "...... ifconfig ......"
ifconfig
udisk_mount_dir=$(ls -d1 /mnt/media_rw/* 2> /dev/null | head -n 1)
if [[ x"${udisk_mount_dir}" == x"" || ! -d ${udisk_mount_dir} ]]; then
echo "Does not exist U-Disk !"
exit 2
fi
target_log_dir=${udisk_mount_dir}/$(date "+%Y.%m.%d_%H.%M.%S")
# target_log_dir=/data/UserData/logs_for_debug/$(date "+%Y.%m.%d_%H.%M.%S")
echo mkdir -p ${target_log_dir}
mkdir -p ${target_log_dir}
echo cp -r /data/logs/tools_log ${target_log_dir}
cp -r /data/logs/tools_log ${target_log_dir}
# chown -R system:system /data/UserData/logs_for_debug
rm -f ${udisk_mount_dir}/fetch_sparrow_logs.txt
sync
In order to add a line like
cp -r /data ${target_log_dir}
The goal is to copy the whole data folder (and its sub-folders) to the attached USB disk. This might be the wrong folder, but with a bit of trial & error one should be able to get to see the LICENSE.txt file. I wonder if the options are in plain text...
Disclaimer: I don't own this device and I am not looking forward to buy one (I have the DS1054Z which is more than I will ever need). These are just my thoughts and ideas, they might break you brand new device.
-
Found a hidden debug mode in the utility menu that can be enabled if you tap the About button several times. This unlocks more options in the Other and the SelfCal tabs and a new Debug tab. Not sure if it has other effects.
-
I am a Java/Kotlin software developer and like some of the folks here my hobby is electronics, mainly microcontrollers stuff (pic18,pic24,pic32) and PCBs, also opened firmware update file and successfully decompiled the APKs, I have some experience with Android development so with that code and some effort you can compile your own modified APK and run it on the scope, I think everything is open in the scope to do that. Looking quickly at the code I think Sparrow.apk is all the GUI stuff, that should be communicating with the FPGA, is interesting to analyze the code because we can reverse engineer the communication between APK and FPGA so we can run custom apps on the scope.
In the screenshots, you can see some code to render the data on the screen, another thing to notice is that Rigol did not bother to obfuscate the code. :-DD
-
I have tracked the entire process of reading HDCODE, and have confirmed that it reads information from the GPIO port.
OK, but what does it do with that number?
Have you carefully read the analysis content in front of this thread, HDCODE is a 4-bit binary code,
HDCODE 1000 = Hardware version is 8
HDCODE 1100 = Hardware version is 12.
You should be familiar with similar computer coding.
Yes, I know all that...
The question is what does it do with that number? People have turned their DHO800s into DHO900s with vendor.bin so the firmware doesn't appear to do much with HDCODE.
I analyzed their apk software using IDA and found that hdcode was indeed used, and this part of the call was made before the system was calibrated, so this can be explained by overriding the vendor.bin Upgrading the DHO800 to the DHO900 will have an offset zero potential and be very noisy. So it's also not clear to me why they don't get the model ID directly through the information inside the vendor.bin. :-//
-
I analyzed their apk software using IDA and found that hdcode was indeed used, and this part of the call was made before the system was calibrated, so this can be explained by overriding the vendor.bin Upgrading the DHO800 to the DHO900 will have an offset zero potential and be very noisy. So it's also not clear to me why they don't get the model ID directly through the information inside the vendor.bin. :-//
It might just be a legacy thing. Maybe they originally planned to use hardware to select the model then a boss changed it to use vendor.bin to save a few $$$ on the production line.
-
It might just be a legacy thing. Maybe they originally planned to use hardware to select the model then a boss changed it vendor.bin to save a few $$$ on the production line.
Your guess fits the reality quite well.
-
AFAIK all of this vendor.bin, chip IDs, etc. started (in a more well thought way) with the MSO5000 and its bigger brothers.
What has been implemented in the HDO/DHO machines has some inheritance of those days but it's completely messed up, making hacks substantially easier to implement. On purpose or not, you choose.
-
(https://lh3.google.com/u/0/d/1X7i-IOEQTVkVzLjNHOUFmJzDq246F5Oy=w3841-h1956-iv1)
(https://lh3.google.com/u/0/d/1roa-bEnMEfKAOTVdbr6g1w2Uym4LoERj=w2870-h1956-iv1)
Some are reporting the waveform became fluffy after the hack.
edit: the person who reported this issue said he solved it by replacing the .hex calibration file from the backup. I didn't see this issue so can't confirm if it is true.
-
Yes, I know all that...
The question is what does it do with that number? People have turned their DHO800s into DHO900s with vendor.bin so the firmware doesn't appear to do much with HDCODE.
It is just the hardware version (likely they had an older version before release probably low run or prototype).
Mine is DHO804 and it is Hardware version 12
(https://electrodacus.com/RIGOL/Rigol2.jpg)
-
(https://lh3.google.com/u/0/d/1X7i-IOEQTVkVzLjNHOUFmJzDq246F5Oy=w3841-h1956-iv1)
(https://lh3.google.com/u/0/d/1roa-bEnMEfKAOTVdbr6g1w2Uym4LoERj=w2870-h1956-iv1)
Some are reporting the waveform became fluffy after the hack.
Is there a measurement picture to compare?
-
Some are reporting the waveform became fluffy after the hack.
Is there a measurement picture to compare?
Higher bandwidth = more fluff. That's just the way it is.
-
Some are reporting the waveform became fluffy after the hack.
Is there a measurement picture to compare?
Higher bandwidth = more noise. That's just the way it is.
Exactly! I even read one thread on some forum where one guy strips several capacitors of the front-end circuit of its high-end scope to lower the bandwidth of BW mode on that channel to use it for the purpose of low noise studies when high bandwidth is not required.
That's why I thought that firmware from dho914s was more attractive because it could get all the features without quadrupling the bandwidth.
But anyway it would the interesting to see more head-to-head comparisons between 804 and 924s firmware to know the exact level of fluffiness.
-
to know the exact level of fluffiness.
BW limit 100 MHz option should resolve the issue.
-
to know the exact level of fluffiness.
BW limit 100 MHz option should resolve the issue.
I still think the HDO800 could do 125Mhz with the right sort of hacking. That's the sweet spot for the sample rate.
(and a really fancy hack could switch 125MHz/250MHz depending on how many channels are enabled)
-
and a really fancy hack could switch 125MHz/250MHz depending on how many channels are enabled
This should normally be the job for Rigol, on the 900 models.
But I wouldn't be surprised if the users get it right first. ;)
Assuming that both models use the same hardware, I hope that the 800 can be brought up to the same bandwidth without having to pretend it's a 900.
-
to then try the 800 and 900 probes, although there are 2 types of probes on 900 depending on the specific model?
would be cool to see on the lower freq x1 mode too. you know, how much difference is actually down to the included probes. at these price points. that's not to say cannot get 3rd party ones - kindda just bumps the price up which then makes into some pricing difference between 800 and 900 series. be it whatever if only +$100 for the probes themselves. but hacking l.a. header is so cheap, which would make to $200 worth of options (unless the 900 comes with external l.a. module, but i dont believe it does, does it?)
-
edit: the person who reported this issue said he solved it by replacing the .hex calibration file from the backup. I didn't see this issue so can't confirm if it is true.
Could you please describe step by step the procedure? Where to get the DHO800_DHO900_Update.GEL from DHO924? Could the scope be hacked without warranty sticker violation?
-
Could the scope be hacked without warranty sticker violation?
Yes. You can hack it with Android Debugger ("ADB") over the ethernet port.
-
edit: the person who reported this issue said he solved it by replacing the .hex calibration file from the backup. I didn't see this issue so can't confirm if it is true.
Could you please describe step by step the procedure? Where to get the DHO800_DHO900_Update.GEL from DHO924? Could the scope be hacked without warranty sticker violation?
Obviously, you didn't look closely at the tool software RIGOL_Tools_v1.0.2 .zip
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077960/#msg5077960 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077960/#msg5077960)
that I released a few pages before this thread. With it you don't need to disassemble the hardware and program the SD card, and you can freely upgrade to the latest firmware without having to worry about zero offset.
-
....and you can freely upgrade to the latest firmware without having to worry about zero offset.
I've found 1.14 (the latest firmware) SD card disc image only (the first message of this thread).
How do I install firmware V1.14 on my V1.00 scope without disassembly? Should I extract the ./rigol folder and replace it on the scope through adb push? Or should I extract the DHO800_DHO900_Update.GEL file, push it to the scope, and install with appropriate script? :-// :-BROKE
-
edit: the person who reported this issue said he solved it by replacing the .hex calibration file from the backup. I didn't see this issue so can't confirm if it is true.
Could you please describe step by step the procedure? Where to get the DHO800_DHO900_Update.GEL from DHO924? Could the scope be hacked without warranty sticker violation?
Updated: Please check here first:https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5130924#msg5130924 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5130924#msg5130924)
Sure.
1. Make a full backup of your oscilloscope
This was done by taking the oscilloscope apart and extracting its SD card to make a full disk image.
Alternatively, you can make a backup using ADB to transfer all the files to your PC, I think it can achieve the same goal. (The rigoltool provided by @souldevelop also relies on ADB, see #31)
2. Roll back the firmware version from 01.00 to 01.14. (Noted that 01.14 did have an earlier compile date although it has a larger number.)
This was previously done by overwriting the SD card with the disk image containing firmware version 01.14 provided by @hubertyoung. (See #0)
Alternatively, I think replacing all the files on the SD card with ADB commands can achieve the same goal. (Just replacing the critical files may be enough but I have no idea which file is affecting the firmware number.)
3. Reboot and check if the firmware version has been successfully rolled back. If not, disconnect the power and try again.
4. Write the new identity of the oscilloscope using the rigoltool. Reboot and your oscilloscope has been hacked.
5. Calibrate your oscilloscope. Several people are reporting strange issues after hacking. For most of the time, calibration can solve the issue.
In my case, I do a full calibration manually. In the "settings" menu, tap on the "about" tab several times to activate factory mode. Turn to the calibration tab and do a full calibration. Some reports that they can do the full calibration with no issue. In my case, I have to uncheck the "ADC phase" to complete the calibration.
Alternatively, some replace the cal_xxx.hex file from the backup (Step1) and claim that can also get the job done. (See #86)
-
Some claim they managed to hack the oscilloscope on firmware version 01.00 but they refuse to share their practices. Nonetheless, I will document what they say about this subject as it may contain some useful clues.
1. They claim that the baseline drift was caused by an update on the calibration algorithm. The reference gain is different from the previous firmware.
2. They claim that they solve this issue by programming the FPGA.
3. boot.bin is involved in the process.
I don't know much about FPGA but as the boot.bin is located at \rigol\FPGA, I think it is the file to be used to program the FPGA.
It seems that there are also some scripts located at rigol\shell that describe the update process of the FPGA.
Obviously, I am not smart enough to piece all these together. Therefore, I provide all the information on my hand and hope someone better to come and save the day. :palm:
-
so it is a mismatch between the boot.bin fpga code and the rigol firmware causing this issue?
for example if the fpga code isnt gets triggered to be updated? or is trys gets updated (uploaded) and fails, thereby defaulting back to what was originally programmed in the factory? sorry i don't know how this fpga works here. if its reloaded into running memory every boot time. instead of being flashed. or can it be that once programmed, the running fpga code is then subsequently configured with some settings, things like this?
those hints sound credible though. as per reason for why
-
The Zynq is Xilinx FPGA and it usually loads the "bitstream" upon power on from an external source (usually flash rom). I doubt somebody made changes to the bitstream of the FPGA as that is pretty difficult exercise (unless you are an insider).
Btw., I would not mess with the upgrade until at least 3 brave new (knowledgeable) users will do it successfully (and they confirm the process step by step).
-
The Zynq is Xilinx FPGA and it usually loads the "bitstream" upon power on from an external source (usually flash rom). I doubt somebody made changes to the bitstream of the FPGA as that is pretty difficult exercise (unless you are an insider).
Btw., I would not mess with the upgrade until at least 3 brave new (knowledgeable) users will do it successfully (and they confirm the process step by step).
You don't need 3 brave. 1 is enough as long as it is knowledgeable. :)
About the bitstream, I don't believe there was any "patch" change. At most, what happened is a repackaging of the bitstream from another model. Even that is see to believe.
I don't need to remember that patching the bitstream is beyond "knowledgeable" user level.
Also, remember these scope's price is well within many user's budgets here. But, there are some for whom even this price has some punch. Spearheading new unproven "push the envelope" efforts might result in unhappy faces...
-
Has anyone decompiled the APK files and started to make sense of them yet? I've taken a look but being an Android development newb I am having trouble finding my way. I have been trying to find out where the application talks to the hardware to try to determine how much work, such as math functions, is done in the application vs FPGA.
I won't have a scope in my hands for over a week and I hope that it will be easier to find my way in the code once I can use debug to watch it working. Of course I'll also have to figure out how to get debug working too.
-
I just pulled the main .apk file out to have a fiddle with it. Can anybody recommend a free apk decompiler?
nb. I'm not an Android guy so I don't really know what I'm doing. (yet)
Edit: I put the .apk file here: http://www.artlum.com/pub/DHO/Sparrow.apk (http://www.artlum.com/pub/DHO/Sparrow.apk)
-
How can I decrypt/encrypt vendor.bin files?
I'd like to diff them to see if features can be enabled selectively.
-
How can I decrypt/encrypt vendor.bin files?
Does SoulDevelop's tool decrypt vendor.bin as part of its job? Alternatively I think I read somewhere that the encryption is the same as previous Rigol models, maybe look to the 1000z tool to extract the decryption part.
-
How can I decrypt/encrypt vendor.bin files?
I'd like to diff them to see if features can be enabled selectively.
@tv84 had posted a decrypted vendor.bin here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074867/#msg5074867), so he can probably help?
Also, the same post mentions a :VENDor:CONFigure SCPI command to change individual parameters in vendor.bin. Has anyone tried that? Can it be that easy?
-
How can I decrypt/encrypt vendor.bin files?
Does SoulDevelop's tool decrypt vendor.bin as part of its job? Alternatively I think I read somewhere that the encryption is the same as previous Rigol models, maybe look to the 1000z tool to extract the decryption part.
It's TEA encryption with a known key. Shouldn't be too difficult...
-
On to Mech trying to upgrade his scope from DHO804 to DHO924 in the whole night... after reading carefully this thread, then creating full backup of original FW (DHO804 ver 00.01.00)...
doing upgrade by using souldevelop's tool https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077957/#msg5077957 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077957/#msg5077957) for ver 1.00 FW to DHO924 model, creating problem weird voltage vertical offset on all channels.
and then copying full image v1.14 from first post https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074423/#msg5074423 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074423/#msg5074423) , doing calibration at first also introduce some weirdness esp when trying to enter development mode and enable ADC gain, AFE zero during calibration. switching dso off, turn on again and calibrate in normal mode, now it seems ok... few issues with 804 -> 924 upgrade...
1) even though BW increased to 230MHz, but extra ringing on pulses (overshot on both UTG962's and Leo Bodnar's pulse shown below)
2) observing 200uV/div reveals some suspiciously low noise floor when plotted in FFT. upon close observation of a signal between 500uV/div and 200uV/div, i concluded, there some kind of averaging (boxcar or running average) going on at 200uV/div, from less dense spectral content on display, shown below.. cant complaint much for an extra feature.. (better something than nothing, if you dont like it, dont use it)
3) the DSO original serial number is lost (already saved in backup image), so lets wait until someone know how to decrypt-edit-encrypt back the vendor.bin
good thing is...
1) 50Mpts memory (10Mpts/ch if all channel enabled)
2) 230MHz BW (except ringy)
3) Bode plot menu appears, quick play with it, possibly it can be hacked by injecting external (middleman) signal?
4) Nice D (LA)and G (AWG) stickers at bottom screen next to channels button (that Fungus really hates)
fwiw...
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1907349;image)
-
On to Mech trying to upgrade his scope from DHO804 to DHO924 in the whole night... after reading carefully this thread, then creating full backup of original FW (DHO804 ver 00.01.00)...
You don't need too do any of that. Just replace vendor.bin using ADB, it takes a few seconds.
Fungus' quick guide to changing to a 924:
Download adb command line tools here: https://developer.android.com/tools/releases/platform-tools (https://developer.android.com/tools/releases/platform-tools)
(nb. You only need three files from that .zip file: adb.exe and AdbWin*.dll)
Now do this:
adb connect 192.168.1.205:55555 (or whatever your IP address is)
adb pull /rigol/data/vendor.bin (keep this file safe - it's your vendor.bin)
Download the HDO924 vendor.bin from here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074867/#msg5074867)
adb push vendor.bin /rigol/data (send the HDO924 vendor.bin to the 'scope)
adb reboot (do NOT power cycle it, there seems to be a caching delay before the file is written to flash)
To switch it back just push your original vendor.bin
-
You don't need too do any of that. Just replace vendor.bin using ADB, it takes a few seconds....
i think that is what souldevelop's tool do earlier on my scope.. some DHO924's vendor.bin got pushed into DHO804 v00.01.00
-
You don't need too do any of that. Just replace vendor.bin using ADB, it takes a few seconds....
i think that is what souldevelop's tool do earlier on my scope.. some DHO924 got pushed into DHO804 1.00
I prefer to do it manually.
-
Do you have the vendor.bin for a 924S ? (ie. With AWG)
I'm trying to collect vendor.bin files for all the different models. I have the 924 but not the 924S.
-
Do you have the vendor.bin for a 924S ? (ie. With AWG)
I'm trying to collect vendor.bin files for all the different models. I have the 924 but not the 924S.
i did full copy from OP, didnt you read? that means i'm using his vendor right now. i only have my DHO804 vendor.bin but its already in the 32GB image file.. takes time to extract if you interested. bed time now..
btw: i think one hint to crack vendor.bin is disassemble sparrow.apk or whoever apk read the file for serial and model display and find out what decryption scheme is used, or possibly by luck find encryption scheme too in there. if you just want to eyeball the difference of rjindael encrypted files content i believe you are going to have bad daysssss... thats alan turing's job at breaking enigma.
-
Do you have the vendor.bin for a 924S ? (ie. With AWG)
I'm trying to collect vendor.bin files for all the different models. I have the 924 but not the 924S.
i did full copy from OP, didnt you read? that means i'm using his vendor right now. i only have my DHO804 vendor.bin but its already in the 32GB image file.. takes time to extract if you interested. bed time now..
Yeah, I read. Could you pull the 924S vendor.bin using ADB now you have his image installed? It only takes a second, see instructions above.
Once you have vendor.bin files you'll never need to do the SD card imaging thing again. eg. You could switch back to your original 804 over Ethernet in not much more than the time it takes to reboot.
btw: i think one hint to crack vendor.bin is disassemble sparrow.apk or whoever apk read the file for serial and model display and find out what decryption scheme is used, or possibly by luck find encryption scheme too in there.
I think it's TEA encryption with the standard Rigol key but I haven't had time to play yet.
(ie. It's more obfuscation than encryption...)
I have sparrow.apk decompiled but most of the low level functions are in a ".so" file so there's no source code for me to read.
-
Hi. Thanks for all for the effort.
So after reading all the posts I have sincerely not understood if the tool provided is definitely able to upgrade the Rigol without the calibration problem. As far as I have understood it has still some minor things lneed to be corrected (GPIO pin model assignment) . Is the tool ready or will be there more version? Thank you all.
-
Hi. Thanks for all for the effort.
So after reading all the posts I have sincerely not understood if the tool provided is definitely able to upgrade the Rigol without the calibration problem. As far as I have understood it has still some minor things lneed to be corrected (GPIO pin model assignment) . Is the tool ready or will be there more version? Thank you all.
from what i understand reading the thread... and doing the upgrade last night with no-hassle-free process. souldevelop's tool is to automate adb's job at uploading vendor.bin file into android operating system in the dso's sd card. adb tool is generic (manual command line) tool for android system debugging, its like remote control pc tool. it can send command to android OS, upload and download files etc. otoh the image file (600-800MB compressed, 32GB expanded) in OP is the whole operating system ver1.14 if you want to write to your sd card using hdd raw copy tool in PC... its preloaded with DHO924S verdor.bin "signature" so you dont have to use souldevelop's tool nor adb to change anything. just copy, run and calibrate.
currently DHO800 batch in market comes with ver1.00 and it has issues with calibrating DHO800 HW for DHO900 model. but earlier ver1.14 android has no issue or can be worked to calibrate. so if your DHO800 already has OS ver1.14 in it, you can just use souldevelop's tool to switch back and forth verdor.bin file in and out of your DHO. but if you have ver1.00 OS in your DSO, i think you need to full copy the image file in OP first into sd card. i have suspicion that ver1.00 is newer updated and more fine tuned calibration algorithm, so if you dont want to miss out its new feature, dont upgrade to DHO900, just upgrade to DHO814 using souldevelop's tool.
if i know android system and am an apk developer, i would like to construct the whole android file structure in sandbox folder in my PC, try to study it, put a usefull apk tool for the DSO like Azusa did put game in https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg4981042/#msg4981042 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg4981042/#msg4981042) and also try to find how vendor.bin is read, decrypted and encrypted so we can edit it in plain text, put DHO924 model in it, our original serial number, encrypt it back and put in DSO. unfortunately i'm not apk developer, so let young people do the job. we can only benefit from their hardwork right now.
-
you dont have to use souldevelop's tool nor adb to change anything. just copy, run and calibrate.
So long as you don't mind opening it up and unglueing the SD card... :popcorn:
The ADB method can be done in two minutes without opening anything up and is completely reversible (so long as you keep your vendor.bin safe).
I had no calibration problems with the latest 01.01.19 firmware.
Here's my 804 thinking it's a 924:
(https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/?action=dlattach;attach=1906821;image)
This was my rise time measurement:
(https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/?action=dlattach;attach=1906779;image)
-
The ADB method can be done in two minutes without opening anything up and is completely reversible (so long as you keep your vendor.bin safe).
What about the possible simple hack/mod to limit or raise BW just by swapping SD cards without opening the unit chassis (of course you have to open it once).
That can be done with this neat SD card extender and attached to the backside with regular double-sided tape.
-
you dont have to use souldevelop's tool nor adb to change anything. just copy, run and calibrate.
So long as you don't mind opening it up and unglueing the SD card... :popcorn:
mine is not glued, it is taped which can easily be untaped and retaped. unglueing and tearing down is our play thing, its even the mission/motto of this forum ;) here attached step by step guide on doing backup your sd SW and HW (please note how i store the original card without needing external dedicated space for it (d.jpg) ;D now running from another sd card, its cheap nowadays...
I had no calibration problems with the latest 01.01.19 firmware.
ok now we have newer than v1.00? where can i get it?
-
The ADB method can be done in two minutes without opening anything up and is completely reversible (so long as you keep your vendor.bin safe).
What about the possible simple hack/mod to limit or raise BW just by swapping SD cards without opening the unit chassis (of course you have to open it once).
That can be done with this neat SD card extender and attached to the backside with regular double-sided tape.
I guess that would work. :-//
Still takes time to prepare all the SD cards though, and you have to own a pile of them.
-
I had no calibration problems with the latest 01.01.19 firmware.
ok now we have newer than v1.00? where can i get it?
https://supportcn.rigol.com/Public/Uploads/uploadfile/files/ftp/Firmware/DHO800_DHO900(Software)UpdateV00.01.01.zip
-
Hi,
The "ADB Method":
When I run adb connect 192.XXXXXXX after a while the message "failed to connect 192.XXXXXXXX" appears.
When I try it again, message "already conneted to 192.XXXXXXXX" appears.
But when I type the command for getting the data from the rigol the message "device is offline" appears - although it´s not...
-
When I run adb connect 192.XXXXXXX after a while the message "failed to connect 192.XXXXXXXX" appears.
When I try it again, message "already conneted to 192.XXXXXXXX" appears.
Do you have anything else connected, eg. a phone on USB?
Try doing "adb disconnect"
-
The scope is connected via LAN cable to the router, webserver access is no problem, scope is online.
My smartphone is also connected via wlan to the router.
EDIT: second pic attached
-
Second try with another pc (notebook), same results.
-
Second try with another pc (notebook), same results.
Use scope-ip-address:55555 (five 5's)
The scope should connect right away. If it is hanging, reboot the scope and PC and try again, with the five 5's (not 4). Hope this helps.
-
This was it :-+
And now...tadaa.. ;)
-
This was it :-+
And now...tadaa.. ;)
:)
-
Note that your serial number is in vendor.bin so it will change when you do this.
I predict a lot of 'scopes out there with identical serial numbers...
-
;D
So, before calibration, only channel 1 have a "huge" offset.
BTW, did you notice that you now have 200µV/Div. ?
-
BTW, did you notice that you now have 200µV/Div. ?
Oh, yeah... :-+
-
Offset is not getting better after calibration...
More, it varies with the different V/div steps.
Is there are solution for it ?
Edit:
so you are running OS 01.01.19?
I think not.
-
I predict a lot of 'scopes out there with identical serial numbers...
hubertyoung's serial number... who cares? ;D
So, before calibration, only channel 1 have a "huge" offset.
BTW, did you notice that you now have 200µV/Div. ?
so you are running OS 01.01.19? with legit in-scope upgrade method? and then use adb or souldevelop's tool to push hubertyoungs DHO924 verdor.bin? can you check offset for all channels at 200uV, 500uV, 1mV/div etc to b correct? i got all kind of weirdness when overwriting DHO924's vendor.bin into OS V01.00...
Offset is not getting better after calibration...
More, it varies with the different V/div steps.
Is there are solution for it ?
Edit:
so you are running OS 01.01.19?
I think not.
so you got the weirdness thaat i experienced... up to 1 or 5V/div has some nasty offset, but when going up to 10V/div offset is correct again.
later i will try upgrade my legi V01.00 to V01.19 fungus provided and see what happens if i overwrite the DHO924 vendor.bin alone. if calibration ok, then thats should be the better hack. upgrade to DHO924, but still using latest (bug fixed) OS...
-
so you are running OS 01.01.19?
I think not.
If you press "About" three times you get the extended firmware version number... :)
Offset is not getting better after calibration...
Did self-cal report success?
There's extended calibration options if you enable debug mode as above. Don't ask me what they do though. Some of them said "failed" on mine when I tried them.
-
Did self-cal report success?
Yes..
-
Did self-cal report success?
Yes..
I just went to 924 again and I have an offset on channel 3. I'm sure I didn't have that before... :-\
-
It varies...
So, after upgrading following your link, the version shows this (Pic).
After that doing the self-cal again, offset problems still persists.
I think I´ll going back to 804..
-
It varies...
So, after upgrading following your link, the version shows this (Pic).
After that doing the self-cal again, offset problems still persists.
I think I´ll going back to 804..
go back to original 804, do the legit upgrade to 01.19, then push vendor.bin again. this is what i'm going to try, but not tonight...
-
go back to original 804
Dit it, everything´s fine again.
It would probably be better if one could intervene specifically in one's own bin file, but that is beyond my abilities, clear case. ;)
do the legit upgrade to 01.19
I had taken the link from Fungus, it seems that it is not, if you look at my picture "version" (that was after the firmwareupgrade).
-
There must be something in the (very small) .bin file that "changes" the offset, because what I have noticed in the last 2 hours is that the offset "varies" depending on the setting of the sensitivity.
For example, you can see a small offset at 5V/div, which should then be "huge" if you go further down.
But this is not so, it is sometimes smaller, sometimes larger.
If I didn't know better, one could think that there are calibration data in the .bin file that don't fit to another scope.
Or it has something to do with the additional 200µV/div, which does not exist in the 800, that something gets mixed up.
-
I'm trying to understand some of the early posts in this thread:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074867/#msg5074867 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074867/#msg5074867)
It seems that all that's in vendor.bin is a model number, a serial number, and a MAC address.
In that case: The options that you get are based only on the model number in that file. They aren't selected individually.
The post after that one doesn't make much sense:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5075035/#msg5075035 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5075035/#msg5075035)
"simply replacing the vendor.bin will cause a 5mV-10mV offset to appear, and it can't be eliminated by self-cal."
Why should that be?
-
There must be something in the (very small) .bin file that "changes" the offset, because what I have noticed in the last 2 hours is that the offset "varies" depending on the setting of the sensitivity.
For example, you can see a small offset at 5V/div, which should then be "huge" if you go further down.
That's easy: Each individual range will have its own offset/scale values, all created during calibration.
-
Why should that be?
We are currently experiencing that this is the case.
Why this is so, currently no idea, maybe it still comes.
-
I found out you can load any firmware you want. It doesn't complain about downgrades...
I've just gone back to 1.00, I wanted to check something.
-
I analyzed their apk software using IDA and found that hdcode was indeed used, and this part of the call was made before the system was calibrated, so this can be explained by overriding the vendor.bin Upgrading the DHO800 to the DHO900 will have an offset zero potential and be very noisy. So it's also not clear to me why they don't get the model ID directly through the information inside the vendor.bin. :-//
Could you expand on this? We're trying this upgrade now and hitting this problem.
-
I found out you can load any firmware you want. It doesn't complain about downgrades...
I've just gone back to 1.00, I wanted to check something.
I confirmed it!
With firmware 1.00 I see this in my "Options":
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1908513;image)
After upgrading to firmware 1.01 I see this:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1908519;image)
-
We had already established that today.
For me, however, this also means that something can still happen with our 800 models.
With a little patience and cleverness (which I certainly do not have in this matter), you could make an 824 with 50 Mpts memory from the 804.
-
I found out you can load any firmware you want. It doesn't complain about downgrades...
I've just gone back to 1.00, I wanted to check something.
Re: the offsets, this worked for me very well for now: Starting with the 1.00 firmware and original corresponding 804 vendor.bin file, recalibrate (with the scope warmed up). Then substitute the 924 vendor.bin file (with the serial number we've all seen). Turn the scope on, with all the channels on and let it sit (if cold) for about 20 minutes at 200uV/div and, say, at 1ms/ with 1Mpts/62.5MSa/s. Hopefully you will see the 4 traces slowly come together, with no significant offsets (and <24uV AC-RMS term.), and remaining on top of each other all the way from 200uV/div to 10V/div. (Inconvenient to have to use the 1.00 firmware and to have to recalibrate with the orig. 804 file in the meantime, but not too bad with adb...)
-
I analyzed their apk software using IDA and found that hdcode was indeed used, and this part of the call was made before the system was calibrated, so this can be explained by overriding the vendor.bin Upgrading the DHO800 to the DHO900 will have an offset zero potential and be very noisy. So it's also not clear to me why they don't get the model ID directly through the information inside the vendor.bin. :-//
Could you expand on this? We're trying this upgrade now and hitting this problem.
I would love to hear more from souldevelop but I haven't seen a post from him lately. I did a quick search and found a product called IDA by a company called Hex-Rays. It looks to me like he used the pro version which is very expensive.
-
I'm still wondering about the "Option" section in the Utility menu.
After the purchase there was a bandwith option, after the firmware upgrade now a storage depth option.
And this although there are no options to buy...
-
This is the main reason why I've been away from all the noise in this thread. Let the dust settle and then we'll see what needs to be done.
Changing options from version to version... :palm:
-
So called v1.14 Firmware is exactly v1.00 except for these files:
folder | name | size, bytes
data cal_adc.hex 1.876
data cal_afe_bandwidth.hex 348
data cal_afe_zero.hex 348
data cal_ddr.hex 76
data cal_lsb.hex 156
data cal_vertical.hex 179.452
data Key.data 148 (here is your key, don't replace this file)
data vendor.bin 212 (here is your serial and model (which may, or not may be extending your scope's options))
data\default cal_vertical.hex 179.452
FPGA BOOT.bin 3.631.368
-
vendor.bin has nothing to do with options! For what interests you all, it's basically Model and S/N.
-
You can create backup of many Rigol specific files (incl. vendor.bin and key.data) by typing in the command prompt:
adb connect <IP of your scope>:55555
adb devices
adb shell rm /rigol/DHO800_DHO900_Update.GEL
adb shell cd /rigol;sh build_gel.sh
adb pull rigol/DHO800_DHO900_Update.GEL
This creates DHO800_DHO900_Update.GEL file.
It's GZIP archive with DHO800_DHO900_Update (no extention) file inside. It's TAR archive containing all files and folders from the "rigol" folder.
-
This creates DHO800_DHO900_Update.GEL file.
Where ?
-
With firmware 1.00 I did not find the way to properly upgrade my DHO804 to DHO924. The offset is always there.
I tried to replace cal*.hex files, but ended up with no waveform display.
Then, probably after replacing the Key.data file, my scope went into the boot loop.
There was no time to do anything before the reboot. The sparrow.apk was constantly reloading.
In this state, adb worked fine, it was possible to write any files to the scope, but the "/rigol/data/cal_afe_bandwidth.hex" was always replaced by the scope for the same instance before reboot. That was probably some dummy file, which I did not find in any of the firmware copies I have.
So I had to open the oscilloscope, to flash the DHO924S firmware from the first message. And now it's back again, calibrated with no offset.
BTW, the firmware is from DHO924S, but replacing only the vendor.bin gives DHO924 without the "S" option.
UPDATE: boot loop was due to lack of execution permissions on the scripts.
-
This creates DHO800_DHO900_Update.GEL file.
Where ?
In the /rigol folder.
-
So called v1.14 Firmware is exactly v1.00 except for these files:
folder | name | size, bytes
data cal_adc.hex 1.876
data cal_afe_bandwidth.hex 348
data cal_afe_zero.hex 348
data cal_ddr.hex 76
data cal_lsb.hex 156
data cal_vertical.hex 179.452
data Key.data 148 (here is your key, don't replace this file)
data vendor.bin 212 (here is your serial and model (which may, or not may be extending your scope's options))
data\default cal_vertical.hex 179.452
FPGA BOOT.bin 3.631.368
thanks for info. last night i saved all those from 1.0.0, 1.1.2 and 1.14 thinking they might do something. using souldevelop tool is very quick pulling many files and viewing files structure, i wish souldevelop can expand its functionality to push files manually, no need command line... maybe next is experimenting with latest v1.1.2 and inserting those cal hex from 1.14 ... last night i upgraded to v1.1.2 and overwriting vendor.bin with 924, channel offset still problem...
-
So called v1.14 Firmware is exactly v1.00 except for these files:
folder | name | size, bytes
data cal_adc.hex 1.876
data cal_afe_bandwidth.hex 348
data cal_afe_zero.hex 348
data cal_ddr.hex 76
data cal_lsb.hex 156
data cal_vertical.hex 179.452
data Key.data 148 (here is your key, don't replace this file)
data vendor.bin 212 (here is your serial and model (which may, or not may be extending your scope's options))
data\default cal_vertical.hex 179.452
FPGA BOOT.bin 3.631.368
The timestamp changes on "cal_vertical.hex" whenever you do a self-cal. I think that's where the results are stored. :)
thanks for info. last night i saved all those from 1.0.0, 1.1.2 and 1.14 thinking they might do something. using souldevelop tool is very quick pulling many files and viewing files structure
You can pull many files with ADB by putting a '.' on the end of the file name.
eg. Use this to pull the entire "/rigol/data" folder (with subfolders)
ADB pull /rigol/data/.
-
You can create backup of many Rigol specific files (incl. vendor.bin and key.data) by typing in the command prompt:
adb connect <IP of your scope>:55555
adb shell rm /rigol/DHO800_DHO900_Update.GEL
adb shell cd /rigol;sh build_gel.sh
This creates DHO800_DHO900_Update.GEL file.
It's GZIP archive with DHO800_DHO900_Update (no extention) file inside. It's TAR archive containing all files and folders from the "rigol" folder.
It would be awesome if somebody could do this with a 1.14 installation and upload the .GEL file somewhere.
That way everybody could try 1.14 without opening up their 'scope and messing around with SD cards.
-
vendor.bin has nothing to do with options! For what interests you all, it's basically Model and S/N.
To be precise: Model, serial number and MAC address
Options appear to be in /rigol/data/Key.data
I read somewhere that the key file is encrypted using the serial number from vendor.bin but that would imply my serial decoder options should disappear when I change my vendor.bin. But they don't. :-//
-
This creates DHO800_DHO900_Update.GEL file.
It's GZIP archive with DHO800_DHO900_Update (no extention) file inside. It's TAR archive containing all files and folders from the "rigol" folder.
Aha! The thing inside the .gel file is a .tar file. That's worth knowing :)
(Obvious, really, if you look at "build_gel.sh")
####################################################################################
# Create tar.gz package
####################################################################################
if [ -d data/ ]; then
tar -czvf temp.gel app driver FPGA shell tools resource data
else
tar -czvf temp.gel app driver FPGA shell tools resource
fi
if [ $? -eq 0 ]; then
mv temp.gel $build_out
else
echo "Create Sparrow-Package GEL Failed !"
exit 1
fi
echo "Create Sparrow-Package GEL Success !"
-
So called v1.14 Firmware is exactly v1.00 except for these files:
folder | name | size, bytes
data cal_adc.hex 1.876
data cal_afe_bandwidth.hex 348
data cal_afe_zero.hex 348
data cal_ddr.hex 76
data cal_lsb.hex 156
data cal_vertical.hex 179.452
data Key.data 148 (here is your key, don't replace this file)
data vendor.bin 212 (here is your serial and model (which may, or not may be extending your scope's options))
data\default cal_vertical.hex 179.452
FPGA BOOT.bin 3.631.368
With firmware 1.00 I did not find the way to properly upgrade my DHO804 to DHO924. The offset is always there.
I tried to replace cal*.hex files, but ended up with no waveform display.
The secret might be in /rigol/FPGA/BOOT.bin
-
I'm trying to understand some of the early posts in this thread:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074867/#msg5074867 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074867/#msg5074867)
It seems that all that's in vendor.bin is a model number, a serial number, and a MAC address.
In that case: The options that you get are based only on the model number in that file. They aren't selected individually.
The post after that one doesn't make much sense:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5075035/#msg5075035 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5075035/#msg5075035)
"simply replacing the vendor.bin will cause a 5mV-10mV offset to appear, and it can't be eliminated by self-cal."
Why should that be?
Please refer to here for the possible reason:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5108487 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5108487)
-
So called v1.14 Firmware is exactly v1.00 except for these files:
folder | name | size, bytes
data cal_adc.hex 1.876
data cal_afe_bandwidth.hex 348
data cal_afe_zero.hex 348
data cal_ddr.hex 76
data cal_lsb.hex 156
data cal_vertical.hex 179.452
data Key.data 148 (here is your key, don't replace this file)
data vendor.bin 212 (here is your serial and model (which may, or not may be extending your scope's options))
data\default cal_vertical.hex 179.452
FPGA BOOT.bin 3.631.368
With firmware 1.00 I did not find the way to properly upgrade my DHO804 to DHO924. The offset is always there.
I tried to replace cal*.hex files, but ended up with no waveform display.
The secret might be in /rigol/FPGA/BOOT.bin
All the clue so far seem to suggest this might be the case.
-
To decrypt vendor.bin, this should work. I don't have one (yet) so I can't test for myself. Stumbled across this post and thought I'd help out. Added some notes on how to find key.
import xxtea
# .\Sparrow.apk\lib\arm64-v8a\libscope-auklet.so
# CApiUtility::ApiUtility_SaveVendorData(_QWORD *) > CXXTEA::setKeys(int *) > fileKeys
key = b'\x34\xCD\x12\xAB\x34\xCD\x12\xAB\x34\xCD\x12\xAB\x34\xCD\x12\xAB'
with open('vendor.bin', 'rb') as f:
ven_data = f.read()
ven_dec = xxtea.decrypt(ven_data, key, False)
print(ven_dec)
ven_enc = xxtea.encrypt(ven_dec, key, False)
print(ven_enc == ven_data)
-
You can create backup of many Rigol specific files (incl. vendor.bin and key.data) by typing in the command prompt:
adb connect <IP of your scope>:55555
adb shell rm /rigol/DHO800_DHO900_Update.GEL
adb shell cd /rigol;sh build_gel.sh
This creates DHO800_DHO900_Update.GEL file.
It's GZIP archive with DHO800_DHO900_Update (no extention) file inside. It's TAR archive containing all files and folders from the "rigol" folder.
It would be awesome if somebody could do this with a 1.14 installation and upload the .GEL file somewhere.
That way everybody could try 1.14 without opening up their 'scope and messing around with SD cards.
Here you go:https://drive.google.com/file/d/1PPwj8Ll_AcQYaTjsKz7_kHFZq16VN0zK/view?usp=drive_link (https://drive.google.com/file/d/1PPwj8Ll_AcQYaTjsKz7_kHFZq16VN0zK/view?usp=drive_link)
What is it?
It is an upgrade pack based on the files on my oscilloscope with FW 01.14. The vendor.bin of 924 is already included.
How to use it?
Use the upgrade function of the oscilloscope(Remove the extra text in the file name before use). Please refer to Rigol's official FW upgrade guide.
After the upgrade, the FW version would be 01.06 (I don't know why) but there will be no DC offset.
If the waveform disappeared after the upgrade, do a selfcal and it will be back.
Is it safe?
No, if you don't know what you are doing.
Would it work?
Yes. As tested by some other 804 owners.
p.s. It seems that sparrow.apk determines the displayed FW version.
Feeding in 1Vpp 120MHz Sin wave as a demo.
(https://lh3.google.com/u/0/d/1AybP1MGqevxaRlnVmEzZUgQbQhdyLTHN=w3840-h1984-iv1)
(https://lh3.google.com/u/0/d/1D902YZVbF369OJbrkmO-LXeDuvg9n6am=w3840-h1984-iv2)
-
Options appear to be in /rigol/data/Key.data
I read somewhere that the key file is encrypted using the serial number from vendor.bin but that would imply my serial decoder options should disappear when I change my vendor.bin. But they don't. :-//
Once again: key.data is only a ECC key for the options. Has no keys inside! It's encrypted with a standard key (in these DHO).
-
Options 70mhz to 100mhz and storage depth can be unlock using SCPI command,which could gnenrate by rigol HDO-tools.
https://gitlab.com/riglol/rigolee/hdo-tools
(string BW7TO10,RLU)
(https://i.ibb.co/G73qfnq/123121212241.jpg) (https://ibb.co/8M4HnNH)
-
Options 70mhz to 100mhz and storage depth can be unlock using SCPI command,which could gnenrate by rigol HDO-tools.
https://gitlab.com/riglol/rigolee/hdo-tools
(string BW7TO10,RLU)
That's nice! Looks like a much cleaner way to enable these options than having to make the scope a pseudo-DHO9x4. Is there also a string to enable 250 MHz bandwidth, by any chance?
-
Options 70mhz to 100mhz and storage depth can be unlock using SCPI command,which could gnenrate by rigol HDO-tools.
https://gitlab.com/riglol/rigolee/hdo-tools
(string BW7TO10,RLU)
That looks like a better way to do it! I'll try it later.
How do you know the possible strings?
-
That's nice! Looks like a much cleaner way to enable these options than having to make the scope a pseudo-DHO9x4. Is there also a string to enable 250 MHz bandwidth, by any chance?
That won't happen. When you want to go above the official options for a certain model, you have to change model.
-
That won't happen. When you want to go above the official options for a certain model, you have to change model.
The bandwidth upgrade is currently enabled as a trial on my DHO804.
With the latest firmware it also says memory depth option.
Maybe 250MHz won't work but I'll give 100Mhz+memory depth a try.
-
Options 70mhz to 100mhz and storage depth can be unlock using SCPI command,which could gnenrate by rigol HDO-tools.
https://gitlab.com/riglol/rigolee/hdo-tools (https://gitlab.com/riglol/rigolee/hdo-tools)
(string BW7TO10,RLU)
That file is hard coded for DHO4000 keys.
I tried modifying it for DHO800 using this post as a guide: https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5067982/#msg5067982 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5067982/#msg5067982)
But I haven't had any luck yet.
-
I've got 50Mpts memory in a DHO800!
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1910013;image)
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1910019;image)
-
I've got 50Mpts memory in a DHO800!
:-+
But where's the 100 MHz bandwidth option?
-
I haven't had any luck generating keys for bandwidth upgrade but it's easy to push the DHO814 vendor.bin. I get about 135MHz measured bandwidth with that (2.6ns rise time).
Theory:
In the last firmware update the trial for "70MHz-100Mhz bandwidth upgrade option" changed to trial for "Storage depth option" (see screen captures). Various people saw this.
So... maybe Rigol is planning a storage upgrade option for the DHO800 and that's why that option works.
:-//
The trick to finding out would be to try a bandwidth upgrade key with 1.00 firmware.
With 1.00 firmware:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1908513;image)
With 1.01 firmware:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1908519;image)
-
Has anyone seen where the options get stored?
In a file called "license.lic" like in some other Rigol equipments or in separate .lic files?
(should be next to Key.data)
-
Has anyone seen where the options get stored?
In a file called "license.lic" like in some other Rigol equipments or in separate .lic files?
(should be next to Key.data)
I've got a new file called "RLU.lic" in /rigol/data:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1910031;image)
The option I installed has code "RLU" so I'm guessing that's where it went.
10MPts per channel with all channels enabled on a DHO800: :)
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1910037;image)
-
FWIW: The RLU.lic file is plain ASCII text with my license key in it. I'm guessing it's no use to anybody else.
-
FWIW: The RLU.lic file is plain ASCII text with my license key in it. I'm guessing it's no use to anybody else.
Can you generate a key for the 70-to-100-MHz upgrade and store it as BW7TO10.lic? Maybe the option is just missing in the UI?
-
I haven't had any luck generating keys for bandwidth upgrade but it's easy to push the DHO814 vendor.bin. I get about 135MHz measured bandwidth with that (2.6ns rise time).
you are still being haunted by anti-aliasing rebel movement do you? ;)
btw i copied all files from rigol folder of ver1.0.0.19 (DHO804 from factory), ver1.1.0.2 (DHO804 legit gel upgrade) and ver1.14 (DHO924 illegit hack) using RigolTool.exe and do files size and binary (data) comparison:
comparing ver1.0.0.19 (DHO804 from factory), ver1.1.0.2 (DHO804 legit gel upgrade), every files are the same except:
\data\cal_afe_bandwidth.hex
\data\cal_vertical.hex
\FPGA\BOOT.bin
comparing the legit copies above (both) with ver1.14 (DHO924 illegit hack), the differences are:
\app\Launcher.apk
\app\Sparrow.apk
\app\Webcontrol.apk
\data\default\cal_vertical.hex
\data\cal_adc.hex
\data\cal_afe_bandwidth.hex
\data\cal_afe_zero.hex
\data\cal_ddr.hex
\data\cal_lsb.hex
\data\cal_vertical.hex
\data\Key.data
\vendor.bin
\FPGA\BOOT.bin
files in DHO924 dont exist in DHO804:
\data\cal_ext.hex
\FPGA\SPU_H12S1.bit
i also did recalibration on each version to see what files are changed in rigol\data:
recalibrating ver1.0.0.19, the following file is changed:
\data\cal_vertical.hex
recalibrating ver1.1.0.2 the following files are changed:
\data\cal_afe_bandwidth.hex
\data\cal_vertical.hex
recalibrating ver1.14 the following files are changed:
\data\cal_adc.hex
\data\cal_afe_bandwidth.hex
\data\cal_afe_zero.hex
\data\cal_vertical.hex
so during calibration, one or more of that files will be changed.
fwiw...
-
How about BW7TO25 BW10TO25...? :)
-
How about BW7TO25 BW10TO25...? :)
They don't exist in the apk file. :)
-
Can you generate a key for the 70-to-100-MHz upgrade and store it as BW7TO10.lic? Maybe the option is just missing in the UI?
Nothing.
-
How about BW7TO25 BW10TO25...? :)
They don't exist in the apk file. :)
Neither is BW7TO10.
-
I haven't had any luck generating keys for bandwidth upgrade but it's easy to push the DHO814 vendor.bin. I get about 135MHz measured bandwidth with that (2.6ns rise time).
you are still being haunted by anti-aliasing rebel movement do you? ;)
It seems to be the fastest I can get and have the self-cal work. 8)
-
I have now also tried this, works....
-
I have now also tried this, works....
:-+
But now I am confused... I thought that, with the bandwidth option removed in the new firmware, a model change to DHO814 (via vendor.bin) is the only way to get 100 MHz bandwidth. So how is yours a DHO804, but nevertheless with 100 MHz? ???
-
I have now also tried this, works....
What code did you use to get 100Mhz bandwidth on an 804?
(And have you measured the bandwidth?)
Can you list /rigol/data to see what files you have in there?
-
Bandwith measuring and check if we really have 50Mpts will follow.
I have changed the rgtool script as it was in the link, removed all "nonsense" options, left RLU and inserted BW7T10.
Then entered the generated keys via the SCPI console.
-
You know what the next question will be, right? :)
Any chance of adding BW7TO25 and BW10TO25 to the script and giving those a try?
-
Can you list /rigol/data to see what files you have in there?
Bandwith is in...
-
Oh -- it's BW7T10, not BW7TO10 as originally stated by nervdg.
That might explain why it didn't work for Fungus.
How did you find the correct spelling?
-
Hi,
already exists in the script...
Edit:
Any chance of adding BW7TO25 and BW10TO25 to the script and giving those a try?
Tried...No. ;)
Makes sense as long as the scope is a 800 model.
-
Checking the bandwith with a sml01 generator and 50ohm external resistor.
Bandwith: Proofed.. ;)
I think I don´t need a further bandwith upgrade.
-
BTW, here is the DC accuracy check results on my DHO804. The voltage source is 7.49844 V.
Stock firmware - 0.25% accuracy:
[attachimg=1]
DHO924 firmware, autocalibrated, offset is close to zero, error is 1.66%. That's awful:
[attachimg=2]
So, not only the DC offset is the issue, but the DC accuracy also!! :bullshit:
-
Bandwith: Proofed.. ;)
Additional, bodnarpulser risetime.
-
Finally, 50Mpts "proofed"...
-
Finally, 50Mpts "proofed"...
Please, help me, I modified rgtools according to the post https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5067982/#msg5067982 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5067982/#msg5067982)
But the scope ignores my SCPI commands. The format is ": SYSTem: OPTion: INSTall DHO800-BW7T10@<96 char key>" ?
Could you share the working script, please.
UPDATE: ": SYSTem: OPTion: INSTall" should be without spaces, and it WORKS!! 8)
-
Me I typed it in this way into the console:
:SYST:OPT:INST DHO800-RLU@XXXXXXXXXXXXXXXXXX
-
Oh -- it's BW7T10, not BW7TO10 as originally stated by nervdg.
That might explain why it didn't work for Fungus.
I think I tried all combinations. Even BW70TO100, etc.
I'll do it again and see... :-//
-
Me I typed it in this way into the console:
:SYST:OPT:INST DHO800-RLU@XXXXXXXXXXXXXXXXXX
I just pushed the "BW7T10.lic" that I generated earlier (same file!) to the 'scope with ADB. I rebooted one last time and it worked! I have no idea why it didn't work before. :-//
My DHO 804 now says 100Mhz and I have 50Mpts memory.
Weirdly enough I seem to have more bandwidth than before, too. Before I had a rise time of 2.6ns (see previous page) and now I have 2.3ns.
Maybe my 'scope just needed a few hours rest from all the hacking attempts. :-DD
Final state:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1910454;image)
-
Checking the bandwith with a sml01 generator and 50ohm external resistor.
Bandwith: Proofed.. ;)
I think I don´t need a further bandwith upgrade.
Yep, I'm staying with this setup, too. It's enough for me. 8)
-
150MHz measured
Take 0.45 in your calculation and you'll get what I've measured before. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5132343/#msg5132343)
-
Really... No one is going to try if BW7T20 works?
P.S. I am still waiting for eBay to release the money of my sold DS1054Z to buy the DHO804 and give it a try :)
-
Really... No one is going to try if BW7T20 works?
Martin has tried upgrading to 250 MHz (the highest bandwidth available in the 900 series) without success. 200 MHz is not a bandwidth Rigol offers anywhere in the 800/900 series. It would be a logical next step after the 814 though; maybe worth a try?
Any chance of adding BW7TO25 and BW10TO25 to the script and giving those a try?
Tried...No. ;)
-
Really... No one is going to try if BW7T20 works?
Martin has tried upgrading to 250 MHz (the highest bandwidth available in the 900 series) without success. 200 MHz is not a bandwidth Rigol offers anywhere in the 800/900 series. It would be a logical next step after the 814 though; maybe worth a try?
Any chance of adding BW7TO25 and BW10TO25 to the script and giving those a try?
Tried...No. ;)
I haven't seen anyone try it without O
BW7T20
-
I am pretty sure both Martin and Fungus did, based on the pre-existing entries in the script. It was just on this thread that the original post mentioning this upgrade approach mis-spelled it as "TO".
-
Did some APK unpacking and greping, here is what I found as possible options:
grep -r BW7T1 *
Binary file classes2.dex matches
Binary file lib/arm64-v8a/libscope-auklet.so matches
xxd lib/arm64-v8a/libscope-auklet.so | grep -A 3 BW7
00a39090: 424e 4400 4257 3754 3130 0045 4d42 4400 BND.BW7T10.EMBD.
00a390a0: 434f 4d50 0042 5731 3554 3235 0041 5554 COMP.BW15T25.AUT
00a390b0: 4f00 424f 4445 0042 5737 5432 3000 4257 O.BODE.BW7T20.BW
00a390c0: 3130 5432 3000 524c 5500 4257 3254 3400 10T20.RLU.BW2T4.
00a390d0: 4257 3254 3800 4257 3454 3800 4145 524f BW2T8.BW4T8.AERO
00a390e0: 0046 4c45 5800 4155 4449 4f00 2e6c 6963 .FLEX.AUDIO..lic
-
I haven't seen anyone try it without O
BW7T20
It doesn't work.
-
Did some APK unpacking and greping
I confirm this text fields in 7 apk files on my DHO804 original firmware:
OPT_AERO OPT_ARINC OPT_AUDIO OPT_AUTO OPT_BND OPT_BODE OPT_BW10T20 OPT_BW15T25 OPT_BW2T4 OPT_BW2T8 OPT_BW4T8 OPT_BW7T10 OPT_BW7T15 OPT_BW7T20 OPT_CM_ENET OPT_CM_HDMI OPT_CM_MIPI OPT_CM_USB OPT_COMP OPT_COUNT OPT_DG OPT_EMBD OPT_EYE OPT_FLEX OPT_JITTER OPT_MSO OPT_PWR OPT_RLU OPT_RTSA OPT_UNKNOWN OPT_UPA
These apk files are different copies of base.apk and Sparrow.apk.
Strings near by: "Unknown Forever days Key.data HDO800 HDO900 DHO800 DHO900"
-
150MHz measured bandwidth:
Did you try OPT_BW7T15 OPT_BW7T20?
-
Take 0.45 in your calculation and you'll get what I've measured
Did you try BW7T15 BW7T20?
-
I tried BW10T25, but nevertheless, the measured bandwith is 200Mhz (0.707) with BW7T10
-
Did some APK unpacking and greping
I confirm this text fields in 7 apk files on my DHO804 original firmware:
OPT_AERO OPT_ARINC OPT_AUDIO OPT_AUTO OPT_BND OPT_BODE OPT_BW10T20 OPT_BW15T25 OPT_BW2T4 OPT_BW2T8 OPT_BW4T8 OPT_BW7T10 OPT_BW7T15 OPT_BW7T20 OPT_CM_ENET OPT_CM_HDMI OPT_CM_MIPI OPT_CM_USB OPT_COMP OPT_COUNT OPT_DG OPT_EMBD OPT_EYE OPT_FLEX OPT_JITTER OPT_MSO OPT_PWR OPT_RLU OPT_RTSA OPT_UNKNOWN OPT_UPA
These apk files are different copies of base.apk and Sparrow.apk.
Strings near by: "Unknown Forever days Key.data HDO800 HDO900 DHO800 DHO900"
I think those files have every string for every Rigol 'scope ever made in them. :)
-
150MHz measured
Take 0.45 in your calculation and you'll get what I've measured before. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5132343/#msg5132343)
OK, I'm old fashioned. Apparently it's changed to 0.45 (https://www.tek.com/en/support/faqs/how-bandwidth-related-rise-time-oscilloscopes)
My little AWG doesn't go that high but if you have 0.707 amplitude at 200MHz and we both have the same rise time....
... it's time open the "200MHz" bottle and have a party. :)
-
Just a note that VirusTotal is currently showing 25/72 "detections" for RigolTool.exe: https://www.virustotal.com/gui/file/436c4795ddb4fd5edfeba5e2bf904811f7f0d061c43b99f9578b01dac3e49eb2/detection (https://www.virustotal.com/gui/file/436c4795ddb4fd5edfeba5e2bf904811f7f0d061c43b99f9578b01dac3e49eb2/detection)
-
All your really need to hack it is upload three files with adb.
I want to test if you can use any key file on any 'scope. I think you should be able to.
If so we can just make a zip file with adb.exe and key/license files in it. That's all you need to hack a DHO800.
-
You can't because the S/N is used in the licenses. Unless everybody is using the same S/N... ;)
-
You can't because the S/N is used in the licenses. Unless everybody is using the same S/N... ;)
Key.data has to be derived from the S/N otherwise Rigol wouldn't be able to generate licenses for you based on your S/N.
The question is: Does it have to match the S/N when the 'scope is checking the license files?
I don't think it does because I can change my vendor.bin and I still have 50M memory.
eg. Here's my 'scope with the DHO814 vendor.bin that's floating around:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1910826;image)
So what's the point of Key.data? I'm not sure... they could easily use the S/N to encrypt the license files instead. :-//
I want to try making a Key.data with a random number in it and generate some license files for that. If it works then we can just pass three files around for everybody to use instead of getting people to pull their key, generate licenses from it, etc.
-
Key.data has to be derived from the S/N otherwise Rigol wouldn't be able to generate licenses for you based on your S/N.
The question is: Does it have to match the S/N when the 'scope is checking the license files?
[...]
I want to try making a Key.data with a random number in it and generate some license files for that. If it works then we can just pass three files around for everybody to use instead of getting people to pull their key, generate licenses from it, etc.
While this might work, it would give Rigol the option (via a future firmware update) to invalidate licenses generated with a non-matching key. Nobody knows whether Rigol will ever be inclined to do that, but I would prefer to stick with licenses and keys which are indistinguishable from the official ones.
-
Key.data has to be derived from the S/N otherwise Rigol wouldn't be able to generate licenses for you based on your S/N.
The question is: Does it have to match the S/N when the 'scope is checking the license files?
[...]
I want to try making a Key.data with a random number in it and generate some license files for that. If it works then we can just pass three files around for everybody to use instead of getting people to pull their key, generate licenses from it, etc.
While this might work, it would give Rigol the option (via a future firmware update) to invalidate licenses generated with a non-matching key. Nobody knows whether Rigol will ever be inclined to do that, but I would prefer to stick with licenses and keys which are indistinguishable from the official ones.
Maybe...
In that case we need to know how to derive Key.data from the scope's serial number. That way all we need is the S/N to generate keys that can be entered via the scope's web interface.
I wonder if Riglol does that.
-
Deriving the key from the SN would be a weakness - hacking one scope means hacking all of them. Having a random generated key associated with every serial number upon initializing when manufacturing is much safer. So I guess Rigol have a look up table associating serial number with the key. That is how they can generate the license based on a serial number eventually. Upper is based on assuming the key is secretly stored. In theory it is, because it's encrypted, in fact it's not because the key for encryption is well known.
Bottom line, this should mean, that the Fungus' idea of just passing three files should work...
-
Did some APK unpacking and greping
I confirm this text fields in 7 apk files on my DHO804 original firmware:
OPT_AERO OPT_ARINC OPT_AUDIO OPT_AUTO OPT_BND OPT_BODE OPT_BW10T20 OPT_BW15T25 OPT_BW2T4 OPT_BW2T8 OPT_BW4T8 OPT_BW7T10 OPT_BW7T15 OPT_BW7T20 OPT_CM_ENET OPT_CM_HDMI OPT_CM_MIPI OPT_CM_USB OPT_COMP OPT_COUNT OPT_DG OPT_EMBD OPT_EYE OPT_FLEX OPT_JITTER OPT_MSO OPT_PWR OPT_RLU OPT_RTSA OPT_UNKNOWN OPT_UPA
These apk files are different copies of base.apk and Sparrow.apk.
Strings near by: "Unknown Forever days Key.data HDO800 HDO900 DHO800 DHO900"
I think those files have every string for every Rigol 'scope ever made in them. :)
Exactly.
It is the whole bundle of all evtl options for this software platform.
Which of these can then actually become active depends on the respective hardware.
For example, jitter and eye diagram are of course complete utopia, even for the DHO4000 scopes. ;)
We have already brought out the "absolute" with the bandwidth upgrade to 100Mhz and the memory expansion to 50Mpts.
More is not possible....for the 800 model.
If we told the 800 it was now a 900, we would add the 250Mhz max bandwidth at 2ns/div.
And that's it, or until rigol introduces new options that you can unlock.
Because they have to be there, anyone can try them out and generate and enter license keys for the other decoders for example, nothing will happen because they don't exist for either the 800 or the 900.
-
How to use a larger memory card (64GB tested).
1) copy byte to byte oscilloscope's SD-card to the start of a new 64GB card;
2) analyze and undelete 4 biggest ext4 partitions with partition manager software (tested with Paragon Hard Disk Manager; it's a MBR volume, so you can chooze only 4)
3) resize the last 26GB partition to the end of free space (Done with GParted from Linux. No Windows software is found to be able to do this. Paragon Disk Manager, EaseUS, AOMEI Partition Assistant failed at resizing the partition.)
If you find a Windows app that can resize the partition on the card, please, let me know.
My stock memory card is Lexar 633x SDHC-I V10 U1 A1 29.5 GB (31,719,424,000 bytes)
PS: it's done because I have a spare 64GB card, not for the extra space 8).
[attachimg=1]
-
Is anyone willing to share their key.data file? Or has one been attached to post already? Looking at libscope-auklet.so inside sparrow apk, there are two references where it looks like it's reading licensing information near start of each function.
CApiLicense::ApiLicense_SetLicenseKey(CApiLicense *, __int64)
CApiLicense::getLicenseKey(__int64 a1, RString *a2, size_t *a3)
> sub_256818(&CApiLicense::LICENSE_PATH, "Key.data"); # I think this function just reads data from the device
In both license related functions, it looks like it reads the data from key.data near start of code then processes it. Would be helpful to see some actual data to understand what is going on.
Also, it is likely worthwhile to dig into the "opt" related functions as part of CAPiLicense class in that same .so file. This might help with analysis of how things are handled.
For example, I believe this is checking whether license is valid for bandwidth:
[attachimg=1]
-
Is anyone willing to share their key.data file?
Here is the key from DHO924 firmware from the first post of this thread.
-
I wonder if BW10T20 could upgrade a DGO814 from 100 to 200 MHz.
I have also noticed that BW7T10.lic is not encrypted. Maybe we can enable some of the other licenses by writing them directly to /rigol/data.
-
DHO 800 : 70 Mhz/100Mhz
DHO 900 : 125Mhz/250Mhz
DHO 1000: 70Mhz/100Mhz/200Mhz
DHO 4000: 200Mhz/400Mhz/800Mhz
Hope that helps.
-
Looking at libscope-auklet.so inside sparrow apk...
What are you using to look at that??
I've been poking around the apk and all the interesting stuff is in the .so file but I don't know what to use on it.
-
The .so files are arm compiled libraries. You need something like IDA or Ghidra.
-
The .so files are arm compiled libraries.
I know that much! :)
You need something like IDA or Ghidra.
So you're using "IDA"...
-
You need something like IDA or Ghidra.
So you're using "IDA"...
But the free version doesn't do ARM. >:(
-
Can anyone give an overview over the H/W variants of the 800/900 series scopes? E.g. which ones do have hardware capabilites preinstalled for the AWG and stuff like that.
Are all DHO900 series scopes identical hardware-wise, since all of them have the LA connector preinstalled as well as the AWG output at the back? I'd like to avoid having to cut into the case, so I'd go for the DHO914 in that case, as long as all the DHO924S features can be hacked software-wise.
In brief, the motherboard of all the 800/900 series are the same, just the 800 series is missing a few components.
All the 900 series have the LA connector on the front, while the 800 series don't have that connector soldered on the motherboard.
Only the 914S/924S models have the AFG module hardware inside, the 914/924 don't (at least that is my assumption).
The DHO924/DHO924S come with 350MHz probe, but the 914 and 800 series come with 150MHz probes.
If one's just missing a few components does this mean you could, with a bit of skill and some parts, convert the 800 to the 900? You'd need a FW image as well, of course.
Thanks!
-
If one's just missing a few components does this mean you could, with a bit of skill and some parts, convert the 800 to the 900?
Yes.
You'd need a FW image as well, of course.
That's the easy part.
-
Is anyone willing to share their key.data file? Or has one been attached to post already? Looking at libscope-auklet.so inside sparrow apk, there are two references where it looks like it's reading licensing information near start of each function.
CApiLicense::ApiLicense_SetLicenseKey(CApiLicense *, __int64)
CApiLicense::getLicenseKey(__int64 a1, RString *a2, size_t *a3)
> sub_256818(&CApiLicense::LICENSE_PATH, "Key.data"); # I think this function just reads data from the device
In both license related functions, it looks like it reads the data from key.data near start of code then processes it. Would be helpful to see some actual data to understand what is going on.
Also, it is likely worthwhile to dig into the "opt" related functions as part of CAPiLicense class in that same .so file. This might help with analysis of how things are handled.
For example, I believe this is checking whether license is valid for bandwidth:
I don't understand what's going on and why do I need to do this? Doesn't the Rigoltool I provided earlier help you liberate bandwidth? Or something else happened that I didn't know.
-
If one's just missing a few components does this mean you could, with a bit of skill and some parts, convert the 800 to the 900?
Besides soldering skills, you would also have to be good with a Dremel to cut the LA port into the front. I don't see many people doing that to their cute new scope...
Oh, and there are two extra buttons on the DHO900 too. Happy tinkering! ::)
-
I've checked BW7T15, BW7T20, and BW7T25 options installation on my DHO804, but no luck.
The BW7T10 and RLU options work fine.
So now I'm using 100MHz (? 2.1ns rize time = 166MHz bw) 50Mpts 64GB memory oscilloscope. 8)
It's time to calibrate the DHO924 firmware!...
-
I don't understand what's going on and why do I need to do this? Doesn't the Rigoltool I provided earlier help you liberate bandwidth? Or something else happened that I didn't know.
They are peer reviewing... :-DD
-
I don't understand what's going on and why do I need to do this? Doesn't the Rigoltool I provided earlier help you liberate bandwidth? Or something else happened that I didn't know.
They are peer reviewing... :-DD
I think there are still two worthwhile directions for improving the hackability or making it more convenient:
(a) Make the DHO hackable just via the GUI, similar to e.g. the DS1000Z series: Provide an online generator for license keys which requires just the serial number as an input, not the device key. This will only work if the key is derived from the serial number, rather than generated independently and kept in a global serial > key lookup table by Rigol.
(b) Enable the activation of DHO900 bandwidth and decoders without causing calibration problems or loss of the serial number, and without activating the redundant display of the digital channels on the screen.
-
Gentlemen, the Key.data was created in the MSO days as an ECC public key destined to verify the option licenses. AFAIR, in this DHO world, the key is being used as a symmetric key (lo and behold :palm: :palm: |O) to encrypt/decrypt the licenses.
If this is the case, you don't need to know from where it was generated, you just need to use Key.data and create all the licenses based on it and spread joy all over (together with the key).
It's totally irrelevant what was the seed of the Key and you can overwrite it with no problems. People doing this will never buy official licenses from Rigol so their original key is useless.
-
If this is the case, you don't need to know from where it was generated, you just need to use Key.data and create all the licenses based on it and spread joy all over (together with the key).
It's totally irrelevant what was the seed of the Key and you can overwrite it with no problems. People doing this will never buy official licenses from Rigol so their original key is useless.
But if (!) there is an algorithmic way to check whether the key.data is consistent with the serial number, Rigol could do that in a future firmware and disable "homemade" licenses -- right?
-
If one's just missing a few components does this mean you could, with a bit of skill and some parts, convert the 800 to the 900?
Besides soldering skills, you would also have to be good with a Dremel to cut the LA port into the front. I don't see many people doing that to their cute new scope...
Oh, and there are two extra buttons on the DHO900 too. Happy tinkering! ::)
If I know really DHO804 will work LA. I will cut the panel for the connector on the new oscilloscope. And the buttons do not need to be cut, there is a touch screen and LA can be activated from the screen. In my country, 200 euros is a lot of money.
-
It's totally irrelevant what was the seed of the Key and you can overwrite it with no problems. People doing this will never buy official licenses from Rigol so their original key is useless.
Yep, that's what I was thinking.
But if (!) there is an algorithmic way to check whether the key.data is consistent with the serial number, Rigol could do that in a future firmware and disable "homemade" licenses -- right?
They could do that but I really don't believe they will.
-
Rigol could do that in a future firmware and disable "homemade" licenses -- right?
We're talking about a system that started as ECC and now is being used as symmetric... :palm: They could but they won't as they never did. In the past, no Rigol scope has ever complained about having its key changed.
-
If I know really DHO804 will work LA. I will cut the panel for the connector on the new oscilloscope. And the buttons do not need to be cut, there is a touch screen and LA can be activated from the screen. In my country, 200 euros is a lot of money.
I have been thinking about making a small pin header to FPC cable adapter board and use a couple of MIPI camera cables to bring the LA pins out of the case without cutting anything.
-
Also, as @souldevelop has shown in this thread's beginning, the FW has some "hdcode" bits checking. So, only changing the model in vendor.bin might not be enough to complete the model change. One would have to patch the FW (all of them in the future)! Just saying because I don't remember having read any development in this area saying that this is not a problem.
-
Yes, and the appearance of the offset error after a DHO800 to 900 "conversion" via vendor.bin is not understood or resolved yet.
-
Yes, and the appearance of the offset error after a DHO800 to 900 "conversion" via vendor.bin is not understood or resolved yet.
With RIGOL TOOL, you don't need to worry about new problems brought by firmware upgrades of any version, no offset error ,no other error , no app anit-check which is currently the perfect solution.
Replacing the vendor .bin of another model of device directly will result in offset error, because the vendor .bin has serial number and model information, so you must have the ability to unlock the vendor's .bin to solve some other problems such as offset error. XXXX.apk running on the device checks the vendor's .bin and adjusts the way it calibrates based on what's inside, and what I know is not speculation, it's a credit to IDA.
-
But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?
-
But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?
It's been measured at 200MHz with the "100Mhz" hack applied. :)
If you really need the decoders then just turn it into a 924. A few mV offset on one of the channels isn't going to affect decoding.
-
But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?
The DHO800 can be modified to DHO900 200MHz by rigoltool.
Because it is done by directly modifying the vendor.bin device information file, no additional OPT license is required, and a certain series model already comes with the corresponding option function by default.
-
Also, as @souldevelop has shown in this thread's beginning, the FW has some "hdcode" bits checking. So, only changing the model in vendor.bin might not be enough to complete the model change. One would have to patch the FW (all of them in the future)! Just saying because I don't remember having read any development in this area saying that this is not a problem.
No apps.apk have been found to check HDCODE. ^-^
-
But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?
The DHO800 can be modified to DHO900 200MHz by rigoltool.
Because it is done by directly modifying the vendor.bin device information file, no additional OPT license is required, and a certain series model already comes with the corresponding option function by default.
your tool still cannot solve offset issue, and it does not allow me to upgrade to DHO924S (it warned me that my model doesnt support FG feature how clever the program is ;)) what do i miss? https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126331/#msg5126331 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126331/#msg5126331)
there's 3rd branch of the hack (1st is v1.14 DHO924S, 2nd is your rigol tool) https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5131482/#msg5131482 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5131482/#msg5131482) i'm not sure if it can fix the issue
-
But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?
The DHO800 can be modified to DHO900 200MHz by rigoltool.
Because it is done by directly modifying the vendor.bin device information file, no additional OPT license is required, and a certain series model already comes with the corresponding option function by default.
your tool still cannot solve offset issue, what do i miss? https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126331/#msg5126331 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126331/#msg5126331)
xu
there's 3rd branch of the hack (1st is v1.14 DHO924, 2nd is your rigol tool) https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5131482/#msg5131482 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5131482/#msg5131482)
After the modification is complete, it needs to be calibrated from scratch.
-
After the modification is complete, it needs to be calibrated from scratch.
i did..
-
After the modification is complete, it needs to be calibrated from scratch.
i did..
Do you guys mean running a self-cal, or something that goes beyond that?
-
After the modification is complete, it needs to be calibrated from scratch.
i did..
Can you take a screenshot of your firmware version page and what is the deviation of offset error?
-
IMHO, the hackability of their products is main part of Rigol's marketing strategy, so I do not expect making hacking harder with FW updates.
-
Can you take a screenshot of your firmware version page and what is the deviation of offset error?
Here's a screenshot by Martin72. He did run into the offset problem, and self-cal could not fix it: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5128053/#msg5128053. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5128053/#msg5128053.) -- Edit: Reply #139, dunno why I can't link to the right post.
Fungus did not have an offset issue though: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126985/#msg5126985. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126985/#msg5126985.) -- Edit: Reply #119.
They both had replaced the vendor.bin with the one from hubertyoung. But that should not make a difference for the offset issue compared to your approach, right? It seems to be unit-specific whether a model change causes the offset problem. (And also a problem with the DC accuracy, as demonstrated by serg65536 in reply #200.)
-
After the modification is complete, it needs to be calibrated from scratch.
The calibration fails.
-
But you cannot get beyond 100 MHz on the DHO800, and can't get the extra decoders, right?
It's been measured at 200MHz with the "100Mhz" hack applied. :)
If you really need the decoders then just turn it into a 924. A few mV offset on one of the channels isn't going to affect decoding.
The extra decoders are needing the LA, they're parallel decoders.
-
The extra decoders are needing the LA, they're parallel decoders.
CAN and LIN??
-
My fault, overlooked in the datasheet the sources ch1-ch4 on both.... :P
-
After the modification is complete, it needs to be calibrated from scratch.
The calibration fails.
My God, how can this be..... |O
-
My fault, overlooked in the datasheet the sources ch1-ch4 on both [CAN and LIN].... :P
It's just one or two wires after all. But both protocols have long been used as a differentiator for the better oscilloscopes, or as a chargeable option.
I find it interesting that Rigol still makes hacking easy withing the limited range of DHO800 options, but has moved several options "out of reach" by declaring the DHO900 to be a different product line. The total opposite of what they did in the MSO5000 range! Maybe someone decided that the hacking was getting out of hand and hurting revenue too much -- so they wanted to preserve some of it, to keep the hobbyists interested, but put tighter constraints on it.
-
The extra decoders are needing the LA, they're parallel decoders.
LIN bus is 1 wire, CAN bus is two.
-
After the modification is complete, it needs to be calibrated from scratch.
i did..
Do you guys mean running a self-cal, or something that goes beyond that?
i mean self-cal from dso menu. iirc i tried both in testmode on and in testmode off...
After the modification is complete, it needs to be calibrated from scratch.
The calibration fails.
My God, how can this be..... |O
iirc if we enable adc gain or phase (self-cal in testmode on), calibration will fail, but if we just do normal self-cal (testmode off), calibration succeeded, but there are offsets everywhere on all channels. and the worst is, if i feed signal to channel input, there is no signal at all on the display. i tried both FW v0.1.0.0.9 and v0.1.1.0.2 using your tool but no success, i wish it to be success because i can use the latest FW revision from rigol, but i have to use image of DHO924 FWv1.14 from hubertyoung now. self-cal works ok.
-
After the modification is complete, it needs to be calibrated from scratch.
i did..
Can you take a screenshot of your firmware version page and what is the deviation of offset error?
sorry i didnt save the screenshots, my DHO804 now running hubertyoung image, try doing all again from v1.0.0.9 will take hours.
since at it, you all DHO900 owners (@souldevelop and @hubertyoung and @others) can help us identify components labelled a,b,c,d,e in attachment? they are unpopulated in DHO800. i'm guessing a is MPPY 3630 280, similar to adjacent ICs, not sure what it does, cant even find datasheet for it. thank you.
-
After the modification is complete, it needs to be calibrated from scratch.
i did..
Can you take a screenshot of your firmware version page and what is the deviation of offset error?
or maybe i forgot to power cycle the dso after using rigol tool? i cant remember.
-
i mean self-cal from dso menu. iirc i tried both in testmode on and in testmode off...
Yep. I tried all the options and always had an offset on channel 3.
Maybe we need to copy some ".cal" files from the 924 image to make it work, I don't know for sure. See my theory below... :popcorn:
At this point I don't really care. All I really wanted for my DHO804 was the extra memory and a decent bandwidth. I have both of those now and no useless on-screen junk from the 900-series LA.
The only missing thing is the extra 200uV/div range of the DHO900 but I can easily live without that.
Theory: The extra 200uV/div range might be the reason the DHO800's cal files don't work with a DHO900's vendor.bin.
-
Maybe we need to copy some ".cal" files from the 924 image to make it work, I don't know for sure. See my theory below... :popcorn:
...
Theory: The extra 200uV/div range might be the reason the DHO800's cal files don't work with a DHO900's vendor.bin.
i reported earlier, DHO924 has extra files in data folder.. they are \data\cal_ext.hex and \FPGA\SPU_H12S1.bit not sure what they do, as you said, i got what i want..
...and no useless on-screen junk from the 900-series LA.
do you want 36 pages dick waving contest on this? rigol fanboy vs rigol fanboy... ;D if i have time, i'll explore AFG and Bode plot feature, or even LA feature if i really get nasty.
The only missing thing is the extra 200uV/div range of the DHO900 but I can easily live without that.
another thing to note is when changing time scale from 2ns/div to 5ns/div, sometime on larger scale 10 to 20ns/div iirc, there is 1-2 seconds delay until the signal is updated again in DHO924 FW v 1.14, a bit annoying but i can tolerate for the sake of increased (aliased) BW... this doesnt happen in DHO804 legit FW.
-
....i can tolerate for the sake of increased (aliased) BW... this doesnt happen in DHO804 legit FW.
Try copying all the 924's cal files to your 'scope. See if it fixes it.
-
The only missing thing is the extra 200uV/div range of the DHO900 but I can easily live without that.
I can do without anything that is artificially zoomed in.
-
The only missing thing is the extra 200uV/div range of the DHO900 but I can easily live without that.
I can do without anything that is artificially zoomed in.
I've been wondering what "artificially zoomed" means, actually, for a 12 bit ADC and a screen with 600 vertical pixels total, and 400 or so available for the traces.
So they only map about 1/3 of the full ADC range to the full vertical screen range. But that still leaves 3 or 4 ADC digits per vertical screen pixel. Combined with the small size of the screen, what's wrong with a zoomed-in view to show the detail?
-
From the DHO900 datasheet.
[4]: 200 μV/div and 500 μV/div is a magnification of 1 mV/div setting. For vertical accuracy calculations, use full scale of 8 mV.
-
You can use a SD card copy from another scope of the same model on your scope with high precision.
Calibration is not secretly stored in the firmware, it's in the /rigol/data/*cal files.
Today I've flashed non original V1.14 (it's probably the oldest firmware available) to my DHO804:
1) There was initially a huge zero offset.
2) Zero offset could be eliminated with autocalibration (default mode: 1M + all ch)
3) The resulting DC precision if awful
After pushing the original cal files to the scope:
4) There was an offset initially,
5) but it's eliminated with autocalibration (default mode: 1M + all ch)
6) The resulting DC precision is perfect
7) You can update non original 1.14 to 1.01 with no issues
-
From the DHO900 datasheet.
[4]: 200 μV/div and 500 μV/div is a magnification of 1 mV/div setting. For vertical accuracy calculations, use full scale of 8 mV.
So at 200 μV/div it's approx. the bit per pixel.
-
From the DHO900 datasheet.
[4]: 200 μV/div and 500 μV/div is a magnification of 1 mV/div setting. For vertical accuracy calculations, use full scale of 8 mV.
So... that scale doesn't have a calibration?
There goes my theory. :-DD
-
To calibrate DHO924 firmware on DHO804 scope we need to place initial calibration values into the calibration files of the 924 firmware.
That's probably:
- vertical sensitivity and zero offset of the input amp for each volt per div value. That's a 15 * 2 = 30 numbers.
- vertical sensitivity and zero offset for the offset voltage source for each of the offset ranges. That's 4 * 2 = 8 numbers.
As far as I can tell, this would be much easier, than changing the vertical compensation algorithm back to DHO800 mode, to use original calibration files.
-
Total newb here (Hi!), but I've been following all the discussions here since I found Dave's DHO800 videos over the weekend. The DHO804 looks like a perfect beginner scope for me. Following the threads has been a task, but let me see if I got this right:
Option 1: You can swap in the DHO914 Vendor.bin (and maybe other stuff on the SD card?) to get many options, but that frequently screws up calibration, right?
Option 2: Use hdo_tools to grab your Key.data file, generate your option strings with the BW7T10 and RLU options, then punch them into the DHO804 scope's web interface, get up to 200MHz bandwidth and some options, but calibration is not affected?
Or am I still mixed up on all this? Thanks in advance, and let me know what I might not be getting right here.
-
Total newb here (Hi!), but I've been following all the discussions here since I found Dave's DHO800 videos over the weekend. The DHO804 looks like a perfect beginner scope for me. Following the threads has been a task, but let me see if I got this right:
Option 1: You can swap in the DHO914 Vendor.bin (and maybe other stuff on the SD card?) to get many options, but that frequently screws up calibration, right?
Yes.
nb. The calibration thing is still being worked on and may be solved in the next few days. We only got the other hacks working yesterday.
Option 2: Use hdo_tools to grab your Key.data file, generate your option strings with the BW7T10 and RLU options, then punch them into the DHO804 scope's web interface, get up to 200MHz bandwidth and some options, but calibration is not affected?
200Mhz measured bandwidth and 50MPts memory
(which is 10x more memory with all 4 channels enabled!)
I did it all manually using ADB but that's just me. I like to understand the process.
Important point: Buy with 100% confidence that it can be done.
-
Option 1: You can swap in the DHO914 Vendor.bin (and maybe other stuff on the SD card?) to get many options, but that frequently screws up calibration, right?
Option 2: Use hdo_tools to grab your Key.data file, generate your option strings with the BW7T10 and RLU options, then punch them into the DHO804 scope's web interface, get up to 200MHz bandwidth and some options, but calibration is not affected?
Option 2 is the only choice for now. You save the scope's accuracy and it's 100% ready for future firmware updates.
Option 1 does not allow to do calibration. It has low voltage accuracy and could be blocked in future updates.
-
7) You can update non original 1.14 to 1.01 with no issues
why people only showing the result but not how? do you mean we can run with v1.01, and then copy the DHO924S' vendor.bin and then we get DHO924 running v1.01 FW and no issue with calibration offset? how? iirc i tried that and no success...
-
There must be a non-volatile memory in the scope!
I flashed the memory card with a fresh copy of 924 firmware, because waveform fluffiness appeared. But vertical and horizontal settings were preserved on the first boot (even the vernier was active). And, guess what? The fluffy waveforms are there again.
The first fresh installation of exactly the same firmware copy worked fine initially.
Network settings are preserved also.
This works if you don't change the firmware type. Probably because this constant memory is used differently by different software versions.
-
7) You can update non original 1.14 to 1.01 with no issues
why people only showing the result but not how? do you mean we can run with v1.01, and then copy the DHO924S' vendor.bin and then we get DHO924 running v1.01 FW and no issue with calibration offset? how? iirc i tried that and no success...
I think maybe you need to copy the entire 1.14 SD card image, complete with .cal files.
-
There must be a non-volatile memory in the scope!
There's an FRAM chip to store the current settings every time you change them.
-
7) You can update non original 1.14 to 1.01 with no issues
why people only showing the result but not how? do you mean we can run with v1.01, and then copy the DHO924S' vendor.bin and then we get DHO924 running v1.01 FW and no issue with calibration offset? how? iirc i tried that and no success...
V1.14 is some early software, the V1.01 from official site - is the latest.
I mean you can flash your scope with DHO924S firmware from the first message of this thread, update it to the V1.01 software and "enjoy" low accuracy and high offset voltage, as you would on initial V1.14 software.
-
Option 2 is the only choice for now. You save the scope's accuracy and it's 100% ready for future firmware updates.
It depends on what you want to achieve.
If you want maximum bandwidth with 5V signals then what's a few millivolts of offset? It's completely irrelevant.
You might want CAN/LIN bus decoding and you need a DHO900 for that.
(A few millivolts offset won't matter for that either... :popcorn: )
PS: I think most people only had problems on one channel. My problem was channel 3, all my other channels were perfect.
-
Thanks for the replies, Fungus and Serg65536. It's very impressive how quickly these hacks have developed. Some seriously talented folks here, for sure. Kudos to all! I'll keep reading just because it's damn fun to watch this unfold.
-
V1.14 is some early software, the V1.01 from official site - is the latest.
Typical Rigol firmware version control sloppiness.
-
7) You can update non original 1.14 to 1.01 with no issues
why people only showing the result but not how? do you mean we can run with v1.01, and then copy the DHO924S' vendor.bin and then we get DHO924 running v1.01 FW and no issue with calibration offset? how? iirc i tried that and no success...
V1.14 is some early software, the V1.01 from official site - is the latest.
I mean you can flash your scope with DHO924S firmware from the first message of this thread, update it to the V1.01 software and "enjoy" low accuracy and high offset voltage, as you would on initial V1.14 software.
i see now. you mean using the legit gel file v1.01 from rigol site, upgrade the "hacked to" DHO924 scope using rigol recommended method ie usb drive upgrade right? thanks.
wait a minute, but V1.01 is only upgrade a few files https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5132049/#msg5132049 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5132049/#msg5132049) this means, even if upgrade to v1.01 gel, we still using old v1.14 sparrow.apk... fyi.. i'll try later and see if sparrow.apk got updated too..
-
I'll try later and see if sparrow.apk got updated too..
Sparrow will definitely be updated in 1.01 because some things changed in the UI.
(eg. location of probe attenuation setting)
-
How can you actually read a bin. file ?
That would interest me.
-
How can you actually read a bin. file ?
That would interest me.
Use Siglent BIN to CSV utility.
-
Reading a BIN
Any old hex editor will work. Just do a search.
-
How can you actually read a bin. file ?
That would interest me.
You mean vendor.bin?
It has binary data in it. You can see it using something like HxD (on windows) to see it in hexadecimal/ASCII.
It's encrypted though so you won't see much. :)
-
Is anyone willing to share their key.data file? Or has one been attached to post already? Looking at libscope-auklet.so inside sparrow apk, there are two references where it looks
How do you get such a nice function names? I'm trying to load the sparrow.apk with IDA Pro 7.7.220118 (last unlocked version), but no pseudocode (F5) is available.
-
APK is zip archive, unzip it first.
-
How can you actually read a bin. file ?
That would interest me.
You mean vendor.bin?
It has binary data in it. You can see it using something like HxD (on windows) to see it in hexadecimal/ASCII.
It's encrypted though so you won't see much. :)
i downloaded the so called decrypted vendor.bin i still dont see much with hex editor... so i dont know whats the deal with xxtea encryt/decryption.
APK is zip archive, unzip it first.
more specifically... classes.dex right?
-
How can you actually read a bin. file ?
That would interest me.
A .bin file can be read with any hexadecimal (or binary) editor, like HxD. BUT, unless you know or are able to recognize what's inside that specific .bin file, usually a .bin file has a data structure format that's is gibberish for an (untrained) human eye.
So, a .bin file can have practically endless format combinations.
-
There's an FRAM chip to store the current settings every time you change them.
Usually (since MSO5k) that FRAM has also been used to store the vendor.bin, Key.data and licenses. From preliminary analysis of the DHO behavior done by others (I've not verified this), I would say that it seems the DHO doesn't work exactly the same (and if so, I can only attribute to programmer's laziness, sloppiness or pure lack of knowledge) as people have been able to change things just by replacing files.
-
APK is zip archive, unzip it first.
IDA is smart enough to do it automatically, it finds the entry point and does analysis, but the result is poorly readable.
-
i downloaded the so called decrypted vendor.bin i still dont see much with hex editor... so i dont know whats the deal with xxtea encryt/decryption.
Encrypted files are random from the point of simple analysis.
Successful decryption gives meaningful content: zero sequences in this case. It's extremely low probability to have such data in random sequence.
That's the sign of successful decryption.
-
i downloaded the so called decrypted vendor.bin i still dont see much with hex editor...
Ah, the untrained eye...
I lost track of the post with that decrypted file but it was definitely decrypted/correct.
-
I lost track of the post with that decrypted file but it was definitely decrypted/correct.
:palm: It's in the 1st page.
-
I just received my DHO914S Scope. I wanted to get the least expensive model that had both the logic analyzer and the AWG hardware, hoping to be able to unlock the 250 MHz bandwidth.
I modified the rgtool.go script to use with the DHO900 but never found the bandwidth license. Next I installed the 924 vendor.bin file, and although it enabled the 250 MHz bandwidth, it also disabled the AWG and the associated Bode plot option.
What is the best course of action for me to enable everything on this scope? Is there a DHO 924S vendor.bin file available, or preferably a known working rgtool.go for the DHO900?
Thanks,
Stan
-
I lost track of the post with that decrypted file but it was definitely decrypted/correct.
:palm: It's in the 1st page.
Oh, yeah, duh!
Here's the hex dump of the decrypted file as shown in HxD:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1913409;image)
First up: You can see a lot of zeros, that's a good sign of correct decryption.
Here's the analysis:
00000000 File CRC32: A2A69654 [00000008-000000D3] CRC OK
00000004 File Length: 204 Size OK
-----------------------------------------------------------
00000008 NameSize: 4
0000000C Name: E_CFG_MODEL_RAW
00000010 FieldSize: 56
00000014 CRC32: 0ADE0274 [0000001C-0000004B] CRC OK
00000018 DataSize: 44 Size OK
0000001C Data: DHO924
-----------------------------------------------------------
0000004C NameSize: 4
00000050 Name: E_CFG_SN_RAW
00000054 FieldSize: 56
00000058 CRC32: 6184E52C [00000060-0000008F] CRC OK
0000005C DataSize: 44 Size OK
00000060 Data: DHO9A252500008
-----------------------------------------------------------
00000090 NameSize: 4
00000094 Name: E_CFG_MAC
00000098 FieldSize: 56
0000009C CRC32: 8292C492 [000000A4-000000D3] CRC OK
000000A0 DataSize: 44 Size OK
000000A4 Data: 0019AFA00004
File processed OK
First up: The checksum is hexadecimal A2A69654
In the hexdump you can see the first four bytes are 54 96 A6 A2. That's the same four bytes as the checksum but reversed, that tells me the rest of the file will also have any 32-bit numbers reversed in it.
Next up in the hex dump we have CC 00 00 00. Reverse that and we get 0x000000CC - 204 in decimal. That's the file size.
After that is 04 00 00 00, that gives us "NameSize: 4". It looks like every packet of data in the file is preceded by its size so we read out 4 bytes. "05 00 00 00". 5 must be the code for E_CFG_MODEL_RAW (which I assume is "model number").
Then we get 38 00 00 00, ie 0x00000038, 56 in decimal. The remainder of the "E_CFG_MODEL_RAW" packet is 56 bytes long. It has a 4-byte CRC ("0ADE0274 ") and then this:
06 00 00 00 31 67 FA 5A AE C8 12 02 15 AA 70 96 0A CA 4E A0 EF 82 04 1B B2 36 40 C3 23 CF 2E EF 3A 03 58 80 76 02 1B CD BF 10 1A 36 45 2C 02 98
I'm not exactly sure how that works but the first 4 bytes are"6" (the length of the string "DHO924") plus what I assume is an encrypted version of the text (there's no zeros or recognizable characters in the data and some bytes are higher than 127).
The next packet is the serial number. It starts at offset 0x00004c and has the same structure.
The final packet is the MAC address and starts at 0x00000090. Same structure again.
Why would they encrypt the strings inside the file? No idea. It's suspicious that all three strings in the file have 40 bytes of data even though the strings are different lengths.
-
i downloaded the so called decrypted vendor.bin i still dont see much with hex editor...
Ah, the untrained eye...
I lost track of the post with that decrypted file but it was definitely decrypted/correct.
i'm not intending to work hard on that, up to a point where i dont know what is real and what is interpolated ;) i expect i can see my serial number and scope model in plain text in hex editor... so there must be a method/function to translate all those values between zerooos into plain text serial number.
-
what I assume is an encrypted version of the text (there's no zeros or recognizable characters in the data and some bytes are higher than 127).
Correct. The file is XXTEA encrypted and the strings inside are again XXTEA encrypted. AFAIR someone posted a tool that takes care of all of this... or I imagined that?
-
Actually, that's perfectly OK if my 804 now has 50Mpts and 100Mhz (measured 200Mhz) bandwidth.
But... ;)
It would be nicer to have the 2ns/div and the other decoders without having to make it a 900.
Let's see where this thread leads to.
-
currently i have 2 sd cards ready... v1.14 DHO924 (which currently i use) and the other v1.01 DHO804 (legit copy) ordering more 32GB sd cards for other version, so switching between versions and models, or for hacking trial and error, is only a matter of switching sd card and redo self-cal. i prefer all DHO924S features, except with latest FW from rigol site, and my original serial number.
-
It would be nicer to have the 2ns/div and the other decoders without having to make it a 900.
Let's see where this thread leads to.
Does the DHO900 have 2ns/div? I don't care much about all the other DHO900 stuff but that would be nice to have.
We'll probably need to modify the .apk file to get it though and I don't know anything about doing that...
(yet)
-
Does the DHO900 have 2ns/div?
Datasheet say "yes".
-
It would be nicer to have the 2ns/div and the other decoders without having to make it a 900.
Let's see where this thread leads to.
Does the DHO900 have 2ns/div? I don't care much about all the other DHO900 stuff but that would be nice to have.
We'll probably need to modify the .apk file to get it though and I don't know anything about doing that...
(yet)
yes, but v1.14 FW has some quirk there. https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5135757/#msg5135757 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5135757/#msg5135757)
-
Do your scopes use the MAC address that is embedded into the vendor.bin?
Mine uses different MAC on ethernet NIC - one starting with 56:30:2a. vendor.bin has MAC starting 00:19:AF.
Not sure where this comes from... any ideas?
-
Do your scopes use the MAC address that is embedded into the vendor.bin?
Mine does.
-
Do your scopes use the MAC address that is embedded into the vendor.bin?
Mine uses different MAC on ethernet NIC - one starting with 56:30:2a. vendor.bin has MAC starting 00:19:AF.
Not sure where this comes from... any ideas?
00:19:AF is the MAC address block assigned to Rigol; 56:30:2a comes back as "unassigned". Strange...
https://maclookup.app/search/result?mac=00:19:AF
-
Do your scopes use the MAC address that is embedded into the vendor.bin?
Mine uses different MAC on ethernet NIC - one starting with 56:30:2a. vendor.bin has MAC starting 00:19:AF.
Not sure where this comes from... any ideas?
00:19:AF is the MAC address block assigned to Rigol; 56:30:2a comes back as "unassigned". Strange...
https://maclookup.app/search/result?mac=00:19:AF
From dmesg:
[ 5.827923] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: mac address: 56:30:2a:xxxxxx
[ 5.827960] eth0: device MAC address 56:30:2a:xxxxxxxx
[ 7.219817] ethernet PHY : genphy init done, phyid = 0x00000128.
[ 7.238202] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 7.508644] init: Service 'up_eth0' (pid 230) exited with status 0
[ 10.230097] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
I've grepped briefly rigol scripts and can't see anything that would be overriding it in any way...
Am I thinking correct that rk_gmac-dwmac fetches this mac from the rockchip SoC registers...?
Not super important but curious...
-
FWIW, 56:30:2a is a MAC OUI that has the "locally administered" bit set (https://en.wikipedia.org/wiki/MAC_address#Address_details), which means that it's an OID that is "made up" and not in the IEEE OUI registry (which is why a MAC address search tool won't find a match).
I don't know why the oscilloscope would use one of those instead of the Rigol owned MAC address, but I have a guess from Google:
This post on some armbian forum (https://forum.armbian.com/topic/8688-nanopi-neo4-armbian565-mac-address-is-no-fixed/?do=findComment&comment=69648) shows the following lines in dmesg:
[ 7.853012] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: rk_vendor_read eth mac address failed (-1)
[ 7.853052] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: generate random eth mac address: 5a:b7:f0:5b:53:d4
[ 7.853058] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: rk_vendor_write eth mac address failed (-1)
[ 7.853066] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: mac address: 5a:b7:f0:5b:53:d4
[ 7.853071] eth0: device MAC address 5a:b7:f0:5b:53:d4
In that case the MAC address is randomly generated on each boot. If your randomly generated MAC address is stable across boots, then what might have happened is that on first boot 'rk_vendor_read eth mac address failed' occurred and a random MAC was generated (with OUI 56:30:2a). But in your case maybe the following 'rk_vendor_write eth` did not fail and was written to some saved configuration location and subsequent boot successfully read that MAC?
I don't think this randomly generated MAC address will cause big problems. It's highly unlikely that a duplicate MAC will be found on your local network which is the the most important place the MAC address is used. However there are two other scenarios I can think of where MAC addresses get used that aren't uncommon:
- some licensing algorithms will use a MAC address as an identifier. I don't think Rigol uses MAC addresses for its option licenses, so I don't think there's a problem there
- DHCP can use MAC address to identify if a node asking for an IP address was recently assigned some IP address so the DHCP server will give that node the same address (if it hasn't already been given to another node). If the oscilloscope's MAC address changes with each boot, it's more likely to get a different IP address each time. This is generally not a big problem unless you want the scope's IP address to generally be stable or want to configure the DHCP server to assign a fixed IP to that oscilloscope. The workaround for that is to assign a fixed IP outside of the DHCP range on the scope itself (I assume the scope's settings have some mechanism for that?)
-
FWIW, 56:30:2a is a MAC OUI that has the "locally administered" bit set (https://en.wikipedia.org/wiki/MAC_address#Address_details), which means that it's an OID that is "made up" and not in the IEEE OUI registry (which is why a MAC address search tool won't find a match).
I don't know why the oscilloscope would use one of those instead of the Rigol owned MAC address, but I have a guess from Google:
This post on some armbian forum (https://forum.armbian.com/topic/8688-nanopi-neo4-armbian565-mac-address-is-no-fixed/?do=findComment&comment=69648) shows the following lines in dmesg:
[ 7.853012] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: rk_vendor_read eth mac address failed (-1)
[ 7.853052] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: generate random eth mac address: 5a:b7:f0:5b:53:d4
[ 7.853058] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: rk_vendor_write eth mac address failed (-1)
[ 7.853066] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: mac address: 5a:b7:f0:5b:53:d4
[ 7.853071] eth0: device MAC address 5a:b7:f0:5b:53:d4
In that case the MAC address is randomly generated on each boot. If your randomly generated MAC address is stable across boots, then what might have happened is that on first boot 'rk_vendor_read eth mac address failed' occurred and a random MAC was generated (with OUI 56:30:2a). But in your case maybe the following 'rk_vendor_write eth` did not fail and was written to some saved configuration location and subsequent boot successfully read that MAC?
I don't think this randomly generated MAC address will cause big problems. It's highly unlikely that a duplicate MAC will be found on your local network which is the the most important place the MAC address is used. However there are two other scenarios I can think of where MAC addresses get used that aren't uncommon:
- some licensing algorithms will use a MAC address as an identifier. I don't think Rigol uses MAC addresses for its option licenses, so I don't think there's a problem there
- DHCP can use MAC address to identify if a node asking for an IP address was recently assigned some IP address so the DHCP server will give that node the same address (if it hasn't already been given to another node). If the oscilloscope's MAC address changes with each boot, it's more likely to get a different IP address each time. This is generally not a big problem unless you want the scope's IP address to generally be stable or want to configure the DHCP server to assign a fixed IP to that oscilloscope. The workaround for that is to assign a fixed IP outside of the DHCP range on the scope itself (I assume the scope's settings have some mechanism for that?)
That's what I thought that this is locally defined set. However I don't see any other errors in dmesg log related, hence I was curious why this is the case.
This MAC is persistent and same after every reboot (cold).
The other theory I have is that perhaps bootloader is reading and configuring NIC's MAC register at the early boot stage.
Perhaps it cannot read it from where it's stored and psuedo-random is generated (however always same).
My guess is that it could be before mentioned fRAM... that might be storing same information as in the vendor.bin file.
I haven't broken the seal on my unit yet, but perhaps early boot console log would shed more light at it.
Other work around would be to run small script to override MAC with correct one. (ip link set dev <your device here> address <your new mac address>).
But in my case MAC is persistent and hence DHCP assigned IP so not a problem at all...
Also I wonder if anyone that tried substituting vendor.bin from other models have seen MAC address being updated on their devices to correspond with used file?
-
Here is a modified rgtool file for DHO800 with all the possible Rigol options I found on the net :) As you already know most of them will not work, but I added them for complecity.
What I wonder, after watching Dave's teardown video, is can we add AWG signal generator to the DHO800's. It seems there is just one component missing that directly outputs on the back BNC.
Dave assumes its a buffer/driver, but it has a little bit unusual footprint and pin numbering... so I guess it is rather some generator module... But this could be answered only by a DHO9xxS owner :) Anyone?
-
What I wonder, after watching Dave's teardown video, is can we add AWG signal generator to the DHO800's. It seems there is just one component missing that directly outputs on the back BNC.
Dave assumes its a buffer/driver, but it has a little bit unusual footprint and pin numbering... so I guess it is rather some generator module... But this could be answered only by a DHO9xxS owner :) Anyone?
TO my knowledge, there is a whole daughter board missing. There might be teardown photos on the forum somewhere from a DHO924S?
-
Yep I searched a bit and here are the pics from souldevelop https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5051812/#msg5051812 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5051812/#msg5051812)
-
I've received my DHO914S, it was delivered with FW 1.00, in options I've discovered bw upgrade from 150 to 250Mhz option (it was in "Limit" state), so decided to check if it can be generated.
First updated to 1.01 fw, upgrade bw option disappeared from option list.
Modified hdo-tools script as was described before in this topic, but added BW15T25 option in it, when inserted generated key in web gui, and oscilloscope said "option installed" or something similar on it's screen, and now it shows "DHO914S (Max BW:250M)" in about tab, so looks like it works, see screenshots.
But I don't know how to check if it's really working at 250Mhz BW :)
-
If you don't have a generator that goes at least up to 300Mhz, then there is still a very steep square wave signal where you can approximately determine the bandwidth of your scope by its measured rise time.
However, the tests with the 804 showed that the bandwidth extension can be trusted.
-
If you don't have a generator that goes at least up to 300Mhz, then there is still a very steep square wave signal where you can approximately determine the bandwidth of your scope by its measured rise time.
However, the tests with the 804 showed that the bandwidth extension can be trusted.
Absence of BW 150 to 250 upgrade option (which disappeared in 1.01 update) confuses me, maybe it's only showing 250M in model and not working, if I understand correctly DHO800 still has 70 to 100 option listed in options tab. I don't think I really need 250M (but more is always better), this was experiment to share new info with other people on this forum, this is more hobby :)
Unfortunately I've only oscilloscope built in generator and Uni-T UTG962 gen, which is not too fast.
I'll maybe try to find signals with low rise time in some boards like esp32, arduino or similar.
-
I don't think I really need 250M (but more is always better)
With the DSO900, more bandwidth is a bit of a double-edged sword. If you enable more than two channels, your sampling rate will drop to 312 MSa/s, so the scope cannot capture signals above 150 MHz anyway due to the Nyquist limit.
With the upgrade to 250 MHz, you have now disabled the analog lowpass at the inputs which would previously suppress frequencies above 125 MHz. So you may see some aliasing -- IF you feed in signals which have such high-frequency components, e.g. fast square waves, AND you have more than two channels enabled.
(Note that using the digital channels will also eat up half of your sampling rate, by the way. So only one analog channel can be used in parallel, running at 625 MSa/s then, if you want to look at fast analog information in parallel with the digital channels.)
-
Hi,
Absence of BW 150 to 250 upgrade option (which disappeared in 1.01 update) confuses me, maybe it's only showing 250M in model and not working, if I understand correctly DHO800 still has 70 to 100 option listed in options tab.
Before the first firmware update, my DHO804 showed 70 to 100Mhz as an option, after the update ist was gone (and replaced by storage depth option).
Nevertheless, I was able to "activate" both, the bandwidth is now 100Mhz, measured even at 200Mhz.
-
DHO800/DHO900 UNLOCK TOOLS
1) Install GOLang distribution
2) In the "run_DHO_Tools.bat":
- set the GO installation directory path
- set the IpAddress variable (your scope's address is on the IO tab of the "Utility" window)
- change options list, if DHO900
- change scopeID, if DHO900
- if you don't want to create a backup file and pull it to the computer, delete line 35, or make it comment like this:
rem call "adb\05 make Backup And pull it - adb rm updateGEL, sh buildGEL, pull.bat"
3) Run the "run_DHO_Tools.bat"
4) Send the generated SCPI commands to the scope via the SCPI browser tab, opened by the script. Common command view:
:SYSTem:OPTion:INSTall DHOX00-<option>@XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Scope reboot is not needed.
5) Check BW limit on the "About" tab and the memory depth (for the DHO804) on the "Options" tab of the "Utility" window.
PS: To remove installed options use the "adb\03 adb remove ALL options.bat" file or the ":SYSTem:OPTion:UNINstall" command from p268 of the DHO800/DHO900 Programming Guide.
UPDATE REASON: extending the description text.
-
With the upgrade to 250 MHz, you have now disabled the analog lowpass at the inputs which would previously suppress frequencies above 125 MHz. So you may see some aliasing -- IF you feed in signals which have such high-frequency components, e.g. fast square waves, AND you have more than two channels enabled.
Thanks for explanation, fortunately license is easy removable to activate low pass filters again.
Before the first firmware update, my DHO804 showed 70 to 100Mhz as an option, after the update ist was gone (and replaced by storage depth option).
Nevertheless, I was able to "activate" both, the bandwidth is now 100Mhz, measured even at 200Mhz.
Good news, will hope they won't remove this hack in next releases.
-
Good news, will hope they won't remove this hack in next releases.
Normally I would say, hack or no hack, we have entered a license key.
This remains unaffected by any firmware update.
However, a small residual risk remains, because you can't officially purchase upgrades.
Status now.
-
Absence of BW 150 to 250 upgrade option (which disappeared in 1.01 update) confuses me
There's no official upgrade so they probably took it out of the UI to stop people asking where they can buy it.
(the 50M memory option for the DHO800 is still a mystery...)
I'll maybe try to find signals with low rise time in some boards like esp32, arduino or similar.
I haven't tried an Arduino pin recently but I don't think it will be anywhere near fast enough to measure 250Mhz.
-
I wonder wether going for a MSO5074 @ 1070€ and upgrading it to a MSO5324 @ 2569€ with 8 GSa/s (2 GSa/s with 4 channels) isn't the better deal, than spending 712€ on a DHO914 and upgrading it to a DHO914S @ 831€ (since the 250 MHz are not alias free due to 0,3125 GSa/s on the DHO900).
Well, the MSO5000 is not 12 bit :-BROKE
-
I wonder wether going for a MSO5074 @ 1070€ and upgrading it to a MSO5324 @ 2569€ with 8 GSa/s (2 GSa/s with 4 channels) isn't the better deal, than spending 712€ on a DHO914 and upgrading it to a DHO914S @ 831€ (since the 250 MHz are not alias free due to 0,3125 GSa/s on the DHO900).
Well, the MSO5000 is not 12 bit :-BROKE
I don't think the DHO914 compares very favourably with the MSO5000 TBH. It's much better for lower level signals, but that's about it. Also, the "S" model has a daughter board for the AWG, so I don't think you can upgrade it just by software.
The bode plot and the LA are kind of broken now too.
Until the additional features work properly, you are better served with the MSO5000 or any other MSO really, if you really need that capability.
-
I wonder wether going for a MSO5074 @ 1070€ and upgrading it to a MSO5324 @ 2569€ with 8 GSa/s (2 GSa/s with 4 channels) isn't the better deal, than spending 712€ on a DHO914 and upgrading it to a DHO914S @ 831€ (since the 250 MHz are not alias free due to 0,3125 GSa/s on the DHO900).
Well, the MSO5000 is not 12 bit :-BROKE
They are very different beasts. The two main decisions you need to make are: (a) Is the small format of the DHO900 a bonus for you, or do you prefer the larger screen and separate channel controls of the MSO5000? (b) Is the lower noise and 12-bit resolution of the DHO900 important for you, because you expect to do a lot of analog work, or is the high sample rate and up to 350 MHz bandwidth of the MSO5000 more relevant since you will focus on digital signals?
May I suggest that any follow-up discussion moves to another DHO800/900 thread, e.g. https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/. (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/.) The present thread is meant to focus on hacking approaches.
-
I wonder wether going for a MSO5074 @ 1070€ and upgrading it to a MSO5324 @ 2569€ with 8 GSa/s (2 GSa/s with 4 channels) isn't the better deal, than spending 712€ on a DHO914 and upgrading it to a DHO914S @ 831€ (since the 250 MHz are not alias free due to 0,3125 GSa/s on the DHO900).
That's a very good question.
Unfortunately you're the only one who can answer it. :)
How often do you need to look at millivolt signals?
-
PS: To remove installed options use "adb\03 adb remove ALL options.bat" or the SCPI command from the manual.
Has anyone tested this? What exactly is "adb\03" and where is it supposed to work? It doesn't seem to work in a windows command prompt, in a shell nor in the SCPI command window. What is the \03 part?
"adb remove ALL options.bat" doesn't work as "remove" is not an adb command.
-
adb is the Android Debugger. You can use it to hack around the 'scope, copy files to/from it, etc.
You can download it here: https://developer.android.com/tools/adb
-
Hello Everyone,
there is an adb-plugin for the Total Commander filemanager, which gives you easy access to the DHO filesystem.
https://www.ghisler.ch/board/viewtopic.php?t=34980 (https://www.ghisler.ch/board/viewtopic.php?t=34980)
Double click on the zip file in the TC and the plugin will be installed. Then click on network drives and you will see the adb-plugin. Click on it and enter the DHO-IP "XXX.XXX.XXX.XXX:55555" under "connect to device". Then click on the green connection symbol...
Some folders can read/write normally, others are mounted as ro and can only be read...
Maybe they can also be mounted r/w ::)
Best,
edit: one picture was double :P
-
adb is the Android Debugger. You can use it to hack around the 'scope, copy files to/from it, etc.
You can download it here: https://developer.android.com/tools/adb
If you were replying to me, I already have adb and have used it several times. My point was "adb\03" is not valid a valid command nor is "adb \03". Also remove is not a valid adb command.
The following command does not appear to be valid, unless I am missing something.
PS: To remove installed options use "adb\03 adb remove ALL options.bat" or the SCPI command from the manual.
-
If you were replying to me, I already have adb and have used it several times. My point was "adb\03" is not valid a valid command nor is "adb \03". Also remove is not a valid adb command.
It's not a thread for computer newbies. But here for you:
To remove installed options use the .bat file from the adb directory from the attached to my original message file: "adb\03 adb remove ALL options.bat" or the :SYSTem:OPTion:UNINstall command from the Programming manual.
-
Hello Everyone,
there is an adb-plugin for the Total Commander filemanager, which gives you easy access to the DHO filesystem.
Indeed...
-
Has anyone tested this? What exactly is "adb\03" and where is it supposed to work? It doesn't seem to work in a windows command prompt, in a shell nor in the SCPI command window. What is the \03 part?
"adb remove ALL options.bat" doesn't work as "remove" is not an adb command.
The description is updated to avoid misinterpretation. It's meant to help newbies anyways.
The file was downloaded around 70 times, and no complains so far, except for your difficulties.
-
Some folders can read/write normally, others are mounted as ro and can only be read...
Maybe they can also be mounted r/w ::)
This is because default access is user level, I haven't tried plugin, may be you can force it to exec su before exporting fs to total commander, but in adb shell you can exec su command and become root user, most folders will be accessible and writable as root, be careful with it :)
-
I skipped downloading your zip file because I already have my own local edited copy of rgtool.go. I already installed the BW7T10 and RLU licenses via SCPI. All I was looking for was "rm *.lic" or ":SYSTem:OPTion:UNINstall" the rest I can fill in for myself.
I am an ADB and SCPI newb. The only thing I missed was that your instructions were specific to script files contained in your zip. I assumed *nix paths so I totally missed that "adb\03 adb remove ALL options.bat" was referring to a file. Spaces in file names are evil for a few reasons.
I also assumed that not many people have removed the upgraded licenses yet.
So yeah, I made a bunch of bad assumptions. Thank you for trying to make this easier for people. I am sorry I took away from that.
-
I also assumed that not many people have removed the upgraded licenses yet.
Each license creates a ".lic" file in /rigol/bin.
You can add them, remove them, do whatever you like. They're just a text file with the license key in it to match the file name.
-
I also assumed that not many people have removed the upgraded licenses yet.
Each license creates a ".lic" file in /rigol/bin.
You can add them, remove them, do whatever you like. They're just a text file with the license key in it to match the file name.
That was obvious once I opened the batch file and saw the adb shell rm command. I suppose I should have shared that for people following along though.
-
Follow up to my original post:
I modified rgtool.go for my DHO914S to try to extract the BW15T25 license key from the Key.data file to upgrade to 250 MHz bandwidth. When I run it I get back a string that shows this:
Key: brainpoolP256r1;0429C03147397DB14EF8300804016CDF9281DBBE2E3488ADC3BAD82E042
B00A6E8509E688BA16719D929D2314CE1978E17EC393A58E27D70B49133A80B3B6E831E
Generating options for DHO9XXXXXX
:SYST:OPT:INSTall%!(EXTRA string=DHO900-BW15T25@8bd798ba1bd51cdbee7792d403cf4f8e
60a7d9802aaa6f5315498d25ffe5bae906e69767702c7527bce533b1ebe963bd)
What does all of this output signify? Why does the output of the rgtool program show "EXTRA string=" and have the presumed license string enclosed in parentheses? Is BW15T25 the valid keyword to extract the license key?
I used the SCPI interface to try to install this license but obviously it doesn't work.
Thanks!
-
What does all of this output signify? Why does the output of the rgtool program show "EXTRA string=" and have the presumed license string enclosed in parentheses?
I had the same output, so no worries about that.
-
I used the SCPI interface to try to install this license
In this way:
:SYST:OPT:INST DHO900-BW15T25@8bd798ba1bd51cdbee7792d403cf4f8e
60a7d9802aaa6f5315498d25ffe5bae906e69767702c7527bce533b1ebe963bd
?
What options will be shown on your DHO914S ?
-
Just a theoretical question, if I upgraded my DHO914s from BW 125MHz to 250MHz is it possible to undo the upgrade later, and how would that be done? Reversing the change would reduce input noise and aliasing effects.
-
Thanks for the info. As I understand it, you got the same output format as I did with the :SYST:OPT:INSTall%!(EXTRA string= at the beginning and the ) at the end, and you just edited out the all%!(EXTRA string= and the )?
I tried that and still no joy. My installed options are the same as before, with three serial bus analysis options (embedded, auto, and computer), as well as the Bode plot analysis. The "About" screen shows DHO914S (Max BW 125M).
What am I doing wrong?
-
Hi,
Yepp only copy this :
DHO900-BW15T25@8bd798ba1bd51cdbee7792d403cf4f8e
60a7d9802aaa6f5315498d25ffe5bae906e69767702c7527bce533b1ebe963bd
And type it in the scpi command prompt like I´ve posted before with :SYST:OPT:INST
My installed options are the same as before
Your options screen shows nothing else ?
-
Just a theoretical question, if I upgraded my DHO914s from BW 125MHz to 250MHz is it possible to undo the upgrade later, and how would that be done?
I guess (not know!) by removing the license key.
Reversing the change would reduce input noise and aliasing effects.
I consider noise to be negligible.
-
Just a theoretical question, if I upgraded my DHO914s from BW 125MHz to 250MHz is it possible to undo the upgrade later, and how would that be done? Reversing the change would reduce input noise and aliasing effects.
Yes. It's easy.
Either delete the license file using ADB or try ":SYST:OPT:UNINST ALL"
(I'm typing that last command from memory from DS1054Z days so it might be wrong. :) Point is: It CAN be done... I've done it several times with ADB method while I was messing around. Basic ADB use is well worth learning for hacking these 'scopes... )
adb connect 192.168.1.xxx:55555 (five fives)
adb shell ls -l /rigol/data (all the files related to model/licenses are in "/rigol/data")
adb pull /rigol/data/file.dat
adb push file.dat /rigol/data
adb shell rm /rigol/data/file.dat
In your case it would be much easier to push a DHO924's vendor.bin to your scope than to mess around generating licenses. There's one attached to the fifth post of this thread.
Remember: Pull your own vendor.bin file first and keep it safe so you can push it back and return to your original DHO914.
-
Thank you very much Martin72 and Fungus, good to know. :)
-
Reversing the change would reduce input noise and aliasing effects.
I consider noise to be negligible.
I didn't notice any change in noise level when I was switching between 804/924.
Aliasing will change in DHO924 mode when more than two channels are enabled (312.5MHz sample rate isn't high enough for 250MHz+ analog bandwidth).
Solution: Be aware of it. Go to 625MHz sample rate by turning off a channel or two when you're looking at something important or when you suspect aliasing is happening.
Remember: Aliasing can occur at any frequency. I can alias a 1kHz sine wave as something else by setting up my 200MHz DHO800 badly enough.
-
I modified rgtool.go for my DHO914S to try to extract the BW15T25 license key from the Key.data file to upgrade to 250 MHz bandwidth. When I run it I get back a string that shows this:
.........
I used the SCPI interface to try to install this license but obviously it doesn't work.
Thanks!
Use my Rigol Unlock Tools (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5148330/#msg5148330). It's a trasparent script. Original instruction has some mistakes.
-
Just a theoretical question, if I upgraded my DHO914s from BW 125MHz to 250MHz is it possible to undo the upgrade later, and how would that be done? Reversing the change would reduce input noise and aliasing effects.
Yes, you can delete lic files, see the Rigol Unlock Tools (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5148330/#msg5148330)
-
Thanks for the info! I ran your unlock tool after modifying it for my HDO914S, but I still cannot get the bandwidth to upgrade. I'm running 1.01 firmware, if that makes any difference. Here's the output from run_DHO_tools.bat:
C:\Users\Stan\Desktop\ADB>run_dho_tools_900.bat
List of devices attached
connected to 192.168.1.211:55555
Here you can find all *.lic files of options already installed:
total 680
-rwxrwxrwx 1 system system 148 2013-01-18 08:55 Key.data
-rwxrwxrwx 1 system system 1876 2013-01-18 08:51 cal_adc.hex
-rwxrwxrwx 1 system system 348 2023-11-06 20:08 cal_afe_bandwidth.hex
-rwxrwxrwx 1 system system 348 2013-01-18 08:52 cal_afe_zero.hex
-rwxrwxrwx 1 system system 96372 2013-01-18 08:58 cal_afg.hex
-rwxrwxrwx 1 system system 76 2013-01-18 09:09 cal_ddr.hex
-rwxrwxrwx 1 system system 36 2013-01-18 09:12 cal_la.hex
-rwxrwxrwx 1 system system 156 2013-01-18 08:58 cal_lsb.hex
-rwxrwxrwx 1 system system 205084 2013-01-18 09:07 cal_vertical.hex
drwxrwxrwx 2 root root 4096 2023-06-02 14:16 default
drwxrwxrwx 2 root root 4096 2013-01-18 16:50 probe
-rwxrwxrwx 1 shell shell 220 2023-10-28 22:12 vendor.bin
Making backup, see the "/backup/" folder (you can install it from a flash drive,
as you do it with the official update)
/rigol/data/Key.data: 1 file pulled, 0...kipped. 0.0 MB/s (148 bytes in 0.040s)
go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO9
SCPI format: ':SYSTem:OPTion:INSTall'
options: [BODE BW15T25]
Key: brainpoolP256r1;0429C03147397DB14EF8300804016CDF9281DBBE2E3488ADC3BAD82E042
B00A6E8509E688BA16719D929D2314CE1978E17EC393A58E27D70B49133A80B3B6E831E
Generating unlock SCPI commands for the DHO900 series scope:
:SYSTem:OPTion:INSTall DHO900-BODE@20634951498c770751a30efddf5229e51a68bdf4ce38c
6f64229625b2961e9e706e69767702c7527bce533b1ebe963bd
:SYSTem:OPTion:INSTall DHO900-BW15T25@8bd798ba1bd51cdbee7792d403cf4f8e60a7d9802a
aa6f5315498d25ffe5bae906e69767702c7527bce533b1ebe963bd
Generated option commands saved to the file: 'SCPI_commands_generated.txt'
Please, send generated :SYSTem:OPTion:INSTall commands to the scope via the SCPI
interface, and press any key to check for the new *.lic files.
Options are installed without scope reboot.
Press any key to continue . . .
Here you can find all *.lic files of options already installed:
total 680
-rwxrwxrwx 1 system system 148 2013-01-18 08:55 Key.data
-rwxrwxrwx 1 system system 1876 2013-01-18 08:51 cal_adc.hex
-rwxrwxrwx 1 system system 348 2023-11-06 20:08 cal_afe_bandwidth.hex
-rwxrwxrwx 1 system system 348 2013-01-18 08:52 cal_afe_zero.hex
-rwxrwxrwx 1 system system 96372 2013-01-18 08:58 cal_afg.hex
-rwxrwxrwx 1 system system 76 2013-01-18 09:09 cal_ddr.hex
-rwxrwxrwx 1 system system 36 2013-01-18 09:12 cal_la.hex
-rwxrwxrwx 1 system system 156 2013-01-18 08:58 cal_lsb.hex
-rwxrwxrwx 1 system system 205084 2013-01-18 09:07 cal_vertical.hex
drwxrwxrwx 2 root root 4096 2023-06-02 14:16 default
drwxrwxrwx 2 root root 4096 2013-01-18 16:50 probe
-rwxrwxrwx 1 shell shell 220 2023-10-28 22:12 vendor.bin
Press any key to continue . . .
You mentioned that you corrected some mistakes in the original instructions. I assume that the one I d/l'd is the corrected version, right?
Regards,
Stan
-
There doesn't seem much point in generating keys on a 900-series.
It's far easier to just change the DHO914 vendor.bin to a DHO924 vendor.bin, eg. use the one in post #5 of this thread.
nb. You need keys for a DHO800 because it's the only way to get the memory upgrade.
-
The problem with changing the vendor.bin file is that unless it's from a 924S, you lose the AWG and the Bode plot functionality (I've already tried that).
A minor issue is that the serial number is changed as well. Not really a huge deal, but I'd like to make the upgrade as "clean" as possible, and the license keygen seems to be the better way to do that.
Regards,
Stan
-
The problem with changing the vendor.bin file is that unless it's from a 924S, you lose the AWG and the Bode plot functionality (I've already tried that).
can someone identify these parts? they are missing in dho800... b,c,d,e. especially d,e please...
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1921041;image)
-
Here you can find all *.lic files of options already installed:
.....
Regards,
Stan
As you can see, there is no *.lic files in the file listing at the end. Did you send command:
"
:SYSTem:OPTion:INSTall DHO900-BW15T25@8bd798ba1bd51cdbee7792d403cf4f8e60a7d9802aaa6f5315498d25ffe5bae906e69767702c7527bce533b1ebe963bd
"
through the SCPI page to the scope.
I've seen BW15T25 command working on DHO914 model earlier in this thread, as far as I remember. (see https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5147868/?topicseen#msg5147868 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5147868/?topicseen#msg5147868))
-
can someone identify these parts? they are missing in dho800... b,c,d,e. especially d,e please...
From the locations on the PCB I'd guess they're something to do with power for the AWG daughterboard.
-
I'm not sure what went wrong with my previous upgrade attempts, because I sent the identical string, but I tried it again after power cycling the DHO914S and it worked!
Unlike the other Rigol scopes I have, the BW upgrade doesn't show up as an option in the options list, but does show "Max BW:250M" in the "About" section.
Thanks to all who had the patience to help me with this!
-
I'm not sure what went wrong with my previous upgrade attempts, because I sent the identical string, but I tried it again after power cycling the DHO914S and it worked!
The problem was in the extra symbol you'd copied from the terminal window. There should be no extra spaces or carriage return symbols, but your original message has "enter" symbols at the 80 symbols mark.
That's why the script is writing commands to the file.
Copy the commands from the file "SCPI_commands_generated.txt".
-
The a,b,c is related to the logic analyzer most probably (a- power, b-c setting the threshold level?), the d,e with the AWG.
-
I'm not sure what went wrong with my previous upgrade attempts, because I sent the identical string, but I tried it again after power cycling the DHO914S and it worked!
Unlike the other Rigol scopes I have, the BW upgrade doesn't show up as an option in the options list, but does show "Max BW:250M" in the "About" section.
Thanks to all who had the patience to help me with this!
Hi, I order a 914s from China and it is on the way. Can you post steps to upgrade to 924s in detail?
-
Here again a comparison between the original 70Mhz version and now, the "unleashed" version, which has 200Mhz bandwidth (although you can only hack on 100Mhz and only 100Mhz are displayed, maybe the reason why after the last firmware update the bandwidth option is no longer displayed).
As noted earlier: The "70MHz" version of the DHO800 has 125MHz measured bandwidth. :)
I think Rigol's marketing department is under-labelling the DHO800 to fool people into buying the DHO900.
(Which makes perfect sense - they probably make 3x profit in return for a $1 edge connector!)
is 250MHz BW now enabled in DHO800? how about AFG and LA capability? any news?
-
From an earlier posting by Serg65536:
DHO800/DHO900 UNLOCK TOOLS
1) Install GOLang distribution
2) In the "run_DHO_Tools.bat":
- set the GO installation directory path
- set the IpAddress variable (your scope's address is on the IO tab of the "Utility" window)
- change options list, if DHO900
- change scopeID, if DHO900
- if you don't want to create a backup file and pull it to the computer, delete line 35, or make it comment like this:
rem call "adb\05 make Backup And pull it - adb rm updateGEL, sh buildGEL, pull.bat"
3) Run the "run_DHO_Tools.bat"
4) Send the generated SCPI commands to the scope via the SCPI browser tab, opened by the script. Common command view:
:SYSTem:OPTion:INSTall DHOX00-<option>@XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Scope reboot is not needed.
5) Check BW limit on the "About" tab and the memory depth (for the DHO804) on the "Options" tab of the "Utility" window.
PS: To remove installed options use the "adb\03 adb remove ALL options.bat" file or the ":SYSTem:OPTion:UNINstall" command from p268 of the DHO800/DHO900 Programming Guide.
UPDATE REASON: extending the description text.
All the necessary files and info are in this EEVBlog thread. Once you've run the batch file and generated the license key(s), be sure to copy the license string(s) from the SCPI_commands_generated.txt file (NOT from your terminal window) to avoid inserting any extraneous characters into your license string.
BTW, the measured bandwidth on my newly upgraded DHO914S is 265 MHz on each channel. Of course, activating more than one channel at a time cuts the sampling rate, so the bandwidth will be decreased.
-
BTW, the measured bandwidth on my newly upgraded DHO914S is 265 MHz on each channel.
Show it please...
-
is 250MHz BW now enabled in DHO800? how about AFG and LA capability? any news?
The original hacking approach, where the vendor.bin file is replaced and a DHO800 can be turned into a 900 (from a software perspective), has fallen out of fashion somewhat. Several users have observed offset voltages afterwards which could not be removed by auto-calibration, and have hence gone back to the DHO800 configuration.
The alternative approach (referred to by swperk two posts above) is limited to enabling the full memory and higher bandwidth on the DHO800 -- nominally 100 MHz, but close to 200 MHz in practice. Or it can upgrade a DHO914 to a 924. It does not have any side effects.
To my knowledge, nobody has reported on having actually tried any hardware upgrades (LA or AWG). Given the mentioned side effects of the DHO800-to-900 software hack, retrofitting the LA has become even less attractive in my view. Adding the AWG to a DHO900 (non-S version) would require a copy of the AWG piggyback board; I have not seen any efforts in that direction beyond photos of the original board.
-
BTW, the measured bandwidth on my newly upgraded DHO914S is 265 MHz on each channel.
Show it please...
I had 1.6ns rise time on my DHO804 when I copied the 924 vendor.bin onto it. That's 280MHz. :)
-
The original hacking approach, where the vendor.bin file is replaced and a DHO800 can be turned into a 900 (from a software perspective), has fallen out of fashion somewhat. Several users have observed offset voltages afterwards which could not be removed by auto-calibration, and have hence gone back to the DHO800 configuration.
I don't recall anybody copying the DHO900 .cal files across though. Maybe that would fix it.
Me? I stopped hacking when I measured 200Mhz bandwidth. It seems a sensible limit given the limited sample rate. 280MHz would limit you to one channel if you need to obey Nyquist and I only have the 150MHz probes.
Does anybody have a factory 914? It would be interesting to know the measured bandwidth on that, given that the "70MHz" 804 measures in at over 120MHz.
-
Me? I stopped hacking when I measured 200Mhz bandwidth. It seems a sensible limit given the limited sample rate. 280MHz would limit you to one channel if you need to obey Nyquist and I only have the 150MHz probes.
I agree that even more bandwidth is not worth the extra effort and potential side effects. But having the CAN and LIN decoders, which so far are only available in the DHO900 series, might be valuable for some users. Personally I have not come across LIN but would certainly appreciate CAN support.
-
The original hacking approach, where the vendor.bin file is replaced and a DHO800 can be turned into a 900 (from a software perspective), has fallen out of fashion somewhat. Several users have observed offset voltages afterwards which could not be removed by auto-calibration, and have hence gone back to the DHO800 configuration.
I don't recall anybody copying the DHO900 .cal files across though. Maybe that would fix it.
Me? I stopped hacking when I measured 200Mhz bandwidth. It seems a sensible limit given the limited sample rate. 280MHz would limit you to one channel if you need to obey Nyquist and I only have the 150MHz probes.
Does anybody have a factory 914? It would be interesting to know the measured bandwidth on that, given that the "70MHz" 804 measures in at over 120MHz.
but you still dont have bode plot feature.. :P i'm working on AFG module now, there's hope. I now know what ic d and e do and what they are suppose to be... Posibbly LA too later on. while you people figure out how to properly upgrade to dho900.
-
I've developed vendor.bin repack utility. It allows editing of any field of the vendor.bin file. I'm not sure if I should share it here. Not everyone who reads this thread can make and restore backup....
[attachimg=1]
-
The image is from my DHO804 scope. I hoped to fix the offset issue while transitioning to DHO924 model, but had no luck.
It seems like the only way to fix the offset and DC accuracy is to find the difference in calibration algorithm and fix the initial values.
cal_adc.hex is 1.83KB, cal_vertical.hex is 200KB. It's huge files for such a simple task. And the size of 924 firmware cal_vertical file is different.
-
I've developed vendor.bin repack utility. It allows editing of any field of the vendor.bin file. I'm not sure if I should share it here. Not everyone who reads this thread can make and restore backup....
I was working on it but I haven't had much time this week and I'm trying to do it in Javascript so it's fiddly.
The idea is to have an HTML file with the keygen in it so nobody has to download GO or ADB (or whatever). Just open the HTML file in a browser, enter your serial number, and press "generate".
The image is from my DHO804 scope. I hoped to fix the offset issue while transitioning to DHO924 model, but had no luck.
Did you try copying all the 924's .cal files onto your DHO800?
I see no reason at all why the hardware would be different. :-//
-
I had played with the SCPI command set earlier, based on the programming guide dho1000/4000(800/900 have the same version 3.0).
https://www.batronix.com/files/Rigol/Oszilloskope/DHO1000/dho10004000_programmingguide_en.pdf (https://www.batronix.com/files/Rigol/Oszilloskope/DHO1000/dho10004000_programmingguide_en.pdf)
Most of it works, but not the interesting stuff. ;)
:SYSTem:MODules? for example shows 0,0,0,0,0 which makes sense because my 804 do not have any hardware modules like AWG and/or LA.
Also :SYSTem:RAMount? (number of analog channels), but :SYSTem:OPTION:STATus? <type> won´t work, although I have the BW7T10 and RLU "option" installed.
This at least tells me that these options and the possibility to install them do not actually exist.
But I will play with the command again in "test mode" (3x "about"), or generate another bandwidth key greater than 100Mhz and see if it is accepted in this mode.
-
I agree that even more bandwidth is not worth the extra effort and potential side effects. But having the CAN and LIN decoders, which so far are only available in the DHO900 series, might be valuable for some users. Personally I have not come across LIN but would certainly appreciate CAN support.
I can switch it to a 924 in two minutes if I ever need that. :)
-
Did you try copying all the 924's .cal files onto your DHO800?
I see no reason at all why the hardware would be different. :-//
I've tried this combinations:
1) 924 vendor.bin on 804 firmware: non correctable DC offset, voltage accuracy is low, fluffy waveform
2) 924 vendor.bin on 804 firmware but with 924 cal files: non correctable DC offset, voltage accuracy is low (1.6%), fluffy waveform
3) 804 vendor.bin but with 924 cal files: no DC offset, voltage accuracy is low (1.6%), waveform is normal (not sure)
4) back to the original unlocked DHO804 vendor.bin and cal files: no DC offset, voltage accuracy is high (0.26%), waveform is normal
BTW, waveform fluffines, probably, would dissapear by itself if I keep the scope with no power for 12H or more.
-
I wanted a tool to decode/encode the vendor.bin file in my daily OS which is linux,
so I've written my own tool https://github.com/zelea2/rigol_vendor_bin (https://github.com/zelea2/rigol_vendor_bin) in C with no dependencies.
I've cross-compiled it for windows too but is is just command line.
I don't have a DHO800 scope yet but I'm ordering one soon :)
-
..BTW, waveform fluffines, probably, would dissapear by itself if I keep the scope with no power for 12H or more.
Sounds strange :o .. What would be the mechanism behind?
-
I wanted a tool to decode/encode the vendor.bin file in my daily OS which is linux,
so I've written my own tool
Interesting.
I had downloaded the exe file and copied it together with the 924 vendor bin into the same folder.
Then run the exe in the command line and it seems it decodes the bin file.
And how does it work the other way round?
-
I wanted a tool to decode/encode the vendor.bin file in my daily OS which is linux,
so I've written my own tool
And how does it work the other way round?
On Windows:
rigol_vendor_bin.exe -h
Regards.
-
..BTW, waveform fluffines, probably, would dissapear by itself if I keep the scope with no power for 12H or more.
Sounds strange :o .. What would be the mechanism behind?
Some not initialized memory. You should wait for it to discharge, or for the software to init it. I've done this just once, so I'm not sure. And someone also has reported the same behavior here.
-
I don't have a DHO800 scope yet but I'm ordering one soon :)
Where did you get the second key, if you don't have the scope to debug?
-
Where did you get the second key, if you don't have the scope to debug?
I presume you are talking about the 'Key.data' file'; I've extracted both (including 'vendor.bin') from and SD card image which was published here.
The 'Key.data' is only needed to generate the unlock option strings and is not tied to the 'vendor.bin'.
What's interesting is that after the XXTEA decryption the Key.data reveals a very long hex string. Only the first 32 characters of that string are used
as the AES256 key (as ASCII characters not as hex data) to encrypt the options.
-
Hi zelea2,
thank you for sharing your work. I have a question about the operation of the keygen.
I tested the original vendor bin and the one generated with your tool.
I used kd2.go for testing from the website:
https://gitlab.com/riglol/rigolee/hdo-tools (https://gitlab.com/riglol/rigolee/hdo-tools)
original vendor.bin :
using key [ab12cd34 ab12cd34 ab12cd34 ab12cd34]
raw data:
54 96 A6 A2 CC 00 00 00 04 00 00 00 05 00 00 00 38 00 00 00 74 02 DE 0A 2C 00 00 00 06 00 00 00 31 67 FA 5A AE C8 12 02 15 AA 70 96
0A CA 4E A0 EF 82 04 1B B2 36 40 C3 23 CF 2E EF 3A 03 58 80 76 02 1B CD BF 10 1A 36 45 2C 02 98 04 00 00 00 07 00 00 00 38 00 00 00
2C E5 84 61 2C 00 00 00 0E 00 00 00 80 1D FD C7 EA 3E 89 0F 5F EF BA F5 B0 98 79 86 7C 3A 75 E0 69 2F 6E 1E 89 72 B3 88 4E B0 93 B0
B1 53 F3 31 89 5F 8D 92 7F 5B CF C3 04 00 00 00 09 00 00 00 38 00 00 00 92 C4 92 82 2C 00 00 00 0C 00 00 00 86 33 95 9A BE 57 EE 5D
BA 58 82 86 E4 9E 39 30 67 24 28 3C 4D 04 09 A7 7F E4 AF 3D 93 72 85 8B 96 AC A7 7C 67 C2 1D 45 35 83 0D 64
vendor crc ok a2a69654
id:5 | str:DHO924 | data:[7d ca b7 dd 76 31 c4 3d b0]
id:7 | str:DHO9A252500008 | data:[7b 77 71 3d d a e8]
id:9 | str:0019AFA00004 | data:[96 c9 16 c6 ab 9 56 85]
generated vendor.bin :
using key [ab12cd34 ab12cd34 ab12cd34 ab12cd34]
raw data:
3F B9 06 18 CC 00 00 00 04 00 00 00 05 00 00 00 38 00 00 00 A7 A9 56 84 2C 00 00 00 06 00 00 00 D4 95 85 AC 49 94 9F B2 4D 3D B5 EE
E7 08 69 E5 AC 86 9C 8E 84 48 16 BE 76 ED A4 E9 C8 49 34 31 2A AC F9 75 5C 7D B1 D3 BF 28 82 B5 04 00 00 00 07 00 00 00 38 00 00 00
AC 40 49 5F 2C 00 00 00 0E 00 00 00 FA 9F 5B E3 1D F5 82 9B 2D FE 47 EA D0 18 7B 99 A7 21 BA 86 3B 8E F1 A1 A2 93 2F 93 E3 C3 7C EA
2A 96 37 09 1C 45 E3 03 76 4F 02 26 04 00 00 00 09 00 00 00 38 00 00 00 9B 63 F8 40 2C 00 00 00 0C 00 00 00 C1 37 FC B5 5C 98 5E 11
53 75 16 47 6B 13 BD 87 1A 50 45 A3 A4 8D 7E E3 A2 C7 94 68 D7 68 FB B1 11 EF BC DE 3A FE 1A 8F 97 D2 45 29
vendor crc ok 1806b93f
id:5 | str:DHO924 | data:[0 0 0 0 0 0 0 0 0]
id:7 | str:DHO9A252500008 | data:[0 0 0 0 0 0 0]
id:9 | str:0019AFA00004 | data:[0 0 0 0 0 0 0 0]
Is this correct and the differences do not matter?
Regards.
-
Is this correct and the differences do not matter?
A string field is 44 bytes long regardless of the actual string length.
I've zeroed the rest of the bytes rather than leaving them random.
-
Is this correct and the differences do not matter?
A string field is 44 bytes long regardless of the actual string length.
I've zeroed the rest of the bytes rather than leaving them random.
Thank you for your answer.
-
An .imgc image is a compressed image of the scope filesystem made with the "HDD Raw Copy Tool" which is windows only.
If you want to decompress it in linux you can use the 'unimgc' utility and the destination can be an SD card (root partition) or a local file (of approx 30GB size).
If you want to read/write files from the image (and make offline permanent changes) I've made a quick script which mounts all the scope partitions using the loop devices on linux (offsets and sizes are hardcoded).
-
If you want to read/write files from the image (and make offline permanent changes) I've made a quick script which mounts all the scope partitions using the loop devices on linux (offsets and sizes are hardcoded).
you can setup loop device on whole image and use kpartx -av on this loop, it'll automatically create all partitions in /dev/mapper without hardcoding (in case something will change in future units).
edit: sorry this won't work with this android sd card image, only standard partition tables
-
Hello dudes,
not sure if I'll buy a DHO1074 (currently available with a super discount) or a DHO9x4S. In the thread about the Bode Plot function of the latter, it seems that it's buggy, even with the latest firmware updates. I can wait (have 2 other higher end oscilloscopes, a Tektronix and a Siglent, the Rigol would be an extra) but I'd have preferred to exploit the discount I can get now (and probably around Black Friday).
350MHz probes apart, is it 100% certain that the DHO914S and DHO924S have exactly the same identical hardware, and that the former can be completely hacked into the latter?
Cheers.
-
I've attached photos of the performance of my bandwidth upgraded DHO914S. I can see no difference (other than the probes) between mine and an "official" DHO924S.
I used a Leo Bodnar fast rise time pulse generator into a 50 ohm pass-through terminator to measure a 1.3 ns rise time. I used the "analog scope" formula of 0.35/rise time to calculate an approximately 269 MHz bandwidth. Then I used a calibrated signal generator to find the -3 dB point using 100 MHz as a reference level. The 620 mV p-p measured at 100 MHz was reduced to 620 mV / SQRT(2), or about 438 mV p-p at 305 MHz. Looks like the bandwidth formula for this scope should be revised to BW = 0.4/rise time.
-
0.35/rt for gaussian scope. Otherwise 0.45/rt..
-
I've attached photos of the performance of my bandwidth upgraded DHO914S. I can see no difference (other than the probes) between mine and an "official" DHO924S.
There's no difference internally but the DHO924 comes with better probes.
Looks like the bandwidth formula for this scope should be revised to BW = 0.4/rise time.
Use 0.45 for DSOs:
https://www.tek.com/en/support/faqs/how-bandwidth-related-rise-time-oscilloscopes (https://www.tek.com/en/support/faqs/how-bandwidth-related-rise-time-oscilloscopes)
-
0.35/rt for gaussian scope. Otherwise 0.45/rt..
"Gaussian scope" is a misnomer, I think. A Gaussian filter is a bandpass with a Gaussian-shaped frequency response (and hence also a Gaussian-shaped impulse response); not used in scope front ends to my knowledge. The 0.35 conversion factor between risetime and bandwidth applies to first- or second-order lowpass filters; 0.45 is the "rule of thumb" for the steeper filters often used today.
-
Misnomer? Are you saying tektronix is stupid?
Could you give a reference please? Where does Tektronix talk about "Gaussian oscilloscopes" or Gaussian filters in the front end?
-
Could you give a reference please? Where does Tektronix talk about "Gaussian oscilloscopes" or Gaussian filters in the front end?
Why today somebody else has to do someone's else homework? :palm: https://www.tek.com/en/support/faqs/how-bandwidth-related-rise-time-oscilloscopes#:~:text=Historically%2C%20oscilloscope%20frequency%20response%20tended,Bandwidth%20x%20rise%20time%20%3D%200.45. (https://www.tek.com/en/support/faqs/how-bandwidth-related-rise-time-oscilloscopes#:~:text=Historically%2C%20oscilloscope%20frequency%20response%20tended,Bandwidth%20x%20rise%20time%20%3D%200.45.)
And where exactly does that short text talk about "Gaussian scopes" or "Gaussian anything"?
Mate, I understand the 0.35 vs. 0.45 factors, and I summarized that just a couple of posts above. My point is that your terminology is wrong and misleading. ("Misnomer", you know? A wrong or inaccurate use of a term.) This has nothing to do with Gaussian filters.
-
I meant keysight/hp :palm: ... read!... https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://f.hubspotusercontent40.net/hubfs/281197/Keysight_Evaluating_Oscilloscopes_AppNote_CControls.pdf&ved=2ahUKEwj07rStk8iCAxUfi2MGHXCfBQUQFnoECAoQBg&usg=AOvVaw0xDwW53v3efGuzk-2vb-CF (https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://f.hubspotusercontent40.net/hubfs/281197/Keysight_Evaluating_Oscilloscopes_AppNote_CControls.pdf&ved=2ahUKEwj07rStk8iCAxUfi2MGHXCfBQUQFnoECAoQBg&usg=AOvVaw0xDwW53v3efGuzk-2vb-CF)
-
I meant keysight/hp :palm: ... read!... https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://f.hubspotusercontent40.net/hubfs/281197/Keysight_Evaluating_Oscilloscopes_AppNote_CControls.pdf&ved=2ahUKEwj07rStk8iCAxUfi2MGHXCfBQUQFnoECAoQBg&usg=AOvVaw0xDwW53v3efGuzk-2vb-CF (https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://f.hubspotusercontent40.net/hubfs/281197/Keysight_Evaluating_Oscilloscopes_AppNote_CControls.pdf&ved=2ahUKEwj07rStk8iCAxUfi2MGHXCfBQUQFnoECAoQBg&usg=AOvVaw0xDwW53v3efGuzk-2vb-CF)
That's a strange one... I would actually call their definition of "Gaussian frequency response" a misnomer too. ("A low-pass frequency response that has a slow roll-off characteristic that begins at approximately 1/3 the –3 dB frequency".)
Every other text I have seen defines a "Gaussian frequency response" very specifically as a frequency response that follows Gauss' "bell curve", i.e. g(f) ~ exp (-f²/a). This specific frequency response is not required to obtain the 0.35/risetime relationship, and it is not present in typical scope front ends.
All actual derivations of the 0.35 factor which I have come across assume a plain old first-order or second-order lowpass filter. Probably a real Gaussian filter would give a similar factor. But focusing the whole bandwidth discussion on Gaussian filters, as Keysight does, seems misleading to me.
-
That's a strange one... I would actually call their definition of "Gaussian frequency response" a misnomer too. ("A low-pass frequency response that has a slow roll-off characteristic that begins at approximately 1/3 the –3 dB frequency".)
Every other text I have seen defines a "Gaussian frequency response" very specifically as a frequency response that follows Gauss' "bell curve", i.e. g(f) ~ exp (-f²/a). This specific frequency response is not required to obtain the 0.35/risetime relationship, and it is not present in typical scope front ends.
All actual derivations of the 0.35 factor which I have come across assume a plain old first-order or second-order lowpass filter. Probably a real Gaussian filter would give a similar factor. But focusing the whole bandwidth discussion on Gaussian filters, as Keysight does, seems misleading to me.
Primarily, a Gaussian filter has a Gaussian impuse response, and that results in a lowpass filter (not bandpass as you said in a previous post). The magnitude of the frequency response also has a Gaussian bell shape, centered at 0Hz (if you consider both, positive and negative frequencies in the Fourier frequency domain). And the corresponding log magnitude (-> decibel scale) is a quadratic function of frequency.
[ Generally, bandpass filters can be derived from their corresponding lowpass prototypes. So Gaussian bandpass filters do exist as well. However, a Gaussian bandpass does not have a Gaussian impulse response (it's a cosine wave with Gaussian envelope). ]
The risetime * bandwidth product of an ideal Gaussian (lowpass) filter is 0.332.
A filter with Gaussian impulse response has the shortest rise time which is possible without overshoot in the step response. There exist filters with same bandwidth and shorter rise times, but they do overshoot. A "maximally flat" frequency response will always overshoot.
A true Gaussian response can only be approximated, in both domains, analog and digital. At least in the analog domain, never expect a perfect approximation. In the digital domain, the approximation accuracy is, of course, just a matter of the number of FIR filter taps you are willing to spend.
-
Primarily, a Gaussian filter has a Gaussian impuse response, and that results in a lowpass filter (not bandpass as you said in a previous post). The magnitude of the frequency response also has a Gaussian bell shape, centered at 0Hz (if you consider both, positive and negative frequencies in the Fourier frequency domain).
[ Generally, bandpass filters can be derived from their corresponding lowpass prototypes. So Gaussian bandpass filters do exist as well. However, a Gaussian bandpass does not have a Gaussian impulse response (it's a cosine wave with Gaussian envelope). ]
Right, thanks for the correction. But do we agree that Keysight's definition of "Gaussian frequency response" is rather misleading? -- Anyway, it seems that their main message, at the end of the application note, is simply: "Some cheap competitors have a really messy frequency response. Buy a Keysight." ;)
-
Right, thanks for the correction. But do we agree that Keysight's definition of "Gaussian frequency response" is rather misleading?
Read it as "approximately Gaussian". As long as you don't quantify the deviation, it's always correct. You can also consider Bessel as an approximation for Gaussian (although the design goal of Bessel is a different one).
-
Looks like the bandwidth formula for this scope should be revised to BW = 0.4/rise time.
I had also first determined the rise time with the Bodnar pulser and then calculated the bandwidth with the 0.45/rt formula.
Then I measured the actual bandwidth with a generator, which worked well.
-
I've attached photos of the performance of my bandwidth upgraded DHO914S. I can see no difference (other than the probes) between mine and an "official" DHO924S.
There's no difference internally but the DHO924 comes with better probes.
Better probes objectively, but maybe not in reality when used on a shared 1.25GS/s ADC: won't the 350MHz probes only cause more aliasing, except when using just one channel?
-
Better probes objectively, but maybe not in reality when used on a shared 1.25GS/s ADC: won't the 350MHz probes only cause more aliasing, except when using just one channel?
I compared the rise times on my hacked "200Mhz" DSO804 with 150Mhz probes vs. 50-Ohm BNC. It made very little difference.
Based on that I assume the real-world bandwidth difference between the 150Mhz and 350Mhz probes will be negligible on these 'scopes.
Maybe the 350Mhz probes aren't really a bonus from the probing point of view. Does anybody know if they feel better?
-
I don't have a DHO800 scope yet but I'm ordering one soon :)
I've ordered a DHO804 from Aliexpress https://www.aliexpress.com/item/1005005962731116.html (https://www.aliexpress.com/item/1005005962731116.html) for only £321 (chinese singles day).
To my surprise I've got the scope only 3 days later without having to pay any other VAT or customs fees (probably was shipped from UK not China). Brilliant deal!
I've plugged it to my LAN network, pulled the Key.data and vendor.bin files (via adb) and installed these 2 licenses: BW7T10.lic RLU.lic to increase the front end bandwidth and the memory depth.
The whole process was painless and took less than 5 min.
I've also noticed an SSH server running on the scope. Does anyone know what's the default root password?
-
I had also first determined the rise time with the Bodnar pulser and then calculated the bandwidth with the 0.45/rt formula.
Then I measured the actual bandwidth with a generator, which worked well.
Was the Bodnar pulser directly connected to the 1M Ohm input (-> 50 Ohm || Cin), or via feed-through terminator (-> 25 Ohm || Cin) ?
-
I had also first determined the rise time with the Bodnar pulser and then calculated the bandwidth with the 0.45/rt formula.
Then I measured the actual bandwidth with a generator, which worked well.
Was the Bodnar pulser directly connected to the 1M Ohm input (-> 50 Ohm || Cin), or via feed-through terminator (-> 25 Ohm || Cin) ?
https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5106120/#msg5106120 (https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/msg5106120/#msg5106120)
-
Yepp,
It's one from Huber&Suhner.
https://www.ebay.com/itm/266252468369 (https://www.ebay.com/itm/266252468369)
-
With the new firmware V 1.02 I have a good and a little bit of a bad news. (DHO800 CN page (https://www.rigol.com/products/detail/DHO800) or direct link (https://alc-sh-wwwdownload.oss-cn-shanghai.aliyuncs.com/cn/Firmware/Digital%20Osscillscope/DHO800%26DHO900/DHO800_DHO900(Software)Updatev00.01.02.00.00.zip))
1) Now I can use DHO924 as a main firmware, zero offset could be removed by the calibration. And the voltage accuracy is great also.
2) Now ADC Gain self test is turned on by default.
3) AFE zero self cal procedure increases the DC offset badly. To restore it you can push old cal files and repeat default calibration.
[attachimg=3]
Now it's time to hack it more. 8)
PS: push original old *.cal files (without default *.cal files), if your calibration fails.
-
1) Now I can use DHO924 as a main firmware, zero offset could be removed by the calibration. And the voltage accuracy is great also.
great! but where is the AFG (bode plot) function?
-
1) Now I can use DHO924 as a main firmware, zero offset could be removed by the calibration. And the voltage accuracy is great also.
great! but where is the AFG (bode plot) function?
I use DHO924 vendor.bin without "S" postfix.
-
And the voltage accuracy is great also.
5mV/div is interesting..
-
Where can I download firmware version 1.02? The Rigol NA site has only 1.01.
-
I wouldn´t do this until rigolna list it too.
You may see the problems I had with this yesterday.
I can still remember my MSO5000 days.
Not every firmware update was listed everywhere back then, some Chinese versions turned out to be beta status and didn't even make it onto the American and European websites.
There is no need for it at the moment, I would wait.
-
Here's my DHO800 pretending to be an HP15C calculator:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1930860;image)
(It's the only APK file I had lying around... :) )
Yes, it works perfectly. 8)
-
Accessing the google play web site over WiFi:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1930872;image)
-
Yes, it works perfectly.
So we could add this to the pro/cons list:
Can simulate a scientific calculator.
If that's not a reason to buy, then I don't know what is. ;)
-
So we could add this to the pro/cons list:
Can simulate a scientific calculator.
If that's not a reason to buy, then I don't know what is. ;)
Wait 'til I get electrodroid working... killer app! :-BROKE
The web browser screen recorder still works when you're using other apps! :)
https://www.youtube.com/watch?v=FMXPUd4uKb8 (https://www.youtube.com/watch?v=FMXPUd4uKb8)
-
Wait 'til I get electrodroid (https://electrodroid.en.uptodown.com/android) working... killer app! :-BROKE
Try this app (https://play.google.com/store/apps/details?id=it.Ettore.calcolielettrici), works very well in landscape mode! Its very similar to Electrodroid.
But it also have same color scheme as Rigol UI ;)
-
Who's laughing now? :-DD
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1930947;image)
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1930953;image)
-
Wait 'til I get electrodroid (https://electrodroid.en.uptodown.com/android) working... killer app! :-BROKE
Try this app (https://play.google.com/store/apps/details?id=it.Ettore.calcolielettrici), works very well in landscape mode! Its very similar to Electrodroid.
Electrodroid lets you download the apk directly.
-
Electrodroid lets you download the apk directly.
Are you sure? Since your link leads to the site with stolen apps. Be careful with APKs from those third party sites.
Trojans or crypto miners on the scopes are the things that now may suddenly happens ;D
Here is the official site https://electrodoc.it/electrodoc/ which has only links to various markets and there is nothing about direct download for their apps.
-
Are you sure? Since your link leads to the site with stolen apps. Be careful with APKs from those third party sites.
That's supposedly a safe site and I ran the apk through online scanners but I've removed the link just in case.
The google Play store doesn't seem to work directly on the 'scope. I guess it's missing some components.
Installing apps is a bit useless anyway, I haven't find a way to launch them except via ADB. None of the scope buttons takes you to the Android home screen (unless somebody at Rigol put in a secret combination). You need an external keyboard to do anything.
-
Installing apps is a bit useless anyway, I haven't find a way to launch them except via ADB. None of the scope buttons takes you to the Android home screen (unless somebody at Rigol put in a secret combination). You need an external keyboard to do anything.
Did you try to remap one of the scope buttons for a home screen launch?
Another possibility is to remap one of the scope buttons for a custom launcher with a list of installed apps.
-
Did you try to remap one of the scope buttons for a home screen launch?
How would I do that?
-
The easiest way is to try to install Button Mapper since it supports custom keycodes if I remember correctly.
This video is just for demoing its main concept.
video (https://www.youtube.com/watch?v=G9mJyJDOfI4)
-
Is this possible with the standard firmware or do you need the firmware version 1.02?
ps: great to see another HP calc. lover ;-)
Who's laughing now? :-DD
-
Is this possible with the standard firmware or do you need the firmware version 1.02?
Any firmware will do.
The updates don't change the android system, only the contents of the /rigol folder.
-
And the voltage accuracy is great also.
5mV/div is interesting..
Here is 5mV.
[attachimg=1]
-
200mV and 2V
[attachimg=1]
-
I found some keyboard shortcuts that work on the DHO. Plug in a keyboard and try these:
Win+ENTER - go to Android home screen (there's nothing there, just a big Rigol logo as wallpaper).
Win+B - open the web browser (lightning (https://play.google.com/store/apps/details?id=acr.browser.barebones&hl=en&gl=US)).
Alt-TAB - open the task switcher (open the web browser first so you have something to switch :) ).
Finally...
Win+N - open the Android notifications. Here you can increase your screen brightness(!) and if you touch the gear at the top you can go into system settings and set up your WiFi. No Ethernet cable or ADB needed :-)
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1931988;image)
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1931994;image)
-
Also this:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1931967;image)
All we need now is a launcher to put app icons on the home screen and we have a full Android device. Anybody know a good one?
-
can we get back on how to hack DHO800 to DHO924S (full LA with AWG capability) while keeping serial number and use latest FW? i have enough android apps to play with..
I've used my Micsig to show PDFs while I was assembling something. The screen is bigger than my phone.
-
I agree, perhaps it would be worth starting a dedicated thread with the list of possibly useful apps on the scopes with Android, including a custom launcher, etc. ;)
-
Let's get back to the actual hacking.
We were able to get the 804 up to 100Mhz and 50Mpts of memory relatively easily.
And the actual bandwidth is even twice as high, 200Mhz.
What is still missing...
E.g. the 2ns/div. and the CAN and LIN decoder function.
We assume that the 800 and 900 platforms are identical, except for the LA part.
But something must be different, because 924 scopes have 250Mhz bandwidth, measured a little more.
Let's think about this again.
-
We were able to get the 804 up to 100Mhz and 50Mpts of memory relatively easily.
And the actual bandwidth is even twice as high, 200Mhz.
Yep.
What is still missing...
E.g. the 2ns/div. and the CAN and LIN decoder function.
On the 800?
That's all inside a huge ".so" file. At first I thought those functions would be in Java but they're not. Almost all the 'scope functions are written in C++ and are in a binary ".so" file. It's going to be difficult to modify that.
If you need those functions then just push a DHO924 vendor.bin and ignore the few pixels of offset on calibration. It's annoying but it won't really affect much. Most people only seem to have offset on a single channel.
(I'm still not sure why calibration is different between them ... my gut feeling is that it ought to be solvable but I've stopped caring about the extra bandwidth given the sample rate)
We assume that the 800 and 900 platforms are identical, except for the LA part.
Yep.
But something must be different, because 924 scopes have 250Mhz bandwidth, measured a little more.
It's all software: Something inside that ".so" file is looking at the model name in vendor.bin and doing things differently on the DHO900.
-
PS: I'd love to know what measured bandwidth is with a DHO914 vendor.bin.
-
Well...I could do this in the next days.
-
Also: Does a 914 vendor.bin calibrate OK?
-
Well...I could do this in the next days.
Ehh...do we have a 914 bin avaible ? And a 924 ?
-
Ehh...do we have a 914 bin avaible ?
I've never seen one.
And a 924 ?
There's a 924 on page one of this topic. Post #5 IIRC.
-
That means nobody successful yet with 800 to 924S conversion with latest fw? other than try to make it a smartphone device? So i will stick with hubertyoung fw 1.14 924S until my project finished... that trick hasnt obsolete yet.
-
That means nobody successful yet with 800 to 924S conversion with latest fw? other than try to make it a smartphone device? So i will stick with hubertyoung fw 1.14 924S until my project finished... that trick hasnt obsolete yet.
The 'S' has an extra PCB with the signal generator on it. How will you get that via a firmware update?
PS: Who made you into the thread police? Figuring out how to get to the Android settings for WiFi setup and installing other apps is definitely hacking.
I also figured out how to control the screen brightness. Somebody was complaining earlier that the screen wasn't bright enough.
-
I don't have a DHO800 scope yet but I'm ordering one soon :)
I've ordered a DHO804 from Aliexpress https://www.aliexpress.com/item/1005005962731116.html (https://www.aliexpress.com/item/1005005962731116.html) for only £321 (chinese singles day).
To my surprise I've got the scope only 3 days later without having to pay any other VAT or customs fees (probably was shipped from UK not China). Brilliant deal!
I've plugged it to my LAN network, pulled the Key.data and vendor.bin files (via adb) and installed these 2 licenses: BW7T10.lic RLU.lic to increase the front end bandwidth and the memory depth.
The whole process was painless and took less than 5 min.
I've also noticed an SSH server running on the scope. Does anyone know what's the default root password?
hint: pasword -> no; but you can install pub certificate for this into root account. this is with adb. it doesn't survive reboot.
-
I've also noticed an SSH server running on the scope. Does anyone know what's the default root password?
hint: pasword -> no; but you can install pub certificate for this into root account. this is with adb. it doesn't survive reboot.
You can use 'adb shell' and then type 'su', for root privileges. ('exit' twice to get back to your pc shell.)
-
I don't have a DHO800 scope yet but I'm ordering one soon :)
I've ordered a DHO804 from Aliexpress https://www.aliexpress.com/item/1005005962731116.html (https://www.aliexpress.com/item/1005005962731116.html) for only £321 (chinese singles day).
To my surprise I've got the scope only 3 days later without having to pay any other VAT or customs fees (probably was shipped from UK not China). Brilliant deal!
I've plugged it to my LAN network, pulled the Key.data and vendor.bin files (via adb) and installed these 2 licenses: BW7T10.lic RLU.lic to increase the front end bandwidth and the memory depth.
The whole process was painless and took less than 5 min.
I've also noticed an SSH server running on the scope. Does anyone know what's the default root password?
Try admin Or RIGOL(rigol)
-
Corrupted SD card?
I was able to back up /rigol /config /data /dev /sbin using adb.
I tried to 'adb pull /rigol/data/*' <- this is bad syntax and did not work, maybe damaged something
Wifi, keyboard, mouse are working.
I did not backup the SD.
Win-n gives this message.
"Damaged Storage, Storage damaged. You may have to reformat it."
Scope otherwise is functional.
Sometime during all of this I upgraded the firmware to 1.01. Didn't notice any problems until I figured out the "win-n" thing.
-
Under Storage settings:
334MB used of 26.00GB
SD card: corrupted
-
I tried to 'adb pull /rigol/data/*' <- this is bad syntax and did not work, maybe damaged something
Should be: 'adb pull /rigol/data/.'
But '*' won't damage anything - it's a pull request.
FWIW: Mine says that, too, but the 'scope seems to work OK so I ignored it. I have a copy of my /rigol folder so I can re-image the SD card if it ever fails.
Anybody else tried this? Do you get that message? Maybe they're all like that... :-//
-
Yeah I get the same error. I did pull some files and also push a few with ADB before I managed to get to the notifications menu (thanks fungus). So it seems that message might be there on all of these
-
I thought it was because of the hundreds of times I pushed files to it then instantly rebooted. :-DD
-
Corrupted SD card?
No worries about it. I think this is some kind of bug. Because I have the same error right out of the box.
Probably because the system expected to be booted from a real NAND flash rather than an SD card, and it tried to read the SD card as a normal storage device but failed.
Rigol didn't bother the Andriod too much, I believe they just downloaded the Andriod7 SDK from the dev board manufator when they developing the software. :-DD
-
Yep. We're not supposed to be seeing this stuff so they simply don't care.
-
Thanks Guys, glad to know I'm not the only one seeing the corrupted SD card message. Probably will do a backup before I get too carried away.
-
Thanks Guys, glad to know I'm not the only one seeing the corrupted SD card message. Probably will do a backup before I get too carried away.
It doesn't say it's "corrupted"...
-
See #462. Settings->Storage settings. What does yours say?
-
See #462. Settings->Storage settings. What does yours say?
OK, it says it there.
I'm still not worried though.
Edit: I see it has "e2fsck" in the system. Who's brave enough to try to use it? :popcorn:
adb shell e2fsck
-
I'm not going to mess around with mine at that level... :)
-
I'm not sure but clicking on that message android system should offer option to fix this.
Anybody try that?
-
Hey everybody :)
I just got my DHO 914S and thought I would join the fun.
I have two projects I thought would interest you all.
1. I'm designing a front cover for the 800/900 Series to be 3D printed. I'm planning on finishing the first prototype today.
2. I want to build myself one of those DIY PLA2216 described here on [Climbers.net][/https://climbers.net/sbc/clone-pla2216-logic-probe-analyzer/]
However, I plan on improving the project in the way the author (Nikki Smith) proposes on the page. He mentions that he is working on those improvements himself.
Does anybody have information on the progress of his second version?
-
However, I plan on improving the project in the way the author (Nikki Smith) proposes on the page. He mentions that he is working on those improvements himself.
Does anybody have information on the progress of his second version?
This might be of interest (check the whole thread from the linked post onwards):
https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5097933/#msg5097933 (https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5097933/#msg5097933)
-
However, I plan on improving the project in the way the author (Nikki Smith) proposes on the page. He mentions that he is working on those improvements himself.
Does anybody have information on the progress of his second version?
This might be of interest (check the whole thread from the linked post onwards):
https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5097933/#msg5097933 (https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5097933/#msg5097933)
are there low cost logic probe available for sale? i cant find a link or price. do we have to build our own?...
-
are there low cost logic probe available for sale? i cant find a link or price. do we have to build our own?...
The low-cost version (which can only handle TTL/CMOS levels) is available on ebay.com. Search for "MSO5000 logic probe" or "PLA2216". Should be $70 to $80, including a set of cheap grabbers.
-
I performed a backup test of the SD card without removing the warranty sticker.
I tested the received file with the script from the link:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5165031/#msg5165031 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5165031/#msg5165031)
Positive result.
Backup time less than 1 hour.
The test was performed on Linux.
I fixed it a bit, now it works every time I start it.
adb connect <IP Address>:55555
adb root
adb connect <IP Address>:55555
adb pull /dev/block/mmcblk1 mmcblk1.img
If someone has removed the warranty sticker, please perform a test of starting the oscilloscope from the SD card with the content of the file received as above.
I don't have that option
-
Hi
I'm here with a quick update on the front cover.
I have attached a quick and dirty render of the first version.
After a test print I will post the cad files on my grabcad page, https://grabcad.com/jakob.holz-1
Please share your thoughts and suggestions.
Have a nice day, bye!
-
I see it has "e2fsck" in the system. Who's brave enough to try to use it?
“e2fsck -n” will run the command in readonly mode and will not make any changes to the file system so you can get an idea what the corruption is.
-
I'm here with a quick update on the front cover.
I have attached a quick and dirty render of the first version.
After a test print I will post the cad files on my grabcad page, https://grabcad.com/jakob.holz-1
Please share your thoughts and suggestions.
Will there be a bit of extra room for adhesive padding strips (felt or similar)? Might be a good idea to avoid scratch marks on the scope, and also gives a bit more tolerance on the dimensions.
Is the Rigol logo on the front raised? How would you 3D-print this -- doesn't the lid get printed lying face-down?
-
Is the Rigol logo on the front raised? How would you 3D-print this -- doesn't the lid get printed lying face-down?
You fill it with support material then pull it out afterwards.
-
Is the Rigol logo on the front raised? How would you 3D-print this -- doesn't the lid get printed lying face-down?
You fill it with support material then pull it out afterwards.
Not sure how you are envisioning that. Do you propose to print the whole lid face-up, with mountains of support material on the inside and below most of the edges?
Or print if face-down, with a 0.5 mm layer of support material everywhere except where the letters are? How would you remove that material and get a reasonably unmarred surface? (Maybe if you have a multi-material printer and can load a dedicated support material which does not bond strongly with the main layer. But even then it seems a challenging geometry.)
I would rather go with a smooth front without any logo, which you can print face-down and get a nice texture from your printer's bed surface. Or maybe an embossed logo can work, if the recessed areas of the letters are not too wide.
-
Hello and thank you very much for your suggestions.
First I should clarify a couple of things:
1. This design should be printable without any support material.
2. By printing the cover standing up on the bottom of the cover I can angle the top of the cover such that the overhang can be printable.
I have chosen to print it standing up due to two concerns:
1. The latch.
The latch has to be printed such that the layer lines flow parallel to the bending force (please look at figure1 for this).
The latch could be printed this way with the cover laying on its front face but than the latch would have less material supporting it without making it bulkier.
2. The front surface.
It would look very nice with a textured build plate. But with a flat (glass top) which are still very popular this would give it an "ironed" look which I do not like. So the entire esthetic would depend on your build plate, and the goal of a good design is to avoid that.
(although I have to admit thinking about it, a textured look would be very nice ^-^)
3. Round edges.
Round edges with a big radius like here can not be printed lying flat because at the bottom this results in unprintable overhangs.
You could say: "Don't use round angles then." -No, it looks nice. The Rigol design esthetic is very pointy with lots of sharp edges and pointy corners, a slight round over would defuse this a bit imo. (but I'm en engineer and not a designer, so what do I know...).
4. Embossing
The embossing can stick out (like it currently does) or cut in to the front face.
Both have the same problem when printing it attached to a side wall eg. the first line is unsupported (please look at figure2).
But with the logo sticking out only 0.4mm this is less than one layer line width so it will actually be supported.
The problem comes when the wall is printed at an angle (like here) the solution is to add a taper at the bottom so the overhang is 90 degrees.
Note: I will have to ad a steeper bootom taper than it is the case currently to make the model printable.
So those are my thoughts.
I will try the design on an ultimaker 5.
If it works, great. If not, I will try a simpler front geometry and print it flat like you suggested.
Again thank you very much for your suggestions and have a great day.
Bye.
-
Hi. What about the HDO802? Can it be upgraded? And to which model, if possible?
-
Hi. What about the HDO802? Can it be upgraded? And to which model, if possible?
You can upgrade it to a HDO812 with 50Mpts memory. Measured bandwidth is about 200Mhz.
-
Please tell me, if I have a DHO802, what should I write in these lines?
"rem TESTED on DHO804: RLU BW7T10
rem For DHO914, probably: BODE BW15T25
set options=RLU BW7T10"
I'm sorry, this is my first time doing this
-
The "set options=RLU BW7T10", which is already there, should be just what you want. RLU means the memory upgrade, BW7T0 the bandwidth upgrade from 70 to 100 MHz. The two "rem... " lines are just comments and you can leave them unchanged.
-
Like this:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1937394;image)
Everything else is not necessary/possible.
-
Hi. What about the HDO802? Can it be upgraded? And to which model, if possible?
You can upgrade it to a HDO812 with 50Mpts memory. Measured bandwidth is about 200Mhz.
iirc the 802 front end all populated for 4 channels, except no BNC input. am i correct and if its possible to upgrade to 4 channels? by boring 2 holes on the front?
-
iirc the 802 front end all populated for 4 channels, except no BNC input. am i correct and if its possible to upgrade to 4 channels? by boring 2 holes on the front?
No idea but would you do it for 50 bucks difference in price?
You'd have to buy two more probes as well...
-
Plus chances are high that you have to populate missing parts on the board for ch3 and ch4.
-
iirc the 802 front end all populated for 4 channels, except no BNC input. am i correct and if its possible to upgrade to 4 channels? by boring 2 holes on the front?
No idea but would you do it for 50 bucks difference in price?
You'd have to buy two more probes as well...
the damage has been done. he already bought it and seek to upgrade. which one is better? $50 hack? or $100 hack?
-
The first thing I did in mine was to put an external 92mm ventilator. Got rid of the noise. Attached to plastic ties.
-
The first thing I did in mine was to put an external 92mm ventilator. Got rid of the noise. Attached to plastic ties.
Bravo! I like this because it's comical and seems like something I would do. I remember hot gluing an AC-powered soldering fume extractor fan to a DIY soldering iron power unit I built because the PWM control circuit I designed kept getting too toasty.
-
After the purchase, I monitored the periodic interference in the amplifier. And it was impossible to hear it in the speaker because of the DHO noise. And I get tired of the long noise.
-
The first thing I did in mine was to put an external 92mm ventilator. Got rid of the noise. Attached to plastic ties.
Does it blow or suck? What's your system temperatures before/after?
-
Bravo! I like this because it's comical and seems like something I would do.
That was my first thought, too, as soon as I saw the VESA screw holes.
(I don't think they'll line up with a standard size fan though)
I've got a couple of really silent 120mm fans left over from a PC build. I might give them a go. I'm not sure which way the air should go though. In or out?
-
The outer one blows inside the case. The temperature on the radiator in different places is about 38. The temperature of the processor in the DHO interface after warming up to 52 max.
-
120 will rest on the bottom. DHO stands with a tilt. Therefore, I stopped at 92.
-
Bravo! I like this because it's comical and seems like something I would do.
That was my first thought, too, as soon as I saw the VESA screw holes.
i also have a few that size of fans and it will be very easy to do. but since i have no problem with noise yet, i'll keep that for later. what i would like to do in case if i do it is automatic power cutoff when fan not rotating, got blocked or end of life. we can detect this from sense/pwm line in 3 or 4 wires fan. i got the idea from dave's video removing the built-in fan and dso got halted. i learnt this technique from my big printer that was not turning on, i figured its fan got blocked by disintegrating foam meant for sealing... removing those stucked foams, the fan rotating again and my printer is working. i guess its a safety feature, suitable when fan operation is critical. ymmv.
-
The DHO800 fan is noisy, for sure, but for some reason I don't find it too annoying. Not sure why.
Also noteworthy is the complete lack of any discussion on fan replacement in the DHO800/DHO900 threads. Go figure.
That post did not age well. ;)
-
Updated my DHO802 using the method from #334. Now the frequency is 100MHz, the memory is 50. Tell me, 200MHz won't work?
-
Updated my DHO802 using the method from #334. Now the frequency is 100MHz, the memory is 50. Tell me, 200MHz won't work?
No, since there is no 200 MHz model in the DHO800 series. But the actual bandwidth of the 100 MHz model is significantly higher, about 200 MHz -- there are measurements somewhere in this long thread. So I think you are all set regarding upgrades.
-
That's great! Everything turned out to be very simple, although you have to read the branch with a translator)). Can you also tell me if an update to DHO is released, should I reset the settings?
-
Can you also tell me if an update to DHO is released, should I reset the settings?
That should not be necessary. The installed upgrades look to the scope firmware just like regular options purchased from Rigol. (Which are installed the same way, via a SCPI command.) So the upgrades should just stay in place when you upgrade to a new firmware.
-
Also noteworthy is the complete lack of any discussion on fan replacement in the DHO800/DHO900 threads. Go figure.
That post did not age well. ;)
It was correct up 'til then. :-DD
-
Updated my DHO802 using the method from #334. Now the frequency is 100MHz, the memory is 50. Tell me, 200MHz won't work?
It already did.
-
Bravo! I like this because it's comical and seems like something I would do.
That was my first thought, too, as soon as I saw the VESA screw holes.
i also have a few that size of fans and it will be very easy to do. but since i have no problem with noise yet, i'll keep that for later. what i would like to do in case if i do it is automatic power cutoff when fan not rotating, got blocked or end of life. we can detect this from sense/pwm line in 3 or 4 wires fan. i got the idea from dave's video removing the built-in fan and dso got halted. i learnt this technique from my big printer that was not turning on, i figured its fan got blocked by disintegrating foam meant for sealing... removing those stucked foams, the fan rotating again and my printer is working. i guess its a safety feature, suitable when fan operation is critical. ymmv.
My computer with 5 coolers +2 video coolers is quieter than DHO with stock. People have different reactions to noise. I can't stand him. Even if he will appear occasionally. And the cooler that stands inside cannot be made quieter. The blades will always growl. It's made like a rattle.
-
... And the cooler that stands inside cannot be made quieter. The blades will always growl. It's made like a rattle.
It's more than possible since I've already been working on that for some time and have several very promising concepts to achieve that without external fans, but it will definitely require SLS-printed parts.
Also interesting thing that I've found out during different simulations is that the massive bottom part works mainly as a passive heatsink while the weak top part tries to cool 6W Rockchip and 5W Zynq chips. >:D
-
Nice simulation and rendering work!
What is the temperature range for that false-colour scale? The visual impression it gives is "from darn hot to ice-cold", but intuitively I would not expect a huge temperature gradient across a metal part that conducts heat quite well?
-
It depends on airflow, but in general about 10 degrees Celsius.
As you can see hottest areas have too little heatsink body to effectively dissipate that much heat in a short time.
-
As you can see hottest areas have too little heatsink body to effectively dissipate that much heat in a short time.
Yeah, well, they will have to rely on heat conduction to the area with the cooling fins -- which is not that far away.
I don't find a 10 degree temperature gradient too disconcerting, and I guess neither did the Rigol engineers. Otherwise they could easily have made the main base plate of the heat spreader a tad thicker, for improved conduction away from the hot spots (or rather warm spots). That would not have requried any change to the overall heat spreader, fins and fan arrangement.
What I find a bit suspicious is that the very blocky, compact "fingers" which reach down to the FPGA and CPU are already showing up as noticeably warmer than the main heat spreader plate directly above them. Shouldn't heat conduction be very effective across those short length scales and compact metal parts?
-
What I find a bit suspicious is that the very blocky, compact "fingers" which reach down to the FPGA and CPU are already showing up as noticeably warmer than the main heat spreader plate directly above them. Shouldn't heat conduction be very effective across those short length scales and compact metal parts?
Eagle eyes. That's because of the dark tint from the shadow of the bottom view which I forgot to hide before making those screenshots ::)
-
I also tried this cooler, without the case. He gets very tight there. But it was still audible.
-
I also tried this cooler, without the case. He gets very tight there. But it was still audible.
I think it'll be difficult to silence it with an internal fan but did it make a significant difference?
-
I did not measure the temperature and close the lid when I realized that it was also loud with him. It was just interesting for me to try with such blades.
-
From an earlier posting by Serg65536:
DHO800/DHO900 UNLOCK TOOLS
1) Install GOLang distribution
2) In the "run_DHO_Tools.bat":
- set the GO installation directory path
- set the IpAddress variable (your scope's address is on the IO tab of the "Utility" window)
- change options list, if DHO900
- change scopeID, if DHO900
- if you don't want to create a backup file and pull it to the computer, delete line 35, or make it comment like this:
rem call "adb\05 make Backup And pull it - adb rm updateGEL, sh buildGEL, pull.bat"
3) Run the "run_DHO_Tools.bat"
4) Send the generated SCPI commands to the scope via the SCPI browser tab, opened by the script. Common command view:
:SYSTem:OPTion:INSTall DHOX00-<option>@XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Scope reboot is not needed.
5) Check BW limit on the "About" tab and the memory depth (for the DHO804) on the "Options" tab of the "Utility" window.
PS: To remove installed options use the "adb\03 adb remove ALL options.bat" file or the ":SYSTem:OPTion:UNINstall" command from p268 of the DHO800/DHO900 Programming Guide.
UPDATE REASON: extending the description text.
All the necessary files and info are in this EEVBlog thread. Once you've run the batch file and generated the license key(s), be sure to copy the license string(s) from the SCPI_commands_generated.txt file (NOT from your terminal window) to avoid inserting any extraneous characters into your license string.
BTW, the measured bandwidth on my newly upgraded DHO914S is 265 MHz on each channel. Of course, activating more than one channel at a time cuts the sampling rate, so the bandwidth will be decreased.
What is "GOLang"? I did a keyword search in this entire discussion, and only your two posts appear in the results, neither of which explain what "GOLang" is or how it is to be used. I also cannot find it inside your achive, which has the following files...
[attach=1]
-
I've ordered a DHO804 from Aliexpress https://www.aliexpress.com/item/1005005962731116.html (https://www.aliexpress.com/item/1005005962731116.html) for only £321 (chinese singles day).
I've plugged it to my LAN network, pulled the Key.data and vendor.bin files (via adb) and installed these 2 licenses: BW7T10.lic RLU.lic to increase the front end bandwidth and the memory depth.
The whole process was painless and took less than 5 min.
Clicking your AliExpress link shows the current price to be US$373.44 (free shipping) for the same DHO804 model, which seems to be less than the price you paid, at least, at today's exchange rate. Actually, I see a $3 off coupon, which brings it to US$370.44. Nice. But did it include the LITEON branded ower supply adapter brick? I assume that's the "good one"? Is the LENOVO one the good one? Also, what kind of wall socket plug did it come with? (Japan uses the US style plug.) Looking through the photo reviews on that AliExpress seller I see some people with the LITEON and others with the LENOVO.
I also see from photo reviews how reflective that screen is. My goodness! I don't think even the earliest lossy iMacs were that bad. But for the price, I suppose it can be overlooked (or not, depending on how your eyes focus).
So did you use the "GOLang" hack? I still can't figure out what the heck that even means.
-
I got my hands on the firmware version 00.01.02 from some shady source and I performed the following test:
Starting with F/W version 00.01.14, push vendor.bin, upgrade to F/W version 00.01.02,self-cal.
Result: DC offset on channel 3.
Starting with F/W version 00.01.00, push vendor.bin, upgrade to F/W version 00.01.02,self-cal.
Result: No obvious offset on all channels, similar to the hack performed on F/W version 00.01.14 before.
Since Rigol hasn't officially announced F/W version 00.01.02 and because of the shady nature of the source I got it, I think it would be better not to spread the F/W for now. :-X Just FYI.
Let me know if you want to see some tests on this F/W. I have a Siglent 2142X AWG on my bench.
-
What is "GOLang"?
https://go.dev/
It's the programming language used for the key generator script.
-
What is "GOLang"?
https://go.dev/
It's the programming language used for the key generator script.
Thanks. I see MacOS mentioned there, which implies we can accomplish this hack without resorting to the Dark Side of Windoze, correct? 8)
-
I've ordered a DHO804 from Aliexpress https://www.aliexpress.com/item/1005005962731116.html (https://www.aliexpress.com/item/1005005962731116.html) for only £321 (chinese singles day).
I've plugged it to my LAN network, pulled the Key.data and vendor.bin files (via adb) and installed these 2 licenses: BW7T10.lic RLU.lic to increase the front end bandwidth and the memory depth.
The whole process was painless and took less than 5 min.
Clicking your AliExpress link shows the current price to be US$373.44 (free shipping) for the same DHO804 model, which seems to be less than the price you paid, at least, at today's exchange rate. Actually, I see a $3 off coupon, which brings it to US$370.44. Nice. But did it include the LITEON branded ower supply adapter brick? I assume that's the "good one"? Is the LENOVO one the good one? Also, what kind of wall socket plug did it come with? (Japan uses the US style plug.) Looking through the photo reviews on that AliExpress seller I see some people with the LITEON and others with the LENOVO.
I also see from photo reviews how reflective that screen is. My goodness! I don't think even the earliest lossy iMacs were that bad. But for the price, I suppose it can be overlooked (or not, depending on how your eyes focus).
So did you use the "GOLang" hack? I still can't figure out what the heck that even means.
You can activate any these license with the Rigol tool provided on this thread. It serves the same purpose, just easier to handle since it has a GUI. Just FYI.
-
I've ordered a DHO804 from Aliexpress https://www.aliexpress.com/item/1005005962731116.html (https://www.aliexpress.com/item/1005005962731116.html) for only £321 (chinese singles day).
I've plugged it to my LAN network, pulled the Key.data and vendor.bin files (via adb) and installed these 2 licenses: BW7T10.lic RLU.lic to increase the front end bandwidth and the memory depth.
The whole process was painless and took less than 5 min.
Clicking your AliExpress link shows the current price to be US$373.44 (free shipping) for the same DHO804 model, which seems to be less than the price you paid, at least, at today's exchange rate. Actually, I see a $3 off coupon, which brings it to US$370.44. Nice. But did it include the LITEON branded ower supply adapter brick? I assume that's the "good one"? Is the LENOVO one the good one? Also, what kind of wall socket plug did it come with? (Japan uses the US style plug.) Looking through the photo reviews on that AliExpress seller I see some people with the LITEON and others with the LENOVO.
I also see from photo reviews how reflective that screen is. My goodness! I don't think even the earliest lossy iMacs were that bad. But for the price, I suppose it can be overlooked (or not, depending on how your eyes focus).
So did you use the "GOLang" hack? I still can't figure out what the heck that even means.
You can activate any these license with the Rigol tool provided on this thread. It serves the same purpose, just easier to handle since it has a GUI. Just FYI.
Thank you for your kindness in mentioning that, but I'm afraid I am not adept at finding it. I did a keyword search for Rigol tool, with and without quotes, but I am not spotting it. Could you please provide a link to it?
-
What is "GOLang"? I did a keyword search in this entire discussion, and only your two posts appear in the results, neither of which explain what "GOLang" is or how it is to be used.
Did you google it?
-
I've ordered a DHO804 from Aliexpress https://www.aliexpress.com/item/1005005962731116.html (https://www.aliexpress.com/item/1005005962731116.html) for only £321 (chinese singles day).
I've plugged it to my LAN network, pulled the Key.data and vendor.bin files (via adb) and installed these 2 licenses: BW7T10.lic RLU.lic to increase the front end bandwidth and the memory depth.
The whole process was painless and took less than 5 min.
Clicking your AliExpress link shows the current price to be US$373.44 (free shipping) for the same DHO804 model, which seems to be less than the price you paid, at least, at today's exchange rate. Actually, I see a $3 off coupon, which brings it to US$370.44. Nice. But did it include the LITEON branded ower supply adapter brick? I assume that's the "good one"? Is the LENOVO one the good one? Also, what kind of wall socket plug did it come with? (Japan uses the US style plug.) Looking through the photo reviews on that AliExpress seller I see some people with the LITEON and others with the LENOVO.
I also see from photo reviews how reflective that screen is. My goodness! I don't think even the earliest lossy iMacs were that bad. But for the price, I suppose it can be overlooked (or not, depending on how your eyes focus).
So did you use the "GOLang" hack? I still can't figure out what the heck that even means.
You can activate any these license with the Rigol tool provided on this thread. It serves the same purpose, just easier to handle since it has a GUI. Just FYI.
Thank you for your kindness in mentioning that, but I'm afraid I am not adept at finding it. I did a keyword search for Rigol tool, with and without quotes, but I am not spotting it. Could you please provide a link to it?
You can find it on #31 of this thread
-
Edit: Asked multiple people, rolling back my oscilloscope to the original state, and the issue of a second waveform appearing and filker at a low triggering level is still there. Seemed to be a widespread BUG. I have mentioned this in the BUG thread.
NOT a bug, just something in your signal causing false triggers.
-
@akkk44: Please do try the "Noise rejection" switch in the trigger dialog, as I suggested in the bug thread where you posted this in parallel. And let's please stop the discussion in this thread here, since it has nothing to do with hacking.
-
Multiple DHO800 owners have also confirmed this happens to them.
That doesn't mean it's a bug.
Trigger is a circuit that detects a rising voltage. 12 bit resolution means it can "see" (and react to) things that an 8 bit trigger doesn't.
Try turning on the noise reject in the trigger and see if that helps.
Try stopping the 'scope and zoom in on the undesired trigger point, see what's there.
Are you using 50 Ohm terminated cable?
Edit: Should probably be in the "Test and compare" thread.
-
Hi all,
Not so easy to climb on the bandwagon, 22 pages to browse.
I was going to place an order for a Rigol 814, now I am not sure to understand all hacks possibility.
If I buy a 804 hacks will bring it to the same level of a 814, or are there still advantages to buy a 814?
Thank you
-
Hi all,
Not so easy to climb on the bandwagon, 22 pages to browse.
I was going to place an order for a Rigol 814, now I am not sure to understand all hacks possibility.
If I buy a 804 hacks will bring it to the same level of a 814, or are there still advantages to buy a 814?
Thank you
Adding the 100 MHz option (which results in an effective bandwidth of ~200 MHz) and the 50 MPts memory option are the two hacks which are absolutely straightforward and robust. These options are activated using the same mechanism which Rigol themselves use when they sell you the options.
The only difference between an upgraded 804 and an 814 scope is the different digit printed on the front panel. ;) The four probes shipped with the 804 are also the same as the 814 probes (150 MHz bandwidth).
There is a more "aggressive" hack which lets a DHO8x4 scope assume it is a 900-series model, by replacing or modifying the vendor.bin file on its internal SD card. This enables even higher bandwidth (exceeding the Nyquist limit in some settings!) plus triggers and decoders for CAN and LIN protocols. But it has shown side effects in some units, with calibration offsets which are still under investigation. Not recommended at this time if you want to focus on actually using your scope, I'd say.
-
Hi all,
Not so easy to climb on the bandwagon, 22 pages to browse.
I was going to place an order for a Rigol 814, now I am not sure to understand all hacks possibility.
If I buy a 804 hacks will bring it to the same level of a 814, or are there still advantages to buy a 814?
Thank you
Like you, I have not yet purchased the scope. I have been considering the DSO804 in hopes of figuring out the precise steps to hacking it to a better model. This thread does not contain a single post with a nice series of steps though. Instead we have this confusion...
1. souldevelop in Post#31 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077954/#msg5077954) introduces a tool he created. But you must download that tool in two parts, given in posts #32 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077957/#msg5077957) & #33 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077960/#msg5077960). I wish it were that simple, but it's not. If you keep reading page after page, we see additions. Some people are talking about the requirement to perform Calibration, but of course no steps are given, so we who don't yet have a scope are confused by what must be done, how it is to be done, and when.
2. Fungus in Post#111 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126355/#msg5126355) gives some updated steps, but he does things a little differently with a MANUAL INSTALL of vendor.bin.
3. Serg65536 in Post#334 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5148330/#msg5148330) then enters the hacking game with something called GOLang (https://go.dev), which I myself know nothing about. You'd think that would be the preferred solution, but then I was told to refer back to the tool created by souldevelop, which I mentioned in #1 above.
NOTE: Fungus in Post#60 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078542/#msg5078542) mentions that some of the hacks (all of the hacks?) which change the 800-series to the 900-series end up adding on screen elements that serve no function at all on the 800-series because the 800-series lacks hardware support for that. I agree 100% with Fungus that I would not want a hack (if possible) that adds disfunctional elements to the LCD of the scope because that is bothersome and confusing.
All said, there is no complete list of steps (e.g., 1, 2, 3... 11, 12, DONE!) to victory when it comes to hacking this scope. Seems you sort of need to know what you are doing with each hack proposed and then play around until it works. That's all I can surmise without yet having a scope in front of me.
Now if someone well informed, having had 100% success with their hack would be nice enough to post all the required steps in sequence for the preferred method, assuming nothing and explaining in detail, that would be idea for people coming to this thread. Then everyone could simply refer to that one post and get down to business in no time.
-
1. souldevelop in Post#31 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077954/#msg5077954) introduces a tool he created. But you must download that tool in two parts, given in posts #32 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077957/#msg5077957) & #33 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077960/#msg5077960). I wish it were that simple, but it's not. If you keep reading page after page, we see additions. Some people are talking about the requirement to perform Calibration, but of course no steps are given, so we who don't yet have a scope are confused by what must be done, how it is to be done, and when.
2. Fungus in Post#111 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5126355/#msg5126355) gives some updated steps, but he does things a little differently with a MANUAL INSTALL of vendor.bin.
3. Serg65536 in Post#334 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5148330/#msg5148330) then enters the hacking game with something called GOLang (https://go.dev), which I myself know nothing about. You'd think that would be the preferred solution, but then I was told to refer back to the tool created by souldevelop, which I mentioned in #1 above.
Option 3 is what you want for an upgrade from the DHO804 to 814. It is a semi-automated script which reads out the unique key file from the scope, and uses that key to generate SCPI commands which unlock the options. (Just like the commands Rigol will give you if you order an option.)
The earlier links you give refer to the more aggressive approach via swapping the vendor.bin file, which historically was discovered first.
-
3. Serg65536 in Post#334 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5148330/#msg5148330) then enters the hacking game with something called GOLang (https://go.dev), which I myself know nothing about. You'd think that would be the preferred solution, but then I was told to refer back to the tool created by souldevelop, which I mentioned in #1 above.
Option 3 is what you want for an upgrade from the DHO804 to 814. It is a semi-automated script which reads out the unique key file from the scope, and uses that key to generate SCPI commands which unlock the options. (Just like the commands Rigol will give you if you order an option.)
The main disadvantage I see in going only with an upgrade to a DSO814 is that you don't get the memory upgrade from 25M to 50M. I'd take the memory upgrade over the bandwidth upgrade, if I had to choose. What are your thoughts about that?
-
The main disadvantage I see in going only with an upgrade to a DSO814 is that you don't get the memory upgrade from 25M to 50M. I'd take the memory upgrade over the bandwidth upgrade, if I had to choose. What are your thoughts about that?
You do get the memory upgrade this way. I explicitly said so in the summary above (#532), and it's all over this thread -- including the post you linked to as your option 3. My thoughts are that, if you want to consider the "hacking" route at all, you will need to put in a little bit of homework. :)
-
If I buy a 804 hacks will bring it to the same level of a 814
You can make it better than the 814.
or are there still advantages to buy a 814?
No.
-
or are there still advantages to buy a 814?
No.
there are. for extra $70 you'll get 100MHz sticker and save some minutes of doing hack job...
-
...for extra $70 you'll get 100MHz sticker and save some minutes of doing hack job...
But you still only get 25Mpts of memory for that extra $70, not 50M.
ebastler informs me (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5194620/#msg5194620) that you get 50Mpts if you apply the GOLang hack from the DHO804 to DHO814.
-
My thoughts are that, if you want to consider the "hacking" route at all, you will need to put in a little bit of homework. :)
Well, apparently that is no longer the case. ;)
Here's a step-by-step video just published on the RetroChannel. I have not validated it, but it looks plausible:
https://www.youtube.com/watch?v=Az9lXMGV_jM (https://www.youtube.com/watch?v=Az9lXMGV_jM)
-
Thank you all, 804 on the way :)
-
...for extra $70 you'll get 100MHz sticker and save some minutes of doing hack job...
But you still only get 25Mpts of memory for that extra $70, not 50M.
ebastler informs me (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5194620/#msg5194620) that you get 50Mpts if you apply the GOLang hack from the DHO804 to DHO814.
he asked what benefit between 804 and 814, both 25Mpts... if you want to step up to DHO900 feature (50Mpts), get ready to waste some minutes more.
-
he asked what benefit between 804 and 814, both 25Mpts... if you want to step up to DHO900 feature (50Mpts), get ready to waste some minutes more.
Just to make sure we are on the same page: The 50 MPts memory is no longer an exclusive DHO900 feature. It has been made available as an official option for the DHO800 in the first (?) firmware update, if I recall correctly. A bit confusing, since there is no updated datasheet which mentions this option, to my knowledge.
-
...for extra $70 you'll get 100MHz sticker and save some minutes of doing hack job...
But you still only get 25Mpts of memory for that extra $70, not 50M.
ebastler informs me (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5194620/#msg5194620) that you get 50Mpts if you apply the GOLang hack from the DHO804 to DHO814.
he asked what benefit between 804 and 814, both 25Mpts... if you want to step up to DHO900 feature (50Mpts), get ready to waste some minutes more.
Even though the 50Mpts is only in the 900, you can unlock it in the 800 without putting in a vendor.bin from the 900. At least that's what I inferred from earlier posts. The unlock procedure is the same as transforming a 804 to a 814. You cannot get the additional V/div ranges or the 250 bandwidth without making it think it's a 900.
-
Well, apparently that is no longer the case. ;)
Here's a step-by-step video just published on the RetroChannel. I have not validated it, but it looks plausible:
https://www.youtube.com/watch?v=Az9lXMGV_jM (https://www.youtube.com/watch?v=Az9lXMGV_jM)
I watched it, it is valid. All of the things he suggests you verify are still accurate.
-
I'm not sure but clicking on that message android system should offer option to fix this.
Anybody try that?
Don't use my advice.
Seems there is an conflicting situation between Rigol application and Android operating system.
I did it and formatting hang at 20%
I could leave it as is but ...
Next step was factory reset from android menu , also don't do this.
After restart I get a bootloop with only some quick flashing text on screen.
Power cycle few times and started with circle logo and erasing message of android recovery.
And the problems begin
Android see storage partition and all OK
Rigol app report negative size.
adb can't connect anymore getting message on screen remote cmd error but in the end I was able to connect only with Total Commander and their plugin
And worst of all trigger malfunction.
What that means is when turn trigger knob I get a violet line on screen and also colour of trigger on top bar change to violet too and no adjustment available.
Try to calibrate no fix,
Overwrite Rigol folder from backup no fix.
Maybe after few power cycle Rigol app "fix" somehow storage partition as I can see that size is pozitive and no more negative as before,but now android complain again about that problem.
Also try to update firmware but no go, getting only execution failure when select update file and try to update.
Anyway for further investigation I did a full backup by this method
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5182476/#msg5182476 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5182476/#msg5182476)
and restored original backup on sdcard, also made with this method
As a note
First time I try from adb console to restore backup, to avoid opening the scope but i killed it, started to write and after some time suddenly (not finished writing) restarted and no more started again so I need to open and write card with external tools.
After that all was fine again.
Taking a quick look at "damaged" backup I can see just in first screen on winhex that are different,looking like some UEFI style partition, didn't check more as lack of time but winhex recognize from start this is an disk image and showing three partitions (but unable to show files) while with original backup can't detect any partition even if I choose this is a disk image.
So android reset change something as is expect to be, but incompatible with Rigol app format.
For those who want to experiment more maybe a launcher or a file browser can be added to Rigol App folder with name help.apk or help_en.apk I don't know if are standalone application one for chinese one for english or parent-child so help is main app and help_en is loaded in case english is selected.
And for missing keyboard maybe installing some version of gboard apk will fix this, if android manage to acces it.
After other problems detected by others now we see problems at level os-application, in the end that looks like an unfinished product or applications made in hurry without basic requirements fixed.
-
After other problems detected by others now we see problems at level os-application, in the end that looks like an unfinished product or applications made in hurry without basic requirements fixed.
I don't recall Rigol ever saying this can be used to run Android apps. There's no way to get to Android via the normal controls.
(Unlike Micsig which has a "home" button, launcher, keyboard, etc.)
-
And I'm not talking about other application but about Rigol sparrow.apk and android operating system.
-
And I'm not talking about other application but about Rigol sparrow.apk and android operating system.
What conflict? My 'scope boots and runs.
-
Mine too.
So? That means is perfect? It's buggy
I'm not here for arguing.
If you have a different opinion feel free to express it, but stop arguing with me.
-
I don't recall Rigol ever saying this can be used to run Android apps. There's no way to get to Android via the normal controls.
What conflict? My 'scope boots and runs.
I don't understand how you can be so cavalier about this.
There seems to be some inconsistency in the file system. It's there right out of the box (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5178210/#msg5178210), at least in some units.
Who knows what the effect will be when you save a lot of screenshots locally, or run the n'th firmware update? The scope might crash due to file corruption. For a "naive" user who has not hacked his way into it beforehand to make a backup copy of the SD card, that could mean sending it in for service. If it only happens after the warranty period, it could cost serious money. Not good.
-
RetroChannel also has video to add WIFI and launcher(details in questions/comments area).
https://www.youtube.com/watch?v=ECc2BdJzZfs (https://www.youtube.com/watch?v=ECc2BdJzZfs)
-
My thoughts are that, if you want to consider the "hacking" route at all, you will need to put in a little bit of homework. :)
Well, apparently that is no longer the case. ;)
Here's a step-by-step video just published on the RetroChannel. I have not validated it, but it looks plausible:
https://www.youtube.com/watch?v=Az9lXMGV_jM (https://www.youtube.com/watch?v=Az9lXMGV_jM)
Nice concise video. I just added that video to the original post.
-
I just created my own DHO914 vendor.bin to see what bandwidth I get using it.
Answer: About 225MHz
This gives about 2.7x oversample when two channels are enabled, which I can live with.
I also get 2ns/div horizontal, 200uV vertical, 50M memory, the extra decoders, and it calibrates the same as the original DHO804.
Maybe the best hack for a DHO804. :)
The only downside is the digital channel thing in the UI.
-
The only downside is the digital channel thing in the UI.
A piece of black masking tape should take care of that. ;)
Edit: Maybe Rigol will provide a reduced-bandwidth setting for the DHO900 series in a future firmware update, either user-selectable or kicking in automatically in 3- or 4-channel mode? Must be a concern for the "real" DHO914 too, and even more the 924.
-
I'm still wondering if I should leave it in or not.
The extra bandwidth is unimportant, I can get 50Mts on a DHO800, I don't really care about the decoders...
It's all down to whether I want to trade 2ns/div for the ugly graphic.
I'm going to sleep on it.
-
I am satisfied with the bandwidth and memory hack, the only thing that is a bit annoying is the missing 2ns/div. ;)
And as for the "missing" decoders, honestly, does anyone really need them?
-
The only downside is the digital channel thing in the UI.
A piece of black masking tape should take care of that. ;)
now, i dont have to... why mask a little bit nice bell and whistle? https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5200419/#msg5200419 (https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5200419/#msg5200419)
(https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/?action=dlattach;attach=1942692;image)
-
Yesterday just received my new DHO804 toy, that I bought with the money from my old DS1054Z I sold in ebay :)
Yesterday I just unlocked 100MHz and the mem depth. Today I fooled it to be DHO924 using the vendor file from the first post.
Of course with the 924 vendor file I get the annoying DC offset, so @Fungus how did you fix that or it is just not seen with 914 one?
Here are the results sampling the same 100MHz SDRAM clock, but using 500 MHz Tek probe, using correspondingly 70, 100 and 250 MHz BW: it seems the pics are too big for the forum, tomorrow I will downscale them and upload them here.
-
Of course with the 924 vendor file I get the annoying DC offset, so @Fungus how did you fix that or it is just not seen with 914 one?
The 914 calibrates OK.
Here are the results sampling the same 100MHz SDRAM clock, but using 500 MHz Tek probe, using correspondingly 70, 100 and 250 MHz BW: it seems the pics are too big for the forum, tomorrow I will downscale them and upload them here.
Haw are you making the pics? Use the 'scope's screenshot function, or (even better) the web interface screenshot.
-
Here are the pics.
I am old school, so I used my phone to take them :)
P.S.: I did the measurement the right way - used the provided probe's spring for the ground connection!
P.S2: The setup is the same as with the old DS1054Z https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg2586828/#msg2586828 (https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg2586828/#msg2586828)
-
Looks about right.
The limits of the 150Mhz Rigol probe are very clear (see image). The 300Mhz harmonic is definitely attenuated by it.
I've measured the bandwidth at every configuration, I get:
70Mhz DHO800: 125MHz measured bandwidth
100Mhz DHO800: 200MHz measured
125MHz DHO900: 225MHz measured
250Mhz DHO900: 280Mhz measured
This was done using a pulse fed into the 'scope via. 50 Ohm terminated coax and measuring the rise time.
Martin72 has confirmed the math (ie. 0.45/rise time) by measuring attenuation of signals from his signal generator.
(my cheapo siggen doesn't go that high... :( )
Why is Rigol so conservative with the labeling? No idea. :-//
-
now, i dont have to... why mask a little bit nice bell and whistle? https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5200419/#msg5200419 (https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5200419/#msg5200419)
(https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/?action=dlattach;attach=1942692;image)
Does the signal generator work? THAT is a hack.
It should probably have its own thread.
-
Does the signal generator work?
looking at D0, some floating signal going on, but proper probe need to be built to avoid damage to fpga pins inside. from reading, fpga can accepts rspecl differential signal safely.
edit: oh you mean the afg module? work in progress, still waiting for parts to arrive.
-
Why is Rigol so conservative with the labeling? No idea. :-//
Good question.
Inspired by the last posts here, I measured a probe from my rigol.
First only the rise time, soon on the R&S generator.
I used the (unfortunately no longer available) bodnarpulser, fitted the probe with a spring and fixed it to the output as well as possible (it's not perfect).
The rise time of the hacked rigol is not influenced by the probe, so it is already over 200Mhz.
Then I connected the same setup to a 500Mhz scope and measured about 1.1ns.
I will verify this with the generator soon.
-
Of course with the 924 vendor file I get the annoying DC offset, so @Fungus how did you fix that or it is just not seen with 914 one?
The 914 calibrates OK.
I can confirm that partly :)
Tonight I decided to try to f*ck the devil once more:
1. I decided to generate vendor file for 914
2. Verified there is no DC offset
3. Decided to use BW option upgrade to 250MHz hoping no offset will be introduced
4. Generated the BW15T25 option and applied it and... offset is there!
Bottom-line: It's not the 924 vendor file that introduces the offset, it is the very 250MHz BW enablement that does it.
So here are two possible reasons - either software i.e. Rigol made sure its not that easy to have the 250MHz BW, either hardware - there might be somewhere small component difference between the 800 and the 900 series in the front-end...
-
Bottom-line: It's not the 924 vendor file that introduces the offset, it is the very 250MHz BW enablement that does it.
So here are two possible reasons - either software i.e. Rigol made sure its not that easy to have the 250MHz BW, either hardware - there might be somewhere small component difference between the 800 and the 900 series in the front-end...
if you copy the whole hubertyoung's 924S fw on dho800, now its 250MHz, but there is no offset, how you explain that?
-
Bottom-line: It's not the 924 vendor file that introduces the offset, it is the very 250MHz BW enablement that does it.
It makes no sense though. Calibration isn't done with a signal that's changing.
there might be somewhere small component difference between the 800 and the 900 series in the front-end...
I don't believe that. I think the firmware does something different when it detects a 924.
-
Bottom-line: It's not the 924 vendor file that introduces the offset, it is the very 250MHz BW enablement that does it.
It makes no sense though. Calibration isn't done with a signal that's changing.
Try it, it costs 5 mins... You already have the 914 configuration, just generate yourself a DHO900 BW upgrade option.
-
Bottom-line: It's not the 924 vendor file that introduces the offset, it is the very 250MHz BW enablement that does it.
So here are two possible reasons - either software i.e. Rigol made sure its not that easy to have the 250MHz BW, either hardware - there might be somewhere small component difference between the 800 and the 900 series in the front-end...
if you copy the whole hubertyoung's 924S fw on dho800, now its 250MHz, but there is no offset, how you explain that?
Damn, I thought I'm done with the hacking...
I haven't open my scope yet so I can not directly dd the hubertyoung's image. I'll try to manually compare firmware content to see what is the difference. I really would like the 250 megs bandwidth without offset.
-
I really would like the 250 megs bandwidth without offset.
But it's not such a big difference in real bandwidth -- not sure whether it is worthwhile. As measured by Fungus,
125MHz DHO900: 225MHz measured
250Mhz DHO900: 280Mhz measured
-
Not sure about that, looking at real 100MHz signal using the right probe:
-
I really would like the 250 megs bandwidth without offset.
But it's not such a big difference in real bandwidth -- not sure whether it is worthwhile. As measured by Fungus,
125MHz DHO900: 225MHz measured
250Mhz DHO900: 280Mhz measured
Yep, and one of those two settings breaks the "2.5x" rule for sample rate with 2 channels enabled.
625MSa/s @ 225MHz gives 2.8x oversample
625MSa/s @ 280MHz gives 2.3x oversample
-
Not sure about that, looking at real 100MHz signal using the right probe:
You're looking at the difference the 300Mhz harmonic makes with a 225Mhz vs. 280Mhz oscilloscope.
That's the sort of setup a marketing department would use. :)
PS: A few 5mV of offset makes zero difference for digital signals.
-
Just FYI, while playing with the upgrade options, I pasted the whole list at once in the web interface of the scope and hit send (strings are intentionally truncated):
:SYSTem:OPTion:INSTall DHO800-BW2T4@7438837537
:SYSTem:OPTion:INSTall DHO800-BW2T8@33526edc3b
:SYSTem:OPTion:INSTall DHO800-BW4T8@6aef25ef93
:SYSTem:OPTion:INSTall DHO800-BW7T10@c648cb912
:SYSTem:OPTion:INSTall DHO800-BW7T15@b9bdc5e27
:SYSTem:OPTion:INSTall DHO800-BW7T20@8bf2c3452
:SYSTem:OPTion:INSTall DHO800-BW10T20@44618ef3
:SYSTem:OPTion:INSTall DHO800-BW15T25@192653e3
:SYSTem:OPTion:INSTall DHO800-AERO@832fc9c2e74
:SYSTem:OPTion:INSTall DHO800-ARINC@e771496048
:SYSTem:OPTion:INSTall DHO800-AUDIO@fa89095f52
:SYSTem:OPTion:INSTall DHO800-AUTO@102a385d266
:SYSTem:OPTion:INSTall DHO800-AWG@efad83ca473e
:SYSTem:OPTion:INSTall DHO800-BND@8720d45f439e
:SYSTem:OPTion:INSTall DHO800-BODE@d07e116934c
:SYSTem:OPTion:INSTall DHO800-COMP@b56e6789a69
:SYSTem:OPTion:INSTall DHO800-COUNT@17ef539118
:SYSTem:OPTion:INSTall DHO800-DG@3950b6c79250f
:SYSTem:OPTion:INSTall DHO800-EMBD@8d316fca563
:SYSTem:OPTion:INSTall DHO800-EYE@cae00e28e8e5
:SYSTem:OPTion:INSTall DHO800-FLEX@b7f26d0c18d
:SYSTem:OPTion:INSTall DHO800-JITTER@1fbd0f7df
:SYSTem:OPTion:INSTall DHO800-MSO@e630514de32b
:SYSTem:OPTion:INSTall DHO800-PWR@4d4d7bf2b911
:SYSTem:OPTion:INSTall DHO800-RLU@ef44597ef58e
:SYSTem:OPTion:INSTall DHO800-RTSA@3aa195bbf20
:SYSTem:OPTion:INSTall DHO800-UPA@bb00db9e8da8
:SYSTem:OPTion:INSTall DHO800-CM_USB@f577d673e
:SYSTem:OPTion:INSTall DHO800-CM_ENET@32dc101b
:SYSTem:OPTion:INSTall DHO800-CM_MIPI@0ae25bf2
:SYSTem:OPTion:INSTall DHO800-CM_HDMI@52fede3a
And out of these 31 options only three were accepted (.lic files were created in the /rigol/data folder) for DHO800, those are expectedly RLU, BW7T10 and... the BND (bundle) one. Not sure what the bundle option should enable, but at least it does not enable additional protocol decoders.
Expectedly for DHO900, additionally the BODE option was accepted.
-
After several self calibrations I saw that all the cal files get modified except "-rwxrwxrwx 1 system system 156 2013-01-18 08:58 cal_lsb.hex".
Can some DHO92X owner share his whole /rigol, /rigol/data folder or at least cal_lsb.hex file (one can delete its Key.data file - I am not interested in it)?
-
After several self calibrations I saw that all the cal files get modified except "-rwxrwxrwx 1 system system 156 2013-01-18 08:58 cal_lsb.hex".
Can some DHO92X owner share his whole /rigol, /rigol/data folder or at least cal_lsb.hex file (one can delete its Key.data file - I am not interested in it)?
you can download and play with hubertyoung's fw in first page. here is the data i extracted sometime ago.. the rigol folder is about 95MB, so not easy to upload.
-
After several self calibrations I saw that all the cal files get modified except "-rwxrwxrwx 1 system system 156 2013-01-18 08:58 cal_lsb.hex".
Can some DHO92X owner share his whole /rigol, /rigol/data folder or at least cal_lsb.hex file (one can delete its Key.data file - I am not interested in it)?
you can download and play with hubertyoung's fw in first page. here is the data i extracted sometime ago.. the rigol folder is about 95MB, so not easy to upload.
Isn't his image an HDO804 one? - "@hubertyoung has provided a DHO804 FW1.14 image with the DHO924 vendor file preloaded".
-
Isn't his image an HDO804 one? - "@hubertyoung has provided a DHO804 FW1.14 image with the DHO924 vendor file preloaded".
@hubertyoung has provided a DHO804 FW1.14 image with the DHO924 vendor file preloaded. It can be extracted using 7zip then flash using HDD Raw Copy Tool (compressed image).
https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8 (https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8)
@Luc7777 provided some guidelines on how has has achieved this.
Hi,
- This is what I've done:
1. Run the Win32 Disk Imager
2. Backup the SD
3. Flash the SD with the image from the link
4. Run the claibartation (offset gone) - device identifies as DHO804
5. Connect the scope to ethernet
6 Run adb:
6.1 adb devices
6.2 adb connect 192.xxx.x.xxx:55555
6.3 "adb pull /rigol/data/vendor.bin"
6.4 backup the generated vendor bin file from the adb folder to a new location
6.5 copy in the adb folder the DHO924 image
6.6 "adb push vendor.bin /rigol/data"
the "precursor" to the hack is here, feel free to follow as to why fw 1.14, instead of fw 1.0.0 (i need to recap)
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg4977448/#msg4977448 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg4977448/#msg4977448)
-
How to use the scope as an android tablet :)
With sound!
0) Open your scope and make full backup of the MicroSD card, with the "HDD Raw Copy Tool" for eg. (compressed image takes ~500MB of disk space only)
1) Find any USB headphones (or other USB sound device identified as headphones with default driver in windows. I've checked two old ones and both are working.).
2) Find a USB hub.
3) Find a USB keyboard with the "home" key.
4) Connect 1), 2) and 3) to the scope. (Reboot was not required in my case, press "win+n" to access system notifications bar, sound levels and settings).
5) Install some simple launcher:
adb connect
adb install yourSimpleLauncherName.apk
6) Install chrome (the last version for the android 7 is chrome 119.0.6045.194, probably, it will argue for absence of play services, but will launch nevertheless).
7) PRESS "Stop" BUTTON (it's required to release CPU resources).
8 ) Press "Home" button on the USB keyboard, select yourSimpleLauncherName and press "always". (This will substitute the com.rigol.launcher, but scope should initialize successfully anyway).
9) Now on boot yourSimpleLauncher should always launch before the "com.rigol.scope" application, and you should be able to switch to yourSimpleLauncher with the "home" key, or with the "alt+tab" keys. (Don't forget to press the "Stop" button to release CPU resources).
10) Enjoy chrome browsing and 1080p YouTube videos with sound and no frame drops.
11) OPTIONAL. If you plan to boot into yourSimpleLauncher and be able to launch the scope app any time later:
- install MyAndroidTools,
- disable "GuardServiceReceiver" for the "com.rigol.launcher" application (MyAndroidTools/apps/com.rigol.launcher/see all component info/broadcast receiver/GuardServiceReceiver).
This will prevent FPGA initialization, reduce CPU usage, thus reducing power consumption (from 2.5 A to 1.2 - 1.4 A @12V), chip temperature, and increase device sustainability.
But in this way, you can launch the RIGOL.SCOPE app from the launcher any time later.
-
Recently picked up 804 and have been trying to understand better how the OS is configured - thanks to all the great info in this thread getting started was easy.
My two main problems with the scope are:
- fan noise
- boot time
Without voiding the warranty the only solution seems to put something into the blades of the existing fan to stop it from spinning, and place a quiet external fan blowing into the case. I have not checked yet if the USB B port in the back has power on it - if yes will use that to drive an external fan.
As for the boot time, I have been looking at Android doze mode - the idea is to bring the power down to the point where the scope could remain booted and allow for a quick turn on - some other ideas would be to use a tftp server and do remote boot, but need to get at the bootloader. Thus far neither sleep or doze has not worked - I think the main reason for the slow boot is the read speed of the SD card - doing a full backup, it shows about 10MB/s.
Now for some info that might be of value to others. I want the scope to have an accurate time when connected to the network - have been able to force it to use an ntp server:
adb shell su -c 'settings put global ntp_server <IP or name>'
One issue I run into was that the timezone was being reset on each boot - sadly they force the timezone in the startup script:
adb shell
su -
cd /rigol/shell; cp start_rigol_app.sh start_rigol_app.sh.orig
sed -i 's?setprop persist.sys.timezone Asia/Shanghai?setprop persist.sys.timezone America/New_York?' start_rigol_app.sh
Given the update .GEL file is just a compressed tar, it should be possible to update the script before the update is run. Adbd is run by default but there is a currently commented out line in start_rigol_app.sh that could shut it down - using WinKey-N combination scroll down to About and click 7 times to enable the standard Android Developer menu.
-
Now for some info that might be of value to others. I want the scope to have an accurate time when connected to the network - have been able to force it to use an ntp server:
ntp works out of the box.
-
My two main problems with the scope are:
- fan noise
- boot time
I'm afraid the boot time is par for the course these days; some other scopes are worse. That's technical progress -- a proper OS booting up for you... ::)
I have not checked yet if the USB B port in the back has power on it - if yes will use that to drive an external fan.
I don't think any USB Device port is supposed to supply power. The USB Host (PC etc.) provides the power; if the Device were to try the same, two sources would be fighting it out.
-
Now for some info that might be of value to others. I want the scope to have an accurate time when connected to the network - have been able to force it to use an ntp server:
ntp works out of the box.
In my case all the hardware is behind a firewall - ntp is provided by local hosts, all Internet connections go through a proxy. Before I made the change I did not check which ntp servers they were using as the default.
-
My two main problems with the scope are:
- fan noise
- boot time
I'm afraid the boot time is par for the course these days; some other scopes are worse. That's technical progress -- a proper OS booting up for you... ::)
I have not checked yet if the USB B port in the back has power on it - if yes will use that to drive an external fan.
I don't think any USB Device port is supposed to supply power. The USB Host (PC etc.) provides the power; if the Device were to try the same, two sources would be fighting it out.
Maybe I am not understanding but if I plug a USB drive or a kbd dongle into the front port, the port will provide the power to it - what I am not sure is what type of port the back USB B port is - I need to look at the manual.
Forgetting the issue of where the power for the fan would come from, has anybody stopped the internal fan and used an external one ( without opening the case ), or are people just adding an external fan and both are running ? Is the internal fan PWM or just runs at the same speed all the time - thanks.
-
Maybe I am not understanding but if I plug a USB drive or a kbd dongle into the front port, the port will provide the power to it - what I am not sure is what type of port the back USB B port is - I need to look at the manual.
The port in the front is a USB Host port. You connect USB Devices to it (memory stick, mouse etc.), and they are controlled by and powered from the Host, i.e. from the oscilloscope.
The port in the back is a USB Device port. You connect a USB Host to it (your PC), and the Host provides power -- although the Rigol scope, acting as a USB Device, does not use that power. But it can't provide power itself since that would clash with the power supplied by the Host.
-
Forgetting the issue of where the power for the fan would come from, has anybody stopped the internal fan and used an external one ( without opening the case )
You mean by poking a stick through the bars? I don't think anybody's tried that yet, no.
-
Maybe I am not understanding but if I plug a USB drive or a kbd dongle into the front port, the port will provide the power to it - what I am not sure is what type of port the back USB B port is - I need to look at the manual.
The port in the front is a USB Host port. You connect USB Devices to it (memory stick, mouse etc.), and they are controlled by and powered from the Host, i.e. from the oscilloscope.
The port in the back is a USB Device port. You connect a USB Host to it (your PC), and the Host provides power -- although the Rigol scope, acting as a USB Device, does not use that power. But it can't provide power itself since that would clash with the power supplied by the Host.
I suspected that it was the case - I guess I can use a USB C splitter, and get the power from there, or just have a dedicated power brick. Most of the time the scope will stay in one place possibly mounted on a VESA mount. The part I am not sure about is stopping the internal fan by 'force' >:D with a piece of wood dowel by poking it through one of the holes in the back.
-
The part I am not sure about is stopping the internal fan by 'force' >:D with a piece of wood dowel by poking it through one of the holes in the back.
It does sound a bit crude, and might cause higher-than-intended current through that fan. Have you tried "passive" solutions? Try guiding the sound by placing some barriers above and/or on the sides behind the scope, maybe an air duct made of styrofoam or such, so less direct sound reaches your ears. If there's a wall behind the scope, that might also reflect the fan noise, and putting some dampening material there might help. All without blocking the airflow, of course.
-
Stopping that fan will also block airflow to the hottest part of the heatsink.
Much better to learn how to remove warranty void stickers without breaking them. :)
-
Without voiding the warranty the only solution seems to put something into the blades of the existing fan to stop it from spinning, and place a quiet external fan blowing into the case.
That´s a really bad idea...
As ebastler already mentioned, the current can increase excessively and thus damage not only the fan but also other components - and then the warranty may also be invalidated.
In general, when modifying/replacing fans, it is important to bear in mind that the original fan was included in the thermal load calculations during development.
Now the internal fan sits directly on the large heat sink and blows through its fins.
If you now want to go along and have a fan blow into the housing from the outside, it has to be "stronger", which could ruin the hope of making the device quieter.
If you ignore this in order to simply make it quieter, the power could be too low and the device could heat up more, which could lead to malfunctions or deviations from the measurement tolerances.
The external fan must then also be attached in such a way that the air flow can enter the housing as unhindered as possible.
This means screwing or gluing and then the warranty is also void.
I would think about it if I were you and weigh up the pros and cons.
-
Stopping that fan will also block airflow to the hottest part of the heatsink.
Much better to learn how to remove warranty void stickers without breaking them. :)
That ^-^ or if they made the fan PWM - an external fan would be able to make it run at a much lower speed. I have a second fan just sitting behind and the Board test shows about 43C CPU and 39C Ambient temps.
All my current computers are either all-in-one with no fan or NUC like boxes - I am not a fan of any noise ( pun not intended ). I watched Dave's fan video while back so I don't recall if he mentioned if it was PWM or not.
-
Without voiding the warranty the only solution seems to put something into the blades of the existing fan to stop it from spinning, and place a quiet external fan blowing into the case.
That´s a really bad idea...
As ebastler already mentioned, the current can increase excessively and thus damage not only the fan but also other components - and then the warranty may also be invalidated.
In general, when modifying/replacing fans, it is important to bear in mind that the original fan was included in the thermal load calculations during development.
Now the internal fan sits directly on the large heat sink and blows through its fins.
If you now want to go along and have a fan blow into the housing from the outside, it has to be "stronger", which could ruin the hope of making the device quieter.
If you ignore this in order to simply make it quieter, the power could be too low and the device could heat up more, which could lead to malfunctions or deviations from the measurement tolerances.
The external fan must then also be attached in such a way that the air flow can enter the housing as unhindered as possible.
This means screwing or gluing and then the warranty is also void.
I would think about it if I were you and weigh up the pros and cons.
I agree - on the plus side we do have built in temp. sensors and it is easy to verify any results. Without those sensors it would be a lot more difficult to know if there is any negative impact. I am sure we all have seen fans that have been on for years full of dust that have stopped working - to be honest I have never measured small 12V fans - not sure if the stall current applies here.
-
The external fan must then also be attached in such a way that the air flow can enter the housing as unhindered as possible.
This means screwing or gluing and then the warranty is also void.
There's 4 screw holes on the back for mounting things.
I was thinking of 3D printing an adapter for a 90mm fan.
-
There's 4 screw holes on the back for mounting things.
That's right, I hadn't thought about it.
I was thinking of 3D printing an adapter for a 90mm fan.
I might find the fan a bit annoying, but it's rarely so quiet here that it's noticeable.
-
there was a time i'm stupid with electronics, but blocking fan with a stick is not one of it. read the manual, if you poke around what not a normal users do, you void the warranty. asking for warranty because of what you did and saying you did nothing is cheating. better learn proper engineering.
-
I did so and forgot. Fixed it on the ties. Silence now. Temperatures are normal. It's an old fan. I checked on it. I ordered a new one, I'm waiting. 92mm
-
Has anybody rebooted into the bootloader or the recovery using adb reboot bootloader or adb reboot recovery ? I recall a post from a person that tried to run fsck and in the end sadly had to void the warranty to resolve it - at least for now I want to play safe.
I want to try to boot it from a USB drive to see if it can boot faster - it would be nice to see how fast it can be. I was thinking that network boot might be faster, but ram to ram copy over the network is not very fast ( at least using adb ):
adb shell 'dd bs=1024 count=100000 if=/dev/zero' | dd status=progress > /dev/null
95878656 bytes (96 MB, 91 MiB) copied, 10 s, 9.6 MB/s
I also tried using ssh pipe from the scope to a Linux box - got about 11.7 MB/s - hope nobody is tempted to make this into a NAS box ;D
I plan to do some more reading on sleep and doze modes in Android 7 - would be nice if they implemented that at the factory and give it as an option. Pressing the power button could have an option of sleep or off.
-
I did so and forgot. Fixed it on the ties. Silence now. Temperatures are normal. It's an old fan. I checked on it. I ordered a new one, I'm waiting. 92mm
Just to make sure I understand - you did or did not stop the built in fan ? If yes what method did you use ?
-
I did so and forgot. Fixed it on the ties. Silence now. Temperatures are normal. It's an old fan. I checked on it. I ordered a new one, I'm waiting. 92mm
Just to make sure I understand - you did or did not stop the built in fan ? If yes what method did you use ?
I opened the case, removed the fan, connected the external one. If you put 120mm, it will rest against the table. That's why I chose 92. I bought from the Chinese, so I don't really care about the warranty.
-
Thanks for the update - I suspect with a good quality fan one might get better thermals compared to the built in one. I believe most fans operate better in push mode compared to the pull, the only limitation here is the total cross area of the case holes over the external fan.
-
Thanks for the update - I suspect with a good quality fan one might get better thermals compared to the built in one. I believe most fans operate better in push mode compared to the pull, the only limitation here is the total cross area of the case holes over the external fan.
I think any fan will do. With this size of the blades, it will have a larger air flow than the built-in one. They installed the wrong type of fan. It needs a turbine like this. And the one they put up, the air flow is directed to ...))
-
I'm thinking about one of these... I use them in all my PC builds these days. They're completely silent.
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1950489;image)
I/m gonna 3D print an adapter adapter to attach it to the VESA holes.
-
There was no bequiet or Noctua on sale. I ordered it easier. This is not a computer that I almost never turn off. I think it doesn't make much sense to strive to put a long-lasting quiet cooler. And why complicate it with an adapter? Plastic ties - 5 minutes and you're done.
-
I just received my 804, firmware 01.01
Bandwith and Mem depth option installed easily with the tuto #334 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5149494/#msg5148330)
Then WiFi dongle installed, based on TheRetroChannel (https://youtu.be/ECc2BdJzZfs?si=cL3MCWegNBvK0sl-) youtube video.
All works perfectly.
At the first boot, because of all posts about the fan, I was worried about the noise, but sincerely that was a good surprise, my Tektronix, my power supply and my UPS all are worse and the UPS is running 24/24. Probably environment and different sensitivity to noise.
But if it’s an issue for you, beaware with quiet fan, most of them have very low air flow. And forget to block the original fan,really a bad idea.
Boot time is not relevant for me too, I don’t think it is to work on a lab, but yes that could be to use it on the ground.
Now use it :popcorn:
-
I just received my 804, firmware 01.01
Bandwith and Mem depth option installed easily with the tuto #344 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5149494/#msg5149494)
It's not difficult to apply text links, so to help people who come after and read what you wrote, I have linked Post #344 in the quote above. If everyone could post a link when citing earlier posts, that would be fabulous.
I just ordered my DHO804 from the Jiutian Instrument Store (https://www.aliexpress.com/item/1005005962731116.html) on AliExpress, as per the private conversations I've had with several people in this forum about their good experience using that particular seller. The price was right too, at only $358.66, which beats even TEquipment with the EEVBlog discount code ($375.06 with free domestic US shipping). (And because I reside in Japan, I save a whole lot more by going with AliExpress versus TEquipment due to shipping charges.) AliExpress also tends to put pricing on the shipping documents that is rather low, so as to avoid import taxes most of the time. I was also surprised to see it is expected to arrive Dec. 24th. Today is Dec. 12th. Interesting.
I will be doing the Dave-recommended hack (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5197986/#msg5197986) upon arrival.
-
I bought it on Aliexpress Rigol store, really good contact with their team.
That was a black week, final price 326.89$
[attach=1]
-
I bought it on Aliexpress Rigol store, really good contact with their team.
That was a black week, final price 326.89$
(Attachment Link)
Very nice "Black Friday" price, to be sure.
Did the Rigol store put $326.89 on the shipping documents, or a lower price?
In any case, these prices are low enough for most hobbyists to get the scope, and thanks to this hacking thread, we now know how to enjoy it even more.
-
If everyone could post a link when citing earlier posts, that would be fabulous.
Good suggestion :-+
Did it
Did the Rigol store put $326.89 on the shipping documents, or a lower price?
A lower price, 130$, but I haven’t asked them to do that !
The package has been randomly selected for inspection by customs :( and I had to give a proof of payment with threat of penalty if the declared amount was false. Finally no penalties but had to pay tax on the full price of 365$ not on the reduced price of 326$ ! But better than penalties, tax could be doubled
-
I just received my 804, firmware 01.01
Bandwith and Mem depth option installed easily with the tuto #344 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5149494/#msg5149494)
It's not difficult to apply text links, so to help people who come after and read what you wrote, I have linked Post #344 in the quote above. If everyone could post a link when citing earlier posts, that would be fabulous.
I just ordered my DHO804 from the Jiutian Instrument Store (https://www.aliexpress.com/item/1005005962731116.html) on AliExpress, as per the private conversations I've had with several people in this forum about their good experience using that particular seller. The price was right too, at only $358.66, which beats even TEquipment with the EEVBlog discount code ($375.06 with free domestic US shipping). (And because I reside in Japan, I save a whole lot more by going with AliExpress versus TEquipment due to shipping charges.) AliExpress also tends to put pricing on the shipping documents that is rather low, so as to avoid import taxes most of the time. I was also surprised to see it is expected to arrive Dec. 24th. Today is Dec. 12th. Interesting.
I will be doing the Dave-recommended hack (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5197986/#msg5197986) upon arrival.
Such links should be fixed in the header of the topic. It's hard to find in the messages.
-
But if it’s an issue for you, beaware with quiet fan, most of them have very low air flow.
This fact cannot be stressed enough. If possible, always try to identify model and maker of the fan in place and get its datasheet where volumetric flow and static pressure are stated. If a 1:1 replacement is the intension, the new one should offer the same flow and pressure capabilities. Often, the noise reduction is limited to about 3db then using modern low noise fans.
The potential to lower noise further is greater when replacing one fan with multiple ones, where you can accept either lower pressure or lower flow per fan depending on series or parallel installation. However, the more complex the airflow, the more it is neccessary to.measure the final effective flow of the system to be sure it matches the original one.
-
But if it’s an issue for you, beaware with quiet fan, most of them have very low air flow.
This fact cannot be stressed enough.
Exactly. Too many people don't understand the science and practical application of airflow and cooling.
To be honest in this case there's usually more wiggle room for a general cooling function, where the tolerance window can be pretty wide. But I often see this mistake in 3D printing. 3D print heads typically include 2 types of fans/coolers: one for the hotend which melts the plastic, and another to cool the printed part. Beginners will inevitably want a "quieter" fan for one or both, and go for something like a Noctua -- but there's a reason that such silent fans are rarely included by the printer manufacturer. They don't realize that the right amount of airflow is critical in printing. Too little airflow from a quiet fan and your hotend will overhead and suffer heat creep, or your parts don't cool quickly enough to support the next layer. OTOH too much airflow cools too quickly and you wind up with layer adhesion issues or the printed part warping. So it's crucial to match the airflow to the printer and use case. Sometimes this can even change between different filament types and require a different cooling profile based on what's being printed.
-
But if it’s an issue for you, beaware with quiet fan, most of them have very low air flow.
This fact cannot be stressed enough.
Exactly. Too many people don't understand the science and practical application of airflow and cooling.
To be honest in this case there's usually more wiggle room for a general cooling function, where the tolerance window can be pretty wide. But I often see this mistake in 3D printing. 3D print heads typically include 2 types of fans/coolers: one for the hotend which melts the plastic, and another to cool the printed part. Beginners will inevitably want a "quieter" fan for one or both, and go for something like a Noctua -- but there's a reason that such silent fans are rarely included by the printer manufacturer. They don't realize that the right amount of airflow is critical in printing. Too little airflow from a quiet fan and your hotend will overhead and suffer heat creep, or your parts don't cool quickly enough to support the next layer. OTOH too much airflow cools too quickly and you wind up with layer adhesion issues or the printed part warping. So it's crucial to match the airflow to the printer and use case. Sometimes this can even change between different filament types and require a different cooling profile based on what's being printed.
Noctua, like Be quiet, is very different, with a different flow. But they all have one thing in common: quiet work for a long time. The computer has a Zalman power supply. The cooler started to crack after a year. I picked up a similar stream of be quiet SILENT WINGS, 3 years of complete silence. Exactly the same problem was with the cooling of the processor. I put a similar Noctua and forgot. Quieter does not mean less flow. The noise depends on the size (speed), the type of bearing, the quality of the bearing, the quality of the lubricant, the quality of the blades, their shape, balancing. Manufacturers of equipment are trying to reduce its cost, so they put the cheapest coolers. This is the easiest way to save money. For example, Zalman puts Noname coolers in its very decent power supplies. Why? Are they better than Noctua? Or is there no Noctua with the right flow?))
-
This is the easiest way to save money.
The easiest way for all of us to have saved money would have been for Rigol to have designed a quiet or silent cooling system from the get-go. I simply do not understand why the otherwise intelligent folks at Rigol cannot understand that they could have made the device a tad bit deeper to accommodate a large and quiet cooling fan.
I have an old TDS1012 scope from Tektronix that is 100% silent. Sure, it's old tech and deeper overall than the Rigol, but that's beside the point. The DHO804 could have been made almost as small as it is now, yet very quiet or even silent. It doesn't take much brain power either, as evidenced by all the fan hack talk in this thread by people who trying to fix the design flaw after the fact.
-
Maybe Rigol is just smarter than other suppliers of cheap scopes.
In any case, I don't know of any other brand where people want to tinker with it first.
But to Rigol's credit, Siglent's direct competitor is louder.
-
For fan the truth is on datasheet not on a marketing sheet.
For old Tektronix my 400MHz 2465B is at least 200% noisier ;)
Replace original internal fan by an external fan, this is more experimentation than theory, many parameters change then an IR camera would be your friend.
-
For fan the truth is on datasheet not on a marketing sheet.
For old Tektronix my 400MHz 2465B is at least 200% noisier ;)
Replace original internal fan by an external fan, this is more experimentation than theory, many parameters change then an IR camera would be your friend.
It is not the cooler that is making noise, but the air directed across the radiator fins. They tried to reduce the noise by applying 8v instead of 12v to it. But it's useless. This is how air raid sirens are designed. Apparently, the designers did not know about this. And the main goal was to make the body as thin as possible. In addition, this arrangement of the ribs prevents the efficient use of the air flow from the cooler, increases the wear of its bearings. And almost any external cooler can handle this air flow. https://www.youtube.com/watch?app=desktop&v=D7l5s7ZKz7M (https://www.youtube.com/watch?app=desktop&v=D7l5s7ZKz7M) There is also a very similar sound here)) https://www.youtube.com/watch?v=kUsK8AtIgeA (https://www.youtube.com/watch?v=kUsK8AtIgeA)
-
From the LAN connection, is there a way to access to the local storage to get saved file ?
I didn’t see anything on the web interface, but maybe I missed something!
Not yet tested, maybe there is a smb share ?
-
From the LAN connection, is there a way to access to the local storage to get saved file ?
I didn’t see anything on the web interface, but maybe I missed something!
Not yet tested, maybe there is a smb share ?
It runs an FTP server as well as a web server. :)
I use WinSCP to access files directly.
-
It runs an FTP server as well as a web server. :)
Tip-top thank you !
On MacOS finder "Connect to the server" ftp://192.168.xxx.xxx
Maybe, that can help someone:
Default login “admin” and password “rigol”
-
Thanks guys for all your time in hacking the scope. I will probably buy myself one for Christmas and join the reversing club, :o Will dump what ever you guys need during the season.
-
It's not difficult to apply text links, so to help people who come after and read what you wrote, I have linked Post #344 in the quote above. If everyone could post a link when citing earlier posts, that would be fabulous.
I just ordered my DHO804 from the Jiutian Instrument Store (https://www.aliexpress.com/item/1005005962731116.html) on AliExpress, as per the private conversations I've had with several people in this forum about their good experience using that particular seller. The price was right too, at only $358.66, which beats even TEquipment with the EEVBlog discount code ($375.06 with free domestic US shipping). (And because I reside in Japan, I save a whole lot more by going with AliExpress versus TEquipment due to shipping charges.) AliExpress also tends to put pricing on the shipping documents that is rather low, so as to avoid import taxes most of the time. I was also surprised to see it is expected to arrive Dec. 24th. Today is Dec. 12th. Interesting.
I will be doing the Dave-recommended hack (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5197986/#msg5197986) upon arrival.
Those units are very new builds and will come with firmware 1.01.02
-
I'm thinking about one of these... I use them in all my PC builds these days. They're completely silent.
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1950489;image)
I/m gonna 3D print an adapter adapter to attach it to the VESA holes.
They make brushless 90-92mm x 14-15mm thick fans that can run low 1100 rpm's. That's still way more flow than the tiny one inside.
I would however not disable the internal fan, just slow it down to about silent, this way there's two fans in case one fan fail. IIRC someone wrote that you can control the int fan speed from within an OS file.
I was gonna attach a microcontroller to ext fan for pwm control, but it's not needed here, will likely just tap int fan wire to control an IGBT on the ext fan, and then add a fan resistor to slow down ext fan to an acceptable flow rate. Gonna use a usbC splitter to power ext fan.
-
Those units are very new builds and will come with firmware 1.01.02
Got mine 2 days ago firmware V00.01.01
Same version on Rigol website
-
I would however not disable the internal fan, just slow it down to about silent, this way there's two fans in case one fan fail. IIRC someone wrote that you can control the int fan speed from within an OS file.
I was gonna attach a microcontroller to ext fan for pwm control, but it's not needed here, will likely just tap int fan wire to control an IGBT on the ext fan, and then add a fan resistor to slow down ext fan to an acceptable flow rate. Gonna use a usbC splitter to power ext fan.
Any links or other info on how to get at the fan control - the more I use the scope the more the fan noise bothers me - for now I put a large fan and the combination changes the overall pitch where I don't find it objectionable, but would be great to find a solution without voiding the warranty.
-
Has anybody looked at the built in keys and if they send key codes ? I am using a mouse to interact with a lot of the menus and it works well but right now the only button that seems to work is the left click - would be nice to be able to use the middle, right and the scroll wheel, or maybe it is just my mouse that is not doing that.
The function I would love to perform is to be able to press the [X] sub-window closing icon - right now I find it faster to press the built in Menu button ie first time it brings its own window and the second press closes it.
-
Those units are very new builds and will come with firmware 1.01.02
Got mine 2 days ago firmware V00.01.01
Same version on Rigol website
My bad, meant to write
v00.01.02 dated Nov 9 2023
I am not sure when the newer hardware was coming off assembly line, but apparently there's definitely new calibration code for it.
I think if the unit is super new, like the ink is still drying, it will have the v00.01.02 firmware.
-
Where I can download DHO914 vendor.bin? Can't find in this topic (
-
Where I can download DHO914 vendor.bin? Can't find in this topic (
Check out Reply #555 on: December 03, 2023 , a few pages back.
Maybe Fungus can help?
-
I ordered mine today from the Rigol Website here in the EU. What do you guys want me to post here on the thread?
-
I ordered mine today from the Rigol Website here in the EU. What do you guys want me to post here on the thread?
What did you order?
Firmware version when you get it.
-
What did you order?
Firmware version when you get it.
My apologies, I ordered the 804 version for €399.00 delivered. I will indeed post the firmware etc.
-
Ordered my DHO804 Dec 5th, arrived today with firmware 00.01.02.
-
Has anyone tried using this it on a battery pack?
Which model, what capacity, what autonomy ?
Please share your experience :)
-
Has anyone tried using this it on a battery pack?
Which model, what capacity, what autonomy ?
Please share your experience :)
Batterfly tested it:
https://www.youtube.com/watch?v=pWxmYD5bc7I (https://www.youtube.com/watch?v=pWxmYD5bc7I)
-
Batterfly tested it
Thank you for this link, but this video is almost useless!
No information about the powerbank he is using.
We know that will works, but as in comments but not with all.
I am looking for user feedbacks on various models of powerbanks we can buy.
-
I tested my 804 with Lenovo Go USB-C Laptop Power Bank, it work with no issues.
-
I tested my 804 with Lenovo Go USB-C Laptop Power Bank, it work with no issues.
I had a look to the description of this power bank, really good but pricy :P USB-C output 65W, that is enough the scope need 48W (12V 4A).
On Aliexpress for now I haven’t found anything, all was PD3.0 but only 12V/3A even they claim 65W or even 100W but that is only bullshit marketing.
-
Where I can download DHO914 vendor.bin? Can't find in this topic (
I found this tool https://github.com/zelea2/rigol_vendor_bin and successfully changed model to DHO914 in my own vendor.bin
-
I found this tool https://github.com/zelea2/rigol_vendor_bin and successfully changed model to DHO914 in my own vendor.bin
How did you use this tool, there is only poor description ?
-
I found this tool https://github.com/zelea2/rigol_vendor_bin and successfully changed model to DHO914 in my own vendor.bin
How did you use this tool, there is only poor description ?
it has builtin help
Rigol 'vendor.bin' encoder/decoder v0.6 - Zelea
At least the scope model (-M) must be supplied
./rigol_vendor_bin [options] [vendor_bin_file]
-M # set scope model
-n random serial number
-N # set serial number
-a random MAC address
-A # set MAC address
-o generate all option strings (uses 'Key.data')
-O # generate option string for feature #
-d debug switch
-
Thank you for this link, but this video is almost useless!
No information about the powerbank he is using.
I'm not sure how much more information you need? He said in the video it was a 20,000mAH battery bank. What other specs do you need? Assuming the capacity is the same, any other USB-C PD power bank should operate very similarly.
-
What other specs do you need? Assuming the capacity is the same, any other USB-C PD power bank should operate very similarly.
As described in the user guide the power adaptator provide 12V 4A (48V), but if you have a look to usb-c PD3.0 powerbanks most of them provide only 12V / 3A so only 36W or even less.
The powerbank Lenovo Go used by t_i_t_o can provide 65W on the usb-c port
-
As described in the user guide the power adaptator provide 12V 4A (48V), but if you have a look to usb-c PD3.0 powerbanks most of them provide only 12V / 3A so only 36W or even less.
As discussed here several times (in the correct DHO800 thread), it is actually not correct that the scope uses 12V when operated on a USB PD adapter. It negotiates 15V, and hence 3A should be enough. The manual is outdated. It refers to the cheap adapter originally supplied by Rigol, which provided a fixed 12V output.
Could I ask that this discussion is kept out of the "Hacking" thread, since it has nothing to do with hacking?
-
As described in the user guide the power adaptator provide 12V 4A (48V), but if you have a look to usb-c PD3.0 powerbanks most of them provide only 12V / 3A so only 36W or even less.
As discussed here several times (in the correct DHO800 thread), it is actually not correct that the scope uses 12V when operated on a USB PD adapter. It negotiates 15V, and hence 3A should be enough. The manual is outdated. It refers to the cheap adapter originally supplied by Rigol, which provided a fixed 12V output.
Could I ask that this discussion is kept out of the "Hacking" thread, since it has nothing to do with hacking?
The LO PSU is only rated 3A from 5-15vdc, but will allow 3.25A @ 20vdc
If the DHO wants to use 15vdc, it can only consume 45watt(max)
https://www.onlinecomponents.com/en/datasheet/pa165058ltpd-56959467/ (https://www.onlinecomponents.com/en/datasheet/pa165058ltpd-56959467/)
-
I am looking for user feedbacks on various models of powerbanks we can buy.
Making a comprehensive list will be tough.
This one is good value, widely available, and claims 15V 3A capability:
https://www.mi.com/global/product/mi-50w-power-bank-20000/specs/ (https://www.mi.com/global/product/mi-50w-power-bank-20000/specs/)
(on three ports simultaneously so I'm sure it will do it on one)
Disclaimer: Haven't tried it myself but I've got one on my Xmas list.
-
Start-up state file?
the 804, presumably 800 series, starts up with CH1 active and in Auto mode. Why it starts up this way is a bit confusing to me.
Is there a file to change (or menu setting) so it starts up with no channels active and in the STOP state?
-
This works fine for me.
https://www.aliexpress.com/item/1005002010583857.html?spm=a2g0o.order_list.order_list_main.69.63b81802JEST91 (https://www.aliexpress.com/item/1005002010583857.html?spm=a2g0o.order_list.order_list_main.69.63b81802JEST91)
Using USB-C.
it lasts about 5 hours when fully charged. and writes an average consumption of 38W.
-
I've received my DHO804 with 00.01.02 firmware from the factory.
I converted it to DHO914 via vendor.bin and then tried to activate 250Mhz bandwidth via license and it works without any offsets.
SelfCal was also successful
UPD: Also tried to change model to 924 in vendor.bin, no offset as well
-
I've received my DHO804 with 00.01.02 firmware from the factory.
I converted it to DHO914 via vendor.bin and then tried to activate 250Mhz bandwidth via license and it works without any offsets.
SelfCal was also successful
UPD: Also tried to change model to 924 in vendor.bin, no offset as well
Hmm, IIRC there are some posting saying the vendor.bin mod from 800 to 914 does not work for every aspect of the 800.
What changes exactly were made?
-
I've received my DHO804 with 00.01.02 firmware from the factory.
I converted it to DHO914 via vendor.bin and then tried to activate 250Mhz bandwidth via license and it works without any offsets.
SelfCal was also successful
UPD: Also tried to change model to 924 in vendor.bin, no offset as well
Hmm, IIRC there are some posting saying the vendor.bin mod from 800 to 914 does not work for every aspect of the 800.
What changes exactly were made?
Only changed model in my original vendor.bin via tool from github
-
There is a strange thing on saye rigol. Both on a global and on a European level.
-
There is a strange thing on saye rigol. Both on a global and on a European level.
Fully updated new firmware, same version, no changes. :-//
-
I installed AIDA64 and included is the report - this is for v 1.01 firmware. AIDA seems to report Bluetooth but I have not seen any mention of built-in bluetooth device. Hope somebody finds the report of value.
I am looking for the fan PWM interface - from /proc and /sys the following things come up:
/sys/bus/i2c/drivers/fan53555-regulator
/sys/bus/platform/devices/pwm_fan
/sys/devices/platform/pwm_fan
/sys/firmware/devicetree/base/pwm_fan
I am just starting to look at those locations, but if anybody has been able to locate the interface please let us know.
-
No luck finding PWM - I looked at the boot messages and nothing stands out. The fan53555 is a PWM voltage regulator with lower output voltage.
Here are few other things that might be of use:
1) Setting HDMI resolution - on DHO800 line there is no direct menu item to set the resolution - for some reason my monitor got 1920x1200 and the output did not look right - here is a quick fix:
with a kbd connected: WinKey-N → Settings Gear Icon → Display → HDMI → Resolution → 1920×1080
Its possible to set the resolution using adb as well but the string has some magic numbers - after you set it using the above method you get find out what the value is:
adb shell 'getprop persist.sys.resolution.aux'
- use setprop to set the value
2) NFS mount - if one needs to move a lot of files or wants to save items directly on their NAS from the scope ( ie wave images, recordings, settings). One plus is that it does not impact the SD card and can increase its life ( doing the mount does not remove any of the existing files in /data/UserData ). I assume you have an nfs server on IP 1.2.3.4 running over TCP with version 4.2 and has an export disk /rigol:
adb shell
su -
busybox mount -t nfs -o proto=tcp,vers=4.2 1.2.3.4:/rigol /data/UserData
chmod a+rw /data/UserData
- the write speed is about 10MB/s based on my tests. Right now the mount does not persist over reboots - I may add some scripting to run at boot time, or you can have a script running from a remote host and perform the mount using adb shell su -c ... command.
3) Use busybox to find missing commands - I like less, so in the shell I can say alias less='busybox less' and now have a less command - to see all commands type busybox
-
Here are few other things that might be of use:
1) Setting HDMI resolution - on DHO800 line there is no direct menu item to set the resolution - for some reason my monitor got 1920x1200 and the output did not look right - here is a quick fix:
Much easier: Tap the "about" button three times and you get settings for the HDMI resolution.
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1956444;image)
-
Taking a good quality screenshot (better than via web ui)
adb exec-out screencap -p > screen.png
-
The fan53555 is a PWM voltage regulator with lower output voltage.
I wonder what that is used for.
Onsemi has that model #, it could change voltage depending on thermal load. Programmable via I2C, so perhaps that's easier to program than using PWM. Perhaps the constant "flicker" of PWM is a no-no for a scope device like this?
"The FAN53555 is a step-down switching voltage regulator that delivers a digitally programmable output from an input voltage supply of 2.5 V to 5.5 V. The output voltage is programmed through an I2C interface capable of operating up to 3.4 MHz."
:-//
-
I now recall reading about tapping on About but for some reason I assumed it was one of the Android menus - this way is much easier - thanks.
I do wonder why they have to hide the item or maybe I missed it in the manual :-//
-
With today's OTA to 00.01.02, the Storage depth option seems to have disappeared, too:
-
With today's OTA to 00.01.02, the Storage depth option seems to have disappeared, too:
It's disappeared from options list, but still working. And for me, dho924 vendor.bin has no offset on 00.01.02
-
Anyone saved and willing to share 1.02 as it seems to be gone from any of rigol sites?
-
Anyone saved and willing to share 1.02 as it seems to be gone from any of rigol sites?
I thought fungus said it was being pulled back?
I never did download a 01.02 version.
-
The fan noise doesn't bother me.
For those who it does bother; have you tried changing the pwm frequency or duty cycle using the original fan and an external source? This would identify if the harsh, to your ears, sound caused by the fan or the pwm which drives it.
-
It has been determined for a long time. The noise is caused by the design of the execution. Air raid sirens are designed according to this principle.
-
It has been determined for a long time. The noise is caused by the design of the execution. Air raid sirens are designed according to this principle.
Some fans whine at certain pwm frequencies. Are you saying that you know for a fact that this is not a contributing factor in DHO800 oscilloscopes?
This is a well known problem in the diy 3d printer community. A quick search shows this has been discussed here too. At least one thread here has a better test suggestion. Instead of using pwm, use a variable power supply to see if it reduces the fan noise.
Eg. https://www.eevblog.com/forum/beginners/filtering-pwm-to-smooth-dc/ (https://www.eevblog.com/forum/beginners/filtering-pwm-to-smooth-dc/)
-
I did some sleuthing arund on the various Rigol sites using nifty F12 via Firefox. Their sites are heavy in .js imports, so needless to say I had to read through many .js files looking for clues.
The two 01.01 downloads, one with Aug 2023 date, the other Dec 2023, are all the same zip file. I suspect the 01.02 zip was attached to the Dec 2023 download, until they swapped it back to 01.01
I was not able to locate a 01.02 download.
I will contact Rigol support since my unit has 01.02 and ask for the 01.02 zip.
-
It has been determined for a long time. The noise is caused by the design of the execution. Air raid sirens are designed according to this principle.
Some fans whine at certain pwm frequencies. Are you saying that you know for a fact that this is not a contributing factor in DHO800 oscilloscopes?
This is a well known problem in the diy 3d printer community. A quick search shows this has been discussed here too. At least one thread here has a better test suggestion. Instead of using pwm, use a variable power supply to see if it reduces the fan noise.
Eg. https://www.eevblog.com/forum/beginners/filtering-pwm-to-smooth-dc/ (https://www.eevblog.com/forum/beginners/filtering-pwm-to-smooth-dc/)
Why complicate it? It's much simpler. You take the fan out of its socket and realize that it is not making noise)) You can easily find information on how an air alert is set up on Google. I screwed an external cooler to Rigol, and no PWM prevents it from working quietly. Take a look and everything will become clear. In the photo there is an air raid siren
-
So, what should be the right shape for the fan with the existing heatsink?
Talented designers here may print out the rotor/blades and try..
-
I've been a lurker for a while but figure I have something to add here.
I have a DHO804 that I had done the SCPI mods to successfully, and currently have a 914 vendor.bin that self cal'ed properly. I've been running FW 1.02. I got mine via Valuetronics. I still have the 1.02 firmware on my HD, so here you go.
https://file.io/s9E8WaojBr0N
-
Is that file auto deleted after one download (i.e. free use option on file.io) ?
-
Is that file auto deleted after one download (i.e. free use option on file.io) ?
I get a "file deleted" message.
-
What does the 804 become when you change just the model number to 914 in the vendor.bin file? And when doing that, any diffs between 1.01 and the 1.02 FW?
800/900 uses same firmware, and there are hardware diffs between 800 & 900, so what all do you gain with just a model number change in vendor.bin?
-
That was my first try at File.io, let me try dropbox...
https://www.dropbox.com/scl/fi/qdo6kfje8coxgxbgp9012/DHO800_DHO900-Software-Updatev00.01.02.00.00.zip?rlkey=35rzumxdyw7g6qfsv8j9flztr&dl=0 (https://www.dropbox.com/scl/fi/qdo6kfje8coxgxbgp9012/DHO800_DHO900-Software-Updatev00.01.02.00.00.zip?rlkey=35rzumxdyw7g6qfsv8j9flztr&dl=0)
I went for the 914 to gain the CAN decoders since I frequently work with CAN bus stuff. Otherwise the BW upgrade would have been fine. I'm hesitant to buy a probe and cut a hole in my case since my cutting skills aren't pretty and I have a Saelea pro 16 on hand.
-
That was my first try at File.io, let me try dropbox...
https://www.dropbox.com/scl/fi/qdo6kfje8coxgxbgp9012/DHO800_DHO900-Software-Updatev00.01.02.00.00.zip?rlkey=35rzumxdyw7g6qfsv8j9flztr&dl=0 (https://www.dropbox.com/scl/fi/qdo6kfje8coxgxbgp9012/DHO800_DHO900-Software-Updatev00.01.02.00.00.zip?rlkey=35rzumxdyw7g6qfsv8j9flztr&dl=0)
I went for the 914 to gain the CAN decoders since I frequently work with CAN bus stuff. Otherwise the BW upgrade would have been fine. I'm hesitant to buy a probe and cut a hole in my case since my cutting skills aren't pretty and I have a Saelea pro 16 on hand.
Got it.
What's not in the Release notes? Reply#661 is not in the release notes. Why is that option removed?
Variants of 00.01.01.00.xy ??? All of the 01.01's downloadable from Rigol are the same zip file, so I wonder who is running a 01.01 variant?
What the heck is item #4?
Release notes:
[Model Supported] All the DHO800/900 series oscilloscopes
[Latest Revision Date] 2023/11/2
[Updated Contents]
v00.01.02.00.00 2023/11/2
1. Self calibration optimization update
2. Solve the problem of UltraLab startup connection failure
3. Solve the problem of failure to save waveform in wfm format
4. Add education model equivalent settings
5. Solve the problem of unresponsive touch on startup screen
v00.01.01.00.02 2023/09/12
1. Self calibration optimization update
2. Update Help Documents
v00.01.01.00.01 2023/08/10
1. Remove all time-related displays on the instrument
2. To modify the vertical interface, click the wiring diagram to modify the AC coupling function
3. Modify the delayed scan Chinese display as Zoom
4. Modify the order of the menu in the upper right corner, put the measurement in the front and Default in the back
5. The probe ratio interface is removed, and the probe ratio option is added to the vertical first-level menu
v00.01.00.00.19 2023/07/24
1. The first version is released
-Released the production version.
-
What does the 804 become when you change just the model number to 914 in the vendor.bin file?
A DHO914, believe it or not... :)
-
What does the 804 become when you change just the model number to 914 in the vendor.bin file?
A DHO914, believe it or not... :)
Not quite, right. 900 has more hardware in it. I wonder what the android error logs look like if the OS ("fw") is expecting all the 900 hardware?
So with just vendor.bin mod to change model to "914", the 804 becomes a 4ch 12 Bit 125 MHz 1.25 GSa/s 50 Mpts 1,000,000 wfms/s, with no calibration or other issues ?
-
So with just vendor.bin mod to change model to "914", the 804 becomes a 4ch 12 Bit 125 MHz 1.25 GSa/s 50 Mpts 1,000,000 wfms/s, with no calibration or other issues ?
Yes.
(actually 225Mhz measured bandwidth... :) )
You also get the 2ns/div horizontal and 200uV/div vertical ranges, and the CAN/LIN serial decoders.
-
It has been determined for a long time. The noise is caused by the design of the execution. Air raid sirens are designed according to this principle.
Some fans whine at certain pwm frequencies. Are you saying that you know for a fact that this is not a contributing factor in DHO800 oscilloscopes?
This is a well known problem in the diy 3d printer community. A quick search shows this has been discussed here too. At least one thread here has a better test suggestion. Instead of using pwm, use a variable power supply to see if it reduces the fan noise.
Eg. https://www.eevblog.com/forum/beginners/filtering-pwm-to-smooth-dc/ (https://www.eevblog.com/forum/beginners/filtering-pwm-to-smooth-dc/)
Why complicate it? It's much simpler. You take the fan out of its socket and realize that it is not making noise)) You can easily find information on how an air alert is set up on Google. I screwed an external cooler to Rigol, and no PWM prevents it from working quietly. Take a look and everything will become clear. In the photo there is an air raid siren
I never suggested removing the fan, just connecting it to a different power source. Taking the fan out of the case may change how it resonates.
Anyhow as the sound doesn't bother me at all, I won't be opening mine. I was trying to offer something to try which may offer a less physical hacking way to reduce the sound for those who it does annoy. For all I know the fan runs on DC rather than PWM.
-
That was my first try at File.io, let me try dropbox...
https://www.dropbox.com/scl/fi/qdo6kfje8coxgxbgp9012/DHO800_DHO900-Software-Updatev00.01.02.00.00.zip?rlkey=35rzumxdyw7g6qfsv8j9flztr&dl=0 (https://www.dropbox.com/scl/fi/qdo6kfje8coxgxbgp9012/DHO800_DHO900-Software-Updatev00.01.02.00.00.zip?rlkey=35rzumxdyw7g6qfsv8j9flztr&dl=0)
I went for the 914 to gain the CAN decoders since I frequently work with CAN bus stuff. Otherwise the BW upgrade would have been fine. I'm hesitant to buy a probe and cut a hole in my case since my cutting skills aren't pretty and I have a Saelea pro 16 on hand.
Just some observations.
All of the 01.01 downloads use a CAP V in their name (UpdateV), the 01.02 zip used a lower case v.
Also, the 800 series is missing digi header, so not only would you need to cut a hole in case, would also need to solder header to board, and there was chatter about some mem chips missing in 800's.
-
Where I can download DHO914 vendor.bin? Can't find in this topic (
I found this tool https://github.com/zelea2/rigol_vendor_bin and successfully changed model to DHO914 in my own vendor.bin
Do you still have your original vendor.bin file?
If so, can you get a diff?
eg;
name each with "oem" and "edit"
vendor.oem.bin and vendor.edit.bin
xxd vendor.oem.bin vendor.oem.hex
xxd vendor.edit.bin vendor.edit.hex
then diff them
vimdiff vendor.oem.hex vendor.edit.hex
post pic of the diff
-
I can confirm - 1.02 along with 924 vendor.bin does not show the offset issue.
-
I can confirm - 1.02 along with 924 vendor.bin does not show the offset issue.
Please add clarity.
You used the bin tool to mod model number in your 800 vendor.bin file. You did not adb push (copy in) a vendor.bin from a 900, correct?
-
Yes, I simply modded my 804 vendor.bin to a 924 one and pushed it to the scope.
-
Yes, I simply modded my 804 vendor.bin to a 924 one and pushed it to the scope.
See my reply #682, can you do that for the forum folks?
-
I can also confirm that my "Baseus Power Bank, 65W 20000mAh". will power the scope just fine. Though plugging it into my Pine power 120W desktop PSU killed the 10 pin power delivery controller IC. I have yet to identify it and there are no markings.
-
I have 1.02, just adb push 924 vendor.bin downloaded from here, no offset after selfcal.
but I found WIN+N to andorid, it warns SDcard broken. The scope works well now.
-
It has been determined for a long time. The noise is caused by the design of the execution. Air raid sirens are designed according to this principle.
Some fans whine at certain pwm frequencies. Are you saying that you know for a fact that this is not a contributing factor in DHO800 oscilloscopes?
This is a well known problem in the diy 3d printer community. A quick search shows this has been discussed here too. At least one thread here has a better test suggestion. Instead of using pwm, use a variable power supply to see if it reduces the fan noise.
Eg. https://www.eevblog.com/forum/beginners/filtering-pwm-to-smooth-dc/ (https://www.eevblog.com/forum/beginners/filtering-pwm-to-smooth-dc/)
Why complicate it? It's much simpler. You take the fan out of its socket and realize that it is not making noise)) You can easily find information on how an air alert is set up on Google. I screwed an external cooler to Rigol, and no PWM prevents it from working quietly. Take a look and everything will become clear. In the photo there is an air raid siren
I never suggested removing the fan, just connecting it to a different power source. Taking the fan out of the case may change how it resonates.
Anyhow as the sound doesn't bother me at all, I won't be opening mine. I was trying to offer something to try which may offer a less physical hacking way to reduce the sound for those who it does annoy. For all I know the fan runs on DC rather than PWM.
On the second day after the purchase, I was looking for an interference in the amplifier. The growl of the DHO cooler drowned out the sound of the speaker for me. And it was very annoying. Without hesitation, he opened, removed this ratchet and put on an external cooler. And if you listen to this nightmare all day, your head will be square by evening. 7 coolers in my computer are almost inaudible, and one DHO roars like a bike. ))
-
On the second day after the purchase, I was looking for an interference in the amplifier. The growl of the DHO cooler drowned out the sound of the speaker for me. And it was very annoying. Without hesitation, he opened, removed this ratchet and put on an external cooler. And if you listen to this nightmare all day, your head will be square by evening. 7 coolers in my computer are almost inaudible, and one DHO roars like a bike. ))
"coolers"? Is each "cooler" a fan? If you can't hear 7 fans running then I suspect they are all running at like 200rpm.
Noise comes from mostly airflow. To get some flow from a tiny fan it needs to run fast rpm's. More flow + smaller fan, is a catch-22 design in terms of noise. Bigger fan blades can 1) run slower, and 2) have better designed blades to help mitigate wind noise. But sometimes physical size and costs become more of a factor when the noise is still in that "acceptable" range.
Pop open case, inline a resistor with the tiny fan, install a 90x15mm on ext side. That's what I will do, but I have more to do along the way, gonna be testing the noise on the provided usb-c psu, then I will add some filtering. I will skip doing any PWM control on the ext fan side to avoid any harmonics stuff since I will split the usb-c to power both DHO and ext fan, so just gonna use a generic pot to slow the ext fan into the right flow.
-
It might just be the amount of other fans that are running in our shop, but I can hear my fan and don't find it annoying at all. I have to actively listen for it to notice it. Other power supplies and test fixtures easily drown it out.
-
On the second day after the purchase, I was looking for an interference in the amplifier. The growl of the DHO cooler drowned out the sound of the speaker for me. And it was very annoying. Without hesitation, he opened, removed this ratchet and put on an external cooler. And if you listen to this nightmare all day, your head will be square by evening. 7 coolers in my computer are almost inaudible, and one DHO roars like a bike. ))
"coolers"? Is each "cooler" a fan? If you can't hear 7 fans running then I suspect they are all running at like 200rpm.
Noise comes from mostly airflow. To get some flow from a tiny fan it needs to run fast rpm's. More flow + smaller fan, is a catch-22 design in terms of noise. Bigger fan blades can 1) run slower, and 2) have better designed blades to help mitigate wind noise. But sometimes physical size and costs become more of a factor when the noise is still in that "acceptable" range.
Pop open case, inline a resistor with the tiny fan, install a 90x15mm on ext side. That's what I will do, but I have more to do along the way, gonna be testing the noise on the provided usb-c psu, then I will add some filtering. I will skip doing any PWM control on the ext fan side to avoid any harmonics stuff since I will split the usb-c to power both DHO and ext fan, so just gonna use a generic pot to slow the ext fan into the right flow.
No, they work at a normal speed. Usually about 60%. When rendering, the coolers are at 100%. The loudest ones are on the video card. And it's quieter than DHO. It's just that when the cooler started making sounds on the Zalman power supply after a year of operation, I replaced it with Be Quiet. Noctua was installed on the processor after a year of operation. The cabinet ones also Be Quiet. It's just about the quality of the coolers. Only the air flow is audible. In DHO, with this design, the quality of the cooler does not matter. Do you want to slow it down? There is already 8V, usually the coolers start rotating starting from 5V. In addition, even at 8V in the DHO settings, you can see a temperature of about 60C. It's not critical, but it's not 40 anymore. Now I have a maximum temperature with an external cooler that I have seen- 55C. And silence. I bought DHO for comfortable work, and if the warranty prevents it, then I don't need it.
-
I'm not sure what went wrong with my previous upgrade attempts, because I sent the identical string, but I tried it again after power cycling the DHO914S and it worked!
Unlike the other Rigol scopes I have, the BW upgrade doesn't show up as an option in the options list, but does show "Max BW:250M" in the "About" section.
Thanks to all who had the patience to help me with this!
Hi, I order a 914s from China and it is on the way. Can you post steps to upgrade to 924s in detail?
Hi. Any news regarding upgrade from 914S to 924S with vendor.bin file?
I was also interested into that topic.
Best regards
-
On the second day after the purchase, I was looking for an interference in the amplifier. The growl of the DHO cooler drowned out the sound of the speaker for me. And it was very annoying. Without hesitation, he opened, removed this ratchet and put on an external cooler. And if you listen to this nightmare all day, your head will be square by evening. 7 coolers in my computer are almost inaudible, and one DHO roars like a bike. ))
"coolers"? Is each "cooler" a fan? If you can't hear 7 fans running then I suspect they are all running at like 200rpm.
Noise comes from mostly airflow. To get some flow from a tiny fan it needs to run fast rpm's. More flow + smaller fan, is a catch-22 design in terms of noise. Bigger fan blades can 1) run slower, and 2) have better designed blades to help mitigate wind noise. But sometimes physical size and costs become more of a factor when the noise is still in that "acceptable" range.
Pop open case, inline a resistor with the tiny fan, install a 90x15mm on ext side. That's what I will do, but I have more to do along the way, gonna be testing the noise on the provided usb-c psu, then I will add some filtering. I will skip doing any PWM control on the ext fan side to avoid any harmonics stuff since I will split the usb-c to power both DHO and ext fan, so just gonna use a generic pot to slow the ext fan into the right flow.
No, they work at a normal speed. Usually about 60%. When rendering, the coolers are at 100%. The loudest ones are on the video card. And it's quieter than DHO. It's just that when the cooler started making sounds on the Zalman power supply after a year of operation, I replaced it with Be Quiet. Noctua was installed on the processor after a year of operation. The cabinet ones also Be Quiet. It's just about the quality of the coolers. Only the air flow is audible. In DHO, with this design, the quality of the cooler does not matter. Do you want to slow it down? There is already 8V, usually the coolers start rotating starting from 5V. In addition, even at 8V in the DHO settings, you can see a temperature of about 60C. It's not critical, but it's not 40 anymore. Now I have a maximum temperature with an external cooler that I have seen- 55C. And silence. I bought DHO for comfortable work, and if the warranty prevents it, then I don't need it.
Fan blade speed will be proportional to flow rate for any given fan. Fan blade speed must increase as fan gets smaller for any constant flow rate. Little fans make more noise.
Swap out your fans for little ones, adjust to get require flow, noise will go way up.
The DHO800/900 is a tiny box, so not easy to put a large low rpm fan inside. And perhaps the tiny fan is just a low quality sleeve bearing item?
But duly noted, that warranty foil sticker, you can buy them from many china sources. ;)
However, I do believe there is a way to control that tiny fan speed from within a file somewhere.
-
You can adjust the speed, make it smaller. And get 75C at 24C in the room and more than 80C in the summer. I don't like this idea. Rigol has done everything to reduce the body. But let me have it a little more, but without noise. There are experiments in this video. But I advise you to look at the temperature not only on the radiator surface, but also in the Rigol menu. In any case, he did not achieve a quiet job. https://www.youtube.com/watch?v=zoyaHOqp9gI (https://www.youtube.com/watch?v=zoyaHOqp9gI)
-
Yes, I simply modded my 804 vendor.bin to a 924 one and pushed it to the scope.
I was playing around with that rigol_vendor.bin tool. It does not modify any bin file, it just creates them. If you supply
So when you say "modded", was that a manual hex edit, or you just created new bin and pushed that in?
If you pass in only a filename "rigol_vendor_bin myBinFile.bin", it decodes the file.
For readers, if you do a manual set of serial using the tool, only the last 7 digits in your UTIL ABOUT serial is the serial number.
The 1st six chars are series chars, eg 800 series will all be "DHO8A25", 900 "DHO9A25", etc.
-
Here are few other things that might be of use:
1) Setting HDMI resolution - on DHO800 line there is no direct menu item to set the resolution - for some reason my monitor got 1920x1200 and the output did not look right - here is a quick fix:
Much easier: Tap the "about" button three times and you get settings for the HDMI resolution.
I have the 01.02 firmware, when I tap "about" in UTILITY --> ABOUT 3x it toggles a "TestModel" option ON or OFF.
What is "TestModel" ?
When set to TestModel:ON I can then click OTHER to get to HDMI settings, which also contains the open source acknowledgement option to read it.
When set to TestModel:OFF the OTHER menu item only shows the open source agreement item, but if I tap OTHER it flashes the HDMI settings page for a 1/4sec and returns back to the open source display.
-
rigol_vendor_bin shows info about the provided vendor bin, if no other arguments are provided. If you provide -m and a model name, it will create new vendor.enc file with new model based on the provided vendor.bin. Now you need to rename vendor.enc to vendor.bin and push to your scope. Have you RTFM? That is how I modded my vendor file.
-
rigol_vendor_bin shows info about the provided vendor bin, if no other arguments are provided. If you provide -m and a model name, it will create new vendor.enc file with new model based on the provided vendor.bin. Now you need to rename vendor.enc to vendor.bin and push to your scope. Have you RTFM? That is how I modded my vendor file.
-M
not -m
;)
-
Do the same hacks as for the DHO804 also work for the 2 channel DH802 version?
-
Try them and let us know : )
-
Question about that rigol bin tool.
When using the -o option to gen all the scpi options, is it specific to hardware version (dho800 vs dho900), or specific to the vendor.bin version?
Eample, my 804 is now a 914 via just the vendor bin mod using the tool. But do I gen options for DHO800 or DHO900 ? The hardware is still "12" for DH800, not an "8" for DHO900, as seen in UTIL --> ABOUT.
The tool generated a ton of scpi option strings, but obviously not all of them will apply to the 800 hardware, so which ones are the useful ones?
-
Question about that rigol bin tool.
When using the -o option to gen all the scpi options, is it specific to hardware version (dho800 vs dho900), or specific to the vendor.bin version?
Eample, my 804 is now a 914 via just the vendor bin mod using the tool. But do I gen options for DHO800 or DHO900 ? The hardware is still "12" for DH800, not an "8" for DHO900, as seen in UTIL --> ABOUT.
The tool generated a ton of scpi option strings, but obviously not all of them will apply to the 800 hardware, so which ones are the useful ones?
You have to gen options for dho900 by specifying modified vendor.bin
-
Unlike most people, I found no offensive odor at all when powering on my DHO804.
And unlike most people, I've not found the fan offensive. Would love it silent (no fan) but it's not as bad as I thought based on what other people said.
I also completed the hack, largely using this video...
this video as a guide, (https://www.youtube.com/watch?v=Az9lXMGV_jM)
But I did it using an Apple Silicon M1 MacBook Pro.
Sadly, batch files don't work on the vastly superior computing platform we know as the Mac. :) You therefore must install Parallels Desktop Trial (Windows on Arm), but there are yet more hoops to jump through.
You can't download the Hack ZIP archive (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1918596) and leave it in the normal location or Windows (in Parallels) will complain that UNC paths are not supported. Blasted all! The workaround is to move the decompressed ZIP folder into your /Program Files (within Parallels Desktop). But then it still won't work because you must edit Properties and change permissions so contents of that folder can be edited/added!! Then you need to run the *.bat file as Administrator via right-click on the *.bat.
Of course, your scope must be connected to your local network (I used an Ethernet cable), and you need to edit the *.bat file as explained in the video, which I did, of course, prior to what I just told you. In the end it worked, but there needs to be a Mac version that is not a *.bat file but rather an *.sh file which will run in the MacOS Terminal. That would eliminate the use of Parallels Desktop entirely, which is a huge headache.
Anyway, my DHO804 is not 100MHz with 50M memory, and no silly DHO900-series non-functional menus to mess with my mind. It's the ideal setup.
-
In this youtube video, it use a shargeek stormpower bank, on this display we can see the DHO use 15V between 2.150 - 2.650 A, I think it is an interesting information for those who want to power the fan through the usb+c (there is not so much power available and it’s not 12V!).
[attachimg=1]
https://youtu.be/TXL916et9_Y?si=ufldtgFa_a2auhS4 (https://youtu.be/TXL916et9_Y?si=ufldtgFa_a2auhS4)
-
In this youtube video, it use a shargeek stormpower bank, on this display we can see the DHO use 15V between 2.150 - 2.650 A, I think it is an interesting information for those who want to power the fan through the usb+c (there is not so much power available and it’s not 12V!).
It also works on 12V...
-
It also works on 12V...
But not with the Liteon adaptator include with the scope, not enough power 12V/3A.
Humm, the FNB58 I am thinking to buy one, it’s very useful :D
-
In this youtube video, it use a shargeek stormpower bank, on this display we can see the DHO use 15V between 2.150 - 2.650 A, I think it is an interesting information for those who want to power the fan through the usb+c (there is not so much power available and it’s not 12V!).
(Attachment Link)
https://youtu.be/TXL916et9_Y?si=ufldtgFa_a2auhS4 (https://youtu.be/TXL916et9_Y?si=ufldtgFa_a2auhS4)
The psu is good for 45w @15vdc.
Adding a 12v fan, or a 5v fan with 5v via linear regulator, is not gonna max out the Liteon when powering the DHO.
Noctua fans will be around 0.4w.
12v fan, just inline a 1/2 watt to accomodate psu going to 15vdc, along with a "robust" pot to slow the fan down some.
5v fan with reg, then just use a pot on fan to slow it some.
-
Unlike most people, I found no offensive odor at all when powering on my DHO804.
And unlike most people, I've not found the fan offensive. Would love it silent (no fan) but it's not as bad as I thought based on what other people said.
I also completed the hack, largely using this video...
But I did it using an Apple Silicon M1 MacBook Pro.
Sadly, batch files don't work on the vastly superior computing platform we know as the Mac. :) You therefore must install Parallels Desktop Trial (Windows on Arm), but there are yet more hoops to jump through.
You can't download the Hack ZIP archive (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1918596) and leave it in the normal location or Windows (in Parallels) will complain that UNC paths are not supported. Blasted all! The workaround is to move the decompressed ZIP folder into your /Program Files (within Parallels Desktop). But then it still won't work because you must edit Properties and change permissions so contents of that folder can be edited/added!! Then you need to run the *.bat file as Administrator via right-click on the *.bat.
Of course, your scope must be connected to your local network (I used an Ethernet cable), and you need to edit the *.bat file as explained in the video, which I did, of course, prior to what I just told you. In the end it worked, but there needs to be a Mac version that is not a *.bat file but rather an *.sh file which will run in the MacOS Terminal. That would eliminate the use of Parallels Desktop entirely, which is a huge headache.
Anyway, my DHO804 is not 100MHz with 50M memory, and no silly DHO900-series non-functional menus to mess with my mind. It's the ideal setup.
I watched that vid a few times, looked over the directions in it. Now it seems all you need is to gen a vendor.bin file using the posted rigol_bin tool. Just making the bin file a 914 opens up the 800's the same way the vid shows. More BW and 50M depth.
-
Anyone see the "storage error" message when you connect keyboard and get to Android vua WIN+N key?
An internal SD card is not formatted? What's that SD card for?
I let android do formatting for "internal use". Is this SD card where you would normall save screen pics?
-
Anyone see the "storage error" message when you connect keyboard and get to Android vua WIN+N key?
Yes, EVERYBODY has that.
Just ignore it.
-
Anyone see the "storage error" message when you connect keyboard and get to Android vua WIN+N key?
Yes, EVERYBODY has that.
Just ignore it.
I did the format option, now no error.
But what SD card storage was it looking at?
-
I've received my DHO804 with 00.01.02 firmware from the factory.
I converted it to DHO914 via vendor.bin and then tried to activate 250Mhz bandwidth via license and it works without any offsets.
SelfCal was also successful
UPD: Also tried to change model to 924 in vendor.bin, no offset as well
Did you push in a SCPI command for the BW expansion? If so, which command? And doe sthe added option show up in the UTIL OPTIONS area?
-
I did the format option, now no error.
But what SD card storage was it looking at?
It's the SD card which stores the firmware, FPGA configuration etc. There is no flash chip in the scope, just this SD card. I would be careful with the formatting.
You are spending a lot of time exploring the scope, and also writing here. May I suggest that you carve out some time for reading the earlier posts in this thread, watching Dave's teardown video etc.? It feels like this thread has come full circle now; most of what gets reported or asked has been discussed here before.
-
I did the format option, now no error.
But what SD card storage was it looking at?
It's the SD card which stores the firmware, FPGA configuration etc. There is no flash chip in the scope, just this SD card. I would be careful with the formatting.
You are spending a lot of time exploring the scope, and also writing here. May I suggest that you carve out some time for reading the earlier posts in this thread, watching Dave's teardown video etc.? It feels like this thread has come full circle now; most of what gets reported or asked has been discussed here before.
Maybe it didn't actually format the SD, maybe android just marked for a type of use, options were "for moving files", or, "for internal use". I did the latter. Whatever it did, no changes to scope operation and error is gone. And yep, been moving around in the filesyetem as root via adb shell. Some interesting stuff inside. lol.
At least FFT flatop was "fixed" using the exe tool from the hacking 1000 thread.
I read all the posts up until now. The teardown thread though is a bit longer, not sure I read all posts there.
-
Anyone saved and willing to share 1.02 as it seems to be gone from any of rigol sites?
https://www.dropbox.com/scl/fi/e765b98hni77r5hu7qe5w/DHO800_DHO900_Update.GEL?rlkey=6xbqvtlxhe523mw18ubyjldom&dl=0 (https://www.dropbox.com/scl/fi/e765b98hni77r5hu7qe5w/DHO800_DHO900_Update.GEL?rlkey=6xbqvtlxhe523mw18ubyjldom&dl=0)
-
Note this file is NOT the same as the 1.02 that some users got over OTA recently. The OTA file have last modified times that are 1 week later (11/09).
-
Has anyone posted this file received via OTA yet?
-
Has anyone posted this file received via OTA yet?
You need to complete 2 steps described earlier in another thread.
1. XML file request
2. Downloading FW based on data from the received XML file
You cannot skip step 1.
-
Has anyone posted this file received via OTA yet?
You need to complete 2 steps described earlier in another thread.
1. XML file request
2. Downloading FW based on data from the received XML file
You cannot skip step 1.
I tried these steps and the first step returns the error "Unknown serial number". Moreover, this is only in the browser of the oscilloscope itself; on the computer the error “404 Not found” is generally displayed.
-
I have a Mac desktop and no Windows.
I just installed the Mac native Android adb kit, golang, connected to the device with native adb connect.
I then ran the golang app to make the keygen based on the values I just manually grabbed.
The batch file might be helpful for windows users to automate the whole thing but it's almost as simple to just read it and run the commands.
If someone hassles I'd be open to making a mac/linux bash script to do the same.
-
How to get the OTA GEL file:
1. Replace with real SN in this link and open in browser https://spiderapi.rigol.com/api/Support/ProductUpgradeFile?sn=DHO8AXXXXXXXXX&hardware=1.0&behaviour=soft&software=00.01.01
2. Open the downloaded XML file and open again in browser the URL inside the XML file. This should download the 1.02 GEL file.
3. Copy the GEL file to a USB FLASH drive and update your scope as usual Rigol_Icon-->Storage-->Upgrade-->USB drive D-->The GEL file...
-
How to get the OTA GEL file:
1. Replace with real SN in this link and open in browser https://spiderapi.rigol.com/api/Support/ProductUpgradeFile?sn=DHO8AXXXXXXXXX&hardware=1.0&behaviour=soft&software=00.01.01
2. Open the downloaded XML file and open again in browser the URL inside the XML file. This should download the 1.02 GEL file.
3. Copy the GEL file to a USB FLASH drive and update your scope as usual Rigol_Icon-->Storage-->Upgrade-->USB drive D-->The GEL file...
For my serial number the following .xml is issued. Translation - "No production information of serial number found".
But I managed to get a valid .xml with a link to the update from another, made-up serial number, thanks :)
The downloaded update file is posted here - https://drive.google.com/file/d/1kqA-li3k91R1qF8_Nw4iN5hi5C3HgZ_f/view?usp=sharing
P.S. The update was successful, the activated options were saved.
-
I confirm previous messages: after updating the firmware to version 00.01.02, changing the oscilloscope model from 814 to 914 occurs without vertical shift of channels. Both immediately after changing the model and after calibration, everything is fine with the offsets.
With firmware 00.01.01 there were channel shifts when trying to change the model to 914.
-
If someone hassles I'd be open to making a mac/linux bash script to do the same.
Having such a script would be fantastic for the scope-using masses who prefer Macs over Windoze (proper spelling). :)
-
I managed to clone the SD card with great difficulty, I accidentally violated the seal, so I had to decide whether to take the device apart.
The partitions look like this to me on the clone card.
unallocated 268MiB
ext4 128MiB
ext4 2GiB
ext4 16MiB
unallocated 616MiB
ext4 116GiB <-- After resizing with gpartded.
I made the clone SD card with the linux dd command, after copying it back to the second SD card, I succeeded in repairing the partition table with the help of the linux "testdisk".
I couldn't find the option in the free paragon.
All 4 ext4 primary partitions.
I managed to make an extended one on my very first try...
Which didn't work.
My question is, do you also have the two unallocated parts?
So far it works stably, I haven't experienced any errors.
I used the Kingson canvas go plus 170/90 MB/s SD card, but the boot time did not get any shorter.
-
I managed to clone the SD card with great difficulty,
congratulation!
I accidentally violated the seal,
congratulation! welcome to the club.
so I had to decide whether to take the device apart.
the fate is pretty clear right now.. who asked you to join eevblog?
-
Thanks, it was planned, but not so soon, I wanted to leave it untouched for another 5 months.
After watching a few of Dave's videos, I decided, I'll get answers to my questions here, so I'll join.
it is true that it took me half a year to register.
Is the above part ok?
Does anyone else have a similar partition allocation, I mean the unallocated part?
-
There is a complete card dump posted earlier, I don't remember which thread, someone also posted the offsets and the sizes of all partitions previously...
I also remember that when I listed the partitions in the /dev/block folder they were more than 10.
-
Here is the partition info https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008)
And here is the card image https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046580/#msg5046580 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046580/#msg5046580)
-
On topic of little cooling fan, I did some poking around, unless the litlle fan is voltage controlled by i2c regulator or the like, I believe the fan is simply attached to fixed voltage.
The "pwm_fan" driver is commented out in the start_rigol_app.sh script.
-
I took 804 (fw 01.02) to 914 via vendor bin file.
Then applied the BW15T25 option code, unit now says it's a 914 BW250.
Ran a self-cal.
I don't see any DC offset issue.
Are others seeing dc offset issue with the 250 option applied?
-
Yes with v01.01, not with v01.02.
-
Just a note :) The vertical calibration files (cal_vertical.hex) are significantly different between versions 01.01 and 01.02. In version 01.01 the file size is 205084 bytes, while in version 01.02 its size is 538300 bytes. The structure of these files is also clearly different.
I tried to quickly view the file structure of version 01.02. It is not clear what is what in its structure; all that is clear is that there is a file header and some identical records of 56 bytes in size. It seems that each entry contains a number in double format (64-bit floating point), a number in int64 format (64-bit integer) and some other obscure values that I could not clearly identify. If you look at these entries throughout the file, you can see that the file is clearly divided into three equal parts of 179 KB, each with approximately 3200 entries. At the beginning of each part, the double number has a value of approximately 10.5, and by the end of the part its value decreases to approximately 1.0. The int64 number in the first record has a value of 100 000 and with each record it increases in steps of 2 000 to a value of 200 000, then in steps of 5 000 to a value of 500 000, then in steps of 10 000 to a value of 1 000 000, then in increments of 20 000, and so on until the value of 10 000 000 000 in the last entry. And so on in all three parts of the file. I have no guesses as to the purpose of all these numbers. Maybe someone will have some idea what these numbers are.
-
Just a note :) The vertical calibration files (cal_vertical.hex) are significantly different between versions 01.01 and 01.02. In version 01.01 the file size is 205084 bytes, while in version 01.02 its size is 538300 bytes. The structure of these files is also clearly different.
I tried to quickly view the file structure of version 01.02. It is not clear what is what in its structure; all that is clear is that there is a file header and some identical records of 56 bytes in size. It seems that each entry contains a number in double format (64-bit floating point), a number in int64 format (64-bit integer) and some other obscure values that I could not clearly identify. If you look at these entries throughout the file, you can see that the file is clearly divided into three equal parts of 179 KB, each with approximately 3200 entries. At the beginning of each part, the double number has a value of approximately 10.5, and by the end of the part its value decreases to approximately 1.0. The int64 number in the first record has a value of 100 000 and with each record it increases in steps of 2 000 to a value of 200 000, then in steps of 5 000 to a value of 500 000, then in steps of 10 000 to a value of 1 000 000, then in increments of 20 000, and so on until the value of 10 000 000 000 in the last entry. And so on in all three parts of the file. I have no guesses as to the purpose of all these numbers. Maybe someone will have some idea what these numbers are.
You will have a better view of the file by 1st converting them using xxd, then open the conversion in your hex editor. The 01.02 is gonna be so much different than 01.01 so using vimdiff or the like probably fruitless.
It looks like blocks of cal data, I just not sure what all the numbers mean.
Although I don't see DC offset, the noise levels on ch1 and ch4 seem to drift way higher than ch2 or ch3. Put on some Vrms in Analyse using various modes (AC vs DC couple, etc), and I'll see ch1 ch4 be in 1-2mV area while ch2 ch3 are in 600uV area. At one point they were all in uV area, then ch1 ch4 got into the low mV area.
ch1 ch4 seems to drift some, at least away from ch2 ch3.
It's been talked about some, 01.02 FW might be for some production that had perhaps new chips (same function) that needed new cal file. Add to that Rigol yanked the 01.02 from all downloads. So now begs the question, wondering if 01.02 FW runs ok on the DHO's that came with 01.01 or older FW?
-
You will have a better view of the file by 1st converting them using xxd, then open the conversion in your hex editor. The 01.02 is gonna be so much different than 01.01 so using vimdiff or the like probably fruitless.
But why? I can already see hexadecimal representation in the hex editor. Here, it would probably be more useful to convert the file into a text representation of the records - the serial number of the record and the values stored in it. Create a .csv file with these values so you can see the big picture. Maybe build a graph using these values, maybe it will lead to some ideas.
It looks like blocks of cal data, I just not sure what all the numbers mean.
Yes, I don't understand this either. And I don’t understand why the file is divided into three identical parts, and not into four according to the number of channels. And why are there so many records with these values - more than 12,000 in total.
Add to that Rigol yanked the 01.02 from all downloads.
Yes, but at the same time version 01.02 began to arrive on oscilloscopes via OTA :)
So now begs the question, wondering if 01.02 FW runs ok on the DHO's that came with 01.01 or older FW?
Yes, my DHO814 oscilloscope, which came with firmware 01.01, works quite well after updating the firmware to 01.02. Moreover, with the new firmware it has been successfully upgraded to the DHO914 model without channel offsets.
-
You will have a better view of the file by 1st converting them using xxd, then open the conversion in your hex editor. The 01.02 is gonna be so much different than 01.01 so using vimdiff or the like probably fruitless.
But why? I can already see hexadecimal representation in the hex editor. Here, it would probably be more useful to convert the file into a text representation of the records - the serial number of the record and the values stored in it. Create a .csv file with these values so you can see the big picture. Maybe build a graph using these values, maybe it will lead to some ideas.
Well, try xxd convert and then look at the hex. See anything?
-
Well, try xxd convert and then look at the hex. See anything?
I don't have Linux to try. But I still don’t understand what it will give. It simply converts binary to hexadecimal, and I already see hexadecimal on the screen in the hex editor, as in the screenshot above :)
-
Well, try xxd convert and then look at the hex. See anything?
I don't have Linux to try. But I still don’t understand what it will give. It simply converts binary to hexadecimal, and I already see hexadecimal on the screen in the hex editor, as in the screenshot above :)
Not clear to me if the cal files are encrypted with TEA like the vendor bin file.
-
Not clear to me if the cal files are encrypted with TEA like the vendor bin file.
Absolutely not. Encrypted files cannot contain long sequences of the same character.
Today or tomorrow I will try to write a utility that will extract records from cal_vertical.hex into a readable text form. At least those fields that are definitely numbers.
-
You will have a better view of the file by 1st converting them using xxd, then open the conversion in your hex editor. The 01.02 is gonna be so much different than 01.01 so using vimdiff or the like probably fruitless.
But why? I can already see hexadecimal representation in the hex editor. Here, it would probably be more useful to convert the file into a text representation of the records - the serial number of the record and the values stored in it. Create a .csv file with these values so you can see the big picture. Maybe build a graph using these values, maybe it will lead to some ideas.
It looks like blocks of cal data, I just not sure what all the numbers mean.
Yes, I don't understand this either. And I don’t understand why the file is divided into three identical parts, and not into four according to the number of channels. And why are there so many records with these values - more than 12,000 in total.
Add to that Rigol yanked the 01.02 from all downloads.
Yes, but at the same time version 01.02 began to arrive on oscilloscopes via OTA :)
So now begs the question, wondering if 01.02 FW runs ok on the DHO's that came with 01.01 or older FW?
Yes, my DHO814 oscilloscope, which came with firmware 01.01, works quite well after updating the firmware to 01.02. Moreover, with the new firmware it has been successfully upgraded to the DHO914 model without channel offsets.
Interestingly, the firmware v00.01.01.00.01 is posted everywhere, and on the Chinese website v00.01.01.00.02
-
From what I can see, they version it using 5 sets of 2
00.01.01.00.01
00.01.01.00.02
Grab each of these and sha256 the zip, see if it's identical or not.
and then I see a 00.01.02.00.00, which is what my 804 came with. I think the 01.02 is dated something like Nov 2023.
The 1st two I think are just v01.01 FW's, could actually be the same exact FW.
One way to know for sure, download the 00.01.01.00.02 item, extract out the "cal_vertical.hex" file and see if it's near 538.3kB, this bigger cal file comes in v01.02
-
From what I can see, they version it using 5 sets of 2
00.01.01.00.01
00.01.01.00.02
Grab each of these and sha256 the zip, see if it's identical or not.
and then I see a 00.01.02.00.00, which is what my 804 came with. I think the 01.02 is dated something like Nov 2023.
The 1st two I think are just v01.01 FW's, could actually be the same exact FW.
One way to know for sure, download the 00.01.01.00.02 item, extract out the "cal_vertical.hex" file and see if it's near 538.3kB, this bigger cal file comes in v01.02
If it is the same firmware, then it is not logical to write separate release notes 00.01.01.00.02 in the Release Notes file. There is no correction item 00.01.01.00.02 in this file on the Rigol global server.
-
In this version 00.01.01.00.02 the size of the cal_vertical.hex file is the same as in version 00.01.01.00.01 - 205084 bytes.
I figured out a little about the header of the calibration files. This applies to all calibration files in all versions.
At offset 0 is the checksum (CRC32) of the header itself, with the exception of the length field - 4 bytes.
At offset 4 is the length of the header in bytes, starting at offset 8 (checksum and length fields excluded) - 4 bytes.
From bytes 12 to 20, I couldn’t figure out what was there. There is some pattern in them among different calibration files, but I don’t understand what it is.
At offset 20 is the size of the data in the file excluding the header - 4 bytes.
At offset 24 there is a checksum (CRC32) of the data in the file excluding the header - 4 bytes.
After this, the data itself begins, because The header size is 20 bytes everywhere (plus 4 bytes of checksum before the header).
-
From what I can see, they version it using 5 sets of 2
00.01.01.00.01
00.01.01.00.02
Grab each of these and sha256 the zip, see if it's identical or not.
and then I see a 00.01.02.00.00, which is what my 804 came with. I think the 01.02 is dated something like Nov 2023.
The 1st two I think are just v01.01 FW's, could actually be the same exact FW.
One way to know for sure, download the 00.01.01.00.02 item, extract out the "cal_vertical.hex" file and see if it's near 538.3kB, this bigger cal file comes in v01.02
If it is the same firmware, then it is not logical to write separate release notes 00.01.01.00.02 in the Release Notes file. There is no correction item 00.01.01.00.02 in this file on the Rigol global server.
I concur, there should be 4 distinct FW's for DHO800/900
Just seems odd that the 1st 3 are in the 01.01 line, then all of a sudden comes a 01.02, why not name the last one "00.01.01.00.03" or something like that. Perhaps just very bad versioning.
From 01.02 release note
Model Supported] All the DHO800/900 series oscilloscopes
[Latest Revision Date] 2023/11/2
[Updated Contents]
v00.01.02.00.00 2023/11/2
1. Self calibration optimization update
2. Solve the problem of UltraLab startup connection failure
3. Solve the problem of failure to save waveform in wfm format
4. Add education model equivalent settings
5. Solve the problem of unresponsive touch on startup screen
v00.01.01.00.02 2023/09/12
1. Self calibration optimization update
2. Update Help Documents
v00.01.01.00.01 2023/08/10
1. Remove all time-related displays on the instrument
2. To modify the vertical interface, click the wiring diagram to modify the AC coupling function
3. Modify the delayed scan Chinese display as Zoom
4. Modify the order of the menu in the upper right corner, put the measurement in the front and Default in the back
5. The probe ratio interface is removed, and the probe ratio option is added to the vertical first-level menu
v00.01.00.00.19 2023/07/24
1. The first version is released
-Released the production version.
-
I have attached a program that reads values from the cal_vertical.hex files of versions 00.01.01 and 00.01.02. The archive with the program contains, for example, the original file cal_vertical.hex and the file with the read values cal_vertical.hex.csv:
[attach=1]
The program saves everything to a .csv text file in the same directory. This is a console program for Windows. Just give it the file name cal_vertical.hex as an input parameter; this file must be in the same directory as the program.
As it turned out, cal_vertical.hex in version 00.01.02 is divided not into 3 parts, but into 12 parts. But in version 00.01.01 it is divided into only 4 parts.
-
Hmm, the sequential numbers in the entries seem to correspond to the vertical scale adjustment steps in fine mode.
Numbers: 100000,102000,104000,...,198000,200000,205000,210000,215000,...,495000,500000,510000,520000,530000,...,980000,990000,1000000,1 020000,1040000 and so on up to 10000000000, that is, 5 circles with a zero added to the end after each circle.
Increasing the voltage scale in fine mode:
1.00mv,1.02mv,1.04mv,...,1.98mv,2.00mv,2.05mv,2.10mv,2.15mv,...,4.95mv,5.00mv,5.10mv,5.20mv,5.30mv,... ,9.80mv,9.90mv,10.00mv,10.20mv,10.40mv and so on up to 10V, that is, the same 5 circles with the same step.
In version 00.01.01 this is repeated 4 times - we can assume that this is for 4 channels. But I don’t understand why in version 00.01.02 this is repeated 12 times. Three times per channel?
-
Perhaps done before, but I did a little probing of the Liteon PSU DC voltage line while powering DHO804.
Periodic (~62kHz) ~1.5MHz ringing, then some ~33MHz ringing in between.
Noted, I had a small 220uF hanging on the supply, which only brought down V by ~2mV.
Noted, not really sure if the noise is generated from the PSU or from the 804.
I'll now try to make inline filter using ferrite and some Henry.
Edit: after doing some models in LTspice, I think I can squash the noise -70 to -90dB on the 33MHz, near -40dB on the 1.5MHz, and near -30dB on the 62kHz, a substantial amount. Now I try it with real parts. ;)
-
Perhaps done before, but I did a little probing of the Liteon PSU DC voltage line while powering DHO804.
Periodic (~62kHz) ~1.5MHz ringing, then some ~33MHz ringing in between.
Noted, I had a small 220uF hanging on the supply, which only brought down V by ~2mV.
Noted, not really sure if the noise is generated from the PSU or from the 804.
I'll now try to make inline filter using ferrite and some Henry.
Edit: after doing some models in LTspice, I think I can squash the noise -70 to -90dB on the 33MHz, near -40dB on the 1.5MHz, and near -30dB on the 62kHz, a substantial amount. Now I try it with real parts. ;)
But why? If this is not reflected in the input channels? :)
-
Interesting. Changing only one value (out of 9612) in the cal_vertical.hex file leads to a zero shift for all four channels, and by different amounts and even with different signs.
-
Perhaps done before, but I did a little probing of the Liteon PSU DC voltage line while powering DHO804.
Periodic (~62kHz) ~1.5MHz ringing, then some ~33MHz ringing in between.
Noted, I had a small 220uF hanging on the supply, which only brought down V by ~2mV.
Noted, not really sure if the noise is generated from the PSU or from the 804.
I'll now try to make inline filter using ferrite and some Henry.
Edit: after doing some models in LTspice, I think I can squash the noise -70 to -90dB on the 33MHz, near -40dB on the 1.5MHz, and near -30dB on the 62kHz, a substantial amount. Now I try it with real parts. ;)
But why? If this is not reflected in the input channels? :)
Why? Because I can, I have all the parts needed, plus I am making usb-c spliiter to fit into a 3d printed frame that will hold a 92x14mm fan on rear vesa mount. I am not yet sure I want to mount the 804 to an arm, I am leaning not to, too "permanent" for my crazy workspace.
-
Why? Because I can, I have all the parts needed
Ah, well, I agree, that’s a pretty good reason :)
I am not yet sure I want to mount the 804 to an arm, I am leaning not to, too "permanent" for my crazy workspace.
In fact, this is an extremely convenient option. I myself did not understand all its convenience until I tried it. It greatly adds comfort to working with the oscilloscope - you can rotate, raise, lower, or move the oscilloscope as convenient at the moment. I work sitting closer to the computer, or sit down at the next table, or stand next to the workstation - I can always move the oscilloscope for comfortable work :)
I was also worried about the permanence of such a fastening, but the bracket I purchased turned out to be able to quickly remove and install the device, just unscrew a couple of wing nuts :)
-
Why? Because I can, I have all the parts needed
Ah, well, I agree, that’s a pretty good reason :)
I am not yet sure I want to mount the 804 to an arm, I am leaning not to, too "permanent" for my crazy workspace.
In fact, this is an extremely convenient option. I myself did not understand all its convenience until I tried it. It greatly adds comfort to working with the oscilloscope - you can rotate, raise, lower, or move the oscilloscope as convenient at the moment. I work sitting closer to the computer, or sit down at the next table, or stand next to the workstation - I can always move the oscilloscope for comfortable work :)
I was also worried about the permanence of such a fastening, but the bracket I purchased turned out to be able to quickly remove and install the device, just unscrew a couple of wing nuts :)
I just got the 804 short time ago, was looking to replace an older Owon unit, but I wanted full built-in battery operation like my Owon has, along with good FFT. Micsig probably would have worked for me, but I got the 804 at a good price, plust now it's a 914 250BW. I often times take my Owon from desk to garage to probe automotive stuff. I'll use the 804 for same thing but it has no built-in batt. So my scope travels around more than most do. I will perhaps keep using Owon in garage, but some of the knob "pots" need ixing. If I do an arm I'll need to think about rigging up a good quick disconnect so I don't have to unscrew things.
As for the calibration file, I wondering if that cal file has dedicated sections depending on specific hardware found in the unit by FW?
-
As for the calibration file, I wondering if that cal file has dedicated sections depending on specific hardware found in the unit by FW?
Looks like no. The firmware update supplied for all 8xx/9xx models is the same, and the default calibration file in this update is also the same for all models.
I believed that this file contained correction factors for each vertical scale step for all channels in various modes. But judging by the fact that changing one single value in this file leads to a displacement of all channels, and on many vertical scales, everything there is much more complicated. We need to conduct a lot of different experiments with this file, then perhaps some understanding will emerge.
-
I often times take my Owon from desk to garage to probe automotive stuff. I'll use the 804 for same thing but it has no built-in batt.
As for the frequent transfer of the oscilloscope to the garage... If I had to often take the oscilloscope from the workshop to work without mains power, I would probably assemble a 4S4P battery pack from 18650 cells and think about quickly mounting it on a VESA plate, which is screwed to the oscilloscope. I removed the oscilloscope from the bracket (unscrewing the two wing nuts is only 10 seconds), screwed the battery pack to the plate on the oscilloscope using the same wing nuts and took it to the garage or somewhere else :)
-
Somebody said the file got twice as big.
Maybe the 904 had a separate calibration file and this is the two files joined together to make one universal file.
-
Has anyone tried upgrade hacking the 802 yet?
-
Somebody said the file got twice as big.
Maybe the 904 had a separate calibration file and this is the two files joined together to make one universal file.
It became larger in the firmware update 01/00/02 for all models. It now has three times as many records, but the records themselves have become smaller and contain fewer values.
In addition, as far as I understand, in firmware 00.01.01 and earlier, the smaller file was also the same for all models; there was no separate file for 9xx. Although I could be wrong, because... I don't have the original .GEL file pulled from the 9xx model oscilloscope :)
-
By the way, I updated my program to read the calibration file cal_vertical.hex.
[attach=1]
Now the program displays the calibration date and time (I found where they are stored in the file). Additionally, I added two options:
-o - inserts into the .csv file the offset for each entry relative to the beginning of the file in hexadecimal.
-O is the same as -o, but in decimal format.
This is done so that it is easy to find the entry of interest from the .csv in the .hex file.
-
Maybe the new cal file was "digitized", meaning used some sort of actual stepping gear to calibrate the hardware, where before perhaps just linear interpolation between a few test points? :-//
-
Maybe the new cal file was "digitized", meaning used some sort of actual stepping gear to calibrate the hardware, where before perhaps just linear interpolation between a few test points? :-//
Unclear. If the calibration proceeds in steps and for each step its own coefficient is created in the calibration file (as I imagined before), then why does changing just one coefficient in the calibration file immediately affect all channels and many steps of the vertical scale? What are the other numbers in each entry next to the odds for (their value ranges from 0 to 3)? Perhaps these are the modes of input amplifiers/attenuators? For now there are only unanswered questions :)
If all this were understood, then it would be possible to manually refine the channel calibration more carefully than is done in automatic mode. Although, in principle, automatic calibration gives a satisfactory result, although not ideal.
-
I experimented with the supply voltage of the oscilloscope by connecting it to a laboratory power supply. The oscillograph works normally at a voltage from 9 to 16.8 volts, I was afraid to give more, not knowing what circuit it has at the power input. But since it is normally powered by 15 volts on its native power supply, it means it should also withstand 16.8V.
The minimum voltage at which it still remains operational is 8.5 volts, but this is already on the very verge of shutting down; as soon as the voltage drops a little lower, the oscilloscope reboots.
Power consumption is approximately constant - about 36.5 watts with the oscilloscope application running and about 31.2 watts with the application closed. But a force-closed application automatically restarts after a while :)
This all means that the oscilloscope can be powered from both a 4S battery (12-16.8V) and a 3S battery (9-12.6V).
The voltages shown in the photo on the power supply are inflated to compensate for the voltage drop on the wires. At the same time, the oscilloscope received almost exactly 9V and 16.8V.
-
I think it was clear the scope would at least operate on 12V considering the prototype power supply originally reported was a fixed (not PD) 12V supply. Since 12V is an optional, not mandatory, profile in the PD 3.x spec, while 15V is mandatory, I expect they negotiate 15V for widest PD supply compatibility.
-
I mounted mine with an arm and spacers for the plate. The arm I got is setup so a single thumbscrew is all it takes to remove it. I had a spacer made up to mount it below my microscope arm so I only have a single pole taking up space. I also attached a probe holder to the arm to keep them out of the way. Super convenient and no more permanent than it needs to be.
-
I experimented with the supply voltage of the oscilloscope by connecting it to a laboratory power supply. The oscillograph works normally at a voltage from 9 to 16.8 volts, I was afraid to give more, not knowing what circuit it has at the power input. But since it is normally powered by 15 volts on its native power supply, it means it should also withstand 16.8V.
The minimum voltage at which it still remains operational is 8.5 volts, but this is already on the very verge of shutting down; as soon as the voltage drops a little lower, the oscilloscope reboots.
Power consumption is approximately constant - about 36.5 watts with the oscilloscope application running and about 31.2 watts with the application closed. But a force-closed application automatically restarts after a while :)
This all means that the oscilloscope can be powered from both a 4S battery (12-16.8V) and a 3S battery (9-12.6V).
The voltages shown in the photo on the power supply are inflated to compensate for the voltage drop on the wires. At the same time, the oscilloscope received almost exactly 9V and 16.8V.
The DHO800 and perhaps the 900 use about 34w of power.
@12vdc you are max'ing out USB-C connector spec, and have surpassed std cable spec for amps.
It would really be best for equip like this to run on 24vdc to keep supply amps lower, and/or use a better connector, USB-C is not really a good choice, std barrel would have been better. Save USB-C for data.
-
The DHO800 and perhaps the 900 use about 34w of power.
@12vdc you are max'ing out USB-C connector spec, and have surpassed std cable spec for amps.
Huh? USB-C PD is rated up to 5A. Many laptops run at 20V 5A all day long on a USB-C port. USB-C PD 3.1 spec goes up to 48V 5A, so 240W. 12V3A is not even remotely pushing the limits of the USB-C connector. As far as cables go, 3A at 5V is the minimum current that a USB-C cable must support to even legally call itself a USB-C cable.
-
I think it was clear the scope would at least operate on 12V considering the prototype power supply originally reported was a fixed (not PD) 12V supply. Since 12V is an optional, not mandatory, profile in the PD 3.x spec, while 15V is mandatory, I expect they negotiate 15V for widest PD supply compatibility.
I was more interested in whether it would work on 9 volts to power it from 3S batteries :)
The DHO800 and perhaps the 900 use about 34w of power.
Even more than 36 watts.
It would really be best for equip like this to run on 24vdc to keep supply amps lower, and/or use a better connector, USB-C is not really a good choice, std barrel would have been better. Save USB-C for data.
Well, we have what we have. If desired, you can insert a power connector into the wall of the case.
-
Photos of the disassembled Liteon power supply - https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5248569/#msg5248569 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5248569/#msg5248569) :)
-
I also attached a probe holder to the arm to keep them out of the way. Super convenient and no more permanent than it needs to be.
Great idea, thanks! It will be necessary to print a similar holder for probes too :)
-
The DHO800 and perhaps the 900 use about 34w of power.
@12vdc you are max'ing out USB-C connector spec, and have surpassed std cable spec for amps.
Huh? USB-C PD is rated up to 5A. Many laptops run at 20V 5A all day long on a USB-C port. USB-C PD 3.1 spec goes up to 48V 5A, so 240W. 12V3A is not even remotely pushing the limits of the USB-C connector. As far as cables go, 3A at 5V is the minimum current that a USB-C cable must support to even legally call itself a USB-C cable.
Amps is the only thing that matters with USB-C. The physical spacing between connector pins both in port and on board, along with the insulation used on wires, can withstand much more than 48vdc. So the "power" rating does not mean too much for USB-C cables and connectors. If PD agrees for 20vdc and the cable is 5A rated, you get good 100w transfer. If PD agrees 48vdc and the cable is 5A rated, you get good 240w transfer.
DHO is about 34w. This maps to about 2.3A@15vdc for the DHO. Going to 12vdc you'll be up'ing the amps by about +0.6 (2.9A), taking it close to std cable max. 5A cable, then all good, but why increase amps, makes no sense to me.
5A on cables that are 5A rated. 5A is the std connector rating.
-
Amps is the only thing that matters with USB-C. The physical spacing between connector pins both in port and on board, along with the insulation used on wires, can withstand much more than 48vdc. So the "power" rating does not mean too much for USB-C cables and connectors.
5A on cables that can handle it. 5A is the connector rating.
Almost any cable will withstand 5A, the only question is how many volts will be lost on it :) The cable that I used (a cheap, worthless cable) to connect has a resistance of each power core of 70 mOhm, which means that at 5A it will drop 0.07*2*5=0.7V. Unpleasant, but not too critical :)
-
I think it was clear the scope would at least operate on 12V considering the prototype power supply originally reported was a fixed (not PD) 12V supply. Since 12V is an optional, not mandatory, profile in the PD 3.x spec, while 15V is mandatory, I expect they negotiate 15V for widest PD supply compatibility.
I was more interested in whether it would work on 9 volts to power it from 3S batteries :)
The DHO800 and perhaps the 900 use about 34w of power.
Even more than 36 watts.
It would really be best for equip like this to run on 24vdc to keep supply amps lower, and/or use a better connector, USB-C is not really a good choice, std barrel would have been better. Save USB-C for data.
Well, we have what we have. If desired, you can insert a power connector into the wall of the case.
I rounded off your HY PSU display #'s 17x2, but yep, 37.x watts from your PSU at that higher voltage.
37w @12vdc exceeds std USB-C cable specs. If it's a 5A rated cable, then ok. But why would anyone want to lower voltage for more amps? If anything, I want smaller wire (less used space on my desk, more flexible) with less amps.
-
Amps is the only thing that matters with USB-C. The physical spacing between connector pins both in port and on board, along with the insulation used on wires, can withstand much more than 48vdc. So the "power" rating does not mean too much for USB-C cables and connectors.
5A on cables that can handle it. 5A is the connector rating.
Almost any cable will withstand 5A, the only question is how many volts will be lost on it :) The cable that I used (a cheap, worthless cable) to connect has a resistance of each power core of 70 mOhm, which means that at 5A it will drop 0.07*2*5=0.7V. Unpleasant, but not too critical :)
Agreed.
I was just noting actual USB-C specs.
But my statement still holds, why up the amps going form 15v to 12v? :-//
-
But my statement still holds, why up the amps going form 15v to 12v? :-//
When powering the oscilloscope? This is the property of switching voltage converters - it takes from the source the same power that it supplies to the load (plus its own losses, that is, its efficiency). Therefore, if the source voltage decreases, the current taken from it increases in order to maintain the same power.
And if the question is why make a 9-12 volt 3S battery, then the point is compactness. For example, a 3S2P battery will be light and compact, providing about 2 hours of power to the oscilloscope :)
-
The specs you posted in that image show minimum required specs of 3A for cables and 5A for connectors, as I stated.
You said:
@12vdc you are max'ing out USB-C connector spec, and have surpassed std cable spec for amps.
which is entirely untrue on both counts.
36W at 12V is 3A. That meets even the minimum specs. It's nowhere near stressing the connector nor any remotely decent cable. I'm not sure why you're so concerned about 2.3A vs 2.9A when either are about half the connector spec and within the minimum cable spec? As you said, almost any cable is going to meet a 3A spec. Sure if you have a 100W+ device you want to be sure to spec a higher quality cable. But at these current levels you're not in any kind of exceptional territory with standard cables and connectors.
-
Mount the DHO to an arm: In fact, this is an extremely convenient option
Any issue with the weight of the oscilloscope ?
His weight is below 2Kg, and all arms I have checked begin at 2Kg and even 3Kg.
-
Any issue with the weight of the oscilloscope ?
His weight is below 2Kg, and all arms I have checked begin at 2Kg and even 3Kg.
Add weight to the arm if the scope is too light, like Ian did in his vesa mount video:
https://youtu.be/iB-SsFZvqiE?feature=shared (https://youtu.be/iB-SsFZvqiE?feature=shared)
-
Any issue with the weight of the oscilloscope ?
His weight is below 2Kg, and all arms I have checked begin at 2Kg and even 3Kg.
Add weight to the arm if the scope is too light, like Ian did in his vesa mount video:
https://youtu.be/iB-SsFZvqiE?feature=shared (https://youtu.be/iB-SsFZvqiE?feature=shared)
I saw this, but in fact I would like to avoid this hack, I would prefer to mod the arm if needed or better found one from 1Kg, for now only arms for mic or tablet begin at lower weight, and often need to adapt a vesa head.
-
Any issue with the weight of the oscilloscope ?
His weight is below 2Kg, and all arms I have checked begin at 2Kg and even 3Kg.
I have a bracket with adjustable force of the pneumatic cylinder. At the minimum adjusted force, the oscilloscope is held stably at the set height without trying to rise.
-
I've attached a version of the rigol unlock tools batch file translated to a .sh file for those of us using Mac computers. It still requires having adb and the Go language installed.
However, my DHO914 is not accepting the generated BW15T25 option SCPI command (no generated .lic file), either with the original 00.01.00 or now the 00.01.01 firmware downloaded from the rigolna site.
EDIT: and also not accepting the option with the 00.01.02 firmware posted here.
Has anyone succeeded in increasing the bandwidth of a real DHO914 this way on either of those firmwares?
-
I've attached a version of the rigol unlock tools batch file translated to a .sh file for those of us using Mac computers. It still requires having adb and the Go language installed.
However, my DHO914 is not accepting the generated BW15T25 option SCPI command (no generated .lic file), either with the original 00.01.00 or now the 00.01.01 firmware downloaded from the rigolna site.
EDIT: and also not accepting the option with the 00.01.02 firmware posted here.
Has anyone succeeded in increasing the bandwidth of a real DHO914 this way on either of those firmwares?
I think there should be no difference between a real 914 or an ex 814. My ex 814, which now considers itself a 914, accepted the BW15T25 generated option. But the generation tool was different - https://github.com/zelea2/rigol_vendor_bin
-
I succeeded deceive 814. BW15T25 passed without problems.
-
I succeeded deceive 814. BW15T25 passed without problems.
And I decided that an increase to 914 was enough. I didn’t find any reason to upgrade to 924, especially 924S :)
-
And I thought, why not? Now at least there are no empty spaces in the bottom panel. :) ;)
-
I succeeded deceive 814. BW15T25 passed without problems.
can you explain the step how to add LA and AFG without removing your serial number?
-
Now at least there are no empty spaces in the bottom panel. :) ;)
Good reason, I won't argue :)))
...
I discovered a couple of days ago that the keyboard shortcut Win + ] splits the screen :)
-
I succeeded deceive 814. BW15T25 passed without problems.
can you explain the step how to add LA and AFG without removing your serial number?
Simply change the scope model to DHO914S or DHO924S in the vendor.bin file. But LA and AFG won’t work anyway.
-
exactly...
-
I succeeded deceive 814. BW15T25 passed without problems.
can you explain the step how to add LA and AFG without removing your serial number?
Simply change the scope model to DHO914S or DHO924S in the vendor.bin file. But LA and AFG won’t work anyway.
any specific steps how to do that? i didnt follow this thread closely sorry. i'm working on to make both AFG and LA to work now, still in progress...
-
i'm working on to make both AFG and LA to work now, still in progress...
Oh thats cool! I will look forward to hearing about your results :)
In addition to this hardware, it looks like you also need to solder 2 missing memory chips onto the main board of the oscilloscope. Presumably this memory is needed for LA, but as far as I know, no one has yet tested this in practice.
any specific steps how to do that? i didnt follow this thread closely sorry.
1. Download the files /rigol/data/vendor.bin and /rigol/data/Key.data from the oscilloscope using ADB:
adb pull /rigol/data/vendor.bin
adb pull /rigol/data/Key.data
2. Using this program - https://github.com/zelea2/rigol_vendor_bin - change the oscilloscope model to DHO914S or DHO924S in the vendor.bin file:
rigol_vendor_bin.exe -M DHO924S
3. Using the same program, generate all possible options using the Key.data file:
rigol_vendor_bin.exe -o
For convenience, you can direct the program output to a file so that all generated options are saved in it:
rigol_vendor_bin.exe -o >>options.txt
4. Load the vendor.bin file back into the oscilloscope:
adb push vendor.bin /rigol/data/
5. Reboot the oscilloscope.
6. Send the DHO900-BODE and DHO900-BW15T25 options from those generated in step 3 via the SCPI interface.
-
1. Download the files /rigol/data/vendor.bin and /rigol/data/Key.data from the oscilloscope using ADB:
why i asked is one day when i'm done and ready to do FW hack, this thread will be 100 pages, it will be very difficult to find specific hack like this esp not everyone interested.. hence i saved your post's link with the content offline (local HDD) for my quick reference later, thanks.
In addition to this hardware, it looks like you also need to solder 2 missing memory chips onto the main board of the oscilloscope. Presumably this memory is needed for LA, but as far as I know, no one has yet tested this in practice.
reading rigol diy logic probe threads... i tried quick hack shorting "probe present" detection pin to gnd and LA gui got activated. i saw some up and down in LA signals, maybe due to random floated pins, so i guess this thing doesnt require the 2x DDR ram. i only soldered 2x unpopulated dual opamps near LA port (i guess its for trigger level D0-D7 and D8-D15) and one MPM3630 smps converter (with some difficulty) for 4V rail. i'm planning for external 5V power bank to power that rail from LA probe in case people are not willing to do MPM3630 on DHO800 board, so bare minimum is to solder 2x msop-8 opamps on DHO800 board. one thing i noted is 50Mpts memory for CH1 got halved when LA gui activated, so hopefully LA is using the another half, not from unpopulated DDR3L ram.
(https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/?action=dlattach;attach=1942692;image)
https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5200419/#msg5200419 (https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5200419/#msg5200419)
since its look like brighter hope, i already had a go at doing this and already cut the front panel of my scope and made youtube video to guide others if interested, its irrevesible, and since its not final yet (the LA probe probably wont work as expected), i dont think to publish the link yet so far.
same thing with AFG module.. 2x dual opamps (original TP1282, i replaced with OPA2350, same as the LA) required to install for AFG offset and magnitude (gain) i already have a working prototype module but i have noise/crosstalk issue to fix at low level signal, thats why i asked csuhi17 in fw bug report thread about it, i already redid pcb ver2... now waiting for LA probe module to complete before sending both prototype to jlcpcb... fwiw.
https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot (https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot)
https://www.youtube.com/watch?v=vKeOM21Gt7A (https://www.youtube.com/watch?v=vKeOM21Gt7A)
-
I've attached a version of the rigol unlock tools batch file translated to a .sh file for those of us using Mac computers. It still requires having adb and the Go language installed.
However, my DHO914 is not accepting the generated BW15T25 option SCPI command (no generated .lic file), either with the original 00.01.00 or now the 00.01.01 firmware downloaded from the rigolna site.
EDIT: and also not accepting the option with the 00.01.02 firmware posted here.
Has anyone succeeded in increasing the bandwidth of a real DHO914 this way on either of those firmwares?
I think there should be no difference between a real 914 or an ex 814. My ex 814, which now considers itself a 914, accepted the BW15T25 generated option. But the generation tool was different - https://github.com/zelea2/rigol_vendor_bin
I was finally able to get the BW increase using the rigol_vendor_bin, while the rigol unlock tools didn't work for me. I don't know why there was a difference, but I now have 250MHz bandwidth displayed.
-
why i asked is one day when i'm done and ready to do FW hack, this thread will be 100 pages, it will be very difficult to find specific hack like this esp not everyone interested.. hence i saved your post's link with the content offline (local HDD) for my quick reference later, thanks.
I agree, unfortunately, it’s already quite difficult to find useful points in such a large topic. I have seen forums where a topic is assigned a curator who regularly updates the first post of the topic with links to interesting and useful posts from the topic. It would be very convenient :)
You go into the topic and immediately see a mini-QWO with links to relevant posts:
- how to update the firmware
- how to upgrade to an older model
- how to open options
- useful programs
Etc. :)
reading rigol diy logic probe threads... i tried quick hack shorting "probe present" detection pin to gnd and LA gui got activated. i saw some up and down in LA signals, maybe due to random floated pins, so i guess this thing doesnt require the 2x DDR ram. i only soldered 2x unpopulated dual opamps near LA port (i guess its for trigger level D0-D7 and D8-D15) and one MPM3630 smps converter (with some difficulty) for 4V rail. i'm planning for external 5V power bank to power that rail from LA probe in case people are not willing to do MPM3630 on DHO800 board, so bare minimum is to solder 2x msop-8 opamps on DHO800 board. one thing i noted is 50Mpts memory for CH1 got halved when LA gui activated, so hopefully LA is using the another half, not from unpopulated DDR3L ram.
(https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/?action=dlattach;attach=1942692;image)
https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5200419/#msg5200419 (https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/msg5200419/#msg5200419)
since its look like brighter hope, i already had a go at doing this and already cut the front panel of my scope and made youtube video to guide others if interested, its irrevesible, and since its not final yet (the LA probe probably wont work as expected), i dont think to publish the link yet so far.
same thing with AFG module.. 2x dual opamps (original TP1282, i replaced with OPA2350, same as the LA) required to install for AFG offset and magnitude (gain) i already have a working prototype module but i have noise/crosstalk issue to fix at low level signal, thats why i asked csuhi17 in fw bug report thread about it, i already redid pcb ver2... now waiting for LA probe module to complete before sending both prototype to jlcpcb... fwiw.
https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot (https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot)
https://www.youtube.com/watch?v=vKeOM21Gt7A (https://www.youtube.com/watch?v=vKeOM21Gt7A)
This is very interesting and cool! If there are ready-made instructions for making AFG and LA, that will be great :)
-
This is very interesting and cool! If there are ready-made instructions for making AFG and LA, that will be great :)
it will involve buying lots of parts.. rev engineering, making circuit and pcb and assembling them ;) my target is cheapest 250MHz 1GSps MSO+sig_gen (bode plot and LA probe included) at cheaper cost than DHO924S (or DHO914S) alone...
-
it will involve buying lots of parts.. rev engineering, making circuit and pcb and assembling them ;) my target is cheapest 250MHz 1GSps MSO+sig_gen (bode plot and LA probe included) at cheaper cost than DHO924S (or DHO914S) alone...
Whoever wants to do it will buy it :) Whoever doesn’t want to or can’t will buy it from you on eBay ;)
-
Does anyone have the 1.02 firmware for the DHO800 and also when upgrading the DHO804 to DHO924 are all of the DC reading within spec for the DHO924 and is anything out of the spec in the datasheet
-
Does anyone have the 1.02 firmware for the DHO800 and also when upgrading the DHO804 to DHO924 are all of the DC reading within spec for the DHO924 and is anything out of the spec in the datasheet
IIRC someone attached it as a zip, and/or gave a link to the zip that has the 01.02 FW, but it's a few posts/pages back. You'll need to do some digging.
-
But when you upgrade it to 924 does it now act within the specs or is it still off
-
But when you upgrade it to 924 does it now act within the specs or is it still off
800's to 900's seem to behave ok. Certainly 802 to 914, or 804 to 924S will have some limitations due to missing hardware/connections.
You gain mainly better scale resolution, mem depth, and BW.
My 804 runs as a 914, seems to work ok (on FW 01.02). It's kinda at the limitations of the hardware at this point.
-
would you recommend upgrading to 924 or 914 and whats the difference not the S
-
would you recommend upgrading to 924 or 914 and whats the difference not the S
Not being willing to read a couple of pages in the forum is one thing. Not being willing to read even the high-level product bullet points at any online seller's website, takes it to another level. I am not sure you are ready to perfom any "hack", since you would need to follow a paragraph of instructions or two. ::)
-
I have read through most of the thread and the sellers documentation I understand that 914 is 125 mhz and and the 924 is 250mhz but to my understanding there is a rigol addon which allows you to change the 914 to have 250 mhz aswell. I just wanted to confirm that I didn't miss anything given this thread is 33 pages.
-
Yes, you can upgrade within each family (804 to 814, 914 to 924) by buying upgrade keys from Rigol, or generating such keys yourself via a key generator script which is also available in this thread. Going from the 800 to the 900 series requires the other hacking approach, by modifying or replacing the vendor.bin file.
It should be equivalent whether you go straight to the 924 via its vendor.bin, or go to the 914 and then apply the bandwidth upgrade key later.
In either case, it is questionable whether the 924 model makes much sense. The actual, measured bandwidth for the 914 is already higher than specified by Rigol, namely around 200 MHz. And given the limited sampling rate of the small DHOs, they can't really keep up with that bandwidth once you enable more than two channels (and hence run at only ~ 300 MHz sampling rate per channel). So you will get aliasing if higher frequency components than half the sampling rate are present in the signal.
Frankly, I would stick with an upgrade to the 814 model. That one also has the higher measured bandwidth, and it won't annoy you with a display for the non-existent digital channels on the screen.
-
is it better to change the vendor.bin from 804 to 814 or just do the license key upgrades or is there no difference
-
is it better to change the vendor.bin from 804 to 814 or just do the license key upgrades or is there no difference
The resulting functionality should be exactly the same. Personally I would prefer the approach via the license key, since the result looks more "official": The scope will still identify as an 804, consistent with its front panel, just with the 100 MHz bandwidth upgrade applied. In contrast, an 804 which identifies as an 814 can only be obtained via hacking.
Either modification is reversible, of course, e.g. if you need to send the scope in for service. It's a bit easier with the license key approach, where you just need to send an official SCPI command (:SYST:OPT:UNINST).
-
Thanks, Im still leaning to upgrading it to a 914 or 924 for the 200 μV/div, does the aliasing issue exist on the real DHO900s or only on the hacked 800s
-
The aliasing isue is related to the sample rate.
The absolute minimum sample rate has to be at least double the measured frequency.
With ~300MS/s (4 channels active, or the logic analyzer and 2 channels) you can only measure frequency content up to 150MHz maximum. In practice, more like 120MHz.
The scope doesn't limit the bandwith nor tells you about this.
I get that more is better, but with the 100MHz key you are actually getting close to 200MHz bandwith. I'd leave it at 814, you can always change the vendor.bin later on if needed.
Edit: so, yes, the original 914 will have the same problem, or even worse with the logic channels active.
-
The aliasing isue is related to the sample rate.
The absolute minimum sample rate has to be at least double the measured frequency.
With ~300MS/s (4 channels active, or the logic analyzer and 2 channels) you can only measure frequency content up to 150MHz maximum. In practice, more like 120MHz.
The scope doesn't limit the bandwith nor tells you about this.
I get that more is better, but with the 100MHz key you are actually getting close to 200MHz bandwith. I'd leave it at 814, you can always change the vendor.bin later on if needed.
Edit: so, yes, the original 914 will have the same problem, or even worse with the logic channels active.
problem with siglent fanboys is they expect the machine to be "automatic". even 804 70MHz you can put into aliasing if too large timebase. so you have to keep the bolded line above in mind during probing because rigol dho is more or less a "manual transmission" car. meaning if you want to probe 250MHz circuit, make sure you dont activate all channels. 1 or 2 channels maximum. siglent machine will be unable to probe this high frequency content if you forgot to deactivate all channels too. its like spitting bullshit that a manual car cannot automatically change gear similar to automatic car. manual car has its benefit. whats that? i leave that to your imagination. i already mentioned that implicitly.
-
siglent machine will be unable to probe this high frequency content if you forgot to deactivate all channels too.
In Siglent's defense, they do adhere to the Nyquist limit in their scopes' design and specs. The entry level models have 2 GSa/s (in contrast to the DHO800/900's 1.25 GSa/s), and they go up to 200 MHz input bandwidth. So even in 4-channel mode, you get 500 MSa/s or 2.5 x the analog bandwidth.
Rigol is pushing their specs beyond that limit. And specifically with the DHO 900 series, where they cut the sampling rate in half when activating the digital channels (and without telling anywhere in the manual or spec sheet!), they are pushing way too far in my opinion. 125 156 MSa/s is sad even in an entry-level scope, and a bit absurd in a scope with a "250 MHz bandwidth!" banner spec.
-
siglent machine will be unable to probe this high frequency content if you forgot to deactivate all channels too.
In Siglent's defense, they do adhere to the Nyquist limit in their scopes' design and specs.
yes in effect the machine is crippling itself. in order to probe high freq, we have to remember switching off the other channels too. my point is, we dont operate our machine mindlessly, something need to keep in mind.
The entry level models have 2 GSa/s (in contrast to the DHO800/900's 1.25 GSa/s), and they go up to 200 MHz input bandwidth. So even in 4-channel mode, you get 500 MSa/s or 2.5 x the analog bandwidth.
extrapolating from rigol situation, someone will try to hack the 2GSps machine to 1GHz BW, because sometime they need maximum BW esp rf nuts. while saving money from buying rf grade dso. imho this is why rigol hack is so hot around here. while there are hack threads for siglent too, but siglent is double or more the price... keyword is bang per buck... as i said, if siglent can get SDS800X price close enough to rigol, maybe it could be a game changer, cheers.
-
This helps solve the problem with time zones. https://4pda.to/forum/index.php?showtopic=798101&view=findpost&p=57379222
-
This helps solve the problem with time zones. https://4pda.to/forum/index.php?showtopic=798101&view=findpost&p=57379222
Thanks, the program works great. After the reboot, the time zone remained the one I configured.
-
The aliasing isue is related to the sample rate.
The absolute minimum sample rate has to be at least double the measured frequency.
With ~300MS/s (4 channels active, or the logic analyzer and 2 channels) you can only measure frequency content up to 150MHz maximum. In practice, more like 120MHz.
The scope doesn't limit the bandwith nor tells you about this.
I get that more is better, but with the 100MHz key you are actually getting close to 200MHz bandwith. I'd leave it at 814, you can always change the vendor.bin later on if needed.
Edit: so, yes, the original 914 will have the same problem, or even worse with the logic channels active.
problem with siglent fanboys is they expect the machine to be "automatic". even 804 70MHz you can put into aliasing if too large timebase. so you have to keep the bolded line above in mind during probing because rigol dho is more or less a "manual transmission" car. meaning if you want to probe 250MHz circuit, make sure you dont activate all channels. 1 or 2 channels maximum. siglent machine will be unable to probe this high frequency content if you forgot to deactivate all channels too. its like spitting bullshit that a manual car cannot automatically change gear similar to automatic car. manual car has its benefit. whats that? i leave that to your imagination. i already mentioned that implicitly.
I don't think it is much of a problem, really, but I thought it was worth mentioning, because is an easy trap to fall on for beginners.
I understand the advantages of manual cars, and don't use automatics.
Still, manual or not, the 900 series should state the sampling limitation with LA, and it should be quite visible. There are a lot of beginners using this scopes, I think this is a fair thing to say.
Edit: Although you are right in that it is better to have 250MHz max. that cannot be used with all channels, than crippling bandwith to never have aliasing problems.
-
i try hack files on 802 model - all work ok , 100Mhz and 50mpts achieved
-
i try hack files on 802 model - all work ok , 100Mhz and 50mpts achieved
Details please.
-
I watched both of Retrochannel's videos, and first updated to the 01.01 firmware, and applied the bandwidth/sample depth hack by connecting the scope directly to my router via Ethernet. Everything seemed to work fine. I then ordered a USB WiFi adapter and tried to set that up and noticed a lot of... flaky behavior.
When I first tried, the touch screen didn't work with the keyboard plugged in. Since then, it hasn't been an issue. However, on about 1 in 5 bootups with the WiFi dongle installed, I will get "LAN Disconnected" and everything works fine. The other 4 out of 5 times, it seems to just ignore the dongle. I don't think I ever saw an instance of disconnecting and reconnecting the dongle fixing the issue. If you reboot enough, it will eventually work, but it seems pretty random. When it's not working, attempts to turn on WiFi don't work. It'll go on for a split second and then disable. I'm thinking I just got lucky the first time when I went to go set everything up.
Anyone got any ideas? I apologize if this was discussed earlier and I missed it.
-
wever, on about 1 in 5 bootups with the WiFi dongle installed, I will get "LAN Disconnected" and everything works fine. The other 4 out of 5 times, it seems to just ignore the dongle. I don't think I ever saw an instance of disconnecting and reconnecting the dongle fixing the issue. If you reboot enough, it will eventually work, but it seems pretty random. When it's not working, attempts to turn on WiFi don't work. It'll go on for a split second and then disable. I'm thinking I just got lucky the first time when I went to go set everything up.
I take it that you have confirmed that you have the right WiFi adapter version (TL-WN725N, version 2.0 or 3.0)? Do you still have the USB hub connected, from the initial setup via the keyboard? If so, it's worth a try to remove it and plug the WiFi dongle into the scope directly.
-
I take it that you have confirmed that you have the right WiFi adapter version (TL-WN725N, version 2.0 or 3.0)? Do you still have the USB hub connected, from the initial setup via the keyboard? If so, it's worth a try to remove it and plug the WiFi dongle into the scope directly.
I have tried with and without the hub. In order to reduce the chances of a problem, I bought it using the Amazon link provided. Bottom of the package identifies it as: TL-WN725N(US) Ver 3.6, UPC Code: 845973050719
For shits and giggles, I plugged it into my Windows Laptop, the driver appeared to identify as a Realtek 8188EU. After playing with it more, I'd say it's working less than 1 in 5 times. I haven't been able to get it to work in at least 10 reboots.
Few other observations: The physical keyboard seems to work consistently. I tried the USB WiFi in my computer twice, and both times the little green light in the device turned on.
So, it's possible that the USB connection in the Rigol is faulty, but this seems very unlikely. It's possible the WiFi dongle is faulty (seems unlikely) or it's the wrong chipset (also seems unlikely). If it is the dongle, I might be able to exchange it at Amazon. The other possibility is that installing the bandwidth/memory updates somehow hosed everything up. Seems unlikely too, but it's got to be something, right? Other people are presumably not having this problem.
-
I seem to want one of these scope for some reason. I have an 1104X-E, upgraded to a 1204X-E with the signal generator (the AWG, full function, not the adapter). I'm intrigued by the DHO814 and read most of the pages here and they seem to be about all the hacks. I understand all the advantages of 12b vs 8bit, etc.
But I'm wondering of people really like the 814? I realize I won't be getting much out of it, but the user interface is consistent with all the other modern devices and the update rates on the FFT look snappier than my 1104X-E. On the 1104, I seem to have to hit a lot of buttons to make changes. Even compared to my ancient Tek 3054C that has a vertical knob column for acquisition. I didn't notice if the battery came with the 814? I also have an Owon 7102 with battery so no gain there. Was also wondering if Siglent might try to leapfrog Rigol with their own low-end 12Bit.
thanks
Jerry
-
But I'm wondering of people really like the 814?
I like mine a lot! The touch screen is a massive upgrade and the UI is really fast to navigate. You really won't ever go back to twisty-knob models after using one.
Siglent is responding (they have to!):
https://www.eevblog.com/forum/testgear/siglent-new-sds800x-hd-first-bactch-unboxing-and-noise-compare-with-dho800/msg5238453/#msg5238453 (https://www.eevblog.com/forum/testgear/siglent-new-sds800x-hd-first-bactch-unboxing-and-noise-compare-with-dho800/msg5238453/#msg5238453)
-
Siglent is responding (they have to!):
why you have to keep relating to siglent even if when not asked? ???
You really won't ever go back to twisty-knob models after using one.
try vertical offset change using screen when all 4 channels active. if you can get rid of rotary knob, tell me... screen interface on that matter still need improvement, its automatic changing channel to what it thinks closest to where you touch, and it sucks tbh. i will still use rotary knob for that
On the 1104, I seem to have to hit a lot of buttons to make changes.
same thing happened to my rigol DS1054Z, i think the internal need cleaning.
I didn't notice if the battery came with the 814?
no battery, too bad. if switch off dso, date is lost. but well, we dont buy dso as timekeeper, esp the cheap one what do you expect? ymmv.
-
Siglent is responding (they have to!):
why you have to keep relating to siglent even if when not asked? ???
Damned if I do, damned if I don't... :-//
-
Update to 01.02 or not ?
I don't like to upgrade if I don't see any improvement for my usage, but But maybe they didn't notice all the changes in the readme.txt !
So have you seen any improvements or bug fixed ? (other than the offset error for those who modify the vendor file).
I'm suspicious with this upgrade because it's not even available on their website for download, weird behavior from Rigol !
-
The touch screen is a massive upgrade and the UI is really fast to navigate. You really won't ever go back to twisty-knob models after using one.
??? Weren't you happy with your all-in-wonder Micsig? Or, afterall, their screen/UI was not so good??
-
The touch screen is a massive upgrade and the UI is really fast to navigate. You really won't ever go back to twisty-knob models after using one.
??? Weren't you happy with your all-in-wonder Micsig? Or, afterall, their screen/UI was not so good??
Could we relegate that kind of squabbling to one of the general unboxing, impressions etc. threads please? This thread is meant to be focused on hacking approaches, and is getting a bit unwieldy anyway. Thanks.
-
since its look like brighter hope, i already had a go at doing this and already cut the front panel of my scope and made youtube video to guide others if interested, its irrevesible, and since its not final yet (the LA probe probably wont work as expected), i dont think to publish the link yet so far.
Wow. You appear to have made significant progress here. I saw your video about cutting the LA port slot, and I want to offer another way... perhaps it may be easier to do it is using a 3D-printed template that will rest on the outer wall of the first BNC deepening and the left USB port. I believe they have more than enough position accuracy for placing the template. With the template you you will have more control over the cutting process. Then, I suggest using a manual jigsaw instead of Dremel.
And since I currently have 914s on hand, I can do all of the measuring, modeling, and several test prints to ensure that everything is properly positioned because everyone has only one try)).
Also, I thought it would be nice after cutting the LA port slot to 3d print the inner walls of the slot to hide the gap between the front walls of the MSO and its pcb, as is done on the DHO900... it may help it to look not so DIY.
-
Also, I thought it would be nice after cutting the LA port slot to 3d print the inner walls of the slot to hide the gap between the front walls of the MSO and its pcb, as is done on the DHO900... it may help it to look not so DIY.
thanks for your offer and idea. another way of doing it is cut the slot however nasty shape it will be, even if slightly bigger not a problem. and then 3d print rectangle or however fancy, sci-fi techy shape covering on outer wall with protrusion to the inside wall touching to metal enclosure inside not a problem, to make it more look neat. but this requires the owner to have 3d printer. and imho its a bit wasteful and time consuming just to make a "one-time use disposable" cutting template, just learn to cut properly with whatever tools you have, cheers.
-
...just learn to cut properly with whatever tools you have, cheers.
I completely agree, however not everyone has jeweler's hands, therefore I believe it took some work to make this slot as beautiful as possible without messing it up... especially if you want to use the MSO frequently and don't want to look at an ugly hole on its neat face.
Anyway, when you finish your project I would be happy to help with this template.
-
Anyway, when you finish your project I would be happy to help with this template.
you asked about the dimension of the slot hole and depth, and someone else answered.
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5159226/#msg5159226 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5159226/#msg5159226)
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5166510/#msg5166510 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5166510/#msg5166510)
but i think whats missing are distances of the slot to the top, bottom and side wall of the front panel relatively, so we can measure and draw guideline at the correct position, correctly aligned to the inside metal slot, not the slight mistake i've made in the video you saw. i hope you understand i dont have time to draw where they are. if you can measure and post for us, then it probably helpful one day, but not for me, its too late for me :P
-
since its look like brighter hope, i already had a go at doing this and already cut the front panel of my scope and made youtube video to guide others if interested, its irrevesible, and since its not final yet (the LA probe probably wont work as expected), i dont think to publish the link yet so far.
Wow. You appear to have made significant progress here. I saw your video about cutting the LA port slot, and I want to offer another way... perhaps it may be easier to do it is using a 3D-printed template that will rest on the outer wall of the first BNC deepening and the left USB port. I believe they have more than enough position accuracy for placing the template. With the template you you will have more control over the cutting process. Then, I suggest using a manual jigsaw instead of Dremel.
And since I currently have 914s on hand, I can do all of the measuring, modeling, and several test prints to ensure that everything is properly positioned because everyone has only one try)).
Also, I thought it would be nice after cutting the LA port slot to 3d print the inner walls of the slot to hide the gap between the front walls of the MSO and its pcb, as is done on the DHO900... it may help it to look not so DIY.
If 3d printer is available, perhaps just easier to cut the scope bezel in rough dimensions to fit the connector needed, then 3d print a bezel that fits over the connector snugly and covers the scope cut. Result should be somewhat professional finish.
-
I take it that you have confirmed that you have the right WiFi adapter version (TL-WN725N, version 2.0 or 3.0)? Do you still have the USB hub connected, from the initial setup via the keyboard? If so, it's worth a try to remove it and plug the WiFi dongle into the scope directly.
I have tried with and without the hub. In order to reduce the chances of a problem, I bought it using the Amazon link provided. Bottom of the package identifies it as: TL-WN725N(US) Ver 3.6, UPC Code: 845973050719
For shits and giggles, I plugged it into my Windows Laptop, the driver appeared to identify as a Realtek 8188EU. After playing with it more, I'd say it's working less than 1 in 5 times. I haven't been able to get it to work in at least 10 reboots.
Few other observations: The physical keyboard seems to work consistently. I tried the USB WiFi in my computer twice, and both times the little green light in the device turned on.
So, it's possible that the USB connection in the Rigol is faulty, but this seems very unlikely. It's possible the WiFi dongle is faulty (seems unlikely) or it's the wrong chipset (also seems unlikely). If it is the dongle, I might be able to exchange it at Amazon. The other possibility is that installing the bandwidth/memory updates somehow hosed everything up. Seems unlikely too, but it's got to be something, right? Other people are presumably not having this problem.
My 804 will not link to my netgear DS104 hub, I had to use a switch.
I don't think your USB-A port is bad, probably a driver issue. What does the green light mean on the USB wifi adapter? Just power, or communicating with host?
-
No battery? I thought I saw a version, I'll have to go back and look, that had two batteries that slipped into the back? Either way, there are hundreds of USBC options including solar.
-
No battery? I thought I saw a version, I'll have to go back and look, that had two batteries that slipped into the back? Either way, there are hundreds of USBC options including solar.
..... any options need to provide around 37watt of power for 800 series, possibly a smidge more on the 900 series when using the logic input stuff.
Considering the 800/900's don't seem to manage input power (USB PD), a simple 15v PSU with barrel connector would have sufficed. USB PD is good for when the PSU is home for multi power sinks.
-
??? Weren't you happy with your all-in-wonder Micsig? Or, afterall, their screen/UI was not so good??
I'm very happy with the Micsig, I don't regret buying it at all.
Things have moved on though.
-
I don't know what the green light is. I noticed it when I plugged it into my laptop. I presume it's some sort of activity light.
It wouldn't shock me if it's a driver issue but I'm using the adapter that the instructions say to get, I even bought it from the same Amazon link. There is a version discrepancy (they say to use V2 or 3, but this seems to be V3.6) -- however, it identifies as a Realtek 8188EU, which is what the V3 allegedly is, so you'd think that would be okay.
-
I don't know what the green light is. I noticed it when I plugged it into my laptop. I presume it's some sort of activity light.
It wouldn't shock me if it's a driver issue but I'm using the adapter that the instructions say to get, I even bought it from the same Amazon link. There is a version discrepancy (they say to use V2 or 3, but this seems to be V3.6) -- however, it identifies as a Realtek 8188EU, which is what the V3 allegedly is, so you'd think that would be okay.
Which item specifically?
The one that works should be the TP-Link TL-WN725N. I just orderd it from amzon for $10(US), just to try it.
-
No battery? I thought I saw a version, I'll have to go back and look, that had two batteries that slipped into the back? Either way, there are hundreds of USBC options including solar.
Most likely you have seen an amateur mod. There is such a video on YouTube.
https://www.youtube.com/watch?v=MbBq1AVIQAc&t=1s&pp=ygUMcmlnb2wgZGhvODAw (https://www.youtube.com/watch?v=MbBq1AVIQAc&t=1s&pp=ygUMcmlnb2wgZGhvODAw)
-
I tried the USB WiFi in my computer twice, and both times the little green light in the device turned on.
My green light also lights up when I connect the adapter to the computer, but when the adapter is connected to the scope, this green light does not light up, although the adapter works stably and the scope is connected to the network. Adapter - TP-LINK TL-WN725N.
-
I tried the USB WiFi in my computer twice, and both times the little green light in the device turned on.
My green light also lights up when I connect the adapter to the computer, but when the adapter is connected to the scope, this green light does not light up, although the adapter works stably and the scope is connected to the network. Adapter - TP-LINK TL-WN725N.
This is what I purchased:
https://www.amazon.com/gp/product/B008IFXQFU?th=1 (https://www.amazon.com/gp/product/B008IFXQFU?th=1)
This is what I received:
-
I don’t have a DHO800, but if you can run the Linux dmesg command in an ADB command line, the kernel should post messages that could indicate what’s going wrong with the Wi-Fi adapter when you plug it in.
-
I don’t have a DHO800, but if you can run the Linux dmesg command in an ADB command line, the kernel should post messages that could indicate what’s going wrong with the Wi-Fi adapter when you plug it in.
Sorry for asking if you could spoonfeed me here, but could you elaborate on exactly what to do? I don't have much experience using ADB.
-
Considering the 800/900's don't seem to manage input power (USB PD)
What I think understand with this trace (I got it with a FNB58), there is PD negotiations when the power supply is connected.
SOURCE give SourceCapabilities
SINK Make a request
SOURCE Accept
[attachimg=1 width=600]
-
Sorry for asking if you could spoonfeed me here, but could you elaborate on exactly what to do? I don't have much experience using ADB.
First, connect the ADB to the oscilloscope with the command: adb connect 192.168.x.x:55555 (1 in the screenshot). Of course, instead of 192.168.x.x, substitute the real IP address of the oscilloscope.
Then go to the command line of the oscilloscope with the command: adb shell (2 in the screenshot).
There, enter the command: dmesg >>/rigol/dmsg.txt (3 in the screenshot). This will create a file /rigol/dmsg.txt and direct all dmesg output to it.
Exit the oscilloscope command line with the command: exit (4 in the screenshot).
Download the dmsg.txt file from the oscilloscope with the command: adb pull /rigol/dmsg.txt (5 in the screenshot).
Now you have a dmsg.txt file in your adb directory, which you can open and view in any text editor.
I don’t know what to look for there, I’m not very friendly with Linux :) I hope that knowledgeable people can tell you this :)
-
Sorry for asking if you could spoonfeed me here, but could you elaborate on exactly what to do? I don't have much experience using ADB.
First, connect the ADB to the oscilloscope with the command: adb connect 192.168.x.x:55555 (1 in the screenshot). Of course, instead of 192.168.x.x, substitute the real IP address of the oscilloscope.
Then go to the command line of the oscilloscope with the command: adb shell (2 in the screenshot).
There, enter the command: dmesg >>/rigol/dmsg.txt (3 in the screenshot). This will create a file /rigol/dmsg.txt and direct all dmesg output to it.
Exit the oscilloscope command line with the command: exit (4 in the screenshot).
Download the dmsg.txt file from the oscilloscope with the command: adb pull /rigol/dmsg.txt (5 in the screenshot).
Now you have a dmsg.txt file in your adb directory, which you can open and view in any text editor.
I don’t know what to look for there, I’m not very friendly with Linux :) I hope that knowledgeable people can tell you this :)
This seems potentially problematic. I can't access it via WiFi if the problem is occuring, and if it's not, there's probably nothing to look at. Maybe I could connect to it via Ethernet, but that might affect WiFi? Other alternative might be via USB... I could potentially connect a USB cable to the scope if I use the hub on the scope, but I'd think then I wouldn't want to connect via IP address.
-
This seems potentially problematic. I can't access it via WiFi if the problem is occuring, and if it's not, there's probably nothing to look at. Maybe I could connect to it via Ethernet, but that might affect WiFi? Other alternative might be via USB... I could potentially connect a USB cable to the scope if I use the hub on the scope, but I'd think then I wouldn't want to connect via IP address.
Indeed, when connecting to a LAN, the WiFi adapter loses its IP address, although it remains connected to the access point. It’s probably better to connect via USB, but unfortunately, I don’t know how to connect via ADB in this case.
-
Sorry for asking if you could spoonfeed me here, but could you elaborate on exactly what to do? I don't have much experience using ADB.
First, connect the ADB to the oscilloscope with the command: adb connect 192.168.x.x:55555 (1 in the screenshot). Of course, instead of 192.168.x.x, substitute the real IP address of the oscilloscope.
Then go to the command line of the oscilloscope with the command: adb shell (2 in the screenshot).
There, enter the command: dmesg >>/rigol/dmsg.txt (3 in the screenshot). This will create a file /rigol/dmsg.txt and direct all dmesg output to it.
Exit the oscilloscope command line with the command: exit (4 in the screenshot).
Download the dmsg.txt file from the oscilloscope with the command: adb pull /rigol/dmsg.txt (5 in the screenshot).
Now you have a dmsg.txt file in your adb directory, which you can open and view in any text editor.
I don’t know what to look for there, I’m not very friendly with Linux :) I hope that knowledgeable people can tell you this :)
You need to be on ethernet to see what the USB is doing.
Noted: dmesg on android is limited.
Connect your scope via wire, give it an IP via a keyboard and mouse (via usb hub) connected to the USB-A port.
Connect to the scope from PC or laptop using browser, just goto the IP address, etc.
Once confirmed the scope is connected to your network, unplug all from scope USB port
Using the ADB toolset, from your PC/laptop (assume windows), start a cmd shell, cd to the adb tools directory
then do this:
adb connect YourScopeIP:55555
adb shell
su -
dmesg -c (this shows ring buffer, then clears it out)
dmesg (this should just show you blank, since the buffer was cleared)
lsusb
plug in the wifi dongle, wait about 2sec
lsusb
dmesg
hit enter to scroll as needed
copy this dmesg and lsusb text from your cmd window, post it here so we can see what it's complaining about.
then do
exit
exit
adb disconnect
As a test, I did that procedure, except I plugged in one of my Logitech USB adapters for wireless keyboard/mouse, and the android found new hardware, ID'd it as vendor Logitech, and attached it for use.
If the wifi dongle can't be attached to the host, the messages should indicate why.
-
I tried the USB WiFi in my computer twice, and both times the little green light in the device turned on.
My green light also lights up when I connect the adapter to the computer, but when the adapter is connected to the scope, this green light does not light up, although the adapter works stably and the scope is connected to the network. Adapter - TP-LINK TL-WN725N.
This is what I purchased:
https://www.amazon.com/gp/product/B008IFXQFU?th=1 (https://www.amazon.com/gp/product/B008IFXQFU?th=1)
This is what I received:
Well, a v3.6 may be the issue.
Did you follow a vid like this one, you kinda need the keyboard to do config through the gui. Get the dmesg info that I listed a post or so back from here.
https://www.youtube.com/watch?v=ECc2BdJzZfs (https://www.youtube.com/watch?v=ECc2BdJzZfs)
-
This is what I purchased:
https://www.amazon.com/gp/product/B008IFXQFU?th=1 (https://www.amazon.com/gp/product/B008IFXQFU?th=1)
This is what I received:
I found the box from my adapter. It seems the same. The difference between EU and US, I think, is only in the frequency grid and maximum power.
-
I found the box from my adapter. It seems the same. The difference between EU and US, I think, is only in the frequency grid and maximum power.
You did spot the difference between "Ver 3.0" and "Ver. 3.6" though?
-
You did spot the difference between "Ver 3.0" and "Ver. 3.6" though?
Yes, even earlier in the discussion. Of course, this could be the problem, but I don't think so.
-
This is what I purchased:
https://www.amazon.com/gp/product/B008IFXQFU?th=1 (https://www.amazon.com/gp/product/B008IFXQFU?th=1)
This is what I received:
I found the box from my adapter. It seems the same. The difference between EU and US, I think, is only in the frequency grid and maximum power.
The box label hpmaxim posted has "v3.6" with a distinctive extra "5G" printed. Not sure what that "5G" means, it's a 2.4GHz-only device.
TP-link driver download page shows the v3 linux driver is from 2018. But, Windows and MAC has a much newer publish date. So maybe the 2018 drivers were ok for the v3.0 stuff, but with v3.6 TP-link only updated Windows and MAC ?
Not sure, but I will have the nano soon to test with.
-
The box label hpmaxim posted has "v3.6" with a distinctive extra "5G" printed. Not sure what that "5G" means, it's a 2.4GHz-only device.
TP-link driver download page shows the v3 linux driver is from 2018. But, Windows and MAC has a much newer publish date. So maybe the 2018 drivers were ok for the v3.0 stuff, but with v3.6 TP-link only updated Windows and MAC ?
Not sure, but I will have the nano soon to test with.
I'm sure that the 5G on the label has nothing to do with the frequency or type of connection, it's something official, like the designation of a specific factory, or order number or something like that :)
On the TP-Link website there is support for simply version 3 without specifying subversions, so this subversion should not have any meaning for the host. Most likely it reflects minor changes in the gland. For example, a different antenna, a different layout, a different type of plastic in the end :) But the chip remains the same, with the same characteristics and the same interface to the host.
I don't rule out the possibility that this could create connection problems, but I'll be very surprised if it turns out to be true :)
-
I bought the required WIFI adapter on the second try. The chip we need here is the REALTEK RTL8188EU. The first realtek rtl8188CU I bought does not work with rigol.!!!
-
I bought the required WIFI adapter on the second try. The chip we need here is the REALTEK RTL8188EU. The first realtek rtl8188CU I bought does not work with rigol.!!!
What laser etching is on the No-Go nano? Are they the same model # ?
-
there is no engraving there, I showed it in the photo..... I bought both adapters according to the principle of the chip I needed, and not according to the adapter model number....
-
Sorry, haven't had an opportunity to try the suggestions yet. To clear things up, yes, I watched the Doom video. Yes, I used a USB 4 port hub, with a USB keyboard and the TP Link Dongle.
I want to be clear that I have never seen a version number listed on any of the listings. So, in order to "be safe", I ordered off the Amazon listing pointed to by the video that was identified as version 3.0. If Amazon is shiping V3.6 (and it appears they are), and version 3.6 is incompatible for whatever reason, someone really should I identify a seller who will reliably sell you V3, and remove the Amazon link from the video and/or elsewhere. I think it's also reasonable to assume that if TPLink is now producing V3.6, that they will cease to produce V3, and that V2 and V3 will become increasingly difficult to get, and it may be a good idea to start hunting for other compatible devices.
-
I had a look at the TP-Link website, and there is no mention of a version 3.6, neither on the product nor support part of the site, and whether I select Germany or US as the country. (But here is no mention of other "decimal point" sub-versions either, they just talk about V1, V2 and V3.)
Hence I guess a comparison of dmesg outputs, or outputs from whatever other tools might give detailed information under whichever OS, is our best bet to try and understand potential differences between versions 3.0 and 3.6. I no longer have my DHO1074, but still have a v3.0 TP-Link dongle which I could ask Windows or Linux about. But diagnostic outputs directly from a DHO's Android environment might be more useful?
-
I had a look at the TP-Link website, and there is no mention of a version 3.6, neither on the product nor support part of the site, and whether I select Germany or US as the country. (But here is no mention of other "decimal point" sub-versions either, they just talk about V1, V2 and V3.)
Hence I guess a comparison of dmesg outputs, or outputs from whatever other tools might give detailed information under whichever OS, is our best bet to try and understand potential differences between versions 3.0 and 3.6. I no longer have my DHO1074, but still have a v3.0 TP-Link dongle which I could ask Windows or Linux about. But diagnostic outputs directly from a DHO's Android environment might be more useful?
I have observed the same on TP site.
I did some searching around and apparently some box stickers now say "v3.8".
You can use my procedure in reply #845 (a page back) on any basic linux install. Droid will just have limited switches to use with dmesg and lsusb, so that's what I put in #845.
Try it with your v3.0 on linux, post what you get.
The next step is to just dig out the driver the dho has for a usb wifi device.
-
Here is the result of dmesg from my scope with a normally working adapter TL-WN725N(EU) according to Randy222's instructions (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5269047/#msg5269047), just for comparison:
rk3399_rigol:/ # lsusb
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # lsusb
Bus 003 Device 006: ID 0bda:8179
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # dmesg
[17956.250192] usb 3-1: new high-speed USB device number 6 using xhci-hcd
[17956.370762] usb 3-1: New USB device found, idVendor=0bda, idProduct=8179
[17956.370849] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17956.370865] usb 3-1: Product: 802.11n NIC
[17956.370878] usb 3-1: Manufacturer: Realtek
[17956.370889] usb 3-1: SerialNumber: 00E04C0001
[17956.378239] bFWReady == _FALSE call reset 8051...
[17956.405746] RTW: 0x000: 29 81 00 6C 0B 00 00 00 00 0C 00 00 00 00 00 00
[17956.405944] RTW: 0x010: 25 24 24 25 25 25 29 29 29 28 28 F1 FF FF FF FF
[17956.406046] RTW: 0x020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.406126] RTW: 0x030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.408038] RTW: 0x040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.408150] RTW: 0x050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.408240] RTW: 0x060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.408323] RTW: 0x070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.408423] RTW: 0x080: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.408508] RTW: 0x090: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.408599] RTW: 0x0a0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.408680] RTW: 0x0b0: FF FF FF FF FF FF FF FF A1 3F 17 00 00 00 00 00
[17956.408769] RTW: 0x0c0: 00 01 00 10 00 00 00 00 00 03 FF FF FF FF FF FF
[17956.408854] RTW: 0x0d0: DA 0B 79 81 43 66 00 78 8C B5 B8 A3 8C 09 03 52
[17956.408937] RTW: 0x0e0: 65 61 6C 74 65 6B 0D 03 38 30 32 2E 31 31 6E 20
[17956.409044] RTW: 0x0f0: 4E 49 43 0C 03 30 30 45 30 34 43 30 30 30 31 00
[17956.409135] RTW: 0x100: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.409224] RTW: 0x110: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.409317] RTW: 0x120: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.409438] RTW: 0x130: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.409534] RTW: 0x140: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.409634] RTW: 0x150: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.409717] RTW: 0x160: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.409810] RTW: 0x170: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.409892] RTW: 0x180: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.410081] RTW: 0x190: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.410219] RTW: 0x1a0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.410321] RTW: 0x1b0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.410437] RTW: 0x1c0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.410535] RTW: 0x1d0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.410645] RTW: 0x1e0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.410738] RTW: 0x1f0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[17956.410841]
[17956.410910] RTW: hal_com_config_channel_plan chplan:0x21
[17956.413652] RTW: rtw_regsty_chk_target_tx_power_valid return _FALSE for band:0, path:0, rs:0, t:-1
[17956.413818] [WLAN_RFKILL]: rockchip_wifi_mac_addr: enter.
[17956.413835] [WLAN_RFKILL]: get_wifi_addr_vendor: rk_vendor_read wifi mac address failed (-1)
[17956.418688] RTW: rtw_ndev_init(wlan0) if1 mac_addr=78:8c:b5:b8:a3:8c
[17956.421098] RTW: rtw_ndev_init(p2p0) if2 mac_addr=7a:8c:b5:b8:a3:8c
rk3399_rigol:/ #
-
You can use my procedure in reply #845 (a page back) on any basic linux install. Droid will just have limited switches to use with dmesg and lsusb, so that's what I put in #845.
Try it with your v3.0 on linux, post what you get.
Sorry -- I forgot that my Linux notebook is on loan to a friend at the moment. My Raspberry-based mini-MAME cabinet refuses to even boot with the TP-Link adapter installed, so I'm out of suitable test devices unfortunately.
-
@hpmaxim,
If you insert a usb mem stick (FAT), does the DHO (droid) attach it?
If so then you know the USB-A port is not faulty.
Which version of DHO firmware do you have?
-
well, some sleuthing around, dug up some info.
@hpmaxim, when you plug in that nano wifi into Windows, what RT chipset is identified?
If the v2 with 8188EUS works (8188CU from v1 did not), then I would expect v3 v3.6 v3.8 (v3.x) to also work, they (v2 v3) should all have the RTL8188EUS wifi chipset. I say that because the current downloadable driver package for linux is for RTL8188E.
RT has variants of 8188E (EUS, ETV, etc). Feature diffs, etc. I suspect the drivers provided by TP-link are source code snipped to accomodate 8188EUS.
Side note, the driver package has lines in makefile for compiling against an android sdk, but those lines are commented out.
browse into /system/lib/modules
read the readme.txt file
then
modinfo /system/lib/modules/8188eu.ko
I guess you could drop in any compiled-for-droid driver source there, to support any wifi adapter you wanted to use.
-
I guess you could drop in any compiled-for-droid driver source there, to support any wifi adapter you wanted to use.
Really? Is that how it works? The drivers are totally agnostic of any details of the specific SoC the OS is running on?
-
I guess you could drop in any compiled-for-droid driver source there, to support any wifi adapter you wanted to use.
Really? Is that how it works? The drivers are totally agnostic of any details of the specific SoC the OS is running on?
Must be compiled against android sdk (OS), and the platform architecture.
The RTL8188 linux driver package has in it ability to compile for arm android.
ARCH := arm
#Android-JB42
#CROSS_COMPILE := /home/android_sdk/Allwinner/a31/android-jb42/lichee/buildroot/output/external-toolchain/bin/arm-linux-gnueabi-
#KSRC :=/home/android_sdk/Allwinner/a31/android-jb42/lichee/linux-3.3
#ifeq ($(CONFIG_USB_HCI), y)
#MODULE_NAME := 8188eu_sw
#endif
# ==== Cross compile setting for kitkat-a3x_v4.5 =====
CROSS_COMPILE := /home/android_sdk/Allwinner/a31/kitkat-a3x_v4.5/lichee/buildroot/output/external-toolchain/bin/arm-linux-gnueabi-
KSRC :=/home/android_sdk/Allwinner/a31/kitkat-a3x_v4.5/lichee/linux-3.3
ARCH := arm
# ===Cross compile setting for Android 4.2 SDK ===
#CROSS_COMPILE := /home/android_sdk/Allwinner/a20_evb/lichee/out/android/common/buildroot/external-toolchain/bin/arm-linux-gnueabi-
#KSRC := /home/android_sdk/Allwinner/a20_evb/lichee/linux-3.3
# ==== Cross compile setting for Android 4.3 SDK =====
#CROSS_COMPILE := /home/android_sdk/Allwinner/a20/android-jb43/lichee/out/android/common/buildroot/external-toolchain/bin/arm-linux-gnueabi-
#KSRC := /home/android_sdk/Allwinner/a20/android-jb43/lichee/linux-3.4
# ==== Cross compile setting for kitkat-a20_v4.4 =====
CROSS_COMPILE := /home/android_sdk/Allwinner/a20/kitkat-a20_v4.4/lichee/out/android/common/buildroot/external-toolchain/bin/arm-linux-gnueabi-
KSRC := /home/android_sdk/Allwinner/a20/kitkat-a20_v4.4/lichee/linux-3.4
-
The start scripts in /rigol/shell/ are interesting.
Some lines of the shell scripting seem to be extraneous/useless.
But today I did set a screen dim timer so if you walk away for an hour or so the screen will dim to about -95% after the timer, and lowered the overall screen brightness from 255 to 200.
They also set a boot count tracker, does a "+1" to the counter on each boot and set into a property key. I fixed that, changed +1 to a +0
getprop, setprop, settings are all good to know commands.
Not sure why they don't use hwclock and set it to OS date.
Btw, it also starts ftpd, and has sshd running. Do I need ftp? I shut down ftpd. ssh can be handy for not wanting to use adb
-
The start scripts in /rigol/shell/ are interesting.
Some lines of the shell scripting seem to be extraneous/useless.
But today I did set a screen dim timer so if you walk away for an hour or so the screen will dim to about -95% after the timer, and lowered the overall screen brightness from 255 to 200.
They also set a boot count tracker, does a "+1" to the counter on each boot and set into a property key. I fixed that, changed +1 to a +0
getprop, setprop, settings are all good to know commands.
Not sure why they don't use hwclock and set it to OS date.
Btw, it also starts ftpd, and has sshd running. Do I need ftp? I shut down ftpd. ssh can be handy for not wanting to use adb
Thanks, interesting information.
I also set automatic screen dimming, but through the Android settings. And I use FTP to take screenshots, so I probably won’t disable it :)
Regarding the download counter - very interesting, is it just for statistics or can it be used somehow? Well, for example, every 100th boot, request an update via OTA, or something similar.
And I found the time zone setting for Asia/Shanghai, I’ll try to replace it with my own zone and see what happens, maybe there will no longer be a need for a separate application to force installation when loading the correct time zone.
-
Btw, it also starts ftpd, and has sshd running. Do I need ftp? I shut down ftpd. ssh can be handy for not wanting to use adb
I use FTP to get screenshots and .csv files out of it.
It's much easier/faster than messing around with USB sticks.
-
The new firmware version has arrived - https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5272446/#msg5272446 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5272446/#msg5272446) :)
It's funny, but after the update the maximum bandwidth dropped to 125 MHz. It appears that the update has removed the band extension option. And there may be other options. Although the .LIC files are all still there.
-
It's funny, but after the update the maximum bandwidth dropped to 125 MHz. It appears that the update has removed the band extension option. And there may be other options. Although the .LIC files are all still there.
I just installed it and did some quick tests and my license keys seem to have stopped working.
-
I just installed it and did some quick tests and my license keys seem to have stopped working.
Yeah. We can try to generate and activate the options again.
But what’s nice is that on the new firmware it was calibrated noticeably better than on the previous one 00.01.02.00.00, the vertical displacement is much smaller at all limits. But there was also a joke (although maybe it was there before, I just didn’t notice it): at some limits, turning on/off the 20 MHz band limit leads to a vertical shift. Moreover, if you switch the vertical scale one step up or down, and then go back, the shift disappears. This is especially noticeable on channel 4 of my oscilloscope at scales of 10, 20 and 50 mV (with a 1x probe divider installed). Here the vertical displacement jumps by as much as one and a half small divisions (a little more than a quarter of the major division).
-
All in all...
Now, instead of the file /Rigol/Data/Key.data, this directory contains the file /Rigol/Data/RKey.data, the contents of which are different from the old one.
The rigol_vendor_bin.exe utility generates options (if you rename RKey.data to Key.data), but the oscilloscope does not accept the generated options, it writes “License invalid. Remaining attempts: X”, where X starts with 9 and decreases with each attempt. I tried changing the key file by renaming Key.data to RKey.data and loading it into the oscilloscope. But even in this case, the oscilloscope does not accept the options, it writes “Invalid key”. Something has changed in the algorithm for generating and checking options.
-
Oh, yeah! "Key.data" has vanished and there's a new file "RKey.data"
Maybe we can make new licenses using that...
Update: Nope, not with the existing key generator.
-
Something has changed in the algorithm for generating and checking options.
Finally!! I haven't done an analysis but I can only expect the programmers to have studied a little more about how to correctly implement ECC cryptography in a Rigol droid machine...
That clearly shows Rigol isn't happy with the DHO license mess and will be making life a little harder for people intending to license "upgrade" their machines.
However, what user @DrMefistO released yesterday in the MSO5000 hack thread should be the way to go (if all is according to plan) for this new DHO reality.
-
That clearly shows Rigol isn't happy with the DHO license mess and will be making life a little harder for people intending to license "upgrade" their machines.
Changing vendor.bin is easier than generating license keys.
(unless somebody figured out how to do serial number->license while I wasn't paying attention)
-
Rigol release a new firmware 1.02.02 on their Chinese website, and looks like they change the "Key" file to "RKey", and all my hack was gone.
I tried to re-hack it but fail, so this looks like a completely different key file.
Thankfully I have a full disk image backup so I can recover it easily, But If you don't, DO NOT UPDATE TO THE LATEST FIRMWARE at least before people find a new way to hackin
Edit: oops looks like I am a bit late
-
Firmware downgrade is easy.
You DID make a copy of your Key.data, right? :)
-
That clearly shows Rigol isn't happy with the DHO license mess and will be making life a little harder for people intending to license "upgrade" their machines.
Changing vendor.bin is easier than generating license keys.
(unless somebody figured out how to do serial number->license while I wasn't paying attention)
If they corrected everything then even "changing vendor.bin" should become "harder".
Nonetheless, just changing vendor.bin doesn't solve all the option upgrade possibilities. At least, future ones.
-
To upgrade/downgrade firmware I just copy DHO800_DHO900_Update.GEL onto the internal disk with FTP and use the "upgrade" menu. No need to mess around with USB sticks.
I just went back to firmware 1.01, no problem.
With firmware 1.02 I can still use a DHO914 vendor.bin for bandwidth/memory upgrade (I was on DHO804 with licenses before).
(Does anybody know where the 'scope's "Internal storage" is mounted in the file system?)
-
If they corrected everything then even "changing vendor.bin" should become "harder".
I doubt they're "correcting" the protection. If they wanted that they could just disable ADB.
-
If they corrected everything then even "changing vendor.bin" should become "harder".
I doubt they're "correcting" the protection. If they wanted that they could just disable ADB.
:wtf: The licensing method being correct has nothing to do with ADB being enabled/disabled.
-
:wtf: The licensing method being correct has nothing to do with ADB being enabled/disabled.
They are technically separate things, of course, but clearly they both impact "hackability": Having ADB access (or some other access to the file system) was required to perform the license generation, in order to get to the key.data file. And having ADB access has been sufficient to perform some upgrades by swapping or modifying vendor.bin, independent of the license generation scheme used.
So I do see Fungus' point: If Rigol wanted to close the "hack door", they could also have disabled ADB access. Anyway, they took a different approach.
Has anyone tried the vendor.bin swap with the new firmware yet? Rigol didn't put additional checks in place for that, or did they?
-
(Does anybody know where the 'scope's "Internal storage" is mounted in the file system?)
/data/UserData/
Has anyone tried the vendor.bin swap with the new firmware yet? Rigol didn't put additional checks in place for that, or did they?
I just changed from 914 to 924 - everything is ok, the oscilloscope considers itself a DHO924 model with a bandwidth of 250 MHz. Despite the fact that in the original it is DHO814 :)
-
:wtf: The licensing method being correct has nothing to do with ADB being enabled/disabled.
It wasn't clear what you meant by "correcting".
They don't care much about hacking so why would they be working on the encryption math to make sure it was correct?
If they want to prevent hacking then step 1 would be disabling ADB.
So I do see Fungus' point: If Rigol wanted to close the "hack door", they could also have disabled ADB access. Anyway, they took a different approach.
The only reason I can think of is that they decided to start selling upgrades and the math was broken.
Has anyone tried the vendor.bin swap with the new firmware yet? Rigol didn't put additional checks in place for that, or did they?
vendor.bin works perfectly.
How would they check it anyway? They'd have to add some hardware to the PCB to identify the model.
-
It appears that the AES key used to decode the Key.data file has changed. When decoding a file from the previous firmware, a text string similar to the key is obtained that looks like this:
brainpoolP256r1;0405B21204BBA6FF16B9110FD458F4B2EF5A8484B7B46A259BCA90D66BC425BD5E960DFDEB0F6D368EFDB0FB64B43D93FF4FB554D33EB74D0006E5D09A54791EF2
But when decoding a file from the new firmware, we get some nonsense with non-printable characters as in screenshot.
[attach=1]
We need to extract a new AES key from the new Sparrow.apk application. I think it is in this application.
-
vendor.bin works perfectly.
How would they check it anyway? They'd have to add some hardware to the PCB to identify the model.
Shouldn't be too difficult to check whether that extra memory chip is populated, i.e. whether it's a 900 or 800 series. And maybe there is redundant information in the FRAM (as it is the case for the key.data content) which they are ignoring so far but could check against the vendor.bin?
-
The start scripts in /rigol/shell/ are interesting.
Some lines of the shell scripting seem to be extraneous/useless.
But today I did set a screen dim timer so if you walk away for an hour or so the screen will dim to about -95% after the timer, and lowered the overall screen brightness from 255 to 200.
They also set a boot count tracker, does a "+1" to the counter on each boot and set into a property key. I fixed that, changed +1 to a +0
getprop, setprop, settings are all good to know commands.
Not sure why they don't use hwclock and set it to OS date.
Btw, it also starts ftpd, and has sshd running. Do I need ftp? I shut down ftpd. ssh can be handy for not wanting to use adb
Thanks, interesting information.
I also set automatic screen dimming, but through the Android settings. And I use FTP to take screenshots, so I probably won’t disable it :)
Regarding the download counter - very interesting, is it just for statistics or can it be used somehow? Well, for example, every 100th boot, request an update via OTA, or something similar.
And I found the time zone setting for Asia/Shanghai, I’ll try to replace it with my own zone and see what happens, maybe there will no longer be a need for a separate application to force installation when loading the correct time zone.
Zone setting is in the /rigol/shell/start_rigol_app.sh script, so yep, just change it to your TZ using std TZ setting. I changed mine.
I did not get to the hwclock line yet. Not sure why they call it like they do.
They load things in a time sensitive sequence, I tried reducing the sleep timers and found issues when doing that.
You can grab screen pics direct from web ui.
I was trying to do scpi commands from droid shell, but it's not easy to do, they use an encoding scheme in the web ui page via .js scripts. The actual encoded scpi command gets pushed direct to tcp port 9004 vis basic web socket. If you run the same command in web ui, the actual encoding sent changes. I want the unit to boot up and then go to STOP state with CH1 off.
-
I was trying to do scpi commands from droid shell, but it's not easy to do, they use an encoding scheme in the web ui page via .js scripts. The actual encoded scpi command gets pushed direct to tcp port 9004 vis basic web socket. If you run the same command in web ui, the actual encoding sent changes. I want the unit to boot up and then go to STOP state with CH1 off.
Hmm, it seems that no coding is performed to send the command, the command text is sent as is. Here the answers come in a hex that needs to be converted to UTF8.
But I can’t help here - I’m very unfamiliar with Linux and web programming :)
-
I was trying to do scpi commands from droid shell, but it's not easy to do, they use an encoding scheme in the web ui page via .js scripts. The actual encoded scpi command gets pushed direct to tcp port 9004 vis basic web socket. If you run the same command in web ui, the actual encoding sent changes. I want the unit to boot up and then go to STOP state with CH1 off.
Hmm, it seems that no coding is performed to send the command, the command text is sent as is. Here the answers come in a hex that needs to be converted to UTF8.
But I can’t help here - I’m very unfamiliar with Linux and web programming :)
I can confirm that the command you type into web gui is not the actual payload sent to tcp port 9004.
There's actually 4 sets of command types, each type will be sent to a different port, 9001 9002 9003 or 9004.
The javascript used on the SCPI page does some form of coding beyond just a UTF8. Using Wireshark I can see the payload each time I send command via web ui, I will send :RUN numerous times and each payload is different, but 10bytes with 1st four the same for the :RUN command
-
The javascript used on the SCPI page does some form of coding beyond just a UTF8. Using Wireshark I can see the payload each time I send command via web ui, I will send :RUN numerous times and each payload is different, but 10bytes with 1st four the same for the :RUN command
Strange, I see on the page sending text directly from the command input field to the websocket: websocket.send(command.value);
No coding is done before this.
I even created a local page for sending SCPI commands and disabled external scripts - and it works :) I checked it with a Java script trace.
-
You can send SCPI commands via "telnet" (really just a raw IP connection) on port 5555.
-
The javascript used on the SCPI page does some form of coding beyond just a UTF8. Using Wireshark I can see the payload each time I send command via web ui, I will send :RUN numerous times and each payload is different, but 10bytes with 1st four the same for the :RUN command
Strange, I see on the page sending text directly from the command input field to the websocket: websocket.send(command.value);
No coding is done before this.
I even created a local page for sending SCPI commands and disabled external scripts - and it works :) I checked it with a Java script trace.
Just for reference, my 804 came with 00.01.02 FW
open scpi page IP/scpi.html
I use FF, so I do "view source"
There's 2 .js files loaded in.
open each .js, there's an obvious encoding scheme going on, on "input" data, which then comes back as command.value
They appear to encode the data prior to websocket.send()
in config.js you'll see the "function encode(input)" section
The actual web socket construct to tcp 9004 for sending the command is made in the js file, not in any code in scpi.html.
Can you share your html page for sending scpi commands.
-
I just read a little about websockets. Simply sending command texts to port 9004 (websocket) will not work. There you must first initiate the websocket protocol with a special header.
There's 2 .js files loaded in.
open each .js, there's an obvious encoding scheme going on, on "input" data, which then comes back as command.value
They appear to encode the data prior to websocket.send()
in config.js you'll see the "function encode(input)" section
No, command.value is simply the value of the page element with id command.
You can remove links to these two additional scripts from the source text of the page and sending/receiving commands will still work, just the results will not be displayed on the page. You just need to substitute a specific address in the websocket creation function instead of the standardCommandServerUrl variable.
That is, the websocket creation line in the main file should look like this:
const websocket = new WebSocket("ws://192.168.1.171:9004");
(Replace the IP address with the address of your oscilloscope)
That's all. No other scripts, no coding :)
The encoding function encode(input) located in the config.js file is only called from another function in the same file - getImageData(event). Judging by the content of this function, encoding applies to jpeg images. Perhaps it is encoded into base64 or vice versa from it.
Attached are screenshots of the script trace with sending direct command text to the websocket and receiving a response from the oscilloscope. This is from a local file in which references to external scripts have been removed.
-
So... It seems that the issue of licenses and keys is not dealt with by the application itself, but by one of the binary libraries in it - libscope-auklet.so
Only in this library is the file name RKey.data found, and it also contains a list of all oscilloscope models, and not only the 800/900 series.
And it also contains functions with promising names. Glory to the Rigol programmers who give us binaries with debugging information :))
But the disassembler (Ghidra) has been analyzing and parsing this library for about 40 minutes; I have never encountered such a long analysis time.
-
So... It seems that the issue of licenses and keys is not dealt with by the application itself, but by one of the binary libraries in it - libscope-auklet.so
Yes, almost all the 'scopes functions are in that file.
When it was announced I thought there would be a lot of Java to hack around and modify but it turns out there isn't. There's a huge .so file with everything except the UI in it.
It should be possible to search the old .so file for the previous AES key then look in the same area of the new .so for the new key.
-
I guess you could drop in any compiled-for-droid driver source there, to support any wifi adapter you wanted to use.
Really? Is that how it works? The drivers are totally agnostic of any details of the specific SoC the OS is running on?
Must be compiled against android sdk (OS), and the platform architecture.
The kernel then
disagrees about version of symbol module_layoutwhen insmodding, so Module.symvers (https://sven.killig.de/android/DHO/Module.symvers) has to be extracted from the kernel partition and used for the build.
I did this and here are the Wifi modules that fall out of an Advantech rk3399 BSP build:
8188fu.ko 8189fs.ko 8723bs.ko 8723cs.ko 8822be.ko mlan.koI don't own any of these models, but if someone does and wants to give it a try:
https://sven.killig.de/android/DHO/system/lib/modules/
-
well, some sleuthing around, dug up some info.
@hpmaxim, when you plug in that nano wifi into Windows, what RT chipset is identified?
If the v2 with 8188EUS works (8188CU from v1 did not), then I would expect v3 v3.6 v3.8 (v3.x) to also work, they (v2 v3) should all have the RTL8188EUS wifi chipset. I say that because the current downloadable driver package for linux is for RTL8188E.
RT has variants of 8188E (EUS, ETV, etc). Feature diffs, etc. I suspect the drivers provided by TP-link are source code snipped to accomodate 8188EUS.
Side note, the driver package has lines in makefile for compiling against an android sdk, but those lines are commented out.
browse into /system/lib/modules
read the readme.txt file
then
modinfo /system/lib/modules/8188eu.ko
I guess you could drop in any compiled-for-droid driver source there, to support any wifi adapter you wanted to use.
Looks like 8188EU to me.
-
Can you copy'n'paste the Hardware IDs property on the Details tab?
-
SCPI info
1st, the webserver on the 9000 ports is a Java websocket server "TooTallNate Java-WebSocket"
2nd, the Java app requires "websocket upgrade" when making tcp connection to implement encryption.
Hence why telnet will not work, and explains what I was seeing in Wireshark.
The ws client needs to support the encryption part, otherwise the server side rejects the comms.
-
The kernel then
disagrees about version of symbol module_layoutwhen insmodding, so Module.symvers has to be extracted from the kernel partition and used for the build.
I did this and here are the Wifi modules that fall out of an Advantech rk3399 BSP build:
8188fu.ko 8189fs.ko 8723bs.ko 8723bu.ko 8723cs.ko 8822be.ko mlan.koI don't own any of these models, but if someone does and wants to give it a try:
https://sven.killig.de/android/DHO/system/lib/modules/
I went to the page you listed, browser gave me the big red DANGER warning and blocked page.
However, I did grab a ko file to see it it insmod's on my 804
Will report back shortly.
-
I went to the page you listed, browser gave me the big red DANGER warning and blocked page.
Oh my, what did it say? Perhaps a homepage on a server behind DSL is too unusual these days...
-
I went to the page you listed, browser gave me the big red DANGER warning and blocked page.
Oh my, what did it say? Perhaps a homepage on a server behind DSL is too unusual these days...
I have a couple of the sec extensions loaded in FF, so one of them ID's the site as being "dangerous". I suspect by fqdn or by the IP from dns.
Anyways, I insmod the 8188fu.ko into the 804, no complaints.
Note: an initial insert (1st time) the device would not attach, a reboot with 8188eu atached and now it fine, I can remove it and re-insert, no issue at all. No green light though, I see the light controls in linux source code, but perhaps the 8188eu.ko on the DHO left that part out, or the x-compile removes that feature.
dmesg shows it as "idProduct 8179"
@hpmaxim - did you do the lsusb / dmesg procedure I listed earlier?
-
New update for the RT 8188eu v3.6 nano wifi
From my testing, it appears that when you attempt to insert the nano after the DHO is running, the 8188eu.ko KLM fails to load in.
If you boot with the nano in USB port, the system loads the 8188eu.ko KLM.
I fix this issue by doing an insmod in the "/rigol/shell/start_rigol_app.sh" script
I added the following just after the section (near top) where it loads the Motorcomm ETH KLM
insmod /system/lib/modules/8188eu.ko
Now I can insert the nano after boot time and there's no issue of the wifi coming up.
The system should just do a insmod of the ko KLM when it recoginizes that device being inserted into USB port, and then do a rmmod to pull the KLM out when the nano gets pulled from USB port.
That said, most will just leave the wifi nano in the USB port, so it's always there at boot. However, some like me have a USB hub in USB-A port, and the hub has ports that have on/off switches. I don't always have the nano wifi up and running, I turn it on when needed, etc.
Update: another odd thing. You have to insert the nano and manually turn on the wifi slider (android). Leave the slider as is (on position), now the wifi goes on/off in sync with presence of the nano. However, if you manually have the slider to off, the insertion of the nano will not turn on the wifi. That's some odd functionality.
-
I don't own any of these models
...but I own the Edimax EW-7822ULC (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/wireless_adapters_ac1200_dual-band/ew-7822ulc/), so I built its driver (https://www.edimax.com/edimax/mw/cufiles/files/download/Driver_Utility/EW-7822ULC/EW-7822ULC_Linux_Driver_1.0.1.5.zip) for the USB IDs
0b05:184c
0bda:b812
0bda:b82c
13b1:0043
7392:b822
7392:c822
and insmodded
https://sven.killig.de/android/DHO/system/lib/modules/88x2bu.ko (https://sven.killig.de/android/DHO/system/lib/modules/88x2bu.ko)
Its LED is blinking, and 5 GHz seems to work:
(https://sven.killig.de/android/DHO/EW-7822ULC.png)
Build instructions on https://sven.killig.de/android/DHO (https://sven.killig.de/android/DHO)
-
New update for the RT 8188eu v3.6 nano wifi
From my testing, it appears that when you attempt to insert the nano after the DHO is running, the 8188eu.ko KLM fails to load in.
If you boot with the nano in USB port, the system loads the 8188eu.ko KLM.
I fix this issue by doing an insmod in the "/rigol/shell/start_rigol_app.sh" script
I added the following just after the section (near top) where it loads the Motorcomm ETH KLM
insmod /system/lib/modules.8188eu.ko
Now I can insert the nano after boot time and there's no issue of the wifi coming up.
The system should just do a insmod of the ko KLM when it recoginizes that device being inserted into USB port, and then do a rmmod to pull the KLM out when the nano gets pulled from USB port.
That said, most will just leave the wifi nano in the USB port, so it's always there at boot. However, some like me have a USB hub in USB-A port, and the hub has ports that have on/off switches. I don't always have the nano wifi up and running, I turn it on when needed, etc.
Update: another odd thing. You have to insert the nano and manually turn on the wifi slider (android). Leave the slider as is (on position), now the wifi goes on/off in sync with presence of the nano. However, if you manually have the slider to off, the insertion of the nano will not turn on the wifi. That's some odd functionality.
Sorry for taking so long, here's what I got:
rk3399_rigol:/ # dmesg
rk3399_rigol:/ # lsusb
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # lsusb
Bus 003 Device 002: ID 0bda:8179
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # dmesg
[ 271.381320] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[ 271.500329] usb 3-1: New USB device found, idVendor=0bda, idProduct=8179
[ 271.500409] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 271.500424] usb 3-1: Product: 802.11n NIC
[ 271.500437] usb 3-1: Manufacturer: Realtek
[ 271.500461] usb 3-1: SerialNumber: 00E04C0001
[ 271.753363] SELinux: Unable to set superblock options before the security server is initialized
I then tried your insmod command (although you had a typ-o, should be /system/lib/modules/8188eu.ko), it now seems to be mostly working:
I booted several times in a row. First two worked great. Third time it still worked, but seemed a bit slower to start. I also tried unplugging and plugging it back in and this didn't seem to work. Fourth time, I plugged in the hub and keyboard along with the WiFi dongle and it didn't seem to work. Fifth and sixth times I went back to just WiFi, and it worked but was a bit slow to start. Then I unplugged and plugged back in, and that worked. Repeated a few times. All good. Then tried a 7th time with the hub, and it still worked.
So weird that mine is behaving so differently from other people's... Should I edit the file /rigol/shell/start_rigol_app.sh and add the insmod command in there? How do I edit it? vi?
-
Sorry for taking so long, here's what I got:
rk3399_rigol:/ # dmesg
rk3399_rigol:/ # lsusb
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # lsusb
Bus 003 Device 002: ID 0bda:8179
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # dmesg
[ 271.381320] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[ 271.500329] usb 3-1: New USB device found, idVendor=0bda, idProduct=8179
[ 271.500409] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 271.500424] usb 3-1: Product: 802.11n NIC
[ 271.500437] usb 3-1: Manufacturer: Realtek
[ 271.500461] usb 3-1: SerialNumber: 00E04C0001
[ 271.753363] SELinux: Unable to set superblock options before the security server is initialized
I then tried your insmod command (although you had a typ-o, should be /system/lib/modules/8188eu.ko), it now seems to be mostly working:
I booted several times in a row. First two worked great. Third time it still worked, but seemed a bit slower to start. I also tried unplugging and plugging it back in and this didn't seem to work. Fourth time, I plugged in the hub and keyboard along with the WiFi dongle and it didn't seem to work. Fifth and sixth times I went back to just WiFi, and it worked but was a bit slow to start. Then I unplugged and plugged back in, and that worked. Repeated a few times. All good. Then tried a 7th time with the hub, and it still worked.
So weird that mine is behaving so differently from other people's... Should I edit the file /rigol/shell/start_rigol_app.sh and add the insmod command in there? How do I edit it? vi?
That dmesg shows fail to load driver. When the driver load ok you'll see many lines of "RTW", then you should see the rockchip binding MAC address, etc etc.
I fixed my edit goof
After editing start sh file, reboot with the nano in USB
Then using keyboad go into the Android settings --> WiFi , and slide the wifi on/off slider to on. If it won't slide on then the nano driver did not load for some reason.
Configure your wifi settings. No need for this step if just testing that the 8188eu.ko driver loads, but you'll need to add wifi settings at some point to get on a wifi network.
Leave it there.
Power off the scope
Remove the nano
Power up
Go back to Android wifi settings with keyboard (it should show wifi slider as off)
Insert nano, Wifi slider should auto-on itself
Remove nano, Wifi slider should auto-off itself
That is the consistent functionality I get.
-
This is the HOW TO SSH post
So, real easy to setup your SSH access.
I use putty app on windoze, because it's ez to use, saves session profiles, and can gen keys.
Reference info --> https://www.liquidweb.com/kb/putty-ssh-keys/ (https://www.liquidweb.com/kb/putty-ssh-keys/)
step-1 gen and save rsa pub private key pair (1 pair, two keys) using the putttgen tool (command line) (leave the passphrase blank)
step-2 open the pub key in like notepad, edit the file, make just the key part one line, leave open, DO NOT SAVE your edit, doing this edit just for a copy later.
step-3 create a ssh session for your scope IP, save the session so you can load it later. Follow steps --> (see ref info url), always go back to SESSION and click SAVE after each change is made in session settings. Use "root" for username in DATA.
step-4 follow steps in this snippet
//snippet\\
adb connect [IP]:55555
adb root
adb remount
adb shell
vi /system/etc/ssh/authorized_keys (I won't expand how to use vi)
//end snippet\\
paste your one-line pub key from step-2 as a new line in this keys file
save your vi edit, exit vi
At this point you should be able to just load your saved Putty session and click "open" button. It drops you in as root.
Troubleshoot as needed, but you should not have to.
Now exit adb from your adb cmd window
exit
exit
adb disconnect
Shutdown and reboot scope, test your ssh access.
//// optional editing \\\\\
You'll notice some existing keys in the ssh keys file, not sure why those are there, maybe for support reasons.
If you want to make your scope more secure (since sshd is running), you can make a backup copy of the keys file, edit the keys file and remove the existing lines (dd in vi) , then continue on to add your pub key into the file.
You could also just comment out the existing lines in keys files, but having just your pub key there is more secure.
-
Most or maybe all will have connected oscilloscope to local area network and not exposed to internet.
So no way to access it from internet until you set up such thing in your router or modem.
-
So... It seems that the issue of licenses and keys is not dealt with by the application itself, but by one of the binary libraries in it - libscope-auklet.so
Only in this library is the file name RKey.data found, and it also contains a list of all oscilloscope models, and not only the 800/900 series.
I had a brief look at that library and in function CApiLicense::getLicenseKey a call to 'access' is made to verify if that file is present.
If not it falls back and reads "Key.data" instead.
So the fix could be as simple as deleting RKey.data and restoring Key.data from backup. I haven't checked this yet because I haven't upgraded my firmware.
-
[ 271.753363] SELinux: Unable to set superblock options before the security server is initialized
The DHO800 has selinux enabled? That's surprising (I don't actually have a DHO800, so I'm just going by what I read on eevblog).
Try to disable selinux with:
setenforce 0
and see if that allows the WiFi driver to start.
-
[ 271.753363] SELinux: Unable to set superblock options before the security server is initialized
The DHO800 has selinux enabled? That's surprising (I don't actually have a DHO800, so I'm just going by what I read on eevblog).
Try to disable selinux with:
setenforce 0
and see if that allows the WiFi driver to start.
Not that I see, selinux is not in enforcement mode, but appears to be running. More logging which means more delays with cpu cycles. If it's not used then it should not be running.
-
Most or maybe all will have connected oscilloscope to local area network and not exposed to internet.
So no way to access it from internet until you set up such thing in your router or modem.
Devices get exposed to internet all the time, mostly by accident/ignorance.
You can likely find many DHO devices in shodan.
-
So... It seems that the issue of licenses and keys is not dealt with by the application itself, but by one of the binary libraries in it - libscope-auklet.so
Only in this library is the file name RKey.data found, and it also contains a list of all oscilloscope models, and not only the 800/900 series.
I had a brief look at that library and in function CApiLicense::getLicenseKey a call to 'access' is made to verify if that file is present.
If not it falls back and reads "Key.data" instead.
So the fix could be as simple as deleting RKey.data and restoring Key.data from backup. I haven't checked this yet because I haven't upgraded my firmware.
Yes, I also spent the evening tinkering with the disassembler, but I couldn’t find where the new keys were being read from. Everything is not as obvious there as I hoped :)
-
So the fix could be as simple as deleting RKey.data and restoring Key.data from backup. I haven't checked this yet because I haven't upgraded my firmware.
You can downgrade your firmware and restore the original Key.data, no problem.
-
So the fix could be as simple as deleting RKey.data and restoring Key.data from backup. I haven't checked this yet because I haven't upgraded my firmware.
Oh, didn't pay attention to that.
No, that won't work. In this case, it reads Key.data, decrypts the data from it with the old key, then encrypts this data with the new key and stores it in RKey.data, and deletes Key.data.
Actually, this is exactly what he does immediately after the update, and this is how the RKey.data file appears instead of Key.data.
-
:popcorn: Waiting for next episodes...
-
Yes, this new firmware recreates RKey.data on boot and deletes the old one.
-
I just got Bluetooth to work for the Edimax EW-7611ULB (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/bluetooth/ew-7611ulb) (not V2) :D Just extract
https://sven.killig.de/android/DHO/ew7611ulb.tgz (https://sven.killig.de/android/DHO/ew7611ulb.tgz)
to the root of the filesystem and start
rk3399_rigol:/ # ew7611ulb.sh
Both the Bluetooth and Wi-Fi pages (since it's a combo dongle) in the Settings app should work then:
(https://sven.killig.de/android/DHO/ew7611ulb.png)
To undo, replace *.so with a backup or the initially shipped ones (https://sven.killig.de/android/DHO/bluetooth-orig.tgz).
Build instructions on https://sven.killig.de/android/DHO (https://sven.killig.de/android/DHO)
-
I just got Bluetooth to work for the Edimax EW-7611ULB (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/bluetooth/ew-7611ulb) (not V2) :D Just extract
https://sven.killig.de/android/DHO/ew7611ulb.tgz (https://sven.killig.de/android/DHO/ew7611ulb.tgz)
to the root of the filesystem and start
rk3399_rigol:/ # /data/local/tmp/ew7611ulb.sh
Both the Bluetooth and Wi-Fi pages (since it's a combo dongle) in the Settings app should work then.
This info comes at an interesting time, seeing Amazon just delivered my TL-WN725N (WIFI-only dongle) today. However, the Edimax EW-7611ULB is not sold here in Japan (not yet on Amazon Japan), so I guess it doesn't really matter for me. But I do see the merits, as Bluetooth would allow you to connect a wireless keyboard and mouse. But arguably, if you have WiFi and get your scope on your computer, then the computer has the keyboard and mouse, making the need for them on the actual scope less important.
With that said, it would be helpful to iOS users who haven't the faintest idea how Android works to know a precise step-by-step method to "extract XXX to the root of the filesystem" and then "start." I personally don't know what that entails, hence the desire to see steps.
Thanks.
-
Shipping to Japan seems to be available at eBay.com (https://www.ebay.com/sch/i.html?_from=R40&_nkw=EW-7611ULB&_sacat=0&_sop=15).
Steps:
adb connect [IP]:55555
adb root
adb remount
adb push ew7611ulb.tgz /data/local/tmp
adb shell
rk3399_rigol:/ # tar xfz /data/local/tmp/ew7611ulb.tgz
rk3399_rigol:/ # ew7611ulb.sh
rk3399_rigol:/ # am start -a android.settings.SETTINGS
-
Shipping to Japan seems to be available at eBay.com (https://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=ew-7611+ulb&_fcid=104&_sop=15).
Yes, but the total is about US$30, and when you consider the horrid exchange rate we have right now, that makes an otherwise ¥1000 product become something like ¥4400, which is totally and utterly insane. I paid ¥800 for my TL-WN725N and free shipping as a Prime member here in Japan. That dongle, even without Bluetooth, is therefore the logical choice for the frugal.
But thank you for the steps, as those steps will help others who can actually afford the dongle you are using.
-
It might also work for other RTL8723BU dongles with USB Vendor IDs
0489
0bda
1358
13d3
but after much trial & error with other chips in the Edimax EW-7611UB5/BT-8500 and the Plugable USB-BT4LE, I'm unsure...
-
Just wanedt to thank everyone, especially Randy222 for all the detailed help. I'm about to go on a vacation, so I'll be away from the scope for a few weeks. As it stands now, I did load the module into the kernel and it seems to work pretty reliably if the Nano is plugged directly in to the scope when booted. Otherwise, it can be flaky.
-
Hello!
I was "lucky" enough to upgrade my new HDO804 to v00.01.02.00.02 without backup and only then trying to unlock the options. ;(
Now I have only RKey.data file, even when I downgrade firmware it doesn't create old file.
Is there a way to copy it from some other scope? Or I have now only old upgrade way with rewriting flash card?
I suppose, in next 2-3 months all new scopes will be with this v00.01.02.00.02 firmware where current unlock script is not working.
-
Yes, this new firmware recreates RKey.data on boot and deletes the old one.
Exploring the functions of interest that handle the RKey.data file I came up with the following:
- I've disassembled the entire libscope-auklet.so with IDA Pro
- Then wrote a Perl script to extract only some of the functions and also change the assembly format so it will be accepted by GAS
- All calls to libc functions have been replaced with the "native" ARM64 libc
- I've then added some C wrappers to be able to compile a static ELF aarch64 file
This worked fine and at least enabled me to understand the RString structure which is used everywhere in the license API for strings.
It also makes a much smaller executable which is handled faster by IDA. The IDA ARM64 decompiler only works in v7.7 not the latest v8.3 but it's not very helpful.
My plan was to run this test program on my Linux machine with the qemu-aarch64 emulator, read the old Key.data file and observe it how it creates the new RKey.data
Unfortunately all the libscope functions are written in C++, "new" and "delete" operators are everywhere and are a pain to interface with plain C.
I've got tangled in the tens of extra functions needed to properly run this on the emulator so I've dropped it for now.
(If someone want ot have a look I've included the sources here: https://github.com/zelea2/rigol_vendor_bin/tree/main/rkey_test (https://github.com/zelea2/rigol_vendor_bin/tree/main/rkey_test) )
A better approach would be to patch the functions of interest with hooks which will run C functions from a separate .so library. This new library can be written
and compiled comfortably on a Linux machine. Then the original libscope-auklet.so has to be manipulated with objcopy/objdump to add the hooks extra symbols.
Finally the patched and new library can be reinserted in the Sparrow.apk (with zip update) and then replaced on the scope. The entire process can be automated with a script.
This will allow the modified application to run directly on the scope and make it save trace files and data dumps while it is handling its licenses.
My observation is that generating the option license strings have stayed the same but now the AES key for decrypting them is hidden inside the RKey.data
-
Yes, this new firmware recreates RKey.data on boot and deletes the old one.
Exploring the functions of interest that handle the RKey.data file I came up with the following:
- I've disassembled the entire libscope-auklet.so with IDA Pro
- Then wrote a Perl script to extract only some of the functions and also change the assembly format so it will be accepted by GAS
- All calls to libc functions have been replaced with the "native" ARM64 libc
- I've then added some C wrappers to be able to compile a static ELF aarch64 file
This worked fine and at least enabled me to understand the RString structure which is used everywhere in the license API for strings.
It also makes a much smaller executable which is handled faster by IDA. The IDA ARM64 decompiler only works in v7.7 not the latest v8.3 but it's not very helpful.
My plan was to run this test program on my Linux machine with the qemu-aarch64 emulator, read the old Key.data file and observe it how it creates the new RKey.data
Unfortunately all the libscope functions are written in C++, "new" and "delete" operators are everywhere and are a pain to interface with plain C.
I've got tangled in the tens of extra functions needed to properly run this on the emulator so I've dropped it for now.
(If someone want ot have a look I've included the sources here: https://github.com/zelea2/rigol_vendor_bin/tree/main/rkey_test (https://github.com/zelea2/rigol_vendor_bin/tree/main/rkey_test) )
A better approach would be to patch the functions of interest with hooks which will run C functions from a separate .so library. This new library can be written
and compiled comfortably on a Linux machine. Then the original libscope-auklet.so has to be manipulated with objcopy/objdump to add the hooks extra symbols.
Finally the patched and new library can be reinserted in the Sparrow.apk (with zip update) and then replaced on the scope. The entire process can be automated with a script.
This will allow the modified application to run directly on the scope and make it save trace files and data dumps while it is handling its licenses.
My observation is that generating the option license strings have stayed the same but now the AES key for decrypting them is hidden inside the RKey.data
There must be a key to decrypt RKey.data somewhere there...
-
There must be a key to decrypt RKey.data somewhere there...
There is no AES operation in CApiLicense::getLicenseKey (which reads RKey.data) just bytes scrambling.
AES_decrypt is only called in CApiLicense::verifyOption
Unfortunately qemu-aarch64 cannot run dynamically linked programs, only static - otherwise I would have used libscope-auklet.so as is.
Maybe an even better option is to make a minimal ARM64 disk image (constructed from the scope's filesystem) and then run my test program
inside the emulated system with qemu-system-aarch64
-
I was "lucky" enough to upgrade my new HDO804 to v00.01.02.00.02 without backup and only then trying to unlock the options. ;(
Now I have only RKey.data file, even when I downgrade firmware it doesn't create old file.
Is there a way to copy it from some other scope? Or I have now only old upgrade way with rewriting flash card?
I think it'll work if you just change the name to Key.data.
In theory it's derived from your serial number in vendor.bin but 'the firmware doesn't seem to check if they match.
-
There must be a key to decrypt RKey.data somewhere there...
Yep. That's the important thing and it should be much easier to find than figuring out how RKey.data is generated.
-
Yep. That's the important thing and it should be much easier to find than figuring out how RKey.data is generated.
Knowing out to decrypt it is, at most, as easy as knowing how to create it. In a worst case scenario (asym crypto), much harder or practically unfeasible.
-
Knowing out to decrypt it is, at most, as easy as knowing how to create it. In a worst case scenario (asym crypto), much harder or practically unfeasible.
You don't just have to know how to encrypt it, you have to know what to put in it.
-
So in a nutshell, what is the current state?
- do the previously made hacks (applied onto an older firmware) stop working when firmware is upgraded?
- it seems that it's currently not possible to hack a scope with the latest FW, correct?
-
There is no AES operation in CApiLicense::getLicenseKey (which reads RKey.data) just bytes scrambling.
AES_decrypt is only called in CApiLicense::verifyOption
I'm not talking about the AES key, but specifically about the key that decodes RKey.data :)
So in a nutshell, what is the current state?
- do the previously made hacks (applied onto an older firmware) stop working when firmware is upgraded?
- it seems that it's currently not possible to hack a scope with the latest FW, correct?
Yes, the previously received options stop working and it is not yet possible to generate new ones for the latest firmware. But it is still possible to upgrade the oscilloscope model number.
-
Yes, the previously received options stop working and it is not yet possible to generate new ones for the latest firmware.
What kind of options?
But it is still possible to upgrade the oscilloscope model number.
Interesting. Is it different from the options that you mentioned above? Actually let's put it this way: the (only) things that I am after are unlocking a DHO804 into 100MHz, or whatever is achievable, bandwidth, and (I saw somewhere that it was possible earlier) into 50M/25M/10M memory depth. Is this still possible?
My scope is still in transit, so I'm now kind of gathering info and preparing for what can be expected. I ordered it around the time new FW was released, so it will very likely have an older FW, but it may as well come with the latest one, who knows.
-
v00.01.02.00.00 still works like the older 01.01's
Do the hacks as we know them break with anything newer than v00.01.02.00.00 ?
-
You don't just have to know how to encrypt it, you have to know what to put in it.
The same for decrypt (start, end, algo, key, IV, mode, etc). Please, don't continue this road.
-
What kind of options?
I meant options (keys) to unlock additional features. For older firmware they could be generated and received by the oscilloscope. In the latest firmware, previously generated options are no longer accepted, since their generation requires another, new key, which is still unknown.
Interesting. Is it different from the options that you mentioned above? Actually let's put it this way: the (only) things that I am after are unlocking a DHO804 into 100MHz, or whatever is achievable, bandwidth, and (I saw somewhere that it was possible earlier) into 50M/25M/10M memory depth. Is this still possible?
My scope is still in transit, so I'm now kind of gathering info and preparing for what can be expected. I ordered it around the time new FW was released, so it will very likely have an older FW, but it may as well come with the latest one, who knows.
No, no additional features can be unlocked in the latest firmware. You will not be able to generate an option to increase bandwidth or increase memory depth. But it remains possible to force the oscilloscope to consider itself not a DXO804 with a 70 MHz bandwidth, but, for example, a DXO914 with a 125 MHz bandwidth and full memory depth, or a DXO924 with a 250 MHz bandwidth. To do this, simply use a special utility to change the oscilloscope model in the vendor.bin file.
-
But since nobody knows what Rigol will come up with in the future, it is better to make a 1:1 backup of the SD card first. Then run your scope with the new SD card so you always have the untouched original.
-
But it remains possible to force the oscilloscope to consider itself not a DXO804 with a 70 MHz bandwidth, but, for example, a DXO914 with a 125 MHz bandwidth and full memory depth, or a DXO924 with a 250 MHz bandwidth. To do this, simply use a special utility to change the oscilloscope model in the vendor.bin file.
Who cares how the scope identifies itself? :)
What really matters is not what it considers itself to be, but whether the increased bandwidth and memory depth will actually work, when it thinks that it's a more advanced model. Will they, with the updated vendor.bin?
But since nobody knows what Rigol will come up with in the future, it is better to make a 1:1 backup of the SD card first. Then run your scope with the new SD card so you always have the untouched original.
Yeah it goes without saying, this is precisely what I'm planning to do.
-
Who cares how the scope identifies itself? :)
What really matters is not what it considers itself to be, but whether the increased bandwidth and memory depth will actually work, when it thinks that it's a more advanced model. Will they, with the updated vendor.bin?
Yes, these will work. And as a little added benefit, you also get triggers and decoding for the CAN and LIN protocols.
There is one cosmetic "side effect": A control box for the digital channels will be displayed in the bottom line of the screen, but these will of course be non-working. Some users also experienced a functional side effect earlier -- namely small voltage offsets in some channels which the self-calibration could not remove -- but I believe this has been resolved with the more recent firmware versions.
-
But since nobody knows what Rigol will come up with in the future, it is better to make a 1:1 backup of the SD card first. Then run your scope with the new SD card so you always have the untouched original.
No need. A firmware update is just a UNix .tar of the the contents of the /rigol folder with /rigol/data excluded.
There's even a shell command "/rigol/build_gel.sh" to make your own .gel file from your current setup.
(which I'm guessing is the reason why there's so many "unofficial" firmwares out there - they made it too damn easy for any random employee to create one from whatever internal version they happen to have - "Here, try this and see if it helps...")
Firmware downgrades work just fine. There's a matching "/rigol/do_update.sh" if you want to see the process, it's just "kill all the running tasks then tar -xvf and reboot"
Having said that: The trick is not to rush to install it on day 1. Let others find out for you... :)
-
So, I would like to get a summary, correct me if I am wrong here.
The newer FW's perhaps 01.02.00.01 and beyond (please verify the version that changes things) uses different key data methods for license keys. So, this means license keys generated prior to this FW version won't work?
That leads me to these questions:
1) If you upgrade to the latest FW, you'll need to somehow get new license/options keys from Rigol? (for those who bought options)? This process works how? Do you just email them, is there some user portal you goto?
2) Can you still generate options-lics using the poted rigol tool using the new "key data" file from the new FW's ?
-
So, I would like to get a summary, correct me if I am wrong here.
The newer FW's perhaps 01.02.00.01 and beyond (please verify the version that changes things) uses different key data methods for license keys. So, this means license keys generated prior to this FW version won't work?
That's right.
That leads me to these questions:
1) If you upgrade to the latest FW, you'll need to somehow get new license/options keys from Rigol? (for those who bought options)? This process works how? Do you just email them, is there some user portal you goto?
2) Can you still generate options-lics using the poted rigol tool using the new "key data" file from the new FW's ?
1) Only owners of licensed options can answer this :)
2) No, options that work for the latest firmware cannot yet be generated using this new RKey.data file.
-
1) If you upgrade to the latest FW, you'll need to somehow get new license/options keys from Rigol? (for those who bought options)? This process works how? Do you just email them, is there some user portal you goto?
I don't think Rigol has sold options for these yet.
Maybe they're about to start selling them, hence this change...
(They'll have to be cheap though, otherwise people will simply buy a DHO900... :-// )
-
Who would buy options if the latest FW is still very buggy?
1st step for Rigol is, fix the issues and release a stable FW.
-
Who would buy options if the latest FW is still very buggy?
1st step for Rigol is, fix the issues and release a stable FW.
What's "unstable" about it? I've never seen the slightest instability.
Edit: And bugs are very few and no showstoppers, just a handful of annoyances with simple workarounds.
(ie. Nothing like "decoding doesn't work" or anything like that, more like "it doesn't remember a certain setting if I power it off and on again" level of bug)
-
1st step for Rigol is, fix the issues and release a stable FW.
Even after the first firmware update, my rigol no longer crashed - at least that's what I mean by "stable" firmware.
-
1st step for Rigol is, fix the issues and release a stable FW.
Even after the first firmware update, my rigol no longer crashed - at least that's what I mean by "stable" firmware.
I meant stable, as in when you advance a FW version it reduces bugs and/or does not bring back old bugs and/or does not introduce new bugs.
I don't see any new feature in 01.02.xx.xx FW's, only a changelog file that says "fix this" "fix that".
Perhaps I missed it, has there been any Rigol fix for the FFT issue?
All he features/specs per model number, should be working 100% bug free. The bug list should become reduced with each new FW released.
800 is a bit less complicated than the 900 series, but same principles still apply.
-
No scope model in this world is or will ever be 100% bug-free.
What's more, it's a very inexpensive scope - you can't expect the development department to sit down and fix every annoying bug, the budget isn't there for that.
With bugs, a distinction must be made between functionally relevant and just "annoying" bugs.
Rigol and other manufacturers will generally ensure that their cheap products are stable, anything else is more of a bonus.
I wouldn't want to get my hopes up with the FFT.
The bug with the faulty window coefficients has been around forever and the lack of features such as average and peak hold will probably not be rectified either, as even the largest scope, the Stationmax , only has rudimentary FFT features.
As of now the scope is stable and has some nice new features, if you want something else you have to buy a scope somewhere else.
-
I think it turned out quite neatly. :popcorn:(LA port)
-
Looks nice and tidy! :-+
So, does the LA fully work without the extra RAM installed on the main board, or did you add that too? (Has it ever been clarified what that extra RAM is for -- LA, AWG or something else?)
-
Just populating those missing RAM chips will not be enough.
Android OS must be aware of this and is not like a config file where you declare available RAM.
I think is on bootloader stage or preloader maybe.
So we need to find a way to extract all from sdcard not what is found until now and compare between models with more or less RAM
One quick test method will be to put an sdcard image on card from model with more RAM in one with less it may work but who know if OK or not work at all.
-
How do you know that thus RAM is under Android OS control? Is that known?
-
Yes, obviously LA works without installing additional memory... Unfortunately, I can’t check its operation yet, due to the lack of an LA adapter, as soon as I get one, I’ll definitely check everything. At the moment I am emulating the connection of an LA adapter by connecting the two rightmost pins of the LA connector (pin detect + pin gnd). In any case, I will install additional memory, I assume that next week the two SKhynix H5TQ2G63FFR memory chips I ordered will arrive to me, they will be immediately installed on the board. I will show the entire installation process with all the checks and measurements of all voltages and signals on the installed chips in a video on my YouTube channel https://youtube.com/@stepan.koshman
-
I'm sure this is not true!... This memory is not used in android os!... it is needed for FPGA.
-
Will be usefull if someone with model with more RAM will post some hardware info gathered by some hardware info software.
Then we can compare with less RAM models hardware info.
Indeed, looks like this is used by Xilinx chip.
-
I will do this in my video, it will show the state of the RAM before installing DDR3 chips, and after...
-
The fact is that the RAM chip in question is connected to the FPGA, and not to the Android processor. And for this reason, the configuration about the presence and addressing of memory is stored in the configuration flash. Android OS has nothing to do with it. I managed to find an analogue RAM DDR. And I can install it on the station, but I need a flash dump that is connected to the FPGA from the older version DHO900 series. I bought DHO804.
-
Need a flash chip dump from the series DHO900. And it seems to me that RAM is best suited in terms of parameters and characteristics MT41K256M16LY-093. Or I could be wrong.
-
I think there is no need for a dump, and it is enough to do a DDR calibration...
-
Maybe. You need to check all options.
-
more useful information. Currently, without additional RAM installed, when LA is activated, the maximum available memory depth for analog channels is halved.
-
In any case, I will install additional memory, I assume that next week the two SKhynix H5TQ2G63FFR memory chips I ordered will arrive to me, they will be immediately installed on the board. I will show the entire installation process with all the checks and measurements of all voltages and signals on the installed chips in a video on my YouTube channel https://youtube.com/@stepan.koshman
be prepared with good reflow tool as i tried reflowing only MPM3630 smps ic with heat gun is not making a dent on solder blobs on pcb. i assume it has massive thermal mass underneath there... btw: my prototype pcb arrived and i just cut them last night. i need to perfect my reflow process using oven since vssop is not really easy to do by hand. and i'm quite busy with other things atm, so weekend is my hope for the next few weeks. ymmv.
-
Thank you! Taking this opportunity, I would like to ask if there is any success in your generator board project?
-
Thank you! Taking this opportunity, I would like to ask if there is any success in your generator board project?
as you can see in the picture above, i've not populate them, they just arrived. rev1 last time i got crosstalk issue in low level signal, so hopefully it will not occur in this rev2 (i dont know where the crosstalk came from, probably counterfeit ICs? or EMI from adjacent DHO800 motherboard? i dont know but the later is unlikely imho)
-
:-+
-
I updated my DHO812 to version 00.01.02.00.02 - a decoder and a CAN trigger appeared, but in the additional AUTO options the trigger is marked as limited
-
I'm having trouble getting RigolTool working. :-\
At first Norton 360 flagged it as a virus, but I submitted the file for review at Norton and it will now unzip.
But If I start the app, the initial screen appears, then shuts down after 2 seconds.
I tried running as admin, also turning off Norton.
I am using Windows 10.
Not interested in hacking my scope...yet,
but I'd like to download waveform files over wifi.
I'm using adb commands, but its a pain.
-
In any case, I will install additional memory, I assume that next week the two SKhynix H5TQ2G63FFR memory chips I ordered will arrive to me, they will be immediately installed on the board. I will show the entire installation process with all the checks and measurements of all voltages and signals on the installed chips in a video on my YouTube channel https://youtube.com/@stepan.koshman
be prepared with good reflow tool as i tried reflowing only MPM3630 smps ic with heat gun is not making a dent on solder blobs on pcb. i assume it has massive thermal mass underneath there... btw: my prototype pcb arrived and i just cut them last night. i need to perfect my reflow process using oven since vssop is not really easy to do by hand. and i'm quite busy with other things atm, so weekend is my hope for the next few weeks. ymmv.
Sounds like you need to convert a small toaster oven into a reflow.
-
No scope model in this world is or will ever be 100% bug-free.
What's more, it's a very inexpensive scope - you can't expect the development department to sit down and fix every annoying bug, the budget isn't there for that.
With bugs, a distinction must be made between functionally relevant and just "annoying" bugs.
Rigol and other manufacturers will generally ensure that their cheap products are stable, anything else is more of a bonus.
I wouldn't want to get my hopes up with the FFT.
The bug with the faulty window coefficients has been around forever and the lack of features such as average and peak hold will probably not be rectified either, as even the largest scope, the Stationmax , only has rudimentary FFT features.
As of now the scope is stable and has some nice new features, if you want something else you have to buy a scope somewhere else.
Huh?
The unit is sold with a spec sheet. Buyers are expecting that the spec sheet (the things they are paying for) works without bugs.
I was not expecting my 804 turned into a 914 to behave 100%, but I do expect the 804 iteself to behave 100%.
-
Then go and study the specs...
Is there anything in there that is currently not available or not working?
-
I was not expecting my 804 turned into a 914 to behave 100%, but I do expect the 804 iteself to behave 100%.
...or, failing to deliver this on the initial release, the manufacturer must at least provide a publicly available issue tracker where customers could report bugs and expect reasonable reaction from the developers: acknowledgment, setting resolution milestones to future firmware versions etc.
Just like it is with any good software project whose maintainers aren't assholes.
-
Sounds like you need to convert a small toaster oven into a reflow.
I would prefer to use bottom heating to 150-180 degrees and burn from above with a hairdryer as usual, instead of heating the entire board to 300 degrees in the oven.
-
and burn from above with a hairdryer as usual
that's one hell of a hairdryer you've got there...
-
that's one hell of a hairdryer you've got there...
:)))) Of course, I meant a soldering hot air gun :)) Dumb Google translation :))
-
I don't own any of these models
...but I own the Edimax EW-7822ULC (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/wireless_adapters_ac1200_dual-band/ew-7822ulc/), so I built its driver (https://www.edimax.com/edimax/mw/cufiles/files/download/Driver_Utility/EW-7822ULC/EW-7822ULC_Linux_Driver_1.0.1.5.zip) for the USB IDs
0bda:b812
0bda:b82c
13b1:0043
7392:b822
7392:c822
and insmodded
https://sven.killig.de/android/DHO/system/lib/modules/88x2bu.ko (https://sven.killig.de/android/DHO/system/lib/modules/88x2bu.ko)
Its LED is blinking, and 5 GHz seems to work:
(https://sven.killig.de/android/DHO/EW-7822ULC.png)
Can you Add ASUS USB AC53 device?Thank you
https://github.com/maccuaa/asus-ac53-rtl8822bu/commit/af6b0a19c79e6977c1cb5b7a8c4faf00a5286422 (https://github.com/maccuaa/asus-ac53-rtl8822bu/commit/af6b0a19c79e6977c1cb5b7a8c4faf00a5286422)
-
...but I own the Edimax EW-7822ULC (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/wireless_adapters_ac1200_dual-band/ew-7822ulc/), so I built its driver (https://www.edimax.com/edimax/mw/cufiles/files/download/Driver_Utility/EW-7822ULC/EW-7822ULC_Linux_Driver_1.0.1.5.zip) for the USB IDs
Can you please elaborate on how you built the driver for the target platform? What toolchain you used, etc.
-
Sounds like you need to convert a small toaster oven into a reflow.
no worry, that is taken cared of... last night i tested my 138°C and 158°C solder paste and they reflowed as expected, my cheap oven got temp control from 100-200°C and a timer, so i think that will do without extra modification. btw: hairdryer is only suitable to dry the wife's hair, not to burn her to death to 150°C... ;D ymmv.
-
Yes, obviously LA works without installing additional memory... Unfortunately, I can’t check its operation yet, due to the lack of an LA adapter, as soon as I get one, I’ll definitely check everything. At the moment I am emulating the connection of an LA adapter by connecting the two rightmost pins of the LA connector (pin detect + pin gnd). In any case, I will install additional memory, I assume that next week the two SKhynix H5TQ2G63FFR memory chips I ordered will arrive to me, they will be immediately installed on the board. I will show the entire installation process with all the checks and measurements of all voltages and signals on the installed chips in a video on my YouTube channel https://youtube.com/@stepan.koshman
When you have the LA adapter, can you test the LA functionality without the RAM chips first, to verify it works and then populate the chips and see what's different?
-
I certainly understand that this would be the most correct thing.... But unfortunately I do not have this adapter. All I can do is indirectly confirm or refute the operation of the installed memory chips by looking at the presence of activity on the data exchange lines with another oscilloscope....And I will do this, as I wrote above.
-
Can you Add ASUS USB AC53 device?Thank you
There you go:
https://sven.killig.de/android/DHO/system/lib/modules/88x2bu.ko
-
Can you please elaborate on how you built the driver for the target platform? What toolchain you used, etc.
I put down some notes at
https://sven.killig.de/android/DHO
Also some AOSP apks
-
I certainly understand that this would be the most correct thing.... But unfortunately I do not have this adapter. All I can do is indirectly confirm or refute the operation of the installed memory chips by looking at the presence of activity on the data exchange lines with another oscilloscope....And I will do this, as I wrote above.
Have you tried looking at oscilloscopes for DDR activity at the pins of empty spaces when initializing DDR calibration or when turning it on DHO?
-
that would definitely make sense. Maybe I'll try it (but it's unlikely). And I won’t poke at the empty points because there are pull-up resistors there, that’s where I’ll check the activity.
-
I certainly understand that this would be the most correct thing.... But unfortunately I do not have this adapter.
If you already made external connector for LA - you can just carefully use logic pins for testing.
I own DHO924 and with LA -detect pins connected I see some random noise pickup on several channels, it's reacting to the fingers, touching the pin.
Even with 1 pin connected from diff input it's show's some signals.
It's also splitting resources to serve LA
CH1 1.250GSa/s 50M
LA 625MSa/s 25M
LA+CH1 - 625MSa/s 25M
LA+CH1,CH2 312MSa/s 10M
LA+4xCH 156MSa/s 1M
Probable additional memory need for trigger function with LA, but I cannot check it.
Don't think it's related to bus decode or bus trigger - at-least it's no any difference with selecting analog channel or LA as trigger or decode source
-
Hello!
Want to ask peoples with Android skills - is it possible to hack screen resolution and DPI settings?
For example set the screen size 1100x640 and center image, so useless gray frame will become out of screen?
or set DPI screen information as for 10'' display on DHO1000 - it's very probable the screen layout is the same, but different DPI cause to select different fonts and window frames in order to get more readable interface, like 1-string results layout and less space for window captions.
It's very annoying, but obviously RIGOL will not try to optimize it.
-
or set DPI screen information as for 10'' display on DHO1000 - it's very probable the screen layout is the same, but different DPI cause to select different fonts and window frames in order to get more readable interface, like 1-string results layout and less space for window captions.
rk3399_rigol:/ # wm density
Physical density: 228
Override density: 114
doesn't seem to have any effect on the scope app.
-
rk3399_rigol:/ # wm density
Physical density: 228
Override density: 114
doesn't seem to have any effect on the scope app.
after some playing with screen size and DPI -
setting density higher than 228 - results font become bigger, but not all strings where changed
setting screen size 1280x750 - scope app adopts online, but after reboot it's revert previous size, with virtual resolution 1280x750
in any case results still 2 strings per value :-\, no any improvement in screen allocation
I can set black unused frame with wm overscan, but no way to crop image and hide outer frame. |O
-
hi,
I am a bit alien to the discussion, forgive it to me.
So I am newbie, looking to get my first scope. After considering/stretching budget few times, I settled down to 804 model. Possibility to hack it sounds like a good bonus.
- Is 804 an optimal choice here? (4 channels + unlockable frequency?)
- Does software hacking void warranty permanently, or is it possible to restore it if something breaks down the way and ship it for repairs?
- I must have missed this one - is it difficult soldering task to retrofit LA into 800?
-
I certainly understand that this would be the most correct thing.... But unfortunately I do not have this adapter.
If you already made external connector for LA - you can just carefully use logic pins for testing.
I own DHO924 and with LA -detect pins connected I see some random noise pickup on several channels, it's reacting to the fingers, touching the pin.
Even with 1 pin connected from diff input it's show's some signals.
It's also splitting resources to serve LA
CH1 1.250GSa/s 50M
LA 625MSa/s 25M
LA+CH1 - 625MSa/s 25M
LA+CH1,CH2 312MSa/s 10M
LA+4xCH 156MSa/s 1M
Probable additional memory need for trigger function with LA, but I cannot check it.
Don't think it's related to bus decode or bus trigger - at-least it's no any difference with selecting analog channel or LA as trigger or decode source
Oooh this is very useful, please clarify is your model 924 with additional memory chips installed? Or have you hacked vendor.bin? Regarding the noise on LA channels, I also have it on some channels....
-
Is 804 an optimal choice here? (4 channels + unlockable frequency?)
Yes. You can have everything from just the base model.
Does software hacking void warranty permanently, or is it possible to restore it if something breaks down the way and ship it for repairs?
It's easy to reverse and leave no trace.
I must have missed this one - is it difficult soldering task to retrofit LA into 800?
Probably more difficult to cut the hole in the case. Read the threads carefully before trying it though and you might not need it. Protocol decoding works fine with just the analog channels.
-
I must have missed this one - is it difficult soldering task to retrofit LA into 800?
I have seen three users here who have soldered the probe connector onto the board, but none of them has also populated the extra RAM chip which the DHO900 has. (And which is much more difficult to obtain and to solder, since it comes in a BGA package.)
Unfortunately none of those three has a logic probe yet, so they have not tested the logic analyser in earnest. It is still unknown what the extra RAM is actually doing, and whether the logic analyser can be used (with limitations?) without it.
-
Does software hacking void warranty permanently, or is it possible to restore it if something breaks down the way and ship it for repairs?
It's easy to reverse and leave no trace.
As long as the scope is still functional enough to let you reconnect and remove the hack, of course.
But since you are based in Europe, I think it would be an uphill battle for Rigol to claim that the hack has voided your warranty. Depending on the specific national implementation of the rules and the time of failure, they might have to prove that the hack has actually caused the problem. (At least as far as the obligatory consumer warranty is concerned -- anything beyond that is at Rigol's discretion.)
-
I got the online upgrade thing today:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1989985;image)
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1989991;image)
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1989997;image)
-
And are you going to take the plunge? Looks like your scope is still an 814, so you would need to switch to the vendor.bin upgrade instead?
-
I said "yes" and I got firmware 01.02.00.00.
It says I still have my 100MHz upgrade (haven't tested it) but the 50M memory has vanished.
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2008778;image)
-
So that's annoying...
I have to either go to DHO914 and put up with extra junk on screen and higher bandwidth than ideal, or stick with 1.01 and have a pesky red dot on the menu.
I wonder what URL I have to block to get rid of the red dot.
-
So that's annoying...
I have to either go to DHO914 and put up with extra junk on screen and higher bandwidth than ideal, or stick with 1.01 and have a pesky red dot on the menu.
But the 914 is 100 MHz bandwidth, isn't it?
(correction: actually 125 -- but still ok with 1.25 Gsa/s?)
Extra junk on the screen yes, but it doesn't cover an otherwise used area, it will just appear where black background currently is, so while annoying, it's probably not so big deal.
-
But the 914 is 100 MHz bandwidth, isn't it?
It says "125Mhz" on the sticker but it's 225MHz measured.
The "100MHz" DHO814 is 200Mhz measured, slightly better for the limited sampling rates when multiple channels are on.
I'm sure it won't make much difference in practice, but it's annoying.
-
I said "yes" and I got firmware 01.02.00.00.
It says I still have my 100MHz upgrade (haven't tested it) but the 50M memory has vanished.
Version 01.02.00.00 does not override the generated options, this happens since version 01.02.00.02. The 50M memory, as I remember, stops being displayed in the information, but in reality remains accessible.
-
Version 01.02.00.00 does not override the generated options, this happens since version 01.02.00.02.
You mean version 00.01.02.00.00 vs. 00.01.02.00.02? ;)
Why, oh why, does Rigol need five double-digits to count versions? I don't think I have ever seen anything beyond "00" for the top-level number; and there is no rhyme or reason to how they use the other four. At least it seems that the DHO series displays the version numbers in the same way in its system info dialog as they are shown on the various websites. The DS1000Z shows "SP something" instead of the last (?) two digits, adding to the numbering confusion...
-
You mean version 00.01.02.00.00 vs. 00.01.02.00.02? ;)
Yes exactly. It’s easy to get confused in this mass of zeros, and I share your confusion about Rigol’s version numbering.
-
Version 01.02.00.00 does not override the generated options, this happens since version 01.02.00.02.
Ah, OK... my RLU.lic file was messed up. I think I was trying to generate a key for version 01.02.00.02 using RKey.data
I copied a good RLU.lic to the 'scope and it's all working now. :-+
Now let me warm it up and do a self-cal.
-
Oooh this is very useful, please clarify is your model 924 with additional memory chips installed? Or have you hacked vendor.bin? Regarding the noise on LA channels, I also have it on some channels....
It's true DHO924 without any mod. I didn't opened it, so cannot confirm memory installed.
My DHO produce 150MHz noise on channel D0 and sometimes on D13. noise disappearing if cable connected to input (both + and-) even without any load - it's just not terminated digital input
-
Just posted LA behavior in bug thread
https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5296438/#msg5296438 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5296438/#msg5296438)
Based on it - LA need 48MB of memory to store 25Mpts (16 bit per point) and transfer rate more than 1.25GB/s what is the size and speed of memory,
not soldered in DHO800 ? is it capable to handle this data?
And the same calculation for main acquisition memory
96MB and more than 2.5GB/s
single chip can handle lower transfer rate, but memory controller can access it in parallel with 2 or 4 channels.
In theory, any DDR2 should deliver this speed, but oscilloscope require very stable access rate, so probable twice the maximum transfer rate required.
-
For the software hackers in the thread. I installed a very simple Android/Kotlin program on the scope to capture the "key" events when twiddling all the knobs and dials. Attached is an image of the key codes each generates.
Useful if you want to write some side-loaded software that uses the scope's controls.
These were all captured and tested on a 924S even though the image shows an 814. Hopefully you can see where I added key codes for the missing buttons.
NOTE: Each of the key codes shown is added to 0x40000000, so the Run/Stop button produces key code 0x4000000C.
-
I am also lucky, after upgrading to 01.02, the unlock tool will not work, can you help me? |O
-
I don't think I have ever seen anything beyond "00" for the top-level number;
One of the uses of that top-level is to distinguish between production and beta versions. 04 means Beta.
-
Oooh this is very useful, please clarify is your model 924 with additional memory chips installed? Or have you hacked vendor.bin? Regarding the noise on LA channels, I also have it on some channels....
It's true DHO924 without any mod. I didn't opened it, so cannot confirm memory installed.
My DHO produce 150MHz noise on channel D0 and sometimes on D13. noise disappearing if cable connected to input (both + and-) even without any load - it's just not terminated digital input
You can look through the vents on the handle side. If there are seats on the board, then there are no microcircuits.
-
My brand new 914 just arrived here - that spot below the handle looks like that.
[attach=1]
Not, that I would desperatly need it, but I was too curious. :palm:
Just discovered that nasty warranty-sticker Rigol places at the bottom of the scope. Probably need a hairdriyer for this...
-
All 900 Series oscilloscopes have fully installed FPGA RAM.
-
All 900 Series oscilloscopes have fully installed FPGA RAM.
But what's it used for?
Nobody knows...
-
All 900 Series oscilloscopes have fully installed FPGA RAM.
But what's it used for?
Nobody knows...
Maybe that memory was originally meant to be dedicated to the digital channels' data, working in parallel with the standard RAM for the analog channels? I.e. the idea was to have twice the memory bandwidth in the DHO900 series vs. the 800 models, to support the additional digital channels without sacrificing analog sampling rate? And for whatever reason that did not work out and Rigol had to fall back, last minute, onto a solution with shared memory and compromised sampling rates?
That's speculation, of course. But it would be an explanation for the awkward sampling rate compromise, and also for the fact that Rigol forgot to mention it in the datasheet.
If it should be true, a hacked DHO800 might work as an MSO just as well (or not so well) as the DHO900. And on the other hand, maybe Rigol are still hoping to improve the DHO900 sampling rates, by tweaking the FPGA code and enabling that extra RAM? Or to come out with an upgraded "DHO900 deluxe" in the future?
-
Or come out with an upgraded "DHO900 deluxe" in the future?
DHO 900 Pro Max with Titanium enclosure :-DD
-
Or come out with an upgraded "DHO900 deluxe" in the future?
DHO 900 Pro Max with Titanium Magnesium enclosure :-DD
:-DD
-
Fashionable "aviation aluminum". Well, or at least carbon :)))
-
Fashionable "aviation aluminum". Well, or at least carbon :)))
Has to be called "aerospace" or "NASA grade" aluminum, you know, the special stuff. :-DD
Wouldn't good 'ol ABS case do the job though, bringing down physical costs, and the savings can be put back into better coders?
-
Я предполагаю что все намного прозаичнее, и они просто начнут продавать дополнительную глубину памяти в виде лицензионных ключей, ведь для моделей 900 и 924 пока не предлагалось лицензии на увеличение глубины памяти.... Они же так делают уже много лет...... И не только Rigol......
-
Another option is that the points of a complex signal when generated by the generator are stored in an additional memory area. Draw function, load and generate complex waveform.Or when using the Bode plot function.
-
I wonder what URL I have to block to get rid of the red dot.
I would also like to know, for when the time comes to block mine.. Can you Wireshark it (https://www.wireshark.org/) ?
-
For the software hackers in the thread. I installed a very simple Android/Kotlin program on the scope to capture the "key" events when twiddling all the knobs and dials. Attached is an image of the key codes each generates.
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=1990369;image)
Is it possible to remap one of them them to open up the Android info screen?
There's plenty of buttons on there that I'll never use...
-
I would also like to know, for when the time comes to block mine.. Can you Wireshark it (https://www.wireshark.org/) ?
http://support.rigol.com/api/Support/ProductUpgradeFile?sn= (http://support.rigol.com/api/Support/ProductUpgradeFile?sn=)<serialnumber>&hardware=1.0&behaviour=soft&software=00.01.01
-
Я предполагаю что все намного прозаичнее, и они просто начнут продавать дополнительную глубину памяти в виде лицензионных ключей, ведь для моделей 900 и 924 пока не предлагалось лицензии на увеличение глубины памяти.... Они же так делают уже много лет...... И не только Rigol......
...deepl
I assume that everything is much more prosaic, and they will just start selling additional memory depth in the form of licence keys, because for the 900 and 924 models they have not yet offered a licence to increase the memory depth..... They've been doing that for years...... And not just Rigol......
I wondered, why they do sell this new model just in different "flawours" without any additional license. There is also a separate fashionable bag, the box and packaging are not like the usual "unattractive" brown box, but a nice black or white box, which enables Youtubers to do some presentable unboxing videos. Are they up to a new market with this model - a bit more fashionable?
BTW: If you look in the box, on the left there is an empty spot, which looks like it could be populated by a mouse.
-
For the software hackers in the thread. I installed a very simple Android/Kotlin program on the scope to capture the "key" events when twiddling all the knobs and dials. Attached is an image of the key codes each generates.
Is it possible to remap one of them them to open up the Android info screen?
There's plenty of buttons on there that I'll never use...
Ooh! Same here. I'm also curious about the ARM controller that scans the buttons on the front panel. -mainly, what kind of interface does it use to communicate with the mainboard/RK3399? I'm thinking they might've implemented a USB HID keyboard, which if true, might be fairly easy to modify.
@0xACE Where does your program look for the "key codes"?
-
Can you Wireshark it (https://www.wireshark.org/) ?
http://support.rigol.com/api/Support/ProductUpgradeFile?sn= (http://support.rigol.com/api/Support/ProductUpgradeFile?sn=)<serialnumber>&hardware=1.0&behaviour=soft&software=00.01.01
I figured it would be rigol.com. ::)
I don't really want to block that in my router but I assume Android has /etc/hosts.
Edit: Google says it does, so that's easy to block if there's ever a firmware that I don't want.
-
Can we hack the colour of the traces?
I have a colour grade on channel 1 and a sync signal on channel 2, with a persitance of 1s they nearly look the same color.
And as a second wish, can we hack the trigger and channel indicators away?
-
I wish every scope would allow an individual color selection for each channel. Though, very few does unfortunately.
-
With all the hacking stuff, I think I will try to P-V the dho804, then get that to load into vmware workstation.
Or, install the same droid OS in VMware, then copy over all the additional Rigol stuff from the dho into the guest droid OS.
Will make poking around much easier.
Has anyone booted the DHO from a bootable USB stick?
-
If you're going to poke around, add a watch with a date in the lower right corner, like in the 1000 series.... ^-^
-
This question/answer might be of use for key-remapping, though I've not looked into it.
From StackExchange: https://android.stackexchange.com/questions/249423/how-to-remap-keyboard-shortcut
I'll post the GitHub link to the KeyReporter program later this evening. Thought I already had it there, but apparently not.
I did not see the keyboard as a USB device (using `lsusb`) but I may not have interpreted it correctly.
I also played with controlling the LEDs by calling into the binary shared library (extracted from Sparrow.apk -- the "scope" program). Unfortunately, when calling the "Post" function the library seems to start up the FPGA or something else on the scope and kills the active program on me.
-
Here is the GitHub Repo with the "Android-Keys" program I used to discover the keycodes.
https://github.com/stephenhouser/Android-Keys (https://github.com/stephenhouser/Android-Keys)
-
Here is the GitHub Repo with the "Android-Keys" program I used to discover the keycodes.
https://github.com/stephenhouser/Android-Keys (https://github.com/stephenhouser/Android-Keys)
Just for clarity, keyboard keys, and not "keys" used for lics.
Cool. Thanks.
-
Yes! Keyboard keycodes. not license keys
-
Here is the GitHub Repo with the "Android-Keys" program I used to discover the keycodes.
https://github.com/stephenhouser/Android-Keys (https://github.com/stephenhouser/Android-Keys)
Just for clarity, keyboard keys, and not "keys" used for lics.
Cool. Thanks.
Usually, GitHub projects have a readme when you click the link, that tells what it's for.
Here is the GitHub Repo with the "Android-Keys" program I used to discover the keycodes.
@0xACE Thanks for sharing the link. Saved me having to ask. 8)
-
With all the hacking stuff, I think I will try to P-V the dho804, then get that to load into vmware workstation.
Or, install the same droid OS in VMware, then copy over all the additional Rigol stuff from the dho into the guest droid OS.
Will make poking around much easier.
Has anyone booted the DHO from a bootable USB stick?
Please keep us apprised of your progress. I'm really interested in USB booting, especially regarding boot speed, etc. and virtualization might be a nice environment to experiment in.
-
I wonder what URL I have to block to get rid of the red dot.
Request was like this:
https://spiderapi.rigol.com/api/Support/ProductUpgradeFile?sn=DHO8AXXXXXXXXX&hardware=1.0&behaviour=soft&software=00.01.01
This is shown in adb logcat
UPDATE: Just noticed this was already answered... ::)
-
If you're going to poke around, add a watch with a date in the lower right corner, like in the 1000 series.... ^-^
Problem: Only DHO8/9 scopes with access to a NTP server could take advantage of the date/clock function, since these don't have a RTC battery...
...Yet ;)
(cough: Pin 9, PMIC. /cough)
-
I wonder what URL I have to block to get rid of the red dot.
Request was like this:
https://spiderapi.rigol.com/api/Support/ProductUpgradeFile?sn=DHO8AXXXXXXXXX&hardware=1.0&behaviour=soft&software=00.01.01
This is shown in adb logcat
UPDATE: Just noticed this was already answered... ::)
But with a different URL:
http://support.rigol.com/api/Support/ProductUpgradeFile?sn=<serialnumber>&hardware=1.0&behaviour=soft&software=00.01.01
-
Ok, sorry for the confusion. I just checked with Wireshark:
The initial update check is addressed to support.rigol.com.
The actual firmware image file would apparently be loaded from spiderapi.rigol.com.
NTP is queried from asia.pool.ntp.org
Additionally, I had two connection attempts to 192.168.1.143:2300 which is not a valid destination within my network...
-
Additionally, I had two connection attempts to 192.168.1.143:2300 which is not a valid destination within my network...
Thanks for doing that.
So if I'm reading this right; you're on a different private IP space than the "de facto" 192.x, but the scope is trying to reach a "hard coded" private NAT address?
-
Additionally, I had two connection attempts to 192.168.1.143:2300 which is not a valid destination within my network...
Thanks for doing that.
So if I'm reading this right; you're on a different private IP space than the de facto 192.x, but the scope is trying to reach some "hard coded" private NAT addresses?
Yes, indeed. I just tried to configure a device at this address and look at the communication, but this failed cause the Rigol itself uses my DHCP assigned subnet, and the Mikrotik router doesn't know where to route this request to. I'm reluctant to reconfigure any router settings... It would be better to set up some isolated network with a Raspberry Pi or anything alike. Not sure if I find the time this weekend to do this, but I'm curious now...
-
If you're going to poke around, add a watch with a date in the lower right corner, like in the 1000 series.... ^-^
I managed to do this using a third-party program "Status Bar Mini PRO"
-
Please elaborate a bit more.
How to install Status Bar Mini PRO
Can it be moved to righttop off the screen?
I managed to do this using a third-party program "Status Bar Mini PRO"
-
Please elaborate a bit more.
How to install Status Bar Mini PRO
Can it be moved to righttop off the screen?
I managed to do this using a third-party program "Status Bar Mini PRO"
Just enter a query with the name of the program in a search engine, you will immediately be offered links to download the apk file, install the downloaded apk in your skope. You can place the date and time display in any area of the screen, you can also choose the color and font size, this program is very flexible in settings. Go for it!!!
-
Now this was quite some fun to setup... 8)
[attachimg=1]
Apparently, Rigol is contacting 192.168.1.143 for Android OTA updates...
bofh@raspberrypi:~ $ sudo ip addr add 192.168.1.143/22 dev eth0.666
bofh@raspberrypi:~ $ nc -l -s 192.168.1.143 -p 2300
HEAD /OtaUpdater/android?product=rk3399_rigol&version=1.0.0&sn=RW8GIY5R55&country=US&language=en HTTP/1.1
Host: 192.168.1.143:2300
Connection: Keep-Alive
User-Agent: rk29sdk/4.0
bofh@raspberrypi:~ $
-
Apparently, Rigol is contacting 192.168.1.143 for Android OTA updates...
Maybe Rigol's internal server for devs to push out updates...
-
I wish every scope would allow an individual color selection for each channel. Though, very few does unfortunately.
By the way, LeCroy has a paid option... :-DD :-DD :-DD
-
Weel shall we mail Rigol with this idea? An option for Eu20,-- is a cashcow.
I wish every scope would allow an individual color selection for each channel. Though, very few does unfortunately.
By the way, LeCroy has a paid option... :-DD :-DD :-DD
-
Now this was quite some fun to setup... 8)
Apparently, Rigol is contacting 192.168.1.143 for Android OTA updates...
bofh@raspberrypi:~ $ sudo ip addr add 192.168.1.143/22 dev eth0.666
bofh@raspberrypi:~ $ nc -l -s 192.168.1.143 -p 2300
HEAD /OtaUpdater/android?product=rk3399_rigol&version=1.0.0&sn=RW8GIY5R55&country=US&language=en HTTP/1.1
Host: 192.168.1.143:2300
Connection: Keep-Alive
User-Agent: rk29sdk/4.0
bofh@raspberrypi:~ $
That's so awesome, thanks for confirming that. Seems like a silly thing for the devs to overlook. And, given that they're targeting a specific port#, I agree with @Fungus that it's probably an internal server.
-
I managed to do this using a third-party program "Status Bar Mini PRO"
Looks like you also modified the fonts as well. Did you do that with Status Bar Mini Pro as well? If so, It's worth the $3us to me.
Edit: Looks like the font modifying program was mentioned in the "Unbox" thread, sorry.
It's probably a bit peevish of me, but I would love to change the font on the "Auto" in the upper left corner so the "O" isn't wrapped around to the second line in the box. I know it's a bargain scope, and maybe users have filed a bug report, but it just looks silly and unprofessional.
-
I would love to change the font on the "Auto" in the upper left corner so the "O" isn't wrapped around to the second line in the box. I know it's a bargain scope, and maybe users have filed a bug report, but it just looks silly and unprofessional.
Filing a bug report (with Rigol) on a hack is probably not going to be effective. :)
The original font fits into its allotted space without a line break, I believe.
-
I managed to do this using a third-party program "Status Bar Mini PRO"
Looks like you also modified the fonts as well. Did you do that with Status Bar Mini Pro as well? If so, It's worth the $3us to me.
It's probably a bit peevish of me, but I would love to change the font on the "Auto" in the upper left corner so the "O" isn't wrapped around to the second line in the box. I know it's a bargain scope, and maybe users have filed a bug report, but it just looks silly and unprofessional.
I changed the font with the program "FontFix 4.9.0", the font name is "comfortaa", in some places the text does not fit on one line because I increased the font scale in the android system settings... It’s more convenient for me.If you don’t change the font scale in the system, everything will fit....
-
I would love to change the font on the "Auto" in the upper left corner so the "O" isn't wrapped around to the second line in the box. I know it's a bargain scope, and maybe users have filed a bug report, but it just looks silly and unprofessional.
Filing a bug report (with Rigol) on a hack is probably not going to be effective. :)
The original font fits into its allotted space without a line break, I believe.
Confirmed. I guess I saw so many screenshots recently with the wrap around, and mine was back in the box, I thought it was systemic.
And yeah, that wouldn't be prudent to file with Rigol. ;)
-
Now this was quite some fun to setup... 8)
(Attachment Link)
Apparently, Rigol is contacting 192.168.1.143 for Android OTA updates...
bofh[member=125346]raspberrypi[/member]:~ $ sudo ip addr add 192.168.1.143/22 dev eth0.666
bofh[member=125346]raspberrypi[/member]:~ $ nc -l -s 192.168.1.143 -p 2300
HEAD /OtaUpdater/android?product=rk3399_rigol&version=1.0.0&sn=RW8GIY5R55&country=US&language=en HTTP/1.1
Host: 192.168.1.143:2300
Connection: Keep-Alive
User-Agent: rk29sdk/4.0
bofh[member=125346]raspberrypi[/member]:~ $
These commands are seen on the DHO ?
Not making sense to me.
sudo ip addr add 192.168.1.143/22 dev eth0.666 binds ipv4 address with /22 mask to sub iface 666 on eth0
nc -l -s 192.168.1.143 -p 2300 , at least in combo with ip add, this nc seems to be setting up a local tcp socket listener on port 2300
So how does this facilitate an OTA update?
-
These commands are seen on the DHO ?
No. These commands are being run on a raspberry pi. They set up a listener on that IP address so that when the DHO tries to connect to it, the raspberry will display the request that the DHO makes.
-
These commands are seen on the DHO ?
No. These commands are being run on a raspberry pi. They set up a listener on that IP address so that when the DHO tries to connect to it, the raspberry will display the request that the DHO makes.
Ahhh. Makes sense now.
Just run filter on wireshark looking for the ARP who-has and DNS requests. Maybe see even more odd attempts from the DHO to reach out.
-
I know some have been dissecting some binaries with Ghidra. I am now playing around with apk dissector APKEditor
https://github.com/REAndroid/APKEditor
It's been a few years since I had a android SDK going for doing some java and C apps, but now we get to dissect the rigol apk's that's on the DHO(android).
I pulled out the APK's from the v00.01.02.00.00 gel zip
Did APKEditor d (type raw) on the Sparrow APK, found some interesting strings in the biggest binary (5,420,496 bytes resources.arsc). A lot of references to non DHO800/900 features and upgrades. Perhaps they reuse a code module across a lot of the various hardware?
In the pic, in the "opensurces.files" folder I find Rigol logo images, likely the boot image and one other smaller one. The "header.htm" file there appears to be the html front side to the opensource acknowledgement, but for the bigger models (see pic).
This DHO800/900 GEL appears to have files that are not applicable to the DHO800/900 models.
Examples below, attached is strings.txt if you want to just browse the output from strings command.
20.0kbps
2000
20000
20000X
2000X
200M
))200MHz to 350MHz bandwidth upgrade option
))200MHz to 400MHz bandwidth upgrade option
))200MHz to 500MHz bandwidth upgrade option
))200MHz to 800MHz bandwidth upgrade option
200Mpts deep memory option
200X
200ms
20Mbps
20kbps
230.4kbps
244.14kHz
250.0kbps
25000
250M
250kbps
2Gpts deep memory option
2Mbps
30.52kHz
300 bps
30000
300bps
305.18kHz
33.3kbps
))350MHz to 500MHz bandwidth upgrade option
38.4kbps
3Mbps
4.88MHz
4.8kbps
))400MHz to 800MHz bandwidth upgrade option
460.8kbps
480p/60Hz
488.28kHz
4Mbps
5 Bits
5 bits
50 Ohm overload protection
50 bps
50.0kbps
500.0kbps
5000
50000X
5000X
500M
500Mpts deep memory option
500X
500kbps
500ms
50Ohm Overload,Protected!(CH1)
50Ohm Overload,Protected!(CH2)
50Ohm Overload,Protected!(CH3)
50Ohm Overload,Protected!(CH4)
Some refernce to HP printers
HP/deskjet
HP/laserjet
-
The best I could do was to dump TAR GZ of the raw decompiled APK's to easy upload site. Now you can dig in.
Files with my local sha256sum hashes
v 00.01.02.00.00
Sparrow https://easyupload.io/giyf2f
Launcher https://easyupload.io/8et8ty
Webcontrol https://easyupload.io/ewkhmh
b24e07e618d518775f8e8e830ae394cddf2c84c06c4ea4b733baebd09e67f5f8 Sparrow.apk.tar.gz
3e0f16b6fb2f83394b00600bb4da9c141b53a5541bb85fa09741f28ce18405e6 Launcher.apk.tar.gz
c260dae73c6e50021412cc38495b534b8e7fcadc146ec9e243f54c6f352156a8 Webcontrol.apk.tar.gz
v 00.01.02.00.02
Sparrow https://easyupload.io/a931b4
Launcher https://easyupload.io/i89y1t
Webcontrol https://easyupload.io/b4dhr6
8b09d764c7b84056ae8c84322c55916da30612f3bd829e888ba233819364e436 Sparrow-2.apk.tar.gz
085117333d0fdf2c62f7bdaf312ed55cb2dbc743f772575a17dcdadf7a547366 Launcher-2.apk.tar.gz
1b982eeae2eb1f822e93d309d00b0e669829d619c838dc59d0a1f121c43ace03 Webcontrol-2.apk.tar.gz
-
Digging through the APK and classes is where I found the calls to the native library which controls the LEDs on the control surface. In `com.rigol.scope.cil` package.
As a side note, the colors of the traces are in the colors.xml file, which is compiled to a binary resource file. Easy to modify if you are recompiling, not so easy if the APK is signed.
-
Digging through the APK and classes is where I found the calls to the native library which controls the LEDs on the control surface. In `com.rigol.scope.cil` package.
As a side note, the colors of the traces are in the colors.xml file, which is compiled to a binary resource file. Easy to modify if you are recompiling, not so easy if the APK is signed.
APKEditor says it can rebuild from dissecting, so you can edit and then rebuild it, I just not sure how signing works
b is option to build from the json/xml "b | build - Builds android binary from json/xml"
[roott@localhost APKeditor]# java -jar APKEditor.jar b -h
Builds android binary from json/xml
Options:
-i input path
-o output path
-framework-version preferred framework version number
-framework path of framework file (can be multiple)
-sig signatures directory path
-res-dir sets resource files root dir name
(eg. for obfuscation to move files from 'res/*' to 'r/*'
or vice versa)
-
Is the oscilloscope application really signed?
I wonder if an unsigned APK simply won’t launch? Or how does a signature work?
-
All .apk are signed. Normally they're just signed with your own local certificate, the problem are system apps with elevated rights recognizable by
android:sharedUserId="android.uid.system"in AndroidManifest.xml
You can't resign them because you don't have the private key of the system cert.
One possible workaround is to NOP out the cert check in PackageManagerService...
-
One possible workaround is to NOP out the cert check in the system...
or, is it possible to add your own cert that you sign the APK with into the trusted certificate store in the system? There has to be a store of trusted certs that the system uses to validate the APKs against. I don't know how it works in android though.
-
Since we have root access, should be easy to add a cert to System cert store. Then sign mod'd APK's.
Or even possibly mod the APK to trust User cert store?
https://medium.com/hackers-secrets/adding-a-certificate-to-android-system-trust-store-ae8ca3519a85
-
Those are for TLS, not apks.
-
I wonder whether there is any validation method outside of the Google play framework at all. Internet search has been fruitless for me (besides the google apps related results), so I suppose there might be none, unless Rigol implemented something of their own.
-
apk validation happens in AOSP, not Google Play.
-
apk validation is AOSP, not Google Play.
Still a bit hard to search (goddamn https related results make SNR ridiculous), however found this, FWIW:
Applications can be signed by a third-party (OEM, operator, alternative market) or self-signed. Android provides code signing using self-signed certificates that developers can generate without external assistance or permission. Applications do not have to be signed by a central authority. Android currently does not perform CA verification for application certificates.
https://source.android.com/docs/security/overview/app-security
-
Xposed might be an (untested) way:
https://www.xda-developers.com/application-signature-verification-how-it-works-how-to-disable-it-with-xposed-and-why-you-shouldnt/ (https://www.xda-developers.com/application-signature-verification-how-it-works-how-to-disable-it-with-xposed-and-why-you-shouldnt/)
A bit newer:
https://xiaomiui.net/how-to-disable-signature-verification-on-android-4235/ (https://xiaomiui.net/how-to-disable-signature-verification-on-android-4235/)
-
Here's the manifest.xml for Sparrow.apk and Launcher.apk
attached as txt file
-
Xposed might be an (untested) alternative:
https://www.xda-developers.com/application-signature-verification-how-it-works-how-to-disable-it-with-xposed-and-why-you-shouldnt/ (https://www.xda-developers.com/application-signature-verification-how-it-works-how-to-disable-it-with-xposed-and-why-you-shouldnt/)
A bit more current:
https://xiaomiui.net/how-to-disable-signature-verification-on-android-4235/ (https://xiaomiui.net/how-to-disable-signature-verification-on-android-4235/)
I may be misunderstanding the concept of apk signing and signature validation, but it all doesn't compute for me. It's still the same asymmetric cryptography, in principle similar to what is used e.g. by TLS (for https), correct? Which means the signature, at the end of the day, is validated against one of the trusted public keys, known by the local system, which must be kept either in plain text (like TLS CAs), or obfuscated in some way, but it must still be readable by the system, and thus, ultimately, also by the human having physical access to the storage device where that trusted key store is located. It should also be modifiable just as well.
This means it should be doable without extra software, just with modifying some files on the storage, just need where to look. After all, that software is aimed mostly towards smartphones and is made to be easy to use for a typical (power)user of a typical device. Am I wrong? Any android gurus here? How does it actually work under the hood?
(and, before we get ourselves too deep into this, perhaps the scope will be just happy to run a self-signed scope app?)
-
I may be misunderstanding the concept of apk signing and signature validation, but it all doesn't compute for me.
There's v1 and v2 and a v3 of APK signing
https://source.android.com/docs/security/features/apksigning
https://medium.com/@dhuma1981/understanding-new-apk-signature-scheme-v2-b705178f4d60
But it does not seem like the signing part is an obstacle. Just sign mod'd APK with some new key, and put the trusted key in the System store.
https://developer.android.com/tools/apksigner
-
Anyone have the Adroid Studio installed?
Use apksigner to verify if/how the Rigol APK's are signed
I need to get latest SDK on my windows since my linux disk is now full (need to fix that issue). But see if what I need is in cmd-line tools-only zip.
https://developer.android.com/tools/apksigner
-
I have loaded and run my own apps (from android studio) but have not tried resigning the Sparrow.apk
-
Use apksigner to verify if/how the Rigol APK's are signed
You can read about the signing details in the DHO1000 thread: https://www.eevblog.com/forum/testgear/hacking-the-hdo1khdo4k-rigol-12-bit-scope/msg5242014/#msg5242014 (https://www.eevblog.com/forum/testgear/hacking-the-hdo1khdo4k-rigol-12-bit-scope/msg5242014/#msg5242014)
Assuming its the same here.
-
Hi Could you tell me how to restore the RLU.lic file? I was trying to upgrade the 02 firmware and looks like I messed up with the RLU.lic file. Thankyou
-
Hi Could you tell me how to restore the RLU.lic file? I was trying to upgrade the 02 firmware and looks like I messed up with the RLU.lic file. Thankyou
It doesn't work with firmware 01.02.02
-
Howdy. I'm trying to get a complete backup from a new/unmodded DHO800 so I can open it up and get hackin'.
I panicked a bit when the second calibration attempt failed. I found this post (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5135658/#msg5135658) from @Mechatrommer and others about calibration failure with "testmode on"
Anyone know which of the additional options work/fail to cal, to save me some time?
Also, I know ADB works fine via Wifi, but what about via USB? Is that B port only for USBTMC? I can't see any devices via ChromeOS/Linux or Windoze(altho', it shows up in Device Mangler)
-
Howdy. I'm trying to get everything backed up on my sparkling new(albeit smelly) DHO8xx so I can open it and get to work.
The smell goes away after a week or so.
(I left mine powered up in a spare room so it was warm, YMMV).
Since it takes so long to run thru a calibration, does anyone know which of the additional options fail, to save me some time?
How about you just use default options? They work.
Also, I know ADB works fine via Wifi, but what about via USB?
No.
Is that B port only for USBTMC?
It's for plugging in your WiFi dongle. :)
After that you can use FTP to grab files and web browser for screenshots.
-
Howdy. I'm trying to get everything backed up on my sparkling new(albeit smelly) DHO8xx so I can open it and get to work.
The smell goes away after a week or so.
(I left mine powered up in a spare room so it was warm, YMMV).
Since it takes so long to run thru a calibration, does anyone know which of the additional options fail, to save me some time?
How about you just use default options? They work.
Also, I know ADB works fine via Wifi, but what about via USB?
No.
Is that B port only for USBTMC?
It's for plugging in your WiFi dongle. :)
After that you can use FTP to grab files and web browser for screenshots.
Oh great. I heard it goes away, so I'll continue to be patient. The smell makes me flash back to early years of "letting the smoke out" of components.
I know the default options work, but I wanted to have copies of the extended options, just in case.
So the USB B port on the back is for plugging devices into? Sweet! I'll build a Male B to Female A adapter then. :D
Thanks!
-
As is in current config
USB B port on the back is an USB device or client or whatever name they have, is not a USB host port.
USB A port on front is a USB host port where you can plug devices
-
As is in current config
USB B port on the back is an USB device or client or whatever name they have, is not a USB host port.
USB A port on front is a USB host port where you can plug devices
I do wish that we had 1-2 more native USB ports on these to plug devices into without going through a hub. And as such, I'm curious how difficult it would be to modify the RK3399 config so the B port would be a 3.x host... Adding a little power control chip and connector wouldn't be that difficult. I think it would be a better use of a port than USBTMC, at least for my uses.
-
Without schematic need reverse engineering at hardware and software level.
Read RK3399 datasheet
https://www.rockchip.fr/RK3399 (https://www.rockchip.fr/RK3399) datasheet V1.8.pdf
Check if USB required pins are not used for alternative functions (maybe are unused or used for something else)
Route that to USB port.
Make required initialization in android OS and that's all.
-
Is that B port only for USBTMC?
It's for plugging in your WiFi dongle. :)
After that you can use FTP to grab files and web browser for screenshots.
So the USB B port on the back is for plugging devices into? Sweet! I'll build a Male B to Female A adapter then. :D
Thanks!
Ooops, no! I got confused, the one one the back is only for connecting TO the device.
The one on the front is for WiFi. It's pretty much all you need.
-
I do wish that we had 1-2 more native USB ports on these to plug devices into without going through a hub.
I'm sure you can find a hub small enough to glue to the front if you need more ports...
I'm happy with just a WiFi dongle.
There's absolutely no need for USB sticks when you have WiFi working and I find a stylus works better than a mouse.
-
I was wondering if there's enough room inside to bodge a small USB hub (e.g. simply with 4 wires) in place of the original front panel port and connect a wifi dongle and an extension cable leading to the front panel connector to it, making the original port now connected to the hub and creating a built-in wifi interface. One would need to be really desperate to go this way though :)
-
Howdy. I'm trying to get a complete backup from a new/unmodded DHO800 so I can open it up and get hackin'.
I panicked a bit when the second calibration attempt failed. I found this post (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5135658/#msg5135658) from @Mechatrommer and others about calibration failure with "testmode on"
Anyone know which of the additional options work/fail to cal, to save me some time?
Also, I know ADB works fine via Wifi, but what about via USB? Is that B port only for USBTMC? I can't see any devices via ChromeOS/Linux or Windoze(altho', it shows up in Device Mangler)
A linux boot USB and using ddrescue would be my approach, but there are also live droid tools that can copy block level.
Of if you just want files, maybe tar-zip / and place the output file on a large USB stick.
-
Is the oscilloscope application really signed?
I wonder if an unsigned APK simply won’t launch? Or how does a signature work?
Yep. Surely signed.
Interesting signing info, would think the cert info would be Rigol Corp china, but appears to be SDK default with a rigol email address.
As we can see, only type-v2 signing is done.
There's also a difference between INSTALLING vs SIDE-LOADING an APK. I believe the Rigol APK's are side loaded.
Re-signing with a new key pair does seem doable. However, there seems to be conflicting text on Android site about being able to re-sign with or without same keys w/o issue.
Is it possible to derive the private key from this public key? My answer is yes we can, but will need access to some qubit cycles in cloud or something since it takes time.
apksigner verify --verbose --print-certs C:\Users\randy\Desktop\DHO\Sparrow.apk.zip
Verifies
Verified using v1 scheme (JAR signing): false
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v3.1 scheme (APK Signature Scheme v3.1): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=hexiaohua@rigol.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
Signer #1 certificate SHA-256 digest: f48e7189aac174df7fd19acf58b6d15832760fcf25ac0a6d4bcd5fc1974d4c03
Signer #1 certificate SHA-1 digest: df345a93532e902ff6291668c20ad69da3b72ff6
Signer #1 certificate MD5 digest: 40490c2e0b280e29ba5e46205272e3dc
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: ca871f06fa7ffaa5beda2179a2278a0474d98e6b5e11d9aab2dfb590d8e57292
Signer #1 public key SHA-1 digest: 90ff0ddf5a0881ea080558b3b585dd0352342d8e
Signer #1 public key MD5 digest: 78d923a60c0963a38de1ee05b4556031
Also, from poking around in Sparrow APK in Droid Studio Hedgehog, Rigol's SDK is v29 but they target v25. Not sure why, maybe some of their hardware can't run droid above v25, or maybe due to some deprecation in v29 they still write for v25 in the v29 SDK. Not sure exactly. Studio also throws up a boat load of warnings about bad whitespacing, and one URI error for the URL in manifeat for schema reference. The URL does not seem to exist on internet, so maybe Rigol has a hosts entry for it in their SDK machine?
-
There's also a difference between INSTALLING vs SIDE-LOADING an APK. I believe the Rigol APK's are side loaded.
There's a script /rigol/shell/do_extract.sh that installs the .apk
-
There's also a difference between INSTALLING vs SIDE-LOADING an APK. I believe the Rigol APK's are side loaded.
There's a script /rigol/shell/do_extract.sh that installs the .apk
Installs, or just copies files out of the GEL(zip) and places them onto a filesystem?
-
There's a script /rigol/shell/do_extract.sh that installs the .apk
Installs, or just copies files out of the GEL(zip) and places them onto a filesystem?
I'm not an Android expert but it looks like an install to me:
...
UPDATE_DSO=$UPDATE_SOURCE/app/Sparrow.apk
####################################################################################
# Scope APK install. return if failed You can install WITHOUT VERSION CHECKING
####################################################################################
if [ -f $UPDATE_DSO ]; then
echo pm install -r $UPDATE_DSO
pm install -r $UPDATE_DSO >/dev/null 2>&1
#check if success
if [ $? -ne 0 ]; then
#restore when install failed
cp $UPDATE_BAKUP/* $UPDATE_TARGET/ -R
echo 'Upgradation failed'
rm $UPDATE_FLAG
sync
exit 2
fi
fi
echo "OK"
-
They dev/null the install stdout? Why?
If the check fails and cp rollback happens, wouldn't it be nice to have the install log?
-
They dev/null the install stdout? Why?
So that the hackers can have fun finding and fixing it, it seems.
-
Did a little tuning for SSH and startup script.
Once you get SSH working with keys (as written up already), the ssh session is missing ANDROID_SYSTEM and ANDROID_DATA env variables.
Variables are ANDROID_SYSTEM=\system and ANDROID_DATA=\data
I set "AcceptEnv ANDROID_SYSTEM ANDROID_DATA" in sshd_config file (you need to remount /system as rw to edit that file).
I then pass along the variables in Putty.
Next is to STOP the scope and to turn off CH1 during boot-up. After re-reading thread posts I figured it out.
So, in start script (/rigol/shell/) I make some mods around the insmod of the touchscreen driver. Not really sure why they put a sleep 20 before loading ts driver focaltech_ts.ko
So, I comment out that sleep 20 and add a sleep 10 after the ts driver, then this line below "sleep 10" , echo ":STOP;CHANnel1:DISPlay 0" |toybox nc -q 2 localhost 5555
Now the unit boots a smidge faster and it will rest in a no-channel STOP mode (the way it should be).
I could not find any properties key values that would set Channel or Run state.
-
Without schematic need reverse engineering at hardware and software level.
Read RK3399 datasheet
https://www.rockchip.fr/RK3399 (https://www.rockchip.fr/RK3399) datasheet V1.8.pdf
Check if USB required pins are not used for alternative functions (maybe are unused or used for something else)
Route that to USB port.
Make required initialization in android OS and that's all.
Thanks! That's what I thought too. I've read thru several datasheets and schematics from various RK3399 SBC vendors. Rigol most likely used a reference design from Rockchip., and I wish I could get my hands on the one they used in this design, especially with schematics.. I've been out of the biz long enuf to lose all my old industry contacts.
Clearly, the USB B port in the back is routed directly, as it's already in use as a USB device, and implemented as USBTMC. What I was suggesting is changing that port to a 3.1 host. I haven't opened mine yet, but Dave's teardown pics show the protection diodes(on the back) for that port.
-
A linux boot USB and using ddrescue would be my approach, but there are also live droid tools that can copy block level.
Of if you just want files, maybe tar-zip / and place the output file on a large USB stick.
So, did you find that these DHO scopes boot from USB? 'cuz I have a super cheap M.2 drive and USB adapter that gets ~1GBps transfers that I would prefer to use to boot from. Sure would beat the TF speed of 10-11.
-
I do wish that we had 1-2 more native USB ports on these to plug devices into without going through a hub.
I'm sure you can find a hub small enough to glue to the front if you need more ports... I'm happy with just a WiFi dongle.
I see your point, but again, I was saying without a hub. It looks "fiddly" to me to have a bunch of cables and adapters hanging off and besides, cheap USB connectors have a finite amount of mating cycles. -verify this claim by looking in your junk box.
There's absolutely no need for USB sticks when you have WiFi working and I find a stylus works better than a mouse.
Well, there are other devices that people like to plug into these other than WiFi; like kybd/mouse, audio, Bluetooth, etc. I've even seen people using thermal cameras and SDRs. -Even tho' the latter are probably not that important to have plugged all the time.
BTW: I have a couple 5-in-1 USB-C "docks" (i.e., hubs) that have SDCard/USB/HDMI, and interestingly, one of them makes my scope reboot when I plug it in. -without anything peripherals plugged into it. And it doesn't freak out any other devices I've plugged it into. Funky.
-
For the effort needed to hack in more USB ports,
just get a small USB "hub" that has a 12" USB cord on it, plug it in and then attach the hubby to rear of scope.
But that's just me. ;)
As for the USB-C in rear, in the teardown does it look like data pins weave into the RK3399? Or is thet USB-C soley just power?
If the read C data pins can be used, then it is possible to make a power & data-pins combiner using 3 USB-C female connectors, this way you can do feedthrough for the power wart and for a serial data line.
I did read through the RK3399 datasheet PDF. There are several ways to boot it, one being a USB OTG method, where you can actually boot something like ubuntu. I just not sure how USB OTG works.
-
I've written a small C program to dump the scope FRAM.
You can use the kernel /dev/i2c devices to do that. FRAM sits on bus 4 at slave address 0x50
You must first write 2 bytes specifying the start address and then you can read/write from the file descriptor.
I have found no evidence that the scope model, serial or MAC are stored in the FRAM.
The Key.data (I'm still on the old firmware) is though.
At address 0x100 you have a header of 6 words, next the CRC32 of the file and then from 0x11C-0x1B0
the entire Key.data file
The FRAM is mostly empty except the 0x800-0x12F0 region which I presume holds all the calibration data.
-
I have found no evidence that the scope model, serial or MAC are stored in the FRAM.
FRAM is only for storing the current state of the device for power-off. It gets written to every time you twist a knob so it has to be something that can't ever wear out.
(cue all the "flash can do that too!" replies)
The model, serial and MAC are stored in /rigol/data/vendor.bin
-
I see auklet.so changes a lot from 01.02.00.00 to 01.02.00.02
But I went looking for "lic" and "Key.data"
Note sure this helps.
You can see where RKey.data is in the v01.02.00.02 so file, maybe hunt that down in Ghidra.
In the older FW, is the key used an AES key? Is that key perhaps part of the keypair used to sign the APK's ?
[roott@localhost DHO]# strings libscope-auklet.01.02.so |grep lic
_ZN8CApiBase14licenseChangedEv
_ZN14CApiHorizontal14licenseChangedEv
_ZThn8_N14CApiHorizontal14licenseChangedEv
_ZN11CApiUtility14licenseChangedEv
_ZThn8_N11CApiUtility14licenseChangedEv
_ZN7CApiRef14licenseChangedEv
_ZThn8_N7CApiRef14licenseChangedEv
_ZN11CApiTrigger14licenseChangedEv
_ZThn8_N11CApiTrigger14licenseChangedEv
_ZN7CApiBus14licenseChangedEv
_ZThn8_N7CApiBus14licenseChangedEv
_ZN10CApiSearch14licenseChangedEv
_ZThn8_N10CApiSearch14licenseChangedEv
.lic
[%s][%s][%d]: ************USB-TMC Application Watcher - init_netlink E ************
[%s][%s][%d]: ************USB-TMC Application Watcher - init_netlink X ************
[%s][%s][%d]: ************USB-TMC Application Watcher************
[%s][%s][%d]: ************USB-TMC Application Watcher - do while loop - netlink_sd = %d ************
[roott@localhost DHO]# strings libscope-auklet.01.02.so |grep lic |wc -l
18
///////////////////\\\\\\\\\\\\\\\\\\\\
[roott@localhost DHO]# strings libscope-auklet.01.02.02.so |grep lic
_ZN8CApiBase14licenseChangedEv
_ZN14CApiHorizontal14licenseChangedEv
_ZThn8_N14CApiHorizontal14licenseChangedEv
_ZN11CApiUtility14licenseChangedEv
_ZThn8_N11CApiUtility14licenseChangedEv
_ZN7CApiRef14licenseChangedEv
_ZThn8_N7CApiRef14licenseChangedEv
_ZN11CApiTrigger14licenseChangedEv
_ZThn8_N11CApiTrigger14licenseChangedEv
_ZN7CApiBus14licenseChangedEv
_ZThn8_N7CApiBus14licenseChangedEv
_ZN10CApiSearch14licenseChangedEv
_ZThn8_N10CApiSearch14licenseChangedEv
.lic
../../../../src/cpp/scope/api/license/license.cpp
[%s][%s][%d]: ************USB-TMC Application Watcher - init_netlink E ************
[%s][%s][%d]: ************USB-TMC Application Watcher - init_netlink X ************
[%s][%s][%d]: ************USB-TMC Application Watcher************
[%s][%s][%d]: ************USB-TMC Application Watcher - do while loop - netlink_sd = %d ************
[roott@localhost DHO]# strings libscope-auklet.01.02.02.so |grep lic |wc -l
19
///////////////////\\\\\\\\\\\\\\\\\\\\
[roott@localhost DHO]# strings libscope-auklet.01.02.02.so |grep lic > 2.txt
[roott@localhost DHO]# strings libscope-auklet.01.02.so |grep lic > 1.txt
[roott@localhost DHO]# diff 1.txt 2.txt
14a15
> ../../../../src/cpp/scope/api/license/license.cpp
///////////////////\\\\\\\\\\\\\\\\\\\\
[roott@localhost DHO]# strings libscope-auklet.01.02.so |grep Key.data
Key.data
[roott@localhost DHO]# strings libscope-auklet.01.02.so |grep Key.data |hexdump
0000000 654b 2e79 6164 6174 000a
0000009
[roott@localhost DHO]# strings libscope-auklet.01.02.02.so |grep Key.data
RKey.data
[roott@localhost DHO]# strings libscope-auklet.01.02.02.so |grep Key.data |hexdump
0000000 4b52 7965 642e 7461 0a61
000000a
-
There are two new public functions in the new libscope-auklet.so, which appear to be relevant to the license changes:
method.CApiLicense.generate_something
method.CApiLicense.xorEncrypt
Plus a few private ones. xorEncrypt is trivial, but 'generate_something' looks quite interesting.
-
There are two new public functions in the new libscope-auklet.so, which appear to be relevant to the license changes:
method.CApiLicense.generate_something
method.CApiLicense.xorEncrypt
Plus a few private ones. xorEncrypt is trivial, but 'generate_something' looks quite interesting.
I find it in Ghidra, but I can't follow the assembly code that well. But I getting it slowly. Here's the C function of the assembly.
So what does this function do?
void _ZN11CApiLicense18generate_somethingEm(long *param_1,undefined8 param_2,long param_3)
{
undefined *puVar1;
undefined8 uVar2;
ulong uVar3;
undefined *puVar4;
long lVar5;
long lVar6;
long lVar7;
ulong uVar8;
long lVar9;
*param_1 = 0;
param_1[1] = 0;
param_1[2] = 0;
if (param_3 == 0) {
return;
}
puVar1 = (undefined *)FUN_00271b60(param_3);
lVar9 = 0;
puVar4 = puVar1 + param_3;
*param_1 = (long)puVar1;
param_1[1] = (long)puVar1;
param_1[2] = (long)puVar4;
if (puVar4 <= puVar1) goto LAB_0037a56c;
do {
*puVar1 = (char)lVar9;
param_1[1] = (long)(puVar1 + 1);
while( true ) {
if (param_3 + -1 == lVar9) {
return;
}
puVar1 = (undefined *)param_1[1];
puVar4 = (undefined *)param_1[2];
lVar9 = lVar9 + 1;
if (puVar1 < puVar4) break;
LAB_0037a56c:
lVar5 = *param_1;
lVar6 = (long)puVar1 - lVar5;
uVar8 = lVar6 + 1;
if ((long)uVar8 < 0) {
uVar2 = FUN_0027ec50(param_1);
lVar9 = *param_1;
if (lVar9 != 0) {
param_1[1] = lVar9;
FUN_00273f60(lVar9);
}
/* WARNING: Subroutine does not return */
FUN_00b1036c(uVar2);
}
if ((ulong)((long)puVar4 - lVar5) < 0x3fffffffffffffff) {
uVar3 = ((long)puVar4 - lVar5) * 2;
if (uVar8 <= uVar3) {
uVar8 = uVar3;
}
if (uVar8 != 0) goto LAB_0037a5a4;
lVar7 = 0;
}
else {
uVar8 = 0x7fffffffffffffff;
LAB_0037a5a4:
lVar7 = FUN_00271b60(uVar8);
}
*(undefined *)(lVar7 + lVar6) = (char)lVar9;
if (0 < lVar6) {
FUN_0027fef0(lVar7,lVar5,lVar6);
}
*param_1 = lVar7;
param_1[1] = (long)((undefined *)(lVar7 + lVar6) + 1);
param_1[2] = lVar7 + uVar8;
if (lVar5 != 0) {
FUN_00273f60(lVar5);
}
}
} while( true );
}
-
I've updated my tool to be able to generate options for the new RKey.data file:
https://github.com/zelea2/rigol_vendor_bin
The only difference between the Key.data and RKey.data is that the later is XORed with a vector of incremented bytes then xxtea decrypted as before.
The AES keys are changed but we don't need to understand how. I haven't even tested it yet because I'm at work and my scope at home connected on my localnet.
I was able to print my new AES key because in the end I found a very nice environment to test functions in the libscope-auklet.so library.
Initially I wanted to run all my tests on a linux PC but that turned out almost impossible because all of the other library dependencies and symbol versioning.
In the end I've used the scope itself with 'adb root/push/pull/shell' commands.
First I've installed on my linux machine the latest Android NDK (not SDK) then I've made a working directory where I could compile my programs:
<NDK>/build/tools/make_standalone_toolchain.py --arch arm64 --install-dir working_dirIn my test program I first call dlopen to load "libscope-auklet.so" (I also do export LD_LIBRARY_PATH= so the program can find it) and then you can
call any exported function from that library and don't worry about signatures.
I call the CApiLicense constructor and finally the getLicenseKey and print them to stdout. I've also dumped the CApiLicense structure which is 440 bytes long
but I haven't bothered with what all fields represent.
The function which deletes and replaces the old Key.data with RKey.data is CApiLicense::init and I've checked by running it twice that is generates the same new file
so the new AES key (as the old one) must be somehow linked to your particular scope.
I haven't even tested this and my scope is still on v1.1 - probably someone else will beat me until I get home :P
-
I haven't even tested this and my scope is still on v1.1 - probably someone else will beat me until I get home :P
Unfortunately, the options created by the new version do not work :( The oscilloscope writes “License is invalid.”.
Although the key decoded from RKey.dat is similar to the real one (in the Key.dec file with the -d option):
brainpoolP256r1;0405B21204BBA6FF16B9110FD458F4B2EF5A8484B7B46A259BCA90D66BC425BD5E960DFDEB0F6D368EFDB0FB64B43D93FF4FB554D33EB74D0006E5D09A54791EF2
-
so the new AES key (as the old one) must be somehow linked to your particular scope.
This part though I still question. New key?
That does not make much sense given the issue that would arise from end-users who bought upgrade options and installed the lic to activate an option, unless the new Rkey.data process can still properly deciper old option lics?
Then some new updated FW comes along with a new key, which would then cause issue for the older lics based on older key data? Then end-user would need to have Rigol re-gen new option lics?
I don't see anywhere where Rigol mentions this might be an issue. This suggests to me perhaps the old option lics still work, but installing a new option lic is a different process, not necesarily with "new" key?
From Android Studio it appears Rigol (or the hands-on folks using the Android SDK) used a default "debug" key for system. With 1,000's, maybe 10's 1,000's, of DHO out there, unique key management for each device would be very problematic.
I am perhaps wrong about it.
-
Unfortunately, the options created by the new version do not work :( The oscilloscope writes “License is invalid.”.
Although the key decoded from RKey.dat is similar to the real one (in the Key.dec file with the -d option):
At least I've solved the RKey.data problem. They must have changed something in the option gen also.
One thing that comes to mind is that previously they were using the ASCII of the hex key as key, maybe now they read it properly as hex not as string.
-
[...] issue that would arise from end-users who bought upgrade options and installed the lic to activate an option, unless the new Rkey.data process can still properly deciper old option lics?
Then some new updated FW comes along with a new key, which would then cause issue for the older lics based on older key data? Then end-user would need to have Rigol re-gen new option lics?
Do we have evidence that any upgrade options have successfully been sold under the old scheme? When I got my DHO1074 with a "bundled" memory upgrade,
- Rigol struggled mightily to send the upgrade info at all -- took a few weeks and three reminders;
- The sheet they eventually sent, as well as the website to generate the unlock code, did not make any reference to the way the unlock info needs to be entered in the DHO series scopes;
- When I had figured that out -- using info from the hacking thread here, since full information on the SCPI parameters was just not available from the Rigol documentation -- the code did not work.
So maybe the original key.data scheme is flawed, and that was the reason to switch to a new one?
-
This part though I still question. New key?
That does not make much sense given the issue that would arise from end-users who bought upgrade options and installed the lic to activate an option, unless the new Rkey.data process can still properly deciper old option lics?
Then some new updated FW comes along with a new key, which would then cause issue for the older lics based on older key data? Then end-user would need to have Rigol re-gen new option lics?
I don't see anywhere where Rigol mentions this might be an issue. This suggests to me perhaps the old option lics still work, but installing a new option lic is a different process, not necesarily with "new" key?
But it is true - the options that were active in version 00.01.02.00 were canceled when updating to version 00.01.02.02.
-
if you want the "meaningless clock"
SCPI :DIS:CLOC 1 cammand activates screen clock directly under LXI logo bottom right of screen.
I then do a :SYST:DATE 2099,12,31;:SYST:TIME 23,59,59
At least now I can use the clock as an uptime from boot, starting at basically 01/01/2100 00:00:00
So, send :DIS:CLOC 1;:SYST:DATE 2099,12,31;:SYST:TIME 23,59,59 via toolbox "toybox nc" in the start script.
The DHO will not accept SCPI year higher than 2099, but the clock will turn over to year 2100.
Anyone know what :SYST:KIMP is, the key value accepts 0 or 1
:SAVE:SET 1 crashes the Sparrow.apk :(
-
This part though I still question. New key?
That does not make much sense given the issue that would arise from end-users who bought upgrade options and installed the lic to activate an option, unless the new Rkey.data process can still properly deciper old option lics?
Then some new updated FW comes along with a new key, which would then cause issue for the older lics based on older key data? Then end-user would need to have Rigol re-gen new option lics?
I don't see anywhere where Rigol mentions this might be an issue. This suggests to me perhaps the old option lics still work, but installing a new option lic is a different process, not necesarily with "new" key?
But it is true - the options that were active in version 00.01.02.00 were canceled when updating to version 00.01.02.02.
If that's the case, then I suspect there are little to no buyers of option lics, so to kill off the user generated lics they just modify the lic process in a new FW.
Rigol's reponse to "all you crackers". ;)
-
Rigol's reponse to "all you crackers". ;)
Almost. ;) The damage is done. ::)
-
If that's the case, then I suspect there are little to no buyers of option lics, so to kill off the user generated lics they just modify the lic process in a new FW.
I would like to remind you that there are still no purchasable options for this series.
If you think about it a little, apparent contradictions resolve themselves.
-
I'm really confused now.
I've upgraded my scope first via internet to version 1.2 and that has created a RKey.data. When compared to FRAM stored version it's the same but without the XOR over it.
Then I upgraded manually to DHO800_DHO900(Software)Updatev00.01.02.00.02 and when I tried to run my test program with this version of the libscope-auklet.so I've got no key back.
When I have straced my program I get the following failed accesses:
1566 openat(AT_FDCWD, "/rigol/data/BND.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/BW7T10.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/EMBD.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/COMP.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
When I've disassembled the new libscope-auklet.so I haven't found any 'RKey.data' string .. only 'Key.data'
WTF?
-
I'm really confused now.
I've upgraded my scope first via internet to version 1.2 and that has created a RKey.data. When compared to FRAM stored version it's the same but without the XOR over it.
Then I upgraded manually to DHO800_DHO900(Software)Updatev00.01.02.00.02 and when I tried to run my test program with this version of the libscope-auklet.so I've got no key back.
When I have straced my program I get the following failed accesses:
1566 openat(AT_FDCWD, "/rigol/data/BND.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/BW7T10.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/EMBD.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/COMP.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
When I've disassembled the new libscope-auklet.so I haven't found any 'RKey.data' string .. only 'Key.data'
WTF?
RKey.data is there for sure. Are you looking at the correct .so file?
Note this function says "Gen NEW KEY". I think it's Rigol just blocking all the generated option lics simply by installing this new FW. We hacked it, they blocked it.
attached
-
Rigol's reponse to "all you crackers". ;)
Heh, well, I won’t have a DHO814 with options that expand the bandwidth and memory depth, but a DHO914, which without any options already has a 125 MHz bandwidth and a memory depth of 50 megapoints :))
When I've disassembled the new libscope-auklet.so I haven't found any 'RKey.data' string .. only 'Key.data'
WTF?
This line is definitely in the new library :)
[attach=1]
-
I'm really confused now.
I've upgraded my scope first via internet to version 1.2 and that has created a RKey.data. When compared to FRAM stored version it's the same but without the XOR over it.
Then I upgraded manually to DHO800_DHO900(Software)Updatev00.01.02.00.02 and when I tried to run my test program with this version of the libscope-auklet.so I've got no key back.
When I have straced my program I get the following failed accesses:
1566 openat(AT_FDCWD, "/rigol/data/BND.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/BW7T10.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/EMBD.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/COMP.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
I don’t quite understand the essence of these errors, but if this is an attempt to open these files, then there will be errors, because updating to version 00.01.02.00.02 deletes all .lic files as they are no longer valid due to the changed option generation algorithm.
-
if you want the "meaningless clock"
SCPI :DIS:CLOC 1 cammand activates screen clock directly under LXI logo bottom right of screen.
Cool! My oscilloscope receives the date and time from the network, so I can get by with one command :)
-
For the effort needed to hack in more USB ports,
just get a small USB "hub" that has a 12" USB cord on it, plug it in and then attach the hubby to rear of scope.
But that's just me. ;)
As for the USB-C in rear, in the teardown does it look like data pins weave into the RK3399? Or is thet USB-C soley just power?
If the read C data pins can be used, then it is possible to make a power & data-pins combiner using 3 USB-C female connectors, this way you can do feedthrough for the power wart and for a serial data line.
I did read through the RK3399 datasheet PDF. There are several ways to boot it, one being a USB OTG method, where you can actually boot something like ubuntu. I just not sure how USB OTG works.
Again, I was saying "...USB ports on these to plug devices into without going through a hub
FYI; I think those "data pins" traces you're referring to are the USB-B data traces. I haven't beeped it out yet, tho'.
The USB-C port is for power input only, or at least what I've found so far. My C dock/hub device will pass power, but peripherals don't connect to the Rigol, like they do on the A/host port up front. I've tested this dock with 3 other tablet/notebook devices, and it works as intended.
Hmmm. Well, AFAIK; USB OTG is basically USB where the host(phone, tablet, etc) has the capability to power the devices that are plugged into it. It takes software and hardware to implement it, I'm pretty sure. -And it's doubtful Rigol would've spent the time/effort. **
Also, a lot of these boot methods require a physical button to be pressed prior to boot time. Hey, maybe that's what the empty tact switch pads are for?(shown in the teardown photos)
So you haven't booted it from a USB stick then?
** Given the fact that there's a lot of other features the RK3399 have, that they clearly ignored.
-
I don’t quite understand the essence of these errors, but if this is an attempt to open these files, then there will be errors, because updating to version 00.01.02.00.02 deletes all .lic files as they are no longer valid due to the changed option generation algorithm.
I am wondering if the new RKey.data method parks a unique key onto each system, perhaps used by Rigol later in some way to gen new lic files? Now each device becomes unique in some way, hence my key won't gen lics for your device, as we have done before with a common tool. However, knowing the method can still yield good lic files, but the key used for each system is perhaps different.
There's perhaps a test to find out.
Maybe take v01.02.00.02 GEL, unpack the files into a "orig" folder, install the GEL to the device, then use the device script to re-GEL a backup, and then find the file diffs between the two. This should show us what the new FW did during it's install and 1st boot?
Then perhaps take md5 of all the files from this 1st backup. Then restore something like v01.02.00.00 to the device, then update device with v01.02.00.02 again, grab a GEL backup, and repeat the compare steps again.
Now you have two lists of md5, one from backup #1 and one from backup #2.
Now find all files that have different md5. Then analuze that to determine if you expect such file to have same or different md5.
This method might lead to knowing of this new key method creates unique key during the FW install/boot, or not. Might also help find more info about the key itself.
The 2nd method which seems perhaps doable, mod the APK and re-sign it so it runs as shared user "system". Then we can muck around with functions and what-not, bypass the new key methos, etc.
-
Here is the DHO804 FW1.14 image (Thanks to @hubertyoung) with the DHO924 vendor file preloaded. Extract using 7zip then flash using HDD Raw Copy Tool (compressed image). If there is an vertical offset then use self cal or extended self cal.
https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8 (https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8)
and
Here is the DHO804 FW1.14 image (Thanks to @hubertyoung) with the DHO924 vendor file preloaded. Extract using 7zip then flash using HDD Raw Copy Tool (compressed image). If there is an vertical offset then use self cal or extended self cal.
https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8 (https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8)
Hi,
- This is what I've done:
1. Run the Win32 Disk Imager
2. Backup the SD
3. Flash the SD with the image from the link
4. Run the claibartation (offset gone) - device identifies as DHO804
5. Connect the scope to ethernet
6 Run adb:
6.1 adb devices
6.2 adb connect 192.xxx.x.xxx:55555
6.3 "adb pull /rigol/data/vendor.bin"
6.4 backup the generated vendor bin file from the adb folder to a new location
6.5 copy in the adb folder the DHO924 image
6.6 "adb push vendor.bin /rigol/data"
Is this procedure usable with firmware 00.01.02?
-
Again, I was saying "...USB ports on these to plug devices into without going through a hub
FYI; I think those "data pins" traces you're referring to are the USB-B data traces. I haven't beeped it out yet, tho'.
The USB-C port is for power input only, or at least what I've found so far. My C dock/hub device will pass power, but peripherals don't connect to the Rigol, like they do on the A/host port up front. I've tested this dock with 3 other tablet/notebook devices, and it works as intended.
Hmmm. Well, AFAIK; USB OTG is basically USB where the host(phone, tablet, etc) has the capability to power the devices that are plugged into it. It takes software and hardware to implement it, I'm pretty sure. -And it's doubtful Rigol would've spent the time/effort. **
Also, a lot of these boot methods require a physical button to be pressed prior to boot time. Hey, maybe that's what the empty tact switch pads are for?(shown in the teardown photos)
So you haven't booted it from a USB stick then?
** Given the fact that there's a lot of other features the RK3399 have, that they clearly ignored.
Right, not every pin/feature of the RK3399 is used or implemented. Common practice.
I assume Rigol has to flash the boot-rom some how, there has to be a method.
The FW Rigol puts out for download is not even the android OS, it's just the scope app stuff.
It's probably easier to just make a USB-A nano that has a Logitech key/mouse, BT, wifi, and a passthrough 1-port USB "hub" for a 128GB mem stick, so you can have all that in one front USB-A port. ;)
As for data transfer, the droid has nc in toybox, so you could essentially stream data in bi-directional fashion over wifi between the DHO and another device.
Another option is to try and find a USB hub that uses wifi between a USB desk hub and the DHO. Essentially USB<--wifi-->USB config. Essentially a double ended USB/wifi mux.
I could be wrong, but I am guessing there's not that many people who want their DHO800/900 to have 6 v3.1 USB ports.
-
Is this procedure usable with firmware 00.01.02?
I suspect that's all old method.
Read through this thread.
Also, the 01.02 has several rev's already, 00.01.02.00.00 .01 and .02
-
Dear friends, could you please provide the list or close-up photos of the missing devices of 814? Thank you!
-
I am wondering if the new RKey.data method parks a unique key onto each system, perhaps used by Rigol later in some way to gen new lic files? Now each device becomes unique in some way, hence my key won't gen lics for your device, as we have done before with a common tool. However, knowing the method can still yield good lic files, but the key used for each system is perhaps different.
The keys were always different, which is why it was necessary to generate options for each device individually :)
The 2nd method which seems perhaps doable, mod the APK and re-sign it so it runs as shared user "system". Then we can muck around with functions and what-not, bypass the new key methos, etc.
It would be great to pull off such a trick! This would open up enormous possibilities for modifying the oscilloscope application. I thought about this myself, but although I am a programmer, I only use C/C++ for microcontrollers, and Android with its applications is a dark forest for me. I can’t even imagine how realistic it is to do this and how much work will be required.
-
I'm really confused now.
I've upgraded my scope first via internet to version 1.2 and that has created a RKey.data. When compared to FRAM stored version it's the same but without the XOR over it.
Then I upgraded manually to DHO800_DHO900(Software)Updatev00.01.02.00.02 and when I tried to run my test program with this version of the libscope-auklet.so I've got no key back.
When I have straced my program I get the following failed accesses:
1566 openat(AT_FDCWD, "/rigol/data/BND.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/BW7T10.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/EMBD.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/COMP.lic", O_RDWR) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
1566 openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
When I've disassembled the new libscope-auklet.so I haven't found any 'RKey.data' string .. only 'Key.data'
WTF?
Darn ... I have "updated" to an old backup instead of version 1.2.2 because all of the update files have to be called DHO800_DHO900_Update.GEL with no version in the file
and I used one from the wrong directory.
Now my scope is in a weird state I can ping it, I can see the 55555 port open with nmap, the web interface is working but I can't adb connect to it anymore. So downgrading doesn't go so smooth.
I guess I'll have to open it now and manually restore the sdcard.
The above strace is when I run my test program linked to a particular libscope-auklet
set_RString( &z, "License" );
CApiLicense_CApiLicense( &AL, z, 0x24 );
CApiLicense_init( &AL );
set_RString( &a, "key" );
set_RString( &b, "seed" );
CApiLicense_getLicenseKey( &AL, &a, &b );
printf( "key: %s\n", get_RString( &a, NULL ) );
printf( "seed: %s\n", get_RString( &b, NULL ) );
and since I was using the one from version 1.0 it was just looking for Key.data which has been previously erased by version 1.2
Now again I can't do anything until I get home >:(
-
The ssh server on your scope doesn't accept passwords. If you want ssh access do the following:
mount -o rw,remount /system
cat > /system/etc/ssh/authorized_keys
and paste your .ssh/id_rsa.pub then press Ctrl-D
cat > /system/etc/profile
export ANDROID_DATA=/data
export ANDROID_ROOT=/system
# also your favorite aliases, then press Ctrl-D
you can also vi /system/etc/ssh/sshd_config if you need to change any other settings like the ssh port
mount -o ro,remount /system
At next boot or when init.rigol.rc is executed it will
copy /system/etc/ssh/authorized_keys /data/ssh/authorized_keys
service daemonssh /system/bin/start-sshThe you can ssh without password on port 22.
-
Can someone please shed some light on which Sparrow.apk is the one currently running and where did it came from?
I have 2 versions residing on my scope:
rk3399_rigol:/rigol # ll /rigol/app/Sparrow.apk /system/app/Sparrow/Sparrow.apk
-rwxrwxrwx 1 root root 36898060 2023-07-21 08:21 /rigol/app/Sparrow.apk
-rw-r--r-- 1 root root 37148630 2023-08-23 03:40 /system/app/Sparrow/Sparrow.apkI also have 3 GEL packages containing Sparrow.apk:
GEL.v1.1 36816140 Sparrow.apk
GEL.v1.2 36840716 Sparrow.apk
GEL.v1.2.2 36840716 Sparrow.apk(same file in both 1.2 and 1.2.2)
None of the apk sizes match!
The /rigol/shell/do_update.sh and do_extract.sh scripts update the one in the /rigol/app directory
Are the apk modified when they are installed?
$ scp root@10.0.0.227:/rigol/app/Sparrow.apk .
$ unzip Sparrow.apk
$ strings lib/arm64-v8a/libscope-auklet.so | grep -i key.dat
Key.datasame happens with the /system/app/Sparrow/Sparrow.apk they all seem to use an old version of the libscope-auklet.so
But when I extract it directly from the GEL file:
$ tar -zxvf DHO800_DHO900_Update.GEL.v1.2.2.tar.gz
$ unzip app/Sparrow.apk
$ strings lib/arm64-v8a/libscope-auklet.so | grep -i key.dat
RKey.data
-
So, Android is an odd type of mini beast.
With this level of droid there's actually 3 places where APK's can live, and depending on where they live the permissions get assigned or inherited different ways.
3 locations
/data/app/
/system/app/
/system/priv-app/
The update GEL (GEL = PK file) script on my DHO appears to unpack the GEL into a tmp folder, and from there the install and copies are done.
You can't really rely of hash or filesize of all the Sparrow APK's, a simple change made to the signing cert/key can make all that recon look different. You can however extract out the files of the APK's and then compare files.
So, I went looking around with tools am and pm, it appears all 3 rigol APK's (scope, launcher, webcontrol) all live in /data/app/
"scope" runs as package "com.rigol.scope"
My DHO has orig 00.01.02.00.00 FW. I have not changed anything on FW side.
It appears loading the scope app does not even happen in the start script, the am command to load .MainActivity has been commented out.
There's also some bloatware still active on the device, I post about that in a new post.
Do the APK's in the GEL get unpacked and perhaps manipulated? I don't think they do. Multiple APK's of same name on the filesystem are likely remnants.
Droid is a pita when it comes to naming stuff. Your have "APK" file name, but inside that you have the actual package name.
Why on my DHO I have Rigol package dir names with "-1", not sure.
These are the running Rigol apps on my DHO
adb shell cmd package list packages -f
package:/data/app/com.rigol.scope-1/base.apk=com.rigol.scope
package:/data/app/com.rigol.webcontrol-1/base.apk=com.rigol.webcontrol
package:/data/app/com.rigol.launcher-1/base.apk=com.rigol.launcher
-
I am wondering if the new RKey.data method parks a unique key onto each system, perhaps used by Rigol later in some way to gen new lic files? Now each device becomes unique in some way, hence my key won't gen lics for your device, as we have done before with a common tool. However, knowing the method can still yield good lic files, but the key used for each system is perhaps different.
The keys were always different, which is why it was necessary to generate options for each device individually :)
The 2nd method which seems perhaps doable, mod the APK and re-sign it so it runs as shared user "system". Then we can muck around with functions and what-not, bypass the new key methos, etc.
It would be great to pull off such a trick! This would open up enormous possibilities for modifying the oscilloscope application. I thought about this myself, but although I am a programmer, I only use C/C++ for microcontrollers, and Android with its applications is a dark forest for me. I can’t even imagine how realistic it is to do this and how much work will be required.
Ahhh, that's right, now I recall. We were just pulling out Key.data into the ext tool, but each Key.data was diffent.
But noted here, we have access to droid via root. We can turn on "allow install of apps from unknown sources" in Security. I suspect this means we can install anything, which means mod the Rigol APK's, rebuild them, install.
-
DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.
The default build only has the Android Demo package disabled, but we can disable more.
Disabling does appear to be boot persistent (can likely ditch printspooler) NOTE: package:com.android.captiveportallogin seems to be needed for wifi connection to work.
pm disable [package name]
com.android.wallpapercropper
com.android.proxyhandler
com.android.smspush
com.android.providers.blockednumber
com.android.bluetooth
com.android.wallpaperpicker
package:com.android.captiveportallogin
The full list of packages installed
package:com.android.cts.priv.ctsshim
package:com.android.providers.media
package:com.rigol.webcontrol
package:com.android.wallpapercropper
package:com.rigol.launcher
package:com.android.externalstorage
package:com.android.htmlviewer
package:com.android.providers.downloads
package:com.android.defcontainer
package:com.android.pacprocessor
package:com.android.certinstaller
package:android.rockchip.update.service
package:android
package:com.android.mtp
package:com.android.backupconfirm
package:com.android.provision
package:com.android.statementservice
package:com.android.providers.setting:com.android.sharedstoragebackup
package:com.android.printspooler
package:com.android.dreams.basic
package:com.android.webview
package:com.android.rk
package:com.android.inputdevices
package:com.android.retaildemo
package:android.ext.shared
package:com.android.keychain
package:com.android.printservice.recommendation
package:android.ext.services
package:com.android.packageinstaller
package:com.svox.pico
package:com.android.proxyhandler
package:com.android.managedprovisioning
package:com.android.smspush
package:com.android.storagemanager
package:com.android.settings
package:acr.browser.barebones
package:com.android.cts.ctsshim
package:com.android.shell
package:com.android.wallpaperbackup
package:com.android.providers.blockednumber
package:com.android.providers.userdictionary
package:com.android.location.fused
package:com.android.systemui
package:com.ampak.rftesttool
package:com.android.bluetooth
package:com.android.wallpaperpicker
package:com.android.captiveportallogin
package:com.rigol.scope
-
DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.
Does that reduce the boot time noticeably?
-
DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.
Does that reduce the boot time noticeably?
Not that I noticed. On my DHO there are several sleep commands in the start-rigol-app script, which seems to account for almost 50% of the boot time. I think Rigol has to slow the sequence for the various hardware components to be 100% available for next piece.
The bloat packages don't use much if any cpu, but they do take up ram.
My rule is, if not needed then it's gone.
-
If that's the case, then I suspect there are little to no buyers of option lics, so to kill off the user generated lics they just modify the lic process in a new FW.
I would like to remind you that there are still no purchasable options for this series.
If you think about it a little, apparent contradictions resolve themselves.
Due to the way they rolled out the 800/900, their intent was most likely to have pay-for options.
Otherwise it would have been very easy to remove the functions that import option strings, and remove functions that read lic files.
-
On my DHO there are several sleep commands in the start-rigol-app script, which seems to account for almost 50% of the boot time. I think Rigol has to slow the sequence for the various hardware components to be 100% available for next piece.
This sounds like there's potential for improvement. If we can identify what components it has to wait for, then probably the sleeps can be rewritten into loops (with small delays between iterations) with polling the respective parts to check if they're ready.
Or, just reduce the sleeps until the scope begins to fail to boot properly :)
-
None of the apk sizes match!
I have figured out what is happening: the upgrade fails no matter what file I supply to the scope.
If you do the upgrade from the interface everything seems to work, no errors, scope reboots and comes back with the previous version.
If I do it manually:
rk3399_rigol:/rigol # shell/do_update.sh DHO800_DHO900_Update.GEL 1
still no error message but when I examine /data/logs/tools_log/gel_update_logs.txt I get
pm install -r /mnt/tmp/app/Webcontrol.apk
/mnt/tmp/shell/do_extract.sh: line 157: 1909 Aborted pm install -r $UPDAT
pm install -r /mnt/tmp/app/Launcher.apk
/mnt/tmp/shell/do_extract.sh: line 165: 1915 Aborted pm install -r $UPDAT
pm install -r /mnt/tmp/app/Sparrow.apk
/mnt/tmp/shell/do_extract.sh: line 195: 1923 Aborted pm install -r $UPDAT
cp: pmapService: Text file busy
Upgradation failedThat is their upgrade script that fails I haven't done anything.
When the upgrade fails for any reason the old applications are restored.
I have tried to kill pmapService as they do in their script. That didn't make any difference.
Then I've killed all the rigol processes:
system 1097 235 1757788 115484 SyS_epoll_ 7c14699b84 S com.rigol.launcher
system 1176 235 3716012 441924 futex_wait 7c1464acf0 S com.rigol.scope
system 1247 235 1593224 99152 SyS_epoll_ 7c14699b84 S com.rigol.launcher:Watchdog
system 1261 235 1625108 100360 SyS_epoll_ 7c14699b84 S com.rigol.webcontrolbut they come back with new PIDs.
Also when I try
rk3399_rigol:/rigol # pm uninstall com.rigol.launcher
AbortedI need to get to the bottom of which script launches the Rigol apps so I can edit it.
Editing /rigol/shell/start_rigol_app.sh had no effect it's probably copied somewhere else.
-
None of the apk sizes match!
I have figured out what is happening: the upgrade fails no matter what file I supply to the scope.
If you do the upgrade from the interface everything seems to work, no errors, scope reboots and comes back with the previous version.
If I do it manually:
rk3399_rigol:/rigol # shell/do_update.sh DHO800_DHO900_Update.GEL 1
still no error message but when I examine /data/logs/tools_log/gel_update_logs.txt I get
pm install -r /mnt/tmp/app/Webcontrol.apk
/mnt/tmp/shell/do_extract.sh: line 157: 1909 Aborted pm install -r $UPDAT
pm install -r /mnt/tmp/app/Launcher.apk
/mnt/tmp/shell/do_extract.sh: line 165: 1915 Aborted pm install -r $UPDAT
pm install -r /mnt/tmp/app/Sparrow.apk
/mnt/tmp/shell/do_extract.sh: line 195: 1923 Aborted pm install -r $UPDAT
cp: pmapService: Text file busy
Upgradation failedThat is their upgrade script that fails I haven't done anything.
When the upgrade fails for any reason the old applications are restored.
I have tried to kill pmapService as they do in their script. That didn't made any difference.
Then I've killed all the rigol processes:
system 1097 235 1757788 115484 SyS_epoll_ 7c14699b84 S com.rigol.launcher
system 1176 235 3716012 441924 futex_wait 7c1464acf0 S com.rigol.scope
system 1247 235 1593224 99152 SyS_epoll_ 7c14699b84 S com.rigol.launcher:Watchdog
system 1261 235 1625108 100360 SyS_epoll_ 7c14699b84 S com.rigol.webcontrolbut they come back with new PIDs.
Also when I try
rk3399_rigol:/rigol # pm uninstall com.rigol.launcher
AbortedI need to get to the bottom of which script launches the Rigol apps so I can edit it.
Editing /rigol/shell/start_rigol_app.sh had no effect it's probably copied somewhere else.
It seems Android loads up the Rigol APK packages. Maybe in the past the start script did it, but I see a am start command commented out.
The start script appears to sequence peripherals like touchscreen, wifi driver if you want, screen brightness property, TZ, etc. It also increments a boot counter.
PID's will be assigned, so they different each boot.
How are you on the droid? Just ADB?
adb connect
adb shell
su -
now re-run the update script, it should run a-ok.
What's those lines in that script? Was your copy trncated, or does it really say "$UPDAT" ?
And "upgradation" is a real word, but most just say "upgrade". :-DD
-
It seems Android loads up the Rigol APK packages. Maybe in the past the start script did it, but I see a am start command commented out.
now re-run the update script, it should run a-ok.
What's those lines in that script? Was your copy trncated, or does it really say "$UPDAT" ?
And "upgradation" is a real word, but most just say "upgrade". :-DD
That's the chinese "upgradation" which is not working !!!
Yes the line was longer I've truncated it when I've paste it:
... Aborted pm install -r $UPDATE_DSO > /dev/null 2>&1
I'm on ssh as root (better than adb). I've tried it via adb root too ... same failure.
You are right, Android starts those apps. How do I disable them because the update script still fails. I'm stuck.
-
It seems Android loads up the Rigol APK packages. Maybe in the past the start script did it, but I see a am start command commented out.
now re-run the update script, it should run a-ok.
What's those lines in that script? Was your copy trncated, or does it really say "$UPDAT" ?
And "upgradation" is a real word, but most just say "upgrade". :-DD
That's the chinese "upgradation" which is not working !!!
Yes the line was longer I've truncated it when I've paste it:
... Aborted pm install -r $UPDATE_DSO > /dev/null 2>&1
I'm on ssh as root (better than adb). I've tried it via adb root too ... same failure.
You are right, Android starts those apps. How do I disable them because the update script still fails. I'm stuck.
Well, I mentioned it before. Why they dump stdout and err to dev/null is nuts.
edit that and just replace /dev/null with "/rigol/data/pm_logs.txt" so you can go back and see what the err is.
When you in on ssh, what do you get from
echo $ANDROID_ROOT
echo $ANDROID_DATA
If blank then you need to export them before doing things in ssh.
export ANDROID_ROOT=/system ANDROID_APP=/data
pm disable [package name]
that will disable them, just reboot. Then enable them after.
I showed pm a few posts back.
-
export ANDROID_SYSTEM=/system ANDROID_APP=/data
I already have those in my /system/etc/profile
export ANDROID_DATA=/data
export ANDROID_ROOT=/system
(it's _ROOT not _SYSTEM)
together with my favorite aliases
pm disable [package name]
that will disable them, just reboot. Then enable them after.
That did the trick pm disable com.rigol.scope stopped it no need to reboot.
Now the upgrade shows no error but I end up with the same old Sparrow.apk
# ll /mnt/tmp/app/Sparrow.apk
36840716 2024-01-03 20:11 /mnt/tmp/app/Sparrow.apk
# pm install -r /mnt/tmp/app/Sparrow.apk
Success
# ll /rigol/app/Sparrow.apk
36898060 2024-02-02 05:25 /rigol/app/Sparrow.apk
# ll /system/app/Sparrow/Sparrow.apk
37148630 2023-08-23 11:40 /system/app/Sparrow/Sparrow.apk
If I just copy the APK by hand (after I stop the service) instead of pm install would that break anything?
-
DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.
The default build only has the Android Demo package disabled, but we can disable more.
Disabling does appear to be boot persistent (can likely ditch printspooler) NOTE: proxyhandler seems to be needed for wifi connection to work.
I'm all for debloating to speed up the boot time. Drives me nuts! |O waiting for a piece of test gear to boot.
But, can you ditch the printspooler service and still print? I think I saw someone printing from his scope last week.
-
export ANDROID_SYSTEM=/system ANDROID_APP=/data
I already have those in my /system/etc/profile
export ANDROID_DATA=/data
export ANDROID_ROOT=/system
(it's _ROOT not _SYSTEM)
together with my favorite aliases
pm disable [package name]
that will disable them, just reboot. Then enable them after.
That did the trick pm disable com.rigol.scope stopped it no need to reboot.
Now the upgrade shows no error but I end up with the same old Sparrow.apk
# ll /mnt/tmp/app/Sparrow.apk
36840716 2024-01-03 20:11 /mnt/tmp/app/Sparrow.apk
# pm install -r /mnt/tmp/app/Sparrow.apk
Success
# ll /rigol/app/Sparrow.apk
36898060 2024-02-02 05:25 /rigol/app/Sparrow.apk
# ll /system/app/Sparrow/Sparrow.apk
37148630 2023-08-23 11:40 /system/app/Sparrow/Sparrow.apk
If I just copy the APK by hand (after I stop the service) instead of pm install would that break anything?
Yes. My mistake. I fixed it in post.
MD5 all the Sparrow.APK's, match them back to GEL zips.
But hint, as related to pm installs, keep an eye on base.apk
I only find these Rigol enabled packages in this location.
adb shell cmd package list packages -f
package:/data/app/com.rigol.scope-1/base.apk=com.rigol.scope
package:/data/app/com.rigol.webcontrol-1/base.apk=com.rigol.webcontrol
package:/data/app/com.rigol.launcher-1/base.apk=com.rigol.launcher
-
DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.
The default build only has the Android Demo package disabled, but we can disable more.
Disabling does appear to be boot persistent (can likely ditch printspooler) NOTE: proxyhandler seems to be needed for wifi connection to work.
I'm all for debloating to speed up the boot time. Drives me nuts! |O waiting for a piece of test gear to boot.
But, can you ditch the printspooler service and still print? I think I saw someone printing from his scope last week.
Correct.
If you need to print then keep the spooler.
If you need wifi then keep that proxy item.
Otherwise disable.
-
I have made a backup of my scope before any upgrade. My scope then was at firmware version 1.1 and these are the backup files:
37148630 Jan 31 13:19 /system/app/Sparrow/Sparrow.apk
36898060 Jan 31 13:25 /rigol/app/Sparrow.apk
9739f00ca56a2fa07816c97894c08591 /system/app/Sparrow/Sparrow.apk
95fe9524be73bd7fd14384be474eff0e /rigol/app/Sparrow.apk
Today after the scope has been upgraded the about screen says version 1.2 but the above files are the same and md5sum is still as recorded.
Where is the actual update stored on this scope?
-
I have made a backup of my scope before any upgrade. My scope then was at firmware version 1.1 and these are the backup files:
37148630 Jan 31 13:19 /system/app/Sparrow/Sparrow.apk
36898060 Jan 31 13:25 /rigol/app/Sparrow.apk
9739f00ca56a2fa07816c97894c08591 /system/app/Sparrow/Sparrow.apk
95fe9524be73bd7fd14384be474eff0e /rigol/app/Sparrow.apk
Today after the scope has been upgraded the about screen says version 1.2 but the above files are the same and md5sum is still as recorded.
Where is the actual update stored on this scope?
Actual update appears to be copied out from GEL into tmp dir for install.
Can you MD5 the Sparrow APK's from the GEL files. Do any Sparrow.apk on droid filesystem match those in your GEL files?
Also noted, FW1 vs FW2 might have exact same Sparrow.apk, but the GEL archive has many other files in it that may have changed. So just because FW version changed, that alone does not mean that the Sparrow.apk has changed.
-
DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.
The default build only has the Android Demo package disabled, but we can disable more.
Disabling does appear to be boot persistent (can likely ditch printspooler) NOTE: proxyhandler seems to be needed for wifi connection to work.
I'm all for debloating to speed up the boot time. Drives me nuts! |O waiting for a piece of test gear to boot.
But, can you ditch the printspooler service and still print? I think I saw someone printing from his scope last week.
In the start script, they sleep 10 after booting FPGA, guessing it needs some time to boot, and needs to be up before all the gpio driver stuff happens.
After the touchscreen driver is loaded (kinda last bit of loading devices/drivers in script) I have to do a sleep 15 before sending scpi commands. It appears the rigol packages takes some time to fully load up. If you send scpi too soon they either don't apply or the scope app crashes.
My boot time testing results:
45sec for scope to boot where it enters Run state (no screen yet)
+4sec (49) to have scope screen w/ touch
+2sec (51) for the scpi commands to take effect
So, I believe initial test/teardown boot tests were around 58sec boot. Now I have it to 49sec. 9sec faster.
Noted, this is with short list of packages disabled, and I also have in my start script an added line to insmod the 8188eu.ko wifi driver.
-
Can you MD5 the Sparrow APK's from the GEL files. Do any Sparrow.apk on droid filesystem match those in your GEL files?
GEL v1.1: 5b37a8772770865d3f80b9440d665005 Sparrow.apk size 36816140
GEL v1.2 and GEL v1.2.2: 65ad4627e45b8de6ea3fc5aac95943d6 Sparrow.apk size 36840716
Can anyone please check the MD5 sums on their /system/app/Sparrow/Sparrow.apk and /rigol/app/Sparrow.apk
I'm definitely on new firmware because my Key.data has been replaced by RKey.data. /mnt/bak and /mnt/tmp are erased at every boot so the question is still open
where is the actual code for com.rigol.scope stored?
Also when you are using the SCPI Panel control and send a string like ":SYST:OPT:INST DHO800-BW7T15@3EFC1...." do you get any reply from the scope
(like invalid license) because I'm not getting any reply back.
-
Can you MD5 the Sparrow APK's from the GEL files. Do any Sparrow.apk on droid filesystem match those in your GEL files?
GEL v1.1: 5b37a8772770865d3f80b9440d665005 Sparrow.apk size 36816140
GEL v1.2 and GEL v1.2.2: 65ad4627e45b8de6ea3fc5aac95943d6 Sparrow.apk size 36840716
Can anyone please check the MD5 sums on their /system/app/Sparrow/Sparrow.apk and /rigol/app/Sparrow.apk
I'm definitely on new firmware because my Key.data has been replaced by RKey.data. /mnt/bak and /mnt/tmp are erased at every boot so the question is still open
where is the actual code for com.rigol.scope stored?
Also when you are using the SCPI Panel control and send a string like ":SYST:OPT:INST DHO800-BW7T15@3EFC1...." do you get any reply from the scope
(like invalid license) because I'm not getting any reply back.
adb shell cmd package list packages -f
package:/data/app/com.rigol.scope-1/base.apk=com.rigol.scope
package:/data/app/com.rigol.webcontrol-1/base.apk=com.rigol.webcontrol
package:/data/app/com.rigol.launcher-1/base.apk=com.rigol.launcher
-
adb shell cmd package list packages -f
package:/data/app/com.rigol.scope-1/base.apk=com.rigol.scope
Finally! So all updates go to /data
# ll /data/app/com.rigol.scope-1/base.apk
36840716 2024-02-02 06:54 /data/app/com.rigol.scope-1/base.apkWhich is the same file as Sparrow.apk from GEL v1.2.2 - mystery solved
-
adb shell cmd package list packages -f
package:/data/app/com.rigol.scope-1/base.apk=com.rigol.scope
Finally! So all updates go to /data
# ll /data/app/com.rigol.scope-1/base.apk
36840716 2024-02-02 06:54 /data/app/com.rigol.scope-1/base.apkWhich is the same file as Sparrow.apk from GEL v1.2.2 - mystery solved
Not sure it's an stored "update" in that sense.
It's likely the result from the droid processing via the pm install.
It's been awhile since I did dev work for droid OS, but I believe pm relies heavily on the apk manifest to do the actual install.
Much of the Rigol coding I have seen (from just this 800/900 FW stuff) seems to indicate that they are using old levels of SDK stuff. I thought I saw some references to Eclipse too.
Using the shared uid of "system" along with long list of perms definitions, and parking the apk in /data , is an old way of doing things.
My hedgehog droid studio makes many call-outs to deprecated coding, even for the target level of droid, and I only opened Sparrow.apk, didn't even look at the other stuff.
-
Some of what I saw in the de-compiled `Sparrow.apk` UI code looked like Compose (relatively new) vs XML (older). I would expect there are different teams working on different parts of the scope and they might have different tooling.
Additionally, they are running Android 7 which is, as we say here in the north east, wicked old.
-
Some of what I saw in the de-compiled `Sparrow.apk` UI code looked like Compose (relatively new) vs XML (older). I would expect there are different teams working on different parts of the scope and they might have different tooling.
Additionally, they are running Android 7 which is, as we say here in the north east, wicked old.
Smali and Kotlin too.
I see a lot of XML throughout.
Pics just from Sparrow
Rigol is building on v10 (API 29.Q), but targets v7 (API 25.N_MR1) <-- 9 revs behind the latest available.
Why not run a newer droid and code in a better API? My guess is, leave the dev platform alone as long as it can make the code for the products.
-
Also when you are using the SCPI Panel control and send a string like ":SYST:OPT:INST DHO800-BW7T15@3EFC1...." do you get any reply from the scope
(like invalid license) because I'm not getting any reply back.
Can someone try this and let me know?
I've noticed a change in CApiLicense::verifyOption function for the newer firmware: it now expects 56 bytes instead of 48 as previously.
Then they call RString::remove to remove 8 of these bytes before calling AES_decrypt. The AES_set_decrypt_key seems to be
identical as before. The encrypted bytes must be the same (48) because the AES only does 16 bytes at a time.
So there is definitely a format change for the option strings.
-
Also when you are using the SCPI Panel control and send a string like ":SYST:OPT:INST DHO800-BW7T15@3EFC1...." do you get any reply from the scope
(like invalid license) because I'm not getting any reply back.
Can someone try this and let me know?
I've noticed a change in CApiLicense::verifyOption function for the newer firmware: it now expects 56 bytes instead of 48 as previously.
Then they call RString::remove to remove 8 of these bytes before calling AES_decrypt. The AES_set_decrypt_key seems to be
identical as before. The encrypted bytes must be the same (48) because the AES only does 16 bytes at a time.
So there is definitely a format change for the option strings.
Which 8 bytes get removed?
I might be wrong, but I think the task at-hand is to retrieve the value obtained from AES_set_decrypt_key
-
Which 8 bytes get removed?
I might be wrong, but I think the task at-hand is to retrieve the value obtained from AES_set_decrypt_key
We already know that. The AES key is the decryption of RKey.data starting at offset 16 (what comes after "brainpoolP256r1;")
The problem is that the option string has changed, it now has 16 extra characters (8 extra bytes)
I would like to experiment with various option strings (using the new key) but whatever SCPI option command I send to the scope I get no reply.
Is this the normal way when the option license doesn't match or do I still have a bad update?
If you're on firmware v1.2 it's not that hard to put a ":SYST:OPT:INST DHO800-RLU@0000000000000000000000000000000000000" string in your web
interface and let me know the output (if any)
-
I'm sort of a casual Linux user with rudimentary skills. Does upgrading a Rigol DHO804 to a higher level require upper echelon computer hacking skills, or can us children of a lesser god accomplish it without trashing a $400+ initial investment?
-
I'm sort of a casual Linux user with rudimentary skills. Does upgrading a Rigol DHO804 to a higher level require upper echelon computer hacking skills, or can us children of a lesser god accomplish it without trashing a $400+ initial investment?
Provided you haven't upgraded to the latest firmware, you should have a fairly easy time following the guide in this post. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5194689/#msg5194689) If you upgraded, you'll need to learn how to downgrade to do the hacks.
Good luck.
-
I'm sort of a casual Linux user with rudimentary skills. Does upgrading a Rigol DHO804 to a higher level require upper echelon computer hacking skills
No.
or can us children of a lesser god accomplish it without trashing a $400+ initial investment?
Yes.
-
Additionally, they are running Android 7 which is, as we say here in the north east, wicked old.
Rigol is building on v10 (API 29.Q), but targets v7 (API 25.N_MR1) <-- 9 revs behind the latest available.
So speaking of Android 7: Any of you Android peeps working on running Android 11 or 12 on the DHO's that some of the SBC vendors are shipping with their RK3399 boards?
Maybe it's me, but it sure seems like the newer versions are so much faster at booting. --actually, pretty much everything.
-
or can us children of a lesser god accomplish it without trashing a $400+ initial investment?
Yes.
Remember: There's two ways to do it. One is easy - just change the "vendor.bin" file to a higher model (even a 900 series).
adb connect 192.168.XX.YY:55555
adb push vendor.bin /rigol/data
The other way is more involved and needs you to generate license keys for extra features.
-
I would like to experiment with various option strings (using the new key) but whatever SCPI option command I send to the scope I get no reply.
Is this the normal way when the option license doesn't match or do I still have a bad update?
If you're on firmware v1.2 it's not that hard to put a ":SYST:OPT:INST DHO800-RLU@0000000000000000000000000000000000000" string in your web
interface and let me know the output (if any)
When sending an option to SCPI that is unknown to the oscilloscope (for example, sending :SYST:OPT:INST DHO900-BODE to a DHO814 oscilloscope), nothing happens at all. No notifications on the oscilloscope, no response to the SCPI terminal. When sending a known option, but with an incorrect key, a notification “License invalid” appears on the oscilloscope screen and a counter of remaining attempts, starting from 9. There is also no response in the SCPI terminal.
I no longer remember what happened when sending a known option with the correct key :) It seems that there was no response in SCPI either, and a notification like “Option installed” appeared on the oscilloscope screen. But I can't guarantee that I remember correctly :)
PS: After all attempts to add an option have been exhausted, new attempts to add an option will cause a "Trial option install failure" notification to appear on the screen. SCPI still does not receive any response.
-
When sending an option to SCPI that is unknown to the oscilloscope (for example, sending :SYST:OPT:INST DHO900-BODE to a DHO814 oscilloscope), nothing happens at all. No notifications on the oscilloscope, no response to the SCPI terminal. When sending a known option, but with an incorrect key, a notification “License invalid” appears on the oscilloscope screen and a counter of remaining attempts, starting from 9. There is also no response in the SCPI terminal.
Thanks for that Andy. My scope and computer were in different rooms and I've never noticed the messages. With all this testing I keep my scope half of the day on
and what I do to minimize wear is turn off all channels and also stop the acquisition. I also reduce the screen brightness a lot:
echo 20 > /sys/devices/platform/backlight/backlight/backlight/brightnessThe number of failed attempts are recorded in FRAM but they don't seem to survive a reboot. The entire structure stored in FRAM at address 0x100 handles licenses.
Your RKey.data is also stored there and right after the individual options:
000001B0 13 09 00 00 | ED F6 FF FF | 04 00 00 00 | FC FF FF FF | 82 7F 61 DD | 70 08 00 03
000001C8 15 09 00 00 | EB F6 FF FF | 04 00 00 00 | FC FF FF FF | 14 4F 66 AA | 70 08 00 02First word identifies the option Type (0x913 == RLU) followed by the complement word followed by length (4) then complemented
then the CRC32 of the following 4 bytes. The last '03' means that 3 attempts have been made for the RLU option.
All these attempts can easily be cleared just by setting the length of the entire structure to 0xB0 (and the following complement word) .. this saves rebooting the scope.
-
Boyz and girlz we're back in business!
https://github.com/zelea2/rigol_vendor_bin
It was as simple as appending 16 chars to the option strings. Now the .lic files came back to my /rigol/data directory.
There is no feedback from the SCPI interface even for the correct licenses, you only get a message on the scope's screen.
It took me a while to understand all the parameters I had to set (including a new COptInfo structure). Have a look at test.c if you're curious.
First I've tried to use scope's gdbserver; that failed, then I've used a static precompiled gdbserver for arm64 that didn't work either
In the end I've used a precompiled static gdb to trace my test program and understand the CApiLicense_verifyOption function.
That wasn't very pleasant because I had no GEF or any graphic interface and I had to type a lot of gdb commands.
Probably if I will spend some more time I will get the remote debugging working but I'll save that for the next license change ;)
-
Boyz and girlz we're back in business!
https://github.com/zelea2/rigol_vendor_bin
It was as simple as appending 16 chars to the option strings. Now the .lic files came back to my /rigol/data directory.
There is no feedback from the SCPI interface even for the correct licenses, you only get a message on the scope's screen.
It took me a while to understand all the parameters I had to set (including a new COptInfo structure). Have a look at test.c if you're curious.
First I've tried to use scope's gdbserver; that failed, then I've used a static precompiled gdbserver for arm64 that didn't work either
In the end I've used a precompiled static gdb to trace my test program and understand the CApiLicense_verifyOption function.
That wasn't very pleasant because I had no GEF or any graphic interface and I had to type a lot of gdb commands.
Probably if I will spend some more time I will get the remote debugging working but I'll save that for the next license change ;)
1) The lic file was written, but did that option become activated?
1a) Are these 16B (16 chars) random, or are the generated?
2) I already have options strings that work on my 804(as a 914). So, are you saying after I up the FW to 00.01.02.00.02 all I need to do is resend same option strings but pad the end of each string with random 16bytes (chars)?
3) If #2 will not work, can we still use the rigol-tools gen tool using RKey.data (rename to Key.data for the tool), and then add random 16bytes (16 chars) to the end of each string?
If none of that, then can you add clarity.
Thanks.
-
Got the RKey file mystery solved.
func LoadKeys() ([]uint8, error, []uint8) {
data, err := ioutil.ReadFile(Expand(keyFile))
if nil != err {
return nil, err, nil
}
for i, _ := range data {
data ^= byte(i & 0xFF);
}
dd := decodeDefaultXXTEA(data)
fmt.Printf("%s", dd)
i := bytes.Index(dd, []uint8(";"))
if -1 == i {
return nil, errors.New("key format error"), nil
}
return dd[i+1:], nil, dd
}
-
1) The lic file was written, but did that option become activated?
1a) Are these 16B (16 chars) random, or are the generated?
2) I already have options strings that work on my 804(as a 914). So, are you saying after I up the FW to 00.01.02.00.02 all I need to do is resend same option strings but pad the end of each string with random 16bytes (chars)?
3) If #2 will not work, can we still use the rigol-tools gen tool using RKey.data (rename to Key.data for the tool), and then add random 16bytes (16 chars) to the end of each string?
If none of that, then can you add clarity.
Yes they are activated.
AES keys in Key.data and RKey.data are different and they are both tied to your hardware. We don''t know how to generate them. The license options are decrypted with these keys
so you can't just append chars to an old option string. The keys are also encoded differently (the RKey one has an extra XOR with an incremented vector after it's XXTEA scrambled).
The new option strings have 16 extra characters at the end (the length is checked) and in the current firmware they are discarded but they might be used in the future.
-
I added the BND, AUTO and RLU options to my Rigol812 v.1.2.0.2 - everything works!
Thanks
-
1) The lic file was written, but did that option become activated?
1a) Are these 16B (16 chars) random, or are the generated?
2) I already have options strings that work on my 804(as a 914). So, are you saying after I up the FW to 00.01.02.00.02 all I need to do is resend same option strings but pad the end of each string with random 16bytes (chars)?
3) If #2 will not work, can we still use the rigol-tools gen tool using RKey.data (rename to Key.data for the tool), and then add random 16bytes (16 chars) to the end of each string?
If none of that, then can you add clarity.
Yes they are activated.
AES keys in Key.data and RKey.data are different and they are both tied to your hardware. We don''t know how to generate them. The license options are decrypted with these keys
so you can't just append chars to an old option string. The keys are also encoded differently (the RKey one has an extra XOR with an incremented vector after it's XXTEA scrambled).
The new option strings have 16 extra characters at the end (the length is checked) and in the current firmware they are discarded but they might be used in the future.
Right, new key "RKey.data", unique to each device.
So can we just pull that over to the rigol-tool generator as "Key.data", gen some options, then just add some random 16 chars to the end of each string before sending the options back in via SCPI?
The 16 chars are random?
-
So can we just pull that over to the rigol-tool generator as "Key.data", gen some options, then just add some random 16 chars to the end of each string before sending the options back in via SCPI?
The 16 chars are random?
Do not change the file name. My program behaves differently if it finds RKey.data instead of Key.data
The 16 chars at the end don't matter.
-
I did the unthinkable. Say hello to my DHO800, I call it the "quiet and deadly" 8)
I had a spare standard PC case fan (10 or 12mm ? not sure what's the measurement for these, just the normal case fan), I cut the plug off the end of it, soldered it to the original two pin connector, then ziptied it to the back.
Of course I added a metal grill to it so I don't put stuff in the blades. The CPU_CHIP runs at 48.7 ˚C and CPU_AMBIENT 45.6 ˚C and it is completely mute.
It is a 12V fan but running at 7V it is perfectly quiet and moves a lot of air still.
I HIGHLY recommend it for everyone. VERY important note though: If you plug in the fan cable through the venthole then first reassemble the back and screw in the 4 screws because it is unreachable after ziptieing the fan. Zipties are cheap so you can cut them off if something is blocked anyway.
Unfortunately the carrying handle is the "deadly" part because the back side of the fan is still exposed so it is not recommended to be fingered. through the carryhole. ;)
No 3D printing required or any cutting of the original enclosurem just zipties and only the old fan got hurt in the process.
-
Of course I added a metal grill to it so I don't put stuff in the blades. The CPU_CHIP runs at 48.7 ˚C and CPU_AMBIENT 45.6 ˚C and it is completely mute.
What was the temperature before?
Did you remove the old fan?
-
The number of failed attempts are recorded in FRAM but they don't seem to survive a reboot.
No, the number of unsuccessful attempts is saved when rebooting and turning off the power, I already checked this :) However, even if the number of attempts is exhausted, the option with the correct key is still activated :)
Boyz and girlz we're back in business!
https://github.com/zelea2/rigol_vendor_bin
Cool! I activated all the available options for myself, everything went without a hitch :) Thank you for the great work you did! :)
-
Of course I added a metal grill to it so I don't put stuff in the blades. The CPU_CHIP runs at 48.7 ˚C and CPU_AMBIENT 45.6 ˚C and it is completely mute.
What was the temperature before?
Did you remove the old fan?
Yes I did remove the old one. I cut the wire of the old fan to get the same female plug to solder onto the fan power cables. Originally the fan was a 3 pin fan PWM controllable but I removed the thrid one of course to not dangle around.
If I remember correctly the stock temp was 54C CPU_AMBIENT and 58C CPU_CHIP so it is even better and even quieter lol. And despite the huge fan it is just small enough to not interfere with the stand because of the extra width.
-
Hi , I've just got a DHO802 and ver 1.2 of the software is installed, I have installed a dongle wi-fi and found I can increase the BW and Mem depth, but only with firmware 1.1. so a couple of questions.
Is it possible to downgrade the firmware to 1.1 from 1.2?
If so where is a copy of the 1.1 firmware located - not on any site I've googled so far.?
is the process the same as the upgrade process?
Thanks
-
Is it possible to downgrade the firmware to 1.1 from 1.2?
You don't need to downgrade, all versions can use options now. See a few messages above.
-
Tell me, do the firmware of the DHO800 and DHO900 still differ from each other? I think that when switching from version 800 to version 900 by changing the vendor, it is not entirely correct. Perhaps the 800 version is missing some files? And the 800 version differs from the 900 in the presence of additional files that are not created when the vendor changes. ???
-
Tell me, do the firmware of the DHO800 and DHO900 still differ from each other?
They've never differed.
Look at the name of the firmware file: "DHO800_DHO900_Update.GEL"
I think that when switching from version 800 to version 900 by changing the vendor, it is not entirely correct. Perhaps the 800 version is missing some files? And the 800 version differs from the 900 in the presence of additional files that are not created when the vendor changes. ???
No.
-
Not being a coding guru, and disassembler god; what process do you need to follow? Or, do you have to learn some new coding languages to get the options to work.
I'm sure there are a lot of DhO800 newbies (like me) waiting for a step-by-step guide (like on page 14 by the brilliant Serg65536) to gratefully follow. Referring back to a complex discussion with people who understand the intricacies of complex assembles languages are not really helpful. Referring to a step-by-step guide now that would be helpful.
thanks you for your thoughts never-the-less.
-
Not being a coding guru, and disassembler god; what process do you need to follow? Or, do you have to learn some new coding languages to get the options to work.
I'm sure there are a lot of DhO800 newbies (like me) waiting for a step-by-step guide (like on page 14 by the brilliant Serg65536) to gratefully follow. Referring back to a complex discussion with people who understand the intricacies of complex assembles languages are not really helpful. Referring to a step-by-step guide now that would be helpful.
thanks you for your thoughts never-the-less.
It was C code, compiled against the device architecture.
C --> compile --> assembly
-
The number of failed attempts are recorded in FRAM but they don't seem to survive a reboot.
No, the number of unsuccessful attempts is saved when rebooting and turning off the power, I already checked this :) However, even if the number of attempts is exhausted, the option with the correct key is still activated :)
Boyz and girlz we're back in business!
https://github.com/zelea2/rigol_vendor_bin
Cool! I activated all the available options for myself, everything went without a hitch :) Thank you for the great work you did! :)
yep. great work zelea2.
-
Step-by-step guide:
- download the generator from here https://github.com/zelea2/rigol_vendor_bin
- Install adb on your linux or windows computer (if you haven't already)
- connect your scope to your local network and find its IP address then
- adb connect IP:55555
- adb -s IP:55555 pull /rigol/data/vendor.bin
- adb -s IP:55555 pull /rigol/data/RKey.data
- make sure that the generator and the 2 files you've downloaded are in the same directory and then generate all options
- rigol_vendor_bin -o
- Optional step: you can also modify your vendor.bin file (to change the scope type, serial number or MAC address) and then send it back to your scope with a push command
- open a browser and go to the scope IP address and click on SCPI commands
- copy and paste each option you desire installed in your browser and press "Send" (RLU for memory etc...)
- you won't get any confirmation in the browser but you'll see a message on your scope's display after each successful option is installed
That's it.
-
Thank you so much for a speedy and informative guide, I will certainly try it in next few hours.
Also to others pointing out to me my lack of understanding of the Rigol operating system foibles.
I thank you once more.
-
I have tried this now and it works perfectly for me, thank you zelea2. There are a few got-yers for people not proficient in how some of the supporting software works (no disrespect zelea2) and maybe not used to using command line ( I know most on the thread will say - in that case should not be here), but that's disingenuous. Most newbies want to learn and get advice from those more learned than they are.
If enough people with limited knowledge are struggling (post a request- if many) then I will try to do a fully detailed step-by-step for the totally inept newbies like me, when it comes to this scope's architecture, to get the job done.
-
( I know most on the thread will say - in that case should not be here), but that's disingenuous. Most newbies want to learn and get advice from those more learned than they are.
Good job! That was nice of @zelea2 to fire off a list for ya. -Amazing and talented person.
Sadly, despite best intentions, there are sometimes assumptions in the step by step guides that we, the uninitiated, have to figure out on our own. That's great that you were able to get up and running. Kudos! Proof that you DO belong here.
There's a very important post by Dave/EEVblog in the beginning of this Test Equipment (https://www.eevblog.com/forum/testgear/newbies-please-read-before-posting/msg355405/#msg355405) thread that says "Regulars. please be nice to newbies who ask a question..."
It's actually regarding searching, but it's good for everyone to remember that "we were all newbies once".
-
So now that the options are back with 00.01.02.00.02, question now is, do I actually upgrade to that version?
Will post a question in the Bugs + Firmware thread to try and get what the new bugs are, and if any were fixed.
-
So now that the options are back with 00.01.02.00.02, question now is, do I actually upgrade to that version?
Another question is what is actually better for, say, an 804 scope: activate all the 8xx options (i.e., 100, or what was it, 125 MHz bandwidth), or install the 900 firmware, which unlocks, IIRC, 200 MHz bandwidth. The question is, are those 200 MHz actually real, or, in other words, are they usable given the 1.25 Gsa/s max rate?
-
So now that the options are back with 00.01.02.00.02, question now is, do I actually upgrade to that version?
Another question is what is actually better for, say, an 804 scope: activate all the 8xx options (i.e., 100, or what was it, 125 MHz bandwidth), or install the 900 firmware, which unlocks, IIRC, 200 MHz bandwidth. The question is, are those 200 MHz actually real, or, in other words, are they usable given the 1.25 Gsa/s max rate?
As you are not drilling a hole into your machine and the option is revertable: go for the max. Other option: A 1:1 comparable setup on a 900 and a maxed out 800. Could we use the Batronix Demo Board for that? Third option: wait for the profs, who already tested that. There might be a difference regarding the non populated memory chip sockets on the 800 - but the 1.25Gsa/s is valid for both.
-
So now that the options are back with 00.01.02.00.02, question now is, do I actually upgrade to that version?
Another question is what is actually better for, say, an 804 scope: activate all the 8xx options (i.e., 100, or what was it, 125 MHz bandwidth), or install the 900 firmware, which unlocks, IIRC, 200 MHz bandwidth. The question is, are those 200 MHz actually real, or, in other words, are they usable given the 1.25 Gsa/s max rate?
I made my 804 a 914, then added just a couple of options.
IIRC, someone said the bandwidth was good for 180MHz -3db.
I think you have to look at the actual hardware diffs between 800-900 series to understand how options work. IIRC, less the digi of 914-924S, less the sig gen, all the same hardware. (or something like that).
-
Is there a complete list of options and a description of what they do (what are they for)?
-
Is there a complete list of options and a description of what they do (what are they for)?
There are some posts about options.
I am not 100% of what they all do.
This list is from the gen tool for 900 vendor.bin
Is the list for the 800 vendor.bin longer? I am not sure, but you can perhaps do that diff using the gen tool. Make an options list for 800 and 900, then compare them.
Some did apply, some did not. My 804 has a 914 vendor.bin
DHO900-AERO
DHO900-ARINC
DHO900-AUDIO
DHO900-AUTO
DHO900-BND
DHO900-BODE
DHO900-BW100T20
DHO900-BW10T20
DHO900-BW15T25
DHO900-BW2T42
DHO900-BW2T8
DHO900-BW4T8
DHO900-BW7T15
DHO900-BW7T20
DHO900-CM_ENET
DHO900-CM_HDMI
DHO900-CM_MIPI
DHO900-CM_USB
DHO900-COMP
DHO900-COUNT
DHO900-DG
DHO900-EMBD
DHO900-EYE
DHO900-FLEX
DHO900-MSO
DHO900-PWR
DHO900-RLU
DHO900-RTSA
DHO900-UPA
-
Another question is what is actually better for, say, an 804 scope: activate all the 8xx options
I say activate all the 804 options. That's 200Mhz real (measured+confirmed) bandwidth even though it only says 100Mhz, and 50M memory.
The question is, are those 200 MHz actually real, or, in other words, are they usable given the 1.25 Gsa/s max rate?
Yes it's real, up to 280MHz if you change it to a DHO924, but ... do you want that given the sample rate?
200MHz seems more sensible to me. 200MHz lets you use two channels without aliasing.
-
Another question is what is actually better for, say, an 804 scope: activate all the 8xx options
I say activate all the 804 options. That's 200Mhz real (measured+confirmed) bandwidth even though it only says 100Mhz, and 50M memory.
The question is, are those 200 MHz actually real, or, in other words, are they usable given the 1.25 Gsa/s max rate?
Yes it's real, up to 280MHz if you change it to a DHO924, but ... do you want that given the sample rate?
200MHz seems more sensible to me. 200MHz lets you use two channels without aliasing.
But if you swap vendor.bin, then only some options apply. I find it easier to swap vendor.bin and then apply a few options.
-
But if you swap vendor.bin, then only some options apply. I find it easier to swap vendor.bin and then apply a few options.
??
There's only two options that do anything - bandwidth upgrade and 50M memory.
If you make it a DHO900 then you already get both of those.
If you want to apply them to a DHO804 then you don't need to touch vendor.bin
-
200MHz seems more sensible to me. 200MHz lets you use two channels without aliasing.
...and if I leave only one channel on? Will the higher BW be of any use? For those special occasions, you know, when one needs to grab a bottle of beer, sit in a comfortable chair and watch the sharp rise and fall edges.
-
...and if I leave only one channel on? Will the higher BW be of any use? For those special occasions, you know, when one needs to grab a bottle of beer, sit in a comfortable chair and watch the sharp rise and fall edges.
It's not really much more bandwidth. You'd have to go to 400Mhz to halve the rise time.
Even so, you can switch to another model in about 10 seconds for those "special occasions". Just send a different vendor.bin then kill the 'scope task. It will auto-restart after a few seconds as the new model. You can even make a .bat file to do it. :)
-
But if you swap vendor.bin, then only some options apply. I find it easier to swap vendor.bin and then apply a few options.
??
There's only two options that do anything - bandwidth upgrade and 50M memory.
If you make it a DHO900 then you already get both of those.
If you want to apply them to a DHO804 then you don't need to touch vendor.bin
Bode lic took on a 914 vendor.bin
If you just swap vendor.bin to a 914, you get more BW right there, hence in the 804 you need to apply an option, so less option setting if you swap the vendor.bin, etc.
-
There's only two options that do anything - bandwidth upgrade and 50M memory.
I have further analyzed the firmware and I've created a list with all available options for each series:
rigol_vendor_bin -l
Available options for Series: 800 900
0 BND 0 0
2 COMP 5 4
3 EMBD 3 2
4 AUTO 4 3
19 RLU 1 .
20 BODE . 5
21 BW7T10 2 .
25 BW15T25 . 1
Bandwidth 'StaticSysBand' range [4-17] depending on options and hardware:
4 (default), 5 (21,23), 6 (21-hw4-5,23-hw4-5,24), 7 (25 series 900)
This library also covers Rigol series 1000 and 4000 on top of 800 and 900 so not all the options are available.
First option BND stands for bundle and it is activated by default and covers the basic options for each series.
I only enable RLU and BW7T10 for my DHO804
The bandwidth is just a number from 4 to 17 (only 8 cases) - probably sent to the FPGA - and only certain hardware allow some of these higher numbers.
-
I only enable RLU and BW7T10 for my DHO804
Can you enable CAN/LIN on DHO800?
-
There's only two options that do anything - bandwidth upgrade and 50M memory.
I have further analyzed the firmware and I've created a list with all available options for each series:
rigol_vendor_bin -l
Available options for Series: 800 900
0 BND 0 0
2 COMP 5 4
3 EMBD 3 2
4 AUTO 4 3
19 RLU 1 .
20 BODE . 5
21 BW7T10 2 .
25 BW15T25 . 1
Bandwidth 'StaticSysBand' range [4-17] depending on options and hardware:
4 (default), 5 (21,23), 6 (21-hw4-5,23-hw4-5,24), 7 (25 series 900)
This library also covers Rigol series 1000 and 4000 on top of 800 and 900 so not all the options are available.
First option BND stands for bundle and it is activated by default and covers the basic options for each series.
I only enable RLU and BW7T10 for my DHO804
The bandwidth is just a number from 4 to 17 (only 8 cases) - probably sent to the FPGA - and only certain hardware allow some of these higher numbers.
In last iteration of the gen tool (I guess for Key.data FW's), it only gave me one Comp, but nine BW options for 914 vendor.bin.
Now you show in chart four Comp options for 900 series?
Am I reading the chart correct? The numbers under series means how many options there are for that type of option (COMP, AUTO, etc etc).
-
Am I reading the chart correct? The numbers under series means how many options there are for that type of option (COMP, AUTO, etc etc).
The numbers are just what the scope uses to identify the options. If the option is not available it's a dot, otherwise it's this number.
I've removed all options for the 1000 and 4000 series. Use the -l option if you want to see the entire list.
-
Can you enable CAN/LIN on DHO800?
From what I've disassembled I think the answer is no but I might be wrong.
One thing that I couldn't figure out is what are the default bundle options for each series and that's something I looked long time for but it's well hidden in that C++ code.
I don't really understand what's the attraction of a L.A. on this scope. You usually want your L.A. to be integrated with your computer as tightly as possible and a scope's
not good for this. I have several L.A. at home and at work but the one that I'm using most often is this: https://www.dreamsourcelab.com/product/dslogic-series/ (https://www.dreamsourcelab.com/product/dslogic-series/)
It can sample 16ch@400MHz has all the possible decoders and you can even write your own decoders and it's only 150$. You can dump all the waveforms as .vcd files
and load them in powerful processing software on your PC. One of the best features is RLE encoding for signals with few transitions and you can record hours of transactions.
Or you can go even cheaper at 10$ https://www.aliexpress.com/item/1005003649856071.html (https://www.aliexpress.com/item/1005003649856071.html) and that still covers half of your typical L.A. captures.
Although I have a 10k$ Tektronics L.A. at work I rarely use it.
For CAN sniffing / probing what I found best was any STM32 part with a CAN driver and a USB interface. That makes a very powerful development environment.
I even have a board with an STM32 + FPGA so I can watch for certain CAN messages in real time and knock them off before they even finish and replace them with my own ones.
-
I have several L.A. at home and at work but the one that I'm using most often is this: https://www.dreamsourcelab.com/product/dslogic-series/ (https://www.dreamsourcelab.com/product/dslogic-series/)
It can sample 16ch@400MHz has all the possible decoders and you can even write your own decoders and it's only 150$. You can dump all the waveforms as .vcd files
and load them in powerful processing software on your PC. One of the best features is RLE encoding for signals with few transitions and you can record hours of transactions.
+1 for DreamSourceLab gear. Their UI and software design is top notch.
I really wanted to do the Logic Analyzer upgrade hack to my DHO, but the more I looked into it, the less appealing it became.
-
From what I've disassembled I think the answer is no but I might be wrong.
That's what I thought.
One thing that I couldn't figure out is what are the default bundle options for each series and that's something I looked long time for but it's well hidden in that C++ code.
It's the RS232/SPI/I2C decoders.
-
On my DHO-812, after updating to version 1.0.2, a CAN trigger appeared (without LIN), but with restrictions (Limited), after activating the AUTO option it switched to Forever.
It turns out that Rigol included the AUTO option as a bonus for buyers of DHO-812 and 814?
-
I don't really understand what's the attraction of a L.A. on this scope.
Agree. I think that LA on an oscilloscope is not serious. You can quickly look at a short data packet, but for normal analysis and debugging of protocols you still need a normal separate LA connected to a computer.
-
I don't really understand what's the attraction of a L.A. on this scope.
Agree. I think that LA on an oscilloscope is not serious. You can quickly look at a short data packet, but for normal analysis and debugging of protocols you still need a normal separate LA connected to a computer.
I think the main attraction is the support for mixed signal analysis: Observe an analog signal which is measured or controlled and at the same time watch the digital control signals; observe a large number of digital channels and check whether the suspicious behaviour of some channels is due to bad signal quality, etc.
Yes, you can do that by keeping two separate devices in sync, but it is more convenient to use an integrated MSO. For purely digital analysis, a PC-based logic analyser will have many advantages -- memory size, data management, choice of decoders, screen resolution, ...
-
If you need to decode short packets in real time, then the LA in the scope is more useful than any external LA. External standalone LA have limited capabilities in real-time cyclic capture with continuous display on the screen. Еvery task has its own means :D
-
+1 for DreamSourceLab gear. Their UI and software design is top notch.
To be fair it's not their software, it's based on sigrok, they have only added a skin.
The good part is that it's open source and you can modify it to suit your needs
(but it takes 20min to compile).
From what I've disassembled I think the answer is no but I might be wrong.
That's what I thought.
Since there is no separate "CAN" license one possibility is that it is covered by one of the three COMP/EMBD/AUTO licenses.
These are available for every 800/900 scope. I will let you guys experiment with those because I don't know what they enable.
One thing that I couldn't figure out is what are the default bundle options for each series and that's something I looked long time for but it's well hidden in that C++ code.
It's the RS232/SPI/I2C decoders.
Actually "bundle" covers all supported options for a scope series.
There is a function called CApiLicense::activeOpt which enables the bundle then deletes all the extra available options.
These options are later re-enabled only if a valid coresponding .lic file is found.
-
So guys the chips are installed, I filmed the whole process
https://youtu.be/tC4oR421hfM
https://youtu.be/HyH9DJBt6K0
-
So guys the chips are installed, I filmed the whole process
https://youtu.be/tC4oR421hfM
https://youtu.be/HyH9DJBt6K0
Amazing! What is the result?
-
The result is still completely unclear to me... I’ll be testing this weekend...
-
+1 for DreamSourceLab gear. Their UI and software design is top notch.
To be fair it's not their software, it's based on sigrok, they have only added a skin.
The good part is that it's open source and you can modify it to suit your needs
(but it takes 20min to compile).
Since there is no separate "CAN" license one possibility is that it is covered by one of the three COMP/EMBD/AUTO licenses.
These are available for every 800/900 scope. I will let you guys experiment with those because I don't know what they enable.
Yeah, I misworded that UI comment. I know they're Sigrok based, but I thought they added more than just a skin. Still, it's better than stock., it's much more intuitive than most., and (at least in their scope UI(DSView)) it's really nice.
On your "CAN" license topic: Wouldn't it make sense if AUTOmobile was for "CAN"?
-
So guys the chips are installed, I filmed the whole process
https://youtu.be/tC4oR421hfM
https://youtu.be/HyH9DJBt6K0
Very Nice! Watching the vidz now. Can't wait to see if it makes a difference. Thanks for pioneering the effort!
Nice PCB ruler BTW, I have the set! :-+
-
@S2084
Seemed like a long time to be under the heat.
To keep SMD's from swimming away, use a small weighted arm to hold the chips in place, this way you don't need to fork them around while at same time heating.
But, that's just my 2cents, you look like you have done hot-air before. The last time I did it was soldering some very small SO8 to a converter pcb (smd to dip). I was afraid of cooking the chip with direct heat, so I placed small shield over the body.
Nice rework, waiting for results.
-
The result is still completely unclear to me... I’ll be testing this weekend...
I can’t believe that Rigol install two additional memory chips in the DHO900 just to confuse everyone :)
Has anyone checked on DHO800 with a replaced vendor.bin to DHO900, does the 50M and LA work correctly? It’s one thing just enable it in the options, it’s quite another thing for all functions to work correctly.
-
I'm sorry, it's hard to shoot on the video..... I did it with a soldering hair dryer just because I wanted to capture the process on video.... The board was preheated to 150°C. This is usually done at the soldering station, there are no problems with landing BGA chips ....
-
I'm sorry, it's hard to shoot on the video..... I did it with a soldering hair dryer just because I wanted to capture the process on video.... The board was preheated to 150°C. This is usually done at the soldering station, there are no problems with landing BGA chips ....
Nah, you're totally fine. I think hot air rework "iron" is the way most of us would install their BGA's, and it looks like you were roughly 2 minutes per IC, which is pretty close to a typical reflow time.
Plus, If you ever watch what some of the kids do to their RROD XBOX's, you were much nicer to the chips and PCBa.
FYI @Randy222 it's not advisable to push down on an IC during reflow. You want the IC to "seat itself", which is what happens when the solder flows just right. If you look real close, they move around left/right and rotation during the process. Let the thermodynamics do it's thing!
-
I'm sorry, it's hard to shoot on the video..... I did it with a soldering hair dryer just because I wanted to capture the process on video.... The board was preheated to 150°C. This is usually done at the soldering station, there are no problems with landing BGA chips ....
Nah, you're totally fine. I think hot air rework "iron" is the way most of us would install their BGA's, and it looks like you were roughly 2 minutes per IC, which is pretty close to a typical reflow time.
Plus, If you ever watch what some of the kids do to their RROD XBOX's, you were much nicer to the chips and PCBa.
FYI @Randy222 it's not advisable to push down on an IC during reflow. You want the IC to "seat itself", which is what happens when the solder flows just right. If you look real close, they move around left/right and rotation during the process. Let the thermodynamics do it's thing!
I no re-work hot air expert. But I have used an arm just like this one, with "great success" on everything I hand solder or hot air.
You can weight it llight or heavy, just move the weight. http://vpapanik.blogspot.com/2015/02/the-smd-beak.html (http://vpapanik.blogspot.com/2015/02/the-smd-beak.html)
I have seen many SMD all crooked due to swimming.
But anyways, back to the results.
-
I've done my share of hot-air work, but have watched like HUNDREDS of hours of others doing it (my daily entertainment is not TV, but rather watching electronics assembly & repair videos). I have never once seen or heard of someone using an "arm" like that. Doesn't look necessary at all to me.
You typically use tweezers to position and hold the component down until the solder gets near the melting point and becomes tacky, the component then "sticks" and you remove the tweezers as the solder melts and the component settles into place as was mentioned. If you're dislodging or blowing away random components your airflow is probably too high, you're holding the heat there for far too long, and/or you're blowing at a low angle to the board. The most common way to dislodge a nearby component is to bump it while its solder is soft/liquid. Typically the capillary action is enough to hold it in place if you just don't touch it.
Another common beginner mistake with hot air is fearing too much heat, so you turn the temp down but then hold it far too long to get the job done. With few exceptions it's typically better to use higher heat for a shorter time. With practice you learn to manage the right balance of temp+airflow+time. It's all in the technique.
-
I no re-work hot air expert. But I have used an arm just like this one, with "great success" on everything I hand solder or hot air.
You can weight it llight or heavy, just move the weight. http://vpapanik.blogspot.com/2015/02/the-smd-beak.html (http://vpapanik.blogspot.com/2015/02/the-smd-beak.html)
I have seen many SMD all crooked due to swimming.
I've done my share of hot-air work, but have watched like HUNDREDS of hours of others doing it (my daily entertainment is not TV, but rather watching electronics assembly & repair videos). I have never once seen or heard of someone using an "arm" like that. Doesn't look necessary at all to me.
the risk of bga short underneath due to "weight stampede" is proportional to the weight used / force exerted.. btw how S2084 ensure all bga pins are properly reballed/connected or without short is not demonstrated. perharps i'll do the whole board preheat and "hair dryer" reflow (surprisingly looks similar to mine ;D) as a last resort when LA section of OS confirmed that the unpopulated ram is really necessary for the LA operation. AND if i desperate enough on the functionality putting aside the risk involved. over preheat it and the FPGA dropped, consider the DSO is gone.
-
Of course, I first checked the voltage drop in diode continuity mode at the terminals of the transition resistors, and it was the same as those near the factory memory chip.... That's all for now...
-
the risk of bga short underneath due to "weight stampede" is proportional to the weight used / force exerted.. btw how S2084 ensure all bga pins are properly reballed/connected or without short is not demonstrated. perharps i'll do the whole board preheat and "hair dryer" reflow (surprisingly looks similar to mine ;D) as a last resort when LA section of OS confirmed that the unpopulated ram is really necessary for the LA operation. AND if i desperate enough on the functionality putting aside the risk involved. over preheat it and the FPGA dropped, consider the DSO is gone.
I was going to ask @S2084 about screening solder paste etc., but then I realized Rigol screened the paste, then reflowed the PCBa without populating those ICs.
So, for anyone thinking to do this: There is already the perfect amount of solder on the pads. Just need flux and hot air to complete the job.
-
I no re-work hot air expert. But I have used an arm just like this one, with "great success" on everything I hand solder or hot air.
You can weight it llight or heavy, just move the weight. http://vpapanik.blogspot.com/2015/02/the-smd-beak.html (http://vpapanik.blogspot.com/2015/02/the-smd-beak.html)
I have seen many SMD all crooked due to swimming.
The weighted arm shown on that page is meant to be used with hand soldering (with a conventional iron and a spool of solder). The author mentions that he has neither a stencil nor a paste dispenser, and uses the arm since he needs a "third hand". Of course, when hand-soldering that way, there is no harm in "forcing" the position of the SMD component.
(I never found the need for a third hand however. I prefer to tin one pad first, then position the component with tweezers while re-heating the pad, then properly solder the other pad(s) and touch up the first one. -- None of this applies to BGAs and the Rigol upgrade discussed here, of course...)
-
Has anyone checked on DHO800 with a replaced vendor.bin to DHO900, does the 50M and LA work correctly?
50M definitely works.
-
Has anyone checked on DHO800 with a replaced vendor.bin to DHO900, does the 50M and LA work correctly?
50M definitely works.
How did you determine this? Methodology?
-
How did you determine this? Methodology?
Everybody reading this has thread has enabled it and been using it for months.
-
How did you determine this? Methodology?
Everybody reading this has thread has enabled it and been using it for months.
I think that means 50M with simultaneous operation of analogue channels and LA.
-
@S2084
From what I found after a quick search
DHO924 use GDP2BFLM-CA DDR3(L) 4Gb
but you use
H5TQ2G63FFR-PBC DDR3 2Gb
-
I think that means 50M with simultaneous operation of analogue channels and aircraft.
I don't know what aircraft you're referring to but I can do this:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2006228;image)
-
How did you determine this? Methodology?
Everybody reading this has thread has enabled it and been using it for months.
I think that means 50M with simultaneous operation of analogue channels and LA.
it has been tested 50M (single or divided among analog channels) are real (i can download data to PC) but when using LA GUI activated, memory will get divided to 25Mpts for 1CH analog (i only tested 1CH + LA) i can try find API to download the 25Mpts LA data to PC but i want to make sure i'm not downloading random data, so i need LA probe and probe something meaningful to prove what i'm downloading is real and i do the test in one go. so until then (when i have a LA probe)
-
I don't know what aircraft you're referring to but I can do this:
The plane is again a Google translation misunderstanding :)) I meant the logic analyzer.
I think the question was whether the available memory depth of the 50M oscilloscope would be preserved when the analog channel and logic analyzer were turned on simultaneously. Perhaps the additional memory chips are dedicated memory for the analyzer, so as not to share it with analog channels. In your screenshot the memory depth is only 10M.
-
In your screenshot the memory depth is only 10M.
thats for each channel. 4 channes active consume 40M total, that proves enough 50M is activated. stock unit you'll have abysmal like 1M/ch if all channels active. he can fullfill your wish by showing 1ch only active and show 50Mpts above there.
-
In your screenshot the memory depth is only 10M.
10M per channel.
I posted that because the unhacked DHO800 only does 1M per channel with four channels on.
-
Bottom line: The extra memory in the DHO900 is a mystery.
They could be fake chips for all we know.
-
Any dumps of 25Q128 of Xilinx Zynq available?
Most wanted from models with three RAM chips.
-
In your screenshot the memory depth is only 10M.
thats for each channel. 4 channes active consume 40M total, that proves enough 50M is activated. stock unit you'll have abysmal like 1M/ch if all channels active. he can fullfill your wish by showing 1ch only active and show 50Mpts above there.
Do you have a 900 series oscilloscope? Or the 800th hacked to 900?
It will be interesting to see what the real 900 will show when, for example, one analog channel and one logic analyzer channel are active.
-
Any dumps of 25Q128 of Xilinx Zynq available?
Most wanted from models with three RAM chips.
The FPGA firmware file is located in the update archive - BOOT.bin and BOOT_SelfTest.bin, each 3631368 bytes in size. Most likely they are written unchanged in 25Q128.
-
Any dumps of 25Q128 of Xilinx Zynq available?
Most wanted from models with three RAM chips.
The FPGA firmware file is located in the update archive - BOOT.bin and BOOT_SelfTest.bin, each 3631368 bytes in size. Most likely they are written unchanged in 25Q128.
This may be the main idea of using a 25 series initialization flash drive. It stores the initial initialization of the FPGA and it is in it that the presence of additional RAM memory is registered!! And the external update and firmware file that is stored in the Android OS only fills the program execution area and not the configuration of the FPGA and its modules!!! Anyone who works with FPGAs knows that when the FPGA starts, the initial configuration of the module DDR is loaded from external memory flash series 25Q128. Maybe I'm wrong, but this could be with 80% probability. And to put an end to this issue, it is necessary to compare the contents of the 25 series memory in the 900 and 800 oscilloscopes.
-
The initial FPGA configuration can be loaded in different ways. There is a more interesting question: why ZYNC? 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. The other two DRAM chips apparently use a DDR3 “soft”-controller implemented in FPGA part. Why the hell is ZYNC even in this circuit? Most likely because it is an old and very cheap chip. Because it is the only-FPGA chip that is needed here, not the CPU or SOC.
-
Do you have a 900 series oscilloscope? Or the 800th hacked to 900?
you can search my posts...
-
This may be the main idea of using a 25 series initialization flash drive. It stores the initial initialization of the FPGA and it is in it that the presence of additional RAM memory is registered!! And the external update and firmware file that is stored in the Android OS only fills the program execution area and not the configuration of the FPGA and its modules!!! Anyone who works with FPGAs knows that when the FPGA starts, the initial configuration of the module DDR is loaded from external memory flash series 25Q128. Maybe I'm wrong, but this could be with 80% probability. And to put an end to this issue, it is necessary to compare the contents of the 25 series memory in the 900 and 800 oscilloscopes.
No, that seems unlikely. The .GEL firmware update file is a compressed archive. In one of its sub-folders, it contains two complete FPGA configuration files (for regular operation and selftest). So these files are updated too during a firmware update. And the DHO800 and 900 models share the exact same FPGA configuration file.
-
Then it turns out that this configuration flash drive is rewritten every time the power is turned on?And if the RAM is connected to a slow interface, then it may simply store additional points for the generator, for example, points of an arbitrary curve. Or this is all a commercial move by Rigol!
-
Then it turns out that this configuration flash drive is rewritten every time the power is turned on?
No, that's not what I meant to say. When you install a firmware update, the new FPGA configuration is copied once from the USB stick (or the online download) into the configuration flash. And then, of course, it is copied from the flash into to FPGA every time the scope boots.
And if the RAM is connected to a slow interface, then it may simply store additional points for the generator, for example, points of an arbitrary curve.
That's what nobody knows...
-
When you install a firmware update, the new FPGA configuration is copied once from the USB stick (or the online download) into the configuration flash. And then, of course, it is copied from the flash into to FPGA every time the scope boots.
Do you mean the internal SD card by "flash"?
Related question: is the SD card the only storage that contains all the scope-specific data? In other words, will backing up the SD card (byte-for-byte raw image copy) and later restoring it after doing any kind of changes restore the original condition of the scope?
-
Some comments for last few posts.
I think we covered storage devices already in this thread. I can go back onto my 804 later and list out the storage devices. Putting all the OS on sd card is not a good idea, so hopefully it's not there.
2nd, I see some noted the FPGA bin is same for 800-900, but that alone does not mean much. bin code can use dynamic functions (good coding), like "what ram can I access?". So, same code, different addressabe memory devices possible depending what's on the m-board.
-
Do you mean the internal SD card by "flash"?
No, I was referring to the 25Q128 serial flash, right next to the FPGA.
Related question: is the SD card the only storage that contains all the scope-specific data? In other words, will backing up the SD card (byte-for-byte raw image copy) and later restoring it after doing any kind of changes restore the original condition of the scope?
There is also the 25Q128 with the FPGA config, and there is an FRAM chip which contains a copy of the key.data file, the most recent scope state, and probably calibration data. (Not sure about the latter -- maybe these are written to the SD card?)
-
Putting all the OS on sd card is not a good idea, so hopefully it's not there.
Where else would it be?
2nd, I see some noted the FPGA bin is same for 800-900, but that alone does not mean much. bin code can use dynamic functions (good coding), like "what ram can I access?". So, same code, different addressabe memory devices possible depending what's on the m-board.
Of course. There obviously are various differences between the 800 and 900 hardware, where the CPU and the FPGA need to decide "dynamically" what to do. These decisions may be based on the vendor.bin entry and/or on querying the actual hardware. I just wanted to correct Aleksandr's assumption that different FPGA configurations, stored in the 25Q128, are encoding the model differences.
-
Do you have a 900 series oscilloscope? Or the 800th hacked to 900?
It will be interesting to see what the real 900 will show when, for example, one analog channel and one logic analyzer channel are active.
I have dho914 modded to 924 and it does 10M with 4 channels active.
Don't have the LA probe, but if anyone could tell me how to trick device into thinking it has one attached, i could test 1ch + LA configuration
-
Do you have a 900 series oscilloscope? Or the 800th hacked to 900?
It will be interesting to see what the real 900 will show when, for example, one analog channel and one logic analyzer channel are active.
I have dho914 modded to 924 and it does 10M with 4 channels active.
Don't have the LA probe, but if anyone could tell me how to trick device into thinking it has one attached, i could test 1ch + LA configuration
I am trying to catch up on 10M part.
Mod'd, and the display says "10Mpts" with 4ch active, but does the scope actually do it?
Maybe that question is more relative to an 800 series mod'd up to 900 series?
-
I am trying to catch up on 10M part.
Mod'd, and the display says "10Mpts" with 4ch active, but does the scope actually do it?
YES!
-
I have dho914 modded to 924 and it does 10M with 4 channels active.
Don't have the LA probe, but if anyone could tell me how to trick device into thinking it has one attached, i could test 1ch + LA configuration
Short the "probe connected" pin to it's corresponding GND. (use a 2-pin shorting jumper) If memory serves it's pin 1
EDIT: confirmed. Jumper covering rightmost 2 pins in a vertical manner. See this post (https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800)/msg5211147/#msg5211147) for more info
-
The initial FPGA configuration can be loaded in different ways. There is a more interesting question: why ZYNC? 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. The other two DRAM chips apparently use a DDR3 “soft”-controller implemented in FPGA part. Why the hell is ZYNC even in this circuit? Most likely because it is an old and very cheap chip. Because it is the only-FPGA chip that is needed here, not the CPU or SOC.
Why ZYNC FPGA?
Here's a theory in question form: Can you implement PCIe in a FPGA without using a CPU core?
EDIT: Hey, while you FPGA peeps are paying attn: Do any of you know how many PCIe lanes Rigol are using in the 800/900? All four appear to be routed between SoC and FPGA, --and that's smart-- but that's a ton of B/W, and i'm curious if we could utilize a lane for something else.
-
Why ZYNC FPGA?
Here's a theory in question form: Can you implement PCIe in a FPGA without using a CPU?
Where would PCIe be used in the scope?
Between the RK3399 and ZYNC FPGA.
[attachimg=1]
-
Short the "probe connected" pin to it's corresponding GND. (use a 2-pin shorting jumper) If memory serves it's pin 1
Thanks!
So for 914/924 it's:
| 50M | 1ch | - | - |
| 25M | 2ch | 1ch+LA | - |
| 10M | 3ch | 4ch | 2ch+LA |
| 1M | 3ch+LA | 4ch+LA | - |
-
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...
-
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?
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 ?
Also to note, if the scope is in STOP state, the auto-down on mem depth does not change until you put scope into RUN. That's odd way of doing things. Don't you want to know your actual mem depth setting before the scope goes to RUN?
-
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.
-
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! ;)
-
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.
-
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.
-
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.
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
-
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.
-
sysctl -w vm.swappiness=100
Why? I would rather have this one set to zero.
But is there any swap enabled, anyway?
-
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.
-
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.
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.
-
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.
-
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.
-
I have found that there are some predefined authorized keys for ssh access in /data/ssh/authorized_keys with the following usernames/emails:
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):
$ ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa root@<ip>
-
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.
-
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.
-
I have found that there are some predefined authorized keys for ssh access in /data/ssh/authorized_keys with the following usernames/emails:
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):
$ 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.
-
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:
[attachimg=1]
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.
-
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 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5310781/#msg5310781)
-
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 (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.
-
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.
-
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
-
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)
-
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.
-
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 (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.
-
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 (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.
-
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?
-
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?
First, I'm -by no means- an expert. And, I probably should have waited for someone else to reply. But, since I'm also interested in this topic, and come from a similar bkgd as you: (Embedded micro work & Android is a black hole) I think it's very feasible, but It's hard to tell if any of the Android dudes want to take this on.
I did a little bit of hacking years ago on Android and recall that you can "unWrap" APKs with common compression tools, as they're generally just Zip files with APK extension.
Then it's a matter of modifying the files and re-packing it. The challenge is re-signing it so the OS doesn't reject your app.
I did a search in this topic here for APK and Sign(Signing) because I remember some discussion about this, and found you have been one of the ones talking about this exact subject.
FWIW; I'm wondering if it might be prudent to try to make something that applies patches to the app(s) or functions after boot rather than patching the main app., That way it might survive updates. I dunno., maybe one of the wicked Android hackers can chime in as to the level of effort.
Research Topics:
Decompile/Recompile (https://stackoverflow.com/questions/50783434/decompile-a-signed-apk-modify-and-recompile-usiing-different-keystore-than-that)
APK Extension (https://www.quora.com/What-kind-of-compression-is-used-for-APK-what-is-the-dictionary-size)
-
This link is the decompiled Sparrow APK for FW 00.01.02.00.02.
Edit at will, rebuild with Gradle in Android Studio. Will it run on the DHO? TBD.
https://easyupload.io/plxok2
My local MD5 of the zip before being uploaded to Easy.
9b0c488110104fffe30b5d39aaa0ea99 Sparrow.apk_Decompiler.com.zip
I am not sure signing matters much, you can enable the Android setting "allow install of apps from unknown sources".
I also notice now Rigol has two downloads for 00.01.02.00.02, one for DHO800 and one for DHO900. Hmmm, in the past they were the same download. I cannot download them, you need a login, so if someone can check their hashes to see if they are same or different, that would be great.
-
I wonder how difficult it is to disassemble an apk, change something in it and compile it back so that it works.
It's just a zip file. Unzip it, patch it, zip it up again!
All APKs are signed though, so the question is: Will the 'scope accept/run it? ie. Can you self-sign it and persuade the 'scope to run it?
(I don't know the answer to that part...)
Ref: https://developer.android.com/studio/publish/app-signing
Another problem with that is that it would have to be re-done for every firmware update.
-
I wonder how difficult it is to disassemble an apk, change something in it and compile it back so that it works.
It's just a zip file. Unzip it, patch it, zip it up again!
All APKs are signed though, so the question is: Will the 'scope accept/run it? ie. Can you self-sign it and persuade the 'scope to run it?
(I don't know the answer to that part...)
Ref: https://developer.android.com/studio/publish/app-signing
Another problem with that is that it would have to be re-done for every firmware update.
Wow, that sounds very familiar... :o But much more brief than my blathering. :-DD
-
I also notice now Rigol has two downloads for 00.01.02.00.02, one for DHO800 and one for DHO900. Hmmm, in the past they were the same download. I cannot download them, you need a login, so if someone can check their hashes to see if they are same or different, that would be great.
Where?
Give a link
On int.rigol.com is same DHO800_DHO900(Software)Updatev00.01.02.00.02 for both
-
I also notice now Rigol has two downloads for 00.01.02.00.02, one for DHO800 and one for DHO900. Hmmm, in the past they were the same download. I cannot download them, you need a login, so if someone can check their hashes to see if they are same or different, that would be great.
Where?
Give a link
On int.rigol.com is same DHO800_DHO900(Software)Updatev00.01.02.00.02 for both
I do not understand that strategy of Rigol EU with this mandatory login for a firmware download...
here it is also available without login
https://www.rigolna.com/firmware/ (https://www.rigolna.com/firmware/)
-
I do not understand that strategy of Rigol EU with this mandatory login for a firmware download...
I don't think there is a strategy behind that, just incompetence...
When I try to download firmware from the DHO900 product page, that fails because the link is plainly broken. (It's a malformed address, which appends a full URL on the international site directly to the rigol.eu URL.) When I try the same from the DHO800 product page or the rigol.eu support page, the link goes to some address which expects an XML file with a key -- maybe meant for online updates downloaded directly by the scope? So that fails because the required parameters are not provided.
I don't know what's going on with Rigol and firmware updates. Their numbering scheme and inconsistency of calendar dates has been a mess for a long time, and now URLs seem a challenge too...
-
Well, I just tested downloads of:
800/900 firmware (https://www.rigolna.com/firmware/) from the 'all firmware' page @axantas shared, and
from the downloads tab via DHO800 (https://www.rigolna.com/products/rigol-digital-oscilloscopes/dho800/) and the DHO900 (https://www.rigolna.com/products/digital-oscilloscopes/dho900/) specific pages
NO broken links for me. All three links pointed to the same file "DHO800_DHO900(Software)Updatev00.01.02.00.02.zip" and were each 96.9MB in size once downloaded.
BTW: If you want a laugh, check out the DM3058/DM3068 version number!
[attachimg=1]
Incidentally, I couldn't find any links for 800 or 900 specific FW as @Randy222 mentioned, only 800/900 combo.
-
Well, I just tested downloads of:
800/900 firmware (https://www.rigolna.com/firmware/) from the 'all firmware' page @axantas shared, and
from the downloads tab via DHO800 (https://www.rigolna.com/products/rigol-digital-oscilloscopes/dho800/) and the DHO900 (https://www.rigolna.com/products/digital-oscilloscopes/dho900/) specific pages
NO broken links for me.
That's good. It's Rigol's European site which we were discussing, and where things are currently broken. I think Rigol would be doing themselves a favor if they adopted one global firmware repository, instead of all the triplicate work (and often inconsistency) at the US and EU sites.
I do not understand that strategy of Rigol EU with this mandatory login for a firmware download...
here it is also available without login
https://www.rigolna.com/firmware/ (https://www.rigolna.com/firmware/)
-
But, since I'm also interested in this topic, and come from a similar bkgd as you: (Embedded micro work & Android is a black hole) I think it's very feasible, but It's hard to tell if any of the Android dudes want to take this on.
Well, in general, I work quite closely with embedded microelectronics, but I’m familiar with Android only as a user and have the most superficial knowledge of development for it :)
I did a search in this topic here for APK and Sign(Signing) because I remember some discussion about this, and found you have been one of the ones talking about this exact subject.
Yes, I also did a little searching for information on this issue and realized that this is in principle possible. The only problem is that you can only compile back SMALI, which is essentially a kind of assembler. So you don’t have to dream about changes at the Java level :)
It's just a zip file. Unzip it, patch it, zip it up again!
All APKs are signed though, so the question is: Will the 'scope accept/run it? ie. Can you self-sign it and persuade the 'scope to run it?
(I don't know the answer to that part...)
Ref: https://developer.android.com/studio/publish/app-signing
Another problem with that is that it would have to be re-done for every firmware update.
You don’t just need to unzip and then archive, you need to decompile and then compile back, and this is more difficult :)
Regarding signing the application - as I understand after reading several articles and topics on forums, this is not a problem. You can sign with a signature you created yourself; there are tools for this.
The most important thing is that after decompilation, changes and compilation, the application remains working :)
-
i'm working on to make both AFG and LA to work now, still in progress...
Oh thats cool! I will look forward to hearing about your results :)
In addition to this hardware, it looks like you also need to solder 2 missing memory chips onto the main board of the oscilloscope. Presumably this memory is needed for LA, but as far as I know, no one has yet tested this in practice.
any specific steps how to do that? i didnt follow this thread closely sorry.
1. Download the files /rigol/data/vendor.bin and /rigol/data/Key.data from the oscilloscope using ADB:
adb pull /rigol/data/vendor.bin
adb pull /rigol/data/Key.data
2. Using this program - https://github.com/zelea2/rigol_vendor_bin - change the oscilloscope model to DHO914S or DHO924S in the vendor.bin file:
rigol_vendor_bin.exe -M DHO924S
3. Using the same program, generate all possible options using the Key.data file:
rigol_vendor_bin.exe -o
For convenience, you can direct the program output to a file so that all generated options are saved in it:
rigol_vendor_bin.exe -o >>options.txt
4. Load the vendor.bin file back into the oscilloscope:
adb push vendor.bin /rigol/data/
5. Reboot the oscilloscope.
6. Send the DHO900-BODE and DHO900-BW15T25 options from those generated in step 3 via the SCPI interface.
Aren't both option at point 6 already available on a DHO900S series by default?
By upgrading the DHO914S into a 924S isn't just the bandwith to be increased?
So can I just increase in my DHO914S the BW without modifying the vendor.bin?
regards and thanks
-
1. Download the files /rigol/data/vendor.bin and /rigol/data/Key.data from the oscilloscope using ADB:
adb pull /rigol/data/vendor.bin
adb pull /rigol/data/Key.data
2. Using this program - https://github.com/zelea2/rigol_vendor_bin (https://github.com/zelea2/rigol_vendor_bin) - change the oscilloscope model to DHO914S or DHO924S in the vendor.bin file:
rigol_vendor_bin.exe -M DHO924S
3. Using the same program, generate all possible options using the Key.data file:
rigol_vendor_bin.exe -o
For convenience, you can direct the program output to a file so that all generated options are saved in it:
rigol_vendor_bin.exe -o >>options.txt
4. Load the vendor.bin file back into the oscilloscope:
adb push vendor.bin /rigol/data/
5. Reboot the oscilloscope.
6. Send the DHO900-BODE and DHO900-BW15T25 options from those generated in step 3 via the SCPI interface.
Aren't both option at point 6 already available on a DHO900S series by default?
By upgrading the DHO914S into a 924S isn't just the bandwith to be increased?
So can I just increase in my DHO914S the BW without modifying the vendor.bin?
regards and thanks
I don’t remember exactly about BODE, but it seems that it was initially either not available at all or available as a trial option.
Yes, now you can simply change the BW without changing the oscilloscope model, to do this, just skip steps 2, 4 and 5.
If the oscilloscope is flashed with the latest firmware 00.01.02.00.02, then you need to load the RKey.dat file from the oscilloscope instead of Key.dat.
Recently, zelea2 added to its utility another way to unlock all options available for a given model - https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5323313/#msg5323313 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5323313/#msg5323313)
PS: I keep getting confused about the correct spelling of this longest version of Rigol's firmware :))
-
You don’t just need to unzip and then archive, you need to decompile and then compile back, and this is more difficult :)
At it's most elemental level, patching does not require decompilation and recompilation. Certainly when it's possible to get compilable source code from a binary distribution, such as when Java archives include the original source, that's great but it's pretty rare. When you can get an approximation of original source through decompilation with tools such as Ghidra or IDA, it's not so that it can be recompiled, but only to help follow the code in a higher level language than assembler. But in most cases you're disassembling to assembler code and reading that to understand what the code is doing, therefore strong knowledge of assembler is necessary for effective RE.
Sometimes just following the logic is enough to understand the algorithm in order to create a key generator, in which case no patching or updating the binary is required. Otherwise, patching data or opcode bytes directly in the binary (e.g. to jump over a validation check) is done to alter or short-circuit the logic to achieve your goal. There is no compiling of source code happening here.
I did a great deal of software reverse engineering back in the 90's and early 00's in both personal and professional contexts, leveraging tools like Periscope and SoftICE as well as IDA, OllyDbg, and others to RE and patch code. It was generally easier back then before methods like encryption, signing, anti-debug tricks, etc. were commonly employed that made RE more difficult, though seldom impossible.
-
You don’t just need to unzip and then archive, you need to decompile and then compile back, and this is more difficult :)
At it's most elemental level, patching does not require decompilation and recompilation. Certainly when it's possible to get compilable source code from a binary distribution, such as when Java archives include the original source, that's great but it's pretty rare. When you can get an approximation of original source through decompilation with tools such as Ghidra or IDA, it's not so that it can be recompiled, but only to help follow the code in a higher level language than assembler. But in most cases you're disassembling to assembler code and reading that to understand what the code is doing, therefore strong knowledge of assembler is necessary for effective RE.
Sometimes just following the logic is enough to understand the algorithm in order to create a key generator, in which case no patching or updating the binary is required. Otherwise, patching data or opcode bytes directly in the binary (e.g. to jump over a validation check) is done to alter or short-circuit the logic to achieve your goal. There is no compiling of source code happening here.
I did a great deal of software reverse engineering back in the 90's and early 00's in both personal and professional contexts, leveraging tools like Periscope and SoftICE as well as IDA, OllyDbg, and others to RE and patch code. It was generally easier back then before methods like encryption, signing, anti-debug tricks, etc. were commonly employed that made RE more difficult, though seldom impossible.
I'm not talking about analysis, but about changing the application. Decompile, modify and compile back.
With the help of Ghidra, by the way, you can also modify programs, but to a very limited extent. Although I once tinkered with the firmware of a 3D printer (for which there were no sources) and managed to modify it very significantly, adding my own compiled functions to the binary and redirecting calls in the firmware to them instead of native functions :)
-
I'm not talking about analysis, but about changing the application. Decompile, modify and compile back.
I'm not just talking about analysis, either. "Patching" is by definition changing the application. I've modified hundreds of binaries through patching, and not decompiling/recompiling, which was the point of my post. In most cases decompiling/recompiling isn't an option, patching is the only viable way to change the app.
-
I'm not talking about analysis, but about changing the application. Decompile, modify and compile back.
I'm not just talking about analysis, either. "Patching" is by definition changing the application. I've modified hundreds of binaries through patching, and not decompiling/recompiling, which was the point of my post. In most cases decompiling/recompiling isn't an option, patching is the only viable way to change the app.
In a binary without decompilation, you can change only very slightly. For example, replace the call to the license check function with unconditional truth. But redoing the algorithm for how a function works is a big challenge.
I want to be able to change the operation of the application without regard to the restrictions imposed by the already compiled binary :)
-
You can checkout what we did for patching the application on the sibling thread for DHO1000. Although I don't see why it's necessary except you want to fix bugs yourself.
-
So guys the chips are installed, I filmed the whole process
https://youtu.be/tC4oR421hfM
https://youtu.be/HyH9DJBt6K0
Did anything work out? Is there any result? Look forward to.
-
I commenting on past few posts.
1) Two seperate FW's, perhaps the same, need login. --> https://supportint.rigol.com/SUPPORTS/software-firmware-download.html
2) You cannot just unpack an APK and edit. An APK is a package set of compiled goods along with some other text files.
3) I provided the decompiled APK, tons of .java source files to edit if you like
If we are wanting the source of the C libraries (.so files), then I need to see if I can get that.
One test is to hexedit or Ghidra edit one non-significant byte in the auklet.so library, then swap it out on the DHO, see what happens. The auklet.so appears to be where all the functions are for doing scope stuff.
An APK should have file that contains all the hashes of the files in an APK for intergrity, and then the APK itself is signed so that Andoid device knows it's from a trusted source. Again, we can install apps from unknown sources.
-
Although I don't see why it's necessary except you want to fix bugs yourself.
To change the channel color palette, for example, and maybe make other UI customizations.
-
1) Two seperate FW's, perhaps the same, need login. --> https://supportint.rigol.com/SUPPORTS/software-firmware-download.html
view page source and get links
https://download.rigol.com/cn/Firmware/Digital%20Oscilloscope/DHO800%26DHO900/DHO800_DHO900(Software)Updatev00.01.02.00.02.zip
Same firmware
-
3) I provided the decompiled APK, tons of .java source files to edit if you like
As I understand from reading on the Internet, compiling .java files after decompilation is a very bad idea. You need to modify and compile SMALI files.
-
Sorry distubing You AndyBig, I cannot access via adb the oscope (DHO914S).
Upgrading older DHO800 to 924 was easy enough, now it seems connection failure to the device.
Do I need to extra enable something on the oscope?
BTW I can see all 6 options visible (5 in Forever state - BandWidth is Limited) and FW is 00.01.00 built on 2023/07/21
Will try to upgrade to the latest and the retry.
Any help appreciated
Regards
-
Try port 55555 (five digits).
-
|O |O |O |O Yeah, that works....
Sorry :palm: :palm: :palm: :palm: :palm:
-
Don't ask me how I knew to watch out for that... ::)
-
3) I provided the decompiled APK, tons of .java source files to edit if you like
As I understand from reading on the Internet, compiling .java files after decompilation is a very bad idea. You need to modify and compile SMALI files.
The decompiles SMALI files are in the zips I posted back a few pages. APKTOOL decompiles of all 3 or the Rigol APK's (web scope launcher). Edit the SMALI files all day if you like.
Here's what the .com.rigol.scope MainActivity looks like. attached as .smail.txt
However, I am not sure you need to edit SMALI files. The process is to code in Java, compile it, convert to dex using Android dx tool, dex --> smali using baksmali tool
Read these links
https://stackoverflow.com/questions/29051781/convert-java-file-to-smali-file#29052019
https://payatu.com/blog/an-introduction-to-smali/
-
The decompiles SMALI files are in the zips I posted back a few pages. APKTOOL decompiles of all 3 or the Rigol APK's (web scope launcher). Edit the SMALI files all day if you like.
Here's what the .com.rigol.scope MainActivity looks like. attached as .smail.txt
Yes, thank you, I saw your message with a link to a decompiled application, but to be honest, I’m not yet sure that I’m ready to dive even into Java, not to mention SMALI :) The last time I dealt with Java was about 12 years ago :))
However, I am not sure you need to edit SMALI files. The process is to code in Java, compile it, convert to dex using Android dx tool, dex --> smali using baksmali tool
Read these links
https://stackoverflow.com/questions/29051781/convert-java-file-to-smali-file#29052019
https://payatu.com/blog/an-introduction-to-smali/
I have seen many reports that the Java code obtained during the decompilation process has inaccuracies and obvious errors. For example, a function may contain a return statement first and then the function code itself. I'm afraid that it will be almost impossible to find and fix all such jambs. At the same time, SMALI has code that matches the application exactly. In addition, I have come across mentions that when compiling from Java, some kind of fiddling is necessary with the external dependencies to be plugged in, or rather with their versions. But here I'm not sure, because... I haven't studied this issue in depth. In fact, the first reason is already quite enough to be very skeptical about assembling from decompiled Java sources :)
-
So guys the chips are installed, I filmed the whole process
https://youtu.be/tC4oR421hfM
https://youtu.be/HyH9DJBt6K0
Did anything work out? Is there any result? Look forward to.
Unfortunately, I have to admit that no changes have occurred. memory depth remained the same. I even went back to firmware 1.00.19, and then updated to the latest, but it did not give any result. It looks like these two memory chips are not used by the system. But in any case, when Rigil decides to use them, I already have them installed....
-
Unfortunately, I have to admit that no changes have occurred. memory depth remained the same. I even went back to firmware 1.00.19, and then updated to the latest, but it did not give any result. It looks like these two memory chips are not used by the system. But in any case, when Rigil decides to use them, I already have them installed....
Did gabiz_ro's question regarding the choice of memory chips ever get answered? From what I see in teardown photos and datasheets, he seems right about a potential mismatch:
@S2084
From what I found after a quick search
DHO924 use GDP2BFLM-CA DDR3(L) 4Gb
but you use
H5TQ2G63FFR-PBC DDR3 2Gb
-
It looks like these two memory chips are not used by the system.
:)
-
So guys the chips are installed, I filmed the whole process
https://youtu.be/tC4oR421hfM
https://youtu.be/HyH9DJBt6K0
Did anything work out? Is there any result? Look forward to.
Unfortunately, I have to admit that no changes have occurred. memory depth remained the same. I even went back to firmware 1.00.19, and then updated to the latest, but it did not give any result. It looks like these two memory chips are not used by the system. But in any case, when Rigil decides to use them, I already have them installed....
Step #1 might have been to probe the lands of the empty mem positions using another tool while the scope was running, to at least ascertain if there's any activity there.
If #1 proves to be active, then perhaps as mentioned, specific mem chips are needed?
Not sure if you can do it, maybe remove the installed chips and solder in sockets instead, this way you can perhaps just pop-in and pop-out chips at-will.
-
The decompiles SMALI files are in the zips I posted back a few pages. APKTOOL decompiles of all 3 or the Rigol APK's (web scope launcher). Edit the SMALI files all day if you like.
Here's what the .com.rigol.scope MainActivity looks like. attached as .smail.txt
Yes, thank you, I saw your message with a link to a decompiled application, but to be honest, I’m not yet sure that I’m ready to dive even into Java, not to mention SMALI :) The last time I dealt with Java was about 12 years ago :))
However, I am not sure you need to edit SMALI files. The process is to code in Java, compile it, convert to dex using Android dx tool, dex --> smali using baksmali tool
Read these links
https://stackoverflow.com/questions/29051781/convert-java-file-to-smali-file#29052019
https://payatu.com/blog/an-introduction-to-smali/
I have seen many reports that the Java code obtained during the decompilation process has inaccuracies and obvious errors. For example, a function may contain a return statement first and then the function code itself. I'm afraid that it will be almost impossible to find and fix all such jambs. At the same time, SMALI has code that matches the application exactly. In addition, I have come across mentions that when compiling from Java, some kind of fiddling is necessary with the external dependencies to be plugged in, or rather with their versions. But here I'm not sure, because... I haven't studied this issue in depth. In fact, the first reason is already quite enough to be very skeptical about assembling from decompiled Java sources :)
I believe we have good methodology to undo APK's, edit them, pack them back up, less the signing issue.
Have a read:
https://medium.com/@sandeepcirusanagunla/decompile-and-recompile-an-android-apk-using-apktool-3d84c2055a82
-
Unfortunately, I have to admit that no changes have occurred. memory depth remained the same. I even went back to firmware 1.00.19, and then updated to the latest, but it did not give any result. It looks like these two memory chips are not used by the system. But in any case, when Rigil decides to use them, I already have them installed....
Did gabiz_ro's question regarding the choice of memory chips ever get answered? From what I see in teardown photos and datasheets, he seems right about a potential mismatch:
@S2084
From what I found after a quick search
DHO924 use GDP2BFLM-CA DDR3(L) 4Gb
but you use
H5TQ2G63FFR-PBC DDR3 2Gb
In order not to look for answers, you can install those chips yourself that you consider necessary
-
So guys the chips are installed, I filmed the whole process
https://youtu.be/tC4oR421hfM
https://youtu.be/HyH9DJBt6K0
Did anything work out? Is there any result? Look forward to.
Unfortunately, I have to admit that no changes have occurred. memory depth remained the same. I even went back to firmware 1.00.19, and then updated to the latest, but it did not give any result. It looks like these two memory chips are not used by the system. But in any case, when Rigil decides to use them, I already have them installed....
Step #1 might have been to probe the lands of the empty mem positions using another tool while the scope was running, to at least ascertain if there's any activity there.
If #1 proves to be active, then perhaps as mentioned, specific mem chips are needed?
Not sure if you can do it, maybe remove the installed chips and solder in sockets instead, this way you can perhaps just pop-in and pop-out chips at-will.
Are you at least somewhat competent to give such advice? :-DD
-
In order not to look for answers, you can install those chips yourself that you consider necessary
Not sure whether it was meant that way, but your comment comes across as disparaging. Which would be unwarranted, since my question was sincere:
If indeed you populated 2 GB DRAM chips instead of 4 GB, that would obviously be an explanation why they did not work. Since you seem to know what you are doing, I assume you had a good reason to choose those chips. Hence I would hope that you can share that reason. Thanks!
-
Fine! Job is done! And there is a result! Since the absence of a result is also a result! Then let competent people tell you whether such RAM is suitable? mt41k256m16tw-093
-
And I would still try to upload a full dump from the DHO900 oscilloscope into a 25 series flash drive that is connected to the FPGA! There is some certainty in this too!
-
Since the absence of a result is also a result!
I disagree. A negative result -- i.e. the definite conclusion that even suitable RAM does not get used -- would be a result. But the absence of a result provides very limited information.
Having said that, I think it is entirely possible that the RAM is unused (at this time). I have speculated earlier that Rigol had originally designed it in to store the digital data, providing extra capacity and extra bandwidth for these. But ran into problems, maybe routing congestions in the FPGA, and decided to share the main RAM between analog and digital data, as a fallback solution. Which would explain the somewhat embarrassing reduction of the analog sampling rate when the digital channels are used.
-
Step #1 might have been to probe the lands of the empty mem positions using another tool while the scope was running, to at least ascertain if there's any activity there.
If #1 proves to be active, then perhaps as mentioned, specific mem chips are needed?
Not sure if you can do it, maybe remove the installed chips and solder in sockets instead, this way you can perhaps just pop-in and pop-out chips at-will.
Are you at least somewhat competent to give such advice? :-DD
Yes is the answer.
But it was more a question. Would it be easier, for testing purposes, to install some type of socket?
That mem is 96-TFBGA package. 96 ball contact, Are you confident all 96 were soldered in good and clean, even with the swimming?
The results do provide some head scratching,
1) no apparent change with mem soldered in?
2) no adverse affects either?
-
But it was more a question. Would it be easier, for testing purposes, to install some type of socket?
Last time I looked, BGA sockets cost about the same as a DHO9xx. Have you come across more affordable options?
-
Side note for hacking.
Mem dump KLM
compile LiME, insmod it, mem dump, evaluate memory.
https://www.pwc.be/en/FY21/documents/Android_memory_forensics.pdf (https://www.pwc.be/en/FY21/documents/Android_memory_forensics.pdf)
-
But it was more a question. Would it be easier, for testing purposes, to install some type of socket?
For BGA? Nope.
-
But it was more a question. Would it be easier, for testing purposes, to install some type of socket?
For BGA? Nope.
Well, the naked lands could have been probed before trying to solder in the chip, yes?
-
In order not to look for answers, you can install those chips yourself that you consider necessary
Nice replay
I will definitely do that in near future.
on topic now
As for MT41K256M16TW-093 that was what I found available on stock, seems compatible but I'm not 100% sure, from datasheet looks like some data lines are splitted in lower and upper.
Just for example on video cards when replace RAM chips there are some some config resistor that you need to change based on chip vendor, it may be different pinout but I don't think so.
So best approach will be to use same chips as original ones.
I don't think they are separated, data lines are shared, to check for some activity on this chips you must be doing this only on specific pins that are used only by that memory chip under test, chip select or chip enable (maybe some others too) and if there is firmware on that 25Q128 and is different from models with different RAM size then you also got nothing since FPGA will not try to use them so no activity an dedicated pins.And now we can't be sure for anything.
Some say that 25Q128 is used to store some initialization for FPGA and firmware is loaded by startup script, a little strange to use 16MB chip only for that, if my memory serve well that firmware or boot from FPGA folder is around 4MB
-
Step #1 might have been to probe the lands of the empty mem positions using another tool while the scope was running, to at least ascertain if there's any activity there.
If #1 proves to be active, then perhaps as mentioned, specific mem chips are needed?
Not sure if you can do it, maybe remove the installed chips and solder in sockets instead, this way you can perhaps just pop-in and pop-out chips at-will.
Are you at least somewhat competent to give such advice? :-DD
Yes is the answer.
But it was more a question. Would it be easier, for testing purposes, to install some type of socket?
That mem is 96-TFBGA package. 96 ball contact, Are you confident all 96 were soldered in good and clean, even with the swimming?
The results do provide some head scratching,
1) no apparent change with mem soldered in?
2) no adverse affects either?
Are you familiar with the concept of "surface tension of a liquid"???
-
Did gabiz_ro's question regarding the choice of memory chips ever get answered? From what I see in teardown photos and datasheets, he seems right about a potential mismatch:
In order not to look for answers, you can install those chips yourself that you consider necessary
Look, there are a few simple potential answers to my question which I can think of:
- "You are mistaken; the DRAM I used is the correct type because ..."
- "I know it's not the exact type; I chose this one as a workaround because..."
- "Oh shit."
But I can't think of an explanation why you would first come back with a snide comment, then ignore my polite request to clarify. What's wrong?
-
Please don't be angry, I'll answer you now.
-
Well, the naked lands could have been probed before trying to solder in the chip, yes?
If you have a DHO800 with no chips blocking the pads you can probe them to look for activity at boot up.
PS: Has anybody looked in the boot log for messages to do with extra memory?
-
Some say that 25Q128 is used to store some initialization for FPGA and firmware is loaded by startup script, a little strange to use 16MB chip only for that, if my memory serve well that firmware or boot from FPGA folder is around 4MB
FPGA boot.bin is fairly small
3.6 MB (3,631,368 bytes)
Some reasons why maybe 16MB mem chip is used:
1) more common and less expensive than older 8MB chips?
2) maybe just bought 16MB in huge bulk for various products where more mem is needed, so less cost and common chip across the product lines?
3) maybe for possible future feature releases?
As a side question, the experiment was done on 800 series. I wonder if anything changes if you change vendor.bin so the 800 thinks it's a 914 or 924?
-
Did gabiz_ro's question regarding the choice of memory chips ever get answered? From what I see in teardown photos and datasheets, he seems right about a potential mismatch:
In order not to look for answers, you can install those chips yourself that you consider necessary
Look, there are a few simple potential answers to my question which I can think of:
- "You are mistaken; the DRAM I used is the correct type because ..."
- "I know it's not the exact type; I chose this one as a workaround because..."
- "Oh shit."
But I can't think of an explanation why you would first come back with a snide comment, then ignore my polite request to clarify. What's wrong?
I have not found exactly the same memory chips on sale. But somewhere on the network I saw a debug board with FPGA ZYNQ, on which exactly the same memory chips were installed that I installed in my Rigol. From this I concluded that they must be compatible..... That's all..... Was there such a great need for this explanation of mine???
-
Well, there was (and still is?) the question: "In your tests, did the scope simply not use the memory since it is the wrong type and therefore failed some self test?"
So I was curious whether you already have a conclusive answer to that, i.e. an argument why this RAM type can (or even must) be used for testing. That's why I asked.
-
I repeat, there are no changes in the operation of the oscilloscope! I didn’t do anything with it..... Secondly, I never said that the DDR chips I installed are the only true alternative to those installed in the 900 series. I don't understand where you got this from?
-
Was there such a great need for this explanation of mine???
This is a discussion forum. The whole point of a discussion forum is to discuss. That's what we do. We're engineers, technicians, scientists. Someone posts something. Others ask questions, poke holes, challenge, correct misinformation, etc. If you don't want people to question you, then maybe reconsider engaging in the first place. It makes you look pretty arrogant to think you can post and nobody should be expected to question you about it.
-
I loaded the pwm_fan.ko driver into 804 , driver from the 1000/4000 GEL FW bundle.
Loads ok, no errors. lsmod show 4 instances, but I can't find where to set PWM freq or %.
Perhaps all moot if the fan wires simpley attach to Vcc-Gnd, but I simply don't know where thise wires go.
The driver appears to be written by someone at Samsung.
Any thoughts?
-
Some say that 25Q128 is used to store some initialization for FPGA and firmware is loaded by startup script, a little strange to use 16MB chip only for that, if my memory serve well that firmware or boot from FPGA folder is around 4MB
The oscilloscope firmware contains two binaries for FPGAs - BOOT.bin and BOOT_SelfTest.bin. And most likely both of these files are loaded into 25Q128, that is, at least 8 MB is already needed. Perhaps some other data is loaded there, but even if not, it seems reasonable to me to install flash memory with a reserve, and not exactly according to the size currently required :)
-
I loaded the pwm_fan.ko driver into 804 , driver from the 1000/4000 GEL FW bundle.
Loads ok, no errors. lsmod show 4 instances, but I can't find where to set PWM freq or %.
Check if there's anything under /sys/class/hwmon after the module is loaded. If there is a supported fan controlling chip, there will be symlinks to respective directories which may contain files with "fan" and "pwm" in their names.
Also, why don't you post that .ko here so that others might take a look too? :)
Perhaps all moot if the fan wires simpley attach to Vcc-Gnd, but I simply don't know where thise wires go.
IIRC Dave measured voltage at the fan connector to be 8V, so it's at least not the main 12V rail, meaning there's a chance.
-
Fine! Job is done! And there is a result! Since the absence of a result is also a result! Then let competent people tell you whether such RAM is suitable? mt41k256m16tw-093
I don't think anyone can answer you competently. The best option for you would be to try this on your own... In the worst case, nothing will change in the operation of the oscilloscope. On my own behalf, I can advise you not to be lazy and change the balls on the chips to lead-containing ones with a lower melting point.... All soldering on the board is done using lead-containing solder. This action will save you a lot of nerves...
-
I have not found exactly the same memory chips on sale. But somewhere on the network I saw a debug board with FPGA ZYNQ, on which exactly the same memory chips were installed that I installed in my Rigol. From this I concluded that they must be compatible..... That's all..... Was there such a great need for this explanation of mine???
The fact that somewhere Zynq with its configuration and its firmware worked with these memory chips does not mean at all that it will work with the same memory in Rigol, in which a completely different firmware and configuration is loaded into the FPGA. There is a high probability that this will not work.
-
Do you really think that I don’t understand this? Of course, this probability is quite high... But how can you estimate the probability that the guys from Rigol prescribed a strictly defined model of RAM chips in the FPGA?
-
Do you really think that I don’t understand this? Of course, this probability is quite high... But how can you estimate the probability that the guys from Rigol prescribed a strictly defined model of RAM chips in the FPGA?
I think this probability is close to 100%. It makes no sense for them to prescribe settings for dozens of memory chip models.
-
I loaded the pwm_fan.ko driver into 804 , driver from the 1000/4000 GEL FW bundle.
Loads ok, no errors. lsmod show 4 instances, but I can't find where to set PWM freq or %.
Check if there's anything under /sys/class/hwmon after the module is loaded. If there is a supported fan controlling chip, there will be symlinks to respective directories which may contain files with "fan" and "pwm" in their names.
Also, why don't you post that .ko here so that others might take a look too? :)
Perhaps all moot if the fan wires simpley attach to Vcc-Gnd, but I simply don't know where thise wires go.
IIRC Dave measured voltage at the fan connector to be 8V, so it's at least not the main 12V rail, meaning there's a chance.
ko attached as txt file
my local MD5
58070b2e6c5ced96ef685e17fb019192 1000-4000v00.02.11.pwm_fan.ko.txt
the devicetree has files and such, but I cannot ID an actual device or find anything that resembles settings.
-
Some say that 25Q128 is used to store some initialization for FPGA and firmware is loaded by startup script, a little strange to use 16MB chip only for that, if my memory serve well that firmware or boot from FPGA folder is around 4MB
The oscilloscope firmware contains two binaries for FPGAs - BOOT.bin and BOOT_SelfTest.bin. And most likely both of these files are loaded into 25Q128, that is, at least 8 MB is already needed. Perhaps some other data is loaded there, but even if not, it seems reasonable to me to install flash memory with a reserve, and not exactly according to the size currently required :)
The BOOT_SelfTest.bin is not installed (flashed) with a GEL update.
Only BOOT.bin gets an spi2flash to FPGA address 0x400000
They actually do a "spi2erase" at 0x400000 before flashing the bin from GEL
I suspect if you need SelfTest it needs to be flashed to 0x400000, but done manually.
I'll try it and see what happens.
-
@S2084
From what I found after a quick search
DHO924 use GDP2BFLM-CA DDR3(L) 4Gb
but you use
H5TQ2G63FFR-PBC DDR3 2Gb
last time i did the homework, i put IS43TR16256BL-125KBLI in my aliexpress cart just in case one day i decide to choose that route (if later after LA probe experiment or others DHO900S owners prove it to be beneficial to install) its 4Gb ram from the datasheet but i'm not expert in DDR3 tech, there are 16bits and 8bits lanes and plethora of DDR3 speed and signal integrity specs that easily confuses me. advices are welcomed...
https://www.aliexpress.com/item/1005006042462729.html (https://www.aliexpress.com/item/1005006042462729.html)
https://my.mouser.com/datasheet/2/198/43_46TR16256A_85120AL-268426.pdf (https://my.mouser.com/datasheet/2/198/43_46TR16256A_85120AL-268426.pdf)
Are you familiar with the concept of "surface tension of a liquid"???
during reflow, if we wiggle the ic a little bit, it should get back to its least surface tension position,usually if all pins are reflowed/melted properly. at least this is a poor mens indication a proper reflow process is made. i've seen other videos using 45degree angled mirror and camera to see the side of the ic for proper reflow. btw no need to get offended by others, think positively they merely provide suggestions and thoughts for the proper process. we appreciate what you did... doing it and reporting findings (regardless of success or failure) is alot better than speculative talk imho, ymmv.
-
3) maybe for possible future feature releases?
Nah.
I wonder if anything changes if you change vendor.bin so the 800 thinks it's a 914 or 924?
It works perfectly.
-
3) maybe for possible future feature releases?
Nah.
I wonder if anything changes if you change vendor.bin so the 800 thinks it's a 914 or 924?
That's not what I mean.
There are some properties of the hardware that persist. Look at "getprop" settings. Device serial # there does not match my vendor.bin serial.
Next you have hardware type ID. 800's are different than 900's.
So maybe due to some other properties the code does not go after the additional memory that was added?
Throwing ideas out there.
It works perfectly.
-
The question is completely different. How do you even understand that the DHO900 is using this additional memory? Maybe it's just there for beauty and not used during work!!! That's the point! This memory may not be needed at all!!! How to understand that it is used in DHO900?
-
I noticed something odd on my 804 that has 00.01.02.00.00
The GEL update script stuff appears to use 0x400000 as the base address to erase and flash the BOOT.bin using spi2flash
In those same update scripts it does a setprop for the persist fpga boot address 0x400000 used by the start script which loads fpga using spi2boot.
But I noticed my getprop setting is 0x00000
I flashed the test bin in using teh reload_fpga script, it does the erase and flash commands, then reloads pcie and xdma ko drivers, and reloads the scope app.
Upon one of my tests I thought I saw a two option tounch menu behind the rigol logo during boot, but scope app loads over it. I think I need to am kill scope and launcher to get back to base android screen, or at least minimize those apps.
If I use spi2flash directly and provide anything less than 0x400000, i get err saying the bin needs min 0x400000 (4MB). The spi2flash address argument does not appear to be a start address, seems to be just how big the flash dest needs to be, so then what does the getprop "boot address" mean?
-
The question is completely different. How do you even understand that the DHO900 is using this additional memory? Maybe it's just there for beauty and not used during work!!! That's the point! This memory may not be needed at all!!! How to understand that it is used in DHO900?
Why would Rigol buy and place SMA mem chips onto the board if they are not used at all? Maybe the mem devices in 900 are just dummy chips?
We must use some logic, and the not used at all logic does not make sense to me.
-
Maybe it's just there for beauty and not used during work!!! That's the point!
by any stretch, i cannot imagine why some designer will put 2 of them on pcb and connect traces and resistors to fpga just for fun.. the fact is, its still unknown why they are there, so imho its pointless to expand such speculative discussion unless you have something physically or programmatically proven.
-
Why would Rigol buy and place SMA mem chips onto the board if they are not used at all? Maybe the mem devices in 900 are just dummy chips?
by any stretch, i cannot imagine why some designer will put 2 of them on pcb and connect traces and resistors to fpga just for fun..
I had offered one possible explanation. Any thoughts on that?
I think it is entirely possible that the RAM is unused (at this time). I have speculated earlier that Rigol had originally designed it in to store the digital data, providing extra capacity and extra bandwidth for these. But ran into problems, maybe routing congestions in the FPGA, and decided to share the main RAM between analog and digital data, as a fallback solution. Which would explain the somewhat embarrassing reduction of the analog sampling rate when the digital channels are used.
Edit: Maybe Rigol are still hoping to eventually enable the extra RAM, by fixing/improving the FPGA configuration for the DHO900. They have not updated the datasheet to make the reduced analog sampling rate in LA mode official and final.
-
Here's a link I found to view replacement RAM on the manufacturer's website https://www.gigadevice.com.cn/technical-resource/dram-cross-reference?wd=mt41k256m16tw-093 (https://www.gigadevice.com.cn/technical-resource/dram-cross-reference?wd=mt41k256m16tw-093)
-
ko attached as txt file
my local MD5
58070b2e6c5ced96ef685e17fb019192 1000-4000v00.02.11.pwm_fan.ko.txt
So it does create an entry under /sys/class/hwmon, and there is indeed a "pwm1" control file, but whatever value you write to it, it has no effect, even if you write "0", which would normally stop the fan.
This driver may be for a different chip, or there may be no chip at all, or the module may need some options to recognize what the DHO800/900 have.
I wonder if there's a way to run lm-sensors on android... It has a sensors-detect tool that scans hardware for the presence of any of the supported chips. Need to search on this.
-
So it does create an entry under /sys/class/hwmon, and there is indeed a "pwm1" control file, but whatever value you write to it, it has no effect, even if you write "0", which would normally stop the fan.
This driver may be for a different chip, or there may be no chip at all, or the module may need some options to recognize what the DHO800/900 have.
The larger models, DHO1000 and 4000, do provide PWM control for the fan on the hardware and driver level. The current firmware always sets it to 100%, but a slower fan speed can be set via the startup batch files. Maybe the driver installed on the DHO800 is a leftover from porting the firmware, but is not actually supported in hardware?
-
I think it is entirely possible that the RAM is unused (at this time). I have speculated earlier that Rigol had originally designed it in to store the digital data, providing extra capacity and extra bandwidth for these. But ran into problems, maybe routing congestions in the FPGA, and decided to share the main RAM between analog and digital data, as a fallback solution. Which would explain the somewhat embarrassing reduction of the analog sampling rate when the digital channels are used.
if this speculation/possibility is true:
1) then they dont have to populate the extra RAM on new currently produced DHO900 series.
2) or... the extra ram got some possible use anyway, if not now, then in the future. just wait for FW update.
either way, they were not put there just for fun (or mere decoration) in the first place.
-
Looking at some schematics with DDR3 and tracing connections looks like only pins E7 D3 F3 G3 C7 B7 are individual connected to CPU, in our case FPGA.
So if measuring on unpopulated place on this pins and find that is not connected then may be dummy chips.
If there are some readings then PCB have traces from unpopulated place to FPGA but that not means that if soldered will be used.
I think we need to compare content of SPI flash chip between models.
https://www.eevblog.com/forum/blog/eevblog-1563-new-$389-12bit-rigol-dho800-scope-teardown/msg5046301/#msg5046301 (https://www.eevblog.com/forum/blog/eevblog-1563-new-$389-12bit-rigol-dho800-scope-teardown/msg5046301/#msg5046301)
Looking at boot log of FPGA and at BOOT.bin from latest firmware and seems to be match on partition addresses and checksums.
Don't know what version was on Dave scope at that date and I search for older firmware and I found one in which BOOT.bin(from DHO800_DHO900(Software)UpdateV00.01.00) is different but partition addresses and checksums are identical.
So either checksums are dummy or are for something else.
value offset
Partition Number: 1
Image Word Len: 0x000D6468 0x00000CC0 ?
Data Word Len: 0x000D6468 0x00000CC4 ?
Partition Word Len: 0x000D6468 0x00000CC8 ?
Load Addr: 0x00000000 0x00000CCC ?
Exec Addr: 0x00000000 0x00000CD0 ?
Partition Start: 0x000045D0 0x00000CD4
Partition Attr: 0x00000020 0x00000CD8
Section Count: 0x00000001 0x00000CDC ?
Partition Checksum Offset: 0x00000000 ` 0x00000CE0 ?
Unknown 0x00000250 0x00000CE4
Unknown 0x00000000 0x00000CE8
Unknown 0x00000000 0x00000CEC
Unknown 0x00000000 0x00000CF0
Unknown 0x00000000 0x00000CF4
Unknown 0x00000000 0x00000CF8
Checksum: 0xFFD78A86 ` 0x00000CFC
Partition Number: 2
Image Word Len: 0x00003002 0x00000D00 ?
Data Word Len: 0x00003002 0x00000D04 ?
Partition Word Len: 0x00003002 0x00000D08 ?
Load Addr: 0xFFFF0000 0x00000D0C ?
Exec Addr: 0xFFFF0000 0x00000D10 ?
Partition Start: 0x000DAA40 0x00000D14
Partition Attr: 0x00000010 0x00000D18
Section Count: 0x00000001 0x00000D1C
Partition Checksum Offset: 0x00000000 ` 0x00000D20 ?
Unknown 0x00000260 0x00000D24
Unknown 0x00000000 0x00000D28
Unknown 0x00000000 0x00000D2C
Unknown 0x00000000 0x00000D30
Unknown 0x00000000 0x00000D34
Unknown 0x00000000 0x00000D38
Checksum: 0xFFF3C348 0x00000D3C
Partition Number: 0
Image Word Len: 0x00004002 0x00000C80 ?
Data Word Len: 0x00004002 0x00000C84 ?
Partition Word Len: 0x00004002 0x00000C88 ?
Load Addr: 0x00000000 0x00000C8C ?
Exec Addr: 0x00000000 0x00000C90 ?
Partition Start: 0x000005C0 0x00000C94
Partition Attr: 0x00000010 0x00000C98
Section Count: 0x00000001 0x00000C9C ?
Partition Checksum Offset: 0x00000000 ` 0x00000CA0 ?
Unknown 0x00000240 0x00000CA4
Unknown 0x00000000 0x00000CA8
Unknown 0x00000000 0x00000CAC
Unknown 0x00000000 0x00000CB0
Unknown 0x00000000 0x00000CB4
Unknown 0x00000000 0x00000CB8
Checksum: 0xFFFF37E8 0x00000CBC
-
Looking at some schematics with DDR3 and tracing connections looks like only pins E7 D3 F3 G3 C7 B7 are individual connected to CPU, in our case FPGA.
So if measuring on unpopulated place on this pins and find that is not connected then may be dummy chips.
If there are some readings then PCB have traces from unpopulated place to FPGA but that not means that if soldered will be used.
I think we need to compare content of SPI flash chip between models.
https://www.eevblog.com/forum/blog/eevblog-1563-new-$389-12bit-rigol-dho800-scope-teardown/msg5046301/#msg5046301 (https://www.eevblog.com/forum/blog/eevblog-1563-new-$389-12bit-rigol-dho800-scope-teardown/msg5046301/#msg5046301)
Looking at boot log of FPGA and at BOOT.bin from latest firmware and seems to be match on partition addresses and checksums.
Don't know what version was on Dave scope at that date and I search for older firmware and I found one in which BOOT.bin(from DHO800_DHO900(Software)UpdateV00.01.00) is different but partition addresses and checksums are identical.
So either checksums are dummy or are for something else.
value offset
Partition Number: 1
Image Word Len: 0x000D6468 0x00000CC0 ?
Data Word Len: 0x000D6468 0x00000CC4 ?
Partition Word Len: 0x000D6468 0x00000CC8 ?
Load Addr: 0x00000000 0x00000CCC ?
Exec Addr: 0x00000000 0x00000CD0 ?
Partition Start: 0x000045D0 0x00000CD4
Partition Attr: 0x00000020 0x00000CD8
Section Count: 0x00000001 0x00000CDC ?
Partition Checksum Offset: 0x00000000 ` 0x00000CE0 ?
Unknown 0x00000250 0x00000CE4
Unknown 0x00000000 0x00000CE8
Unknown 0x00000000 0x00000CEC
Unknown 0x00000000 0x00000CF0
Unknown 0x00000000 0x00000CF4
Unknown 0x00000000 0x00000CF8
Checksum: 0xFFD78A86 ` 0x00000CFC
Partition Number: 2
Image Word Len: 0x00003002 0x00000D00 ?
Data Word Len: 0x00003002 0x00000D04 ?
Partition Word Len: 0x00003002 0x00000D08 ?
Load Addr: 0xFFFF0000 0x00000D0C ?
Exec Addr: 0xFFFF0000 0x00000D10 ?
Partition Start: 0x000DAA40 0x00000D14
Partition Attr: 0x00000010 0x00000D18
Section Count: 0x00000001 0x00000D1C
Partition Checksum Offset: 0x00000000 ` 0x00000D20 ?
Unknown 0x00000260 0x00000D24
Unknown 0x00000000 0x00000D28
Unknown 0x00000000 0x00000D2C
Unknown 0x00000000 0x00000D30
Unknown 0x00000000 0x00000D34
Unknown 0x00000000 0x00000D38
Checksum: 0xFFF3C348 0x00000D3C
Partition Number: 0
Image Word Len: 0x00004002 0x00000C80 ?
Data Word Len: 0x00004002 0x00000C84 ?
Partition Word Len: 0x00004002 0x00000C88 ?
Load Addr: 0x00000000 0x00000C8C ?
Exec Addr: 0x00000000 0x00000C90 ?
Partition Start: 0x000005C0 0x00000C94
Partition Attr: 0x00000010 0x00000C98
Section Count: 0x00000001 0x00000C9C ?
Partition Checksum Offset: 0x00000000 ` 0x00000CA0 ?
Unknown 0x00000240 0x00000CA4
Unknown 0x00000000 0x00000CA8
Unknown 0x00000000 0x00000CAC
Unknown 0x00000000 0x00000CB0
Unknown 0x00000000 0x00000CB4
Unknown 0x00000000 0x00000CB8
Checksum: 0xFFFF37E8 0x00000CBC
But no one has the contents of the SPI flash chip :-// |O :-
-
Just did some checks.
Hard to measure under bga chips.
Just poke on external balls for better result need to desolder actual chip.
First I look at pins E7 D3 F3 G3 C7 B7 of not mounted chips, good news is there are some readings in diode mode on multimeter so this pins are connected somewhere.
Pins T3 T7 T8 (address line A13 A14 A8 ) seems to be connected via some resistors (that line of resistors under GDP2BFLM-CA) to their corespondent on GDP2BFLM-CA mounted chip
But T2 (reset) seems to be connected somewhere else or is connected via a higher value resistor.
On address lines value of resistor was around 43 ohms
Also pins A2 A3 A7 (data lines of not mounted chips) doesn't seems to be connected to their corespondent on mounted chip or are connected via a higher value resistor.
In simple words.
PCB seems to have tracks for missing DDR3 chips.
Address lines seems to be common for all three chips.
Data lines seems at first that are not common for DDR3 chips but are connected somewhere.
Reset also seems like is not shared for all chips.
So I'll order 3 MT41K256M16TW-093 and replace GDP2BFLM-CA and if all OK populate also missing chips.
It will take a while until that.
Also take a dump of that 25Q128.
Need to do some comparation.
I don't know on what version is my scope since in about is only 00.01.01
Now let's hope that someone will upload one from other models with more RAM
-
Just did some checks.
Hard to measure under bga chips.
Just poke on external balls for better result need to desolder actual chip.
First I look at pins E7 D3 F3 G3 C7 B7 of not mounted chips, good news is there are some readings in diode mode on multimeter so this pins are connected somewhere.
Pins T3 T7 T8 (address line A13 A14 A8 ) seems to be connected via some resistors (that line of resistors under GDP2BFLM-CA) to their corespondent on GDP2BFLM-CA mounted chip
But T2 (reset) seems to be connected somewhere else or is connected via a higher value resistor.
On address lines value of resistor was around 43 ohms
Also pins A2 A3 A7 (data lines of not mounted chips) doesn't seems to be connected to their corespondent on mounted chip or are connected via a higher value resistor.
In simple words.
PCB seems to have tracks for missing DDR3 chips.
Address lines seems to be common for all three chips.
Data lines seems at first that are not common for DDR3 chips but are connected somewhere.
Reset also seems like is not shared for all chips.
So I'll order 3 MT41K256M16TW-093 and replace GDP2BFLM-CA and if all OK populate also missing chips.
It will take a while until that.
Also take a dump of that 25Q128.
Need to do some comparation.
I don't know on what version is my scope since in about is only 00.01.01
Now let's hope that someone will upload one from other models with more RAM
:-+ :-+ :-+
-
Comparing dump FPGA_SPI_DHO804.bin with files result
0x00000000 - 0x00376907 something size 0x376908
0x00376908 - 0x003FFFFF blank , FF's only
0x00400000 - 0x00776907 is BOOT.bin from FPGA folder size 0x376908
0x00776908 - 0x007FFFFF blank , FF's only
0x00800000 - 0x00B76907 is BOOT_SelfTest.bin from FPGA folder size 0x376908
0x00B76908 - 0x00FFFFFF blank , FF's only
So only area 0x00000000 - 0x00376907 contain something can't identify.
Looks similar to other files, maybe old version of BOOT.bin or maybe something used for FPGA initialization, who knows?
This may be those three partitions from log messages, partition 1 is BOOT.bin, partition 2 is BOOT_SelfTest.bin and maybe partition 0 is that unknown from 0x0 - 0x376908
-
So only area 0x00000000 - 0x00376907 contain something can't identify.
Looks similar to other files, maybe old version of BOOT.bin or maybe something used for FPGA initialization, who knows?
Might be the "factory default" FPGA configuration, which always stays in there as a fallback?
-
I already asked in another post what the hidden DDR functions are in the oscilloscope menu. If I may repeat again, what are these hidden settings, especially for DDR?
-
It may be
from reload_fpga.sh
is declared as option for --default command option
default_fw_path=/rigol/FPGA/BOOT.bit
default_download_addr=0x000000
But there is no BOOT.bit only bin
bit file is SPU_H12S1.bit I don;t know what is used for.
Also looking at that script I see that after doing and inserting xdma.ko module check for a file and based on that set FPGA boot address
-
Now let's hope that someone will upload one from other models with more RAM
DHO914 (with 924 vendor.bin)
-
It may be
from reload_fpga.sh
is declared as option for --default command option
default_fw_path=/rigol/FPGA/BOOT.bit
default_download_addr=0x000000
But there is no BOOT.bit only bin
bit file is SPU_H12S1.bit I don;t know what is used for.
Also looking at that script I see that after doing and inserting xdma.ko module check for a file and based on that set FPGA boot address
That script is jacked in some ways. It appears Rigol took some other script and just jacked it up to "work" with the GEL update script.
the syntax has $1 and $2 as args
Syntax is $1 only , it must be "--default", or you must pass actual $1 and $2
$1 = --default will run the update on the default addr using "BOOT.bit". I simply cp-paste BOOT.bin to BOOT.bit and it works fine.
$1 and $2 args (file and address) and the script uses those for spi2erase and spi2flash and spi2boot, using the $2 address for boot and in setprop
However, if I run script from FPGA dir, passing "BOOT.bin 0x400000" as args, getprop for boot addr still shows 0x00000
spi2flash wont accept "0x000000" as addr, err's with "must be at least 0x400000 (4MB)". So it's not clear to me how default in script is "0x000000".
spi2flash addr arg must be how big space to flash into, does not appear where to park the start of the flash image. Which is interesting because of the FPGA boot addr found in the startup script in /rigol/shell/
If I try and flash BOOT.bin into addr arg 0x800000, the running system will panic and reboot. Probably have stepped on xdma0 in doing that flash, which I assume the tool padded out to 8MB.
So, some more digging in this area is needed.
-
Thanks! @empeka
Is your DHO914 with 3 DDR3 RAM chips?
Compared and
0x00400000 - 0x00776907 is BOOT.bin from FPGA folder size 0x376908
0x00776908 - 0x007FFFFF blank , FF's only
0x00800000 - 0x00B76907 is BOOT_SelfTest.bin from FPGA folder size 0x376908
0x00B76908 - 0x00FFFFFF blank , FF's only
are identical with my DHO804
But area 0x00000000 - 0x00376907 many differences.
-
The decompiles SMALI files are in the zips I posted back a few pages. APKTOOL decompiles of all 3 or the Rigol APK's (web scope launcher). Edit the SMALI files all day if you like.
Here's what the .com.rigol.scope MainActivity looks like. attached as .smail.txt
Yes, thank you, I saw your message with a link to a decompiled application, but to be honest, I’m not yet sure that I’m ready to dive even into Java, not to mention SMALI :) The last time I dealt with Java was about 12 years ago :))
However, I am not sure you need to edit SMALI files. The process is to code in Java, compile it, convert to dex using Android dx tool, dex --> smali using baksmali tool
Read these links
https://stackoverflow.com/questions/29051781/convert-java-file-to-smali-file#29052019
https://payatu.com/blog/an-introduction-to-smali/
I have seen many reports that the Java code obtained during the decompilation process has inaccuracies and obvious errors. For example, a function may contain a return statement first and then the function code itself. I'm afraid that it will be almost impossible to find and fix all such jambs. At the same time, SMALI has code that matches the application exactly. In addition, I have come across mentions that when compiling from Java, some kind of fiddling is necessary with the external dependencies to be plugged in, or rather with their versions. But here I'm not sure, because... I haven't studied this issue in depth. In fact, the first reason is already quite enough to be very skeptical about assembling from decompiled Java sources :)
I think I have a method to edit some in basic APK (java) stuff. Not anything in the .so C files (not yet).
So, maybe I try to change CH1 to be "not yellow" ?
If we can achieve that then we know we can edit and run mods.
-
Thanks! @empeka
Is your DHO914 with 3 DDR3 RAM chips?
Compared and
0x00400000 - 0x00776907 is BOOT.bin from FPGA folder size 0x376908
0x00776908 - 0x007FFFFF blank , FF's only
0x00800000 - 0x00B76907 is BOOT_SelfTest.bin from FPGA folder size 0x376908
0x00B76908 - 0x00FFFFFF blank , FF's only
are identical with my DHO804
But area 0x00000000 - 0x00376907 many differences.
It is the upper part of the address space that is responsible for initializing FPGA modules!
-
Thanks! @empeka
Is your DHO914 with 3 DDR3 RAM chips?
Compared and
0x00400000 - 0x00776907 is BOOT.bin from FPGA folder size 0x376908
0x00776908 - 0x007FFFFF blank , FF's only
0x00800000 - 0x00B76907 is BOOT_SelfTest.bin from FPGA folder size 0x376908
0x00B76908 - 0x00FFFFFF blank , FF's only
are identical with my DHO804
But area 0x00000000 - 0x00376907 many differences.
Perhaps this space is the FPGA bootloader code? Like an MBR record for the FPGA?
The start script uses 0x000000 as FPGA boot address when calling spi2boot
Also noted, the update GEL scripts do not flash in the BOOT_SelfTest.bin file. Someone please dbl-check.
-
I already asked in another post what the hidden DDR functions are in the oscilloscope menu. If I may repeat again, what are these hidden settings, especially for DDR?
Is this from a native 924?
What hardware type # is the device?
My 804 runs as a 914, but I don't see such items in any menu. FW 00.01.02.00.00
-
It is the upper part of the address space that is responsible for initializing FPGA modules!
What makes you think so?
Not true for the Xilinx FPGAs I have used.
-
Looking at some schematics with DDR3 and tracing connections looks like only pins E7 D3 F3 G3 C7 B7 are individual connected to CPU, in our case FPGA.
So if measuring on unpopulated place on this pins and find that is not connected then may be dummy chips.
If there are some readings then PCB have traces from unpopulated place to FPGA but that not means that if soldered will be used.
I think we need to compare content of SPI flash chip between models.
How can you ID all the traces on PCB, wont some be in multi-layer pcb?
-
I already asked in another post what the hidden DDR functions are in the oscilloscope menu. If I may repeat again, what are these hidden settings, especially for DDR?
Is this from a native 924?
What hardware type # is the device?
My 804 runs as a 914, but I don't see such items in any menu. FW 00.01.02.00.00
I have an 804. If you press "About" three times you will enter debug mode.
-
It is the upper part of the address space that is responsible for initializing FPGA modules!
What makes you think so?
Not true for the Xilinx FPGAs I have used.
The GEL file update scripts setprop to 0x000000
The rigol start script checks the value and uses it.
fpga_boot_addr=$(getprop persist.rigol.fpga.boot.addr)
if [[ x"${fpga_boot_addr}" == x"" ]]; then
fpga_boot_addr=0x000000
/rigol/tools/spi2boot ${fpga_boot_addr}
-
@Aleksandr
I think is only for some testing
Translated is
starting address length
document name
document path
save load
I think load some file into memory then save it then you need to compare and if identical then OK if not identical then problems.
@Randy222
I take a look on schematics not on PCB and identified that pins are alone connected to another chip, and not sharing any connection like in case of data and address and clock lines that are common between chips.
As for what I measure on PCB was only on edge of chip inserting thin wire attached to multimeter probe under chip and on pads where was missing chips.
-
Is your DHO914 with 3 DDR3 RAM chips?
yes, 3* K4B4G1646E-BYMA
-
I think I have a method to edit some in basic APK (java) stuff. Not anything in the .so C files (not yet).
So, maybe I try to change CH1 to be "not yellow" ?
If we can achieve that then we know we can edit and run mods.
Yes, such a check will be quite sufficient :) I don’t have enough free time to do this yet. It would be great if you check it out :)
-
Is your DHO914 with 3 DDR3 RAM chips?
yes, 3* K4B4G1646E-BYMA
Ooooh! This is great! A different memory and more common!!!!
-
I have an 804. If you press "About" three times you will enter debug mode.
"TestModel" is the mode. I don't see anything that says "debug".
-
I think they're fake/defective chips put there to make people think they can't convert their DHO800 into a DHO900 for the price of a connector.
It's as plausible as any other theory I've seen.
-
I already asked in another post what the hidden DDR functions are in the oscilloscope menu. If I may repeat again, what are these hidden settings, especially for DDR?
FYI: there's several extra menu pages/items(plus extra calibration items) that show up once you enable debug mode i.e., "testmodel on".
[attach=1]
[attach=2]
[attach=3]
[attach=4]
[attach=5]
My theory: these menus are for during Design Verification Testing. --like for manually setting/fixing ADC errors, scale, & offsets etc.,
Also, a guess to your Q: After translation, it looks like the DDR menu might be used to Save/Load the DDR3 contents to a file, again as a debug tool.
Maybe the discussion topic today about "populated vs. unpopulated DDR3" could benefit from using this...?tool?
EDIT: Sorry, I took too long to reply, others have chimed in. Decided to post since some may benefit from seeing the menus.
-
Is your DHO914 with 3 DDR3 RAM chips?
yes, 3* K4B4G1646E-BYMA
Ooooh! This is great! A different memory and more common!!!!
AliExpress! DDR3 K4B4G1646E-BYMA 4 Gb
https://sl.aliexpress.ru/p?key=u9Q7Ogb
-
Is your DHO914 with 3 DDR3 RAM chips?
yes, 3* K4B4G1646E-BYMA
Ooooh! This is great! A different memory and more common!!!!
AliExpress! DDR3 K4B4G1646E-BYMA 4 Gb
https://sl.aliexpress.ru/p?key=u9Q7Ogb
Interesting: In comparison of the datasheets, those Samsung parts are:
512 Mb x8 @ 1866 Mbps (didn't bother looking up the timing)
The GigaDevice GDP2BFLM-CA parts are:
256 Mb x16 @ 2133 Mbps with 14-14-14 timing. which matches K4B4G1646D-BYNB from Samsung.
They must've designed a bit of flexibility into the FPGA DDR3 controller.
Ref:
https://semiconductor.samsung.com/us/dram/ddr/ddr3/k4b4g1646e-byma/
https://semiconductor.samsung.com/us/dram/ddr/ddr3/k4b4g1646d-bynb/
-
Is your DHO914 with 3 DDR3 RAM chips?
yes, 3* K4B4G1646E-BYMA
Ooooh! This is great! A different memory and more common!!!!
AliExpress! DDR3 K4B4G1646E-BYMA 4 Gb
https://sl.aliexpress.ru/p?key=u9Q7Ogb
Interesting: In comparison of the datasheets, those Samsung parts are:
512 Mb x8 @ 1866 Mbps (didn't bother looking up the timing)
The GigaDevice GDP2BFLM-CA parts are:
256 Mb x16 @ 2133 Mbps with 14-14-14 timing. which matches K4B4G1646D-BYNB from Samsung.
They must've designed a bit of flexibility into the DDR3 controller.
Take a closer look at the decoding of the markings, K4B4G1646E-BYMA 256Mb x 16. Timing doesn't really matter here, I think.
-
Take a closer look at the decoding of the markings, K4B4G1646E-BYMA 256Mb x 16. Timing doesn't really matter here, I think.
RAS/CAS, Setup, etc timings don't matter in a Dram controller?
BTW: I was going by the Samsung website(links above), comparing it to the decoded part number of the GigaRam parts originally stuffed. Looks like they put slower parts in newer builds. Maybe they were never taking full advantage of the first parts.
-
In order not to look for answers, you can install those chips yourself that you consider necessary
Not sure whether it was meant that way, but your comment comes across as disparaging. Which would be unwarranted, since my question was sincere:
If indeed you populated 2 GB DRAM chips instead of 4 GB, that would obviously be an explanation why they did not work. Since you seem to know what you are doing, I assume you had a good reason to choose those chips. Hence I would hope that you can share that reason. Thanks!
@2084's experiment was worthwhile.
I think 2GB vs 4GB might not absolutely cause it to not work
Point: the controller may not see anything above the 2GB boundary, but the values in the first 2 gigs should've been ok, therefore it probably wouldn't outright fail..
Anyone who has debugged enough Dram designs with a solder short/open on an address line knows what I mean.
Well, the naked lands could have been probed before trying to solder in the chip, yes?
If you have a DHO800 with no chips blocking the pads you can probe them to look for activity at boot up.
PS: Has anybody looked in the boot log for messages to do with extra memory?
Point 1: Most of the signals(address/data) are routed to each of the Drams, only control lines differ, so you have to find the individual Chip Selects, to see if they're being addressed.
Point 2: I thought it was already discussed/agreed that the FPGA DDR3's aren't connected to the system., so how would Android know to look for/log it?
I have not found exactly the same memory chips on sale. But somewhere on the network I saw a debug board with FPGA ZYNQ, on which exactly the same memory chips were installed that I installed in my Rigol. From this I concluded that they must be compatible..... That's all..... Was there such a great need for this explanation of mine???
I say again: I think you did a good job the reflowing the DDR's on your unit. No shorts, and it boots and still works? Fantastic.
The chips you found don't appear to be DDR3L, which may be a problem, since they may not always work well at that lower voltage. (1.35 vs 1.5 volts)
Do you really think that I don’t understand this? Of course, this probability is quite high... But how can you estimate the probability that the guys from Rigol prescribed a strictly defined model of RAM chips in the FPGA?
I think this probability is close to 100%. It makes no sense for them to prescribe settings for dozens of memory chip models.
Actually, it is bad design to NOT plan for several "memory chip models". Horrible., considering how volatile the Ram market is/has been historically. Single sourced parts are avoided at all costs, if the company wants to stay in business for very long.
I think it is entirely possible that the RAM is unused (at this time). I have speculated earlier that Rigol had originally designed it in to store the digital data, providing extra capacity and extra bandwidth for these. But ran into problems, maybe routing congestions in the FPGA, and decided to share the main RAM between analog and digital data, as a fallback solution. Which would explain the somewhat embarrassing reduction of the analog sampling rate when the digital channels are used.
Edit: Maybe Rigol are still hoping to eventually enable the extra RAM, by fixing/improving the FPGA configuration for the DHO900. They have not updated the datasheet to make the reduced analog sampling rate in LA mode official and final.
@ebastler I think you nailed it. This is the most probable scenario. The extra DDR3's aren't in use in the 900's, but probably/hopefully will be used via an update, some time in the future.
-
The extra DDR3's aren't in use in the 900's, but probably/hopefully will be used via an update, some time in the future.
Or (and we all know Rigol, this is most often the case with them) these memory chips will never be used. There is also an assumption that the chips were originally used, but Rigol could not get the entire system to work correctly and disabled them at the last moment in the release firmware. Many PCBs had already been assembled at that time. They didn't remove the chips...
-
There is also an assumption that the chips were originally used, but Rigol could not get the entire system to work correctly and disabled them at the last moment in the release firmware. Many PCBs had already been assembled at that time. They didn't remove the chips...
Those two assumptions are not mutually exclusive. I also hypothesized that a relatively late change to a fallback solution is responsible for the fact that the two unused chips were populated.
But it seems that Rigol continues to populate these chips, even in recent builds (with different DDR3 RAM types); I have not read about any DHO9xx which does not have them. And they have not "downgraded" the datasheet specs so far to reflect the limitations of the fallback solution.
That might suggest that Rigol still hope to fix this via a firmware update. Where "hoping" would, of course, not imply a guarantee that it will actually happen... The upcoming SDS800X HD launch should at least give Rigol some motivation to up their game!
-
What about logic analyzer?
Still no one made hardware upgrade to logic analyzer and compare with models with logic analyzer from factory.
(at least I don't know anyone that confirmed that)
-
The extra DDR3's aren't in use in the 900's, but probably/hopefully will be used via an update, some time in the future.
Or (and we all know Rigol, this is most often the case with them) these memory chips will never be used. There is also an assumption that the chips were originally used, but Rigol could not get the entire system to work correctly and disabled them at the last moment in the release firmware. Many PCBs had already been assembled at that time. They didn't remove the chips...
Which firmware? I don't think Android code in GEL would do it, but the FPGA BOOT.bin code could.
So maybe we need to compare the initial FW BOOT.bin with the latest 00.01.02.00.02 BOOT.bin , which was something I was about to do today.
If there is significant change then maybe that's where use of extra DDR was cut out.
On last few posts:
It was mentioned about FPGA log file on Android. This file is not from the FPGA, it's log data that comes from std-out std-err from running FPGA related commands "spi2", etc.
It was also mentioned something about using 4GB chip when FPGA only uses 2GB. That's typically ok, the addresser simply won't call out to mem blocks beyond some programmed limit. But I find this an odd method given how flexible FPGA's are, BOOT.bin should just have a mem function for something like get_mem_size(), and then use it. Unless the AMD FPGA itself is made to have 2GB max addressable.
I read app data sheet on the micron DDR mem that was listed some posts back. They make note about using the L mem in the 1.5v space, but no notes about using the 1.5v mem in the 1.3v space. I suspect using 1.5v mem in 1.3v space may cause the mem to not function as expected.
-
I need to get the 1st FW image to compare to, v00.01.00.00.19 2023/07/24 is the initial. Anyonone have this FW zip / link, or just the FPGA BOOT.bin from this version?
But, so far no changes to FPGA BOOT.bin
As for updating FPGA via GEL update, kinda odd they just do it even if BOOT.bin is the same. The update script should 1st check if the old vs new are different, then only spi2flash the FPGA if there's a diff, hash check is easy to do. There's always risk if a push of code goes badly, so don't do it unless you need to. ;)
Also take a look at the attached strings found in BOOT.bin. References to "micron", and the biggest reference to memory (MB, Gb, etc) is "2G Bits".
[roott@localhost DHO]# md5sum BOOT.01.01.00.00.bin
80b92f7ab2b60552737fcf12ddb39bb6 BOOT.01.01.00.00.bin
[roott@localhost DHO]# md5sum BOOT.01.02.00.00.bin
80b92f7ab2b60552737fcf12ddb39bb6 BOOT.01.02.00.00.bin
[roott@localhost DHO]# md5sum BOOT.01.02.00.02.bin
80b92f7ab2b60552737fcf12ddb39bb6 BOOT.01.02.00.02.bin
[root@localhost DHO]#
-
As for updating FPGA via GEL update, kinda odd they just do it even if BOOT.bin is the same. The update script should 1st check if the old vs new are different, then only spi2flash the FPGA if there's a diff, hash check is easy to do. There's always risk if a push of code goes badly, so don't do it unless you need to. ;)
Apparently Rigol has excellent circuit engineers and interface designers. But very bad programmers. And it shows in all their products. It’s interesting that they themselves don’t understand where their weakest point is.
-
@Randy222
I have found one that is different
Don't know what version is, it may be the initial one that was on scope when brand new, since I found it on an backup of one USB pen drive in Rigol FPGA folder.
Need to switch to linux to mount and extract files from sdcard backup I made at that time and compare files.
BOOT_SelfTest.bin is identical
-
@Randy222
I have found one that is different
Don't know what version is, it may be the initial one that was on scope when brand new, since I found it on an backup of one USB pen drive in Rigol FPGA folder.
Need to switch to linux to mount and extract files from sdcard backup I made at that time and compare files.
BOOT_SelfTest.bin is identical
Thanks.
I now using Cutter to do some analysis.
Your bin has 21 functions.
All the others have 24 functions.
I don't know what new or what's changed yet.
-
Just sayin': Nobody claimed that Rigol ever shipped a DHO900 which used that extra RAM.
Oh, and are you sure Cutter can do anything meaningful on FPGA binaries? (That's what you are looking at, right?)
-
Just sayin': Nobody claimed that Rigol ever shipped a DHO900 which used that extra RAM.
Oh, and are you sure Cutter can do anything meaningful on FPGA binaries? (That's what you are looking at, right?)
Cutter appears to dissemble/decompile just fine.
-
Xilinx configuration bitstream files practically cannot be parsed, disassembled, etc. You can only do a byte-by-byte comparison, but you will never know what exactly the two files differ in, what functionality they have.
But even differences in two files will not be proof that the FPGA will have a different configuration; even changing the project synthesis parameters & settings will produce different files with completely identical functionality.
-
I don't know about Cutter, just take a look now.
At firs sight seems is in x64 mode.
I don't think that is FPGA format.
Also file use some unknown for me endianness little endian in dword or 4 bytes ?
Also maxspb69 is right.
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000910 6C 62 73 66 66 6C 65 2E 00 00 00 00 00 00 00 00 lbsffle.........it may be fsblelf
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000950 5F 55 50 53 53 32 31 48 69 62 2E 31 00 00 00 74 _UPSS21Hib.1...tit must be SPU_H12S1.bit
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000990 61 64 70 75 65 2E 65 74 00 00 66 6C 00 00 00 00 adpue.et..fl....is update.elf
-
Cutter appears to dissemble/decompile just fine.
What language does it decompile or disassemble into? ???
Maybe there's code for the on-chip ARM processor somewhere in there. But that's not the FPGA configuration which would drive the DRAM. I would be very surprised if Cutter had anything to say about FPGA configuration data proper.
We have that saying in Germany, "I am looking at it like a pig staring into clockworks." But at least you describe what you see with a lot of conviction.
-
Attached pics from Cutter
-
Yes, that's ARM assembly code, which has nothing to do with the FPGA configuration itself.
-
Yes, that's ARM assembly code, which has nothing to do with the FPGA configuration itself.
That's the FPGA BOOT.bin that comes in DHO GEL package, gets "flashed" using spi2flash.
So what exactly is the FPGA BOOT.bin file ?
-
So what exactly is the FPGA BOOT.bin file ?
I assume it is the FPGA configuration file. But since the FPGA contains an ARM core, among much other stuff, there will (also) be ARM code in there -- unless that is loaded from external ROM separately. You are clearly looking at ARM code there. I assume that there are also proper FPGA configuration data in the .bin file, which Cutter ignores since it can't recognize anything.
If you are not familiar with FPGAs, it may be helpful to read up on them. While the high-level languages used to describe their behavior (Verilog and VHDL) do look somewhat similar to C, the functionality they encode is very different from what a CPU with a sequential program does. Essentially you create a "wired" circuit, made from individual flip-flops, logic lookup tables, and programmable interconnects. This circuit will behave like a hard-wired one, with massively parallel operation of the different parts of the circuit.
The binary configuration file describes (on a rather low "close to the metal" level) how all the internal "switches" in the FPGA matrix are set which select the active interconnects, define the logic tables etc.
-
So what exactly is the FPGA BOOT.bin file ?
I assume it is the FPGA configuration file. But since the FPGA contains an ARM core, among much other stuff, there will (also) be ARM code in there -- unless that is loaded from external ROM separately. You are clearly looking at ARM code there. I assume that there are also proper FPGA configuration data in the .bin file, which Cutter ignores since it can't recognize anything.
If you are not familiar with FPGAs, it may be helpful to read up on them. While the high-level languages used to describe their behavior (Verilog and VHDL) do look somewhat similar to C, the functionality they encode is very different from what a CPU with a sequential program does. Essentially you create a "wired" circuit, made from individual flip-flops, logic lookup tables, and programmable interconnects. This circuit will behave like a hard-wired one, with massively parallel operation of the different parts of the circuit.
The binary configuration file describes (on a rather low "close to the metal" level) how all the internal "switches" in the FPGA matrix are set which select the active interconnects, define the logic tables etc.
Well, you made me go read some.
In this hack thread the mention of the "N25Q128" tells me the spi2flash is flashing this micron serial NOR flash memory. Is this memory in the FPGA ?
In the BOOT.bin I find references to the AMD API stuff:
xqspips_options.c
xdevcfg_intr.c
xqspips.c
xdevcfg.c
AMD API:
https://xilinx.github.io/embeddedsw.github.io/qspips/doc/html/api/xqspips__flash__intr__example_8c.html
https://xilinx.github.io/embeddedsw.github.io/qspips/doc/html/api/xqspips__options_8c.html
-
So what exactly is the FPGA BOOT.bin file ?
I assume it is the FPGA configuration file. But since the FPGA contains an ARM core, among much other stuff, there will (also) be ARM code in there -- unless that is loaded from external ROM separately. You are clearly looking at ARM code there. I assume that there are also proper FPGA configuration data in the .bin file, which Cutter ignores since it can't recognize anything.
If you are not familiar with FPGAs, it may be helpful to read up on them. While the high-level languages used to describe their behavior (Verilog and VHDL) do look somewhat similar to C, the functionality they encode is very different from what a CPU with a sequential program does. Essentially you create a "wired" circuit, made from individual flip-flops, logic lookup tables, and programmable interconnects. This circuit will behave like a hard-wired one, with massively parallel operation of the different parts of the circuit.
The binary configuration file describes (on a rather low "close to the metal" level) how all the internal "switches" in the FPGA matrix are set which select the active interconnects, define the logic tables etc.
Well, you made me go read some.
In this hack thread the mention of the "N25Q128" tells me the spi2flash is flashing this micron serial NOR flash memory. Is this memory in the FPGA ?
In the BOOT.bin I find references to the AMD API stuff:
xqspips_options.c
xdevcfg_intr.c
xqspips.c
xdevcfg.c
AMD API:
https://xilinx.github.io/embeddedsw.github.io/qspips/doc/html/api/xqspips__flash__intr__example_8c.html
https://xilinx.github.io/embeddedsw.github.io/qspips/doc/html/api/xqspips__options_8c.html
@Randy222 FPGA's don't have flash memory(per se), and are almost always loaded/programmed by a BINary file from an external IC. At least that's how they always were when I was designing stuff with them
@ebastler That was a nice brief synopsis re: FPGA
-
Is not in FPGA it is attached to to FPGA via a SPI bus
From that external memory or JTAG (selection made by jumper) FPGA boot and load its configuration etc.
-
Interesting, the spi2flash binary has the BOOT.bin file location-name hardcoded in it.
-
https://docs.xilinx.com/r/en-US/ug1283-bootgen-user-guide/Introduction (https://docs.xilinx.com/r/en-US/ug1283-bootgen-user-guide/Introduction)
Good lecture
-
I was trying to expand my program which reads and writes the FRAM memory to the Serial Flash memory.
By examining the 3 example programs spi2erase, spi2flash and spi2boot I saw that they were using the kernel /dev/spidev1.0 device.
In my naivety I thought that the flash is connected directly to one of the RK3399 chip SPI interfaces which is not true!
The SPI interface is connected to the Zynq-7000 FPGA.
To erase the flash the main CPU writes 6 bytes "\rPROG\r" followed by 4 bytes (MSB) of address followed by 4 bytes (MSB) of length.
To write the flash you have to send 256 byte chunks with 1ms delay in between.
To select the boot image the main CPU writes 6 bytes "\rBOOT\r" followed by 4 bytes (MSB) of address then wait 5 seconds.
As far as I can see there is no way to read back to content of the serial flash (without an external programmer). This chip is connected to the FPGA
and it is the ARM32 inside the FPGA which is responsible for sending commands. Multiple serial flash chip vendors are supported.
If you examine the /rigol/FPGA/BOOT.bin file you can find inside two ARM32 images including vector tables and thumb/32bit instructions:
offset 0x1700 length 0x10008 load_address 0x0
offset 0x36a900 length 0xC008 load_address 0xffff0000
The second one deals with the QSPI flash commands. The Zynq has two ARM cores so my guess is that one core runs this last image and acts as a supervisor
while the other one can be loaded and rebooted. There are plenty of printf/log messages so there must be a serial interface somewhere where these are delivered.
-
It can be assumed that just for two cores of the workstation such a large DDR RAM is needed. For example, one core works with analog inputs of an ADC and a logic analyzer, another core with a generator! Or, another crazy idea, three workstation cores are created, one works with a generator, another with analog inputs of the ADC and the third with a logic analyzer, with each core having its own DDR RAM memory.
-
I hope didn't make any mistakes.
Inside dumped FPGA SPI those are partitions details.
Later edit:
Seems like partition that I counted as 0 is in fact bootloader.
part 0 offset 0x01700
lenght 0x10008
attrib bits Destination device 1: PS
part 1 offset 0x011740
lenght 0x3591A0
attrib bits Destination device 2: PL
part 2 offset 0x36A900
lenght 0x00C008
attrib bits Destination device 1: PS
Destination load address FFFF0000
-
PS refers to the processor part of the FPGA, PL refers to the logical part.
I’m not at all sure that the processor core is used in this case, most likely only the FPGA part is used, and the choice of ZYNC7000 is due to its extreme cheapness and sufficient characteristics for this device. ARTIX would be significantly more expensive.
-
Getting more confused.
There are SoC Boot Images and MPSoC Boot Images.
They have similar layout.
Which is which?
All seems to have same pointers to tables.
All are SoC or MPSoC or one is SoC other MPSoC boot image?
First is SoC and second (BOOT.bin) and third (BOOT_SelfTest.bin) are MPSoC ? Since only latest two are chosen by software and updatable?
-
I see there has been some great progress on hacking these devices, but I have not read the complete thread.
Was curious were are we at regarding the DHO800 hacking?
1. What would be the maximum single channel bandwidth possible? (is 250MHz possible in software?)
2. Also what is the maximum memory depth that could be hacked on a DHO800?
3. Could an external trigger be enabled on 4 channel model?
4. Has anyone managed to attach and use a PLA2216 logic probe?
Br, HVE
-
https://github.com/zelea2/rigol_vendor_bin
I've added a native utility program 'nv-mem' which allows you to read/write/compare the FRAM content and
also covers the functionality of 'spi2erase' 'spi2flash' 'spi2fpga' and 'spi2boot' programs.
This should allow easy experimentation and identification of what's stored in the FRAM.
-
@zelea2 thank you for all the work you have done.
I have two minor comments, the -g option does not work for rigol_vendor_bin and the version number has not been changed. :-+
-
https://github.com/zelea2/rigol_vendor_bin
I've added a native utility program 'nv-mem' which allows you to read/write/compare the FRAM content and
also covers the functionality of 'spi2erase' 'spi2flash' 'spi2fpga' and 'spi2boot' programs.
This should allow easy experimentation and identification of what's stored in the FRAM.
I was about to ask.....
1) what function does the FPGA serve, "what does it do" ? My comment (the value appears to be width to flash and not an actual address in the flash mem, the micron NOR flash notes suggest it must be flashed to nearest 256k, and the bin file is very close to 4M, so the tool will err if the value is less than 0x400000)
Can you breakdown what these commands do
2) spi2flash /rigol/FPGA/BOOT.ini 0x400000
3) spi2boot 0x000000
4) spi2boot 0x400000
I assume spi2flash talks to the flash mem addressable on SPI bus via /dev/spidev1.0 character device, and spi2boot talks to FPGA on SPI bus via same chacaretr device (as seen in ghidra)?
Here's an observation on my non-updated 804, came with FW 00.01.02.00.00
The GEL update script "do_extract.sh" will flash BOOT.bin (only this one file) to "${fpga_download_addr}" , and it will do a "setprop persist.rigol.fpga.boot.addr ${fpga_download_addr}", that variable is set to 0x400000
fpga_download_addr=0x400000
fpga_fw=/rigol/FPGA/BOOT.bin
Now, on my non-updated 804, that property in Android is set to 0x000000, and it is this value that is used in the "start_rigol_app.sh" script using the spi2boot command.
Also odd, the reload_fpga.sh script uses 0x000000 as the default download address used by spi2flash, if you pass "--default" as arg 1, but this script has syntax $1 or $1 and $2. This script also uses flash file "BOOT.bit"
If you try and flash to 0x000000 the spi2fash throws err
This script does not appear to be used during a GEL update. I also find commented reference to "ds7000". #build_out=DS70000Update.GEL, so maybe the reload_fpga.sh is from another platform?
I had also flashed the Test bin to 0x400000, I did not observe any functional diffs after the flashing and spi2boot, or upon reboot of scope.
Also noted: I think Rigol goofed on naming their scripts, "do_extract.sh" actually carries out updating FPGA and APK's, while "do_update.sh" actually carries out unpacking the GEL file.
***********************************************
So, can some of you check the property setting on your scope, and list the value and whether or not you had done a FW GEL update.
getprop persist.rigol.fpga.boot.addr
***********************************************
Another side note: I think it was @zelea2 noted the spi2flash binary file makes reference to use one of the spi devices "/dev/spidev1.0" from Android /dev/. Yes, the linux kernel at boot recognizes two "spi" character devices, so probably like normal the binary tools send serial data to the spi character devies to talk to devices on spi bus. Makes sense.
-
1. What would be the maximum single channel bandwidth possible? (is 250MHz possible in software?)
It (at least my DHO804) shows rise time (using a 74LVC based generator -- not the best possible, but a good bit faster than the scope) of 1.4-1.5 ns, as measured by the scope itself, which should correspond to about 230..300 MHz BW, depending on what formula you use to estimate it. Someone posted about the same numbers obtained using Leo Bodnar's generator earlier.
It would be nice to test the -3db frequency as well, but I don't have a generator capable of creating the required frequency. Anyone?.. :)
2. Also what is the maximum memory depth that could be hacked on a DHO800?
50M.
3. Could an external trigger be enabled on 4 channel model?
There's no dedicated input for this, so you'll need to use one of the channels to feed the trigger signal into, unless the rear aux. out can be used as an input, but it doesn't seem likely, and there's nothing in the UI suggesting that it could be possible.
-
I have two minor comments, the -g option does not work for rigol_vendor_bin and the version number has not been changed. :-+
The -g option doesn't work by itself, you also need -o or -O#
Version is v1.2 I don't see where it isn't changed.
-
I have two minor comments, the -g option does not work for rigol_vendor_bin and the version number has not been changed. :-+
The -g option doesn't work by itself, you also need -o or -O#
Version is v1.2 I don't see where it isn't changed.
Yes, of course everything is OK, I downloaded the release from github incorrectly :palm:
-
https://github.com/zelea2/rigol_vendor_bin
I've added a native utility program 'nv-mem' which allows you to read/write/compare the FRAM content and
also covers the functionality of 'spi2erase' 'spi2flash' 'spi2fpga' and 'spi2boot' programs.
This should allow easy experimentation and identification of what's stored in the FRAM.
Damn it, guy, you are carrying almost the entire successful hacking of an oscilloscope on yourself, a thousand thanks! :) Without you in this thread it would be very sad :)
-
Maybe Rigol should offer Zelea2 a job🤔
-
Some sleuthing.
It appears the character device /dev/pwm_fan is opened by, ........................ --> com.rigol.scope App.
So, now I go hunt down where in the APK is pwm_fan. Perhaps addressable via an 'am' call to an activity.
-
Some sleuthing.
It appears the character device /dev/pwm_fan is opened by, ........................ --> com.rigol.scope App.
So, now I go hunt down where in the APK is pwm_fan. Perhaps addressable via an 'am' call to an activity.
Has anyone looked at the power supply to the fan with an oscilloscope - is it really PWM or constant voltage?
-
Some sleuthing.
It appears the character device /dev/pwm_fan is opened by, ........................ --> com.rigol.scope App.
So, now I go hunt down where in the APK is pwm_fan. Perhaps addressable via an 'am' call to an activity.
Has anyone looked at the power supply to the fan with an oscilloscope - is it really PWM or constant voltage?
It being just a 2-wire fan, if it is PWM power then the red wired would be some sort of PWM drive. I'll need to open the case and scope it.
That's not typical setup of PWM fans for cooling. PWM driven fans usually are 3 or 4 wire, PWM signal sent to the fan.
The other I did notice, platform driver fan53555-regulator , a fairchild i2c addressable buck regulator.
It was stated in teradown that Dave measure 8v. Hmmm, that's an odd voltage, unless his meter was fooled by PWM, or, an i2c regulator is controlling that dc voltage.
-
Has anyone looked at the power supply to the fan with an oscilloscope - is it really PWM or constant voltage?
8V DC, no sign of any switching activity there.
-
Maybe Rigol should offer Zelea2 a job🤔
I do electronics (silicon level) all day long. I don't need another job :D
Home I have the Rigol DHO804, the Hantek DSO5202B, DSCope/C20P/200MHz and my trusty 400MHz Tektronix 2465B.
How many scopes does one need? ???
It's just that this scope is a novelty toy, I have no shortage of much more powerful scopes at work.
-
It was stated in teradown that Dave measure 8v. Hmmm, that's an odd voltage, unless his meter was fooled by PWM, or, an i2c regulator is controlling that dc voltage.
I think it's just regulated down to a fixed 8V DC by something. The Rigol engineers must have chosen this voltage, because the fan noise at a full 12V would have become totally unacceptable, and at 8V it is almost bearable and provides a sufficient air flow for cooling.
I'm now replacing it by an external 120mm fan, and when I open the case again to connect it permanently (it's now connected to a lab PSU), I will try to trace where that internal fan connector is connected, as long as it doesn't require removing the main PCB.
I wonder if a centrifugal fan will be better than the stock one -- maybe someone will eventually try it. I was going to order some 45mm and 50mm models, but eventually decided to whack a 120mm fan on the outside. Nothing is going to beat it for the amount of air flow that it can produce while staying almost silent. The centrifugal ones, however, can likely be a good compromise: no parts hanging on the outside and covering the vesa mount area, and perhaps they will not be so whiny and sound more like the laptop coolers.
-
Maybe Rigol should offer Zelea2 a job🤔
I do electronics (silicon level) all day long. I don't need another job :D
Home I have the Rigol DHO804, the Hantek DSO5202B, DSCope/C20P/200MHz and my trusty 400MHz Tektronix 2465B.
How many scopes does one need? ???
It's just that this scope is a novelty toy, I have no shortage of much more powerful scopes at work.
And Hantek DSO5202B is also a toy and even worse than a rigol. I am very disappointed in Hantek, I have 3 oscilloscopes from Hantek and all of them are simply not close to rigol. There are a lot of errors and brakes, both hardware and software.
-
Some sleuthing.
It appears the character device /dev/pwm_fan is opened by, ........................ --> com.rigol.scope App.
So, now I go hunt down where in the APK is pwm_fan. Perhaps addressable via an 'am' call to an activity.
Has anyone looked at the power supply to the fan with an oscilloscope - is it really PWM or constant voltage?
It being just a 2-wire fan, if it is PWM power then the red wired would be some sort of PWM drive. I'll need to open the case and scope it.
That's not typical setup of PWM fans for cooling. PWM driven fans usually are 3 or 4 wire, PWM signal sent to the fan.
The other I did notice, platform driver fan53555-regulator , a fairchild i2c addressable buck regulator.
It was stated in teradown that Dave measure 8v. Hmmm, that's an odd voltage, unless his meter was fooled by PWM, or, an i2c regulator is controlling that dc voltage.
The Yellow wire in a 3 wire PC fan is for speed sensing by the fan controller chip.
-As it has been for decades. PWM (speed control) comes from the controller chip. IIRC, The 4th wire was sometimes used on a thermistor for local(I.e. inlet/outlet) temp monitoring.
Please refrain from comments like you're an authority on matters you're not fully educated in. ChatGPT AI crap will index this errant info and become even worse than it is.
-
The Yellow wire in a 3 wire PC fan is for speed sensing by the fan controller chip.
-As it has been for decades. PWM (speed control) comes from the controller chip. IIRC, The 4th wire was sometimes used on a thermistor for local(I.e. inlet/outlet) temp monitoring.
Just to clear out any confusion here. In a typical 4-pin computer fan the pinout is as follows:
1 - GND
2 - +12V
3 - open collector/open drain tachometer -- pull it up to pin 2 with a reasonable resistor and you'll get (IIRC) twice your revolution frequency as a square wave signal between this pin and GND
4 - PWM input: 100% RPM if left floating, 0% or minimal RPM if shorted to ground (depends on the fan), intermediate RPM defined by pulse widthduty cycle, where pulses are created by shorting this pin to ground for a certain length of the oscillation period. I'm not sure about the frequency, but ~25 kHz always worked for me. I may probe this pin with a scope inside an actual computer some day to figure it out.
Now, when it comes to computers, some (many?) motherboards can control fan speed not only by utilizing the pin 4 (which leaves the actual speed control to the fan itself), but also by doing DC/DC conversion themselves and powering the fan with a varying, user-adjustable, DC voltage on pin 2. There's no reason why any other equipment wouldn't do it, if necessary. Only the DHO800/900 don't seem to do it. They might be capable of it -- in hardware -- and the 8V level may just be hardcoded somewhere in software, which would make some sense from the R&D and labour-saving standpoint. This remains to be figured out.
-
Some sleuthing.
It appears the character device /dev/pwm_fan is opened by, ........................ --> com.rigol.scope App.
So, now I go hunt down where in the APK is pwm_fan. Perhaps addressable via an 'am' call to an activity.
Has anyone looked at the power supply to the fan with an oscilloscope - is it really PWM or constant voltage?
It being just a 2-wire fan, if it is PWM power then the red wired would be some sort of PWM drive. I'll need to open the case and scope it.
That's not typical setup of PWM fans for cooling. PWM driven fans usually are 3 or 4 wire, PWM signal sent to the fan.
The other I did notice, platform driver fan53555-regulator , a fairchild i2c addressable buck regulator.
It was stated in teradown that Dave measure 8v. Hmmm, that's an odd voltage, unless his meter was fooled by PWM, or, an i2c regulator is controlling that dc voltage.
The Yellow wire in a 3 wire PC fan is for speed sensing by the fan controller chip.
-As it has been for decades. PWM (speed control) comes from the controller chip. IIRC, The 4th wire was sometimes used on a thermistor for local(I.e. inlet/outlet) temp monitoring.
Please refrain from comments like you're an authority on matters you're not fully educated in. ChatGPT AI crap will index this errant info and become even worse than it is.
Nope, a 4w does not typically use 4th wire for temp sensing.
My point was, 3w or 4w fans, are either driven by PWM from the power line, or, in 4w a PWM signal is delivered to the fan.
Most 2w fans are not driven by PWM, but they can be just like a 3w, less any feedback control, but there could be a remote temp sensor, like a diode in a chip somewhere, a discrete diode in specific place, or perhaps even thermocouple junction on PCB.
Most typical 3w and 4w run like the attached pic.
The Fairchild i2c buck regulator outputs DC, variable DC. That could be used to control a fan. But I don't think that is being used on the DHO's. 8vdc sounds like either simple burn 4v through resistor, or, an 8v regulator.
-
PWM driven fans usually are 3 or 4 wire, PWM signal sent to the fan.
Quite often, PWM fan control over two wires is used. Its power supply is simply modulated.
-
Has anyone looked at the power supply to the fan with an oscilloscope - is it really PWM or constant voltage?
8V DC, no sign of any switching activity there.
Multimeter or scope? If scope, did you check several frequencies, or look at any components near the fan connector?
It was stated in teradown that Dave measure 8v. Hmmm, that's an odd voltage, unless his meter was fooled by PWM, or, an i2c regulator is controlling that dc voltage.
I think it's just regulated down to a fixed 8V DC by something. The Rigol engineers must have chosen this voltage, because the fan noise at a full 12V would have become totally unacceptable, and at 8V it is almost bearable and provides a sufficient air flow for cooling.
PWM through a proper RC filter looks exactly like DC..
It may be PWM further upstream, just not at the connector.
BTW: It USED to be common practice in noise abatement to "spin up" 12V fans at their rated voltage, then settle down to ~7-8V for quieter operation.
8vdc sounds like either simple burn 4v through resistor, or, an 8v regulator.
That is far from proper design technique. (referring to the resistor, not regulator)
-
Multimeter or scope? If scope, did you check several frequencies, or look at any components near the fan connector?
Both, but the scope check was admittedly a quick one. However, it was definitely not a PWM signal, at least not an unfiltered one, i.e., not a square wave, but I didn't look for the switching noise or any finer details -- I saw a flat trace at 8V on a DC coupled input and was satisfied with it at that time. I will take a more detailed look, when I open it again to connect the 120mm fan, and I'll also try to see where the fan connector may be connected to.
-
PWM driven fans usually are 3 or 4 wire, PWM signal sent to the fan.
Quite often, PWM fan control over two wires is used. Its power supply is simply modulated.
Noctua puts a PWM drive IC in the fan itself. The IC drives the fan in ideal way, using a PWM signal from some controller. So they claim, etc.
-
FYI, the RK3399 SoC has 4 hardware PWM outputs. On the Fan speed control topic, it might be worthwhile looking for code that drives them.
I seem to recall the fan starts on power up, so maybe it's not under Android control..? I don't recall anyone giving specific timing of the fan power compared to the power rails tho.
-
I seem to recall the fan starts on power up, so maybe it's not under Android control..? I don't recall anyone giving specific timing of the fan power compared to the power rails tho.
I'll definitely need to check this one as well -- it will be a good indicator of whether that voltage is controlled by software or not. But just from the sound of it, it seems like it gets power right when the scope is powered up, and the voltage isn't changing.
-
FYI, the RK3399 SoC has 4 hardware PWM outputs. On the Fan speed control topic, it might be worthwhile looking for code that drives them.
I seem to recall the fan starts on power up, so maybe it's not under Android control..? I don't recall anyone giving specific timing of the fan power compared to the power rails tho.
I find a lot of RK pins in hardware definitions in the OS.
Recall what GPIO pins they are?
-
FYI, the RK3399 SoC has 4 hardware PWM outputs. On the Fan speed control topic, it might be worthwhile looking for code that drives them.
I seem to recall the fan starts on power up, so maybe it's not under Android control..? I don't recall anyone giving specific timing of the fan power compared to the power rails tho.
I find a lot of RK pins in hardware definitions in the OS.
Recall what GPIO pins they are?
Here's what I found with quick check in the datasheet. Will edit if I look/find more.
Pin# Pin Name
AF5 GPIO4_C2/PWM0/VOP0_PWM/VOP1_PWM
M25 GPIO1_B6/PWM3B_IR
M28 GPIO1_C3/PWM2
P25 GPIO0_A6/PWM3A_IR
AL3 GPIO4_C6/PWM1
In case anyone cares: I didn't find any references to PWM or Fan in the PMIC datasheet.
-
PWM pins can only sink/source 3mA, too little for a direct drive. So, if there is any PWM driving that fan from the RK, has to be intermediate fet or igbt or the like.
But, it was stated, the 8v appears to be 8vdc, so PWM to the fan less likely.
I will however seek out the RK PWM pins in Android.
-
PWM pins can only sink/source 3mA, too little for a direct drive. So, if there is any PWM driving that fan from the RK, has to be intermediate fet or igbt or the like.
And that has to be easy enough to see on the board, unless, of course, it hides under the heat sink. Will look for it!
-
PWM pins can only sink/source 3mA, too little for a direct drive. So, if there is any PWM driving that fan from the RK, has to be intermediate fet or igbt or the like.
But, it was stated, the 8v appears to be 8vdc, so PWM to the fan less likely.
I will however seek out the RK PWM pins in Android.
It wasn't said(or even inferred) that it would be directly driven. Smart system designers use a buffer, because shit happens.., and fans get clogged.
BTW: "it was stated" PWM thru a low pass filter looks like DC. And Multimeters aren't really useful for PWM signals. :-DMM -Fundamental electronics.
But, given all the other SMPS they have peppered thru this design, I wouldn't be surprised if they did one just for the fan.
And that has to be easy enough to see on the board, unless, of course, it hides under the heat sink. Will look for it!
Might be better to work backwards from the fan connector.
-
Okay, so here's what I have found (or rather not found) so far.
There are no traces coming from the fan connector visible on the upper side of the board whatsoever. There is also nothing that I probed around the connector that would measure 8V above ground (but I haven't probed everything -- only those spots where I didn't risk shorting things). So the fan supply circuitry must all be sitting on the back side of the board, and I am not willing to remove it, so we'll need to wait until someone else does it, or we can try to look for it in Dave's teardown video (https://youtu.be/KQF4UzLPpr0?t=733).
Now, main rail is 15V, fan is running at 8V, so that is a 7V drop at what I estimate to be 80-90 mA, or about 600 mW, if a linear regulator was used, and that would mean a component of a substantial size to handle this heat (not a SOT23 one at least). There seem to be nothing like that around the fan connector, or, from what I see in Dave's video, on the back side, either. So, most likely, this 8V line comes from some switching converter, but if so, its output is filtered very well.
I probed the fan power with my old handheld scope, which is lacking in many respects, but it would allow to see noise up to a few MHz and a few tens of mV p-p. It didn't show it. All it displayed was the fan's interruption of power consumption that happens four times per revolution and seen as short voltage spikes on the fan power rail (AC coupled input is used here):
[attachimg=1]
1/15.5ms * 60 ~= 3870 rpm, and this is exactly what I measured with a laser tachometer: the stock fan runs at ~3850 rpm. As I hold the rotating fan to slow it down, the spikes on the displayed waveform become spaced further apart.
Interestingly, the 120mm fan that I'm replacing the stock one with does the same thing: briefly break the circuit, or stop drawing current otherwise, exactly four times per revolution. I wonder what's that. Might be a result of how they are made electromechanically, or some stall detection and prevention circuitry. I have no clue.
The delay between the main rail and fan 8V rail being powered on when the soft power-on button is pressed is about 500-700 ms, the fan is powered after the main rail. It jumps to 8V from the start and sits there -- no 12V startup pulse or anything like that.
-
How many scopes does one need? ???
Must I be honest?
1 Hameg, 3 Teks,2 Hantek, 1 Owon, 1 Zeewei, 2 Fnirsi, 1 Zoyi, 1 Dreamscope and some 5 more analogs in the basement.
-
Okay, so here's what I have found (or rather not found) so far.
There are no traces coming from the fan connector visible on the upper side of the board whatsoever. There is also nothing that I probed around the connector that would measure 8V above ground (but I haven't probed everything -- only those spots where I didn't risk shorting things). So the fan supply circuitry must all be sitting on the back side of the board, and I am not willing to remove it, so we'll need to wait until someone else does it, or we can try to look for it in Dave's teardown video (https://youtu.be/KQF4UzLPpr0?t=733).
I went to disassemble my oscilloscope :)
-
This is what I was able to discover about the fan power supply after fiddling around for a while.
First, a general view of the board from both sides. The area we are interested in is highlighted in yellow:
[attach=3]
[attach=4]
One of the connector pins is marked with a plus sign:
[attach=6]
Larger photographs of areas where I was able to detect circuits from the fan contacts. I highlighted the connections with the “plus” contact in red, and the connections with the second contact in blue.
[attach=1]
[attach=2]
The “plus” contact here is clearly general, because many sections of the board are connected to this circuit. But this does not seem to be a positive circuit, because diode "A" on the back of the board is connected to this circuit by the anode.
I found very few connections to the second contact. And to be honest, I didn’t fully understand what was what. On the reverse side there is a chip “B”, next to which there are two resistors, clearly forming a voltage divider. A “blue” circuit comes to one of the resistors, and the middle point between the resistors is connected to pin 2 of the chip (highlighted in yellow). It looks like this chip is a stepdown converter. The inductance next to it is also connected to the chip (both terminals). There is no connection between the fan contact and this inductance. So it’s still not clear where the fan is powered from. Although the resistor divider hints that this chip should power the fan.
Here are larger pictures of these areas:
[attach=5]
[attach=7]
My oscilloscope may be disassembled for some time, so if I need to check something or take a photo, I can do it before I assemble it :)
-
One of the connector pins is marked with a plus sign:
And in reality it is a minus! It is connected to ground rail -- test and you'll see continuity between it and chassis. The other one is the +8V rail.
From what you showed on the pictures it does look like it's powered from a buck converter.
-
Based on the above photos and measurements (if they were carried out correctly), I assume that the right resistor in the divider is voltage feedback, its resistance should be around 1kOhm, and reducing the value of this resistor will lead to a decrease in fan speed.... .
As for diodes connected in reverse polarity, this is standard practice in circuits with an inductive load (a cooler is precisely an inductive load). It protects against bursts of self-induction....
-
Thanks for the investigative work everyone., Just a quick FYI: Dave's teardown pictures are here (https://flic.kr/s/aHBqjATvZW) on his Flickr. Where you can find really nice photos of each main area of the scope. Even some closeups. You can also download the original resolution(6K x 3.5K)
I've traced many signals and looked up several components thanks to his great early work.
-
How many scopes does one need? ???
Must I be honest?
1 Hameg, 3 Teks,2 Hantek, 1 Owon, 1 Zeewei, 2 Fnirsi, 1 Zoyi, 1 Dreamscope and some 5 more analogs in the basement.
There are support groups for people like you.
...and me :-BROKE
-
Thanks for the investigative work everyone., Just a quick FYI: Dave's teardown pictures are here (https://flic.kr/s/aHBqjATvZW) on his Flickr. Where you can find really nice photos of each main area of the scope. Even some closeups. You can also download the original resolution(6K x 3.5K)
I've traced many signals and looked up several components thanks to his great early work.
Wow... thank you very much...
How did I miss this... :clap: :clap: :clap:
-
Thanks for the investigative work everyone., Just a quick FYI: Dave's teardown pictures are here (https://flic.kr/s/aHBqjATvZW) on his Flickr. Where you can find really nice photos of each main area of the scope. Even some closeups. You can also download the original resolution(6K x 3.5K)
I've traced many signals and looked up several components thanks to his great early work.
I wish I could find such good photos from series DHO900! Actually it would be great.
-
And in reality it is a minus! It is connected to ground rail -- test and you'll see continuity between it and chassis. The other one is the +8V rail.
Yes, that's all true :)
From what you showed on the pictures it does look like it's powered from a buck converter.
I think so too.
Based on the above photos and measurements (if they were carried out correctly), I assume that the right resistor in the divider is voltage feedback, its resistance should be around 1kOhm, and reducing the value of this resistor will lead to a decrease in fan speed.... .
This is what my multimeter showed on these resistors. 53.85 and 9.48 kOhm. The multimeter is normal, you can trust it within 1% :)
As for diodes connected in reverse polarity, this is standard practice in circuits with an inductive load (a cooler is precisely an inductive load). It protects against bursts of self-induction....
Yes, I know.
-
I wish I could find such good photos from series DHO900! Actually it would be great.
I do as well. The only one i've seen is from an earlier post from someone trying to identify components.
[attach=1]
-
Lol, I just discovered this nonsense on my oscilloscope board :)) A drop of solder shorted one of the capacitors and almost shorted the second capacitor. These are blocking capacitors under the processor. Rigol, where is your quality control? :))
-
Well, I’ll probably do an analog adjustment of the fan speed... I happen to have good NTC thermistors of different ratings.....
-
Well, I’ll probably do an analog adjustment of the fan speed... I happen to have good NTC thermistors of different ratings.....
Old school, I LOVE IT! :clap: I need similar, and think I even have a 80mm fan that has a thermistor on it. Now where did I put that box?
-
Another example of an external fan mod.
Used one of those "slim" form factor 120 mm fans (15 mm thick). Settled on 5.4V / 1030 RPM after a bit of experimenting. Voltage regulation is achieved by two 24 Ohm resistors connected in series with the fan. Added a 560 uf, 10V polymer electrolytic cap to reduce the 4x RPM ripple that I mentioned above -- might be unnecessary, but I don't want any ripple inside the scope, where it can be avoided.
It is really quiet, only becomes audible when you get closer than ~50-60 cm, and that's in a quiet environment. Temps are ~4 deg.C lower than they were with the stock fan (it's now showing 52 CPU / 48 CPU ambient at 22 deg.C in the room). By running the fan at full 8V the temps are reduced by further 4-5 degrees, but the added noise makes it absolutely not worth it.
Overall look:
[attachimg=1]
Mounting: M4x8 bolts. Anything longer won't be possible to get into the gap, and these are just the right size for this fan. Of course I had to drill four new 4.5mm holes for them spaced 100 mm x 100 mm.
[attachimg=2]
Beware of the clearance between the fan's outer lower edge and the surface on which the scope stands! This is one of the reasons to prefer the slim form factor fans. In this case, the required clearance was achieved with the new holes placed at the same distance from the lower edge as the original ones. This placement also provides enough room for the carrying handle to remain usable, and the part of the fan protruding above the scope's housing is just so narrow that the blades can't be reached from inside, unless you have extra thin fingers and/or try really hard.
And yes, the back lid's mounting screw holes remain reachable with the fan installed. No need to remove it to get inside the scope.
[attachimg=3]
[attachimg=4]
[attachimg=5]
Power cable routing:
[attachimg=6]
p.s. Initially I wanted the fan to suck air out of the scope instead of blowing it in, but, alas, this fan (and I would guess that it's a general rule) is only good at pushing, not pulling. It was totally helpless when it tried to pull air through those vent holes: a lot of noise, very little performance. Pushing air into the scope, on the other hand, works really well.
-
Well, I’ll probably do an analog adjustment of the fan speed... I happen to have good NTC thermistors of different ratings.....
And there's plenty of room inside even for a THT control board (within reason of course). You mean automatic temperature-controlled fan speed adjustment? This sounds like a viable idea, but for best results, I guess, the temperature sensor has to be screwed onto the heat sink, or otherwise put into tight thermal contact with it, and preferably on the bottom side of the heat sink to prevent air flow from spoiling the measurement.
-
..., the temperature sensor has to be screwed onto the heat sink, or otherwise put into tight thermal contact with it, and preferably on the bottom side of the heat sink to prevent air flow from spoiling the measurement.
Only this way and no other way.
-
Based on my observations using a thermal imaging camera, the board itself is subject to heating no less than the radiator, which means the NTC thermistor can be mounted on the reverse side, for example, under the FPGA chip, and there will be no protruding wires. Regarding the method of controlling the rotation speed of the cooler, I meant replacing one of the resistors in the resistive divider with an NTC thermistor, the resistance of which decreases as the temperature rises. I have already found one whose resistance at room temperature is 8 kOhm, it seems to me that it will be ideal.
-
Based on my observations using a thermal imaging camera, the board itself is subject to heating no less than the radiator, which means the NTC thermistor can be mounted on the reverse side, for example, under the FPGA chip, and there will be no protruding wires. Regarding the method of controlling the rotation speed of the cooler, I meant replacing one of the resistors in the resistive divider with an NTC thermistor, the resistance of which decreases as the temperature rises. I have already found one whose resistance at room temperature is 8 kOhm, it seems to me that it will be ideal.
That's a clever idea, let us know how it works out. Best done with a bigger fan of course, as the stock one will remain loud af regardless of how you control it (unless you are ok with the target temps of 70-80 degrees or so).
-
800 board seems to be missing a lot of SMD parts.
Missing fet to right of fan header, the IC below it is a pfet, one to right is missing on both 800-900, all that in the power area of the board.
Next is the two missing IC's down below the fan header. Are those dc-dc bucks on the 900? Do these items feed power to the RAM chips? Two missing IC's in power section, and two missing RAM chips. Hmmmm. Oddly though, resistors/caps/inductors (perhaps) are installed all around those missing IC's. Why leave out the IC's but leave in those other small SMD's ?
-
Why leave out the IC's but leave in those other small SMD's ?
because the ICs are $3-7/pc and those small SMD's are 0.05cent/pc? so less work to remove fewer parts in pick and place files? attached are spot the difference between 800 and 900 board, and some findings/guesses i made a little while ago.. (thanks to dho900 owners who contributed) fwiw...
-
Here guys is the result of my modification. My assumption that reducing the resistance of the resistor in the divider will lead to a decrease in the fan speed turned out to be correct. The resistance of the pre-soldered resistor I measured was 55.6 kOhm. In parallel, a 1MOhm variable resistance resistor was connected to it, this gave a very large range of fan speed adjustment. I adjusted the noise level so that it is not audible at all, even up close. With this setting, the temperature on the board did not exceed 61°C for about one hour of operation at maximum load. Photos are attached.
-
Here guys is the result of my modification. My assumption that reducing the resistance of the resistor in the divider will lead to a decrease in the fan speed turned out to be correct. The resistance of the pre-soldered resistor I measured was 55.6 kOhm. In parallel, a 1MOhm variable resistance resistor was connected to it, this gave a very large range of fan speed adjustment. I adjusted the noise level so that it is not audible at all, even up close. With this setting, the temperature on the board did not exceed 61°C for about one hour of operation at maximum load. Photos are attached.
I would do as you wrote earlier - I would replace another resistor with an NTC thermistor with a resistance of 10k and in series with it a resistance selected so that the fan reaches factory speed at a crystal temperature of 65°C. As the temperature rises, the thermistor resistance will drop and the fan speed will increase.
-
Here guys is the result of my modification. My assumption that reducing the resistance of the resistor in the divider will lead to a decrease in the fan speed turned out to be correct. The resistance of the pre-soldered resistor I measured was 55.6 kOhm. In parallel, a 1MOhm variable resistance resistor was connected to it, this gave a very large range of fan speed adjustment. I adjusted the noise level so that it is not audible at all, even up close. With this setting, the temperature on the board did not exceed 61°C for about one hour of operation at maximum load. Photos are attached.
I would do as you wrote earlier - I would replace another resistor with an NTC thermistor with a resistance of 10k and in series with it a resistance selected so that the fan reaches factory speed at a crystal temperature of 65°C. As the temperature rises, the thermistor resistance will drop and the fan speed will increase.
Yes, of course, but it requires a lot of time to set up, which unfortunately I don’t have much of. The main thing is that we have jointly dealt with the issue of fan noise. Thanks to all!
-
I adjusted the noise level so that it is not audible at all, even up close. With this setting, the temperature on the board did not exceed 61°C for about one hour of operation at maximum load.
This is pretty good. Now the idea of trying a centrifugal fan becomes even more promising -- given how inoptimal the stock fan is for the job, a centrifugal one could potentially result in stock or lower than stock temperatures at a very low, if audible at all, noise level.
-
If the fan is on a buck dc-dc, should we not see some chopping, 100kHz, 400kHz, something?
As for internal fan control, I gave up looking for PWM control. I won't solder anything to the board, I just gonna put a pot into back cover and inline that with the fan. Then I 3D print a cover to go over the rear which will accomdate fan or fans of some kind. I want to be able to vesa mount it too. I thinking maybe 3D print a wedge cover so that (for now) the lean won't hit any bigger fan sticking out the back. Since I am making a DC filter for the usb-c IN power I will power my fan setup from that.
-
If the fan is on a buck dc-dc, should we not see some chopping, 100kHz, 400kHz, something?
I tried to look for it, but found nothing. But the scope I used was a basic handheld one (JDS6052S (https://www.aliexpress.com/item/4001201877087.html)), which may not have the required vertical sensitivity. Admittedly I couldn't decide whether it would be safe to use the DHO800 to probe its own internals, so I didn't do it. We need someone else to probe that 8V fan power rail with a decent scope to look for the switching noise. If there is any, it's going to be under 10-20 mV -- it seems to be filtered pretty well.
-
If the fan is on a buck dc-dc, should we not see some chopping, 100kHz, 400kHz, something?
I tried to look for it, but found nothing. But the scope I used was a basic handheld one (JDS6052S (https://www.aliexpress.com/item/4001201877087.html)), which may not have the required vertical sensitivity. Admittedly I couldn't decide whether it would be safe to use the DHO800 to probe its own internals, so I didn't do it. We need someone else to probe that 8V fan power rail with a decent scope to look for the switching noise. If there is any, it's going to be under 10-20 mV -- it seems to be filtered pretty well.
This is what I was able to see on the fan connector.
-
Admittedly I couldn't decide whether it would be safe to use the DHO800 to probe its own internals, so I didn't do it.
Where is your sense of adventure?!?!?! :-DD
In theory, since it looks like everything is referenced off the system GND, it should be perfectly safe to probe itself. :-/O
-
Here's a good adventure.Frequency increase up to 400 MHz; replacing inductors expands the zone. https://4pda.to/forum/index.php?showtopic=1080959#entry128030525 Post Но. 21-30.
-
But be aware that 400 MHz bandwidth can only be used in single-channel mode, where the scope's sampling rate will satisfy the Nyquist criterion. When using more channels (at reduced sampling rate per channel), it will be the user's responsibility to limit the spectral content of the incoming signal. Otherwise aliasing will occur.
Also, it's not easy to properly feed a 400 MHz signal into a scope without internal 50 Ohm termination. Considering those two limitations, I am not sure it's worthwhile to modify the input filter.
-
The optimal bandwidth for this scope is 125 MHz maximum in 1-2 channel mode, and 70 MHz in 3-4 channel mode. In extreme cases, 250 MHz in single channel.
There is no point in expanding it.
-
Note: I can get aliasing on the 1kHz probe compensation signal if I set it up wrong.
The trick to aliasing is awareness.
-
The trick to aliasing is awareness.
But the trick to opening up the scope's physical lowpass filters on the input is that awareness alone will no longer help you. ???
-
The trick to aliasing is awareness.
But the trick to opening up the scope's physical lowpass filters on the input is that awareness alone will no longer help you. ???
there are people doing it for a specific purpose to achieve something, and then there are people who follow the step because its cool without knowing the purpose or consequences. either way, i'm not one among any of them. God gave me strength to work side income to afford used GHz dso and some probes, the consequences? i currently dont have space for them to operate in comfortable way ::) please note getting a properly used GHz scope will still requires $5K or above, let alone the matching active probes. cheers.
-
If you read carefully what RX3AM wrote on that forum, you can see that he wrote about the pass resistance of 50 Ohm, and even recommended not to modify all four channels, and even pointed out the approximate error in the measurements. If you don't need it, then you don't have to do it. In my opinion, the purpose for which he did this is clearly described there. I consider this man extremely competent in what he did, unlike some of the “great theorists” who often speak out here. ^-^
-
rigol dso is already capable of aliasing without you modify anything out of factory (if you dont switch peak detect on). just switch to large enough timescale and sample rate will go down way below nyquist limit for a scope.. even with 20MHz limit is turned on, sample rate can go down even further iirc. is there entry level scope from any brand can do automatic BW reduction based on current sample rate used by user? to satisfy this nyquist limit problem? i havent heard one.
-
If you read carefully what RX3AM wrote on that forum, you can see that he wrote about the pass resistance of 50 Ohm, and even recommended not to modify all four channels, and even pointed out the approximate error in the measurements. If you don't need it, then you don't have to do it. In my opinion, the purpose for which he did this is clearly described there. I consider this man extremely competent in what he did, unlike some of the “great theorists” who often speak out here.
External 50 Ohm termination is good to ~200 MHz. I would not trust step response measurements etc. at 400 MHz unless the scope offers internal 50 Ohm termination. And even if modifying a single channel only, one has to be aware of the increased aliasing problem for that channel going forward.
I'm not saying that nobody should make that modification; it may have its uses e.g. in amateur radio. But I think it is justified to point out the limitations and side effects, without getting slighted for that.
-
Guys! 500€....And a real opportunity to see the spectrum up to 625 Mhz....And even measure it relatively truthfully....In my opinion, we are all forgetting about the price of this device... :box:
-
Guys! 500€....And a real opportunity to see the spectrum up to 625 Mhz....And even measure it relatively truthfully....In my opinion, we are all forgetting about the price of this device... :box:
Even cheaper if you buy a DHO802, which would be all you need in "400 MHz mode" anyway. Too bad they don't make an 801 version. :P
-
The optimal bandwidth for this scope is 125 MHz maximum in 1-2 channel mode, and 70 MHz in 3-4 channel mode. In extreme cases, 250 MHz in single channel.
There is no point in expanding it.
250 MHz bandwidth makes scope usable to 25-50 MHz. Above that, square wave will become sinus - more or less.
500 MHz will allow to see up to 100 MHz - unless ringing or background noise will come into play.
Probes included to DHO924S have a nominal bandwidth 350 MHz. Practically it should have little bit more, around 380-500 MHz. However 10 pF in a probe can be a little pain - You know where.
-
Here guys is the result of my modification. My assumption that reducing the resistance of the resistor in the divider will lead to a decrease in the fan speed turned out to be correct. The resistance of the pre-soldered resistor I measured was 55.6 kOhm. In parallel, a 1MOhm variable resistance resistor was connected to it, this gave a very large range of fan speed adjustment. I adjusted the noise level so that it is not audible at all, even up close. With this setting, the temperature on the board did not exceed 61°C for about one hour of operation at maximum load. Photos are attached.
My modification is V 2.0. the second resistor in the divider was replaced with a 10 kOhm NTC thermistor. I left the 1 MOhm parallel variable resistor for adjustment; it still regulates the fan speed. Now everything works as I originally planned, the speed increases very smoothly along with the temperature. A variable resistor makes it possible to adjust the desired speed at the desired temperature. With these ratings, it turned out to be possible to set the maximum voltage on the fan at 10V, which is even higher than what was in the factory version. Damn this works great!!!
-
...and even recommended not to modify all four channels
Just modify channel 4 and save it for special occasions! :)
-
Just modify channel 4 and save it for special occasions! :)
Sampling rate is halved if channel 4 is enabled (as well as any but channel 1), even if it's the only channel enabled. So if any channel is to be made special, then it has to be channel 1.
-
This is wrong,!!!
-
Sampling rate is halved if channel 4 is enabled (as well as any but channel 1), even if it's the only channel enabled.
No, you are mistaken there. Most likely you neglected to change the trigger input to channel 4 as well. If you leave triggering on channel 1, that channel also remains active, since it's a digital trigger system.
-
Just modify channel 4 and save it for special occasions! :)
Sampling rate is halved if channel 4 is enabled (as well as any but channel 1), even if it's the only channel enabled. So if any channel is to be made special, then it has to be channel 1.
Try setting trigger on channel 4...
-
Also, if some measurements are enabled on other channels ^-^
-
You just need to switch the trigger to the only active channel. And the frequency will again become maximum.
P.S. For some reason I didn’t see the messages above before mine...
-
Now that we have said this on four channels, I think we can move on. ::)
-
By the way, the noise of channels 1 and 4 is not much different. According to the average value AC.RMS on channel 1 is 18.67 µV, on channel 4 - 17.90 µV.
-
...and even recommended not to modify all four channels
Just modify channel 4 and save it for special occasions! :)
Im waiting for some screenshots, how good/bad it works.
-
Good catch guys. Yes I can confirm that 1.25 Gsa/s is actually possible on channel 4 :).
And I've been caught by this trigger channel thing more than once already! It's actually caused not only by the trigger setting, but also if any of the other channels are used in measurements, counter, and, I think, math as well. In other words, other channels, even if they are turned off, must not be referenced by anything to allow for full sampling rate to be active. This can easily be considered a bug, or at least a serious UX issue: when a channel is off and its respective button is not lit on the front panel, then it should not matter whether anything else references it. If it's off, it can't be used by anything anyway, and it should be automatically disabled for everything that may be concerned.
-
Good catch guys. Yes I can confirm that 1.25 Gsa/s is actually possible on channel 4 :).
thanks for letting us know ;D we have been with rigol since the beginning... like 20 years ago? ::)
-
This can easily be considered a bug, or at least a serious UX issue: when a channel is off and its respective button is not lit on the front panel, then it should not matter whether anything else references it. If it's off, it can't be used by anything anyway, and it should be automatically disabled for everything that may be concerned.
But the channel can be used! I am pretty sure that triggering works, and according to the manual, so does the DVM (and the counter?). I can't double-check this anymore since I no longer have my DHO.
If a channel is "off", i.e. its front panel button unlit and the settings field on the screen not coloured, that primarily means that it is not displayed on the screen. It can still acquire data, and hence take up part of the scope's sampling bandwidth.
I think this is useful functionality. You may want to trigger on a separate channel, but don't need to see it on the screen. In that case it is nice that you can disable the trace to reduce clutter on the small screen. Same for counter and DVM measurements (assuming that they actually work on a non-displayed channel).
-
But the channel can be used! I am pretty sure that triggering works, and according to the manual, so does the DVM (and the counter?). I can't double-check this anymore since I no longer have my DHO.
If a channel is "off", i.e. its front panel button unlit and the settings field on the screen not coloured, that primarily means that it is not displayed on the screen. It can still acquire data, and hence take up part of the scope's sampling bandwidth.
Agreed, these are all valid points. I've just checked: yes, trigger, measurements, and counters all keep working when the respective trace display is off.
Then there has to be a way to disable the channel trace display and data acquisition separately :). It can still be annoying for the user to see that the sampling rate is not at the max level and sit there wondering why for a moment, then remember that it has to be dereferenced in measurements etc., and find and turn those off (sometimes one by one, when it's not desired to remove all).
-
Then there has to be a way to disable the channel trace display and data acquisition separately :). It can still be annoying for the user to see that the sampling rate is not at the max level and sit there wondering why for a moment, then remember that it has to be dereferenced in measurements etc., and find and turn those off (sometimes one by one, when it's not desired to remove all).
If you see a channel colour highlighted, either in one of the channel indicators on the lower left, the measurements on the right, or the trigger indicator on top, the channel is "active". I don't see an issue with the operating logic there.
You can quickly deactivate individual measurements by swiping them to the right. And you should be aware which channel you are triggering from anyway -- apart from taking up part of the sample rate, it has a certain influence on what you see on the screen. ;)
-
Then there has to be a way to disable the channel trace display and data acquisition separately :). It can still be annoying for the user to see that the sampling rate is not at the max level and sit there wondering why for a moment, then remember that it has to be dereferenced in measurements etc., and find and turn those off (sometimes one by one, when it's not desired to remove all).
at least you will be wondering only once. and then you ask people why and now you know and are educated and become a better man... if you dont want that, buy good brand dso fully automatic, Lecroy maybe? or Rohde & Schwarz? tell us what brand name dso that doesnt cause confusion to beginner? in any aspect?
-
If you see a channel colour highlighted, either in one of the channel indicators on the lower left, the measurements on the right, or the trigger indicator on top, the channel is "active". I don't see an issue with the operating logic there.
There may be a lot of measurements that don't fit in the narrow vertical space, much of which is additionally wasted by the useless icons, frames, and padding. It will then require the user to scroll through the list and find the unnecessary channels referenced -- on a small screen with small letters. This is a UI/UX issue.
You can quickly deactivate individual measurements by swiping them to the right. And you should be aware which channel you are triggering from anyway -- apart from taking up part of the sample rate, it has a certain influence on what you see on the screen. ;)
The fact that there is a workaround does not mean that the issue does not exist.
at least you will be wondering only once. and then you ask people why and now you know and are educated and become a better man... if you dont want that, buy good brand dso fully automatic, Lecroy maybe? or Rohde & Schwarz? tell us what brand name dso that doesnt cause confusion to beginner? in any aspect?
This has nothing to do with the Rigol's UI/UX problems that I mentioned. The fact that I have never used a Rigol product before makes my observations more valuable -- having a previously unaware person estimate the usability of a user interface is an essential step in designing one. I only pointed out some of issues, that's it, there's no reason to start a personal discussion or do a comparison with other products. Maybe some day someone from the Rigol UI/UX team (if they even have one) will see this and take it into account.
-
Maybe some day someone from the Rigol UI/UX team (if they even have one) will see this and take it into account.
send a PM to them... we both pray for that.. except i prayed long time ago... what i learnt, other than simple pluses spelling mistake, we have to learn the rigol's way. i hope your msg will reach them and they accepted and implemented. cheers.
-
i hope your msg will reach them and they accepted and implemented. cheers.
I'm pretty sure it will not, lol. Or if it will, it will fall on deaf ears. That's why I'm simply leaving it here so that if eventually Rigol hires someone who will care, they will be able find it here along with all the other issues.
-
But the channel can be used! I am pretty sure that triggering works, and according to the manual, so does the DVM (and the counter?). I can't double-check this anymore since I no longer have my DHO.
If a channel is "off", i.e. its front panel button unlit and the settings field on the screen not coloured, that primarily means that it is not displayed on the screen. It can still acquire data, and hence take up part of the scope's sampling bandwidth.
Agreed, these are all valid points. I've just checked: yes, trigger, measurements, and counters all keep working when the respective trace display is off.
Then there has to be a way to disable the channel trace display and data acquisition separately :). It can still be annoying for the user to see that the sampling rate is not at the max level and sit there wondering why for a moment, then remember that it has to be dereferenced in measurements etc., and find and turn those off (sometimes one by one, when it's not desired to remove all).
Alternatively Rigol could change it so the referenced channel buttons blink to show they are still in use.
-
Alternatively Rigol could change it so the referenced channel buttons blink to show they are still in use.
That would be distracting.
-
Alternatively Rigol could change it so the referenced channel buttons blink to show they are still in use.
Blinking would be distracting indeed, but the idea is good: a small highligted spot like a dot in the corner of the channel button would do the job. Rigol should really opensource their UI app, or, alternatively, create a plugin API to allow the community to create mods, if they lack the resources to fix all the bugs and missing features themselves.
-
Rigol should really opensource their UI app, or, alternatively, create a plugin API to allow the community to create mods, if they lack the resources to fix all the bugs and missing features themselves.
That will increase their sales, because that idea will increase usability and therefore much more people will want this. But accountants and managers of most companies think differently.
-
For the software hackers in the thread. I installed a very simple Android/Kotlin program on the scope to capture the "key" events when twiddling all the knobs and dials. Attached is an image of the key codes each generates.
Useful if you want to write some side-loaded software that uses the scope's controls.
These were all captured and tested on a 924S even though the image shows an 814. Hopefully you can see where I added key codes for the missing buttons.
NOTE: Each of the key codes shown is added to 0x40000000, so the Run/Stop button produces key code 0x4000000C.
I am trying to keep up in this thread.
I had made a note to go dig on the keycode from your pic.
While sifting through java code of Sparrow.apk I came across Panel keycode file. This should ID everything else on the panel, plus some other keyevents. Some key events appear to have pre-req, like a CH needs to be on 1st, etc.
The Java uses decimal, so I converted the base hex to base decimal, then you just add the decimal mapped to the keyevent.
As a side note, I believe I found where CH colors are, so I will try and change CH1 to be "not-yellow", repack and resign the APK, then install & test.
code here, and attached. They appear to be common on 800-900 series. Eg; MODE on 800 gives a "hardware not present" err, which is expected as there is no sig gen on the 800.
Duly noted, there's a ton of other Android keyevents you can send in, this list is just for com.rigol.scope
adb shell input keyevent [keycode]
ADD the keycode decimal to base # 1073741824 = keycode for adb
package com.rigol.scope.views;
public interface PanelKeyCode {
public static final int ALARM_CH1_OVERLOAD = 241;
public static final int ALARM_CH2_OVERLOAD = 242;
public static final int ALARM_CH3_OVERLOAD = 243;
public static final int ALARM_CH4_OVERLOAD = 244;
public static final int KEY_ACQUIRE = 4;
public static final int KEY_ANALYSE = 18;
public static final int KEY_AUTO = 13;
public static final int KEY_CH1 = 21;
public static final int KEY_CH1_MENU = 65;
public static final int KEY_CH1_OFFSET_CCW = 4182;
public static final int KEY_CH1_OFFSET_CW = 2134;
public static final int KEY_CH1_OFFSET_Z = 88;
public static final int KEY_CH1_SCALE_CCW = 4147;
public static final int KEY_CH1_SCALE_CW = 2099;
public static final int KEY_CH1_SCALE_Z = 53;
public static final int KEY_CH2 = 22;
public static final int KEY_CH2_MENU = 114;
public static final int KEY_CH2_OFFSET_CCW = 4150;
public static final int KEY_CH2_OFFSET_CW = 2102;
public static final int KEY_CH2_OFFSET_Z = 56;
public static final int KEY_CH2_SCALE_CCW = 4163;
public static final int KEY_CH2_SCALE_CW = 2115;
public static final int KEY_CH2_SCALE_Z = 69;
public static final int KEY_CH3 = 23;
public static final int KEY_CH3_MENU = 49;
public static final int KEY_CH3_OFFSET_CCW = 4198;
public static final int KEY_CH3_OFFSET_CW = 2150;
public static final int KEY_CH3_OFFSET_Z = 104;
public static final int KEY_CH3_SCALE_CCW = 4179;
public static final int KEY_CH3_SCALE_CW = 2131;
public static final int KEY_CH3_SCALE_Z = 85;
public static final int KEY_CH4 = 24;
public static final int KEY_CH4_MENU = 81;
public static final int KEY_CH4_OFFSET_CCW = 4214;
public static final int KEY_CH4_OFFSET_CW = 2166;
public static final int KEY_CH4_OFFSET_Z = 120;
public static final int KEY_CH4_SCALE_CCW = 4195;
public static final int KEY_CH4_SCALE_CW = 2147;
public static final int KEY_CH4_SCALE_Z = 101;
public static final int KEY_CLEAR = 11;
public static final int KEY_CURSOR = 16;
public static final int KEY_DECODE_MENU = 55;
public static final int KEY_DEFAULT = 17;
public static final int KEY_DISPLAY = 121;
public static final int KEY_DISP_CLEAR = 248;
public static final int KEY_FORCE = 10;
public static final int KEY_FUNC_CCW = 4179;
public static final int KEY_FUNC_CW = 2131;
public static final int KEY_FUNC_Z = 81;
public static final int KEY_GI = 3;
public static final int KEY_HORI_ZOOM = 113;
public static final int KEY_LA = 2;
public static final int KEY_LA_MENU = 40;
public static final int KEY_LOCAL = 98;
public static final int KEY_MATH = 25;
public static final int KEY_MATH_MENU = 72;
public static final int KEY_MEASURE = 15;
public static final int KEY_MENU_BACK = 139;
public static final int KEY_MENU_F1 = 75;
public static final int KEY_MENU_F2 = 59;
public static final int KEY_MENU_F3 = 43;
public static final int KEY_MENU_F4 = 27;
public static final int KEY_MENU_F5 = 107;
public static final int KEY_MENU_F6 = 123;
public static final int KEY_MENU_F7 = 135;
public static final int KEY_MENU_OFF = 91;
public static final int KEY_MODE = 97;
public static final int KEY_MOTOR = 66;
public static final int KEY_PLAY_NEXT = 122;
public static final int KEY_PLAY_PRE = 58;
public static final int KEY_PLAY_STOP = 42;
public static final int KEY_QUICK = 20;
public static final int KEY_RECORD_BACK = 8;
public static final int KEY_RECORD_FORWARD = 6;
public static final int KEY_RECORD_PLAY = 7;
public static final int KEY_REF = 1;
public static final int KEY_REF_MENU = 255;
public static final int KEY_RUN_STOP = 12;
public static final int KEY_SEARCH = 5;
public static final int KEY_SINGLE = 14;
public static final int KEY_SLPOE = 9;
public static final int KEY_SOURCE1_MENU = 74;
public static final int KEY_SOURCE2_MENU = 103;
public static final int KEY_STORAGE = 137;
public static final int KEY_TIME_NAVIGATE = 138;
public static final int KEY_TIME_OFFSET_CCW = 4166;
public static final int KEY_TIME_OFFSET_CW = 2118;
public static final int KEY_TIME_OFFSET_Z = 72;
public static final int KEY_TIME_SCALE_CCW = 4211;
public static final int KEY_TIME_SCALE_CW = 2163;
public static final int KEY_TIME_SCALE_Z = 117;
public static final int KEY_TOUCH = 71;
public static final int KEY_TOUCH_LOCK = 19;
public static final int KEY_TRIGGER = 26;
public static final int KEY_TRIG_FORCE = 39;
public static final int KEY_TRIG_LEVEL_CCW = 4150;
public static final int KEY_TRIG_LEVEL_CW = 2102;
public static final int KEY_TRIG_LEVEL_Z = 52;
public static final int KEY_TRIG_MENU = 120;
public static final int KEY_TRIG_MODE = 87;
public static final int KEY_USER = 82;
public static final int KEY_UTILITY = 89;
public static final int KEY_WAVE_POS_CCW = 4166;
public static final int KEY_WAVE_POS_CW = 2118;
public static final int KEY_WAVE_POS_Z = 68;
public static final int KEY_WAVE_RECORD = 39;
public static final int KEY_WAVE_RECORD_BACK = 38;
public static final int KEY_WAVE_RECORD_FORWAD = 40;
public static final int KEY_WAVE_VOLT_CCW = 4134;
public static final int KEY_WAVE_VOLT_CW = 2086;
public static final int KEY_WAVE_VOLT_Z = 36;
public static final int KEY_ZOOM = 32;
public static final int KNOB_FUNC1_ANTICLOCKWISE = 187;
public static final int KNOB_FUNC1_CLOCKWISE = 186;
public static final int KNOB_FUNC1_PRESSED = 188;
public static final int KNOB_FUNC2_ANTICLOCKWISE = 171;
public static final int KNOB_FUNC2_CLOCKWISE = 170;
public static final int KNOB_FUNC2_PRESSED = 172;
public static final int KNOB_HORIZONTAL_POS_ANTICLOCKWISE = 139;
public static final int KNOB_HORIZONTAL_POS_CLOCKWISE = 138;
public static final int KNOB_HORIZONTAL_POS_PRESSED = 140;
public static final int KNOB_HORIZONTAL_SCALE_ANTICLOCKWISE = 203;
public static final int KNOB_HORIZONTAL_SCALE_CLOCKWISE = 202;
public static final int KNOB_HORIZONTAL_SCALE_PRESSED = 204;
public static final int KNOB_POWEROFF = 27;
public static final int KNOB_TRIG_ANTICLOCKWISE = 235;
public static final int KNOB_TRIG_CLOCKWISE = 234;
public static final int KNOB_TRIG_PRESSED = 236;
public static final int KNOB_VERITICAL_LEVEL_ANTICLOCKWISE = 219;
public static final int KNOB_VERITICAL_LEVEL_CLOCKWISE = 218;
public static final int KNOB_VERITICAL_LEVEL_PRESSED = 220;
public static final int KNOB_VERITICAL_POS_ANTICLOCKWISE = 155;
public static final int KNOB_VERITICAL_POS_CLOCKWISE = 154;
public static final int KNOB_VERITICAL_POS_PRESSED = 156;
-
Speaking of interaction events, any idea of a way to get the time passed since the used turned or pressed any control knob or button or touched the screen? I want to write a script to dim the screen after a timeout and restore brightness when any interactive activity is detected.
-
Speaking of interaction events, any idea of a way to get the time passed since the used turned or pressed any control knob or button or touched the screen? I want to write a script to dim the screen after a timeout and restore brightness when any interactive activity is detected.
I believe that's the Android timeout setting in getprop list
My 804 dims after 5min, any event brings it back to the set full-brightness.
ro.rk.screenoff.time
-
I decided to break down step by step the hack and upgrade of oscilloscopes of the DHO8xx/9xx series :) I translated it through Google, so please don’t scold me too much if you come across a translation error :)
Tools you will need:
- USB-hub, any. You can buy a miniature one with 2-4 sockets and leave it on the oscilloscope permanently.
[attach=1]
A hub is needed so that you can connect a keyboard and WiFi at the same time. If you plan to connect to the network via cable, then a hub is not necessary. - Keyboard - regular USB or wireless with its own receiver plugged into USB. This one works great for me:
[attach=2]
- WiFi dongle or connecting to the network with a cable. In the case of WiFi, dongles based on the RTL8188EU chipset are suitable. This one definitely works:
[attach=3]
If you don’t want to bother with WiFi, you can connect to the network with a cable. In any case, you must have network access to the oscilloscope.
Software:
- Android ADB - https://developer.android.com/tools/releases/platform-tools (https://developer.android.com/tools/releases/platform-tools) - software to access the oscilloscope over the network.
- Utility for hack - https://github.com/zelea2/rigol_vendor_bin/releases (https://github.com/zelea2/rigol_vendor_bin/releases)
There are two ways to hack: 1 - turn your oscilloscope into an other model, 2 - generate options for it that expand its capabilities. In any case, the oscilloscope must be connected to the network and accessible over the network from the computer.
Important: The WiFi dongle must be connected to the oscilloscope before turning on the power, otherwise the oscilloscope will not see it.
Connect WiFi
- Connect the WiFi dongle and keyboard, turn on the power to the oscilloscope.
- After the oscilloscope is fully loaded, press the Win+N combination on the keyboard. This will cause the top curtain of Android to fall out, in which, among other things, there will be a settings gear.
[attach=4] - Tap on this gear and you will be taken to the standard Android settings, where you will go to the WiFi settings.
- Here you turn on Wi-Fi, wait until your network is detected (the network must be in the 2.4 GHz range), select it, enter the password and make sure that the connection is successful. Now you can use Alt+Tab to return to the oscilloscope application itself.
These settings will be saved even when the power is turned off, so if the WiFi dongle is connected, the oscilloscope will automatically connect to the network when turned on (and automatically update the current date/time, albeit with the Chinese time zone).
Attention! Before changing the oscilloscope model, you need to make sure that it has firmware version 00.01.02.00.02 or later installed, otherwise after changing the model from 8xx to 9xx you will get unpleasant vertical shifts on the channels.
To see the full version of the firmware, and not just its first three numbers, click the "About Product" item in the "Utility" menu three times in a row.
If the current firmware version is less than 00.01.02.00.02, then update the firmware before using hacks. You can download the firmware update here - https://www.rigolna.com/products/digital-oscilloscopes/dho900/. (https://www.rigolna.com/products/digital-oscilloscopes/dho900/.)
1 - Changing the oscilloscope model
For example, you can turn the DHO804 into a DHO924, which will immediately have the appropriate bandwidth and maximum memory depth. Disadvantages of this method:
- the inscription DHO814 will still remain on the face :))
- a button for turning on the logic analyzer, which is in the 9xx series and not in the 8xx series, will be added to the interface below. There is nothing critical about this; you still won’t be able to turn it on; the message “The LA adapter is not connected".
How to do:
- See the oscilloscope IP address in the menu:
[attach=5] - Go to the directory with unpacked ADB and launch the command line there.
- On the command line write the command:
adb connect 192.168.1.171:55555
Of course, replace the address 192.168.1.171 with the address of your oscilloscope. - Now write the command:
adb pull /rigol/data
When this command completes, the "data" directory will appear in the current directory. I recommend saving this directory with the original files as a backup, just in case. - From this “data” directory, copy two files into the directory with the unpacked utility “rigol_vendor_bin”: 1 - vendor.bin, 2 - Key.data or RKey.data (depending on the oscilloscope firmware version).
- Go to the directory with the unpacked utility "rigol_vendor_bin" and write the command there:
rigol_vendor_bin.exe -M DHO924
Instead of the DHO924, you can substitute another model into which you want to turn your oscilloscope. Options:
- DHO802
- DHO804
- DHO814
- DHO914
- DHO914S
- DHO924
- DHO924S
- As a result of the previous command, you should receive a vendor.enc file in the current directory. Copy it to the directory with ADB and rename it there to vendor.bin.
- Go to the directory with ADB (in which you should already have a new vendor.bin file) and write the command there:
adb push vendor.bin /rigol/data/ - Reboot the oscilloscope and enjoy :)
2 - Generation of additional options that expand capabilities
With this method, the oscilloscope model remains the same, but you can expand the capabilities with additional options, which are usually sold for money :)
The first 5 points are similar to the previous method.
- See the oscilloscope IP address in the menu:
[attach=5] - Go to the directory with unpacked ADB and launch the command line there.
- On the command line write the command:
adb connect 192.168.1.171:55555
Of course, replace the address 192.168.1.171 with the address of your oscilloscope. - Now write the command:
adb pull /rigol/data
When this command completes, the "data" directory will appear in the current directory. I recommend saving this directory with the original files as a backup, just in case. - From this “data” directory, copy two files into the directory with the unpacked utility “rigol_vendor_bin”: 1 - vendor.bin, 2 - Key.data or RKey.data (depending on the oscilloscope firmware version).
- Go to the directory with the unpacked utility "rigol_vendor_bin" and write the command there:
rigol_vendor_bin.exe -o >opts.txt
This command will create a file "opts.txt", at the end of which a list of all options available for your model will be generated in the form of ready-made SCPI commands in the following form:
:SYST:OPT:INST DHO900-BW15T25@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Instead of "x" there will be many different numbers and letters. - Open the page with the address of your oscilloscope in your browser and select the “SCPI Panel Control” item there:
[attach=7]
- Insert all the generated lines with options into the text field (one at a time) and click “Send & Read”. In response to an option that the oscilloscope recognizes, an “Option installed” notification will appear on its display. It seems that you can send several lines with options at once, but this is not 100% reliable.
- Go to the “About” menu of the oscilloscope and enjoy the numbers of the new bandwidth, and in the Acquire settings you will be pleasantly surprised by the new memory depth :)
2 - Same as the previous one, alternative method
- See the oscilloscope IP address in the menu:
[attach=5] - From the directory of the unpacked utility "rigol_vendor_bin" copy the file "generate_all_options" to the directory with the unpacked ADB.
- Go to the directory with unpacked ADB and launch the command line there.
- On the command line write the command:
adb connect 192.168.1.171:55555
Of course, replace the address 192.168.1.171 with the address of your oscilloscope. - Now write the command:
adb push generate_all_options /rigol/data/
This will copy the "generate_all_options" file to the oscilloscope in the "/rigol/data" directory. - Launch the terminal to the oscilloscope in ADB:
adb shell
Now you should see the oscilloscope terminal command line with the following prompt - "rk3399_rigol:/$". - Here write the command:
su
The $ sign in the tooltip should change to #. This gives administrator rights to manipulate files. - Go to the "/rigol/data" directory:
cd /rigol/data - Make the file "generate_all_options" in this directory executable:
chmod 777 generate_all_options - Run the file "generate_all_options" for execution:
./generate_all_options
As a result of executing this file, information about the operation of the program should appear in the terminal, something like this:
Rigol 'vendor.bin' encoder/decoder v1.2 - Zelea
-------------------------------------------------- ---------
Model: DHO914
SN: DHO9A25xxxxxxxx
MAC: 0019xxxxxxxx
-------------------------------------------------- ---------
Generating options for DHO914
-------------------------------------------------- ---------
BW15T25 EMBD AUTO COMP BODE
-------------------------------------------------- ---------
To check, you can run the file list command:
ls -l
And make sure that files with the .lic extension appear:
[attach=6] - Write the command:
exit
And repeat it again to exit to the command line of the operating system. - Reboot the oscilloscope, go to the oscilloscope's "About" menu and enjoy the new bandwidth numbers, and in the Acquire settings you will be pleasantly surprised by the new memory depth :)
-
Speaking of interaction events, any idea of a way to get the time passed since the used turned or pressed any control knob or button or touched the screen? I want to write a script to dim the screen after a timeout and restore brightness when any interactive activity is detected.
I did this simply in the Android settings :)
-
I decided to break down step by step the hack and upgrade of oscilloscopes of the DHO8xx/9xx series :)
Wow, @AndyBig that's THE most comprehensive guide to date. Hopefully that will reduce the confusion & questions for newcomers.
Not scolding, but there are a couple trivial translation errors that slipped by:
--turn your oscilloscope into an older other model...
--Important: The WiFi whistle dongle must be...
--These settings will be saved even when the power is turned off, so if the WiFi whistle dongle is connected...
Thank you for your awesome effort! :clap:
p.s., They should make that post a sticky.
-
Not scolding, but there is a couple trivial translation errors that slipped by:
I tried to proofread and remove language-specific idioms, but I still missed some of them :) Thanks, I fixed it :)
-
Has anyone tried if SCRCPY over ADB works?
https://github.com/Genymobile/scrcpy
-
Has anyone tried if SCRCPY over ADB works?
https://github.com/Genymobile/scrcpy
I tried it. The screen slows down as soon as the image begins to change dynamically over most of it - for example, when the signal changes quickly with a span of half a screen or more. Web control in the oscilloscope's native interface works much better in this regard.
The only plus is that this program allows you to transfer special keyboard shortcuts, such as Alt+H (home screen), Alt+S (switching between running applications), etc.
Although it’s actually an interesting thing, I’ll keep it, thanks for the link :)
-
Good news. Found where all the colors are set.
With that step completed I need to move onto making an edit in a file, repack, resign, and then swap out the Sparrow app.
This will tell us if a resign will work ok. I suspect it will, we can toggle the Android switch "allow apps from unknown sources".
Progress.
-
Whoever will be taking apart their scope next, including the removal of the heat sink, please measure the size and thickness of the thermal pads. I have a crazy idea of trying those "phase change thermal pads", but need to know what size to order, and I don't want to take the scope apart again, given that someone here will surely do it sooner or later :).
-
Good news. Found where all the colors are set.
With that step completed I need to move onto making an edit in a file, repack, resign, and then swap out the Sparrow app.
This will tell us if a resign will work ok. I suspect it will, we can toggle the Android switch "allow apps from unknown sources".
Progress.
Update:
In testing, was able to uninstall system app com.rigol.scope, and reinstall it (Sparrow.apk), the OEM stuff.
I did edit, repack, resign, and zipalign.
pm install did not complain about any signature stuff, but I did get a failed install due to missing "NativeLibs". I do believe I can fix this problem by editing manifest to not call for "extractNativeLibs".
I need to investigate further.
-
I am not sure if it is the right place to ask, but maybe someone will know.
Does DHO900 keep track of how long it was in use (working hours)? There is nothing I can see in Rigol's menu, but maybe Android keeps track of it? Is there any way to check?
-
Here guys is the result of my modification. My assumption that reducing the resistance of the resistor in the divider will lead to a decrease in the fan speed turned out to be correct. The resistance of the pre-soldered resistor I measured was 55.6 kOhm. In parallel, a 1MOhm variable resistance resistor was connected to it, this gave a very large range of fan speed adjustment. I adjusted the noise level so that it is not audible at all, even up close. With this setting, the temperature on the board did not exceed 61°C for about one hour of operation at maximum load. Photos are attached.
My modification is V 2.0. the second resistor in the divider was replaced with a 10 kOhm NTC thermistor. I left the 1 MOhm parallel variable resistor for adjustment; it still regulates the fan speed. Now everything works as I originally planned, the speed increases very smoothly along with the temperature. A variable resistor makes it possible to adjust the desired speed at the desired temperature. With these ratings, it turned out to be possible to set the maximum voltage on the fan at 10V, which is even higher than what was in the factory version. Damn this works great!!!
Made a video about it
https://youtu.be/nCtWG5JYNDo
-
Whoever will be taking apart their scope next, including the removal of the heat sink, please measure the size and thickness of the thermal pads. I have a crazy idea of trying those "phase change thermal pads", but need to know what size to order, and I don't want to take the scope apart again, given that someone here will surely do it sooner or later :).
Probably I will do my modifications today, so I will measure it.
Does DHO900 keep track of how long it was in use (working hours)? There is nothing I can see in Rigol's menu, but maybe Android keeps track of it? Is there any way to check?
I suggest to install some Android app working in the background.
-
I own 924S from couple months, but from the beginning I wanted to run Heroes III. Now I can confirm it works.
https://www.youtube.com/watch?v=90p06tHq0OQ (https://www.youtube.com/watch?v=90p06tHq0OQ)
-
I own 924S from couple months, but from the beginning I wanted to run Heroes III. Now I can confirm it works.
Rigol sells a rooted Android, so you can run whatever.
But why did you want to run a game on a scope device?
-
Rigol sells a rooted Android, so you can run whatever.
But why did you want to run a game on a scope device?
Just for fun.
Installing wasn't so easy. At the beginning Rigol app was randomly switching up to front.
Now I think to install Linux instead of Android. Maybe Rigol app will work on anbox (app to use Android apps on Linux). That will be much more useful.
-
Is the 800/900 screen natively better than 1024x600 ?
<meta-data android:name="design_width_in_dp" android:value="1024"/>
<meta-data android:name="design_height_in_dp" android:value="600"/>
If it's better than that we can increase app resolution within same aspect ratio.
-
Is the 800/900 screen natively better than 1024x600 ?
Rigol might get some things wrong, but they are no idiots. Of course they run the screen at its native resolution, and they put that (being the highest and hence best-looking number) in the datasheet too.
-
Is the 800/900 screen natively better than 1024x600 ?
Rigol might get some things wrong, but they are no idiots. Of course they run the screen at its native resolution, and they put that (being the highest and hence best-looking number) in the datasheet too.
The screen device runs it's own native "resolution", it has physical pixels. I'll look into the screen model and driver file to see if that's really the best res it is.
The app runs on a specified resolution. If that's not the native device res then the driver would need to interpolate. If the aspect is not the same then you get squishing and such.
I think perhaps the spec sheet tells us what the Scope app is, and less about the underlying devices of the hardware.
All good info.
-
The screen device runs it's own native "resolution", it has physical pixels. I'll look into the screen model and driver file to see if that's really the best res it is.
The app runs on a specified resolution. If that's not the native device res then the driver would need to interpolate. If the aspect is not the same then you get squishing and such.
I think perhaps the spec sheet tells us what the Scope app is, and less about the underlying devices of the hardware.
All good info.
Look, Randy, I really did not need an explanation from you on physical screen resolution vs. driver resolution etc. Nobody here needs that. We have all used LCD monitors and seen the effect of different resolutions and driver settings; quite a few here have designed LCD monitors into systems and driven them on a low level. Seeing you dish out those explanations just makes me wonder whether (a) you have an unrealistic picture of the audience here, or (b) you have an unrealistic picture of yourself.
On the other hand, please consider why on earth Rigol should build in a higher-resolution display and then drive it a lower resolution?! The display would be more expensive; it would take more power; it would take more CPU/GPU bandwidth to drive the pixels; the interpolated picture would look worse than on a native-resolution display. And if they still were to use that high-res display despite all that: Why would they put anything but the highest justifiable resolution number into the datasheet??
I think you can safely drop that resolution hypothesis.
-
Installing wasn't so easy. At the beginning Rigol app was randomly switching up to front.
You could kill the scope app. -It will be less annoying and will draw considerably less power. (and generate less heat, etc.) :popcorn:
Now I think to install Linux instead of Android. Maybe Rigol app will work on anbox (app to use Android apps on Linux). That will be much more useful.
:-+ And might even boot faster!
-
Installing wasn't so easy. At the beginning Rigol app was randomly switching up to front.
You could kill the scope app. -It will be less annoying and will draw considerably less power. (and generate less heat, etc.) :popcorn:
Now I think to install Linux instead of Android. Maybe Rigol app will work on anbox (app to use Android apps on Linux). That will be much more useful.
:-+ And might even boot faster!
You cant kill scope app, there's a watchdog that restarts it to MainActivity.
You can disable the app though so it can't start.
As side note, I am able to make edits in Sparrow.apk to change CH1 color.
However, Android is giving me grief. There are remnants of com.rigol.scope somewhere on the system that logs "versioning" along with the keys used for signing. My install of updated Sparrow.apk fails because the prrevious version used different keys.
I did full uninstall of the original app, removed all relative directories, but somewhere (possibly pm) it's holding onto previous version info.
I might try to rename the app to something like com.rigol.scopee and see if that works, but not today.
-
You cant kill scope app, there's a watchdog that restarts it to MainActivity.
You can disable the app though so it can't start.
Yep! That's what I should've written., I couldn't quickly find the post by @Serg65536 referencing it, then got distracted with something else. Thanks for the assist.
As side note, I am able to make edits in Sparrow.apk to change CH1 color.
However, Android is giving me grief. There are remnants of com.rigol.scope somewhere on the system that logs "versioning" along with the keys used for signing. My install of updated Sparrow.apk fails because the prrevious version used different keys.
I did full uninstall of the original app, removed all relative directories, but somewhere (possibly pm) it's holding onto previous version info.
I might try to rename the app to something like com.rigol.scopee and see if that works, but not today.
Would this Android APK Editor (https://apk-editor.en.uptodown.com/android) help at all? looks kinda neat from the screenshots/description. I don't know what the diff is from this and the G play store, but at least this one I posted has a normal looking version number.
EDIT: @Serg65536's excellent guide (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5209788/#msg5209788) to booting your scope without running the scope app by default
-
You could kill the scope app. -It will be less annoying and will draw considerably less power. (and generate less heat, etc.) :popcorn:
Before doing this, you need to kill the launcher app (com.rigol.launcher) first, otherwise it will restart the oscilloscope app every few seconds. And no, if the oscilloscope application has been loaded at least once, then it will no longer consume less. Consumption increases when the FPGA is initialized in the start_rigol_app.sh script and after that remains high until the device is turned off :)
:-+ And might even boot faster!
If you disable the launcher so that it does not cause execution of the start_rigol_app.sh script upon startup, then the startup time is about 38 seconds :) However, I haven’t figured out how to manually trigger the execution of this script from Android, and without it, the oscilloscope application, of course, does not work normally.
-
You could kill the scope app. -It will be less annoying and will draw considerably less power. (and generate less heat, etc.) :popcorn:
Before doing this, you need to kill the launcher app (com.rigol.launcher) first, otherwise it will restart the oscilloscope app every few seconds. And no, if the oscilloscope application has been loaded at least once, then it will no longer consume less. Consumption increases when the FPGA is initialized in the start_rigol_app.sh script and after that remains high until the device is turned off :)
:-+ And might even boot faster!
If you disable the launcher so that it does not cause execution of the start_rigol_app.sh script upon startup, then the startup time is about 38 seconds :) However, I haven’t figured out how to manually trigger the execution of this script from Android, and without it, the oscilloscope application, of course, does not work normally.
38 seconds is NOT very much of a savings. :(
See the guide I posted above(from page 24) that I mentioned @Serg65536 wrote up. Not exactly sure if it's still relevant these days., but worth a try for those who care.
EDIT: @Serg65536's excellent guide (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5209788/#msg5209788) to booting your scope without running the scope app by default
-
38 seconds is NOT very much of a savings. :(
See the guide I posted above(from page 24) that mentioned that Serg wrote up. Not exactly sure if it's still relevant these days., but worth a try for those who care.
It's not entirely clear there either. After you disable autorun for the native launcher, it will not automatically launch the FPGA initialization script and the oscilloscope application, this is understandable. But how can you launch the oscilloscope application at any time after this? The FPGA remains uninitialized and the application will not work normally.
-
You could kill the scope app.
It restarts automatically. :)
-
You cant kill scope app, there's a watchdog that restarts it to MainActivity.
You can disable the app though so it can't start.
Yep! That's what I should've written., I couldn't quickly find the post by @Serg65536 referencing it, then got distracted with something else. Thanks for the assist.
As side note, I am able to make edits in Sparrow.apk to change CH1 color.
However, Android is giving me grief. There are remnants of com.rigol.scope somewhere on the system that logs "versioning" along with the keys used for signing. My install of updated Sparrow.apk fails because the prrevious version used different keys.
I did full uninstall of the original app, removed all relative directories, but somewhere (possibly pm) it's holding onto previous version info.
I might try to rename the app to something like com.rigol.scopee and see if that works, but not today.
Would this Android APK Editor (https://apk-editor.en.uptodown.com/android) help at all? looks kinda neat from the screenshots/description. I don't know what the diff is from this and the G play store, but at least this one I posted has a normal looking version number.
EDIT: @Serg65536's excellent guide (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5209788/#msg5209788) to booting your scope without running the scope app by default
apktool is my goto item.
I can unpack, edit, repack, zipalign, apksigner it. All the verify stuff seems to indicate the "new" APK is a-ok.
The issue now is an Android issue. It remembers previously install apps, even if you uninstall them. I not sure yet where this mapping lives in this Android.
As example, it's fully uninstalled, yet "pm list packages -u" still shows an entry for com.rigol.scope
-
The FPGA remains uninitialized and the application will not work normally.
Maybe "/rigol/shell/reload_fpga.sh" will give a clue...
-
BTW, how is the main app actually started?
The shell/start_rigol_app.sh script has it commented out (around line 150):
### Start Main APP
# sleep 3
# am start -n com.rigol.scope/.MainActivity
And nowhere in the shell scripts I see a command to start it, except restartScope.sh:
#!/system/bin/bash
su
kill -9 $(pidof com.rigol.scope)
am start -n com.rigol.scope/.MainActivity
but it isn't referenced in any of the other shell scripts. A mystery!
-
38 seconds is NOT very much of a savings. :(
See the guide I posted above(from page 24) that mentioned that Serg wrote up. Not exactly sure if it's still relevant these days., but worth a try for those who care.
It's not entirely clear there either. After you disable autorun for the native launcher, it will not automatically launch the FPGA initialization script and the oscilloscope application, this is understandable. But how can you launch the oscilloscope application at any time after this? The FPGA remains uninitialized and the application will not work normally.
His 11th(optional) step doesn't describe how to launch it from the new launcher?
-
BTW, how is the main app actually started?
The shell/start_rigol_app.sh script has it commented out (around line 150):
### Start Main APP
# sleep 3
# am start -n com.rigol.scope/.MainActivity
And nowhere in the shell scripts I see a command to start it, except restartScope.sh:
#!/system/bin/bash
su
kill -9 $(pidof com.rigol.scope)
am start -n com.rigol.scope/.MainActivity
but it isn't referenced in any of the other shell scripts. A mystery!
The commenetd out stuff is old stuff, they just did not remove it from the script. Why they made this thing so convoluted makes you head-scratch. I suspect 800-900 is just a port down from their bigger brothers and sisters, and they just hacked out what was not needed using comment '#', and then added stuff as break-fix so it will work.
There are several Activities listed in the Manifest. You can us 'am' to call an Activity, like "am start -n com.rigol.scope/.MainActivity"
You can move the scope app to rear, and then recall the Main Activity, am will just say "already running, moving app to front", and then you see scope app on screen again.
They app start from init.rigol.rc:service startApp /system/bin/bootApp.sh
Basically an init start command (call other script). That bootApp script is also copied into /rigol/shell/, probably from doing an install of a GEL.
Look at /init.rigol.rc script, it does all that ssh key copying too, and some other stuff.
It's easier to leave the init script alone when it comes to doing scope update with a GEL file. So they make changes to the scripts in /rigol/shell , etc. This is an easier approach for the way they crafted GEL updates.
When you do some of these tests from scope screen, they call to an activity.
<activity android:name="com.rigol.scope.ActivityRigolTouchTest"/>
<activity android:name="com.rigol.scope.ActivityRigolLcdTest"/>
<activity android:name="com.rigol.scope.ActivityRigolKeyTest"/>
<activity android:name="com.rigol.scope.ScreenSaverActivity"/>
-
The commenetd out stuff is old stuff, they just did not remove it from the script. Why they made this thing so convoluted makes you head-scratch. I suspect 800-900 is just a port down from their bigger brothers and sisters, and they just hacked out what was not needed using comment '#', and then added stuff as break-fix so it will work.
There are several Activities listed in the Manifest. You can us 'am' to call an Activity, like "am start -n com.rigol.scope/.MainActivity"
You can move the scope app to rear, and then recall the Main Activity, am will just say "already running, moving app to front", and then you see scope app on screen again.
They app start from init.rigol.rc:service startApp /system/bin/bootApp.sh
Basically an init start command (call other script). That bootApp script is also copied into /rigol/shell/, probably from doing an install of a GEL.
No, still not clear.
All the bootApp.sh script does is initialize the logs directory (if not exists already) and call /rigol/shell/start_rigol_app.sh, which does not have any reference to com.rigol.scope except that commented out one.
Look at /init.rigol.rc script, it does all that ssh key copying too, and some other stuff.
This init script calls (among other things) the bootApp.sh script, but again no reference to com.rigol.scope.
In fact,
1|rk3399_rigol:/ # grep com.rigol.scope /*.rc
1|rk3399_rigol:/ #
None of the init scripts have it either.
However it's mentioned here:
./data/data/com.rigol.launcher/shared_prefs/spUtils.xml: <string name="launch_package_name">com.rigol.scope</string>
Also this makes it clear that yes it's managed by com.rigol.launcher:
./data/system_ce/0/recent_tasks/260_task.xml:<task task_id="260" real_activity="com.rigol.scope/.MainActivity" real_activity_suspended="false" affinity="com.rigol.scope" root_has_reset="false" auto_remove_recents="false" asked_compat_mode="false" user_id="0" user_setup_complete="true" effective_uid="1000" task_type="0" first_active_time="1358470242648" last_active_time="1358470242667" last_time_moved="1358470242650" never_relinquish_identity="true" task_description_color="ff6200ee" task_description_colorBackground="ff303030" task_thumbnailinfo_task_width="0" task_thumbnailinfo_task_height="0" task_thumbnailinfo_screen_orientation="0" task_affiliation_color="-10354450" task_affiliation="260" prev_affiliation="-1" next_affiliation="-1" calling_uid="1000" calling_package="com.rigol.launcher" resize_mode="2" privileged="false" min_width="-1" min_height="-1">
(I'm referring to the calling_package attribute)
Now, how is com.rigol.launcher started? It's late, so I'll continue with this later, unless someone has an answer ready.
The purpose of this search is to get a clear understanding of the boot sequence and the component dependencies to adequately experiment with those hardcoded sleeps and other stuff to reduce the boot time.
-
The FPGA remains uninitialized and the application will not work normally.
Maybe "/rigol/shell/reload_fpga.sh" will give a clue...
Yes, but how can a user execute a script in Android? So I removed the launcher, now my oscilloscope starts with an output to the desktop. And how can I make it so that I can start the FPGA initialization from there?
-
I was able to modify the application, package it, and get it working. Tried changing the color of channel 1 to white, like Randy222. And I did it! True, not exactly where I expected :)) It’s not the wave itself that has changed, but the channel indicator :)
True, the application now does not work fully - for some reason, screenshots are not saved. I had to take a screenshot via web control. I don't know why this could be.
-
I was able to modify the application, package it, and get it working. Tried changing the color of channel 1 to white, like Randy222. And I did it! True, not exactly where I expected :)) It’s not the wave itself that has changed, but the channel indicator :)
True, the application now does not work fully - for some reason, screenshots are not saved. I had to take a screenshot via web control. I don't know why this could be.
Do you need to re-assign the shortcut key for the screenshot? Maybe the defaults are saved elsewhere(or not saved) after modification...
Also, What method did you use to modify the app? Manual or via an app?
EDIT: Earlier I posted a link at #1533 to an app that modify/signs/packs APKs (that I haven't tried yet), but the hyperlink was obfuscated behind a word. Since I'm not well experienced with Android I've been looking for apps to carry out some mods
https://apk-editor.en.uptodown.com/android
-
Do you need to re-assign the shortcut key for the screenshot? Maybe the defaults are saved elsewhere(or not saved) after modification...
Also, What method did you use to modify the app? Manual or via an app?
No, I checked that right away. The Quick button is assigned a screenshot action, but the screenshot is not created on disk. Even through the Storage menu, clicking the Save button does not save the screenshot. Settings or Wave are saved without problems.
Unfortunately, I didn’t understand the question about changing the application :(
-
Also, What method did you use to modify the app? Manual or via an app?
Unfortunately, I didn’t understand the question about changing the application :(
I'm guessing you didn't use the app, then... ;) FYI: I edited my post above yours with the link.
-
I'm guessing you didn't use the app, then... ;) FYI: I edited my post above yours with the link.
Ah, I understand what application we are talking about. No, I used apk_tool and tools from Android SDK.
-
Yeah, I think I understand why screenshots are not being recorded. When you try to take a screenshot, the following line is added to the log, among other things:
02-22 07:44:35.551 221 279 E SurfaceFlinger: Permission Denial: can't read framebuffer pid=1753, uid=10035Apparently, this is due to the fact that I changed the user of the application to solve the problem with the new keys with which I signed the application after the changes.
-
I was able to modify the application, package it, and get it working. Tried changing the color of channel 1 to white, like Randy222. And I did it! True, not exactly where I expected :)) It’s not the wave itself that has changed, but the channel indicator :)
Exactly what I expected. :)
The trace on the screen will be in the FPGA code. Good luck modifying that...
-
I was able to modify the application, package it, and get it working. Tried changing the color of channel 1 to white, like Randy222. And I did it! True, not exactly where I expected :)) It’s not the wave itself that has changed, but the channel indicator :)
Exactly what I expected. :)
The trace on the screen will be in the FPGA code. Good luck modifying that...
Are you suggesting the scope trace data is assigned colors in the framebuffer before it leaves the FPGA? And if so, are all the math and FFT waveforms treated in the same way?
Doesn't seem very logical. Any UI changes would require modifying the VHDL. Seems more likely that the Framebuffer would be color agnostic, but referenced to specific channels, and leave it to the UI team to apply the colors to the individual bit planes.
-
Are you suggesting the scope trace data is assigned colors in the framebuffer before it leaves the FPGA? And if so, are all the math and FFT waveforms treated in the same way?
Doesn't seem very logical. Any UI changes would require modifying the VHDL. Seems more likely that the Framebuffer would be color agnostic, but referenced to specific channels, and leave it to the UI team to apply the colors to the individual bit planes.
I would also expect that the FPGA does not prepare the complete frame buffer. The resolution and number of pixels in the traces is probably defined by the FPGA, as well as the greyscale values based on the digital phosphor simulation. But then the CPU will transfer those data to the screen, most likely assigning colors at that point.
-
FPGAs have no user interface at all. User interfaces is not a task for FPGAs.
All screen rendering is done by the Rockchip SOC, but according to data prepared in the FPGA, as ebastler correctly noted.
-
FPGAs have no user interface at all.
That's not categorically true, of course. I have driven HDMI screens directly from FPGAs -- they certainly can maintain an on-chip frame buffer, or generate pixel information on the fly, and drive the required TMDS signals. But as you state, that's not how the screen in the DHO scopes is connected; it is driven by the Rockchip SOC.
-
I’m not saying this, it’s just done that way.
Moreover, Rockchip has HDMI and MIPI-DSI controllers, a hardware-based framebuffer, etc.
You can use FPGA to simply organize a framebuffer and even draw the simplest elements in it. But you can’t make a complex user interface on an FPGA, it’s not that it’s impossible, but it’s damn difficult and pointless, that’s what processors are for.
-
Exactly what I expected. :)
The trace on the screen will be in the FPGA code. Good luck modifying that...
Yes, I also come to this opinion. Of course, I won’t even try to edit the FPGA configuration, it’s unrealistic :)
Are you suggesting the scope trace data is assigned colors in the framebuffer before it leaves the FPGA? And if so, are all the math and FFT waveforms treated in the same way?
Doesn't seem very logical. Any UI changes would require modifying the VHDL. Seems more likely that the Framebuffer would be color agnostic, but referenced to specific channels, and leave it to the UI team to apply the colors to the individual bit planes.
I assume that the application can set the FPGA trace drawing parameters - window size, number of points, trace color, afterglow, etc. And then just take a ready-made buffer with an image of the trace and overlay it on the image of the interface. The interface itself is drawn by the application. I found in the decompiled sources the drawing of a panel with measurement results, the drawing of a grid in the trace window, and other things related to the interface. But I couldn’t find the process for drawing the traces. Although I didn’t search very carefully and I don’t understand the organization of programs for Android :)
-
Are you suggesting the scope trace data is assigned colors in the framebuffer before it leaves the FPGA?
Yes.
And if so, are all the math and FFT waveforms treated in the same way?
Probably.
Doesn't seem very logical.
Seems perfectly logical. The FPGA does all the work of decimating the samples and doing the sin(x)/x reconstruction.
-
Everything to the screen is defined in Rigol APK.
-
The commenetd out stuff is old stuff, they just did not remove it from the script. Why they made this thing so convoluted makes you head-scratch. I suspect 800-900 is just a port down from their bigger brothers and sisters, and they just hacked out what was not needed using comment '#', and then added stuff as break-fix so it will work.
There are several Activities listed in the Manifest. You can us 'am' to call an Activity, like "am start -n com.rigol.scope/.MainActivity"
You can move the scope app to rear, and then recall the Main Activity, am will just say "already running, moving app to front", and then you see scope app on screen again.
They app start from init.rigol.rc:service startApp /system/bin/bootApp.sh
Basically an init start command (call other script). That bootApp script is also copied into /rigol/shell/, probably from doing an install of a GEL.
No, still not clear.
Ahh. Sorry, I perhaps misunderstood the question from earlier.
The Rigol start script sets up xdma, screen, FPGA, TZ, some other stuff too.
Once an APK is installed it can have two states, ENABLED or DISABLED. The app can still run in both states, but ENBALED means that Android loads the app at boot time. You can still start a DISABLED app by manually calling an Activity in that app, such as using 'am start com.rigol.scope/.MainActivity'
It's like a service in Windows, "auto" vs "manual", but in Windows services "disabled" means just that, service cannot be started at all. Android is silly in many ways.
Not sure why they had a manual start command in the start script. Maybe they were testing, maybe the app was installed as disabled and they wanted to start app at specific time, or perhaps that line is just a leftover from another model.
-
Once an APK is installed it can have two states, ENABLED or DISABLED. The app can still run in both states, but ENBALED means that Android loads the app at boot time. You can still start a DISABLED app by manually calling an Activity in that app, such as using 'am start com.rigol.scope/.MainActivity'
It's like a service in Windows, "auto" vs "manual", but in Windows services "disabled" means just that, service cannot be started at all. Android is silly in many ways.
All right, so then this question is morphing into "how does android boot initialization and service startup work?", which is outside of the scope of this thread :).
-
Once an APK is installed it can have two states, ENABLED or DISABLED. The app can still run in both states, but ENBALED means that Android loads the app at boot time. You can still start a DISABLED app by manually calling an Activity in that app, such as using 'am start com.rigol.scope/.MainActivity'
It's like a service in Windows, "auto" vs "manual", but in Windows services "disabled" means just that, service cannot be started at all. Android is silly in many ways.
All right, so then this question is morphing into "how does android boot initialization and service startup work?", which is outside of the scope of this thread :).
I was not the one to ask how the app starts.
-
The screen device runs it's own native "resolution", it has physical pixels. I'll look into the screen model and driver file to see if that's really the best res it is.
The app runs on a specified resolution. If that's not the native device res then the driver would need to interpolate. If the aspect is not the same then you get squishing and such.
I think perhaps the spec sheet tells us what the Scope app is, and less about the underlying devices of the hardware.
All good info.
Look, Randy, I really did not need an explanation from you on physical screen resolution vs. driver resolution etc. Nobody here needs that. We have all used LCD monitors and seen the effect of different resolutions and driver settings; quite a few here have designed LCD monitors into systems and driven them on a low level. Seeing you dish out those explanations just makes me wonder whether (a) you have an unrealistic picture of the audience here, or (b) you have an unrealistic picture of yourself.
On the other hand, please consider why on earth Rigol should build in a higher-resolution display and then drive it a lower resolution?! The display would be more expensive; it would take more power; it would take more CPU/GPU bandwidth to drive the pixels; the interpolated picture would look worse than on a native-resolution display. And if they still were to use that high-res display despite all that: Why would they put anything but the highest justifiable resolution number into the datasheet??
I think you can safely drop that resolution hypothesis.
Well, the /system/build.prop "persist.sys.framebuffer.main" option is set to only 1024x600@60
Whaaaa? The screen can do 1920x1080@60 just fine.
So, I can tell you, the device is not setup to use the screen at best resolution.
With the OEM setting, Scope app displays in the lower res, AND, taking screenshots and vid are in the lower res.
I changed the setting to be 1920x1080@60 and now the Scope app displays in that higher resolution (fonts and stuff will get smaller), AND, grabbing pics are now in the 1920x1080 resolution, even when you use Webcontrol take-pic.
There's also lcd_density setting, set to 228 by default. I tried 20 and the screen starts to look pixel-ated, then I try 300 and it looks good, but, from Android docs this setting appear to be some sort of "bucket" setting, so I suspect 300 is the same as the (probably calculated) 228 setting.
Why Rigol uses the lower res setting? Likely because the physical screen size is tiny, 7" diagonal, making things "hard to read" with a 1920x1080 res. I guess they figure if you want 1920x1080 you gonna slap down a larger 24" monitor with hdmi in 1920x1080 and view there?
I suspect though, if you run the DHO in 1920x1080, when you zoom in you get finer detail? I didn't do the math of painted signal pixels vs screen res.
As a side note, not sure what happened, maybe from mucking around with FPGA flashing, or maybe removal of Sparrow and reinstall did it. I have no front-end signal processing (at least not getting through Scope app to screen). 1kHz gen still works, the rest of Scope app seems to still be ok.
-
All right, so then this question is morphing into "how does android boot initialization and service startup work?", which is outside of the scope of this thread :).
The Rigol.apk application is launched by the Launcher.apk application. There is no autostart of the oscilloscope application on Android :)
-
Well, the /system/build.prop "persist.sys.framebuffer.main" option is set to only 1024x600@60
Whaaaa? The screen can do 1920x1080@60 just fine.
So, I can tell you, the device is not setup to use the screen at best resolution.
What lets you assume that the physical display resolution is the higher number? Display contents might just as well get scaled down to the physical 1024*600 if you set a higher res in software, right?
I have not seen teardown photos yet which went as far as removing the LCD panel and showing its type. So, short of taking a magnifying glass and counting pixels: Could you please measure the precise width and height of the active display area? (Scope powered on, measuring the outer dimensions of the gray frame that gets displayed.) The proportions of 1024:600 1280:800, 1920:1080 are all different. So those dimensions should give us a hint.
Edit: My bet is on 154 * 90 86 mm². Touch displays with 1024*600 resolution and 0.15 mm nearly square pixels are very common.
Edit²: Changed the vertical dimension above. Seems that the display manufacturer lies about "square" pixels. All those displays are only 85.9 mm tall according to their specs...
-
Why Rigol uses the lower res setting? Likely because the physical screen size is tiny, 7" diagonal, making things "hard to read" with a 1920x1080 res. I guess they figure if you want 1920x1080 you gonna slap down a larger 24" monitor with hdmi in 1920x1080 and view there?
I don’t believe that the developers from Rigol are so stupid that they didn’t think of installing a cheaper display with a real resolution of 1024x600 if everything in the oscilloscope is designed for this resolution.
When you specified a higher resolution to the application, it began to generate an image at this higher resolution, but Android automatically scaled it to the display resolution when outputting to it.
High resolution does not mean that everything on the screen will be small. You can look at smartphones with 2k or even higher resolution displays to see this.
-
Why Rigol uses the lower res setting? Likely because the physical screen size is tiny, 7" diagonal, making things "hard to read" with a 1920x1080 res. I guess they figure if you want 1920x1080 you gonna slap down a larger 24" monitor with hdmi in 1920x1080 and view there?
I don’t believe that the developers from Rigol are so stupid that they didn’t think of installing a cheaper display with a real resolution of 1024x600 if everything in the oscilloscope is designed for this resolution.
When you specified a higher resolution to the application, it began to generate an image at this higher resolution, but Android automatically scaled it to the display resolution when outputting to it.
High resolution does not mean that everything on the screen will be small. You can look at smartphones with 2k or even higher resolution displays to see this.
1920x1080 , aka std "real hdmi" resolution, is just about the std starting point for any manufactured display these days. Buying something less is likely hard and-or more expensive, since everything is HD, 4k, 8k, etc.
1920x1080 on a physical 7" diag display makes things very tiny. So, you paint 1024x600 to that screen via the screen driver, which has to scale it up to native screen res, which simply means it blows up the image, making it easier to read.
If you painted 1024x600 without upscale to 1920x1080 in 1:1 fashion, in essence the 1024 paints with borders, that too would look very tiny on the screen.
You can test it to see if you get better zoom ability on a signal in the 1920x1080 setting.
The setting is not an App setting. It's a system build property. The app just says "ok, go paint my data to the screen". The screen driver (OS) needs to take the image and map it to the display.
-
Well, the /system/build.prop "persist.sys.framebuffer.main" option is set to only 1024x600@60
Whaaaa? The screen can do 1920x1080@60 just fine.
So, I can tell you, the device is not setup to use the screen at best resolution.
What lets you assume that the physical display resolution is the higher number? Display contents might just as well get scaled down to the physical 1024*600 if you set a higher res in software, right?
That's false. Because if my physical screen (canvas) is 1920x1080 and whatever pic is being displayed fully on that canvas, I am looking at literally 1920x1080 pixels. If the source is native 1024x600 then I know some scaler inbetween had to do about x1.875 interpolation math. If my source is say 4k and my HD screen is full (assuming same aspect ratio, so no cropping), I know the scaler had to downscale using interpolation. Upscale means adding artifacts, downscaling means losing data. If however my source is 1920x1080 and I see full screen image on my HD 1920x1080 screen, there's no scaling, no artifacts, no lost data, it's a 1:1 mapping. A mismatch in aspect ration usually means cropping or having a border, like watching letterbox movie on an HD screen.
1024x600 is not same aspect ratio of 1920x1080, close, but not simple interger scaling.
As example, my Panny PHD plasma is an "HD" panel, yet does not have native canvas size of 1920x1080, the thing lieterally has to down-scale all HD signals to fit it's screen without changing the aspect ratio.
Anyways. There's a setting to try out. Need to remount /system as rw to make the change though.
-
All right, so then this question is morphing into "how does android boot initialization and service startup work?", which is outside of the scope of this thread :).
The Rigol.apk application is launched by the Launcher.apk application. There is no autostart of the oscilloscope application on Android :)
Launcher APK appears to be a watchdog type of app, keeps an eye on things.
com.rigol.scope should stay running when the Launcher is in disabled state.
The issue I have with not getting signal to the Scope app, seems to be that the APK did not install as a system app. So, back to figuring that out.
-
The Rigol.apk application is launched by the Launcher.apk application.
...and what is that one started by?
-
1920x1080 , aka std "real hdmi" resolution, is just about the std starting point for any manufactured display these days. Buying something less is likely hard and-or more expensive, since everything is HD, 4k, 8k, etc.
No.
1920x1080 on a physical 7" diag display makes things very tiny. So, you paint 1024x600 to that screen via the screen driver, which has to scale it up to native screen res, which simply means it blows up the image, making it easier to read.
No.
You can test it to see if you get better zoom ability on a signal in the 1920x1080 setting.
Here is a screenshot taken with the resolution set to 1600x900. Does this mean that the physical display also has the same resolution?
And if I change the resolution to 2560x1440 in the application properties and take a screenshot, will this mean that the display also has this physical resolution? :)
Launcher APK appears to be a watchdog type of app, keeps an eye on things.
com.rigol.scope should stay running when the Launcher is in disabled state.
That's right.
The Rigol.apk application is launched by the Launcher.apk application.
...and what is that one started by?
Launcher.apk itself is located in Android autostart :)
-
This screenshot looks awesome. So much better information density. Does it look good on the actual scope screen too?
-
Screenshot with a given resolution of 2560x1440 :)
-
This screenshot looks awesome. So much better information density. Does it look good on the actual scope screen too?
No, in reality the numbers on the icons are almost unreadable. For example, it is impossible to see the voltage scale on the channel, horizontal scale parameters, etc. without looking closely. True, I have a matte film pasted on it, which slightly blurs the image, but I think even without it it will be difficult to read small numbers.
-
I have not seen teardown photos yet which went as far as removing the LCD panel and showing its type. So, short of taking a magnifying glass and counting pixels: Could you please measure the precise width and height of the active display area? (Scope powered on, measuring the outer dimensions of the gray frame that gets displayed.) The proportions of 1024:600 1280:800, 1920:1080 are all different. So those dimensions should give us a hint.
Just opened mine.
LCD is silicone glued into chassis.
So until someone (unlucky one) breaks one and need replacement and find model only option is to count pixels.
Take a high res photo zoom it on PC and start counting.
LCD flex cable is 30 pins
Looks like 5 pairs of high signals.
One may be clock rest 4 of them data lines.
There may be other method to count pixels.
Create some usual resolutions pics and mark some counts on pixels at bottom-top left-right open images on scope in full screen and see which one match.
-
No, in reality the numbers on the icons are almost unreadable. For example, it is impossible to see the voltage scale on the channel, horizontal scale parameters, etc. without looking closely. True, I have a matte film pasted on it, which slightly blurs the image, but I think even without it it will be difficult to read small numbers.
Hmm, but I was wondering how such a picture would be displayed on an external high-resolution display...
-
Thanks for checking!
From my perspective there is no need to count pixels. The internet is full of 7" touch screens with 1024*600 pixels; they are thick on the ground; other scope manufacturers use them too. Higher resolution displays in that size are very exotic, and I have explained yesterday why it would seem absurd to install one and then drive and specify it at a lower resolution.
If Randy prefers to believe that he has a higher resolution display in his scope, so be it.
-
This screenshot looks awesome. So much better information density. Does it look good on the actual scope screen too?
No, in reality the numbers on the icons are almost unreadable. For example, it is impossible to see the voltage scale on the channel, horizontal scale parameters, etc. without looking closely. True, I have a matte film pasted on it, which slightly blurs the image, but I think even without it it will be difficult to read small numbers.
But this is expected. We are taking a large canvas (larger than screen) and having it scale down into screen canvas. So as to not crop the source the scaler has to squish the source (to maintain a fully readable image), which means it has to remove pixels from the source in order to fit screen canvas. It's not like taking a 1920x1080 metal cookie cutter, cutting out a section of a 2560x1440 source, and then painting the screen 1:1 with the cutout. That would be cropping the image.
The lcd density setting of 228 is odd. That does not match up with a 7"diag screen in either 1920x1080 or 1024x600. However, 1920x1080 7" would need more density than 228. So, you tell me, what's the actual HxY pixel count for this DHO display?
-
The final point in the discussion about the physical resolution of the display. I am attaching images of a screenshot with a physical resolution of 1024x600, a photograph of a section of the display, and a comparative picture of a piece of the screenshot and the display. On a piece of screenshot, pixels are demarcated by lines. It is clearly visible that the display resolution matches the screenshot resolution, that is, 1024x600.
-
No, in reality the numbers on the icons are almost unreadable. For example, it is impossible to see the voltage scale on the channel, horizontal scale parameters, etc. without looking closely. True, I have a matte film pasted on it, which slightly blurs the image, but I think even without it it will be difficult to read small numbers.
Hmm, but I was wondering how such a picture would be displayed on an external high-resolution display...
You see it better on a physically bigger screen.
1920x1080 7" is a lot of pixels very very close together, high physical DPI. 1920x1080 on a 36" monitor is same pixel count, but physical DPI is way less.
-
There's a bunch of Android commands that show resolution and, probably, physical display info.
For example:
rk3399_rigol:/ $ dumpsys|grep PhysicalDisplayInfo
PhysicalDisplayInfo{1024 x 600, 60.000004 fps, density 1.425, 213.0 x 213.0 dpi, secure true, appVsyncOffset 1000000, bufferDeadline 16666666}
rk3399_rigol:/ $ wm size
Physical size: 1024x600
1|rk3399_rigol:/ $ dumpsys window displays
WINDOW MANAGER DISPLAY CONTENTS (dumpsys window displays)
Display: mDisplayId=0
init=1024x600 228dpi cur=1024x600 app=1024x600 rng=600x600-1024x1024
deferred=false layoutNeeded=false
rk3399_rigol:/ $ cat /sys/devices/platform/display-subsystem/drm/card0/card0-DSI-1/mode
1024x600p97
rk3399_rigol:/ $ cat /sys/devices/platform/display-subsystem/drm/card0/card0-DSI-1/modes
1024x600p97
I'm pretty sure it's a physically 1024x600 screen.
-
I'm pretty sure it's a physically 1024x600 screen.
I'm absolutely sure of this.
-
I'm pretty sure it's a physically 1024x600 screen.
I'm absolutely sure of this.
Indeed. I did the phys measure too (camera and a measurable line).
So, we know phys native dpi is 170.6665px/inch
Is the actual source in this native resolution? Ideally we want 1:1 so there's no adding of artifacts or removal of data.
-
Hallelujah! :-+
-
So, I played around with different settings for the resolution of the external display (4k) when the resolution of 1440p was specified in the application properties. No improvements are noticeable, it seems that with any settings there is simply scaling from the native physical resolution of the display - 1024x600.
The thickness of the grid lines and the trace always remains the same.
-
So, this seems odd, but I guess I will come to understand why later.
My reinstall of the Sparrow.apk from Rigol GEL installed as non-system app. And then I had no signal aquisition.
Hmmmm.
Just for giggles, I ran the calibrate routine. Now it aquires signal and shows on the screen.
Also, if I halt rigol launcher, scope still runs, but the controls dont work.
-
So, I played around with different settings for the resolution of the external display (4k) when the resolution of 1440p was specified in the application properties. No improvements are noticeable, it seems that with any settings there is simply scaling from the native physical resolution of the display - 1024x600.
The thickness of the grid lines and the trace always remains the same.
What setting are you using?
-
My reinstall of the Sparrow.apk from Rigol GEL installed as non-system app.
Does it save screenshots from the Storage menu or by clicking the Quick button?
-
So, I played around with different settings for the resolution of the external display (4k) when the resolution of 1440p was specified in the application properties. No improvements are noticeable, it seems that with any settings there is simply scaling from the native physical resolution of the display - 1024x600.
The thickness of the grid lines and the trace always remains the same.
What setting are you using?
In the application manifest:
<meta-data android:name="design_width_in_dp" android:value="1024"/>
<meta-data android:name="design_height_in_dp" android:value="600"/>
I tried a variety of HDMI resolution settings, both from the oscilloscope menu and from the Android settings. From 1280x1024 to 3840x2160.
-
My reinstall of the Sparrow.apk from Rigol GEL installed as non-system app.
Does it save screenshots from the Storage menu or by clicking the Quick button?
PNG files save a-ok to /data/UserData/
But noted, I reinstalled the Rigol signed APK, not my edited version. For some reason it does not show up in the system apps list (adb shell cmd package list packages -s). Webcontrol and Launcher still do, I did no mess with those yet.
-
So, I played around with different settings for the resolution of the external display (4k) when the resolution of 1440p was specified in the application properties. No improvements are noticeable, it seems that with any settings there is simply scaling from the native physical resolution of the display - 1024x600.
The thickness of the grid lines and the trace always remains the same.
Makes sense, and the safe way to do it.
It was also how it came across on Daves's video, and the waveform looked very rough on the bigger screen. https://youtu.be/r_BYYgCqScE?si=NH9vGg2ALA7p8_02&t=47
-
There's a bunch of Android commands that show resolution and, probably, physical display info.
For example:
rk3399_rigol:/ $ dumpsys|grep PhysicalDisplayInfo
PhysicalDisplayInfo{1024 x 600, 60.000004 fps, density 1.425, 213.0 x 213.0 dpi, secure true, appVsyncOffset 1000000, bufferDeadline 16666666}
rk3399_rigol:/ $ wm size
Physical size: 1024x600
1|rk3399_rigol:/ $ dumpsys window displays
WINDOW MANAGER DISPLAY CONTENTS (dumpsys window displays)
Display: mDisplayId=0
init=1024x600 228dpi cur=1024x600 app=1024x600 rng=600x600-1024x1024
deferred=false layoutNeeded=false
rk3399_rigol:/ $ cat /sys/devices/platform/display-subsystem/drm/card0/card0-DSI-1/mode
1024x600p97
rk3399_rigol:/ $ cat /sys/devices/platform/display-subsystem/drm/card0/card0-DSI-1/modes
1024x600p97
I'm pretty sure it's a physically 1024x600 screen.
Change the setting in build.prop file, then re-run your dumpsys. Can't always rely on software. ;)
My measure does seem to indicate a physical 1024x600 screen.
-
Another good news is that the application works quite well not only after changing some properties in the .xml files, but also after changing the algorithms themselves in the source codes. True, only in the source code of the Java analogue of assembler - smali. I tried changing some small things just to check that the application would work after compiling back. After a quick search, I found an area in the source code that was easy to change - I simply reduced the radius of curvature of the elements in the measurement panel. Everything worked :)
-
But noted, I reinstalled the Rigol signed APK, not my edited version.
Ah, well then of course it will save :)
-
After a quick search, I found an area in the source code that was easy to change - I simply reduced the radius of curvature of the elements in the measurement panel. Everything worked :)
Maybe one day someone will find how to also remove those icons wasting the precious vertical space.
-
Maybe one day someone will find how to also remove those icons wasting the precious vertical space.
That's what I wanted to find, but I couldn't find it quickly :)
-
Well, it almost worked :) You just need to correct the drawing of the border around the dimension :)
-
My scope arrived yesterday, and after running for an hour the fan stopped and the back of the scope reached over 85°C.
When I contacted the supplier they said that they would have to get it returned, sent off for testing, etc.etc.
So I opened the scope and found the the fan was faulty, and it has 'dead spots' when it stops and won't start spinning without a flick.
I checked through my junk, found an old 40mm fan (with casing), and chopped off the case to leave only the three support pieces. These fitted when the bolts went, so I just screwed then under the edges of the bolts, and it works perfectly.
The interesting thing is that this fan is also ball-bearing, unlike the stock one. It is nice and quiet, but keeps the CPU at a pretty consistent 57°C (CPU_AMBIENT of 56°) in a 20°C room.
The importer is sending me a replacement for the stock fan, but this one is so much quieter than the stock one (when it worked) that I'm not going to swap it over.
Perhaps taking enclosed ball-bearing fans and chopping them is a better way to go? 40mm is not ideal, but as it works effectively and is so much quieter...
-
Measurements without space-consuming icons in the headers :)
-
Measurements without space-consuming icons in the headers :)
That is super hot.! Wow @AndyBig, Nicely done. Now, just roll that into a Rigol UI tweak tool and we'll be all set! ;) Seriously tho', great job. So much better looking.
BTW: It's probably a dirty word to use here, but I honestly think the crappy FNIRSI 1013D 7" tablet scope that I returned displayed it's measurements better than my DHO.
-
My scope arrived yesterday, and after running for an hour the fan stopped and the back of the scope reached over 85°C.
When I contacted the supplier they said that they would have to get it returned, sent off for testing, etc.etc.
So I opened the scope and found the the fan was faulty, and it has 'dead spots' when it stops and won't start spinning without a flick.
Cool little hack. Nicely done! Proof that 'not everything new is always better'.
Side note: If you care, you might try peeling up the label on the defective fan and look for cold solder joints on the SOT part(s). There's often a hall effect sensor & FETs under there.
-
BTW: It's probably a dirty word to use here, but I honestly think the crappy FNIRSI 1013D 7" tablet scope that I returned displayed it's measurements better than my DHO.
It seems to me that only the lazy have not yet scolded the way Rigol shows measurements :)) And quite deservedly, I think.
In a few minutes I will show you an even more condensed version of the measurements :)
-
It seems to me that there is no point in compressing it any more :) It’s already much better than it was in the original :) For comparison, I’ve attached a comparative picture of how it was and how it turned out :)
-
BTW: It's probably a dirty word to use here, but I honestly think the crappy FNIRSI 1013D 7" tablet scope that I returned displayed it's measurements better than my DHO.
It seems to me that only the lazy have not yet scolded the way Rigol shows measurements :)) And quite deservedly, I think.
In a few minutes I will show you an even more condensed version of the measurements :)
Sorry, I probably should have kept that comment to myself and just celebrated your accomplishments of the day., but I couldn't control it.
So is it extremely difficult to do these UI mods, and have you discovered any other defects like the screenshots not functioning?
It seems to me that there is no point in compressing it any more :) It’s already much better than it was in the original :) For comparison, I’ve attached a comparative picture of how it was and how it turned out :)
IF the label and value was all on one line, it could be smaller. But would we see enough digits to still be useable?
-
So is it extremely difficult to do these UI mods, and have you discovered any other defects like the screenshots not functioning?
I can't evaluate it objectively. For me - yes, it’s difficult, because... I'm not familiar with Android development, I don't know the basics of Android applications - how they work, how they interact with the OS, how they generate images, etc. I have to google a lot, guess a lot, and in some cases try to act at random and see what happens :) In addition, I have to change low-level code - DALVIK, which also does not add convenience. I can imagine that for a person who is well acquainted with developing applications for Android, this will all be much easier :)
IF the label and value was all on one line, it could be smaller. But would we see enough digits to still be useable?
Yes, I thought about this too, but the names of some dimensions are too long for all the numbers to fit after them. Although in principle you can expand the entire panel :)
-
Side note: If you care, you might try peeling up the label on the defective fan and look for cold solder joints on the SOT part(s). There's often a hall effect sensor & FETs under there.
Yes, I did that, and I reflowed the pads I could see, but most is under the plastic. Still no luck.
J.
-
A convenient application for unpacking and decompiling .apk https://github.com/skylot/jadx . It can even work as a debugger, I tried it and it works :)
-
But could we omit the names and only show (a scaled down) icon together with the value on one line?
And for the next wish: make it a setting we can change somewhere using the UI ;-)
Yes, I thought about this too, but the names of some dimensions are too long for all the numbers to fit after them. Although in principle you can expand the entire panel :)
-
It seems to me that only the lazy have not yet scolded the way Rigol shows measurements :)) And quite deservedly, I think.
I have.
It's especially criminal how the stat values are split across two lines:
(https://www.eevblog.com/forum/testgear/rigol-dho804-test-and-compare-thread/?action=dlattach;attach=1896087;image)
The DHO1000 does it like this:
(https://www.eevblog.com/forum/testgear/rigol-hdo1000-and-hdo4000-12bit-oscilloscopes-launched-in-china/?action=dlattach;attach=1946721;image)
The firmware is supposedly the same, I wonder if we can get the DHO800 to do it like the DHO1000.
-
I would love to have the statistics/measurements in a window that can be moved along the screen.
-
But could we omit the names and only show (a scaled down) icon together with the value on one line?
Icons that are one line of text high will simply not be legible on the screen.
And for the next wish: make it a setting we can change somewhere using the UI ;-)
You think too well of my ability to modify the application :))))
-
The DHO1000 does it like this:
The firmware is supposedly the same, I wonder if we can get the DHO800 to do it like the DHO1000.
This is very interesting. You need to get the application from DHO1000 and see how it is done there.
-
This is very interesting. You need to get the application from DHO1000 and see how it is done there.
Should all be nicely laid out in the .GEL files which Rigol offers for download, shouldn't it? I certainly appreciate their open format for the firmware update files. :)
-
But could we omit the names and only show (a scaled down) icon together with the value on one line?
Icons that are one line of text high will simply not be legible on the screen.
Maybe I didn't express myself quite right, but if you take the current icon height (so the same viewing as we are used to) and place the values next to it, it can work.
See the image [attachimg=1]
You think too well of my ability to modify the application :))))
Remember Pipi Longstocking: “I have never tried that before, so I think I should definitely be able to do that.” :-DD
-
Maybe I didn't express myself quite right, but if you take the current icon height (so the same viewing as we are used to) and place the values next to it, it can work.
I don't think the icons alone are sufficiently self-explanatory to distinguish all the different measurement flavors.
-
Maybe I didn't express myself quite right, but if you take the current icon height (so the same viewing as we are used to) and place the values next to it, it can work.
See the image (Attachment Link)
Well, at a quick glance, try to distinguish these two icons from each other from your picture on a rather small oscilloscope screen, and also remember which icon means what :)
-
Well, it almost worked :) You just need to correct the drawing of the border around the dimension :)
Very promising! Hope this will eventually boil down to a recipe suitable for a regular (advanced) user.
-
It's especially criminal how the stat values are split across two lines:
Maybe negligent software developer by mistake replace tab with new line
-
If you look at the measurement dialogs, Rigol has supplied a different icon for each type of measurement.
You need the information on which channel(s) the measurement takes place.
That can be done by attaching the coloured text as shown in my image.
Or, if we would be really fancy, place the icon in a bar with the same colour as the channels.
I don't think the icons alone are sufficiently self-explanatory to distinguish all the different measurement flavors.
-
Perhaps taking enclosed ball-bearing fans and chopping them is a better way to go? 40mm is not ideal, but as it works effectively and is so much quieter...
I doubt that such a big difference in the loudness can be attributed to the ball bearing vs sleeve (or whatever) difference. Both create almost zero noise on their own, unless broken.
There must be something else -- the number of blades, their angle, and, very likely, the very difference between the 40 mm and 45 mm diameter, where the latter leaves much less space between the edges of the blades and the fins of the heat sink, possibly resulting in the air siren effect.
-
If you look at the measurement dialogs, Rigol has supplied a different icon for each type of measurement.
Sure. But I would not be willing to memorize the subtle details to distinguish them all, and recall which one means which. And, when in use, stare at them long enough to actually see all the little details.
-
with a bit of practise that is not too hard. Rigol did a good job on the icons, and if you add a measurement, you'll see the corresponding icon.
-
If you look at the measurement dialogs, Rigol has supplied a different icon for each type of measurement.
Right, but they are so small and also drawn in gray over dark background, that they become useless unless you look at them up close. It also takes time and effort to distinguish one from another, they all look too similar.
Text is just so much better -- it is read and recognized at a glance, can be read from a (much) larger distance.
-
with a bit of practise that is not too hard. Rigol did a good job on the icons, and if you add a measurement, you'll see the corresponding icon.
Good luck distinguishing Vmax, Vtop, Vamp and Vpp, to pick just one example. :P
-
with a bit of practise that is not too hard. Rigol did a good job on the icons, and if you add a measurement, you'll see the corresponding icon.
There's no way one can realistically tell these three apart from 60 cm, let alone remember which means what:
[attachimg=1]
Text labels, on the other hand, are readable and immediately obvious.
-
If you look at the measurement dialogs, Rigol has supplied a different icon for each type of measurement.
You need the information on which channel(s) the measurement takes place.
That can be done by attaching the coloured text as shown in my image.
Or, if we would be really fancy, place the icon in a bar with the same colour as the channels.
The icons, of course, are different, and they generally indicate what they mean. But the differences are so insignificant and hard to see with a small icon size that you have to look closely to understand which icon is drawn on this dark gray background :)
-
Very promising! Hope this will eventually boil down to a recipe suitable for a regular (advanced) user.
Yes, you just need to uninstall the native application and install the modified one. All this is easily done through ADB :) But the ability to take screenshots on an oscilloscope is lost; this can only be done through web control.
Maybe negligent software developer by mistake replace tab with new line
No, it's more complicated than that. Partially specified through layouts in .xml, partially defined in source codes. It’s difficult for me to understand all these intricate interweavings of the structure of the Android application.
-
with a bit of practise that is not too hard. Rigol did a good job on the icons, and if you add a measurement, you'll see the corresponding icon.
There's no way one can realistically tell these three apart from 60 cm, let alone remember which means what:
(Attachment Link)
Text labels, on the other hand, are readable and immediately obvious.
60 cm is a bit much, but on the web interface, I can clearly see the differences.
And as I said, it takes a bit of practice, but I really think Rigol has done a good job.
But as asked before: maybe it should be configurable in a settings dialog.
-
with a bit of practise that is not too hard. Rigol did a good job on the icons, and if you add a measurement, you'll see the corresponding icon.
Good luck distinguishing Vmax, Vtop, Vamp and Vpp, to pick just one example. :P
Maybe I have eagle eyes, but I can easily do that.
-
Good luck distinguishing Vmax, Vtop, Vamp and Vpp, to pick just one example. :P
Maybe I have eagle eyes, but I can easily do that.
You have three people in this thread who very quickly jumped in to say that the icons alone are too difficult to distinguish. (Visually, since they are small; and cognitively, since many of them are very similar to others.) Nobody has chimed in yet to support your suggestion. Small numbers, but I dare say that a full-blown usability study would come to the same conclusion.
-
This is very interesting. You need to get the application from DHO1000 and see how it is done there.
Should all be nicely laid out in the .GEL files which Rigol offers for download, shouldn't it? I certainly appreciate their open format for the firmware update files. :)
Yes, I have already downloaded and unpacked the GEL for DHO1000, I’ll try to look and compare later :)
-
I'm not pushing my preferences to anyone. If some people want text labels fine, I would like to do without.
Usability studies show that some people like an icon only approach, others like icon+text.
The people from Microsoft have made a special registry setting for that called TaskbarGlomLevel.
TaskbarGlomLevel change its value to 0, 1 or 2 depending on what you need it to do.
To always combine, hide labels (default): TaskbarGlomLevel = 0
Combine when taskbar is full/Show labels: TaskbarGlomLevel = 1
Never combine/Show labels: TaskbarGlomLevel = 2
You have three people in this thread who very quickly jumped in to say that the icons alone are too difficult to distinguish. (Visually, since they are small; and cognitively, since many of them are very similar to others.) Nobody has chimed in yet to support your suggestion. Small numbers, but I dare say that a full-blown usability study would come to the same conclusion.
-
Personally I prefer just icons when we can distinguish them clearly or can customize which ones appear on the grid space available.
But when icons differ only at the pixel level then it's better to use a label.
I appreciate the effort Rigol placed in creating those icons BUT it doesn't seem to work for me. With that said, I wouldn't be able to design better icons.
The icons are good, but could have a bit higher contrast.
-
The DHO1000 does it like this:
The firmware is supposedly the same, I wonder if we can get the DHO800 to do it like the DHO1000.
This is very interesting. You need to get the application from DHO1000 and see how it is done there.
Download the .gel file from Rigol.
-
If you look at the measurement dialogs, Rigol has supplied a different icon for each type of measurement.
Sure. But I would not be willing to memorize the subtle details to distinguish them all, and recall which one means which. And, when in use, stare at them long enough to actually see all the little details.
A better hack is to add some code that gives a slider switch "icons on/off".
-
This is very interesting. You need to get the application from DHO1000 and see how it is done there.
Should all be nicely laid out in the .GEL files which Rigol offers for download, shouldn't it? I certainly appreciate their open format for the firmware update files. :)
Yes, I have already downloaded and unpacked the GEL for DHO1000, I’ll try to look and compare later :)
Most of everything that's in the dho800-900 code comes from their "same level" DSO model.
-
A few items to note.
1) screen res. build.prop is where you go. I set mine to 1280x750 (that's 1.25x native). It displays well, lets you grab pics at that res 96dpi.
2) build.prop setting will carry into "dumpsys |grep Display" , but , actual physical screen seems to be captured by a function "fts_dt_coords", no matter the prop setting, this function gets "x(0 1024) y(0 600)". This appears to be the physcial screen layout.
Now, onto another question. What is the scope doing here (pics).
I have some noise from open probe, then I go to Stop mode, then I off/on CH1 keypad. Why the changes in the display? Is the last one just a view of last captured screen in buffer? Pics are in the 1280x750 size.
-
Now, onto another question. What is the scope doing here (pics).
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2031956;image)
-
Now, onto another question. What is the scope doing here (pics).
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2031956;image)
I get it, but the scope was in STOP mode for pic #2 and #3. Where did the superposition samplings go after doing a CH1 off the on ?
-
But could we omit the names and only show (a scaled down) icon together with the value on one line?
Icons that are one line of text high will simply not be legible on the screen.
Maybe I didn't express myself quite right, but if you take the current icon height (so the same viewing as we are used to) and place the values next to it, it can work.
See the image (Attachment Link)
You think too well of my ability to modify the application :))))
Remember Pipi Longstocking: “I have never tried that before, so I think I should definitely be able to do that.” :-DD
I was checking this out on my 804. But, instead of opening a Measure side tray I just open a Measure Window, add some measurements, and that can give way more info than the side tray can, withouit icons. Measure Window has each measurement already expanded. I do notice though that some values get truncated in side-by-side windows, but you can move it to above-below view so that the truncate gets removed, it's like "153...mv" in side-side view will then be "153.52mv" in the above-below windowing view.
So, although the icons thing for side tray does allow more stuff in the side tray, not sure if we need to remove icons there. If you need so many measures, then use the Measure Window and just use side tray Measure for one or three measures. Measure Window allows you to see all the stats for that measurement without expanding the item in side tray, which then pushes the other measures out of view.
I guess in some ways the UI is flexible, just depends on how you want or need to view data on the screen.
-
...not sure if we need to remove icons there. If you need so many measures, then use the Measure Window and just use side tray Measure for one or three measures.
...And "640K ought to be enough for anyone."
-B. Gates
-
The DHO1000 does it like this:
The firmware is supposedly the same, I wonder if we can get the DHO800 to do it like the DHO1000.
This is very interesting. You need to get the application from DHO1000 and see how it is done there.
Download the .gel file from Rigol.
@Fungus, I read that as they were saying: "Hey, that's a great idea. Maybe you could 'Download the .gel file from Rigol.', roll up your sleeves and pitch in on the effort".
And before you attack me ad hominem;
I would love to contribute on the Android hacks, and I'm trying to learn like @AndyBig did, but I'm not very capable yet.
-
Measure window is awfully large, taking half of the waveform display area. It works for some situations, but for others a small sidebar works better.
-
A few items to note.
1) screen res. build.prop is where you go. I set mine to 1280x750 (that's 1.25x native). It displays well, lets you grab pics at that res 96dpi.
2) build.prop setting will carry into "dumpsys |grep Display" , but , actual physical screen seems to be captured by a function "fts_dt_coords", no matter the prop setting, this function gets "x(0 1024) y(0 600)". This appears to be the physcial screen layout.
Can you write up a step/step guide for editing build.prop for those of us not super great at Android/Linux hackin'? I'm pretty good with things now, but it's frustrating trying to parse thru exabytes of crap that may/not be applicable to a particular model. I'm sure others would like something as well.
Now, onto another question. What is the scope doing here (pics).
I have some noise from open probe, then I go to Stop mode, then I off/on CH1 keypad. Why the changes in the display? Is the last one just a view of last captured screen in buffer? Pics are in the 1280x750 size.
I can't check on my scope right now, but here's a theory:
Can you try that exact same experiment on the 1K calibration signal?
It sounds like you're stopping acquisition of a spurious noise signal source and expecting the same results. Try a known repetitive source.
-
with a bit of practise that is not too hard. Rigol did a good job on the icons, and if you add a measurement, you'll see the corresponding icon.
Good luck distinguishing Vmax, Vtop, Vamp and Vpp, to pick just one example. :P
Maybe I have eagle eyes, but I can easily do that.
my condolence to you, did you get the eagle eyes from operation? afaik human should have human eye and eagle cant type in forum... but anyway funny aside... my aging eyes luckily still can distinguish too... except not sure what they represent, i didnt rely too much on small icons... this proved eagle eye conundrum..
-
I get it, but the scope was in STOP mode for pic #2 and #3. Where did the superposition samplings go after doing a CH1 off the on ?
Your switching CH1 off has cleared from the screen buffer the picture of the multiple, overlaid CH1 traces. So when you switch CH1 on again, the only data the scope has to display is the most recent capture (from the capture data buffer), and that's what it shows you.
I.e. it falls back onto the same information it would show you right away upon stopping if you had disabled the "waveform freeze", as described in the manual section Fungus has shared.
-
I get it, but the scope was in STOP mode for pic #2 and #3. Where did the superposition samplings go after doing a CH1 off the on ?
Your switching CH1 off has cleared from the screen buffer the picture of the multiple, overlaid CH1 traces. So when you switch CH1 on again, the only data the scope has to display is the most recent capture (from the capture data buffer), and that's what it shows you.
I.e. it falls back onto the same information it would show you right away upon stopping if you had disabled the "waveform freeze", as described in the manual section Fungus has shared.
Not sure, only because that last capture trace from buffer is always a smaller clean capture? Why is it never one of the other more erratic looking items?
-
Not sure, only because that last capture trace from buffer is always a smaller clean capture? Why is it never one of the other more erratic looking items?
The "erratic looking items" are the overlay of many traces taken in succession, with intensities weighted by how often a certain pixels sees a trace, and how long ago the last trace hit it. That mimics the behavior of analog CRT scopes. It lets you see which types of traces are frequent and which ones represent rare events. Called "digital phosphor technology" or similar by the scope manufacturers, it was a big step forward in digital scopes, especially when it became available in affordable ones about 10 years ago.
All the individual sweeps look like the "clean" one in your third screenshot.
May I recommend that you spend a bit more time with the scope part of your DHO, and less with the Android part? ;) Otherwise you might have saved yourself a lot of money by buying a cheap tablet instead of the scope...
-
Measure window is awfully large, taking half of the waveform display area. It works for some situations, but for others a small sidebar works better.
Not true. The waveform display remains the same, that's just a window that gets shrunk to 1/2 the LCD display.
But yeah, it shrinks the waveform window. Pros & Cons. I guess Rigol calls it "flexible" views.
But if you jam 6 Measures in side Tray "measure", when you expand one it will force the ones below down and some will fall out of view. Measure Window you can see all the expanded Measures at the same time. Pros & Cons.
Rigol almost got UI right. They should just code in some on/off sliders and allow the user to have icons or not. Or better yet, code the APK to read a "style" xml file from /rigol/data/ where you can edit your own styles or "skin", this way everyone can run their UI their own way.
-
Not sure, only because that last capture trace from buffer is always a smaller clean capture? Why is it never one of the other more erratic looking items?
The "erratic looking items" are the overlay of many traces taken in succession, with intensities weighted by how often a certain pixels sees a trace, and how long ago the last trace hit it. That mimics the behavior of analog CRT scopes. It lets you see which types of traces are frequent and which ones represent rare events. Called "digital phosphor technology" or similar by the scope manufacturers, it was a big step forward in digital scopes, especially when it became available in affordable ones about 10 years ago.
All the individual sweeps look like the "clean" one in your third screenshot.
May I recommend that you spend a bit more time with the scope part of your DHO, and less with the Android part? ;) Otherwise you might have saved yourself a lot of money by buying a cheap tablet instead of the scope...
I uderstand the individual traces are overlayed.
I think you missued what I was saying.
My observation was rather straightforward. None of the erratic looking individual traces ever are displayed after turning CH back On. Given how bright the screen in with all the overlay traces (a blob of color), I never get one of the bigger/larger traces when CH goes back to On.
-
My observation was rather straightforward. None of the erratic looking individual traces ever are displayed after turning CH back On. Given how bright the screen in with all the overlay traces (a blob of color), I never get one of the bigger/larger traces when CH goes back to On.
As seen by the shading of the overlaid traces, the ones with higher amplitudes are rare events. They should show up as individual capture sporadically if you try often enough. Or, if you want to isolate them deliberately, you can set a higher trigger threshold.
-
I have some noise from open probe, then I go to Stop mode, then I off/on CH1 keypad. Why the changes in the display? Is the last one just a view of last captured screen in buffer? Pics are in the 1280x750 size.
Again, @Randy222
You're stopping acquisition of a spurious noise signal source and expecting the same results each time.
Can you duplicate this "erratic looking data" on the 1K calibration signal? (a known repetitive source.)
-
I have some noise from open probe, then I go to Stop mode, then I off/on CH1 keypad. Why the changes in the display? Is the last one just a view of last captured screen in buffer? Pics are in the 1280x750 size.
Again, @Randy222
You're stopping acquisition of a spurious noise signal source and expecting the same results each time.
Can you duplicate this "erratic looking data" on the 1K calibration signal? (a known repetitive source.)
Sporadic traces are easier to see it.
A constant 1kHz sq.wave will run with a thicker horizononatl lines, then you Stop it, CH off, CH on, then the horizonatl sections become thin. Repeat that and you get the same thing with slightly different looking horizontal line. Can'y really see what I mean with a contant repeat signal.
Sporadic traces are all over the screen, I would expect some of them to show during the last step, but what I get is always a "narrow" trace kinda through the center of what was once the blob of color on the screen.
Probably all normal, was just making observation.
-
Cooling fan noise.
I must say, the little mighty that comes with is rather noisy, I can here that whine from 20ft away. So I can understand those who say the thing is noisy.
I changed direction on making that noise go away. Instead is large external fan I will park two small fans inside under the rear cover to replace the noisy little mighty that came with. Something like the attached.
-
Why the changes in the display?
I think the "persisted" part isn't stored anywhere. It's just in the frame buffer.
Is the last one just a view of last captured screen in buffer?
Yes.
-
with a bit of practise that is not too hard. Rigol did a good job on the icons, and if you add a measurement, you'll see the corresponding icon.
There's no way one can realistically tell these three apart from 60 cm, let alone remember which means what:
Rigol should make the icons bigger!
-
i finished my "barebone minimum functioning" of "full functionalities cloned" PLA2216 LA Probe for my DHO800.. and now is testing time! (last night) it can read all channels correctly now after fixing 2 unsoldered pins today, now i have 16 channels LA probe at 625MSps 25Mpts memory yes! next test will be to download the LA data to PC to see if the dso is not lying. maybe tomorrow since i need to learn how to do it in SW... so far to probe LA offline on screen, we dont need the missing DDR3L RAM fwiw...
ps: during calibration, if fpga detecting floating input (unsoldered pins or joints), it will deactivate that 8bit lane and floored the threshold (trigger level) to -20V. my mistake. please also note when operating the LA probe, i can disconnect it from dso, and dso will turn off LA GUI faithfully, when i connect it again, dso will say "LA Probe Connected" and we can activate LA GUI, so this means, we can disconnect and reconnect the probe during dso operation, at least FW/GUI supports it, unlike what the documentation said. maybe next time i video and snapshots probing more realistic stuffs on all 16 channels. fwiw cheers.
HQ thread: https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800)/msg5352677/#msg5352677 (https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800)/msg5352677/#msg5352677)
-
Most of everything that's in the dho800-900 code comes from their "same level" DSO model.
But there are plenty of differences between these applications.
A better hack is to add some code that gives a slider switch "icons on/off".
This is much more difficult to do than just changing something existing :)
-
i finished my "barebone minimum functioning" of "full functionalities cloned" PLA2216 LA Probe for my DHO800.. and now is testing time! (last night) it can read all channels correctly now after fixing 2 unsoldered pins today, now i have 16 channels LA probe at 625MSps 25Mpts memory yes! next test will be to download the LA data to PC to see if the dso is not lying. maybe tomorrow since i need to learn how to do it in SW... so far to probe LA offline on screen, we dont need the missing DDR3L RAM fwiw...
ps: during calibration, if fpga detecting floating input (unsoldered pins or joints), it will deactivate that 8bit lane and floored the threshold (trigger level) to -20V. my mistake. please also note when operating the LA probe, i can disconnect it from dso, and dso will turn off LA GUI faithfully, when i connect it again, dso will say "LA Probe Connected" and we can activate LA GUI, so this means, we can disconnect and reconnect the probe during dso operation, at least FW/GUI supports it, unlike what the documentation said. maybe next time i video and snapshots probing more realistic stuffs on all 16 channels. fwiw cheers.
HQ thread: https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800)/msg5352677/#msg5352677 (https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800)/msg5352677/#msg5352677)
Super!!! Thanks for the work you've done! This is a wonderful result!!!! I think everything else will work as it should! We will now wait for the result on AFG. It’s just that you are the only one today who could and will be able to do this! Thank you again for your enormous contribution to this device!
-
That's wonderful news! I miss Nikki Smith new posts, but Mechatrommer just nailed it!
I have PLA2216 and DHO804. So I want to try the LA probe with hacked DHO.
Mechatrommer, tell us, please, did you add any unpopulated (missed) components near the dedicated place for IDC 50M (2.54mm pitch) header connector? I mean, one piece of MPM3630 (the DC-DC buck converter with integrated MOSFET, inductor and two capacitors, made by MPS in QFN-20 package, https://eu.mouser.com/ProductDetail/Monolithic-Power-Systems-MPS/MPM3630GQV-Z (https://eu.mouser.com/ProductDetail/Monolithic-Power-Systems-MPS/MPM3630GQV-Z) https://www.monolithicpower.com/media/document/MPM3630_r1.0.pdf (https://www.monolithicpower.com/media/document/MPM3630_r1.0.pdf) https://www.monolithicpower.com/en/mpm3630.html (https://www.monolithicpower.com/en/mpm3630.html) ), two dual op amps (TP1282 in MSOP-8 package, TP1282L1-VR or equal substitute) and some bulky surface mounted diode above that two op amp ICs.
Is that diode present on DHO900' PCB? Does anyone have a clear pictures (or scans) of DHO900 series PCB (DHO914(S), DHO924(S))?
Thanks to all contributors!
-
Is that diode present on DHO900' PCB? Does anyone have a clear pictures (or scans) of DHO900 series PCB (DHO914(S), DHO924(S))?
Thanks to all contributors!
If we are talking about this diode: No it is not populated on a 924S. Thas spot is visible even without opening. My first usecase for a Kensington slot. :popcorn:
-
Does anyone have a clear pictures (or scans) of DHO900 series PCB (DHO914(S), DHO924(S))?
I reposted one of the main DHO900 PCBa a few pages back link here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5338592/#msg5338592) from early days when Mechatrommer was trying to identify components to do his upgrade. This side is pretty much all you need AFAIK, then you can use the Flickr teardown photos for everything else in the 800/900s. Best of luck to ya!
-
Mechatrommer, tell us, please,
already answered you in this post, i dont want to double post, cheers.
https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800)/msg5353574/#msg5353574 (https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800)/msg5353574/#msg5353574)
-
Today I finally decided to record the image that I took from my original card immediately after receiving the oscilloscope onto a new SD. After I inserted a new card with a recorded image into the oscilloscope and turned it on, after about 40 seconds of loading, a window like the one in the screenshot appeared.
When I try to enter a password, a message appears, which I don’t remember verbatim, but its meaning is: “Although the correct password was entered, the data still could not be decrypted. It is necessary to reset the system to factory settings.” And the "Reset" button. Moreover, this appears when entering any password, I tried 1111, 1234, and 0000.
After I confirmed the reset and the reset process finished, everything worked fine after rebooting. But I was surprised by this behavior, because the image was read from a working card. In theory, the oscilloscope should have simply turned on and started working as with the original card...
-
If we are talking about this diode: No it is not populated on a 924S. Thas spot is visible even without opening. My first usecase for a Kensington slot. :popcorn:
OK, I see. Thank you, Mechatrommer and axantas !
AndyBig, are you talking about Lexar microSD (TransFlash) card? Do you remember what software utility you used to make an image of the original memory card? Anyway, can an image being made of bootable media with Linux-based OS (which Android is happen to be) be, like, "a bit-perfect copy" in all circumstances?
May this issue have something in common, something to do with "improperly unmounted volume with Linux file system" being back-up'ed to an image? Because I recently got similar warning message when was trying to make a back-up image of a bootable microSD from chinese portable video consoles (like Datafrog SF2000, Anbernic RG353V) via Norton Ghost utility.
-
AndyBig, are you talking about Lexar microSD (TransFlash) card? Do you remember what software utility you used to make an image of the original memory card? Anyway, can an image being made of bootable media with Linux-based OS (which Android is happen to be) be, like, "a bit-perfect copy" in all circumstances?
May this issue have something in common, something to do with "improperly unmounted volume with Linux file system" being back-up'ed to an image? Because I recently got similar warning message when was trying to make a back-up image of a bootable microSD from chinese portable video consoles (like Datafrog SF2000, Anbernic RG353V) via Norton Ghost utility.
Yes, about this card. Now I don’t remember exactly what program I used to read the image from it, either HDDRawCopy or Win32DiskImager. I recorded the image onto a new HDDRawCopy card.
I'm too new to Android and Linux to speculate, I just don't know why this could be :) But actually it looks strange to me.
-
I finally achieved what I wanted from the very beginning - to have the measurements occupy one line. I spent two days digging on the Internet, mastering the basics of element layout in Android applications, and in the end I understood enough to do it :) All that remains is to correct the drawing of the borders and background of these lines, but this is not difficult :) However, I had to slightly increase the width of the entire panel, but in my opinion this is not very critical.
-
well done, I like it.
-
AndyBig, are you talking about Lexar microSD (TransFlash) card? Do you remember what software utility you used to make an image of the original memory card? Anyway, can an image being made of bootable media with Linux-based OS (which Android is happen to be) be, like, "a bit-perfect copy" in all circumstances?
May this issue have something in common, something to do with "improperly unmounted volume with Linux file system" being back-up'ed to an image? Because I recently got similar warning message when was trying to make a back-up image of a bootable microSD from chinese portable video consoles (like Datafrog SF2000, Anbernic RG353V) via Norton Ghost utility.
In Linux, (almost) everything is a file, which You can read, write, etc. Right now Im writing on a laptop with Linux - both disk drives are files in /dev (/dev/sda and /dev/sdb) directory and having permission to read those files (usually only root id:0 and users in group disk) You can read every bit as it is. Same with SD cards and everything else (framebuffer for example). So You can make 1:1 copy. Im planning to do this (maybe today) and change SD card to decrease boot time and increase space for more files. Just copy this disk file into another file and back to another SD card.
Also Im planning to change this scope to run Linux instead of Android, as I said previously.
-
I finally achieved what I wanted from the very beginning - to have the measurements occupy one line. I spent two days digging on the Internet, mastering the basics of element layout in Android applications, and in the end I understood enough to do it :) All that remains is to correct the drawing of the borders and background of these lines, but this is not difficult :) However, I had to slightly increase the width of the entire panel, but in my opinion this is not very critical.
Do You have instructions or ready file(s) to do the same by us?
-
What program do you recommend to backup an oscilloscope system from an SD card?
-
AndyBig, are you talking about Lexar microSD (TransFlash) card? Do you remember what software utility you used to make an image of the original memory card? Anyway, can an image being made of bootable media with Linux-based OS (which Android is happen to be) be, like, "a bit-perfect copy" in all circumstances?
May this issue have something in common, something to do with "improperly unmounted volume with Linux file system" being back-up'ed to an image? Because I recently got similar warning message when was trying to make a back-up image of a bootable microSD from chinese portable video consoles (like Datafrog SF2000, Anbernic RG353V) via Norton Ghost utility.
In Linux, (almost) everything is a file, which You can read, write, etc. Right now Im writing on a laptop with Linux - both disk drives are files in /dev (/dev/sda and /dev/sdb) directory and having permission to read those files (usually only root id:0 and users in group disk) You can read every bit as it is. Same with SD cards and everything else (framebuffer for example). So You can make 1:1 copy. Im planning to do this (maybe today) and change SD card to decrease boot time and increase space for more files. Just copy this disk file into another file and back to another SD card.
Also Im planning to change this scope to run Linux instead of Android, as I said previously.
In this case, there are no readable files on the memory card. The file system is not recognized on it at all - both under Windows and Linux, as far as I understand from what I read on this forum. Therefore, copying data from this card is carried out by special programs that simply read all the bytes at a low level by sector.
If you are hoping to speed up loading by replacing the card with a faster one, this will not help. The read speed from the card is not a bottleneck for boot time, this has already been tested before, and I tested it too, installing a card with a stated read speed of up to 104 MB/sec :)
Do You have instructions or ready file(s) to do the same by us?
Everything here is actually quite simple. The .apk file is unpacked by the appktool utility, resulting in a directory with the complete contents of the application. This directory also contains the source codes of DALVIK in .smali files - a kind of assembler in the Java world. Changing the logic of the application is just possible by editing these sources. In addition, there are .xml files with descriptions of various properties, parameters, arrangement of elements in forms, etc. For example, in order to change the location and size of elements on the measurement panel, I just changed the layout description in one of the .xml files. But to change the process of drawing the border and background for these elements, I changed the source codes of the program in the .smali file.
To make it easier to navigate these Java assembler sources, you can decompile the .dex files obtained after the apktul into source codes in Java. They will not be able to compile back into the application, but they can better understand what is happening in .smali and what and how needs to be changed there to get the desired result.
After the changes have been made, the application is reassembled using the same appktool utility. After this, the resulting new application needs to be run through two more utilities - to align all internal resources of 4 bytes, and to sign the application. And you can install the resulting application on Android :)
I'll probably write more detailed instructions on all these steps later. In the meantime, I’m ready to answer questions if someone doesn’t succeed.
-
What program do you recommend to backup an oscilloscope system from an SD card?
Personally Im using cp (copy) in the Linux terminal emulator. However most people recommend using dd instead of cp. Graphical software is doing the same job as cp, but BTW often its slower - especially when You have many small files.
cp /dev/sdb /home/userName/someFolderName/anyFileNameYouWant
ls to list files. dmesg | less to see log (something was connected and new disk file was created) and eventually some disk tools to make sure of what is what, like a (g)parted, fdisk, cfdisk, etc.
-
What program do you recommend to backup an oscilloscope system from an SD card?
For example - https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074423/?topicseen#msg5074423 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5074423/?topicseen#msg5074423)
-
In this case, there are no readable files on the memory card. The file system is not recognized on it at all - both under Windows and Linux, as far as I understand from what I read on this forum. Therefore, copying data from this card is carried out by special programs that simply read all the bytes at a low level by sector.
In Linux as I said before, You dont need to install and use "special programs", because of philosophy "everything is a file" - even I can manage fan speed in my laptop with reading and writing to a text file in a system directory - If I want, I can make simple script program to make anything with that. Same with block devices - accessible at low level just by reading/writing (or copying) file - contents are 1:1 of what is on the SD card. This is one of many reasons, why I dont have Windows.
The file system is not recognized on it at all
Maybe Im not a expert in file systems (BTW. best world expert in it, currently is in jail, because his wife is dead), but I have little bit of experience (mostly with *nix and fat) file systems and recovering files from damaged fs, so I will try to do a hex dump or some tools to see if there is a any fs hided deep inside - I expect some heder before. Eventually this is hardware encrypted - in that case it will be difficult to do anything.
If you are hoping to speed up loading by replacing the card with a faster one, this will not help. The read speed from the card is not a bottleneck for boot time, this has already been tested before, and I tested it too, installing a card with a stated read speed of up to 104 MB/sec :)
When I was copying (somewhere here I put a video if it) files to install a game on this scope, it was incredibly slow for some reason. I will check this later also.
-
so I will try to do a hex dump
Well, I’m not a Linux expert at all, and not even a user, so I won’t say with confidence, but it seems that this issue was discussed in this or in a neighboring topic and it was said that simple copying doesn’t work, you need to do a low-level dump. But I could be wrong :)
-
so I will try to do a hex dump
Well, I’m not a Linux expert at all, and not even a user, so I won’t say with confidence, but it seems that this issue was discussed in this or in a neighboring topic and it was said that simple copying doesn’t work, you need to do a low-level dump. But I could be wrong :)
Please read my previous couple posts with proper understanding. Im not a Windows user. Not at all. You can make a binary copy of raw contents of any disk by just copying file from a system directory, because "everything is a file". Its no matter what is in it, You will make a (dump) copy 1:1 without any "fancy special programs". After that I can use any software capable to read file(s) - including hex/ascii view or file recovery software which is looking for any file system hided in a file. File being a raw copy of SD contents
One very simple command to copy raw binary data from a serial block device - including SD cards:
cp /dev/sdb /home/userHomeDirectory/rawBinaryImageOfFancySDcardFromScope.fancyLongFileExtension
To be less fancy, I can use any graphical file manager in Linux to make exactly same thing.
-
You can make a binary copy of raw contents of any disk by just copying file from a system directory, because "everything is a file". Its no matter what is in it, You will make a (dump) copy 1:1 without any "fancy special programs".
Thank you, now it becomes clearer to me. So I was wrong :)
-
PS. Please be aware of possible many disk files. With additional number at the end, this is a raw contents of a partition/volume from same disk without number.
Once, I did a mistake and destroyed contents in a SD card with photos from a phone.
-
That's it, I'll stop here with the alteration of measurements. True, so far I have not been able to put the names of the parameters and the values in the disclosed measurement points into one line...
-
That's near perfect. But this still prevents taking screenshots, right? I wonder what's the deal with that.
-
That's near perfect. But this still prevents taking screenshots, right? I wonder what's the deal with that.
Umm -- what am I looking at in AndyBig's most recent post then? I nearly mistook it for a screenshot. ???
-
Umm -- what am I looking at in AndyBig's most recent post then? I nearly mistook it for a screenshot. ???
Lol good point. Then the issue is solved? There was the issue of the inability to take screenshots with custom-rebuilt APK.
-
Linux file permissions management are made with KISS (Keep It Simple, Stupid) idea, so its preety simple. Android is based on modified Linux (Linux is the name of a system kernel doing very low level stuff - not the whole system, like some people think) and I dont have too much experience with any hacking on Android. BTW. I noticed my 924S (noted in about or somewhere here) has Linux kernel with word Ubuntu in a version text...
Those permissions are bits (flags) for three categories: "user" (owner of file), "group" (files and users can be in groups for additional permissions) and "others".
Mentioned bits can be changed to more human readable form:
ls -l /dev/tty0
crw--w---- 1 root tty 4, 0 02-20 12:30 /dev/tty0
chmod changes those bits, also with human readable R, W and X - last one is for execution permission (normal binary like exe in Windows or even shell scripts).
To make it readable for user, group and others (for everyone) its just:
chmod +r /some/file/path
To make it readable for users: u+r, for group: g+r, and for others: o+r.
There are also two special bits, but its not related here. But... sometimes suid bit can be usefull to execute file as root (admin) user instead of id of user in file.
So, when You cant read file, change this file permissions or use another user or add yourself in that group.
-
That's near perfect. But this still prevents taking screenshots, right? I wonder what's the deal with that.
Alas, yes. The problem is this. There are two points:
1. Applications from Rigol are signed with their key, which we do not have, so we have to sign the modified application with the key we generated for ourselves.
2. In applications from Rigol, the user android.uid.system is specified in the manifest, which means, as it seems to me, that this application will be launched with system rights.
If we leave this user in the manifest, then when we try to install our modified Android application, it will throw the error INSTALL_FAILED_SHARED_USER_INCOMPATIBLE. This means that Android has detected an existing key for this user, and it does not match our key with which we signed the application. Therefore, we have to remove this system user from the manifest, and the application starts with the usual permissions of a simple user. And as a result, when I try to take a screenshot, the following error appears in the system log:
SurfaceFlinger: Permission Denial: can't read framebuffer pid=6902, uid=10038That is, a simple user does not have enough permissions to read the framebuffer to take a screenshot. I don't know what to do with this yet. There is an idea to delete all Rigol applications so that there are no applications left in the system with this user, then re-sign them with our key and install them back. But I suspect this trick won't work :)
Umm -- what am I looking at in AndyBig's most recent post then? I nearly mistook it for a screenshot. ???
This is a screenshot from web control :)
P.S. Hmm, yeah. A quick search on the Internet led to the conclusion that the android.permission.READ_FRAME_BUFFER permission is only allowed for applications that are signed with the same key as the Android ROM. So, it seems there is no way to overcome this, unless you crack Rigol’s native key :)
-
And as a result, when I try to take a screenshot, the following error appears in the system log:
SurfaceFlinger: Permission Denial: can't read framebuffer pid=6902, uid=10038That is, a simple user does not have enough permissions to read the framebuffer to take a screenshot. I don't know what to do with this yet. There is an idea to delete all Rigol applications so that there are no applications left in the system with this user, then re-sign them with our key and install them back. But I suspect this trick won't work :)
Yeah so basically non-system apps have no direct access to framebuffer. There are two solutions:
a) run the recompiled apk as a system app. This should be possible (we have root, we can do everything), just need to figure out how;
b) instead of reading the framebuffer directly, run the following command: "screencap -p /data/UserData/custom-screenshot-NNN.png".
I've just verified that the second one works all right. I wonder how feasible it will be to substitute the native framebuffer capture code with a custom code doing exec() to run screencap on whatever the called might be: the "quick" button or the respective menu fuction. Or maybe it can be possible to run a daemon in background that would watch for "quick" button key press events and run screencap regardless of what the rigol app is doing.
Some additional details: https://stackoverflow.com/questions/12615240/how-to-run-android-system-app-without-root-permission
For the first one:
https://stackoverflow.com/questions/15205159/install-failed-shared-user-incompatible-while-using-shared-user-id
https://xdaforums.com/t/solved-install-failed-shared-user-incompatible.1219029/
Apparently it should be as easy as properly uninstalling the original app before installing the rebuilt one?
-
P.S. Hmm, yeah. A quick search on the Internet led to the conclusion that the android.permission.READ_FRAME_BUFFER permission is only allowed for applications that are signed with the same key as the Android ROM. So, it seems there is no way to overcome this, unless you crack Rigol’s native key :)
So Google destroyed Linux simplicity (with Android), more than I thought. Maybe there is possible to make frame buffer file (if its still Linux with "everything is a file") readable/writable for every user with chmod 666 or chmod +rw (both will do same thing).
-
PS. https://stackoverflow.com/questions/24917927/how-to-execute-a-chmod-in-android-api-8
Looks like there is chmod in Andoid.
Dont know how its with other models, but in mine 924S there is ssh on default port. So its possible to insert key into .ssh and log into ssh. After that, type chmod something [enter].
-
Apparently it should be as easy as properly uninstalling the original app before installing the rebuilt one?
I read through these links, and others too. It seems that this task is not trivial. Now I’ll try one quick method that I read about, without installing a custom recovery and without rebuilding the kernel :) But I don’t think it will work.
PS. https://stackoverflow.com/questions/24917927/how-to-execute-a-chmod-in-android-api-8
Looks like there is chmod in Andoid.
Dont know how its with other models, but in mine 924S there is ssh on default port. So its possible to insert key into .ssh and log into ssh. After that, type chmod something [enter].
There is chmod, there is chown, there are many other commands from Linux :)
Only chmod will not help here. We need to somehow convince the system that this application is signed with the correct key. Well, or that it is its own and has the right to execute privileged methods of the system API :)
-
So Google destroyed Linux simplicity (with Android), more than I thought.
Think: You really can't have apps capturing the screen on people's phones.
-
So Google destroyed Linux simplicity (with Android), more than I thought.
Think: You really can't have apps capturing the screen on people's phones.
User groups (as in original Linux) is good enough for this job. User root and group name fb (framebuffer in short). If app is not working with uid 0 (as root) and running user is not in group fb (gid of that group), then it cant read framebuffer or execute anything which can do it - in exception with suid bit, but in that case, this process manages what it can be done and what not so much - great example is sudo - with (or without - if configured in this way) giving/asking current user password it read configuration and it checks if You can do this or not.
With that in mind, I dont see any reason to make it more complicated in any way. Linux is not Windows. Google basically made Windows from Linux for no obvious reason. If something is working 100% correctly - dont change it.
Yet again, people speaks about Linux and permissions management in it, without knowing completely anything about it.
-
Only chmod will not help here. We need to somehow convince the system that this application is signed with the correct key. Well, or that it is its own and has the right to execute privileged methods of the system API :)
Maybe some non-developers and Windows users will not agree with me, but again I see Google is a crap company with very cheap developers. Why they didnt use something which was working good enough for years and in same time was simple? User groups as mentioned before. If root user (app running with uid 0) wants to give or take permission, then it will do it. Normal user can't, unless he become root in some way (password, key or suid).
Is there possible to install self-signed cert in Android?
Anyway, I have one more reason to try installing Linux instead crappy Android on this scope.
-
Maybe some non-developers and Windows users will not agree with me, but again I see Google is a crap company with very cheap developers. Why they didnt use something which was working good enough for years and in same time was simple? User groups as mentioned before. If root user (app running with uid 0) wants to give or take permission, then it will do it. Normal user can't, unless he become root in some way (password, key or suid).
Is there possible to install self-signed cert in Android?
Anyway, I have one more reason to try installing Linux instead crappy Android on this scope.
I’m not an Android developer, but offhand I can see the following reason: in addition to restricting access to resources, Android developers also decided to introduce restricting access to system API functions.
And I still defeated this scourge! :)))) I was able to persuade the system to consider the application trusted enough so that it could gain access to privileged system calls, including the framebuffer :) True, this is quite confusing, you will need to write a script that will perform all the actions to enter the installed application to trusted ones.
Here is a screenshot honestly taken on an oscilloscope, downloaded from it via FTP :)
-
Time to create a github repo with a toolchain/scripts, and a patchset to be applied to the original apk, for others to create their own custom apks!
-
Time to create a github repo with a toolchain/scripts, and a patchset to be applied to the original apk, for others to create their own custom apks!
IMHO scrips working directly on scope should be better.
Doing those scripts, we need to remember, not everybody will have everything original - including config files. Also it can be different firmware.
-
Is there possible to install self-signed cert in Android?
Anyway, I have one more reason to try installing Linux instead crappy Android on this scope.
Awesome! Do you have experience porting/running Android apps on Linux? I(for one) eagerly await news of your progress so my 'scope won't be so crappy. :-/O
We clearly need more help here on the Android side of things. Perhaps you and @Randy222 can team up and open source this baby!
-
Is there possible to install self-signed cert in Android?
Anyway, I have one more reason to try installing Linux instead crappy Android on this scope.
Awesome! Do you have experience porting/running Android apps on Linux? I(for one) eagerly await news of your progress so my 'scope won't be so crappy. :-/O
We clearly need more help here on the Android side of things. Perhaps you and @Randy222 can team up and open source this baby!
https://en.wikipedia.org/wiki/Anbox
Same thing like Wine, but for Android apps instead of Windows apps. No need for sarcasm here.
-
Time to create a github repo with a toolchain/scripts, and a patchset to be applied to the original apk, for others to create their own custom apks!
Yes, there is already a decent set of tools, and the operations are not very simple.
I wrote out a reminder for myself on updating the application so that it becomes a system one - it turned out to be 14 points that need to be completed in the oscilloscope shell. Here you definitely need to write a script that will do all this without errors and typos :)
Is there possible to install self-signed cert in Android?
I do not know this. I think it is possible if you try hard enough. But what will this give? :)
-
Is there possible to install self-signed cert in Android?
I do not know this. I think it is possible if you try hard enough. But what will this give? :)
Im currently using self signed and even expired cert to sign other (expired) certs. Thats how my private mail server is running for many years. Everyday in logs I can see (mostly) russian hack attempts without succeed.
-
Anyway, I have one more reason to try installing Linux instead crappy Android on this scope.
It seems to me that this will be a very difficult task. I think the FPGA is very closely coupled to the processor at a very low level. It is possible that the image of the traces is transmitted directly to the video subsystem.
But if you succeed, it will be great! :)
Im currently using self signed and even expired cert to sign other (expired) certs.
I think that you can do this in Android, but it will not help with system applications. Here it is necessary that both the system kernel and the application are signed with the same key. That is, to use a self-signed certificate, you need to disassemble the android image, re-sign its ROM with your key and put it back together. And then if you sign applications with this key, they will have access to all privileged API functions without any installation difficulties :)
Thats how my private mail server is running for many years. Everyday in logs I can see (mostly) russian hack attempts without succeed.
But why do they need your mail server? :)))
-
https://en.wikipedia.org/wiki/Anbox
Same thing like Wine, but for Android apps instead of Windows apps. No need for sarcasm here.
I'm aware of Anbox. I was asking if you can port the 'scope app to Linux so it runs natively vs VM. And BTW: --from the link you shared--
Anbox was deprecated on February 3, 2023 as it's no longer being actively maintained.
And BTW#2: I wasn't being sarcastic. If you're trying to make friends here, perhaps you could take a less abrasive tone with everyone.
-
But why do they need your mail server? :)))
Welcome in real IT world. They have more than one reason. One is as in most cases, free computing power with fast and reliable internet connection. Second one, my server is doing one "bad" things for many Russia servers - mostly government servers, and naturally they want to stop this. No luck for them for ~2 years.
I dont have anything to Russians - its just for those bad ones.
Bit offtopic here.
-
Anbox was deprecated on February 3, 2023 as it's no longer being actively maintained.
Dont know about others, but mine 924S is running on Android 7. Also this scope is not a phone - as far I know.
And BTW#2: I wasn't being sarcastic.
Sounded to me like sarcasm, especially with this red text color.
If you're trying to make friends here, perhaps you could take a less abrasive tone with everyone.
You sounded to me also abrasive. Maybe we should go back to topic and stop this stupid fight of who is more smart?
-
I remember seeing something about test keys in some android devices in about menu.
Can't check now, no Android phone and my scope is disassembled.
Take a look in android menu, settings, about, and maybe under software versions .
Also if they use AOSP maybe, worth a try with keys from AOSP version 7 if is Android 7 ?
Maybe I'm wrong, I have no knowledge on Android builds or apps.
-
I remember seeing something about test keys in some android devices in about menu.
Can't check now, no Android phone and my scope is disassembled.
Take a look in android menu, settings, about, and maybe under software versions .
Also if they use AOSP maybe, worth a try with keys from AOSP version 7 if is Android 7 ?
Maybe I'm wrong, I have no knowledge on Android builds or apps.
It's Android 7.1.2 in these.
The reference designs, BSP's and several SBC manufacturers chose it because it was a very stable OS & kernel, which is desirable for embedded applications.
-
next test will be to download the LA data to PC to see if the dso is not lying. maybe tomorrow since i need to learn how to do it in SW... so far to probe LA offline on screen, we dont need the missing DDR3L RAM fwiw...
i tried sending command to dso to set digital channel as source (:WAV:SOUR D11 for example), and dso reported cmd error. so i still not success downloading digital data to PC. and GUI becomes extra slow (1-2fps) when LA GUI is activated, try and error using USB connectivity to PC last night causing the dso to hang/unresponsive or extra delay and lag several times that i have to switch it off and restart. today i tried downloading to USB stick, i managed to get screen and 1MPts memory data in CSV format. earlier i tried 25MPts but i got empty CSV files, so this is a bit inconsistent and confusing, see attached screenshots and zipped csv data.
maybe next time i video and snapshots probing more realistic stuffs on all 16 channels. fwiw cheers.
probing its own internal organ below. there some nasty jitter, not sure SW or HW bug, probably my diy probe's front end divider with extra ringing or overshoot too, not sure. but FW is reading all 16 channels on screen yay!
https://www.youtube.com/watch?v=wHVnUdzOl8E (https://www.youtube.com/watch?v=wHVnUdzOl8E)
-
next test will be to download the LA data to PC to see if the dso is not lying. maybe tomorrow since i need to learn how to do it in SW... so far to probe LA offline on screen, we dont need the missing DDR3L RAM fwiw...
i tried sending command to dso to set digital channel as source (:WAV:SOUR D11 for example), and dso reported cmd error. so i still not success downloading digital data to PC. and GUI becomes extra slow (1-2fps) when LA GUI is activated, try and error using USB connectivity to PC last night causing the dso to hang/unresponsive or extra delay and lag several times that i have to switch it off and restart. today i tried downloading to USB stick, i managed to get screen and 1MPts memory data in CSV format. earlier i tried 25MPts but i got empty CSV files, so this is a bit inconsistent and confusing, see attached screenshots and zipped csv data.
maybe next time i video and snapshots probing more realistic stuffs on all 16 channels. fwiw cheers.
probing its own internal organ below. there some nasty jitter, not sure SW or HW bug, probably my diy probe's front end divider with extra ringing or overshoot too, not sure. but FW is reading all 16 channels on screen yay!
https://www.youtube.com/watch?v=wHVnUdzOl8E (https://www.youtube.com/watch?v=wHVnUdzOl8E)
You are a genius!!!
-
I try to solve rest of sdcard dump, what remain after extracting known 6 partition.
Maybe will be usefull somehow
Based on my dump:
start - end address
id block preloader 0x8000 - 0x37FFFF
preloader 0x8800 - 0x37FFFF
vendor storage 0x380000 - 0x3BFFFF DVKR
reserved space 0x3C0000 - 0x3EFFFF
reserved1 0x3F0000 - 0x3F7FFF SYSD DRMK
U-Boot Env 0x3F8000 - 0x3FFFFF boot parameters
reserved2 0x400000 - 0x7FFFFF PARM
loader 0x800000 - 0x8FFFFF LOADER all 4 are identical
loader 0x900000 - 0x9FFFFF LOADER
loader 0xA00000 - 0xAFFFFF LOADER
loader 0xB00000 - 0xBFFFFF LOADER
loader3 0xC00000 - 0xDFFFFF BL31 both BL31 are identical
BL31 0xC00800 ...
BL31 0xC34000 ...
BL31 0xC36000 ...
BL32 0xC3D000 - 0xC9AFFF
loader3 0xE00000 - 0xFFFFFF BL31
BL31 0xE00800 ...
BL31 0xE34000 ...
BL31 0xE36000 ...
BL32 0xE3D000 - 0xE9AFFF
Rockchip resource image 0x1400000 - 3 entries
0x1400800 - 0x1413E75 rk-kernel.dtb
0x1414000 - 0x1437208 Rigol logo
0x1437400 - 0x147E476 Rigol logo
KRNL 0x2400000
KRNL 0x3C00000
KRNL 0x5C00000
-
You are a genius!!!
do not exagerate when making compliment ;D to be frank, i dont believe in genius, only hard work behind it... i'm no better than most of people here.. i worked bit by bit, with many mistakes... not in one night.. btw i managed to save the 25MPts digital + CH1 analog data into CSV file, the 700MB+ size deluded me, when checking with hex editor... it got CH1 data, but digital data is still empty, just header and commas... so no success yet... cheers.
edit: tried saving 10Mpts, same think empty digital data, but CH1 analog data present throughout the record, so this is not USB corruption issue, maybe dso needs 2x DDR3L RAM, or FW bug..
edit 2: made another try.. saving CSV 1Mpts, 10Mpts, 25Mpts consecutively after hit single trigger. 1Mpts (46MB) success! 10Mpts (312MB) failed! 25Mpts (1GB) success! hmmm ??? inconsistent. it seems i managed to get non-empty digital data at 25Mpts yay!. maybe this inconsistency is SW bug.
-
I try to solve rest of sdcard dump, what remain after extracting known 6 partition.
Maybe will be usefull somehow
Based on my dump:
start - end address
id block preloader 0x8000 - 0x37FFFF
preloader 0x8800 - 0x37FFFF
vendor storage 0x380000 - 0x3BFFFF DVKR
reserved space 0x3C0000 - 0x3EFFFF
reserved1 0x3F0000 - 0x3F7FFF SYSD DRMK
U-Boot Env 0x3F8000 - 0x3FFFFF boot parameters
reserved2 0x400000 - 0x7FFFFF PARM
loader 0x800000 - 0x8FFFFF LOADER all 4 are identical
loader 0x900000 - 0x9FFFFF LOADER
loader 0xA00000 - 0xAFFFFF LOADER
loader 0xB00000 - 0xBFFFFF LOADER
loader3 0xC00000 - 0xDFFFFF BL31 both BL31 are identical
BL31 0xC00800 ...
BL31 0xC34000 ...
BL31 0xC36000 ...
BL32 0xC3D000 - 0xC9AFFF
loader3 0xE00000 - 0xFFFFFF BL31
BL31 0xE00800 ...
BL31 0xE34000 ...
BL31 0xE36000 ...
BL32 0xE3D000 - 0xE9AFFF
Rockchip resource image 0x1400000 - 3 entries
0x1400800 - 0x1413E75 rk-kernel.dtb
0x1414000 - 0x1437208 Rigol logo
0x1437400 - 0x147E476 Rigol logo
KRNL 0x2400000
KRNL 0x3C00000
KRNL 0x5C00000
https://www.eevblog.com/forum/blog/eevblog-1563-new-$389-12bit-rigol-dho800-scope-teardown/msg5046301/#msg5046301 (https://www.eevblog.com/forum/blog/eevblog-1563-new-$389-12bit-rigol-dho800-scope-teardown/msg5046301/#msg5046301)
I think there is no partition table. Just a bootloader and filesystem starting at some point (once I did a disk in PC in same way, but without any bootloader - naked FS without bootsector - even Linux automount probably will not detect this, unless its a usb stick or sd card). Still I didnt look at mine, but for 99% I will do it today.
-
I think there is no partition table. Just a bootloader and filesystem starting at some point (once I did a disk in PC in same way, but without any bootloader - naked FS without bootsector - even Linux automount probably will not detect this, unless its a usb stick or sd card). Still I didnt look at mine, but for 99% I will do it today.
There might be no partition table as such -- the standard linux tools don't detect it -- but there are partitions that can be mounted and explored.
Try to use this tool on the image:
$ apt show testdisk
Package: testdisk
Version: 7.1-5+nmu1
Priority: optional
Section: admin
It will find the partitions (except root, for some reason) and restore the GPT record for them. And it also finds them very quickly, it's not doing a full scan, so there should be some kind of partition table that it uses. Maybe a backup copy of GPT?
-
but there are partitions that can be mounted and explored.
File system, not a partition.
It will find the partitions (except root, for some reason) and restore the GPT record for them. And it also finds them very quickly, it's not doing a full scan, so there should be some kind of partition table that it uses. Maybe a backup copy of GPT?
Why You need GPT for this? Anyway, If You have full FS deep into some data (in SD card and not in the beginning), You can extract this part to separate file and in Linux You cant mount any file as a file system - there is no need to be block file. In older systems You need to add loop option - in newest its added automatically.
mount /some/file /some/directory -o loop
Or if it cant detect file system type, You can type it:
mount -t fstype /some/file /some/directory -o loop
-
File system, not a partition.
There are several partitions with file systems (ext4) on the SD card all right.
Anyway, If You have full FS deep into some data (in SD card and not in the beginning), You can extract this part to separate file and in Linux You cant mount any file as a file system - there is no need to be block file.
Of course. The problem is that you can only do it if you know the start offset of the file system in the image file (or on the block device). And you don't know it unless you have a partition table (such as GPT) or a tool that can scan the image and detect file systems by looking for known headers.
Standard linux tools such as losetup or fdisk don't see any partitions on the sd card. Testdisk does.
-
And you don't know it unless you have a partition table (such as GPT) or a tool that can scan the image and detect file systems by looking for known headers.
If there is no partition table in this SD card, why You mentioning it? You want to add it or something? To play around, its good enough to extract and mount it.
Standard linux tools such as losetup or fdisk don't see any partitions on the sd card. Testdisk does.
That is what I told in this thread couple days ago.
Anyway, I was expecting ext4, because its fast and reliable filesystem. Not a fat or ntfs rubbish.
-
MTD partition layout is passed to kernel from Uboot. It then appears in the boot log. Is this guys what you are debating?
[ 1.402697] uboot: 0x000400000 -- 0x000800000 (4 MB)
[ 1.402715] trust: 0x000800000 -- 0x000c00000 (4 MB)
[ 1.402724] misc: 0x000c00000 -- 0x001000000 (4 MB)
[ 1.402733] resource: 0x001000000 -- 0x002000000 (16 MB)
[ 1.402746] kernel: 0x002000000 -- 0x003800000 (24 MB)
[ 1.402755] boot: 0x003800000 -- 0x005800000 (32 MB)
[ 1.402762] recovery: 0x005800000 -- 0x009800000 (64 MB)
[ 1.402770] backup: 0x009800000 -- 0x010800000 (112 MB)
[ 1.402778] cache: 0x010800000 -- 0x018800000 (128 MB)
[ 1.402786] system: 0x018800000 -- 0x098800000 (2048 MB)
[ 1.402793] metadata: 0x098800000 -- 0x099800000 (16 MB)
[ 1.402801] verity_mode: 0x099800000 -- 0x099808000 (0 MB)
[ 1.402809] baseparamer: 0x099808000 -- 0x099c08000 (4 MB)
[ 1.402816] frp: 0x099c08000 -- 0x099c88000 (0 MB)
[ 1.402823] rigol: 0x099c88000 -- 0x0b9088000 (500 MB)
[ 1.402831] userdata: 0x0c0000000 -- 0x762600000 (27174 MB)
-
How to modify the oscilloscope application.
This application is a standard application for Android, so all the methods of working with it are no different from the methods of working with any other application for Android. I will describe the process under Windows, but under Linux everything will be almost the same, all tools are available for Linux.
What programs will you need:
apktool - https://github.com/iBotPeaches/Apktool (https://github.com/iBotPeaches/Apktool) - a utility for unpacking and packing an .apk application. It unpacks the application into the individual files that make up the application. Requires Java (JRE) installed on the system.
zipalign - a utility included in Android build-tools (https://developer.android.com/tools (https://developer.android.com/tools)). Aligns the contents of the .apk after it has been packaged. I didn’t find how to download build-tools separately, so I downloaded and installed the full Android Studio, which also includes build-tools.
keytool - a utility from the Java SDK (https://www.oracle.com/cis/java/technologies/downloads/ (https://www.oracle.com/cis/java/technologies/downloads/)) for creating a key storage with which you will sign the application.
jarsigner a utility from the Java SDK (https://www.oracle.com/cis/java/technologies/downloads/ (https://www.oracle.com/cis/java/technologies/downloads/)) for signing applications with keys from the key store, which was created by the keytool utility.
adb a utility included in the Android platform-tools (https://developer.android.com/tools/releases/platform-tools (https://developer.android.com/tools/releases/platform-tools)) for working with Android devices connected via a local network or USB.
jadx - https://github.com/skylot/jadx (https://github.com/skylot/jadx) - a utility for decompiling an application into Java source codes. Select and download the "jadx-gui with bundled JRE" option.
apktool and jadx are downloaded from github, they do not need installation.
If you download and install Android Studio (https://developer.android.com/studio (https://developer.android.com/studio)), then all other utilities (except apktool and jadx) will already be included. After downloading and installing, make sure that the path to Java is specified in the environment variables - try typing in the command line
javaand press Enter. You should see java help with a description of the parameters and commands.
In the same way, check the availability of keytool and jarsigner.
So, everything has been downloaded and installed, you can start unpacking the application.
Create a separate directory for working with the application. For example, the path would be the "SparrowWork" directory. Copy the application file (Sparrow.apk), apktool (apktool_2.9.3.jar in the current version), and zipalign (zipalign.exe from the Android SDK, it should be located in the Android SDK installation directory, in one of the subdirectories) to this directory ). It is better to rename the original application file, for example to Sparrow_orig.apk.
Go to this directory and open a command prompt in it.
First you need to create a key store, with which you will then sign the application after assembly. This is done only once before the first assembly; there is no need to repeat this in the future. The key store is created with the command:
keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000Here “my-release-key” is the name of the key store being created; you can substitute any other name, which you will then put in the signing command. "alias_name" is the name of the key, you can also replace it with any other, which you can then substitute in the signing command.
After launching, the program will ask you for various data - name, organization, city, etc. - you can write whatever you want. In addition, it will ask for a password for the vault, you will need to come up with it and remember it, it will be needed for the signing command.
Now extract the application into a separate directory using the command:
java -jar apktool_2.9.3.jar d Sparrow_orig.apk -o Sparrow_unpack
You should have a subdirectory "Sparrow_unpack" in your directory, which will contain all the contents of the application in its original form. In principle, here you can already start editing application files. For example, the "Sparrow_unpack/res" directory will contain all application resources - images, .xml files with texts, parameters, screen layout, etc. In the directory "Sparrow_unpack/smali" and "Sparrow_unpack/smali_classes2" there will be .smali files with source codes in the DALVIK language - this is something like an assembler for Java.
If you want to get source codes in Java, then run the downloaded and unpacked jadx utility (jadx-gui-1.4.7.exe for the current version). In it, open the application file Sparrow_orig.apk and wait until the analysis and decompilation is completed. Now you can view all source codes directly in this program - it has a fairly convenient source viewer. You can save the result as a project - File -> Save as gradle project in a separate subdirectory, then all source java files will be available at any time in this directory, you can open them in your favorite editor.
Warning: You will not be able to compile the application back from the decompiled java files, they are only intended to help you understand the contents of the .smali files. Each .java file will correspond to a .smali file with the same name and in the same subdirectory.
All changes are made to files in the directory into which the application was unpacked using the apktool utility. In the example, this is the Sparrow_unpack directory. The application will be built from this directory after all changes.
Okay, you've changed what you wanted, now you need to put the application back together.
The assembly is done with the command:
java -jar apktool_2.9.3.jar b -o Sparrow_unalign.apk Sparrow_unpakHere Sparrow_unalign.apk is the name of the application that will be created, Sparrow_unpack is the directory from which the files for the build are taken.
If no errors are found after the changes, the Sparrow_unalign.apk file will appear in the current directory. Now you need to align the contents of the application with the command:
zipalign.exe 4 Sparrow_unalign.apk Sparrow.apkAs a result, a Sparrow.apk file will be created, with all its contents aligned and almost ready for installation. All that remains is to sign it with the command:
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore -storepass 123456 Sparrow.apk alias_nameHere you specify "my-release-key" - the name of the key store you created, "123456" - the password and "alias_name" - the password and key name that you specified when creating the key store.
That's it, now the Sparrow.apk application is completely ready for installation.
About the installation. From the factory, the oscilloscope application is installed as a system application, so simply replacing it with your own modified one will not work. You must first remove the original version. Don't worry - you can always install the original application back. You made a copy of it just in case, didn’t you? :)
If on your system the path to the directory with the adb utility is included in the environment variables and the adb command can be executed from anywhere, then you can continue working in the current directory. Otherwise, copy the resulting Sparrow.apk application to the directory with adb and launch the command line there.
On the command line, type the command:
adb connect 192.168.1.171:55555Where 192.168.1.171 replace with the IP address of your oscilloscope. The oscilloscope must be turned on and accessible via the local network.
After that, type the command:
adb uninstall com.rigol.scopeAfter a second or two, the application should disappear from the oscilloscope screen and the message “Success” will appear in the terminal.
Install your application:
adb install -g -r Sparrow.apkThe process takes quite a long time, almost a minute, so don't worry about everything getting stuck. When finished, a “Success” message should appear and within a few seconds the oscilloscope application should automatically launch.
If your modified application is already installed on the oscilloscope and you reinstall it after the next modification, then there is no need for a separate command to remove the old application. You can immediately issue the installation command:
adb install -g -r Sparrow.apk
That's it, your modified application is installed :)
There is only one point: your application cannot be a system one, because it is signed with the wrong key. One of the noticed negative consequences of this is the inability to take screenshots directly on the oscilloscope. But they can be done via web control. It is possible to make a modified application a system one, but there will be a separate post about this later.
P.S. I'm not a real Android app modder, and I've described here what I've learned and tried over the past few days, so there may be inaccuracies in my description. Maybe someone more experienced will correct me at some points :)
-
From ADB Linux manual:
• -l: Forward lock application.
• -r: Replace existing application.
• -t: Allow test packages.
• -s: Install application on sdcard.
• -d: Allow version code downgrade (debuggable packages only).
• -p: Partial application install.
• -g: Grant all runtime permissions.
-
From ADB Linux manual:
• -l: Forward lock application.
• -r: Replace existing application.
• -t: Allow test packages.
• -s: Install application on sdcard.
• -d: Allow version code downgrade (debuggable packages only).
• -p: Partial application install.
• -g: Grant all runtime permissions.
In Windows adb the same keys :)
-
Tested on mine 924S.
List packages:
adb shell pm list packages
Acquire apk directory of package:
adb shell pm path com.rigol.scope
Pull apk into local directory:
adb pull /data/app/com.rigol.scope-1/base.apk
If somebody will need this for some strange reason, file size is 36840716 bytes (36.8 MB, 35.13 MiB).
-
Tested on mine 924S.
List packages:
adb shell pm list packages
Acquire apk directory of package:
adb shell pm path com.rigol.scope
Pull apk into local directory:
adb pull /data/app/com.rigol.scope-1/base.apk
If somebody will need this for some strange reason, file size is 36840716 bytes (36.8 MB, 35.13 MiB).
The .GEL update file contains, among other things, the original Sparrow.apk, which is installed in /data/app/com.rigol.scope-1/ :)
-
In case anyone is wondering about the DHO8/900 file structure, file system partitions, and SDCard speed/upgrades, here is a good starting point for your research:
Partition(s) information with offsets(from Sept/23)
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008)
Partition cloning including repairing partition table.(SDCard corrupt error)
--He also confirmed there was no apparent speed benefit to the upgrade to larger/faster card.
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5240010/?topicseen#msg5240010 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5240010/?topicseen#msg5240010)
Step by step - Cloning to new/larger card by the great @Serg65536
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5134359/?topicseen#msg5134359 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5134359/?topicseen#msg5134359)
Cheers!
-
In Windows adb the same keys :)
But his were better, because they're from Linux. :-DD
Stop trolling again.
I wrote instructions. I wrote clearly Linux manual. Im not using Windows and I cant check if everything is the same on Windows version. So You think Im worse because I dont have Windows or what?
Again, please stop trolling.
-
Partition(s) information with offsets(from Sept/23)
Every scope can have different offsets. Especially after upgrade.
-
Every scope can have different offsets. Especially after upgrade.
After the update - no, because only user applications are updated, the update does not enter the system. But from the factory - it is possible that in newer models Rigol may change something in the Android system. But in my opinion this is very unlikely.
-
Interesting "tails" are hidden in the application. It turns out that not all existing settings items are displayed, some of them are simply disabled, but they are there. True, they don’t change anything, there are probably no handlers for them, but it’s still interesting :)
-
After the update - no, because only user applications are updated, the update does not enter the system. But from the factory - it is possible that in newer models Rigol may change something in the Android system. But in my opinion this is very unlikely.
Process with uid (or with setuid) can do everything. Im not Android specialist, but thats the way on any Linux-based system.
Interesting "tails" are hidden in the application. It turns out that not all existing settings items are displayed, some of them are simply disabled, but they are there. True, they don’t change anything, there are probably no handlers for them, but it’s still interesting :)
With working WiFi I see correct date (NTP most likely), but time is wrong. Maybe its Chinese timezone :)
-
With working WiFi I see correct date (NTP most likely), but time is wrong. Maybe its Chinese timezone :)
Yes, the oscilloscope launch script start_rigol_app.sh sets the Asia/Shanghai time zone:
setprop persist.sys.timezone Asia/ShanghaiI changed it to my time zone and the time is displayed correctly.
-
Interesting "tails" are hidden in the application. It turns out that not all existing settings items are displayed, some of them are simply disabled, but they are there. True, they don’t change anything, there are probably no handlers for them, but it’s still interesting :)
I would've loved to be "a fly on the wall" during that meeting.. I'm sure a Dev made a comment about how hard it was to implement something, and the PM said "Well, just cut it for now, we'll put it back in some day" --Don't miss those meetings at all!
BTW, nice job on the scope app hacking guide, Andy. Herculean effort! :clap:
-
There is only one point: your application cannot be a system one, because it is signed with the wrong key.
Apparently there is a way. There are publicly available app signing keys that can be used for testing/developing apps to be installed as system apps. Check this: https://stackoverflow.com/questions/37586255/signing-my-android-application-as-system-app
If I understand it correctly, then signing the apk with one of those keys, instead of a self-signed key, should do the trick.
There are downsides (explained on stackoverflow), but they are hardly applicable in our case.
-
Apparently there is a way. There are publicly available app signing keys that can be used for testing/developing apps to be installed as system apps. Check this: https://stackoverflow.com/questions/37586255/signing-my-android-application-as-system-app
If I understand it correctly, then signing the apk with one of those keys, instead of a self-signed key, should do the trick.
There are downsides (explained on stackoverflow), but they are hardly applicable in our case.
Damn, at first glance I was even glad that such an opportunity existed :) However, a more careful reading of the links clarified the situation - these mean the keys that are used to assemble the system by the manufacturer. I very much doubt that Rigol signed his Android build with a test key, which can be taken from the AOSP source code.
I looked at the certificate with which the Sparrow application was signed, and it is slightly different from the test ones.
-
In Windows adb the same keys :)
But his were better, because they're from Linux. :-DD
Stop trolling again.
I wrote instructions. I wrote clearly Linux manual. Im not using Windows and I cant check if everything is the same on Windows version. So You think Im worse because I dont have Windows or what?
Again, please stop trolling.
Calm down!
-
Since we have root access on scope could be used scope to sign apk by itself?
I see an apk-signer on google play store, but there may be others too.
-
Since we have root access on scope could be used scope to sign apk by itself?
I see an apk-signer on google play store, but there may be others too.
Of course we can, it's not difficult at all. The problem is that we do not know the correct key that needs to be signed so that the application becomes trusted and can run under the system account and have privileged access to system resources. But there is a workaround - since we have root access, we can manually move the installed application to /system/priv-app after installation, which makes the application trusted and gives privileged access.
-
Damn, at first glance I was even glad that such an opportunity existed :) However, a more careful reading of the links clarified the situation - these mean the keys that are used to assemble the system by the manufacturer. I very much doubt that Rigol signed his Android build with a test key, which can be taken from the AOSP source code.
I looked at the certificate with which the Sparrow application was signed, and it is slightly different from the test ones.
It was my impression that the test keys were supported by stock android, universally. Their very purpose is test and development -- so that you can install and test the app you develop as system app on any system without creating your own build of the OS. Of course you can't publish the app signed with them on google play etc.
I may be wrong. Really need an android professional in this topic. I'm sure they are on the forum!
-
Regarding raising rights for a modified application.
What is the essence of the problems? Initially, from the factory, the oscilloscope application - Sparrow.app - was signed by Rigol with the same key with which he signed the Android kernel when assembling it. This allows the application to run under the sysytem account and gives it privileged access to system resources and system API calls. For example, some API calls require such privileged access during the screenshot process. But we don’t know this key, so we have no way to sign the application with it after modification. Because of this, our application runs under the account of an ordinary user and the system denies access to some API calls when taking a screenshot. Our modified application can't take screenshots, yeah. Perhaps there are similar restrictions in some other areas, but I only noticed this.
But I found a description of a workaround online, available if you have root access to the system, and we have it :) The point of this workaround is to place the application in /system/priv-app. Applications located in this directory are automatically considered trusted and receive privileged access, almost the same as applications running under the system account (and maybe completely the same, I don’t fully understand this).
To do this, we first need to install the application in the usual way, so that during installation a .odex file is created for our application in the /data/app directory (in its own subdirectory, separate for each application, in our case it will be /data/app/com.rigol.scope-1).
Further:
- Stop the work of the com.rigol.launcher application first, and then com.rigol.scope.
- In the /system/priv-app directory we create a directory with the file name of our application, in our case it is /system/priv-app/Sparrow.
- Copy the lib and oat subdirectories with all contents into it from the /data/app/com.rigol.scope-1 directory, recursively including nested subdirectories.
- Copy the file of our modified application - Sparrow.apk - into the same directory (it must be written in advance from the PC somewhere accessible on the oscilloscope, for example in /rigol/data).
- Assign attributes 755 (rwxr-xr-x) to the /system/priv-app/Sparrow directory and all its contents at full depth recursively. I'm actually not sure if this step is necessary, but I was having some kind of glitch until I assigned these attributes. Maybe it was a coincidence.
- Completely delete the /data/app/com.rigol.scope-1 directory with all its contents.
- Reboot the oscilloscope.
That's it, now our application, although it still runs under the account of a regular user, becomes trusted and has privileged access to system APIs. And it can take screenshots again :)
When updating our application after the next modification, we will need to repeat all this. So I'm thinking of writing a script with all these actions and putting it in /rigol/data. During the next update after the standard installation process, simply drop a new application file into /rigol/data and run this script there, which will do everything necessary. But while we haven’t gotten around to it yet, we need to check a couple more points and test such an installation using a script.
-
It was my impression that the test keys were supported by stock android, universally. Their very purpose is test and development -- so that you can install and test the app you develop as system app on any system without creating your own build of the OS. Of course you can't publish the app signed with them on google play etc.
No, the point of test keys is that they sign the kernel and application assembly at the testing stage. These are just known working keys as an example from Google. After everything has been debugged and tested, before release the kernel and all applications are re-signed with their own vendor key. Google strongly recommends doing this, and I am sure that Rigol did just that.
I even looked at the certificate (open, of course) that signed the original application - the certificate data, although very slightly, differs from those that come with AOSP. Rigol changed the email address in the certificate, leaving everything else as it was in test keys :)
Verifies
Verified using v1 scheme (JAR signing): false
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v3.1 scheme (APK Signature Scheme v3.1): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=hexiaohua@rigol.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
Signer #1 certificate SHA-256 digest: f48e7189aac174df7fd19acf58b6d15832760fcf25ac0a6d4bcd5fc1974d4c03
Signer #1 certificate SHA-1 digest: df345a93532e902ff6291668c20ad69da3b72ff6
Signer #1 certificate MD5 digest: 40490c2e0b280e29ba5e46205272e3dc
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: ca871f06fa7ffaa5beda2179a2278a0474d98e6b5e11d9aab2dfb590d8e57292
Signer #1 public key SHA-1 digest: 90ff0ddf5a0881ea080558b3b585dd0352342d8e
Signer #1 public key MD5 digest: 78d923a60c0963a38de1ee05b4556031
-----BEGIN CERTIFICATE-----
MIIECzCCAvOgAwIBAgIUINzTdl44KGbN5zrMwq1QEIADPRMwDQYJKoZIhvcNAQEF
BQAwgZQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQH
DA1Nb3VudGFpbiBWaWV3MRAwDgYDVQQKDAdBbmRyb2lkMRAwDgYDVQQLDAdBbmRy
b2lkMRAwDgYDVQQDDAdBbmRyb2lkMSIwIAYJKoZIhvcNAQkBFhNoZXhpYW9odWFA
cmlnb2wuY29tMB4XDTIwMDcxMDAzNDg1OVoXDTQ3MTEyNjAzNDg1OVowgZQxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFp
biBWaWV3MRAwDgYDVQQKDAdBbmRyb2lkMRAwDgYDVQQLDAdBbmRyb2lkMRAwDgYD
VQQDDAdBbmRyb2lkMSIwIAYJKoZIhvcNAQkBFhNoZXhpYW9odWFAcmlnb2wuY29t
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtmIPvmnFTAd95RNbqCLS
iOKrilEABcW8rtBCu70ofoOpOWLX5R2NBPWtYtOq+y4EF/dJddUVxOeOdTBngW8J
GfQiU7rqxxzWrskXh437KZYmcnAJxrEQkM7lBifPIYhihlmGCRVMM1eBZRdaRHjA
bSsM7flBMPhM8tpEX3g7kIoKa0NFrb+Z4206WrWX+0tIsvo8yA92pyqcwh4p2Ayx
cUnNWRnQdRU5iunuQmR5IS1uvryVyxYVX4T+WK5bQsupeXuwnTuCHSkJP2WMc5lE
6FZ7B1RcS7Lk+KQQ67S7TaqKp/iMgKM1l99Q74KaYoYvAhoNO6S7PAvZs/4DWnRu
5QIDAQABo1MwUTAdBgNVHQ4EFgQUyFB6a1gMxXBZ8LVszL0IQhTz5KkwHwYDVR0j
BBgwFoAUyFB6a1gMxXBZ8LVszL0IQhTz5KkwDwYDVR0TAQH/BAUwAwEB/zANBgkq
hkiG9w0BAQUFAAOCAQEAovdgpHN5gi9BMTNspmart0EH8fG4aqNWGZUxEM/dsR9K
+aP7rA3MyKwzjxNzaH8tg9TOD6zaWAZIkNtPXCVkTp+9XEp7WE1fP0xcqZpJoxTI
bydPrvXvfk819xCivXttmsK0WgvBPfnM0V6ARMKpCTSzZsSLkEpBS8Z+3/2gWG07
q1fbiblpv1YxH+cEhA8gE2rbIWX/EleJxYFGFY6fUBi4ENHG3Wrbpgnmw9WWXuNs
NfbAlbwqA5blWu16rFpQUrkjqaF7FbChBjnvdGPOU+gcSmwAmH3M8bzxnfdGdW+2
kRz3p/JLF8ypivfkdUqYIW69cwuygcvlhbKaK31wtA==
-----END CERTIFICATE-----
And this is already enough for the key to become completely different :) I tried to sign the application with test keys, but as expected, it did not give anything.
Really need an android professional in this topic. I'm sure they are on the forum!
Agree! I would really like an experienced Android developer to join the discussion.
-
The matching pub key appears to be located in otacerts.zip on the filesystem.
I added my own pub key to that zip and was attempting to do an OTA install of edited APK, but when it boots in recovery I can't find any navigation keys to move the menu.
It's about impossible to reload the Sparrow apk using the android.uid.system shared user, the apk must be signed with a key that matches the pub key in the android.uid.system keystore. I cannot find a way to add a key to that keystore.
There is however some further hacking that can cause pm install to skip sig verify, but it's very convoluted and appears to need recovery mode, which I cannot navigate.
As a side note, I was curious to see what Rigol had done with Sparrow. My scope is v00.01.02.00.00, I removed Sparrow and took Sparrow from a 00.01.02.00.02 GEL file and installed that. Installs just fine, but the only change that I notices was the whole RKey.data stuff. Nothing else appears to have changed, the scope runs exactly as it did before. I ran the zelea2 util to regen keys on the existing 914 vendor.bin.
-
Damn, at first glance I was even glad that such an opportunity existed :) However, a more careful reading of the links clarified the situation - these mean the keys that are used to assemble the system by the manufacturer. I very much doubt that Rigol signed his Android build with a test key, which can be taken from the AOSP source code.
I looked at the certificate with which the Sparrow application was signed, and it is slightly different from the test ones.
It was my impression that the test keys were supported by stock android, universally. Their very purpose is test and development -- so that you can install and test the app you develop as system app on any system without creating your own build of the OS. Of course you can't publish the app signed with them on google play etc.
I may be wrong. Really need an android professional in this topic. I'm sure they are on the forum!
android.uid.system has a keystore. apps running in context of android.uid.system (uid 1000) need to be signed with a private key that matches a pub key inside that keystore. Unless Rigol gives you their private key used for signing, there is no way to do it. Their SDK signs Android, and the android.uid.system belongs to the compiled/signed Android OS.
https://android.stackexchange.com/questions/208523/how-androids-permissions-mapping-with-uids-gids-works
-
Since we have root access on scope could be used scope to sign apk by itself?
I see an apk-signer on google play store, but there may be others too.
Of course we can, it's not difficult at all. The problem is that we do not know the correct key that needs to be signed so that the application becomes trusted and can run under the system account and have privileged access to system resources. But there is a workaround - since we have root access, we can manually move the installed application to /system/priv-app after installation, which makes the application trusted and gives privileged access.
In the Android model, only apps that run under same shared context (uid) can share data between the apps.
That said, if you park an app in app-priv running in some other uid context, that app still can't share data with other apps.
Does Sparrow apk need to share data with other apps and vice-versa? Might not be.
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.
-
In the Android model, only apps that run under same shared context (uid) can share data between the apps.
That said, if you park an app in app-priv running in some other uid context, that app still can't share data with other apps.
Does Sparrow apk need to share data with other apps and vice-versa? Might not be.
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.
Android is based on Linux kernel and there are uid and gid. This second one is a id of a group. Anyway, I dont know how much its used, but it is.
-
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.
I looked at this file and found that it requires you to assign specific permissions to applications. For example:
<assign-permission name="android.permission.UPDATE_APP_OPS_STATS" uid="audioserver" />
<allow-in-power-save package="com.android.providers.downloads" />
I didn't find an example of how to put just the application name there.
-
As a side note, I was curious to see what Rigol had done with Sparrow. My scope is v00.01.00.00.00, I removed Sparrow and took Sparrow from a 00.01.02.00.02 GEL file and installed that. Installs just fine, but the only change that I notices was the whole RKey.data stuff. Nothing else appears to have changed, the scope runs exactly as it did before. I ran the zelea2 util to regen keys on the existing 914 vendor.bin.
Starting from version 00.01.02.00.00, the calibration process has been changed. Calibration data is recorded in a different format and is larger in size. And starting with this version, the problem of vertical channel shift when upgrading an oscilloscope from DHO800 to DHO900 has gone away.
-
As a side note, I was curious to see what Rigol had done with Sparrow. My scope is v00.01.00.00.00, I removed Sparrow and took Sparrow from a 00.01.02.00.02 GEL file and installed that. Installs just fine, but the only change that I notices was the whole RKey.data stuff. Nothing else appears to have changed, the scope runs exactly as it did before. I ran the zelea2 util to regen keys on the existing 914 vendor.bin.
Starting from version 00.01.02.00.00, the calibration process has been changed. Calibration data is recorded in a different format and is larger in size. And starting with this version, the problem of vertical channel shift when upgrading an oscilloscope from DHO800 to DHO900 has gone away.
Sorry, that was my mistake. My 804 came with 00.01.02.00.00
I fixed my post.
-
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.
I looked at this file and found that it requires you to assign specific permissions to applications. For example:
<assign-permission name="android.permission.UPDATE_APP_OPS_STATS" uid="audioserver" />
<allow-in-power-save package="com.android.providers.downloads" />
Scroll down near end of file, there's a system app whitelisted permission. Just add another line there for com.rigol.scope
I didn't find an example of how to put just the application name there.
-
In the Android model, only apps that run under same shared context (uid) can share data between the apps.
That said, if you park an app in app-priv running in some other uid context, that app still can't share data with other apps.
Does Sparrow apk need to share data with other apps and vice-versa? Might not be.
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.
Android is based on Linux kernel and there are uid and gid. This second one is a id of a group. Anyway, I dont know how much its used, but it is.
The only thing Android has in common with linux distros is the kernel source code. After that Android looks and runs very different than everything else.
Android uses 1000-9999 for priveleged UID, where as in all linux distros (RH, debian, slack, etc etc) they use the 1000-9999 for low priv UID.
-
Scroll down near end of file, there's a system app whitelisted permission. Just add another line there for com.rigol.scope
Oh yes, I found it.
<!-- These are the packages that are white-listed to be able to run as system user -->
<system-user-whitelisted-app package="com.android.settings" />
As far as I understand, it may allow the application to run under the system account even if the application is not signed with a system key. I'll have to try it, thanks :)
-
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
Unfortunately, it didn't help. First I just pasted <system-user-whitelisted-app package="com.rigol.scope" /> into /etc/permissions/platform.xml and rebooted the oscilloscope. But the application still launched under the account of a regular user, and the system denied him access to the API when he tried to take a screenshot. I then rebuilt the application adding the system userid and tried to install it, but the installation failed with INSTALL_FAILED_SHARED_USER_INCOMPATIBLE error, same as before.
This method doesn't work.
-
I found how to remove an LA I don’t need from the bottom panel and, after digging deeper into the code, I figured out how to enable the date and time display :)
-
I found how to remove an LA I don’t need from the bottom panel and, after digging deeper into the code, I figured out how to enable the date and time display :)
:-+
Any chance you can get the info boxes for CH1..4 to display the probe divider setting? Only possible if the information is available to the display routine, I guess.
Edit: I hope you are keeping good records of all the changes you make. For a future new firmware, I assume you have to manually re-do them all over, right?
-
But the application still launched under the account of a regular user
Even if You change executable uid? Have You tried to make "ugly" move with uid 0?
-
FWIW, com.rigol.scope runs under uid 1000, whereas the processes run by root run under uid 0.
-
FWIW, com.rigol.scope runs under uid 1000, whereas the processes run by root run under uid 0.
Android is the red-head linux.
https://android.stackexchange.com/questions/208523/how-androids-permissions-mapping-with-uids-gids-works
-
Any chance you can get the info boxes for CH1..4 to display the probe divider setting? Only possible if the information is available to the display routine, I guess.
At the moment, I don’t see such a possibility yet :( Although I would like to have it myself.
Edit: I hope you are keeping good records of all the changes you make. For a future new firmware, I assume you have to manually re-do them all over, right?
Yes, that’s right, for the new firmware version you will have to make all the changes again. Although it’s not necessary to do everything manually :) I try to mark all my changes in the source code with a comment so that later it’s easy to find them all :)
Even if You change executable uid? Have You tried to make "ugly" move with uid 0?
If you tell me how to do this, I'll try :)
-
One very simple command to copy raw binary data from a serial block device - including SD cards:
cp /dev/sdb /home/userHomeDirectory/rawBinaryImageOfFancySDcardFromScope.fancyLongFileExtension
To be less fancy, I can use any graphical file manager in Linux to make exactly same thing.
Does using the cp command on a block device create a file that you can image back to a new block device, and it will boot?
-
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
Unfortunately, it didn't help. First I just pasted <system-user-whitelisted-app package="com.rigol.scope" /> into /etc/permissions/platform.xml and rebooted the oscilloscope. But the application still launched under the account of a regular user, and the system denied him access to the API when he tried to take a screenshot. I then rebuilt the application adding the system userid and tried to install it, but the installation failed with INSTALL_FAILED_SHARED_USER_INCOMPATIBLE error, same as before.
This method doesn't work.
So, dig some more, look at "ro.control_privapp_permissions=log", I think that's in build.prop see --> https://source.android.com/docs/core/permissions/perms-allowlist
Then see if that log spits up a perms issue, which you can likely fix in an xml file.
-
Even if You change executable uid? Have You tried to make "ugly" move with uid 0?
If you tell me how to do this, I'll try :)
I found previously at some forum about sudo and su in Android, but I dont see it in my bookmarks and history. Too much using incognito browser for almost everything...
However, when I googled for phrase "android sudo", I found this:
https://www.youtube.com/watch?v=xBt6H-bg-G4 (https://www.youtube.com/watch?v=xBt6H-bg-G4)
BTW. Currently Im doing hacking with completly different approach - more complicated at the beginning but will be easier later. I managed to run other U-boot (Grub doesnt work unless loaded by U-boot) and couple different Linux distros - somehow its not stable - not at all. By now, it works only on HDMI and internal LCD is blank (no backlight). Now I have idea to make dual-boot with original U-boot and use original kernel from this Android (never tried this before) - I will try it later.
-
Even if You change executable uid? Have You tried to make "ugly" move with uid 0?
If you tell me how to do this, I'll try :)
I found previously at some forum about sudo and su in Android, but I dont see it in my bookmarks and history. Too much using incognito browser for almost everything...
However, when I googled for phrase "android sudo", I found this:
https://www.youtube.com/watch?v=xBt6H-bg-G4 (https://www.youtube.com/watch?v=xBt6H-bg-G4)
BTW. Currently Im doing hacking with completly different approach - more complicated at the beginning but will be easier later. I managed to run other U-boot (Grub doesnt work unless loaded by U-boot) and couple different Linux distros - somehow its not stable - not at all. By now, it works only on HDMI and internal LCD is blank (no backlight). Now I have idea to make dual-boot with original U-boot and use original kernel from this Android (never tried this before) - I will try it later.
The util you found appears to be a way to "root" an otherwise locked Android, like most phones are.
We can SSH in as root.
We can also be root using adb.
We have root access to the DHO system, we can change anything on the system.
What we don't have is, a private key used to sign everything. Android however is flexible, we can still run stuff that is not signed by system key, but those apps become "restricted".
-
Since we have root and physical access to storage, we can modify everything. This includes modifying the mechanism that verifies the apk signature to decide whether to allow it to run as a system app. I wonder how feasible this would be. Food for thought.
-
Since we have root and physical access to storage, we can modify everything. This includes modifying the mechanism that verifies the apk signature to decide whether to allow it to run as a system app. I wonder how feasible this would be. Food for thought.
That's what I was wondering about. If applications get signed with a (non-available) private key, the signature must be checked (when starting the app) against a public key that is somewhere in the Android system. Is it known where that key resides, and can it be replaced?
-
However, when I googled for phrase "android sudo", I found this:
I know how to get root in the terminal. But I don’t know how to make the application run as root. Well, as far as I understand, the root and the system are different entities. Once the application is rooted, it will be able to access all resources, but it will still be limited in API calls.So, dig some more, look at "ro.control_privapp_permissions=log", I think that's in build.prop see --> https://source.android.com/docs/core/permissions/perms-allowlist (https://source.android.com/docs/core/permissions/perms-allowlist)
Then see if that log spits up a perms issue, which you can likely fix in an xml file.
Honestly, I don't see the point in digging that deep. All the same, the application will not work under the system account, and a method to bypass the restrictions has already been found :)
That's what I was wondering about. If applications get signed with a (non-available) private key, the signature must be checked (when starting the app) against a public key that is somewhere in the Android system. Is it known where that key resides, and can it be replaced?
Looks like this is the key - https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5357267/#msg5357267 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5357267/#msg5357267)
-
Since we have root and physical access to storage, we can modify everything. This includes modifying the mechanism that verifies the apk signature to decide whether to allow it to run as a system app. I wonder how feasible this would be. Food for thought.
That's what I was wondering about. If applications get signed with a (non-available) private key, the signature must be checked (when starting the app) against a public key that is somewhere in the Android system. Is it known where that key resides, and can it be replaced?
Apps need to be installed before they can run.
The permission "allow apps from unknown sources" means sig verify is skipped, but the apk still needs to be signed. Non trusted apps will be limited in various ways. Example, the only way for app to run with all the system priveleges is for the app to be signed with trusted system key. A self signed app cannot use shared user android.uid.system, Android won't allow that, etc.
Having the public key does not help at all. But I wonder if we can install another pub key into trusted area of Android, for android.uid.system? I suspect not.
The Rigol droid is kinda old, they are using many deprecated siwtches. See --> https://developer.android.com/guide/topics/manifest/manifest-element#uid
-
Apps need to be installed before they can run.
Ok, so replace "checked when starting the app" by "checked when installing the app". But the check is still performed by the local Android instance, by verifying the signature against some (public) key which exists locally, right? So the idea was to replace that key with one where we have both, the private key for signing and the public one for checking.
The permission "allow apps from unknown sources" means sig verify is skipped, but the apk still needs to be signed. Non trusted apps will be limited in various ways. Example, the only way for app to run with all the system priveleges is for the app to be signed with trusted system key. A self signed app cannot use shared user android.uid.system, Android won't allow that, etc.
That was not what I meant.
But I wonder if we can install another pub key into trusted area of Android, for android.uid.system?
That was what I meant! :)
-
However, when I googled for phrase "android sudo", I found this:
I know how to get root in the terminal. But I don’t know how to make the application run as root. Well, as far as I understand, the root and the system are different entities. Once the application is rooted, it will be able to access all resources, but it will still be limited in API calls.So, dig some more, look at "ro.control_privapp_permissions=log", I think that's in build.prop see --> https://source.android.com/docs/core/permissions/perms-allowlist (https://source.android.com/docs/core/permissions/perms-allowlist)
Then see if that log spits up a perms issue, which you can likely fix in an xml file.
Honestly, I don't see the point in digging that deep. All the same, the application will not work under the system account, and a method to bypass the restrictions has already been found :)
That's what I was wondering about. If applications get signed with a (non-available) private key, the signature must be checked (when starting the app) against a public key that is somewhere in the Android system. Is it known where that key resides, and can it be replaced?
Looks like this is the key - https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5357267/#msg5357267 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5357267/#msg5357267)
The Rigol apps are chown'd root:root. The manifest only states to use shared user id of "android.uid.system". This is for perms reasons, and, apps with same shared uid can share data. I am not sure what data is shared between the Rigol apps and others. However, to get that level of shared user perms of "system" (inherited) the app's MUST be signed with same private key that signed the droid (rom).
You can perhaps replace that shared uid in manifest for all the Rigol apps, but from there I am not sure what breaks or not. The app-priv logging switch should log perms requests that fail, allowing you to see what the issue is after moving app away from shared uid of "system".
-
Apps need to be installed before they can run.
Ok, so replace "checked when starting the app" by "checked when installing the app". But the check is still performed by the local Android instance, by verifying the signature against some (public) key which exists locally, right? So the idea was to replace that key with one where we have both, the private key for signing and the public one for checking.
The permission "allow apps from unknown sources" means sig verify is skipped, but the apk still needs to be signed. Non trusted apps will be limited in various ways. Example, the only way for app to run with all the system priveleges is for the app to be signed with trusted system key. A self signed app cannot use shared user android.uid.system, Android won't allow that, etc.
That was not what I meant.
But I wonder if we can install another pub key into trusted area of Android, for android.uid.system?
That was what I meant! :)
There are ways to bypass sig checking of pm, MAGISK
But that whole process is for non-rooted droids. Most droids are locked and don't allow the permission "allow install of apps from unknown sources". In thise cases the hackers figured out a way to still install a non-trusted app. But that does not escape the security controls around android.uid.system and the keys used to signed the system. It only allows the install of a self-signed app, which we are already doing, because the DHO is a root'd device, already open to us using root.
The whole security model with how Android runs, even root is restricted.
-
The Rigol apps are chown'd root:root.
How did you determine this? I couldn't see any evidence anywhere that Rigol's applications run under root. All files they create are owned by the system.
The manifest only states to use shared user id of "android.uid.system". This is for perms reasons, and, apps with same shared uid can share data. I am not sure what data is shared between the Rigol apps and others. However, to get that level of shared user perms of "system" (inherited) the app's MUST be signed with same private key that signed the droid (rom).
Yes, I know. This is discussed throughout the last few pages of the topic :)
I think that Rigol's applications do not exchange any common data with each other. At least I didn't see any signs of it.
You can perhaps replace that shared uid in manifest for all the Rigol apps, but from there I am not sure what breaks or not. The app-priv logging switch should log perms requests that fail, allowing you to see what the issue is after moving app away from shared uid of "system".
Probably, replacing the user ID android.uid.system with any other one in the webcontrol application will lead to its inoperability, because it requires access to system resources that are only allowed to applications under the system account. I'm not sure about the launcher application, but it is possible that it will not be able to work under a non-system account.
-
One very simple command to copy raw binary data from a serial block device - including SD cards:
cp /dev/sdb /home/userHomeDirectory/rawBinaryImageOfFancySDcardFromScope.fancyLongFileExtension
To be less fancy, I can use any graphical file manager in Linux to make exactly same thing.
Does using the cp command on a block device create a file that you can image back to a new block device, and it will boot?
Yes, it will boot. cp does binary copy of a file. dd is more fancy, because it can count block, do skips etc. If You dont need fancy dd options, just a raw copy, cp is good enough and faster. Anyway, You can even use GUI app to do the same as cp does.
Every file is a string of binary data - even text files are binary (but with ASCII contents and mostly new line at the end). Filesystem is also string of binary data - FS driver in operating system reads this and divide in small parts called files.
BTW. Right now Im fighting to exclude kernel and initrd from sd card - this is nowhere in 5 filesystems, but hided somewhere before.
-
The Rigol apps are chown'd root:root.
How did you determine this? I couldn't see any evidence anywhere that Rigol's applications run under root. All files they create are owned by the system.
The manifest only states to use shared user id of "android.uid.system". This is for perms reasons, and, apps with same shared uid can share data. I am not sure what data is shared between the Rigol apps and others. However, to get that level of shared user perms of "system" (inherited) the app's MUST be signed with same private key that signed the droid (rom).
Yes, I know. This is discussed throughout the last few pages of the topic :)
I think that Rigol's applications do not exchange any common data with each other. At least I didn't see any signs of it.
You can perhaps replace that shared uid in manifest for all the Rigol apps, but from there I am not sure what breaks or not. The app-priv logging switch should log perms requests that fail, allowing you to see what the issue is after moving app away from shared uid of "system".
Probably, replacing the user ID android.uid.system with any other one in the webcontrol application will lead to its inoperability, because it requires access to system resources that are only allowed to applications under the system account. I'm not sure about the launcher application, but it is possible that it will not be able to work under a non-system account.
ssh in
ls -al /system/app/Webcontrol/Webcontrol.apk
ls -al /system/app/Launcher/Launcher.apk
ls -al /system/app/Sparrow/Sparrow.apk
does it show root root ? owner:group it belongs to. They are all rw r r (644) perms too.
This does not mean the apk runs as that uid or gid.
However the apk runs (natively, vm, etc), the uid that starts it or calls it up into another running process (like vm in vm host process), that's the uid the apk runs as.
If a.jar is nobody:nobody and I am in as root, I can call java -jar a.jar to run that jar file.
In std Linux, if the APK's are root:root and 644, then we can say "system" uses the read permission to read in the APK.
***************************************
Then do
ps |grep scope
ps |grep launcher
ps |grep webcontrol
notice all those apk packages are running as "system" user. The "system" user loaded and ran those APK's.
And it all makes sense, the actual running APK is not in /system/app or priv-app
Notice the APK directories in /data/app
/data/app/com.rigol.launcher-1/
ls -al /data/app/com.rigol.launcher-1/base.apk
BAM, it's chown'd system:system
I believe the pm install copies the APK and parks it in /data/app as "system" user. From there uid 1000 does whatever it wants with that file (apk). It's also possible that the base.apk gets to /data/app/ during boot (need to verify).
The base.apk has been altered, md5's of the base apk and their corresponding apk in /system/app/ are not the same. I need to copy out the base.apk and take a look at it, compare, etc.
base.apk is smaller by about 105B on my ntfs filesystem. Looking inside the apk's side-by-side, no obvious diffs, each carries the same signature too.
Something got goofy on my DHO, after reinstalll of the Rigol signed Sparrow, it no longer shows as a system app "adb shell cmd package list packages -s"
-
ssh in
ls -al /system/app/Webcontrol/Webcontrol.apk
ls -al /system/app/Launcher/Launcher.apk
ls -al /system/app/Sparrow/Sparrow.apk
does it show root root ? owner:group it belongs to. They are all rw r r (644) perms too.
I apologize, I did not carefully read your message to which I was responding. For some reason I read “Rigol applications are executed under the root account.” I apologize again.
-
Linux version of the license generator script.
Update: do not use on firmware 00.01.02.00.02 or later.
Instead use https://github.com/zelea2/rigol_vendor_bin
-
Linux version of the license generator script.
Apparently this tool was never updated to work with the latest firmware version 00.01.02.00.02.
-
Seems to have worked on mine?
Else I wouldn't have offered it.
I updated to the latest firmware before running this.
(directly from the net, via the mis-named "Upgrade" menu option, which does not upgrade anything, it just does firmware update)
My scope was 00.01.01 when I got it this afternoon.
I connected it to my lan via ethernet and the main menu gear icon got a red dot on it after a few minutes.
The "upgrade" menu option updated it to 00.01.02.
After that I wrote that bash script and it worked.
And now that you make me wonder...
The About screen only shows 00.01.02 and not the last part.
I show a build date of only 2023/11/09 when the latest firmware from the web site has dates later than that.
So I just applied 00.01.02.02 via usb... and now the build date says 2024/01/03
....and BW is back to 70M and mem depth back to 25M
...and the keys generated by the tool no longer work.
I guess that answers the question of if Rigol might do something to break existing keys. They absolutely did.
-
I just applied 00.01.02.02 via usb... and now the build date says 2024/01/03
....and BW is back to 70M and mem depth back to 25M
...and the keys generated by the tool no longer work.
Old news, there's been a new key generator for ages.
I guess that answers the question of if Rigol might do something to break existing keys. They absolutely did.
Nonsense. At best they were just fiddling with the code preparing to sell official upgrades or something like that.
If Rigol wanted to stop hackers they'd disable ADB to stop people changing vendor.bin or downloading key.dat (which is needed to generate keys).
Changing vendor.bin is the easiest hack and gets you more features than the key generator does.
-
The About screen only shows 00.01.02 and not the last part.
Tap three times on the About menu item :)
I show a build date of only 2023/11/09 when the latest firmware from the web site has dates later than that.
So I just applied 00.01.02.02 via usb... and now the build date says 2024/01/03
....and BW is back to 70M and mem depth back to 25M
...and the keys generated by the tool no longer work.
I guess that answers the question of if Rigol might do something to break existing keys. They absolutely did.
Yes, Rigol has changed the option checking process in 00.01.02.00.02. But this problem has long been solved by the user Zelea2, here is a tool he developed for a good mood - https://github.com/zelea2/rigol_vendor_bin :)
And, by the way, I like it better - it’s easier to use and you don’t need to install any programming languages.
-
Wonerdful!
It worked perfect.
Thank you and wow thank you Zelea
-
I just applied 00.01.02.02 via usb... and now the build date says 2024/01/03
....and BW is back to 70M and mem depth back to 25M
...and the keys generated by the tool no longer work.
Old news, there's been a new key generator for ages.
The first post doesn't mention this at all.
All else flows from that fact.
-
If Rigol wanted to stop hackers they'd disable ADB to stop people changing vendor.bin or downloading key.dat (which is needed to generate keys).
If they disable ADB, it will be still possible to change it directly on SD card with little more effort (or with easier way with flashing image from other model). So they dont want to waste time for this.
-
Yes, Rigol has changed the option checking process in 00.01.02.00.02. But this problem has long been solved by the user Zelea2, here is a tool he developed for a good mood - https://github.com/zelea2/rigol_vendor_bin (https://github.com/zelea2/rigol_vendor_bin) :)
i used that tool few days ago on FW 00.01.02.00.02 to change vendor.bin from 804 to 924S. and pushing it and reboot, i got all i need, 250MHz BW all options unlimited forever, bode plot ready and my SN retained yay! (except changes DHO8 to DHO9) no need to do step 3 and 6 in https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5254071/#msg5254071 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5254071/#msg5254071)
-
bode plot ready
But it lacks hardware support, right? This needs signal generator, which the DHO800 don't have, if I understand correctly.
-
bode plot ready
But it lacks hardware support, right? This needs signal generator, which the DHO800 don't have, if I understand correctly.
Mechatrommer is also working on a replica AWG board. (It's a piggyback board that can be added to the DHO800 too.)
-
bode plot ready
But it lacks hardware support, right? This needs signal generator, which the DHO800 don't have, if I understand correctly.
yes you are right, but i suspect support is coming, or at least diy is possible. this guy gave hope, but he's probably just a clueless lunatic idiot coming from nowhere ;D (rebels are built on hope :P)... ymmv.
https://www.youtube.com/watch?v=vKeOM21Gt7A (https://www.youtube.com/watch?v=vKeOM21Gt7A)
-
Today I spent a lot of time trying to assemble decompiled sources of Sparrow in Android Studio. Although I read a lot of reviews on the Internet that it was almost impossible to build a working application from decompiled Java source codes, there was still a little hope. However, no, life is cruel and there was no surprise. You will have to dig into the Java assembler as before to make any changes to the application logic :(
-
how about trying to understand how to build a java (or any machine code such as exe) compiler and decompiler inside out? along the way you know the format and how OS make entry to the executables allocate RAM etc etc... i think if you guru enough in this, you should be able to insert additional machine codes with correct offset, and correction too on all existing call offsets? this is what i really loved to do on exe but never got the chance and time, i'm just enjoying developing my own app.. and i feel i'm getting older, not enough time :P too many responsibilities and hobbies. ymmv.
-
how about trying to understand how to build a java (or any machine code such as exe) decompiler inside out?
Now we are getting into real "hacking" territory.
How about trying to understand how to build a scope inside out? ;)
-
Now we are getting into real "hacking" territory.
How about trying to understand how to build a scope inside out? ;)
the scope of discussion is SW... you dont have to know the HW in order to change the SW... vice versa. and imho its not hacking, its just a proper route when one wants to become compiler designer (human to machine OS specific conversion) or at least you need to understand its machine code and how they are arranged in certain format in apk or exe or linux/mac format whatever... human made it, so another human (we?) should be able to understand it.. it just a matter of willing to spend time. ymmv.
-
Now we are getting into real "hacking" territory.
How about trying to understand how to build a scope inside out? ;)
ADC is capable to make 2 Gsa/s. Dont know how is with FPGA, but we should try to do at least 1.5.
-
how about trying to understand how to build a java (or any machine code such as exe) compiler and decompiler inside out? along the way you know the format and how OS make entry to the executables allocate RAM etc etc... i think if you guru enough in this, you should be able to insert additional machine codes with correct offset, and correction too on all existing call offsets? this is what i really loved to do on exe but never got the chance and time, i'm just enjoying developing my own app.. and i feel i'm getting older, not enough time :P too many responsibilities and hobbies. ymmv.
I'm far from a guru in Android and Java, I'm just learning everything related to them :)
There is no need to work with “machine codes” (Java opcodes); after decompilation, higher level sources are available - approximately at the level of assembler for a PC. I have already started changing them and it is producing results. But this method is very slow and inconvenient :)
ADC is capable to make 2 Gsa/s. Dont know how is with FPGA, but we should try to do at least 1.5.
Nothing related to the operation of the FPGA will be changed by me or anyone else. Well, unless someone takes and writes from scratch the complete firmware for an FPGA oscilloscope, but to be honest, I won’t even understand what to call him - a genius or a madman :))
-
I found how to remove an LA I don’t need from the bottom panel and, after digging deeper into the code, I figured out how to enable the date and time display :)
achievement like this is already great, if its only involves flipping a constant bit/byte without changing code size/structure/logic. but even greater if it involved adding more codes into the compiled apk.. it might not be easy, you probably need access to android/java documentation on how to assemble into a machine/OS readable format, by paying professional fee... i dont know this android SDK/assembler stuffs.. maybe you need to investigate rat/grey/black/illegit route, just an idea :P so ymmv.
But this method is very slow and inconvenient :)
the problem is when new FW update is released, are you patient enough to redo all the hardwork again? maybe building an automating app can help significantly? just an idea ymmv. cheers.
-
madman
Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.
-
But this method is very slow and inconvenient :)
the problem is when new FW update is released, are you patient enough to redo all the hardwork again? maybe building an automating app can help significantly? just an idea ymmv. cheers.
git.
-
achievement like this is already great, if its only involves flipping a constant bit/byte without changing code size/structure/logic. but even greater if it involved adding more codes into the compiled apk.. it might not be easy, you probably need access to android/java documentation on how to assemble into a machine/OS readable format, by paying professional fee... i dont know this android SDK/assembler stuffs.. maybe you need to investigate rat/grey/black/illegit route, just an idea :P so ymmv.
The decompiled source codes of DALVIK allow you to add/remove/change anything you like. These are not machine codes in an executable file, where you need to take care not to break the structure of the file, where it is impossible to insert something, or replace it with something larger. No, here are the source codes in a programming language, just a very low-level one :)
Here is an example of a piece of such source code:
# virtual methods
.method public draw(Landroid/graphics/Canvas;)V
.locals 16
move-object/from16 v0, p0
.line 85
iget-object v1, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
iget v1, v1, Landroid/graphics/Rect;->right:I
iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
iget v2, v2, Landroid/graphics/Rect;->right:I
iget v3, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mTopWidth:I
# changed
# const/16 v3, 120
# sub-int/2addr v2, v3
# sub-int/2addr v1, v2
.line 87
iget v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->currentState:I
if-eqz v2, :cond_1
const/4 v3, 0x1
if-eq v2, v3, :cond_0
goto/16 :goto_0
.line 92
:cond_0
iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
iget v2, v2, Landroid/graphics/Rect;->left:I
int-to-float v5, v2
const/4 v6, 0x0
int-to-float v7, v1
iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
iget v2, v2, Landroid/graphics/Rect;->bottom:I
int-to-float v8, v2
iget v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mRadius:I
add-int/lit8 v4, v2, 0x1
int-to-float v9, v4
# const/high16 v9, 0x3f000000 # 0.5f
add-int/2addr v2, v3
int-to-float v10, v2
# const/high16 v10, 0x3f000000 # 0.5f
iget-object v11, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->selectedPaint:Landroid/graphics/Paint;
move-object/from16 v4, p1
invoke-virtual/range {v4 .. v11}, Landroid/graphics/Canvas;->drawRoundRect(FFFFFFLandroid/graphics/Paint;)V
.line 96
iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
iget v2, v2, Landroid/graphics/Rect;->left:I
You can change it as you like, when you reassemble it, it will be compiled into the correct “executable” Java file with all the changes made.
the problem is when new FW update is released, are you patient enough to redo all the hardwork again? maybe building an automating app can help significantly? just an idea ymmv. cheers.
Well, I try to mark all changes with a comment so that later they can be easily found in all files. In addition, I think that during updates a very small part of the code will be affected, so you can simply copy the files with your changes.
In general, just for fun, you should try to decompile versions 00.01.01 and 00.01.02 and compare the resulting sources :)
Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.
I assure you that changing the binary firmware of such an FPGA is several orders of magnitude more difficult than any port of the Linux kernel :) Perhaps this can be compared to completely rewriting the entire kernel from scratch. Moreover, initially without having any source codes for this kernel, only a compiled kernel and a disassembler :)
-
Any chance you can get the info boxes for CH1..4 to display the probe divider setting? Only possible if the information is available to the display routine, I guess.
Something like that, right? :))
-
:-+ :-+
-
The decompiled source codes of DALVIK allow you to add/remove/change anything you like. These are not machine codes in an executable file, where you need to take care not to break the structure of the file, where it is impossible to insert something, or replace it with something larger. No, here are the source codes in a programming language, just a very low-level one :)
Here is an example of a piece of such source code:
Is there no decompiler for Android which generates Java source code instead of bytecode assembly?
For plain .class and .jar files, there seem to exist a couple of decompilers.
-
Here is an example of a piece of such source code:
...
You can change it as you like, when you reassemble it, it will be compiled into the correct “executable” Java file with all the changes made.
those codes look somehow readable and editable.. so then why your statement above is contradicting with your statement below?
Although I read a lot of reviews on the Internet that it was almost impossible to build a working application from decompiled Java source codes, there was still a little hope. However, no, life is cruel and there was no surprise. You will have to dig into the Java assembler as before to make any changes to the application logic :(
Something like that, right? :))
great job! rigol should hire you ;D
-
Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.
I assure you that changing the binary firmware of such an FPGA is several orders of magnitude more difficult than any port of the Linux kernel :) Perhaps this can be compared to completely rewriting the entire kernel from scratch. Moreover, initially without having any source codes for this kernel, only a compiled kernel and a disassembler :)
I did already an email to Rigol for source codes just for kernel and U-boot used on this scope - currently they didnt reply. Maybe they do tomorrow?
-
Is there no decompiler for Android which generates Java source code instead of bytecode assembly?
For plain .class and .jar files, there seem to exist a couple of decompilers.
The fact that decompilers exist doesn't mean rebuilding decompiled code produces the same build as the original code.
While it's been a few years since I did hardcore Java development, the typical decompiler like jad almost never produces source that can be cleanly compiled back to an identical binary/bytecode representation of the original build. Often it won't even build at all, especially with a complex project. It's more for reverse engineering and analysis purposes, being able to better understand what the code is doing, than it is for producing pristine source to make changes to and rebuild. Even if you could rebuild it successfully, you could never trust it to behave exactly the same way in every detail.
It is possible to include your Java source in your JAR/WAR/EAR file, and in the early days of Java you'd sometimes run into this, which was a pleasant surprise. For our internal Java apps we would sometimes do this just as emergency backup of the source before we were more disciplined about source control. If you had the executable Java, then you also had the source that built it. Obviously not something a commercial Java application would want to do (unless maybe it was open source). It also bloats the Java archive considerably for larger code bases.
-
Is there no decompiler for Android which generates Java source code instead of bytecode assembly?
For plain .class and .jar files, there seem to exist a couple of decompilers.
Yes, there is, but the decompilation process is imperfect; there are many errors and strange designs that need to be corrected in order to be able to compile a working application from these sources. When the application is small, with a couple of dozen source code files, this is not so scary. But when the application is huge, consisting of several thousand source code files, then fixing all the decompiler errors becomes unrealistic.
Decompiled Java sources can be used for information in order to better understand what is happening in the corresponding files with DALVIK. That's all.
those codes look somehow readable and editable.. so then why your statement above is contradicting with your statement below?
No contradictions. Although these source codes are quite readable and allow any editing, working with them is still much more difficult and labor-intensive than with high-level source codes like Java or C.
great job! rigol should hire you ;D
It’s too early to rejoice, for now this is just a static inscription, in no way dependent on the actual setting of the probe divider :) But I seem to already see a fundamental possibility of linking the selected divider setting to it. But I'll have to tinker with this.
-
I did already an email to Rigol for source codes just for kernel and U-boot used on this scope - currently they didnt reply. Maybe they do tomorrow?
It's very interesting how this will end. I will be waiting for the result of your request :)
-
Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.
I assure you that changing the binary firmware of such an FPGA is several orders of magnitude more difficult than any port of the Linux kernel :) Perhaps this can be compared to completely rewriting the entire kernel from scratch. Moreover, initially without having any source codes for this kernel, only a compiled kernel and a disassembler :)
I did already an email to Rigol for source codes just for kernel and U-boot used on this scope - currently they didnt reply. Maybe they do tomorrow?
It would be somewhat neat if Rigol would split the SW for the device. Close up the actual functional parts like FPGA and the like, but make the UI side more opensource. We appear to just want to change UI stuff. There's some functionla stuff whre Rigol has issues, like FFT, and from the hack-1000 thread we got a util form a user that fixes FFT flat-top issue.
As a side note, I am working on adding a color box to the Channel widget, in the color box you can enter RGB value to change the color of the channel. I thought about color picker wheel too. My work has been slow comared to others here, I just too busy with other priorities.
color wheel
BufferedImage createWheelBuffer(int radius) {
final int diameter = radius * 2;
final double radius2 = radius * radius;
float hue, sat;
final double PI2 = 2 * Math.PI;
double dist2;
int rgb;
BufferedImage buffer = new BufferedImage(diameter, diameter, BufferedImage.TYPE_INT_ARGB);
for (int x = 0; x < diameter; x++) {
for (int y = 0; y < diameter; y++) {
dist2 = distance2(x, y, radius, radius);
// if the point is not inside the circle we go to the next point
if (dist2 > radius2) continue;
hue = (float) (Math.atan2(y - radius, x - radius) / PI2);
sat = (float) Math.sqrt((float) dist2) / (float) radius;
rgb = Color.HSBtoRGB(hue, sat, 1);
buffer.setRGB(x, y, rgb);
}
}
return buffer;
}
int distance2(int x1, int y1, int x2, int y2) {
int a = x2 - x1;
int b = y2 - y1;
return a * a + b * b;
}
And in the paintComponent event:
protected void paintComponent(Graphics gr) {
super.paintComponent(gr);
Graphics2D g = (Graphics2D) gr;
BufferedImage buffer = createWheelBuffer(radius);
g.drawImage(buffer, x, y, this);
}
-
ADC is capable to make 2 Gsa/s. Dont know how is with FPGA, but we should try to do at least 1.5.
That would be a good hack.
There's been speculation that the bottleneck is the FPGA but we don't know that for sure.
It all depends on what generates the clock. It might be fixed by hardware though.
-
Yes, there is, but the decompilation process is imperfect; there are many errors and strange designs that need to be corrected in order to be able to compile a working application from these sources. When the application is small, with a couple of dozen source code files, this is not so scary. But when the application is huge, consisting of several thousand source code files, then fixing all the decompiler errors becomes unrealistic.
Decompiled Java sources can be used for information in order to better understand what is happening in the corresponding files with DALVIK. That's all.
Is is possible to just decompile individual classes? Surely that would make it much more manageable.
The majority of the code in these is C++ though. From the poking around I did it seemed like Java is only used for UI, everything else is in a huge .so file (12Mb IIRC).
-
As a side note, I am working on adding a color box to the Channel widget, in the color box you can enter RGB value to change the color of the channel. I thought about color picker wheel too. My work has been slow comared to others here, I just too busy with other priorities.
Have you already found in the source code how to set the color of the channel trace?
-
As a side note, I am working on adding a color box to the Channel widget, in the color box you can enter RGB value to change the color of the channel. I thought about color picker wheel too. My work has been slow comared to others here, I just too busy with other priorities.
Have you already found in the source code how to set the color of the channel trace?
I posted the color wheel code (that just creates the color wheel, would still need picker and variable set), but implementing a box in the CH widget where you enter RGB value is much easier.
I need to hunt down the widget code, insert box and a [0-9][a-f][ok] keypad, then it updates the channel color variable.
-
Yes, there is, but the decompilation process is imperfect; there are many errors and strange designs that need to be corrected in order to be able to compile a working application from these sources. When the application is small, with a couple of dozen source code files, this is not so scary. But when the application is huge, consisting of several thousand source code files, then fixing all the decompiler errors becomes unrealistic.
Decompiled Java sources can be used for information in order to better understand what is happening in the corresponding files with DALVIK. That's all.
Is is possible to just decompile individual classes? Surely that would make it much more manageable.
The majority of the code in these is C++ though. From the poking around I did it seemed like Java is only used for UI, everything else is in a huge .so file (12Mb IIRC).
Sparrow is almost all java smali. Most of the math related functions are in that auklet.so file.
apktool decompiles all of it.
-
Is is possible to just decompile individual classes? Surely that would make it much more manageable.
I’ve already thought about this, but I haven’t found any evidence that Android Studio can compile .smali files. It would be convenient to insert into the project only a few interesting Java sources for modification, and all other files are guaranteed working .smali files.
Someday later I will explore this possibility again :)
The majority of the code in these is C++ though. From the poking around I did it seemed like Java is only used for UI, everything else is in a huge .so file (12Mb IIRC).
Yes, I also come to this conclusion. The application here is simply an interface between the user and the .so library. Transfer the user's wishes to the library and take data from there for display (except for traces that are drawn without the participation of the application).
-
ADC is capable to make 2 Gsa/s. Dont know how is with FPGA, but we should try to do at least 1.5.
That would be a good hack.
There's been speculation that the bottleneck is the FPGA but we don't know that for sure.
It all depends on what generates the clock. It might be fixed by hardware though.
That was one of my thoughts - quartz or PLL.
-
There's been speculation that the bottleneck is the FPGA but we don't know that for sure.
It all depends on what generates the clock. It might be fixed by hardware though.
The clocks are most likely generated inside the FPGA via a PLL, based on an external quartz. You could reconfigure the PLL if you had access to the FPGA VHDL or Verilog code -- but that would most likely not give you a working, faster data processing.
The permissible maximum frequency will depend on the transit delays of the logic gates and routing delays of the connecting fabric; it depends on how the circuit in the FPGA is set up. If we assume that the Rigol engineers are neither dumb nor mean, they will be running the FPGA close to the maximum it can reliably achieve.
Ok, there is the possibility that they are mean. ;) Maybe the DHO800/900 are deliberately throttled to keep the DHO1000 series well-differentiated. But still, I don't think you can realistically re-configure the clock without access to the FPGA sources.
-
Maybe answer is much simpler than we think. And maybe the answer exists in this file: DHO1000-DHO4000 Update v00.02.12 (https://download.rigol.com/cn/Firmware/Digital%20Oscilloscope/DHO1000%26DHO4000/DHO1000-DHO4000(software)Updatev00.02.12.zip).
-
Maybe answer is much simpler than we think. And maybe the answer exists in this file: DHO1000-DHO4000 Update v00.02.12 (https://download.rigol.com/cn/Firmware/Digital%20Oscilloscope/DHO1000%26DHO4000/DHO1000-DHO4000(software)Updatev00.02.12.zip).
The answer is 42. But what is the question?
-
Maybe answer is much simpler than we think. And maybe the answer exists in this file: DHO1000-DHO4000 Update v00.02.12 (https://download.rigol.com/cn/Firmware/Digital%20Oscilloscope/DHO1000%26DHO4000/DHO1000-DHO4000(software)Updatev00.02.12.zip).
The answer is 42. But what is the question?
How to increase sample rate. Rigol makes clues like in a good criminal story.
Speaking of criminal... Right now Im running Linux on 924S and with really cold heatsink and cold cpu, it often crashes with heavy cpu load - I think they didnt give too much capacitors.
-
Right now Im running Linux on 924S and with really cold heatsink and cold cpu, it often crashes with heavy cpu load - I think they didnt give too much capacitors.
Since the scope ran nice and stable under Android, isn't the much more likely explanation that there is something not quite right with the Linux kernel or drivers?
"Ever since I'm driving blindfolded, my car keeps bumping into things. I think the manufacturer did a lousy job with the steering wheel design!"
-
Right now Im running Linux on 924S and with really cold heatsink and cold cpu, it often crashes with heavy cpu load - I think they didnt give too much capacitors.
Since the scope ran nice and stable under Android, isn't the much more likely explanation that there is something not quite right with the Linux kernel or drivers?
"Ever since I'm driving blindfolded, my car keeps bumping into things. I think the manufacturer did a lousy job with the steering wheel design!"
To check this, offcourse I need to install log rotate (to see some logs before a crash) and measure voltages/ripples. BTW. buck converter IC is managed via I2C and I had some problems with one kernel module related to this bus.
-
What's the CPU load when it's running the 'scope application?
-
What's the CPU load when it's running the 'scope application?
I Didnt check it before. Right now I have fight with Debian instead of Android and currently (sadly) no rigol app - it will be later.
Some days ago I was playing HoM&MIII (old game from 90' ported to Android - heavy load for short moments like 10-15 seconds at most) on it for couple hours and rigol app was working in the background without any problems.
-
What's the CPU load when it's running the 'scope application?
I measured cpu usage of my DHO802 using the system monitor of the ADB Shell apk:
https://youtube.com/shorts/G_zunMmZ-TA?si=r4rV0MslRNU9YPfI
-
then it updates the channel color variable.
I talked about this. Do you already know how the color is set to the channel trace? Found this variable?
-
For those who want to modify the application, I found a convenient extension for VS Code - APKLab. It is very convenient to edit smali with syntax highlighting. Can compile with one click after changes, align, sign and install on the device. Replaces manual work with a set of utilities apktool, zipalign, jarsigner.
Maybe, of course, everyone already knows about this program and I’m writing about the obvious, but I just found it now :)
-
Maybe answer is much simpler than we think. And maybe the answer exists in this file: DHO1000-DHO4000 Update v00.02.12 (https://download.rigol.com/cn/Firmware/Digital%20Oscilloscope/DHO1000%26DHO4000/DHO1000-DHO4000(software)Updatev00.02.12.zip).
The answer is 42. But what is the question?
dont depend your life on a movie, pop culture or some pure coincidence. you life will be in jeopardy ;) ;D i swear i'll never watch that movie again, my time is more precious.
-
The answer is 42. But what is the question?
dont depend your life on a movie, pop culture or some pure coincidence. you life will be in jeopardy ;) ;D i swear i'll never watch that movie again, my time is more precious.
I didn't even realize there was a movie. I read the book and played the text adventure, looong ago. Worth every minute! :)
-
I measured cpu usage of my DHO802 using the system monitor of the ADB Shell apk:
https://youtube.com/shorts/G_zunMmZ-TA?si=r4rV0MslRNU9YPfI
It's working pretty hard. Rigol did not provide that heat spreader and fan for decorative purposes...
-
It's working pretty hard. Rigol did not provide that heat spreader and fan for decorative purposes...
Yes you are right. But don't mind the graphical artifacts and distortions. Just my phone was recording the screen, at same time controlling the oscilloscope via the web interface, and receiving data via adb.
-
What's the CPU load when it's running the 'scope application?
I measured cpu usage of my DHO802 using the system monitor of the ADB Shell apk:
https://youtube.com/shorts/G_zunMmZ-TA?si=r4rV0MslRNU9YPfI
Yeah... You didnt see me when doing make -j 6 to compile Linux kernel. So all cores was loaded to 100% for a quite long time. When I omit '-j ', only one core was fully loaded and int this case, it was very stable.
I will check that issue later - maybe its design or maybe only my scope. Now I need to have proper kernel to load Rigol kernel modules - I dont have source code, so at least I need same or similar version of Kernel. I cant do 10 things at the same time - its much harder to keep focus :)
-
Manufacturer is slowly releasing firmware updates, you guys are moving lightning speed forward with some decent upgrades and tons of PoC hacks...
Where is the golden spot as for today?
can someone summarize which is best-to-date "stable" hack to use on rigol 804?
-
can someone summarize which is best-to-date "stable" hack to use on rigol 804?
do a search by "zelea2" in this topic, you'll find the latest mentions of the git repo and other necessary leads.
-
can someone summarize which is best-to-date "stable" hack to use on rigol 804?
do a search by "zelea2" in this topic, you'll find the latest mentions of the git repo and other necessary leads.
Forum search engines takes a lot of cpu and database load - sometimes user must wait even many minutes for output. Its quicker to use db indexes by using user page (link on the nick) -> Show Posts on the left side.
-
then it updates the channel color variable.
I talked about this. Do you already know how the color is set to the channel trace? Found this variable?
Did you edit the colors xml file?
Edit "yellow" at the bottom of the doc.
-
Did you edit the colors xml file?
Edit "yellow" at the bottom of the doc.
Yes, I tried to do this at the very beginning of my attempts to change something in the application :)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5348603/#msg5348603 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5348603/#msg5348603)
-
can someone summarize which is best-to-date "stable" hack to use on rigol 804?
do a search by "zelea2" in this topic, you'll find the latest mentions of the git repo and other necessary leads.
Forum search engines takes a lot of cpu and database load - sometimes user must wait even many minutes for output.
i remember this only happened when i was on intel i386 or earlier. how old are you? ;D
here one of the result.. https://www.eevblog.com/forum/testgear/hacking-the-hdo1khdo4k-rigol-12-bit-scope/msg5320080/#msg5320080 (https://www.eevblog.com/forum/testgear/hacking-the-hdo1khdo4k-rigol-12-bit-scope/msg5320080/#msg5320080) (not search on this topic, i searched on the entire forum... 9 hits)
-
Forum search engines takes a lot of cpu and database load - sometimes user must wait even many minutes for output. Its quicker to use db indexes by using user page (link on the nick) -> Show Posts on the left side.
Not since indexing came into the picture ~30+yrs ago.
Almost all forum package have built-in indexing, or the platform has an indexer on the side used by the forum code.
Using the indexer to find stuff does take cpu, but mush less overall cpu time due to very fast results.
Some system admins might even bound forum processes to cpu's 0,1,2,3,4,5 and bound indexer process to cpu's 6,7
-
Did you edit the colors xml file?
Edit "yellow" at the bottom of the doc.
Yes, I tried to do this at the very beginning of my attempts to change something in the application :)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5348603/#msg5348603 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5348603/#msg5348603)
Which item specifically did you edit, can you share that line here.
I'll look for trace color variable.
If you want to change the icons and such being used, just edit the images (attached)
-
Did you edit the colors xml file?
Edit "yellow" at the bottom of the doc.
Yes, I tried to do this at the very beginning of my attempts to change something in the application :)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5348603/#msg5348603 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5348603/#msg5348603)
This xml calls out "<stroke android:width="1.0dip" android:color="@color/bg_channel1_color" />"
Edit this entry in the colors.xml file <color name="bg_channel1_color">#fff1e504</color>
-
Which item specifically did you edit, can you share that line here.
I'll look for trace color variable.
I tried changing this value:
<color name="yellow">#ffffff00</color>
And this:
<color name="chan1">@color/yellow</color>
If you want to change the icons and such being used, just edit the images (attached)
Yes, I've seen it all before. But some (rather most) images in .xml files are in SVG format, and I haven’t figured out how to easily change them yet :)
-
I dont remember who did one-line measurements, but somebody uploaded it somewhere?
-
Which item specifically did you edit, can you share that line here.
I'll look for trace color variable.
I tried changing this value:
<color name="yellow">#ffffff00</color>
And this:
<color name="chan1">@color/yellow</color>
If you want to change the icons and such being used, just edit the images (attached)
Yes, I've seen it all before. But some (rather most) images in .xml files are in SVG format, and I haven’t figured out how to easily change them yet :)
the @ sign is a symbol for "reference", it refers back to the already defined color yellow by name, <color name="yellow">#fff1e504</color>, this way they can define more variables that map back to the same color definition, etc. Don't change any of the entries that use @
You need to edit the other entry in colors.xml file, I listed it. It appears more bad coding on Rigol part, why they use two variable, one for line color and one for button color? One color definition is all that's needed. Maybe the $4000 scopes allow you to set both button and line color? Recall much of the DHO800-900 code comes from other dev work.
As mattert of fact, you can make it a one color reference, just change <color name="bg_channel1_color">#fff1e504</color> to <color name="bg_channel1_color">@color/yellow</color>, so when you change <color name="yellow">#fff1e504</color> then both button and line change to that color.
They are using android.graphics.color scheme, a decimal value converted as hex in the xml.
The other color definition in other xml file <stroke android:width="1.0dip" android:color="@color/bg_channel1_color" /> is the yellow color being used for line (should be), it refers back to the colors.xml file, etc, so be sure the color you want is an android.graphics.color decimal value converted back to hex.
See --> https://convertingcolors.com/android-color-4294042884.html?search=Android(4294042884)
when you change value on webpage the top section of the page becomes that color.
***************************************
If you want to preserve Rigol data, just make your own color by name entry, something like <color name="my_ch1_color">#00ffff00</color>, then change the other two referencing entries to use "@color/my_ch1_color", <color name="chan1">@color/my_ch1_color</color>. It's that simple.
If you want me to write a bash script to mod that file using color values as args, I can do that, but I think 1st step is to manually try your edits to see results.
-
I dont remember who did one-line measurements, but somebody uploaded it somewhere?
Not yet, but I can post it if needed. I'm still trying to finish displaying the probe attenuation in the channel icons.
-
the @ sign is a symbol for "reference", it refers back to the already defined color/yellow, this way they can define more variables that map back to the same color definition, etc. Don't change any of the entries that use @
You need to edit the other entry in colors.xml file, I listed it. It appears more bad coding on Rigol part, why they use two variable, one for line color and one for button color? One color definition is all that's needed.
As mattert of fact, you can make it a one color reference, just change <color name="bg_channel1_color">#fff1e504</color> to <color name="bg_channel1_color">@color/yellow</color>, so when you change <color name="yellow">#00ffff00</color> then both button and line change to that color.
I already know everything you wrote :) I would advise you to change the color of the trace of any channel yourself and share your experience of what and where you changed to achieve the result. Because I couldn’t change the color of the track, no matter what I changed. Only the color of the icon and other interface elements changes, but not the trace.
They are using android.graphics.color scheme, a decimal value converted as hex in the xml.
The other color definition is the yellow color being used for line (should be), so be sure the color you want is an android.graphics.color decimal value converted back to hex.
See --> https://convertingcolors.com/android-color-4294042884.html?search=Android(4294042884)
when you change value on webpage the top section of the page becomes that color.
I am familiar with hexadecimal notation and methods for encoding colors at different depths.
-
the @ sign is a symbol for "reference", it refers back to the already defined color/yellow, this way they can define more variables that map back to the same color definition, etc. Don't change any of the entries that use @
You need to edit the other entry in colors.xml file, I listed it. It appears more bad coding on Rigol part, why they use two variable, one for line color and one for button color? One color definition is all that's needed.
As mattert of fact, you can make it a one color reference, just change <color name="bg_channel1_color">#fff1e504</color> to <color name="bg_channel1_color">@color/yellow</color>, so when you change <color name="yellow">#00ffff00</color> then both button and line change to that color.
I already know everything you wrote :) I would advise you to change the color of the trace of any channel yourself and share your experience of what and where you changed to achieve the result. Because I couldn’t change the color of the track, no matter what I changed. Only the color of the icon and other interface elements changes, but not the trace.
They are using android.graphics.color scheme, a decimal value converted as hex in the xml.
The other color definition is the yellow color being used for line (should be), so be sure the color you want is an android.graphics.color decimal value converted back to hex.
See --> https://convertingcolors.com/android-color-4294042884.html?search=Android(4294042884)
when you change value on webpage the top section of the page becomes that color.
I am familiar with hexadecimal notation and methods for encoding colors at different depths.
But I asked you what did you change, you did not list <color name="bg_channel1_color">#fff1e504</color>, so I ask again, what did you change, or not change?
If you changed "<color name="chan1">@color/yellow</color>", what exactly did you change it to? No need to change the reference entry, etc.
I tried changing this value:
<color name="yellow">#ffffff00</color>
And this:
<color name="chan1">@color/yellow</color>
I didn't say you needed to know how to convert to hex, I said the entries being used are encoded hex from decimal values of android.graphics.color map. If you know that already, then good, other readers might not have known that. Most don't know that android.graphics.color(4294967040) is a pee yellow color ;)
-
I dont remember who did one-line measurements, but somebody uploaded it somewhere?
Not yet, but I can post it if needed. I'm still trying to finish displaying the probe attenuation in the channel icons.
BTW. print screen key on USB keyboard works. File path and name for example: [last file system]/media/0/Screenshots/Screenshot_20130118-090648.png
-
I dont remember who did one-line measurements, but somebody uploaded it somewhere?
Not yet, but I can post it if needed. I'm still trying to finish displaying the probe attenuation in the channel icons.
BTW. print screen key on USB keyboard works. File path and name for example: [last file system]/media/0/Screenshots/Screenshot_20130118-090648.png
Having image data stuck on the scope has limited use. Would be easy to use 'toybox nc' to copy the newly created images that show up in that media location to some other location on network, like a nas attached to windows or something..
-
I dont remember who did one-line measurements, but somebody uploaded it somewhere?
Not yet, but I can post it if needed. I'm still trying to finish displaying the probe attenuation in the channel icons.
BTW. print screen key on USB keyboard works. File path and name for example: [last file system]/media/0/Screenshots/Screenshot_20130118-090648.png
Having image data stuck on the scope has limited use. Would be easy to use 'toybox nc' to copy the newly created images that show up in that media location to some other location on network, like a nas attached to windows or something..
In Android settings probably, we can change this locaction.
If ssh works, then maybe also sshfs which can be mounted on external Linux machine and offcourse it will be visible locally like any other mounted file system. Dont know if sshfs works at Windows.
-
But I asked you what did you change, you did not list <color name="bg_channel1_color">#fff1e504</color>, so I ask again, what did you change, or not change?
If you search the code, you can see that this color alias only applies to a couple of labels :)
If you changed "<color name="chan1">@color/yellow</color>", what exactly did you change it to? No need to change the reference entry, etc.
Changed it to a constant value of white color.
BTW. print screen key on USB keyboard works. File path and name for example: [last file system]/media/0/Screenshots/Screenshot_20130118-090648.png
Yep, I already tried that :)
-
Speaking of print-screens I forgot to mention, I rewrited my *-nix script (make and save screenshot on external computer) to work with other scopes and I tested it on 924S.
https://github.com/norbertkiszka/rigol-screenshot
-
Having image data stuck on the scope has limited use.
Well, I don’t know, I’m fine using images on an oscilloscope :)
-
Having image data stuck on the scope has limited use.
Well, I don’t know, I’m fine using images on an oscilloscope :)
They're not really stuck once you use a tool to get them. ;)
Another way of saying it, without using a tool the images are stuck on the scope, there's no option in Util icon that says "move my images to FTP server", or something like that, etc.
-
Having image data stuck on the scope has limited use.
Well, I don’t know, I’m fine using images on an oscilloscope :)
They're not really stuck once you use a tool to get them. ;)
Another way of saying it, without using a tool the images are stuck on the scope, there's no option in Util icon that says "move my images to FTP server", or something like that, etc.
You can make a script on server/computer to download/synchronize those files. Script can be executed by hand, by cron or in a loop. To copy and preserve date&time, You can use rsync -av source destination
FTP or SSHFS or whatever. Maybe on scope side instead.
-
You can make a script on server/computer to download/synchronize those files. Script can be executed by hand, by cron or in a loop. To copy and preserve date&time, You can use rsync -av source destination
FTP or SSHFS or whatever. Maybe on scope side instead.
There is no rsync command in the oscilloscope system :)
-
But I asked you what did you change, you did not list <color name="bg_channel1_color">#fff1e504</color>, so I ask again, what did you change, or not change?
If you search the code, you can see that this color alias only applies to a couple of labels :)
If you changed "<color name="chan1">@color/yellow</color>[/b][/color]", what exactly did you change it to? No need to change the reference entry, etc.
Changed it to a constant value of white color.
BTW. print screen key on USB keyboard works. File path and name for example: [last file system]/media/0/Screenshots/Screenshot_20130118-090648.png
Yep, I already tried that :)
You changed <color name="chan1">@color/yellow</color> to <color name="chan1">@color/white</color> ?
I guess that still works because a color with name "white" is defined, but that's the button color.
Also, you should not change any of the reference entries.
Next is, refences to "yellow" color in the colors.xml file comes from all sorts of files
[roott@localhost Sparrow]# find . -type f 2>/dev/null -exec grep -b "yellow" ${PWD} {} \;
./res/layout/activity_screen_saver.xml:746: <TextView android:textSize="72.0sp" android:textColor="@color/yellow" android:id="@id/main_ad_textview" android:tag="binding_2" android:layout_width="wrap_content" android:layout_height="wrap_content" />
./res/color/keyboard_tvtextcolor_selector.xml:111: <item android:state_pressed="true" android:color="@color/coldyellow" />
./res/color/keyboard_tvtextcolor_selector.xml:187: <item android:state_focused="true" android:color="@color/coldyellow" />
./res/values/colors.xml:3135: <color name="chan1">@color/yellow</color>
./res/values/colors.xml:3448: <color name="coldyellow">#ffffe200</color>
./res/values/colors.xml:9792: <color name="light_goldenrod_yellow">#fffafad2</color>
./res/values/colors.xml:10298: <color name="light_yellow">#ffffffe0</color>
./res/values/colors.xml:16700: <color name="yellow">#00ffff00</color>
./res/values/colors.xml:16743: <color name="yellow_green">#ff9acd32</color>
./res/values/public.xml:125946: <public type="color" name="coldyellow" id="0x7f06004f" />
./res/values/public.xml:134262: <public type="color" name="light_goldenrod_yellow" id="0x7f0600c4" />
./res/values/public.xml:134918: <public type="color" name="light_yellow" id="0x7f0600ce" />
./res/values/public.xml:148405: <public type="color" name="yellow" id="0x7f060187" />
./res/values/public.xml:148463: <public type="color" name="yellow_green" id="0x7f060188" />
./res/values/public.xml:252635: <public type="drawable" name="bg_yellow_line_menu" id="0x7f0803fa" />
./smali/androidx/constraintlayout/core/widgets/analyzer/DependencyGraph.smali:119869: const-string v4, " BGCOLOR=\"yellow\" "
./smali/com/rigol/scope/R$color.smali:5472:.field public static final coldyellow:I = 0x7f06004f
./smali/com/rigol/scope/R$color.smali:12852:.field public static final light_goldenrod_yellow:I = 0x7f0600c4
./smali/com/rigol/scope/R$color.smali:13428:.field public static final light_yellow:I = 0x7f0600ce
./smali/com/rigol/scope/R$color.smali:25435:.field public static final yellow:I = 0x7f060187
./smali/com/rigol/scope/R$color.smali:25485:.field public static final yellow_green:I = 0x7f060188
./smali/com/rigol/scope/R$drawable.smali:13406:.field public static final bg_yellow_line_menu:I = 0x7f0803fa
And we have back references to just color names too, this one bg_yellow_line_menu.xml seems like it's related to line draw for ch1
roott@localhost Sparrow]# find . -type f 2>/dev/null -exec grep -b "bg_channel1_color" ${PWD} {} \;
./res/drawable/bg_yellow_line_menu.xml:148: <stroke android:width="1.0dip" android:color="@color/bg_channel1_color" />
./res/values/colors.xml:1393: <color name="bg_channel1_color">#fff1e504</color>
./res/values/public.xml:123342: <public type="color" name="bg_channel1_color" id="0x7f060029" />
./smali/com/rigol/scope/R$color.smali:3172:.field public static final bg_channel1_color:I = 0x7f060029
-
you changed <color name="chan1">@color/yellow</color> to <color name="chan1">@color/white</color> ?
I wrote it - to a constant value, and not to a link. That is, to
<color name="chan1">#ffffffff</color>
Next is, refences to "yellow" color in the colors.xml file comes from all sorts of files
[roott@localhost Sparrow]# find . -type f 2>/dev/null -exec grep -b "yellow" ${PWD} {} \;
./res/layout/activity_screen_saver.xml:746: <TextView android:textSize="72.0sp" android:textColor="@color/yellow" android:id="@id/main_ad_textview" android:tag="binding_2" android:layout_width="wrap_content" android:layout_height="wrap_content" />
./res/color/keyboard_tvtextcolor_selector.xml:111: <item android:state_pressed="true" android:color="@color/coldyellow" />
./res/color/keyboard_tvtextcolor_selector.xml:187: <item android:state_focused="true" android:color="@color/coldyellow" />
./res/values/colors.xml:3135: <color name="chan1">@color/yellow</color>
./res/values/colors.xml:3448: <color name="coldyellow">#ffffe200</color>
./res/values/colors.xml:9792: <color name="light_goldenrod_yellow">#fffafad2</color>
./res/values/colors.xml:10298: <color name="light_yellow">#ffffffe0</color>
./res/values/colors.xml:16700: <color name="yellow">#00ffff00</color>
./res/values/colors.xml:16743: <color name="yellow_green">#ff9acd32</color>
./res/values/public.xml:125946: <public type="color" name="coldyellow" id="0x7f06004f" />
./res/values/public.xml:134262: <public type="color" name="light_goldenrod_yellow" id="0x7f0600c4" />
./res/values/public.xml:134918: <public type="color" name="light_yellow" id="0x7f0600ce" />
./res/values/public.xml:148405: <public type="color" name="yellow" id="0x7f060187" />
./res/values/public.xml:148463: <public type="color" name="yellow_green" id="0x7f060188" />
./res/values/public.xml:252635: <public type="drawable" name="bg_yellow_line_menu" id="0x7f0803fa" />
./smali/androidx/constraintlayout/core/widgets/analyzer/DependencyGraph.smali:119869: const-string v4, " BGCOLOR=\"yellow\" "
./smali/com/rigol/scope/R$color.smali:5472:.field public static final coldyellow:I = 0x7f06004f
./smali/com/rigol/scope/R$color.smali:12852:.field public static final light_goldenrod_yellow:I = 0x7f0600c4
./smali/com/rigol/scope/R$color.smali:13428:.field public static final light_yellow:I = 0x7f0600ce
./smali/com/rigol/scope/R$color.smali:25435:.field public static final yellow:I = 0x7f060187
./smali/com/rigol/scope/R$color.smali:25485:.field public static final yellow_green:I = 0x7f060188
./smali/com/rigol/scope/R$drawable.smali:13406:.field public static final bg_yellow_line_menu:I = 0x7f0803fa
In the example you gave there is not a single mention of bg_channel1_color , which you so persistently wrote to me about :)
I repeat - first try changing the color of the trace on your oscilloscope yourself. I think you will find that this is more difficult to do than you imagine.
-
There is no rsync command in the oscilloscope system :)
there's also no less which is ridiculous and annoying. it should be easy, however, to install busybox there, which contains all those small utilities.
same for rsync actually.
-
There is no rsync command in the oscilloscope system :)
there's also no less which is ridiculous and annoying. it should be easy, however, to install busybox there, which contains all those small utilities.
same for rsync actually.
And he stands there :)
-
You can make a script on server/computer to download/synchronize those files. Script can be executed by hand, by cron or in a loop. To copy and preserve date&time, You can use rsync -av source destination
FTP or SSHFS or whatever. Maybe on scope side instead.
There is no rsync command in the oscilloscope system :)
rsync can be used on other side and get files via sshd. Same as scp command.
-
In the example you gave there is not a single mention of bg_channel1_color , which you so persistently wrote to me about :)
I repeat - first try changing the color of the trace on your oscilloscope yourself. I think you will find that this is more difficult to do than you imagine.
I gave the exact back reference in my post, see attached
Duly noted, this color may just be line color for the ch menus.
<?xml version="1.0" encoding="utf-8"?>
<shape
xmlns:android="http://schemas.android.com/apk/res/android">
<corners android:radius="3.0dip" />
<stroke android:width="1.0dip" android:color="@color/bg_channel1_color" />
<solid android:color="@color/black" />
</shape>
-
I gave the exact back reference in my post, see attached
Duly noted, this color may just be line color for the ch menus.
<?xml version="1.0" encoding="utf-8"?>
<shape
xmlns:android="http://schemas.android.com/apk/res/android">
<corners android:radius="3.0dip" />
<stroke android:width="1.0dip" android:color="@color/bg_channel1_color" />
<solid android:color="@color/black" />
</shape>
Ok, I'm looking forward to a screenshot with green/red/brown, etc. track :)
-
Also take a look here
Sparrow/smali/com/rigol/scope/R$color.smali
lots of color definitions in that file too.
[roott@localhost scope]# grep "7f060029" "R\$color.smali"
.field public static final bg_channel1_color:I = 0x7f060029
-
Today I spent many hours trying to add a color to the probe divider value on an enabled channel and have the value change color depending on whether the channel is on or off. I recompiled and reinstalled the application probably 200 times. I learned a lot of new and strange things about the DALVIK language :))
-
Also take a look here
Sparrow/smali/com/rigol/scope/R$color.smali
lots of color definitions in that file too.
[roott@localhost scope]# grep "7f060029" "R\$color.smali"
.field public static final bg_channel1_color:I = 0x7f060029
I don’t just watch it, I add my names and meanings of colors and interface elements to it :)
-
rsync can be used on other side and get files via sshd. Same as scp command.
Yes, I didn't think about that :)
-
Today I spent many hours trying to add a color to the probe divider value on an enabled channel and have the value change color depending on whether the channel is on or off. I recompiled and reinstalled the application probably 200 times. I learned a lot of new and strange things about the DALVIK language :))
no leap year in a DHO. :-DD
-
Today I spent many hours trying to add a color to the probe divider value on an enabled channel and have the value change color depending on whether the channel is on or off. I recompiled and reinstalled the application probably 200 times. I learned a lot of new and strange things about the DALVIK language :))
no leap year in a DHO. :-DD
5 year later... TV news: some hackers managed to build DHO4804 oscilloscope from a DHO802.
-
no leap year in a DHO. :-DD
Why not? Of course have :)
-
I have idea to write script to automatically send created screenshots from scope to ssh or ftp. Somebody works on the scope, goes to other place with computer and all screenshots are already on local disk. I wrote this, because sometimes I have some nice ideas, which later I forget, so maybe somebody will remind me this later on this forum.
-
at this point... just force it to spit out all the data over API and write linux based software for computer :-//
-
I re-created a project to change the application and transferred all the changes made to it to fix them in git. The project was posted on github - https://github.com/Andy-Big/DHO800_900_Sparrow_project
By the way, today I tried to decompile the application versions 00.01.01.00.00 and 00.01.02.00.02 and compare the resulting sources. Yes, there really are differences, but not so big that it would pose a problem when a new version is released. Of course, you will have to tinker for about an hour to make all the changes from the new version, checking that they will not spoil my changes, but this is not such a big problem, considering how “frequently” new versions are released :)
-
at this point... just force it to spit out all the data over API and write linux based software for computer :-//
There are already bunch of different software on Linux for oscilloscopes (downloading, viewing and measurements of waveforms, remote screenshots, change settings via network and many more), so what is Your point?
-
I re-created a project to change the application and transferred all the changes made to it to fix them in git. The project was posted on github - https://github.com/Andy-Big/DHO800_900_Sparrow_project
By the way, today I tried to decompile the application versions 00.01.01.00.00 and 00.01.02.00.02 and compare the resulting sources. Yes, there really are differences, but not so big that it would pose a problem when a new version is released. Of course, you will have to tinker for about an hour to make all the changes from the new version, checking that they will not spoil my changes, but this is not such a big problem, considering how “frequently” new versions are released :)
What are .so libs are for? Anyway, some little idiot-proof readme will be preety useful.
-
I have idea to write script to automatically send created screenshots from scope to ssh or ftp.
There are several here already using SSH or FTP to get screenshots, video recordings, and/or setup files from their scopes. Or even using the web control interface or with SCPI commands.
And there are some saving to NAS using NFS mount via busybox; bypassing the internal SDCard. 8)
You can search the forum here for examples, if you don't want to reinvent the wheel.
-
What are .so libs are for? Anyway, some little idiot-proof readme will be preety useful.
The largest one - libscope-auklet.so - implements all the operating functions of the oscilloscope. All work with the FPGA is done through it, saving and loading parameters, determining the model and the capabilities available to it, checking licenses and keys, and much more. Together with the FPGA, it forms the functional core of the oscilloscope.
The rest, judging by their names, are for working with .png images, for working with .pdf, for servicing the keyboard and indicators panel, general functions of C++ libraries.
Yes, I'll have to make some kind of readme :)
-
What are .so libs are for? Anyway, some little idiot-proof readme will be preety useful.
The largest one - libscope-auklet.so - implements all the operating functions of the oscilloscope. All work with the FPGA is done through it, saving and loading parameters, determining the model and the capabilities available to it, checking licenses and keys, and much more. Together with the FPGA, it forms the functional core of the oscilloscope.
The rest, judging by their names, are for working with .png images, for working with .pdf, for servicing the keyboard and indicators panel, general functions of C++ libraries.
So You disassembled it and made some changes?
-
So You disassembled it and made some changes?
-
So You disassembled it and made some changes?
Heh. I was suspecting this change in xml and graphic files. Eventually in app binary instead of FPGA. Quite big surprise.
-
Heh. I was suspecting this change in xml and graphic files. Eventually in app binary instead of FPGA. Quite big surprise.
Not only. Changes are also made to the application's executable files.
-
Heh. I was suspecting this change in xml and graphic files. Eventually in app binary instead of FPGA. Quite big surprise.
Not only. Changes are also made to the application's executable files.
Disassembling takes much more effort than play with xml files. Big thx for sharing.
-
Disassembling takes much more effort than play with xml files. Big thx for sharing.
Changing resources alone won't get you far :)
-
There is no rsync command in the oscilloscope system :)
there's also no less which is ridiculous and annoying. it should be easy, however, to install busybox there, which contains all those small utilities.
same for rsync actually.
The dho droid has toybox, but no less in there.
-
BTW. print screen key on USB keyboard works. File path and name for example: [last file system]/media/0/Screenshots/Screenshot_20130118-090648.png
It does work, but on my 804 I had to change droid settings for screen pics, it was not set to internal storage, so prtscn was throwing err "cannot save image".
-
BTW. print screen key on USB keyboard works. File path and name for example: [last file system]/media/0/Screenshots/Screenshot_20130118-090648.png
It does work, but on my 804 I had to change droid settings for screen pics, it was not set to internal storage, so prtscn was throwing err "cannot save image".
Thats little strange. Mine 924S never had this issue. Maybe different firmware version I guess.
-
So I did it! The channel widgets in the bottom panel now display the actual probe divider value that was set for the channel.
-
Speaking of it. Another useful thing will be custom probe ratio. Like 11, 12, 13 but I think that probably can be hard. But... In some earlier firmware it was different, In 02.0.02 we have x20 x50 and somewhere before it was only powers of ten - so we can make diffs.
-
So I did it! The channel widgets in the bottom panel now display the actual probe divider value that was set for the channel.
do we really need the decimal place?
-
In my 924S mac address is like completely random (unknown vendor id). First three bytes should be vendor id and Rigol got 0019AF for many years.
https://gist.github.com/aallan/b4bb86db86079509e6159810ae9bd3e4 (https://gist.github.com/aallan/b4bb86db86079509e6159810ae9bd3e4)
0019AF Rigol Technologies, Inc.
-
So I did it! The channel widgets in the bottom panel now display the actual probe divider value that was set for the channel.
do we really need the decimal place?
Probably difficulty with cracking compiled binaries - its not super easy to change float into int or the other way round in assembler. Example for ARM64:
https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:2,endLineNumber:7,positionColumn:2,positionLineNumber:7,selectionStartColumn:2,selectionStartLineNumber:7,startColumn:2,startLineNumber:7),source:'//+Type+your+code+here,+or+load+an+example.%0Avoid+testFunction(void)+%7B%0A++++float+f%3B%0A++++int+i%3B%0A++++f+%3D+10.0%3B%0A++++i+%3D+(int)f%3B%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:arm64g1020,filters:(b:'0',binary:'1',binaryObject:'1',commentOnly:'0',debugCalls:'1',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'0',trim:'1'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'',overrides:!(),selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+ARM64+gcc+10.2+(Editor+%231)',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4 (https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:2,endLineNumber:7,positionColumn:2,positionLineNumber:7,selectionStartColumn:2,selectionStartLineNumber:7,startColumn:2,startLineNumber:7),source:'//+Type+your+code+here,+or+load+an+example.%0Avoid+testFunction(void)+%7B%0A++++float+f%3B%0A++++int+i%3B%0A++++f+%3D+10.0%3B%0A++++i+%3D+(int)f%3B%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:arm64g1020,filters:(b:'0',binary:'1',binaryObject:'1',commentOnly:'0',debugCalls:'1',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'0',trim:'1'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'',overrides:!(),selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+ARM64+gcc+10.2+(Editor+%231)',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4)
-
Speaking of it. Another useful thing will be custom probe ratio. Like 11, 12, 13 but I think that probably can be hard. But... In some earlier firmware it was different, In 02.0.02 we have x20 x50 and somewhere before it was only powers of ten - so we can make diffs.
Yes, it will indeed be much more difficult. I'm not even entirely sure that this will be possible without serious modification of the native library.
do we really need the decimal place?
I simply take the text from the existing list of divisors. I'll look for this list and try to change it. Decimal places do look weird, I agree.
Probably difficulty with cracking compiled binaries - its not super easy to change float into int or the other way round in assembler. Example for ARM64:
For virtual machine bytecode everything is a little simpler, but you still have to tinker a lot :)
-
Very nice work AndyBig!!
But a couple questions/comments...
It appears that you had to increase the bottom channel banner (taking away from the waveform display window?
It also appears this caused the text in the right hand "result" window to not display correctly as you can see "Vmin(C1)" is slightly on top of "Cur:"
Would it be possible to instead keep the bottom ribbon the same size (thus not taking away from the waveform window and causing the above noted problem) and instead
either
Make the large colored channel numbers slightly smaller and move them up and put the 10x under the large channel number?
or
Use the large black space to the right of the 4 channel boxes and put a table of 1,2,3,4 with the associated probe multiplier there?? Or even use the blank space at the top of the window next to Waveform View and put 1:10X, 2:1X, 3:1X, 4:10X
or
find some other open space that the probe multiplier would fit without causing window realestate placement conflicts
It definately seems Rigol could have done a much better job of providing the user with more info (like the missing probe multiplier).
What I really wish is that when viewing the display through the web interface that MORE info could be made available on the external monitor and have a nice large waveform display.
Good work none the less!!!
cheers
Dwight
-
Removed decimal places from probe divisor values. At the same time, I fixed the selection of the active channel widget in the bottom panel :)
-
Very nice work AndyBig!!
Thanks :)
But a couple questions/comments...
It appears that you had to increase the bottom channel banner (taking away from the waveform display window?
It also appears this caused the text in the right hand "result" window to not display correctly as you can see "Vmin(C1)" is slightly on top of "Cur:"
No, I didn't change the dimensions of the bottom panel. This misalignment of the text in the results pane is caused by my attempts to compile the measurements into one line. I still haven’t fully figured out the layout of this panel in all its modes, which is why I ended up with such an overlay :( I’ll have to try to figure it out again.
Would it be possible to instead keep the bottom ribbon the same size (thus not taking away from the waveform window and causing the above noted problem) and instead
either
Make the large colored channel numbers slightly smaller and move them up and put the 10x under the large channel number?
By the way, I considered this option for placing the divider, but abandoned it because for this the channel numbers would have to be significantly reduced, and I didn’t want that. But in general, you can try it and see what happens :)
or
Use the large black space to the right of the 4 channel boxes and put a table of 1,2,3,4 with the associated probe multiplier there??
No, this place is occupied by LA and AFG widgets in 9xx models .
Or even use the blank space at the top of the window next to Waveform View and put 1:10X, 2:1X, 3:1X, 4:10X
And here there is very little space when a second window opens, for example with FFT :)
or
find some other open space that the probe multiplier would fit without causing window realestate placement conflicts
Well, this is just the first attempt for now. If a more optimal option is found, of course we can redo it :)
It definately seems Rigol could have done a much better job of providing the user with more info (like the missing probe multiplier).
What I really wish is that when viewing the display through the web interface that MORE info could be made available on the external monitor and have a nice large waveform display.
Unfortunately this is not possible :(
-
I simply take the text from the existing list of divisors. I'll look for this list and try to change it. Decimal places do look weird, I agree.
In text (char array) its just to set null (\0) to make a flag of end of text. If we need to get rid of ".0" and that is always two chars, then probably easiest way will be to count everything up to null and after that put another null with two places to the left.
It definately seems Rigol could have done a much better job of providing the user with more info (like the missing probe multiplier).
What I really wish is that when viewing the display through the web interface that MORE info could be made available on the external monitor and have a nice large waveform display.
Unfortunately this is not possible :(
If displayed waveform is 100% generated in FPGA (with same resolution as we see right now) then scaling this up will create same pixels but bigger, like resizing existing image.
Anyway, HDMI is a separate display. When I put and run Linux (instead of Android) on sd card, then right now I have only HDMI output. Maybe this info will help with further hacking.
-
In text (char array) its just to set null (\0) to make a flag of end of text. If we need to get rid of ".0" and that is always two chars, then probably easiest way will be to count everything up to null and after that put another null with two places to the left.
Everything is easier here :) Here is a piece of code in which the texts needed to be changed:
new-instance v0, Lcom/rigol/scope/cil/ServiceEnum$ProbeX;
const-string v9, "Probe_10X"
const/16 v10, 0xf
const/16 v11, 0xf
const-string v12, "10"
const-string v13, ""
const-string v14, ""
move-object v8, v0
invoke-direct/range {v8 .. v14}, Lcom/rigol/scope/cil/ServiceEnum$ProbeX;-><init>(Ljava/lang/String;IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;)V
sput-object v0, Lcom/rigol/scope/cil/ServiceEnum$ProbeX;->Probe_10X:Lcom/rigol/scope/cil/ServiceEnum$ProbeX;
new-instance v0, Lcom/rigol/scope/cil/ServiceEnum$ProbeX;
const-string v2, "Probe_15X"
const/16 v3, 0x10
const/16 v4, 0x10
const-string v5, "15"
const-string v6, ""
const-string v7, ""
move-object v1, v0
invoke-direct/range {v1 .. v7}, Lcom/rigol/scope/cil/ServiceEnum$ProbeX;-><init>(Ljava/lang/String;IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;)V
sput-object v0, Lcom/rigol/scope/cil/ServiceEnum$ProbeX;->Probe_15X:Lcom/rigol/scope/cil/ServiceEnum$ProbeX;
new-instance v0, Lcom/rigol/scope/cil/ServiceEnum$ProbeX;
const-string v9, "Probe_20X"
const/16 v10, 0x11
const/16 v11, 0x11
const-string v12, "20"
const-string v13, ""
const-string v14, ""
move-object v8, v0
invoke-direct/range {v8 .. v14}, Lcom/rigol/scope/cil/ServiceEnum$ProbeX;-><init>(Ljava/lang/String;IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;)V
sput-object v0, Lcom/rigol/scope/cil/ServiceEnum$ProbeX;->Probe_20X:Lcom/rigol/scope/cil/ServiceEnum$ProbeX;
-
Everything is easier here :) Here is a piece of code in which the texts needed to be changed:
Thats completely unknown language for me. In my case its only C, some script languages and little bit of assembler. Maybe I will start to learn this after I run everything on this scope on Linux instead of Android and that will take some time, because I need not only working kernel but also source or only headers to compile other things. Maybe I will try to run original kernel (binary from Rigol) in the last resort.
-
If anyone wants to try, here is a link to the modified application - https://drive.google.com/file/d/1m7_UzTostQTJtiZSkwr4j9gKpi_M7fQ9/view?usp=sharing
Before installation, you need to uninstall the original application:
adb uninstall com.rigol.scopeThen install the new one:
adb install -r Sparrow.apkWithout special steps, the modified application does not have system permissions, so it cannot take screenshots from the Quick button or from the Drive menu. Screenshots can only be taken in web control.
If you need to return the original application, then in the same way, first uninstall the modified one and then install the original one back.
-
Thats completely unknown language for me.
Yes, I, too, was not familiar with this language and did not even suspect its existence :) Now I’m studying, I will know another language in addition to those in which I have already written.
-
If anyone wants to try, here is a link to the modified application - https://drive.google.com/file/d/1m7_UzTostQTJtiZSkwr4j9gKpi_M7fQ9/view?usp=sharing
Before installation, you need to uninstall the original application:
adb uninstall com.rigol.scopeThen install the new one:
adb install -r Sparrow.apkWithout special steps, the modified application does not have system permissions, so it cannot take screenshots from the Quick button or from the Drive menu. Screenshots can only be taken in web control.
If you need to return the original application, then in the same way, first uninstall the modified one and then install the original one back.
Unless You will use print screen on USB keyboard.
But tha... replacing all files on running scope (instead of using apk) won't do the trick?
-
But tha... replacing all files on running scope (instead of using apk) won't do the trick?
No, it won't help. The problem is the wrong key with which the application is signed. Only Rigol has the correct key :)
The only thing that will help is copying the files of the installed application in /system/priv-app/ to the folder created there for this application.
-
But tha... replacing all files on running scope (instead of using apk) won't do the trick?
No, it won't help. The problem is the wrong key with which the application is signed. Only Rigol has the correct key :)
The only thing that will help is copying the files of the installed application in /system/priv-app/ to the folder created there for this application.
Or maybe bind quick button to Android print-screen?
-
Or maybe bind quick button to Android print-screen?
It’s better to copy it to the system directory, and let it work with privileged rights, as intended by the developers :) I’ll need to write a script for this later and run it via adb shell after installation.
-
Or maybe bind quick button to Android print-screen?
It’s better to copy it to the system directory, and let it work with privileged rights, as intended by the developers :) I’ll need to write a script for this later and run it via adb shell after installation.
Now Im little confused. Maybe I miss something or its my lack of Android knowledge. Earlier You told uid 0 wont help as far I remember.
-
Or maybe bind quick button to Android print-screen?
It’s better to copy it to the system directory, and let it work with privileged rights, as intended by the developers :) I’ll need to write a script for this later and run it via adb shell after installation.
Now Im little confused. Maybe I miss something or its my lack of Android knowledge. Earlier You told uid 0 wont help as far I remember.
There are two ways to make an application privileged: 1 - run it as the user android.user.system (this is written in the application manifest during assembly), 2 - place it in the /system/priv-app directory.
The first method is standard, but it is not available to us, because... requires signing the application with a system key. And we can easily use the second one, thanks to Rigol, who left ADB open with root access :)
With the second method, the application is launched on behalf of an ordinary user, but the system still considers him privileged and gives access to those APIs that are inaccessible to a regular application.
-
@AndyBig, and all others here
Good news, I made your apk take screen shot from the button "Quick"
One sec while I gather up the docs for you. Super easy fix. Nice work on the edits btw.
********************************************
1sec later... ;)
My edits are via ssh, I left off using adb to push app back onto scope, I park it in /system/priv-app/Sparrow/ as 644 root:root , pm install that apk
You need to add a perm to AndroidManifest.xml
<uses-permission android:name="android.permission.ACCESS_SURFACE_FLINGER"/>
Recompile, align, sign, reinstall
The launcher should restart scope app in a few sec
Find the uid for com.rigol.scope (ps |grep scope), you'll use this new uid in your platform.xml edit (my example shows u0_a36, your uid might be different)
The pitfall here is, every re-install will get a new uid for the app. I started with u0_a35, my hack failed, I tried again, works. I can create bash script to awk sed the platform file after a app reinstall to make it less pita, etc.
mount -o rw,remount /system
vi /system/etc/permissions/platform.xml
copy-paste the below block in
save file
reboot
<assign-permission name="android.permission.READ_FRAME_BUFFER" uid="u0_a36" />
<assign-permission name="android.permission.CAPTURE_VIDEO_OUTPUT" uid="u0_a36" />
<assign-permission name="android.permission.CAPTURE_SECURE_VIDEO_OUTPUT" uid="u0_a36" />
<assign-permission name="android.permission.ACCESS_SURFACE_FLINGER" uid="u0_a36" />
<permission name="android.permission.READ_FRAME_BUFFER" >
<group gid="u0_a36" />
</permission>
<permission name="android.permission.CAPTURE_VIDEO_OUTPUT" >
<group gid="u0_a36" />
</permission>
<permission name="android.permission.CAPTURE_SECURE_VIDEO_OUTPUT" >
<group gid="u0_a36" />
</permission>
<permission name="android.permission.ACCESS_SURFACE_FLINGER" >
<group gid="u0_a36" />
</permission>
***********************************************
side note for readers, if you want to see what all the code is logging, from ssh just run "logcat /system/log", then touch a knob, or tap screen and see what coords you actually touched. When logcat is idle, you can hit enter a few times to make a space, then touch a scope control, everything is basically logged, which in my opinion we might want to turn off to take some load off the cpu side, not need to log all that stuff unless we trying to debug it.
And sorry I could not hack it as fast as AndyBig has, my dho has been in the box, I only get to play around with it in limited spare time, I actually reworking my little lab area.
-
Those system key, where we can find them?
We have full raw dump of sdcard.
I don't know about cryptography but how system verify signature only with public key?
-
Those system key, where we can find them?
We have full raw dump of sdcard.
I don't know about cryptography but how system verify signature only with public key?
I think Im no expert in cryptography, but when You generate private and public key, then private key You keep in a secret and its used only to sign other staff, including other keys. Public key is only to verify signed files, that's why its public.
-
Those system key, where we can find them?
We have full raw dump of sdcard.
I don't know about cryptography but how system verify signature only with public key?
x509 cert signing, that's how.
I will have to say, if verification process needs to run through memory (which it does), then as root you have a way to steal key data. Is it worth the effort? Not for this device.
-
Those system key, where we can find them?
We have full raw dump of sdcard.
I don't know about cryptography but how system verify signature only with public key?
x509 cert signing, that's how.
I will have to say, if verification process needs to run through memory (which it does), then as root you have a way to steal key data. Is it worth the effort? Not for this device.
The public/private key scheme works a little differently. In order to verify a signature with a private key, you only need to know the corresponding public key. This is from the field of asymmetric encryption, where encoding is done with one key from the pair, and decoding is done with the second key. Thus, the system does not need to store the private key, it only needs to know the public key. Therefore, trying to find the private key in the firmware is pointless, it simply isn’t there :)
-
@AndyBig, and all others here
Good news, I made your apk take screen shot from the button "Quick"
You need to add a perm to AndroidManifest.xml
...
Great, then there is another method for granting high privileges to an application :)
I think that the issue with different uids can be solved by specifying some specific user in the application manifest, but I have not tried this yet.
-
Today I wrote and tested scripts to automate the installation of a modified application and grant it privileged rights so that it could take screenshots :)
The archive contains the application itself, as well as two .bat files, a .sh script and a readme. If for some reason it is not possible to run .bat files, then the readme describes all the steps using adb commands to install the application, grant it privileged rights and return to the original application.
The spmod_inst.bat file is used for the initial installation of the modified application and for updating it.
The spmod_uninst.bat file is used to return to the original application after the modified one.
The sysmode.sh file is a script that is copied to the oscilloscope and executed there, it includes all the actions to escalate application privileges.
Archive link - https://drive.google.com/file/d/15znLDczPyQCcPbygPwo7iK6uTHG0mk7z/view?usp=sharing
-
Today I wrote and tested scripts to automate the installation of a modified application and grant it privileged rights so that it could take screenshots :)
The archive contains the application itself, as well as two .bat files, a .sh script and a readme. If for some reason it is not possible to run .bat files, then the readme describes all the steps using adb commands to install the application, grant it privileged rights and return to the original application.
The spmod_inst.bat file is used for the initial installation of the modified application and for updating it.
The spmod_uninst.bat file is used to return to the original application after the modified one.
The sysmode.sh file is a script that is copied to the oscilloscope and executed there, it includes all the actions to escalate application privileges.
Archive link - https://drive.google.com/file/d/15znLDczPyQCcPbygPwo7iK6uTHG0mk7z/view?usp=sharing
Check the other apps in priv-app, are they 644 and not 755? I forget, check it.
Also, that's a lot of scripting,
Take a look at managing user UID with pm.
Example,
before install add a uid using pm without restrictions
then install using pm and the -user switch
If that works a-ok, then you only need to echo into the platform.xml file once, and from there just re-use same uid during a re-intsall of the app.
I'll write up a .sh to install the app,................. uninstall app, create uid , echo into the xml, install app. But not until mon or tue next week. something like "install.sh [uid] [apk]"
creates the uid, install app, fixes platform.xml, it will also check to see if the install is first time or a reinstall.
@AndyBig, and all others here
Good news, I made your apk take screen shot from the button "Quick"
You need to add a perm to AndroidManifest.xml
...
Great, then there is another method for granting high privileges to an application :)
I think that the issue with different uids can be solved by specifying some specific user in the application manifest, but I have not tried this yet.
priv-app alone does not allow surface flinger for non-system uid. is there a fix just in manifest?
Also to note, we can do this perms thing only because it's an old version of droid, this feature has been deprecated, newer droid REQUIRES system uid to get at surface flinger.
Those system key, where we can find them?
We have full raw dump of sdcard.
I don't know about cryptography but how system verify signature only with public key?
x509 cert signing, that's how.
I will have to say, if verification process needs to run through memory (which it does), then as root you have a way to steal key data. Is it worth the effort? Not for this device.
The public/private key scheme works a little differently. In order to verify a signature with a private key, you only need to know the corresponding public key. This is from the field of asymmetric encryption, where encoding is done with one key from the pair, and decoding is done with the second key. Thus, the system does not need to store the private key, it only needs to know the public key. Therefore, trying to find the private key in the firmware is pointless, it simply isn’t there :)
That's not the point. The pub key is held in a trusted/protected area, just as they are when using keys auth for ssh, there's no priavte key on the system right, but it verifies only with a "trusted" pub key. The goal would be to find out how to add your pub key to the system keystore, and memory hacking is a way to do that. Once you can add your pub key to that protected keystore, then anything you sign with your private key will be trusted by the system.
-
Check the other apps in priv-app, are they 644 and not 755? I forget, check it.
644, but I decided that 755 would be more reliable :)))
I'll write up a .sh to install the app,................. uninstall app, create uid , echo into the xml, install app. But not until mon or tue next week. something like "install.sh [uid] [apk]"
creates the uid, install app, fixes platform.xml, it will also check to see if the install is first time or a reinstall.
Great!
priv-app alone does not allow surface flinger for non-system uid. is there a fix just in manifest?
Well, at least this allows the application to take screenshots :) I completely removed the indication of the user from the manifest.
Also to note, we can do this perms thing only because it's an old version of droid, this feature has been deprecated, newer droid REQUIRES system uid to get at surface flinger.
It's good that Rigol made an oscilloscope on an old version of Android :)
That's not the point. The pub key is held in a trusted/protected area, just as they are when using keys auth for ssh, there's no priavte key on the system right, but it verifies only with a "trusted" pub key. The goal would be to find out how to add your pub key to the system keystore, and memory hacking is a way to do that. Once you can add your pub key to that protected keystore, then anything you sign with your private key will be trusted by the system.
I'm not sure that Android allows you to have more than one key, which it uses to check applications for compliance with the system level. And if we replace the only key that is used for this, then there is a possibility that the system, when booting, checks itself with the same key (the kernel is signed with the same private key) and the check will not pass with the replaced key.
But I'm not an Android expert, I could be wrong. These are just my thoughts.
-
I think keystore is empty on scope.
There are few keystore executable in /System/bin
keystore, keystore_cli and keystore_cli_v2
keys seems to be dev so maybe ading more keys or debug or release could be accepted. Via keystore commands.
As an update to https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5355560/#msg5355560 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5355560/#msg5355560)
KRNL 0x2400000 kernel
KRNL 0x3C00000 ramdisk (can be extracted with 7zip)
KRNL 0x5C00000 recovery (can be extracted with 7zip)
-
Another drawback of the modified application was discovered - it is denied access to external storage, that is, to a USB flash drive. Because of this, the application gives an error when loading if the flash drive is plugged into USB. And you cannot save screenshots to a flash drive.
I looked at how the flash drive is mounted, the user root and group sdcard_rw are assigned to it.
[attachimg=1]
It seems that moving the application to /system/priv-app does not solve all the issues. This gives access to the API, but does not give access to resources. I think that a possible solution could be the method suggested by @Randy222 - editing the platform.xml file.
-
It seems that moving the application to /system/priv-app does not solve all the issues. This gives access to the API, but does not give access to resources. I think that a possible solution could be the method suggested by @Randy222 - editing the platform.xml file.
Try adding the user that the app runs under to the sdcard_rw group.
(not sure how it's even done on android)
-
Your RKey.data is also stored there and right after the individual options:
000001B0 13 09 00 00 | ED F6 FF FF | 04 00 00 00 | FC FF FF FF | 82 7F 61 DD | 70 08 00 03
000001C8 15 09 00 00 | EB F6 FF FF | 04 00 00 00 | FC FF FF FF | 14 4F 66 AA | 70 08 00 02First word identifies the option Type (0x913 == RLU) followed by the complement word followed by length (4) then complemented
then the CRC32 of the following 4 bytes. The last '03' means that 3 attempts have been made for the RLU option.
Look here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg5367605/#msg5367605).
BTW, is anyone able to provide me (via pm) a copy of his FRAM dump so that I can parse it (using my MSO5000 FRAM tool) for you to see?
-
Also to note, we can do this perms thing only because it's an old version of droid, this feature has been deprecated, newer droid REQUIRES system uid to get at surface flinger.
It's good that Rigol made an oscilloscope on an old version of Android :)
From UART of mine scope:
U-Boot 2014.10-RK3399-06-gb34072bb7d (Aug 23 2023 - 11:38:38)
[ 0.000000] Linux version 4.4.126 (adil@ubuntu) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05) ) #72 SMP PREEMPT Tue Jul 18 13:47:35 CST 2023
Looks like they used OrangePi old build scripts with same toolchains. I found this build and last couple days Im making my own based on that. I gave it a name: "Orange Rigol". It will be on my github, when it will be usable.
-
Greetings to all. Today I tried to fix the time zone by this way and got a broken scope with eternal logo :)
...
One issue I run into was that the timezone was being reset on each boot - sadly they force the timezone in the startup script:
adb shell
su -
cd /rigol/shell; cp start_rigol_app.sh start_rigol_app.sh.orig
sed -i 's?setprop persist.sys.timezone Asia/Shanghai?setprop persist.sys.timezone America/New_York?' start_rigol_app.sh
I entered the adb commands changing "America/New_York" to "Europe/Helsinki". Then I checked the contents of the script, the timezone has indeed changed. Then I turned off the device and it no longer boots:
https://youtu.be/ebFSV6VQNRM?si=QLLapAEXIMGRVYaN
At 36 sec a quiet click is heard and that’s it, no other activity. When I press and hold the power button device turns off normally. Now he has no means of communication. My PC does not respond to the scope connection either through the rear usb (usb device) or through the front one (I disabled the VBUS wire in the type A -> type A cable in advance so as not to have consequences due to some potential difference and possible through currents).
My router interface does not see the scope connected via LAN. If I connect it by rj45 cord directly to the PC, then a new network connection appears in Windows, the PC regularly sends packets, but does not receive any in response, zero. The LEDs near the lan connector of scope are active.
I haven't done anything with the SD card yet. I have a copy of the entire "rigol" directory, but do not have a full "factory" dump of my sd card.
Where do you recommend starting debugging? Buy a new 32GB sd card and try to mount other people’s images that were posted on this forum, including Dave's img? Or look for ways to get into native recovery to install TWRP, with which maybe can upload the native script or the entire full "rigol" directory back?
A few days earlier, out of curiosity, I reboot scope to its native recovery via adb, it looks like this:
[spoiler]
(https://i.postimg.cc/BZYzyVRB/IMG-20240228-112010.jpg) (https://postimg.cc/BtFNPMSj)
[/spoiler]
I won’t say that I’m in despair, but it’s somehow unpleasant. I hope experienced programmers will help me. Have a nice day!
-
Greetings to all. Today I tried to fix the time zone by this way and got a broken scope with eternal logo :)
This happened to me too!
I thought it was a random glitch, but apparently it wasn't, and it is reproducible. I edited the time zone in the boot script, replacing the original value with Europe/Kiev -- and I did verify in the command line that it indeed worked, meaning the TZ name was correct -- and on next reboot there was that eternal logo after a quiet click about halfway of the expected boot process.
It did boot eventually, however. I am not sure what exactly helped. I tried various things: connect or disconnect ethernet and wifi, wait several minutes or hours before the next attempt (maybe until morning, I don't remember), with the USB power cable disconnected. At some point it booted and it was able to connect to network, I don't remember if it was wired or wireless. It took some maybe 10-20 boot attempts in total.
Since changing the timezone to a non-factory one causes boot trouble, it means that the boot sequence is designed terribly wrong. I suspect that there are some decisions as to when various parts should be started that are made based on the text representation of current time -- and if it suddenly changes mid-boot, which is the case when you change the TZ, something is going to see an unexpected (e.g. negative) time difference and fail.
Now, worst case, you can always take the SD card out, back it up, and ideally put aside in a safe place, then get a new SD card (not necessarily 32 GB -- can be 64 GB or more), and write the backup image to it. Then, mount the file system (you need the /rigol partition), which you can do knowing the offset (man mount, search for "LOOP-DEVICE SUPPORT"; fs offsets were posted several pages earlier in this thread), and revert the changes you made to the boot script.
Once you get it back working again, make a fresh backup of the SD card and save it somewhere safe.
-
Actually since you are able to enter the bootloader and it offers you to mount /system, then, probably, if you can get a shell with a mounted /system, you can mount the /rigol partition from there and edit the boot script directly on the scope without removing the SD card.
-
I edited the time zone in the boot script, replacing the original value with Europe/Kiev
Im from Ukraine too, but wrote "Helsinki" in script because I didn't know how to write correctly (for Android system) "Kiev" or "Kyiv" 😂
Thanks for your answers, shapirus!
-
I have installed https://4pda.to/forum/index.php?showtopic=798101 fore timezone.
-
Since changing the timezone to a non-factory one causes boot trouble, it means that the boot sequence is designed terribly wrong.
Changing the time zone in the start_rigol_app.sh script did not cause any failures. After the change, the oscilloscope booted up as usual.
Actually since you are able to enter the bootloader and it offers you to mount /system, then, probably, if you can get a shell with a mounted /system, you can mount the /rigol partition from there and edit the boot script directly on the scope without removing the SD card.
There are no problems entering this recovery, this is done by the adb command. But to move between items here you need to press the “Volume+” and “Volume-” buttons, but they are not on the oscilloscope :)
-
Finally my build from scratch is working on this scope :-BROKE Few things left to enter alpha stage.
-
I edited the time zone in the boot script, replacing the original value with Europe/Kiev
Im from Ukraine too, but wrote "Helsinki" in script because I didn't know how to write correctly (for Android system) "Kiev" or "Kyiv" 😂
Thanks for your answers, shapirus!
https://gist.github.com/arpit/1035596 (https://gist.github.com/arpit/1035596)
Europe/Kiev
-
Finally my build from scratch is working on this scope :-BROKE Few things left to enter alpha stage.
Cool! Do you have accelerated video implemented yet? Historically, it has been a challenge for RK3399 based SBCs running Linux. I'm pretty sure it's important since this is a visual device, and is probably one of the biggest reasons Rigol's team chose Android for the RK3399 based products.
Keep up the work. Looking forward to your progress.
-
There are no problems entering this recovery, this is done by the adb command. But to move between items here you need to press the “Volume+” and “Volume-” buttons, but they are not on the oscilloscope :)
I definitely remember that stock recovery worked with the physical keyboard, like with tvboxes.
Now, after resuscitation using Dave's .img, recovery does not load. It tries to boot, and once every 22 seconds the following information appears on the screen for a moment:
(https://i.postimg.cc/fT1qMvsV/ezgif-com-crop.gif) (https://postimages.org/)
(https://i.postimg.cc/V6QDGgRP/IMG-20240305-222425.jpg) (https://postimages.org/)
(https://i.postimg.cc/Y968JFnG/IMG-20240305-222524.jpg) (https://postimages.org/)
But it doesn't load. This doesn't bother me much, but I would like to have a backup recovery option via usb adb instead of disassembling and installing a spare sd card.
I updated old fw of Dave's image to 1.02, and while I didn’t return the 802 model with Zelea2's tool. Just for fun, I’m testing the 814. I did a simple calibration (not an advanced calibration), the offsets disappeared on the first and second channels. On the fourth channel (ext trig in the original) there are still offsets, including a constant ADC's offset that does not depend on the set input sensitivity V/div value. I think this is explained by the different configuration of these resistors in 802/804 and 814/804:
(https://i.postimg.cc/0yzn9FXq/IMG-20240306-021633.jpg) (https://postimg.cc/RWzKRszP)
(https://i.postimg.cc/Nffbz51F/IMG-20240306-021717.jpg) (https://postimg.cc/nMgvsVSf)
I will continue my research when I have more free time.
-
There are no problems entering this recovery, this is done by the adb command. But to move between items here you need to press the “Volume+” and “Volume-” buttons, but they are not on the oscilloscope :)
I definitely remember that stock recovery worked with the physical keyboard, like with tvboxes.
Now, after resuscitation using Dave's .img, recovery does not load. It tries to boot, and once every 22 seconds the following information appears on the screen for a moment:
(https://i.postimg.cc/fT1qMvsV/ezgif-com-crop.gif) (https://postimages.org/)
(https://i.postimg.cc/V6QDGgRP/IMG-20240305-222425.jpg) (https://postimages.org/)
(https://i.postimg.cc/Y968JFnG/IMG-20240305-222524.jpg) (https://postimages.org/)
But it doesn't load. This doesn't bother me much, but I would like to have a backup recovery option via usb adb instead of disassembling and installing a spare sd card.
I updated ol fw of Dave's image to 1.02, and while I didn’t return the 802 model witht Zelea's tool. Just for fun, I’m testing the 814. I did a simple calibration (not an advanced calibration), the offsets disappeared on the first and second channels. On the fourth channel (ext trig in the original) there are still offsets, including a constant ADC's offset that does not depend on the set input sensitivity V/div value. I think this is explained by the different configuration of these resistors in 802/804 and 814/804:
(https://i.postimg.cc/0yzn9FXq/IMG-20240306-021633.jpg) (https://postimg.cc/RWzKRszP)
(https://i.postimg.cc/Nffbz51F/IMG-20240306-021717.jpg) (https://postimg.cc/nMgvsVSf)
I will continue my research when I have more free time.
Pretty useful info. Someday we will make a rocket based on this scope :)
Anyway, I have image of 924S. I can upload it somewhere if You need it (before that, I need to delete some non-free files from it - not relevant to scope).
-
Now, after resuscitation using Dave's .img, recovery does not load. It tries to boot, and once every 22 seconds the following information appears on the screen for a moment:
Check UART output. I can't read this blurry text.
-
BTW I Just found this (decompiled from SD card):
i2c@ff160000 {
compatible = "rockchip,rk3399-i2c";
reg = <0x0 0xff160000 0x0 0x1000>;
clocks = <0x8 0x46 0x8 0x15a>;
clock-names = "i2c", "pclk";
interrupts = <0x0 0x24 0x4 0x0>;
pinctrl-names = "default";
pinctrl-0 = <0x3e>;
#address-cells = <0x1>;
#size-cells = <0x0>;
status = "okay";
clock-frequency = <0x61a80>;
rtc@32 {
compatible = "rockchip,rtc-rx8010sj";
reg = <0x32>;
interrupt-parent = <0x3f>;
interrupts = <0x3 0x8>;
status = "okay";
};
};
I think that was copied from DHO1000 or DHO4000.
Anyway, it will be also in my build if somebody wants to add this RTC.
-
I can't read this blurry text.
The text is clearly visible in the second and third images. These are stills (frames) from the video. Same as on blurred gif (1st image).
Anyway, I have image of 924S. I can upload it somewhere if You need it (before that, I need to delete some non-free files from it - not relevant to scope).
Thank you! I will definitely contact you when I find time to experiment with 924S img on my 802.
-
I can't read this blurry text.
The text is clearly visible in the second and third images. These are stills (frames) from the video. Same as on blurred gif (1st image).
From UART in mine 924S:
[ 0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 coherent_pool=1m cma=257M androidboot.baseband=N/A androidboot.selinux=disabled androidboot.hardware=rk30board androidboot.console=ttyFIQ0 init=/init mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00002000@0x00004000(trust),0x00002000@0x00006000(misc),0x00008000@0x00008000(resource),0x0000C000@0x00010000(kernel),0x00010000@0x0001C000(boot),0x00020000@0x0002C000(recovery),0x00038000@0x0004C000(backup),0x00040000@0x00084000(cache),0x00400000@0x000C4000(system),0x00008000@0x004C4000(metadata),0x00000040@0x004CC000(verity_mode),0x00002000@0x004CC040(baseparamer),0x00000400@0x004CE040(frp),0x000FA000@0x004CE440(rigol),-@0x00600000(userdata) storagemedia=sd androidboot.oem_unlocked=0 uboot_logo=0x02000000@0xf5c00000 loader.timestamp=2023-08-23_11:38:38 SecureBootCheckOk=0
So i suggest to check this filesystems by using almost any Linux computer.
rknand can be googled.
-
Thank you! I will definitely contact you when I find time to experiment with 924S img on my 802.
I think it should be identical apart from the vendor.bin file.
-
Anyway, I have image of 924S. I can upload it somewhere if You need it (before that, I need to delete some non-free files from it - not relevant to scope).
I'm interested too, just to compare with 800 series.
Partitions on sdcard are offset by 0x400000
Real addresses on sdcard are
uboot: 0x000800000 -- 0x000C00000 (4 MB)
trust: 0x000C00000 -- 0x001000000 (4 MB)
misc: 0x001000000 -- 0x001400000 (4 MB)
resource: 0x001400000 -- 0x002400000 (16 MB)
kernel: 0x002400000 -- 0x003C00000 (24 MB)
boot: 0x003C00000 -- 0x005C00000 (32 MB)
recovery: 0x005C00000 -- 0x009C00000 (64 MB)
backup: 0x009C00000 -- 0x010C00000 (112 MB)
cache: 0x010C00000 -- 0x018C00000 (128 MB)
system: 0x018C00000 -- 0x098C00000 (2048 MB)
metadata: 0x098C00000 -- 0x099C00000 (16 MB)
verity_mode: 0x099C00000 -- 0x099C08000 (0 MB)
baseparamer: 0x099C08000 -- 0x09A008000 (4 MB)
frp: 0x09A008000 -- 0x09A088000 (0 MB)
rigol: 0x09A088000 -- 0x0B9488000 (500 MB)
userdata: 0x0C0400000 -- 0x7629FFFFF (27174 MB) ?
-
I definitely remember that stock recovery worked with the physical keyboard, like with tvboxes.
Is that only for wired kybds, or wireless too? I haven't found any good info for button-less navigation in recovery., so please share when you find something.
I would like to have a backup recovery option via usb adb instead of disassembling and installing a spare sd card.
I don't know about your country/vendor, but I've heard that several countries have barred companies from voiding warranties based on peeling the stupid sticker they use. I.e., they supposedly can't refuse service(based on a fragile sticker). Check the main forums here; Dave was involved in a conversation, and he even made a YT video on how to peel it up safely.(warning; make sure it's warm)
Oh, and it's only a $300US product. How much will it cost to send it for service??
FYI: I'm booting mine from a 64GB card with a spare DD img on my Ubuntu box, and the original SDCard safely stored.
I updated old fw of Dave's image to 1.02, and while I didn’t return the 802 model with Zelea2's tool. Just for fun, I’m testing the 814. I did a simple calibration (not an advanced calibration), the offsets disappeared on the first and second channels. On the fourth channel (ext trig in the original) there are still offsets, including a constant ADC's offset that does not depend on the set input sensitivity V/div value. I think this is explained by the different configuration of these resistors in 802/804 and 814/804:
I will continue my research when I have more free time.
That's interesting. I was wondering if anyone put a 814 model number on their 802 scope to make a 3ch scope. Good to know! Thanks for sharing the pic of the DHO802 Ext/Ch4 AFE. FYI: once you enable the testmodel option, you might be able to play with your 4th ch offsets YMMV, standard disclaimers apply. ;)
-
I'm interested too, just to compare with 800 series.
Partitions on sdcard are offset by 0x400000
16! That is the most partitions i've seen so far. There have been a few people reporting partitions/offsets since the first bunch of scopes hit the mainstream in September, and I'm trying to keep track of them all.. BTW: What are you using to view, Testdisk?
Thanks!
-
You can't view them.
There is no partitions record.
I see how partition was extracted with some script (sorry can't remember who make it)
Then what addresses are passed to kernel and see that is an offset for what we know from script and that.
My scope is still on pieces.
If anyone can check with mount command if there are more.
It may be that at runtime others to be "mounted" but they are more or less just empty.
It may be possible to build partition table and Android doesn't upset.
-
That's interesting. I was wondering if anyone put a 814 model number on their 802 scope to make a 3ch scope. Good to know! Thanks for sharing the pic of the DHO802 Ext/Ch4 AFE. FYI: once you enable the testmodel option, you might be able to play with your 4th ch offsets YMMV, standard disclaimers apply. ;)
There was such an attempt. According to a post from someone who was trying to make a 924 out of his 812 by changing the model name in vendor.bin, the CH4 channel appeared and displayed a trace, but it was impossible to set a trigger on it.
Here is his explanation:
Made 812 into 924. The 4th channel is there (blue) but is not synchronized, the trigger does not work. I turn on the control of the CH4 trigger and the “T” cursor does not move, “SINGLE” also does not work.
When analyzing the situation, two places were found on the oscilloscope board that can determine the HW version and thus determine the behavior of the oscilloscope program. These are resistors near the input front end of channel 4, and resistors on the bottom side of the board in the processor area.
-
You can't view them.
There is no partitions record.
I see how partition was extracted with some script (sorry can't remember who make it)
Then what addresses are passed to kernel and see that is an offset for what we know from script and that.
My scope is still on pieces.
If anyone can check with mount command if there are more.
It may be that at runtime others to be "mounted" but they are more or less just empty.
It may be possible to build partition table and Android doesn't upset.
You can mount them directly from a image or extract them to separate files via dd. Default block size in dd is 512 bytes and testdisk display offsets and sizes also with same block size - so You can do copy paste.
When analyzing the situation, two places were found on the oscilloscope board that can determine the HW version and thus determine the behavior of the oscilloscope program. These are resistors near the input front end of channel 4, and resistors on the bottom side of the board in the processor area.
Somebody did a measurement of its values?
Anyway, if somebody wants to make a some play with buttons...
rockchip-key {
compatible = "rockchip,key";
status = "okay";
io-channels = <0xc7 0x1>;
vol-up-key {
linux,code = <0x73>;
label = "volume up";
rockchip,adc_value = <0x1>;
};
vol-down-key {
linux,code = <0x72>;
label = "volume down";
rockchip,adc_value = <0xaa>;
};
power-key {
gpios = <0xc8 0x5 0x1>;
linux,code = <0x74>;
label = "power";
gpio-key,wakeup;
};
menu-key {
linux,code = <0x3b>;
label = "menu";
rockchip,adc_value = <0x2ea>;
};
home-key {
linux,code = <0x66>;
label = "home";
rockchip,adc_value = <0x163>;
};
back-key {
linux,code = <0x9e>;
label = "back";
rockchip,adc_value = <0x230>;
};
camera-key {
linux,code = <0xd4>;
label = "camera";
rockchip,adc_value = <0x1c2>;
};
};
-
That's interesting. I was wondering if anyone put a 814 model number on their 802 scope to make a 3ch scope. Good to know! Thanks for sharing the pic of the DHO802 Ext/Ch4 AFE. FYI: once you enable the testmodel option, you might be able to play with your 4th ch offsets YMMV, standard disclaimers apply. ;)
There was such an attempt. According to a post from someone who was trying to make a 924 out of his 812 by changing the model name in vendor.bin, the CH4 channel appeared and displayed a trace, but it was impossible to set a trigger on it.
Here is his explanation:
Made 812 into 924. The 4th channel is there (blue) but is not synchronized, the trigger does not work. I turn on the control of the CH4 trigger and the “T” cursor does not move, “SINGLE” also does not work.
When analyzing the situation, two places were found on the oscilloscope board that can determine the HW version and thus determine the behavior of the oscilloscope program. These are resistors near the input front end of channel 4, and resistors on the bottom side of the board in the processor area.
Thanks for the recap and the additional info.. I gathered that the stuff options were how they set the AFE config from Tor's post yesterday.
Do you have a link to that 812 -> 924 post? Maybe I'm not looking at the right thread.
-
Do you have a link to that 812 -> 924 post? Maybe I'm not looking at the right thread.
This was discussed on another forum, starting with this post - https://4pda.to/forum/index.php?showtopic=1080959&view=findpost&p=128706710 :)
-
Somebody did a measurement of its values?
As far as I know - no. At least I haven’t seen information about this :) I think that in the processor area these are just jumpers, zero resistance. They set the HW version, it seems to me. Just binary code.
-
You can't view them.
There is no partitions record.
I see how partition was extracted with some script (sorry can't remember who make it)
Then what addresses are passed to kernel and see that is an offset for what we know from script and that.
My scope is still on pieces.
If anyone can check with mount command if there are more.
It may be that at runtime others to be "mounted" but they are more or less just empty.
It may be possible to build partition table and Android doesn't upset.
Thanks. I've been viewing & editing using Testdisk under Linux Ubuntu, but I could only see 15 partitions on my card. It's a copy of my original, so maybe I miscounted, or didn't see an un-allocated "partition".
-
I lost incredible amount of time to modify kernel 5.x to make it work. But that made me possible for me to make 4.4.179 fully working as it should.
HDMI now works as a separate screen. Of course it can work as a mirror.
[attach=1]
[attach=2]
-
I lost incredible amount of time to modify kernel 5.x to make it work. But that made me possible for me to make 4.4.179 fully working as it should.
HDMI now works as a separate screen. Of course it can work as a mirror.
Good job! :-+ Please clarify: Does HDMI only work as a mirror, or also as an extended workspace display?
Curious: How is CPU usage and thermal performance?
Oh, and does it play Tux Racer? :-DD
-
Another drawback of the modified application was discovered - it is denied access to external storage, that is, to a USB flash drive. Because of this, the application gives an error when loading if the flash drive is plugged into USB. And you cannot save screenshots to a flash drive.
I looked at how the flash drive is mounted, the user root and group sdcard_rw are assigned to it.
It seems that moving the application to /system/priv-app does not solve all the issues. This gives access to the API, but does not give access to resources. I think that a possible solution could be the method suggested by @Randy222 - editing the platform.xml file.
@AndyBig; Have you tried replacing the sparrow.apk in an update.GEL with your modified one, and apply it like a standard "update"? I'm wondering if the system might not reject the modified app if applied like this vs. ADB install method.
-
@AndyBig; Have you tried replacing the sparrow.apk in an update.GEL with your modified one, and apply it like a standard "update"? I'm wondering if the system might not reject the modified app if applied like this vs. ADB install method.
No, I haven’t tried it, but there’s no point in it - the application from the update is installed with the same pm install command, so the result will be the same.
-
A few of updates for the crowd:
1) I was able to script up two scripts, one to handle re-install of mod'd Sparrow APK, and another that will mod the platform.xml permissions using your template file. Scripts run well with checks, backups, and menus. I tested everything multiple times, but I need to do a final test before sharing it here.
2) After testing scripts work I went onto looking at how pm installs (reinstalls) APK's. Something went south while I was poking around. At first it would reboot until scope app started, would get a pid, and then it would die, and then retry that over and over. I could still get in via shh and use adb. But after poking around more on that issue, it now only reboots to a Rigol logo without Eth0 starting, so I suspect it's hung somewhere, possibly a corrupt sdcard, not sure yet.
3) I went in under the cover to get some measurements for my fans, and to investigate board under heatsink (AndyBig posted about a solder blob). I looked around using macro camera and did not find any solder issues, but I did find some crud that was kinda a flaky off-white residue all around all of the BNC input areas. I suspect dried washing solution, but that can't be too good for impedance. See attached pics. I used some rubbing alcohol on one of my SLR lens brushes to clean the input areas well, and then blown dry with bellows.
4) I am not big fan of thermal pads, so I added a ball of my heatsink paste above and below each pad. And not to worry, each ball is size properly for the size of the chip, there will be no leaking over the edges.
5) Two of the heatsink screws were not tight at all. They all went back in using some lightweight threadlocker.
Onto questions:
I took sdcard to my linux system, it will recoginze 16 disk slices as /dev block devices, but they will not mount and fdisk won't show anything. I never checked, but is the sdcard encrypted? Is anyone successfully mounting the slices on sdcard, and if so how are you doing that?
-
I lost incredible amount of time to modify kernel 5.x to make it work. But that made me possible for me to make 4.4.179 fully working as it should.
HDMI now works as a separate screen. Of course it can work as a mirror.
Are you planning to port out all the Android stuff to native Linux OS? This would seem like a big to-do.
Another option is to compile Qemu for your dho linux, and then just run the whole dho android in that emulator. But I am not sure what the benefits would be because all the Rigol stuff would need to run through a vm layer to get to hardware, and vice-versa.
-
A few of updates for the crowd:
3)a flaky off-white residue all around all of the BNC input areas. I suspect dried washing solution, but that can't be too good for impedance.
Probably solder flux residue. Happens with hand soldered thru-hole parts when they don't spot clean the area after assembly. Even using "no-clean" flux.
4) I am not big fan of thermal pads, so I added a ball of my heatsink paste above and below each pad. And not to worry, each ball is size properly for the size of the chip, there will be no leaking over the edges.
You essentially ADDED additional thermal impedance by adding a layer of compound with the pad. May help, may hinder. YMMV
5) Two of the heatsink screws were not tight at all. They all went back in using some lightweight threadlocker.
Threadlocker? You're never going back in? Well, clearly they didn't torque the screws during assembly. Shame. :palm:
Onto questions:
I took sdcard to my linux system, it will recoginze 16 disk slices as /dev block devices, but they will not mount and fdisk won't show anything. I never checked, but is the sdcard encrypted? Is anyone successfully mounting the slices on sdcard, and if so how are you doing that?
SDCard is not encrypted. I've had good luck using "testdisk" on Ubuntu. People talk about mounting using loopback, which I haven't tried.
FYI: Here are a couple links from searching for "partition" (just the highlights)
Sept:
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008)
More:
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046892/#msg5046892 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046892/#msg5046892)
Dec:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5240010/?topicseen#msg5240010 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5240010/?topicseen#msg5240010)
My post about SDCard partitions:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5356541/?topicseen#msg5356541 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5356541/?topicseen#msg5356541)
Most recent, from 3 days ago:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5374955/#msg5374955 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5374955/#msg5374955)
-
A few of updates for the crowd:
3)a flaky off-white residue all around all of the BNC input areas. I suspect dried washing solution, but that can't be too good for impedance.
Probably solder flux residue. Happens with hand soldered thru-hole parts when they don't spot clean the area after assembly. Even using "no-clean" flux.
4) I am not big fan of thermal pads, so I added a ball of my heatsink paste above and below each pad. And not to worry, each ball is size properly for the size of the chip, there will be no leaking over the edges.
You essentially ADDED additional thermal impedance by adding a layer of compound with the pad. May help, may hinder. YMMV
5) Two of the heatsink screws were not tight at all. They all went back in using some lightweight threadlocker.
Threadlocker? You're never going back in? Well, clearly they didn't torque the screws during assembly. Shame. :palm:
Onto questions:
I took sdcard to my linux system, it will recoginze 16 disk slices as /dev block devices, but they will not mount and fdisk won't show anything. I never checked, but is the sdcard encrypted? Is anyone successfully mounting the slices on sdcard, and if so how are you doing that?
SDCard is not encrypted. I've had good luck using "testdisk" on Ubuntu. People talk about mounting using loopback, which I haven't tried.
FYI: Here are a couple links from searching for "partition" (just the highlights)
Sept:
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008)
More:
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046892/#msg5046892 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046892/#msg5046892)
Dec:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5240010/?topicseen#msg5240010 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5240010/?topicseen#msg5240010)
My post about SDCard partitions:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5356541/?topicseen#msg5356541 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5356541/?topicseen#msg5356541)
Most recent, from 3 days ago:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5374955/#msg5374955 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5374955/#msg5374955)
The solder job on the BNC connector pins looks really good, but the area right around the pins look really clean, and I doubt they brush or use liquid flux, probably just pop in the connector and solder. So I guessing it's from the solder. Also a bit odd it's in a crescent shape around the 3 pins. Whatever it was, it's gone now, for the better.
Adding thermal paste, good stuff, can help more heat move through. There's no way to remove the pads, the heatsink is not precision machined and it spans 7 chips.
The threadlocker is weak stuff for small screws, they break lose easily with a driver. I not sure if the loose screws undid themselves or not, but the screw material is not the same as the insert, so maybe (maybe) thermal expansion creep.
I'll checkout the links for mounting this card.
-
I'm having trouble getting RigolTool working. :-\
But If I start the app, the initial screen appears, then shuts down after 2 seconds.
I tried running as admin...
I am using Windows 10.
I'm using adb commands, but its a pain.
i'm experiencing the same issue. but last time it was working i can view and download some files with ease, i think i updated Windows 10 with something that made its not working. any new version of RigolTool?
ref: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5132049/#msg5132049 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5132049/#msg5132049)
-
The solder job on the BNC connector pins looks really good, but the area right around the pins look really clean, and I doubt they brush or use liquid flux, probably just pop in the connector and solder. So I guessing it's from the solder. Also a bit odd it's in a crescent shape around the 3 pins. Whatever it was, it's gone now, for the better.
Here's something funny: This pic from HubertYoung's teardown (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg4976278/#msg4976278) last July, even has flux on the BNC connector
[attach=1]
@Randy222
So, did your thermal mods lower your scope temperatures?
-
I'm having trouble getting RigolTool working. :-\
But If I start the app, the initial screen appears, then shuts down after 2 seconds.
I tried running as admin...
I am using Windows 10.
I'm using adb commands, but its a pain.
i'm experiencing the same issue. but last time it was working i can view and download some files with ease, i think i updated Windows 10 with something that made its not working. any new version of RigolTool?
ref: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/175/ (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/175/)
RigolTool? I think most people have moved on to the Vendor Bin tool by @zelea2 (https://github.com/zelea2/rigol_vendor_bin) for upgrading their scope.
BTW: the link that you posted doesn't seem to point to any specific problem.
-
I never checked, but is the sdcard encrypted? Is anyone successfully mounting the slices on sdcard, and if so how are you doing that?
Its not encrypted. At the beginning there is no GPT table but only bootloader (U-boot). Kernel and file systems are little bit later and Linux kernel takes MTD offsets, sizes and names of those filesystems from cmd boot args. That is visible from early kernel messages to uart:
[ 0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 coherent_pool=1m cma=257M androidboot.baseband=N/A androidboot.selinux=disabled androidboot.hardware=rk30board androidboot.console=ttyFIQ0 init=/init mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00002000@0x00004000(trust),0x00002000@0x00006000(misc),0x00008000@0x00008000(resource),0x0000C000@0x00010000(kernel),0x00010000@0x0001C000(boot),0x00020000@0x0002C000(recovery),0x00038000@0x0004C000(backup),0x00040000@0x00084000(cache),0x00400000@0x000C4000(system),0x00008000@0x004C4000(metadata),0x00000040@0x004CC000(verity_mode),0x00002000@0x004CC040(baseparamer),0x00000400@0x004CE040(frp),0x000FA000@0x004CE440(rigol),-@0x00600000(userdata) storagemedia=sd androidboot.oem_unlocked=0 uboot_logo=0x02000000@0xf5c00000 loader.timestamp=2023-08-23_11:38:38 SecureBootCheckOk=0
If You have binary image file of sdcard, then You can examine it with some software like testdisk or binwalk. Testdisk gives offsets and sizes in 512 B. blocks, so eventually You need to multiply those values with this number.
You can extract those FS with dd to another file or mount them directly:
mount -t ext4 sdcard_dho924s.bin /some/empty/directory -o offset=3225419776,sizelimit=28494004224
Its easier to mount them from separate files or You can make scripts or just put it into fstab.
BTW. Some time ago... Two people asked for 924S SD card image, so here it is: 924S SD image (http://elektrykplakal.pl/something/sdcard_dho924s.bin.tar.xz). User: dho924s. Password is the same.
Are you planning to port out all the Android stuff to native Linux OS? This would seem like a big to-do.
Another option is to compile Qemu for your dho linux, and then just run the whole dho android in that emulator. But I am not sure what the benefits would be because all the Rigol stuff would need to run through a vm layer to get to hardware, and vice-versa.
Qemu is not any system emulator or API layer. Its just for other CPU architectures emulation. What is the point to emulate ARM64 inside ARM64?
There is something like Wine, but for Android apps. Exactly "anbox". If this works as a Linux container, then it will work almost like a on Android - maybe 1% slower. Currently Im using couple Linux containers for many years - this even can work on KVM and XEN without losing efficiency. So most probably there is no need to run another system as a guest in any way. If anbox will fail, then I will try to make real Android inside container without anbox.
Beside of Rigol app, running Linux on this scope gives opportunity to run other scope software - both for Linux and for Android. Maybe me or somebody else will find a way to get data from FPGA to give it to another existing app in real time. But now Im going to make stable system and some changes in build scripts - after that, I will make a new github repo with it and next step will be to run this app. BTW some of communication and managing FPGA is done via kernel modules compiled by Rigol - and that gives some very nice opportunities - even without decompiling it.
Right now everything works very stable with one small exception - Xorg sometimes crashes because of problems with one library - probably because of old kernel. Currently Im investigating it - I like very short error messages which tells almost nothing. I dont want to use original kernel from Rigol, but maybe I will.
BTW. Currently staff like mp4 decoding or OpenGL works like it should. Here is a little proof:
https://www.youtube.com/watch?v=ca_y4zmKaQc (https://www.youtube.com/watch?v=ca_y4zmKaQc)
I am using Windows 10.
I'm using adb commands, but its a pain.
I didnt have any problems with adb on Debian 11 and Debian 12. Im not using Windows since XP SP2 beacuse it was always pain in the ass - especially one bug which caused to destroy all file systems on all connected disks (not only in my case)... One of my machines currently has uptime of 280 days - only one problem was temporary no free space on disk because of lack of system monitoring software (lazy me).
-
S2084, I watched your one-hour video on YT about DIY upgraded cooling system of your DHO. You did a good job! Moreover, the writings is much more readable now, after changing the system Android fonts. Though "AUTO" now is splitted in two lines and "D" (LA tab), "G" (AFG tab) letters now are cut down below and "M" (Math windows tab) letter is shifted down a little.
How do you think, do users of these DHO really need to look at two zeroes after decimal point for vertical scale ranges in V/ (in channel tabs)? Maybe, respected AndyBig will remove them in his modded Sparrow.apk (as he did it for added by him divider ratios) if he'd like?
Because, as I think, the probe's divider ratios visible on CH tabs is must have, but when it is done for the price of font's size — it's pity.
Either do users need the dot waveform mode as an alternative to the vector waveform mode in these DHOs — and will Rigol ever implement (or, should I say, unlock) it?
BTW, did you already try to use LA probe on your hacked (either in HW and SW) DHO? Did you change the places where the jumpers are soldered on the other side of the main PCB under the Rockchip SoC/MCU to change the actual HW version marker?
-
I'm having trouble getting RigolTool working. :-\
But If I start the app, the initial screen appears, then shuts down after 2 seconds.
I tried running as admin...
I am using Windows 10.
I'm using adb commands, but its a pain.
i'm experiencing the same issue. but last time it was working i can view and download some files with ease, i think i updated Windows 10 with something that made its not working. any new version of RigolTool?
ref: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/175/ (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/175/)
RigolTool? I think most people have moved on to the Vendor Bin tool by @zelea2 (https://github.com/zelea2/rigol_vendor_bin) for upgrading their scope.
BTW: the link that you posted doesn't seem to point to any specific problem.
zelea tool is for upgrading and editing vendor bin, rigoltool is a gui tool, like windows (linux/android) file explorer i can see file structure and directory much quickly. adb is like command prompts, difficult to navigate large amount of files.. RigolTool automate that.. i used this tool last time to map similarities and differences between dho800 and dho900 firmware (file structure). thats my post in the link earlier, i link again for my own reference (sorry i just noticed i linked to the wrong page, thats not what i intended to link... now its corrected thanks)
ps: i want to see again FW differences since my upgrade path (dho804 fw v1.0.0 -> dho924s hacked fw v1.2.2) created bugs thats not exist in legit path (dho924s fw 1.14 -> dho924s fw 1.2.2) as in earlier link, there are files in dho924s dont exist in dho804 such as ...
files in DHO924 dont exist in DHO804:
\data\cal_ext.hex
\FPGA\SPU_H12S1.bit
this is raised due to my report and howardlong's reply:
https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5379389/#msg5379389 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5379389/#msg5379389)
https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5380205/#msg5380205 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5380205/#msg5380205)
https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5380262/#msg5380262 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5380262/#msg5380262)
-
How do you think, do users of these DHO really need to look at two zeroes after decimal point for vertical scale ranges in V/ (in channel tabs)? Maybe, respected AndyBig will remove them in his modded Sparrow.apk (as he did it for added by him divider ratios) if he'd like?
Are you talking about these values that are yellow and white? I think numbers after the decimal point are still needed :)
[attachimg=1]
-
ps: i want to see again FW differences since my upgrade path (dho804 fw v1.0.0 -> dho924s hacked fw v1.2.2) created bugs thats not exist in legit path (dho924s fw 1.14 -> dho924s fw 1.2.2) as in earlier link, there are files in dho924s dont exist in dho804 such as ...
Were you able to use RigolTool since the license key change in early January? key.data is now rKey.data, and there are some cal differences since then., IIRC.
BTW: The newest RigolTool version I have is 1.0.2 if you need it.
-
BTW: The newest RigolTool version I have is 1.0.2 if you need it.
yes i need it, can you provide the link..? thanks
-
BTW: The newest RigolTool version I have is 1.0.2 if you need it.
yes i need it, can you provide the link..? thanks
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077957/#msg5077957 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077957/#msg5077957)
-
BTW: The newest RigolTool version I have is 1.0.2 if you need it.
yes i need it, can you provide the link..? thanks
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077957/#msg5077957 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5077957/#msg5077957)
this is the one i'm running and quit disgracefully. i will try to pm him thanks. i just forgot who made it.
-
this is assuming it is correct infos there (about the gpl license, and it being intree). that this is not been honestly mistaken. and it assumes rigol respects the terms of the linux kernel, and the terms of the gpl license?
Correct. And I would say they will send you the code.
They sent all the GPL code for the MSO5000 to @Olliver. And he has it on his Github page...
Maybe Im little dumb, but I cant find it on Github, Gitlab and nowhere else. Anybody has a link or know where I should look?
-
How do you think, do users of these DHO really need to look at two zeroes after decimal point for vertical scale ranges in V/ (in channel tabs)? Maybe, respected AndyBig will remove them in his modded Sparrow.apk (as he did it for added by him divider ratios) if he'd like?
Are you talking about these values that are yellow and white? I think numbers after the decimal point are still needed :)
(Attachment Link)
Well, I think, it depends. Even for 12bit digital scope the reading "500.00uV/" has no physical sense. This is not a bench 8-digits voltmeter but a graticule scale. Zeroes are very round and nifty though.
But you are right if we talk about fine vertical scale adjustment. Up to 3..4 significant decimal digits are legit.
-
@antiquant I’m very glad that you liked my solution for upgrading the cooling system, it really works even better than I expected. As for testing LA, I did not check its operation due to the lack of an LA sampler (I just can’t decide on which project I will do it). Regarding bringing the HW version into line with the 900 model (HW V 8), some time ago I did some work to select the location of the configuration resistors on the back side of the board, but unfortunately I could not find the combination I needed, I attach a photo of the options I tested. in the left column is a combination, in the right column is the HW version shown in the scope shell. I have to wait until someone shows me a photo of the back of the 900 series board.....
-
@antiquant I’m very glad that you liked my solution for upgrading the cooling system, it really works even better than I expected. As for testing LA, I did not check its operation due to the lack of an LA sampler (I just can’t decide on which project I will do it). Regarding bringing the HW version into line with the 900 model (HW V 8), some time ago I did some work to select the location of the configuration resistors on the back side of the board, but unfortunately I could not find the combination I needed, I attach a photo of the options I tested. in the left column is a combination, in the right column is the HW version shown in the scope shell. I have to wait until someone shows me a photo of the back of the 900 series board.....
Im curious if its possible to switch into 9 - for DHO1000, maybe 2G samples per second will be possible?
I have 924S, later I will do some photos.
Very likely GPIO pins are read by hdcode_gpio.ko. Most of Linux modules like that reads hardware (gpio, serial, etc) and makes a file inside /proc or /sys. Couple years ago I was changing existing module to make one more file in /proc and that was pretty simple. So if hdcode_gpio.ko is doing this and only this, then it will be possible to give app any model You want without removing case at all.
-
BTW: The newest RigolTool version I have is 1.0.2 if you need it.
this is the one i'm running and quit disgracefully. i will try to pm him thanks. i just forgot who made it.
I tried to put it on DropBox for you, but they complain that it's a deviant file. Someone reported on the forums that his app was flagged a while back. I don't use Windows often, so I wouldn't know/care.
I hope this works.
-
Im curious if its possible to switch into 9 - for DHO1000, maybe 2G samples per second will be possible?
No, It is Immpossible. In 1000 there is really different hardware - another FPGA with different firmware and with other, more powerful capabilities.
-
Maybe Im little dumb, but I cant find it on Github, Gitlab and nowhere else. Anybody has a link or know where I should look?
You are a "little dumb", but that isn't the point... ;) Hey, your words, not mine. :blah: Oh, and relax d00d, I'm joking around.
Olliver's note 2 L's username here is @Oliv3r, -in case you want to PM him
--Here is his post about his GPL (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3184028/#msg3184028) request
--Here is Rigol's open source ack document (https://eu.rigol.com/Public/Uploads/uploadfile/files/ftp/DS/MSO5000%20Open%20Source%20Acknowledgment.pdf) Which has the contact info @Rigol to request the info yourself if you want (Section 1.2, FYI).
--Here is Olliver's LAPod Gitlab (https://gitlab.com/riglol/lapod) project page
--and his main Gitlab page (https://gitlab.com/riglol) with all his projects.
Good luck. Maybe this will help you find what you need.
-
Im curious if its possible to switch into 9 - for DHO1000, maybe 2G samples per second will be possible?
No, It is Immpossible. In 1000 there is really different hardware - another FPGA with different firmware and with other, more powerful capabilities.
I know its completely different FPGA, but of course I will not change binaries, just change it to app and Rigol kernel modules can see different "hardware number". Maybe it will change sample frequency in FPGA or maybe not. Is there any reason that I shouldnt try?
EDIT: Why moderators doesnt ban trolls on this forum?
-
I know its completely different FPGA, but of course I will not change binaries, just change it to app and Rigol kernel modules can see different "hardware number". Maybe it will change sample frequency in FPGA or maybe not. Is there any reason that I shouldnt try?
It's the same as putting an ECU from a Ferrari racing engine into an ordinary Ford engine and hoping that the Ford will make the same power as the Ferrari. But as a result, most likely Ford will not be able to drive at all :)
If you want, try it, of course. But personally, I will consider it a miracle if something working comes out of this :)
-
The sample rate on the DHO900 is halved when using the digital channels. That suggests the limit is in the FPGA throughput, one way or the other, or the bus is somehow limited by hardware. It doesn't hurt to try though
-
I know its completely different FPGA, but of course I will not change binaries, just change it to app and Rigol kernel modules can see different "hardware number". Maybe it will change sample frequency in FPGA or maybe not. Is there any reason that I shouldnt try?
It's the same as putting an ECU from a Ferrari racing engine into an ordinary Ford engine and hoping that the Ford will make the same power as the Ferrari. But as a result, most likely Ford will not be able to drive at all :)
If you want, try it, of course. But personally, I will consider it a miracle if something working comes out of this :)
You probably never heard about impossible things done by people in Poland.
Swaping racing engines into very cheap, very small and very old cars are done here pretty often...
[attach=1]
https://www.youtube.com/watch?v=Dl4CI2NpSDQ (https://www.youtube.com/watch?v=Dl4CI2NpSDQ)
-
Whoever will be taking apart their scope next, including the removal of the heat sink, please measure the size and thickness of the thermal pads. I have a crazy idea of trying those "phase change thermal pads", but need to know what size to order, and I don't want to take the scope apart again, given that someone here will surely do it sooner or later :).
@shapirus, Maybe you already got what you needed, but here are the measurements in case anyone else needs, notated on the picture. Oh, I forgot to label; 1mm thickness.
[attach=1]
-
The sample rate on the DHO900 is halved when using the digital channels. That suggests the limit is in the FPGA throughput, one way or the other, or the bus is somewhat limited by hardware. It doesn't hurt to try though
The FPGA in this design is very capable, and most likely not a bottleneck to performance.. They limit by design, because that's the way scopes are designed.. It's a lot of data to process/handle concurrently. FYI, the bandwidth is halved every time you turn an additional channel as well.
-
What does the app do with those bits? In what form are they related to model and/or options?
so easy, it is the hardware version:
model hardware version
DHO804 and DHO814 12
DHO802 DHO812 4
DHO914S DHO924S DHO914 DHO924 8
DHO1072 9
DHO4000 0
Can't you change the table in software? Is the version configured in the OTP SOC area or in a Rigol ASIC?
The RK3399 chip corresponds to the GPIO in the hardware version number:
bit0= GPIO0_A4 PIN 4
bit1= GPIO0_B0 PIN 8
bit2= GPIO0_B3 PIN 11
bit3= GPIO0_B4 PIN 12
I don't have a cross-compilation environment for RK3399 here, if anyone can compile a hdcode_gpio.ko by themselves to replace the original factory, you can achieve hardware version number customization.
digging this thread... in an attempt to search HW difference between 8 and 12... attached are the back side of RK3399 and Zynq FPGA of my DHO804, just in case some DHO900 owners is kind enough to spot the differences. maybe the config resistor is there? its difficult to tell if there is no DHO900 pictures for comparison. cheers.
-
I hope this works.
thanks, but its binary matched with what i have here...
-
Whoever will be taking apart their scope next, including the removal of the heat sink, please measure the size and thickness of the thermal pads. I have a crazy idea of trying those "phase change thermal pads", but need to know what size to order, and I don't want to take the scope apart again, given that someone here will surely do it sooner or later :).
@shapirus, Maybe you already got what you needed, but here are the measurements in case anyone else needs, notated on the picture. Oh, I forgot to label; 1mm thickness.
(Attachment Link)
Perfect, thanks a lot. Data recorded!
...no I haven't opened it since I added the external 120mm fan. Not gonna fix what ain't broke, for the time being, as I've got other stuff at the moment to satisfy my potentially destructive curiosity :)
-
digging this thread... in an attempt to search HW difference between 8 and 12... attached are the back side of RK3399 and Zynq FPGA of my DHO804, just in case some DHO900 owners is kind enough to spot the differences. maybe the config resistor is there? its difficult to tell if there is no DHO900 pictures for comparison. cheers.
Seems that you and S2084 are working similar paths. From earlier today. Check out the full size pic.
Regarding bringing the HW version into line with the 900 model (HW V 8), some time ago I did some work to select the location of the configuration resistors on the back side of the board, but unfortunately I could not find the combination I needed, I attach a photo of the options I tested. in the left column is a combination, in the right column is the HW version shown in the scope shell. I have to wait until someone shows me a photo of the back of the 900 series board.....
BTW: here are internal pix from early days 924S teardown by hubertyoung (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg4976278/#msg4976278)
[attach=1]
-
You probably never heard about impossible things done by people in Poland.
Swaping racing engines into very cheap, very small and very old cars are done here pretty often...
But you are not going to rearrange the engine (FPGA), but only the ECU (application) :)
I didn’t write anything about replacing the engine itself. Putting FPGAs from 1000 into 900 is generally beyond logic, reason and possibilities; it will be easier and cheaper to buy 1000 :)
-
Seems that you and S2084 are working similar paths. From earlier today. Check out the full size pic.
yes coincidentally but maybe due to different reason. LA triggering is not working on my hacked unit FW1.2.2 while on legit user, its working fine on the same FW... on older FW 1.14, its working on my unit, i think the older FW didnt check for HW difference... here what lead me to open up my dho again...
https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5382044/#msg5382044 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5382044/#msg5382044)
until it is fixed, the workaround for now is i have to use 2 different SD card FW. if i really need LA triggering, then i will insert FW 1.14.. by default i will run on latest FW 1.2.2 and set analog CH1 to whatever digital signal i want to trigger. fwiw.
-
BTW: here are internal pix from early days 924S teardown by hubertyoung (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg4976278/#msg4976278)
i have those pictures. i tried to find the difference with squint eyes, i cannot find though.. whats missing is the backside of the board..
Check out the full size pic.
Regarding bringing the HW version into line with the 900 model (HW V 8), some time ago I did some work to select the location of the configuration resistors on the back side of the board, but unfortunately I could not find the combination I needed, I attach a photo of the options I tested. in the left column is a combination, in the right column is the HW version shown in the scope shell. I have to wait until someone shows me a photo of the back of the 900 series board.....
i dont quite understand on which part it is located... is it in the red circle below? (there is no HW ver 8 in his photo)
-
Ehhh people - always doing simple things with time consuming methods. I never removed heatsink and never soldered anything inside, but I managed to change "Hardware number" with very simple methods. Learn more and be lazy - thats the key.
[attach=1]
[attach=2]
[attach=3]
[pid 1885] futex(0x71563a45d8, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 1894] write(62, "\1\0\0\0\0\0\0\0", 8 <unfinished ...>
[pid 1900] <... nanosleep resumed> NULL) = 0
[pid 1894] <... write resumed> ) = 8
[pid 1900] futex(0x7137472df8, FUTEX_WAIT_BITSET_PRIVATE, 2, NULL, ffffffff <unfinished ...>
[pid 1885] <... futex resumed> ) = 1
[pid 1894] ppoll([{fd=56, events=POLLIN}, {fd=62, events=POLLIN}, {fd=63, events=POLLIN}, {fd=64, events=POLLIN}], 4, NULL, NULL, 0 <unfinished ...>
[pid 1852] nanosleep({0, 35000000}, <unfinished ...>
[pid 1894] <... ppoll resumed> ) = 1 ([{fd=62, revents=POLLIN}])
[pid 1851] openat(AT_FDCWD, "/dev/hdcode_gpio", O_RDWR|O_NONBLOCK <unfinished ...>
[pid 1894] read(62, <unfinished ...>
[pid 1850] <... pselect6 resumed> ) = 0 (Timeout)
[pid 1894] <... read resumed> "\f\0\0\0\0\0\0\0", 8) = 8
[pid 1849] <... nanosleep resumed> NULL) = 0
[pid 1848] <... nanosleep resumed> NULL) = 0
[pid 1894] futex(0x70ac1c7830, FUTEX_WAKE_PRIVATE, 2147483647 <unfinished ...>
-
Ehhh people - always doing simple things with time consuming methods. I never removed heatsink and never soldered anything inside, but I managed to change "Hardware number" with very simple methods. Learn more and be lazy - thats the key.
(Attachment Link)
(Attachment Link)
(Attachment Link)
[pid 1885] futex(0x71563a45d8, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 1894] write(62, "\1\0\0\0\0\0\0\0", 8 <unfinished ...>
[pid 1900] <... nanosleep resumed> NULL) = 0
[pid 1894] <... write resumed> ) = 8
[pid 1900] futex(0x7137472df8, FUTEX_WAIT_BITSET_PRIVATE, 2, NULL, ffffffff <unfinished ...>
[pid 1885] <... futex resumed> ) = 1
[pid 1894] ppoll([{fd=56, events=POLLIN}, {fd=62, events=POLLIN}, {fd=63, events=POLLIN}, {fd=64, events=POLLIN}], 4, NULL, NULL, 0 <unfinished ...>
[pid 1852] nanosleep({0, 35000000}, <unfinished ...>
[pid 1894] <... ppoll resumed> ) = 1 ([{fd=62, revents=POLLIN}])
[pid 1851] openat(AT_FDCWD, "/dev/hdcode_gpio", O_RDWR|O_NONBLOCK <unfinished ...>
[pid 1894] read(62, <unfinished ...>
[pid 1850] <... pselect6 resumed> ) = 0 (Timeout)
[pid 1894] <... read resumed> "\f\0\0\0\0\0\0\0", 8) = 8
[pid 1849] <... nanosleep resumed> NULL) = 0
[pid 1848] <... nanosleep resumed> NULL) = 0
[pid 1894] futex(0x70ac1c7830, FUTEX_WAKE_PRIVATE, 2147483647 <unfinished ...>
if you are a little bit more clearer with those cryptic lines... then we might be capable of replicating... not everybody can speak your language ;) cheers.
-
if you are a little bit more clearer with those cryptic lines... then we might be capable of replicating... not everybody can speak your language ;) cheers.
Now I have 9 like in DHO1000. Wanna see 666 or any other number?
[attach=1]
Android is based on Linux kernel with little bit of staff from GNU. Every process leaves trace, and we can strace that. I didnt expect to production app being compiled with flags to trace function calls, but without it its possible to trace all system calls like a opening or closing files. Typically lot of things (including sleeps and many other things), so its better to send it via pipe to a file, to examine it later.
Second thing: In Unix and Unix-like (Linux) systems, everything is a file (https://en.wikipedia.org/wiki/Everything_is_a_file). So You dont need to write or download any software to do many things - couple basic tools and You can do almost everything.
Third thing: most drivers are layer between real hardware and... guess what is on other side. Spoiler: on other side there is a file.
Fourth thing: solution was practically already on this forum. Module hdcode_gpio.ko was reading some GPIO pins (I dont know which pins, how often and etc) and creating a file to read from there or maybe even to write into.
My suspicions was in /sys or eventually in /proc pseudo-filesystems, where normally more or less strange drivers creates some files. Comparing files listed into text files (Kompare from KDE - very useful), with and without this module (rmmod and insmod) gives me practically nothing. But opened file names visible with strace...
[pid 1851] openat(AT_FDCWD, "/dev/hdcode_gpio", O_RDWR|O_NONBLOCK <unfinished ...>
So to make a first test, I decided to unload this module and restart the app. As in my previous post, number was 0 instead of 8 like original.
Inserting this module back and restarting app, still gives 0. Im not a expert with Android. I have very little bit of knowledge with *-nix systems but not specially with Android - more of that, I think that is a very big crap, especially 8 and newer. No surprise for me, they used 7. Currently Im using two mobile phones - one with 7 and second one with 14.
Investigating further with this module...
rk3399_rigol:/ $ ls -l /dev/hdcode_gpio
crwxrwxrwx 1 root root 10, 45 2013-01-18 16:50 /dev/hdcode_gpio
C at the beginning means that is not normal file, but a char device - almost the same, but usually created by some kernel module.
I tried to read from it...
rk3399_rigol:/ $ cat /dev/hdcode_gpio
Houston, we have a cra... sudden reboot and crash. I almost had a heart attack. Playing too much, can cause to destroy something - for example, small mistake can cause to write into I2C and boom, RK808 gives much much higher voltages than usual. So be careful.
Next experiment was to remove this module from kernel and from Rigol script, where is located insmod command. Mentioned file disappeared :-BROKE no surprise.
Normally in /dev directory special (magic?) file system is mounted. Root can create and in some cases can delete files from there. Including completely normal files. So whats the problem?
echo -n "9" > /dev/hdcode_gpio
I wanted DHO1000 but result was more like DHO9234532487. Jokes aside, app showed hardware number 57...
After about 15 minutes of thinking (I was too much lazy to do experiments with random numbers) I reminded ASCII table. Character 9 is 57 in ASCII.
In ASCII byte 0x9 (9 in decimal) is a tab (\t). So...
rk3399_rigol:/ # echo -en "\t" > /dev/hdcode_gpio
After that, little test to confirm I didnt made any mistake:
rk3399_rigol:/ # cat /dev/hdcode_gpio
rk3399_rigol:/ #
And now I have what I always wanted from being 3 years old.
-
i dont quite understand on which part it is located... is it in the red circle below? (there is no HW ver 8 in his photo)
That's the spot! And it's verified on 8x2 vs 8x4 teardown photos.
-
...Second thing: In Unix and Unix-like (Linux) systems, everything is a file (https://en.wikipedia.org/wiki/Everything_is_a_file)...
learning that could take years...
i dont quite understand on which part it is located... is it in the red circle below? (there is no HW ver 8 in his photo)
That's the spot! And it's verified on 8x2 vs 8x4 teardown photos.
soldering this could take minutes. the "golden spoonfeed" question now is... whats the combination photo for DHO900S? ;D (ps: learning to solder good could take years ;D)
-
...Second thing: In Unix and Unix-like (Linux) systems, everything is a file (https://en.wikipedia.org/wiki/Everything_is_a_file)...
learning that could take years...
I dont get it why people when see two buttons instead of one, then they tell its complicated...
Everything is a file - three simple words. Thats it.
Wanna copy sd card image (file) into real card? Then copy it into another file which is equivalent of sd card - no need to use google to find some crazy software with malware included.
Wanna to turn off/on fan or change speed? Then You can read or write into a file. In same way now I can manage backlight leds (LCD) in my scope.
You want to write script and You need current ram informations like a total size? Then You can just read text file instead of googling for hours.
Everything is simple after You stop thinking the opposite.
More of that, in Linux there is a KISS acronym. Which stands for: Keep It Simple, Stupid. BTW. There is no more complicated system like Windows - this is very good for people which they have definitely too much time.
soldering this could take minutes. the "golden spoonfeed" question now is... whats the combination photo for DHO900S? ;D (ps: learning to solder good could take years ;D)
Research took me about one hour. How long You done research with resistors? Weeks?
After that research being done, I can change this number in 10-15 seconds. What is Your time with playing with resistors?
-
I have a crazy idea of trying those "phase change thermal pads", but need to know what size to order...
Perfect, thanks a lot. Data recorded!
...no I haven't opened it since I added the external 120mm fan. Not gonna fix what ain't broke, for the time being, as I've got other stuff at the moment to satisfy my potentially destructive curiosity :)
@Shapirus
BTW: It's probably obvious, but if it were me, I would order several 20mm2 and cut some into 10's. but more importantly, I would try to source slightly thicker pads so they can accommodate the variations across that heatsink. I'm sure the pads have a spec for how much they can tolerate a little compression.
Last little thing: You might want to check to see if they can be removed/reassembled. The ones I used last weren't re-workable, and had to "burn-in" for a period after installation, but were incredibly efficient once set up.
-
I dont get it why people when see two buttons instead of one, then they tell its complicated...
Everything is a file - three simple words. Thats it.
after reading your posts carefully i come to the realization that your technique is indeed the simplest one without opening up my scope again. i was very distracted lately, sorry... but there are still few things left to ask, i guess it should not take long anymore it should be this close...
1) where do i need to save those script you provided above? what file name?
2) and then using adb tool in which folder in the scope do i need to push it?
3) which line do i have to edit to get HW version number 8?
thanks for your persistent tips and helps..
-
Seems that you and S2084 are working similar paths. From earlier today. Check out the full size pic.
Regarding bringing the HW version into line with the 900 model (HW V 8), some time ago I did some work to select the location of the configuration resistors on the back side of the board, but unfortunately I could not find the combination I needed, I attach a photo of the options I tested. in the left column is a combination, in the right column is the HW version shown in the scope shell. I have to wait until someone shows me a photo of the back of the 900 series board.....
here is the complete list... resistors are 10Kohm... R1 and R2 (from left to right) are parallel, installing them will be 5Kohm, same thing with R3, R4 (rightmost)
-
Thanks dude.... I only had enough for a few combinations.... Then I gave up... :)
-
Thanks dude.... I only had enough for a few combinations.... Then I gave up... :)
yeah what a disappointment i dont want others into the same trap, hence i post. it seems there is other place for combination to get HW 8, lets wait photo donor from dho900 owner, i also just finished browsing this 80 pages thread to look for HW mod in case i missed, but not much news... so for now, life goes on.
-
here is the complete list... resistors are 10Kohm... R1 and R2 (from left to right) are parallel, installing them will be 5Kohm, same thing with R3, R4 (rightmost)
Could it be that for other versions of HW it is necessary to solder in resistors with other values?
-
I think this is extremely unlikely...
-
here is the complete list... resistors are 10Kohm... R1 and R2 (from left to right) are parallel, installing them will be 5Kohm, same thing with R3, R4 (rightmost)
Could it be that for other versions of HW it is necessary to solder in resistors with other values?
yes possibly, but what value? 20K? 30K? and at which positions? multiplying 2 probabilities can end up in thousands of possible combinations. me give up... maybe i'll look into the combination above if any "rhythm" ring the bell.. such as 0001 (HW5) and 0010 (HW13) dont quite add up (short dash derived by S2084 long dash derived by me), since the least 2 bits (and also the most 2 bits on the left) seem to be in parallel when measured with DMM, maybe next time to investigate when i'm fresh again.
-
Thanks dude.... I only had enough for a few combinations.... Then I gave up... :)
yeah what a disappointment i dont want others into the same trap, hence i post. it seems there is other place for combination to get HW 8, lets wait photo donor from dho900 owner, i also just finished browsing this 80 pages thread to look for HW mod in case i missed, but not much news... so for now, life goes on.
Don't forget the 80 pages of the Unboxing & teardown thread while you're at it. :o
-
I think this is extremely unlikely...
I don't see any point in making parallel resistors for digital signals. This means that most likely these resistors give the processor not just 0 or 1, but a voltage level that changes depending on whether one resistor is installed or both are installed in parallel places.
On the other hand, according to Mechatrommer, installing one R1 and one R2 gives different versions of HW, which also makes no sense if they are paralleled. In general, it’s not clear yet :)
-
BTW: It's probably obvious, but if it were me, I would order several 20mm2 and cut some into 10's. but more importantly, I would try to source slightly thicker pads so they can accommodate the variations across that heatsink. I'm sure the pads have a spec for how much they can tolerate a little compression.
The thing about the phase change pads (as opposed to the regular silicone pads), as far as I understand, is that they become very soft when heated, like tar or bubble gum, which allows them to take the shape of the surfaces that they sit between, and fill all the gaps and irregularities, and if the heatsink mounts are spring-loaded, then the pads will not stop it (or at least will resist much less) from moving towards the chips as far as the springs are able to push it, eventually achieving the lowest thermal resistance possible. That's why getting them in a little thicker size than required should make sense -- the unnecessary thickness will be squeezed out, if, of course, the respective chips will get hot enough (which may not be the case actually). And of course it makes sense to grab, if available, one big single sheet and just cut whatever sizes are needed from it.
They're pricey though. But who cares about the price when it comes to hobby, experimenting and learning.
Last little thing: You might want to check to see if they can be removed/reassembled. The ones I used last weren't re-workable, and had to "burn-in" for a period after installation, but were incredibly efficient once set up.
I'm pretty sure the phase change pads are single use only, at least this is kind of obvious for what they are. I haven't researched the fine details yet, though.
-
Don't forget the 80 pages of the Unboxing & teardown thread while you're at it. :o
did that quckly just looking for photos... not much development as well past the separation of this thread from there.. the most prominent contributions are from chinese members azuka, souldevelop, hubertyoung etc on early pages.
On the other hand, according to Mechatrommer, installing one R1 and one R2 gives different versions of HW, which also makes no sense if they are paralleled. In general, it’s not clear yet :)
when only R1 installed, i measured resistance across it 10Kohm, when R2 installed, i measured 4-5Kohm across either one of them, so i assumed they are paralleled, but i didnt check how the traces are connected they are too small and faint to see. i measured lose resistor is 10Kohm. fwiw...
-
when only R1 installed, i measured resistance across it 10Kohm, when R2 installed, i measured 4-5Kohm across either one of them, so i assumed they are paralleled, but i didnt check how the traces are connected they are too small and faint to see. i measured lose resistor is 10Kohm. fwiw...
I’m really itching to disassemble the oscilloscope and study these resistors under a microscope, to solve this riddle :) As soon as I have some free time, I’ll do it.
-
(ps: learning to solder good could take years ;D)
In previous year I learned one woman to solder both THT and SMD properly in about 2-3 hours - including unpacking my toys (soldering station and other things) and packing it back. After that, she fixed her expensive SMD mounted LED strips by herself. Personally I was learned by her mother, when I was couple years old. Being patient is the key.
I dont get it why people when see two buttons instead of one, then they tell its complicated...
Everything is a file - three simple words. Thats it.
after reading your posts carefully i come to the realization that your technique is indeed the simplest one without opening up my scope again. i was very distracted lately, sorry... but there are still few things left to ask, i guess it should not take long anymore it should be this close...
1) where do i need to save those script you provided above? what file name?
2) and then using adb tool in which folder in the scope do i need to push it?
3) which line do i have to edit to get HW version number 8?
thanks for your persistent tips and helps..
Do You need some magic rule again? There is no rules here. At least Im not too much familiar with Android and I cant tell about any rules in Android. There are already existing scripts from Rigol - at least one of them is executed before starting app process, and You need to disable loading module hdcode_gpio.ko (to prevent from creating one file I was talking earlier) in one of those scripts - so guess where will be the best and easiest place for this?
Do I need to tell such simple things? Its like painting a picture - its Your choice in which part of canvas/paper You will begin. Same here - if its not working as You wanted, then grab another paper... Most mistakes in scripts (in exception of changing supply voltages) can be reverted in matter of seconds. Overheating PCB and damaging very small SMD components not very likely - some years ago I was making money from fixing laptops, and I made many mistakes already (most of them was caused by being lazy).
Also, what particular way You chose to edit script is Your chose. Again I suggest to do everything on Linux (chose Debian), because You have simple and in same time very powerful tools like a bash (sometimes very big magic can be done via putting one char in some command - saving hours of Your time).
(ps: learning to solder good could take years ;D)
In previous year I learned one woman to solder both THT and SMD properly in about 2-3 hours - including unpacking my toys (soldering station and other things) and packing it back. After that, she fixed her expensive SMD mounted LED strips by herself. Personally I was learned by her mother, when I was couple years old. Being patient is the key.
3) which line do i have to edit to get HW version number 8?
Really? Its already in that mine earlier post. You need just one byte. Create one-byte length file. Thats all the magic. How You will do it, is Your choice. Theoretically nothing should delete this file, but who knows? Even if, thats no problem. Mine scope (924S) works with full bandwidth without this file (displayed HW is 0) so maybe there is no point to create this file at all?
BTW... maybe there is a point to dynamically create this file by a user choice. This scope originally has to offer only two bandwidth settings - full and 20 MHz. Displayed HW number is from app start (later changing doesnt do anything - at least as I checked it once), but according to strace output, this is being read many times later (by opening and closing file descriptor). I will check this later - If I forget, please remind me.
here is the complete list... resistors are 10Kohm... R1 and R2 (from left to right) are parallel, installing them will be 5Kohm, same thing with R3, R4 (rightmost)
Earlier I told here to measure those resistors. Everybody else assumed those are 0 Ω resistors... I wasnt complaining, but watching everybody destroying their scopes. Next time dont assume anything, especially when somebody tells You opposite. Using multimeter can take couple seconds and can save expensive&precise equipment and save many hours of unnecessary work.
Somebody did a measurement of its values?
That was week ago, and everybody was too lazy to check this with multimeter. Being lazy is a good thing. Being too much lazy, not so much. Now I dont see any point to make any play with this resistors anymore. Leave as it is and use my "complicated" hack - instead of unnecessary heating PCB and damaging it.
I think this is extremely unlikely...
I don't see any point in making parallel resistors for digital signals. This means that most likely these resistors give the processor not just 0 or 1, but a voltage level that changes depending on whether one resistor is installed or both are installed in parallel places.
On the other hand, according to Mechatrommer, installing one R1 and one R2 gives different versions of HW, which also makes no sense if they are paralleled. In general, it’s not clear yet :)
I see many points. Same amount of resistors, but less CPU pins used. This is not a place of communication or any other signal. Booting 1 ms slower is nothing. Again, this is another reason, to use multimeter before soldering in blind like a 6-year old kids. Using voltmeter is also useful :-DMM
I’m really itching to disassemble the oscilloscope and study these resistors under a microscope, to solve this riddle :)
Thats why I decided to use photo of microsope as a default wallpaper in my "orangerigol", which I will push to github later.
Speaking of solving a riddle... Again You are doing very unnecessary job, as I told earlier. Here is probably best example of solving riddles in easiest possible way:
https://www.youtube.com/watch?v=-Qtf8exmD0A (https://www.youtube.com/watch?v=-Qtf8exmD0A)
-
here is the complete list... resistors are 10Kohm... R1 and R2 (from left to right) are parallel, installing them will be 5Kohm, same thing with R3, R4 (rightmost)
Earlier I told here to measure those resistors. Everybody else assumed those are 0 Ω resistors... I wasnt complaining, but watching everybody destroying their scopes. Next time dont assume anything, especially when somebody tells You opposite. Using multimeter can take couple seconds and can save expensive&precise equipment and save many hours of unnecessary work.
Somebody did a measurement of its values?
i measured the value since S2084's report doesnt look like simple logic 0-1 nor binary value... so since at it, i tried to gather as much information, but i was trying to being quick just to get the HW version, i was not aware the discussion was about hacking 2CH to 4CH scope. anyway, dont sounds like you being ignored, i learnt long enough to expect nothing when being ignored, its probably their loss, not mine. or probably its beyond their comprehension, or they are too "immersed" on the things they are already familiar with, thats the quickest route to their or my belief. just a piece of advice, if you want to help, try to be as clear and as simplest as you can, because not everybody is talented enough in your area. if they see its fruitfull then interest will comes in. this is how we learn, we have to start from something simple. (ps: btw why orangerigol? why dont orangetightshort? as in your linked video? that probably will give much more attention ;D) cheers.
-
In the meantime, my LA connector seems to have acquired its final form... :) :) :)
-
(ps: btw why orangerigol? why dont orangetightshort? as in your linked video? that probably will give much more attention ;D) cheers.
Because it is (heavily) modified build from OrangePi. One of many modification is latest version of Debian (much much newer and nicer software). That was my first thought to give it a name.
-
Can You say: Cocaina?
Now I need vendor.bin and Key.data from DHO1000 and some other files. I cant find it.
Of course I didnt change FPGA and binary from 900. To being sure it wasnt changed, I reflashed it with /rigol/FPGA/BOOT.bin
So looks like communication between app and FPGA is different. @AndyBig You are probably good with Scali - can You do some investigation?
-
@AndyBig You are probably good with Scali - can You do some investigation?
I don't even know what Scali is :)
All communication between the application and the FPGA goes through the libscope-auklet.so library. Well, more precisely, it’s not even a connection with the FPGA; the application doesn’t know anything about the FPGA at all. The application simply broadcasts user actions to libscope-auklet.so and receives results from it.
-
@AndyBig You are probably good with Scali - can You do some investigation?
I don't even know what Scali is :)
All communication between the application and the FPGA goes through the libscope-auklet.so library. Well, more precisely, it’s not even a connection with the FPGA; the application doesn’t know anything about the FPGA at all. The application simply broadcasts user actions to libscope-auklet.so and receives results from it.
I already tried to change libscope-auklet.so back to original and app from DHO1000 crashes at start. Maybe somebody can decompile merge this two different libs to make it work? Yeah, I know how it sounds.
-
I think I have found something useful.
rk3399_rigol:/ # cat /rigol/resource/conf/version.txt
0x0@SPU_H12S4.bit
0x4@SPU_H12S4B.bit
0x2@SPU_H12S2B.bit
0x3@SPU_H12S2.bit
0x1@SPU_H12S2.bit
0x9@SPU_H12S2B.bit
rk3399_rigol:/ #
-
I already tried to change libscope-auklet.so back to original and app from DHO1000 crashes at start.
This is a completely expected result.
Maybe somebody can decompile merge this two different libs to make it work? Yeah, I know how it sounds.
Well, if you understand how it sounds, then you understand what the answer to your question is :)
-
SO at this point on the DHO804, what is the best method to increase its bandwidth/memory depth? I saw a method early on in the thread that had a youtube video showing it, but then I saw something about a firmware update that may have invalidated that method? I'm thinking about ordering on of these so I want to get the low down on the latest method that it solid. It sounds like in the DHO8 series that the 804 is the one.
-
SO at this point on the DHO804, what is the best method to increase its bandwidth/memory depth?
https://github.com/zelea2/rigol_vendor_bin
-
SO at this point on the DHO804, what is the best method to increase its bandwidth/memory depth? I saw a method early on in the thread that had a youtube video showing it, but then I saw something about a firmware update that may have invalidated that method? I'm thinking about ordering on of these so I want to get the low down on the latest method that it solid. It sounds like in the DHO8 series that the 804 is the one.
You want to upgrade it to DHO814 or to DHO924?
In this second case, You need to change HW number and probably reflash FPGA (that is my today discovery).
-
SO at this point on the DHO804, what is the best method to increase its bandwidth/memory depth? I saw a method early on in the thread that had a youtube video showing it, but then I saw something about a firmware update that may have invalidated that method? I'm thinking about ordering on of these so I want to get the low down on the latest method that it solid. It sounds like in the DHO8 series that the 804 is the one.
Hi there!! It's not obvious to find the newest/greatest guide, sorry. -but @Andybig wrote up a guide many pages ago that is step by step, using a couple different approaches, and very complete.
It is your best chance for success. See here--
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076)
Have fun hackin' :-/O
p.s., the DHO804 offers "the best bang for the buck", since it has everything a DHO900 has currently, except the additional hardware that the S models have.
-
By the way...
-
You want to upgrade it to DHO814 or to DHO924?
In this second case, You need to change HW number and probably reflash FPGA (that is my today discovery).
Please don't say that. Users don't reflash the FPGA. FPGA's lose their memory on power-down/reboot.
The system loads(I.e., programs) the FPGA via SPI Flash. The CPU can send a *.bin to upgrade that flash so it loads it subsequently.
-
By the way...
That's something. Does it actually work?
-
By the way...
That's something. Does it actually work?
Of course not!!! I did this two months ago..... nothing works there...:):):):). even the sensitivity does not change.... horizontal scan too, sampling frequency is always 625..... :):):):)
-
By the way...
That's something. Does it actually work?
Kinda... Everything from 10M to 100M gives 10M.
-
Kinda... Everything from 10M to 100M gives 10M.
What method was that? Technically the scope is capable of 50M all right. My DHO804 stores 50M points: I can capture 40ms worth of samples at 1.25 GSa/s and, when acquisition is stopped, zoom all the way to 2 ns/div at any point of the captured interval.
Your screenshot made me wonder if it can do 100M somehow.
-
Kinda... Everything from 10M to 100M gives 10M.
What method was that? Technically the scope is capable of 50M all right. My DHO804 stores 50M points: I can capture 40ms worth of samples at 1.25 GSa/s and, when acquisition is stopped, zoom all the way to 2 ns/div at any point of the captured interval.
Your screenshot made me wonder if it can do 100M somehow.
I changed vendor.bin. Model name HDO1074, serial number also from photo in this forum and I generated lic files for DHO1000 with this: https://github.com/zelea2/rigol_vendor_bin/
-
Call me crazy, but right now I want to do 4.1 G Sa/s...
More crazy thing is, I know how to do this :-BROKE :popcorn:
Currently there is no magic smoke, but after one minute play I see trigger works only in single mode - probably I changed too much files for experiments.
-
This is more or less normal:
[attach=1]
This is changed:
[attach=2]
So looks like sample rate wasn't changed at all (measured frequency went higher and rise time is lower), but now probably I know where I should look for it.
However... With same generator measured rise time is 2.55 ns vs 1.02 ns. Frequency is 17.71 MHz vs 56.66 MHz. According to change in measured frequency, sample rate is 1.25 (4/1.25) but rise time has different ratio... Maybe because of interpolation.
-
So looks like sample rate wasn't changed at all (measured frequency went higher and rise time is lower), but now probably I know where I should look for it.
Also note how the displayed waveform in the second screenshot is zoomed out, while timebase is set to 10 ns/div, whereas it should have been zoomed in, as the other screenshot has 20 ns/div. This isn't right.
-
So looks like sample rate wasn't changed at all (measured frequency went higher and rise time is lower), but now probably I know where I should look for it.
Also note how the displayed waveform in the second screenshot is zoomed out, while timebase is set to 10 ns/div, whereas it should have been zoomed in, as the other screenshot has 20 ns/div. This isn't right.
Because I changed time base couple times...
-
Because I changed time base couple times...
When you change time base, the displayed waveform must properly fit in the respective number of horizontal divisions.
Was the signal the same in those two screenshots?
In the first screenshot the displayed waveform's period takes slightly less than 3 divisions. 3 div = 60 ns, frequency with 60 ns period is 16.6 MHz, and it's slightly less than 3 div, so the counter shows 17.7 MHz correctly.
In the second screenshot the counter still shows the same 17.7 MHz, but the displayed waveform's period is slightly less than 2 div; 1 div = 10 ns, the cursors measure it right: 18 ns. Then, 1 / 18 ns ~= 55.5 MHz, meaning that the scope failed to render the horizontal scale properly, but it still counted the zero crossings right (which apparently happens in a whole separate part of the system and doesn't depend on what's actually displayed).
-
Because I changed time base couple times...
When you change time base, the displayed waveform must properly fit in the respective number of horizontal divisions.
Was the signal the same in those two screenshots?
In the first screenshot the displayed waveform's period takes slightly less than 3 divisions. 3 div = 60 ns, frequency with 60 ns period is 16.6 MHz, and it's slightly less than 3 div, so the counter shows 17.7 MHz correctly.
In the second screenshot the counter still shows the same 17.7 MHz, but the displayed waveform's period is slightly less than 2 div; 1 div = 10 ns, the cursors measure it right: 18 ns. Then, 1 / 18 ns ~= 55.5 MHz, meaning that the scope failed to render the horizontal scale properly, but it still counted the zero crossings right (which apparently happens in a whole separate part of the system and doesn't depend on what's actually displayed).
When I figured out this app is capable up to 40 G Sa/s (maybe even more) my laptop died because I forget to connect it back (I needed power supply for a generator and I used same power cord). After that I decided to do a quick experiment, which You have seen on screenshots. Right now Im going to try anything above 1.25 in a similar way (more changes).
Still Im not sure why rise time was changed by different ratio.
-
right now I want to do 4.1 G Sa/s...
To do this you will have to solder a second ADC.
-
right now I want to do 4.1 G Sa/s...
To do this you will have to solder a second ADC.
This ADC as far as I know is capable to do at least 2G.
-
This ADC as far I know is capable to do at least 2G.
More like a maximum of 2G. Therefore, for 4G you need a second ADC.
-
This ADC as far I know is capable to do at least 2G.
More like a maximum of 2G. Therefore, for 4G you need a second ADC.
Thats also good.
-
This ADC as far I know is capable to do at least 2G.
More like a maximum of 2G. Therefore, for 4G you need a second ADC.
Thats also good.
But this does not mean at all that on 8xx/9xx hardware it will produce 2G :)
-
But this does not mean at all that on 8xx/9xx hardware it will produce 2G :)
When I first learned about the 1.25 GSa/s sampling rate on the DHO800/900 series, I thought they might be deliberately throttled to keep some differentiating features for the DHO1000. But then it became known that Rigol had to cripple the DHO900 series by cutting its analog sampling rate in half whenever the digital channels are used. (Which happen to consume half the data rate, capturing 16-bit words at 625 MSa/s.)
This lets me assume that there is indeed a limitation in the overall data rate (analog + digital channels combined) which the scope can process, and that the limit is not set by the ADC. The DRAM or its interface to the FPGA is a likely suspect.
-
Please don't say that. Users don't reflash the FPGA. FPGA's lose their memory on power-down/reboot.
The system loads(I.e., programs) the FPGA via SPI Flash. The CPU can send a *.bin to upgrade that flash so it loads it subsequently.
Not 100% sure about that.
System indeed program program SPI flash, but only some part.
I have checked before and SPI flash content was matched with boot and selftest bin programmed by system but area starting from 0x0 is not matched with anything.
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5332511/#msg5332511 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5332511/#msg5332511)
user empeka provide dump from 914
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5332670/#msg5332670 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5332670/#msg5332670)
Result of comparation.
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5332712/#msg5332712 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5332712/#msg5332712)
It may be a different version of firmware or maybe not and firmware is different.
-
Please don't say that. Users don't reflash the FPGA. FPGA's lose their memory on power-down/reboot.
The system loads(I.e., programs) the FPGA via SPI Flash. The CPU can send a *.bin to upgrade that flash so it loads it subsequently.
Not 100% sure about that.
System indeed program program SPI flash, but only some part.
I have checked before and SPI flash content was matched with boot and selftest bin programmed by system but area starting from 0x0 is not matched with anything.
It may be a different version of firmware or maybe not and firmware is different.
Agreed, it's hard to tell what that 0x00 bit is/was supposed to point at.
My hypothesis: they have one "working", one "update" and one "factory" copy of the FPGA configuration.
It used to be standard practice in embedded designs I worked on, to keep multiple copies in case an update goes bad. If the update is good, and boots normal, then the "working" and "update" copies can be revised. Then a "restore to factory" copy hidden away that can be restored in case of corruption, etc. Saves on tech support inquiries and RMA's.
I'm not sure exactly how Rigol chose to do it., but I think you proved that they loaded the SPI with multiple copies. I remember thanking your post.
And then; This could just be Rigol software guys not cleaning up behind themselves. They have multiple copies of files littered everywhere on the SDCard.
-
It may be a different version of firmware or maybe not and firmware is different.
BTW, sorry. I'm not sure I follow this statement.. Maybe i'm tired from Daylight "Savings" time cutting my sleep. :=\
-
When I first learned about the 1.25 GSa/s sampling rate on the DHO800/900 series, I thought they might be deliberately throttled to keep some differentiating features for the DHO1000. But then it became known that Rigol had to cripple the DHO900 series by cutting its analog sampling rate in half whenever the digital channels are used. (Which happen to consume half the data rate, capturing 16-bit words at 625 MSa/s.)
I wouldn't call it "crippled".
I see it more like a Swiss Army knife: It has a lot of tools available but you use them individually. You're not supposed to open all the blades at the same time.
This one's strength is the analog part. If you use digital all day long then get an MSO5000 instead. :-//
-
rather than to prove heroness by enabling 314.159265 GSps that possibly the HW cant even support anyway, even though on screen it says it can, even possibly smoking the ADC/FPGA... its better time spent to practically prove the easy way say to change HW 12 to 8 (not 67 nor 3.142) the idea of one SW reusable for 1000 HW is not new, in fact its even before i started learning C nearly 30 years ago...
-
I wouldn't call it "crippled".
I see it more like a Swiss Army knife: It has a lot of tools available but you use them individually. You're not supposed to open all the blades at the same time.
What's the point of an MSO if I cannot fully use the digital and analog channels at the same time?
If I wanted a pure logic analyser, something like the Dreamsource Lab devices would be a much better choice. If I wanted a purely analog scope, the DHO800 will suffice. In fact, buying the combination of those two is probably a better idea than buying a DHO900.
But if you want to observe both, analog+digital signals on the same screen, buying an MSO from a different brand is a better choice than the DHO900. (Or buying the MSO5000 if you can live with noisy analog signals.) I would still call a 200 MHz scope which drops to 150 MSa/s under certain circumstances "crippled", in particular when it does not dial back its anti-aliasing filters accordingly.
-
The DRAM or its interface to the FPGA is a likely suspect.
Yes, I think so too. It’s not for nothing that they installed a cheaper FPGA compared to the 1000/4000 series.
-
I wouldn't call it "crippled".
I see it more like a Swiss Army knife: It has a lot of tools available but you use them individually. You're not supposed to open all the blades at the same time.
What's the point of an MSO if I cannot fully use the digital and analog channels at the same time?
You can use them all, just not at full bandwidth.
The scissors on a Swiss Army knife aren't as high bandwidth as a pair of real scissors but I've used the scissors on mine a LOT.
-
yeah! especially an MSO that you can get at ~$600 including LA probe ::) up the game? probably 1-2GSps MSO? buy siglent SDS800X! and those AFG and LA module sold separately. (ps: i dont mind mentioning the name here as i sense rigol fanboys dont get easily insulted ;D)
-
SDCard is not encrypted. I've had good luck using "testdisk" on Ubuntu. People talk about mounting using loopback, which I haven't tried.
FYI: Here are a couple links from searching for "partition" (just the highlights)
Sept:
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5048008/#msg5048008)
More:
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046892/#msg5046892 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046892/#msg5046892)
Dec:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5240010/?topicseen#msg5240010 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5240010/?topicseen#msg5240010)
My post about SDCard partitions:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5356541/?topicseen#msg5356541 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5356541/?topicseen#msg5356541)
Most recent, from 3 days ago:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5374955/#msg5374955 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5374955/#msg5374955)
My DHO 804 sdcard appears to have only two Android partitions, "android_meta" and "android_expand". I think the "16" number mentioned elsewhere in this hackng thread is the number of mount points, and not partitions.
Well, my sdcard might very well be encrypted.
The GUID number for type (used by android) seems to suggest encryption is used.
If the DHO has no HSM to store keys (or does it?), then the question becomes, are the keys on the sd card, and if so maybe they are in the _meta partition. I can't mount _meta either.
Edit: hexdump -C on the _expand partition does show some ascii stuff up front, seems like boot info about cpu and some settings. I am trying to find the expand_ .key file that's used by vold on Android. Without an HSM to access the vold key has to be on sdcard as non-encrypted. The mystery gets deeper.
-
My DHO 804 sdcard appears to have only two Android partitions, "android_meta" and "android_expand". I think the "16" number mentioned elsewhere in this hackng thread is the number of mount points, and not partitions.
Well, my sdcard might very well be encrypted.
The GUID number for type (used by android) seems to suggest encryption is used.
If the DHO has no HSM to store keys (or does it?), then the question becomes, are the keys on the sd card, and if so maybe they are in the _meta partition. I can't mount _meta either.
Use testdisk or binwalk. This is not encrypted.
Edit: You have file systems (partitions) but without any partition table.
-
My DHO 804 sdcard appears to have only two Android partitions, "android_meta" and "android_expand". I think the "16" number mentioned elsewhere in this hackng thread is the number of mount points, and not partitions.
Well, my sdcard might very well be encrypted.
The GUID number for type (used by android) seems to suggest encryption is used.
If the DHO has no HSM to store keys (or does it?), then the question becomes, are the keys on the sd card, and if so maybe they are in the _meta partition. I can't mount _meta either.
Use testdisk or binwalk. This is not encrypted.
Edit: You have file systems (partitions) but without any partition table.
It appears to be GPT, it shows 2 partitions., each named, and each has GUID type number, along with start and end blks to each.
Those GUID type numbers are referenced in Android docs under "adopted" storage. At some point playing around I think I did select "internal" when the sdcard error pops up in android when using keybard to poke around the droid menu stuff. Not sure yet. I'll image my sdcard and then much around with the image.
-
My DHO 804 sdcard appears to have only two Android partitions, "android_meta" and "android_expand". I think the "16" number mentioned elsewhere in this hackng thread is the number of mount points, and not partitions.
Well, my sdcard might very well be encrypted.
The GUID number for type (used by android) seems to suggest encryption is used.
If the DHO has no HSM to store keys (or does it?), then the question becomes, are the keys on the sd card, and if so maybe they are in the _meta partition. I can't mount _meta either.
Use testdisk or binwalk. This is not encrypted.
Edit: You have file systems (partitions) but without any partition table.
It appears to be GPT, it shows 2 partitions., each named, and each has GUID type number, along with start and end blks to each.
tesdisk sees 5 partitions.
-
BTW, sorry. I'm not sure I follow this statement.. Maybe i'm tired from Daylight "Savings" time cutting my sleep. :=\
I don't know is hard to understand what I want to say?
I'm talking about SPI attached to FPGA content and differences.
Hex comparing two files.
Address range DHO804 DHO814S
0x00000000 - 0x00376907 different different
0x00376908 - 0x003FFFFF identical identical blank , FF's only
0x00400000 - 0x00776907 identical identical BOOT.fin file
0x00776908 - 0x007FFFFF identical identical blank , FF's only
0x00800000 - 0x00B76907 identical identical BOOT_SelfTest.bin file
0x00B76908 - 0x00FFFFFF identical identical blank , FF's only
-
Something I thought may be useful to share....Playing around with the Waveforms software that runs the Digilent Analog Discovery AD2 (which is a nice 14-bit little device with great software), it occurred to me that one could use its "spectrum analyzer" to display and manipulate DHO800 FFT traces, leveraging the software features, like multiple measurements, markers, trace colors, etc., etc.
To begin, the DHO FFT traces can retrieved, e.g. averaged, and saved into a csv file, using a few lines of python code:
import pyvisa as visa
import numpy as np
import pandas as pd
scopedev = 'TCPIP0::192.168.0.10::5555::SOCKET' #four 5's
nSamples = 100
scope = visa.ResourceManager().open_resource(scopedev)
scope.read_termination = scope.write_termination = '\n'
print("Scope: ", scope.query("*IDN?"))
scope.write(":WAV:SOURCE MATH1;:WAV:FORM ASCii;:WAV:MODE NORMAL")
fstart = float(scope.query(":MATH1:FFT:FREQuency:START?"))
fend = float(scope.query(":MATH1:FFT:FREQuency:END?"))
X = np.linspace(fstart, fend, 1000, endpoint=True)
fftData =[]
for i in range(0,nSamples):
fftData += [np.array(scope.query(":WAV:DATA?").split(","),dtype=float)]
npData = np.array(fftData)
avgFFTdata = np.mean(npData,axis=0)
maxFFTdata = np.max(npData,axis=0)
saveData = pd.DataFrame(columns=["Frequency (Hz)","Avg (dBV)","PeakHold (dBV)"])
saveData["Frequency (Hz)"]=X
saveData["Avg (dBV)"]=avgFFTdata
saveData["PeakHold (dBV)"]=maxFFTdata
saveData.to_csv("TestSAData.csv",index=False)
The Waveforms software, allows you to save a "workspace" which can be configured to have "Spectrum" and "Script" tabs. (BTW, the software is free and it can run in DEMO mode, in which all this works...). The Waveforms script required to import the saved DHO FFT traces from the saved csv file into the "spectrum analyzer" can also be very short:
var data = String(FileRead("/Users/Home/temp/TestSAData.csv")).trim().split('\n')
Spectrum1.Trace1.label = "T1: Avg"
Spectrum1.Trace2.label = "T2: MaxHold"
var data_length = data.length
var trace1_mag = var trace2_mag = []
min_f = data[1].split(',')[0]
max_f = data[data_length-1].split(',')[0]
Spectrum1.Frequency.Start.value = min_f
Spectrum1.Frequency.Stop.value = max_f
for(var i = 1; i < data_length; i++){
trace1_mag.push(data[i].split(',')[1])
trace2_mag.push(data[i].split(',')[2])
}
Spectrum1.Trace1.setMagnitude(trace1_mag,min_f,max_f)
Spectrum1.Trace2.setMagnitude(trace2_mag,min_f,max_f)
Spectrum1.run()
The python script to retrieve and save the FFT data from the scope, and bring up the Waveforms software can be executed from a single shell script (or separately). To bring up the Waveforms software with the saved workspace (say "WS"), running the script, one just needs to execute
[path.....]/Waveforms.exe WS.dwf3work -runscript
I have a shell script that does this mapped to an alias. My saved workspace has measurements, and a few other things set up (with spectrum and script tabs open). So after setting up the FFT on the DHO, on my laptop I just execute the script (mapped to an alias like "fft"), and I get a display looking like the screenshot attached below, where I can further add more markers, measurements, etc...When I change the FFT trace on the scope, I can always re-run the python script to save new traces, and run the Waveforms script on the workspace (with one click) to update the displayed traces (all of this can be done in a running loop, but not really needed...)
-
yeah! especially an MSO that you can get at ~$600 including LA probe ::) up the game? probably 1-2GSps MSO? buy siglent SDS800X! and those AFG and LA module sold separately. (ps: i dont mind mentioning the name here as i sense rigol fanboys dont get easily insulted ;D)
I don't want to divert this into a Siglent vs. Rigol argument, but would like to correct the implication that the Rigol solution comes at an unbeatable price. For those who are happy to "hack" their scopes by generating license keys, but don't want to physically hack the hardware, the Siglent prices are actually more favorable. European prices without VAT:
Siglent SDS804 + SLA1016: 700€
Rigol DHO914 + PLA2216: 900€
Surcharge for function generator if you want Bode plotting:
Siglent SAG1021I: 139€ -- or 0€ if you already have an external Siglent generator
Rigol DHO9xx-S version: 100€
In MSO mode the Siglent will give you 2 GSa/s instead of 0.625 for the analog channels, and 1 GSa/s instead of 0.625 for digital. The latter being quite nice since your digital data will be sampled in 1 ns steps instead of somewhat awkward 1.6 ns. (Let's not get into software aspects like FFT, Bode wiggles etc.)
-
After all that 2037 post what i read, I have one simple question....
Is all of that hack what work on DHO804 (BW 100MHz, 50 Mpts memory depth), work also on DHO802?
If i understand only difference between DHO804 and DHO802 is frontend channel number?!
-
OTOH, the 900 is a true MSO, the SDS800 only gets decimated display data from the acquisition hardware on the logic probe.
But yeah, the halved sample rate with LA on is a problem.
-
My DHO 804 sdcard appears to have only two Android partitions, "android_meta" and "android_expand". I think the "16" number mentioned elsewhere in this hackng thread is the number of mount points, and not partitions.
Well, my sdcard might very well be encrypted.
The GUID number for type (used by android) seems to suggest encryption is used.
If the DHO has no HSM to store keys (or does it?), then the question becomes, are the keys on the sd card, and if so maybe they are in the _meta partition. I can't mount _meta either.
Edit: hexdump -C on the _expand partition does show some ascii stuff up front, seems like boot info about cpu and some settings. I am trying to find the expand_ .key file that's used by vold on Android. Without an HSM to access the vold key has to be on sdcard as non-encrypted. The mystery gets deeper.
I used testdisk on Linux on a DD imaged backup of my original Nov/2023 SDCard, and it found several partitions, EXT4 and Unallocated(like other's have) --and most importantly-- I noticed they were all Deleted. Note: this was only using the quick scan. Deep scan revealed 100's
I undeleted the main partition, and I was able to do a lot more with the card. In my case, it's a 64G card that I'm currently thrashing on, and I was able to resize the 29.5 gigs to full size of the card using "disks" GUI tool in Ubuntu.
Also, It appears that Rigol had an image that was slightly too large for the target cards, thus making it difficult to image. i.e., DD complains about 1 byte not getting copied when it finishes quits. Other users have reported similar findings all the way back when the first scopes were shipped.
I think it might be interesting to make a new card with partitions then imagecopy the useful partitions over. I don't really know how, but I'll probably try some day.
-
My DHO 804 sdcard appears to have only two Android partitions, "android_meta" and "android_expand". I think the "16" number mentioned elsewhere in this hackng thread is the number of mount points, and not partitions.
Well, my sdcard might very well be encrypted.
The GUID number for type (used by android) seems to suggest encryption is used.
If the DHO has no HSM to store keys (or does it?), then the question becomes, are the keys on the sd card, and if so maybe they are in the _meta partition. I can't mount _meta either.
Use testdisk or binwalk. This is not encrypted.
Edit: You have file systems (partitions) but without any partition table.
It appears to be GPT, it shows 2 partitions., each named, and each has GUID type number, along with start and end blks to each.
tesdisk sees 5 partitions.
/system and /data are mount points with a filesystem, they are not partitions.
SSH in to a dho and run mount command.
-
/system and /data are mount points with a filesystem, they are not partitions.
SSH in to a dho and run mount command.
Yes, but most people dont know what is file system, but they often know what is partition. Thats why I wrote that way.
-
My DHO 804 sdcard appears to have only two Android partitions, "android_meta" and "android_expand". I think the "16" number mentioned elsewhere in this hackng thread is the number of mount points, and not partitions.
This is interesting. Are you certain that it's indeed the original image and it was never modified? Did you by any chance do anything with that menu in the scope's OS itself, where it says that the storage is damaged in the pull-down menu (that we use to connect to wifi)? I wonder if it would propose to recover the partitions or something like that -- I never cared to open it.
Here's mine. I copied it using dd after one or two boots of the scope, put it aside and operated only on its copies. Using the same sgdisk command:
$ sudo sgdisk --print sd-card-image
Creating new GPT entries in memory.
Disk sd-card-image: 61952000 sectors, 29.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 802A23EF-3BC6-40CF-87EF-68F6FC651712
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 61951966
Partitions will be aligned on 2048-sector boundaries
Total free space is 61951933 sectors (29.5 GiB)
Number Start (sector) End (sector) Size Code Name
It doesn't see anything. There is no partition table whatsoever.
Testdisk detects the partitions only after executing the "Analyse/Quick search" command:
Disk sd-card-image - 31 GB / 29 GiB - CHS 3857 255 63
Partition Start End Size in sectors
>* Linux 34 42 9 50 123 9 262144
P Linux 50 123 10 311 144 25 4194304 [system]
P Linux 311 144 26 313 154 33 32768
L Linux 392 34 27 3856 85 5 55652352
Once it detects these partitions (I have no idea how it's doing it, but judging by the speed with which it does it I don't think it's doing a full scan for FS signatures), it can save the partition table referencing them to the image, and then they can be mounted with standard tools like losetup. Otherwise, it's still possible to mount them, but you need to pass the start offset and size parameters to mount.
-
Disk sd-card-image - 31 GB / 29 GiB - CHS 3857 255 63
Partition Start End Size in sectors
>* Linux 34 42 9 50 123 9 262144
P Linux 50 123 10 311 144 25 4194304 [system]
P Linux 311 144 26 313 154 33 32768
L Linux 392 34 27 3856 85 5 55652352
If You select msdos partition table before quick search, then testdisk will assume 4 root partitions at max. Try to select GPT.
If You want to find much more things, then use binwalk.
-
After all that 2037 post what i read, I have one simple question....
Is all of that hack what work on DHO804 (BW 100MHz, 50 Mpts memory depth), work also on DHO802?
If i understand only difference between DHO804 and DHO802 is frontend channel number?!
Welcome! Yes, follow the guide by @AndyBig found here. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076) Have fun!
-
Is all of that hack what work on DHO804 (BW 100MHz, 50 Mpts memory depth), work also on DHO802?
Welcome! Yes, follow the guide by @AndyBig found here. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076) Have fun!
Umm... but what would be the target model to upgrade to? There is no DHO912 or 922, right?
-
Is all of that hack what work on DHO804 (BW 100MHz, 50 Mpts memory depth), work also on DHO802?
Welcome! Yes, follow the guide by @AndyBig found here. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076) Have fun!
Umm... but what would be the target model to upgrade to? There is no DHO912 or 922, right?
Sorry, Yes. @FileFixer you'll want to upgrade by applying the licenses, not by doing the Vendor (I.e., model number) upgrade.
FYI: there are 3 methods in that guide., and you don't have to make it a 900 series to get the upgrades.
-
FYI: there are 3 methods in that guide., and you don't have to make it a 900 series to get the upgrades.
Ah, right. I had not recalled that AndiBig's instructions covered all approaches. So approach 2 or 3 will work, but will only provide the bandwidth increase, not the additional decoders and increased memory.
-
If You select msdos partition table before quick search, then testdisk will assume 4 root partitions at max. Try to select GPT.
If You want to find much more things, then use binwalk.
Yes correct, the partition layout, even if there is no partition table as such, appears to be GPT:
Disk sd-card-image - 31 GB / 29 GiB - CHS 3857 255 63
Partition Start End Size in sectors
>P Linux filesys. data 548864 811007 262144
P Linux filesys. data 811008 5005311 4194304 [system]
P Linux filesys. data 5005312 5038079 32768
P Linux filesys. data 5047360 6071359 1024000 [rigol]
P Linux filesys. data 6299648 61951999 55652352
-
yeah! especially an MSO that you can get at ~$600 including LA probe ::) up the game? probably 1-2GSps MSO? buy siglent SDS800X! and those AFG and LA module sold separately. (ps: i dont mind mentioning the name here as i sense rigol fanboys dont get easily insulted ;D)
FWIW I don't think the DHO900 is a very good purchase for the LA.
(and I never have...)
The only DHO model really worth buying right now is the DHO804. The DHO1000 was good when they were selling them at$600. I wouldn't pay $1000 for one though.
If there was a DHO800 with AWG optino for $100 more? That would be cool...
I really don't care if there's a new Siglent. My DHO800 does what I need and some things about it seem better (eg. the display). It's also much smaller and has VESA/HDMI.
I hope I never see Siglent boys in Rigol threads saying the Rigol shouldn't be bought under any circumstances. ::)
-
OTOH, the 900 is a true MSO, the SDS800 only gets decimated display data from the acquisition hardware on the logic probe.
Interesting... :popcorn:
-
OTOH, the 900 is a true MSO, the SDS800 only gets decimated display data from the acquisition hardware on the logic probe.
Interesting... :popcorn:
A bit misleading, I think. The display data are of course decimated (as they are in any scope), except for the fastest time base settings: The display obviously does not have the same horizontal resolution as the acquisition buffer.
The difference for the entry-level Siglent MSOs, in my understanding, is that the full digital data reside in the external logic analyzer unit. But they can be decoded there with the full time resolution -- not limited to the down-sampled display contents like in the good ol' DS1054Z.
-
You are right. The point I was trying to make is that the triggering and processing is done in the external module and, although the signals are time-correlated in the scope screen, the 800X-HD doesn't get the full data. As such, it is not truly MSO, which shows in the triggering, for example.
It sure is useful, but not equivalent to the 2000 series Siglent scopes, the MSO5000, or the DHO900. Bugs notwithstanding anyway.
-
Can someone show me the filesystem data, just ssh into the dho and run "mount" command.
-
[...] it is not truly MSO, which shows in the triggering, for example.
It sure is useful, but not equivalent to the 2000 series Siglent scopes, the MSO5000, or the DHO900. Bugs notwithstanding anyway.
The triggering limitation caused by the separate acquisition of the digital data is that a mixed analog/digital pattern trigger is not supported, to my knowledge. But can the DHO900 or MSO5000 do that? It might be a hardware limitation in the Siglent, a software limitation in the Rigol -- but is the user-facing functionality any different?
But we digress... If I recall correctly,we only opened this can of worms after I referred to the DHO900's compromised sampling rates as an argument why there likely is a hardware bottleneck in the scope's downstream data processing. Which I still consider a valid argument -- but maybe we should have left it there; apologies for being part of the subsequent digression.
-
Can someone show me the filesystem data, just ssh into the dho and run "mount" command.
rk3399_rigol:/ # mount
rootfs on / type rootfs (ro,size=1832008k,nr_inodes=458002)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=1966596k,nr_inodes=491649,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime,gid=3009,hidepid=2)
sysfs on /sys type sysfs (rw,relatime)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime,mode=755)
/sys/kernel/debug/tracing on /sys/kernel/debug/tracing type tracefs (rw,relatime,mode=755)
none on /acct type cgroup (rw,relatime,cpuacct)
none on /dev/stune type cgroup (rw,relatime,schedtune)
tmpfs on /mnt type tmpfs (rw,relatime,size=1966596k,nr_inodes=491649,mode=755,gid=1000)
none on /config type configfs (rw,relatime)
none on /dev/memcg type cgroup (rw,relatime,memory)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
none on /dev/cpuset type cgroup (rw,relatime,cpuset,noprefix,release_agent=/sbin/cpuset_release_agent)
pstore on /sys/fs/pstore type pstore (rw,relatime)
/dev/block/mmcblk1p10 on /system type ext4 (ro,noatime,nodiratime,noauto_da_alloc,data=ordered)
/dev/block/mmcblk1p9 on /cache type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,noauto_da_alloc,data=ordered)
/dev/block/mmcblk1p11 on /metadata type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,noauto_da_alloc,data=ordered)
/dev/block/mmcblk1p16 on /data type ext4 (rw,dirsync,nosuid,nodev,noatime,nodiratime,discard,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/mmcblk1p15 on /rigol type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,noauto_da_alloc,data=ordered)
tmpfs on /storage type tmpfs (rw,relatime,size=1966596k,nr_inodes=491649,mode=755,gid=1000)
/data/media on /mnt/runtime/default/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6)
/data/media on /storage/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6)
/data/media on /mnt/runtime/read/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=23)
/data/media on /mnt/runtime/write/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7)
rk3399_rigol:/ #
-
Is all of that hack what work on DHO804 (BW 100MHz, 50 Mpts memory depth), work also on DHO802?
Welcome! Yes, follow the guide by @AndyBig found here. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076) Have fun!
My target will be extension from 70MHz bandwith to 100MHz and from 25Mpts to 50Mpts memory depth as options. For bandwith if I understand there will be BW7T10 and RLU for memory upgrade. To choose a model, maybe can be DHO812?!
In Zalea script for vendor.bin I see there is DHO812 model with BW7T10 and RLU options inside DHO8xx models.
Umm... but what would be the target model to upgrade to? There is no DHO912 or 922, right?
Sorry, Yes. @FileFixer you'll want to upgrade by applying the licenses, not by doing the Vendor (I.e., model number) upgrade.
FYI: there are 3 methods in that guide., and you don't have to make it a 900 series to get the upgrades.
My target will be extension from 70MHz bandwith to 100MHz and from 25Mpts to 50Mpts memory depth as options. For bandwith if I understand there will be BW7T10 and RLU for memory upgrade. To choose a model, maybe can be DHO812?!
In Zalea script for vendor.bin I see there is DHO812 model with BW7T10 and RLU options inside DHO8xx models.
-
My target will be extension from 70MHz bandwith to 100MHz and from 25Mpts to 50Mpts memory depth as options. For bandwith if I understand there will be BW7T10 and RLU for memory upgrade. To choose a model, maybe can be DHO812?!
In Zalea script for vendor.bin I see there is DHO812 model with BW7T10 and RLU options inside DHO8xx models.
Yes, DHO812 is what you want, since your hardware is missing the 3rd AFE(analog front end) Actually, once you apply the BW/Mem upgrades it doesn't matter if you leave it as a 802., you still get the performance, IIRC
-
My DHO 804 sdcard appears to have only two Android partitions, "android_meta" and "android_expand". I think the "16" number mentioned elsewhere in this hackng thread is the number of mount points, and not partitions.
Well, my sdcard might very well be encrypted.
The GUID number for type (used by android) seems to suggest encryption is used.
If the DHO has no HSM to store keys (or does it?), then the question becomes, are the keys on the sd card, and if so maybe they are in the _meta partition. I can't mount _meta either.
Edit: hexdump -C on the _expand partition does show some ascii stuff up front, seems like boot info about cpu and some settings. I am trying to find the expand_ .key file that's used by vold on Android. Without an HSM to access the vold key has to be on sdcard as non-encrypted. The mystery gets deeper.
I used testdisk on Linux on a DD imaged backup of my original Nov/2023 SDCard, and it found several partitions, EXT4 and Unallocated(like other's have) --and most importantly-- I noticed they were all Deleted. Note: this was only using the quick scan. Deep scan revealed 100's
I undeleted the main partition, and I was able to do a lot more with the card. In my case, it's a 64G card that I'm currently thrashing on, and I was able to resize the 29.5 gigs to full size of the card using "disks" GUI tool in Ubuntu.
Also, It appears that Rigol had an image that was slightly too large for the target cards, thus making it difficult to image. i.e., DD complains about 1 byte not getting copied when it finishes quits. Other users have reported similar findings all the way back when the first scopes were shipped.
I think it might be interesting to make a new card with partitions then imagecopy the useful partitions over. I don't really know how, but I'll probably try some day.
Don't use dd, use ddrescue.
-
"new" dho 800-900 "high res" models? So new that when you click Models and Pricing there's none listed as 50M. ;)
Seems like they just opened them up to max? (corrected by next post). Bad marketing I guess.
https://www.rigolna.com/dho/ (https://www.rigolna.com/dho/)
-
"new" dho 800-900 "high res" models? So new that when you click Models and Pricing there's none listed as 50M. ;)
Seems like they just opened them up to max?
https://www.rigolna.com/dho/ (https://www.rigolna.com/dho/)
These are "new" as in "the newest models in our offering". They are the DHO800 and 900 as originally launched, just with a copy & paste error on the title page (incorrectly stating 50 MPts memory for the DHO800).
-
Is all of that hack what work on DHO804 (BW 100MHz, 50 Mpts memory depth), work also on DHO802?
Welcome! Yes, follow the guide by @AndyBig found here. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076) Have fun!
My target will be extension from 70MHz bandwith to 100MHz and from 25Mpts to 50Mpts memory depth as options. For bandwith if I understand there will be BW7T10 and RLU for memory upgrade. To choose a model, maybe can be DHO812?!
In Zalea script for vendor.bin I see there is DHO812 model with BW7T10 and RLU options inside DHO8xx models.
Umm... but what would be the target model to upgrade to? There is no DHO912 or 922, right?
Sorry, Yes. @FileFixer you'll want to upgrade by applying the licenses, not by doing the Vendor (I.e., model number) upgrade.
FYI: there are 3 methods in that guide., and you don't have to make it a 900 series to get the upgrades.
My target will be extension from 70MHz bandwith to 100MHz and from 25Mpts to 50Mpts memory depth as options. For bandwith if I understand there will be BW7T10 and RLU for memory upgrade. To choose a model, maybe can be DHO812?!
In Zalea script for vendor.bin I see there is DHO812 model with BW7T10 and RLU options inside DHO8xx models.
An 802 will likley run as a 924 vendor bin, but 2ch only. What the gui will look like will be fun. But even so, and 802 can become an 812 easily.
-
Don't use dd, use ddrescue.
If there is no problem with reading data, then dd, ddrescue and cp will do same job. cp cant do offsets but its faster.
-
The DRAM or its interface to the FPGA is a likely suspect.
Yes, I think so too. It’s not for nothing that they installed a cheaper FPGA compared to the 1000/4000 series.
That's hardly fair. Street price is $299USD for the DHO802 and the Zync is $100 of the BOM cost for just one part. I don't think there was room for anything more(much. less an Artix 7), and still stay in business.
-
Don't use dd, use ddrescue.
You Linux guys have more tools than you know how to use. --And each of you has better tools than everyone else... ;)
Seriously tho': @Randy222, ddrescue is not built into Linux and dd is, so that's what I know how to use. I appreciate the advice, I got lucky installing & using testdisk, and can't wait to try ddrescue.
-
The DRAM or its interface to the FPGA is a likely suspect.
Yes, I think so too. It’s not for nothing that they installed a cheaper FPGA compared to the 1000/4000 series.
That's hardly fair. Street price is $299USD for the DHO802 and the Zync is $100 of the BOM cost for just one part. I don't think there was room for anything more(much. less an Artix 7), and still stay in business.
I think we can safely assume that Rigol don't pay $100. And the Zync is certainly a good choice for the DHO800!
With the DHO900, I still like the theory that Rigol originally planned to get extra DRAM bandwidth from the additional DRAM chip on the main board, and had to fall back to the compromised sampling rates late in the game since they could not configure the FPGA to feed both DRAM channels at the required speed. Maybe that's yet to come? I think they must be working on successors for the DHO1000 and 4000 series (with MSO capability) right now...
-
I've followed most of this thread but not all. Some of the work that's been accomplished is incredible.
I was not paying attention for a while to the thread and came back to read a good bit of text about certificates and keys.
I wanted to chime-in that at the very least a person who wanted to sign software as Rigol would need Rigol's (Certificate Authority) private key (ultimately stripped of the passphrase) that was used to sign software - or whatever else you may want to digitally sign. I admittedly have not looked at any of the certs or keys and I have not done any investigation of rigol's infrastructure - like their CAs - to see how their systems might be configured.
I do know that there would be no valid reason for Rigol to leave the private key on the device. I don't think any amount of searching is going to turn up the private key - which would be needed, due to the way PKI functions.
-
You Linux guys have more tools than you know how to use. --And each of you has better tools than everyone else... ;)
Seriously tho': @Randy222, ddrescue is not built into Linux and dd is, so that's what I know how to use. I appreciate the advice, I got lucky installing & using testdisk, and can't wait to try ddrescue.
All right, let's play this game for a moment.
Neither dd, not ddrescue is built into Linux. But they may be installed in some operating systems using Linux.
Both are available via standard package repositories in Debian and derivatives, and one of them is always installed, as it comes in a package that has the "required" priority.
...and yes, there is no reason to go for ddrescue unless you need to recover data from a partially faulty medium.
-
If somebody wants to play with HW number, there is simpler way, than I wrote before.
printf '\x8' > /dev/hdcode_gpio
Of course, get rid of hdcode_gpio module first, by unloading it (rmmod hdcode_gpio) and commenting it out in /rigol/shell/start_rigol_app.sh - above command can go into this file (personally I did it at very beginning).
-
I do know that there would be no valid reason for Rigol to leave the private key on the device. I don't think any amount of searching is going to turn up the private key - which would be needed, due to the way PKI functions.
Yeah that's obvious. That part of the discussion ended up with two questions that have yet to be answered: a) where is the keystore that the respective public key is stored in and b) is it possible to add an arbitrary public key to that store? Technically we have root, so the answer to the second one should be "yes", but it's not certain.
-
You Linux guys have more tools than you know how to use. --And each of you has better tools than everyone else... ;)
Seriously tho': @Randy222, ddrescue is not built into Linux and dd is, so that's what I know how to use. I appreciate the advice, I got lucky installing & using testdisk, and can't wait to try ddrescue.
All right, let's play this game for a moment.
Neither dd, not ddrescue is built into Linux. But they may be installed in some operating systems using Linux.
Both are available via standard package repositories in Debian and derivatives, and one of them is always installed, as it comes in a package that has the "required" priority.
...and yes, there is no reason to go for ddrescue unless you need to recover data from a partially faulty medium.
Linux is not a system. Its just a kernel which do very low-level staff. In Debian (one of reasons why I like this distro) You have incredible amount of software in repositories. I dont see any reason to use Ubuntu which is not user-friendly like its at first glance.
-
I think we can safely assume that Rigol don't pay $100. And the Zync is certainly a good choice for the DHO800!
With the DHO900, I still like the theory that Rigol originally planned to get extra DRAM bandwidth from the additional DRAM chip on the main board, and had to fall back to the compromised sampling rates late in the game since they could not configure the FPGA to feed both DRAM channels at the required speed. Maybe that's yet to come? I think they must be working on successors for the DHO1000 and 4000 series (with MSO capability) right now...
Well, FPGA's are expensive parts. You know that better than most.
BTW: Low quantity(1-10 piece) pricing here is roughly $150, and 1k pricing is around $110., I assumed they have preferred pricing, and chose $100 as a pretty realistic price point, based on experience. So maybe they're $80? Still, that's a pretty decent chunk of the BOM cost for one part.
And yeah, I did a bit of feature investigation into the Zync, and those are amazing little parts. They're certainly faster and more capable looking than some here are giving them credit. I think your "fall back to compromised..." statement is the most likely scenario for why they're not getting more and deeper acquisition on the DHO900's. I would love to sit down with their team and hear their story.
-
Neither dd, not ddrescue is built into Linux. But they may be installed in some operating systems using Linux.
Yep., sorry. I stand corrected. I have never installed or used Linux on a system that didn't have dd on it "out of the box". Maybe back in 1991 or '92 when I installed it for the first time(from a CDROM from the back of a 1200 page "Linux Bible" book, but never in modern times.
...and yes, there is no reason to go for ddrescue unless you need to recover data from a partially faulty medium.
Which is pretty much the case with this "partially faulty" SDCard., ;D
-
I do know that there would be no valid reason for Rigol to leave the private key on the device. I don't think any amount of searching is going to turn up the private key - which would be needed, due to the way PKI functions.
Yeah that's obvious. That part of the discussion ended up with two questions that have yet to be answered: a) where is the keystore that the respective public key is stored in and b) is it possible to add an arbitrary public key to that store? Technically we have root, so the answer to the second one should be "yes", but it's not certain.
Answering both of those questions is not going to help you sign software as Rigol.
-
Answering both of those questions is not going to help you sign software as Rigol.
But wouldn't it help you sign software as "someone who can sign software which gets all privileges on this scope"? Create your own private key, place the corresponding public key in the scope's store for trusted keys, then sign apps with your own private key -- and the scope should accept them?
I understand that the public keys for "trusted keys", stored in the scope, are secured in some way for that very reason. (In a TPM module in the SOC?) So this may not be an approach that works in practice. But if one could add a new public key, it should do the trick, right?
-
But wouldn't it help you sign software as "someone who can sign software which gets all privileges on this scope"? Create your own private key, place the corresponding public key in the scope's store for trusted keys, then sign apps with your own private key -- and the scope should accept them?
I understand that the public keys for "trusted keys", stored in the scope, are secured in some way for that very reason. (In a TPM module in the SOC?) So this may not be an approach that works in practice. But if one could add a new public key, it should do the trick, right?
No. There is a key that signs the kernel assembly. The system application must be signed with the same key, and not some other one, even if it is also super trusted :)
-
Answering both of those questions is not going to help you sign software as Rigol.
But we don't need to. We need to sign APKs with a key that the system would trust. How do we make it trust a key? Right, we add the respective public key to the keystore.
-
No. There is a key that signs the kernel assembly. The system application must be signed with the same key, and not some other one, even if it is also super trusted :)
Then how/when exactly are these keys compared?
-
No. There is a key that signs the kernel assembly. The system application must be signed with the same key, and not some other one, even if it is also super trusted :)
Then how/when exactly are these keys compared?
I don’t know such details, but I think that the signature of the kernel itself is checked during boot using the key specified as system. In fact, we need to re-sign the kernel itself with our key in order to be able to sign system applications in the future.
But I could be wrong.
-
yeah! especially an MSO that you can get at ~$600 including LA probe ::) up the game? probably 1-2GSps MSO? buy siglent SDS800X! and those AFG and LA module sold separately. (ps: i dont mind mentioning the name here as i sense rigol fanboys dont get easily insulted ;D)
FWIW I don't think the DHO900 is a very good purchase for the LA.
(and I never have...)
If there was a DHO800 with AWG optino for $100 more? That would be cool...
maybe i was not clear enough... MSO at ~$600 with LA probe and AWG module and function such as bode plot included... granted LA and AWG GUI is at stage of toyish level, but lets hope it can be better with FW upgrade from rigol and hack route fropm users.
-
Here is a good battery for an oscilloscope, enough for a whole day of work, 28 lithium cells with a capacity of 3200 mAh each :) ;D
-
Answering both of those questions is not going to help you sign software as Rigol.
But we don't need to. We need to sign APKs with a key that the system would trust. How do we make it trust a key? Right, we add the respective public key to the keystore.
Don't those keys need to be signed by the master key?
-
Here is a good battery for an oscilloscope, enough for a whole day of work, 28 lithium cells with a capacity of 3200 mAh each :) ;D
How many days to charge that?
-
Here is a good battery for an oscilloscope, enough for a whole day of work, 28 lithium cells with a capacity of 3200 mAh each :) ;D
How many days to charge that?
thats a 28-35 li-on batteries that costs $3 each the cheap and descent capacity... hence we are talking about $85-$100 cost... not to mention assembling them. if i want that kind of setup, i just buy a small 4Ah SLA battery. easier to setup and charge, but that just me maybe.
-
Don't those keys need to be signed by the master key?
Whatever the "master key" is, it is at the end of the day still compared against a known public key, stored somewhere. That may ultimately end up being in the bootloader, but as long as it is unlocked, we should be able to modify it as we wish. But how exactly it is done, I have no idea. Depends on implementation.
-
if i want that kind of setup, i just buy a small 4Ah SLA battery
...which won't last an hour.
-
How many days to charge that?
Three or four hours :)
thats a 28-35 li-on batteries that costs $3 each the cheap and descent capacity... hence we are talking about $85-$100 cost... not to mention assembling them. if i want that kind of setup, i just buy a small 4Ah SLA battery. easier to setup and charge, but that just me maybe.
Yes, their cost is about that. But this, of course, is a joke. I just repacked this battery with new cells today :) In general, I’m thinking about assembling an external battery with 8 or 12 of these cells - 4S2P or 4S3P. For a voltage of 12-16 volts and a capacity of 6400 or 9200 mAh.
-
I'm getting one of these:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2067341;image)
-
if i want that kind of setup, i just buy a small 4Ah SLA battery
...which won't last an hour.
i mean the normal SLA car battery 40Ah still cheaper... or we can just make a cigarette plug for it.
-
I installed RLU and BW7T10 options on a DHO804 with FW 00.01.02
100M BW works (no entry in option list, only "Max BW: 100M" in "Model").
But the 50M memory option does not show up in UI and I can select 50M only on CH2, every other channel is limited to 25M (single channel mode of course)
If I try to apply the RLU code again it says "option already activated".
I tried changing model to 814 and replacing contents of RLU.lic with the fresh generated one for 814, but it does not change anything.
Am I doing something wrong or is this a bug?
EDIT: ebastler is right, trigger on CH2 |O
Regarding fan noise: I just added 100Ohm in series to the stock fan, not noticeable anymore. CPU stays below 70°C (50°C in idle) at 20°C ambient, heatsink is 45-50°C. So maybe something around 70Ohm would be better.
-
I'm getting one of these:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2067341;image)
Such a suitcase probably weighs as much as five oscilloscopes? :o
-
i mean the normal SLA car battery 40Ah still cheaper... or we can just make a cigarette plug for it.
You will also need to buy a cart for it :))
-
I can select 50M only on CH2, every other channel is limited to 25M (single channel mode of course)
You are probably still triggering on channel 2? So that channel is still active, even if it is not displayed, and will take up its share of the memory. If you display and trigger from CH1 (or 3 or 4) only, you should have the full memory available for them.
-
i mean the normal SLA car battery 40Ah still cheaper... or we can just make a cigarette plug for it.
You will also need to buy a cart for it :))
Good idea! It can power the cart, too...
-
@Fungus -- don't attach that battery to your VESA mount! ;)
(Well, maybe it can serve as the base for a VESA mount...)
Does the price of that no-name battery include fire insurance?
-
@AndyBig You are familiar with APKLab. I tried probably everything. I can deassemble original apk, rebuild it and install.
Same with apk from You - Your changes are visible. But when I made my own modifications in decompiled code (in many files at the same time, including displayed text) rebuild and install it, nothing is changed. I tried older versions of apktool (of course I changed APKLab config and to be sure I deleted ~/.apklab/apktool_2.9.3.jar).
Is there maybe some cache preventing changes?
BTW. Its hard to search thru this topic with that many posts. Can You give me url to Your repo?
-
@AndyBig You are familiar with APKLab. I tried probably everything. I can deassemble original apk, rebuild it and install.
Same with apk from You - Your changes are visible. But when I made my own modifications in decompiled code (in many files at the same time, including displayed text) rebuild and install it, nothing is changed. I tried older versions of apktool (of course I changed APKLab config and to be sure I deleted ~/.apklab/apktool_2.9.3.jar).
Is there maybe some cache preventing changes?
No, there are no caches there, all changes are applied directly, without additional actions.
What files exactly did you change? Was the modified file taken from the /dist directory?
BTW. Its hard to search thru this topic with that many posts. Can You give me url to Your repo?
Yes, of course - https://github.com/Andy-Big/DHO800_900_Sparrow_project
-
What files exactly did you change? Was the modified file taken from the /dist directory?
Exactly. After every rebuild date/time of this new apk was changed to actual. Even I tried to to manual installation with same result.
However... Now i tried to move generated apk into another folder, unpack+dissasemble it and rebuild it back - looks like it works (because of crash...). Of course that is not good way to test changes.
Maybe now I try to make it from beginning from Your repo.
BTW. FPGA Image from DHO1000 works, however after reflashing I see no changes - not at all. BTW2. PLL is driven by a kernel module.
Edit:
What files exactly did you change?
Mostly inside: smali_classes2/com/rigol/scope
-
However... Now i tried to move generated apk into another folder, unpack+dissasemble it and rebuild it back - looks like it works (because of crash...). Of course that is not good way to test changes.
I haven't encountered anything like this. I disassembled it through APKLab, and put it back together through it - everything worked.
Mostly inside: smali_classes2/com/rigol/scope
Well, yes, that's right. I just thought that maybe you changed the .java files, then nothing will really happen, these files are not involved in the build :)
-
I disassembled it through APKLab
I was using APKLab, but previously it was disassembled by apktool (without APKLab) Maybe thats the reason.
maybe you changed the .java files
Only one .java file also, but mostly files as I said before.
-
BTW. FPGA Image from DHO1000 works, however after reflashing I see no changes - not at all. BTW2. PLL is driven by a kernel module.
The DHO1000 has a completely different FPGA (Artix) and its firmware (configuration) cannot work on the FPGA in the DHO800/900 (Zync). There are no changes, probably because foreign firmware is not accepted by this FPGA and its native firmware is loaded into it.
-
I was using APKLab, but previously it was disassembled by apktool (without APKLab) Maybe thats the reason.
Yes, most likely because of this.
Only one .java file also, but mostly files as I said before.
This is useless, .java files are not compiled when building :)
-
However... Now i tried to move generated apk into another folder, unpack+dissasemble it and rebuild it back - looks like it works (because of crash...). Of course that is not good way to test changes.
I haven't encountered anything like this. I disassembled it through APKLab, and put it back together through it - everything worked.
apklab, apkeditor, and apktool all work for me. Each has it's quarks. Realign zip (apk) and signing I do on a windows machine that has android studio and the platform & build tools.
-
BTW. FPGA Image from DHO1000 works, however after reflashing I see no changes - not at all. BTW2. PLL is driven by a kernel module.
The DHO1000 has a completely different FPGA (Artix) and its firmware (configuration) cannot work on the FPGA in the DHO800/900 (Zync). There are no changes, probably because foreign firmware is not accepted by this FPGA and its native firmware is loaded into it.
Maybe Im wrong, but its the same datasheet. And it works - currently I dont see completely any changes after that.
EDIT: Yeah, I missed last part of Your post. "...firmware is not accepted by this..."
-
apklab, apkeditor, and apktool all work for me. Each has it's quarks. Realign zip (apk) and signing I do on a windows machine that has android studio and the platform & build tools.
I settled on VS Code + APKLab as the most convenient option. And it’s convenient to edit files, and all build processes are automated :)
-
If You select msdos partition table before quick search, then testdisk will assume 4 root partitions at max. Try to select GPT.
If You want to find much more things, then use binwalk.
Yes correct, the partition layout, even if there is no partition table as such, appears to be GPT:
Disk sd-card-image - 31 GB / 29 GiB - CHS 3857 255 63
Partition Start End Size in sectors
>P Linux filesys. data 548864 811007 262144
P Linux filesys. data 811008 5005311 4194304 [system]
P Linux filesys. data 5005312 5038079 32768
P Linux filesys. data 5047360 6071359 1024000 [rigol]
P Linux filesys. data 6299648 61951999 55652352
I made image of sdcard and then connected it to /dev/loop9, ran testdisk on that device.
I get the same as you show here, but did you try to use the p, c, and C hotkeys on any dir or file? I can see filenames and such in the various slices testdisk shows, same structure as in the live DHO, but when I try to copy out a file the C just places an empty folder.
Even after testdisk can you mount the block device ?
Also noted, when I run testdisk on that loop9, it throws a warning "the partion table detected is GPT EFI, do not select none".
-
If You select msdos partition table before quick search, then testdisk will assume 4 root partitions at max. Try to select GPT.
If You want to find much more things, then use binwalk.
Yes correct, the partition layout, even if there is no partition table as such, appears to be GPT:
Disk sd-card-image - 31 GB / 29 GiB - CHS 3857 255 63
Partition Start End Size in sectors
>P Linux filesys. data 548864 811007 262144
P Linux filesys. data 811008 5005311 4194304 [system]
P Linux filesys. data 5005312 5038079 32768
P Linux filesys. data 5047360 6071359 1024000 [rigol]
P Linux filesys. data 6299648 61951999 55652352
I made image of sdcard and then connected it to /dev/loop9, ran testdisk on that device.
I get the same as you show here, but did you try to use the p, c, and C hotkeys on any dir or file? I can see filenames and such in the various slices testdisk shows, same structure as in the live DHO, but when I try to copy out a file the C just places an empty folder.
Even after testdisk can you mount the block device ?
Nah.. I used offsets shown in testdisk to mount it using another terminal emulator.
Edit: testdisk works directly from a image file - I dont see any point to use loop.
-
Maybe Im wrong, but its the same datasheet. And it works - currently I dont see completely any changes after that.
No, they are quite different. The Zynq Z-7015 (DHO800/900) has a much less powerful FPGA than the XC7A100T (DHO1000). Not to mention that Zynq has an additional integrated processor core.
-
Don't use dd, use ddrescue.
If there is no problem with reading data, then dd, ddrescue and cp will do same job. cp cant do offsets but its faster.
And somehow you know that every block on a block device are ok? And just to be clear, not everything is a "file". Block devices can be a file, they can also be ext hardware like sdcard, or spindle drive, or ssd.
The /dev/[files] are mappings, this however does not mean my /dev/sda is a img file somewhere on a mounted filesystem, it could be ext attached hardware.
When I image a disk to /home/myimage.img, "stat myimage.img" shows inode "reg file". If I map that img to /dev/loop9, "stat /dev/loop9" shows inode block device. 100% all files. This is not the same as /dev/sdb that maps to my USB sdcard.
dd has limitations, gddrescue, ddrescuew, and a few other "ddrescue" variants get beyond some putfalls of dd. ;)
If it's a file, dd should be problem free. If it's hardware then something other than dd is a better choice.
-
I've tried to go through the thread, but it's a little daunting reading so many pages of posts. Is the bandwidth and memory hack stable enough that there's no point spending the extra on the DHO814 instead of the DHO804? I saw a recent comment on Youtube that someone was having issues applying it to the latest firmware, is that going to be a problem?
-
I've tried to go through the thread, but it's a little daunting reading so many pages of posts. Is the bandwidth and memory hack stable enough that there's no point spending the extra on the DHO814 instead of the DHO804? I saw a recent comment on Youtube that someone was having issues applying it to the latest firmware, is that going to be a problem?
No, you can easily get 814 from 804, and even 924 with full bandwidth.
-
Don't use dd, use ddrescue.
If there is no problem with reading data, then dd, ddrescue and cp will do same job. cp cant do offsets but its faster.
And somehow you know that every block on a block device are ok? And just to be clear, not everything is a "file". Block devices can be a file, they can also be ext hardware like sdcard, or spindle drive, or ssd.
dd has limitations, gddrescue, ddrescuew, and a few other "ddrescue" variants get beyond some putfalls of dd. ;)
If it's a file, dd should be problem free. If it's hardware then something other than dd is a better choice.
Im using cp to flash SD cards (and other devices) without any problems so far.
Maybe Im wrong, but its the same datasheet. And it works - currently I dont see completely any changes after that.
No, they are quite different. The Zynq Z-7015 (DHO800/900) has a much less powerful FPGA than the XC7A100T (DHO1000). Not to mention that Zynq has an additional integrated processor core.
https://www.mouser.com/pdfDocs/zynq-7000-product-selection-guide.pdf (https://www.mouser.com/pdfDocs/zynq-7000-product-selection-guide.pdf)
Maybe it is, but (probably) nobody tried to dissasemble it to see what was changed between those scope series.
-
If You select msdos partition table before quick search, then testdisk will assume 4 root partitions at max. Try to select GPT.
If You want to find much more things, then use binwalk.
Yes correct, the partition layout, even if there is no partition table as such, appears to be GPT:
Disk sd-card-image - 31 GB / 29 GiB - CHS 3857 255 63
Partition Start End Size in sectors
>P Linux filesys. data 548864 811007 262144
P Linux filesys. data 811008 5005311 4194304 [system]
P Linux filesys. data 5005312 5038079 32768
P Linux filesys. data 5047360 6071359 1024000 [rigol]
P Linux filesys. data 6299648 61951999 55652352
I made image of sdcard and then connected it to /dev/loop9, ran testdisk on that device.
I get the same as you show here, but did you try to use the p, c, and C hotkeys on any dir or file? I can see filenames and such in the various slices testdisk shows, same structure as in the live DHO, but when I try to copy out a file the C just places an empty folder.
Even after testdisk can you mount the block device ?
Nah.. I used offsets shown in testdisk to mount it using another terminal emulator.
Edit: testdisk works directly from a image file - I dont see any point to use loop.
mounted using what type of filesystem?
I was trying to mount the loop block device.
Emulator? We can use losetup with offset and sizelimit switches. I try that next.
-
I've tried to go through the thread, but it's a little daunting reading so many pages of posts. Is the bandwidth and memory hack stable enough that there's no point spending the extra on the DHO814 instead of the DHO804? I saw a recent comment on Youtube that someone was having issues applying it to the latest firmware, is that going to be a problem?
As mentioned, yes.
If you want 4ch 800, get the 804 and turn it into a 924. That's how my 804 runs.
It's not hard, a bit tricky though, you really need to know adb and how to connect via ssh. The tool created by zelea2 runs directly on the dho.
Once you get access to the dho, adb pull the various files for backup reasons. The whole process is rather painless.
-
Maybe it is, but (probably) nobody tried to dissasemble it to see what was changed between those scope series.
No one has tried to disassemble the DHO1000? Of course someone tried :)
https://www.youtube.com/watch?v=qEpkVa_ysaw (https://www.youtube.com/watch?v=qEpkVa_ysaw)
-
I've tried to go through the thread, but it's a little daunting reading so many pages of posts. Is the bandwidth and memory hack stable enough that there's no point spending the extra on the DHO814 instead of the DHO804? I saw a recent comment on Youtube that someone was having issues applying it to the latest firmware, is that going to be a problem?
No, you can easily get 814 from 804, and even 924 with full bandwidth.
One of my reasons why I did buy 924S was different passive probes (350 MHz instead of 150 MHz) included.
mounted using what type of filesystem?
I was trying to mount the loop block device.
mount -t ext4 imageFile.bin /mount/point -o offsetAndSizeOptions
In past years something was changed and I dont need to add option loop - mount does this automatically.
It's not hard, a bit tricky though, you really need to know adb and how to connect via ssh. The tool created by zelea2 runs directly on the dho.
Once you get access to the dho, adb pull the various files for backup reasons. The whole process is rather painless.
adb root
adb shell
So there is no need to use ssh at all.
-
Maybe it is, but (probably) nobody tried to dissasemble it to see what was changed between those scope series.
No one has tried to disassemble the DHO1000? Of course someone tried :)
https://www.youtube.com/watch?v=qEpkVa_ysaw (https://www.youtube.com/watch?v=qEpkVa_ysaw)
I meant flash binary, not scope teardown.
-
I meant flash binary, not scope teardown.
Ah, got it. Here's another disappointment - parsing the FPGA configuration binary is almost impossible, at least for any practical purpose.
-
mount -t ext4 imageFile.bin /mount/point -o offsetAndSizeOptions
In past years something was changed and I dont need to add option loop - mount does this automatically.
adb root
adb shell
So there is no need to use ssh at all.
adb is a bit clunky, unless you use an add-on gui app.
I use putty for ssh, open putty, dbl-click my "rigol" profile name, i'm in.
I only use adb to push and pull files, and where bin tools in ssh have been deprecated and can only be used via adb, like package lists, need to use 'adb shell cmd package'. I said it before, Android is a wonky system, way overly convoluted, but I guess goole needed to say they had their own linux OS.
-
adb is a bit clunky, unless you use an add-on gui app.
I use putty for ssh, open putty, dbl-click my "rigol" profile name, i'm in.
I only use adb to push and pull files, and where bin tools in ssh have been deprecated and can only be used via adb, like package lists, need to use 'adb shell cmd package'. I said it before, Android is a wonky system, way overly convoluted, but I guess goole needed to say they had their own linux OS.
adb shell works little slow (I didnt compare it to ssh beacuse I didnt use it on this scope) if You meant this.
Putty - so looks like You are using Windows. That also can make difference.
About Android, yeah, they took Linux kernel and they made Windows 3.11 from it. Thats why I made my Debian build to work on this scope - but X is little unstable, with same error in logs after every crash.
-
mounted using what type of filesystem?
I was trying to mount the loop block device.
mount -t ext4 imageFile.bin /mount/point -o offsetAndSizeOptions
In past years something was changed and I dont need to add option loop - mount does this automatically.
[/code]
Ok, I found it.
It's 512 setcor size. So, when mounting using the START number found from testdisk, offset for mount is really -o offset=$((512* [start number])) , so example somethig like mount -t ext4 -o offset=$((512*811088)) [PATH_TO_IMG] [PATH_TO_EMPTY_DIR]
So for readers here, image the sdcard (I use ddrescue or the like, not dd), then you can run testdisk on the image (choose EFI/GPT a partition header type), do "anaylse" to find the START numbers of the slice, then you can mount that slice per above. Best to view the slices using the 'p' hotkey to see if the slice is empty or not, as there's no reason to mount an empty slice.
-
I have 924S, later I will do some photosmodules
@norbert.kiszka I still dare to remind you.....
-
I have 924S, later I will do some photosmodules
@norbert.kiszka I still dare to remind you.....
As for now I never removed heatsink. I was going to modify one channel, but I didnt. Also I cant find thermopads - Im not sure if I can reuse existing ones after heatisnk removal (maybe clean them with isopropyl?).
Anyway, I just did two photos just above heatsink. If You need something more (right now without removing heatsink), just give me a sign.
If You going to change only HW number, then read my previous posts about it, because You can change it in "soft" way, without changing resistors or decompiling anything.
-
After some sdcard edits, got my scope back.
I believe this older droid uses sdcardfs on android_meta and android_expand partitions. sdcardfs apparently is a layer that does not use block addressing.
From what I know of and read about sdcardfs, ext4 is the underlying filesystem. Yep, android is as goofy as they come.
Another interesting note, vold has expand encryption keys in /data/misc/vold dir
-
I have 924S, later I will do some photosmodules
@norbert.kiszka I still dare to remind you.....
As for now I never removed heatsink. I was going to modify one channel, but I didnt. Also I cant find thermopads - Im not sure if I can reuse existing ones after heatisnk removal (maybe clean them with isopropyl?).
Anyway, I just did two photos just above heatsink. If You need something more (right now without removing heatsink), just give me a sign.
If You going to change only HW number, then read my previous posts about it, because You can change it in "soft" way, without changing resistors or decompiling anything.
Yes, I would like to see a photo of the back of the board. Thank you...... By the way, it is not necessary to remove the radiator for this.... Your method is good, but when updating the firmware it needs to be repeated... I would like to permanently change the HW configuration.... configuration resistors are located on the reverse side boards.... Thanks again!!!
-
After some sdcard edits, got my scope back.
I believe this older droid uses sdcardfs on android_meta and android_expand partitions. sdcardfs apparently is a layer that does not use block addressing.
From what I know of and read about sdcardfs, ext4 is the underlying filesystem. Yep, android is as goofy as they come.
Good to hear that. Make some backup of working sd card image (at least in two places) and when You will need to do some write test on image, then dont forget to make another copy for that.
Speaking of ext4 - that is great file system, probably best one in world. Long time ago I was using ext3 and after I decided to use brand new ext4 it was crazy fast, especially with fsck (seconds instead of hours). Some people can say ReiserFS is better, but its not longer developed, because currently Hans Reiser is in jail.
Yes, I would like to see a photo of the back of the board. Thank you...... By the way, it is not necessary to remove the radiator for this.... Your method is good, but when updating the firmware it needs to be repeated... I would like to permanently change the HW configuration.... configuration resistors are located on the reverse side boards.... Thanks again!!!
Damn... After upgrading by GEL file, its just two lines of code - how often You do updates? :)
Currently Im working on some software changes, and right now probably I have some "small" breakthrough.
-
Scope cpu temp. for stock fan configurations only.
In Utility , in the self-check board test, what do your ambient and cpu temps say?
Some many posts back I mentioned I added thermal paste between the heatsink pads, trying to ascertain any benefits.
My 804 scope has been on for about 1hr, it's doing no work (all channels are off) temps are
cpu_chip 52.7
cpu_amb 48.7
room amb is 23.5
-
Scope cpu temp. for stock fan configurations only.
In Utility , in the self-check board test, what do your ambient and cpu temps say?
Some many posts back I mentioned I added thermal paste between the heatsink pads, trying to ascertain any benefits.
My scope has been on for about 1hr, it's doing no work (all channels are off) temps are
cpu_chip 52.7
cpu_amb 48.7
room amb is 23.5
Mine had ~56/52 respectively at ~21-22 room ambient.
-
Is the bandwidth and memory hack stable enough that there's no point spending the extra on the DHO814 instead of the DHO804?
Yes.
I think we're overdue for a separate "how to unlock a DHO804" thread now. This one has devolved into Android hacking.
-
If You going to change only HW number, then read my previous posts about it, because You can change it in "soft" way, without changing resistors or decompiling anything.
I have some questions about this.
If they can do it via shoving some data into gpio char device, then why use resistors at all?
If my 804 runs as a 924 vendor.bin, what does the scope gain by changing the HW type number? Does HW type number just unlock features without need for a lic file?
-
Is the bandwidth and memory hack stable enough that there's no point spending the extra on the DHO814 instead of the DHO804?
Yes.
I think we're overdue for a separate "how to unlock a DHO804" thread now. This one has devolved into Android hacking.
The scope is an android, there's really no way to de-couple the two. A hack of droid is a hack of the scope device, a hack of the scope device is a hack of the droid. ;)
-
If You going to change only HW number, then read my previous posts about it, because You can change it in "soft" way, without changing resistors or decompiling anything.
I have some questions about this.
If they can do it via shoving some data into gpio char device, then why use resistors at all?
If my 804 runs as a 924 vendor.bin, what does the scope gain by changing the HW type number? Does HW type number just unlock features without need for a lic file?
App reads file /dev/hdcode_gpio many times (according to strace output) and also its being read by one script in DHO1000 and DHO4000 models. I tried to make DHO804 from DHO924S by changing this byte, but it doesnt change anything - maybe its used only if model in vendor.bin is DHO800.
In my scope I can even change this to 255 without any result in app, beside this number in "about".
-
I think we're overdue for a separate "how to unlock a DHO804" thread now. This one has devolved into Android hacking.
The scope is an android, there's really no way to de-couple the two. A hack of droid is a hack of the scope device, a hack of the scope device is a hack of the droid. ;)
Yes, but most people are only interested in getting more bandwidth and 50M memory on thier 804.
Finding the info in this thread isn't easy...
-
BTW. FPGA Image from DHO1000 works, however after reflashing I see no changes - not at all. BTW2. PLL is driven by a kernel module.
The DHO1000 has a completely different FPGA (Artix) and its firmware (configuration) cannot work on the FPGA in the DHO800/900 (Zync). There are no changes, probably because foreign firmware is not accepted by this FPGA and its native firmware is loaded into it.
I don't think he is ready to accept the architectural differences between the 2 platforms/FPGAs. :palm: Kudos to you for trying to help.
-
If You going to change only HW number, then read my previous posts about it, because You can change it in "soft" way, without changing resistors or decompiling anything.
I have some questions about this.
If they can do it via shoving some data into gpio char device, then why use resistors at all?
If my 804 runs as a 924 vendor.bin, what does the scope gain by changing the HW type number? Does HW type number just unlock features without need for a lic file?
App reads file /dev/hdcode_gpio many times (according to strace output) and also its being read by one script in DHO1000 and DHO4000 models. I tried to make DHO804 from DHO924S by changing this byte, but it doesnt change anything - maybe its used only if model in vendor.bin is DHO800.
In my scope I can even change this to 255 without any result in app, beside this number in "about".
I suspect it only changes default options/features. Example, all the 900's are 50M already. My guess is, a HW number in the 900 series simply allows 50M without any lic, etc.
If the HW number of a 924 provides 50M depth to any 800, then would we 800 folks even need the lic hack?
-
I have some questions about this.
If they can do it via shoving some data into gpio char device, then why use resistors at all?
If my 804 runs as a 924 vendor.bin, what does the scope gain by changing the HW type number? Does HW type number just unlock features without need for a lic file?
We don't know for sure that the app isn't periodically looking at the config bits on those GPIO lines as a sanity/authenticity check. The effort to disable the checking might be a good idea in the long run, but it sure seems a good idea to change those hardware bits on a 802 to make a 804 upgrade so you could potentially use the 4th AFE as a 3rd channel.,(on the cheap)
-
If You going to change only HW number, then read my previous posts about it, because You can change it in "soft" way, without changing resistors or decompiling anything.
I have some questions about this.
If they can do it via shoving some data into gpio char device, then why use resistors at all?
If my 804 runs as a 924 vendor.bin, what does the scope gain by changing the HW type number? Does HW type number just unlock features without need for a lic file?
App reads file /dev/hdcode_gpio many times (according to strace output) and also its being read by one script in DHO1000 and DHO4000 models. I tried to make DHO804 from DHO924S by changing this byte, but it doesnt change anything - maybe its used only if model in vendor.bin is DHO800.
In my scope I can even change this to 255 without any result in app, beside this number in "about".
I suspect it only changes default options/features. Example, all the 900's are 50M already. My guess is, a HW number in the 900 series simply allows 50M without any lic, etc.
If the HW number of a 924 provides 50M depth to any 800, then would we 800 folks even need the lic hack?
I tested with HW 12 and I still have 50M depth.
-
Greetings. I did a quick mod to my scope to make the SDCard easier to access.
[attach=1]
The cool thing is, you could do this to YOUR scope without peeling your Warranty sticker, if you just need to back up your card or try different cards.. Is there any language in the warranty statement that prohibits a plastic alteration? ;)
If anyone cares, I can post step by step pix and instructions how to do it.
-
My suspect idea is probably good.
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078275/#msg5078275 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078275/#msg5078275)
All the 9's are same HW #, they are all 4ch 50M. The only diff is bandwidth.
The 800's have two HW numbers, because 800's are 2ch and 4ch models with different bandwidth.
This leads me to believe HW number is mem depth only setting as default, and then lics for 800's.
We can't apply a lic to a 900 for more mem depth, they are all 50M already.
I can test by removing my 804 mem lic and changing HW # from 12 to 8.
-
The scope is an android, there's really no way to de-couple the two. A hack of droid is a hack of the scope device, a hack of the scope device is a hack of the droid. ;)
I beg to differ. The working hacks which unlock new functionality do that on the application level, by using existing configuration options (option keys or vendor.bin). No software disassembly required, and nothing to do with Android.
On the other hand, the Android exploration has not really produced working hacks beyond some nice cosmetic improvements. Frankly I am not sure what the expectations are for the "Android hacking". What do you expect to gain from it? (Beyond satisfying technical curiosity, which is a perfectly valid reason of course.)
For the DHO1000, I could understand the desire to unlock the built-in 50 Ohm terminators and 400 or 800 MHz bandwidth, which the Rigol firmware for that series does not support at all. But in the DHO800/900 there is no such unused hardware. So what is the end game here?
-
Greetings. I did a quick mod to my scope to make the SDCard easier to access.
(Attachment Link)
The cool thing is, you could do this to YOUR scope without peeling your Warranty sticker, if you just need to back up your card or try different cards.. Is there any language in the warranty statement that prohibits a plastic alteration? ;)
If anyone cares, I can post step by step pix and instructions how to do it.
Funny, I was thinking about same today. I have sdcard ribbon extensions. They also make pcb extensions M-F too.
-
The scope is an android, there's really no way to de-couple the two. A hack of droid is a hack of the scope device, a hack of the scope device is a hack of the droid. ;)
I beg to differ. The working hacks which unlock new functionality do that on the application level, by using existing configuration options (option keys or vendor.bin). No software disassembly required, and nothing to do with Android.
On the other hand, the Android exploration has not really produced working hacks beyond some nice cosmetic improvements. Frankly I am not sure what the expectations are for the "Android hacking". What do you expect to gain from it? (Beyond satisfying technical curiosity, which is a perfectly valid reason of course.)
For the DHO1000, I could understand the desire to unlock the built-in 50 Ohm terminators and 400 or 800 MHz bandwidth, which the Rigol firmware for that series does not support at all. But in the DHO800/900 there is no such unused hardware. So what is the end game here?
Mod apk that needs to save images with quick button, needs a droid hack to allow it. ;)
-
For the DHO1000, I could understand the desire to unlock the built-in 50 Ohm terminators and 400 or 800 MHz bandwidth, which the Rigol firmware for that series does not support at all.
It is in the app but its locked somehow. If I had DHO1000 then I will try to hack it - maybe someone already did it.
-
The scope is an android, there's really no way to de-couple the two. A hack of droid is a hack of the scope device, a hack of the scope device is a hack of the droid. ;)
I beg to differ. The working hacks which unlock new functionality do that on the application level, by using existing configuration options (option keys or vendor.bin). No software disassembly required, and nothing to do with Android.
I think his comment was in direct response to Fungus, "suggesting to fork the thread". --at least that's how I read it.
I think we're overdue for a separate "how to unlock a DHO804" thread now. This one has devolved into Android hacking.
The scope is an android, there's really no way to de-couple the two. A hack of droid is a hack of the scope device, a hack of the scope device is a hack of the droid. ;)
Yes, but most people are only interested in getting more bandwidth and 50M memory on thier 804.
Finding the info in this thread isn't easy...
-
Mod apk that needs to save images with quick button, needs a droid hack to allow it. ;)
Unless You will use print screen on usb keyboard or use Linux/GNU installed on this scope (which I personally did).
-
For the DHO1000, I could understand the desire to unlock the built-in 50 Ohm terminators and 400 or 800 MHz bandwidth, which the Rigol firmware for that series does not support at all.
It is in the app but its locked somehow. If I had DHO1000 then I will try to hack it - maybe someone already did it.
Yes, there was decent progress in the DHO1000 hacking thread. The code seems to be there, but in conditional clauses which skip it on the DHO1000 models. But there were some stumbling blocks -- maybe due to the fact that the code fragments were "abandoned" long ago and no longer fully functional. I am not aware of a fully working DHO1000 hack which gives it the missing hardware features.
-
Yes, I would like to see a photo of the back of the board. Thank you...... By the way, it is not necessary to remove the radiator for this.... Your method is good, but when updating the firmware it needs to be repeated... I would like to permanently change the HW configuration.... configuration resistors are located on the reverse side boards.... Thanks again!!!
Damn... After upgrading by GEL file, its just two lines of code - how often You do updates? :)
Currently Im working on some software changes, and right now probably I have some "small" breakthrough.
i thought you could change HW version by just modding SW... souldevelop hinted us months ago its all about hooking or something hdcode_gpio. if its just a call to those plugin/module then my thinking it shouldnt be that hard to modify that module and push back to dso. but i guess its not as simple as 3 words? (linux is file)? if its Windows, maybe i guess i can start from what i already know, i imagine its something like DLL or drv? i have free ed IDA, so i can open a little bit exe or dll, but since its Linux/android i'm pretty much zero about how things work in those system. maybe later if it turns out config resistor is nowhere to be found in HW, maybe i'll start learning whats all those syntaxes in start_rigol_app.sh and what bits and pieces inside hdcode_gpio dot io or dot apk whatever.
-
Funny, I was thinking about same today. I have sdcard ribbon extensions. They also make pcb extensions M-F too.
Thanks! Yeah., I have one of those. Problem: If you don't cut the slot, the extension doesn't fit, and you can't put the case back together. BTW: the M-F extension I bought has a flared PCB where it attached to the ribbon cable, and will need a wider slot to work.
-
If my 804 runs as a 924 vendor.bin, what does the scope gain by changing the HW type number? Does HW type number just unlock features without need for a lic file?
you need to step few posts/pages back to see why. if you cant find it, trace my posts... my hacked 804->924 cannot do digital trigger while legit 924 can... on a very same FW version. if you can make my dho804 (hacked to 924S) to report HW 8 (instead of 12) in the About Menu, i will be thankful ;)
-
i imagine its something like DLL or drv? i have free ed IDA, so i can open a little bit exe or dll, but since its Linux/android i'm pretty much zero about how things work in those system.
Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries. IDA understands these files without problems, as does Ghidra.
-
Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries.
.so.
.ko are kernel modules.
-
Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries.
.so.
.ko are kernel modules.
Exactly. .so are libs, and .ko are kernel modules.
it shouldnt be that hard to modify that module
Why You want to detonate already opened door? I posted HW number hack without module earlier. This module reads GPIO pins and creates char file with one byte. If You get rid of that module and create this file by hand, then You can have any HW number between 0 and 255.
-
Anyone following the config bits topic: I don't know what they were thinking early times, but the RK3399 doesn't have Pin numbers like 4, 8, 11, 12 as shown in this early post:
[attach=1]
It has BGA row/column naming. Note: I notated the 0-3 bit pins(in pink) on this pic.
[attach=2]
From the RK3399. Those pins are pretty hard to get to, due to solder mask, etc on the back side., but I'm trying. I need my zoom microscope!! (in storage, in another city)
[attach=3]
@Mechatrommer I measured those config resistors at 10k(in circuit). Blank locations read 14-15k, IIRC. Add. BTW, those pins aren't any of the onboard ADCs, either.
I haven't yet desoldered the resistors to confirm values.
Edit:;
As a good primer -- Take a look back to page 3 of this thread for the early GPIO bit discussions, including disassembly of the .ko files.
Nothing much has really changed. https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335)
-
Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries.
.so.
.ko are kernel modules.
Yes, I could have made a mistake with the type of these files. So this is an analogue of Windows drivers? In any case, they can be disassembled as .dll or .exe :)
-
Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries.
.so.
.ko are kernel modules.
Yes, I could have made a mistake with the type of these files. So this is an analogue of Windows drivers? In any case, they can be disassembled as .dll or .exe :)
Some Linux modules are hardware drivers and some are doing other stuff.
-
The steps to modify your scope to remove your SDCard without breaking the seal, or removing any screws.
Upper left side, looking through the vent slots.
[attach=1]
Flush cutters for snipping the slot ribs. These are flat on one side, and it's pretty important for this mod.
[attach=2]
Yours should have tape covering your card. FYI: I doubt this would work if it's hot glued like early units.
[attach=3]
Cut a piece of thin "blister packaging" plastic that products are often packed in. I cut mine 25mm or 1" long, and a little smaller than the card width.
[attach=4]
Count the ribs and snip the three ribs shown with the first cut on the bottom of each rib(flat side down, against the metal frame). Then turn cutters over and cut 2mm up(flat side up), and discard the waste clipping. -you probably don't want it inside your scope, clip it slowly!
You need to take the tape off your card. Xacto knife, maybe? My tape was gone already, but you can cut it against the metal part, then flick it up over the card and card holder, and/or remove with tweezers. Don't cut into the PCB or card. Be careful.
[attach=5]
Attach the plastic tab to the card with double sided tape(thin and really sticky, preferred) I used UV glue 'cuz it's awesome. I've also tried gluing the tab to the bottom of the card, and it works well because of the flat side. (you'll see.)
You may also use a tiny amount of "crazy" cyanoacrylate glue. (hint: start small, and apply to plastic part first, before attaching to card.)
BTW: please do not use your original card
[attach=6]
Mine sticks out 5mm, or slightly less than 1/4". You could probably trim it more if you use tweezers.
Notes:
A: The plastic has to be stiff enough to actuate the push in/out mechanism of the card reader, but thin enough to go in the card reader
B: If you do this mod, do so at your own risk., yada yada. This might void your Warranty.
C: You're working with a backup card, right?
D: Don't cut your Card, PCB or yourself(-it makes your work area messy) with xActo.
E: You might be able to "cut the ribs" with a blade tip on your soldering iron
Final view:
[attach=7]
Stay tuned, I have a few more of these types of projects in mind.
-
Why You want to detonate already opened door? I posted HW number hack without module earlier. This module reads GPIO pins and creates char file with one byte. If You get rid of that module and create this file by hand, then You can have any HW number between 0 and 255.
iirc you mentioned anyone can put it in any file we like. can i put it in autoexec.bat and push to rigol/shell? my point is your instruction was not clear enough.
Anyone following the config bits topic: I don't know what they were thinking early times, but the RK3399 doesn't have Pin numbers like 4, 8, 11, 12 as shown in this early post:
i traced the pins from datasheet to be underside of RK3399
From the RK3399. Those pins are pretty hard to get to, due to solder mask, etc on the back side., but I'm trying. I need my zoom microscope!! (in storage, in another city)
do you see exposed vias on the back? if yes how would you know this via for what pin? you'll need xray to make sure of that. if they use blind via, traces could go somewhere else from inside layer.
As a good primer -- Take a look back to page 3 of this thread for the early GPIO bit discussions, including disassembly of the .ko files.
Nothing much has really changed. https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335)
why hasnt much changed? because it is difficult to do? btw as i understand, in gpio_hdcode_drv_read, the module is reading actually HW pin right? why hasnt somebody modified it to read from a file let say in rigol/shell/autoexec.bat? create a simple guide to do so, push the modified gpio_hdcode_drv_read, make autoexec.bat with number 8 inside and push it again... rather than "you could make any file anywhere?" that will open up a can of puzzless for newbies like me ;D
-
Anyone following the config bits topic: I don't know what they were thinking early times, but the RK3399 doesn't have Pin numbers like 4, 8, 11, 12 as shown in this early post:
i traced the pins from datasheet to be underside of RK3399
From the RK3399. Those pins are pretty hard to get to, due to solder mask, etc on the back side., but I'm trying. I need my zoom microscope!! (in storage, in another city)
do you see exposed vias on the back? if yes how would you know this via for what pin? you'll need xray to make sure of that. if they use blind via, traces could go somewhere else from inside layer.
Yes, I've been following your work, tracing those signals. I have not seen any vias/signals with exposed copper. They have soldermask over almost everything. However, I have some very nice, sharp probes to scratch thru it.
After looking at the PCB last night in person, it looks pretty difficult, but it's only 4 GPIO pins. :o It would be much easier with a microscope.
Side note: How many layers do you think this PCB is?
As a good primer -- Take a look back to page 3 of this thread for the early GPIO bit discussions, including disassembly of the .ko files.
Nothing much has really changed. https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335)
why hasnt much changed? because it is difficult to do? btw as i understand, in gpio_hdcode_drv_read, the module is reading actually HW pin right? why hasnt somebody modified it to read from a file let say in rigol/shell/autoexec.bat? create a simple guide to do so, push the modified gpio_hdcode_drv_read, make autoexec.bat with number 8 inside and push it again... rather than "you could make any file anywhere?" that will open up a can of puzzless for newbies like me ;D
I made that statement, because in September last year, everyone on page 3 was discussing the GPIO pins, HDCODE, *.ko files, how it was being called, and they even disassembled the code.
(Important: I don't want to sound ungrateful)
Nothing became of the discovery or discussion., for whatever reason.
And in human nature things tend to be cyclical., -and here we are almost 6 months later talking about it again. I've noticed that several topics here get "re-hashed" when someone with bright ideas comes along that genuinely wants to make a difference.
I've been at this for 3 months, learning from the greats here(you are one of them) and I am not a coder, other than PIC micros. I know better than try to disassemble & reassemble a big any sized software project. So, I can't help in that regard., but I am trying to help where I can.
-
Side note: How many layers do you think this PCB is?
I think at least 8. Maybe more. And it is unrealistic to reliably track which processor contacts these resistors go to without removing the processor.
Pin numbers (4, 8, 11, 12) are conditional numbering; it is converted into an indication of a physical pin by the gpio_to_desc() function. As far as I understand, when building the kernel, somewhere in the source code there is a file with a list of these numbers and the corresponding real pins, where the comparison comes from. Is it possible to somehow get this list from an already assembled kernel - I don’t know.
-
Why You want to detonate already opened door? I posted HW number hack without module earlier. This module reads GPIO pins and creates char file with one byte. If You get rid of that module and create this file by hand, then You can have any HW number between 0 and 255.
iirc you mentioned anyone can put it in any file we like. can i put it in autoexec.bat and push to rigol/shell? my point is your instruction was not clear enough.
This is not a Windows and not a DOS. Put it into /rigol/shell/start_rigol_app.sh
Side note: How many layers do you think this PCB is?
I think at least 8. Maybe more. And it is unrealistic to reliably track which processor contacts these resistors go to without removing the processor.
Pin numbers (4, 8, 11, 12) are conditional numbering; it is converted into an indication of a physical pin by the gpio_to_desc() function. As far as I understand, when building the kernel, somewhere in the source code there is a file with a list of these numbers and the corresponding real pins, where the comparison comes from. Is it possible to somehow get this list from an already assembled kernel - I don’t know.
Decompiled hdcode_gpio.ko:
int init_module(void * name, void * image) {
r0 = name;
saved_fp = r29;
stack[-24] = r30;
r31 = r31 + 0xffffffffffffffe0;
r29 = &saved_fp;
saved_regs_10 = r19;
if ((misc_register(gpio_hdcode_dev, image) & 0xffffffff80000000) != 0x0) {
r19 = gpio_hdcode_dev;
r0 = printk("register spi2k7_gpio device failed!\n");
r0 = 0xffffffff;
}
else {
r0 = *0x958;
r0 = devm_kmalloc(r0, 0x100, 0x24080c0);
r0 = gpio_request(0x4, "hd_code0");
r0 = gpio_to_desc(0x4);
r0 = gpiod_direction_input();
r0 = gpio_to_desc(0x4);
r0 = gpiod_get_raw_value();
r0 = printk("hd_code0 = %d\n", r0);
r0 = gpio_request(0x8, "hd_code1");
r0 = gpio_to_desc(0x8);
r0 = gpiod_direction_input();
r0 = gpio_to_desc(0x8);
r0 = gpiod_get_raw_value();
r0 = printk("hd_code1 = %d\n", r0);
r0 = gpio_request(0xb, "hd_code2");
r0 = gpio_to_desc(0xb);
r0 = gpiod_direction_input();
r0 = gpio_to_desc(0xb);
r0 = gpiod_get_raw_value();
r0 = printk("hd_code2 = %d\n", r0);
r0 = gpio_request(0xc, "hd_code3");
r0 = gpio_to_desc(0xc);
r0 = gpiod_direction_input();
r0 = gpio_to_desc(0xc);
r0 = gpiod_get_raw_value();
r0 = printk("hd_code3 = %d\n", r0);
r0 = printk(" gpio_hdcode_dev register successfully\n");
r0 = 0x0;
}
r19 = gpio_hdcode_dev;
r19 = saved_regs_10;
r29 = saved_fp;
r30 = stack[-24];
r31 = r31 + 0x20;
return r0;
}
GPIO pins cant be read directly from app player. It has to be driver (kernel module) between.
Dmesg from my scope after loading hdcode_gpio.ko:
[ 1649.263220] hd_code0 = 0
[ 1649.263282] hd_code1 = 0
[ 1649.263300] hd_code2 = 0
[ 1649.263319] hd_code3 = 1
[ 1649.263327] gpio_hdcode_dev register successfully
-
Speaking of decompilation...
spi2pll_gpio.ko:
int spi_pll_write(int arg0, int arg1, int arg2) {
r2 = arg2;
r0 = arg0;
saved_fp = r29;
stack[-56] = r30;
r31 = r31 + 0xffffffffffffffc0;
r29 = &saved_fp;
saved_regs_10 = r19;
stack[-40] = r20;
saved_regs_20 = r21;
stack[-24] = r22;
saved_regs_30 = r23;
stack[-8] = r24;
r22 = arg1;
r19 = r2;
r0 = _mcount(r30, arg1, r2);
r20 = pll_read_write_data;
asm { mrs x0, sp_el0 };
r1 = *(r0 + 0x8);
r0 = r22 + r19;
if (r0 < 0x0) {
r20 = pll_read_write_data;
asm { ccmp x0, x1, #0x2, lo };
}
r20 = pll_read_write_data;
if (CPU_FLAGS & BE) {
r20 = pll_read_write_data;
if (CPU_FLAGS & BE) {
r20 = pll_read_write_data;
r2 = 0x1;
}
r20 = pll_read_write_data;
}
r21 = *pll_read_write_data;
if (r2 != 0x0) {
r20 = pll_read_write_data;
r0 = __check_object_size(r21, r19, 0x0);
r1 = __arch_copy_from_user(r21, r22, r19);
}
else {
r20 = pll_read_write_data;
r0 = memset(r21, 0x0, r19);
r1 = r19;
}
r20 = pll_read_write_data;
r0 = 0xfffffffffffffff2;
if (r1 == 0x0) {
r0 = 0xfffffffffffffff2;
r20 = pll_read_write_data;
r21 = 0x0;
r0 = printk("spi_pll_write : from user write: ");
r22 = "%02x ";
do {
r22 = "%02x ";
r20 = pll_read_write_data;
asm { sxtw x0, w21 };
if (r19 <= r0) {
break;
}
r21 = r21 + 0x1;
r0 = printk("%02x ", *(int8_t *)(*pll_read_write_data + r0));
} while (true);
r22 = "%02x ";
r21 = 0x0;
r0 = printk("\n");
r23 = *pll_read_write_data;
r0 = _raw_spin_lock(0xa7c);
r0 = loc_27c(0x6);
r0 = __const_udelay(0x10c7);
do {
r20 = spi_pll_master;
if (r19 <= r21) {
break;
}
r0 = *(int32_t *)dword_a74;
r22 = 0x7;
r24 = *(int8_t *)(r23 + r21);
r0 = loc_27c(r0);
do {
r20 = spi_pll_master;
if ((SAR(r24, r22) & 0x1) != 0x0) {
r0 = *(int32_t *)dword_a78;
r0 = _spi_pll_set_gpio_high();
}
else {
r0 = *(int32_t *)dword_a78;
r0 = loc_27c(r0);
}
r0 = *(int32_t *)dword_a74;
r22 = r22 - 0x1;
r0 = loc_27c(r0);
r0 = __const_udelay(0x10c7);
r0 = *(int32_t *)dword_a74;
r0 = _spi_pll_set_gpio_high();
r0 = __const_udelay(0x10c7);
} while (r22 != -0x1);
r0 = *(int32_t *)dword_a74;
r21 = r21 + 0x1;
r0 = loc_27c(r0);
} while (true);
r0 = __const_udelay(0x10c7);
r0 = 0x6;
r0 = _spi_pll_set_gpio_high();
r0 = __const_udelay(0x10c7);
r0 = loc_27c(0x6);
r0 = __const_udelay(0x10c7);
r0 = _raw_spin_unlock(0xa7c);
r0 = 0x0;
}
r19 = saved_regs_10;
r20 = stack[-40];
r21 = saved_regs_20;
r22 = stack[-24];
r23 = saved_regs_30;
r24 = stack[-8];
r29 = saved_fp;
r30 = stack[-56];
r31 = r31 + 0x40;
return r0;
}
libscope-auklet.so:
int DevAcquireSPU_SetSampleRate(int arg0, int arg1) {
r0 = arg0;
*(r31 + 0xffffffffffffffe0) = r19;
var_20 = r29;
stack[-8] = r30;
r29 = &var_20;
r19 = arg1;
if (arg1 >= 0x3b9aca1) {
r8 = 0x3b9aca1;
r0 = sub_17f630();
asm { udiv x8, x0, x19 };
r1 = 0x8000;
asm { bfxil w1, w8, #0x0, #0x8 };
r19 = 0x1;
}
else {
r8 = 0x3b9aca1;
r8 = 0x3b9aca0;
r1 = 0x0;
asm { udiv w19, w8, w19 };
}
r0 = 0x10d0;
r0 = sub_176e80();
r0 = 0x10d8;
r1 = r19;
r0 = sub_176e80();
r29 = var_20;
r30 = stack[-8];
r0 = 0x10d4;
r1 = 0x0;
r19 = var_30;
r0 = sub_176e80();
goto .l1;
.l1:
r1 = 0x0;
return r0;
}
0x3b9aca0 = 62500000.
-
step by step guide which screws to unscrew to open dho pcb: see attached... i guess some people still afraid to do this? to snap photo, to mod etc...
if you want to remove heatsink, do unscrew as in picture 2.jpg/ if you dont want to remove heatsink, only access to the underside of pcb, only unscrew as in 2b.jpg
about heat pads.. while lifting heatsink, dont remove heat pads, leave them be where they are, if they stick to the IC, leave them like that, if they stick to heatsink, leave them like that. attaching heatsink again, will attach them all back together... if you really need to lift the heatpads, do it carefully as they are soft and easily broken... there is no glue or paste sticking them to the IC, only oil... fwiw..
tools needed T10 head screwdriver and a plier (to unscrew BNC hex nut) fwiw...
-
As a good primer -- Take a look back to page 3 of this thread for the early GPIO bit discussions, including disassembly of the .ko files.
Nothing much has really changed. https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335)
if souldevelop's report is correct... i just did some photoshop fun (attached) to find where are the 25AA, 28U, 30U, 26V pins are, somewhere in red circle... based on possible closest route, another candidate for config resistor could be in yellow circle.. we went through the blue circle fun ;D be warned you could damage something if not careful...
otoh i dont tend to do your sd card mod. possibly one day this thing is fixed whether in HW or SW, so we dont need to switch sd card anymore, so you'll be left with irreversible cutted top enclosure for no good reason. not a big deal really.
edit: another possible trap is that by modding HW ver from 12 (DHO800) to 8 (DHO900) its possible FW will activate reading the unpopulated DDR3 RAM, another mess if its really happens. ymmv.
-
If those GPIO pins are 0/1, then it will be easier to solder thin wire, put outside, connect some dip-switch and test combinations (dmesg or/and app).
-
based on possible closest route, another candidate for config resistor could be in yellow circle.. we went through the blue circle fun ;D be warned you could damage something if not careful...
edit: another possible trap is that by modding HW ver from 12 (DHO800) to 8 (DHO900) its possible FW will activate reading the unpopulated DDR3 RAM, another mess if its really happens. ymmv.
udało się! will try next what will happen to LA probing..
-
Nice! Can you trigger on digital signals now?
-
If those GPIO pins are 0/1, then it will be easier to solder thin wire, put outside, connect some dip-switch and test combinations (dmesg or/and app).
They are 0 or 1 . But bigger question is, are they OUT or IN pins ? They show as IN pins, which to me suggests those pins are internally pulled down and the resistors connect to 3.3v to provide the "1" in the 4bit code for HW number.
I can't seem to direct data into the hdcode gpio char device, because when I unload the ko module the kernel remove hdcode_gpio from device tree.
However, with the ko module in kernel, I get arg error when trying to direct hex 8 to the hdcode char device in /dev
The two pics are with ko module, and without ko module. It appears the ko module reads those gpio.
My 804 is 1100 = 12
After unload ko module I then did a "am restart" and rigol scope showed "0" as HW number.
I suspect it's truly hardware config bound.
-
udało się!
Is this Polish language?
Did You test my way of changing HW number?
If those GPIO pins are 0/1, then it will be easier to solder thin wire, put outside, connect some dip-switch and test combinations (dmesg or/and app).
They are 0 or 1 . But bigger question is, are they OUT or IN pins ? They show as IN pins, which to me suggests those pins are internally pulled down and the resistors connect to 3.3v to provide the "1" in the 4bit code for HW number.
I can't seem to direct data into the hdcode gpio char device, because when I unload the ko module the kernel remove hdcode_gpio from device tree.
However, with the ko module in kernel, I get arg error when trying to direct hex 8 to the hdcode char device in /dev
The two pics are with ko module, and without ko module. It appears the ko module reads those gpio.
My 804 is 1100 = 12
After unload ko module I then did a "am restart" and rigol scope showed "0" as HW number.
I suspect it's truly hardware config bound.
Because its one byte file. I told it before. Its a binary number - unsigned char. Why You are doing research which I have done it and posted it here before?
-
If somebody wants to play with HW number, there is simpler way, than I wrote before.
printf '\x8' > /dev/hdcode_gpio
Of course, get rid of hdcode_gpio module first, by unloading it (rmmod hdcode_gpio) and commenting it out in /rigol/shell/start_rigol_app.sh - above command can go into this file (personally I did it at very beginning).
I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?
-
I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?
because we dont have a clue where to put it... maybe later as we gain comprehension. i guess what you meant is editing start_rigol_app.sh and pushing it back again? will sure try later.
-
for HW mod from 12 to 8 by luck and brainstorming in this thread... i found a way.. there's another place on the side for config resistor (see attached), before modding, i measure resistance, exactly same thing as before, parallel resistor measured 6Kohm, single resistor measured 10Kohm, so it seems coincidence, why not try? i tried 3 combinations to get what i want (see attached) most significant bit is the topmost resistor in pcb picture below (pcb shows original HW 12 resistor setup).
and in this video, i now can trigger on digital channel (on original HW 12 i cant) so the conclusion is, there is/are differences in FW execution based on HW number. fwiw...
edit: done doing scope's CH calibration on the hacked HW ver scope showing no offset issue... :-+
https://www.youtube.com/watch?v=hW27YGCCvq8 (https://www.youtube.com/watch?v=hW27YGCCvq8)
cheers.
-
I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?
because we dont have a clue where to put it... maybe later as we gain comprehension. i guess what you meant is editing start_rigol_app.sh and pushing it back again? will sure try later.
You can put it into start_rigol_app.sh or execute it manually in a shell and after that execute /rigol/shell/restartScope.sh
Dont forget to comment out insmod to prevent loading this module.
In my case changing this value doesnt change anything. Or I didnt catch the change.
BTW. chmod can be changed to 444 (read only) and it still works. Most likely some Rigol developer was lazy and (s)he put just 777...
-
I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?
because we dont have a clue where to put it... maybe later as we gain comprehension. i guess what you meant is editing start_rigol_app.sh and pushing it back again? will sure try later.
You can put it into start_rigol_app.sh or execute it manually in a shell and after that execute /rigol/shell/restartScope.sh
Dont forget to comment out insmod to prevent loading this module.
In my case changing this value doesnt change anything. Or I didnt catch the change.
BTW. chmod can be changed to 444 (read only) and it still works. Most likely some Rigol developer was lazy and (s)he put just 777...
sounds easy for you, but not for me... i'll cope with this later. cheers.
-
I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?
because we dont have a clue where to put it... maybe later as we gain comprehension. i guess what you meant is editing start_rigol_app.sh and pushing it back again? will sure try later.
You can put it into start_rigol_app.sh or execute it manually in a shell and after that execute /rigol/shell/restartScope.sh
Dont forget to comment out insmod to prevent loading this module.
In my case changing this value doesnt change anything. Or I didnt catch the change.
BTW. chmod can be changed to 444 (read only) and it still works. Most likely some Rigol developer was lazy and (s)he put just 777...
sounds easy for you, but not for me... i'll cope with this later. cheers.
Adding one line and removing other one (or commenting it via # at beginning) into text file is not that difficult.
Speaking of beginning. Dont touch first line:
#!/system/bin/bash
Because its a magic data to tell kernel or shell, which app should execute this script. Add any code anywhere after that.
BTW. We can see how crazy changes (including /system folder) was made to make Android from GNU/Linux. In GNU for many years it was good & simple and they changed that - because they can...
-
If somebody wants to see functions list in libscope-auklet.so with args and offsets, there is a lot of it, so I put it into attachment.
-
Mechatrommer, you've amazed us one more time! My congratulations!
(after a glance on a bottom side of the main pcb with your writings I thought I understand both configurations. But after I look at your writings on a piece of paper I get confused a little though)
BTW, would you tell us, please, something more about the design of your AFG custom-made add-on board?
-
If somebody wants to play with HW number, there is simpler way, than I wrote before.
printf '\x8' > /dev/hdcode_gpio
Of course, get rid of hdcode_gpio module first, by unloading it (rmmod hdcode_gpio) and commenting it out in /rigol/shell/start_rigol_app.sh - above command can go into this file (personally I did it at very beginning).
I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?
The app does not appear to be reading a file in /dev
When you unload the ko module the whole hdcode_gpio device is removed from the device tree, so when you direct printf to /dev/hdcode_gpio it's not going into the KLM, it just creates a regular file.
So your procedure to direct data into the dev file does not work.
-
If somebody wants to play with HW number, there is simpler way, than I wrote before.
printf '\x8' > /dev/hdcode_gpio
Of course, get rid of hdcode_gpio module first, by unloading it (rmmod hdcode_gpio) and commenting it out in /rigol/shell/start_rigol_app.sh - above command can go into this file (personally I did it at very beginning).
I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?
The app does not appear to be reading a file in /dev
When you unload the ko module the whole hdcode_gpio device is removed from the device tree, so when you direct printf to /dev/hdcode_gpio it's not going into the KLM, it just creates a regular file.
So your procedure to direct data into the dev file does not work.
Did You read what I wrote form beginning to the end with proper understanding? I wrote clearly to unload this module first - couple times. How many times I should repeat this until You catch it?
You cant overwrite char device, but for any app reading is reading like any other file. Doesnt matter if its a block device or regular text file. Kernel will give exact same data to the process.
-
BTW, would you tell us, please, something more about your AFG custom-made add-on board?
currently completed rev2 testing and as you can see still stucked on the dho board in recent pictures. for my usage its now so called "usable", but it still has about 3mVpp switching crosstalk and 10mVpp noises on the output, and some distortion at high Vpp at 10-15MHz, but for some others ee gurus, these figures are probably childish, so i try to fondle the last revision 3 on the board, add more decoupling caps here and there and ground plane stitching vias, hopefully there will be small improvement. at the same time along with buying more not so cheap IC/opamp parts.. i'm also spinning LA probe board rev 2 as i have one big stupid careless mistake on schematics earlier only realizing it when pcb ver1 completed :palm:, but the effect will not be so obvious on the output. those i've completed in the last 2 days, now while i'm thinking what other project to put in pcb since i have more spaces before sending to jlcpcb, here you see i'm doing some fun on the config resistor again ::)
btw i think few people asked/PM me about this because they need to see the schematics? or even the pcb gerber files? i'll think about that. there will be higher chance for me to publish schematics in full or partly depending how people ask, or how a particular thread discussion forms. gerber files? maybe not because i have think of our competitors in the northern hemisphere ;) they are very good at knocking competitors to the corner (we read history, even in this forum if you search hard enough, hint nanovna) i hope you get what i mean ;) cheers.
-
for HW mod from 12 to 8 by luck and brainstorming in this thread... i found a way.. there's another place on the side for config resistor (see attached), before modding, i measure resistance, exactly same thing as before, parallel resistor measured 6Kohm, single resistor measured 10Kohm, so it seems coincidence, why not try? i tried 3 combinations to get what i want (see attached) most significant bit is the topmost resistor in pcb picture below (pcb shows original HW 12 resistor setup).
and in this video, i now can trigger on digital channel (on original HW 12 i cant) so the conclusion is, there is/are differences in FW execution based on HW number. fwiw...
cheers.
The pics you have are very confusing.
1) 12 is not binary 1010, 12=1100
2) you show what appears to be 8 connections of some sort that define HW number. I can say 100% that the hdcode_gpio KLM only reads 4, gpio numbers 12 11 8 4 and in that binary order. The kernel shows them as 1100, aka "12".
3) the physical layout of resistors do not appear to be in binary order, because 1010 does not equal 12, and for clarity what you literally observe is not 1010. The "0" are non-connected. The RK needs to do pull up or down for non-connected to avoid floats.
4) we also do not know how the gpio pins are pulled inside the RK. If they are internally pulled up, then a non-connected pin (no resistor) is a "1" inside the RK. If they are internally pulled down, then a non-connected pin (no resistor) is a "0" inside the RK. The only way to know for sure is by way of RK datasheet, which might say "programmable", or by testing the voltage state between gpio pins and resistor.
So, I am curious, you show 8 resistors pads that define HW number. Do the top most ones goto gpio 12 11 8 and 4? Where do the others go?
-
The kernel shows them as 1100, aka "12".
Not the kernel, but module hdcode_gpio.ko which calls printk function in the kernel. I posted decompiled this module earlier.
-
If somebody wants to play with HW number, there is simpler way, than I wrote before.
printf '\x8' > /dev/hdcode_gpio
Of course, get rid of hdcode_gpio module first, by unloading it (rmmod hdcode_gpio) and commenting it out in /rigol/shell/start_rigol_app.sh - above command can go into this file (personally I did it at very beginning).
I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?
The app does not appear to be reading a file in /dev
When you unload the ko module the whole hdcode_gpio device is removed from the device tree, so when you direct printf to /dev/hdcode_gpio it's not going into the KLM, it just creates a regular file.
So your procedure to direct data into the dev file does not work.
Did You read what I wrote form beginning to the end with proper understanding? I wrote clearly to unload this module first - couple times. How many times I should repeat this until You catch it?
You cant overwrite char device, but for any app reading is reading like any other file. Doesnt matter if its a block device or regular text file. Kernel will give exact same data to the process.
I did unload the KLM.
Unload it, and then you direct printf stdout to /dev/hdcode_gpio, and all the OS does is create a regular file in /dev (the inode is a REGULAR FILE). Nothing reads that regular file.
When I printf to /dev/hdcode_gpio, that file contains the hex value, but the scope app cannot find the actual value, so it says HW Type is "0".
Please correct my observations as needed.
The kernel shows them as 1100, aka "12".
Not the kernel, but module hdcode_gpio.ko which calls printk function in the kernel. I posted decompiled this module earlier.
I was looking at gpio in kernel debug dir, the kernel writes all that info. The hdcode KLM only updates gpio 12 11 8 and 4. Sure, the KLM is the item to fetch the gpio states, but kernel writes out that gpio file.
-
(after a glance on a bottom side of the main pcb with your writings I thought I understand both configurations. But after I look at your writings on a piece of paper I get confused a little though)
sorry if i cause confusion, i've corrected the picture on which side i change the config... this is if you already own DHO8*4... here what i played with tonight... to put simply, if you want to change HW 12 to HW 8, just add another 10Kohm 0402 resistor on the bottom side where the resistor is missing... 0603 resistor should be possible with some kongfu... or move the second top most resistor to the bottom most if you dont have the extra part... fwiw...
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2069624;image)
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2069405;image)
-
When you unload the KLM, the hdcode_gpio device is REMOVED from device tree, there is no long a /dev/hdcode_gpio char device in /dev
I say it again, When you unload the KLM, the hdcode_gpio device is REMOVED from device tree, there is no long a /dev/hdcode_gpio char device in /dev
Unload it, and then you direct printf stdout to /dev/hdcode_gpio, and all the OS does is create a regular file in /dev (the inode is a REGULAR FILE).
Thats the point. Let me repeat again, when file is being read, then it doesnt matter if its a some sort of device or a regular file.
Nothing reads that regular file.
Did You check this file permissions? If its not readable then make it readable:
chmod 444 /dev/hdcode_gpio
When I printf to /dev/hdcode_gpio, that file contains the hex value, but the scope app cannot find the actual value, so it says HW Type is "0".
Printf with \x switch makes printf to read value as hex but output is binary - it converts hex to bin. Couple examples (hex = bin = decimal):
\x0 = 0 0 0 0 0 0 0 0 = 0
\x1 = 0 0 0 0 0 0 0 0 = 1
\x8 = 0 0 0 0 1 0 0 0 = 8
\xa = 0 0 0 0 1 0 1 0 = 10
If it works in my scope, then it must work in Yours.
-
So, I am curious, you show 8 resistors pads that define HW number. Do the top most ones goto gpio 12 11 8 and 4? Where do the others go?
i dont know what theory you try explaining.. we agree from your people's expertise there a 4 config pins... but playing around with 4 resistors earlier on top side didnt come up with all binaries you theorized...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839)
so i had a go on another 4 resistors on the side this night, it turned out thats where i need to change to get HW 8. i dont know what binary what logical arrangement there is, all i know now my FW reported HW 8, so i considered it as success...
-
I was looking at gpio in kernel debug dir, the kernel writes all that info. The hdcode KLM only updates gpio 12 11 8 and 4. Sure, the KLM is the item to fetch the gpio states, but kernel writes out that gpio file.
God damn it. Everything goes thru the kernel unless process or module reads or write to ram. Module calls printk which is the same as printf but output goes into kernel log. Data is generated by a module and nothing else.
-
Did You check this file permissions? If its not readable then make it readable:
Printf with \x switch makes printf to read value as hex but output is binary - it converts hex to bin. Couple examples (hex = bin = decimal):
\x0 = 0 0 0 0 0 0 0 0 = 0
\x1 = 0 0 0 0 0 0 0 0 = 1
\x8 = 0 0 0 0 1 0 0 0 = 8
\xa = 0 0 0 0 1 0 1 0 = 10
If it works in my scope, then it must work in Yours.
My box is an 804.
I did exactly as you said, right down to 444 in start script.
The reg file is there, hexdump shows the hex value in the file.
Scope app still shows HW type "0".
-
So, I am curious, you show 8 resistors pads that define HW number. Do the top most ones goto gpio 12 11 8 and 4? Where do the others go?
i dont know what theory you try explaining.. we agree from your people's expertise there a 4 config pins... but playing around with 4 resistors earlier on top side didnt come up with all binaries you theorized...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839)
so i had a go on another 4 resistors on the side this night, it turned out thats where i need to change to get HW 8. i dont know what binary what logical arrangement there is, all i know now my FW reported HW 8, so i considered it as success...
Ahh, I see. So the 4 down to side defines HW type number, in your pic, an 8 ?
With three resistors and a 4bit word, only the un-connected pad can be the 8 in binary, so I suspect the resistors are actually connected to GND, and the unconnected is pulled up in RK.
On the side pads, top to bottom, I suspect they are GPIO pins 4 8 11 12, 12 being most significant in the 4bit word, "12/11/8/4", aka 1000, since 1000 = 8
-
Did You check this file permissions? If its not readable then make it readable:
Printf with \x switch makes printf to read value as hex but output is binary - it converts hex to bin. Couple examples (hex = bin = decimal):
\x0 = 0 0 0 0 0 0 0 0 = 0
\x1 = 0 0 0 0 0 0 0 0 = 1
\x8 = 0 0 0 0 1 0 0 0 = 8
\xa = 0 0 0 0 1 0 1 0 = 10
If it works in my scope, then it must work in Yours.
My box is an 804.
I did exactly as you said, right down to 444 in start script.
The reg file is there, hexdump shows the hex value in the file.
Scope app still shows HW type "0".
I see two possibilities. One is You are not doing all the steps. Second one, You are doing it in completely different way than I told it many times.
Execute this command in a shell. Its the last time when I writing this. I dont want to repeat myself 50 times in a row.
adb connect ip:5555
adb root
adb shell
rmmod hdcode_gpio
printf '\x8' > /dev/hdcode_gpio
/rigol/shell/restartScope.sh
I dont want to hear it doesnt work, beacuse its too simple to make it wrong.
-
So, I am curious, you show 8 resistors pads that define HW number. Do the top most ones goto gpio 12 11 8 and 4? Where do the others go?
i dont know what theory you try explaining.. we agree from your people's expertise there a 4 config pins... but playing around with 4 resistors earlier on top side didnt come up with all binaries you theorized...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839)
so i had a go on another 4 resistors on the side this night, it turned out thats where i need to change to get HW 8. i dont know what binary what logical arrangement there is, all i know now my FW reported HW 8, so i considered it as success...
Ahh, I see. So the 4 down to side defines HW type number.
God damn it ;D... 4 on top also can change HW number as S2084 and those germany's forum link figured out much earlier, but you wont get HW 8, look closely the combination picture in earlier post linked above and what is the FW reporting about it. it wont match your binary pull up and pull down theory there. you need to browse all recent posts, maybe 10-20 pages back to get the feel of it... cheers.
-
if you ask me to where those 8 resistors are connected to RK3399? the answer is i dont know. and probably nobody in this and that forum knows. hacking is about getting what we want without knowing everything. the other non-hack version is full reverse engineering or going the proper education or design route, be my guest ;D cheers.
-
Did You check this file permissions? If its not readable then make it readable:
Printf with \x switch makes printf to read value as hex but output is binary - it converts hex to bin. Couple examples (hex = bin = decimal):
\x0 = 0 0 0 0 0 0 0 0 = 0
\x1 = 0 0 0 0 0 0 0 0 = 1
\x8 = 0 0 0 0 1 0 0 0 = 8
\xa = 0 0 0 0 1 0 1 0 = 10
If it works in my scope, then it must work in Yours.
My box is an 804.
I did exactly as you said, right down to 444 in start script.
The reg file is there, hexdump shows the hex value in the file.
Scope app still shows HW type "0".
I see two possibilities. One is You are not doing all the steps. Second one, You are doing it in completely different way than I told it many times.
Execute this command in a shell. Its the last time when I writing this. I dont want to repeat myself 50 times in a row.
adb connect ip:5555
adb root
adb shell
rmmod hdcode_gpio
printf '\x8' > /dev/hdcode_gpio
/rigol/shell/restartScope.sh
I dont want to hear it doesnt work, beacuse its too simple to make it wrong.
I did it via SSH, not adb, AND, I also commented out the KLM in start script, AND, I added printf and chmod 444 in start script directly under the commented KLM.
Using restart script or rebooting, HW type still says "0".
-
I did it via SSH, not adb, AND, I also commented out the KLM in start script, AND, I added printf and chmod 444 in start script directly under the commented KLM.
Using restart script or rebooting, HW type still says "0".
KLM airlines?
">" is being parsed by a bash (or other shell). If You are sending it from host terminal, then ">" and everything after that is not going thru. So You are generating file in wrong machine.
-
So, I am curious, you show 8 resistors pads that define HW number. Do the top most ones goto gpio 12 11 8 and 4? Where do the others go?
i dont know what theory you try explaining.. we agree from your people's expertise there a 4 config pins... but playing around with 4 resistors earlier on top side didnt come up with all binaries you theorized...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839)
so i had a go on another 4 resistors on the side this night, it turned out thats where i need to change to get HW 8. i dont know what binary what logical arrangement there is, all i know now my FW reported HW 8, so i considered it as success...
Ahh, I see. So the 4 down to side defines HW type number.
God damn it ;D... 4 on top also can change HW number as S2084 and those germany's forum link figured out much earlier, but you wont get HW 8, look closely the combination picture in earlier post linked above and what is the FW reporting about it. it wont match your binary pull up and pull down theory there. you need to browse all recent posts, maybe 10-20 pages back to get the feel of it... cheers.
It's not a theory. I posted the gpio values for hardware 12. There 4 pins that are read by the hdcode_gpio KLM. Thise 4 pins are "rk gpio" 12 11 8 and 4. They are literally set hi hi lo lo per the KLM, 1100 = 8+4+0+0 = 12. Those gpio pin settings must come from SMD's on the board.
How gpio pins are arranged via resistors could be mixed, like 12 8 11 4, due to ability to connect PCB traces to RK gpio pins. But your side resistors appear as 3 stacked with last one missing. In 4bit word, to get "8", that missing one has to be most significnat value in the 4bit word, aka gpio pin 12. Example, 1110 nor 0111 nor 0001 can't be 8, but 1000 is 8.
-
@Randy222 show me Your start script. Whole file from beginning to the last line, even if its a empty line.
-
I did it via SSH, not adb, AND, I also commented out the KLM in start script, AND, I added printf and chmod 444 in start script directly under the commented KLM.
Using restart script or rebooting, HW type still says "0".
KLM airlines?
">" is being parsed by a bash (or other shell). If You are sending it from host terminal, then ">" and everything after that is not going thru. So You are generating file in wrong machine.
What?
The terminal via ssh dumps in as sh, not bash.
The start script runs under bash
Both printf from sh or bash create the same file
0000000 0008
0000001
What does your file look like from hexdump?
-
@Randy222 show me Your start script. Whole file from beginning to the last line, even if its a empty line.
I'll grab it.
-
How gpio pins are arranged via resistors could be mixed, like 12 8 11 4, due to ability to connect PCB traces to RK gpio pins. But your side resistors appear as 3 stacked with last one missing. In 4bit word, to get "8", that missing one has to be most significnat value in the 4bit word, aka gpio pin 12. Example, 1110 nor 0111 nor 0001 can't be 8, but 1000 is 8.
my original config (you can see in picture) top resistors = 1010, side resistors = 1110, this make FW (About menu) reporting HW 12 (the original from factory), now i changed the resistor.... top resistors = 1010 (still same), and now side resistors = 1111, with this, FW reporting HW 8... how do you explain that? with binary theory and hdcode_gpio KLM code?
to add to the fun for anyone interested in digital mental gymnastic: another combination (top 4 bit + side 4 bit):
1010,1110 = HW12 (my scope's default from factory)
1010,1010 = HW12
1010,1111 = HW8
1010,1011 = HW8
0000,1110 = HW4
0001,1110 = HW5
0010,1110 = HW13
for more combination fun, you can combine side bit 1110 with top bit in this combo image we've done earlier (when the side resistors of my scope still defaulted to 1110).
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2062247;image)
nomenclature: 1 = 10Kohm resistor presents, 0 = 10Kohm resistor missing.
-
What does your file look like from hexdump?
-
@Randy222 show me Your start script. Whole file from beginning to the last line, even if its a empty line.
attached
-
What does your file look like from hexdump?
xxd on my file shows "00000000: 08" without -p switch
with -p switch xxd shows "08"
so same as yours.
-
How gpio pins are arranged via resistors could be mixed, like 12 8 11 4, due to ability to connect PCB traces to RK gpio pins. But your side resistors appear as 3 stacked with last one missing. In 4bit word, to get "8", that missing one has to be most significnat value in the 4bit word, aka gpio pin 12. Example, 1110 nor 0111 nor 0001 can't be 8, but 1000 is 8.
my original config (you can see in picture) top resistors = 1010, side resistors = 1110, this make FW (About menu) reporting HW 12 (the original from factory), now i changed the resistor.... top resistors = 1010 (still same), and now side resistors = 1111, with this, FW reporting HW 8... how do you explain that? with binary theory and hdcode_gpio KLM code?
to add to the fun for anyone interested in digital mental gymnastic: another combination (top 4 bit + side 4 bit):
1010,1110 = HW12 (my scope's default from factory)
1010,1010 = HW12
1010,1111 = HW8
1010,1011 = HW8
0000,1110 = HW4
0001,1110 = HW5
0010,1110 = HW13
for more combination fun, you can combine side bit 1110 with top bit in this combo image we've done earlier (when the side resistors of my scope still defaulted to 1110).
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2062247;image)
nomenclature: 1 = 10Kohm resistor presents, 0 = 10Kohm resistor missing.
You have to explain it. ;)
After hardware chage, go into the kernel debug dir I listed a few posts back, read the gpio file, what gpio pins (and values) have changed ?
From what I found, the hdcode KLM only acts on RK gpio pins 12 11 8 and 4.
So perhaps there's more code somewhere else that's reading more pins, but hdcode.ko maps to those 4 pins in the gpio file. I posted the pics.
-
Thank you @AndyBig for this nice and complete recap on the hack! And of course a big thanks to @zelea2 for implenting the hack.
I've discovered last year this topic and I've just bought in March a DHO804. Obviously I came back here this week and I wasn't able to find the last and "official" procedure to hack it. I remember something about the sdcard and the firmware from a DHO924 but still... Luckily I came to your post !
Also, for those who will be in the same situation as me, that's to say with a fresh brand new DHO804, here are some additional information to this hacking tutorial:
- if you
upgrade hack your DHO804 into a DHO924 model with the vendor methode, as recommended in the tuto, you'll get the 250MHz bandwidth, the 50 Mpts depth and the additional decoding protocol (Parallel,RS232, I2C, SPI, LIN, CAN). Also you'll have the SLA tab on the display which of course won't work as no SLA hardware is present on the DHO804. - my DHO804 came with an old firmware (00.01.00.something if I remember). Hacking with the vendor method on this version works but the offset calibration of the 4 channels will be inaccurate even after making the oscilloscope running a self-calibration. I've understand that the best method today is to first upgrade the firmware then apply the vendor method hack from @zelea2
For the story, in my case, I first hacked to DHO924, discovered the incorrect bad offset so I ran a self-calibration with no success. I restored back to DHO804 model by push back my original vendor.bin and rebooted. Then also pushed back my calibration file (.cal) and rebooted again (I don't remember the offset was at that moment OK, anyway). I then upgraded to 00.01.02.00.02 and after the reboot I ran the self-calibration which resulted with a correct offset calibration. Finaly I hacked again to DHO924 model and after the reboot the offset calibration was still OK and of course the hack was working (250 MHz BW, 50 Mpts, ...). I've run a quick test with an eMMC running with 50MHz clock and I was able to clearly see the data bits while capturing the clock on chan 1 and one dataline on chan 2 @ 625 MSa/s while with the DHO804 model it was kind of inaccurate (the frequency measurement of the clock wasn't stable at all).
Well that's all folks ! I hope it will be helpful for other DHO804 owners :)
-
After hardware chage, go into the kernel debug dir I listed a few posts back, read the gpio file, what gpio pins (and values) have changed ?
this thread is a curse, i thought i saw your "kernel report"about gpio pins, now i cant find it :palm: i wish to ask how to do that step by step.. found it! :palm: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389235/#msg5389235 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389235/#msg5389235) then how to do it? into the kernel debug mode?
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2069309;image)
Screenshots...
ah there was a time when i was on HW12 ;) that was few minutes ago ;D yeah big thanks to AndyBig and participants/contributors here...
-
I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?
because we dont have a clue where to put it... maybe later as we gain comprehension. i guess what you meant is editing start_rigol_app.sh and pushing it back again? will sure try later.
You can put it into start_rigol_app.sh or execute it manually in a shell and after that execute /rigol/shell/restartScope.sh
Dont forget to comment out insmod to prevent loading this module.
In my case changing this value doesnt change anything. Or I didnt catch the change.
BTW. chmod can be changed to 444 (read only) and it still works. Most likely some Rigol developer was lazy and (s)he put just 777...
sounds easy for you, but not for me... i'll cope with this later. cheers.
We can't all be amazing software wizards @Mech.,
if so, there wouldn't be any software jobs... or wizards.
-
I've dug in the previous post but I can't see clearly what you can do by changing the HW version ? I've seen here https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781) that you need to modify HW version to change the DHO804 into a DHO924 which what I have done without changing this HW version...So I'm kind of WTF ? Can you please tell me a little bit about the HW version ? I'm curious ;D
-
After hardware chage, go into the kernel debug dir I listed a few posts back, read the gpio file, what gpio pins (and values) have changed ?
this thread is a curse, i thought i saw your "kernel report"about gpio pins, now i cant find it :palm: i wish to ask how to do that step by step.. found it! :palm: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389235/#msg5389235 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389235/#msg5389235) then how to do it? into the kernel debug mode?
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2069309;image)
Screenshots...
ah there was a time when i was on HW12 ;) that was few minutes ago ;D yeah big thanks to AndyBig and participants/contributors here...
In retrospect to your resistor stack on the side, if they represent an "8" then I suspect RK gpio pins are coded with internal pull-up to avoid floats. But this is TBD.
-
I've dug in the previous post but I can't see clearly what you can do by changing the HW version ? I've seen here https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781) that you need to modify HW version to change the DHO804 into a DHO924 which what I have done without changing this HW version...So I'm kind of WTF ? Can you please tell me a little bit about the HW version ? I'm curious ;D
@Mechatrommer has built his own ARB or AFG module that only the 9x4S models have, normally. He also has built and is using a custom LA pod.
He discovered some issues with full compatibility when using the upgraded hardware, and is currently investigating "full hardware" compatibility mode(by adapting the config(I.e., GPIO) resistors), as opposed to software hack methods.
This probably doesn't pertain to "normal" 800 -> 900 scope users.
-
We can't all be amazing software wizards @Mech.,
if so, there wouldn't be any software jobs... or wizards.
i'm no wizard, but if you ask me, i can edit REM autoexec.bat a little bit :-DD
I've dug in the previous post but I can't see clearly what you can do by changing the HW version ? I've seen here https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781) that you need to modify HW version to change the DHO804 into a DHO924 which what I have done without changing this HW version...So I'm kind of WTF ? Can you please tell me a little bit about the HW version ? I'm curious ;D
in order to understand this, you need to fully hack your DHO804 into DHO9x4S with LA probe hardware and punching out a good rectangle front of your dso enclosure. you can follow my posts up to dho800/900 bug and fix thread and then Howardlongs reply, its my recent finding so probably not finalized yet, i think you are the first "single post" poster who heard about this tonight... ;) not even the other super posters who are probably sleeping right now ;). but if you are not intending to extend to HW hack, just 50Mpts and BW hack, HW 12 is probably fine for you... cheers.
-
I've dug in the previous post but I can't see clearly what you can do by changing the HW version ? I've seen here https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781) that you need to modify HW version to change the DHO804 into a DHO924 which what I have done without changing this HW version...So I'm kind of WTF ? Can you please tell me a little bit about the HW version ? I'm curious ;D
You can change 800's into 924 via just the vendor.bin and lic hack using zelea2 tool.
You do not need to change HW number.
The 800's simply do not have the extra hardware that the 900's have, thuse HW number change does not really help.
If you go beyond the basic software hack, you'll need to change HW number.
-
After hardware chage, go into the kernel debug dir I listed a few posts back, read the gpio file, what gpio pins (and values) have changed ?
this thread is a curse, i thought i saw your "kernel report"about gpio pins, now i cant find it :palm: i wish to ask how to do that step by step.. found it! :palm: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389235/#msg5389235 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389235/#msg5389235) then how to do it? into the kernel debug mode?
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2069309;image)
In retrospect to your resistor stack on the side, if they represent an "8" then I suspect RK gpio pins are coded with internal pull-up to avoid floats. But this is TBD.
i asked how to get to this console. but if you need me to have one linux pc, i'm sorry i dont have one.
-
@Randy222 show me Your start script. Whole file from beginning to the last line, even if its a empty line.
attached
After some problems with home network and accidentially pushing it via adb non-root with no execute permissions (because of this I saw interesting things in the logs...), finally I made to boot with executing Your script. Looks like You added something more or it was like that before.
After running my scope on Your script I see two things...
One is this:
# 加载 MIPI 触摸屏驱动 - focaltech for guoxian
#sleep 20
insmod /rigol/driver/focaltech_ts.ko
sleep 20
echo ":STOP;:SYST:DATE 2099,12,31;:SYST:TIME 23,59,59;:DIS:CLOC 1" |toybox nc -q 2 localhost 5555
sleep 5
echo ":CHAN1:DISP 0" |toybox nc -q 2 localhost 5555
Why You (or somebody else) moved sleep 20 later instead leaving it? Somebody for some reason decided to make a delay before loading focaltech_ts.ko. I suggest to not change this behavior,
Second thing, now I have HW 0. I added echo before and after this printf and I can see it in log. Also file is created as it should.
So looks like something is wrong in Your script (before uploading it on my scope, printf trick was working). I dont want to waste time to debug this, so grab my script instead (attached) and try if it works as it should. This is almost original from 924S beside of printf, insmod commented out and chmod 444.
BTW. Im using FPGA flash from a DHO1000 (works the same). H12S2**** is for DHO1000 with single ADC as in readme.txt (GEL for DHO100 and DHO4000) from Rigol.
-
In retrospect to your resistor stack on the side, if they represent an "8" then I suspect RK gpio pins are coded with internal pull-up to avoid floats. But this is TBD.
While it is difficult to figure out which BGA pad each resistor is connected to, it is trivial to figure out whether their other ends are connected to GND or to a supply voltage. I don't understand why this aspect still seems to be a matter of guesswork?
(Of course, whatever the hardware readout of the GPIO is, it could still be inverted in software. Or used to index a lookup table to find the eventual "hardware version" ID, for that matter.)
-
@Randy222 show me Your start script. Whole file from beginning to the last line, even if its a empty line.
attached
After some problems with home network and accidentially pushing it via adb non-root with no execute permissions (because of this I saw interesting things in the logs...), finally I made to boot with executing Your script. Looks like You added something more or it was like that before.
After running my scope on Your script I see two things...
One is this:
# 加载 MIPI 触摸屏驱动 - focaltech for guoxian
#sleep 20
insmod /rigol/driver/focaltech_ts.ko
sleep 20
echo ":STOP;:SYST:DATE 2099,12,31;:SYST:TIME 23,59,59;:DIS:CLOC 1" |toybox nc -q 2 localhost 5555
sleep 5
echo ":CHAN1:DISP 0" |toybox nc -q 2 localhost 5555
Why You (or somebody else) moved sleep 20 later instead leaving it? Somebody for some reason decided to make a delay before loading focaltech_ts.ko. I suggest to not change this behavior,
Second thing, now I have HW 0. I added echo before and after this printf and I can see it in log. Also file is created as it should.
So looks like something is wrong in Your script (before uploading it on my scope, printf trick was working). I dont want to waste time to debug this, so grab my script instead (attached) and try if it works as it should. This is almost original from 924S beside of printf, insmod commented out and chmod 444.
BTW. Im using FPGA flash from a DHO1000 (works the same). H12S2**** is for DHO1000 with single ADC as in readme.txt (GEL for DHO100 and DHO4000) from Rigol.
Damn... After restoring back start_rigol_app.sh I still have HW in app as 0... So looks like something was changed permanently :/
Edit: Earlier I posted my 924S SD card image if somebody wants to test it.
-
In retrospect to your resistor stack on the side, if they represent an "8" then I suspect RK gpio pins are coded with internal pull-up to avoid floats. But this is TBD.
While it is difficult to figure out which BGA pad each resistor is connected to, it is trivial to figure out whether their other ends are connected to GND or to a supply voltage. I don't understand why this aspect still seems to be a matter of guesswork?
i didnt think of this. my scope is reassembled and i dont see much point to it anymore. thinking of it, even if the other end of resistors are connected to gnd, why the other ends also seemed paralleled? if they are connected directly to mcu pin? and with various and seemingly random resistor combination coming up with same HW number, all this binary theory seem nonsensical, better get ass down to soldering iron imho... anyway, lets other to discover this, i'm finished for the night.
Damn... After restoring back start_rigol_app.sh I still have HW in app as 0... So looks like something was changed permanently :/
told you its gonna bite! ;D thanks for your start_rigol_app.sh.txt link but now i'm too afraid to push it to my scope ;)
-
told you its gonna bite! ;D thanks for your start_rigol_app.sh.txt link but now i'm too afraid to push it to my scope ;)
Just for curiosity I tried to bring back hdcode_gpio module and I still have HW 0.
In last resort we (or just maybe only me?) have backup of sd card.
-
@Randy222 show me Your start script. Whole file from beginning to the last line, even if its a empty line.
attached
After some problems with home network and accidentially pushing it via adb non-root with no execute permissions (because of this I saw interesting things in the logs...), finally I made to boot with executing Your script. Looks like You added something more or it was like that before.
After running my scope on Your script I see two things...
One is this:
# 加载 MIPI 触摸屏驱动 - focaltech for guoxian
#sleep 20
insmod /rigol/driver/focaltech_ts.ko
sleep 20
echo ":STOP;:SYST:DATE 2099,12,31;:SYST:TIME 23,59,59;:DIS:CLOC 1" |toybox nc -q 2 localhost 5555
sleep 5
echo ":CHAN1:DISP 0" |toybox nc -q 2 localhost 5555
Why You (or somebody else) moved sleep 20 later instead leaving it? Somebody for some reason decided to make a delay before loading focaltech_ts.ko. I suggest to not change this behavior,
Second thing, now I have HW 0. I added echo before and after this printf and I can see it in log. Also file is created as it should.
So looks like something is wrong in Your script (before uploading it on my scope, printf trick was working). I dont want to waste time to debug this, so grab my script instead (attached) and try if it works as it should. This is almost original from 924S beside of printf, insmod commented out and chmod 444.
BTW. Im using FPGA flash from a DHO1000 (works the same). H12S2**** is for DHO1000 with single ADC as in readme.txt (GEL for DHO100 and DHO4000) from Rigol.
I tested delay before loading KLM for touchscreen. 'sleep 0' made no diff, so why delay the startup with a 'sleep 20'? I suspect much in the 800-900 start script (lots of code) is carry-over from other scope coding projects. Example, Rigol no longer starts the scope app in start script, it's just commeneted out. I posted about all of this long ago in this thread. If you mod the OEM start script and just comment out that sleep 20 before ts KLM, the unit will boot that much faster.
The 20 delay before sending scpi commands is because scope app is not yet ready to take actions from scpi commands. It's coincidence that the two are same number 20.
There's multiple scpi lines because if you send commands back-back the scope may ignore the aft items because it needs to wait for one scpi to complete before working on the next one. AT least from my testing and reading up on scpi, the commands should all be individual sends, but I was able to stack them to limit the number of nc's. If you send scpi commands individually but too fast back-back, you get same issue where some commands are ignored, so there really needs to be a delay bewteen commands so each one can complete before next one is received.
-
if souldevelop's report is correct... i just did some photoshop fun (attached) to find where are the 25AA, 28U, 30U, 26V pins are, somewhere in red circle... based on possible closest route, another candidate for config resistor could be in yellow circle.. we went through the blue circle fun ;D be warned you could damage something if not careful...
Those are some awesome Ps skillz you got there, Mister! Wicked. Wish I would've thought of & did that. :clap:
otoh i dont tend to do your sd card mod. possibly one day this thing is fixed whether in HW or SW, so we dont need to switch sd card anymore, so you'll be left with irreversible cutted top enclosure for no good reason. not a big deal really.
That's ok. My card hack isn't for everyone. I just posted it in case it might benefit someone.
Fantastic job figuring out the HW config bits, buddy.!
-
told you its gonna bite! ;D thanks for your start_rigol_app.sh.txt link but now i'm too afraid to push it to my scope ;)
There's nothing in that start script that impacts and HW number. The start script is sequences fpga, ts, does a boot counter, yada yada yada. Very boring stuff.
I added sysctl commands for tuning, and added some scpi commands to stop scope, turn off ch1, enable clock, and to set clock & date.
HW number in scope app comes from something reading the 4 gpio pin values. The pin states are read by the hdcode_gpio KLM.
How that 4bit word is read is TBD I guess.
I'll do some sleuthing.
-
told you its gonna bite! ;D thanks for your start_rigol_app.sh.txt link but now i'm too afraid to push it to my scope ;)
There's nothing in that start script that impacts and HW number. The start script is sequences fpga, ts, does a boot counter, yada yada yada. Very boring stuff.
I added sysctl commands for tuning, and added some scpi commands to stop scope, turn off ch1, enable clock, and to set clock & date.
HW number in scope app comes from something reading the 4 gpio pin values. The pin states are read by the hdcode_gpio KLM.
How that 4bit word is read is TBD I guess.
I'll do some sleuthing.
Theoretically it shoudlnt. But You have additional SCPI commands and sysctl values changed.
Nah, I will try to reinstall app - maybe it will help. If not, then I will reflash SD card.
Almost forget, I reflashed back original FPGA image, so I will try DHO100 back again.
-
While it is difficult to figure out which BGA pad each resistor is connected to, it is trivial to figure out whether their other ends are connected to GND or to a supply voltage. I don't understand why this aspect still seems to be a matter of guesswork?
I couldn't stand it, curiosity got the better of me. Although I don’t need this hardware hack, I’m just very interested in clarifying this issue myself. So, I disassembled and measured the resistances and connections between them. The result is a picture in the photo. Red are power connections, blue are ground connections, black are signal connections.
It turns out that four pairs of resistors take part in encoding the HW version: R1+R2, R3+R4, R7+R8 and R9+R10. Depending on which resistor of the pair is installed, the GPIO will be pulled to ground or to power.
Resistors R5 and R6 clearly stand out from the overall picture in terms of their values and location; this is something not related to HW coding.
-
told you its gonna bite!
Little strange, but I figured out direct cause.
[pid 3008] openat(AT_FDCWD, "/dev/hdcode_gpio", O_RDWR|O_NONBLOCK) = -1 EACCES (Permission denied)
File descriptor is opened with O_RDWR flag (why???), like it was always (I was using strace before), but according to current strace, now it fails.
Previously it was working with 444 (-r--r--r--) and now not so much. I changed it to 666 (rw) and now it works again (both printf and original module).
Probably Your script changed something, but who cares?
-
Anybody knows some deassembler or decompiler capable of arm64 and to view+change values in hex?
I tried gdb and Relyze (under Wine) - first displays values in other format (stackoverflow doesnt help) and second one fails with unknown opcode. So I cant change libscope-auklet.so.
-
It looks like the version encoding bits are arranged like this:
-
told you its gonna bite! ;D thanks for your start_rigol_app.sh.txt link but now i'm too afraid to push it to my scope ;)
There's nothing in that start script that impacts and HW number. The start script is sequences fpga, ts, does a boot counter, yada yada yada. Very boring stuff.
I added sysctl commands for tuning, and added some scpi commands to stop scope, turn off ch1, enable clock, and to set clock & date.
HW number in scope app comes from something reading the 4 gpio pin values. The pin states are read by the hdcode_gpio KLM.
How that 4bit word is read is TBD I guess.
I'll do some sleuthing.
Theoretically it shoudlnt. But You have additional SCPI commands and sysctl values changed.
Nah, I will try to reinstall app - maybe it will help. If not, then I will reflash SD card.
Almost forget, I reflashed back original FPGA image, so I will try DHO100 back again.
Theoretical?
-
Anybody knows some deassembler or decompiler capable of arm64 and to view+change values in hex?
I tried gdb and Relyze (under Wine) - first displays values in other format (stackoverflow doesnt help) and second one fails with unknown opcode. So I cant change libscope-auklet.so.
Ghidra, IDA.
-
I have 924S, later I will do some photosmodules
@norbert.kiszka I still dare to remind you.....
As for now I never removed heatsink. I was going to modify one channel, but I didnt. Also I cant find thermopads - Im not sure if I can reuse existing ones after heatisnk removal (maybe clean them with isopropyl?).
Anyway, I just did two photos just above heatsink. If You need something more (right now without removing heatsink), just give me a sign.
If You going to change only HW number, then read my previous posts about it, because You can change it in "soft" way, without changing resistors or decompiling anything.
Will somebody please tell @norbert.kiszka that:
a.) the "thermopads" can be re-used safely. 100% re-workable
b.) he doesn't need to clean them, and probably shouldn't to keep from degrading the pad.
c.) he can but probably doesn't need to, clean the chips or heatsink., unless it gets contaminated for some reason.
d.) he should leave the pads attached to whatever surface they are stuck to., as @Mechatrommer suggested.
e.) we would still love to see the "bottom side" pics of an authentic 900 series scope.
-
told you its gonna bite!
Little strange, but I figured out direct cause.
[pid 3008] openat(AT_FDCWD, "/dev/hdcode_gpio", O_RDWR|O_NONBLOCK) = -1 EACCES (Permission denied)
File descriptor is opened with O_RDWR flag (why???), like it was always (I was using strace before), but according to current strace, now it fails.
Previously it was working with 444 (-r--r--r--) and now not so much. I changed it to 666 (rw) and now it works again (both printf and original module).
Probably Your script changed something, but who cares?
So chmod 666 and not 444?
666 works, but I see no changes in scope. Lets see if a remove a lic file.
And I need to make a correction, I run my 804 with a 914 vebdor.bin file. I ight have said 924 in the past.
-
Will somebody please tell @norbert.kiszka that:
a.) the "thermopads" can be re-used safely. 100% re-workable
b.) he doesn't need to clean them, and probably shouldn't to keep from degrading the pad.
c.) he can but probably doesn't need to, clean the chips or heatsink., unless it gets contaminated for some reason.
d.) he should leave the pads attached to whatever surface they are stuck to., as @Mechatrommer suggested.
e.) we would still love to see the "bottom side" pics of an authentic 900 series scope.
But to access the back side of the board you don’t need to remove the heatsink at all :)
-
While it is difficult to figure out which BGA pad each resistor is connected to, it is trivial to figure out whether their other ends are connected to GND or to a supply voltage. I don't understand why this aspect still seems to be a matter of guesswork?
I couldn't stand it, curiosity got the better of me. Although I don’t need this hardware hack, I’m just very interested in clarifying this issue myself. So, I disassembled and measured the resistances and connections between them. The result is a picture in the photo. Red are power connections, blue are ground connections, black are signal connections.
It turns out that four pairs of resistors take part in encoding the HW version: R1+R2, R3+R4, R7+R8 and R9+R10. Depending on which resistor of the pair is installed, the GPIO will be pulled to ground or to power.
Resistors R5 and R6 clearly stand out from the overall picture in terms of their values and location; this is something not related to HW coding.
i think you nailed it. R1+R2 is most significant bit, and R7+R8 is the second. although there are still inconsistency in earlier table such as HW4 (0000) and HW13 (0010) ie R1-4. i guess the RK's pins are floating we should not let both resistors in a pair to be missing. if both resistors (pull up and pull down) are present, they combined (middle voltage) will still read as 0. congratulation on your work deciphering it.
-
i asked how to get to this console. but if you need me to have one linux pc, i'm sorry i dont have one.
I followed a guide and made a bootable USB stick for Ubuntu, which is super user friendly, intuitive and easy to use, to boot my Win10 machine with.
--I liked it so much that I used the built in boot utility to re-partition my Windoze and install Ubuntu permanently, and now I can pick which OS to run on start-up. It's awesome. One of the gurus here mentions Debian... A LOT. so maybe that is worth checking out.
FYI: I had to get a guide for BASH scripting, and that really helped understanding what's going on under the hood in those *.sh files.
IMHO; It's Linux's supercharged version of *.BAT files. Once you understand all the numbers, re-direct pipes etc., things get a bit easier.
-
Will somebody please tell @norbert.kiszka that:
a.) the "thermopads" can be re-used safely. 100% re-workable
no, the thermopad is very vurnerable, i tried to lift the pad for FPGA with tweezer it almost chipped where i pinched the tweezer, its like cheeze. either you handle/lift it with very care, or just leave it there where it stick... there is no glue or paste for it to stick, just an oily thing.
-
So chmod 666 and not 444?
If You try, it probably will not explode or take Your soul.
But to access the back side of the board you don’t need to remove the heatsink at all :)
To change HW number, You dont need to remove housing at all.
-
Will somebody please tell @norbert.kiszka that:
a.) the "thermopads" can be re-used safely. 100% re-workable
no, the thermopad is very vurnerable, i tried to lift the pad for FPGA with tweezer it almost chipped where i pinched the tweezer, its like cheeze. either you handle/lift it with very care, or just leave it there where it stick... there is no glue or paste for it to stick, just an oily thing.
I lifted them with my fingers. They are soft like American Cheese. Maybe the psi from a tweezer pinch is too much.
-
Will somebody please tell @norbert.kiszka that:
a.) the "thermopads" can be re-used safely. 100% re-workable
b.) he doesn't need to clean them, and probably shouldn't to keep from degrading the pad.
c.) he can but probably doesn't need to, clean the chips or heatsink., unless it gets contaminated for some reason.
d.) he should leave the pads attached to whatever surface they are stuck to., as @Mechatrommer suggested.
e.) we would still love to see the "bottom side" pics of an authentic 900 series scope.
But to access the back side of the board you don’t need to remove the heatsink at all :)
Oh yeah. True! I forgot that. Thanks.
-
So chmod 666 and not 444?
If You try, it probably will not explode or take Your soul.
But to access the back side of the board you don’t need to remove the heatsink at all :)
To change HW number, You dont need to remove housing at all.
chmod to 666 worked. But nothing in scope seemed to have changed.
My config however may be a limiting factor. I run 804 as a 914. Maybe HW 8 changes something if the vendor.bin was a 924 version?
I also removed all my lic files and tried HW 8. The about shows 914 125-BW HW-8, and the ch still has 50M depth.
So, perhaps mem depth is just from vendor.bin. I guess I could try a 924 vendor bin to see if the 250-BW comes in by default, but I have a lic for the 914.
So, for my setup, 804 running as 914 with lics, I don't think HW number matters. Is there anything in the 914 that an 804 could gain by going to HW-8? "HW-8" perhaps just indicated availablility of the digital probe interface?
All that, I am back to std insmod of hdcode KLM, HW-12 running as a 914 50M 250BW. I think this is the best an 800 can get without hardware hacking.
-
chmod to 666 worked. But nothing in scope seemed to have changed.
Maybe RKey.data? Anyway, You can try my SD card image (flash it or copy single files after mounting it with offsets) which I posted some days ago... Its almost original DHO924S - only added Nova launcher and VCMI (engine for HIII game).
but you need to unscrew all the heatsink's screws because the threads are on the metal enclosure, you can do without removing heatsink but be carefull when switching pcb upside down, heatsink could fall by gravity, if it drops to hard rock floor, its possible to break into pieces, i dont know what aluminium they used, hopefuilly not brittle one.
It looks like cheap one. I dont expect aviation grade aluminium in a cheap oscilloscope.
-
i think you nailed it. R1+R2 is most significant bit, and R7+R8 is the second. although there are still inconsistency in earlier table such as HW4 (0000) and HW13 (0010) ie R1-4.
Yes, this confuses me a little too, but it could be, for example, due to flux residues.
i guess the RK's pins are floating we should not let both resistors in a pair to be missing. if both resistors (pull up and pull down) are present, they combined (middle voltage) will still read as 0. congratulation on your work deciphering it.
That's right, each pair must contain one of the resistors. And only one. Two resistors is also incorrect, since this is a formally undefined value.
But to access the back side of the board you don’t need to remove the heatsink at all :)
To change HW number, You dont need to remove housing at all.
Your method is not the only correct one. Some people would prefer to change the version in hardware rather than in software.
But to access the back side of the board you don’t need to remove the heatsink at all :)
but you need to unscrew all the heatsink's screws because the threads are on the metal enclosure, you can do without removing heatsink but be carefull when switching pcb upside down, heatsink could fall by gravity, if it drops to hard rock floor, its possible to break into pieces, i dont know what aluminium they used, hopefuilly not brittle one.
No, 6 of the 8 screws holding the heatsink are not screwed into the metal chassis, but into bonnets soldered into the board.
-
I just made a order for new thermopads (6 W/m⋅K). I need to remove this heatsink for many reasons - including photos and overclocking this puppy (which I already did but as for now only FPGA).
-
chmod to 666 worked. But nothing in scope seemed to have changed.
Maybe RKey.data? Anyway, You can try my SD card image (flash it or copy single files after mounting it with offsets) which I posted some days ago... Its almost original DHO924S - only added Nova launcher and VCMI (engine for HIII game).
but you need to unscrew all the heatsink's screws because the threads are on the metal enclosure, you can do without removing heatsink but be carefull when switching pcb upside down, heatsink could fall by gravity, if it drops to hard rock floor, its possible to break into pieces, i dont know what aluminium they used, hopefuilly not brittle one.
It looks like cheap one. I dont expect aviation grade aluminium in a cheap oscilloscope.
RKey stayed the same.
However, RKey will be regen if the RKey is missing. So I am not sure if HW-8 would gen a new RKey that would unlock additional features.
With 800 being limited in actual hardware, I don't think there's much to gain when using a 914 or 924 vendor.bin, other than 250BW and 50M depth, but we can get that on a 800 vendor.bin using the zelea2 lic gen tool.
My 804 became a 914, all that really changed was the addition of the digi pad in bottom of screen, which cannot be used on 800 hardware.
-
I just made a order for new thermopads (6 W/m⋅K). I need to remove this heatsink for many reasons - including photos and overclocking this puppy (which I already did but as for now only FPGA).
Have you overclocked your FPGA? So you already have a confirmed sampling frequency greater than 1.25 GHz?
-
But to access the back side of the board you don’t need to remove the heatsink at all :)
but you need to unscrew all the heatsink's screws because the threads are on the metal enclosure, you can do without removing heatsink but be carefull when switching pcb upside down, heatsink could fall by gravity, if it drops to hard rock floor, its possible to break into pieces, i dont know what aluminium they used, hopefuilly not brittle one.
It's actually cast aluminum, with machining operations after casting.. Pretty typical in low budget, high volume applications, and sadly, also less thermal conductivity compared to extruded aluminum heatsinks.
-
I just made a order for new thermopads (6 W/m⋅K). I need to remove this heatsink for many reasons - including photos and overclocking this puppy (which I already did but as for now only FPGA).
Have you overclocked your FPGA? So you already have a confirmed sampling frequency greater than 1.25 GHz?
FPGA and DAC are of course two separate things. I just found sample rate limit in a libscope-auklet.so and Im going to break this thing. PLL is capable up to 5.5 GHz, but probably DAC has own internal freq. multiplier (according to my findings in a software), so PLL is not a problem here. Anyway, PLL kernel module is just a very simple library to make SPI from GPIO pins - so we possibly can manage PLL frequency without app and FPGA, but its pointless (app needs to change that and user has to calculate time measurements every time - so its heavly time consuming and prone to errors).
Speaking of experiments. In DHA1k/4k GEL there is a many FPGA images - there is a readme of what is what (two different FPGA models and one/two DACs). I didnt make notes (lazy me) but images with _bode and end of file name, gives strange and rare spikes in a waveform (beside of that it works). However I decided to test runt trigger on it and it works perfectly.
Edit: I was thinking about changing FPGA but it takes time and money, also I dont like to (de)solder BGA. DHO4000 have two dacs and FPGA with two cores instead of one - probably because of two dacs.
-
Calibration and Debug menu
After hitting About 3x, in the debug menu, anyone tune the ADC Clock settings?
Then in the SelfCal menu, it shows 12 cal items. If Itry to select them all, the cal fails. Should they not all pass? Maybe some are not applicable to an 804 running with a 914 vendor.bin ?
-
Calibration and Debug menu
After hitting About 3x, in the debug menu, anyone tune the ADC Clock settings?
Then in the SelfCal menu, it shows 12 cal items. If Itry to select them all, the cal fails. Should they not all pass? Maybe some are not applicable to an 804 running with a 914 vendor.bin ?
Once I tried to select only DDR with FPGA flashed with image from DHO1000 and it works. Also it gives some data after click on "detail".
Now I tried once more and after that I see random short and big spikes on unconnected channel...
Edit: after running it third time (DDR+CH1), spikes are the same. But after restarting app spikes disapered.
-
FPGA and DAC are of course two separate things.
These are very closely related things, so until working sampling above 1.25 GHz has been achieved, talking about any overclocking of the FPGA makes no sense :) And I repeat once again that the Artix firmware will not work in Zynq. These are too different systems. No matter how much you want to believe otherwise.
DHO4000 have two dacs and FPGA with two cores instead of one - probably because of two dacs.
Did you want to write an ADC rather than a DAC? And what two cores are we talking about? What kind of cores does Artix have? Zynq actually has a dual-core processor on board, this is its main difference from Artix.
Then in the SelfCal menu, it shows 12 cal items. If Itry to select them all, the cal fails. Should they not all pass? Maybe some are not applicable to an 804 running with a 914 vendor.bin ?
No, calibration fails even in an oscilloscope without modifications if you select unnecessary items.
-
Artix firmware will not work in Zynq
But other way around? There are many images in GEL for DHO1000/DHO4000. I tested it and some of them works the same as original DHO800/900 (BOOT.bin) and some makes distortions in a waveform.
Did you want to write an ADC rather than a DAC?
Yeah, my mistake.
talking about any overclocking of the FPGA makes no sense :)
Thats a one (small) step closer to increase sample rate.
And I repeat once again that the Artix firmware will not work in Zynq
Did You try this? Or its just me?
Zynq actually has a dual-core processor on board, this is its main difference from Artix.
Two ADC = two cores in FPGA. Probably.
No, calibration fails even in an oscilloscope without modifications if you select unnecessary items.
DDR option works. This is probably related to DMA stuff.
-
But other way around? There are many images in GEL for DHO1000/DHO4000. I tested it and some of them works the same as original DHO800/900 (BOOT.bin) and some makes distortions in a waveform.
It won't be the other way around either. How can I explain it to you using an example that you can understand... It’s like taking a Linux image compiled for RK3399 and trying to run it on RK3368.
Thats a one (small) step closer to increase sample rate.
This is a small step in an unknown direction with an unknown result. And even with a misunderstanding whether there is any result at all :)
Did You try this? Or its just me?
I worked with FPGAs, wrote firmware for them. So I know what FPGAs are, how they work, what the binary for them is and how it loads and works.
Two ADC = two cores in FPGA. Probably.
FPGAs have no cores at all. There is not even such a thing as a kernel. In general, with FPGAs everything is very simple - it’s just a lot of elementary logical elements - latches, flip-flops, Look-Up tables. And the binary file simply defines the connections between them. That's all. There are also additional blocks, such as RAM, multipliers, PLLs, transceivers, etc., but they are simply there as auxiliary peripherals.
DDR option works. This is probably related to DMA stuff.
Well, not all options lead to calibration failure. But I know for sure that the crash is caused by even just one option included in addition to the standard ones. I don’t remember which one exactly.
-
FPGAs have no cores at all. There is not even such a thing as a kernel. In general, with FPGAs everything is very simple - it’s just a lot of elementary logical elements - latches, flip-flops, Look-Up tables. And the binary file simply defines the connections between them. That's all. There are also additional blocks, such as RAM, multipliers, PLLs, transceivers, etc., but they are simply there as auxiliary peripherals.
So what is this:
[attach=1]
-
So, for my setup, 804 running as 914 with lics, I don't think HW number matters. Is there anything in the 914 that an 804 could gain by going to HW-8? "HW-8" perhaps just indicated availablility of the digital probe interface?
Digital probe Interface will be activated once your probe adapter pod shorts pin 1-2. See my post here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5322059/#msg5322059)
You can even try it without the adapter using some tweezers, if you're interested.
-
But other way around? There are many images in GEL for DHO1000/DHO4000. I tested it and some of them works the same as original DHO800/900 (BOOT.bin) and some makes distortions in a waveform.
By the way, if you even manage to stuff the firmware from Artix into Zynq (by cutting off the extra length of the file, correcting the header, recalculating the checksums), then you have a very good chance of burning out your oscilloscope as a result - the FPGA itself, the processor or the ADC :)
-
FPGAs have no cores at all. There is not even such a thing as a kernel. In general, with FPGAs everything is very simple - it’s just a lot of elementary logical elements - latches, flip-flops, Look-Up tables. And the binary file simply defines the connections between them. That's all. There are also additional blocks, such as RAM, multipliers, PLLs, transceivers, etc., but they are simply there as auxiliary peripherals.
So what is this:
(Attachment Link)
This is the Zynq family, which is installed in 800/900, but not in 1000/4000. And this is not a pure FPGA, but a SoC, which includes both an FPGA and a processor.
-
FPGAs have no cores at all. There is not even such a thing as a kernel. In general, with FPGAs everything is very simple - it’s just a lot of elementary logical elements - latches, flip-flops, Look-Up tables. And the binary file simply defines the connections between them. That's all. There are also additional blocks, such as RAM, multipliers, PLLs, transceivers, etc., but they are simply there as auxiliary peripherals.
So what is this:
(Attachment Link)
This is the Zynq family, which is installed in 800/900, but not in 1000/4000. And this is not a pure FPGA, but a SoC, which includes both an FPGA and a processor.
Hmmmm
FPGA bit文件说明
按照FPGA器件型号
A100T 标识符
A75T 标识符 B
按照ADC颗粒(采样率)
2ADC 4GSa/s 标识符 S4
1ADC 2GSa/s 标识符 S2
HDO4000-FPGA-A100T
bit1 SPU_H12S4_SelfTest.bit 完成芯片和板级自检；包括DDR校准参数回读。
bit2 SPU_H12S4.bit 常规示波器程序，无Bode图功能
bit3 SPU_H12S4_bode.bit Bode功能版本，无高分辨率
HDO2000/1000-FPGA-A100T
bit1 SPU_H12S2_SelfTest.bit 完成芯片和板级自检；包括DDR校准参数回读。
bit2 SPU_H12S2.bit 常规示波器程序，无Bode图功能
bit3 SPU_H12S2_bode.bit Bode功能版本，无高分辨率
HDO4000-FPGA-A75T
bit1 SPU_H12S4B_SelfTest.bit 完成芯片和板级自检；包括DDR校准参数回读。
bit2 SPU_H12S4B.bit 常规示波器程序，无Bode图功能
bit3 SPU_H12S4B_bode.bit Bode功能版本，无高分辨率
HDO2000/1000-FPGA-A75T
bit1 SPU_H12S2B_SelfTest.bit 完成芯片和板级自检；包括DDR校准参数回读。
bit2 SPU_H12S2B.bit 常规示波器程序，无Bode图功能
bit3 SPU_H12S2B_bode.bit Bode功能版本，无高分辨率
-
FPGA bit文件说明
按照FPGA器件型号
A100T 标识符
A75T 标识符 B
Here they told you in plain text which FPGA models are used - A75T and A100T. This is the Artix 7 family. I would highly recommend studying the base more carefully before trying to poke a stick into the unknown :)
Here even the difference in file sizes should alert you. The fact is that the binary for the same FPGA model always has the same size, regardless of what firmware it contains - test, working, or even from a completely different device.
P.S. An acquaintance of mine who works with both Artix and Zynq just now confirmed to me that the possibility of running firmware for one family in an FPGA of another family is completely excluded. I myself worked with FPGAs from Altera (Intel), and although all FPGAs work in the same way, I still asked him specifically about Artix and Zynq :)
-
But other way around? There are many images in GEL for DHO1000/DHO4000. I tested it and some of them works the same as original DHO800/900 (BOOT.bin) and some makes distortions in a waveform.
By the way, if you even manage to stuff the firmware from Artix into Zynq (by cutting off the extra length of the file, correcting the header, recalculating the checksums), then you have a very good chance of burning out your oscilloscope as a result - the FPGA itself, the processor or the ADC :)
IMHO Its higher chance to burn ADC (capable of 2G) instead of FPGA. Its something like a shorting output with input of Schmitt inverter "gate" - theoretically You shouldnt, practically (in 74AC14) it becomes unstable generator of ~110 MHz (exact frequency depends on moon phase, temperature and time of a day).
FPGA bit文件说明
按照FPGA器件型号
A100T 标识符
A75T 标识符 B
Here they told you in plain text which FPGA models are used - A75T and A100T. This is the Artix 7 family. I would highly recommend studying the base more carefully before trying to poke a stick into the unknown :)
Here even the difference in file sizes should alert you. The fact is that the binary for the same FPGA model always has the same size, regardless of what firmware it contains - test, working, or even from a completely different device.
P.S. An acquaintance of mine who works with both Artix and Zynq just now confirmed to me that the possibility of running firmware for one family in an FPGA of another family is completely excluded. I myself worked with FPGAs from Altera (Intel), and although all FPGAs work in the same way, I still asked him specifically about Artix and Zynq :)
rk3399_rigol:/ # ls -l /rigol/FPGA/
total 81520
-rwxrwxrwx 1 root root 3825893 2024-03-12 06:47 BOOT.bin
-rwxrwxrwx 1 root root 3631368 2013-01-18 09:42 BOOT.bin_
-rwxrwxrwx 1 root root 3631368 2013-01-18 09:42 BOOT_SelfTest.bin
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S2.bit
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S2_SelfTest.bit
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S2_bode.bit
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S4.bit
-rwxrwxrwx 1 root root 3825893 2024-03-12 06:47 SPU_H12S4B.bit
-rwxrwxrwx 1 root root 3825893 2024-03-12 06:47 SPU_H12S4B_SelfTest.bit
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S4_SelfTest.bit
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S4_bode.bit
-rwxrwxrwx 1 root root 1192 2024-03-12 06:47 readme.txt
rk3399_rigol:/ # /rigol/shell/reload_fpga.sh /rigol/FPGA/SPU_H12S2.bit 0x400000
2024.03.14 10.03.46 509584 us
/rigol/tools/spi2erase /rigol/FPGA/SPU_H12S2.bit 0x400000
spi clock : 10 M, using bit: /rigol/FPGA/SPU_H12S2.bit
Download K7 master
Sending :0x3a60e6
Waiting 20s For Erase Flash...
done
2024.03.14 10.04.06 578167 us
/rigol/tools/spi2flash /rigol/FPGA/SPU_H12S2.bit 0x400000
spi clock : 10 M, using bit: /rigol/FPGA/SPU_H12S2.bit
Download K7 master
Sending :0x3a60e6
Start Prog Flash
done
2024.03.14 10.04.31 653066 us
/rigol/tools/spi2boot 0x400000
Boot MultiBoot Image
Waiting 5s For MultiBoot Image Boot...
done
00:00.0 Class 0604: Device 1d87:0100
01:00.0 Class 0700: Device 10ee:7022
Memory map to 0xf5ffd000
offset = 0x4000
Read(0x4000) = #0x1062919#
rk3399_rigol:/ #
-
my DHO804 came with an old firmware (00.01.00.something if I remember). Hacking with the vendor method on this version works but the offset calibration of the 4 channels will be inaccurate even after making the oscilloscope running a self-calibration. I've understand that the best method today is to first upgrade the firmware then apply the vendor method hack from @zelea2
By the way, yes - you need to add to the description that before increasing the model number you need to make sure that the firmware version is not less than 00.01.02.00.02. Thanks for writing about this :)
-
IMHO Its higher chance to burn ADC (capable of 2G) instead of FPGA. Its something like a shorting output with input of Schmitt inverter "gate" - theoretically You shouldnt, practically (in 74AC14) it becomes unstable generator of ~110 MHz (exact frequency depends on moon phase, temperature and time of a day).
When uploading someone else's firmware from another device, there is a very high probability that one of the pins, which was configured as an input by the native firmware, will be configured as an output by someone else's firmware. And it turns out that, for example, the processor output will be connected to the FPGA output. And if the processor sets it to 0, and the FPGA sets it to 1 (or vice versa), then there will actually be a short circuit on both of these outputs. Will both of these outputs survive, or will the output driver of one of them go into oblivion - a very interesting question. I wouldn't want to learn the answer to this from practice on my several hundred dollar oscilloscope.
rk3399_rigol:/ # /rigol/shell/reload_fpga.sh /rigol/FPGA/SPU_H12S2.bit 0x400000
2024.03.14 10.03.46 509584 us
/rigol/tools/spi2erase /rigol/FPGA/SPU_H12S2.bit 0x400000
spi clock : 10 M, using bit: /rigol/FPGA/SPU_H12S2.bit
Download K7 master
Sending :0x3a60e6
Waiting 20s For Erase Flash...
done
2024.03.14 10.04.06 578167 us
/rigol/tools/spi2flash /rigol/FPGA/SPU_H12S2.bit 0x400000
spi clock : 10 M, using bit: /rigol/FPGA/SPU_H12S2.bit
Download K7 master
Sending :0x3a60e6
Start Prog Flash
done
2024.03.14 10.04.31 653066 us
/rigol/tools/spi2boot 0x400000
Boot MultiBoot Image
Waiting 5s For MultiBoot Image Boot...
done
00:00.0 Class 0604: Device 1d87:0100
01:00.0 Class 0700: Device 10ee:7022
Memory map to 0xf5ffd000
offset = 0x4000
Read(0x4000) = #0x1062919#
rk3399_rigol:/ #
This is a log of the binary being written to SPI flash. This doesn’t mean anything, the flash drive doesn’t care what they load into it, even a video instead of firmware.
-
FYI, here's just a comparison of the maximum data transfer rates of the high speed interfaces between Artix and ZYNQ FPGAs (taken from Xilinx's product selection guides) - see attachements.
The XC7A100T (used in DHO1000/4000) is easily four times outperforming the Z-7015 from the DHO800/900. Since this interface is used to move the data from the ADC(s) to the sampling RAM, this clearly explains why Rigol chose to limit the 800/900's sampling rate to 1.25GSa/s while the ADC could run at 2GSa/s. The fourfold performace of the Artix on the other hand, is able to serve two of Rigol's ADCs at full grunt.
I assume that Rigol chose to transfer the data to the RAM as 16bit numbers (and not 12 bit "interleaved" since the overhead would be excessive) which results at a sustained transfer rate of 20Gbit/s @ 1.25GSa/s, add some small overhead and the 25Gbit/s specified for the ZYNQ doesn't seem too generous...
Even though it's a pity, I highly doubt that an up-hack of the DHO800/900's sampling rate is possible with the existing hardware. I'ld be glad to be proven wrong... ;)
-
FYI, here's just a comparison of the maximum data transfer rates of the high speed interfaces between Artix and ZYNQ FPGAs (taken from Xilinx's product selection guides) - see attachements.
The XC7A100T (used in DHO1000/4000) is easily four times outperforming the Z-7015 from the DHO800/900. Since this interface is used to move the data from the ADC(s) to the sampling RAM, this clearly explains why Rigol chose to limit the 800/900's sampling rate to 1.25GSa/s while the ADC could run at 2GSa/s. The fourfold performace of the Artix on the other hand, is able to serve two of Rigol's ADCs at full grunt.
I assume that Rigol chose to transfer the data to the RAM as 16bit numbers (and not 12 bit "interleaved" since the overhead would be excessive) which results at a sustained transfer rate of 20Gbit/s @ 1.25GSa/s, add some small overhead and the 25Gbit/s specified for the ZYNQ doesn't seem too generous...
Even though it's a pity, I highly doubt that an up-hack of the DHO800/900's sampling rate is possible with the existing hardware. I'ld be glad to be proven wrong... ;)
Thanks for your voice of reason. :popcorn: Something I think people tend to overlook here, is that these parts also have to gen 14bit ARB data, and capture 16 channels of digital data whilst handling 4 ADC streams, concurrently... (DHO9x4S models) Lots of bits!
-
Speaking of additional calibration options.. I hadn't noticed this before tonight. There is a "Detail" drop-down on the SelfCal window with some interesting calibration info. -if it passes-
[attachimg=1 width=400]
BTW: these are all the "additional calibration" options that I found to calibrate with success. Anything else added will fail.
[attachimg=2 width=400]
FYI: it took 7 hours to test all the permutations, because some would go 98 or 99% before stopping or crashing.
-
To change HW number, You dont need to remove housing at all.
Your method is not the only correct one. Some people would prefer to change the version in hardware rather than in software.
So far, the only known benefit from changing the hardware ID is better (full?) support for a logic analyser port added to the DHO800. Even with future exploration, changing the hardware ID will probably only make sense when the hardware is changed. ;)
Hence it makes good sense to me to actually change the ID via a hardware (i.e. resistor) modification. One has to open the scope and solder on the main PCB anyway, to make the actual hardware change/upgrade of interest. And then one ends up with a physically encoded ID which will survive all future firmware updates -- whether official ones from Rigol or "homebrew" -- without potential complications.
-
To change HW number, You dont need to remove housing at all.
Your method is not the only correct one. Some people would prefer to change the version in hardware rather than in software.
So far, the only known benefit from changing the hardware ID is better (full?) support for a logic analyser port added to the DHO800. Even with future exploration, changing the hardware ID will probably only make sense when the hardware is changed. ;)
Hence it makes good sense to me to actually change the ID via a hardware (i.e. resistor) modification. One has to open the scope and solder on the main PCB anyway, to make the actual hardware change/upgrade of interest. And then one ends up with a physically encoded ID which will survive all future firmware updates -- whether official ones from Rigol or "homebrew" -- without potential complications.
i wish there is easy and stable method in SW.. so we can switch back easily. There probably trap when you change ID to HW that is not deserving, such as missing ddr3 ram.. i'm on hp, so icant type long.."
-
The opposite side of the front panel control board. Not much here, but posting in case anyone is curious. It wasn't in Dave's Flickr teardown set.
[attach=1 width 300]
In case any dho800->924S users are wondering; the gold plated switch pads (for the ARB and LA buttons) are there in my photo. The LED's are unpopulated though, and you would need a way to push the buttons. But hey! There's a way, at least!
-
When uploading someone else's firmware from another device, there is a very high probability that one of the pins, which was configured as an input by the native firmware, will be configured as an output by someone else's firmware. And it turns out that, for example, the processor output will be connected to the FPGA output. And if the processor sets it to 0, and the FPGA sets it to 1 (or vice versa), then there will actually be a short circuit on both of these outputs. Will both of these outputs survive, or will the output driver of one of them go into oblivion - a very interesting question. I wouldn't want to learn the answer to this from practice on my several hundred dollar oscilloscope.
Thats possible, but IMHO its higher chance of hardware damage caused by ESD - from my personal experience. Anyway, If I will fail, then I will have story to tell. Speaking of reverse engineering, in libscope-auklet.so there is a banch of decoding (audio, aviation buses, power calculations) options which so far currently nobody unlocked - looks like its for other models in vendor.bin and it can be disabled by hardcode. Its not easy to read dissassembled/decompiled code, but I think thats possible.
I assume that Rigol chose to transfer the data to the RAM as 16bit numbers (and not 12 bit "interleaved" since the overhead would be excessive) which results at a sustained transfer rate of 20Gbit/s @ 1.25GSa/s, add some small overhead and the 25Gbit/s specified for the ZYNQ doesn't seem too generous...
Even though it's a pity, I highly doubt that an up-hack of the DHO800/900's sampling rate is possible with the existing hardware. I'ld be glad to be proven wrong... ;)
So theoretically if data going from ADC to FPGA is without any checksums or other overhead, then without overclocking or changing FPGA it should be possible to do 1.25 * (25 / 20) = 1.5625 GHz. That exact number probably would by tricky in changing mentioned lib, because they made sample rate ratio with multiples of 400, 500 and... 625. I just started to decompile this .so, so there is a lot more things to read and test it...
I did the "impossible" things before. Sadly I cant tell of most "impossible" thing I done, because its a secret - somebody payed me just for trying and I succeed anyway and that took months of hard work (half of it was caused by my stupid mistake in a code...).
-
No, 6 of the 8 screws holding the heatsink are not screwed into the metal chassis, but into bonnets soldered into the board.
you are right. i've added 2b.jpg in the step, only 2 screws need to unscrew without removing heatsink. i didnt notice the bonnet things. deleted my invalid post...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389052/#msg5389052 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389052/#msg5389052)
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2071565;image)
i imagine its something like DLL or drv? i have free ed IDA, so i can open a little bit exe or dll, but since its Linux/android i'm pretty much zero about how things work in those system.
Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries. IDA understands these files without problems, as does Ghidra.
last night i downloaded latest version of IDA free version. it said the .ko file is ARM64 and i need to pay additional module. going to their website, it is unclear as my friend's language which version and at what price to buy. so this is beyond my paygrade. and then i downloaded ghidra as per your advice (JDK 21 also needed to install) then i can see something, it has printk and function names, if HW code is indeed is written to a file, then may as well this is what norbert mentioned about. in the mean time i'll try to gather norbert's cryptic posts hopefully i can make out something from them later. its not a one hour job though (noob learning btw the possibility of the other alternative)...
-
last night i downloaded latest version of IDA free version. it said the .ko file is ARM64 and i need to pay additional module. going to their website, it is unclear as my friend's language which version and at what price to buy. so this is beyond my paygrade. and then i downloaded ghidra as per your advice (JDK 21 also needed to install) then i can see something, it has printk and function names, if HW code is indeed is written to a file, then may as well this is what norbert mentioned about. in the mean time i'll try to gather norbert's cryptic posts hopefully i can make out something from them later. its not a one hour job though (noob learning btw the possibility of the other alternative)...
I already posted here decompiled hdcode_gpio.ko and looks like its pretty simple module reading gpio and writing one byte into a file and nothing more. Thats why I posted to do printf (to generate one byte file) in a shell script - instead of unnecessary damaging guaranty sticker and heating PCB with components on it.
-
Any chance on enabling the dot mode display? It really sucks that it's not possible. Has anyone come across any hints in the java app or otherwise?
-
Any chance on enabling the dot mode display? It really sucks that it's not possible. Has anyone come across any hints in the java app or otherwise?
Im not familiar with Java language, but I found this:
for (int i = 0; i < width2; i++) {
this.path.lineTo(i, (float) ((this.amplitude * Math.sin((((1.0f * f) / getWidth()) * 2 * 3.141592653589793d * this.angularFrequency) + this.phaseAngle)) + (getHeight() / 2)));
}
-
OMG a hard coded approximation for pi instead of using the Math.PI (a static final double constant in Java).
(sorry, I'm a mathematician and can't stand this style of programming |O).
-
I mentioned last week to have install script for mod'd APK. Attached is the bundle, read the README before using.
We are in a hacking thread, so for context, a hacking thread.
The bundle is based on AndyBig initial mod'd Scope APK, which worked but had Quick button issue that I found to be an Android permission issue, needed access to Surface_Flinger, so I edited manifest in that APK to include the permission and also updated the Android platform permissions file.
Beyond that, use as you see fit.
I will mention again, read the README before using.
-
OMG a hard coded approximation for pi instead of using the Math.PI (a static final double constant in Java).
(sorry, I'm a mathematician and can't stand this style of programming |O).
Here in the code this is a static constant with double precision :) Most likely it was Math.PI that was used in the source code.
-
OMG a hard coded approximation for pi instead of using the Math.PI (a static final double constant in Java).
(sorry, I'm a mathematician and can't stand this style of programming |O).
Math.PI is not properly irrational either. ;)
-
heating PCB with components on it.
for some, this is bread and butter and hope...
decompiled hdcode_gpio.ko and looks like its pretty simple module reading gpio and writing one byte into a file and nothing more. Thats why I posted to do printf (to generate one byte file) in a shell script
but since there not yet solid and stable solution, i guess its not that simple. from fractions that i can understand, there's complication such as compiled apk/ko kernel authentication error? (MITM spoofing from inside ie modified code/compiled app file) or sleep timing complication? (MITM spoof and sniff from outside? hook/script whatever it is) btw i have no clue about how android/linux system works, you are ahead in this we are counting on you. i may do/learn this on free time next time if i can dig whats the real complications are with hints from posts of you people. cheers.
OMG a hard coded approximation for pi instead of using the Math.PI (a static final double constant in Java).
(sorry, I'm a mathematician and can't stand this style of programming |O).
but you know how to complain when the machine is stupid slow right? ;D this is a good example of how a rough approximation is necessary (compulsory) to make things work. you need to learn to accept "good enough" in engineering, this is not theoretical physics or mathematics ;) cheers.
Here in the code this is a static constant with double precision :) Most likely it was Math.PI that was used in the source code.
didnt someone told him? delusion in the sky. 14 decimal places is way more than good enough.
-
Speaking of additional calibration options.. I hadn't noticed this before tonight. There is a "Detail" drop-down on the SelfCal window with some interesting calibration info. -if it passes-
(Attachment Link)
BTW: these are all the "additional calibration" options that I found to calibrate with success. Anything else added will fail.
(Attachment Link)
FYI: it took 7 hours to test all the permutations, because some would go 98 or 99% before stopping or crashing.
What's the ADC Clock adjustments in Debug? Is that only used when you have $50,000 calibration signal feeding the inputs?
-
heating PCB with components on it.
for some, this is bread and butter and hope...
:-BROKE
decompiled hdcode_gpio.ko and looks like its pretty simple module reading gpio and writing one byte into a file and nothing more. Thats why I posted to do printf (to generate one byte file) in a shell script
but since there not yet solid and stable solution, i guess its not that simple. from fractions that i can understand, there's complication such as compiled apk/ko kernel authentication error? (MITM spoofing from inside ie modified code/compiled app file) or sleep timing complication? (MITM spoof and sniff from outside? hook/script whatever it is) btw i have no clue about how android/linux system works, you are ahead in this we are counting on you. i may do/learn this on free time next time if i can dig whats the real complications are with hints from posts of you people. cheers.
Probably You missed my posts about chmod. App creates file descriptor with RW flag (but it doesnt write into that file). In my case 444 was working, but in case of @Randy222 it wasnt. As far as I remeber, changing 444 to 666 (2 = write permission) worked for him.
In other words do:
chmod 666 /dev/hdcode_gpio
Instead of:
chmod 444 /dev/hdcode_gpio
-
Probably You missed my posts about chmod. App creates file descriptor with RW flag (but it doesnt write into that file). In my case 444 was working, but in case of @Randy222 it wasnt. As far as I remeber, changing 444 to 666 (2 = write permission) worked for him.
In other words do:
chmod 666 /dev/hdcode_gpio
Instead of:
chmod 444 /dev/hdcode_gpio
Yes, 444 no good. 666 is good.
But I noted, on my 804 (probably for all 800's), HW-12 to HW-8 (via software) does not appear to enrich the product. I also run my 804 with the 914 vendor.bin and some lics.
Didn't you mention the hdcode KLM was being called by other processes so not really sure what the impact is when disabling that KLM?
It might be a prudent test to mod that ko KLM so that it perhaps reads a user file that logical maps the gpio pin names to a value, this way you can just plop 0 or 1 into a file and reload the KLM. This would bypass actual read to the RK, etc.
We must remember that the 900 has a bunch more hardware inside.
We could probably carve out a hack thread for 800, and one for 900, but this thread is long and very mixed already.
-
Probably You missed my posts about chmod. App creates file descriptor with RW flag (but it doesnt write into that file). In my case 444 was working, but in case of @Randy222 it wasnt. As far as I remeber, changing 444 to 666 (2 = write permission) worked for him.
In other words do:
chmod 666 /dev/hdcode_gpio
Instead of:
chmod 444 /dev/hdcode_gpio
Yes, 444 no good. 666 is good.
But I noted, on my 804 (probably for all 800's), HW-12 to HW-8 (via software) does not appear to enrich the product. I also run my 804 with the 914 vendor.bin and some lics.
Didn't you mention the hdcode KLM was being called by other processes so not really sure what the impact is when disabling that KLM?
We must remember that the 900 has a bunch more hardware inside.
We could probably carve out a hack thread for 800, and one for 900, but this thread is long and very mixed already.
(https://i.gremicdn.pl/image/free/5add142da8c2baf69ff68e2c205cac85/?t=resize:fill:1200:716,enlarge:1)
GPIO pins can be read and write only by kernel modules. We can decompile other modules, but I doubt that other modules reads those pins.
-
GPIO pins can be read and write only by kernel modules. We can decompile other modules, but I doubt that other modules reads those pins.
Yes, the platform uses that hdcode KLM, perhaps in various ways. I was suggesting mod the KLM to not even read RK gpio, but rather just read a file to obtain values. This way the KLM stays loaded, but we then get control of the values via user file.
-
Scope cpu temp. for stock fan configurations only.
In Utility , in the self-check board test, what do your ambient and cpu temps say?
Some many posts back I mentioned I added thermal paste between the heatsink pads, trying to ascertain any benefits.
My scope has been on for about 1hr, it's doing no work (all channels are off) temps are
cpu_chip / cpu_amb
52.7/48.7
cpu_chip 52.7
cpu_amb 48.7
room amb is 23.5
Mine had ~56/52 respectively at ~21-22 room ambient.
My DHO temps remain a constant 4 diff. After running several cal routines, which takes cpu up to around 50%, temps rose to 57/53.
-
GPIO pins can be read and write only by kernel modules.
Can also be done from userspace by accessing /dev/mem directly.
-
GPIO pins can be read and write only by kernel modules.
Can also be done from userspace by accessing /dev/mem directly.
We can strace syscalls and filter syscalls related to files - which I did couple times. I dont remeber any fd opened for that file.
-
We can strace syscalls and filter syscalls related to files - which I did couple times. I dont remeber any fd opened for that file.
Yeah, normally you work with gpio via kernel modules, was just saying that it's possible to work with the respective registers directly.
There's also /sys/class/gpio interface, which is probably the interface provided by the modules.
These are general considerations, I'm not speaking about this scope's system specifically.
-
Probably You missed my posts about chmod.
is this line ok?
# Get the Hardware version
#insmod /rigol/driver/hdcode_gpio.ko
#chmod 777 /dev/hdcode_gpio
printf '\xc' > /dev/hdcode_gpio
chmod 666 /dev/hdcode_gpio
because i tried...
# Get the Hardware version
#insmod /rigol/driver/hdcode_gpio.ko
#chmod 777 /dev/hdcode_gpio
printf '\x0F' > /dev/hdcode_gpio
chmod 666 /dev/hdcode_gpio
and push the edited start_rigol_app.sh and my scope reboot indefinitely, it just enter GUI for 2 seconds and reboot. congratulation to me and my VB hex knowledge, i'm reimaging the sd card... :-BROKE
-
and push the edited start_rigol_app.sh and my scope reboot indefinitely, it just enter GUI for 2 seconds and reboot. congratulation to me and my VB hex knowledge, i'm reimaging the sd card... :-BROKE
I already did mistake caused to boot loop caused by script. Just mount it on PC and edit this file. If You just want to start system without fixing, then add exit at beginning of script - exit will prevent further script execution. Same as removing execute permission(s) or changing its name.
Reboot can be caused by writing into device file which is read only.
Maybe somehow You had loaded hdcode_gpio.ko. So check Your script carefully.
-
Speaking of additional calibration options.. I hadn't noticed this before tonight. There is a "Detail" drop-down on the SelfCal window with some interesting calibration info. -if it passes-
(Attachment Link)
BTW: these are all the "additional calibration" options that I found to calibrate with success. Anything else added will fail.
(Attachment Link)
FYI: it took 7 hours to test all the permutations, because some would go 98 or 99% before stopping or crashing.
What's the ADC Clock adjustments in Debug? Is that only used when you have $50,000 calibration signal feeding the inputs?
Not 100% sure, but I had a theory(total WAG) about this last month here, below the pix (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5333045/#msg5333045). And now I almost wonder if it's for calibration since there aren't any trimmer/pots for cal like in a lot of Front End sections. But your guess is as good as any.
-
Maybe somehow You had loaded hdcode_gpio.ko. So check Your script carefully.
there is nowhere else hdcode_gpio.ko is scripted in the file. and i already commented the only one as i showed above..
Just mount it on PC and edit this file.
mount what? the sd card? as soon as i hook in with card reader, my windows asks to format it because its unreadable
If You just want to start system without fixing, then add exit at beginning of script - exit will prevent further script execution. Same as removing execute permission(s) or changing its name.
Reboot can be caused by writing into device file which is read only.
how easy! chmod 666 and the file is still read only? duh... ::)
-
there is nowhere else hdcode_gpio.ko is scripted in the file. and i already commented the only one as i showed above..
Maybe this module was already loaded. Did you check it with lsmod?
Edit: to unload module use this:
rmmod hdcode_gpio
Or:
modprobe -r hdcode_gpio
mount what? the sd card? as soon as i hook in with card reader, my windows asks to format it because its unreadable
Windows itself is capable of catching malware instead of doing what we need. Grab some GNU/Linux distribution instead. Personally I dont have Windows at all - for last ~15 years.
I can edit everything directly from SD card with standard GNU tools.
how easy! chmod 666 and the file is still read only? duh... ::)
Permissions are completely separate thing in Linux VFS (which can be directed to real FS if its capable). This module wasnt developed to create writeable file and to read data from it.
-
Personally I dont have Windows at all - for last ~15 years.
then you missed mixed reality experience and errr... telemetry ;D btw if nothing wrong with '\x0F' then the problem must be something else... since i posted, just to let you guys knows... start_rigol_app.sh also get updated from v1.14 to v1.2.2 since i spotted differences such as changes from "focaltech for guoxian" to "focaltech for gaozhan", so i guess for every FW update, we need to redo this script spoofing steps, even if its successful. cheers.
-
if nothing wrong with '\x0F'
App just reads first byte and nothing more. I even done \xFF which makes 255 in app.
Im almost sure you had loaded hdcode_gpio before printf (into existing /dev/hdcode_gpio) and that caused it.
To be safe, You can add rmmod just before printf. If rrmod will be called to unexisting module (not loaded) then it will scream (will print error message) and nothing else.
so i guess for every FW update, we need to redo this script spoofing steps, even if its successful. cheers.
In GNU/Linux You can use /etc/rc... to execute scripts (and to manage order of it) at different runlevels (https://en.wikipedia.org/wiki/Init). Im not very familiar with Android which uses Linux kernel, but beside of that, its a completely different system. As I told before, Google made Windows from a Linux.
-
I was looking for something else, but inside of libscope-auklet.so there is a function DevAcquireSPU_SetSinc so probably we can get rid of sin(x)/x interpolation.
There are many things which can be done by decompiling and changing it, but its time consuming. I wasnt coding in C too much in last couple years, so I managed to forget many things.
-
Is it possible to add a icon to the menu to call an app or failing that, add a link inside the help or even replace the help?
I would like to keep booting into the scope app but be able to call the "Electrical Calculations" ( https://play.google.com/store/apps/details?id=it.Ettore.calcolielettrici&hl=en&gl=US (https://play.google.com/store/apps/details?id=it.Ettore.calcolielettrici&hl=en&gl=US) ) app at will.
-
Is it possible to add a icon to the menu to call an app or failing that, add a link inside the help or even replace the help?
I would like to keep booting into the scope app but be able to call the "Electrical Calculations" ( https://play.google.com/store/apps/details?id=it.Ettore.calcolielettrici&hl=en&gl=US (https://play.google.com/store/apps/details?id=it.Ettore.calcolielettrici&hl=en&gl=US) ) app at will.
Thats why I started to developing Debian to work on this scope and get rid of Android. Currently X crashes from time to time and Rigol didnt send me kernel source code.
-
Mine had ~56/52 respectively at ~21-22 room ambient.
Scope cpu temp. for stock fan configurations only.
In Utility , in the self-check board test, what do your ambient and cpu temps say?
Some many posts back I mentioned I added thermal paste between the heatsink pads, trying to ascertain any benefits.
My scope has been on for about 1hr, it's doing no work (all channels are off) temps are
cpu_chip 52.7
cpu_amb 48.7
room amb is 23.5
Randy222: What were your temps prior to your paste mod?
FYI: Mine were 58.3/53 @25.6 Doing math, 4 ch active, post calibration(1 hour ea test)
I'm running in the 40's now tho'., same test conditions, slight HW mod. ;)
-
Is it possible to add a icon to the menu to call an app or failing that, add a link inside the help or even replace the help?
I would like to keep booting into the scope app but be able to call the "Electrical Calculations" ( https://play.google.com/store/apps/details?id=it.Ettore.calcolielettrici&hl=en&gl=US (https://play.google.com/store/apps/details?id=it.Ettore.calcolielettrici&hl=en&gl=US) ) app at will.
Welcome aboard!
You need to install a simple launcher and then a gesture app to do that. Key assignment, maybe. I think you can do all that via ADB.
FYI: You can get to the android "desktop" by hitting Win-N on your USB keyboard to do fun things with Android.
p.s., You'll probably need the APK's and install directly. Not sure you can install/run play store... Apparently you can. Here's some examples (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5174223/#msg5174223), including Electrodoc and some other Android stuff running on these from a few months ago.
-
Mine had ~56/52 respectively at ~21-22 room ambient.
Scope cpu temp. for stock fan configurations only.
In Utility , in the self-check board test, what do your ambient and cpu temps say?
Some many posts back I mentioned I added thermal paste between the heatsink pads, trying to ascertain any benefits.
My scope has been on for about 1hr, it's doing no work (all channels are off) temps are
cpu_chip 52.7
cpu_amb 48.7
room amb is 23.5
Randy222: What were your temps prior to your paste mod?
FYI: Mine were 58.3/53 @25.6 Doing math, 4 ch active, post calibration(1 hour ea test)
I'm running in the 40's now tho'., same test conditions, slight HW mod. ;)
I honestly don't know. I went in to look around for solder blobs, founds the dirty areas around the BNC solder pins, but when lifting heatsink that's when I noticed sink pads, which I don't like, but since the sink is cast and spans 7 chips, pads is the only way to do it. It's why I asked for others to check temps with 800 and oem fan.
My DHO sitting idle is at 52/48. The diffs always appear to be 4. Does your run a diff of 5? Sitting idle your DHO temps are below 50?
-
Maybe somehow You had loaded hdcode_gpio.ko. So check Your script carefully.
there is nowhere else hdcode_gpio.ko is scripted in the file. and i already commented the only one as i showed above..
Just mount it on PC and edit this file.
mount what? the sd card? as soon as i hook in with card reader, my windows asks to format it because its unreadable
If You just want to start system without fixing, then add exit at beginning of script - exit will prevent further script execution. Same as removing execute permission(s) or changing its name.
Reboot can be caused by writing into device file which is read only.
how easy! chmod 666 and the file is still read only? duh... ::)
It's always best to comment out the hdcode KLM in start script and reboot BEFORE creating the dev file. I have sent junk into the dev char device file with the KLM loaded, it did cause what seemed like a system crash, but I was able to power cycle and it came back.
As for mounting the sdcard, windows will be a bear. Ubuntu LTS live disk (iso to USB stick) is the way to go. Mounting the slices Android has in android_meta and android_expand is tricky, but not hard, use testdisk to find the start #, then mount with offest multiplier of 512. I posted it a few pages back, search the forum for "offset" or "testdisk" or "mount", that should narrow it down.
---> https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5387744/?topicseen#msg5387744 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5387744/?topicseen#msg5387744)
-
My DHO sitting idle is at 52/48. The diffs always appear to be 4. Does your run a diff of 5? Sitting idle your DHO temps are below 50?
diff can be higher with a larger fan, I think I saw a difference of 8 degrees.
-
My DHO sitting idle is at 52/48. The diffs always appear to be 4. Does your run a diff of 5? Sitting idle your DHO temps are below 50?
diff can be higher with a larger fan, I think I saw a difference of 8 degrees.
I was not even sure what "cpu_amb" was. Varies from device to device. cpu_chip is usually a diode or something inside the cpu. "amb" can be anything not in the chip. Isn't larger diff between the two mean cpu heat is not being sinked out to amb fast enough? cpu temp can be no lower than ambient temp, so isnt smaller diff better?
With an 8 diff, does that bring down cpu temp more? Cold amb is good, but most meaningful if the cpu temp also comes down due to the higer temo diff gradient.
-
My DHO sitting idle is at 52/48. The diffs always appear to be 4. Does your run a diff of 5? Sitting idle your DHO temps are below 50?
diff can be higher with a larger fan, I think I saw a difference of 8 degrees.
I was not even sure what "cpu_amb" was. Varies from device to device. cpu_chip is usually a diode or something inside the cpu. "amb" can be anything not in the chip. Isn't larger diff between the two mean cpu heat is not being sinked out to amb fast enough? cpu temp can be no lower than ambient temp, so isnt smaller diff better?
With an 8 diff, does that bring down cpu temp more? Cold amb is good, but most meaningful if the cpu temp also comes down due to the higer temo diff gradient.
I'm not sure yet where they're measuring that CPU_amb at, but it's obviously pretty close, due to the direct correlation in temps. And @shapirus, you nailed it with the larger fan comment.
I have some analytical data that I'll post regarding mods vs temps. Soon.
-
Isn't larger diff between the two mean cpu heat is not being sinked out to amb fast enough? cpu temp can be no lower than ambient temp, so isnt smaller diff better?
Given that it was with a larger fan (*and* a higher than a comfortable from the noise perspective air flow), I suppose it was because there was a higher air flow wherever the ambient sensor is located. May well be not even under the heat sink. I may be wrong though.
-
Do all 900 series oscilloscopes have hardware number 8?
-
Do all 900 series oscilloscopes have hardware number 8?
I can confirm 924S has (originally) HW number 8.
-
Do all 900 series oscilloscopes have hardware number 8?
Funny you ask this question, because I came back to ask about the HW #
Do the HW #'s found in 800-900 series uniquely identify a 800 or 900 model? As example, why not use #'s 1,2,3,4,5,6,7,8 to distinguish between 8 different models found across 800/900 series?
Next question I have is a bit more "sinister". Does the HW # actually mean anything in these DHO's, given their current code set? If you make it HW-12 on an actual 914, does that remove scope feature? If you make it HW-8 on an 802 does that provide more features?
An easy test is, for any oem model (non-mod'd), turn off the hdcode KLM in the start script (see recent previous posts) and reboot. The device will reboot with HW-0. Does that impact the scope features in any way? My unproven theory is that rigol perhaps wanted to use hardware config to place certain boundaries on the device, but never really implememted it (for whatever reasons). If HW # means nothing in terms of actual usable features, then the chatter around HW # is a bit moot.
I changed my HW # a few times, 0, 8, 12, 200, and they all seem to change nothing on my 804, at least nothing that I can see. As example, on any 800 if you set it to HW-8, does that give you any banwidth past 100MHz ? We also know that HW-8 does not fully distinguish between 900's. It perhaps seems HW # just ID's the number of channels, so I will test that theory on my 804 using the HW # for an 802.
-
Does the HW # actually mean anything in these DHO's, given their current code set? If you make it HW-12 on an actual 914, does that remove scope feature? If you make it HW-8 on an 802 does that provide more features?
I thought Mechatrommer had already confirmed that you need to change the HW ID from 12 to 8 in order to get digital triggers to work?
-
Speaking of additional calibration options.. I hadn't noticed this before tonight. There is a "Detail" drop-down on the SelfCal window with some interesting calibration info. -if it passes-
(Attachment Link)
BTW: these are all the "additional calibration" options that I found to calibrate with success. Anything else added will fail.
(Attachment Link)
FYI: it took 7 hours to test all the permutations, because some would go 98 or 99% before stopping or crashing.
The cal items seen after x3 About press, is a bit confusing. Are the ones selected by default the same items used when you just have the std Cal menu of "start"? Or is the std set something different? Is that in the manual?
Rigol should at least identify which ones selected are in the std set of cal tests. And why does selecting the other tests fail? If they are tests not applicable to the device then they should be grayed out. If they are applicable tests and they fail, why do they fail?
-
Does the HW # actually mean anything in these DHO's, given their current code set? If you make it HW-12 on an actual 914, does that remove scope feature? If you make it HW-8 on an 802 does that provide more features?
I thought Mechatrommer had already confirmed that you need to change the HW ID from 12 to 8 in order to get digital triggers to work?
That's it, just the one item? How does that work on an 800 model? Isn't that feature only for the digital analysis port found on the 900's ?
Are we talking about digi triiger selection D0-D15? If so then that's not applicable to 800's. However, I run my 804 as a 914 HW-12 and the digi panel then appears at bottom of screen.
900's have trigger type CAN and LIN, 800's do not. So 800 HW-8 turns on CAN and LIN ? I shall take a look.
800 datasheet shows they have some digi triggers, SPI and I2C are digital signals.
Edit: I just checked my 804 HW-12 running with 914 vendor bin and some lics, CAN and LIN are in my trigger menu.
Are we saying all the digi triggers don't actually work unless the device sees HW-8 ? Or just that CAN and LIN won't work unless there's a digi port installed?
-
I'll second that (firmware 00.01.02).
Do all 900 series oscilloscopes have hardware number 8?
I can confirm 924S has (originally) HW number 8.
-
Speaking of additional calibration options.. I hadn't noticed this before tonight. There is a "Detail" drop-down on the SelfCal window with some interesting calibration info. -if it passes-
(Attachment Link)
BTW: these are all the "additional calibration" options that I found to calibrate with success. Anything else added will fail.
(Attachment Link)
FYI: it took 7 hours to test all the permutations, because some would go 98 or 99% before stopping or crashing.
The cal items seen after x3 About press, is a bit confusing. Are the ones selected by default the same items used when you just have the std Cal menu of "start"? Or is the std set something different? Is that in the manual?
Rigol should at least identify which ones selected are in the std set of cal tests. And why does selecting the other tests fail? If they are tests not applicable to the device then they should be grayed out. If they are applicable tests and they fail, why do they fail?
Enabling "test model" by a taping/clicking 'about' three times is a "top secret" feature, not meant to be found by a customer.
(https://y.yarn.co/870f93ab-2c6c-46ed-a0a8-e0a8b9e699a3_text.gif)
-
I thought Mechatrommer had already confirmed that you need to change the HW ID from 12 to 8 in order to get digital triggers to work?
That's it, just the one item? How does that work on an 800 model? Isn't that feature only for the digital analysis port found on the 900's ?
That's the one function we know about. And yes, it requires that you solder the connector onto the PCB (footprint is ready), cut a slot into the plastic housing, and connect an external logic probe (original Rigol or clone).
I would assume that other hardware ID bits or values have a meaning as well. They could encode existing hardware options, options reserved for future expansion, or different hardware versions in case Rigol make design changes to the board, e.g. due to parts obsolescence. (Again, these could be already existing versions or -- more likely since the product is new -- versions reserved for the future.)
-
900's have trigger type CAN and LIN, 800's do not. So 800 HW-8 turns on CAN and LIN ? I shall take a look.
Seems unlikely. I assume that the hardware ID only encodes differences in the actual hardware on the PCB. More likely the vendor ID controls which software options are enabled.
-
900's have trigger type CAN and LIN, 800's do not. So 800 HW-8 turns on CAN and LIN ? I shall take a look.
Seems unlikely. I assume that the hardware ID only encodes differences in the actual hardware on the PCB. More likely the vendor ID controls which software options are enabled.
But 800's have I2C and SPI, it does not require the digi port for that.
Is CAN and LIN tied directly to the digi port and the scope can't use CAN or LIN trigger on BNC port?
Also, see my edit comment in my last post behind this one.
-
But 800's have I2C and SPI, it does not require the digi port for that.
Is CAN and LIN tied directly to the digi port and the scope can't use CAN or LIN trigger on BNC port?
Also, see my edit comment in my last post behind this one.
Bit of a mix-up there. The HW ID 8 is required to enable triggering from the digital input channels. This is unrelated to decoding serial protocols (or triggering based on decoded protocol signals) captured through the analog channels.
The latter decoder and trigger options do not require specific hardware options on the PCB, and hence are most likely not controlled by the hardware ID. The choice which ones to make available in which models was a pure marketing decision on Rigol's part: Need to reserve some goodies for the more expensive 900 models...
-
But 800's have I2C and SPI, it does not require the digi port for that.
Is CAN and LIN tied directly to the digi port and the scope can't use CAN or LIN trigger on BNC port?
Also, see my edit comment in my last post behind this one.
Bit of a mix-up there. The HW ID 8 is required to enable triggering from the digital input channels. This is unrelated to decoding serial protocols (or triggering based on decoded protocol signals) captured through the analog channels.
The latter decoder and trigger options do not require specific hardware options on the PCB, and hence are most likely not controlled by the hardware ID. The choice which ones to make available in which models was a pure marketing decision on Rigol's part: Need to reserve some goodies for the more expensive 900 models...
So, in summary, There are two HW #'s for 800's, 2ch and 4ch model. For 900's there's just HW-8, they are all 4ch w/ digi port. So, HW-8 only seems to indicate that the device has extra hardware (804 more than the 802, 900's are a opened 804 with digi port.)
So I perhaps conclude HW # is not really relevant unless one decides to add a digi port to an 800 model. I do not get any benefits running my 804 as HW-8. The extra CAN and LIN appears to come from running the 914 vendor.bin
HW-8 --> 4ch with digi port (with AFG?)
HW-12 --> 4ch with no digi port
HW-xx --> 2ch with front side EXT trigger and no digi port (I forget the HW # for the 2ch devices, and I am not sure front EXT is hardware or not).
All the 900's are HW-8 ? Does that mean they all have AFG but only S models have it activated? Isn't AFG more hardware, or is that done via FPGA or something?
-
So I perhaps conclude HW # is not really relevant unless one decides to add a digi port to an 800 model. I do not get any benefits running my 804 as HW-8. The extra CAN and LIN appears to come from running the 914 vendor.bin
That's sounds right, at least as far as we know now. Maybe at some point we will figure out what magic is worked by the additional RAM in the DHO900...
But in any case, it seems very likely that changing the hardware ID only makes sense (today and in the future) if you also change the actual hardware. As long as your original DHO8xx PCB remains unchanged, there will probably be no benefit -- and possibly some detrimental side effects -- from changing the hardware ID.
-
Three photos of underside of CPU in original & unmodified DHO924S. If somebody wants more photos of something particular - better tell me now.
:-BROKE
-
I measured resistors around CPU and noted it. Later I will do image of what is what. Values was 10k, 5k, 4.7k, 22, 1.
-
Three photos of underside of CPU in original & unmodified DHO924S. If somebody wants more photos of something particular - better tell me now.
:-BROKE
Could you take a photo of the side of the input tract?(Its analog part)If possible, on both sides of the board. Thank you!
-
Is the Sa/s rate bound to the ADC? If so can the ADC actually do better than 1.25 Sa/s ?
I notice via logcat that RIGOL.SCOPE : [drv_scope.cpp] [ConfigAquire] [2619] gets sample rate as ":WavSa :SampleRate".
Maybe hackable via software?
-
So, in summary, There are two HW #'s for 800's, 2ch and 4ch model. For 900's there's just HW-8, they are all 4ch w/ digi port. So, HW-8 only seems to indicate that the device has extra hardware (804 more than the 802, 900's are a opened 804 with digi port.)
So I perhaps conclude HW # is not really relevant unless one decides to add a digi port to an 800 model. I do not get any benefits running my 804 as HW-8. The extra CAN and LIN appears to come from running the 914 vendor.bin
HW-8 --> 4ch with digi port (with AFG?)
HW-12 --> 4ch with no digi port
HW-xx --> 2ch with front side EXT trigger and no digi port (I forget the HW # for the 2ch devices, and I am not sure front EXT is hardware or not).
All the 900's are HW-8 ? Does that mean they all have AFG but only S models have it activated? Isn't AFG more hardware, or is that done via FPGA or something?
Good summation. To Add:
802 has the same AFE chip as a 804, but the AFE is missing on CH3, and there are a couple "settings" resistors on the top side, near the Ch4 AFE to further differentiate between 802 and any other model.
AFG is more hardware, in the form of some opAmps and power supplies for trigger levels and to power the AFG and LA pods on the main PCBA. The AFG (digital) data is generated in real-time by the FPGA, then passed to the DAC daughter PCB -typically-only found on S models.
@Mech had to set the HW number because he was experiencing some triggering issues. It might still be worth looking into a software based bypass, but it seems to me there are other things that could be worked on
-
Is the Sa/s rate bound to the ADC? If so can the ADC actually do better than 1.25 Sa/s ?
I notice via logcat that RIGOL.SCOPE : [drv_scope.cpp] [ConfigAquire] [2619] gets sample rate as ":WavSa :SampleRate".
Maybe hackable via software?
It's been in this thread (and a couple of others) more than once. Last time was yesterday, I believe. Do you actually follow this thread, or do you only read the answers to your specific questions? ???
The ADC could quite possibly do 2 GSa/s, since it is apparently the same as in the DHO1000 and 4000. However, the FPGA is probably the bottleneck. TurboTom has posted datasheet evidence which makes it plausible that 1.25 GSa/s is its limit.
-
Three photos of underside of CPU in original & unmodified DHO924S. If somebody wants more photos of something particular - better tell me now.
:-BROKE
Could you take a photo of the side of the input tract?(Its analog part)
Input stages? I already did. First things first. Now Im removing LC filter from channel 4 and adding missing capacitors around dc-dc converters - some of them wasnt populated (one instead of two parallel).
-
Three photos of underside of CPU in original & unmodified DHO924S. If somebody wants more photos of something particular - better tell me now.
:-BROKE
Could you take a photo of the side of the input tract?(Its analog part)
Input stages? I already did. First things first. Now Im removing LC filter from channel 4 and adding missing capacitors around dc-dc converters - some of them wasnt populated (one instead of two parallel).
Ścieżka wejścia analogowego
-
Shaky hands and naked eye.
Edit: In this photo I didnt removed this capacitor before LC filters which was a quite big mistake. It should be also removed, to match transmission line impedance.
-
So, in summary, There are two HW #'s for 800's, 2ch and 4ch model.
the HW version for all series have been laid out by souldevelop, how he came to the conclusion we dont know, probably from his software rev engineering skill, now he is missing so he cant answer, but from evidences posted in forums, his conclusion is so far correct... except S2084 discovered new HW version extension from resistor mod such as HW4,5,13.. what are they? who cares?
I do not get any benefits running my 804 as HW-8. The extra CAN and LIN appears to come from running the 914 vendor.bin
nobody forces you to change to HW8 if vendor.bin hack provides you with everything you need. some even dont want to upgrade to 900 because they hate the digital and afg tab under the GUI. and for companies they dont even want to touch any of rigol_hack with 10" barge pole due to warranty reason. should i sorry for them? heck no because i understand what i need is probably what they hate. free choice for their own benefit and interest and how much risk they want to take.
All the 900's are HW-8 ? Does that mean they all have AFG but only S models have it activated? Isn't AFG more hardware, or is that done via FPGA or something?
AFG is commanded by FPGA and vendor.bin hack to 900 alone will activate it even on HW12, so far no differences that i can spot. bode plot was working fine in HW12. btw checking start_rigol_app.sh i spotted there is another afg_gpio.ko module is loaded if anyone interested, so far i am not interested in wasting time on it since every AFG functionalities that i expect to work, work as expected either on HW12 or 8. the point we looked for HW8 is because we want the 16CH digital channels can be used as trigger source correctly. this has some applications, but if you dont need it, thats fine for you.
point is, we only report and share how to get the hack done in case readers came to find for the solution, same thing other people reported possible but nonsensical HW number or possibility to burn FPGA pins by switching fpga binary alone, a risk that we wont do nor try. no enforcement whatsoever this is not blind religion. if you dont need it, then dont do it. just as some people are not comfortable enough to edit start_rigol_app.sh and cause the dso to hanged, lucky if they made image backup, if not, they can be danggling in the Windows11 air, ymmv.
attached is CAN and LIN trigger support, but i never find a use for them since the beginning until today and probably many years to come, so i dont care if CAN or LIN work or not in HW12 or HW8... if someone comes up with trigger XXX hack, why would i need to do it if i dont use it?
-
Three photos of underside of CPU in original & unmodified DHO924S. If somebody wants more photos of something particular - better tell me now.
if this images came earlier, we will not have try and error. but maybe for good, AndyBig will not provide us with circuit schematics. now we know how to make more combination to make HW12 or 8 (your showing 1101 as i discovered earlier)
Shaky hands and naked eye.
thats the adc input path... analog input is just down below... 4 of them ;) now you are so bold to solder CH4 path in such a way ;D
-
Shaky hands and naked eye.
thats the adc input path... analog input is just down below... 4 of them ;)
No... That was aftermath of my first modification.
-
No... That was aftermath of my first modification.
anyway you are doing mod that i cannot imagine i would go.. ;D
That was three stage low pass filter. Now this is a one stage only.
BTW. I have much bigger coils than those four I removed. Size about 1/3 of this scope and rated to 35 A.
-
No... That was aftermath of my first modification.
anyway you are doing mod that i cannot imagine i would go.. ;D
That was three stage low pass filter. Now this is a one stage only.
that is somehow if i'm correct to control signal integrity in differential signal into ADC, not anything to do with dso analog input respond. you probably change the phase or time delay too.. should you be more clearer you are planning to make it 2 or 5 GSps?
-
No... That was aftermath of my first modification.
anyway you are doing mod that i cannot imagine i would go.. ;D
That was three stage low pass filter. Now this is a one stage only.
that is somehow if i'm correct to control signal integrity in differential signal into ADC, not anything to do with dso analog input respond. you probably change the phase or time delay too.. should you be more clearer you are planning to make it 2 or 5 GSps?
More like a filters to lower bandwidth, to force You to buy more expensive scope. This puppy is very small, lightweight and very good to transport it. DHO4000 not so much.
Anyway, resistors before adc (measured in circuit) are 85 ohms - for each channel.
-
More like a filters to lower bandwidth, to force You to buy more expensive scope. This puppy is very small, lightweight and very good to transport it. DHO4000 not so much.
i hope you success with your SW/FW mod without burning anything. it will be more fun to have 4GSps at $400
Anyway, resistors before adc (measured in circuit) are 85 ohms - for each channel.
impedance matching to avoid reflection?
-
There was already a description of increasing the analog bandwidth to 400 MHz by replacing inductors.
-
More like a filters to lower bandwidth, to force You to buy more expensive scope. This puppy is very small, lightweight and very good to transport it. DHO4000 not so much.
i hope you success with your SW/FW mod without burning anything. it will be more fun to have 4GSps at $400
Anyway, resistors before adc (measured in circuit) are 85 ohms - for each channel.
impedance matching to avoid reflection?
For 100%. But I was expecting 50 ohms.
There was already a description of increasing the analog bandwidth to 400 MHz by replacing inductors.
I know. I did "replacing" as You can see.
-
Speaking of additional calibration options.. I hadn't noticed this before tonight. There is a "Detail" drop-down on the SelfCal window with some interesting calibration info. -if it passes-
(Attachment Link)
BTW: these are all the "additional calibration" options that I found to calibrate with success. Anything else added will fail.
(Attachment Link)
FYI: it took 7 hours to test all the permutations, because some would go 98 or 99% before stopping or crashing.
The cal items seen after x3 About press, is a bit confusing. Are the ones selected by default the same items used when you just have the std Cal menu of "start"? Or is the std set something different? Is that in the manual?
Rigol should at least identify which ones selected are in the std set of cal tests. And why does selecting the other tests fail? If they are tests not applicable to the device then they should be grayed out. If they are applicable tests and they fail, why do they fail?
From my photo; The bottom row of SelfCal items are not selected in a factory stock configuration(at least with my 804), and I doubt there's any reason to believe there's any differences related to SelfCal between authentic 800 and 900's, since they use the same software package.
Through many hours of calibration testing, I was able to figure out you could also do each of the items in the bottom row without premature exit failure.
I captured the default 1, 2, 3 SelfCal screen before I did this testing.
[attachimg=1 width=400]
Why do some items fail SelfCal? Might be able to capture that info in the log file. and, FWIW as I mentioned the "interesting details" triangle has a log as it's calibrating, as I showed in that pic. Maybe it's there. Or via Serial terminal... or k(d)mesg.last, or logcat, etc... (you're the Android expert, not me!) ;)
-
There was already a description of increasing the analog bandwidth to 400 MHz by replacing inductors.
where?
-
AFG is commanded by FPGA and vendor.bin hack to 900 alone will activate it even on HW12, so far no differences that i can spot. bode plot was working fine in HW12. btw checking start_rigol_app.sh i spotted there is another afg_gpio.ko module is loaded if anyone interested, so far i am not interested in wasting time on it since every AFG functionalities that i expect to work, work as expected either on HW12 or 8. the point we looked for HW8 is because we want the 16CH digital channels can be used as trigger source correctly. this has some applications, but if you dont need it, thats fine for you.
The afg KLM uses 5 pins in gpio3, gpio 122,123,124,125,126, using odd name "afg_in1" , odd in that uses the word "in" but the pin is an out pin, and on my 804 are set 10101
-
From the DHO800 Datasheet.
[attachimg=1 Width=400]
--This looks nothing like 50\$\Omega\$ to me.
[attachimg=2 Width=240]
Pretty sure we would need an extra relay and some resistors, and some software to turn 50 ohms on/off, like in the DHO1000.
FYI: This info is for Norbert
-
AFG is commanded by FPGA and vendor.bin hack to 900 alone will activate it even on HW12, so far no differences that i can spot. bode plot was working fine in HW12. btw checking start_rigol_app.sh i spotted there is another afg_gpio.ko module is loaded if anyone interested, so far i am not interested in wasting time on it since every AFG functionalities that i expect to work, work as expected either on HW12 or 8. the point we looked for HW8 is because we want the 16CH digital channels can be used as trigger source correctly. this has some applications, but if you dont need it, thats fine for you.
The afg KLM uses 5 pins in gpio3, gpio 122,123,124,125,126, using odd name "afg_in1" , odd in that uses the word "in" but the pin is an out pin, and on my 804 are set 10101
you gave me some idea, because i have 3 unknown pins on AFG interface, 1 is output i think and the other 2 pins probably input. if there is way knowing what RK3399 pins refered as 122-126... maybe i need to look into afg_gpio.ko more closely. thanks.
-
...... odd in that uses the word "in" but the pin is an out pin, and on my 804 are set 10101
But there is no AFG in a 804. Why would they care if the AFG pins were set on a non-900S model? Or am I missing something?
-
There was already a description of increasing the analog bandwidth to 400 MHz by replacing inductors.
where?
Long time ago in this topic or in teardown&bugs topic. Same input stages and ADC are in DHO1000 and DH4000. This second one has nominal bandwith of 800 MHz.
Anyway, 50 ohm switch is in app, but is hidden. Its shown when You put vendor.bin generated for DHO4000. Its a matter of decompile, change and compile it back. After that add transistor, resistor, diode, relay and resistor... I was just going just to add 4 parallel 0.25W 200 ohm resitors into channel 4 after adding buch of capacitors into empty missing pads and couple other places...
-
There was already a description of increasing the analog bandwidth to 400 MHz by replacing inductors.
where?
I will probably regret this., but here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5340722/#msg5340722) is the link to the 400+ Mhz post... From Feb 17th.
Oh, and @Mechatrommer, you even commented a few links later. ;)
-
Long time ago in this topic or in teardown&bugs topic. Same input stages and ADC are in DHO1000 and DH4000. This second one has nominal bandwith of 800 MHz.
I am not trying to speak for everyone here., but it seems to me like you bought the wrong Oscilloscope.(being a 924S) Perhaps you should sell it and buy a DHO1000 and hack the snot out of that one? Much more capable platform.
Just Sayin'.
-
AFG is commanded by FPGA and vendor.bin hack to 900 alone will activate it even on HW12, so far no differences that i can spot. bode plot was working fine in HW12. btw checking start_rigol_app.sh i spotted there is another afg_gpio.ko module is loaded if anyone interested, so far i am not interested in wasting time on it since every AFG functionalities that i expect to work, work as expected either on HW12 or 8. the point we looked for HW8 is because we want the 16CH digital channels can be used as trigger source correctly. this has some applications, but if you dont need it, thats fine for you.
The afg KLM uses 5 pins in gpio3, gpio 122,123,124,125,126, using odd name "afg_in1" , odd in that uses the word "in" but the pin is an out pin, and on my 804 are set 10101
you gave me some idea, because i have 3 unknown pins on AFG interface, 1 is output i think and the other 2 pins probably input. if there is way knowing what RK3399 pins refered as 122-126... maybe i need to look into afg_gpio.ko more closely. thanks.
When You decompile kernel module from this scope, look also into same module from DHO1000/DHO4000 (same updates for both and modules are there). Some are different and some are the same. This second one has more k. modules.
-
From my photo; The bottom row of SelfCal items are not selected in a factory stock configuration(at least with my 804), and I doubt there's any reason to believe there's any differences related to SelfCal between authentic 800 and 900's, since they use the same software package.
Before trying "AFE Zero", do back up your current cal files. It is known to screw up calibration, and it's not clear if there's any way to restoring from that bad state other than pushing the good cal files back to the scope.
I've had this issue.
-
From my photo; The bottom row of SelfCal items are not selected in a factory stock configuration(at least with my 804), and I doubt there's any reason to believe there's any differences related to SelfCal between authentic 800 and 900's, since they use the same software package.
Before trying "AFE Zero", do back up your current cal files. It is known to screw up calibration, and it's not clear if there's any way to restoring from that bad state other than pushing the good cal files back to the scope.
I've had this issue.
Good point, for anyone following along. Thanks!
BTW: I wasn't advocating performing SelfCal on those additional items. I decided to "try" them to see which ones crashed or not.
-
There was already a description of increasing the analog bandwidth to 400 MHz by replacing inductors.
where?
I will probably regret this., but here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5340722/#msg5340722) is the link to the 400+ Mhz post... From Feb 17th.
Oh, and @Mechatrommer, you even commented a few links later. ;)
i cant read nor see pictures in that forum. I was commenting in general idea without looking specifically. Just watched back dave video, he said front end could be 800MHz, but this need verification. I probably misunderstood rt4612iq afe (i thought adc) and if is differential signal analog?
-
...... odd in that uses the word "in" but the pin is an out pin, and on my 804 are set 10101
But there is no AFG in a 804. Why would they care if the AFG pins were set on a non-900S model? Or am I missing something?
i guess because they code once compatible for all. design once for both 800 and 900. Dave talked about reducing NRE? about man power cost.
-
Anyway, 50 ohm switch is in app, but is hidden. Its shown when You put vendor.bin generated for DHO4000. Its a matter of decompile, change and compile it back. After that add transistor, resistor, diode, relay and resistor... I was just going just to add 4 parallel 0.25W 200 ohm resitors into channel 4 after adding buch of capacitors into empty missing pads and couple other places...
you typed about heating pcb and resistor risk. Now you want to do more heavy metal to make your scope spaggetti mess :palm: whats wrong with $1 external inline 50 ohm teminator? spend a little bit more if u want quality.
-
...... odd in that uses the word "in" but the pin is an out pin, and on my 804 are set 10101
But there is no AFG in a 804. Why would they care if the AFG pins were set on a non-900S model? Or am I missing something?
i guess because they code once compatible for all. design once for both 800 and 900. Dave talked about reducing NRE? about man power cost.
Yes yes. I think you misunderstood my Q. which is intended as a statement to Randy's question. He was asking about the "direction bits" register(pertaining to ARB) being set to in or out.
-
i cant read nor see pictures in that forum. I was commenting in general idea without looking specifically. Just watched back dave video, he said front end could be 800MHz, but this need verification. I probably misunderstood rt4612iq afe (i thought adc) and if is differential signal analog?
Yes, a differential signal goes from rt1642 to the ADC. And from the ADC to the FPGA it is also differential, but digital.
-
Anyway, 50 ohm switch is in app, but is hidden. Its shown when You put vendor.bin generated for DHO4000. Its a matter of decompile, change and compile it back. After that add transistor, resistor, diode, relay and resistor... I was just going just to add 4 parallel 0.25W 200 ohm resitors into channel 4 after adding buch of capacitors into empty missing pads and couple other places...
you typed about heating pcb and resistor risk. Now you want to do more heavy metal to make your scope spaggetti mess :palm: whats wrong with $1 external inline 50 ohm teminator? spend a little bit more if u want quality.
Everything has upsides and downsides. "$1 external inline 50 ohm" is not a best option for higher frequencies and fast rising times and that creates additional staff around which creates troubles and its more time consuming. Whats wrong with having three 1 MΩ channels and one 50 Ω ? For me personally this is a best option.
-
Anyway, 50 ohm switch is in app, but is hidden. Its shown when You put vendor.bin generated for DHO4000. Its a matter of decompile, change and compile it back. After that add transistor, resistor, diode, relay and resistor... I was just going just to add 4 parallel 0.25W 200 ohm resitors into channel 4 after adding buch of capacitors into empty missing pads and couple other places...
Fearless but clueless...
Once you hack your frontend like that, the good thing is that you don't need to pay attention whether you switch in the 50 Ohm termination or not. Signal quality will be a mess either way. ::)
-
Everything has upsides and downsides. "$1 external inline 50 ohm" is not a best option for higher frequencies and fast rising times and that creates additional staff around which creates troubles and its more time consuming. Whats wrong with having three 1 MΩ channels and one 50 Ω ? For me personally this is a best option.
of course you have every right to do whatever setup to your toys. i'm just giving advice, i find it confusing if only solder 50 ohm relay to CH4, i may understand you want to reserve CH4 for special purpose, but if i have to go this route i will solder all channels. but then i only use $1 inline terminator even with leo bodnar pulse. no need to mess with front end just to get built in 50 ohm. to get increased BW 400-500MHz maybe sensible, but 800MHz BW maybe not because nyquist is 1.6-2GSps, way more even using single CH, unless if you can hack/boost the sample rate.
my first attempt if i really need RF > 250MHz, i will profile dso BW respond curve and compensate using manual calculator or my PC SW. for example if you know 400MHz is -2dB down, then you can calculate manually to add visible signal on screen with 2dB, more advance is using inverse FFT to compensate all spectrums and replot the signal on PC SW. i have suspicion that more advance GHz dsos do this kind of SW trick to get flat respond... ymmv.
-
AFG is commanded by FPGA and vendor.bin hack to 900 alone will activate it even on HW12, so far no differences that i can spot. bode plot was working fine in HW12. btw checking start_rigol_app.sh i spotted there is another afg_gpio.ko module is loaded if anyone interested, so far i am not interested in wasting time on it since every AFG functionalities that i expect to work, work as expected either on HW12 or 8. the point we looked for HW8 is because we want the 16CH digital channels can be used as trigger source correctly. this has some applications, but if you dont need it, thats fine for you.
The afg KLM uses 5 pins in gpio3, gpio 122,123,124,125,126, using odd name "afg_in1" , odd in that uses the word "in" but the pin is an out pin, and on my 804 are set 10101
you gave me some idea, because i have 3 unknown pins on AFG interface, 1 is output i think and the other 2 pins probably input. if there is way knowing what RK3399 pins refered as 122-126... maybe i need to look into afg_gpio.ko more closely. thanks.
1) using just shell cli I have full control over any pin that is configured as gpio, as long as there's no KLM using these pins. Caveat is, not sure what good direct control over a pin is, software still needs to read the pin states.
2) RK pins are mapped into 1 of 4 functions, not all pins have 4 defined functions, see the RK datasheet
3) in gpio, the RK has 5x(4x8) mapping, 5 groups of 32 pins, each group divided into 4 banks A B C D, each bank has pin labels 0-7
4) logically the groups are gpio0 gpio1 gpio2 gpio3 gpio4
5) there's no just counting pins, they are "gpio" numbered, and they start at "0" and end on "159", "gpio0_A0" is not to be referred to as "pin #1", its "gpio pin #0, the very 1st pin in gpio". The very last pin in gpio, the 160th pin under gpio, is "gpio pin #159".
122-126 are in gpio3
122 gpio3_D2
123 gpio3_D3
124 gpio3_D4
125 gpio3_D5
126 gpio3_D6
Use this RK datasheet XY matrix to find physical pin location of the "gpio" names.
https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf
Verify this datasheet matches the actual RK chip used in your DHO. My gpio mappings are correct, but if wrong datasheet they could be physically mapped in a different matrix (there are several versions/flavors of RK3399).
You also mention that some of those pins may be 'in' and 'out' pins, but IIRC I noted them as all 'out' pins on my 804, and I have no idea if perhaps they are configured in some way being related to HW #.
-
If anyone is interested, I have attached two files. These are boot logs read from the UART connectors of the processor and FPGA.
-
Verify this datasheet matches the actual RK chip used in your DHO. My gpio mappings are correct, but if wrong datasheet they could be physically mapped in a different matrix (there are several versions/flavors of RK3399).
Question: How many "versions/flavors" of the RK3399 chip have you discovered?
And do you have any info that Rigol used different versions in the DHO's?
Links please?
-
If anyone is interested, I have attached two files. These are boot logs read from the UART connectors of the processor and FPGA.
Thanks for posting these. Have you diff'd these to the original logs Dave posted that he took during the teardown video? Has much changed? I'll check in "the morning" when I get up. ;)
-
If anyone is interested, I have attached two files. These are boot logs read from the UART connectors of the processor and FPGA.
Thanks for posting these. Have you diff'd these to the original logs Dave posted that he took during the teardown video? Has much changed? I'll check in "the morning" when I get up. ;)
No, I didn't compare. I didn't even look closely at what I recorded from my oscilloscope :)
-
Three photos of underside of CPU in original & unmodified DHO924S. If somebody wants more photos of something particular - better tell me now.
:-BROKE
Could you take a photo of the side of the input tract?(Its analog part)
Input stages? I already did. First things first. Now Im removing LC filter from channel 4 and adding missing capacitors around dc-dc converters - some of them wasnt populated (one instead of two parallel).
Ścieżka wejścia analogowego
More like: stopień wejścia analogowego. Word ścieżka means path.
[attach=1]
[attach=2]
[attach=3]
BW 400-500MHz maybe sensible, but 800MHz BW maybe not because nyquist is 1.6-2GSps, way more even using single CH, unless if you can hack/boost the sample rate.
my first attempt if i really need RF > 250MHz, i will profile dso BW respond curve and compensate using manual calculator or my PC SW. for example if you know 400MHz is -2dB down, then you can calculate manually to add visible signal on screen with 2dB, more advance is using inverse FFT to compensate all spectrums and replot the signal on PC SW. i have suspicion that more advance GHz dsos do this kind of SW trick to get flat respond... ymmv.
Even with this sample rate it will still work. 800 MHz bandwidth makes possible to test signals up to ~80 MHz. 80 MHz square wave with 250 MHz bandwidth will be more like sinus and You lose precious data. Only one problem will be with spikes directly between two samples.
Speaking of bandwidth, I did one simple and stupid mistake...
[attach=4]
:-BROKE
Next time I should think more before doing simple job like that. Those two filters makes higher impedance at higher frequencies. so they added this capacitor. When I leaved it (with removed LC filters after it), impedance went down and signal was distorted. Same problem will be with mentioned 400 MHz "hack", when You leave it or remove it.
First LC filter is around 280-300 MHz (they made higher bandwidth than specified because of elements tolerance and eventual complaints because somebody didnt calculate total system bandwidth when using passive probes). Second one is probably around 800 MHz to filter out high frequency noise. Speaking of noise, after correcting my mistake (removing this capacitor) noise went from 74 uV RMS (originally) up to ~145 uV. After some time it went up to 300-350 uV making it less usable. I have suspicious about used thermopads was splashed and it added capacitance like it was with mentioned capacitor (same noise level - probably caused by capacitive load of opamp). Later I will check this.
I used 1mm thick thermopads. After that it was little pressure into thermopad on FPGA and on CPU (rk3399) heatsink was touching about half of it - measured temp. was increased by ~10° beside most expensive thermopads (6 W/m⋅K) from a local shop. Those on input stages was splashed like a cake...
So I measured height difference between those spacers (is that correct english name of it?) with a caliper. At input stages those are longer by 1 mm. So I think input stages should have 0.5 mm and everything else should have 1.5 mm. Workaround is to use 1 mm and 2 mm, but with less size due to splashing it around and possibly creating capacitance...
That is probably the worst aluminium heatsink I ever seen. Thermal conductivity is comparable to a cheap plastic. I think there is a way to hack this problem. Cut it to leave part around input stages and ADC, and cut other and better one to put it into everything else - maybe after that, fan wont be needed or one small at very low speed. Of course this heatsink is also a shield, so maybe it should be cut up to ADC and maybe little bit more.
Power dissipation for RK3399 is 6.05 W. I dont know how much is for FPGA (provided spreadshit doesnt work with LibreOffice correctly) but I assume we need similar size of heatsink due to higher total thermal resistance.
I need to divide next photos into another post because of total size limits and better readability. If somebody wants more photos, I already have much more.
-
I added some capacitors. In some cases, this scope was pretty sensitive to a ripples from PSU (probably common mode) - I didnt figured out when it is and when not. Photo from unplaced caps:
[attach=1]
On left-bottom side this is a parallel to this one on the left and it creates LC filter just after USB-C socket. So I added three caps (two SMD ceramic 330 nF and one film 1uF THT - yellow one). Above that, there are couple LC filters and I just added one 330 nF to a missing spot.
[attach=2]
On other side I added one more 1 uF to mentioned LC filter after USB-C:
[attach=3]
I know that looks very ugly and unprofessional, but who cares when it does the job?
Measured noise with disconnected inputs (ch. 1-3) was lower just by 2%... I didnt measure sensitivity to common mode yet. Long time ago I was going to make linear power supply because of common mode noise from a switching PSU - but I didnt done it yet...
After around 1-2 hr I will post resistors values around CPU in photo.
-
What a lucky coincidence that these are 4-channel scopes. Now you can hack the input stages to all possible combinations of regular and high bandwidth, 1 MOhm and 50 Ohm termination. ::)
Better add a sticker to the front panel to remember which channel does what...
-
What a lucky coincidence that these are 4-channel scopes. Now you can hack the input stages to all possible combinations of regular and high bandwidth, 1 MOhm and 50 Ohm termination. ::)
Better add a sticker to the front panel to remember which channel does what...
One channel with higher bandwidth and 50Ω termination is good enough for me - it will be for special purposes when 250 MHz is not enough. 1-3 channels are unmodified - I just cleaned flux residues because of unnecessary higher capacitance (difference on same signal on those channels is very subtle after this - almost no change).
-
This is what scares me about buying used test equipment. I sincerely hope if Norbert ever sells his scope that fully discloses all of these... adjustments he's made.
-
Even with this sample rate it will still work. 800 MHz bandwidth makes possible to test signals up to ~80 MHz. 80 MHz square wave with 250 MHz bandwidth will be more like sinus and You lose precious data.
if you want to diagnose signal integrity (rise/down time detailed shape) at 80MHz square wave, DHO800/900 is not the tool, period. unless you can modify it to like 10GSps or more. you need at least say 10 points on each rise/fall time. you havent proved that it can even do 2-4GSps, or maybe you did? you just dont want to tell us? either way, you keep posting inconclusively..
Only one problem will be with spikes directly between two samples.
we all know this consequence when you try to make a machine violates nyquist limit... i wonder if you really know the reason behind the theorem? because if you do, i think you wont do what you tried to do with the front end..
Speaking of bandwidth, I did one simple and stupid mistake...
i hope destroying/overloading the centaurus adc input is not one of it. with your lack of evidence and inconclusive post, i hope nobody will follow your step blindly... ymmv.
-
This is what scares me about buying used test equipment. I sincerely hope if Norbert ever sells his scope that fully discloses all of these... adjustments he's made.
We are indeed in a hacking thread so what did You expect? Of course selling anything is a matter of being honest. Are you suggesting something?
Why You didnt tell same thing when half of people in here was playing around with resistor around CPU?
Even with this sample rate it will still work. 800 MHz bandwidth makes possible to test signals up to ~80 MHz. 80 MHz square wave with 250 MHz bandwidth will be more like sinus and You lose precious data.
if you want to diagnose signal integrity (rise/down time detailed shape) at 80MHz square wave, DHO800/900 is not the tool, period. unless you can modify it to like 10GSps or more. you need at least say 10 points on each rise/fall time. you havent proved that it can even do 2-4GSps, or maybe you did? you just dont want to tell us? either way, you keep posting inconclusively..
Only one problem will be with spikes directly between two samples.
we all know this consequence when you try to make a machine violates nyquist limit... i wonder if you really know the reason behind the theorem? because if you do, i think you wont do what you tried to do with the front end..
I don't want to be rude, but probably You dont know too much about analog filters. With same sample rate, changing bandwith via filter changes shape which in some cases can be very significant and change Your decisions. Spikes between samples will be also visible (I still have filtering but on much higher frequency), but it ADC will it see earlier and in less samples. I never told anything about measuring 800 MHz signals. With 80 MHz I still have ~15 samples per period but its less distorted.
Changing coils instead of removing it, makes necessary to add another capacitor to maintain same transmission line termination.
Speaking of bandwidth, I did one simple and stupid mistake...
i hope destroying/overloading the centaurus adc input is not one of it. with your lack of evidence and inconclusive post, i hope nobody will follow your step blindly... ymmv.
ADC wasnt overloaded. More like opamp from input stage IC, but this is not enough to destroy output transistors in it.
-
norbert.kiszka Did I understand correctly that no practical benefit was achieved as a result of all these horrors?
-
This is what scares me about buying used test equipment. I sincerely hope if Norbert ever sells his scope that fully discloses all of these... adjustments he's made.
Sounds like one of those ebay specials in the making: "Powers on. I can't test it any further since I don't know what to look for." ::)
-
ADC wasnt overloaded. More like opamp from input stage IC, but this is not enough to destroy output transistors in it.
Be careful anyway. The ADC is obviously a custom Rigol part. But if I remember correctly, even the pre-amplifier -- while a TI part -- has a part number which people have not been able to find on the TI site or through distributors, hence may be a custom variant for Rigol.
-
norbert.kiszka Did I understand correctly that no practical benefit was achieved as a result of all these horrors?
Its opposite. I can use CH4 at a single channel mode to have higher bandwidth when needed. 250 MHz is calculated for 3-4 channels (312.5 M samples per second) and for people (beginners) complaining about small time offset between channels (because samples are not in the same time). Also this is made to force consumers to buy more expensive (and bigger...) scope. This puppy almost fits into my pocket, making it more useful.
Added capacitors (see photos) makes it work more stable and less vulnerable to ripples from a external PSU - I already had issues with it as I told before. As we all see, whole thing was designed to save every penny at production line. Thats why we have aluminium made from plastic (paraphrase of friend words) and almost everything else made very poorly.
If somebody wants to leave all hardware as it is, then its his/her choice.
Speaking of hacking and things like that. Long time ago I had PC running 233 (or 266?) MHz Celeron overclocked to 600 MHz without single fan inside PC - not even in PSU. But now nominal clocks are much closer to hardware limits - so ~30% is the max what we can overclock those days.
ADC wasnt overloaded. More like opamp from input stage IC, but this is not enough to destroy output transistors in it.
Be careful anyway. The ADC is obviously a custom Rigol part. But if I remember correctly, even the pre-amplifier -- while a TI part -- has a part number which people have not been able to find on the TI site or through distributors, hence may be a custom variant for Rigol.
I didnt notice that is from TI (some logo somwhere?). IMHO TI makes much better jelly bean parts than other manufacturers.
-
I almost forget about photos of input stages from opposite side. Also photo around FPGA.
-
norbert.kiszka Did I understand correctly that no practical benefit was achieved as a result of all these horrors?
as i said tuning to 400-500MHz is probably sensible. but the way he is shorting the filter inductor is like opening up infinite BW at ADC input to me, at least we have a sound filter simulation presented that cutoff nyquist sampling limit, ie at 500-625MHz, slightest presence of anything more than 625MHz will create false (aliased) signal on screen, worse is that dho800/900 enforce sinc interpolation only (no linear vector or dots) on the display. this has been discussed to death and as an arguing point to competing brand fanboysm why dho900 is a bad dso, now this guy want to go even further, amazing!
I don't want to be rude, but probably You dont know too much about analog filters. With same sample rate, changing bandwith via filter changes shape which in some cases can be very significant and change Your decisions. Spikes between samples will be also visible (I still have filtering but on much higher frequency), but it ADC will it see earlier and in less samples. I never told anything about measuring 800 MHz signals. With 80 MHz I still have ~15 samples per period but its less distorted.
thats ok, the day of feeling insulted is gone, we are here to learn new things even if we have to go through lenghty arguments. in fact it is true i have no clue at all at the front end since i never investigate that region, what those LC filter values on components etc because imho no point for me atm. or maybe because i'm not there yet due to no urgent need. yes you can see descent, nice and smooth 80MHz square with 500-800MHz BW scope. i thought you want to see details including rise time region, thats where telling many things about circuit condition. with 10-20X sampling, you can see decent square, but thats all, probably most real step condition are lost anyway. and please note, once sampler is exposed to anything half or more frequency content, you can be happy with any false signals on your screen without knowing it is false, just a precaution that i hope future beginner readers will not fall trap into. this is not me telling, this is mr harry nyquist is telling us. ymmv.
-
I didnt notice that is from TI (some logo somwhere?). IMHO TI makes much better jelly bean parts than other manufacturers.
Hmm... I might be confusing this with some other scope. I'll try to find the reference.
-
norbert.kiszka Did I understand correctly that no practical benefit was achieved as a result of all these horrors?
as i said tuning to 400-500MHz is probably sensible. but the way he is shorting the filter inductor is like opening up infinite BW at ADC input to me, at least we have a sound filter simulation presented that cutoff nyquist sampling limit, ie at 500-625MHz, slightest presence of anything more than 625MHz will create false signal on screen, worse is that dho800/900 enforce sinc interpolation (no linear vector or dots) on the display. this has been discussed to death and as an arguing point to competing brand fanboysm why dho900 is a bad dso, now this guy want to go even further, amazing!
Everybody should keep in mind limits of test equipment hardware and software. I already had that discussion about sampling with my teacher long time ago (thats why he told me he doesnt like digital scopes - however that was exactly two decades ago). In this case most important is to maintain line termination - in "400 MHz hack" nobody mentioned it. Maybe Im stupid and proper termination is not a problem? BTW. This cap before filters has 7 pF (measured).
slightest presence of anything more than 625MHz will create false signal on screen
Are you trying to suggest LC filters are kind of magic and not making false signals? Phase shift in pulses are nothing to worry about? Lowering amplitude of high frequency is also never not a problem? Anything between samples will be still on screen - more or less. Im aware of it. Only one problem for me here is the noise (as I mentioned earlier) - I will check eventual contamination (making higher capacitance somewhere in the analog path) - if its not the case, then I will bring back second stage filter, which I suspect is around 800 MHz.
-
Has anyone tried these Puccy 3 Pack Screen Protector TPU Film Guard (Not Tempered Glass) (https://www.amazon.com/Screen-Protector-compatible-Tempered-Protectors%EF%BC%89/dp/B0CLS4NPMB) for the touchscreen?
If so, what are the pros and cons of them? Does it cut down on the screen reflection?
-
Has anyone tried these Puccy 3 Pack Screen Protector TPU Film Guard (Not Tempered Glass) (https://www.amazon.com/Screen-Protector-compatible-Tempered-Protectors%EF%BC%89/dp/B0CLS4NPMB) for the touchscreen?
If so, what are the pros and cons of them? Does it cut down on the screen reflection?
I remember somebody mentioned some screen protector in this thread or in a teardown/bugs thread.
-
By the way, this is the memory I have on 804.
-
Has anyone tried these Puccy 3 Pack Screen Protector TPU Film Guard (Not Tempered Glass) (https://www.amazon.com/Screen-Protector-compatible-Tempered-Protectors%EF%BC%89/dp/B0CLS4NPMB) for the touchscreen?
If so, what are the pros and cons of them? Does it cut down on the screen reflection?
The description says "gloss finish", so it probably is (at least) as reflective as the original. It's also plastic film, not glass at all. Good thing they give you three of these so you can replace them when they are scratched again...
-
By the way, this is the memory I have on 804.
On 924S I have different ones. All populated (4 GB visible for CPU). Other ones for CPU and other ones for FPGA.
Edit: I dont know if I uploaded photo around CPU, so here it is:
-
If somebody will need values and placement of resistors (924S), I measured most of it around CPU (photos atached).
-
Maybe Im stupid and proper termination is not a problem?
LC filter has its own input and output Zc, maybe that 85ohm you mentioned earlier is its termination? removing the LC filter changes Zc, then you mentioned again 50ohm, how you make to that conclusion? i havent plugin values trace width and distance and gnd plane height into saturn pcb toolkit yet to know what those diff strips' Zc, so :-// btw i cant find any "dho800/900 400 MHz hack" in this forum, that russian forum doesnt show any conclusive method anyway. so your posts seem out of magic for me.
slightest presence of anything more than 625MHz will create false signal on screen
Are you trying to suggest LC filters are kind of magic and not making false signals? Phase shift in pulses are nothing to worry about? Lowering amplitude of high frequency is also never not a problem? Anything between samples will be still on screen - more or less. Im aware of it.
what is the cutoff frequency by shorting those inductors pads?
Only one problem for me here is the noise (as I mentioned earlier) - I will check eventual contamination (making higher capacitance somewhere in the analog path) - if its not the case, then I will bring back second stage filter, which I suspect is around 800 MHz.
either you misunderstand me, or me misunderstand you, i think. please proceed ;D
-
Maybe Im stupid and proper termination is not a problem?
LC filter has its own input and output Zc, maybe that 85ohm you mentioned earlier is its termination? removing the LC filter changes Zc, then you mentioned again 50ohm, how you make to that conclusion? i havent plugin values trace width and distance and gnd plane height into saturn pcb toolkit yet to know what those diff strips' Zc, so :-// btw i cant find any "dho800/900 400 MHz hack" in this forum, that russian forum doesnt show any conclusive method anyway. so your posts seem out of magic for me.
Same impedance must be for DC. That explains why they added capacitor before a filters instead of giving lower value for resistors - with removing coils, this cap (before filter) should be also removed to match same impedance - is that clear or not? Also, resistors just after input stage are 2x 35Ω (70Ω in total). Thats why I removed this cap before filters to match same impedance. 0.1Ω difference is not a problem (measured those resistor before ADC are 85.2 84.9 85.3 85.3).
What You have on mind with 50Ω ? Maybe You misread what I told earlier of what I expected when I was measuring those resistors.
slightest presence of anything more than 625MHz will create false signal on screen
Are you trying to suggest LC filters are kind of magic and not making false signals? Phase shift in pulses are nothing to worry about? Lowering amplitude of high frequency is also never not a problem? Anything between samples will be still on screen - more or less. Im aware of it.
what is the cutoff frequency by shorting those inductors pads?
Much higher than before. More than 1 GHz. Input stage is also a filter - if You like it or not.
Do You have any sort of problem with my modification? I dont see any distortions after this change. Only more noise, as I mentioned three times. Im not Your child, so please dont force me waht I should do with my scope and what I shouldnt. I feel like Im talking with Arduino-child which forces everybody else to put Arduino everywhere (including simple inverter based on single transistor).
either you misunderstand me, or me misunderstand you, i think. please proceed ;D
That didnt sound nice.
-
By the way, this is the memory I have on 804.
Thank you. That's the same as in my 804, purchased Black Friday from AliExpress -CN. I think they ran out of the GigaDevice part in November., as a lot of the photos of newer builds show the Samsung -BYMA parts.
-
either you misunderstand me, or me misunderstand you, i think. please proceed ;D
That didnt sound nice.
Wow man., are you seriously so tired of insulting everyone else, that now you're insulting yourself? ;)
-
Much higher than before. More than 1 GHz. Input stage is also a filter - if You like it or not.
good! try feeding the scope with ringy square wave, say 100MHz square (since you already have 0.8-1GHz scope) nasty signals, not a good one, say with highly mismatched reflected signal, highly overshooted etc, just a simulation of quite badly designed circuit/dut. show me the gibbs! (https://www.eevblog.com/forum/testgear/split-from-rigols-new-dho800-oscilloscope-unbox-amp-teardown) ;) cheers.
-
Much higher than before. More than 1 GHz. Input stage is also a filter - if You like it or not.
good! try feeding the scope with ringy square wave, say 100MHz square (since you already have 0.8-1GHz scope) nasty signals, not a good one, say with highly mismatched reflected signal, highly overshooted etc, just a simulation of quite badly designed circuit/dut. show me the gibbs! (https://www.eevblog.com/forum/testgear/split-from-rigols-new-dho800-oscilloscope-unbox-amp-teardown) ;) cheers.
Currently I will not put housing back to do Your request. I already compared signal between channels and I didnt see any "nasty" signals, reflections or overshots. Please keep Your imagination to yourself.
-
I feel strangely reminded of people modding their old Philips CD players -- disabling DAC oversampling and removing all output lowpass filters. They used to swear by the perceived sound improvement, while others were swearing at them...
-
Ref from CH1 and modded CH4 with exact same settings (including sample rate) and same coax:
-
while others were swearing at them...
Some people thinks that if a some engineer made something in some way, then completely nobody can change that, because engineer decided to use only possible way and everybody changing design are stupid. So if a some stock radio in a car is X, then I shouldnt change it to other model, because some engineer made best possible decision?
-
Much higher than before. More than 1 GHz. Input stage is also a filter - if You like it or not.
good! try feeding the scope with ringy square wave, say 100MHz square (since you already have 0.8-1GHz scope) nasty signals, not a good one, say with highly mismatched reflected signal, highly overshooted etc, just a simulation of quite badly designed circuit/dut. show me the gibbs! (https://www.eevblog.com/forum/testgear/split-from-rigols-new-dho800-oscilloscope-unbox-amp-teardown) ;) cheers.
Currently I will not put housing back to do Your request. I already compared signal between channels and I didnt see any "nasty" signals, reflections or overshots. Please keep Your imagination to yourself.
sorry if i sound "complaining", i'm not... i'm just "asking" or "proposing"... as i said earlier, no compulsion... but we maybe share the same urge.. cheers. ;)
Earlier I told here to measure those resistors. Everybody else assumed those are 0 Ω resistors... I wasnt complaining, but watching everybody destroying their scopes. Next time dont assume anything, especially when somebody tells You opposite. Using multimeter can take couple seconds and can save expensive&precise equipment and save many hours of unnecessary work.
-
Earlier I told here to measure those resistors. Everybody else assumed those are 0 Ω resistors... I wasnt complaining, but watching everybody destroying their scopes. Next time dont assume anything, especially when somebody tells You opposite. Using multimeter can take couple seconds and can save expensive&precise equipment and save many hours of unnecessary work.
When modding CH4 I didnt assume anything. As I posted before, I will repeat myself: I dont see anything wrong with this modded channel beside of higher noise.
-
Ref from CH1 and modded CH4 with exact same settings (including sample rate) and same coax:
Where is this signal coming from and how is it fed to the scope? It looks seriously screwed up, I mean all that strong ringing.
-
Ref from CH1 and modded CH4 with exact same settings (including sample rate) and same coax:
Where is this signal coming from and how is it fed to the scope? It looks seriously screwed up, I mean all that strong ringing.
Cheap and ugly resistors to match impedance and same thing with coax.
-
Ref from CH1 and modded CH4 with exact same settings (including sample rate) and same coax:
I would say that the signal we see is nicely bandwidth-limited to about 100 MHz, in both cases: We see pronounced ringing at the 5th harmonic of the 20 MHz fundamental, so there is not much frequency content above that. And I would eyeball the risetime at 3.0 to 3.5 ns, which is also consistent with not much more than 100 MHz.
Presumably your source already limits the spectral content. In which case one would expect to see neither a benefit, nor any problem, from the lack of an input lowpass filter.
How do things look with a signal which actually contains higher frequency components? Could you show the benefit? And what about aliasing from spectral components above the Nyquist limit?
-
Ref from CH1 and modded CH4 with exact same settings (including sample rate) and same coax:
I would say that the signal we see is nicely bandwidth-limited to about 100 MHz, in both cases: We see pronounced ringing at the 5th harmonic of the 20 MHz fundamental, so there is not much frequency content above that. And I would eyeball the risetime at 3.0 to 3.5 ns, which is also consistent with not much more than 100 MHz.
Presumably your source already limits the spectral content. In which case one would expect to see neither a benefit, nor any problem, from the lack of an input lowpass filter.
How do things look with a signal which actually contains higher frequency components? Could you show the benefit? And what about aliasing from spectral components above the Nyquist limit?
Signal coming from this stupid hand made generator is not bandwidth limited. Beside of overshot, voltages are as expected. Measured rise time is very close to what You told, exactly 2.3 ns.
Later I will make some faster generator, beside of fact I have one (faster than this).
-
Ref from CH1 and modded CH4 with exact same settings (including sample rate) and same coax:
Where is this signal coming from and how is it fed to the scope? It looks seriously screwed up, I mean all that strong ringing.
16MHz (17MHz?) is some sort of arduino clock? 10Vpp source? if its 5Vpp, its unterminated.
-
Ref from CH1 and modded CH4 with exact same settings (including sample rate) and same coax:
Where is this signal coming from and how is it fed to the scope? It looks seriously screwed up, I mean all that strong ringing.
16MHz (17MHz?) is some sort of arduino clock? 10Vpp source? if its 5Vpp, its unterminated.
17.7 MHz, 5Vpp terminated on both ends. In latest firmware there is a 2x probe selection.
-
If anyone is interested, I have attached two files. These are boot logs read from the UART connectors of the processor and FPGA.
Thanks for posting these. Have you diff'd these to the original logs Dave posted that he took during the teardown video? Has much changed? I'll check in "the morning" when I get up. ;)
No, I didn't compare. I didn't even look closely at what I recorded from my oscilloscope :)
Huh. Interesting.
Aside from the Garbage characters at the beginning and the occasional line break diff, not much changed in the FGPA console outputs. Not totally surprising, but a tad bit disappointing that they haven't found something to fix. Maybe their VHDL team is that good....?
On the RK side; Even though dates/versions are same, there are many more white space diffs, and there seems to be several lines not matching up -Altho', admittedly I'm just doing a quick compare using a subpar diff tool--Chrome extension POS. Hard to tell what's missing, and not.
Did you edit/add anything in your bash scripts?
If you don't mind sharing; What is your model # and month built?
-
Did you edit/add anything in your bash scripts?
As far as I remember, I only changed the time zone setting in the oscilloscope application launch script :)
If you don't mind sharing; What is your model # and month built?
Model - DHO814. I don’t even know how to look at the month of release, but I ordered it at the end of November 2023 :)
The firmware is the latest, 00.01.02.00.02
-
Did you edit/add anything in your bash scripts?
As far as I remember, I only changed the time zone setting in the oscilloscope application launch script :)
If you don't mind sharing; What is your model # and month built?
Model - DHO814. I don’t even know how to look at the month of release, but I ordered it at the end of November 2023 :)
The firmware is the latest, 00.01.02.00.02
Ahh, Thanks. This is from when mine was "new": See build date.
[attachimg=1 width=500]
-
Ahh, Thanks. This is from when mine was "new": See build date.
(Attachment Link)
Well, the build date is the build date of the application, it depends only on the version of the application :) Now I have a modified application in which this date is set to February 28, 2024 :)
I don’t even remember what I had there from the factory :) It seems the same as what you have in the screenshot :)
-
My Scope came with one of the really noisy fans. Within 0.5M, I couldn't stand the noise/whine. I decided to find a quiet & hopefully cooler solution.
I know a couple others did mods with 80, 92 and 100mm fans, but I wanted to take the time to illustrate the benefits/tradoffs so people could determine if/how they wanted to take on the challenge. All the pix I remember seeing were 25mm deep, and weren't favored because the fan hits the bench.
First, I attached the stock fan cable to 15mm thick Thermalright fans.(Amazon $6.29USD each)
[attachimg=3 width=300]
Fan 1: 80x80x15mm, <23.3 dBA 28.40 CFM 0.07A @12Vdc
Fan 2: 92x92x15mm, <22.4 dBA 42.58 CFM 0.18A @12Vdc
Note: stock fan is spec'd at 0.17A @12Vdc
FYI: All these tests are running on the internal @8Vdc provided by the original fan connector
I removed the stock fan from the heatsink, to decrease the turbulence and allow more laminar flow. I observed >1C drop after removing the fan, so I left it off for the rest.
[attachimg=1 width=600]
I started with the 80mm. The hardware included with the Thermalright fan fits in the DHO hexagon grid hole pattern nicely.
I located the fan so it misses the RIGOL logo. Less turbulent air noise this way.
[attachimg=2 width=600]
Next, using the 92mm fan, I had a bit more difficulty aligning the holes, but managed a location with maximum air flow, but not quite perfect bolt arrangement. i.e., It works, but not as good looking 'cuz I had to turn a couple backwards from the others. (Mechanial crash)
My factory stock fan, starting temps were always very close to 60C(~59.x), but I only found one saved screenshot at 58.3/55.5 @ 25-26C ambient.
After the mod, all channels active, +math, minimum of 1 hour cookin' at 26C ambient:
80mm = 55.5/52.7C
80mm = 53.8/50.5C (As a test, I blocked the remaining hex holes around the fan with tape to force all incoming air across heatsink)
92mm = 48.7/46.2C I didn't tape up the surrounding holes, but I can if someone needs to know what the delta is.
I didn't order a grill for either fan, but definitely found out what happens when you stick a finger in the blades. :rant: It very politely waits for a few seconds, then restarts. I don't know if that's the fan or the 8V switcher recovering from the stall condition.
[attachimg=4 width=400]
Some things to note:
1. Oh yeah. It's Silent now... At 1/2 meter, you can't hear a thing. Tiny amount of air noise on the backside, directly at the 92mm fan, even less on the 80mm. (like, not even worth trying to measure)
2. It's a well known fact that cooler=better with IC's., but now you can decide if the upgrade is worth it to you.
3. If you don't want to clip/solder your stock fan cable, you could get a JST/Molex or other female connector with 2.54mm/0.10" spacing.
4. I may try to enhance the heatsink surface area by adding a small heatsink to the area where the stock fan was. I definitely think it would be worthwhile to do. I have a 40mm2 sink, but it was a bit too big for that spot, un-modified.
5. If you can find a 80mm at 35 CFM with a reasonable dBA, it might be just about perfect to run at 8V, or maybe run this one at 12V?.
6. Thread locker might be important when the nuts are on the inside. Or use plastic?
Hope this helps someone "upgrade" their 'scope to a quiet, cool running one...
Edit: Update -- Be sure to check out the excellent 120mm fan upgrade (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5338634/#msg5338634) by @shapirus that I completely ignored when I did my mods. --Sorry again for that!
-
All the pix I remember seeing were 25mm deep, and weren't favored because the fan hits the bench.
Somebody installed a 120mm x 15mm fan too: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5338634/#msg5338634 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5338634/#msg5338634)
It'd be ideal to find a fan with the same mounting hole spacing as the vesa mount (i.e. 100mm x 100mm), but so far I haven't seen any.
-
All the pix I remember seeing were 25mm deep, and weren't favored because the fan hits the bench.
Somebody installed a 120mm x 15mm fan too: https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5338634/#msg5338634 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5338634/#msg5338634)
It'd be ideal to find a fan with the same mounting hole spacing as the vesa mount (i.e. 100mm x 100mm), but so far I haven't seen any.
Yeah, I didn't find any either. All the ones around the 100mm range that I saw weren't measuring the mounting locations, but the frame of the fan. Sucks. :(
Edit: Oh, That guy?!!? What a hack! he clearly didn't know what he was doing. :-DD
-
Somebody installed a 120mm x 15mm fan too:
^^ I can't believe I forgot about that. I remember seeing and loving it now. Sorry buddy.
BTW: Did you remove the stock fan as well?
-
BTW: Did you remove the stock fan as well?
Sure enough. There's no point in it sitting there and shading the surface of the heat sink from the air flow.
-
Yeah, I didn't find any either. All the ones around the 100mm range that I saw weren't measuring the mounting locations, but the frame of the fan. Sucks. :(
The 120 mm fans have 105 mm mounting hole spacing, so for 100 mm the frame size would be someting like 115 mm. Maybe they exist, but it would definitely not be one of common types.
-
BTW: Did you remove the stock fan as well?
Sure enough. There's no point in it sitting there and shading the surface of the heat sink from the air flow.
Good job. Awesome. I may try to fit a chunk of heatsink in that area to increase surface area as I mentioned in Note #4. It is sure to help., given what's almost directly underneath the heatsink there. ;)
-
Verify this datasheet matches the actual RK chip used in your DHO. My gpio mappings are correct, but if wrong datasheet they could be physically mapped in a different matrix (there are several versions/flavors of RK3399).
Question: How many "versions/flavors" of the RK3399 chip have you discovered?
And do you have any info that Rigol used different versions in the DHO's?
Links please?
I have seen the RK3399 reprsented as "RK3399(K)" "RK3399-K" "RK3399" and "RK3399Pro"
However, only the "Pro" version seems to have a spec sheet that is different than the others.
-
If anyone is interested, I have attached two files. These are boot logs read from the UART connectors of the processor and FPGA.
RK log is interesting.
1) it confirms what I mentioned a few pages back, this version of droid is using sdcardfs as top layer to the two partions.
2) what's with all the "kernel module not found" messages?
-
Regarding the chatter around hacking a channel to be 50ohm. Why bother, just use a 50ohm passthrough connector. That's been a std for ages now (for scopes that don't support internal 50ohm). And if you roast an insternal 50ohm Z network (whatever that may be), then you need to go dig inside the unit to do the fixing.
-
What you think about passive cooling?
No thermal pad so better transfer of heat.
heatsinks with height of 20 mm less for FPGA and DDR4 that may allow only 19mm and for CPU only 18 mm
Big disadvantage will be weight increase.
-
2) what's with all the "kernel module not found" messages?
I have no idea :) I only cautiously say hello to Linux across the road, I have no friendly relations with him :)
-
What you think about passive cooling?
No thermal pad so better transfer of heat.
heatsinks with height of 20 mm less for FPGA and DDR4 that may allow only 19mm and for CPU only 18 mm
Big disadvantage will be weight increase.
Individual sinks? How do you mount them?
-
What you think about passive cooling?
No thermal pad so better transfer of heat.
heatsinks with height of 20 mm less for FPGA and DDR4 that may allow only 19mm and for CPU only 18 mm
Big disadvantage will be weight increase.
Getting rid of close to 50W from that small enclosure via convection cooling only seems unrealistic. Look at the size of heatsinks with less than 1K/W -- and those are specified for unobstructed convection, while I assume you intend to keep the scope's back lid in place?
Or, another way to look at it: Look at the heat energy per time that has to leave the enclosure. With just the slow air flow from convection, how hot would that air have to be?
-
We can even simulate the heat transfer process of a specific radiator. In the same SolidWorks, for example.
-
I have seen the RK3399 reprsented as "RK3399(K)" "RK3399-K" "RK3399" and "RK3399Pro"
However, only the "Pro" version seems to have a spec sheet that is different than the others.
Main (only?) difference of the "Pro" version seems to be that it incorporates a dedicated NPU (Neural Process Unit) for neural networks. I don't see how that would be beneficial in the DHO scopes, and have not seen a reference to the RK3399Pro being used by Rigol.
-
As for fans, if you can find a thin fan somewhere near 8mm thick, they will fit inside between sink and case. I can find 8mm thick boxer fans, but their XY dimensions are a bit too small, would need too many fans to get the desired airflow. A 40x40x8 would be ideal, you can place 2-3 of those inside the case.
-
Individual sinks? How do you mount them?
There are thermally conductive adhesives need to choose good one.
Getting rid of close to 50W from that small enclosure via convection cooling only seems unrealistic. Look at the size of heatsinks with less than 1K/W -- and those are specified for unobstructed convection, while I assume you intend to keep the scope's back lid in place?
Or, another way to look at it: Look at the heat energy per time that has to leave the enclosure. With just the slow air flow from convection, how hot would that air have to be?
Maybe a mixed solution
Passive for what can be done active for other.
-
if postage cost is not too much, dont forget to mail me the original heatsink.
-
There are thermally conductive adhesives need to choose good one.
Check the weight of adequate heat sinks, and consider whether you want your BGA solder joints to carry that weight. (Plus the extra force when you set the scope onto a table or bump it in transport.)
Maybe a mixed solution
Passive for what can be done active for other.
Requiring the added weight of large heat sinks, an external fan since there will be no room left for an internal one, plus some creative wiring for temperature sensors? I am not convinced.
-
There are thermally conductive adhesives need to choose good one.
Check the weight of adequate heat sinks, and consider whether you want your BGA solder joints to carry that weight. (Plus the extra force when you set the scope onto a table or bump it in transport.)
Maybe a mixed solution
Passive for what can be done active for other.
Requiring the added weight of large heat sinks, an external fan since there will be no room left for an internal one, plus some creative wiring for temperature sensors? I am not convinced.
For many the little DHO's are not stationary, thus the sinks must be able to stay on while the unit gets knocked around. More cons then pros?
I am also wondering if the OEM sink serves as some form of gnd-plane?
-
I am also wondering if the OEM sink serves as some form of gnd-plane?
Absolutely not.
-
EMI shield probably yes to some extend..
-
It's quite a neat cooling design in my opinion. Within the constraints of the compact enclosure, it's a pretty good solution -- large surface area, low profile.
Of course, seeing how people eventually add a large external fan as a backpack -- maybe there was no need to aim for such a low-profile enclosure? Adding a centimeter or two to the depth in return for a larger and quiet fan would have been the rational design choice. But probably the sleek form factor selles more scopes...
-
It's quite a neat cooling design in my opinion. Within the constraints of the compact enclosure, it's a pretty good solution -- large surface area, low profile.
Of course, seeing how people eventually add a large external fan as a backpack -- maybe there was no need to aim for such a low-profile enclosure? Adding a centimeter or two to the depth in return for a larger and quiet fan would have been the rational design choice. But probably the sleek form factor selles more scopes...
They could make it deeper at least up to the depth of the carrying handle, which would have allowed to put a larger and quieter fan inside, and that wouldn't have made the bounding box dimensions larger. It's yet another poor engineering decision that went into this platform. And they are also making a signal generator and a bench DMM in the same enclosure! And of course with the same whiny fans (maybe only powered with a lower voltage, but I think that's not likely).
-
What you think about passive cooling?
No thermal pad so better transfer of heat.
heatsinks with height of 20 mm less for FPGA and DDR4 that may allow only 19mm and for CPU only 18 mm
Big disadvantage will be weight increase.
Personally, I think about passive cooling all the time. I think it's sad when engineers don't take the time to do a good job. IMHO, they chose style over substance in this design.
I bought a heatsink kit when I got the fans for my project, and will post my findings when I do it.
Weight increase? Doubtful. Have you seen the size and weight of the existing heatsink? OMG. I think it will be less weight to implement discrete sinks. I wish I had a scale here for a A-B comparison.
@ebastler I don't think weight on the solder joints will be a concern. As, solder's secondary trait(behind electrical) is mechanical. And generally speaking, there is typically significant clamping force to hold a heatsink in place. -Screws, springs, bands, etc. Right? There may be a spec, of course, and thanks for boosting the awareness of that issue. I just don't think there's enough room internally(<17mm? vertical) to hang enough weight to cause problems.
Also, have you seen some of the heatsinks companies/users/hackers put on little SBCs with these SoCs?? -Wowsa.
-
It's yet another poor engineering decision that went into this platform.
probably your and few others' POV only... adding large fan and add the depth is much easier than cutting enclosure into half to get sleeker profile that fit in a laptop backpack needed by some... you cant satisfy everybody... my PC fan makes dho800 noiseless... i need to put my ear to the very back of enclosure to make sure i didnt forgot to plug the fan's connector in during reassembly...
-
Verify this datasheet matches the actual RK chip used in your DHO. My gpio mappings are correct, but if wrong datasheet they could be physically mapped in a different matrix (there are several versions/flavors of RK3399).
Question: How many "versions/flavors" of the RK3399 chip have you discovered?
And do you have any info that Rigol used different versions in the DHO's?
Links please?
I have seen the RK3399 reprsented as "RK3399(K)" "RK3399-K" "RK3399" and "RK3399Pro"
However, only the "Pro" version seems to have a spec sheet that is different than the others.
Links? I'm well aware of the Pro, but I have not seen any PDFs for the ?K? version. There is a T version on some SBCs... Is that what you're thinking? I have brief info for the T part, and BTW it has the identical pin out that the std RK3399 has.
Again; do you have any info that Rigol used different package parts(as you suggested) on the DHOs? that would suggest different PCB versions.
-
@ebastler I don't think weight on the solder joints will be a concern. As, solder's secondary trait(behind electrical) is mechanical. And generally speaking, there is typically significant clamping force to hold a heatsink in place. -Screws, springs, bands, etc. Right?
There may be a spec, of course, and thanks for boosting the awareness of that issue. I just don't think there's enough room internally(<17mm? vertical) to hang enough weight to cause problems.
Also, have you seen some of the heatsinks companies/users/hackers put on little SBCs with these SoCs?? -Wowsa.
I was referring to gabiz_ro's suggestion to mount the heatsinks (only) by glueing them to the chips -- no screws, springs, bands. I would certainly advise against that.
And again -- look at a few heatsinks with < 1K/W ratings. Those are a different caliber than anything I have seen mounted on SBCs! And they are probably still not good enough to cool the DHO800, unless you leave its back cover off for unobstructed convection.
-
@ebastler I don't think weight on the solder joints will be a concern. As, solder's secondary trait(behind electrical) is mechanical. And generally speaking, there is typically significant clamping force to hold a heatsink in place. -Screws, springs, bands, etc. Right?
There may be a spec, of course, and thanks for boosting the awareness of that issue. I just don't think there's enough room internally(<17mm? vertical) to hang enough weight to cause problems.
Also, have you seen some of the heatsinks companies/users/hackers put on little SBCs with these SoCs?? -Wowsa.
I was referring to gabiz_ro's suggestion to mount the heatsinks (only) by glueing them to the chips -- no screws, springs, bands. I would certainly advise against that.
And again -- look at a few heatsinks with < 1K/W ratings. Those are a different caliber than anything I have seen mounted on SBCs! And they are probably still not good enough to cool the DHO800, unless you leave its back cover off for unobstructed convection.
It's only 6W(TDP) for the RK3399, with few watts for the display, few watts for the storage, a few for misc and efficiency losses. Roughly 20-25W., the rest for the FPGA. -total on the 800s is ~35W., with a tiny bit more for 900S because of the AWG board. How are you coming up with anything close to 1KW? Edit: Disregard, I misread.
BTW, I have seen at least one industrial SBC maker offering a fanless(touting high reliability) RK3399 board design, that had a relatively small heatsink. -maybe ?35x35mm. (Has a 2 year warranty as well.)
I think It might be ok using thermal tape/adhesive as @gabiz_ro was suggesting., provided the adhesive keeps them in place after a few thermal cycles. In my experience with good quality vendors, this hasn't been a concern. However, we are in the new world of AliExpress/Amazon cheap parts these days, so we'll have to see what happens!
-
It's only 6W(TDP) for the RK3399, with few watts for the display, few watts for the storage, a few for misc and efficiency losses. Roughly 20-25W., the rest for the FPGA. -total on the 800s is ~35W., with a tiny bit more for 900S because of the AWG board. How are you getting close to 1KW?
Total power consumption of the DHOs is known to be 4A at 12V, or 3A at 15V if I remember correctly, so about 50W. A heatsink with a 1 K/W rating (that's one Kelvin of temperature increase per Watt of dissipated power -- nothing to do with 1 kW!) seems the lower limit of what you can get away with. It would run at ambient + 50°C, even under the optimistic assumption of free air convection.
Edit: a 35*35 mm² heatsink (with less than 35 mm height, I assume?) will be far from 1 K/W -- more like 10 K/W. You would need a much more hefty heatsink to passively cool the DHO.
-
I don't think dissipating 35 W passively in these dimensions can be viable. 35 W (or what is it actually, 50 W?) is a lot of heat.
Dave tried running the scope with the stock heat sink without the fan in one of his videos (on the second channel IIRC), and it did overheat eventually. Discrete heat sinks may or may not be more effective than that, but either way it gives a decent estimation of what can be achieved with passive cooling. No, I think some forced air flow, even though pretty low, will still be required.
But if someone is willing to experiment with it, there's nothing wrong in that. Quite the opposite: it'll provide useful information to the community, whatever the result will be. I'd only avoid using any kind of permanent thermal glue: the mods should be reversible.
-
The power consumption is around 35W according to my measurement, of course, this amount of power will make passive cooling very difficult. My surface pro 8 (a consumer product with professionally designed thermal management) will also need to turn on the fan when running at the full load (comparable power and size).
-
Total power consumption of the DHOs is known to be 4A at 12V, or 3A at 15V if I remember correctly, so about 50W. A heatsink with a 1 K/W rating (that's one Kelvin of temperature increase per Watt of dissipated power -- nothing to do with 1 kW!) seems the lower limit of what you can get away with. It would run at ambient + 50°C, even under the optimistic assumption of free air convection.
Edit: a 35*35 mm² heatsink (with less than 35 mm height, I assume?) will be far from 1 K/W -- more like 10 K/W. You would need a much more hefty heatsink to passively cool the DHO.
Doh! Brain fart. Sorry about the kW vs K/W confusion. Didn't caffeinate before reading your post.. Agreed.,
--and as others have noted, 35W. That 12V-4A number was for the power supply that was shipped with a few early models.
-
Verify this datasheet matches the actual RK chip used in your DHO. My gpio mappings are correct, but if wrong datasheet they could be physically mapped in a different matrix (there are several versions/flavors of RK3399).
Question: How many "versions/flavors" of the RK3399 chip have you discovered?
And do you have any info that Rigol used different versions in the DHO's?
Links please?
I have seen the RK3399 reprsented as "RK3399(K)" "RK3399-K" "RK3399" and "RK3399Pro"
However, only the "Pro" version seems to have a spec sheet that is different than the others.
Links? I'm well aware of the Pro, but I have not seen any PDFs for the ?K? version. There is a T version on some SBCs... Is that what you're thinking? I have brief info for the T part, and BTW it has the identical pin out that the std RK3399 has.
Again; do you have any info that Rigol used different package parts(as you suggested) on the DHOs? that would suggest different PCB versions.
I don't really know what exact RK3399 Rigol used. If you say Rigol used the low end "RK3399" and not K and not Pro, then I guess that's what it is.
I was not suggesting that some DHO's have varying RK3399. What I said in that post was, make sure the datasheet I linked is the right one. I could have perhaps linked to the wrong datasheet.
RK3399
RK3399K
RK3399Pro
RK3399-T
The K version is right in the datasheet. K appears to have faster clock rate. Pro appears to have a "NPU" processor. Since K and non-K are in same datasheet, then I suspect it has same physical pin mapping since it's one datasheet.
So perhaps three-four-five flavors, but maybe Pro and T has a different pin layout?
See pics
-
EMI shield probably yes to some extend..
That's what I was saying when I said "gnd-plane".
Making those individual glue-on sinks probably takes away from the shielding. If the OEM sink didn't need to be made boxy like that, then they could have saved a ton of aluminum.
-
Edit: a 35*35 mm² heatsink (with less than 35 mm height, I assume?) will be far from 1 K/W -- more like 10 K/W. You would need a much more hefty heatsink to passively cool the DHO.
On closer examination; While that SBC itself is fanless, their temp spec says "@0.7m/s Air Flow"., BTW it looks significantly shorter than 35mm height. They also don't have a FPGA running balls out, contributing to the heat load.
Incidentally, this is a very warm product, naturally. Uncomfortably so, IMHO. When I unplug a USB connector it's HOT., BNC's are as well. I forgot to measure the temperature on the connectors during my fan testing, but the last mod I did cooled the I/O's considerably.
BTW: @shapirus
I watched that video you mentioned, and have some issues with his methodology. I'm not saying it was flawed per se', but I just can't put much confidence in some of his findings in general. Ex: when Rigol did their HALT testing, I doubt they turned it up on end, dumping heat into the power supply section.
-From what I've observed, these scopes don't really need much of an excuse to reboot. Sometimes, I'll look over at my DHO because it's clicking and flashing in the middle of a reboot cycle. For no reason!
(Before anyone asks: ^that's before I opened it)
-
I don't really know what exact RK3399 Rigol used. If you say Rigol used the low end "RK3399" and not K and not Pro, then I guess that's what it is.
I was not suggesting that some DHO's have varying RK3399. What I said in that post was, make sure the datasheet I linked is the right one. I could have perhaps linked to the wrong datasheet.
RK3399
RK3399K
RK3399Pro
RK3399-T
The K version is right in the datasheet. K appears to have faster clock rate. Pro appears to have a "NPU" processor. Since K and non-K are in same datasheet, then I suspect it has same physical pin mapping since it's one datasheet.
So perhaps three-four-five flavors, but maybe Pro and T has a different pin layout?
I didn't say Rigol used the low end RK3399. Nor would I, because the -T is the low end part.
Rigol used the commonly available RK3399 part that's in almost everything that is RK3399 based. BTW: I had to diff the PDFs to find info on the -T parts, because I couldn't find anything online, and don't have any factory rep contacts these days. :(
The K part(I.e., commercial) is from "binning" the fast from the slow parts, with extended temperatures range. -T parts are the slowest of the bunch at 1.5/1.0G clock speeds.
Other than the Pro, the packages, pinouts, etc. are all the same. -You had me going for a minute, I thought you found an undiscovered 3399 variant.
-
Hey Andy (or others who know the answer)...
Regarding your post #1507 in this thread (step-by-step mod guide)
First Andy a big thank you for summarizing the process of updating the DHO800!!
It is mind bending to try to follow all the posts in this thread and keep up with where we are in the learning process.
Is it correct that one should update firmware on their new scope BEFORE doing the hack as you have detailed??
My new DHO804 currently has Firmware 00.01.01 but as of this writing I see Rigol has 00.01.02.00.02 available for download.
If the answer to the firmware update question is YES then it might be a good idea for an edit of your post #1507 to clarify this question.
Even better, as someone else suggested, would be to create a new TOPIC in the forum specifically just to hold the guide and have the separate "guide topic" be updated as new relevant steps or options come to light.
It is a daunting task for a new owner to come to this thread and try to sift through the (currently) 98 pages of discussion.
Or move your guide to the top of the thread would be another option.
But the question I have now is whether I need to update to the latest firmware BEFORE doing the mod??
Thanks again for taking to time to create your step-by-step guide!!
Cheers
Dwight
-
Hey Andy (or others who know the answer)...
Regarding your post #1507 in this thread (step-by-step mod guide)
First Andy a big thank you for summarizing the process of updating the DHO800!!
It is mind bending to try to follow all the posts in this thread and keep up with where we are in the learning process.
Is it correct that one should update firmware on their new scope BEFORE doing the hack as you have detailed??
My new DHO804 currently has Firmware 00.01.01 but as of this writing I see Rigol has 00.01.02.00.02 available for download.
If the answer to the firmware update question is YES then it might be a good idea for an edit of your post #1507 to clarify this question.
Even better, as someone else suggested, would be to create a new TOPIC in the forum specifically just to hold the guide and have the separate "guide topic" be updated as new relevant steps or options come to light.
It is a daunting task for a new owner to come to this thread and try to sift through the (currently) 98 pages of discussion.
Or move your guide to the top of the thread would be another option.
But the question I have now is whether I need to update to the latest firmware BEFORE doing the mod??
Thanks again for taking to time to create your step-by-step guide!!
Cheers
Dwight
Yes, if you plan to change the model from 8xx to 9xx by hacking, then updating the firmware to version 00.01.02.00.02 is necessary, otherwise you will get unpleasant vertical displacements on the channels.
I still can't get around to changing that description. I'll do this right now.
-
Is it correct that one should update firmware on their new scope BEFORE doing the hack as you have detailed??
Yes.
-
Is it correct that one should update firmware on their new scope BEFORE doing the hack as you have detailed??
Yes.
Not sure of all the steps in the hack list provided, but I installed the AndyBig APK into my DHO that was running FW 00.01.02.00.00 and a 914 vendor.bin with lics. The scope app worked fine from what I could see. I later did upgrade to 00.01.02.00.02 and then re-installed the AndyBig APK, all seems ok, but I think I have odd offset in some of the channels, some say the channel os at 0.00v but if I locate the trigger in trace it's -7.54mv, even after running selfcal a few times.
-
I don't really know what exact RK3399 Rigol used. If you say Rigol used the low end "RK3399" and not K and not Pro, then I guess that's what it is.
I was not suggesting that some DHO's have varying RK3399. What I said in that post was, make sure the datasheet I linked is the right one. I could have perhaps linked to the wrong datasheet.
RK3399
RK3399K
RK3399Pro
RK3399-T
The K version is right in the datasheet. K appears to have faster clock rate. Pro appears to have a "NPU" processor. Since K and non-K are in same datasheet, then I suspect it has same physical pin mapping since it's one datasheet.
So perhaps three-four-five flavors, but maybe Pro and T has a different pin layout?
I didn't say Rigol used the low end RK3399. Nor would I, because the -T is the low end part.
Rigol used the commonly available RK3399 part that's in almost everything that is RK3399 based. BTW: I had to diff the PDFs to find info on the -T parts, because I couldn't find anything online, and don't have any factory rep contacts these days. :(
The K part(I.e., commercial) is likely "binning" the fast from the slow not so fast parts, with extended temperatures range.
Other than the Pro, it appears the packages, pinouts, etc. are all the same. -You had me going for a minute, I thought you found an undiscovered 3399 variant.
I don't follow the RK product line, so I myself really don't know what level each "flavor" is at. I only noted that there are several flavors and that we need to check that the datasheet we look at actually matches the RK that's in the DHO.
-
Not sure of all the steps in the hack list provided, but I installed the AndyBig APK into my DHO that was running FW 00.01.02.00.00 and a 914 vendor.bin with lics. The scope app worked fine from what I could see. I later did upgrade to 00.01.02.00.02 and then re-installed the AndyBig APK, all seems ok, but I think I have odd offset in some of the channels, some say the channel os at 0.00v but if I locate the trigger in trace it's -7.54mv, even after running selfcal a few times.
With previous versions of applications there were problems with offsets of up to one major division on the display. For example, with a vertical scale of 100 mV/division there could easily be an offset of 60-80 mV. And it seems that even I saw screenshots with an even greater offsets. This happened when changing the model from DHO8xx to DHO9xx due to different calibration algorithms in these series. In version 00.01.02.00.02, the calibration algorithm was made uniform for the 8xx and 9xx series and the problem of offsets went away.
-
EMI shield probably yes to some extend..
That's what I was saying when I said "gnd-plane".
Making those individual glue-on sinks probably takes away from the shielding. If the OEM sink didn't need to be made boxy like that, then they could have saved a ton of aluminum.
You guys bring up a good point. Look what I found when browsing through teardown photos of higher-end Rigol scopes. Individual tin shields with a cutout for the AFE heatsinks to stick through.
[attachimg=1 width=500]
I wonder about the temp of these versus the DHO800/900s. :-//
-
Hello guys!
I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?
-
Wouldn't it be great if the initial post of this thread could be updated with the current hacking instructions? We have AndyBig's up-to-date instructions, but they are hard to find in the long thread.
@sebyon, the OP, is not online daily, but is an active user. @sebyon, if you read this -- could you please update your original post? (I also see that a moderator has once updated the initial post, but the information is outdated again. If sebyon is not available, we could ask the mods for another update.)
EDIT: In the interim, the up-to-date instructions are here:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076)
-
At the suggestion of AceyTech, I specifically included a link to the description of the hack in my signature so that this description would be easier to find :)
-
You guys bring up a good point. Look what I found when browsing through teardown photos of higher-end Rigol scopes. Individual tin shields with a cutout for the AFE heatsinks to stick through.
I wonder about the temp of these versus the DHO800/900s. :-//
It seems to me that front-end chips should not consume a lot of energy and get very hot. The main consumers are the processor, FPGA and ADC. Well, the display probably consumes something, but we are not interested in it in terms of cooling :)
-
You guys bring up a good point. Look what I found when browsing through teardown photos of higher-end Rigol scopes. Individual tin shields with a cutout for the AFE heatsinks to stick through.
I wonder about the temp of these versus the DHO800/900s. :-//
It seems to me that front-end chips should not consume a lot of energy and get very hot. The main consumers are the processor, FPGA and ADC. Well, the display probably consumes something, but we are not interested in it in terms of cooling :)
Agreed. It seems an odd design choice that these AFE's are essentially heated by the big thermal generators.
-
Agreed. It seems an odd design choice that these AFE's are essentially heated by the big thermal generators.
I'll have to take a look at the radiator with the fan turned off sometime with a thermal imager. It seems that its surface is rough enough to get an adequate picture.
-
It seems to me that front-end chips should not consume a lot of energy and get very hot. The main consumers are the processor, FPGA and ADC. Well, the display probably consumes something, but we are not interested in it in terms of cooling :)
Agreed. It seems an odd design choice that these AFE's are essentially heated by the big thermal generators.
I am not sure whether the assumption that AFE power consumption is negligible is correct. The DHO1000 series even has four dedicated temperature readouts for CH1 and CH4 "chip" and "ambient" temperatures. (And those don't refer to the ADC, which has its own chip & ambient readouts. CPU temperature is monitored as well in the DHO1000, FPGA temperature is not.)
But an interesting thought about deliberately heating parts of the circuit. If Rigol had closed-loop temperature control of the heatsink, they could thermally couple the main 25 MHz oscillator to it to get a temperature-controlled oscillator. :)
-
...
It seems to me that front-end chips should not consume a lot of energy and get very hot. The main consumers are the processor, FPGA and ADC. Well, the display probably consumes something, but we are not interested in it in terms of cooling :)
That's not exactly true... ;). We are talking of a complex, 1GHz-capable low-noise analog design. This stuff unfortunately requires quite high quiescent currents, especially with regards to the low noise requirements. Just look at active microwave components, and their complexity usually is much lower than what we see here. I'ld assume that the four front end chips of the DHO8x4 consume as much power as all the ADC and digital circuitry.
If we could take accurate power measurements of the DHO8x4 and the DHO8x2 (preferably at the DC side, maybe with a USB power analyzer), and assume an internal PSU efficiency of 70% (switcher plus analog post-regulator), the difference would tell us approximately the consumption of one front end chip.
Would be useless but still quite interesting to know... ;D
-
I am not sure whether the assumption that AFE power consumption is negligible is correct. The DHO1000 series even has four dedicated temperature readouts for CH1 and CH4 "chip" and "ambient" temperatures. (And those don't refer to the ADC, which has its own chip & ambient readouts. CPU temperature is monitored as well in the DHO1000, FPGA temperature is not.)
That's not exactly true... ;). We are talking of a complex, 1GHz-capable low-noise analog design. This stuff unfortunately requires quite high quiescent currents, especially with regards to the low noise requirements. Just look at active microwave components, and their complexity usually is much lower than what we see here. I'ld assume that the four front end chips of the DHO8x4 consume as much power as all the ADC and digital circuitry.
It's entirely possible that I'm wrong. Unfortunately, it is impossible to obtain a datasheet for these chips, so we can only speculate.
If we could take accurate power measurements of the DHO8x4 and the DHO8x2 (preferably at the DC side, maybe with a USB power analyzer), and assume an internal PSU efficiency of 70% (switcher plus analog post-regulator), the difference would tell us approximately the consumption of one front end chip.
Would be useless but still quite interesting to know... ;D
That would be really interesting :)
-
That's not exactly true... ;). We are talking of a complex, 1GHz-capable low-noise analog design. This stuff unfortunately requires quite high quiescent currents, especially with regards to the low noise requirements. Just look at active microwave components, and their complexity usually is much lower than what we see here. I'ld assume that the four front end chips of the DHO8x4 consume as much power as all the ADC and digital circuitry.
Also not exactly true: ;) 'We are talking about a complex 2Ghz.... design', borrowed from more advanced models.(that happens to be dumbed down to 1.2G)
Did you see the photo I posted? The heatsink on the AFE is maybe 12x12mm. That's from the DHO5000. Looks like the same AFE's they're putting in the 1000/4000 line.
-
Hello guys!
I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?
glad to hear from you in PM and here... currently we are using rigol_vendor_bin from zelea2 to edit vendor.bin. with vendor.bin edited, other features such as 250MHz BW and 50Mpts memory, AFG and LA features automatically activated, no need extra *.lic anymore. although yours RigolTool can also still be applicable for the job, but its auto destruct now when we run it. its still very usefull for me as file explorer of DHO800, last time i pulled many file system using it.
and other update we were talking about your post is changing HW number read by hdcode_gpio.ko...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382392/#msg5382392 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382392/#msg5382392)
we managed to find where the config resistors are..
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5388278/#msg5388278 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5388278/#msg5388278)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389301/#msg5389301 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389301/#msg5389301)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389916/#msg5389916 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389916/#msg5389916)
but other guys (norbert.kiszka and Randy222 iirc) tried to do it in SW/FW by spoofing start_rigol_app.sh by disabling hdcode_gpio.ko and writing a number into its output file, but we dont find the method stable, i tried and caused the dso to hanged and reboot indefinetely.. so i'll stick with HW modification. since HW12 with hacked dho800 to 900 still not work correctly on LA channel trigger with latest FW 1.2.2 i suspect the FW will check for HW number before activating or not activating LA trigger. ymmv.
-
... That's from the DHO5000. Looks like the same AFE's they're putting in the 1000/4000 line.
Comparing the noise performance of the MSO5000 and the DHO series 12 bit scopes, that's not very likely.
-
Hello guys!
I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?
glad to hear from you in PM and here... currently we are using rigol_vendor_bin from zelea2 to edit vendor.bin. with vendor.bin edited, other features such as 250MHz BW and 50Mpts memory, AFG and LA features automatically activated, no need extra *.lic anymore. although yours RigolTool can also still be applicable for the job, but its auto destruct now when we run it. its still very usefull for me as file explorer of DHO800, last time i pulled many file system using it.
and other update we were talking about your post is changing HW number read by hdcode_gpio.ko...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382392/#msg5382392 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382392/#msg5382392)
we managed to find where the config resistors are..
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5388278/#msg5388278 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5388278/#msg5388278)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389301/#msg5389301 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389301/#msg5389301)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389916/#msg5389916 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389916/#msg5389916)
but other guys (norbert.kiszka and Randy222 iirc) tried to do it in SW/FW by spoofing start_rigol_app.sh by disabling hdcode_gpio.ko and writing a number into its output file, but we dont find the method stable, i tried and caused the dso to hanged and reboot indefinetely.. so i'll stick with HW modification. since HW12 with hacked dho800 to 900 still not work correctly on LA channel trigger with latest FW 1.2.2 i suspect the FW will check for HW number before activating or not activating LA trigger. ymmv.
When we unload the hdcode KLM (comment that out in the start script), the hdcode_gpio device tree is not built upon reboot. This allows us to create a file in /dev that has file type in inode of "reg file". We then wrote "08" into that file. Something apparently reads that file because Scope app will then show "8" in it's About section. But this strategy does appear to be flawed, because the logic of using resistor sets on RK gpio pins does not make sense if a simple file is all that's needed, so the logic tells us they used resistor sets for a reason. The hdcode KLM reads the 4bit code from RK gpio pins (0 or 1 of the 4 gpio pins), it's a 4bit binary word that coverts to integer values, two values for 800's, and "8" for 900's. I believe two values for 800's to distinguish 2 vs 4ch without logic probe, and just "8" for 900's to distinguish it as a 4ch with logic probe. We also know there's another loaded KLM for gpio, and I gave the pin mappings in some post a few pages back, I just not sure what that KLM is used for. Others have done some work with the two sets of resistors that appear to impact HW # and scope functionality, or at least access to that functionality. On the 800's, chaning them from HW12 to HW8 appears to make no diff at all (changed only via the hdcode KLM stuff as mentioned).
As an aside, the auklet .so file, a rather large C++ compiled shared object file which has a ton of functions/routines and stuff in it, and is responsible for most of what you see in the scope gui, example is all of the calibration stuff is done via this .so file. One reason why I think it's so large is, it appears there's lots of code in the file that is not specifically related to 800-900 series. Lots of the Rigol coding appears to be carry-over or re-used code from other scopes over the years. Rigol appears to do poor job of code cleanup when re-using previous code. There's a lot of rerences to 'DS' scopes in the code that runs on 800-900. As example, it's easy to see how the DS1074's have morphed into the DHO800-900.
-
... That's from the DHO5000. Looks like the same AFE's they're putting in the 1000/4000 line.
Comparing the noise performance of the MSO5000 and the DHO series 12 bit scopes, that's not very likely.
I wasn't comparing the noise performance. That would be silly.
Allow me to rephrase; Since Rigol is using their custom ASIC front ends(RT1642IQ) across the scope lineup, and there are obvious differences in cooling design, I would be curious to know if there's a measurable difference between the common cooled and individually cooled models.
-
... That's from the DHO5000. Looks like the same AFE's they're putting in the 1000/4000 line.
Comparing the noise performance of the MSO5000 and the DHO series 12 bit scopes, that's not very likely.
I wasn't comparing the noise performance. That would be silly.
Allow me to rephrase; Since Rigol is using their custom ASIC front ends(RT1642IQ) across the scope lineup, and there are obvious differences in cooling design, I would be curious to know if there's a measurable difference between the common cooled and individually cooled models.
I guess what TurboTom was saying is: Considering that the noise performance of those two scopes is so different, it appears unlikely that they use the same front-end amplifier.
Do we know for sure that the RT1642IQ is used in both scopes? There might be teardown photos from the MSO5000 with the heatsinks removed?
-
... That's from the DHO5000. Looks like the same AFE's they're putting in the 1000/4000 line.
Comparing the noise performance of the MSO5000 and the DHO series 12 bit scopes, that's not very likely.
I wasn't comparing the noise performance. That would be silly.
Allow me to rephrase; Since Rigol is using their custom ASIC front ends(RT1642IQ) across the scope lineup, and there are obvious differences in cooling design, I would be curious to know if there's a measurable difference between the common cooled and individually cooled models.
I guess what TurboTom was saying is: Considering that the noise performance of those two scopes is so different, it appears unlikely that they use the same fron-end amplifier.
Do we know for sure that the RT1642IQ is used in both scopes? There might be teardown photos from the MSO5000 with the heatsinks removed?
I'm not sure that it's the same AFE in the 5000. Teardown pics didn't get that detailed. The 1000s and 4000s are the exact same part tho'.
The input path looks very similar on the MSO5000, but the 50 Ohm and coupling relays aren't present in the AFE section pix, so I'm confused. I was hoping some of the long timers here could shed some light on the subject.
-
Hello guys!
I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?
Hey there. Looks like your Q was answered... I just wanted to thank you for your early work here in the forums, and welcome you back. Cheers!
-
The input path looks very similar on the MSO5000, but the 50 Ohm and coupling relays aren't present in the AFE section pix, so I'm confused.
The MSO5000 does not have internal 50 Ohm termination (which is a bit of a miss for a 350 MHz scope). That feature was reserved for the higher-end MSO7000.
I could not find any photos of the MSO5000's front-end "ASICs" without their heatsinks either, and no type designation. But I'm with TurboTom here: If the MSO5000 had the same front-end as the DHO scopes with their pretty decent noise levels, why would it be so notoriously noisy even for an 8-bit scope?
-
The input path looks very similar on the MSO5000, but the 50 Ohm and coupling relays aren't present in the AFE section pix, so I'm confused.
The MSO5000 does not have internal 50 Ohm termination (which is a bit of a miss for a 350 MHz scope). That feature was reserved for the higher-end MSO7000.
I could not find any photos of the MSO5000's front-end "ASICs" without their heatsinks either, and no type designation. But I'm with TurboTom here: If the MSO5000 had the same front-end as the DHO scopes with their pretty decent noise levels, why would it be so notoriously noisy even for an 8-bit scope?
For some reason I think we're talking about different subjects. The only noise I've mentioned is fan noise.
I was talking about thermal i.e., cooling design, and noticed the AFE parts on the 1000/4000/5000/7000 had different thermal solutions than the DHO8/900s, and shared the photo with the little heatsink poking through the shield, because @Randy222's comment about saving aluminum.
The whole thing made me think about how they're homogenizing the whole thermal design in the DHO800/900., and it makes me curious to separate the ADC/AFE thermally from the FPGA/SoC, since we don't have info for the analog parts.
-
For some reason I think we're talking about different subjects. The only noise I've mentioned is fan noise.
I was talking about thermal i.e., cooling design, and noticed the AFE parts on the 1000/4000/5000/7000 had different thermal solutions than the DHO8/900s, and shared the photo with the little heatsink poking through the shield, because @Randy222's comment about saving aluminum.
The whole thing made me think about how they're homogenizing the whole thermal design in the DHO800/900., and it makes me curious to separate the ADC/AFE thermally from the FPGA/SoC, since we don't have info for the analog parts.
I know that the discussion is about thermal management. The only reason TurboTom and I were bringing up (electronic) noise is to point out that the analog front ends in the MSO5000 and in the DHO series are probably rather different.
Hence the argument "look at those small AFE heatsinks in the MSO5000 -- the large heatsink in the DHO800 is probably transferring more heat to the AFE than cooling it" appears invalid, since the dissipated power of those rather different AFEs may also be rather different.
Somehow we did not get that argument across, and I promise this is the last time I will try. ;) But if you read back over the past handful of posts, you may realize that this is what Tom and I have been saying throughout, in four different ways...
-
@ebastler: You are far more patient than I am... ;)
-
Hence the argument "look at those small AFE heatsinks in the MSO5000 -- the large heatsink in the DHO800 is probably transferring more heat to the AFE than cooling it" appears invalid, since the dissipated power of those rather different AFEs may also be rather different.
i think the most important thing is thermal stability... 70°C dT 1°C is better than 50°C dT 10°C... larger heatsink can provide that... anyway, this thermal discussion is moot.
-
So I'm tweaking the webcontrol app. Decompiled, tweaked, rebuilt, signed (with a self-signed key), aligned, now trying to install.
attempt 1:
1|rk3399_rigol:/data/UserData/apk # pm install -r Webcontrol-rebuilt1-signed-aligned.apk
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]
ok, makes sense, since it's already installed. Uninstalling, trying again:
rk3399_rigol:/data/UserData/apk # pm uninstall com.rigol.webcontrol
Success
rk3399_rigol:/data/UserData/apk # pm install -r Webcontrol-rebuilt1-signed-aligned.apk
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]
wtf? okay, googled, apparently it needs the "--user 0" argument. Let's try:
1|rk3399_rigol:/data/UserData/apk # pm uninstall --user 0 com.rigol.webcontrol
Success
rk3399_rigol:/data/UserData/apk # pm install -r Webcontrol-rebuilt1-signed-aligned.apk
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]
??? ok maybe it's installed for user 1000 too? let's see:
1|rk3399_rigol:/data/UserData/apk # pm uninstall --user 1000 com.rigol.webcontrol
Failure [not installed for 1000]
nope.
Does being a system app imply that there's more to be done than just "pm uninstall"? The app isn't showing as installed by "cmd package list packages", but can still be inspected with "pm dump com.rigol.webcontrol", and I see the following in its output:
Packages:
Package [com.rigol.webcontrol] (75e2815):
userId=1000
sharedUser=SharedUserSetting{df4892 android.uid.system/1000}
What the hell else does it want?
Do I need to remove the respective apk under /system/app as well? I'm kinda hesitant to do it until I figure it out.
Webcontrol shouldn't be any different in this respect from com.rigol.scope -- what did you guys do to fully uninstall it before reinstalling your rebuilt and self-signed versions?
-
So I'm tweaking the webcontrol app. Decompiled, tweaked, rebuilt, signed (with a self-signed key), aligned, now trying to install.
1|rk3399_rigol:/data/UserData/apk # pm install -r Webcontrol-rebuilt1-signed-aligned.apk
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]
...
What the hell else does it want?
Do I need to remove the respective apk under /system/app as well? I'm kinda hesitant to do it until I figure it out.
Webcontrol shouldn't be any different in this respect from com.rigol.scope -- what did you guys do to fully uninstall it before reinstalling your rebuilt and self-signed versions?
You need to remove android:sharedUserId="android.uid.system" from the application manifest. This property in the manifest specifies that the application should be installed as a system application and run under the "system" account. But for this, the application must be signed with a system key.
Well, yes, when you install your self-signed application for the first time, you need to completely remove the native system one before installing it. But you have already done it :) In the future, when you update your application (with the same signature), you can simply update it without first deleting it.
-
You need to remove android:sharedUserId="android.uid.system" from the application manifest.
Nope, same thing:
rk3399_rigol:/data/UserData/apk # pm uninstall com.rigol.webcontrol
Success
rk3399_rigol:/data/UserData/apk # pm uninstall --user 0 com.rigol.webcontrol
Success
1|rk3399_rigol:/data/UserData/apk # cmd package list packages|grep rigol
package:com.rigol.launcher
package:com.rigol.scope
1|rk3399_rigol:/data/UserData/apk # pm install -r Webcontrol-rebuilt2-signed-aligned.apk
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]
1|rk3399_rigol:/data/UserData/apk # pm install -r --user 0 Webcontrol-rebuilt2-signed-aligned.apk
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]
This property in the manifest specifies that the application should be installed as a system application and run under the "system" account. But for this, the application must be signed with a system key.
Yes, but the error is not just about a key mismatch, it's about a key mismatch for an already installed app. Unless they reused that message or used poor wording, I think the system still thinks that the app is installed.
Here's the error I'm getting when I try to install the original apk:
1|rk3399_rigol:/data/UserData/apk # pm install Webcontrol.apk
Failure [INSTALL_FAILED_ALREADY_EXISTS: Attempt to re-install com.rigol.webcontrol without first uninstalling.]
So the system really does think that it's already installed. I need to add the "-r" argument (reinstall) to make it install it.
Well, yes, when you install your self-signed application for the first time, you need to completely remove the native system one before installing it. But you have already done it :) In the future, when you update your application (with the same signature), you can simply update it without first deleting it.
Well apparently I still haven't uninstalled it well enough.
Any more ideas? Renaming the Webcontrol directory and the apk in it in /system/app doesn't help either.
Do I need to reboot? I'm a bit afraid to do it without webcontrol being installed, since the rigol boot scripts are so fragile and can render the system unusable.
UPDATE: I rebooted the scope, and lo and behold!
rk3399_rigol:/data/UserData/apk # pm install Webcontrol-rebuilt2-signed-aligned.apk
Success
Now it seems to lack permissions to access framebuffer or whatever, even though I did add the following to /etc/permissions/platform.xml:
<system-user-whitelisted-app package="com.rigol.webcontrol" />
Did I miss something else?
...or maybe it's my changes that broke it. Will look at that tomorrow.
-
1|rk3399_rigol:/data/UserData/apk # pm install -r --user 0 Webcontrol-rebuilt2-signed-aligned.apk
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.webcontrol signatures do not match the previously installed version; ignoring!]
Do I need to reboot? I'm a bit afraid to do it without webcontrol being installed, since the rigol boot scripts are so fragile and can render the system unusable.
Don't use "--user 0" :)
Yes, you can safely reboot the oscilloscope after removing the webcontrol, it works without any problems.
Did you stop it running before deleting this application?
rk3399_rigol:/ # am force-stop com.rigol.launcher
rk3399_rigol:/ # am force-stop com.rigol.webcontrol
rk3399_rigol:/ # pm uninstall com.rigol.webcontrol
I will now try to re-sign and install this application myself.
-
Don't use "--user 0" :)
Yes it works without it.
Yes, you can safely reboot the oscilloscope after removing the webcontrol, it works without any problems.
Did you stop it running before deleting this application?
I've updated the post above -- yes a reboot fixed it and I was able to install the self-signed app. Nothing else worked, including the force-stop commands, which I did try at some point too (and I checked the process list to make sure that it wasn't running).
Now having what I think may be permission issues, despite the added line in /etc/permissions/platform.xml, and I'll debug this tomorrow, starting with installing a rebuilt apk without any changes except it being self-signed. Maybe it just needs another reboot btw so that the system sees the change in platform.xml -- I didn't try this. Hope it's this.
-
So I'm tweaking the webcontrol app. Decompiled, tweaked, rebuilt, signed (with a self-signed key), aligned, now trying to install.
A good hack would be to fix the screen resolution in the web control and screen recording, it seems to have DHO1000 resolution. The resolution is set in an HTML file which seems to be embedded in the .apk (or at least, I couldn't find it as a file on the internal disk).
Saving the screen as .png instead of .jpg would also be good. I don't know if a simple patch to change .jpg to .png would work.
-
Don't use "--user 0" :)
Yes it works without it.
Yes, you can safely reboot the oscilloscope after removing the webcontrol, it works without any problems.
Did you stop it running before deleting this application?
I've updated the post above -- yes a reboot fixed it and I was able to install the self-signed app. Nothing else worked, including the force-stop commands, which I did try at some point too (and I checked the process list to make sure that it wasn't running).
Now having what I think may be permission issues, despite the added line in /etc/permissions/platform.xml, and I'll debug this tomorrow, starting with installing a rebuilt apk without any changes except it being self-signed. Maybe it just needs another reboot btw so that the system sees the change in platform.xml -- I didn't try this. Hope it's this.
Everything worked out for me using the following algorithm:
1. Stopped the launcher and web control:
rk3399_rigol:/ # am force-stop com.rigol.launcher
rk3399_rigol:/ # am force-stop com.rigol.webcontrol
2. Uninstalled web control:
rk3399_rigol:/ # pm uninstall com.rigol.webcontrol
3. Remounted /system to RW:
rk3399_rigol:/ # mount -o rw,remount /system
4. Deleted the /system/app/Webcontrol directory
5. Rebooted the oscilloscope.
6. Installed a modified (simply disassembled and reassembled and signed) application.
Well, there are problems with access to system APIs - screen capture is impossible, which means neither remote control nor screenshots/screen recording work.
A good hack would be to fix the screen resolution in the web control and screen recording, it seems to have DHO1000 resolution. The resolution is set in an HTML file which seems to be embedded in the .apk (or at least, I couldn't find it as a file on the internal disk).
Saving the screen as .png instead of .jpg would also be good. I don't know if a simple patch to change .jpg to .png would work.
Yes, all server files are stored inside the webcontrol application.
-
A good hack would be to fix the screen resolution in the web control and screen recording, it seems to have DHO1000 resolution.
That's what I'm after.
The resolution is set in an HTML file which seems to be embedded in the .apk (or at least, I couldn't find it as a file on the internal disk).
Nah, html/js rely on what's being sent by the server, or at least they rely on that *too*, which remains to be seen. That the server pushes the picture with 1280x800 size is certain.
Saving the screen as .png instead of .jpg would also be good. I don't know if a simple patch to change .jpg to .png would work.
That may (or may not) be less than trivial. I'll check that once I get my modified apk to work at all.
-
By the way, the login/password for the "Network Settings" page is admin/rigol :)
-
I was able to take screenshots in .png, but remote control did not work, despite the fact that I inserted all the necessary permissions into the manifest (seemingly) and moved the application to /system/priv-app . One of the permissions needed for remote access is never granted to the application:
Requires MANAGE_MEDIA_PROJECTION in order to grant projection permission
And I haven't been able to do anything about it yet.
Plus there is no permission to implement touch events:
InputDispatcher: Asynchronous input event injection permission denied.
-
That the server pushes the picture with 1280x800 size is certain.
It's an HTML canvas with that size defined in the code.
-
InputDispatcher: Asynchronous input event injection permission denied.
Where are you seeing these logs?
-
So I made the scope unbootable when trying to make this damn app run under "system" user. I hate android for not letting me have full control over the device I own.
Anyway, is there any way to enter some recovery mode to mount a partition and change files? There's no network connection at this stage, and adb over USB isn't working either. In fact, there's no activity whatsoever when I connect the scope via the USB port on the rear to my computer, the computer doesn't see any new connected USB device at all.
I'm now going to take out the SD card and mount the partition manually in a card reader, but it'd be nice to be able to do this without taking the scope apart.
-
I hate android for not letting me have full control over the device I own.
I think you have already achieved far more control over the device than Rigol ever intended to give you. 8)
-
It's an HTML canvas with that size defined in the code.
There the video encoder itself is adjusted to a resolution of 1280x800.
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: Rkvpu_Enc_ComponentInit(1321): use vpuapi.
03-23 15:25:52.444 241 1640 E ROCKCHIP_VIDEO_ENC: ConvertOmxAvcLevelToAvcSpecLevel(1093): ConvertOmxAvcLevelToAvcSpecLevel: 512
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: Rkvpu_Enc_GetEncParams(1547): encode params init settings:
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: width = 1280
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: height = 800
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: bitRate = 4096000
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: framerate = 30
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: format = 10
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: enableCabac = 0,
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: cabacInitIdc = 0,
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: intraPicRate = 59,
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: profileIdc = 66,
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: levelIdc = 31,
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: rc_mode = 1,
Where are you seeing these logs?
logcat command in console :)
So I made the scope unbootable when trying to make this damn app run under "system" user. I hate android for not letting me have full control over the device I own.
Anyway, is there any way to enter some recovery mode to mount a partition and change files? There's no network connection at this stage, and adb over USB isn't working either. In fact, there's no activity whatsoever when I connect the scope via the USB port on the rear to my computer, the computer doesn't see any new connected USB device at all.
I'm now going to take out the SD card and mount the partition manually in a card reader, but it'd be nice to be able to do this without taking the scope apart.
Oh, fellow failure :)) I also killed the loading of the oscilloscope by trying to make the application system using the modperms.sh script from Randy222 :))
Then I connected to the hardware UART and through it in the console I restored the original file /system/etc/permissions/platform.xml
-
So I've been failing so far.
None of the following in platform.xml seems to work:
<assign-permission name="android.permission.INJECT_EVENTS" uid="u0_a32" />
<assign-permission name="android.permission.MANAGE_MEDIA_PROJECTION" uid="u0_a32" />
<assign-permission name="android.permission.ACCESS_SURFACE_FLINGER" uid="u0_a32" />
<system-user-whitelisted-app package="com.rigol.webcontrol" />
The app still lacks the required permissions. It runs under the "u0_a32" user. I still think there must be a way to make it run under "system" user, maybe by first installing it as a non-system app and then converting to system.
...but wait, the com.rigol.scope app needed system permissions to take screenshots as well, right? How was that fixed? Was the whitelist entry in platform.xml enough for it?
p.s. I fixed the boot issues by mounting the respective fs on the SD card directly in a card reader. Yes I had to remove the back lid of the scope and take the card out for this. Maybe I will inspect the boot failure logs more closely and try to understand what I did wrong, and maybe there's a way to do it right.
What I did is I tried to change the user id to 1000 in whatever files (and they were appops.xml, packages.list, packages.xml under /data/system) contained the "10032" user id that the app was installed for as a non-system app.
-
...but wait, the com.rigol.scope app needed system permissions to take screenshots as well, right? How was that fixed? Was the whitelist entry in platform.xml enough for it?
For screenshots (READ_FRAME_BUFFER and ACCESS_SURFACE_FLINGER permissions), just move the application to /system/priv-app . This is obviously not enough for the MANAGE_MEDIA_PROJECTION permission. I do not know why it is so.
We would need to make our own Android assembly, signed with our own key. Then we will have full control over system applications. But I have no experience and no knowledge in assembling Android or Linux systems :(
-
ok I've given up for now. Nothing of what I have tried was successful.
It seems to be clear where in the decompiled sources the image/video size is set -- the trick is to search for hex representation of the numbers, that is, 0x320 and 0x500, and change them to 0x258 and 0x400, and likewise for the 1920x1080 video recording. However, it's impossible to test it until we find a way to run the recompiled app as a system app with all the permissions required to use system api.
-
It seems to be clear where in the decompiled sources the image/video size is set -- the trick is to search for hex representation of the numbers, that is, 0x320 and 0x500, and change them to 0x258 and 0x400, and likewise for the 1920x1080 video recording. However, it's impossible to test it until we find a way to run the recompiled app as a system app with all the permissions required to use system api.
Well it's easy to find. Encoder parameters are configured in the file smali\com\rigol\webcontrol\VideoEncoder\VideoEncoderManager.smali in the setUpByJson function. It parses the JSON received from the web page with the encoder parameters - image size and quality. The size is compared with three options - 1080, 720 and 480 (vertical). If one of these options is sent in the parameter, then the corresponding size is set, otherwise the default size is set to 1280x800. And since the value of this parameter is sent as zero (from the script on the assets\control.html page), the encoder is set to the default size. So you just need to change these default values in the screenshot.
-
That's exactly what I did. That part is easy. The difficult part is to run this apk with the system user permissions.
-
The difficult part is to run this apk with the system user permissions.
Yes, I don’t have any ideas on this either.
-
So I made the scope unbootable when trying to make this damn app run under "system" user. I hate android for not letting me have full control over the device I own.
Anyway, is there any way to enter some recovery mode to mount a partition and change files? There's no network connection at this stage, and adb over USB isn't working either. In fact, there's no activity whatsoever when I connect the scope via the USB port on the rear to my computer, the computer doesn't see any new connected USB device at all.
I'm now going to take out the SD card and mount the partition manually in a card reader, but it'd be nice to be able to do this without taking the scope apart.
You could connect a USB -> Serial to the internal console pins and then drop to a shell then get root via SU. That'll let you do quite a bit of stuff.
I know that doesn't help with having to open your case., sorry.
-
You could connect a USB -> Serial to the internal console pins and then drop to a shell via SU. That'll let you do quite a bit of stuff., YMMV.
I know that doesn't help with having to open your case., sorry.
Yeah, and once I open the case, it's much easier (for me) to access the SD card directly.
-
I know that doesn't help with having to open your case., sorry.
Yeah, and once I open the case, it's much easier (for me) to access the SD card directly.
Yeah, I hear ya. I got so tired of opening my case, I use kapton tape and one screw to hold my DHO closed now. I might expand my SD card slot 'fin hack' for access to those console pins..
-
ok I've given up for now.
Of course I had not, whom was I trying to fool?
I knew it was possible.
I managed to disable the signature verification subsystem altogether.
Now we can run anything signed with an arbitrary key with system privileges.
1. Pull /system/framework to a computer
2. Deodex the /system/framework/services.jar component (I used https://github.com/jareddantis/simple-deodexer, as it's simple indeed, and I didn't want to install any full blown IDE: it deodexed everything, but we only need services.jar)
3. Decompile the deodexed services.jar using e.g. apktool
4. Modify the methods responsible for signature verification in smali/com/android/server/pm/PackageManagerService.smali, basically we need to make the methods compareSignatures, compareSignaturesCompat, and compareSignaturesRecover unconditionally return zero, credits to https://xdaforums.com/t/guide-superusermod-disable-signature-verification-nougat-mm.3549952/, the new code to put there can be found there as well.
5. Recompile services.jar using apktool.
6. Replace the original /system/framework/services.jar with the patched version, remove /system/framework/oat/arm64/services.odex, and, just in case, remove the respective cache file in /data/dalvik-cache/arm64
7. Reboot (I actually had to power cycle the scope)
8. Ready to install and use self-signed apps. For webcontrol I had to not only pm uninstall it (with both "--user 0" and without it), but also remove it from /system/app/Webcontrol.
Needless to say, keep a backup of the sd card image handy and know how to restore (by mounting the respective fs and restoring individual files -- usually there's no need to restore the whole image) when things go wrong.
Now, my webcontrol streams a 1024x600 picture, as it should. Picture quality is better than the original 1280x800, but it's still lossy: I believe it uses jpeg/mpeg or some other lossy compression algorithm. I will try (and encourage others to try) to find where it may be configured to have a proper lossless picture. Stream rate is currently below 2 Mbit/s, so there's plenty of headroom not to require any compression at all.
Attached (as zip, to avoid the forum's image format conversion) is an example of the webcontrol stream. You can clearly see the compression artifacts.
p.s. we may not need the stock webcontrol app at all. I haven't searched yet, but there must be better android apps for screen sharing which we could potentially install.
-
Yeah, I hear ya. I got so tired of opening my case I use kapton tape and one screw now.
so dont close it.. screw in some pcb spacers on 2 bottom enclosure's screws, those will make as a good stand... ;D
-
I managed to disable the signature verification subsystem altogether.
Now we can run anything signed with an arbitrary key with system privileges.
1. Pull /system/framework to a computer
2. Deodex the /system/framework/services.jar component (I used https://github.com/jareddantis/simple-deodexer, as it's simple indeed, and I didn't want to install any full blown IDE: it deodexed everything, but we only need services.jar)
3. Decompile the deodexed services.jar using e.g. apktool
4. Modify the methods responsible for signature verification in smali/com/android/server/pm/PackageManagerService.smali, basically we need to make the methods compareSignatures, compareSignaturesCompat, and compareSignaturesRecover unconditionally return zero, credits to https://xdaforums.com/t/guide-superusermod-disable-signature-verification-nougat-mm.3549952/, the new code to put there can be found there as well.
5. Recompile services.jar using apktool.
6. Replace the original /system/framework/services.jar with the patched version, remove /system/framework/oat/arm64/services.odex, and, just in case, remove the respective cache file in /data/dalvik-cache/arm64
7. Reboot (I actually had to power cycle the scope)
8. Ready to install and use self-signed apps. For webcontrol I had to not only pm uninstall it (with both "--user 0" and without it), but also remove it from /system/app/Webcontrol.
Wow that's cool! We should also think about automating this process with a script :)
Now, my webcontrol streams a 1024x600 picture, as it should. Picture quality is better than the original 1280x800, but it's still lossy: I believe it uses jpeg/mpeg or some other lossy compression algorithm. I will try (and encourage others to try) to find where it may be configured to have a proper lossless picture. Stream rate is currently below 2 Mbit/s, so there's plenty of headroom not to require any compression at all.
No, the video is encoded in H.264/AVC format. You can try giving it a higher stream rate.
p.s. we may not need the stock webcontrol app at all. I haven't searched yet, but there must be better android apps for screen sharing which we could potentially install.
I tried the scrcpy recommended everywhere, but it slows down when the picture starts to change frequently across most of the screen - for example, when a signal with a large amplitude jumps without synchronization.
-
I hate android for not letting me have full control over the device I own.
The Android system is designed to prevent rootkits and other forms of subversion. :)
-
The Android system is designed to prevent rootkits and other forms of subversion. :)
I prefer that the OS only provides the means, but lets me decide what to prevent. Never ever should software authors impose their thinking on the user or think that they know better what's good for the user.
-
I killed the system on my oscilloscope by replacing the /system/framework/services.jar file with a modified one :) Now the system is in an endless reboot loop.
shapirus and the modified system.jar does not need to be signed? Or is it still necessary?
-
I killed the system on my oscilloscope by replacing the /system/framework/services.jar file with a modified one :) Now the system is in an endless reboot loop.
shapirus and the modified system.jar does not need to be signed? Or is it still necessary?
No it doesn't. It worked just fine for me. Probably your decompilation/patching/rebuilding steps weren't quite right, or the tools you used.
Here's my version (patched), you can decompile and run diff to compare against yours, or try to use it, as it must be portable: all scopes are the same (within the same fw version). Don't forget that the respective odex file has to be removed.
md5sum: 84b5e4323b782f43c347d5d842f00a31
sha256sum: 12853ad6308327e6273d7c77bd5751f3bad15413a28c5c670a6714044a4703ce
-
No it doesn't. It worked just fine for me. Probably your decompilation/patching/rebuilding steps weren't quite right, or the tools you used.
Here's my version (patched), you can decompile and run diff to compare against yours, or try to use it, as it must be portable: all scopes are the same (within the same fw version). Don't forget that the respective odex file has to be removed.
md5sum: 84b5e4323b782f43c347d5d842f00a31
sha256sum: 12853ad6308327e6273d7c77bd5751f3bad15413a28c5c670a6714044a4703ce
Understood. Thanks for the file, I'll try it later when I get some sleep :)
And I’ll try to understand what went wrong with my modification. Maybe some tool really didn’t work like that - deodex or apktool.
-
An interesting thing is that control.html accepts query parameters "size" and "rate", which can take the values of "1080p" or "720p", and "Extra", "High", or "Low", respectively, and they do get passed to the respective websocket server that does the actual streaming when the websocket session starts, and there is some logic in the server code to switch size and bit rate accordingly (below the lines where the default size constants are set), but for some reason it does not work at all -- it always sets the values to default. Maybe I will try to untangle the spaghetti of conditions and gotos in the smali code to see why, but before that I'll try to change the default bitrate to different values to see if that works at all.
The above was referring to web control, which shares the scope screen interactively.
As far as the screen recording goes, I think we already have the highest bitrate it can do. The encoder itself supports bitrate values up to 40000000 (10000000 was another value that I saw somewhere), but if I change the default value of 6000000 to a higher one, it doesn't result in the increase of the output file size or the video quality. If I make it lower, however (say 500000), then yes the quality drops, so we know that this parameter isn't ignored.
-
I think I figured out my problem. True, at the same time I killed the system boot a couple of times :)
For some reason, apktool was disassembling services.jar with the “do not compress dex” parameter set. After I removed this parameter from apktool.yml everything worked.
An interesting thing is that control.html accepts query parameters "size" and "rate", which can take the values of "1080p" or "720p", and "Extra", "High", or "Low", respectively, and they do get passed to the respective websocket server that does the actual streaming when the websocket session starts, and there is some logic in the server code to switch size and bit rate accordingly (below the lines where the default size constants are set), but for some reason it does not work at all -- it always sets the values to default. Maybe I will try to untangle the spaghetti of conditions and gotos in the smali code to see why, but before that I'll try to change the default bitrate to different values to see if that works at all.
If you look in debug, you can see that the "size" and "rate" parameters are passed with the value null , so the server code sets these values by default.
I also thought about this point: with changes in services.jar described in the link, it turns out that checking application privileges is completely disabled. That is, any application can receive any permission. This may not be very good, I think. We need to think about how to make sure that permissions are granted only to our modified applications. You can try making a condition based on the application class name, for example. If this is com.rigol.scope or com.rigol.webcontrol, then the signature verification returns an unconditional positive result, otherwise let the standard verification be carried out.
As far as the screen recording goes, I think we already have the highest bitrate it can do. The encoder itself supports bitrate values up to 40000000 (10000000 was another value that I saw somewhere), but if I change the default value of 6000000 to a higher one, it doesn't result in the increase of the output file size or the video quality. If I make it lower, however (say 500000), then yes the quality drops, so we know that this parameter isn't ignored.
This is the maximum bitrate. Probably, during the compression process, the bitrate simply does not reach maximum values above 6,000,000. In general, the codec settings should have other parameters that are responsible for the quality of the compressed video stream, most likely because of them the bitrate does not rise high.
-
Hello guys!
I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?
glad to hear from you in PM and here... currently we are using rigol_vendor_bin from zelea2 to edit vendor.bin. with vendor.bin edited, other features such as 250MHz BW and 50Mpts memory, AFG and LA features automatically activated, no need extra *.lic anymore. although yours RigolTool can also still be applicable for the job, but its auto destruct now when we run it. its still very usefull for me as file explorer of DHO800, last time i pulled many file system using it.
and other update we were talking about your post is changing HW number read by hdcode_gpio.ko...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382392/#msg5382392 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382392/#msg5382392)
we managed to find where the config resistors are..
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5388278/#msg5388278 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5388278/#msg5388278)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389301/#msg5389301 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389301/#msg5389301)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389916/#msg5389916 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389916/#msg5389916)
but other guys (norbert.kiszka and Randy222 iirc) tried to do it in SW/FW by spoofing start_rigol_app.sh by disabling hdcode_gpio.ko and writing a number into its output file, but we dont find the method stable, i tried and caused the dso to hanged and reboot indefinetely.. so i'll stick with HW modification. since HW12 with hacked dho800 to 900 still not work correctly on LA channel trigger with latest FW 1.2.2 i suspect the FW will check for HW number before activating or not activating LA trigger. ymmv.
Thank you for your concluding answers, and I'm glad you can continue the discussion. In the new firmware, Key.data has been renamed RKey.data, so I don't know if the encryption method of vendor.bin files has also changed, I took a rough look at the lib library algorithm in the apk a few days ago and changed a lot. As for the hdcode_gpio.ko method, I don't recommend using the method of disabling the driver and then spoofing it through other programs, I prefer to refactor hdcode_gpio.ko, this file implementation is very simple, the standard RK3399 driver is written, if anyone has the time and energy can try.
-
Hello guys!
I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?
Hey there. Looks like your Q was answered... I just wanted to thank you for your early work here in the forums, and welcome you back. Cheers!
Thank you for your concern, recently the time is more tight, so there is very little online time, I started to try to rebuild the new hdcode.ko kernel driver very early, but found that it is not so easy, the main thing is to restore RIGOL's RK3399 development environment, especially the kernel version must be consistent with the goal, otherwise even if you compile it, there will be errors. I'll take the time to try again, cheers friends! :-+
-
Yes, after changing the resolution of the recorded video screen and increasing the bitrate, the video quality has seriously increased.
For comparison, here are screenshots from a video recorded in the original web control and in the modified one. I also attached a screenshot with information about the videos. After the modification, the bitrate almost doubled, despite the fact that the number of pixels in the image decreased by almost four times. And the frame rate also increased.
In the video from the original webcontrol, compression artifacts are very noticeable, the picture is unclear. In the video from the modified web control, the compression is almost imperceptible, the picture is very clear.
P.S. Links to the videos themselves:
original - https://drive.google.com/file/d/12yizmAu-FhmWpCYIUk34HciwkJnIht-e/view?usp=sharing
modified - https://drive.google.com/file/d/1e6QkCdBJsKthzY1yc9gNk0e04Attq5by/view?usp=sharing
-
Did you only change the 1920 and 1080 constants or something else too?
-
Did you only change the 1920 and 1080 constants or something else too?
Changed these constants and bitrate from 6000000 to 10000000 in the file smali\com\rigol\webcontrol\server\PrintWSS.smali (lines 697-701).
-
That's what I did, too. Strangely enough, it did not change the bitrate for me -- however, I don't exactly remember what it was at 1920x1080 (only remember it was roughly ~7MB for a 20-sec recording). I changed the size first, and then I tried different bitrates at 1024x600: there was no difference in the resulting file's bitrate with the constant set to anywhere from 3000000 to 10000000.
-
That's what I did, too. Strangely enough, it did not change the bitrate for me -- however, I don't exactly remember what it was at 1920x1080 (only remember it was roughly ~7MB for a 20-sec recording). I changed the size first, and then I tried different bitrates at 1024x600: there was no difference in the resulting file's bitrate with the constant set to anywhere from 3000000 to 10000000.
Initially it was 6,000,000. Which picture did you try it on? It’s just that in the absence of noise, when the channel trace is a straight line with little noise, there won’t be a high bitrate when encoding video, because the picture is almost static. To achieve the maximum bitrate, you need to change as much of the screen area as possible in each frame; this is why I brought out the noise on such a scale.
-
By the way, in remote screen control, an increase in bitrate has a very noticeable effect on video quality. The screenshots show the quality of the picture in its original form (average bitrate over the network - 9 Mbps) and after increasing the bitrate (average bitrate over the network - 19 Mbps).
But only when connected to cable Ethernet. Through Wi-Fi, my network flow is limited to 4.3 Mbps, it seems that this is the limit of the Wi-Fi connection itself.
-
By the way, in remote screen control, an increase in bitrate has a very noticeable effect on video quality. The screenshots show the quality of the picture in its original form (average bitrate over the network - 9 Mbps) and after increasing the bitrate (average bitrate over the network - 19 Mbps).
But only when connected to cable Ethernet. Through Wi-Fi, my network flow is limited to 4.3 Mbps, it seems that this is the limit of the Wi-Fi connection itself.
Or, the limitation may be imposed by Rigol devs enabling more data over physical ETH.?? I posted a question suggesting this when @shapirus brought it up a couple nights ago, but deleted it after a short while, in favor of not interrupting you and shapirus' "flow".
p.s., Wow, those artifacts are definitely a reason to increase the quality output. eww.
Exciting stuff guys! Nice bit of progress..
-
By the way, in remote screen control, an increase in bitrate has a very noticeable effect on video quality. The screenshots show the quality of the picture in its original form (average bitrate over the network - 9 Mbps) and after increasing the bitrate (average bitrate over the network - 19 Mbps).
But only when connected to cable Ethernet. Through Wi-Fi, my network flow is limited to 4.3 Mbps, it seems that this is the limit of the Wi-Fi connection itself.
Or, the limitation may be imposed by Rigol devs enabling more data over physical ETH.?? I posted a question suggesting this when @shapirus brought it up a couple nights ago, but deleted it after a short while, in favor of not interrupting you and shapirus' "flow".
p.s., Wow, those artifacts are definitely a reason to increase the quality output. eww.
Exciting stuff guys! Nice bit of progress..
I don't know why the developers did this. The bitrate is calculated as width*height*K. The K coefficient depends on the specified quality and can be from 1.5 to 5. Thus, for a 1024x600 screen, the maximum bitrate is 1024*600*5=3072000, which is obviously very small. I set the bitrate to a constant 10000000 and this significantly improved the video quality in remote control.
-
By the way, in remote screen control, an increase in bitrate has a very noticeable effect on video quality. The screenshots show the quality of the picture in its original form (average bitrate over the network - 9 Mbps) and after increasing the bitrate (average bitrate over the network - 19 Mbps).
But only when connected to cable Ethernet. Through Wi-Fi, my network flow is limited to 4.3 Mbps, it seems that this is the limit of the Wi-Fi connection itself.
Or, the limitation may be imposed by Rigol devs enabling more data over physical ETH.?? I posted a question suggesting this when @shapirus brought it up a couple nights ago, but deleted it after a short while, in favor of not interrupting you and shapirus' "flow".
p.s., Wow, those artifacts are definitely a reason to increase the quality output. eww.
Exciting stuff guys! Nice bit of progress..
I don't know why the developers did this. The bitrate is calculated as width*height*K. The K coefficient depends on the specified quality and can be from 1.5 to 5. Thus, for a 1024x600 screen, the maximum bitrate is 1024*600*5=3072000, which is obviously very small. I set the bitrate to a constant 10000000 and this significantly improved the video quality in remote control.
Interesting. I'm familiar with bpp in the formula for video encoding/streaming etc., but the K is new to me. Is the color depth part of the K coefficient, specified elsewhere, or is it not needed in this context?
Sorry, just a curious musing. Don't let me distract if you have other stuff to do.
-
Interesting. I'm familiar with bpp in the formula for video encoding/streaming etc., but the K is new to me. Is the color depth part of the K coefficient, specified elsewhere, or is it not needed in this context?
Sorry, just a curious musing. Don't let me distract if you have other stuff to do.
No, this is just a certain coefficient, a multiplier for calculating the bitrate. It is not related to anything technical. It’s just that Rigol’s engineers decided that to calculate the bitrate in low quality they would multiply the number of pixels by 1.5, in high quality by 4, and in extra quality by 5. I called this number - 1.5, 4 or 5 - coefficient K :)
-
Hi, I wonder if anyone can help me out, when I run "run_DHO_Tools", I get an error "adb: error: remote object '/rigol/data/Key.data' does not exist". I'm connected to the scope remotely using a wifi dongle. Anyone else had this issue, or know how to cure it?
adb: error: remote object '/rigol/data/Key.data' does not exist
go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO8
SCPI format: ':SYSTem:OPTion:INSTall'
options: [RLU BW7T10]
error open Key.data: The system cannot find the file specified.
exit status 10
-
Hi, I wonder if anyone can help me out, when I run "run_DHO_Tools", I get an error "adb: error: remote object '/rigol/data/Key.data' does not exist". I'm connected to the scope remotely using a wifi dongle. Anyone else had this issue, or know how to cure it?
adb: error: remote object '/rigol/data/Key.data' does not exist
go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO8
SCPI format: ':SYSTem:OPTion:INSTall'
options: [RLU BW7T10]
error open Key.data: The system cannot find the file specified.
exit status 10
You can try RKey.data.
-
Hi, I wonder if anyone can help me out, when I run "run_DHO_Tools", I get an error "adb: error: remote object '/rigol/data/Key.data' does not exist". I'm connected to the scope remotely using a wifi dongle. Anyone else had this issue, or know how to cure it?
adb: error: remote object '/rigol/data/Key.data' does not exist
go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO8
SCPI format: ':SYSTem:OPTion:INSTall'
options: [RLU BW7T10]
error open Key.data: The system cannot find the file specified.
exit status 10
In the firmware, starting with version 00.01.02.00.00 (or 00.01.02.00.02, I don’t remember exactly), Rigol changed the coding of options. Now instead of the Key.data file there is an RKey.data file and other keys, so the old key generation tools do not work. Use this tool - https://github.com/zelea2/rigol_vendor_bin from Zelea, it is adapted for new firmware.
-
Hi, I wonder if anyone can help me out, when I run "run_DHO_Tools", I get an error "adb: error: remote object '/rigol/data/Key.data' does not exist". I'm connected to the scope remotely using a wifi dongle. Anyone else had this issue, or know how to cure it?
adb: error: remote object '/rigol/data/Key.data' does not exist
go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO8
SCPI format: ':SYSTem:OPTion:INSTall'
options: [RLU BW7T10]
error open Key.data: The system cannot find the file specified.
exit status 10
In the firmware, starting with version 00.01.02.00.00 (or 00.01.02.00.02, I don’t remember exactly), Rigol changed the coding of options. Now instead of the Key.data file there is an RKey.data file and other keys, so the old key generation tools do not work. Use this tool - https://github.com/zelea2/rigol_vendor_bin from Zelea, it is adapted for new firmware.
Hi, thanks for the info, on the page it says "Precompiled Linux, Windows and Android ARM64 binaries are available from 'Releases' section", but there doesn't appear to be a "releases" section on his page.
Is it possible to roll back to 1.01? I don't remember hacking being this difficult on the 1054z.
Rather annoying, I followed the Retro Channel's video carefully, which suggested to update to any version beyond 1.00, I was on 1.01 already, if I'd ignored that section it would have made my life so much easier. That guy needs to add a card to that video saying not to go beyond 1.01, it'll totally snooker you otherwise lol
Double annoying is that I was all set to buy a 924, but someone pointed out that I could simply get an 804, hack it up to the 924 and save a chunk of money, like it was an easy thing to hack. I could have afforded the 924, but can't afford to get the 924 after already spending out on the 804 which would then sit redundant. Frustrating! lol
-
Hi, thanks for the info, on the page it says "Precompiled Linux, Windows and Android ARM64 binaries are available from 'Releases' section", but there doesn't appear to be a "releases" section on his page.
There: https://github.com/zelea2/rigol_vendor_bin/releases/tag/Rigol
-
Hi, thanks for the info, on the page it says "Precompiled Linux, Windows and Android ARM64 binaries are available from 'Releases' section", but there doesn't appear to be a "releases" section on his page.
Rather annoying, I followed the Retro Channel's video carefully, which suggested to update to any version beyond 1.00, I was on 1.01 already, if I'd ignored that section it would have made my life so much easier. That guy needs to add a card to that video saying not to go beyond 1.01, it'll totally snooker you otherwise lol
Double annoying is that I was all set to buy a 924, but someone pointed out that I could simply get an 804, hack it up to the 924 and save a chunk of money, like it was an easy thing to hack. I could have afforded the 924, but can't afford to get the 924 after already spending out on the 804 which would then sit redundant. Frustrating! lol
TBH, It's not super clear where the "download" link is on the GitHub page.. It's on the right side.
[attachimg=1 width=400]
Your best chance of success is to follow the detailed step-by-step guide in @AndyBig's signature ^^ above your post.
-
Frustrating! lol
first thing you should do.... backup your original sd card that came from factory. this is most critical step if you want anything to be reversible... but behold... you still can copy the hubertyoung's 924Ss FW from first page and get a 924s scope, with later steps to do hardware modification scattered in this thread. but keep your original sd card even if already upgraded to 1.01 or later somewhere else safe. like mine, i put it here (see attached) along with various images of original and upgraded path branch saved in my PC, ymmv.
-
Your best chance of success is to follow the detailed step-by-step guide in @AndyBig's signature ^^ above your post.
I followed the instructions by AndyBig carefully, but a couple of things didn't go quite the same; there was no data folder added, instead it added a bunch of files directly inside the "platform-tools" directory where adb was launched from. so I copied the two files to the "rigol_vendor_bin" directory and and wrote the command: rigol_vendor_bin.exe -M DHO924S in that folder as instructed, but now have this error:
-
I followed the instructions by AndyBig carefully, but a couple of things didn't go quite the same; there was no data folder added, instead it added a bunch of files directly inside the "platform-tools" directory where adb was launched from. so I copied the two files to the "rigol_vendor_bin" directory and and wrote the command: rigol_vendor_bin.exe -M DHO924 in that folder as instructed, but now have this error:
The solution is right there in the error message and subsequent suggestion. The Powershell shell does not search the current directory for an EXE specified on the command line, same as a bash shell. You have to specify the current direction with .\<exe name>.
-
i think this is where knowledge on "Command Prompt" run as admin... or batch file (*.bat) is valuable... ymmv.
-
I must be blind. All working now, just running a calibration, but seems I now have a DHO924S masquerading as a 804.
Thank you, and a huge thanks to everyone who helped me to get this working :)
***** ADDENDUM *****
Something interesting just happened. Adding the 924'S' version showed the function generator up, but when I went into it, there menu was there, but no waveform, so I'm going to assume the function generator is hardware based. To cut a long story short, it (temporarily) bricked my scope (no waveform, menu in the bottom left was not responding, etc.). I double pressed the default button on the front of the scope and it came back to life, but my 804, that was transformed to a 924S was now masquerading as a 814. So it seems that hitting the Default button twice reverts the scope to an 814. So basically the hack is not permanent. Anyone else found this?
-
Oh, fellow failure :)) I also killed the loading of the oscilloscope by trying to make the application system using the modperms.sh script from Randy222 :))
Then I connected to the hardware UART and through it in the console I restored the original file /system/etc/permissions/platform.xml
Which permission(s) did you add to the Template?
-
ok I've given up for now.
Of course I had not, whom was I trying to fool?
I knew it was possible.
I managed to disable the signature verification subsystem altogether.
Now we can run anything signed with an arbitrary key with system privileges.
1. Pull /system/framework to a computer
2. Deodex the /system/framework/services.jar component (I used https://github.com/jareddantis/simple-deodexer, as it's simple indeed, and I didn't want to install any full blown IDE: it deodexed everything, but we only need services.jar)
3. Decompile the deodexed services.jar using e.g. apktool
4. Modify the methods responsible for signature verification in smali/com/android/server/pm/PackageManagerService.smali, basically we need to make the methods compareSignatures, compareSignaturesCompat, and compareSignaturesRecover unconditionally return zero, credits to https://xdaforums.com/t/guide-superusermod-disable-signature-verification-nougat-mm.3549952/, the new code to put there can be found there as well.
5. Recompile services.jar using apktool.
6. Replace the original /system/framework/services.jar with the patched version, remove /system/framework/oat/arm64/services.odex, and, just in case, remove the respective cache file in /data/dalvik-cache/arm64
7. Reboot (I actually had to power cycle the scope)
8. Ready to install and use self-signed apps. For webcontrol I had to not only pm uninstall it (with both "--user 0" and without it), but also remove it from /system/app/Webcontrol.
Needless to say, keep a backup of the sd card image handy and know how to restore (by mounting the respective fs and restoring individual files -- usually there's no need to restore the whole image) when things go wrong.
Now, my webcontrol streams a 1024x600 picture, as it should. Picture quality is better than the original 1280x800, but it's still lossy: I believe it uses jpeg/mpeg or some other lossy compression algorithm. I will try (and encourage others to try) to find where it may be configured to have a proper lossless picture. Stream rate is currently below 2 Mbit/s, so there's plenty of headroom not to require any compression at all.
Attached (as zip, to avoid the forum's image format conversion) is an example of the webcontrol stream. You can clearly see the compression artifacts.
p.s. we may not need the stock webcontrol app at all. I haven't searched yet, but there must be better android apps for screen sharing which we could potentially install.
Nice.
So with these edits, you installed a self-signed Sparrow APK with shared_user of System in the manifest (with no other edits in the APK) and it installs and runs as "system" ?
Can you share a "ps |grep scope"
-
Nice.
So with these edits, you installed a self-signed Sparrow APK with shared_user of System in the manifest (with no other edits in the APK) and it installs and runs as "system" ?
Can you share a "ps |grep scope"
Nah I didn't touch Sparrow yet. I only modified Webcontrol, but otherwise yes, everything's exactly as you wrote.
rk3399_rigol:/ # ps|grep webcontrol
system 1254 233 1626840 84304 SyS_epoll_ 7649856b84 S com.rigol.webcontrol
rk3399_rigol:/ # ps -n|grep webcontrol
1000 1254 233 1626840 84304 SyS_epoll_ 7649856b84 S com.rigol.webcontrol
There should be no difference with Sparrow or any other app.
Regarding the security implications, yes, of course, you wouldn't want to disable signature verification on an arbitrary android device. In this case, however, provided that the scope isn't reachable from public network, and the local network (as well as anyone who can have physical access to it) is trusted, it's a "who cares?" situation.
-
So it seems that hitting the Default button twice reverts the scope to an 814. So basically the hack is not permanent. Anyone else found this?
No matter how much I pressed the "Default" button, my 814, converted to 914, remained 914 :)
Which permission(s) did you add to the Template?
I don’t remember exactly now. It seems that I left the same ones that were in your script, but I also duplicated them for the webcontrol application, changing the script accordingly.
So with these edits, you installed a self-signed Sparrow APK with shared_user of System in the manifest (with no other edits in the APK) and it installs and runs as "system" ?
Can you share a "ps |grep scope"
Yes, that's right. After hacking using the method discovered by Shapirus, self-signed applications with shared_user of System in the manifest are normally installed and launched under UID 1000. Modified applications like Sparrow and Webcontrol work for me this way.
-
Adding the 924'S' version showed the function generator up, but when I went into it, there menu was there, but no waveform, so I'm going to assume the function generator is hardware based. To cut a long story short, it (temporarily) bricked my scope (no waveform, menu in the bottom left was not responding, etc.).
function generator and logic analyzer button down there are hardware based. maybe you want to read through dho800/900 teardown thread and this hack thread to get the whole idea... and maybe you also would like to follow my threads about development of the 2 "replica" hardwares... ymmv.
https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot (https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot)
https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800) (https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800))
and a bit of advice. if possible dont mess with interfaces randomly, the situation will be "undefined" (i would not dare) and unlikely have anything to do with any of the dho800/900 hack discussions, it will be on your own adventure ;) cheers.
-
I remember someone decompiling libscope-auklet.so into what looked like C code -- any hint what was the software that could do that? I tried objump from linux binutils (binutils-aarch64-linux-gnu), but it produces raw assembler code which is on a harder side to understand, and besides it crashes halfway through. Need something else.
-
I remember someone decompiling libscope-auklet.so into what looked like C code -- any hint what was the software that could do that? I tried objump from linux binutils (binutils-aarch64-linux-gnu), but it produces raw assembler code which is on a harder side to understand, and besides it crashes halfway through. Need something else.
IDA, Ghidra.
-
I remember someone decompiling libscope-auklet.so into what looked like C code -- any hint what was the software that could do that? I tried objump from linux binutils (binutils-aarch64-linux-gnu), but it produces raw assembler code which is on a harder side to understand, and besides it crashes halfway through. Need something else.
IDA, Ghidra.
Both will generate what I'd call "pseudo" C code for the purposes of easier analysis than assembler. Don't expect to be able to edit and recompile the complete app from it, though.
-
It's C++, not C.
-
It's interesting. I tried to search where the preset probe ratio multipliers could be defined and couldn't find them neither in Sparrow.apk, nor in libscope-auklet.so. I thought it would have been an array of values, but no, at least, nothing matching the numbers I searched for.
Has anyone found them yet?
It's so lame that it doesn't allow to simply enter an arbitrary multiplier.
update: LOL, as usual, I found it *literally* 1 minute after I posted this. It's in sparrow.apk. Will try to add the multiplier I needed tomorrow. It appears to be in smali_classes2/com/rigol/scope/cil/ServiceEnum$ProbeX.smali, and they define floating point numbers as strings, unless it's decorative and the actual numbers are defined elsewhere.
-
I decided to write here about how much money it cost me to upgrade the DHO814 model to DHO924...(full hardware compliance)... All components were purchased on aliexpress.... The amount is indicated along with the cost of delivery to the Czech Republic...The memory chips installed were all three identical K4B4G1646E
3× K4B4G1646E-BMA - 10€
2× TP1282 - 6€
1× MPM3630 - 2€
1× DC3 IDC JTAG-50Pin - 0.29€
Total Cost. 18.29€😉😉😉😉
-
The memory chips installed were all three identical K4B4G1646E
But have we ever found an answer to the question of what those extra memory chips were needed for?
-
and they define floating point numbers as strings, unless it's decorative and the actual numbers are defined elsewhere.
These value strings are simply strings to display in the select list. For real configuration, completely different values are passed to the libscope-auklet.so library. I can’t say for sure right now, but it seems there are something like enum values, which are passed to the library API when the divisor changes.
-
I must be blind. All working now, just running a calibration, but seems I now have a DHO924S masquerading as a 804.
Thank you, and a huge thanks to everyone who helped me to get this working :)
***** ADDENDUM *****
Something interesting just happened. Adding the 924'S' version showed the function generator up, but when I went into it, there menu was there, but no waveform, so I'm going to assume the function generator is hardware based. To cut a long story short, it (temporarily) bricked my scope (no waveform, menu in the bottom left was not responding, etc.). I double pressed the default button on the front of the scope and it came back to life, but my 804, that was transformed to a 924S was now masquerading as a 814. So it seems that hitting the Default button twice reverts the scope to an 814. So basically the hack is not permanent. Anyone else found this?
Thanks for sharing, this is a very interesting observation! I can confirm the presence of freezes several months ago (I no longer remember the firmware version). Just like you, I modified my vendor.bin to 924S. As far as I can remember now, pressing the “defolt” button helped me get out of the “stupor”... This all happened with AWG turned on. Unfortunately, I cannot confirm or deny the change in the model name to “814”; this was a very long time ago.... Since then, I have made many additions to my scope (see my post above), including moving the configuration resistor, to change HW....I tried to force the hang now and it didn't work! The question that interested me is whether this behavior is caused by the lack of missing components on the board (possibly ddr chips), or is it due to something else?..... mmmmm, this interested me extremely..... Thank you for sharing your experience!!!
-
and why i didnt hang my scope by activating, running, playing, bode plotting with AFG? (before and after resistor config hack, DDR3L always missing until today) afaik there is no feedback signal on my replica AFG board to tell the scope or FW that the board presents or not.
-
and why i didnt hang my scope by activating, running, playing, bode plotting with AFG? (before and after resistor config hack, DDR3L always missing until today) afaik there is no feedback signal on my replica AFG board to tell the scope or FW that the board presents or not.
The question that interested me is whether this behavior is caused by the lack of missing components on the board (possibly ddr chips), or is it due to something else?..... mmmmm, this interested me extremely..... Thank you for sharing your experience!!!
I wonder if this is where the system is looking for the hardware AFG...(From @s2084's modified HW8)
[attachimg=1 width=300]
Does anyone have the console log output from a real 924S?
Reason I ask:
[attachimg=2 width=230] HW12 [attachimg=3 width=230] HW8 -Mod
-
Any idea how/where the pull-down menu (the one that's opened with win-N using a keyboard) is disabled? Is it somewhere in the system or is it in com.rigol.scope? I wonder if it's possible to reenable it.
-
No, this is definitely not in com.rigol.scope, because even if you disable autorun of com.rigol.scope, this top curtain still does not open by swiping from the launcher.
-
No, this is definitely not in com.rigol.scope, because even if you disable autorun of com.rigol.scope, this top curtain still does not open by swiping from the launcher.
Might (or not) be in com.rigol.launcher, as it has this in its AndroidManifest.xml:
<uses-permission android:name="android.permission.DISABLE_STATUS_BAR"/>
But I've not been able to find any code that uses this permission so far.
-
Might (or not) be in com.rigol.launcher, as it has this in its AndroidManifest.xml:
And it doesn’t work with the launcher autorun disabled either :)
-
I wonder if this is where the system is looking for the hardware AFG...(From @s2084's modified HW8)
(Attachment Link)
Does anyone have the console log output from a real 924S?
Reason I ask:
(Attachment Link) HW12 (Attachment Link) HW8 -Mod
i managed to get an "older" version of IDA and disassemble afg_gpio.ko... looks like another can of worm of 5 bits config resistor? but am struggling to learn ARM ASM code here... not sure whats those "0x7A" to "0x7E" representing... i need to sleep now, hopefully will continue this afternoon :palm:...
-
I wonder if this is where the system is looking for the hardware AFG...(From @s2084's modified HW8)
(Attachment Link)
Does anyone have the console log output from a real 924S?
Reason I ask:
(Attachment Link) HW12 (Attachment Link) HW8 -Mod
i managed to get an "older" version of IDA and disassemble afg_gpio.ko... looks like another can of worm of 5 bits config resistor? but am struggling to learn ARM ASM code here... not sure whats those "0x7A" to "0x7E" representing... i need to sleep now, hopefully will continue this afternoon :palm:...
The following is the logical pseudocode for a few key functions:
int gpio_afg_init()
{
set GPIO_122 Label is afg__in1
set GPIO_122 Output Low
set GPIO_123 Label is afg__in2
set GPIO_123 Output Low
set GPIO_124 Label is afg__in3
set GPIO_124 Output Low
set GPIO_125 Label is afg__in4
set GPIO_125 Output Low
set GPIO_126 Label is afg__in5
set GPIO_126 Output Low
}
ssize_t gpio_afg_drv_write(file *file, const int8 *buf, size_t len, loff_t *f_pos)
{
1.copy user data to core.
_arch_copy_from_user(*DB,*buf ,len);
2.write GPIO value.
write GPIO_122(afg__in1) is DB[0] bit value.
write GPIO_123(afg__in2) is DB[1] bit value.
write GPIO_124(afg__in3) is DB[2] bit value.
write GPIO_125(afg__in4) is DB[3] bit value.
write GPIO_126(afg__in5) is DB[4] bit value.
}
ssize_t gpio_afg_drv_read(file *file, int8 *buf, size_t len, loff_t *f_pos)
{
1.read DB from GPIO value.
read DB[0] from GPIO_122(afg__in1) bit value.
read DB[1] from GPIO_123(afg__in2) bit value.
read DB[2] from GPIO_124(afg__in3) bit value.
read DB[3] from GPIO_125(afg__in4) bit value.
read DB[4] from GPIO_126(afg__in5) bit value.
2. copy core DB to user.
_arch_copy_to_user(buf, DB,len);
}
The following is the logical pseudocode for a few key functions.
It is still unclear how the RK3399 GPIO_122~GPIO_126 corresponds to the pins of the AD9744 DAC, and you need to explore. Good luck!
-
The following is the logical pseudocode for a few key functions.
It is still unclear how the RK3399 GPIO_122~GPIO_126 corresponds to the pins of the AD9744 DAC, and you need to explore. Good luck!
I'm pretty sure that the AFG board gets the 14 bit DAC data from the FPGA.
My Hypothesis: The GPIO's you identified might be to/from AFG board. (to set gain, offsets, etc..?)
-
The following is the logical pseudocode for a few key functions.
It is still unclear how the RK3399 GPIO_122~GPIO_126 corresponds to the pins of the AD9744 DAC, and you need to explore. Good luck!
I'm pretty sure that the AFG board gets the 14 bit DAC data from the FPGA. The GPIO's you identified might be for setting gain, offsets, etc..?
I imagine that afg_gpio.ko driver just provides module status detection, or other configurations, and the specific 14-bit data is transmitted through the FPGA, since it only has 5-bit data.
-
The following is the logical pseudocode for a few key functions:
so the RK3399 pins 122-126 are set as output, and then later stage gpio_afg_drv_read read them as if they are input? hmm confusing... ;D
The following is the logical pseudocode for a few key functions.
It is still unclear how the RK3399 GPIO_122~GPIO_126 corresponds to the pins of the AD9744 DAC, and you need to explore. Good luck!
I'm pretty sure that the AFG board gets the 14 bit DAC data from the FPGA. The GPIO's you identified might be for setting gain, offsets, etc..?
My Hypothesis: The GPIO's you identified might be to/from AFG board. (to set gain, offsets, etc..?)
I imagine that afg_gpio.ko driver just provides module status detection, or other configurations, and the specific 14-bit data is transmitted through the FPGA, since it only has 5-bit data.
see attached my attempt rev eng afg pins interface. so far there are only 3 unknown pins UP0, UP1, UP4 (pin 10 on smaller interface and pin 22 and 28 on larger interface) red arrowed in pcb picture and highlighted green on the connector diagram. i didnt bother to check to where they are connected. probably to FPGA, or RK, or to other passive/semi components before going to either one of them. the ultimate reference (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5051812/#msg5051812) provided by you still unclear about them, UP0 seems near some inductor, resistors and cap network, not sure what it is, on my UTG962 AWG, there is some kind of protection mechanism to cut off output in case AFG output is exposed to excessive external DC, so i'm guessing UP0 is probably it.
anyway lets assume just for sake of simplicity those 3 are connected directly to RK and being read or written by afg_gpio.ko, there are still 2 GPIOs unknown... so.. fwiw ymmv...
nomenclature:
DB = DAC digital input
CLK = DAC clock
REL = relays control
AFG OFFSet and AMPLitude signal will only present when we install the 2 missing opamps TP1282 (i used OPA2350). later finding.. pin 28 will be low for 4ms each time bode plot feature is started and then goes back high forever until bode plot is restarted again...
-
The following is the logical pseudocode for a few key functions:
so the RK3399 pins 122-126 are set as output, and then later stage gpio_afg_drv_read read them as if they are input? hmm confusing... ;D
It's probably more like RK_out <--> AFG_in
With RK and AFG being their own IC's.
They probably just labled the gpio pins to designate their use, like "these pins goto AFG in"
You can read the state of any gpio state, does not matter of they they are in or out pins, or digital or analog.
If someting reads the pin states (digi), then that's usually to verify what they are because it's possible some parts of the code somewhere could have changed them.
-
The following is the logical pseudocode for a few key functions:
so the RK3399 pins 122-126 are set as output, and then later stage gpio_afg_drv_read read them as if they are input? hmm confusing... ;D
You can read the state of any gpio state, does not matter of they they are in or out pins, or digital or analog.
If someting reads the pin states (digi), then that's usually to verify what they are because it's possible some parts of the code somewhere could have changed them.
ok, so if reading is only to verify output pin's state (whether its outputtting HI or LO), then its not to verify whether AFG HW exists or not. correct? btw, i managed to rev eng the pin interface is due to FPGA is outputting valid AFG signal naked on bright day even if no AFG HW presents, and i didnt manage to hang anything during the process. so maybe people who reported hanging their dso while playing with AFG GUI did something else to cause the hang? maybe they activate bode plot? and hence dso struggled to find signal on CH1 and CH2?
-
In testing, was able to uninstall system app com.rigol.scope, and reinstall it (Sparrow.apk), the OEM stuff.
I did edit, repack, resign, and zipalign.
pm install did not complain about any signature stuff, but I did get a failed install due to missing "NativeLibs". I do believe I can fix this problem by editing manifest to not call for "extractNativeLibs".
I need to investigate further.
I'm hitting this exact issue now, when trying to install a rebuilt Sparrow.apk:
Failure [INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2]
Apparently it should go well if I set android:extractNativeLibs="true" in AndroidManifest.xml (https://github.com/iBotPeaches/Apktool/issues/1626). Is that what you did to fix it or there's some other way?
It looks somewhat strange.
update: adding the "-p" argument to zipalign fixed the issue. As usual, found the solution 1 minute after posting, but hopefully this will help someone who comes here from a search results page.
-
Having some progress
[attachimg=1]
Alas, the added multipliers don't work (yet). Might be because they really require a modification of the .so, after all, which is also suggested by the fact that changing those floating point numbers presented as strings does not lead to the change of the actual multipliers, unfortunately (but then what are those strings used for?)
-
It's interesting. I tried to search where the preset probe ratio multipliers could be defined and couldn't find them neither in Sparrow.apk, nor in libscope-auklet.so. I thought it would have been an array of values, but no, at least, nothing matching the numbers I searched for.
Has anyone found them yet?
It's so lame that it doesn't allow to simply enter an arbitrary multiplier.
update: LOL, as usual, I found it *literally* 1 minute after I posted this. It's in sparrow.apk. Will try to add the multiplier I needed tomorrow. It appears to be in smali_classes2/com/rigol/scope/cil/ServiceEnum$ProbeX.smali, and they define floating point numbers as strings, unless it's decorative and the actual numbers are defined elsewhere.
I'm interested in probe magnification modifications, maybe I can see if there's any information available in .so.
-
Apparently it should go well if I set android:extractNativeLibs="true" in AndroidManifest.xml (https://github.com/iBotPeaches/Apktool/issues/1626). Is that what you did to fix it or there's some other way?
Yes, that's exactly how I fixed it. But thanks for your method, I think it is more correct.
Alas, the added multipliers don't work (yet). Might be because they really require a modification of the .so, after all, which is also suggested by the fact that changing those floating point numbers presented as strings does not lead to the change of the actual multipliers, unfortunately (but then what are those strings used for?)
To set or save the value of the probe divider, it is not the value of the divider that is sent to .so, but its serial number from 0 (corresponds to 0.0001) to 30 (corresponds to 50000.0). Therefore, adding some other values to the application will not do anything without modifying the .so library.
-
To set or save the value of the probe divider, it is not the value of the divider that is sent to .so, but its serial number from 0 (corresponds to 0.0001) to 30 (corresponds to 50000.0).
I figured that much too, but haven't yet found where those numbers are accepted and processed in the .so. There are some functions having the "ProbeRatio" substring in their names, but ghidra did not disassemble their bodies -- in the .c file it produced they seem to be calling themselves, which is weird. Maybe the actual code should be inside them, maybe not.
p.s. even if we figure that out, then recompiling the .so is going to be a much more difficult job than the same with .apk, and I'm not sure if even possible.
-
To set or save the value of the probe divider, it is not the value of the divider that is sent to .so, but its serial number from 0 (corresponds to 0.0001) to 30 (corresponds to 50000.0).
I figured that much too, but haven't yet found where those numbers are accepted and processed in the .so. There are some functions having the "ProbeRatio" substring in their names, but ghidra did not disassemble their bodies -- in the .c file it produced they seem to be calling themselves, which is weird. Maybe the actual code should be inside them, maybe not.
p.s. even if we figure that out, then recompiling the .so is going to be a much more difficult job than the same with .apk, and I'm not sure if even possible.
The conversion of the divisor from the index to the real value occurs in libscope-auklet.so in the function CApiVertical::ApiChannel_SetProbeRatio (see screenshot). The index value is taken from address 0xd203f8, where there is an array of 31 16-byte values (see screenshot). Each value represents 8 bytes of real value and 8 bytes of decimal power. For example, the first index contains the 16-byte value 0x0100000000000000FCFFFFFF00000000, which means 1 (0100000000000000) multiplied by 10 to the power of -4 (FCFFFFFF00000000).
The real address of this array in the libscope-auklet.so file is 0x00C1F3F8 (see screenshot).
-
At least it should be possible to replace certain multipliers that I don't need (like 50000x) with those I do need by editing the .so directly.
But if we find a way to recompile it, then it'll open a whole lot of new possibilities. If not from C code, then at least it should be possible to recompile it from assembler.
p.s. what did you use for decompilation? Ghidra gave me only this:
void _ZN12CApiVertical24ApiChannel_SetProbeRatioEj(void)
{
_ZN12CApiVertical24ApiChannel_SetProbeRatioEj();
return;
}
either it couldn't do its job, or I didn't use it the right way.
-
At least it should be possible to replace certain multipliers that I don't need (like 50000x) with those I do need by editing the .so directly.
But if we find a way to recompile it, then it'll open a whole lot of new possibilities. If not from C code, then at least it should be possible to recompile it from assembler.
No, it’s almost impossible to recompile the library :( But you can change existing values in it. If you really bother, I think you can even enter a user-specified divisor value, but this is a lot of work both in .so and in .app .
-
p.s. what did you use for decompilation? Ghidra gave me only this:
void _ZN12CApiVertical24ApiChannel_SetProbeRatioEj(void)
{
_ZN12CApiVertical24ApiChannel_SetProbeRatioEj();
return;
}
either it couldn't do its job, or I didn't use it the right way.
That's what I used Ghidra :) There are two functions with the same name, one is in your code quote, and it already calls the second, a screenshot of which I showed.
IDA, by the way, also decompiles quite well. In some places even better than Ghidra.
-
The following is the logical pseudocode for a few key functions:
so the RK3399 pins 122-126 are set as output, and then later stage gpio_afg_drv_read read them as if they are input? hmm confusing... ;D
You can read the state of any gpio state, does not matter of they they are in or out pins, or digital or analog.
If someting reads the pin states (digi), then that's usually to verify what they are because it's possible some parts of the code somewhere could have changed them.
ok, so if reading is only to verify output pin's state (whether its outputtting HI or LO), then its not to verify whether AFG HW exists or not. correct? btw, i managed to rev eng the pin interface is due to FPGA is outputting valid AFG signal naked on bright day even if no AFG HW presents, and i didnt manage to hang anything during the process. so maybe people who reported hanging their dso while playing with AFG GUI did something else to cause the hang? maybe they activate bode plot? and hence dso struggled to find signal on CH1 and CH2?
Well, in kernel debug folder there's the gpio stuff, it holds states of pins, but only info captured from a KLM. Some pins not listed are still addressable from cli, but I just don't know what the outcome is by changing pin states, a bad change could perhaps cause damage.
If RK pin is RK_out and they go to AFG_in pins, that might suggest the RK is configuring the AFG using five 1bit words, or maybe one 5bit word. Not sure how the functionality is. Maybe a 5bit word is a scaling factor from 1 to 32*16*8*4*2 ? If an 800 series runs as a 900, do you get an AFG freq panel to punch in a freq? Sure, it won't do anything but you can monitor the gpio pins to see if there's any relevance.
-
If RK pin is RK_out and they go to AFG_in pins, that might suggest the RK is configuring the AFG using five 1bit words, or maybe one 5bit word. Not sure how the functionality is. Maybe a 5bit word is a scaling factor from 1 to 32*16*8*4*2 ?
another possibility is those 5 pins are connected to FPGA to tell FPGA what to do to output to AFG, not directly to AFG module.
If an 800 series runs as a 900, do you get an AFG freq panel to punch in a freq? Sure, it won't do anything but you can monitor the gpio pins to see if there's any relevance.
i spent a fair amount of time doing this, you can see in attachments earlier. but anything in between my finger press on GUI and those exposed interface pins are a black box to me, in other word i dont know. so i dont want to speculate one of many possibilities. but based on souldevelop's report, those 5 pins are configured as output, so i have a doubt those 5 pins checking are responsible to detect AFG presence or not and cause the dso to hang. thats the matter of discussion right now imho. whatever those 5 pins do, as long as its not for status checking (AFG presence), is not my concern atm. ymmv.
ps: for the past few many hours, i tried to install everything (android studio, apktool, jadx decompiler, bluestacks) to look for what the FW does, where the FW calls to the afg_gpio.ko but not yet success, all i see are bunch of java import and export nonsense stuffs :palm:
-
Does anyone know if it's possible to calibrate/fine-tune the internal reference oscillator? There is some "ADC Clock" in the Debug section of the Utility menu, but it doesn't seem to affect anything.
I know I shouldn't have, but I bought a GPSDO and now I know that this extra "1" is there, and it will never be possible to forget about it now.
[attachimg=1]
-
ps: for the past few many hours, i tried to install everything (android studio, apktool, jadx decompiler, bluestacks) to look for what the FW does, where the FW calls to the afg_gpio.ko but not yet success, all i see are bunch of java import and export nonsense stuffs :palm:
The .apk application does not access the hardware directly, but only through the libscope-auklet.so library.
I know I shouldn't have, but I bought a GPSDO and now I know that this extra "1" is there, and it will never be possible to forget about it now.
I think that this is an error in the master quartz oscillator and nothing can be done about it.
-
ps: for the past few many hours, i tried to install everything (android studio, apktool, jadx decompiler, bluestacks) to look for what the FW does, where the FW calls to the afg_gpio.ko but not yet success, all i see are bunch of java import and export nonsense stuffs :palm:
The .apk application does not access the hardware directly, but only through the libscope-auklet.so library.
yeah, jadx cant open *.so, only ida, but asm @ and # thing, link or reference? or whatever they are not helping either. i dont see how Sparrow.apk (mostly GUI related i see and "this" class) correlates, links or make calls to libscope-auklet.so anyway, whats obvious is... i'm not an android nut... maybe i need more time.. here just filling time while waiting for my pcb to arrive...
-
yeah, jadx cant open *.so, only ida,
jadx only decompiles JVM applications. Shared libraries (.so) are native code, typically written in lower level languages like C/C++ or even ASM.
-
Ghidra is quite good! analyzing code took very long time, but its worth it, iirc yesterday i wasnt patient enough i didnt realize what it was... i think AFG presence check not yet implemented (HasAFG) and "read afg state" only return the 5 bits pin output of 0x7A-0x7E... i think i'm starting to catching up here 8) to be a code digger... just a show off! :P
-
i dont see how Sparrow.apk (mostly GUI related i see and "this" class) correlates, links or make calls to libscope-auklet.so anyway, whats obvious is... i'm not an android nut... maybe i need more time.. here just filling time while waiting for my pcb to arrive...
Interaction with the library is implemented in the file com\rigol\scope\cil\API.java. All interaction is reduced to requesting and recording values of different types by identifiers.
For example, this is how the maximum bandwidth of an oscilloscope is requested:
API.getInstance().UI_QueryInt32(11, MessageID.MSG_APP_UTILITY_BW);
This is how a line with the system version is requested:
API.getInstance().UI_QueryStr(11, MessageID.MSG_MISC_SYSTEM_VERSION);
This is how the G1 (AFG) indicator on the panel lights up and goes out:
API.getInstance().UI_PostInt32Int32(11, MessageID.MSG_APP_UTILITY_LED, ServiceEnum.PanelLed.G1_LED_WHITE.value1, 1);
API.getInstance().UI_PostInt32Int32(11, MessageID.MSG_APP_UTILITY_LED, ServiceEnum.PanelLed.G1_LED_WHITE.value1, 0);
And this is how the command is given to turn off the hardware:
API.getInstance().UI_PostInt32(11, MessageID.MSG_HARDWARE_POWERDOWN, 1);
And so on. There are many hundreds of these identifiers.
-
what is the firmware version out from factory nowadays for dho800 and dho900? is older key.data still relevant for rigol_vendor_bin? or is there newer rigol_vendor_bin that works on RKey.data?
-
or is there newer rigol_vendor_bin that works on RKey.data?
It's been around for a long time.
-
or is there newer rigol_vendor_bin that works on RKey.data?
It's been around for a long time.
because the rigol_vendor_bin i downloaded and applied few weeks ago works on key.data.. i'll look again for newer instruction. thanks.
-
or is there newer rigol_vendor_bin that works on RKey.data?
It's been around for a long time.
because the rigol_vendor_bin i downloaded and applied few weeks ago works on key.data.. i'll look again for newer instruction. thanks.
https://github.com/zelea2/rigol_vendor_bin/releases
-
or is there newer rigol_vendor_bin that works on RKey.data?
It's been around for a long time.
because the rigol_vendor_bin i downloaded and applied few weeks ago works on key.data.. i'll look again for newer instruction. thanks.
https://github.com/zelea2/rigol_vendor_bin/releases
Read the post for a long time. I found this rigol_vendor_bin github repo work fine. But I can't find where it is from? how the hack process is found ? For example how he know the 2 xxtea keys and how he know the vendor.bin is encryped by twice?
-
A little preview
[attach=1]
https://www.youtube.com/watch?v=OXJZxY9YVwE (https://www.youtube.com/watch?v=OXJZxY9YVwE)
-
Read the post for a long time. I found this rigol_vendor_bin github repo work fine. But I can't find where it is from? how the hack process is found ? For example how he know the 2 xxtea keys and how he know the vendor.bin is encryped by twice?
The author disassembled and examined the application and libraries. A lot of hard work indeed.
-
A little preview
(Attachment Link)
Wow that looks exciting. Not just the FFT averaging app, but all the changes to have a launcher etc.
Care to give a bit more details as to what it's all about?
-
A little preview
(Attachment Link)
Wow that looks exciting. Not just the FFT averaging app, but all the changes to have a launcher etc.
Care to give a bit more details as to what's it's all about?
Adding launchers is old news. :)
I'm more interested in how to get to the home screen without a keyboard.
It looks like he's swiping down from the top of the screen...
-
A little preview
(Attachment Link)
Adding launchers is old news. :)
I'm more interested in how to get to the home screen without a keyboard.
It looks like he's swiping down from the top of the screen...
I didn't add a launcher. I kept the original Rigol to avoid screen flickering on startup. I use an accessibility app.
-
Quote from: mrisco on Today at 06:35:17 (https://www.eevblog.com/forum/index.php?topic=393928.msg5437889#msg5437889)
>Quote from: Fungus on Today at 04:41:45 (https://www.eevblog.com/forum/index.php?topic=393928.msg5437688#msg5437688)
>Quote from: mrisco on Today at 03:23:05 (https://www.eevblog.com/forum/index.php?topic=393928.msg5437577#msg5437577)A little preview
> (Attachment Link) (https://www.eevblog.com/forum/index.php/topic,393928.msg5437577.html#msg5437577)
Adding launchers is old news. :)
I'm more interested in how to get to the home screen without a keyboard.
It looks like he's swiping down from the top of the screen...
I didn't add a launcher. I kept the original Rigol to avoid screen flickering on startup. I use an accessibility app.
Maybe you stop talking hints and provide reasonable description?
-
Im instal Button Master and assigned the location of the floating button. Getting out without a keyboard is not a problem https://4pda.to/forum/index.php?showtopic=1075359&ysclid=lur7plmx2b728125086
-
Getting out without a keyboard is not a problem
I can do it with ADB, too, but can you do it without?
-
Im instal Button Master and assigned the location of the floating button. Getting out without a keyboard is not a problem https://4pda.to/forum/index.php?showtopic=1075359&ysclid=lur7plmx2b728125086
There are many options, also "Back button" and "Zone Edge Launcher". I recomend Zone Edge that is what I'm using, this application avoids to change the Rigol launcher.
-
What does ADB have to do with it? Install the Button Master application, it has a floating button option. Turn it on so that it is displayed on all applications. On the Rigol app as well. And set it up so that by clicking it it sends you to the desktop of the launcher or wherever you need.
-
I feel that with the app it is easier to see the peaks, what do you think?
-
Yeah that's how it should have been implemented from the start, at least as far as indicating the values right on the peaks goes.
Averaging is nice to have, too.
-
I uploaded the preview apk temporary here: https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/tag/FFTAVG0.3.2
Until I can find a better place.
-
Hello all, this is my first post on the forum.
I am about to buy my firts digital ociloscope ;D.
i was about to pull the triger on the DHO814, but i have seen that is possible to hack the DHO804 to basically be a DHO814 (100Mhz BW) and more Memory Depth.
My question is:
Still possible to hack brand news (up to date firmware and software) DHO804 ?
if still possible i will get a DHO804 new, from rigol store on aliexpress.
Another question is:
Is worth to buy the DHO814, does it have any thing else (excluding the bigger bandwith) that the DHO804 dont have ?
Actualy the cost diference betwews the two aren't much, but if they are the same i dont wanna to burn money.
DHO804 - BRL 2.488,92 - 490 USD
DHO814 - BRL 2.754,04 - 542 USD
Aliexpress listing say that the 2 models have the same memory depth (25Mpts).
So i probably would do the hack on the DHO814 (if i buy) to get the extra memory depth.
-
...
Another question is:
Is worth to buy the DHO814, does it have any thing else (excluding the bigger bandwith) that the DHO804 dont have ?
Actualy the cost difference betwews the two aren't much, but if they are the same i dont wanna to burn money.
DHO804 - BRL 2.488,92 - 490 USD
DHO814 - BRL 2.754,04 - 542 USD
..
Check in Alibaba, I bought from them and they sent me the DHO804 for a very good price with DHL shipping included.
-
Still possible to hack brand news (up to date firmware and software) DHO804 ?
Yes, you can easily convert your 804 into an 814 and then further increase the memory bandwidth and depth with options.
-
My question is:
Still possible to hack brand news (up to date firmware and software) DHO804 ?
if still possible i will get a DHO804 new, from rigol store on aliexpress.
Yes,
Is worth to buy the DHO814
No.
-
Is worth to buy the DHO814, does it have any thing else (excluding the bigger bandwith) that the DHO804 dont have ?
the price for "DHO814 100MHz" sticker and man hour to upgrade 804 to 814 is worth $52, if you dont want DIY like some people, yes its worth it to get DHO814 ;D
-
I feel that with the app it is easier to see the peaks, what do you think?
Great job! Is it easy / possible to add a frequency log scale?
-
Great job! Is it easy / possible to add a frequency log scale?
I think that it is possible but maybe not easy. Currently the app takes the FFT results from the MATH channel, if I convert to a logarithm scale maybe the plot will lose frequency resolution. Other possible solution is to take the data directly from the acquisition channel (CHn) and do the LFFT calculus inside of the plugin app. If the loss of resolution is acceptable (just visual change of data representation) then it might be easy.
Another possible solution is if the plugin can control the FFT parameters and sweep the frequency range and then stitch the data together, but I haven't explored controlling the oscilloscope from the plugin yet.
-
Great job! Is it easy / possible to add a frequency log scale?
I think that it is possible but maybe not easy. Currently the app takes the FFT results from the MATH channel, if I convert to a logarithm scale maybe the plot will lose frequency resolution. Other possible solution is to take the data directly from the acquisition channel (CHn) and do the LFFT calculus inside of the plugin app. If the loss of resolution is acceptable (just visual change of data representation) then it might be easy.
Another possible solution is if the plugin can control the FFT parameters and sweep the frequency range and then stitch the data together, but I haven't explored controlling the oscilloscope from the plugin yet.
In most cases ( so far I know) it is just a visual change. A logical consequence will be that the data points in the low range will be further apart.
-
In most cases ( so far I know) it is just a visual change. A logical consequence will be that the data points in the low range will be further apart.
If you want, I opened a discussion site in the Github to not polute this thread with a specific topic: https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions
-
First I want to say thanks to: mrisco, AndyBig, Fungus and Mechatrommer for replying my question :).
I ordered the DHO804 from AliExpress.
The main reason is because "RIGOL Store" on AliExpress actually has some stock already in my country, so I won't need to pay any import fees.
The import fees here are insane; if I have to pay the imports fees, the total cost would be 2x oscilloscopes or more :-//, and on the local market
(ignoring the AliExpress "RIGOL Store"), the DHO804 cost something around 6500 BRL / 1280 USD
Now I am waiting anxiously to get my new toy :D
-
I really like the app.
Had some time to look into a TCXO 10MHz 0.1ppm module.
Worked out great:
[attach=1]
I feel that with the app it is easier to see the peaks, what do you think?
-
Does anybody know if it's possible to make the HDMI output a second screen (not a mirror)?
-
Hello everybody!
I recently purchased a Rigol DHO804 oscilloscope. Everything works fine, I haven’t noticed any bugs yet, but..
This question is: Why do the phases of the signals between channels 1 and 2 diverge? The higher the signal frequency, the greater the discrepancy.
My generator produces a maximum sine wave of 70 MHz, so at 70 MHz the phase difference is 20%, and it doesn’t matter between which channels, between 1 and 2, between 1 and 3, between 1 and 4!
But a nuance was noticed that between 2 and 3, 3 and 4, 2 and 4 channels there is no such phase discrepancy, only relative to 1 channel and any other.
Can someone check on their oscillation whether this is the same nonsense or not?
p.s. Activated 50 MB of memory and 100 MHz frequency.
-
Why do the phases of the signals between channels 1 and 2 diverge? The higher the signal frequency, the greater the discrepancy.
My generator produces a maximum sine wave of 70 MHz, so at 70 MHz the phase difference is 20%, and it doesn’t matter between which channels, between 1 and 2, between 1 and 3, between 1 and 4!
I assume what you are observing is "channel skew". There may be variations in the time a signal takes to travel through the scope's front end, due to parts tolerances. It is an approximately constant time offset per channel. In your scope, channel 1 seems to be different from the others by about 3 ns (20% of a signal period at 70 MHz).
You can adjust these skews in the scope software. See section 5.11 of the manual. The adjustment range is -100 to + 100 ns, so your 3 ns skew is easily within the range.
Before you do that, let the scope warm up for at least 30 minutes, and then run a self-calibration (section 21.6 of the manual). Then check the skew again and adjust in the software dialog as needed.
Edit: This thread is specifically about hacking (modifying) the scope hardware & firmware. For general discussions and questions, I think the following thread is the better choice: https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/ (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/)
-
Why do the phases of the signals between channels 1 and 2 diverge? The higher the signal frequency, the greater the discrepancy.
My generator produces a maximum sine wave of 70 MHz, so at 70 MHz the phase difference is 20%, and it doesn’t matter between which channels, between 1 and 2, between 1 and 3, between 1 and 4!
I assume what you are observing is "channel skew".
probe's cable length and model/attenuation type difference also can give effect. try to match length and same probe model as much as possible. or use bnc splitter same length everything is typical skew verification. yeah if anything, report it in bug thread, not hack thread. ymmv.
-
Hello everybody!
I recently purchased a Rigol DHO804 oscilloscope. Everything works fine, I haven’t noticed any bugs yet, but..
This question is: Why do the phases of the signals between channels 1 and 2 diverge? The higher the signal frequency, the greater the discrepancy.
My generator produces a maximum sine wave of 70 MHz, so at 70 MHz the phase difference is 20%, and it doesn’t matter between which channels, between 1 and 2, between 1 and 3, between 1 and 4!
But a nuance was noticed that between 2 and 3, 3 and 4, 2 and 4 channels there is no such phase discrepancy, only relative to 1 channel and any other.
Can someone check on their oscillation whether this is the same nonsense or not?
How are you connecting the signal to the 'scope? Are all the paths from the generator to the BNC connectors the same length?
At those frequencies you should be able to measure differences in the lengths of the wires.
You can adjust these skews in the scope software. See section 5.11 of the manual. The adjustment range is -100 to + 100 ns, so your 3 ns skew is easily within the range.
Hence an option to tweak it manually.
-
You can adjust these skews in the scope software. See section 5.11 of the manual. The adjustment range is -100 to + 100 ns, so your 3 ns skew is easily within the range.
Hence an option to tweak it manually.
not acceptable imho if for no good reason. all CH should be in phase or 0s skew in setting by default, we set non zero skew value only if for special purpose, maybe say an example we cannot match length in DUT or anything out of dso control etc. another suggestion is redo dso calibration...
-
According to my measurements, the discrepancy between the phases of the channels does not exceed 5% (18°) at 60 MHz, this is less than 1 ns.
-
How are you connecting the signal to the 'scope? Are all the paths from the generator to the BNC connectors the same length?
At those frequencies you should be able to measure differences in the lengths of the wires.
True in principle. But a time difference of 3 ns corresponds to about 0.6 m cable length, so it should be an obvious difference, right?
I was also assuming that @Slavius had swapped the same probes or cables across the channels when he tested for inter-channel delays in the various channel combinations. If that was not the case, then indeed he should double-check whether the difference is due to internal skew in the scope or due to external connections.
-
I tried both the native oscilloscope probes from the kit and from the Rigol DS1054Z kit (this oscillator has slightly better probes both in frequency-amplitude and phase characteristics).
All probes are connected in parallel to the generator output, ground probes are connected at one point of the generator ground.
Something else I noticed:
1) First 4 photos: Default setting (Ch-Ch Skew = 0.00s) in channel 1 settings. The difference in phase shift between 1 and 2, 1 and 3, 1 and 4 channels is about 20 degrees, but if you turn on three or four channels at the same time, the shift is eliminated.
[attachimg=8]
[attachimg=1]
[attachimg=2]
[attachimg=3]
2) Last 4 photos: When setting (Ch-Ch Skew = 750ps) in the settings of channel 1. The phase shift difference between 1 and 2, 1 and 3, 1 and 4 channels is about 1 degree, but if you turn on three or four channels at the same time, the phase shift becomes about 20 degrees.
[attachimg=4]
[attachimg=5]
[attachimg=6]
[attachimg=7]
Why this happens is unclear.
-
The phase shift difference between 1 and 2, 1 and 3, 1 and 4 channels is about 1 degree, but if you turn on three or four channels at the same time, the phase shift becomes about 20 degrees.
This is probably due to the change in sampling rate.
-
if you turn on three or four channels at the same time, the phase shift becomes about 20 degrees.
Why this happens is unclear.
There's only one ADC in the 'scope, shared between all channels.
When you turn on more than one channel you can see the sample rate drop.
-
How are you connecting the signal to the 'scope? Are all the paths from the generator to the BNC connectors the same length?
At those frequencies you should be able to measure differences in the lengths of the wires.
True in principle. But a time difference of 3 ns corresponds to about 0.6 m cable length, so it should be an obvious difference, right?
The differences being discussed are sub-ns.
(https://www.eevblog.com/forum/index.php?action=dlattach;topic=393928.0;attach=2126426;image)
-
All probes are connected in parallel to the generator output, ground probes are connected at one point of the generator ground.
Does it vary if you swap the probes around? At these frequencies the tiniest difference in capacitance between probes will show up.
-
The phase shift difference between 1 and 2, 1 and 3, 1 and 4 channels is about 1 degree, but if you turn on three or four channels at the same time, the phase shift becomes about 20 degrees.
This is probably due to the change in sampling rate.
Perhaps yes, I agree that this is not a completely correct measurement, which is associated precisely with lowering the sampling frequency.
Roughly speaking, when 2 channels are turned on, the sampling frequency drops by half, and when 3 or 4 channels are turned on, the sampling frequency drops by 4 times.
If we take the initial maximum measured frequency for this oscilloscope = 100 MHz, then for two channels it will be = 50 MHz, for channels 3 and 4 = 25 MHz.
At such frequencies I think everything will be fine.
p.s. I'll try to do the same experiment with Rigol DS 1054Z. Just out of interest, whether it will behave the same way or not.
-
if you turn on three or four channels at the same time, the phase shift becomes about 20 degrees.
Why this happens is unclear.
There's only one ADC in the 'scope, shared between all channels.
When you turn on more than one channel you can see the sample rate drop.
Yes, it will probably have to to with the discretisation due to the limited sampling rate. The sampling interval is 1.6 ns or 3.2 ns (625 or 312 MHz sampling rate), larger than the observed skew of 0.75 ns.
Still, the scope should know if the samples are not acquired at exactly the same time, and correct for any offsets. And it is strange that CH1 is different from the others. Smells like a firmware glitch... Do other DHO800s show the same effect?
-
Adc is interleaved 0.8ns apart (1.25GSps) so it seems dso doesnt do built in deskew. Best to verify in 1X match length 50ohm environment, otherwise just deskew in setting whatever probes you have from same source.. older ds1054z you have to do mental deskew imagination in brain if it matters. Ymmv.
-
Adc is interleaved 0.8ns apart (1.25GSps) so it seems dso doesnt do built in deskew.
Right, the observed phase shift may be exactly the ADC sampling interval. (Give or take some "analog" tolerances.) But the thing is that the scope does apparently compensate the skew across channels 2..4, and channel 1 too when running at 312 MSa/s. Only when running at 625 MSa/s, and then only for channel 1, the compensation is missing.
That would imply a firmware bug. Hence I am curious whether all DHO800 show this effect.
-
Still, the scope should know if the samples are not acquired at exactly the same time, and correct for any offsets.
Easy to say, but ... in the real world there's probably many little hardware things adding up.
Question: Are the probes properly compensated?
Overlay all four traces on top of each other and compensate them to match each other exactly.
-
Easy to say, but ... in the real world there's probably many little hardware things adding up.
Question: Are the probes properly compensated?
Overlay all four traces on top of each other and compensate them to match each other exactly.
Please take another careful look at Slavius' reply #2605. He did manually compensate the skew carefully -- but then it's off again when he enables more channels.
How would "little hardware things" and probe compensation change when you enable a third or fourth channel, cutting the sampling rate in half? But the observed skew does change then. In my opinion this clearly points to a firmware glitch, not doing the skew compensation properly.
-
Question: Are the probes properly compensated?
Please take another careful look at Slavius' reply #2605. He did manually compensate the skew carefully -- but then it's off again when he enables more channels.
Probe compensation uses the compensation signal on the front panel.
Edit: It's probably not that though. That matches the probe capacitance to the input capacitance but it doesn't tell you anything about the total capacitance of probe+input.
-
In my opinion this clearly points to a firmware glitch not doing the skew compensation properly.
More likely they're not even trying to because it's a fools errand.
Connect up the probes, compensate the skew manually, take the measurements. Don't fiddle around with the setup once you've got it dialed in.
-
In my opinion this clearly points to a firmware glitch not doing the skew compensation properly.
More likely they're not even trying to because it's a fools errand.
Connect up the probes, compensate the skew manually, take the measurements. Don't fiddle around with the setup once you've got it dialed in.
You still don't get it. The skew is quite stable over time, according to Slavius. But it changes depending on how many channels are enabled. Do you expect users to redo the skew compensation whenever they switch a third channel on or off?
I would really be curious whether all DHO800s behave this way -- they should, if my assumption of a firmware bug is correct. But nobody seems interested enough to try and put this in the bug report thread if confirmed?
-
You still don't get it. The skew is quite stable over time, according to Slavius. But it changes depending on how many channels are enabled.
I got it...
Do you expect users to redo the skew compensation whenever they switch a third channel on or off?
Oh, the humanity...
Who knows what switching the sequence of inputs at the ADC can do when there's a different capacitance on each path.
I would really be curious whether all DHO800s behave this way
Aren't you more curious to see if any of your oscilloscopes do this?
-
btw, this skew thing should be in bug report thread, not here.. Slavius should organize the test as suggested to prove this is a FW bug or just test setup mismatch... i suggest moving the last chunk of posts here starting from his post to bug thread.
-
btw, this skew thing should be in bug report thread, not here.
We don't know if it's a bug or a curiosity yet.
It's not a hack though, I'll give you that.
-
Aren't you more curious to see if any of your oscilloscopes do this?
No, I am no longer curious since I checked this on the SDS800X HD. Worst measured phase deviation between channels is 0.3° with a 100 MHz sine signal, i.e. 0.3/360 * 10 ns = 8 ps. I did not do any skew adjustments on the scope, and the skew is independent of the number of channels I enable.
Those measured values may be lucky; they are significantly better than the guaranteed datasheet spec of 100 ps for interchannel skew. Which in turn is much better than Rigol's "spec" (they give a typical value only) of 2 ns (!).
-
..Worst measured phase deviation between channels is 0.3° with a 100 MHz sine signal, i.e. 0.3/360 * 10 ns = 8 ps. I did not do any skew adjustments on the scope, and the skew is independent of the number of channels I enable.
maybe measurement in term of phase is less relevant, maybe we need measurement in time delay... and delay changes when all or only 2 CH actives, maybe we can find the reason why it changes.
It's not a hack though, I'll give you that.
thats why for certain, it should not be here..
-
We don't know if it's a bug or a curiosity yet.
Getting the answer to that question is exactly why I suggested that other DHO800 owners check whether it's a systematic issue. I was not interested in a "mine is better than yours" competition -- although I am pleased enough with the result now that you asked for it. ;)
It's not a hack though, I'll give you that.
Yep; I mentioned that this should be in a different thread in my very first reply to Slavius. But it's near-impossible to move a discussion elsewhere once it has been started; people (myself included) just keep replying as long as it's interesting.
maybe measurement in term of phase is less relevant, maybe we need measurement in time delay... and delay changes when all or only 2 CH actives, maybe we can find the reason why it changes.
I agree, a delay time is what we are really after. But I don't have a source for very steep pulse edges (and the scope would bandwidth-limit them anyway). Letting the scope measure the phase deviation between two sine waves has the advantage of using the full waveform, so it should be reasonably accurate.
-
We don't know if it's a bug or a curiosity yet.
Getting the answer to that question is exactly why I suggested that other DHO800 owners check whether it's a systematic issue. I was not interested in a "mine is better than yours" competition -- although I am pleased enough with the result now that you asked for it. ;)
Ok, I just hooked all four probes up to a crocodile clip coming out of my pulse generator, and... nada.
All traces line up perfectly on the rising edge.
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2128199;image)
Test setup:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2128172;image)
-
Ok, I just hooked all four probes up to a crocodile clip coming out of my pulse generator, and... nada.
All traces line up perfectly on the rising edge.
Thanks for checking. But with all four channels enabled (and prior to any skew adjustments), all channels were well-aligned for Slavius too. Could you please retry with only CH1 and CH2 enabled?
-
Could you please retry with only CH1 and CH2 enabled?
Ideally, every possible combination of more than 1 enabled channels.
-
That’s right, this is most likely a firmware bug or a flaw in the Rigol DHO800-900 series!
I carried out the same test measurements on the Rigol DS1054Z and the maximum phase deviation, regardless of whether 2, 3 or 4 channels were included, was about 1.2 degrees on the test signal - Sine 70 MHz.
Here is the phase shift of the signals when two channels are turned on:
[attachimg=2]
And here is the phase shift of the signals when all four channels are turned on:
[attachimg=1]
-
New 0.3.3 version
Added "x log" button which allows toggle the X axis between linear and logarithmic scale
Added Y value to the peak annotation
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/latest
-
I Tried this today and this is what I got. any help would be grate.
DOH814 firmware 00.01.02 it did make a backup though.
adb: error: remote object '/rigol/data/Key.data' does not exist
go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO8
SCPI format: ':SYSTem:OPTion:INSTall'
options: [RLU BW7T10]
error open Key.data: The system cannot find the file specified.
exit status 10
Please, send generated :SYSTem:OPTion:INSTall commands to the scope via the SCPI interface, and press any key to check for the new *.lic files.
Options are installed without scope reboot.
Press any key to continue . . .
-
I Tried this today and this is what I got. any help would be grate.
DOH814 firmware 00.01.02 it did make a backup though.
adb: error: remote object '/rigol/data/Key.data' does not exist
go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO8
SCPI format: ':SYSTem:OPTion:INSTall'
options: [RLU BW7T10]
error open Key.data: The system cannot find the file specified.
exit status 10
Please, send generated :SYSTem:OPTion:INSTall commands to the scope via the SCPI interface, and press any key to check for the new *.lic files.
Options are installed without scope reboot.
Press any key to continue . . .
As far as I know, in the latest firmware they changed Key.data to RKey.data. I spent a long time fiddling around with this hack of this oscilloscope. And besides this, there was something else that needs to be remembered.
-
Who knows why the "ADC Phase" calibration does not work?
[attachimg=2]
I think that this is exactly the calibration that is needed, with the help of which the phase shift of the channels is calibrated.
Does anyone know how to calibrate this element?
If this item is selected, and regardless of whether only this or other items, then calibration ends with the error "Unknown error occurred while calibrating"
[attachimg=1]
-
Moved all three bugs to the Bugs topic - https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg5459435/#msg5459435
-
I've got a strange window at the webcontrol window (see below). Had to restart the scope in order to get the usual window back.
The buttons had no response.
Did anyone experienced this?
[attach=1]
-
I like this layout ;)
[attach=1]
-
Yes, it is real ;D
[attach=1]
-
Yes, it is real ;D
Nicely done. Very sexy! 8)
BTW: @AndyBig @Shapirus and @Randy222 were all experimenting with the UI elements a short while ago. Are you continuing with their work or doing something different?
-
Are you continuing with their work or doing something different?
I'm making changes directly to the latest Sparrow.apk version.
-
I'm making changes directly to the latest Sparrow.apk version.
Awesome! Very cool. I was away for a bit, so please forgive my naive Q's;
Is your modified app fully functioning when installed? i.e., able to save screenshots, etc...
Is it easy enough to try your mods by doing a simple remove/install of the APK?
-
All this separate work really needs a github repo to track. If not for direct use for the recompilation of the .apk, then at least as a source to make diffs against and patch your own decompiled .apks.
-
Yes, it is real ;D
(Attachment Link)
This screen layout is much better than original...
But a question:
You show signal that has 10ns period, measurements measure 20ns period, and Counter measure 140 Hz (should be cca 100MHz)..
Am I confused or what?
-
All this separate work really needs a github repo to track. If not for direct use for the recompilation of the .apk, then at least as a source to make diffs against and patch your own decompiled .apks.
imho step by step guide how to hex-edit/patch and which part is what, is what i more need.. and then others can continue the work on other parts and produce step by step again, until majority of parts are hacked or known. or a readable script or table in file (byte position, byte value to patch)... so end users also can freely customize which part he/she prefer to change which part to stay default. ymmv.
-
All this separate work really needs a github repo to track. If not for direct use for the recompilation of the .apk, then at least as a source to make diffs against and patch your own decompiled .apks.
imho step by step guide how to hex-edit/patch and which part is what, is what i more need.. and then others can continue the work on other parts and produce step by step again, until majority of parts are hacked or known. or a readable script or table in file (byte position, byte value to patch)... so end users also can freely customize which part he/she prefer to change which part to stay default. ymmv.
UI edits are (at least mostly) all text, no hex editing is involved.
The important part in making it possible is to disable the signature verification, and from there it's all trivial using apktool.
The valuable part, that should not be lost, and which therefore should be hosted in a git repo, is the actual changes to the decompiled text files that tweak the UI.
-
Is your modified app fully functioning when installed? i.e., able to save screenshots, etc...
Oh! I was on page 67 of this now 106 pages thread and saw a modification of the UI. So, I got down to work. I think that I just reinvented the wheel. I should have read some more pages, that could have made my job easier by working on what you have already done.
I had the same problems as Andybig had. My application is signed with my own development key, so it can't share the system user space. So, in the beginning if the application is installed normally and granted root access but not system access, it can't take a screenshot. For me it is not really a big problem because I use the webui to take the screenshots.
-
...You show signal that has 10ns period, measurements measure 20ns period, and Counter measure 140 Hz (should be cca 100MHz)..
Am I confused or what?
Just ignore that, it was noise at my desktop and the screen shows a little piece of a larger noise. So, the counter is counting anything.
-
...All this separate work really needs a github repo to track...
I post the apk for the test in the repo: https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/tag/SPGUI0.2.1
But it is in a very early stage.
Compatible only with Rigol Firmware 00.01.02.00.02
Known issues:
- Without privileged system access the application can't take screenshots.
- Probe ratio is not shown in the main screen
- Currently tested only on DH804-814, it is possible that LA and WG buttons don't work properly
-
Known issues:
- Without privileged system access the application can't take screenshots.
I should have read some more pages
yes :)
it is possible to run self-signed apps with system permissions:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5408810/#msg5408810 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5408810/#msg5408810)
-
Is it possible to remove the RIGOL logo in the top left corner to save some space ?
-
Is it possible to remove the RIGOL logo in the top left corner to save some space ?
If you want more space for waves, you can use full screen mode. ;D
[attach=1]
I have taken a picture of the oscilloscope and not a capture so that you can see that it is not a clipping.
-
If you want more space for waves, you can use full screen mode. ;D
Neat! Can you assign a button to toggle between views?
-
Neat! Can you assign a button to toggle between views?
Maybe it is possible.
-
Damn that's great. It will be a crime not to share :)
BTW, it's better to keep decompiled sources in git rather than an assembled .apk -- for the very purpose of VCS, that is, to keep history, to be able to see diffs, to be able to cooperate with others via forks and pull requests.
Please consider this.
-
It will be a crime not to share :)
BTW, it's better to keep decompiled sources in git rather than an assembled .apk
It's an interesting question what Rigol will think and possibly do about this. Hosting copies of their copyrighted binaries on a public server is probably violating license terms already. Hosting and sharing decompiled sources might be beyond their pain threshold?
Or maybe they don't care. Who is brave enough to run the experiment? ::)
You may not resell, decompile, reverse engineer, disassemble, or otherwise convert the Software to a human perceivable form.
https://int.rigol.com/announce/terms
-
It will be a crime not to share :)
BTW, it's better to keep decompiled sources in git rather than an assembled .apk
It's an interesting question what Rigol will think and possibly do about this. Hosting copies of their copyrighted binaries on a public server is probably violating license terms already. Hosting and sharing decompiled sources might be beyond their pain threshold?
Or maybe they don't care. Who is brave enough to run the experiment? ::)
You may not resell, decompile, reverse engineer, disassemble, or otherwise convert the Software to a human perceivable form.
https://int.rigol.com/announce/terms
That's a good point. Legally, it's questionable at least.
Well, it then could be a private repo with access for trusted forum members :).
Another option would be to keep only diffs in the repo.
-
If they used GPL code, then they must release the source code of the entire project, and can't restrict the use of the code.
-
Or maybe they don't care. Who is brave enough to run the experiment? ::)
Two months ago I gave here a link to my github :)
If you want more space for waves, you can use full screen mode. ;D
I have taken a picture of the oscilloscope and not a capture so that you can see that it is not a clipping.
Have you switched somehow between full screen mode and normal mode while working? Or is it a separate full-screen version of the application?
-
New header bar
[attach=1]
-
Have you switched somehow between full screen mode and normal mode while working? Or is it a separate full-screen version of the application?
It is the same application compiled with some changes as a proof of concept.
-
that's impressive indeed.
don't stop :)
-
I would move the math-button next to the channel-buttons., so that one large black area comes free where the time info can be placed (starting a bit like a siglent ;-)).
-
Or you may want to take a look at the DHO1000/4000 GUI. With its larger screen, it shows four separate Math boxes in the bottom status bar, which show details about each Math function when it's activated. (Also a bit like the Siglents. ;))
The font is a bit smaller in your modified UI, right? Do you still find it comfortably readable on the built-in screen, or do you mostly use an external monitor?
-
If they used GPL code, then they must release the source code of the entire project, and can't restrict the use of the code.
That depends on how they included potential GPL code (or libraries), and what the specific licenses require. If I recall correctly, there is an Open Source Acknowledgement built right into the firmware, so Rigol are not ignorant of their obligations. And I don't think that Acknowledgement states that the whole firmware is open source.