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 working with the Edimax EW-7611ULB V1 (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/bluetooth/ew-7611ulb), V2 (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/bluetooth/ew-7611ulb_v2/) and (thanks to Spectra) Comfast CF-723B Bluetooth/Wifi combo adapters :D Just extract rtl8723.tgz (https://sven.killig.de/android/DHO/rtl8723.tgz) to the root of the filesystem and start
rk3399_rigol:/ # rtl8723.sh
Bus 003 Device 002: ID 0bda:d723
unbinding 3-1:1.0 ...
Bus 003 Device 002: ID 0bda:d723
RTL8723DU
Both the Bluetooth and Wi-Fi pages 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 rtl8723.tgz /data/local/tmp
adb shell
rk3399_rigol:/ # tar xfz /data/local/tmp/rtl8723.tgz
rk3399_rigol:/ # rtl8723.sh
Bus 003 Device 002: ID 0bda:d723
unbinding 3-1:1.0 ...
Bus 003 Device 002: ID 0bda:d723
RTL8723DU
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/RTL8723DU dongles with USB Vendor IDs
0489
0bda
1358
13d3
7392
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
-
Update 05 January 2025: DHO824 support.
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
- DHO824
- 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 disclosure the source upon request because GPL license is viral, and can't restrict the use of the code. It is not enough to show a text acknowledgement. There is a large list of Chinese manufactures that use GPL code and do not disclosure the sources, some of them use the phrase "open source" in a promotional way and do not release any source.
-
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.
-
New header bar
(Attachment Link)
The "New Header" version has been released in the repo.
-
New header bar
(Attachment Link)
The "New Header" version has been released in the repo.
How do I install it Mrisco? theres no instructions.
-
Looking at the zynq 7015 pinouts along with the board layout gives some clues to the DDR SDRAM usage.
The DDR3L chip on the DHO800 is connected up to bank 13 (yellow), this will be a DDR memory controller implemented in the FPGA fabric. The gigadevice GDP2BFLM-CA is a 16-bit wide, 2133MT/s device, if clocked at it's rated frequency, that gives 34Gb/s theoretical memory bandwidth.
It looks like bank 35 (magenta) is being used for the ADC interface, 1.25Gsps @ 12-bit is 15Gb/s. Considering the memory is 16-bit wide, and there are also 16 logic analyser inputs, they could just be storing 12-bit samples as 16-bit instead of repacking, bringing the ADC sample bandwidth up to 20Gb/s.
I'm assuming that bank 34 is mostly being used for the differential LA inputs, as well as any other GPIOs/controls (based on some visible single ended signals on the top layer here too).
Bank 112 (blue) are the GTP tranceivers implementing the PCIe device on the RK3399.
The DHO800 unpopulated memory devices (orange) are specifically for the PS / ARM SoC part of the zynq chip. In most zynq applications, this memory would be the system memory for embedded linux running on the PS. In these situations, any high bandwidth data needs to pass from the FPGA fabric (PL) to the PS via some dedicated AXI buses inside the zynq, and then handled by the PS memory controller, on a separate clock domain. While they technically have the bandwidth (4x buses of 8-16GB/s, depending on clocks), it's likely that just having a synchronous memory device directly on the FPGA fabric is much more suitable for continuously streaming data from an ADC.
It's not clear to me what the PS is being used for in this zynq. Clearly it's not running embedded linux, since the RK3399 is running the host OS, and there's no system memory on the DHO800 series. It could be running some RTOS doing measurements, stats or monitoring (with the limited 256KB of on-chip memory available to it), but I really have no idea.
-
Haven't been around here quite a time, very glad to see you guys are still working on this scope :D
I had talked with someone who used to work at Rigol HQ, and he told me: "The PS part of that 7015 isn't used at all, we only use PL for the work". This might be a rumor, but depends on you.
You might ask why not use an Artix or Spartan if they don't use the PS part. I guess that's because those lower-end ZYNQ chips are incredibly cheap in China right now, I am talking about $1 ZYNQ-7010/pcs or $6~7 ZYNQ-7020/pcs (of course not brand new, it is second-hand but tested to make sure it is functional) at online sales.
Rigol certainly did use brand-new chips, but from the example above, you can imagine how cheap if you purchase a bunch of them from Xilinx.
:popcorn:
-
Looking at the zynq 7015 pinouts along with the board layout gives some clues to the DDR SDRAM usage.
The DDR3L chip on the DHO800 is connected up to bank 13 (yellow), this will be a DDR memory controller implemented in the FPGA fabric. The gigadevice GDP2BFLM-CA is a 16-bit wide, 2133MT/s device, if clocked at it's rated frequency, that gives 34Gb/s theoretical memory bandwidth.
It looks like bank 35 (magenta) is being used for the ADC interface, 1.25Gsps @ 12-bit is 15Gb/s. Considering the memory is 16-bit wide, and there are also 16 logic analyser inputs, they could just be storing 12-bit samples as 16-bit instead of repacking, bringing the ADC sample bandwidth up to 20Gb/s.
I'm assuming that bank 34 is mostly being used for the differential LA inputs, as well as any other GPIOs/controls (based on some visible single ended signals on the top layer here too).
Bank 112 (blue) are the GTP tranceivers implementing the PCIe device on the RK3399.
The DHO800 unpopulated memory devices (orange) are specifically for the PS / ARM SoC part of the zynq chip. In most zynq applications, this memory would be the system memory for embedded linux running on the PS. In these situations, any high bandwidth data needs to pass from the FPGA fabric (PL) to the PS via some dedicated AXI buses inside the zynq, and then handled by the PS memory controller, on a separate clock domain. While they technically have the bandwidth (4x buses of 8-16GB/s, depending on clocks), it's likely that just having a synchronous memory device directly on the FPGA fabric is much more suitable for continuously streaming data from an ADC.
It's not clear to me what the PS is being used for in this zynq. Clearly it's not running embedded linux, since the RK3399 is running the host OS, and there's no system memory on the DHO800 series. It could be running some RTOS doing measurements, stats or monitoring (with the limited 256KB of on-chip memory available to it), but I really have no idea.
Thanks for your analysis and observations. Good to have some new eyes looking at the architecture here.
Couple things I've ascertained: (and have data for)
--The FPGA is hooked to the SoC(RK3399) via PCIe., and according to what I've noticed, they're only using 2 PCIe channels of the 4 lanes(1/2 & 1/2 on top & bottom) The traces you circled(in blue) above are only 2 channels, plus the clock pair.
--There are several DDR3(and DDR3L) parts that have been or are used on the FPGA... While the GigaDevice parts are listed at 2133, We've seen slower speed parts populated. -like 1800-1900 I'm not sure what speed they're running, off the top of my head.
-- There IS actually "system memory on the DHO800 series", it's 4GB of DDR4 connected to the RK3399, and is only clocked at 856Mhz
FYI: They have a console UART on PCB next to the FPGA., The logfile has FSBL and "how it's config'd" information. You might want to poke around at the ZYNC there.
-
I seem to have seen Zynq7Z015r DDR3 support up to 1333mb/s
-
Is it possible to remove the RIGOL logo in the top left corner to save some space ?
When I learn to do this, I was maybe going to put my own name there. ;)
-
Hello all. I tried the 100mhz/memory depth hack on firmware 1.02 and it initially failed with Key.data not found errors.
I edited the 2 batch files to RKey.data and it finds the files now but it says the key file format is wrong.
How do I get this hack to work on 1.02 firmware? Thanks!
-
Hello all. I tried the 100mhz/memory depth hack on firmware 1.02 and it initially failed with Key.data not found errors.
I edited the 2 batch files to RKey.data and it finds the files now but it says the key file format is wrong.
How do I get this hack to work on 1.02 firmware? Thanks!
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)
-
Thanks! I was trying to use the utility from the first page but didnt see this.
It worked good.
-
To help direct people to the hacking guide location, I've added a link in my signature, like @Andy's
[b][color=purple]
[url=https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076]DHO 800/900 hack instructions by @AndyBig[/url]
[/color][/b]
-
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.
Awesome work! I really need to try these modified APKs.
By the way, are you (and @AndyBig) aware of the Revanced Manager (https://github.com/ReVanced/revanced-manager/) / ReVanced Patcher (https://github.com/revanced/revanced-patcher) / ReVanced Patches (https://github.com/ReVanced/revanced-patches/) projects? They provide a generic framework together with a fronted app and individual patches to allow modifying existing APKs easily directly on the target device. The patches target a particular version of the app and one can select which patches one wants to apply from a list of available patches that is updated regularly from the patches repo. (The highest profile app that can be patched using ReVanced is YouTube, and there are now over 60 patches available for it, including ad blocking.)
It would be incredible if these patches for the Sparrow.apk could be transformed into the format Revanced Patcher / Revanced Manager understands - this would solve the legal issue (no copyrighted material would need to be published) while allowing users to only apply patches they want, and the patches would be kept in one central repository allowing for easier collaboration.
ReVanced Manager allows for using custom patches repository (instead of the default ReVanced Patches), so we could have our own.
I do realize it would require significant investment into development time on top of the actual patching, so I would understand if neither you nor @AndyBig were keen on spending any time on this. I just thought it would be awesome to have the patches in ReVanced, both from user and development perspective.
-
After reading many different ways to upgrade the bandwidth and memory of my 804, I have one question does the methods listed hear still work or do I need to keep looking. I used the youtube video and it worked very well but when I did a fermware update it reset back to factory. So does this part below still work from Andybig. Thank you
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.
-
After reading many different ways to upgrade the bandwidth and memory of my 804, I have one question does the methods listed hear still work or do I need to keep looking. I used the youtube video and it worked very well but when I did a fermware update it reset back to factory. So does this part below still work from Andybig. Thank you
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.
Yes, the guide by @AndyBig has every detail you need to hack/upgrade your scope.
You need to upgrade the firmware before you generate options. --otherwise it will revert as you mention.
-
This topic is specifically for hacking, and I think you got it right when you cross-posted this in the FS/Wanted thread. Cool mount tho', and I'm sure many would love having one. Good luck with your business endeavors!
Reasonable. I looked for and found the buy / sell / wanted section of the forum after I posted here. Deleting now.
-
By the way, are you (and @AndyBig) aware of the Revanced Manager (https://github.com/ReVanced/revanced-manager/) / ReVanced Patcher (https://github.com/revanced/revanced-patcher) / ReVanced Patches (https://github.com/ReVanced/revanced-patches/) projects?
It seems to be a lot of work and without the original sources from Rigol it could be difficult to maintain.
I made a new mod with a better compromise between screen elements size and touch screen functionality.
[attachimg=1]
-
Nice!
You could also consider removing the gearwheel in the lower left, and assigning the main menu to the date/time/USB info box in the lower right instead. Easier to reach for right-handed users, and it would "almost" give you enough room to display separate info boxes for each math function, like in the DHO1000/4000.
But you could probably fit in only three math boxes, not four, if the generator and digital channels also need to be displayed. Can the info boxes in the bottom also be scrolled left & right, like the tool shortcuts in the upper right?
Edit: Having looked at the DHO1000 display again, its Math info boxes are quite compact. Maybe you could fit in all four of them without the need for lateral scrolling? You could probably squeeze a couple of mm from the data/time info box too...
-
New version available!
- Full Screen toggle
- Probe attenuation in channel widget
- Trigger coupling indicator
- Automatically show date-time at boot if it is valid
- Compact result bar
- Better UI organization
Link removed, only available privately (http://Link removed, only available privately)
-
But you could probably fit in only three math boxes, not four, if the generator and digital channels also need to be displayed. Can the info boxes in the bottom also be scrolled left & right, like the tool shortcuts in the upper right?
Edit: Having looked at the DHO1000 display again, its Math info boxes are quite compact. Maybe you could fit in all four of them without the need for lateral scrolling? You could probably squeeze a couple of mm from the data/time info box too...
Funny thing about this: The DHO8/900's have the same resolution screen(@different PPI) as DHO1000's, so the UI would just fit, no UI mods or scrolling needed.
-
Funny thing about this: The DHO8/900's have the same resolution screen(@different PPI) as DHO1000's, so the UI would just fit, no UI mods or scrolling needed.
DHO800/900 LCD: 1024x600
DHO1000 LCD: 1280x800
-
Funny thing about this: The DHO8/900's have the same resolution screen(@different PPI) as DHO1000's, so the UI would just fit, no UI mods or scrolling needed.
DHO800/900 LCD: 1024x600
DHO1000 LCD: 1280x800
I was on Rigol's site earlier and saw this;
[attachimg=1 width=500]
But I just re-checked the datasheet, and it claims 1280x800, Doh! :wtf:
-
So there's been at least one person who wished to give my modded webcontrol app a try, so I'm attaching the apk here.
To recap, the changes compared to the original are:
- set native display resolution (1024x600 vs 1280x800 thoughtlessly ported from the dho1000 series app) in the screencast stream
- changed image format from jpeg to png for screenshots taken via the webcontrol app
- changed the screen recorder video resolution to 1024x600
- changed the screen recorder video bitrate to 40000000 (not sure if it had any effect though)
Of course, this apk is self-signed, and since it needs system permissions, it is necessary to disable the android's apk signature verification (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5408810/#msg5408810) in order to be able to install it. My copy of the patched services.jar is attached a few posts later after that one for those who can't or don't want to build their own.
All the necessary disclaimers apply. No responsibility is implied, use at your own risk. Spend some time to do your research to understand what you're doing. Have backups and make sure you know how to restore them, etc.
I'm also attaching a diff against the original apk for reference.
-
Quote from: shapirus on Today at 03:58:53 (https://www.eevblog.com/forum/index.php?topic=393928.msg5501683#msg5501683) My copy of the patched services.jar is attached a few posts later after that one for those who can't or don't want to build their own.
So, all we need to do is to replace Rigol's
services.jar with your one?
BTW I do not see where it was attached.
-
I am interested in purchasing the extended sparrow GUI but would like to ask for a detailed list of steps to install/apply the GUI.
I suggest you post a more detailed list of steps including how to back up the default APK and what tool to use to make that backup.
Where to get the ADB tool.
Etc.
This "hacking" thread has so many pages that it is difficult to keep up.
Does the extended GUI work with non-hacked models of the DHO800?
Will it continue to work after doing the bandwidth hack and the memory depth hack?
Thanks for considering my suggestions and questions.
Cheers
DM
-
- Does the extended GUI work with non-hacked models of the DHO800?
- Will it continue to work after doing the bandwidth hack and the memory depth hack?
Hi, I will try to put more information on how to install, but due to the caution that is necessary to perform that procedure I restricted the use of the extended app to users who already know how to revert to the stock app. It is not difficult but precautions must be taken.
- Yes, the extended app will work with non-hacked and hacked equipment.
- Yes, it should work after the application of the hacks.
In the Github (https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/tag/SPGUI0.2.1)there is a free demo of the extended version, you can do tests with it before of the purchase.
Regards,
Miguel.
-
I understand you've put substantial efforts into building this modified APK, but selling a hacked binary is really looking for troubles imho.
-
I understand you've put substantial efforts into building this modified APK, but selling a hacked binary is really looking for troubles imho.
I agree. It violates Rigol's licensing terms for the firmware, https://int.rigol.com/announce/terms: (https://int.rigol.com/announce/terms:)
users cannot copy, modify, adapt, compile, reproduce, publish, republish, distribute, publicly transmit, publicly release, publicly broadcast, publicly display, reverse engineering, de-compile, disassemble, or illegally use any Materials in whole or in part posted or discovered on this website for any public or commercial purposes without prior written consent from RIGOL
It also violates Patreon's terms of use, where creators have to guarantee that their products do not violate 3rd party intellectual property rigths, https://www.patreon.com/policy/legal#your-creations (https://www.patreon.com/policy/legal#your-creations) .
-
Trying to make money on it may draw unnecessary attention, which will harm entire community, not to mention it being questionable from the ethical standpoint.
-
Hmm so maybe it is better to keep it private and only available to my supporters, thanks.
But Rigol already violated the GPL.
-
But Rigol already violated the GPL.
Do you know that for sure? Are they using GPL-licensed components which are integrated so tightly into their custom software that Rigol is obliged to put their own software under GPL? Which components are that?
-
Do you know that for sure? Are they using GPL-licensed components which are integrated so tightly into their custom software that Rigol is obliged to put their own software under GPL? Which components are that?
If you got the source code, please post the link here.
[attachimg=1]
-
But Rigol only acknowldege 3rd party open-source software there, right? For 3rd party software licensed under GPL (e.g. Linux and Busybox), that does indeed imply that they need to make source code available. But I am not so motivated to make them jump through that hoop, since there are easier ways to obtain that source code.
Rigol don't offer any of their own source code, right -- because they don't think it has "inherited" the GPL? (I can't check the complete Open Source Acknowledgement right now, since I no longer have my DHO and the Acknowledgement seems to reside exclusively in the firmware for these scopes.)
-
But Rigol only acknowldege 3rd party open-source software there, right? For 3rd party software licensed under GPL (e.g. Linux and Busybox), that does indeed imply that they need to make source code available. But I am not so motivated to make them jump through that hoop, since there are easier ways to obtain that source code.
Rigol don't offer any of their own source code, right -- because they don't think it has "inherited" the GPL? (I can't check the complete Open Source Acknowledgement right now, since I no longer have my DHO and the Acknowledgement seems to reside exclusively in the firmware for these scopes.)
I think that this discussion is more for lawyers than for technical people. So, I will leave this here now.
-
Summary of improvements and customizations made to the UI of the DHO800-900 oscilloscopes
https://www.youtube.com/watch?v=mT4ivaMY7zg (https://youtu.be/mT4ivaMY7zg)
https://www.youtube.com/watch?v=mT4ivaMY7zg (https://www.youtube.com/watch?v=mT4ivaMY7zg)
-
Look it that way: he is not selling the rigol binary, he is only selling the changes to it.
-
Look it that way: he is not selling the rigol binary, he is only selling the changes to it.
I think that Rigol will not have any problem about the changes because it does not threaten their business model, on the contrary, it adds value to their product, as do possible additions such as carry bags that other manufacturers make for their equipment. They will be more concerned about license hacks because those directly threaten their business.Other oscilloscope vendors and manufacturers who do not have these improvements or contributions to their own equipment should have greater concern.
-
Quote from: mrisco on Today at 09:45:22 (https://www.eevblog.com/forum/index.php?topic=393928.msg5504182#msg5504182)I think that this discussion is more for lawyers ...
Perhaps, if you don't care about the court's verdict.
-
Look it that way: he is not selling the rigol binary, he is only selling the changes to it.
That's rather like "I'm not selling that Rolling Stones song on Youtube, just the animation I made for it." Not going to fly.
-
Could be interesting to intercept the press of a physical button to assign other functions, especially the "Default" button.
-
Could be interesting to intercept the press of a physical button to assign other functions, especially the "Default" button.
If you manage to do this, it will be absolutely wonderful! I think almost every DHO owner would want this. In your modifications, you step by step translate into reality those things that have been discussed here for a very long time, but the matter has not yet reached further discussions. You are one of the few who say little and just do it, don’t stop!... You shouldn’t pay attention to the opinion of the local “theorists” who are only capable of criticism, in turn doing nothing except this very criticism!
-
You are one of the few who say little and just do it, don’t stop!... You shouldn’t pay attention to the opinion of the local “theorists” who are only capable of criticism, in turn doing nothing except this very criticism!
If you are referring to the discussion of legal risks and limitations, I beg to differ. Nobody is saying that mrisco's modifications aren't worthwhile. In fact, I find them very impressive and they are certainly desirable improvements. (Which I wish Rigol would make..)
But it seems only fair to point out the legal risks to mrisco. He is the one who might expose himself to these risks, e.g. by offering the modified binaries for sale on Patreon.
Actually, I find your attitude rather selfish: "Please make those modifications, because I want them. I don't care whether you get into hot water, because I as a user will not have those legal risks."
-
Join to Free Software Foundation and forget the risks.
-
I've been conflicted since this came to light. My thoughts, if anyone cares;
To my knowledge, Rigol doesn't have a website that offers paid option/model# upgrades that turn a DHO804-->DHO924 or a 914-->924
Yet, we seem to be fine generating these license keys to save $$$. Even when some of these upgrades legitimately take keep money from their bottom line. Hypocrites, the lot of us.
For the majority of us, de-compiling/editing/re-compiling an APK is a daunting task. @Andybig, @shapirus, @Randy222 did an amazing job, laying the foundation for the UI hacking mods. I hope to someday "repay them in kind" with one of my development/hacks.
I guess if you look at @mrisco's work as a modification service, packaging a custom APK model makes the most sense. That's a helluva lot of work, and for the asking price, it should come with a commitment to support the app after future OEM upgrades, or other defects.
The APK is worthless to anyone without a DHO scope, so it's not like it's a direct threat to their financial well being like other app developers.
-
The proper approach for Rigol would be to get in touch with @mrisco, offer him a contract to have him work as an employee or freelancer to improve/fine tune their scope software. As it seems, they could very well use some more talented programmers that also have an understanding of what would make their product more enjoyable / useful for their customers.
-
To my knowledge, Rigol doesn't have a website that offers paid option/model# upgrades that turn a DHO804-->DHO924 or a 914-->924
Yet, we seem to be fine generating these license keys to save $$$. Even when some of these upgrades legitimately take keep money from their bottom line. Hypocrites, the lot of us.
For the majority of us, de-compiling/editing/re-compiling an APK is a daunting task. @Andybig, @shapirus, @Randy222 did an amazing job, laying the foundation for the UI hacking mods. I hope to someday "repay them in kind" with one of my development/hacks.
I guess if you look at @mrisco's work as a modification service, packaging a custom APK model makes the most sense. That's a helluva lot of work, and for the asking price, it should come with a commitment to support the app after future OEM upgrades, or other defects.
The APK is worthless to anyone without a DHO scope, so it's not like it's a direct threat to their financial well being like other app developers.
I never raised any moral concerns about the various "hacking" approaches. Everybody can assess that for themselves, whether as a user or developer of hacks, and draw their personal conclusions. Also, I certainly agree that mrisco's effort is worth some remuneration from users.
All I wanted to point out is that it violates various terms & conditions. The reverse engineering alone is already in conflict with Rigol's terms; offering modifications for sale makes them much more visible, and also conflicts with Patreons usage terms. Again, mrisco is free to draw is own conclusions of course, but it seems fair to highlight the potential hassles.
I agree that Rigol does not lose any revenue through these hacks -- they might even gain some, from people who only buy the scope because some of its original weaknesses have been addressed. Nevertheless they might not like the availability of hacks which create a scope that behaves differently from the official version. Just think about support and warranty issues, and potential reputation damage:
E.g. users might complain (to Rigol or in a public forum) about bugs which are not Rigol's but are caused by a hack. Or hacks might be developed which overclock parts of the scope logic, causing unreliable operation or even damaging the scope. Either scenario would cause reputation damage to Rigol. This is all hypothetical at this time -- but it is sufficient that someone at Rigol thinks about such hypothetical scenarios, and they may come to the conclusion that they don't like hacks which create functionality beyond Rigol's official offering and act against those who are offering such hacks.
-
To my knowledge, Rigol doesn't have a website that offers paid option/model# upgrades that turn a DHO804-->DHO924 or a 914-->924
Yet, we seem to be fine generating these license keys to save $$$. Even when some of these upgrades legitimately take keep money from their bottom line. Hypocrites, the lot of us.
For the majority of us, de-compiling/editing/re-compiling an APK is a daunting task. @Andybig, @shapirus, @Randy222 did an amazing job, laying the foundation for the UI hacking mods. I hope to someday "repay them in kind" with one of my development/hacks.
I guess if you look at @mrisco's work as a modification service, packaging a custom APK model makes the most sense. That's a helluva lot of work, and for the asking price, it should come with a commitment to support the app after future OEM upgrades, or other defects.
The APK is worthless to anyone without a DHO scope, so it's not like it's a direct threat to their financial well being like other app developers.
I never raised any moral concerns about the various "hacking" approaches. Everybody can assess that for themselves, whether as a user or developer of hacks, and draw their personal conclusions. Also, I certainly agree that mrisco's effort is worth some remuneration from users.
All I wanted to point out is that it violates various terms & conditions. The reverse engineering alone is already in conflict with Rigol's terms; offering modifications for sale makes them much more visible, and also conflicts with Patreons usage terms. Again, mrisco is free to draw is own conclusions of course, but it seems fair to highlight the potential hassles.
I agree that Rigol does not lose any revenue through these hacks -- they might even gain some, from people who only buy the scope because some of its original weaknesses have been addressed. Nevertheless they might not like the availability of hacks which create a scope that behaves differently from the official version. Just think about support and warranty issues, and potential reputation damage:
E.g. users might complain (to Rigol or in a public forum) about bugs which are not Rigol's but are caused by a hack. Or hacks might be developed which overclock parts of the scope logic, causing unreliable operation or even damaging the scope. Either scenario would cause reputation damage to Rigol. This is all hypothetical at this time -- but it is sufficient that someone at Rigol thinks about such hypothetical scenarios, and they may come to the conclusion that they don't like hacks which create functionality beyond Rigol's official offering and act against those who are offering such hacks.
Hey bud. We get it. You have made your point, several times. :horse: :horse: :horse: You're not the only smart person in this room.
Can we get back to the goddamned topic E.g., "hacking the DHO800/900" now?
-
I, and several others here would enjoy having the ability to map buttons for our liking. Here, from earlier this year:
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.
[attachimg=1 width 400]
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...
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)
Could be interesting to intercept the press of a physical button to assign other functions, especially the "Default" button.
Maybe this can be done In software, maybe it has to be hardware/firmware.. It could be a pretty useful hack.
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.
I started digging into it, and it's on my list to work on.
[attachimg=2 width=300]
Edit: I have a copy of the PDF, but can't find a good download link to attach for the GD32F350K8U6 on the control panel PCB
-
If an application was able to decode the keys pressing then it is very possible that the keys are interfaced as a hid device.
-
If an application was able to decode the keys pressing then it is very possible that the keys are interfaced as a hid device.
Thanks. I think more investigation would be worthwhile, because somewhere in here, Android or the app is translating these keyevents & actions. Here is (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5300338/#msg5300338) his reply about HID that I failed to add to my post earlier.
Edit: For convenience:
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 (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.
Now that I know what LSUSB does, I'll take a closer look.
-
I have a copy of the PDF, but can't find a good download link to attach for the GD32F350K8U6
https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20240403/GD32F350xxDatasheetRev3.0.pdf (https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20240403/GD32F350xxDatasheetRev3.0.pdf)
https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20240407/GD32F3x0_User_Manual_Rev2.9.pdf (https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20240407/GD32F3x0_User_Manual_Rev2.9.pdf)
-
I have a copy of the PDF, but can't find a good download link to attach for the GD32F350K8U6
https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20240403/GD32F350xxDatasheetRev3.0.pdf (https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20240403/GD32F350xxDatasheetRev3.0.pdf)
https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20240407/GD32F3x0_User_Manual_Rev2.9.pdf (https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20240407/GD32F3x0_User_Manual_Rev2.9.pdf)
Thanks Andy! Sadly, those links haven't produced a PDF for me lately. I tried and didn't want to post a dead link. Maybe this firewall is causing 404 on *.cn domains :(
-
Thanks Andy! Sadly, those links haven't produced a PDF for me lately. I tried and didn't want to post a dead link. Maybe this firewall is causing 404 on *.cn domains :(
Try by looking at Google: GD32F350xxDatasheetRev
-
Thanks Andy! Sadly, those links haven't produced a PDF for me lately. I tried and didn't want to post a dead link. Maybe this firewall is causing 404 on *.cn domains :(
Probably yes, there are problems either with the firewall or with the provider. I can open these links without problems, including through servers in the USA :)
-
Could be interesting to intercept the press of a physical button to assign other functions, especially the "Default" button.
It was relatively easy, but now I'm not convinced about changing the functionality of the physical buttons, I think maybe it's better to create virtual buttons. (How to attach an animated Gif?) I can open Android Settings from the Rigol app by pressing the Default button.
[attachimg=1]
-
Could be interesting to intercept the press of a physical button to assign other functions, especially the "Default" button.
It was relatively easy, but now I'm not convinced about changing the functionality of the physical buttons, I think maybe it's better to create virtual buttons.
Very cool! Virtual, as in onscreen? That would be nice for touch and/or external monitor use.
-
Very cool! Virtual, as in onscreen? That would be nice for touch and/or external monitor use.
Maybe I could add buttons to the utility drawer that opens when the Rigol symbol is pressed.
-
It was relatively easy ... I can open Android Settings from the Rigol app by pressing the Default button.
That's really all that's needed.
If that can be installed via ADB then it makes it very easy to set up the WiFi, etc.
-
That's really all that's needed.
If that can be installed via ADB then it makes it very easy to set up the WiFi, etc.
Yes but, when the display is at the Android settings screen it is necessary turn off the DHO to return to the scope application if there isn't any virtual back/home button installed.
I put a new "Settings" icon in the start menu to go to Android Settings, currently available in the updated 0.4.1 version.
[attachimg=1]
-
It was relatively easy, but now I'm not convinced about changing the functionality of the physical buttons, I think maybe it's better to create virtual buttons. (How to attach an animated Gif?) I can open Android Settings from the Rigol app by pressing the Default button.
I can intercept a physical keypress inside of the scope application but not from outside, so currently it is not possible to map a physical button to, for example, return to the scope application.
-
Planing to buy DHO and have a question.
If I buy DHO804 and install vendor file from 924 will this get me CAN and LIN decoding plus 125MHz bandwidth?
-
Planing to buy DHO and have a question.
If I buy DHO804 and install vendor file from 924 will this get me CAN and LIN decoding plus 125MHz bandwidth?
Yes.
(nb. 250MHz bandwidth)
-
Hi, I`m trying to hack my DHO804 and really need your help, as don`t want brick my scope:
First, I downloaded and upgrade it to 00.01.02.00.02
So, the instructions told to copy two files from /rigol/data directory:
- vendor.bin -- ok!
- key.data or RKey.data - but none of them exists on my scope.
What should I do?
adb shell
rk3399_rigol:/ $ su
rk3399_rigol:/ # cd rigol
rk3399_rigol:/rigol # cd data
rk3399_rigol:/rigol/data # ls
cal_adc.hex cal_afe_zero.hex cal_lsb.hex default vendor.bin
cal_afe_bandwidth.hex cal_ddr.hex cal_vertical.hex probe
rk3399_rigol:/rigol/data # ls -la
total 1136
drwxrwxrwx 4 root root 4096 2013-01-18 09:14 .
drwxrwxrwx 10 root root 4096 1970-01-01 08:00 ..
-rwxrwxrwx 1 system system 1876 2013-01-18 09:03 cal_adc.hex
-rwxrwxrwx 1 system system 348 2013-01-18 08:50 cal_afe_bandwidth.hex
-rwxrwxrwx 1 system system 348 2013-01-18 08:53 cal_afe_zero.hex
-rwxrwxrwx 1 system system 76 2013-01-18 08:54 cal_ddr.hex
-rwxrwxrwx 1 system system 156 2013-01-18 08:57 cal_lsb.hex
-rwxrwxrwx 1 system system 538300 2013-01-18 09:26 cal_vertical.hex
drwxrwxrwx 2 root root 4096 2023-09-19 17:36 default
drwxrwxrwx 2 root root 4096 2013-01-18 16:50 probe
-rwxrwxrwx 1 system system 136 2013-01-18 08:51 vendor.bin
rk3399_rigol:/rigol/data # pwd
/rigol/data
-
With the latest firmware you should have the file /rigol/data/RKey.data
Depending on what you're after it can enough to upload a vendor.bin file.
(eg. make it into a DHO914 - that has ALL the options and ~225Mhz bandwidth).
-
Many thanks for prompt reply, but believe me, as the directory listing on my previous post, really don't exist neither Key or RKey files.
I did a find . RKey.* and find . Key.* on all Sd and nothing.
I would like to keep the modelo and unlock Just the options.
As I understood, you are telling that maybe the Key file Will be not necessary, is this correct, but I'll have the model chanhed.
As last question: these Key or RKey are the scope keyboard (front painel) mapping ? If so, as my model is dho804 (four Channel, 70MHz), someone couldn't send me a copy of his/her file?
-
I would like to keep the modelo and unlock Just the options.
You need RKey.data to do that... :)
RKey.data has your serial number in it. You need it to generate license keys.
-
The most strange: when I access the About screen, the serial number and all original data is show, along with the new firmware code .....02.
There would be in Linux a way to search for my serial number inside any file?
Those information comes from querer, so?
:wtf:
I'll see tomorrow If the Rigol web control page (the one that we access by web browsing by instrument IP address) gives me some Idea from where It takes such data.
-
The most strange: when I access the About screen, the serial number and all original data is show, along with the new firmware code .....02.
The serial number is also in vendor.bin but you need the one in RKey.data for any licenses to work.
When did you buy it? What firmware version have you got?
Maybe they removed it in a new version because technically there's no licenses for sale, we're just hacking.
-
Is there any way you might have deleted it? The 'scope will still work without it.
If you don't have RKey.data then your best option is to make it into a DHO914.
-
If you don't have RKey.data then your best option is to make it into a DHO914.
Why not a 924?
-
Is there any way you might have deleted it? The 'scope will still work without it.
No, I bought it has two weeks only. Just installed the new firmware from ....01 to ....02 and started the upgrade steps. Just make the file copy and, when I was search both files, Just one was there...
[/quote]
I believe RIGOL is excluding key file intencionally when updating to 00.01.02.00.02, as the page Welcome.html has all oscilloscope data written in html code, it's not a script that fill the fields - it is hard coded. So, this page was generated when installing the ...02 version and the key file was deleted. So, no upgrade keeping the original model, and lost of warranty if you upgrade it.
If you don't have RKey.data then your best option is to make it into a DHO914.
Well, I will have to do this...
By the way, ALL of your ARE indeed fabulous with this incredible work!
In the pages where you teaches how to upgrade, there is information how to change the model, serial, etc... after upgrading, Í'll try that and hope the Logic Analyzer button disappears.
-
Just my little contribution for upgrading or just updating the RIGOL DHO800 series, if you don't want read all 110 pages on this thread:
General instructions:
Beware!!! Before anything, check if you have in scope dir /rigol/data two important files:
vendor.bin and Key.data or RKey.data
If you have them, before any update or upgrade, copy them to your computer, mainly the Key.data ou Rkey.data – after updating mine from 00.01.02.00.01 to 00.01.02.00.02, this EXTREMILLY IMPORTANT file disappeared.
After copying both files to a secure place, as told above, and 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.
Make a backup of oscilloscope directory /rigol/data/ at least.
(follow instructions on page 61 of this thread)
Now, specific instructions for those who does not have the Key or RKey files, copyed mainly from page 61 on this thread and added with other informations:
2 (I would call it 3 or 2.1) - Same as the previous one (changing the model), alternative method:
See the oscilloscope IP address in the menu/utility/IO and take note of it:
Mine is 192.168.0.14
I believe you have already downloaded the ADB package and unzipped it to some directory.
(if not, download it now from this address and unzip it to some directory in your computer: https://developer.android.com/tools/releases/platform-tools
)
Download the file "generate_all_options" into the ADB directory (see above) from:
https://github.com/zelea2/rigol_vendor_bin/releases
From the ADB directory, launch the DOS command line.
On the DOS command line window, write the command:
adb connect 192.168.0.14:55555
Of course, replace the address 192.168.1.14 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 oscilloscope LINUX terminal on DOS command line window:
adb shell
Now you should see the oscilloscope terminal command line with the following prompt - "rk3399_rigol:/$".
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":
./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
-------------------------------------------------- ---------
After all, exit from shell and DOS command window keying on:
exit ENTER exit ENTER
Turn off and on the scope and verify the success of operation!
-
If you don't have RKey.data then your best option is to make it into a DHO914.
Why not a 924?
It's all about sample rate to bandwidth ratios.
DHO924 bandwidth is too high for the 625MHz sample rate when just two channels are enabled, DHO914 bandwidth isn't.
DHO914 bandwidth is too high when more than two channels are enabled, which is why licensed DHO800 is preferred.
You might never notice this in practice.
You don't gain much by making it a DHO924 though.
-
Please, the instructions I put above are correct? I'm very afraid of upgrading my expensive oscilloscope, as I have already lost the key file...
-
I go with Fungus, as him explained.
Also, the "script" generate_all_options described bellow has no option, as I can see, to model 924.
Could you verify the instruction I put above, please?
Best regards
Artur
-
Please, the instructions I put above are correct? I'm very afraid of upgrading my expensive oscilloscope, as I have already lost the key file...
I don't think the license generator will work without the key file.
I'm sure you can't hurt anything though. Back up your /rigol folder first...
adb pull /rigol
-
If you don't have RKey.data then your best option is to make it into a DHO914.
Why not a 924?
Why not a 924S? ;)
Please, the instructions I put above are correct? I'm very afraid of upgrading my expensive oscilloscope, as I have already lost the key file...
if anything fails, including asking from Rigol your original key.data, you can still use hubertyoung's 924 FW with vendor.bin and key.data so download it while you still can, dont rely too much on cloud thing. lesson learnt... backup your original FW from factory before doing anything, make your upgraded/hacked FW on another SD card iirc this is the second time i mentioned it.. 32GB sd card is just like $5. cheers.
-
For what it's worth, when I got my DHO1000 in early November, it also came without the key.data file. At the time I put that down to the scope being an early unit which might have been sitting on the shelf for a long time, before Rigol eventually sold it off via the Black Friday sale.
I was able to generate the key.data file based on the the identical information that resides in the FRAM chip on the main board. The key ingredients were
- the Go program from this post: https://www.eevblog.com/forum/testgear/hacking-the-hdo1khdo4k-rigol-12-bit-scope/msg4501300/#msg4501300, (https://www.eevblog.com/forum/testgear/hacking-the-hdo1khdo4k-rigol-12-bit-scope/msg4501300/#msg4501300,) and
- very helpful hints from user veteran68 on how to get that program to run: https://www.eevblog.com/forum/testgear/hacking-the-hdo1khdo4k-rigol-12-bit-scope/msg5250381/#msg5250381 (https://www.eevblog.com/forum/testgear/hacking-the-hdo1khdo4k-rigol-12-bit-scope/msg5250381/#msg5250381)
If your DHO800 really has the same problem and the above information does not suffice, I can dig out my notes and try to help.
-
the key file is derived cryptographically from the serial number in vendor.bin but I don't know if we have the secret key to do it.
Anybody...?
-
the key file is derived cryptographically from the serial number in vendor.bin
Is that so? Do you have a source/reference for that?
If I recall correctly, the jury is still out on that one. The key file might also be totally independent of the serial number, and Rigol maintains a database of key.data vs. serial number which they use to generate upgrade license keys.
In any case, the "generate key.data from FRAM dump" approach mentioned above is known to work -- at least for the DHO1000, but I see no reason why the 800 should be fundamentally different.
-
Great! I will read about the Go and commentaries. I'm really not experienced on doing such low level interventions, but
with your previous help I hope get It upgraded.
-
the key file is derived cryptographically from the serial number in vendor.bin
Is that so? Do you have a source/reference for that? The key file might also be totally independent of the serial number, and Rigol maintains a database of key.data vs. serial number
That seems like a lot of work to me - very unlikely considering they knowingly leave Android debug mode enabled.
-
Is there a way to copy entire SD card to some folder in my PC running Windows without having to open the scope and removing de SD from it??
I found these commands on this thread:
dd if=/dev/sda of=/path/to/backup.img (but it seens to me this must be run in shell command, so, the destiny is not a windows folder or a sd installed in my computer)
Other one:
Executing /rigol/build_gel.sh can generate a backup of the current running version of firmware!
I believe this is too much for me. I don't have the knowledge fur such operations.
-
I tested the below method to recover Key.data/RKey.data files using @Zelea2 tools (many thanks).
1. We copy nv-mem, e.g. to /rigol/temp/ and give permissions 777
2. Run nv-mem -r to create the FRAM.bin file and download it to your computer
3. Open FRAM.bin in the hex editor, select 0x94 bytes from offset 0x011C and save them to the Key.data file.
4. Verify the Key.data file by running rigol_vendor_bin.exe -d -o, the Key.dec text file should be created
5. If a Key.dec file has been created, copy the Key.data file to /rigol/data/
6. Restart the oscilloscope.
7. Depending on the installed FW, the Key.data file will remain in the /rigol/data/ directory or RKey.data will be created
8. We can now generate options
Alternatively, instead of p.2 and p.3 you can run: nv-mem -r -s 0x11C -l 0x94 Key.data to get the Key.data file directly
-
The DHO800/900 oscilloscope runs Android as the OS so it is possible to install Android applications and, by using some hacks, control external equipment like a Riden external power supply via Python scripting.
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions/5
-
I did it! Many thanks for precious support!
At the end, it seems that the important file is the vender.bin, which can be generated by rigol_vendir_bin as wished. My generated key.data by nv-mem was filled with 00 at indicated star-size instructions.
Got the model 914!
Mem depth from 1k to 50M - great!
In options I can see:
1 Embedded serial bus trigger and analyzes: forever
2 Auto serial bus trigger and analysis: forever
3 Computer serial trigger and analysis (RS232/UART): forever
4 Blode plot (packed with signal source)
My question: is it possible to execute Bode analyzes with an external function generator, as my model doesn't have the internal function generator? The menu option is not shown. (as bellow, no, we need the extra AFG board).
PS: some other improvements to this scope:
- someone trying to make his own AFG module for Rigol DHO800 series!
https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot (https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot)
- Improvements on GUI: https://www.patreon.com/mriscoc/shop/rigol-dho800-900-sparrow-extended-gui-204640 (https://www.patreon.com/mriscoc/shop/rigol-dho800-900-sparrow-extended-gui-204640)
- better FFT analyzes:
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/tag/FFTAVG0.3.3 (https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/tag/FFTAVG0.3.3)
And more from our friend just above this message:
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions/5 (https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions/5)
Some protective cases:
https://eleshop.eu/rigol-bag-800.html (https://eleshop.eu/rigol-bag-800.html)
https://www.aliexpress.com/item/1005005213947242.html (https://www.aliexpress.com/item/1005005213947242.html) (select large size)
https://www.aliexpress.com/item/33004483750.html (https://www.aliexpress.com/item/33004483750.html)
https://www.aliexpress.com/item/1005006312639453.html (https://www.aliexpress.com/item/1005006312639453.html)
Front cover:
https://grabcad.com/library/rigol-dho-800-900-front-cover-1 (https://grabcad.com/library/rigol-dho-800-900-front-cover-1)
artur
-
My question: is it possible to execute Bode analyzes with an external function generator, as my model doesn't have the internal function generator? The menu option is not shown.
Congratulations on fixing and upgrading your scope!
Unfortunately external function generators are not supported for Bode analysis. It's an approach Rigol has not implemented on any of their scopes -- they always rely on a built-in module. While Rigol is not offering the signal generator as a retrofittable option either, user @mechatrommer here is working on a reverse-engineered signal generator module that can be added to DHO800 and 900 scopes.
-
Tried and followed the manual that provided
rk3399_rigol:/ $ su
rk3399_rigol:/ # cd /rigol/data
rk3399_rigol:/rigol/data # chmod 777 generate_all_options
rk3399_rigol:/rigol/data # ./generate_all_options
Rigol 'vendor.bin' encoder/decoder v1.2 - Zelea
-----------------------------------------------------------
Model: DHO814
SN: DHO8AXXXXXXX
MAC: XXXXXXXXXXX
-----------------------------------------------------------
Generating options for DHO814
-----------------------------------------------------------
RLU BW7T10 EMBD AUTO COMP
-----------------------------------------------------------
rk3399_rigol:/rigol/data # exit
rk3399_rigol:/ $ exit
And after reboot there are no additional options like CAN decoding.
FW version is:
Firmware Revision: 00.01.02
I did a whole backup beforehand and i did copy /rigol/data to my pc (Key.data and vendor.bin)
-
Tried and followed the manual that provided
rk3399_rigol:/ $ su
rk3399_rigol:/ # cd /rigol/data
rk3399_rigol:/rigol/data # chmod 777 generate_all_options
rk3399_rigol:/rigol/data # ./generate_all_options
Rigol 'vendor.bin' encoder/decoder v1.2 - Zelea
-----------------------------------------------------------
Model: DHO814
SN: DHO8AXXXXXXX
MAC: XXXXXXXXXXX
-----------------------------------------------------------
Generating options for DHO814
-----------------------------------------------------------
RLU BW7T10 EMBD AUTO COMP
-----------------------------------------------------------
rk3399_rigol:/rigol/data # exit
rk3399_rigol:/ $ exit
And after reboot there are no additional options like CAN decoding.
FW version is:
Firmware Revision: 00.01.02
I did a whole backup beforehand and i did copy /rigol/data to my pc (Key.data and vendor.bin)
First, see the part of the guide that says:
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...
You can't see if it's fully updated without ^^
Then, you need to make it a 914/924 to get the decoders.
./generate_all_options -M DHO914
-
Is not the 914 model that has more options?
814: Parallel, RS232/UART, I2C, SPI
914: Parallel, RS232/UART, I2C, SPI, CAN e LIN
-
I updated to latest FW that is on Rigol website.
Build date 24/01/03 20:10:46
00.01.02.00.02
Scope reports this as 00.01.02 - weird it should show minor as well.
Interesting enough, now I do have
Auto serial bus trigger and analysis license but status is Limit.
Not sure if it is time limited or anything else.
I will try and do some CAN tests tomorrow but it is a hay days here (farmers are baling and storing hay) and my phone is off the hook.
And yes 914 has more options, LA as well but that is HW dependent.
-
I updated to latest FW that is on Rigol website.
Build date 24/01/03 20:10:46
00.01.02.00.02
Scope reports this as 00.01.02 - weird it should show minor as well.
Interesting enough, now I do have
Auto serial bus trigger and analysis license but status is Limit.
Not sure if it is time limited or anything else.
Yeah, it's odd that we have to use an undocumented feature(Testmode) to uncover the full version number. Without it, normal users wouldn't know which of the last few version updates they have loaded on their 'scope. They didn't think that one thru.
Nobody here understands why Rigol adopted this nonsensical version numbering scheme. --especially given their release rate for updates.
My theory: The "Version Control" person/department is trying really hard to justify their employment.
-
The perception I get from the internet is that both Rigol and Siglent condone hacking at the hobbyist level. If that is true - and it seems to be, as they don’t secure these products very strongly despite knowing the hacking occurs - it’s a bit strange that Rigol makes it so complicated. Or, maybe Rigol is actually trying to prevent the hacks with the new models?
-
The perception I get from the internet is that both Rigol and Siglent condone hacking at the hobbyist level. If that is true - and it seems to be, as they don’t secure these products very strongly despite knowing the hacking occurs - it’s a bit strange that Rigol makes it so complicated. Or, maybe Rigol is actually trying to prevent the hacks with the new models?
I think the common perception is that they are pretty sloppy in some areas of their design(s). In this case it's in the Android implementation. Wish I was a software guy. :-/O
Hey, speaking of software: Does anyone know how to send output msgs to the UART from the bash scripts? I need to test something., Thanks!
-
the key file is derived cryptographically from the serial number in vendor.bin but I don't know if we have the secret key to do it.
Anybody...?
Unless you have inside info, there's no way to know that.
Why not random? Why not based in the MCU ID, the MAC address, etc, etc... Pick your number.
The day you see a validation of that pubkey, it's the day you'll find out how it's generated.
-
The most strange: when I access the About screen, the serial number and all original data is show, along with the new firmware code .....02.
There would be in Linux a way to search for my serial number inside any file?
Those information comes from querer, so?
:wtf:
I'll see tomorrow If the Rigol web control page (the one that we access by web browsing by instrument IP address) gives me some Idea from where It takes such data.
That info is in the FRAM.
I've said this repeatedly but people don't like to read "hundreds" of pages, as Rigol first devised all of this (in the MSO5k and siblings) the vendor.bin and Key.data were only human representations of info that was in the FRAM. The scopes didn't do nothing with the files just per se.
So, they could work without the files present, and could even re-generate them...
The mess they did with the Android porting may have disrupted some of this but, in essence, it should be similar.
-
the key file is derived cryptographically from the serial number in vendor.bin but I don't know if we have the secret key to do it.
Unless you have inside info, there's no way to know that.
Why not random? Why not based in the MCU ID, the MAC address, etc, etc... Pick your number.
Because:
a) If you look at Key.data it starts with the text "brainpool", ie. they use RFC5639 elliptic curve cryptography. It's not random.
b) When you purchase keys they ask for your serial number so it has to be linked to that.
-
a) If you look at Key.data it starts with the text "brainpool", ie. they use RFC5639 elliptic curve cryptography. It's not random.
b) When you purchase keys they ask for your serial number so it has to be linked to that.
a) Or you are being intellectually dishonest with me or you don't understand what you are talking about. When you say that the key is derived "cryptographically" from the S/N, what do you imagine that magic "cryptographic" operation might be? I perfectly know what is ECC and how keys are generated. The magic operation (whatever you imagine it could be) that you were inferring that would produce a key-pair from a S/N could be exactly the same I was inferring that would be used to create the key-pair from a random seed.
b) :wtf: Why couldn't they ask you for the S/N if they had a database with all your purchase info indexed by S/N? Because that's how most of the other players do.
-
The magic operation (whatever you imagine it could be) that you were inferring that would produce a key-pair from a S/N could be exactly the same I was inferring that would be used to create the key-pair from a random seed.
What would be the point? To make life more difficult...?
Serial number is the simplest and doesn't require databases or any other infrastructure.
if they had a database with all your purchase info...
I'm not a corporation with a corporate account.
-
I just network scanned what ports my oscilloscope had listening for connection on (ports 1-2000). As expected the ports for FTP (21-22), HTTP (80), and HTTPS (8080) were listening for connections.
However, port 111 is also listening for network connections. Google says that that is used for RPC (Remote Procedure Calls), but quick tests with `rpcinfo` didn't work. Anyone have any ideas what this port is being used for?
-
IHowever, port 111 is also listening for network connections. Google says that that is used for RPC (Remote Procedure Calls), but quick tests with `rpcinfo` didn't work. Anyone have any ideas what this port is being used for?
Port 111 can be used to search for LXI resp. VXI instruments in the network. A broadcast is sent to the port via UDP and a TCP port is received in response for further communication via LXI resp. VXI/RPC.
Peter
-
/rigol/tools/pmapService listens on port 111.
It's apparently some kind of portmap implementation. No idea where it forwards connections on that port to. A quick look at `strings pmapService` didn't reveal anything immediately obvious.
-
Thanks.
I just ran a complete TCP port scan (1-65535) and found a few more ports:
- 5555 - a raw SCPI stream (e.g., just type in *IDN? and scope will reply
- 20712 - no idea what this port does
- 55555 - adb access
Any ideas on TCP port 20712?
-
I was looking for some way to create an image from the complete sdcard without opening the scope (I bought it one week ago, I don't want to have warranty problems so far), then I'll share the process that worked for me:
adb connect IP:55555
adb root
adb remount
adb pull /dev/block/mmcblk0 rigol-dho804.img
In the terminal, you should be able to see that the pull command shows some sort of buffer, seems like you have a progress and it stuck at some point.
But if you refresh the folder where the file will be persisted, and also click on the .img file Properties, you'll be able to see that the image file slowly increases in size.
The whole process takes about 2h.
This is the first time I'm doing a backup from an Android device from the adb, so I'm not totally sure if it worked. I'm considering that the image should be fine due to the size around 30GB.
For the next steps I will look for any way to mount this img in Windows or I need to buy a 32GB sdcard to flash it.
-
As alternative method, for those who prefer dd (linux fellows :)), the method below also worked for me (I'm running Windows 11).
- Install Cygwin: https://www.cygwin.com/?ref=itsfoss.com (https://www.cygwin.com/?ref=itsfoss.com)
- All the binaries required are available from the standard Cygwin installation.
- Include the Cygwin binaries to the Path variable (in my case the path is C:\cygwin64\bin)
- Open a cygwin terminal and type the commands below:
adb connect ip:55555
adb shell su root dd if=/dev/block/mmcblk0 | pv -i 0.5 > dho804.img
The whole process takes about 2h (not different than the adb pull method).
After that you have a default image, so that you can hack your scope and still sleep in peace.
-
Sharing information regarding alternative remote access to the scope.
There is an application called scrcpy which allows you to remote control the scope:
https://github.com/Genymobile/scrcpy (https://github.com/Genymobile/scrcpy)
- Download the application and unzip it
- In a terminal, connect to your device: adb connect <scope_ip>:55555
- Double click the scrcpy.exe application, at the previously unzipped folder
In my case, I have only the scope as connected device, then scrcpy connects automatically to it.
I read is other posts that some users managed to modify the WebControl.apk to improve the resolution (amazing job btw). :-+
I know that a "native" solution is always better than relying on third-party software, but maybe this scrcpy application can be an alternative for the persons that are not interested or do not have much time to go deep into the apk modification topic. I attached a picture with the comparison.
Some pictures of what can be done (I'm using the Zone Launcher to avoid connecting a wireless keyboard/mouse to the scope):
-
Sharing information regarding alternative remote access to the scope.
There is an application called scrcpy which allows you to remote control the scope:
Thank you for sharing your findings. Proof positive that giant threads like this without a summary page or decent moderators get unwieldy and TL;DR. Things tend to circle back and "get discovered" again every month or two here.
Back in February (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344901/?topicseen#msg5344901)and again in March, scrcpy was mentioned and they talked about pretty severe motion artifacts that makes it fairly unusable for some. A forum search will reveal more if you're curious.
BTW, To newer scope owners: the stock WebControl app is not perfect, but it's pretty useful as-is, without hackin' about. Try it out!
AndyBig's guide to upgrade/hack DHO scopes (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076)
-
Sharing information regarding alternative remote access to the scope.
There is an application called scrcpy which allows you to remote control the scope:
https://github.com/Genymobile/scrcpy (https://github.com/Genymobile/scrcpy)
Perhaps by disabling the stock WebControl we could get better performance in ScrCpy.
-
Sharing information regarding alternative remote access to the scope.
There is an application called scrcpy which allows you to remote control the scope:
Thank you for sharing your findings. Proof positive that giant threads like this without a summary page or decent moderators get unwieldy and TL;DR. Things tend to circle back and "get discovered" again every month or two here.
Back in February (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344901/?topicseen#msg5344901)and again in March, scrcpy was mentioned and they talked about pretty severe motion artifacts that makes it fairly unusable for some. A forum search will reveal more if you're curious.
BTW, To newer scope owners: the stock WebControl app is not perfect, but it's pretty useful as-is, without hackin' about. Try it out!
AndyBig's guide to upgrade/hack DHO scopes (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5344076/#msg5344076)
You're right, when I was reading the content from the previous pages I was looking for instructions to unlock the scope, didn't pay attention to the comments regarding scrcpy.
I saw in other forums that usually a list with useful things/bugs found is pinned in the first page or even in a separated topic. Especially for bugs such approach would be very good.
Webcontrol apk definitely isn't bad, nothing to complain about it so far, but it doesn't allow me to control the scope. With scrcpy I'm able to access all the touch shortcuts I've configured with Zone Launcher, then I can navigate to the other apps I have installed or to the system settings and return to the scope application without mouse/keyboard connected to the scope.
Regarding the latency, I see no difference from the WebControl at this point. However, this h264 codec available doesn't seems to be the most efficient one.
-
Hello everone. I'm newbie here, so i am say Hello.
I have couple weeks DHO804. First what i've do that unlock with vendor file. Every thing went fine.
Second, i tryed to instal modded sparrow.apk (early version 0.21), and this step not went well.
New apk, is not to want install, but i've deinstalled the old one. Rigol stuck on "rigol" screen.
Fortunately i have maked copy original file and i installed back previous version (original).
From that moment i get often stuck on rigol screen, or blank screen, or rigol screen and then black without backlit screen
At this time, cannot to conect via adb to the oscilloscope. Just like brick. Sometimes (rare) boot normal.
I know in orgilinal GEL file firmware there is sparrow.apk, but i don't know how to repack. I thought install original one when
Rigol bootup normaly. Someone tell me how to repack GEL file? Or maybe other help?
For the records Rigol have waranty void stickers and i thougt not remove.
-
At this time, cannot to connect via adb to the oscilloscope. Just like brick. Sometimes (rare) boot normal.
Uninstalling Sparrow.apk should not affect your ability to connect using ADB. Perhaps it would be better to restore the backup of the card and start again from the beginning.
-
At this time, cannot to connect via adb to the oscilloscope. Just like brick. Sometimes (rare) boot normal.
Uninstalling Sparrow.apk should not affect your ability to connect using ADB. Perhaps it would be better to restore the backup of the card and start again from the beginning.
I think the same. But i wondering how to do this without openig case? (warranty sticker) and unfortunately i don't have maked backup of card.
-
Can someone share SD card dump Rigol DHO804? I mean stock version, maked via adb.
Please.
-
Hi. I upgraded my DHO804 to DHO814 with all options. Worked fine, and I did several measurements with it.
This morning, the unit does not boot. The buttons lights up and the fan starts, but the display is black.
I don't think this is related to the hack itself, but maybe the flash memory is somehow corrupted?
Anyhow. Is it possible to interface the unit without opening it? Can I access the bootloader somehow?
-
Does ADB still work?
-
No, not over ethernet. There is activity at the port, but it does not request an IP address.
-
I pulled the SD card. There are no partitions. I assume the card is corrupted.
Are there any procedures for recovering or reflashing the SD card?
-
I pulled the SD card. There are no partitions. I assume the card is corrupted.
Are there any procedures for recovering or reflashing the SD card?
It's not necessarily corrupted. There's no partition table on the SD card itself, or at least standard tools like fdisk don't see it. But the actual partitions, or, rather, filesystems located each at its own offset, do exist.
You can use, for example, testdisk to scan the card (or better its image) for partitions/filesystems and then, knowing the offsets, mount them and see the data.
Regardless of what you do, now that you've pulled the SD card out, make a backup of its image (using dd, for example).
-
I pulled the SD card. There are no partitions. I assume the card is corrupted.
Are there any procedures for recovering or reflashing the SD card?
It's not necessarily corrupted. There's no partition table on the SD card itself, or at least standard tools like fdisk don't see it. But the actual partitions, or, rather, filesystems located each at its own offset, do exist.
You can use, for example, testdisk to scan the card (or better its image) for partitions/filesystems and then, knowing the offsets, mount them and see the data.
Regardless of what you do, now that you've pulled the SD card out, make a backup of its image (using dd, for example).
Thanks a lot! Actually I was just finished investigating and putting back the original vendor.bin on the SD card, before reading your comment.
However, I did exactly what you suggested. For anyone in the same situation, here is how I fixed the scope:
- Made a backup of the SD card with dd
dd if=/dev/sdX of=sd_card_backup.img bs=1M- Used testdisk to find the GPT partitions and it's corresponding offset and size
testdisk sd_card_backup.img
Disk sd_card_backup.img - 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- Mounted the rigol partition
mount -t ext4 sd_card_backup.img /mnt/disk -o offset=2584248320,sizelimit=524288000- Replaced vendor.bin in /data/ with the original file
- Reinserted the SD card and success!
I'm not quite sure what happened, as I successfully upgraded to DHO814 and used it for some time yesterday.
-
I hacked my 804 to a 924 and then ran self calibration. All seems fine and I get a -3 db of around 280mhz. This seems like a really good upgrade path. Thanks to all involved.
-
After researching things further, and getting pointed in the right direction by Fenstergucker and shapirus, here's an updated / corrected list of what network ports the DHO800/900 exposes over Ethernet. Most folks here already know these but this compiled list could be useful for new folks.
- TCP port 21 = FTP (internal storage only, no USB stick support). Handled by tcpsvcd.
- TCP port 22 = SSH for shell access (and related technologies like scp should also work). Handled by sshd.
- TCP port 80 = HTTP. Handled by WebControl.apk.
- TCP and UDP port 111 = Port Mapper (use by LXI/VXI clients to find the LXI/VXI port). Handled by pmapService.
- TCP port 5555 = Raw SCPI. Handled by Sparrow.apk.
- TCP port 8080 = HTTPS. Handled by WebControl.apk.
- TCP ports 9001-9004 = WebSocket support for SCPI? Handled by WebControl.apk.
- TCP and UDP port 20712 = LXI / VXI remote proceedure call (RPC). This supports prognums for VXI Core, Async, and Interrupt interfaces (prognums 0x0607AF thru 0x0607B1). Handled by Sparrow.apk.
- TCP port 55555 = adb (Android Debug Bridge) for shell access, keystroke injection, pull/push files from/to the scope, etc. Handled by adbd.
FTP comments:
As mentioned, FTP only provides access to the internal storage location where users can save/load files (i.e., the "C:" drive). The FTP daemon is launched by /rigol/shell/start_rigol_app.sh via one script line of tcpsvd 0:21 ftpd ftpd -w /data/UserData/ &. It looks like it would be easy to run a 2nd FTP daemon on a non-standard TCP port to offer access to a USB drive. The only wrinkle would be putting it in a script that 1) first checks whether the USB is present and 2) uses the correct path since it varies from USB drive to USB drive (specifically, it varies by the USB VID and PID IDs of the drive).
pmapService comments:
pmapService (a.k.a. port mapper service) appears to be a simpler implementation of the typical port mapper. Rigol ships this program in its FW update file. It's so cut down that it doesn't list what programs are registered with it (i.e. DUMP command to prognum 100000 fails). It does support finding the LXI/VXI port (i.e. GETPORT returns port 20712) but it doesn't bother even checking what program number is being requested. You want the LXI/VXI Core program? It replies with port 20712. You want the grandma-recipes program? It also replies with port 20712. Hmmm. It's not a server-grade implementation... but then again it doesn't need to be and it gets the job done.
Raw SCPI comments:
Raw connections work best, such as Putty's Raw socket feature (or whatever client you prefer on your OS). Telnet clients can be used as a backup, but avoid binary transfers since the telnet client might misinterpret or mangle the data.
ADB comments:
The ADB client is a "Swiss Army knife" of tools. For example, if you want to use the scope's physical USB port for a USB drive instead of a USB keyboard and don't have a USB hub, you can run adb input keyevent <keycode> to inject keystrokes into the scope's Android UI, including special keys. One example is adb shell input keyevent KEYCODE_APP_SWITCH which will let you switch from one Android app to another. By default, Sparrow.apk is the only running app, but you can launch a WWW browser using adb shell input keyevent KEYCODE_EXPLORER and then use KEYCODE_APP_SWITCH to switch back and forth. There is a great adb cheatsheet at https://gist.github.com/Pulimet/5013acf2cd5b28e55036c82c91bd56d8#file-adbcommands
Misc comments:
Looks like there is NsdServiceInfo (mDNS?) filled out for _http._tcp., _lxi._tcp., _scpi-raw._tcp., and _vxi-11._tcp. setup on port 80. I didn't investigate deeply on these.
-
Separate topic from above: Bluetooth support.
Logcat lists several line that make it appear that Bluetooth is running. For example, the line BluetoothManagerService: Stored bluetooth Name=rk3399,Address=22:22:xx:xx:xx:xx (the xx's are to obscure my MAC address). Because Bluetooth is not exposed to typical users of the scope, my assumption is that either:
- Rigol did not fully populate the Bluetooth hardware but there was at least a controller in the hardware or...
- Android's Bluetooth daemon was run and made up a fake MAC address since it didn't find real hardware. This comes from that the 2nd lowest bit of the 1st MAC address is set which means the MAC address was "locally" assigned and not "universal" (i.e. this MAC address was not part of a HW vendor's assigned range).
Thoughts on this?
Update:
After using adb shell, then using cmd statusbar expand-notifications to get access to Android's Setting, it looks like there is no Bluetooth functionality. This isn't surprising.
-
Morning All
I have a DHO804 FW version is 00.01.02.00.02
Trying to follow the latest video:
https://youtu.be/oBfuWxMFSsI?si=oKTufL6XjIHCgyOs
when I connect via ADB I get:
adb server version (39) doesn't match this client (41); killing...
* daemon started successfully
connected to 192.168.1.164:55555
Should I continue??
-
Is it possible to hack the two channel DHO-xx2 into an 4 channel DHO-xx4?
-
Is it possible to hack the two channel DHO-xx2 into an 4 channel DHO-xx4?
Not easily.
The price difference is only 60 bucks, it's certainly not worth doing except as a challenge.
-
Hi,
I have a DHO 804 FW version 00.01.02.00.02 and with your explanations I was successful enabling the additional BW (100M), AUTO serial bus (just CAN, no LIN) and the memory extension 25 to 50MPts. Thx !
Just one question... the extended 50MPts option does only work on single CH1, correct?
Because if CH 2, 3 or 4 are working each in single channel mode the menu just shows 25MPts...
Regards
Roger
-
Hi,
I have a DHO 804 FW version 00.01.02.00.02 and with your explanations I was successful enabling the additional BW (100M), AUTO serial bus (just CAN, no LIN) and the memory extension 25 to 50MPts. Thx !
Just one question... the extended 50MPts option does only work on single CH1, correct?
Because if CH 2, 3 or 4 are working each in single channel mode the menu just shows 25MPts...
Regards
Roger
If the trigger remains on channel 1, then it eats up memory and sampling frequency as a full-fledged channel. In fact, channel 1 in this case remains fully turned on, it is simply not displayed.
-
Thx, AndyBig.
Of course, that's the reason for cutting the memory :palm:.
And thank you very much for your perfect summary in Reply #1507.
This was really a big help for a noob like me :-+
You and the other cracks here, keep up with your good work :clap: !
-
Hi all. I've just ugraded from my old Modded Hantek (thanks EEV blog) to a DHO814. I was looking forward to some better display etc on my PC monitor so looked at adding the WiFi dongle (TP Link TL-WN725N Ver:3.0) as described on TheRetroChannel YouTube. However it seems Rigol may have blocked this method. When I open up the Android settings on the scope all i get in the WiFi section is a "Disabled" label with a switch next to it. The system won't let me turn it on though, it just flicks it's self back to off again.
It appears I'm on the latest version of the Firmware: v01.02.00.02.
Am I missing something? Has anyone else found this to be the case? Anyone have a solution?
Thanks in advance all.
-
Hi all. I've just ugraded from my old Modded Hantek (thanks EEV blog) to a DHO814. I was looking forward to some better display etc on my PC monitor so looked at adding the WiFi dongle (TP Link TL-WN725N) as described on YouTube. However it seems Rigol may have blocked this method. When I open up the Android settings on the scope all i get in the WiFi section is a "Disabled" label with a switch next to it. The system won't let me turn it on though, it just flicks it's self back to off again.
It appears I'm on the latest version of the Firmware: v01.02.00.02.
Am I missing something? Has anyone else found this to be the case? Anyone have a solution?
Thanks in advance all.
What's the hardware revision of your specific wifi dongle? It's specified somewhere on the box. There were some known not to work (due to a different wifi chip).
The usb vendor id / product id pair might also be different. A known working one is shown by lsusb as:
Bus 001 Device 009: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Kernel module: rtl8xxxu. You can check if it gets loaded using lsmod.
-
Revision 2.0 and 3.0 both US and EU should work perfectly.
-
Hi all. I've just ugraded from my old Modded Hantek (thanks EEV blog) to a DHO814. I was looking forward to some better display etc on my PC monitor so looked at adding the WiFi dongle (TP Link TL-WN725N) as described on YouTube. However it seems Rigol may have blocked this method. When I open up the Android settings on the scope all i get in the WiFi section is a "Disabled" label with a switch next to it. The system won't let me turn it on though, it just flicks it's self back to off again.
It appears I'm on the latest version of the Firmware: v01.02.00.02.
Am I missing something? Has anyone else found this to be the case? Anyone have a solution?
Thanks in advance all.
What's the hardware revision of your specific wifi dongle? It's specified somewhere on the box. There were some known not to work (due to a different wifi chip).
The usb vendor id / product id pair might also be different. A known working one is shown by lsusb as:
Bus 001 Device 009: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Kernel module: rtl8xxxu. You can check if it gets loaded using lsmod.
I have the Version 3.0. which checks out to be RTL8188EU 802.11n in Device Manager on the PC.
Brand new to this scope so have no clue what you are refering to in the code line you gave. What's lsmod?
Thanks
-
What's lsmod?
It's a Linux command.
https://en.wikipedia.org/wiki/Lsmod
do
adb shell lsmod
also
adb shell lsusb
to see your usb devices
-
What's lsmod?
It's a Linux command.
https://en.wikipedia.org/wiki/Lsmod
do
adb shell lsmod
also
adb shell lsusb
to see your usb devices
Hi again. I have no clue on using adb as yet, not had time to look into it.
Am I correct that this is what I need? https://developer.android.com/tools/releases/platform-tools
Or do I have to install the whole Android Studio suite? And can you point me in the right direction for info on how to use it to connect to the scope. I', guessing I may find this on TheRetroChannel...
Thanks for the pointers!
-
Hi again. I have no clue on using adb as yet, not had time to look into it.
Am I correct that this is what I need? https://developer.android.com/tools/releases/platform-tools
Yes.
Or do I have to install the whole Android Studio suite?
No.
And can you point me in the right direction for info on how to use it to connect to the scope. I', guessing I may find this on TheRetroChannel...
Maybe EEVBLOG forums...?
eg. This entire thread is about people hacking their 'scopes with ADB.
-
Maybe EEVBLOG forums...?
eg. This entire thread is about people hacking their 'scopes with ADB.
LOL. Message recieved. I'll do some research over the next few days and get back with my results.
Thank you.
-
Where can I get a generator board for our oscilloscope?
-
Where can I get a generator board for our oscilloscope?
What do you want to generate?
-
he wants to generate functions or waveforms,
they call it FunctionGenerator, ArbWaveformGenerator or AWG.
see friend Mechatrommer here:
https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot/ (https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot/)
-
he wants to generate functions or waveforms,
The internal AWG board of the DHO900?
-
I just got Bluetooth working with the Edimax EW-7611ULB (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/bluetooth/ew-7611ulb) (not V2) Bluetooth/Wifi combo adapter
Now also works with the Edimax EW-7611ULB V2 (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/bluetooth/ew-7611ulb_v2/).
-
What's lsmod?
It's a Linux command.
https://en.wikipedia.org/wiki/Lsmod
do
adb shell lsmod
also
adb shell lsusb
to see your usb devices
@Fungus Hi, me again.
So I connected to the scope via ethernet and ran the commands you suggested. This is what I got back (see pic 1). The first "lsusb" command is with the WiFi dongle plugged into the scope. The second run of the command "lsusb" is without the WiFi dongle. So the scope seems to be seeing the dongle in the port OK (Device ID: 0bda:8179). The second photo shows the output with a Hub, dongle and keyboard connected. The keyboard works fine so the USB on the scope is working. The Wifi dongle works fine on my PC so I know that's OK, and I'm pretty sure it's the right version (TP-Link WN725N Ver:3.0). But I still get the same "WIFi disabled" and I'm still unable to switch it on with the switch in Android settings. I've serched the forum to the best of my ability and can't find any similar issue from anyone else.
It appears that the Kenrnal Module rtl8xxxu you mention is missing. So I'm not sure what to do next. Can it be installed? Where do I find it if so and how do I do that.
Cheers...
P.S. Sorry for all the questions but I've only had the scope for 4 days and don't know anything at all about Android.
-
So I connected to the scope via ethernet and ran the commands you suggested. This is what I got back (see pic 1). The first "lsusb" command is with the WiFi dongle plugged into the scope.
Did you plug it in before you powered on? I think it only checks for the WiFi dongle at startup.
note: You don't need a keyboard for this, you can open the settings with:
adb shell am start com.android.settings
-
That was it :-DD. I dont know why the hell I didn't think about that...
All connected and working properly now. Thank you so much for your help.
Appreciations.
D.
-
I've just bought DHO804. It came with first version of firmware and it did not have CAN analyzer.
After firmware update, now DHO804 became to make CAN signal analyze.
I didn't hack the scope. Just firmware update. Am I missing something, because normally DHO 804 have not CAN analyze feature. :-DD
(https://i.hizliresim.com/j0w5xtp.png)
-
I didn't hack the scope. Just firmware update. Am I missing something, because normally DHO 804 have not CAN analyze feature. :-DD
Normally it's a DHO904 feature. :-//
What does it show on your "Options" screen?
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2313153;image)
-
Hi,
my DHO804 has the CAN option, too. But my copy has the CAN analyzing function since applying the hacks to enable BW7to10, AUTO and Memory expansion all found in the opts.txt by SCPI command. So it's still a DHO804, the DHO model was not changed.
However, LIN option doesn't appear.
-
my DHO804 has the CAN option, too. But my copy has the CAN analyzing function since applying the hacks to enable BW7to10, AUTO and Memory expansion
However, LIN option doesn't appear.
Mine doesn't.
CAN and LIN are the item in the licensing, so something is weird.
What does your "Options" screen show?
-
Hope the pics speak for themself :)
-
iam going to buy this scope and maybe hack it if i can do i buy the 200mhz probes or 100mhz ? Rigol DHO802
-
iam going to buy this scope and maybe hack it if i can do i buy the 200mhz probes or 100mhz ? Rigol DHO802
just keep the ones that come with the scope, they're good enough.
p.s. get a DHO804 instead.
-
i need 1:100 probes for crt work etc wil buy the 804
-
This is my option screen.
I don't know how but it's very good to have CAN analyze function :-DMM
(https://i.hizliresim.com/fhybis0.png)
-
This is my option screen.
I don't know how but it's very good to have CAN analyze function :-DMM
Is the CAN function = 'Auto Serial Bus' trigger and analysis? If so, that is a trial license with a limited number of times you can use it before that function is automatically disabled.
-
This is my option screen.
I don't know how but it's very good to have CAN analyze function :-DMM
Is the CAN function = 'Auto Serial Bus' trigger and analysis?
Yes. It's interesting that it's available though, I've never seen it on a DHO800 before.
Maybe Rigol is planning something.
If so, that is a trial license with a limited number of times you can use it before that function is automatically disabled.
Yep.
But RogerG has it forever...
-
Hi,
my DHO804 has the CAN option, too. But my copy has the CAN analyzing function since applying the hacks to enable BW7to10, AUTO and Memory expansion all found in the opts.txt by SCPI command. So it's still a DHO804, the DHO model was not changed.
However, LIN option doesn't appear.
How did you do the hack?
|O
-
I did as described in this post:
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)
Second way - generation of additional options
Auto was the option for can trigger and analysis.
-
found this if some one wants to make one for them selfs
https://github.com/LorenceChen/DHO800_BatteryPack
-
Factory non-hacked CAN decode/triggering on the DHO800 series was added in ~January with the later firmware updates - it wasn't supported originally, but is supported now (firmware v1.02), and is included in the newer datasheet/user manual. LIN bus is not [yet?] supported.
I'm not sure if the Auto Serial Bus "Limit" in the options refers to a limited number of uses before needing to buy a license or it means that the support is limited (no LIN bus)?
There are issues with a 10x probe and CAN protocol decode - https://www.eevblog.com/forum/testgear/rigol-dho814-capturing-can-frames/msg5406683/#msg5406683 (https://www.eevblog.com/forum/testgear/rigol-dho814-capturing-can-frames/msg5406683/#msg5406683)
-
i need 1:100 probes for crt work etc wil buy the 804
you'll want to check the voltage vs frequency derating curve for the probes you're planning to get.
for basically any passive probes, their max allowed voltage goes down pretty quickly with frequency getting beyond 0.1-1 MHz or so, definitely no HV probing at 100+ MHz.
-
i need 1:100 probes for crt work etc wil buy the 804
you'll want to check the voltage vs frequency derating curve for the probes you're planning to get.
for basically any passive probes, their max allowed voltage goes down pretty quickly with frequency getting beyond 0.1-1 MHz or so, definitely no HV probing at 100+ MHz.
For any work on a crt I'd consider differential probes... And if you're looking at the really high voltages definitely get a proper HV probe.
-
I'm not sure if the Auto Serial Bus "Limit" in the options refers to a limited number of uses before needing to buy a license or it means that the support is limited (no LIN bus)?
It means it's time-limited. It will be disabled after you use the 'scope for a while (40 hours?)
There are issues with a 10x probe and CAN protocol decode
ALL of the serial decoders have a bug where the threshold level isn't multiplied by the probe setting (nb. The attenuation setting, not the physical switch on the probe).
If you don't set the probe to 1x in the vertical menu then you have to multiply your threshold voltage by 10 (the line will be off the top of the screen).
Me? I set it to 1x for serial decoding and the level marker on screen works perfectly.
-
I'm not sure if the Auto Serial Bus "Limit" in the options refers to a limited number of uses before needing to buy a license or it means that the support is limited (no LIN bus)?
It means it's time-limited. It will be disabled after you use the 'scope for a while (40 hours?)
From the User Guide -
The instrument is installed with the trial versions of the options before leaving
factory. The trial time starts from the time when you power on the instrument for
the first time, and the trial time is about 2,160 minutes.
2,160 / 60 = 36 hours running time
I don't have a Rigol scope, but I'd assume there are hacks available that make those options permanent anyway?
-
https://www.eleshop.nl/owon-oscilloscope-probes-2kv.html (https://www.eleshop.nl/owon-oscilloscope-probes-2kv.html)
-
I wouldn't trust a probe in 2kV range, where the ground cable is isolated just with a thin layer of shrink tubing, as seen on the picture in eleshop.
For mains I use a properly isolated Stäubli Isoprobe III with fixed 1:10, which has CAT III 1000 V + CAT IV 600 V rating. They have a separate ground cable with clip, also with its own CAT rating. These probes come in a wide variety, also with higher voltages and 1:100. But this safety has its price:
https://www.staubli.com/de/en/electrical-connectors/products/t-m-products/high-frequency-measurement/touch-protected-passive-probes.html (https://www.staubli.com/de/en/electrical-connectors/products/t-m-products/high-frequency-measurement/touch-protected-passive-probes.html)
-
this one almost 100 euros in the netherlands https://www.conrad.nl/nl/p/staubli-set-isoprobe-iii-hp-sonde-aanraakveilig-35-mhz-100-1-3540-v-126120.html?WT.mc_id=affiliates%3Atradetracker%3Afeed%3A126120&utm_medium=affiliate&utm_source=tradetracker&utm_campaign=308958&utm_content=Shoparize.com+Shopping (https://www.conrad.nl/nl/p/staubli-set-isoprobe-iii-hp-sonde-aanraakveilig-35-mhz-100-1-3540-v-126120.html?WT.mc_id=affiliates%3Atradetracker%3Afeed%3A126120&utm_medium=affiliate&utm_source=tradetracker&utm_campaign=308958&utm_content=Shoparize.com+Shopping)
if the ground wire is to thin or not enough isolated is it dangerous for me or for the scope ?
-
For you.
There's always the chance that you get the live wire on the ground cable depending from what you're doing. These shrink tubes are very thin. Another point is that you can have the live wire at the outer case of the bnc then. That's why I use a scope with isolated BNCs for this task.
-
For you.
There's always the chance that you get the live wire on the ground cable depending from what you're doing. These shrink tubes are very thin. Another point is that you can have the live wire at the outer case of the bnc then. That's why I use a scope with isolated BNCs for this task.
Or a differential probe... Technically not 'isolated', but exponentially safer than a passive probe with a ground lead. Especially useful if the device chassis isn't grounded to earth, like much crt gear.
-
than maybe its best if i buy this one Stäubli SET Isoprobe III-HP Sonde Aanraakveilig 35 MHz 100:1 3540 V
only thing i dont understand is the 35mhz ?
-
than maybe its best if i buy this one Stäubli SET Isoprobe III-HP Sonde Aanraakveilig 35 MHz 100:1 3540 V
only thing i dont understand is the 35mhz ?
That means the probe is only rated for 35MHz - any higher frequencies will be attenuated beyond 3db. And it's a bit out of my experience, but high voltages are frequency dependent, so that probe may not handle it's rated voltage if that voltage goes beyond 35MHz.
-
I did as described in this post:
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)
Second way - generation of additional options
Auto was the option for can trigger and analysis.
Thanks I did it :)
(https://i.hizliresim.com/hb9szli.png)
-
Perfect.
Did BW expansion to 100MHz work, too?
-
Perfect.
Did BW expansion to 100MHz work, too?
Of course!
(https://i.hizliresim.com/h8vaknk.jpeg)
-
ALL of the serial decoders have a bug where the threshold level isn't multiplied by the probe setting (nb. The attenuation setting, not the physical switch on the probe).
If you don't set the probe to 1x in the vertical menu then you have to multiply your threshold voltage by 10 (the line will be off the top of the screen).
Me? I set it to 1x for serial decoding and the level marker on screen works perfectly.
I thought I was going crazy with this issue a while ago. Ugh.
Do we know if anyone reported this to Rigol yet?
-
Is it possible to build a clock with a battery into an oscilloscope? So that the clock does not go astray.
-
Is it possible to build a clock with a battery into an oscilloscope? So that the clock does not go astray.
It's much easier to add WiFi and let it get the time over the network.
(which it does automatically)
-
Do we know if anyone reported this to Rigol yet?
They know about it, for sure.
Why they aren't putting out an update is a mystery. It seems like a bug that will affect a lot of people if they don't know the workaround.
-
Is it possible to build a clock with a battery into an oscilloscope? So that the clock does not go astray.
It is better to allow it to get the time from the network, but you need to select the proper time zone. The extended UI shows the date and time automatically if a valid time is retrieved from the internet.
-
Since DSRemote wasn't made to work with DHO800 and DHO900 series, I just ported it by myself.
It wasn't fully tested, but it works :scared: At least with DHO924S and Debian 12.5.
Exporting waveform (to a file) from internal memory doesn't work and I have no idea why. According to DHO800-Series_programmingguide_EN.pdf it should work. Command :WAV:DATA? return is: "The instruction is not supported!". Please let me know, if somebody knows how to do it.
Source code and precompiled binary: https://github.com/norbertkiszka/DSRemote_DHO800_DHO900
Feel free to use at Your own risk :-BROKE
PS. I didn't announced Debian and Ubuntu build script yet, so there it is: https://github.com/norbertkiszka/orangerigol
-
Thanks, did have a quick tryout.
Really pleased; keep up the good work!
Some remarks (running under ubuntu 22.04.3 LTS)
- user 100 does not have the right permissions straight out of the box. Issue a chmod 0700 /run/user/1000/
- saving to waveform data does not work
- sometimes get an error that the bitmap (from save screenshot scope)m has the wrong size.
- If you invert a channel, the corresponding label is not updated (no down arrow) at the end
-
Nothing new about the DHO :wtf: ?
-
Nothing new about the DHO :wtf: ?
Just bored, or were you waiting for anything specific? ::)
-
Nothing new about the DHO :wtf: ?
Just bored, or were you waiting for anything specific? ::)
If somebody is bored, (s)he can help me with this:
https://www.youtube.com/watch?v=2y0E4PasLPY (https://www.youtube.com/watch?v=2y0E4PasLPY)
-
If somebody is bored, (s)he can help me with this:
Help you calculate something on a calculator or help you play solitaire? :)
-
If somebody is bored, (s)he can help me with this:
Help you calculate something on a calculator or help you play solitaire? :)
With modifying Linux kernel code, to load Rigol modules from their kernel (they don't care about GPL license - which is very bad). Or eventually with forcing their kernel to work with this (should be easier). With that, it should be possible to run Rigol scope app and use this thing also as a scope.
Edit: also somebody can help with forcing DSRemote with exporting waveform data from this scope models.
-
Just bored, or were you waiting for anything specific? ::)
what is the last "goto" version for easy hacking. (Improved tool, not hacking as PoC is the key).
-
With modifying Linux kernel code, to load Rigol modules from their kernel ...
Why change Android to Debian in the first place? What improvement will this bring to the oscilloscope as a tool on the developer's desktop?
-
With modifying Linux kernel code, to load Rigol modules from their kernel ...
Why change Android to Debian in the first place? What improvement will this bring to the oscilloscope as a tool on the developer's desktop?
More useful software on this scope. Which also means easier and faster hacking of a original app.
-
I tried DHO804 with 30.000mAh battery bank.
It worked around 2.5 hours. FYI.
(https://i.hizliresim.com/jsxary6.jpeg)
-
Just bored, or were you waiting for anything specific? ::)
Waiting for new FW or another interesting hack :popcorn:.
-
Just bored, or were you waiting for anything specific? ::)
Waiting for new FW or another interesting hack :popcorn:.
Do Your own one and share it with us.
-
Just bored, or were you waiting for anything specific? ::)
Waiting for new FW or another interesting hack :popcorn:.
Do Your own one and share it with us.
... or consider actually using the scope to measure something interesting. :P
-
...
Exporting waveform (to a file) from internal memory doesn't work and I have no idea why. According to DHO800-Series_programmingguide_EN.pdf it should work. Command :WAV:DATA? return is: "The instruction is not supported!". Please let me know, if somebody knows how to do it.
...
I've seen ":WAV:DATA?" work but only for the analog channels. It doesn't work properly for LA channels (D0, D1, etc) due to bugs causing an earlier ":WAVeform:SOURce D0" to fail.
Attached is a Python file from Rigol that I think I haven't changed too much. This should still be in its original working form, but not guaranteed.
-
Thank you very much, I managed to make 924S from 914. I really want the signal generator to work. What needs to be done? Has anyone tried to do this? Thank you.
-
Thank you very much, I managed to make 924S from 914. I really want the signal generator to work. What needs to be done? Has anyone tried to do this? Thank you.
You have to add another PCB inside it.
They don't sell them, you have to make it yourself.
-
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.
Hello, I have a question about using DHO800 series scope as an android tablet. If I will install launcher on this scope and other android apps, do these changes slow down oscilloscope's performance? Has anyone noticed any glitches or bugs? Thanks.
-
Hello, I have a question about using DHO800 series scope as an android tablet. If I will install launcher on this scope and other android apps, do these changes slow down oscilloscope's performance? Has anyone noticed any glitches or bugs? Is it safe to install other android apps on this scope? Thanks.
Im using DHO924S with other apps including games. But DHO800 series probably has less RAM for a CPU (RK3399). In both cases, there is no swap on the SD card.
Anyway, I advice to do a SD card image backup.
-
Hello, I have a question about using DHO800 series scope as an android tablet. If I will install launcher on this scope and other android apps, do these changes slow down oscilloscope's performance? Has anyone noticed any glitches or bugs? Thanks.
There isn't a slowdown, you can see in the video how the Rigol performs along with another applications: https://youtu.be/OXJZxY9YVwE?si=aRrtFxmTiAf2bcxa
-
Thank you very much, I managed to make 924S from 914. I really want the signal generator to work. What needs to be done? Has anyone tried to do this? Thank you.
You have to add another PCB inside it.
They don't sell them, you have to make it yourself.
And if you solder a microcircuit in place of the missing one, it might work. And the generator signal will go. Has anyone tried to do this? The boards of the 914 and 924Ы are the same, only one microcircuit is missing. Thank you.
-
And if you solder a microcircuit in place of the missing one, it might work. And the generator signal will go. Has anyone tried to do this? The boards of the 914 and 924Ы are the same, only one microcircuit is missing. Thank you.
There, for the generator, you need not just one microcircuit, but a whole printed circuit board with dozens of components :)
-
And if you solder a microcircuit in place of the missing one, it might work. And the generator signal will go. Has anyone tried to do this? The boards of the 914 and 924Ы are the same, only one microcircuit is missing. Thank you.
There, for the generator, you need not just one microcircuit, but a whole printed circuit board with dozens of components :)
Thank you. Is there a photo of the board from the DHO924S oscilloscope?
-
Thank you. Is there a photo of the board from the DHO924S oscilloscope?
DHO924S:
-
Simple to make!
-
Simple to make!
Sure. :)
@Mechatrommer has tried, but I am not sure what the current status is, and I can't find the thread where he reported on his progress. Last I recall it was "kind of working"?
Edit:
Found the relevant thread on bringing up Mechatrommer's DIY function generator PCB. The most recent update seems to be this:
Any news?
After 2 mons waiting no changes?
I have a question - in the beginning, you couldn't get an X-ray of the original board?
I think things would go much faster.
i too wished someone with the original module can do the xray and complete BOM but, i cant wait for such hope. btw still stuck with other things i cant get back to progress yet... cheers.
-
My DHO804 is not booting. Today, after pressing power button the other buttons light up for a moment (as usual) and than there is only a black screen. Tried two different power supplies.
Do you guys have any ideas?
-
My DHO804 is not booting. Today, after pressing power button the other buttons light up for a moment (as usual) and than there is only a black screen. Tried two different power supplies.
Do you guys have any ideas?
If You have void warranty, try to remove SD card, clean contacts and put it back firmly. Please remember to use ESD protection(s).
On top right side, there is a RK808 as a switching converter, so You can check voltages after pressing power.
Emergency shutdown is available after pressing power for a couple seconds.
From which city are You? Eventually, maybe I will be able to help.
BTW. IMHO this should be as a separate topic.
-
Poking SD card through the vent hole helped! I did not want to remove warranty sticker.
Greeting from Gdańsk!
-
Poking SD card through the vent hole helped! I did not want to remove warranty sticker.
Greeting from Gdańsk!
I was hacking and modifying my DHO924S. Often I was flashing SD with my own software (see my "signature" in my footer) and sometimes that (bad card connection) was the reason of not booting with silence on a UART (goldpins close to a SD card).
Speaking of modifying. It's possible to gain bandwidth up to ~1 GHz on this puppy (with higher noise, so it's a good idea to mod one or two channels only) and even lowering the input noise (I did it partially). But this is a very precise SMD work.
BTW. If You don't want to remove sticker, I advise to make a backup of most important files from a /rigol directory via adb and a network or usb connection.
Anyway, support from a Rigol is very very bad in my opinion. Next time I will buy Siglent at least.
Greetings from a Crackow/Kraków.
-
Hello .
A quick question, I have a DH804 with the upgrades mentioned here, it has firmware 00.01.02, it has a more recent firmware version V00.01.03.00.06
If I update the firmware, the upgrades continue normally on the correct device?
Thanks.
-
Hello .
A quick question, I have a DH804 with the upgrades mentioned here, it has firmware 00.01.02, it has a more recent firmware version V00.01.03.00.06
Wow no way! So they did finally release a new firmware. I thought it would never happen.
If I update the firmware, the upgrades continue normally on the correct device?
Well, apparently it was released today, so it's not very likely that anyone has already tried it. Maybe someone will be brave enough to try it out and let all of us know :)
-
Well, apparently it was released today, so it's not very likely that anyone has already tried it. Maybe someone will be brave enough to try it out and let all of us know :)
I started a thread. :)
Note: These 'scopes can be downgraded if a firmware doesn't work out. The upgrade process uses a shell script to extract the files from an archive and there's no version checking or anything like that in the script.
FWIW:
The upgrade process is:
a) Shell command to uninstall the android app
b) tar xf DHO800_DHO900_Update.GEL ...
c) Shell command to install the new android app
-
Well, apparently it was released today, so it's not very likely that anyone has already tried it. Maybe someone will be brave enough to try it out and let all of us know :)
Im almost ready to test new and old bugs in new firmware. Almost, because I had small accident yesterday. Scope is ok, but me not so much :-BROKE
Note: These 'scopes can be downgraded if a firmware doesn't work out. The upgrade process uses a shell script to extract the files from an archive and there's no version checking or anything like that in the script.
Best idea is to make a backup as a SD card image. No matter what will fail (including SD card itself), You can always flash it back.
If somebody don't want to remove warranty sticker, there is always ADB available. It's even possible to get SD card image in that way, but it will be good idea to run fsck on every FS (partition) directly on a image file (in Linux files can be used as a disk, even without partition table as in this case). However, working on a Android is a pain in the a** in compare to a normal Linux/GNU distribution.
-
Best idea is to make a backup as a SD card image. No matter what will fail (including SD card itself), You can always flash it back.
Such a lot of work. :scared:
I already upgraded, the thread is here:
https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-1-03/ (https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-1-03/)
-
Such a lot of work. :scared:
Two minutes including coffee plus time for copying. Unless You are using Windows, then Im sorry.
-
Just for those who don't know:
You can restart the 'scope app in a couple of seconds after pushing a vendor.bin. No need to reboot or worry about file system sync.
You need to be in root mode:
adb root
Then kill and restart the rigol app:
adb shell kill -9 $(pidof com.rigol.scope)
adb shell am start -n com.rigol.scope/.MainActivity
nb. It restarts automatically all by itself after you kill it but it can take 10 seconds or so.
You can put all that in a .bat file and just double-click it to switch between 'scope models in a few seconds. :)
After I'm done messing around I always do a file system sync just to be safe:
adb shell sync
-
.bat file
.bat or .sh?
-
If you have the DHO connected to a Windows machine is ".bat" for Linux and MacOS use a proper formatted ".sh"
-
If you have the DHO connected to a Windows machine is ".bat" for Linux and MacOS use a proper formatted ".sh"
.sh is not directly system related. .sh stands for a POSIX shell script file. Also in *BSD systems and Android. I don't know if Windows is a POSIX compatible (Im not using it).
-
You can use the sh command from git bash (https://www.atlassian.com/git/tutorials/git-bash) like
C:\>sh my-script-test.sh
.
If you have the DHO connected to a Windows machine is ".bat" for Linux and MacOS use a proper formatted ".sh"
.sh is not directly system related. .sh stands for a POSIX shell script file. Also in *BSD systems and Android. I don't know if Windows is a POSIX compatible (Im not using it).
-
.sh is not directly system related. .sh stands for a POSIX shell script file. Also in *BSD systems and Android. I don't know if Windows is a POSIX compatible (Im not using it).
I was referring to @Fungus' instructions, but you can also use “.sh” in Windows if you have MSYS, WSL, etc. but that's another discussion.
-
I don't know if Windows is a POSIX compatible (Im not using it).
It isn't. And neither are most Linux systems.
-
I was referring to @Fungus' instructions...
You all know what I meant...
Jeez.
-
Will the hack remain if I update my oscilloscope with new firmware?
-
Yes
-
Will the hack remain if I update my oscilloscope with new firmware?
Depends on what your "hack" was.
-
.bat file
.bat or .sh?
adb is being ran from windows, so bat file there.
.sh means little on linux, the 1st line of a shell script defines how it will execute. Shell script needs +x permission, or at least a 700 if you're in as root.
-
I did the hack according to the instructions in this video. Will the hack be saved on my oscilloscope when flashing to version 03?
https://youtu.be/oBfuWxMFSsI?si=1lZ1eMA1Vw_xhvii
-
I'll answer myself. I updated from a flash drive and everything is fine.
-
Simple to make!
Sure. :)
@Mechatrommer has tried, but I am not sure what the current status is, and I can't find the thread where he reported on his progress. Last I recall it was "kind of working"?
sorry for late reply i havent attend eevblog lately. i need to organize my life and still trying to complete other tasks... anyway, yes its working but noise spec is not really nice.. thats the last hindrance imho... few weeks ago i tried to get back to it for a moment, but i'm still at 5-10mVpp noise/crosstalk after some quick tin hat hack. i have pcb ver3 that i havent populate but guesstimating from current situation, i might not get very far with this, i might need to do total components reshuffling to move away smps noise to somewhere farther (i tried to be cheap on smps i think this is what shot me back), but since space is limited i cant do much, the other option is to follow closely how smpses in original board are made and what ICs used. i hope i can get back populating pcb ver3 soon and i think that will be the last revision i'm gonna do before publishing report, whatever the noise figure will be.. i'm tired of this there a lot of other tasks suspended because of this hobby. cheers.
-
i'm tired of this there a lot of other tasks suspended because of this hobby. cheers.
If the question is: Is it cost effective to do this instead of paying $100 for the signal generator?
(which I think is what the OP was after...)
I'll say "no".
-
If the question is: Is it cost effective to do this instead of paying $100 for the signal generator?
(which I think is what the OP was after...)
I'll say "no".
The OP has already bought a DHO914 without the signal generator, hence retrofitting a DIY version would be his only option. (Short of selling the scope at a loss and getting a new one.) But I agree with your conclusion, even if it comes too late for the OP.
-
If the question is: Is it cost effective to do this instead of paying $100 for the signal generator?
(which I think is what the OP was after...)
I'll say "no".
The OP has already bought a DHO914 without the signal generator, hence retrofitting a DIY version would be his only option. (Short of selling the scope at a loss and getting a new one.) But I agree with your conclusion, even if it comes too late for the OP.
Better to sell that one and get one with signal generator than try and make a PCB.
-
Better to sell that one and get one with signal generator than try and make a PCB.
I would shy away from the DIY upgrade too, especially in view of the hacking required to install the front panel button and back BNC jack. Even better to do one's research before buying the scope... ::)
In the OP's current situation I would probably opt for a stand-alone dual-channel signal generator. That won't enable automated Bode plots -- unless either Rigol decides to support external generators at some point, or one of the experts on this forum comes up with a dedicated Bode App to run on the scope. But you get a much more capable signal generator, and for the large majority of applications would come out ahead.
-
Do it the old fashioned way of twisting the frequency knob on the SG while eyeballing the phase/amplitude on the 'scope. :)
-
If the question is: Is it cost effective to do this instead of paying $100 for the signal generator?
(which I think is what the OP was after...)
I'll say "no".
The OP has already bought a DHO914 without the signal generator, hence retrofitting a DIY version would be his only option. (Short of selling the scope at a loss and getting a new one.) But I agree with your conclusion, even if it comes too late for the OP.
the aim is an upgrade from DHO804 to DHO924S which i look at aliexpress currently still at ~$400 difference... plus i want to challenge myself and learn, or push the limit to where the DHO800 can be hacked/upgraded... upgrading DHO914/924 to DHO914S/924S by doing diy FG module thinking it can save money is not a good conclusion i agree...
In the OP's current situation I would probably opt for a stand-alone dual-channel signal generator. That won't enable automated Bode plots -- unless either Rigol decides to support external generators at some point, or one of the experts on this forum comes up with a dedicated Bode App to run on the scope. But you get a much more capable signal generator, and for the large majority of applications would come out ahead.
i have standalone Uni-T UTG962 AWG to play with, previously i used diy standalone FG, changing frequency requires turning trimpot knobs no USB PC API capability at all :palm: it was fun though... and i did exercise much earlier to make automated pc app to bode plot using Rigol DS1052E and Hantek DDS3X25, if i want i can just upgrade the app to support UTG962 and DHO800/900 or DS1054Z, but time is becoming limited around here... it seems i got hooked up easily (i think) when there's FG related project that i think i can do it at cheap. i must be very carefull next time ::) cheers.
-
the aim is an upgrade from DHO804 to DHO924S which i look at aliexpress currently still at ~$400 difference... plus i want to challenge myself and learn, or push the limit to where the DHO800 can be hacked/upgraded... upgrading DHO914/924 to DHO914S/924S by doing diy FG module thinking it can save money is not a good conclusion i agree...
Fully understand -- since you do the development yourself, this becomes a hobby project in its own right. I have no concerns at all about that and applaud your effort! :-+
When I (and, I believe, Fungus) was referring to "the OP", that meant user VP 777. He had brought up the question in this thread whether a signal generator upgrade was possible, in reply #2855, and was hoping to get away with just soldering in a missing chip.
-
the aim is an upgrade from DHO804 to DHO924S which i look at aliexpress currently still at ~$400 difference... plus i want to challenge myself and learn, or push the limit to where the DHO800 can be hacked/upgraded... upgrading DHO914/924 to DHO914S/924S by doing diy FG module thinking it can save money is not a good conclusion i agree...
800's to 814 is the best we can do. 900's have more hardware inside. If there's any effort to get an 800 to a 924S, might as well just but the 924S and skip the hacking effort.
-
the aim is an upgrade from DHO804 to DHO924S which i look at aliexpress currently still at ~$400 difference... plus i want to challenge myself and learn, or push the limit to where the DHO800 can be hacked/upgraded... upgrading DHO914/924 to DHO914S/924S by doing diy FG module thinking it can save money is not a good conclusion i agree...
800's to 814 is the best we can do. 900's have more hardware inside. If there's any effort to get an 800 to a 924S, might as well just but the 924S and skip the hacking effort.
You may not have followed Mechatrommer's posts. He is very much aware of the hardware differences, has successfully added the logic analyser port to his 804, and has built the kind-of-working signal generator module which we were just talking about here.
-
adb is being ran from windows
What???
.sh means little on linux, the 1st line of a shell script defines how it will execute. Shell script needs +x permission, or at least a 700 if you're in as root.
sh doesn't means "little". Also, You don't need write permissions if You need to execute a script. Only read and execute. If You are real root (uid=0), then You need nothing.
-
Simple to make!
Sure. :)
@Mechatrommer has tried, but I am not sure what the current status is, and I can't find the thread where he reported on his progress. Last I recall it was "kind of working"?
sorry for late reply i havent attend eevblog lately. i need to organize my life and still trying to complete other tasks... anyway, yes its working but noise spec is not really nice.. thats the last hindrance imho... few weeks ago i tried to get back to it for a moment, but i'm still at 5-10mVpp noise/crosstalk after some quick tin hat hack. i have pcb ver3 that i havent populate but guesstimating from current situation, i might not get very far with this, i might need to do total components reshuffling to move away smps noise to somewhere farther (i tried to be cheap on smps i think this is what shot me back), but since space is limited i cant do much, the other option is to follow closely how smpses in original board are made and what ICs used. i hope i can get back populating pcb ver3 soon and i think that will be the last revision i'm gonna do before publishing report, whatever the noise figure will be.. i'm tired of this there a lot of other tasks suspended because of this hobby. cheers.
And if you had a complete electrical circuit, could you completely replicate it in hardware? Help make a printed circuit board?
-
And if you had a complete electrical circuit, could you completely replicate it in hardware? Help make a printed circuit board?
i've completed my own diy electrical circuit and have completely replicate it in hardware and i did printed circuit board much earlier. your questions are a bit confusing... ;D
-
And if you had a complete electrical circuit, could you completely replicate it in hardware? Help make a printed circuit board?
i've completed my own diy electrical circuit and have completely replicate it in hardware and i did printed circuit board much earlier. your questions are a bit confusing... ;D
I am posting the generator diagram for your judgment, sorry there may be some minor flaws. And so the painstaking work was done, the circuit was obtained, now someone needs to make a printed circuit board, the elements were removed from the board and their value was measured
-
I am posting the generator diagram for your judgment, sorry there may be some minor flaws. And so the painstaking work was done, the circuit was obtained, now someone needs to make a printed circuit board, the elements were removed from the board and their value was measured
Damn, this is very impressive work! No words... I would give you five pluses if it were possible :)
And the circuit is also made strictly according to GOST, immediately recognizable as a serious engineer :)))
-
Just bought a couple of the TL-WN725N USB dongle adapters. Followed the guides to add to the Rigol DHO800. No success. The dongle is not recognised by the scope and and I unable to turn on wifi on in the Android settings (when I try the wifi toggle button bounces straight back to off).
Scope firmware (Utility -> About) : 00.01.02 SP2
The dongle I have is labelled as 240806 Ver 3.0. When first plugged in to a windows PC it acts as a usb memory device and contains 2 files. The Windows PC does not recognised the dongle as a wifi dongle.
- setup.inf
- setup.exe
setup.exe installs drivers for RTL8188GU:
- PBR_RTL8188GU.txt
- rtl8188gu.sys
- vwifibus.sys
driver date: 09/04/2018
driver version: 1040.1.1205.2017
After install the dongle works fine on the windows PC (no longer seen as a memory device) and it appears in Device Manager as TP-LINK Wireless USB Adapter
These are Chinese versions purchased from Taobao. I am now wondering if this is a local/regional version.
An online search shows me lots of people looking for linux drivers but I cannot find anything for Android.
-
TL-WN725N
There are two or three completely different wifi dongles with that model number. Different chipset = most likely different Linux kernel module (driver). This scope have only one compiled wifi module, and You can compile more modules - but only if You have a source code - You can ask Rigol to give You that, since it's a GPL licensed software.
-
There are two or three completely different wifi dongles with that model number. Different chipset = most likely different Linux kernel module (driver)
So I am discovering.
Had thought there was only 2 versions. Made sure I purchased Ver 3. Didn't help :-(
-
There are two or three completely different wifi dongles with that model number. Different chipset = most likely different Linux kernel module (driver)
So I am discovering.
Had thought there was only 2 versions. Made sure I purchased Ver 3. Didn't help :-(
Check modules in a /rigol/driver/
Check if module is loaded with lsmod.
Turn it on when dongle is connected already.
Try to load it by hand with insmod. If this will not help, this dongle will not work.
-
Check modules in a /rigol/driver/
Check if module is loaded with lsmod.
Not sure how to do this at the moment. Will see if I can figure it out.
Followed the instruction in https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5269047/?topicseen#msg5269047 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5269047/?topicseen#msg5269047)
The dongle is shown as usb-storage 3-1:1.0: USB Mass Storage device detected which fits with what I got using Windows. So it looks like, to me at least, the device is detected as a storage device until drivers are installed.
rk3399_rigol:/ # dmesg
rk3399_rigol:/ # lsusb
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ #
rk3399_rigol:/ # lsusb
Bus 003 Device 002: ID 0bda:1a2b
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # dmesg
[ 140.299442] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[ 140.420173] usb 3-1: New USB device found, idVendor=0bda, idProduct=1a2b
[ 140.420257] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 140.420272] usb 3-1: Product: DISK
[ 140.420286] usb 3-1: Manufacturer: Realtek
[ 140.425235] usb-storage 3-1:1.0: USB Mass Storage device detected
[ 140.426941] scsi host0: usb-storage 3-1:1.0
[ 140.672140] SELinux: Unable to set superblock options before the security server is initialized
[ 141.430675] scsi 0:0:0:0: CD-ROM Realtek USB Disk autorun 1.00 PQ: 0 ANSI: 0 CCS
[ 141.435230] scsi 0:0:0:0: Attached scsi generic sg0 type 5
-
lsmod
Turn it on when dongle is connected already.
Try to load it by hand with insmod. If this will not help, this dongle will not work.
I will not repeat this third time in a row.
Also my lsmod and lsub:
rk3399_rigol:/ # lsmod
Module Size Used by
focaltech_ts 213735 0
8188eu 2016009 0
dac_gpio 3444 0
fg_m2c_gpio 2719 0
beeper_gpio 3684 0
spi2afe_gpio 5571 0
xdma 99943 0
pcie_rockchip 20793 0
afg_gpio 3109 0
spi2pll_lxm2582_gpio 3111 0
hdcode_gpio 2304 0
motorcomm 17303 0
fan_gpio_clt 1694 0
rk3399_rigol:/ # lsusb
Bus 003 Device 002: ID 214b:7250
Bus 002 Device 001: ID 1d6b:0003
Bus 003 Device 001: ID 1d6b:0002
Bus 003 Device 003: ID 248a:8367
Bus 003 Device 004: ID 0bda:8179
Bus 003 Device 005: ID 1a2c:2124
-
setup.exe installs drivers for RTL8188GU:
- PBR_RTL8188GU.txt
- rtl8188gu.sys
- vwifibus.sys
[...]
These are Chinese versions purchased from Taobao. I am now wondering if this is a local/regional version.
It seems that RTL8188GU is not the same as RTL8188EU, and unfortunately only the latter is compatible with the driver Rigol has pre-installed. And it indeed looks like you got a version for the local Chinese market only -- my "TL-WN725N(EU) Ver:3.0" has CE and FCC marks as well as an FCC ID on the USB plug.
-
I am posting the second version of the AFG circuit with minor corrections to the circuit; there were some inaccuracies in the circuit design and element positions.
-
It seems that RTL8188GU is not the same as RTL8188EU, and unfortunately only the latter is compatible with the driver Rigol has pre-installed. And it indeed looks like you got a version for the local Chinese market only -- my "TL-WN725N(EU) Ver:3.0" has CE and FCC marks as well as an FCC ID on the USB plug.
When I got mine I just searched for "RTL8188EU" on Amazon and bought the one that came up.
It was a TP-Link TL-WN725N and it cost me about 7 Euros
-
Is this version good?
-
Yes
-
I have not seen the vendor.bin file of 924S, which one can share it. Thank you!
-
I have not seen the vendor.bin file of 924S, which one can share it. Thank you!
You can generate vendor.bin file: https://github.com/zelea2/rigol_vendor_bin
-
I have tried, but can only export Key.datay file, I don't seem to have Rkey.data file. I do not know if there is no correct operation, and the following error message appears
-
I have tried, but can only export Key.datay file, I don't seem to have Rkey.data file. I do not know if there is no correct operation, and the following error message appears
Instead of lazy copying commands, think what are You doing. Everything is very well documented and it's simple. Even error messages gives You an answer - did You read them at all???
-
@LEER333 You are missing a space after the command "pull". The error message is telling you that it has taken the full path (with pull included) as the command to be executed.
-
@LEER333 You are missing a space after the command "pull". The error message is telling you that it has taken the full path (with pull included) as the command to be executed.
He should figure this out by himself - please don't teach others to be lazy and use other people time. Same as unnecessary -s switch and repeated address (he is already connected as is in the messages from adb), but way too lazy to read that.
-
Thanks again! But the generated serial number prompt is not valid, so let's leave it at that
-
Thanks again! But the generated serial number prompt is not valid, so let's leave it at that
Prompt is not valid? Or You mean serial number is somehow strange? In this second case, this is not an issue, at least it shouldn't.
-
The resulting upgrade code was sent with an invalid message
-
Is your DHO914 with 3 DDR3 RAM chips?
yes, 3* K4B4G1646E-BYMA
Is there any difference? The system detects 12GB of ram?
Jest jakaś różnica? System wykrywa 12GB ramu?
-
That is RAM for FPGA not for RK3399 that is Android OS CPU
-
That is RAM for FPGA not for RK3399 that is Android OS CPU
Does it somehow positively affect the oscilloscope?
-
That is RAM for FPGA not for RK3399 that is Android OS CPU
Does it somehow positively affect the oscilloscope?
FPGA works much faster than cheap RK3399 and it stores samples from ADC. With that, CPU (RK3399) can retrieve those samples anything slower. When CPU work is done, FPGA can do another acquisition. That is how cheap digital oscilloscopes are designed.
-
That is RAM for FPGA not for RK3399 that is Android OS CPU
Does it somehow positively affect the oscilloscope?
FPGA works much faster than cheap RK3399 and it stores samples from ADC. With that, CPU (RK3399) can retrieve those samples anything slower. When CPU work is done, FPGA can do another acquisition. That is how cheap digital oscilloscopes are designed.
I think the question was whether the extra RAM in the DHO900 provides a functional advantage, not the FPGA.
To my knowledge it has never been clarified what that extra RAM chip does -- hacking a DHO800 to add logic analyser functionality seems to work without adding the RAM. I like the hypothesis that Rigol had originally planned some other signal acquisition mode for the digital channels (maybe one which would have avoided the reduction in analog sampling rate), but could not get that to work reliably and had to adopt a fallback solution late in the game. Do current DHO900 models still have the RAM populated?
-
That is RAM for FPGA not for RK3399 that is Android OS CPU
Does it somehow positively affect the oscilloscope?
FPGA works much faster than cheap RK3399 and it stores samples from ADC. With that, CPU (RK3399) can retrieve those samples anything slower. When CPU work is done, FPGA can do another acquisition. That is how cheap digital oscilloscopes are designed.
I think the question was whether the extra RAM in the DHO900 provides a functional advantage, not the FPGA.
To my knowledge it has never been clarified what that extra RAM chip does -- hacking a DHO800 to add logic analyser functionality seems to work without adding the RAM. I like the hypothesis that Rigol had originally planned some other signal acquisition mode for the digital channels (maybe one which would have avoided the reduction in analog sampling rate), but could not get that to work reliably and had to adopt a fallback solution late in the game. Do current DHO900 models still have the RAM populated?
I have DHO924S and all RAM are populated.
Maybe it's used somehow, but it's not easy task to do reverse engineering to answer to this question. RAM chips are quite expensive, so it has to be some reason for adding more.
-
I have DHO924S and all RAM are populated.
Maybe it's used somehow, but it's not easy task to do reverse engineering to answer to this question. RAM chips are quite expensive, so it has to be some reason for adding more.
Yes, reverse-engineering would be a challenge, especially with the RAM connected to the FPGA. But one would expect to see a functional difference in DHO900s which have the RAM populated vs. hacked a DHO800, right? I understand that @mechatrommer has added the logic analyser port and a preliminary function generator to his DHO800 -- and while there are some glitches, both seem to work in principle, with specs equivalent to the DHO900?
Obviously Rigol must have had a reason to design in and populate the extra RAM. But maybe the reason did not pan out and they ended up not using the chip? The tradeoff between analog and digital sampling rates in the DHO900 is unexpected and rather awkward, so maybe it was not planned that way? That's why I am curious whether Rigol might have dropped the extra RAM from the BOM in recent units.
-
Speaking of RAM. 4 GB for CPU looks like too much, since less than half of it is used, as far as remember.
Also 12 GB for 50 MS times 4 channels also looks like too much. Maybe it was due to the RAM chips latency?
-
Also 12 GB for 50 MS times 4 channels also looks like too much. Maybe it was due to the RAM chips latency?
Aren't the 50 MSamples available in single-channel mode only, and get reduced to 10 MSamples for 4 channels? The RAM must be used quite differently than one expects...
-
Anybody have any idea when the DHO804 will be available with EU (Poland) delivery at a maximum price of $399? On BangGood it is not available, and it was at a good price, the same amazon.
Sorry for offtop post.
-
Also 12 GB for 50 MS times 4 channels also looks like too much. Maybe it was due to the RAM chips latency?
Aren't the 50 MSamples available in single-channel mode only, and get reduced to 10 MSamples for 4 channels? The RAM must be used quite differently than one expects...
Yeah, I forgot that...
-
Anybody have any idea when the DHO804 will be available with EU (Poland) delivery at a maximum price of $399? On BangGood it is not available, and it was at a good price, the same amazon.
Sorry for offtop post.
I bought mine DHO924S from "authorized distributor" called NDN and located in Warsaw. https://rigol.com.pl/ https://ndn.com.pl/en/
-
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€😉😉😉😉
Could you provide links to the auctions?
-
Could you provide links to the auctions?
That post you refer to is more than half a year old. Most of the AliExpress offers (not auctions) will have changed by now.
If you order stuff, don't forget the Dremel for hacking up your scope's front panel to add the logic analyser port and the channel selection button. And whatever bits you want to use to make the button itself. ::)
(That's another way of saying "Don't do it!"... You would end up with a visibily hacked-up scope. You would still be missing the actual logic analyser pod which costs real money due to its expensive fast comparators. And the DHO900's performance with the digital channels is seriously compromised anyway, since they take sampling rate away from the analog channels. You are better off buying a stand-alone logic analyser, DSLogic or something in that class.)
-
[attach=2]
MPM3630 https://aliexpress.com/item/1005006266647449.html
[attach=3]
TP1282 https://aliexpress.com/item/1005006103987848.html
[attach=1]
K4B4G1646E-BYMA https://aliexpress.com/item/1005006898164186.html
[attach=4]
DC3 IDC JTAG-50Pin https://aliexpress.com/item/1005006802998883.html
Are the chip links ok?
Ps I have a dremel, 3d printer and hot air station. I would love to play with an oscilloscope.
-
I would love to play with an oscilloscope.
Well, it's a hobby, and everybody has their own idea of fun...
All good as long as you realize that the logic connector can't take logic signals directly. The Rigol logic pod costs 300$ plus VAT; homebrew solutions with the full functionality still close to $200. (I assume you have found the respective threads here?) And, as mentioned, the DHO900 is not a great mixed-signal scope anyway.
-
Anybody have any idea when the DHO804 will be available with EU (Poland) delivery at a maximum price of $399? On BangGood it is not available, and it was at a good price, the same amazon.
Sorry for offtop post.
I bought mine DHO924S from "authorized distributor" called NDN and located in Warsaw. https://rigol.com.pl/ https://ndn.com.pl/en/
I purchased DHO804 and it cost me $386.11 with zen.com cashback. That is, some 1540pln. It's good at this price.
-
I just got Bluetooth working with the Edimax EW-7611ULB (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/bluetooth/ew-7611ulb) and V2 (https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/bluetooth/ew-7611ulb_v2/) Bluetooth/Wifi combo adapters :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
or
rk3399_rigol:/ # ew7611ulb-v2.sh
Both the Bluetooth and Wi-Fi pages 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 get WiFi/Bluetooth combo adapter COMFAST CF-723B V2 with RTL8723DU chip, which should be same as Edimax EW-7611ULB V2
Copied https://sven.killig.de/android/DHO/ew7611ulb.tgz (https://sven.killig.de/android/DHO/ew7611ulb.tgz) to /data/local/tmp/ and executed
rk3399_rigol:/ # cd /
rk3399_rigol:/ # cp -rp lib/firmware data/local/tmp
rk3399_rigol:/ # tar xzvf data/local/tmp/ew7611ulb.tgz
rk3399_rigol:/ # ew7611ulb-v2.sh
And WiFi is working perfectly, but I can't make Bluetooth working. At Bluetooth setting page in Android Settings app, when I turn On Bluetooth nothing is happening.
hciconfig -a also don't shows any Bluetooth devices.
rk3399_rigol:/ # lsusb
Bus 003 Device 004: ID 0bda:d723
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # dmesg
[ 3097.215904] usb 3-1: new high-speed USB device number 5 using xhci-hcd
[ 3097.336485] usb 3-1: New USB device found, idVendor=0bda, idProduct=d723
[ 3097.336559] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3097.336577] usb 3-1: Product: 802.11n WLAN Adapter
[ 3097.336608] usb 3-1: Manufacturer: Realtek
[ 3097.336620] usb 3-1: SerialNumber: 00e04c000001
[ 3097.339978] rtk_btusb: btusb_probe: usb_interface ffffffc0a4647800, bInterfaceNumber 0, idVendor 0x0bda, idProduct 0x0000
[ 3097.340015] rtk_btusb: get_fw_table_entry: Product id = 0xd723, fw table entry size 47
[ 3097.340026] rtk_btusb: firmware_info_init: Auto suspend is disabled
[ 3097.340034] rtk_btusb: btusb_probe: download begining...
[ 3097.340042] rtk_btusb: btusb_probe: download ending...
[ 3097.340063] rtk_btusb: btusb_probe: Check bt reset flag 0
[ 3097.341209] RTW:
....
[ 3097.341533] RTW: USB_SPEED_HIGH
[ 3097.341540] RTW: CHIP TYPE: RTL8723DU
[ 3097.341584] RTW: loadparam, Select P2P interface: iface_id:1
[ 3097.341754] RTW: Chip Version Info: CHIP_8723D_T4_1T1R_RomVer(0)
[ 3097.341765] RTW: USB NumInPipe(2), NumOutPipe(4/4)
[ 3097.341833] RTW: EEPROM type is E-FUSE
[ 3097.341995] RTW: Boot from EFUSE, Autoload OK !
[ 3097.342128] RTW: hal_EfuseSwitchToBank: Efuse switch bank to 0
[ 3097.384176] RTW: hal_ReadEFuse_WiFi: data end at address=0x86
[ 3097.384274] RTW: HW EFUSE
[ 3097.384289] RTW: 0x000: 29 81 00 7C 01 88 07 00 A0 04 EC 35 12 C0 A2 D8
......
[ 3097.386551] RTW: VID = 0x0BDA, PID = 0xD723
[ 3097.386558] RTW: Customer ID: 0x00, SubCustomer ID: 0xCD
[ 3097.386568] RTW: hal_EfuseParsePowerSavingSetting...bHWPwrPindetect(0)-bHWPowerdown(0) ,bSupportRemoteWakeup(1)
[ 3097.386576] RTW: ### PS params=> power_mgnt(2),usbss_enable(0) ###
[ 3097.386620] RTW: Hal_EfuseParseBTCoexistInfo_8723D: Enable BT-coex, ant_num=1
[ 3097.386636] RTW: hal_com_config_channel_plan chplan:0x20
[ 3097.390093] RTW: SetHwReg: bMacPwrCtrlOn=1
[ 3097.390153] RTW: _InitPowerOn_8723du: Normal Mode
[ 3097.390208] RTW: _InitPowerOn_8723du: SPS Mode
[ 3097.390796] RTW: rtl8723d_FirmwareDownload((null)) tmp_ps=0
[ 3097.390810] RTW: rtl8723d_FirmwareDownload fw: FW_NIC, size: 29262
[ 3097.390830] RTW: rtl8723d_FirmwareDownload: fw_ver=31 fw_subver=0000 sig=0x23d1, Month=11, Date=18, Hour=20, Minute=41
[ 3097.390838] RTW: rtl8723d_FirmwareDownload(): Shift for fw header!
[ 3097.390877] RTW: rtl8723d_FirmwareDownload by IO write!
[ 3097.404860] RTW: polling_fwdl_chksum: Checksum report OK! (1, 0ms), REG_MCUFWDL:0x00070305
[ 3097.404892] RTW: rtl8723d_FirmwareDownload: download FW count:1
[ 3097.405395] RTW: _8051Reset8723: Finish
[ 3097.423605] RTW: _FWFreeToGo: Polling FW ready OK! (412, 20ms), REG_MCUFWDL:0x000703c6
[ 3097.423632] RTW: rtl8723d_FirmwareDownload success. write_fw:1, 33ms
[ 3097.423673] RTW: <=== rtl8723d_FirmwareDownload()
[ 3097.435068] RTW: CardDisableRTL8723du((null)): bMacPwrCtrlOn=1
...
[ 3097.441650] RTW: country_ie_env:ANY
[ 3097.441933] RTW: rtw_ndev_init(wlan0) if1 mac_addr=e0:e1:a9:3c:fd:a0
[ 3097.442310] RTW: rtw_ndev_notifier_call(wlan0) state:16
[ 3097.443406] RTW: rtw_ndev_notifier_call(wlan0) state:5
[ 3097.443520] RTW: rtw_ndev_init(p2p0) if2 mac_addr=e2:e1:a9:3c:fd:a0
..
[ 3097.743118] RTW: cfg80211_rtw_flush_pmksa(wlan0)
[ 3097.746444] RTW: rtw_android_priv_cmd: Android private cmd "BTCOEXSCAN-STOP" on wlan0
[ 3097.747062] RTW: rtw_android_priv_cmd: Android private cmd "RXFILTER-STOP" on wlan0
[ 3097.747727] RTW: rtw_android_priv_cmd: Android private cmd "RXFILTER-ADD 2" on wlan0
[ 3097.748510] RTW: rtw_android_priv_cmd: Android private cmd "RXFILTER-START" on wlan0
[ 3097.749367] RTW: rtw_android_priv_cmd: Android private cmd "RXFILTER-STOP" on wlan0
[ 3097.750637] RTW: rtw_android_priv_cmd: Android private cmd "RXFILTER-ADD 3" on wlan0
[ 3097.751178] RTW: rtw_android_priv_cmd: Android private cmd "RXFILTER-START" on wlan0
[ 3097.752455] RTW: rtw_android_priv_cmd: Android private cmd "SETSUSPENDMODE 0" on wlan0
Also I edited /rigol/shell/start_rigol_app.sh and added
### insmod ethernet PHY driver for Motorcomm - YT8512
ifconfig eth0 down
insmod /rigol/driver/motorcomm.ko
ifconfig eth0 up
> #Wifi/Bluetooth
> mount --bind /data/local/tmp/firmware /lib/firmware
> insmod /system/lib/modules/rtk_btusbew7611ulbv2.ko
> insmod /system/lib/modules/8723du.ko
# Get the Hardware version
insmod /rigol/driver/hdcode_gpio.ko
chmod 777 /dev/hdcode_gpio
So Now WiFi is starting automatically after reboot.
Any ideas what could be wrong and how to fix Bluetooth?
-
For my EW-7611ULB V2, rtk_btusbew7611ulbv2.ko is quite a bit more verbose:
rk3399_rigol:/ # mount --bind /data/local/tmp/firmware /lib/firmware
rk3399_rigol:/ # dmesg -c
...
rk3399_rigol:/ # insmod /system/lib/modules/rtk_btusbew7611ulbv2.ko
rk3399_rigol:/ # dmesg -c
[ 199.989419] rtk_btusbew7611ulbv2: loading out-of-tree module taints kernel.
[ 199.995549] rtk_btusb: Realtek Bluetooth USB driver ver 3.1.523c92e.20210706-141239
[ 199.995598] rtk_btcoex: rtk_btcoex_init: version: 1.2
[ 199.995608] rtk_btcoex: create workqueue
[ 199.995979] rtk_btcoex: alloc buffers 1792, 2432 for ev and l2
[ 199.996160] rtk_btusb: btusb_probe intf->cur_altsetting->desc.bInterfaceNumber 0
[ 199.996177] rtk_btusb: btusb_probe can_wakeup 1, may wakeup 0
[ 199.996186] rtk_btusb: patch_add
[ 199.996193] rtk_btusb: auto suspend is disabled
[ 199.996202] rtk_btusb: pid = 0xd611
[ 199.996212] rtk_btusb: patch_add: Reset gEVersion to 0xff
[ 199.996254] rtk_btusb: set_bit(HCI_QUIRK_RESET_ON_CLOSE, &hdev->quirks);
[ 199.997806] rtk_btusb: btusb_probe: done
[ 199.997812] rtk_btusb: btusb_open start
[ 199.997826] rtk_btusb: btusb_open hdev->promisc ==0
[ 199.997832] rtk_btusb: download_patch start
[ 199.997837] rtk_btusb: chip type value: 0x71
[ 199.997848] rtk_btusb: HCI reset.
[ 200.000073] usbcore: registered new interface driver rtk_btusbew7611ulbv2
[ 200.007159] rtk_btusb: read_ver_rsp->lmp_subver = 0x8723
[ 200.007239] rtk_btusb: read_ver_rsp->hci_rev = 0xd
[ 200.007257] rtk_btusb: patch_entry->lmp_sub = 0x8723
[ 200.007271] rtk_btusb: load_firmware start
[ 200.007282] rtk_btusb: lmp_version = 0x8723
[ 200.007301] rtk_btusb: config filename rtl8723du_config
[ 200.009440] rtk_btusb: no bdaddr file /opt/bdaddr
[ 200.009484] rtk_btusb: Origin cfg len 22
[ 200.009496] rtk_btusb: 55 ab 23 87 10 00 d9 00 01 0f e4 00 01 08 8d 00
[ 200.009504] rtk_btusb: 01 fa 8f 00 01 bf
[ 200.009518] rtk_btusb: New cfg len 22
[ 200.009525] rtk_btusb: 55 ab 23 87 10 00 d9 00 01 0f e4 00 01 08 8d 00
[ 200.009543] rtk_btusb: 01 fa 8f 00 01 bf
[ 200.009584] rtk_btusb: fw name is rtl8723du_fw
[ 200.013139] rtk_btusb: This is not 8723a, use new patch style!
[ 200.013191] rtk_btusb: rtk_get_eversion: gEVersion 255
[ 200.014170] rtk_btusb: eversion->status = 0x0, eversion->version = 0x2
[ 200.014345] rtk_btusb: load_firmware: New gEVersion 2
[ 200.014385] rtk_btusb: rtk_get_fw_project_id: opcode 0, len 1, data 9
[ 200.014402] rtk_btusb: lmp_version is 8723, project_id is 8723, match!
[ 200.014416] rtk_btusb: fw_version = 0x82a8a133
[ 200.014428] rtk_btusb: number_of_total_patch = 3
[ 200.014442] rtk_btusb: chipID 3
[ 200.014451] rtk_btusb: patch_length 0x889c
[ 200.014463] rtk_btusb: start_offset 0x00004940
[ 200.014476] rtk_btusb: Svn version: -1433992835
[ 200.014487] rtk_btusb: Coexistence: BTCOEX_20210106-3b3b
[ 200.014496] rtk_btusb: buf_len = 0x88b2
[ 200.014778] rtk_btusb: fw: exists, config file: exists
[ 200.014804] rtk_btusb: load_firmware done
[ 200.015075] rtk_btusb: download_data start
[ 200.283142] rtk_btusb: download_data done
[ 200.283210] rtk_btusb: HCI reset.
[ 200.293049] rtk_btusb: read_ver_rsp->lmp_subver = 0xa133
[ 200.293078] rtk_btusb: read_ver_rsp->hci_rev = 0x82a8
[ 200.293085] rtk_btusb: patch_entry->lmp_sub = 0x8723
[ 200.293101] rtk_btusb: Rtk patch end 0
[ 200.293110] rtk_btusb: btusb_open set HCI_RUNNING
[ 200.293141] rtk_btcoex: Open BTCOEX
[ 200.293148] rtk_btusb: btusb_open end
[ 200.295109] rtk_btcoex: BTCOEX hci_rev 0x82a8
[ 200.295129] rtk_btcoex: BTCOEX lmp_subver 0xa133
[ 200.315138] rtk_btusb: btusb_notify: hci0 evt 3
[ 200.367065] rtk_btcoex: BTCOEX hci_rev 0x82a8
[ 200.367098] rtk_btcoex: BTCOEX lmp_subver 0xa133
[ 200.629467] rtk_btcoex: LE connected, handle 0000, status 0x02, interval 0
hciconfig also shows it then:
rk3399_rigol:/ # hciconfig -a
hci0: Type: BR/EDR Bus: USB
BD Address: 08:BE:AC:41:AA:2F ACL MTU: 1021:8 SCO MTU: 255:12
UP RUNNING
RX bytes:1294 acl:0 sco:0 events:30 errors:0
TX bytes:3546 acl:0 sco:0 commands:81 errors:0
Features: 0xff 0xff 0xff 0xfa 0xdb 0xbd 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'rk3399_rigol'
Can't read class of device on hci0: Connection timed out (110)
The driver might be very model specific. I got the EW-7611ULB V1 from Amazon (https://amzn.eu/d/iJgrFvl) and the V2 from B&H (https://www.bhphotovideo.com/c/product/1781039-REG/edimax_technology_ew_7611ulb_v2_2_in_1_wi_fi_4_n150.html).
-
I solved my Bluetooth issue.
For some reason my scope already had rtk_btusb driver build-in in kernel and it was staring before rtk_btusbew7611ulbv2 module was loading and taking over USB device.
Couldn't figure out what is wrong or missing in build-in rtk_btusb driver for RTL8723DU chip so I just unbind USB device from rtk_btusb and bind it to rtk_btusbew7611ulbv2 and Bluetooth started to work.
#Wifi/Bluetooth
mount --bind /data/local/tmp/firmware /lib/firmware
insmod /system/lib/modules/rtk_btusbew7611ulbv2.ko
echo '3-1:1.0' > /sys/bus/usb/drivers/rtk_btusb/unbind
echo '3-1:1.0' > /sys/bus/usb/drivers/rtk_btusbew7611ulbv2/bind
insmod /system/lib/modules/8723du.ko
This is how it looks like in dmesg:
First rtk_btusb driver is loading
[ 1.231416] rtk_btusb: RTKBT_RELEASE_NAME: 20170109_TV_ANDROID_6.x
[ 1.231427] rtk_btusb: Realtek Bluetooth USB driver module init, version 4.1.2
[ 1.231437] rtk_btusb: Register usb char device interface for BT driver
[ 1.231714] usbcore: registered new interface driver rtk_btusb
Then it binding USB device
[ 1.960028] rtk_btusb: btusb_probe: usb_interface ffffffc0e1017800, bInterfaceNumber 0, idVendor 0x0bda, idProduct 0x0000
[ 1.960150] rtk_btusb: get_fw_table_entry: Product id = 0xd723, fw table entry size 47
[ 1.960226] rtk_btusb: firmware_info_init: Auto suspend is disabled
[ 1.960249] rtk_btusb: btusb_probe: download begining...
[ 1.960269] rtk_btusb: btusb_probe: download ending...
[ 1.960305] rtk_btusb: btusb_probe: Check bt reset flag 0
Later I'm loading rtk_btusbew7611ulbv2 module
[ 7.727053] rtk_btusbew7611ulbv2: loading out-of-tree module taints kernel.
[ 7.727863] rtk_btusb: Realtek Bluetooth USB driver ver 3.1.523c92e.20210706-141239
[ 7.727874] rtk_btcoex: rtk_btcoex_init: version: 1.2
[ 7.727879] rtk_btcoex: create workqueue
[ 7.728194] rtk_btcoex: alloc buffers 1792, 2432 for ev and l2
[ 7.728296] usbcore: registered new interface driver rtk_btusbew7611ulbv2
I unbind USB device from rtk_btusb driver
[ 7.729067] rtk_btusb: btusb_disconnect: usb_interface ffffffc0e1017800, bInterfaceNumber 0
[ 7.743779] rtk_btusb: btusb_close: hci running 0
[ 7.743855] rtk_btusb: btusb_disconnect: usb_interface ffffffc0e1017c00, bInterfaceNumber 1
And bind it to rtk_btusbew7611ulbv2 driver
[ 7.744125] rtk_btusb: btusb_probe intf->cur_altsetting->desc.bInterfaceNumber 0
[ 7.744143] rtk_btusb: btusb_probe can_wakeup 1, may wakeup 0
[ 7.744148] rtk_btusb: patch_add
[ 7.744152] rtk_btusb: auto suspend is disabled
[ 7.744157] rtk_btusb: pid = 0xd723
[ 7.744163] rtk_btusb: patch_add: Reset gEVersion to 0xff
[ 7.744174] rtk_btusb: set_bit(HCI_QUIRK_RESET_ON_CLOSE, &hdev->quirks);
[ 7.751634] rtk_btusb: btusb_open start
[ 7.751648] rtk_btusb: btusb_open hdev->promisc ==0
[ 7.751653] rtk_btusb: download_patch start
[ 7.751658] rtk_btusb: chip type value: 0x71
[ 7.751663] rtk_btusb: HCI reset.
And Bluetooth is working :)
Thanks for your help.
-
For some reason my scope already had rtk_btusb driver build-in in kernel
Mine too:
[ 1.218477] rtk_btusb: RTKBT_RELEASE_NAME: 20170109_TV_ANDROID_6.x
[ 1.218486] rtk_btusb: Realtek Bluetooth USB driver module init, version 4.1.2
[ 1.218494] rtk_btusb: Register usb char device interface for BT driver
[ 1.218724] usbcore: registered new interface driver rtk_btusb
Then it binding USB device
Mine doesn't.
Couldn't figure out what is wrong or missing in build-in rtk_btusb driver for RTL8723DU chip so I just unbind USB device from rtk_btusb and bind it to rtk_btusbew7611ulbv2 and Bluetooth started to work.
Strange that I don't have to unbind, but glad it works! :)
-
Can the WIFI adapter solve the problem of clock confusion?
-
Can the WIFI adapter solve the problem of clock confusion?
The scope connects to the time servers via Ethernet cable or Wifi, but the Chinese region is fixed in the startup script, so you need first change to your region in that script.
-
Chinese region
More like timezone.
-
Folks ... please don't throw stones on me ... it's impossible to read this whole thread or to search in it for the missing needle ...
I upgraded my DHO804 to the latest firmware 1.02 and now WiFi doesn't work anymore and I can't switch the switch back on in Android settings. It always switches back to off immediately. :-(
What can I do? My little WiFi dongle worked fine with the firmware before.
Any pointers to solutions (for entry- to mid-level nerds) much appreciated!
Thanks so much and have a great Sunday everyone!
-
Folks ... please don't throw stones on me ... it's impossible to read this whole thread or to search in it for the missing needle ...
I upgraded my DHO804 to the latest firmware 1.02 and now WiFi doesn't work anymore and I can't switch the switch back on in Android settings. It always switches back to off immediately. :-(
What can I do? My little WiFi dongle worked fine with the firmware before.
Any pointers to solutions (for entry- to mid-level nerds) much appreciated!
Thanks so much and have a great Sunday everyone!
Turn it off and on back again (with wifi stick already connected). Eventually try to unload and load driver module back again.
-
Hurray! That helped! WiFi connectivity is back again! :-+
Thanks so much, Norbert!
Now I "just" need a way to bring back all the features I had already activated in firmware 1.01 ...
(And I don't want to make my 804 into some 9xx like TheRetroChannel did it.)
What to do? Is there some place where all the knowledge shared here in this thread has been written up in a nice, noob-friendly tutorial?
-
Hint: The "Enable WiFi" button in Android settings doesn't do anything.
-
Hurray! That helped! WiFi connectivity is back again! :-+
Thanks so much, Norbert!
Now I "just" need a way to bring back all the features I had already activated in firmware 1.01 ...
(And I don't want to make my 804 into some 9xx like TheRetroChannel did it.)
What to do? Is there some place where all the knowledge shared here in this thread has been written up in a nice, noob-friendly tutorial?
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)
-
I executed the following command: adb pull /rigol/data
but got vendor.bin with 0KB size.
any suggestion？
-
Try to pull only this file. BTW. Was there any error messages?
-
IGOR! AWESOME!!! Thanks so much for pointing me to the needle in the haystack!!
It worked flawlessly once I had the options' codes from the tool.
Totally happy now, you made my day! 🤗
-
Thank you for your efforts, the use of zelea2 tool can not generate 26 string number, do not know where is not right. The original string number starts with 2626 but the generated string number starts with 2526。。。
-
Thank you for your efforts, the use of zelea2 tool can not generate 26 string number, do not know where is not right. The original string number starts with 2626 but the generated string number starts with 2526。。。
This is because the oscilloscope model has changed. The beginning of the serial number depends on the model.
-
oh,Thanks!
-
So, if I understand correctly, the hardware (except for knobs and connectors that are missing) is identical in say DHO804 and DHO924? Otherwise upgrading from 70MHz to 250MHz would be in paper only, no? I'm new here and I apologize if I missed that fact in this huge thread.
-
So, if I understand correctly, the hardware (except for knobs and connectors that are missing) is identical in say DHO804 and DHO924?
Yes.
-
So, if I understand correctly, the hardware (except for knobs and connectors that are missing) is identical in say DHO804 and DHO924?
The main PCBs are identical across both series and all models, i.e. full bandwidth and full memory capacity is available on every PCB.
The DHO900 series has the extra connector and button for the digital channels populated, and also some extra RAM next to the FPGA of which the functionality is unknown -- maybe it is not used at all. The 9xx-S models also contain an extra piggyback board with the signal generator hardware, and yet another front panel button to activate the generator.
A couple of very enterprising users have upgraded their DHO8xx to 9xx functionality, but I would not recommend it. You need to hack up your scope's front panel to accommodate the connector, need to find a solution for the missing button, and still need to make or buy the expensive external logic adapter. (It contains fast level converters to drive the differential digital inputs of the FPGA. Note that you may not feed logic signals directly to the scope's digital port!) And also, even the original DHO900 is not great as a mixed signal scope: Using the digital channels cuts the analog sampling rate in half -- which is not generous to begin with.
-
Many thanks for the speedy responses guys! I am hard at contemplating a DHO804 with the - lets call it budget - upgrade option to DHO824. Rookie that I am, all I have is a HDS242 from Owon and it's rather limited. Reading the scope related reviews here I'm actually surprised that it does so well.
Thanks again!
-
Is there any more info on the DC offset on upgrading from the base DH804 to any of the other firmware's?
Which upgrade will not induce a DC offset or harm accuracy?
-
Is there any more info on the DC offset on upgrading from the base DH804 to any of the other firmware's?
Which upgrade will not induce a DC offset or harm accuracy?
You can always run self-calibration, so I don't see any problem with this.
-
Is there any more info on the DC offset on upgrading from the base DH804 to any of the other firmware's?
Which upgrade will not induce a DC offset or harm accuracy?
You can always run self-calibration, so I don't see any problem with this.
Earlier in the thread someone posted a quite large error even after self calibration, that's why I am asking.
-
Never happened to me. Even if one channel is terminated (which I did internally).
-
Earlier in the thread someone posted a quite large error even after self calibration, that's why I am asking.
This was in very early versions. In February, an update to version 00.01.02.00.02 was released, in which the displacement problem went away.
-
Earlier in the thread someone posted a quite large error even after self calibration, that's why I am asking.
This was in very early versions. In February, an update to version 00.01.02.00.02 was released, in which the displacement problem went away.
So even if i do the upgrade do DHO924 the DC accuracy will remain the same now? with 200Mhz and 50Mpts? That will be very good.
I bought the DHO804 on Black Friday with very good discount and will be shipped and arrive very soon.
-
So even if i do the upgrade do DHO924 the DC accuracy will remain the same now? with 200Mhz and 50Mpts?
Yes, that's right.
-
Are my post being deleted?
I post that for people who already got the Extended UI compatible with the firmware 00.01.03 could download the 00.01.04 for free, also the comment from another user about the successful installing was deleted.
-
Are my post being deleted?
Yes, apparently so. I saw it happen once before, with the release announcement of your updated UI improvements a few days ago.
I assume a moderator took offense at the double-posting (here and in the "firmware 1.0.4" thread you created). While I can see the rationale, I think it is very bad style to just quietly delete the post without leaving a comment to document the moderation action. I was assuming that the moderator had contacted you via PM to explain, but apparently that's not the case?
-
But my (single) post about how the installation went smoothly is also deleted. There was no pm from a moderator
Are my post being deleted?
Yes, apparently so. I saw it happen once before, with the release announcement of your updated UI improvements a few days ago.
I assume a moderator took offense at the double-posting (here and in the "firmware 1.0.4" thread you created). While I can see the rationale, I think it is very bad style to just quietly delete the post without leaving a comment to document the moderation action. I was assuming that the moderator had contacted you via PM to explain, but apparently that's not the case?
-
Yes, apparently so. I saw it happen once before, with the release announcement of your updated UI improvements a few days ago.
I assume a moderator took offense at the double-posting (here and in the "firmware 1.0.4" thread you created). While I can see the rationale, I think it is very bad style to just quietly delete the post without leaving a comment to document the moderation action. I was assuming that the moderator had contacted you via PM to explain, but apparently that's not the case?
I post here also because this is the thread where we start the hacking of the oscilloscope's application so, it is rationale that the people look for news about of the development here and not necessarily in the other thread, but also, people arriving at the new firmware post could be interested too. There are a lot of different threads a couple of them don't seem to be very important.
-
Ok, I hope this post will be not deleted, I can't find a way to communicate with the moderator to ask if I can post this, but if Rigol or Siglent come here to post a discount for us I hope that post will be not deleted:
I want to offer a big discount to the members of this thread who have the 00.01.02 firmware and don't planning to upgrade yet, just use the code 815CD in https://www.patreon.com/mriscoc/shop/rigol-dho800-900-sparrow-extended-gui-00-204640 (https://www.patreon.com/mriscoc/shop/rigol-dho800-900-sparrow-extended-gui-00-204640) and you will be able to download the Full extended application compatible with the 00.01.02 firmware for US$ 5
Please make a backup of your files first and download the demo version from the Github to make your confident with the installing of a modified application before any purchase.
I can't reduce the price more due to platform commissions.
-
I post here also because this is the thread where we start the hacking of the oscilloscope's application so, it is rationale that the people look for news about of the development here and not necessarily in the other thread, but also, people arriving at the new firmware post could be interested too. There are a lot of different threads a couple of them don't seem to be very important.
But you really shouldn't be double-posting. Especially in the present case, where you created the "new firmware 1.04" thread yourself (and there were complaints why yet another thread was opened on this scope and its firmware).
That does not take away from the fact that you have created great UI improvements, by the way! :-+ While no longer a Rigol user myself, I continue to be impressed and wish that Rigol would either adopt the improvements into their official UI, or make your life easier by releasing source code.
-
... Rigol would either adopt the improvements into their official UI, or make your life easier by releasing source code.
If I were the product manager of Rigol, I would give instruct to the software department to move all the critical routines to "so" libraries and would left the main application as open source to launch this device like a community device, that would give to the company inputs to solve the mayor problems because the hardware is so-so good for the cost, but the software seems to be unfinished in several aspects.
I think that with this approach, we would have several spectacular bode plots for the 924S, impressive FFT analysis tools and many other applications outside of the imagination of Rigol, and they could be ported to more advanced and expensive devices. It is like to have a huge R&D department for free.
-
move all the critical routines to "so" libraries
There is currently one so library which does most of the app job with acquisition, measurements, etc. Some time ago I did reverse engineering of this lib and I tried to change some things like a disabling sinc interpolation, which is a pain in the back, especially at higher input frequencies and also removed 250 MHz filters (close to the ADC IC) which gives nice 1 GHz bandwidth.
-
... Rigol would either adopt the improvements into their official UI, or make your life easier by releasing source code.
If I were the product manager of Rigol, I would give instruct to the software department to move all the critical routines to "so" libraries and would left the main application as open source to launch this device like a community device, that would give to the company inputs to solve the mayor problems because the hardware is so-so good for the cost, but the software seems to be unfinished in several aspects.
I think that with this approach, we would have several spectacular bode plots for the 924S, impressive FFT analysis tools and many other applications outside of the imagination of Rigol, and they could be ported to more advanced and expensive devices. It is like to have a huge R&D department for free.
...but Rigol does not , like any other company, work for free.
there is a business model and profit has to be made.
-
...but Rigol dors not , like any other company, work for free.
there is a business model and profit has to be made.
Some scopes are open-source (more or less). However those are not-cheap or with not-best parameters.
-
... which gives nice 1 GHz bandwidth.
I would be happy if the bandwidth is keeped in 200MHz (due to the hardware limitation in the sampling rate) but with a good software which use all the capabilities of the device.
-
...but Rigol dors not , like any other company, work for free.
there is a business model and profit has to be made.
Please re-read mrisco's post. He does not suggest Rigol should work for free, but that they should make use of the free work users are willing to put in.
(Which in reality would not come entirely for free either, by the way. Rigol would need to do quality control and probably a lot of cleanup, since the code quality of user contributions would vary widely.)
-
...but Rigol dors not , like any other company, work for free.
there is a business model and profit has to be made.
That's the point, with opening the software they can concentrate in developing their hardware and ASICs, and take ideas and software from the community, in the long time they will made more profit. They would need to have personal to validation the software but the ideas and improvements will be there, they could for example implement some kind of basic software that allow plugins, and make the community plugins official when they pass the validation process.
-
... which gives nice 1 GHz bandwidth.
I would be happy if the bandwidth is keeped in 200MHz (due to the hardware limitation in the sampling rate) but with a good software which use all the capabilities of the device.
Sampling rate is not a problem here. Problem is with noise level. That's why I have two channels modified and two unmodified.
-
...but Rigol dors not , like any other company, work for free.
there is a business model and profit has to be made.
That's the point, with opening the software they can concentrate in developing their hardware and ASICs, and take ideas and software from the community, in the long time they will made more profit.
I think management doesn't really know much about electronics engineering or software. In their eyes that will not make more profit, but instead it will be catastrophe. Good luck with reaching them and fighting with cognitive bias (explaining that they are wrong).
-
...but Rigol dors not , like any other company, work for free.
there is a business model and profit has to be made.
Please re-read mrisco's post. He does not suggest Rigol should work for free, but that they should make use of the free work users are willing to put in.
(Which in reality would not come entirely for free either, by the way. Rigol would need to do quality control and probably a lot of cleanup, since the code quality of user contributions would vary widely.)
Letting it become a community device would harm their profit as it would imply a lower cost for the device but at the same time a higher cost of moderating/finalising/supporting the open source software.
Not a single company has taken that route and become more profitable nor have a better product.
Developing a product is not some sort of a democracy.
-
...but Rigol dors not , like any other company, work for free.
there is a business model and profit has to be made.
Please re-read mrisco's post. He does not suggest Rigol should work for free, but that they should make use of the free work users are willing to put in.
(Which in reality would not come entirely for free either, by the way. Rigol would need to do quality control and probably a lot of cleanup, since the code quality of user contributions would vary widely.)
Letting it become a community device would harm their profit as it would imply a lower cost for the device but at the same time a higher cost of moderating/finalising/supporting the open source software.
Not a single company has taken that route and become more profitable nor have a better product.
I think in the complete opposite way. But in same time I know, cognitive bias is a very strong drug.
-
Letting it become a community device would harm their profit as it would imply a lower cost for the device but at the same time a higher cost of moderating/finalising/supporting the open source software.
I think no, imagine to all the programmable hardware and computer manufacturers be afraid about the software that the users run in their devices. Additionally they would have only one line of community devices while keeping the professional line closed. So the benefit is larger than the risk.
-
PS. Currently I will not by anything from Rigol anymore, because of many reasons. But if they will give source code (even used kernel is on GPL licence so they are obligated) I can change my mind.
-
Letting it become a community device would harm their profit as it would imply a lower cost for the device but at the same time a higher cost of moderating/finalising/supporting the open source software.
I think no, imagine to all the programmable hardware and computer manufacturers be afraid about the software that the users run in their devices. Additionally they would have only one line of community devices while keeping the professional line closed. So the benefit is larger than the risk.
Yeah, Imagine whole world has some devices on which You can create, compile and share Your own software. If that thing will exists, I will call it as a computer. Such a nice name.
If that will happen, whole world will burn, because of no profit from those mentioned computers.
-
I use to work/develop electronics for a company and at a certain moment a customer started to reverse engineer a product and write its own software and started to promote it among other customers.
It became a disaster in managing, choosing,agreeing upon features, support and many bugs and in the end it crashed the product and it had to be withdrawn.
-
I use to work/develop electronics for a company and at a certain moment a customer started to reverse engineer to product and write its own software and started to promote it among other customers.
It became a disaster in managing, choosing,agreeing upon features, support and many bugs and in the end it crashed the product and it had to be withdrawn.
So, Your company didn't released open-source, but somebody else did. That one person was probably a monkey instead of experienced programmer. And somebody writing their own software destroyed Your company? How is that possible? Or You are not telling the whole story.
-
I use to work/develop electronics for a company and at a certain moment a customer started to reverse engineer a product and write its own software and started to promote it among other customers.
It became a disaster in managing, choosing,agreeing upon features, support and many bugs and in the end it crashed the product and it had to be withdrawn.
So the failure of your company not have to be the rule.
We saw many men fail trying to fly until someone succeeded.
-
I use to work/develop electronics for a company and at a certain moment a customer started to reverse engineer to product and write its own software and started to promote it among other customers.
It became a disaster in managing, choosing,agreeing upon features, support and many bugs and in the end it crashed the product and it had to be withdrawn.
So, Your company didn't released open-source, but somebody else did. That one person was probably a monkey instead of experienced programmer. And somebody writing their own software destroyed Your company? How is that possible? Or You are not telling the whole story.
I said the product had to be withdrawn, not the company. The company still exists after 26 years, so no worries.
The issue is that suddenly all of your customers think they can demand features or hardware changes just because someone showed other possibilities.
As a company, that is not what you want, not what you planned, not what you can support, not part of your roadmap, not part of your business plan, …
But hey, feel free to demand your management to go open source.
If you’re lucky, they won’t fire you.
-
If I were the product manager of Rigol, I would give instruct to the software department to move all the critical routines to "so" libraries and would left the main application as open source to launch this device like a community device
Never going to happen. It's too much work for them to do that.
Everybody would demand documentation and tech support, and they'd get blamed every time they changed anything. IT would need whole new departments at Rigol.
Besides, it simply isn't their business model or way of thinking.
-
I've also worked on non-trivial open source projects. The highly successful ones without exception required considerable resource to manage and orchestrate contributions and, in my experience, when commercial entities are the major sponsors and providers of those resources then a 'benign dictatorship' governance model is the only one which comes close to remotely satisfyingly major stakeholders (whilst simultaneously outraging and alienating the open source purists).
However, there's more than one way to skin the proverbial cat. Far less resource is required to nurture and grow an active user community, and to engage with it meaningfully. I think that's where Rigol could make a realistic, affordable difference, if they wanted to. Which it's quite clear they don't. Just listening to user's issues, and clearly communicating a commitment to addressing at least the major ones would go some way to putting some a bit of extra profit on their bottom line.
-
If I were the product manager of Rigol, I would give instruct to the software department to move all the critical routines to "so" libraries and would left the main application as open source to launch this device like a community device
Never going to happen. It's too much work for them to do that.
its going to happen, but only if mrisco is the product manager. probably will end up like what Sorama experienced... we know rigol's stand at this currently is... STFU... but people will keep buying it.
I use to work/develop electronics for a company and at a certain moment a customer started to reverse engineer to product and write its own software and started to promote it among other customers.
It became a disaster in managing, choosing,agreeing upon features, support and many bugs and in the end it crashed the product and it had to be withdrawn.
So, Your company didn't released open-source, but somebody else did. That one person was probably a monkey instead of experienced programmer. And somebody writing their own software destroyed Your company? How is that possible? Or You are not telling the whole story.
I said the product had to be withdrawn, not the company. The company still exists after 26 years, so no worries.
The issue is that suddenly all of your customers think they can demand features or hardware changes just because someone showed other possibilities.
As a company, that is not what you want, not what you planned, not what you can support, not part of your roadmap, not part of your business plan, …
typical business excuse are:
1) we do not support this or that feature. if you want this or that feature, use that monkey's code, but warranty void.
2) we can produce what you want as xtreme/premium/xclusive rich guy edition at increased cost.
its funny how a company has to put down a product due to costumers request. its either:
1) there is other competitor brand product that can do costumers requested features
2) the customers have to stick with your only one product (no competitor) even though with standard/crippled FW. because they still need the standard feature/function of the product, you stil can get profit.
ymmv.
-
Hello, I can get a DHO914. Is there a possibility to upgrade to DHO924S?
-
Hello, I can get a DHO914. Is there a possibility to upgrade to DHO924S?
You can upgrade it to a DHO924 (more bandwidth), but the signal generator in the -S model is an actual add-on board which is not available separately. Also there is an extra front panel button on the -S models to control the generator.
Depending on available pricing you may want to buy a DHO804 instead and upgrade that to a 824. The logic analyzer in the DHO9xx is not great, requires an expensive external probe (which includes active level converters), and takes half the sampling rate away from the analog channels.
-
Thanks for your feedback.
I currently have a DS1954z with a hack.
Unfortunately, I'm always missing a logic analyzer. As I'm currently remodeling my space, a new device with a Vesa mount is perfect.
I use it more as a hobby. What other alternatives are there for logic analyzers?
-
What is it that you need to analyze?
The DHO900 is quite expensive once you add everything and the sample rate isn't very high and the screen is quite small.
The serial decoders in the DHO800 are much better than the DS1054Z.
(well, the entire 'scope is much better - it makes the DS1054Z look like an antique)
-
I had both and I think DS1054Z is much better and much less problematic.
From the beginning to this day, firmware in a DHO800/900 is a piece of sh*t, written by some interns. Only one positive side is hackable (even up to the 1 GHz) bandwidth.
-
From the beginning to this day, firmware in a DHO800/900 is a piece of sh*t, written by some interns.
You're entitled to your opinion, just know that everybody else disagrees with you.
-
From the beginning to this day, firmware in a DHO800/900 is a piece of sh*t, written by some interns.
You're entitled to your opinion, just know that everybody else disagrees with you.
No, it's just You in one single post. Since when all members from entire forum can make single post together?
-
What is it that you need to analyze?
The DHO900 is quite expensive once you add everything and the sample rate isn't very high and the screen is quite small.
The serial decoders in the DHO800 are much better than the DS1054Z.
(well, the entire 'scope is much better - it makes the DS1054Z look like an antique)
I don't want to analyze anything special. I now have an AZ Delivery Logic Analyzer. I would have liked to have something in one device. I already have enough stuff lying around. Unfortunately, the DHO800 series doesn't have one built in.
I had already been thinking about a DS1074Z-S back then, but at the time I had no use for a logic analyzer.
-
I had both and I think DS1054Z is much better and much less problematic.
From the beginning to this day, firmware in a DHO800/900 is a piece of sh*t, written by some interns. Only one positive side is hackable (even up to the 1 GHz) bandwidth.
That seems like a rather distorted take on the DHO800. I had the DS1054Z for many years, and the DHO1074 (largely the same firmware as the 800) for a couple of months. While I eventually decided for the competing SDS814X HD from Siglent, I would certainly say that the DHO800 is better than the DS1000Z in many respects -- and I am not aware of a single aspect where it is worse:
12 bits; higher bandwidth option available; more memory; decoding from full memory; higher screen resolution; touch screen; dual flex encoders for parameter setting; HDMI output. I wish they would optimize the UI's use of screen real estate a bit more (like in mrisco's modified version), but again, I am not aware of a situation where the old DS1054Z displays more/better information on its lower-resolution screen.
So in which respects do you find the DS1054Z "better and less problematic"?
-
I don't want to analyze anything special.
C'mon... give us one example of something you've analyzed before.
(or two...)
-
on the ds1054z even if the track is much thicker, it seems less wavy ...
-
I don't want to analyze anything special. I now have an AZ Delivery Logic Analyzer. I would have liked to have something in one device. I already have enough stuff lying around. Unfortunately, the DHO800 series doesn't have one built in.
I had already been thinking about a DS1074Z-S back then, but at the time I had no use for a logic analyzer.
In case you have not seen it, there is a relevant parallel thread which is active at the moment: https://www.eevblog.com/forum/testgear/what-to-buy-dedicated-logic-analyzer-vs-the-new-scopes-aka-sds824dho924(s)/msg5730101/#msg5730101 (https://www.eevblog.com/forum/testgear/what-to-buy-dedicated-logic-analyzer-vs-the-new-scopes-aka-sds824dho924(s)/msg5730101/#msg5730101)
I'm not sure "something in one device" is necessarily better. If you could elaborate where your current DSO1054Z + cheap AZ Delivery logic analyser falls short of your needs, it would be easier to make suggestions.
Maybe you need a better scope (12 bits?); maybe you need a better USB/PC-based logic analyser (faster? more channels?); maybe you actually need to see analog and digital channels on the same screen. Please let us know what functionality you are currently missing.
-
So in which respects do you find the DS1054Z "better and less problematic"?
Measurements taking less space and using them takes much less time. Much less bugs. Faster boot is useful when You need scope 1-3 times per day to check something - which is often the case when You have repair workshop.
-
So in which respects do you find the DS1054Z "better and less problematic"?
Measurements taking less space and using them takes much less time. Much less bugs. Faster boot is useful when You need scope 1-3 times per day to check something - which is often the case when You have repair workshop.
Sounds like you need one of those Zeeweii 'scopes:
https://www.eevblog.com/forum/testgear/another-dsodmm-zeeweii-dso3d12-claimed-120mhz250msps/ (https://www.eevblog.com/forum/testgear/another-dsodmm-zeeweii-dso3d12-claimed-120mhz250msps/)
Leave the Rigol for the pros.
-
So in which respects do you find the DS1054Z "better and less problematic"?
Measurements taking less space and using them takes much less time. Much less bugs. Faster boot is useful when You need scope 1-3 times per day to check something - which is often the case when You have repair workshop.
Sounds like you need one of those Zeeweii 'scopes:
https://www.eevblog.com/forum/testgear/another-dsodmm-zeeweii-dso3d12-claimed-120mhz250msps/ (https://www.eevblog.com/forum/testgear/another-dsodmm-zeeweii-dso3d12-claimed-120mhz250msps/)
Leave the Rigol for the pros.
Second time when I see offensive trolling from You. Do You have some kind of problems?
-
As you know, the new firmware version 00.01.04.00.02 supports the new DHO824 model with a bandwidth of 200 MHz and a memory depth of 50M, so you can change your DHO8xx to 824, and not to 924 with its non-working logic analyzer panel.
I recompiled (for Windows) the utility from zelea2, adding the DHO824 model to it.
Other community members also added the 824 model to this utility:
- for Mac OS - https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-v00-01-04-00-02-2024111/msg5729989/#msg5729989 (https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-v00-01-04-00-02-2024111/msg5729989/#msg5729989)
- for Android, to run directly on the oscilloscope - https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-v00-01-04-00-02-2024111/msg5732037/#msg5732037 (https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-v00-01-04-00-02-2024111/msg5732037/#msg5732037)
[attach=2]
-
just tried to dowload this zip file, but my pc is blocking dowload :-//
virus detected: Trojan:Script/Wacatac.B!ml
-
just tried to dowload this zip file, but my pc is blocking dowload :-//
virus detected: Trojan:Script/Wacatac.B!ml
And You are using Windows as OS?
-
There's an exe file inside that zip
-
clamscan Pobrane/rigol_vendor_bin_824.zip
Loading: 16s, ETA: 0s [========================>] 8.70M/8.70M sigs
Compiling: 3s, ETA: 0s [========================>] 41/41 tasks
/home/ramzes/Pobrane/rigol_vendor_bin_824.zip: OK
----------- SCAN SUMMARY -----------
Known viruses: 8700659
Engine version: 1.0.7
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.04 MB
Data read: 0.01 MB (ratio 3.00:1)
Time: 21.139 sec (0 m 21 s)
Start Date: 2024:12:01 14:27:11
End Date: 2024:12:01 14:27:32
-
Yes, I'm using Windows.
Microsoft Defender is blocking the download.
-
Yes, I'm using Windows.
Microsoft Defender is blocking the download.
This is one of the reasons why Im not using Windows. I don't have time for such problems.
-
Yes, I'm using Windows.
Microsoft Defender is blocking the download.
This is one of the reasons why Im not using Windows. I don't have time for such problems.
install avast (free version if you tight arse) defender overridden, avast can be disabled at will and download any virus you want...
-
install avast (free version if you tight arse) defender overridden, avast can be disabled at will and download any virus you want...
Avast on a Linux?
-
just tried to dowload this zip file, but my pc is blocking dowload :-//
virus detected: Trojan:Script/Wacatac.B!ml
My Symantec is silent. On VirusTotal the result is 3 out of 72. So your antivirus is clearly paranoid :)
-
install avast (free version if you tight arse) defender overridden, avast can be disabled at will and download any virus you want...
Avast on a Linux?
Avast Linux isn't free. Most Linux users looking for malware protection choose ClamAV.
-
Speaking as a developer: Antivirus is a pain in ass these days.
I get people calling me all the time saying "It says it's a virus!!!" when they try to install things.
Such is life.
-
My dho came and it's got a different psu and usb connector from any of the ones I have seen
-
@BrokeEngineering: Has the USB-C receptacle on the device been changed to accommodate the locking mechanism?
-
Yes, and has a tab for release
-
@BrokeEngineering: Has the USB-C receptacle on the device been changed to accommodate the locking mechanism?
I don't think it was changed, there was already a hole on the side of the USB-C port for the lock.
-
@BrokeEngineering: Has the USB-C receptacle on the device been changed to accommodate the locking mechanism?
I don't think it was changed, there was already a hole on the side of the USB-C port for the lock.
yes but the power supply that came with it, the USB C has the centering pin and the locking mechanism. Refer to first picture I posted
-
This is just the PSU delivered with the new multimeter and the new AWG in DHO design. They always had the lock pin.
-
Its what came with my DHO804
-
This is just the PSU delivered with the new multimeter and the new AWG in DHO design. They always had the lock pin.
I think the pin was originally there because they supplied a 12V power supply with a USB plug on it and the pin meant you couldn't plug it into a 5V phone and kill it.
-
Hi, would you mind my asking you to confirm? Thanks!
Name: minimal_adb_fastboot_1.4.3_portable.zip
Size: 1195695 bytes : 1167 KiB
SHA256: e8a4428ce0bb405b0f657b72e120ed7ea36e295a047c068aec63071bf77fd916
Name: rigol_vendor_bin_824.zip
Size: 14277 bytes : 13 KiB
SHA256: bcec4179c4eff80111f7d273b6d67e52c5be53e94c72e8e73be9765c8df066fa
-
Hey, I'm a new owner of a DHO804. Could you clear up some confusion regarding jailbreaking this model?
- Do I need to first upgrade to the latest firmware for DHO804 before installing firmware for another model (e.g. DHO824, 924, etc.)?
- What is the difference between jailbreaking to
- DHO824
- DHO924
- Simply doing the software license unlocks and keeping it the same model
-
install avast (free version if you tight arse) defender overridden, avast can be disabled at will and download any virus you want...
Avast on a Linux?
linux needs avast antivirus maa? i dont think so... i mean on (the hated) Windows... :palm: i mean if you install avast antivirus on Windows, your hatred will be gone.
-
Hey, I'm a new owner of a DHO804. Could you clear up some confusion regarding jailbreaking this model?
- Do I need to first upgrade to the latest firmware for DHO804 before installing firmware for another model (e.g. DHO824, 924, etc.)?
- What is the difference between jailbreaking to
- DHO824
- DHO924
- Simply doing the software license unlocks and keeping it the same model
Technically there is no jail breaking, you are already root.
The BW7T10 option unlocks the 100MHz bandwith on the DHO804, but there is no option to unlock the 200MHz bandwidth, you have to change the vendor.bin file to DHO824 or DHO924 (but you'll still be limited by the 150MHz probes).
-
Thanks. What is the difference between 824 and 924 vendor bin sideloading? The 924 has features like bode plots and the LA which won't be possible to use on the 804 I suppose? While 824 will give you 50MHz less (200 instead of 250)?
Additionally, is there a single source for these vendor bins for the latest firmware that I can find? (Not downloading random files off forum replies)
-
Thanks. What is the difference between 824 and 924 vendor bin sideloading? The 924 has features like bode plots and the LA which won't be possible to use on the 804 I suppose? While 824 will give you 50MHz less (200 instead of 250)?
That's correct.
Additionally, is there a single source for these vendor bins for the latest firmware that I can find? (Not downloading random files off forum replies)
There is no single source, the file is generated specifically for your device.
-
I was under the impression an arbitrary file can be generated with this utility (e.g. for 924, 824 models) https://github.com/zelea2/rigol_vendor_bin?
-
I was under the impression an arbitrary file can be generated with this utility (e.g. for 924, 824 models) https://github.com/zelea2/rigol_vendor_bin?
Yes, that's right. Except for 824 - the utility doesn't know this new model, because it hasn't been updated by the author yet.
-
Thanks for the tutorial by the way, it's very helpful. Is there any drawback besides UI elements being unavailable going from 804 to 924 for example? Any benefits over using 924 instead of 824 besides the extra 50MHz?
It sounds like it would be more stable to do DHO824->DHO924.
I'm looking into the GitHub project to see if it's trivial to add DHO824 support, perhaps I'll make a PR.
Thanks again :)
-
Any benefits over using 924 instead of 824 besides the extra 50MHz?
Unlocking it to 924 is a well tested proven path.
The 824 mode is new. Not necessarily there will be issues, of course, but it has not been tested as extensively as the 924 mode yet.
-
Thanks for the tutorial by the way, it's very helpful. Is there any drawback besides UI elements being unavailable going from 804 to 924 for example? Any benefits over using 924 instead of 824 besides the extra 50MHz?
It sounds like it would be more stable to do DHO824->DHO924.
I'm looking into the GitHub project to see if it's trivial to add DHO824 support, perhaps I'll make a PR.
Thanks again :)
In addition to the additional 50 MHz, the 924 also has a vertical limit of 200 µV (like the 914). The 824 has a minimum limit of 500 µV. I did not find any other differences :)
Forum participants have already added the 824 model to the utility from zelea2 - for MacOS, for Windows and for running it on the oscilloscope itself, I gave links in my message with an attached archive of the updated utility :)
-
In addition to the additional 50 MHz, the 924 also has a vertical limit of 200 µV (like the 914). The 824 has a minimum limit of 500 µV. I did not find any other differences :)
Do you know if that applies only to the displayed scale, or also to the resolution of the measurements?
-
In addition to the additional 50 MHz, the 924 also has a vertical limit of 200 µV (like the 914). The 824 has a minimum limit of 500 µV. I did not find any other differences :)
Do you know if that applies only to the displayed scale, or also to the resolution of the measurements?
This is a display only scale, scaled from the 1mV/div scale.
-
What is the point of this extra scaling if it's simply software scaling? You're losing data there I assume.
The rise time of the 924 seems to also be faster than other models, I suppose this is a hardware limitation, not software?
I reckon the extra 50 MHz also doesn't make a difference anyways if you're using the stock 150MHz probes :). Sounds like the 824 is a better choice to not get the erroneous UI elements.
-
What is the point of this extra scaling if it's simply software scaling? You're losing data there I assume.
If the "physical" resolution (determined by the pre-amplifier and ADC) is 1 mV/div, that's a bit more than 8 mV for the full 4096 ADC counts. So approximately 500 counts/div, more than the screen resolution.
The software-magnified 500 µV/div and 200 µV/div will let you zoom in a bit further, in theory to a level where ADC steps and screen pixels are on a comparable scale. Whether that's useful in practice or just lets you magnify the noise is another matter...
-
Sorry, I'm a young player! New to scopes
-
What is the point of this extra scaling if it's simply software scaling? You're losing data there I assume.
You have a 12 bit measurement ... it's measuring down to microvolts even though the front end amplifier is set to "1mV per division".
-
Sorry, I'm a young player! New to scopes
You'd have been correct on an 8-bit 'scope, but these aren't 8 bits.
-
Sorry, I'm a young player! New to scopes
No problem at all, it was a viable question. For the older 8-bit scopes, software-based vertical zoom is typically just for specsmanship -- the high "sensitivity" looks good in the datasheet, but in practice it lets you see either ADC steps or noise on the screen.
With the additional ADC steps of the 12-bit scopes, the software zoom becomes more meaningful. Although I would argue that at least the 200 µV/div setting of the DHO900 series is a bit over the top -- you won't see ADC steps, but will probably get drowned in noise in most situations. Still, with enough averaging it may be useful at times to better see very small periodic signals.
-
With the additional ADC steps of the 12-bit scopes, the software zoom becomes more meaningful. Although I would argue that at least the 200 µV/div setting of the DHO900 series is a bit over the top -- you won't see ADC steps, but will probably get drowned in noise in most situations.
Baseline noise on these is about 60uV, IIRC, so a 200uV/div setting is pushing it but it isn't silly.
-
The rise time of the 924 seems to also be faster than other models, I suppose this is a hardware limitation, not software?
No, the input hardware of 8xx and 9xx are the same. The rise time is set programmatically along with the bandwidth limitation.
-
The rise time of the 924 seems to also be faster than other models, I suppose this is a hardware limitation, not software?
No, it's software.
A DHO804 can do it, too.
-
Here is the same oscilloscope (born as 814) converted to 804 and 924. The rise time, as you can see, changes with the model (the first two screenshots with the 2nd channel). The third screenshot (with the 1st channel) is a channel with a physically changed input section to expand the bandwidth :)
-
The rise time, as you can see
Rise time measurement by default automatically defines voltage levels for 10% and 90%, which not always works as it should. You can enable view (lines) for that levels and very often it jumps around like crazy - especially with fast generators. But those levels can be changed - both in % and in voltage. I did this second one with removed ADC LC filters (in original 924S) and I went down to 800 ps (same as sample rate) in normal acquisition and around 750 ps (I don't remember exact value) in average acquisition.
However, sinc interpolation with fast rise times is a pain in the back of the scope. Only way to change it into linear/point display is by reverse engineering and modifying libscope-auklet.so, which is not easy (I tried, but it's hard to understand what is going on in this lib decompiled).
-
You can enable view (lines) for that levels and very often it jumps around like crazy - especially with fast generators.
That's why I opened the measurement panel so that the average value could be seen :)
However, sinc interpolation with fast rise times is a pain in the back of the scope. Only way to change it into linear/point display is by reverse engineering and modifying libscope-auklet.so, which is not easy (I tried, but it's hard to understand what is going on in this lib decompiled).
I looked at libscope-auklet in disassembler and I got the impression that the FPGA is directly responsible for drawing the waves.
-
You can enable view (lines) for that levels and very often it jumps around like crazy - especially with fast generators.
That's why I opened the measurement panel so that the average value could be seen :)
Still it's way better to manually set those levels.
-
Although I would argue that at least the 200 µV/div setting of the DHO900 series is a bit over the top -- you won't see ADC steps, but will probably get drowned in noise in most situations. Still, with enough averaging it may be useful at times to better see very small periodic signals.
Yes, averaging works pretty well in this scenario. I played with it quite extensively once when I needed to measure a very small repetitive signal pretty much hidden in noise, and turning on averaging was almost like magic.
-
turning on averaging was almost like magic.
Same thing when I removed LC filters in one channel. After that, noise is quite high, but playing with high frequency (above 250 MHz) with repetitive signals is way easier with averaging enabled.
-
Hi everyone,
Today, I received my new Rigol DHO914, which comes with factory-installed firmware version 00.01.01.00.02. However, it seems this version has quite a few bugs.
Before diving into testing this device, I have a few questions:
- Is it possible to remove the SD card with the operating system and boot the oscilloscope from a USB drive (e.g., a pendrive) running Android/Linux?. I aks because RK3399 SoC supports USB booting.
- I’d like to upgrade my DHO914 to the DHO924. Can this be achieved by editing only the vendor.bin file without affecting critical data like calibration information? If not, do you know of any other safe methods?
- The DHO914 supports logic analyzer (LA) connections, but the official PLA2216 probe is quite expensive. I’m considering building my own DIY LA probe. There are several designs available online, such as this one: https://www.cnblogs.com/spaceship9/p/18234908 (https://www.cnblogs.com/spaceship9/p/18234908) Which of these projects would you confidently recommend?
- Does the oscilloscope support external portable touch screens connected via HDMI?
- Can the DHO914 be powered via a USB-C power bank?
-
Is it possible to remove the SD card with the operating system and boot the oscilloscope from a USB drive (e.g., a pendrive) running Android/Linux?. I aks because RK3399 SoC supports USB booting.
I didn't tried from a USB, but if You want to boot Linux from SD card: https://github.com/norbertkiszka/orangerigol - this is a full build, which will generate image, flash SD card and resize partition to use its full capacity.
I’d like to upgrade my DHO914 to the DHO924. Can this be achieved by editing only the vendor.bin file without affecting critical data like calibration information? If not, do you know of any other safe methods?
In worst case scenario, You will run self-calibration.
Does the oscilloscope support external portable touch screens connected via HDMI?
Yes.
Can the DHO914 be powered via a USB-C power bank?
Yes. It needs 12 V at 4 A or 15 V at 3 A. You can power it from practically anything and it doesn't need PD communication (if voltage is somewhere between 12-15 V).
-
You can power it from practically anything and it doesn't need PD communication (if voltage is somewhere between 12-15 V).
Just for clarity, you've tested that and found it to work?
-
You can power it from practically anything and it doesn't need PD communication (if voltage is somewhere between 12-15 V).
Just for clarity, you've tested that and found it to work?
I tested it from a laboratory power supply. The oscilloscope works at a voltage of 11 to 16 volts. At a lower voltage it switches off, and I did not risk trying a higher one :)
-
Just for clarity, you've tested that and found it to work?
12V is 12V. There's no magic about the electrons coming from USB PD.
The first batches of these 'scopes came with fixed 12V power supplies.
-
Just for clarity, you've tested that and found it to work?
12V is 12V. There's no magic about the electrons coming from USB PD.
The first batches of these 'scopes came with fixed 12V power supplies.
My question, quite obviously, relates to the requirement for the scope to have any kind of successful PD negotiation in order to 'accept' the supply and allow start up.
And no, not everyone knows what early versions of a scope they didn't buy were supplied with. That's why we ask questions.
-
Does the oscilloscope support external portable touch screens connected via HDMI?
Yes.
I think only monitor via HDMI.
For touchscreen support you need most likely USB connection.
-
I think only monitor via HDMI.
For touchscreen support you need most likely USB connection.
Yep. Dave did it in one of his videos.
-
My DHO804 is my second/spare oscilloscope, which is rarely used. That's why it hasn't yet been liberated and still has the first firmware on it. Can I safely upgrade it now to 1.04 and still hack it later? Or shall I make a copy of the internal SD card first?
(I am sorry if this already has been covered somewhere above - I missed it then).
-
My DHO804 is my second/spare oscilloscope, which is rarely used. That's why it hasn't yet been liberated and still has the first firmware on it. Can I safely upgrade it now to 1.04 and still hack it later? Or shall I make a copy of the internal SD card first?
(I am sorry if this already has been covered somewhere above - I missed it then).
It is useful to make a copy of the SD just in case, but yes, you can update it without a copy, be sure to calibrate it after the update, and hack it after that.
-
Can I safely upgrade it now to 1.04 and still hack it later?
Yes.
-
I would love to have a personalized caption instead of the standard "Waveform view". Can this be hacked?
-
Hi. Does anyone perhaps know what is the maximum supply voltage for an oscilloscope with usbc? I was thinking to connect a 20v battery from a screwdriver. I know you can power 12v and 15v, but what about higher ones?
-
MPM3630
-
I would love to have a personalized caption instead of the standard "Waveform view". Can this be hacked?
So, do you want to change this name somewhere yourself or just change it to another fixed one?
-
I want to give my own name. Eg "Dut1 Exp1".
I would love to have a personalized caption instead of the standard "Waveform view". Can this be hacked?
So, do you want to change this name somewhere yourself or just change it to another fixed one?
-
I want to give my own name. Eg "Dut1 Exp1".
Changing to another fixed name is easy, making it so you can customize this name is difficult and hardly anyone will do it.
-
Hi. Does anyone perhaps know what is the maximum supply voltage for an oscilloscope with usbc? I was thinking to connect a 20v battery from a screwdriver. I know you can power 12v and 15v, but what about higher ones?
It depends on the device.
These 'scopes seems designed for 12-15V. 20V will probably kill them.
-
MPM3630
Ok. I'm going to use the battery from a dji phantom 4 drone. It already has a BMS and is up to 17.4V :)
-
17.4V
Risky thing to do, since probably nobody tested this scope with voltage higher than 16 V. Anyway, it's Your scope :-BROKE
-
Ok. I'm going to use the battery from a dji phantom 4 drone. It already has a BMS and is up to 17.4V :)
Be sure to record a video and post it here. :)
-
Ohms law: The cause of, and the solution to, all electrical mishaps.
-
If you used something like this you could really use whatever tool battery you wanted:
https://www.digikey.com/en/products/detail/murata-power-solutions-inc/UWS-12-4-5-Q12P-C/10427639 (https://www.digikey.com/en/products/detail/murata-power-solutions-inc/UWS-12-4-5-Q12P-C/10427639)
Just as an example, not an endorsement. There are certainly better or cheaper ones to be found.
-
Four cells charged to 4 V gives 16 V. At 3 V it gives 12 V. With little protection against over discharge and cut off at 16 V, I think this will be the best solution. Also less noise, because bulk converter makes some noise and battery by itself is practically pure DC.
-
My 2P4S program ternary lithium battery, oscilloscope is not broken at present
-
Has anyone tried powering it at 17.4v max?
-
Has anyone tried powering it at 17.4v max?
Your question literally can be translated to: has someone lost their mind an tried to destroy his/her scope with higher voltage than designed?
Im afraid, even Im not that crazy person. Not that much.
BTW. Did You try to read full documentation of this MPM3630 which LEER333 gives part of it? There is one plot that can give You answer what can happen with higher voltage.
-
Has anyone tried powering it at 17.4v max?
Your question literally can be translated to: has someone lost their mind an tried to destroy his/her scope with higher voltage than designed?
Yes.
MPM3630 is max 18V.
-
People usually charge to 4.2V, 4S fully charged 16.8V, when loaded with 2.5-3A (what is the DHO's current at 15V?) it will drop down a litle bit and you get drop on the cables and connector too. So 16.4V let say.
Put 2x Si diodes (not schottky one, a beefier for 5-10A one) in series and you are at around 15V..
-
MPM3630 is max 18V.
So go ahead and try to destroy Your scope, because You were too lazy to Google for datasheet of MPM3630 and read it.
Anyway, if it will be broken, tell us how long it will take.
People usually charge to 4.2V, 4S fully charged 16.8V, when loaded with 2.5-3A (what is the DHO's current at 15V?) it will drop down a litle bit and you get drop on the cables and connector too. So 16V let say.
Put 2x Si diodes (not schottky one, a beefier for 5-10A one) in series and you are at around 15V..
Charging Lion to around 4 V instead of 4.2 V will make them last longer. Same as charging phone to 83%. One diode and we have around 15.5 V. Good enough for Australia.
-
I've been reading, and I don't see any contraindications for 17.4V.
And there is even information for ultra-high voltages ie 20volts.
In my case there will be a maximum of 17.4v, which will drop when the battery is loaded.
ABSOLUTE MAXIMUM RATINGS (1)
V IN ................................................... -0.3V to 20V
V OUT ................................................. -0.3V to 20V
V SW .......................................................................
-0.3V (-5V for <10ns) to 20V (22V for <10ns)
V BST ....................................................... VSW +5.5V
All other pins .............................. -0.3V to 5.5V (2)
Continuous power dissipation (T A = +25°C) (3)
............................................................... 2.7W
Junction temperature ................................ 150°C
Lead temperature...................................... 260°C
Storage temperature ................... -65°C to 150°C
Recommended Operating Conditions (4)
Supply voltage (V IN) ......................... 4.5V to 18V
Output voltage (V OUT ) ……………………………..
………………………...……...0.6V to V IN *D MAX (5)
Operating junction temp. (T J ). ...-40°C to +125°C
-
..Charging Lion to around 4 V instead of 4.2 V will make them last longer. Same as charging phone to 83%..
My phone Sammy was charging to 85% this spring (new model with off the shelf fw) after the first update it charges to 80% :) .
I've read somewhere the US army's recent recommendation (or command?) is to charge to 3.9Volt..
PS: based on the current (I assume 2.5A at 15-16V) the power loss at the series diode will be up to 2.5W, so it will get hot!
-
PS: based on the current (I assume 2.5A at 15-16V) the power loss at the series diode will be up to 2.5W, so it will get hot!
It's simple - we multiply the voltage drop across the diode at a given current by this current and get the watts of heat on this diode.
And yes, even 1 watt of heat is too much for a diode without a radiator.
-
I've been reading, and I don't see any contraindications for 17.4V.
In the diagrams you will see that the MPM3630 efficiency suffers a bit when operating at 18V, so it will run hotter. Not sure whether that effect will be significant, but you can't just say "I don't see any contraindications".
Also, did you confirm that there are not other components with marginal specs in the supply circuit? I would very much hope that Rigol did not use 16V electrolytic caps, but it's worth checking.
-
In the diagrams you will see that the MPM3630 efficiency suffers a bit when operating at 18V, so it will run hotter.
You did his job. He should learn to move his a** and do his job instead using others time. He get IC model name on the forum, so what was stopping him to read documentation? This is 5 minutes of works.
Probably nobody did a full reverse engineering of this scope, so nobody knows how long it will work at voltage above 15 V - maybe 5 years and maybe 5 seconds until magic smoke will escape.
This scope was designed to be cheap as possible (more than possible to be honest), so I don't expect from it to handle too much. Same as "300 V" as maximum input voltage (BNC), which I think is far from true.
-
Exactly Sir.
-
Has anyone tried powering it at 17.4v max?
You can be the first!
-
It's simple - we multiply the voltage drop across the diode at a given current by this current and get the watts of heat on this diode.
And yes, even 1 watt of heat is too much for a diode without a radiator.
There are quite beefy diodes in classic cylindrical packages like the 1N5400 series that can handle 3A (or probably more like 2A if you don't pay special attention to how it's mounted), or even 6Axx series spec'd at 6A, and I'm sure there are beefier ones still.
I'd rather worry about the actual energy wasted on the diodes instead of it going into the scope. It's not a small amount. Ideally, a properly chosen battery should be used. Since the scope is known to work fine from 12V, a 4s LiFePo4 battery will work, and I'm almost certain that a 3s NMC battery will work just as well.
-
You may create an android app inside DHO, which will measure the voltage at the battery via the channel 4, when above 15V it will switch in the serial dropper diode (for example a relay contacts in parallel to the diode will disengage), when below 15V the relay contacts will engage and bypass the diode by shorting it.. A nice project for a Sunday afternoon.. :D :D
-
Easier and faster will be to use comparator, opamp or simple transistor based circuit.
Software is on thing, driving GPIO pin is another. Anyway, there is already one module in binary form, so it can be renamed and changed pin only - and that will require some heavy reverse engineering software like Ghidra.
-
There are quite beefy diodes in classic cylindrical packages like the 1N5400 series that can handle 3A (or probably more like 2A if you don't pay special attention to how it's mounted), or even 6Axx series spec'd at 6A, and I'm sure there are beefier ones still.
I'd rather worry about the actual energy wasted on the diodes instead of it going into the scope. It's not a small amount. Ideally, a properly chosen battery should be used. Since the scope is known to work fine from 12V, a 4s LiFePo4 battery will work, and I'm almost certain that a 3s NMC battery will work just as well.
It is not difficult to find a diode that can handle 3A, but 1.5-2 W remains 1.5-2 W. This is not very convenient when you have a part heated to the boiling point of water or even higher next to the battery or directly on the wire.
-
This is not very convenient when you have a part heated to the boiling point of water or even higher next to the battery or directly on the wire.
Just as reminder. Wires with insulation made from PVC (DY, LY) should't be heated to more than 70 °C (158 °F). Other insulation materials can handle more (or less?), but everybody should do their research if needed.
-
I thought this was a EE forum. Its mind numbly simple to strap a nice Buck-Boost converter to a 17V battery pack output with a nice 5A output for some margin (There is one on AE that can do this comfortably for 2$) and slap that on the output of the batteries, add a bulk cap or two for the ripple and step down to output to 15V. I mean cmon guys, no use being smartasses. And if you are paranoid slap a under voltage module on the output of the battery back before the buck boost to stop the batteries from being over-drained if they dont get a smart IC on them..
-
If you guys really want to Il even make you a PCB with a damn integrated charger for the batteries and a USB C to go on the scope input with all the safeties, just give me the 3D model for the battery pack strap so I can make the PCB dimensions.
-
There are quite beefy diodes in classic cylindrical packages like the 1N5400 series that can handle 3A (or probably more like 2A if you don't pay special attention to how it's mounted), or even 6Axx series spec'd at 6A, and I'm sure there are beefier ones still.
I'd rather worry about the actual energy wasted on the diodes instead of it going into the scope. It's not a small amount. Ideally, a properly chosen battery should be used. Since the scope is known to work fine from 12V, a 4s LiFePo4 battery will work, and I'm almost certain that a 3s NMC battery will work just as well.
It is not difficult to find a diode that can handle 3A, but 1.5-2 W remains 1.5-2 W. This is not very convenient when you have a part heated to the boiling point of water or even higher next to the battery or directly on the wire.
You would need a DPAK case at MINIMUM to dissapte that much heat and it will still get toasty very quickly although I did a 500mV FV do-277 mosfet at 4-5 amps and it got to around 85C after like 10-25 mins, but thats way too hot for my likings
-
I thought this was a EE forum. Its mind numbly simple to strap a nice Buck-Boost converter to a 17V battery pack output with a nice 5A output for some margin
This can quickly become not so trivial if you take noise considerations into account. You'd want a converter that doesn't create much noise on both the DC output and as EMI.
-
I thought this was a EE forum. Its mind numbly simple to strap a nice Buck-Boost converter to a 17V battery pack output with a nice 5A output for some margin
This can quickly become not so trivial if you take noise considerations into account. You'd want a converter that doesn't create much noise on both the DC output and as EMI.
Also converters are not 100% efficient. As You mentioned earlier, LiFePo4 is a great idea both due to voltage and also more safe than Lion and Lipo.
-
This agrees,
The battery is the purest power source, with the least background noise
-
For purity: Get a 1 Ohm, 50W resistor. That'll drop 3V at 3A and they're really cheap.
https://www.aliexpress.com/item/1005002172683755.html (https://www.aliexpress.com/item/1005002172683755.html)
-
For less noise it will be better to add missing caps into empty pads on PCB. Some time ago I added some, but I was too lazy to fill all pads... Maybe later I will test with adding to all pads, especially since right now I have some better quality caps.
-
For purity: Get a 1 Ohm, 50W resistor. That'll drop 3V at 3A.
Just make sure you never turn the scope off while it is connected to that power source. ::)
-
For purity: Get a 1 Ohm, 50W resistor. That'll drop 3V at 3A.
Just make sure you never turn the scope off while it is connected to that power source. ::)
-
https://sven.killig.de/android/DHO/
Has anyone been able to get this working with the V1 usb? Unfortunately whenever I start using a bluetooth peripheral, like a mouse, the whole scope crashes. I still need to figure out how to input actual characters for Wi-Fi to test it, as the On-Screen keyboard doesn't pop up.
-
https://sven.killig.de/android/DHO/
Has anyone been able to get this working with the V1 usb? Unfortunately whenever I start using a bluetooth peripheral, like a mouse, the whole scope crashes. I still need to figure out how to input actual characters for Wi-Fi to test it, as the On-Screen keyboard doesn't pop up.
Wait a minute... You were able to make Linux kernel able to load Rigol modules in original binary form?
I did a build script to run Debian on this scope (https://github.com/norbertkiszka/orangerigol), but because of lack of Module.symvers and headers (generated at compile time) I was almost unable to load even only one of them, even when I was using same Android kernel - at very best it was loaded but it didn't work.
Without those modules I can't run this app on another system. Theoretical possibility was to load their kernel as it is in binary form, but this is very bad thing, because it's no longer open source and no longer compliant with the GPL license.
-
Do you think this AC-DC supply provided is noise free? I bet you it does not have any serious output filtering.
Its not so difficult to create a parallel damped output filter.
Again if someone gives me the dimensions for the PCB needed I will make it and then we can check performance. I will use a low EMI DC-DC and do some nice bulk capacitance with a output filter.
There SHOULD be filtering on the input of the scope, considering they have shipped with a whole bunch of different AC-DC PSU's I am guessing there is at least some HALF decent input filtering in the scope power rails.
-
Those scopes was provided with many different PSU. I had LiteOn which I tested and dissasembled to find out it was made "little" unsafe. Lately somebody shared that he get Delta brand PSU. In my opinion Delta is doing very good PSUs or at least it was good some years ago.
-
https://sven.killig.de/android/DHO/ (https://sven.killig.de/android/DHO/)
Has anyone been able to get this working with the V1 usb? Unfortunately whenever I start using a bluetooth peripheral, like a mouse, the whole scope crashes.
I just retested the EW-7611ULB V1 successfully using my updated script (https://sven.killig.de/android/DHO/rtl8723.tgz) (thanks to Spectra's hint it now also works for e.g. the Comfast CF-723B (https://www.aliexpress.com/item/1005005079249433.html)):
rk3399_rigol:/ # rtl8723.sh
Bus 003 Device 002: ID 7392:a611
RTL8723BU
I still need to figure out how to input actual characters for Wi-Fi to test it, as the On-Screen keyboard doesn't pop up.
rk3399_rigol:/ # input text "test"
-
Those scopes was provided with many different PSU. I had LiteOn which I tested and dissasembled to find out it was made "little" unsafe. Lately somebody shared that he get Delta brand PSU. In my opinion Delta is doing very good PSUs or at least it was good some years ago.
I got a Delta with my scope, I ordered it about 2 weeks ago direct from Rigol Shop EU
It does run a bit warm though.
I ordered a thermal camera, when it comes I will measure its temp and report, I dont wanna deal with thermistors checking at various places lol.
-
This agrees,
The battery is the purest power source, with the least background noise
Do not expect the battery powering will help you get rid of switcher's noise. There are other switchers on the pcb too (15v->3.3V, 1.8V etc).
Is there any measurement of the noise floor with the battery vs. the stock psu?
For purity: Get a 1 Ohm, 50W resistor. That'll drop 3V at 3A and they're really cheap.
https://www.aliexpress.com/item/1005002172683755.html (https://www.aliexpress.com/item/1005002172683755.html)
Drop down resistor with regulation:
-
Drop down resistor with regulation:
With this, that scope will be a fully mobile device.
-
For purity: Get a 1 Ohm, 50W resistor. That'll drop 3V at 3A and they're really cheap.
https://www.aliexpress.com/item/1005002172683755.html (https://www.aliexpress.com/item/1005002172683755.html)
You dont need a 50W resistor to drop 1V @ 3 amps, you need like 333 milliohms and ur only dissipating 3 watts. So a 25W or even a 10W is more then adequate
https://vi.aliexpress.com/item/1005002646356939.html?spm=a2g0o.productlist.main.4.13c24431fvNimE&algo_pvid=06a4af59-878c-48c7-b460-41e4a8be75d8&aem_p4p_detail=202412121325103253369858468560001897529&algo_exp_id=06a4af59-878c-48c7-b460-41e4a8be75d8-3&pdp_npi=4%40dis%21BGN%211.40%211.21%21%21%210.74%210.64%21%40210390b817340387102108399e1e6a%2112000021541676525%21sea%21BG%213156952160%21X&curPageLogUid=ZvMOyX8WD0KJ&utparam-url=scene%3Asearch%7Cquery_from%3A&search_p4p_id=202412121325103253369858468560001897529_1 (https://vi.aliexpress.com/item/1005002646356939.html?spm=a2g0o.productlist.main.4.13c24431fvNimE&algo_pvid=06a4af59-878c-48c7-b460-41e4a8be75d8&aem_p4p_detail=202412121325103253369858468560001897529&algo_exp_id=06a4af59-878c-48c7-b460-41e4a8be75d8-3&pdp_npi=4%40dis%21BGN%211.40%211.21%21%21%210.74%210.64%21%40210390b817340387102108399e1e6a%2112000021541676525%21sea%21BG%213156952160%21X&curPageLogUid=ZvMOyX8WD0KJ&utparam-url=scene%3Asearch%7Cquery_from%3A&search_p4p_id=202412121325103253369858468560001897529_1)
0.33 Ohm, 25W, for like 1 USD
-
Is there any measurement of the noise floor with the battery vs. the stock psu?
Not exactly a measurement, but I've had issues with EM noise radiated by a switching PSU a couple of meters away from the circuit I was probing. Yes it was a particularly noisy one, but that's how I found that it can be an issue.
I don't think that a significant percentage of the radiated noise makes it into the analog frontend's signal path inside the scope, it appears to be well-shielded. And it appears that it's isolated pretty well from the power supply's noise, too, since otherwise we'd be seeing it at a much larger scale than when we have to use extreme vertical zoom to actually see it.
Radiated noise, however, can easily affect probing, forcing you to use the ground spring attachment, or direct coaxial cable connection (with proper impedance matching of course) where otherwise you could maybe get away without it. So putting an additional potentially noisy in terms of EMI circuit in the vicinity of the scope should be something to be wary of.
When I was playing with it, as far as I recall, I didn't find the included PSU (Liteon in my case) to be particularly noisy, unless you get real close. And it can be placed farther away, by the length of the cable. The converters placed inside the scope itself are not noiseless, but again, you have to get close to capture that radiation.
p.s. with all that, I think we'd all sure appreciate if someone captured noise floor pictures with battery power and with the included PSU for a direct comparison.
-
ur only dissipating 3 watts
it's actually U²/R.
don't thank me, always glad to help :)
-
You dont need a 50W resistor to drop 1V @ 3 amps, you need like 333 milliohms and ur only dissipating 3 watts. So a 25W or even a 10W is more then adequate
This is all correct, but the task was to drop 3V. 50W is still generous for that, but your values are not applicable.
But on a more general note, I don't get this whole idea of using voltage drop over a resistor. When the scope is powered "off", there will be negligible current draw and hence the full overvoltage will be applied to the MPM3630 step-down regulator, right?
-
ur only dissipating 3 watts
it's actually U²/R.
don't thank me, always glad to help :)
yes, that's what it is for a 1V drop at 3 amps (3W) with 0.33 ohm resistor. With a 1ohm resistor at 3A its 9W, which again a 25W resistor is more then 2x more capacity.
-
You dont need a 50W resistor to drop 1V @ 3 amps, you need like 333 milliohms and ur only dissipating 3 watts. So a 25W or even a 10W is more then adequate
This is all correct, but the task was to drop 3V. 50W is still generous for that, but your values are not applicable.
But on a more general note, I don't get this whole idea of using voltage drop over a resistor. When the scope is powered "off", there will be negligible current draw and hence the full overvoltage will be applied to the MPM3630 step-down regulator, right?
I think it is stupid as well, a well designed buck-boost with moulded inductors, good layout and a output filter with good decoupling will be more then enough and you will get WAY less efficency loss.
-
Here is a good candidate for a low price https://www.ti.com/product/TPS55340?keyMatch=TPS55340&tisearch=universal_search (https://www.ti.com/product/TPS55340?keyMatch=TPS55340&tisearch=universal_search) TPS55340
-
But on a more general note, I don't get this whole idea of using voltage drop over a resistor. When the scope is powered "off", there will be negligible current draw and hence the full overvoltage will be applied to the MPM3630 step-down regulator, right?
It's for portable use so you wouldn't have the battery connected after power-off.
-
But on a more general note, I don't get this whole idea of using voltage drop over a resistor. When the scope is powered "off", there will be negligible current draw and hence the full overvoltage will be applied to the MPM3630 step-down regulator, right?
It's for portable use so you wouldn't have the battery connected after power-off.
So what would be your sequence of steps for powering it ON? Plug in the battery pack, then press the ON switch real quick and hope that the scope has not suffered from the overvoltage in the meantime?
-
So what would be your sequence of steps for powering it ON? Plug in the battery pack, then press the ON switch real quick and hope that the scope has not suffered from the overvoltage in the meantime?
Some time ago he did some trolling here and he called himself a professional. Waste of time to deal with it.
-
So what would be your sequence of steps for powering it ON? Plug in the battery pack, then press the ON switch real quick and hope that the scope has not suffered from the overvoltage in the meantime?
Don't ask me... I'm not the on insisting on using 20V and 17V drill batteries despite having been told several times that the 'scope runs on 12V.
-
So what would be your sequence of steps for powering it ON? Plug in the battery pack, then press the ON switch real quick and hope that the scope has not suffered from the overvoltage in the meantime?
Don't ask me... I'm not the on insisting on using 20V and 17V drill batteries despite having been told several times that the 'scope runs on 12V.
But you are the one who suggested a dropping resistor. ::)
-
But you are the one who suggested a dropping resistor. ::)
Better with a resistor than without one!
-
But you are the one who suggested a dropping resistor. ::)
Better with a resistor than without one!
Or you could just admit that you had not quite thought this through before posting your original suggestion.
-
I suggest using a voltage regulator... they've been around for a while
-
Or you could just admit that you had not quite thought this through before posting your original suggestion.
Oh, that's what this is about... you think you're outsmarting me!
Tell us, was the "resistor" thing before or after I started posting things like this:
Ok. I'm going to use the battery from a dji phantom 4 drone. It already has a BMS and is up to 17.4V :)
Be sure to record a video and post it here. :)
-
I suggest using a voltage regulator... they've been around for a while
The linear voltage regulator would be the safest way, but anyhow - with a linear regulator the heat created (the power loss) will still be the same.
With say 2.5A and dropping 3V from X volt battery the heat will be I*Vdrop = 7.5Watt..
Another option is to use those LiFe.. something batteries - their full charge is a bit lower, afaik.
BTW this is the same issue as many radio amateurs are coping today with - when going portable with their transceivers (ie SOTA - climbing hills, Fauna-Flora, National Parks, etc.) they want as much as possible power with as less kilograms as possible and as close as possible to 13.8V battery voltage (as many think this voltage is the absolute max limit for their rigs).. :D
-
Do you guys honestly think somebody who wants to run his 'scope off a 20V drill battery is going to start building little PCBs and stuff?
Just tell him to get a USB powerbank, it's what they're for...
-
The linear voltage regulator would be the safest way, but anyhow - with a linear regulator the heat created (the power loss) will still be the same.
With say 2.5A and dropping 3V from X volt battery the heat will be I*Vdrop = 7.5Watt..
Another option is to use those LiFe.. something batteries - their full charge is a bit lower, afaik.
BTW this is the same issue as many radio amateurs are coping today with - when going portable with their transceivers (ie SOTA - climbing hills, Fauna-Flora, National Parks, etc.) they want as much as possible power with as less kilograms as possible and as close as possible to 13.8V battery voltage (as many think this voltage is the absolute max limit for their rigs).. :D
They know about USB-C "decoy" modules, right?
https://www.aliexpress.com/item/1005006179191517.html (https://www.aliexpress.com/item/1005006179191517.html)
-
On the RTC, it looks like it may be fairly easy to add a battery. The RK3399 processor used in the DHO has the RTC, only a few parts are needed, including a Lithium-ion coin cell. Here's one schematic (on page 18) that shows one implementation. You can also search for VCC_RTC. https://hacksterio.s3.amazonaws.com/uploads/attachments/1055542/p710-v12_schematic_design_JzSgZmqN7r.PDF
Not sure I'd make the change until the unit is out of warranty, so I've not tried it myself.
Once the hardware is added, a connection to the Internet should update the RTC to the current time, so no UI changes are needed. Screenshots that include the header would show the correct time, even if disconnected from the Internet.
-
RK808 (on top right of PCB) also has RTC.
-
I recreated on of the Rigol modules, which is hdcode_gpio. It works almost the same: it reads GPIO pins and creates char device (one byte output) /dev/hdcode_gpio (8 in mine DHO924S, I didn't tested on other models).
Two differences are: it's writable and it has better error handling.
Theoretically it's pointless to recreate hdcode_gpio, because we can create /dev/hdcode_gpio as a regular text file with bash (printf '\xc' > /dev/hdcode_gpio) and it works the same. But, this is just a beginning of recreating all modules.
Why? With that, we can do three things. Use normal Linux distribution, use another Android and... compile another kernel in order to use any driver that we want - including wifi drivers (other than only one wifi dongle).
https://github.com/norbertkiszka/rigol-orangerigol-linux_4.4.179/blob/main/drivers/rigol/hdcode_gpio.c
-
Thanks, that helped, wifi seems to work, however the bluetooth is flaky, it connects to my Logitech MX Vertical mouse but then it seemingly drops the connection?
❯ adb shell
rk3399_rigol:/ # dmesg | grep -i bluetooth
dmesg | grep -i bluetooth
[ 0.855826] Bluetooth: Core ver 2.21
[ 0.855878] Bluetooth: HCI device and connection manager initialized
[ 0.855893] Bluetooth: HCI socket layer initialized
[ 0.855905] Bluetooth: L2CAP socket layer initialized
[ 0.855937] Bluetooth: SCO socket layer initialized
[ 1.307918] Bluetooth: HCI UART driver ver 2.3
[ 1.307934] Bluetooth: HCI UART protocol H4 registered
[ 1.307945] Bluetooth: HCI UART protocol LL registered
[ 1.307969] rtk_btusb: Realtek Bluetooth USB driver module init, version 4.1.2
[ 1.853352] Bluetooth: RFCOMM TTY layer initialized
[ 1.853464] Bluetooth: RFCOMM socket layer initialized
[ 1.853642] Bluetooth: RFCOMM ver 1.11
[ 1.853839] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 1.854032] Bluetooth: BNEP filters: protocol multicast
[ 1.854238] Bluetooth: BNEP socket layer initialized
[ 1.854441] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 1.854643] Bluetooth: HIDP socket layer initialized
[ 2.367827] usb 3-1: Product: Edimax Wi-Fi N150 Bluetooth4.0 USB Adapter
[ 213.263179] usb 3-1: Product: Edimax Wi-Fi N150 Bluetooth4.0 USB Adapter
[ 1254.571573] rtk_btusb: Realtek Bluetooth USB driver ver 3.1
[ 1484.335698] Bluetooth: hci0 command 0xfc19 tx timeout
[ 1485.018454] hid-generic 0005:046D:B020.0003: input,hidraw0: BLUETOOTH HID v1.11 Mouse [MX Vertical] on
[ 1486.342535] Bluetooth: hci0 command 0xfc19 tx timeout
[ 1654.564949] hid-generic 0005:046D:B020.0004: input,hidraw0: BLUETOOTH HID v1.11 Mouse [MX Vertical] on
[ 1662.350320] hid-generic 0005:046D:B020.0005: input,hidraw0: BLUETOOTH HID v1.11 Mouse [MX Vertical] on
[ 1662.589145] Bluetooth: hci0 command 0xfc19 tx timeout
[ 1664.595735] Bluetooth: hci0 command 0xfc19 tx timeout
[ 1666.602345] Bluetooth: hci0 command 0xfc19 tx timeout
[ 1697.949394] Bluetooth: hci0 command 0xfc19 tx timeout
[ 1698.588610] hid-generic 0005:046D:B020.0006: input,hidraw0: BLUETOOTH HID v1.11 Mouse [MX Vertical] on
[ 1699.955736] Bluetooth: hci0 command 0xfc19 tx timeout
[ 1701.962575] Bluetooth: hci0 command 0xfc19 tx timeout
[ 1751.195217] hid-generic 0005:046D:B020.0007: input,hidraw0: BLUETOOTH HID v1.11 Mouse [MX Vertical] on
[ 1770.435908] Bluetooth: hci0 command 0xfc19 tx timeout
[ 3047.682118] Bluetooth: hci0 command 0xfc19 tx timeout
[ 3048.419858] hid-generic 0005:046D:B020.0008: input,hidraw0: BLUETOOTH HID v1.11 Mouse [MX Vertical] on
[ 3049.688757] Bluetooth: hci0 command 0xfc19 tx timeout
Additional question: How do you get wifi and bt to autostart and autoconnect on boot?
-
Additional question: How do you get wifi and bt to autostart and autoconnect on boot?
At first check if modules are loaded (lsmod) after reboot.
-
rk3399_rigol:/ # lsmod
lsmod
Module Size Used by
usbtmc_dev 41918 2
libcomposite 60749 1 usbtmc_dev
usb_gpib 21937 0
focaltech_ts 213735 0
dac_gpio 3444 1
fg_m2c_gpio 2719 0
beeper_gpio 3684 0
spi2afe_gpio 5571 1
xdma 99943 2
pcie_rockchip 20793 0
afg_gpio 3109 0
spi2pll_lxm2582_gpio 3111 0
hdcode_gpio 2304 0
motorcomm 17303 0
fan_gpio_clt 1694 0
No indeed it doesn't autoload
cat /etc/modules
/system/lib/modules/8723bu.ko
/system/lib/modules/88x2bu.ko
The module is in the sys dirs though.
I'm not too familiar with android, are you supposed to put that .sh script of yours into init.rc somewhere or?
-
I'm not too familiar with android, are you supposed to put that .sh script of yours into init.rc somewhere or?
Im also not so much familiar with Android, but more likely regular GNU/Linux like they should use from the beginning.
If I were you, I would add insmod at the beginning of /rigol/shell/start_rigol_app.sh which is executed very early. One possibility is it will be loaded too late (f**king Android...).
-
Once the hardware is added, a connection to the Internet should update the RTC to the current time, so no UI changes are needed. Screenshots that include the header would show the correct time, even if disconnected from the Internet.
It sets the time via. the Internet but not the time zone, which defaults to Shanghai every time you switch it on.
I prefer to switch off the overlay on the screenshot.
-
Again "professional engineer" which he never heard of NTP used across all today operating systems.
-
It sets the time via. the Internet but not the time zone, which defaults to Shanghai every time you switch it on.
I prefer to switch off the overlay on the screenshot.
The time zone is set to Shanghai in the startup script rigol/shell/start_rigol_app.sh around line 144. You can change it to any other there.
-
Another module is done. It was one of the biggest modules provided by Rigol and I was bit too lazy to do reverse engineering, so I tried my luck with sources of another kernel - I didn't even know if it's correct driver for this touchscreen model. After fixing only one line (thx for Focaltech developers for making it easy, because of hidden backward compatibility), it works. Needs little calibration tho.
https://www.youtube.com/watch?v=54t4oUkz0eo (https://www.youtube.com/watch?v=54t4oUkz0eo)
-
Thanks, that helped, wifi seems to work, however the bluetooth is flaky, it connects to my Logitech MX Vertical mouse but then it seemingly drops the connection?
Strange, my Logitech MX Anywhere 2 works stable on all dongles, even while streaming the Web Control over Wi-Fi.
Additional question: How do you get wifi and bt to autostart and autoconnect on boot?
rk3399_rigol:/rigol/shell # busybox diff start_rigol_app-orig.sh start_rigol_app.sh
--- start_rigol_app-orig.sh
+++ start_rigol_app.sh
@@ -44,6 +44,10 @@
insmod /rigol/driver/motorcomm.ko
ifconfig eth0 up
+
+rtl8723.sh
+
+
# Get the Hardware version
insmod /rigol/driver/hdcode_gpio.ko
chmod 777 /dev/hdcode_gpio
-
Another reverse engineering. This time with AFG.
https://github.com/norbertkiszka/rigol-orangerigol-linux_4.4.179/blob/main/drivers/rigol/fg_m2c_gpio.c
Module fg_m2c_gpio creates char device file (/dev/fg_m2c_gpio) which drives GPIO pin 149 which drives "AFG_GEN" from AFG schematic diagram which somebody provided here as his/her r.e. work (I don't remember his/her nick and I don't want to look for it right now).
This can be tested/used with any DHO800 and DHO900. Both with original firmware and with OrangeRigol.
Turn on AFG:
printf '\x1' > /dev/fg_m2c_gpio
Turn off AFG:
printf '\x0' > /dev/fg_m2c_gpio
With my DHO924S when AFG is turned on by app, it can be turned off as above (app will not know ofc.) and turn back on and it will work as before.
Funny thing, users without AFG (DHO800 and models without S) can use this GPIO with bash or a some Android app to do something useful (maybe some blinking colorful led lights around the scope housing?).
-
One pretty useful thing would be to explore how to get the ch1/ch2 data read quickly (for the new Bode)..
-
One pretty useful thing would be to explore how to get the ch1/ch2 data read quickly (for the new Bode)..
Is there any new Bode?
-
Maybe Im wrong, but looks like module dac_gpio is a phantom. It doesn't do anything, beside of changing four GPIO outputs (after ioctl to the /dev/dac_gear_change), which does completely nothing. Commenting out insmod (and chmod) from start_rigol_app.sh seems doesn't change anything. Also looks like nothing is using /dev/dac_gear_change.
So commenting it out will give us astounding ~0.1 sec less of boot time and little less resources being used.
gpio-153 ( |a ) out hi
gpio-154 ( |a ) out lo
gpio-157 ( |a ) out lo
gpio-158 ( |a ) out lo
-
Another device driver was recreated. This time PLL (LXM2582).
https://github.com/norbertkiszka/rigol-orangerigol-linux_4.4.179/blob/main/drivers/rigol/spi2pll_lxm2582_gpio.c (https://github.com/norbertkiszka/rigol-orangerigol-linux_4.4.179/blob/main/drivers/rigol/spi2pll_lxm2582_gpio.c)
https://www.ti.com/lit/ds/symlink/lmx2582.pdf (https://www.ti.com/lit/ds/symlink/lmx2582.pdf)
Edit: looks like spi2pll_lxm2582_gpio.ko and spi2pll_gpio.ko has only one difference, which is the name of created device file (/dev/spi_3wires_lxm2582 and /dev/spi_3wires respectively).
-
I discovered something. Module spi2afe_gpio as the name suggest, makes possible for app to communicate with front end IC. Commenting out line with insmod ot this module makes noise about 5 times smaller. So about 80% of noise is generated by front end.
That was predictable, since DHO4000 is working with the half amount of LC filters (close to the ADC) with more or less same noise. For 99% it's coming from AFE power supply.
-
I am not sure this fits under the topic, but I wanted to give back a bit, so I made some oscilloscope probe holders, that friction fit into the vents at the top of the scope (DHO804 in pics). Very convenient to not have the probes dangle everywhere. The cables would benefit from some sort of retaining solution, but I have not thought of a good one yet.
Printed with PLA, so far no issues.
I've also monitor VESA arm mounted my scope which is super convenient (if you guys wanna do this I suggest putting spacers to allow heat to escape out the back as it blocks the air exhaust).
https://www.printables.com/model/1115105-rigol-dho800-oscilloscope-probe-holder (https://www.printables.com/model/1115105-rigol-dho800-oscilloscope-probe-holder)
-
This time I recreated another device driver, which communicates with the frontend ICs. As for now, it was the hardest one because of reverse engineering. Result is: 519 lines of code.
https://github.com/norbertkiszka/rigol-orangerigol-linux_4.4.179/blob/main/drivers/rigol/spi2afe_gpio.c
-
This time I recreated another device driver, which communicates with the frontend ICs. As for now, it was the hardest one because of reverse engineering. Result is: 519 lines of code.
https://github.com/norbertkiszka/rigol-orangerigol-linux_4.4.179/blob/main/drivers/rigol/spi2afe_gpio.c
Keep on going. I know this is hard work, and this work is sometimes being ridiculed by others, because they fail to see the purpose. But I say that any research in this direction may turn out to be useful sooner or later even if there's no apparent immediate benefit.
-
Immediate benefit will be when all modules will be ready and working correctly. More likely benefits. Another OS (Linux/GNU) instead of Android, which will make hacking easier or even running it with completely different app - made from scratch or modified existing one (if it's open source).
Also separate monitor with another measurements (or apps if needed) will be extremely useful.
In any case, reverse engineering gives some more knowledge (electronics and about Linux kernel) and some fun - especially if something works after recreating it in a way like this.
-
I just got a new 914S, and the box shows the manufacturing date of October 2024. From the prior reports, I was ready to design a 3D-printed back extension with a 100mm x 10mm thick quiet fan with a temperature-compensating speed control.
Rigol may have changed the design and the fan makes very little noise. From 18" away at the front, I can barely hear it in a very quiet room. If I put my ear to 12" from the back, I can hear the fan running, but not annoying or loud. Without opening it, the heat sink, and the fan appear like the one in the video from a year ago, but you can't see the label on the fan. Perhaps they found a fan that is better.
After warming up for 10 minutes, the CPU temp was 49.3 degrees. Using my sound level meter, C weighting, 2” from the back, the highest reading at any location is 57 dB. At 3” it drops to 53 dB. Using A weighting, it dropped the level another 2-3 dB.
My test was with the original V1.02 software, Hardware “8”. I did not retest with v1.04 but I did not notice a difference in fan noise after I installed v1.04, not that I expected any change.
Now it could there have been no design changes and the sound level varies with small manufacturing differences. It’s also possible some people are more sensitive to the sound. I like a very quiet environment and consider myself very sensitive to noise. To me it seems like a non-issue.
-
I needed a case for my new oscilloscope, but I wanted it as small as possible. Perhaps the stock Rigol case is good, but I found a camera case that works well for only $27 on Amazon. It holds the unit, all four probes, the power supply, and cables. There is still a little room for some 50-ohm feed-through terminators. It’s a Vamson Carrying Case model VP808. I may add a 5/8” layer of foam over the display, but it is not really needed.
-
Do you have a link for that case?
Batronix sells this:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2467467;image)
-
Now it could there have been no design changes and the sound level varies with small manufacturing differences. It’s also possible some people are more sensitive to the sound. I like a very quiet environment and consider myself very sensitive to noise. To me it seems like a non-issue.
Agreed. I am quite sensitive to noise as well and had spent a lot of time making my PC as quiet as possible, for example, but the 804 that I got isn't terribly noisy, even though I got it fully expecting to have to modify it.
It is clearly audible and the sound is akin to have one of those old videocards running in your vicinity, but it isn't annoyingly loud, just a reminder the scope is there and running, even sitting on my desk right next to me. So far it clearly isn't worth tearing it apart but I imagine this will eventually change as bearings in the fan wear out: something tells me they're plain sleeve and not ball bearings!
-
Batronix sells this:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2467467;image)
I always wondered how they arrived at that design. It seems to say "I wanted a motorbike, but all I could afford was this little scope!" ;)
Maybe it started with a picture of sparrow (Rigol's internal code name for the project), and then someone decided that they needed a more impressive bird?
-
Do you have a link for that case?
Here's the Amazon link for the Vamson case I bought: https://www.amazon.com/dp/B08HH7H7BL (https://www.amazon.com/dp/B08HH7H7BL)
-
Yesterday I got my hands on a precision 2 GHz signal power meter for a while and I took the opportunity to study the oscilloscope bandwidth under different models.
The method is as follows: I measured the output signal power from 10 to 600 MHz with a step of 5 MHz with high accuracy on my NanoVNA-F V2 in the generator mode. To be sure, I took the measurements twice with a pause of several hours between measurements. The difference in the results was hundredths of a percent, so I was convinced of the fairly accurate repeatability of the output signal level.
Then I connected the oscilloscope with a cable to the generator output (with a 50 Ohm termination connector at the oscilloscope input) and measured the average signal level (VRMS) at the same frequency points - from 10 to 600 MHz with a step of 5 MHz. From the obtained values, I calculated the power and knowing the true signal power, I was able to get the attenuation value in dB at each frequency point. So far I have measured only a few oscilloscope modifications. Later I want to do this for all other modifications (914, 914 with the bandwidth extension option, 924).
On the graph, the horizontal scale is MHz, the vertical scale is the attenuation of the signal by the oscilloscope in dB. Measurements below -20 dB are not very accurate due to the very weak signal and can have errors of up to 1-2 dB.
I also attach the original Excel file with all the results.
-
Interesting. Good job.
This, however, shows the frequency response of the combination of the oscilloscope AND the inline terminator, which can introduce its own distortions.
Do you have other terminators to repeat the same measurements with? It would be interesting to see if the results will be different.
-
Interesting. Good job.
This, however, shows the frequency response of the combination of the oscilloscope AND the inline terminator, which can introduce its own distortions.
Do you have other terminators to repeat the same measurements with? It would be interesting to see if the results will be different.
Thank you :)
No, I don't have any other terminators, but I measured this one on NanoVNA, it has a fairly flat frequency response up to about 800 MHz. It starts to attenuate 3 dB slightly above 1 GHz.
-
Thanks for this info.
FWIW I drew on the -3dB points and rescaled it a bit.
I previously measured 125/200/250/280 MHz for the various models using a pulse generator and rise time measurements. Your first three results are slightly lower than mine but your "824" is much higher.
Graphs are obviously more useful though, it allows us to see rolloff and pick the best hacking option... :)
My take: The graph shows only about 1dB difference between the "100MHz" and "125Mhz" options as you go higher. The "100MHz" option still seems the healthiest choice for daily driving.
The "200MHz" option is a bit wild but it's giving about 6dB extra at the outer limits. This is well worth having in the toolbox for looking at just one or two channels. It's a bit like having a "turbo" button for those situations (just remember not to leave it on when you've finished!)
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2472915;image)
-
Thanks for this info.
FWIW I drew on the -3dB points and rescaled it a bit.
I wanted to put markers at -3 dB level myself, but I couldn't do it in Excel diagrams. Either I don't know Excel well, or Excel doesn't work with diagrams well :)
The "200MHz" option is a bit wild but it's giving about 6dB extra at the outer limits. This is well worth having in the toolbox for looking at just one or two channels. It's a bit like having a "turbo" button for those situations (just remember not to leave it on when you've finished!)
Yes, I was also surprised by the result of the 824. It will be interesting to compare it with the 914+BW15T25 and with the 924, which have a bandwidth of 250 MHz. In the coming week I will spend another day messing around and make graphs for them and for the channel that I "hacked" on my oscilloscope by reducing the inductance before the ADC, it will also be interesting to compare them with the original channel in all models.
-
Thanks for this info.
FWIW I drew on the -3dB points and rescaled it a bit.
I wanted to put markers at -3 dB level myself, but I couldn't do it in Excel diagrams. Either I don't know Excel well, or Excel doesn't work with diagrams well :)
I used Windows paint. :)
It will be interesting to compare it with the 914+BW15T25 and with the 924, which have a bandwidth of 250 MHz.
It should be exactly the same.
(You could also "downgrade" A DHO900 to a DHO804 and see what happens...)
-
I used Windows paint. :)
I somehow didn't think of such a simple option :))) Probably, my brain just wasn't working anymore, I was tired :)
It should be exactly the same.
(You could also "downgrade" A DHO900 to a DHO804 and see what happens...)
914+BW15T25 and 924 - yes, they should be absolutely identical, but it's interesting to see their BW compared to 825 :)
-
By the way, if anyone is interested, this is what the graph of the NanoVNA-F V2 output power looks like in milliwatts versus frequency.
-
914+BW15T25 and 924 - yes, they should be absolutely identical, but it's interesting to see their BW compared to 825 :)
It needs confirming, obviously, but there should be no difference between a DHO800 and a DHO900 with the same vendor.bin file.
-
It needs confirming, obviously, but there should be no difference between a DHO800 and a DHO900 with the same vendor.bin file.
No, of course I mean a software change of the oscilloscope model :)
There will be no difference between the 800 converted into 900 and the real 900, I am also absolutely sure of this.
-
Be careful with nanovna as a sig gen (especially the cheaper older models) - it outputs square wave (the amplitude is settable in 4 or 5 levels afaik) and the frequency is limited to some 300MHz (with an o'clocked generator chip), all freqs above are the harmonics only. This may not apply to the latest models and the older F V2..
-
Be careful with nanovna as a sig gen (especially the cheaper older models) - it outputs square wave (the amplitude is settable in 4 or 5 levels afaik) and the frequency is limited to some 300MHz (with an o'clocked generator chip), all freqs above are the harmonics only. This may not apply to the latest models and the older F V2..
Yes, that's true, but in theory, the RMS measurement doesn't care what shape the signal is.
-
I measured the bandwidth of the remaining models and options. Now the table and graph contain all the models and possible options that expand the bandwidth.
The surprise was that the 824 bandwidth is absolutely identical to the 924 bandwidth. That is, by declaring the 824 bandwidth at 200 MHz, Rigol actually gives an open bandwidth of 250 MHz (and in practice even a little more than 300 MHz) :)
As last time, I am attaching an archive with an Excel file, in which all the original measurement results are saved.
-
We need a mode between DHO814 and DHO824/924...
-
We need a mode between DHO814 and DHO824/924...
8(1.5)4 :))))
-
Hello everyone, could you please help me with a question? I updated my DHO814 from version 00.01.02.00.02 to version 00.01.04.00.02. Is it possible to revert to 00.01.02.00.02, and how can I do that? Thanks.
-
Hello everyone, could you please help me with a question? I updated my DHO814 from version 00.01.02.00.02 to version 00.01.04.00.02. Is it possible to revert to 00.01.02.00.02, and how can I do that? Thanks.
Yes. Just copy 1.02 .GEL file onto a USB stick and install it.
-
so it doesnt have a forward-only policy like the 1000z does?
interesting.
-
On my DHO924S kernels 5.x and 6.x had small problems with graphic drivers - it didn't work, no matter what I did - including testing 100 kernel forks from GitHub that was made to work on a RK3399. Once I did workaround (just commented out one 'if' that generates error) in a mipi-dsi driver (internal LCD is connected via mipi) and result of it was... HDMI started to work, instead of mipi :palm: :wtf:
So... without almost any knowledge about DRM Linux subsystem (bridge between kernel, graphic drivers and user space) or graphic drivers, I decided to do something really crazy - to make a port of mipi driver from Linux kernel 4.4 into 5.10. 4.4 and 5.10 internally are almost two different kernels - half things are different or deleted (from a regular user perspective it's almost the same - 5.x is much faster and safer). With many DRM api functions, I needed to read tons of documentation, articles and compare code from both kernels. Only mipi driver in 4.4 has 2195 lines of code.
With that crazy and almost impossible thing to do and after about two weeks of fight, I did it :scared: Both mipi-dsi and HDMI works.
However, it crashes when CONFIG_ROCKCHIP_DRM_DEBUG is enabled (null pointer in a VOP driver) and it needs to cleanup huge mess in my code. After fixing those issues, I will put it on my GitHub.
Belive or not, practically I did a Rockchip job without documentation of anything in RK3399 - only pure code with almost no comments in it (code made by Rockchip).
Im not 100% sure, but there is no huge changes in Linux 6.x DRM subsystem (between 5.x and 6.x), so probably it should work on it too. Funny thing, theoretically now it's possible to do a split screen - but that code is probably only for a Android.
so it doesnt have a forward-only policy like the 1000z does?
interesting.
Rigol firmware updates are just zip files without any encryption. Once I did manual update of half of their firmware, from 1.02 to 1.03 - FPGA, kernel modules and scripts - everything without app. It was working fine.
-
Hi, I received a Rigol DHO804 for Christmas and wanted to "upgrade" it a little ;D
I Installed the 1.04 FW and then tried to hack it using the https://github.com/zelea2/rigol_vendor_bin (https://github.com/zelea2/rigol_vendor_bin) tool.
I tried to cretae the vendor.bin to change the 804 to the 824 (I want more bandwith, but not the 924 logic probe panel).
I could create the vendor.bin and push it onto the DHO804, but after reboot I do not get any signals on the channels anymore...
I also tried to create a vendor.bin for the DHO924 (as seen here https://www.youtube.com/watch?v=oBfuWxMFSsI (https://www.youtube.com/watch?v=oBfuWxMFSsI)), but the result is the same.
Is it not working with the 1.04 FW? Or am I doning something fundamentally wrong?
-
Check permisionss of file vendor.bin
ls -l /rigol/data/vendor.bin
-
Is it not working with the 1.04 FW? Or am I doning something fundamentally wrong?
You are doing something wrong. With firmware 00.01.04.00.02 replacing vendor.bin works fine.
P.S.: @zelea2 updated his utility for 824, great :)
-
Did you do a self-cal?
What model do you see on the "About" screen?
-
By the way, an interesting point: I completely deleted the vendor.bin file from the oscilloscope and rebooted it. It booted up as 814, which is what it was originally when I bought it.
-
I received this week the dho804, with firmware 00.01.02.00.02, I did the hack using the method of adding extra capabilities, (not changing the model) and then I updated to version V00.01.04.00.02, it seems that the activations are maintained, thank you very much
-
I believe the issue with the no trace is due to perhaps a one-time migration process of the calibration data when upgrading the firmware. If you upgrade the model, it's looking for a specific calibration but can't find it, hence the blank trace. But really I am not sure.
When I had the issue, this is what I recall doing: copy over the DHO804 vendor.bin file and restart, you should now have a trace, run self-cal, restart, copy the DHO824 vendor.bin and restart, verify trace, self-cal again and restart, should be good to go.
-
Yes, some new versions affect the calibration process and, accordingly, the way calibration data is stored. Version 00.01.04.00.02 is just such a thing, after the update, re-calibration is mandatory.
-
Many thanks, that did the trick.
I reloaded the original vendor.bin and did the self-calib.
The I uploaded the DHO824 vendor.bin and also changed the permissions of the file (adb shell chmod 777 /rigol/data/vendor.bin), just to be on the save side.
Now it's working like a charm :)
-
just another simple usb fan mod...love noctua fans
-
just another simple usb fan mod...love noctua fans
that color mismatch though... :)
but seriously, you DO want to add a protective grill there. whenever you think that you don't, you can be sure that it's a mistake.
-
I needed a case for my new oscilloscope, but I wanted it as small as possible. Perhaps the stock Rigol case is good, but I found a camera case that works well for only $27 on Amazon. It holds the unit, all four probes, the power supply, and cables. There is still a little room for some 50-ohm feed-through terminators. It’s a Vamson Carrying Case model VP808. I may add a 5/8” layer of foam over the display, but it is not really needed.
Thanks for that. This should pair well with Jakob Holz's 3D printed snap on cover for the DHO800/900 series.
I printed one out of Matte Black PLA on my X1C and it came out great. You need to print it at a 45 degree angle on the narrow edge using tree supports as the X1C build size limit is 250mm. I am also exploring a case that I could bolt or pop rivet to the cover that would contain the probes and power supply but your solution may end up being a better one.
Here is a link for files for the cover. I wish my printer would allow making one for my larger DHO1204.
https://grabcad.com/library/rigol-dho-800-900-front-cover-1
-
FYI - my DHO-804 I've got today shows the fw v 1.03..
-
FYI - my DHO-804 I've got today shows the fw v 1.03..
I'd upgrade it, ASAP.
-
..upgraded to 1.04.00.02, now doing the selfcal..
-
Don't forget to calibrate all probes. All channels should be practically identical (unless factory screw up another scope), so You can do it using same channel.
-
..upgraded to 1.04.00.02, now doing the selfcal..
The calibration took 36minutes, while the last 1% took aprox 10minutes..
So something similar to the windoze install :) :)
-
I don't remember exact time, but in my case it was more like 10-15 minutes. However my model is DHO924S.
I'm not using Windows for almost two decades, but I remember Win 2K on PII 266 MHz (SDR, not DDR rubbish) when last 10% took couple hours.
-
Don't forget to calibrate all probes.
What do you mean by this? I don't remember anything related to calibrating probes in this scope. It runs calibration with all channels left open (nothing connected).
-
Don't forget to calibrate all probes.
What do you mean by this? I don't remember anything related to calibrating probes in this scope. It runs calibration with all channels left open (nothing connected).
I mean manual probes calibration (or adjust if You prefer), not scope self-calibration which is something completely different.
https://www.youtube.com/watch?v=7hAIJxRgRxw (https://www.youtube.com/watch?v=7hAIJxRgRxw)
Or if You want to be very precise for some reason (not necessary that slow and imprecise DHO800 rubbish): https://cdn.teledynelecroy.com/files/tutorials/ten_minute_tutorial_probe_calibration.pdf (https://cdn.teledynelecroy.com/files/tutorials/ten_minute_tutorial_probe_calibration.pdf)
-
Ah, that. I thought of something like maybe frequency response calibration or things like that :)
-
Don't forget to calibrate all probes.
What do you mean by this? I don't remember anything related to calibrating probes in this scope. It runs calibration with all channels left open (nothing connected).
"Compensate" the probes. Connect the probe to the compensation signal on the front (1kHz square wave) and adjust the little screw on the probe connector until the top/bottom is flat.
-
All channels should be practically identical (unless factory screw up another scope), so You can do it using same channel.
Nope. You're supposed to match each probe to its channel. That's why they put little colored rings for the probes in the bags.
(There's probably not much in it, but that's what you're supposed to do)
-
Nope. You're supposed to match each probe to its channel. That's why they put little colored rings for the probes in the bags.
Sometimes I cant understand If You trolling again or something else.
Colored rings are because You can use all four probes at the same time and it's easy to make a mistake with swapping channels - that will create bad conclusions.
There's probably not much in it
Looks like a user of a magic glass ball. All four AFD are equal. Only one possible cause of difference is flux residues after cleaning - personally I had very small amounts, but still with it, I have exact same response on all four channels.
-
Nope. You're supposed to match each probe to its channel. That's why they put little colored rings for the probes in the bags.
Sometimes I cant understand If You trolling again or something else.
Colored rings are because You can use all four probes at the same time and it's easy to make a mistake with swapping channels - that will create bad conclusions.
They ensure the same probe is used on the same channel it has been compensated on.
This is basic probe use and ensures measurement repeatability.
-
FYI - my DHO-804 I've got today shows the fw v 1.03..
I'd upgrade it, ASAP.
I recently got (with the discount) the DHO804, it arrived yesterday, with the FW version 1.03
. So, I don't think I'll upgrade and I don't think I'll "upgrade" to DHO824 (or 924).
This decision of mine was born from these considerations:
I already have an original DHO924s and I was able to compare the operation of the two oscilloscopes. In use, the DHO804 heats up much less than the 924S (I think due to the absence of the frequency generator and because it has a 70 MHz bandwidth). These two characteristics (being colder, and having a lower bandwidth) mean that it has less noisy inputs (which is highlighted by the Averange Vpp measurement) and the trace also appears cleaner than the 924S (for ranges of 1 mV and lower) .
To make the behavior of the two oscilloscopes almost uniform I must select the bandwidth limit at 20 MHz. Even if the trace of the 804 is still a little preferable (after all, the 924S is much warmer than the first).
-
furthermore I won't go from 1.03 to 1.04 because I also believe that one of the reasons for the cleaner track depends on the factory calibration, which I would lose if I upgraded the FW
-
furthermore I won't go from 1.03 to 1.04 because I also believe that one of the reasons for the cleaner track depends on the factory calibration, which I would lose if I upgraded the FW
Calibration has no effect on noise levels.
There's really no such thing as "factory calibration". All they do at the factory is press the "self cal" button which you can do too.
You can use 1.03 if you want but be very careful with XY mode because it can make your 'scope unbootable if you power-off in that mode.
-
What we should see as the noise background?
When I terminate ch4, for example, with 50ohm terminator and I look at the noise I see 340uVpp BW OFF, and 225uVpp BW 20MHz, DC at 500kSa/s and 1Mpts (after upgrade to 1.04).
-
What we should see as the noise background?
When I terminate ch4, for example, with 50ohm terminator and I look at the noise I see 340uVpp BW OFF, and 225uVpp BW 20MHz, DC at 500kSa/s and 1Mpts (after upgrade to 1.04).
Peak-to-peak is not a very meaningful or comparable metric for Gaussian-like noise because the probability distribution is unbounded. Instead, measure the standard deviation (some scopes call it AC RMS).
-
What we should see as the noise background?
When I terminate ch4, for example, with 50ohm terminator and I look at the noise I see 340uVpp BW OFF, and 225uVpp BW 20MHz, DC at 500kSa/s and 1Mpts (after upgrade to 1.04).
Peak-to-peak is not a very meaningful or comparable metric for Gaussian-like noise because the probability distribution is unbounded. Instead, measure the standard deviation (some scopes call it AC RMS).
BW 20MHz Avg. 39uV AC RMS, drops down to 33uV after some time (due to Avg math?)
BW OFF Avg. 60uV AC RMS, drops down to 50uV after some time (due to Avg math?)
-
furthermore I won't go from 1.03 to 1.04 because I also believe that one of the reasons for the cleaner track depends on the factory calibration, which I would lose if I upgraded the FW
Calibration has no effect on noise levels.
There's really no such thing as "factory calibration". All they do at the factory is press the "self cal" button which you can do too.
You can use 1.03 if you want but be very careful with XY mode because it can make your 'scope unbootable if you power-off in that mode.
I stick to the facts. I have two oscilloscopes, one from about a year ago (dho924s) and one from a few days ago (DHO804). The DHO804 has better tracking than the DHO924S. Furthermore, the DHO804 is much less hot (almost cold). Since my considerations, in your opinion, are not valid, tell me your considerations
Ps: if the dho804 1.03 no longer works, the Germans who sold it to me would replace it immediately
-
What we should see as the noise background?
When I terminate ch4, for example, with 50ohm terminator and I look at the noise I see 340uVpp BW OFF, and 225uVpp BW 20MHz, DC at 500kSa/s and 1Mpts (after upgrade to 1.04).
this shows that by limiting the passband the noise is reduced, so the opposite is also true, with the same front-end the wider the passband the greater the noise.
The dho 804, which has less bandwidth than the 924, is less noisy. So if you are looking for a very quiet oscilloscope, I think you won't make any bandwidth upgrades.
Then there would be the matter of cleaning the track shown on the video... on this point I await Fungus' response.... and in any case, until I am convinced of the step to take, I have no intention of ruining my DHO 804 virgin
-
..I have no intention of ruining my DHO 804 virgin
That is ok, indeed. Could you look at your both scopes and tell us what the noise background noise you see? Best when you put the termination on the channel's BNC such it does not pick up a noise from the outside.
That would be an interesting comparison. And we do prefer the numbers here..
-
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.
If You take a look at bootom side of heatsink, it becomes clear, that they designed it at first with another FPGA, but changed their mind for a cheaper one, changed placement of FPGA and modifed heatsink without removing old staff for old FPGA. At least mine DHO924S has it.
-
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... ;)
Maybe Im not RAM memory specialist, but I guess we can't use theoretical bandwidth in memory. 1.25GSa/s and 12 bit data gives 2.5 GB/s which is a lot. CL latency in DDR3 is around 10-15 ns. So changing address can take that long (not everytime). So they used more chips.
So why not smaller ones? Answer for that is most likely the same as for AFD chip capable of more than 1 GHz in 250 MHz scope - because it's better to reuse same parts across many models, instead of storing huge amount of parts and to lose money because of it. Also in machines You need to put those parts and take more time to take care, not speaking of human errors, how costly they can be.
1 GB of DDR3 is very cheap, so it's not worth of redesigning hardware and software (or FPGA firmware) with huge risk of getting into a big f*cking wall after couple months, because somebody wanted 10$ more income per month.
-
What we should see as the noise background?
When I terminate ch4, for example, with 50ohm terminator and I look at the noise I see 340uVpp BW OFF, and 225uVpp BW 20MHz, DC at 500kSa/s and 1Mpts (after upgrade to 1.04).
Peak-to-peak is not a very meaningful or comparable metric for Gaussian-like noise because the probability distribution is unbounded. Instead, measure the standard deviation (some scopes call it AC RMS).
BW 20MHz Avg. 39uV AC RMS, drops down to 33uV after some time (due to Avg math?)
BW OFF Avg. 60uV AC RMS, drops down to 50uV after some time (due to Avg math?)
Noise caught internally when You switch configuration most likely - just look how PCB looks and You will know. Other reason can be software bug, but I doubt it.
-
Nope. You're supposed to match each probe to its channel. That's why they put little colored rings for the probes in the bags.
Sometimes I cant understand If You trolling again or something else.
Colored rings are because You can use all four probes at the same time and it's easy to make a mistake with swapping channels - that will create bad conclusions.
They ensure the same probe is used on the same channel it has been compensated on.
This is basic probe use and ensures measurement repeatability.
Noise between channels in my scope has much more differences than impedance on inputs. If You wan't to measure very fast signals from something very precise, then DHO800 and DHO900 series at very best can be used as a paper-weight to hold 100x more expensive probes (and other scope) than this scope.
-
Going back to the noise. Some people likes to omit posts with my reverse engineering and little later they made huge amount of comments with guessing something which is directly related. So I will repeat myself second and last time (next time go ahead and don't read my effort with rev. eng.).
About 90% (I don't remember exact numbers now) of noise is generated by the AFD. Knowing differences between DHO800/900 and DHO4000 it's almost sure that most noise is coming from switching DC-DC converter.
If somebody needs much less noise, cut traces from DC-DC converter going to all AFD, force this converter to make 1-2 V more and place some low-noise LDO regulator in separate and small PCB connected with wires. How complicated that is?
Also, if You have Lite-ON PSU, good luck with internal ground-PE path. Especially with HV probes.
-
Also, if You have Lite-ON PSU, good luck with internal ground-PE path. Especially with HV probes.
What do you mean by this?
-
Also, if You have Lite-ON PSU, good luck with internal ground-PE path. Especially with HV probes.
What do you mean by this?
My another reverse engineering which I did on this forum (for 99.99% in this thread or in teardown thread).
Even best electronics engineering, playing with 200 GHz often completely doesn't know or don't want to know about very basic things related to ELV systems they use. In this case (pseudo) SELV with connected PE in a very poor method - completely unacceptable for any oscilloscope or any other test equipment - even including cheapest ones. It's just one stupid resistor and one capacitor just waiting to be cause of damage of something expensive, like a oscilloscope or measured device or both at the same time.
Anyway, not my scopes, not my problem - too many people called me as being too wise or not so much experienced (so why I play with electronics from being 6-years old?). Good luck with gaining experience with broken scope, broken something else or both - I know from experience, later nobody will apologize that I was right.
-
Going back to the noise. Some people likes to omit posts with my reverse engineering and little later they made huge amount of comments with guessing something which is directly related. So I will repeat myself second and last time (next time go ahead and don't read my effort with rev. eng.).
About 90% (I don't remember exact numbers now) of noise is generated by the AFD. Knowing differences between DHO800/900 and DHO4000 it's almost sure that most noise is coming from switching DC-DC converter.
I forgot to remind what exact reverse engineering - it was related to the module simulating SPI communication with AFD in all four channels. App was made by very lazy people, so it will work no matter what - no errors messages, just execute code. So unloading or better commenting out insmod of this module (as I said previously in this thread if somebody of course didn't want to read my effort) will turn off AFD IC completly and You will see noise from ADC only (and very little bit from its inputs connected practically to traces and LC filters).
If somebody is a genius with a Windows (I cant understand this in last decade, why to use this crap?) and completely zero knowledge about Linux systems, I will explain: modules are modules - like a key in a lock - You can put out key from a lock and put back in. Same with modules - scope will not burn because this test which is temporary. Or like a removing .dll file from a game and put it back in - it works again, right?
-
Nope. You're supposed to match each probe to its channel. That's why they put little colored rings for the probes in the bags.
Sometimes I cant understand If You trolling again or something else.
Colored rings are because You can use all four probes at the same time and it's easy to make a mistake with swapping channels - that will create bad conclusions.
They ensure the same probe is used on the same channel it has been compensated on.
This is basic probe use and ensures measurement repeatability.
Noise between channels in my scope has much more differences than impedance on inputs. If You wan't to measure very fast signals from something very precise, then DHO800 and DHO900 series at very best can be used as a paper-weight to hold 100x more expensive probes (and other scope) than this scope.
Is a function of the BW rating and its corresponding risetime.
Even my 2 GHz DSO won't get anywhere near the 30ps risetime of a Leo Bodnar 10 MHz pulser.
-
Instead of theoretize why not put the 50ohm terminator on the BNC input and look at the Avg AC RMS values while in the 500uV/div? It is much faster than write essays which do not move us forward, imho..
Dropping Avg AC RMS in time - looks to me it averages over the entire memory (1Mpts in above example) so it takes some time. After some time it fluctuates around a value.
-
Instead of theoretize why not put the 50ohm terminator on the BNC input and look at the Avg AC RMS values while in the 500uV/div?
the test must be done without termination of the 50 ohm!
-
Also, if You have Lite-ON PSU, good luck with internal ground-PE path. Especially with HV probes.
the DHO800 /900 system includes a USB-c type power supply. This is a standard (USB-C) which originally does not provide for the chassis to be earthed.
But all power supplies with switching transformers can have the negative connected to ground.
Since it is an oscilloscope it is necessary to bind its inputs to a ground potential.
I don't see the problem. The liteon is already a good power supply.
But if you want, it's possible,
to reduce
EMI, pass the output conductor through a ferrite ring (or cylinder), while for the mains input it is possible to use a complete EMI filter.
I feel good. But I don't need to measure the charge of the neutrino
-
Also, if You have Lite-ON PSU, good luck with internal ground-PE path. Especially with HV probes.
What do you mean by this?
My another reverse engineering which I did on this forum (for 99.99% in this thread or in teardown thread).
Even best electronics engineering, playing with 200 GHz often completely doesn't know or don't want to know about very basic things related to ELV systems they use. In this case (pseudo) SELV with connected PE in a very poor method - completely unacceptable for any oscilloscope or any other test equipment - even including cheapest ones. It's just one stupid resistor and one capacitor just waiting to be cause of damage of something expensive, like a oscilloscope or measured device or both at the same time.
Anyway, not my scopes, not my problem - too many people called me as being too wise or not so much experienced (so why I play with electronics from being 6-years old?). Good luck with gaining experience with broken scope, broken something else or both - I know from experience, later nobody will apologize that I was right.
Sorry I can't make anything of it.
All I know is that there's a 1 meg resistance path between the scope ground and PE when using the supplied Liteon PSU. If one isn't satisified with this, then the scope has a dedicated jack and there's a cable included to connect its chassis to PE directly.
I don't see any problem there.
-
The liteon is already a good power supply.
And You can tell me if this PSU is SELV, PELV or FELV? Because this PSU is not SELV, beside of what they printed on a housing. Did You try to measure Riso? If You dissasemble, You will know that can fail with 50 V between PE and output ground. Proper SELV should survive 4 kV pulse. Mine failed test at 500 V. It was surprise for me that it somehow survived test with 250 V.
Look at my photos and schematic from reverse engineering in mentioned post, because I will not repost it here again and again.
I don't know how it's outside EU and even outside Poland, but in Poland, PSU's with such fault are considered as very unsafe and can't be put to sell, even if You want to sell one only.
To make it compliant with regulations and safe, You need to take out that cheap SMD components and put Y1 rated capacitor, like this one: https://eu.mouser.com/datasheet/2/447/KEM_C1104_KJN-3316338.pdf
Also You can add some resistor (1 M or bigger) in parallel, but it must survive at least 2 kV.
-
I don't see any problem there.
Sounds like a bad joke. This doesn't have "one" resistor. I put photos earlier, so go check it out.
Also I should report this PSU to my local regulator, and after they reach only one for test and it will fail (it will fail for 100%) it will be forever officially marked as unsafe and forbidden to sale in EU. If it's not already.
But If You don't want to think to spending time to even think about this problem - this is not my problem.
-
Liteon power supply has long been supplying premium models of laptops and portable PCs.
So it would be unsuitable because it doesn't have a single resistor?
Evidently it has other protection: otherwise HP, Lenovo, and others would all be incapable of understanding this enormous flaw?
-
Mine is "Delta"..
-
supplying premium models?
You think that changes anything? Do You have Riso meter to prove me wrong? I already made a post with photos and reverse engineering of this crap. Wishful thinking and cognitive bias are very bad things for any engineer.
There are many companies that decades ago was making very good or premium devices, but now they are making crap, not any better than chinese companies. Like Sony, Philips, Boeing or mentioned LiteOn and Lenovo.
If You think it's just a resistor and You don't care about safety of electrical shock or damaging scope, because of this problem, it's not my problem, but Yours.
Mine is "Delta"..
I never had problems with Delta PSU-s. Always very reliable. Some of their designes was lillte strage (or maybe original), but still same good.
-
I'm sorry but I can't understand you. You keep saying there is an electrocution hazard using this switching power supply.
I softly remember that over twenty years ago the best oscilloscopes (like my HP 54600) had abandoned 50Hz power supplies and switched to switching power supplies. In all swictihng power supplies, galvanic isolation is guaranteed (there is a transformer with primary isolated from the secondary and in addition there is a grounded galvanic shield).
The Liteon also has a ground connection on the input. By doing your reverse engineering, were you able to see how far the ground connection goes?
How do you think that in the HP 54600 the ground contact reaches the BNC and not also the negative of the power supply?
Rigol did a great job.... instead... tell us about the ultracquire acquisition and its fantastic possibilities. Do your vaunted oscilloscopes (which they will certainly be in many respects) have this fantastic option?
-
I'm sorry but I can't understand you. You keep saying there is an electrocution hazard using this switching power supply.
I softly remember that over twenty years ago the best oscilloscopes (like my HP 54600) had abandoned 50Hz power supplies and switched to switching power supplies. In all swictihng power supplies, galvanic isolation is guaranteed (there is a transformer with primary isolated from the secondary and in addition there is a grounded galvanic shield).
The Liteon also has a ground connection on the input. By doing your reverse engineering, were you able to see how far the ground connection goes?
How do you think that in the HP 54600 the ground contact reaches the BNC and not also the negative of the power supply?
Rigol did a great job.... instead... tell us about the ultracquire acquisition and its fantastic possibilities. Do your vaunted oscilloscopes (which they will certainly be in many respects) have this fantastic option?
Sorry, but looks like You completely don't know what You are talking about. I was speaking about one particular model of PSU. And I was't talking about whole world or oscilloscopes. Eventually You tried to change topic, because You cannot prove anything.
I know regulations related to devices powered from grid. I have legal license valid everywhere in EU to write paper that describes if some device, electrical installation and electrical grid is safe or not - such paper with my signature and licence number can be used in courts. Also I have test equipment to test such things. That is my special power, What is Yours, beside of knowledge about laptops and behaving as a kid, which cries because somebody told that his toy is bad and unsafe?
PS. It's very easy to lie to Yourself by not seeing my post where I tested it and I did reverse engineering with photos. I think, psychological problems (like cognitive biases) shouldn't have place on engineering forums. It's not what You personally imagine that is, but what is in reality.
-
I already made a post with photos and reverse engineering of this crap.
Where was it, can we have a link please?
This is interesting.
-
I think, psychological problems (like cognitive biases) shouldn't have place on engineering forums. It's not what You personally imagine that is, but what is in reality.
I simply need a link.
You, on the other hand, need to calm down,
and the MODERATOR's official warning
-
I already made a post with photos and reverse engineering of this crap.
Where was it, can we have a link please?
This is interesting.
2 minutes to find... https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5590693/#msg5590693 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5590693/#msg5590693)
Fifth photo tells everything. Also explains why Rigol changed PSU from Lite-On to Delta - they likely know that can cause damage of scope and user at the same time.
Also I did mistake - it didn't fail at 500 V (which is a very very big surprise for that small SMD components), but at 1 kV. Personally I often use at least 5 THT resistors in series to be able to handle at least 2 kV, even if they are one centimeter from VR and connected in parallel.
-
on my 230 volt network I have in cascade, two 20,000 volt spark gaps, two 5000 volt spark gaps, and a complete series of Bticino arresters.
On the roof I have a Faraday cage with a metal strip with 4 ground stakes.
Do your oscilloscopes have these protections?
-
I'm talking about safety.... do you think that only recent equipment that complies with safety standards should be placed on the bench?
I light everything from 1920 to today, so I solve the problem at its root
-
I think I understand the problem Norbert is addressing and will try to summarize it:
The power supply in question is a protection class I device, but the negative pole at the output is not connected to the protective conductor as one would assume (and as would be better for an oscilloscope), but is connected to the protective conductor via an RC network. As a rule, this RC network only serves the purpose of getting the DC output voltage to earth potential. (Otherwise, capacitive coupling would result in approximately half the mains voltage being applied to the DC output and therefore to the BNC sockets).
A capacitor in this RC network failed during an insulation measurement at Norbert with 500V (between the protective conductor and the DC negative pole).
In practice, this results in the following safety risk for the user: If you accidentally apply a voltage to earth, e.g. the mains voltage, to the ground terminal of the probe tip, the entire voltage is applied to the RC network within the power supply. The capacitor is apparently not sufficiently voltage-resistant and will burst. Furthermore, the impedance of the RC network is so high that the upstream fuse does not switch off immediately. This means that energy can continue to flow into the RC network. A fire is very likely.
I am an electrical engineer in Germany and I had tested electrical devices for a while as part of my job. This is why I drew my conclusion from the data that Norbert provided in another thread (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5590693/#msg5590693).
When working with my DHO804, I noticed that the resistance between the ground of the BNC socket and the protective conductor is over 4 ohms. This is why I hard grounded my device via the 4mm socket on the back.
-
These 'scopes have an earth connector on the back and a big green+yellow cable in the box.
Feel free to use them if you're probing something dangerous.
-
Not only fire hazard but also electric shock hazard.
I forgot the obvious ::)
These 'scopes have an earth connector on the back and a big green+yellow cable in the box.
Feel free to use them if you're probing something dangerous.
I was actually using the included power supply in the belief it would ground the scope via the 3-pin Schuko plug. Cause why else would they include a power supply with a Schuko plug, when most USB chargers have 2-pin Euro plugs.
Of course, the instructions shift the responsibility onto the user:
[attachimg=1]
-
I've tried to clean this up somewhat, but really, just stop it.
-
I was actually using the included power supply in the belief it would ground the scope via the 3-pin Schuko plug. Cause why else would they include a power supply with a Schuko plug, when most USB chargers have 2-pin Euro plugs.
I'm not sure how good a ground connection they can make with a USB-C connector.
It's better than nothing I guess but would you trust your life to it?
-
I was actually using the included power supply in the belief it would ground the scope via the 3-pin Schuko plug. Cause why else would they include a power supply with a Schuko plug, when most USB chargers have 2-pin Euro plugs.
I'm not sure how good a ground connection they can make with a USB-C connector.
It's better than nothing I guess but would you trust your life to it?
Did You read all last discussion or just random one post? https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5590693/#msg5590693 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5590693/#msg5590693)
This scope by default is not connected to the PE from grid.
-
Did You read all last discussion or just random one post?
All I said was that maybe USB isn't the best way to ground a 'scope for safety purposes.
(or that's what I meant to say)
I also said this a couple of posts above that:
These 'scopes have an earth connector on the back and a big green+yellow cable in the box...
-
I'm not sure how good a ground connection they can make with a USB-C connector.
It's better than nothing I guess but would you trust your life to it?
Yes, that's definitely a valid point to consider. And the traces on the PCB might even be to narrow to hold any large short-circuit current.
On the other hand, the same applies to the ethernet jack. My scope's 4Ω resistance from BNC barrel to protection ground was only coming from the shielded cable of the ethernet connection. The next ethernet switch was a 5-port desktop device without any grounding, so the 4Ω were made from a complex path of multiple connections and protection class I devices somewhere.
I was actually using the included power supply in the belief it would ground the scope via the 3-pin Schuko plug. Cause why else would they include a power supply with a Schuko plug, when most USB chargers have 2-pin Euro plugs.
I'm not sure how good a ground connection they can make with a USB-C connector.
It's better than nothing I guess but would you trust your life to it?
Did You read all last discussion or just random one post? https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5590693/#msg5590693 (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5590693/#msg5590693)
This scope by default is not connected to the PE from grid.
Norbert, please try to calm down a little bit. :) Fungus was referring to my assumption that the scope would be grounded through the power supply. Nothing wrong with his statement that the USB-C is probably not designed for currents >1kA as they can occur with shorting mains.
-
Yes, that's definitely a valid point to consider. And the traces on the PCB might even be to narrow to hold any large short-circuit current.
I've seen people say they melted the ground clip lead on their probes by connecting it to something naughty.
(but that's useful information/feedback when you're working with dangerous things...)
-
(but that's the sort of information/feedback I'd want...)
So You want less technical explanation? Sure...
PSU made by Liteon and supplied with some of DHO800 and DHO900 series (probably not anymore) is highly unsafe and it wasn't made according to safety regulations. Throw it away and buy Delta or Mean Well instead. Doesn't matter if You chose SELV (separated from PE) or PELV (output negative rail shorted with PE from grid).
https://en.wikipedia.org/wiki/Extra-low_voltage
-
I finally made my way through the Android jungle with its heaps of classes, methods, properties, interfaces, callbacks, etc. And with how it all works in Java assembler (.smal). It took me quite a while, but I finally implemented opening the main window to full screen and collapsing it to standard size by clicking on the icon in the upper left corner of the window :) Well, I repeated from the modification of the previous version the reduction of the measurement sways and the display of the specified probe divider.
-
I've seen people say they melted the ground clip lead on their probes by connecting it to something naughty.
With due diligence, you can burn not only the ground clamp, but also the hook on the central contact :))
-
Hello to everyone, I just read anything about this MAD Scope on this forum, my head is smoking... but the job of everyone of you is incredible.
Many compliments to everyone :clap: :clap:
P.S. I'm waiting for my new one 804
-
Dot mode, exploration and proof of concept
https://www.youtube.com/watch?v=ARIZRKmnTb0 (https://www.youtube.com/watch?v=ARIZRKmnTb0)
-
What means word pseudo in here? Those dots are real samples or You just "dotted" it?
-
Dot mode, exploration and proof of concept
Aim of Dots Mode (as we know it from Siglent scopes) is the emulation of Random Interleaved Sampling (https://cdn.teledynelecroy.com/files/whitepapers/wp_ris_102203.pdf). The prerequisite for this is that the trigger engine determines the trigger point with a higher horizontal resolution than one sample interval of the acquisition sample rate, in order that the waveform of a periodic signal can build up succesively by accumulating sparse points of many traces (each trace with an individual high-resolution horizontal offset) on the persistent display. As with ETS, this allows the Nyquist limit to be overcome for periodic signals. This is of particular interest at low sample rates where there is practically no anti-aliasing filtering.
Does your implementation do that? Does this scope actually provide a high-resolution trigger point position (or horizontal offset) for each acquisition? If not, then I don't see how this kind of Dots Mode can be implemented.
-
What means word pseudo in here? Those dots are real samples or You just "dotted" it?
From Rigol manuals:
* Vectors: the sample points are connected by lines and displayed. Normally, this mode can provide the most vivid waveform to view the steep edge of the waveform (such as square waveform).
* Dots: display the sample points directly. You can directly view each sample point and use the cursor to measure the X and Y values of the sample point.
I use the the screen samples memory to get the points, but they seems to be lightly different to the vectors that the DHO shows in the screen. So, maybe the system does some processing before of drawing trace in the screen.
I'm trying to understand some differences, here are some examples. (Captures directly from the device screen)
-
..I use the the screen samples memory to get the points, but they seems to be lightly different to the vectors that the DHO shows in the screen. So, maybe the system does some processing before of draw the trace in the screen..
They usually do the sinc interpolation, afaik..
-
Can You try single shot with lowest time base and full sample rate 1.25GS/s? Im curious how it will look - if it still will be with interpolation or not.
-
Can You try single shot with lowest time base and full sample rate 1.25GS/s? Im curious how it will look - if it still will be with interpolation or not.
[attachimg=1]
-
I mean lowest time base, not highest.
-
So, I have prepared a short instruction on disabling signature verification by the system and installing modified web control and oscilloscope applications.
Disabling signature verification is necessary so that the system considers the installed applications trusted (supposedly they are signed with a system key) and gives these applications access to all services. Without this, the modified oscilloscope application will not be able to save screenshots, and the modified web control will not be able to show the oscilloscope screen.
It is advisable to have a backup of the memory card image just in case, although if you follow the instructions exactly, you should not need it :) But in extreme cases, this backup can be found on the network or asked from someone :)
1. System patch to disable signature verification. It is done only once, there is no need to repeat it in the future when updating applications to modified or original ones.
For this, you will need ADB - https://developer.android.com/tools/releases/platform-tools , you need to download it and unpack it into a separate directory. It will be convenient to add this directory to the system environment variables so that you can call adb.exe from anywhere, and not just from this folder.
The oscilloscope must be connected to the local network with a cable or via Wi-Fi.
Download and unzip the archive using the link at the end of the post. It contains three files - modified oscilloscope and web control applications, and a patched system file.
Unzip these files to the directory with ADB (or any other if you added ADB to the system environment variables). Run the command line in this folder (open this folder in Explorer and enter the cmd command in its address bar) and then enter the commands shown below in the command line. You need to enter what is marked in bold italics, you can directly copy the specified commands and paste them into the command line.
The first command is to connect ADB to the device by its IP address. The IP address of the oscilloscope can be seen in the oscilloscope itself in the Utility->IO menu. Substitute the address of your oscilloscope instead of 192.168.1.41:
adb connect 192.168.1.41:55555
In response, ADB should report a successful connection:
connected to 192.168.1.41:55555
Now you need to load the patched system file into the oscilloscope:
adb push services.jar /rigol/data/
And get a response about success:
services.jar: 1 file pushed, 0 skipped. 59.7 MB/s (3179392 bytes in 0.051s)
Now run the ADB shell.
adb shell
In this case, instead of the system command line prompt (for example, D:\Rigol>), the oscilloscope command line prompt will appear, and then the commands are entered in this command line:
rk3399_rigol:/ $
Get administrator rights:
su
The $ symbol in the prompt will change to the # symbol:
rk3399_rigol:/ #
Make the system partition writable:
mount -o rw,remount /system
Delete the original system file:
rm /system/framework/services.jar -f
Also delete its remnants in another directory:
rm /system/framework/oat/arm64/services.odex -f
And delete its cache in another directory too:
rm /data/dalvik-cache/arm64/system@framework@services.jar@classes.dex
Move the patched system file previously loaded into the oscilloscope to the system section:
mv /rigol/data/services.jar /system/framework
Return the system partition to read-only mode:
mount -o ro,remount /system
Synchronization command to ensure that all file system changes are saved:
sync
Reboot the oscilloscope:
reboot now
During the reboot, the ADB shell will be dropped and the command line prompt of your system will return. That's it, now your oscilloscope takes all applications at their word that they are system applications, without checking the correctness of the key they are signed with :)
After the oscilloscope boots, you can install modified applications and they will work exactly the same as the original ones, without any restrictions (of course, if they are compiled under the system account).
2. Loading modified oscilloscope and web control applications.
First, just in case, give the ADB connection command again:
adb connect 192.168.1.41:55555
Most likely, ADB will respond that it is already connected:
already connected to 192.168.1.41:55555
Uninstall the installed oscilloscope application:
adb uninstall com.rigol.scope
The application on the oscilloscope should close and a success response should be given:
Success
Install the modified application:
adb install -g -r Sparrow_mod.apk
This may take quite a long time, but in the end a success response should be given:
Performing Streamed Install
Success
Repeat the same for the webcontrol application:
adb uninstall com.rigol.webcontrol
adb install -g -r Webcontrol_mod.apk
The oscilloscope application should start itself within 5-20 sec, but if it does not start - just turn off the oscilloscope by long pressing the power button (or by pulling out the power connector) and turn it on again.
I will describe the changes in the modified oscilloscope and web control applications in the next post.
Archive with files Sparrow_mod.apk, Webcontrol_mod.apk and services.jar: https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod/releases/tag/a002_00.01.04.00.02
-
Modified oscilloscope application version a002
- added display of probe dividers in channel icons
- added display of date and time in the lower right corner
- reduced the height of collapsed measurement results items on the right panel, so that now you can see up to 9 measurement results at a time; at the same time, the font of the values has been slightly increased for better readability
- the measurement results panel has been made slightly more transparent
- the sensitivity area of the arrows for expanding and collapsing measurement items on the right panel has been increased, so that now it is much easier to hit them (in the original interface, this is a real disaster)
- the main oscillogram window can be expanded to full screen and returned to its original size by clicking on the semi-transparent icon in the upper left corner of the window
Screenshots of the modified application:
[attach=4]
[attach=5]
[attach=6]
[attach=1]
[attach=2]
[attach=3]
Modified web control application
- added a button for a screenshot in PNG format, which gives a higher quality picture:
[attach=9]
- improved image quality in the "live" video of the oscilloscope screen. For comparison, I provide a screenshot from the video in the original web control and in the modified one:
[attach=7]
[attach=8]
-
This is a little demo showing the average of 10 frames (up to 100) of the FFT and peak search.
https://www.youtube.com/watch?v=XAoBLTBc0W4 (https://www.youtube.com/watch?v=XAoBLTBc0W4)
-
I mean lowest time base, not highest.
I missed two more screens (Im blind). Anyway, now I can see, those dots are after interpolation - not original samples from ADC.
-
I missed two more screens (Im blind). Anyway, now I can see, those dots are after interpolation - not original samples from ADC.
No, your message arrived just when I was editing and uploading two more images. The last two show differences when the trigger is running and stopping.
-
i have problem with the probe compesation on the chanel 3, is the chanel since I already tried another probes.
fail probe compesation (https://www.youtube.com/watch?v=2Acmukt7y9Y)
-
Have you run self-calibration (with all probes removed)?
-
i have problem with the probe compesation on the chanel 3, is the chanel since I already tried another probes.
fail probe compesation (https://www.youtube.com/watch?v=2Acmukt7y9Y)
Looks like overcompensated. Probably self-calibration will do nothing, but it's 15 minutes, so it's worth to try.
If self-calibration will not help, reach Your seller and request guaranty service. I guess it's due to the flux residues or failure at manufacturing IC which is the heart of all four AFD.
Can You measure input capacitance of all four channels?
-
I would not indicate time duration for the self-cal as it may take much longer (ie. 36 minutes in my case after upgrade to 1.04 with the vanilla 804 v 1.03, probes disconnected) and some people may try to stop the self-cal before it actually finished then..
It will stop with a message that the self-cal has been successful written on the display.
..Probably self-calibration will do nothing, but it's 15 minutes, so it's worth to try.
PS: I would also let the scope run for several hours before the self-cal, such all inside the scope get at the right temperature..
-
So, I have prepared a short instruction on disabling signature verification by the system and installing modified web control and oscilloscope applications.
Disabling signature verification is necessary so that the system considers the installed applications trusted (supposedly they are signed with a system key) and gives these applications access to all services. Without this, the modified oscilloscope application will not be able to save screenshots, and the modified web control will not be able to show the oscilloscope screen.
Thank you for figuring this out! Out of curiosity, what did you change in services.jar? Is it possible to build the modified jar from your GitHub project?
-
So, I have prepared a short instruction on disabling signature verification by the system and installing modified web control and oscilloscope applications.
Disabling signature verification is necessary so that the system considers the installed applications trusted (supposedly they are signed with a system key) and gives these applications access to all services. Without this, the modified oscilloscope application will not be able to save screenshots, and the modified web control will not be able to show the oscilloscope screen.
Thank you for figuring this out! Out of curiosity, what did you change in services.jar? Is it possible to build the modified jar from your GitHub project?
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) ;)
-
Btw., is the mod via the procedure with modding the vendor.bin reversible, such the changes are not detectable? What I've seen somewhere the RKey.data becomes Key.data after the mod.
So perhaps returning the original RKey.data and vendor.bin will make it vanilla again (like "Make Rigol Vanilla Again")??..
-
You can backup whole /rigol/data directory.
-
So, I have prepared a short instruction on disabling signature verification by the system and installing modified web control and oscilloscope applications.
Disabling signature verification is necessary so that the system considers the installed applications trusted (supposedly they are signed with a system key) and gives these applications access to all services. Without this, the modified oscilloscope application will not be able to save screenshots, and the modified web control will not be able to show the oscilloscope screen.
Thank you for figuring this out! Out of curiosity, what did you change in services.jar? Is it possible to build the modified jar from your GitHub project?
No, there is only a pre-built services.jar on GitHub. You can rebuild it yourself, which is what shapirus did, his rebuilt file is on my GitHub :) He found this method online and applied it. I tried to rebuild it myself, but something didn't work the first time and I didn't bother to figure out what the problem was with it, I just used the file provided by shapirus :)
In short - in this file, in several signature verification methods, you need to make them always return zero.
-
i have problem with the probe compesation on the chanel 3, is the chanel since I already tried another probes.
fail probe compesation (https://www.youtube.com/watch?v=2Acmukt7y9Y)
Looks like overcompensated. Probably self-calibration will do nothing, but it's 15 minutes, so it's worth to try.
If self-calibration will not help, reach Your seller and request guaranty service. I guess it's due to the flux residues or failure at manufacturing IC which is the heart of all four AFD.
Can You measure input capacitance of all four channels?
I got these measurements when measuring capacitance at the outputs with the multimeter
1: 1.64nf
2: 1.60nf
3: 1.84nf
4: 1.58nf
-
I'm afraid the measurement of the input capacitance with a multimeter may not be accurate. A check with an RLC bridge type instrument (Shannon Tweezers) results in 15.82pF, 15.86pF, 15.8pF and 15.92pF for channels 1~4. These figures match well with the specified 15pF and the tolerance is about what's to be expected.
-
Unfortunately...got to ask for some assistance. I just "half-bricked" my scope :-//
After successfully installing @AndyBig's U/I patch and playing around with it a little (really nice add-ons by the way), I decided to change the time zone in "rigol/shell/start_rigol_app.sh" -- pulled it, edited it, pushed it. Upon the next reboot, the scope only booted to the "RIGOL" splash screen, or so it seems. At least no relays are clicking or LEDs flashing. I still can access the scope via "adb" and the web app allows me to make a screenshot...of the "RIGOL" splash screen. Pushed the original "start_rigol_app.sh" back on the scope -- no change. Please see attached the list of running processes if that may be helpful. It seems everything is running, but anyway, no scope app on the screen. Maybe someone has got a hint for me what to try before I restore the SD card image that I took some time ago.
Thanks,
Thomas
rk3399_rigol:/ # ps
USER PID PPID VSIZE RSS WCHAN PC NAME
root 1 0 10524 2024 SyS_epoll_ 00004ccd60 S /init
root 2 0 0 0 kthreadd 0000000000 S kthreadd
root 3 2 0 0 smpboot_th 0000000000 S ksoftirqd/0
root 4 2 0 0 worker_thr 0000000000 S kworker/0:0
root 5 2 0 0 worker_thr 0000000000 S kworker/0:0H
root 7 2 0 0 rcu_gp_kth 0000000000 S rcu_preempt
root 8 2 0 0 rcu_gp_kth 0000000000 S rcu_sched
root 9 2 0 0 rcu_gp_kth 0000000000 S rcu_bh
root 10 2 0 0 smpboot_th 0000000000 S migration/0
root 11 2 0 0 smpboot_th 0000000000 S watchdog/0
root 12 2 0 0 smpboot_th 0000000000 S watchdog/1
root 13 2 0 0 smpboot_th 0000000000 S migration/1
root 14 2 0 0 smpboot_th 0000000000 S ksoftirqd/1
root 16 2 0 0 worker_thr 0000000000 S kworker/1:0H
root 17 2 0 0 smpboot_th 0000000000 S watchdog/2
root 18 2 0 0 smpboot_th 0000000000 S migration/2
root 19 2 0 0 smpboot_th 0000000000 S ksoftirqd/2
root 20 2 0 0 worker_thr 0000000000 S kworker/2:0
root 21 2 0 0 worker_thr 0000000000 S kworker/2:0H
root 22 2 0 0 smpboot_th 0000000000 S watchdog/3
root 23 2 0 0 smpboot_th 0000000000 S migration/3
root 24 2 0 0 smpboot_th 0000000000 S ksoftirqd/3
root 26 2 0 0 worker_thr 0000000000 S kworker/3:0H
root 27 2 0 0 smpboot_th 0000000000 S watchdog/4
root 28 2 0 0 smpboot_th 0000000000 S migration/4
root 29 2 0 0 smpboot_th 0000000000 S ksoftirqd/4
root 31 2 0 0 worker_thr 0000000000 S kworker/4:0H
root 32 2 0 0 smpboot_th 0000000000 S watchdog/5
root 33 2 0 0 smpboot_th 0000000000 S migration/5
root 34 2 0 0 smpboot_th 0000000000 S ksoftirqd/5
root 35 2 0 0 worker_thr 0000000000 S kworker/5:0
root 36 2 0 0 worker_thr 0000000000 S kworker/5:0H
root 37 2 0 0 devtmpfsd 0000000000 S kdevtmpfs
root 38 2 0 0 rescuer_th 0000000000 S netns
root 39 2 0 0 rescuer_th 0000000000 S perf
root 40 2 0 0 console_th 0000000000 S kconsole
root 41 2 0 0 watchdog 0000000000 S khungtaskd
root 42 2 0 0 rescuer_th 0000000000 S writeback
root 43 2 0 0 ksm_scan_t 0000000000 S ksmd
root 44 2 0 0 rescuer_th 0000000000 S crypto
root 45 2 0 0 rescuer_th 0000000000 S bioset
root 46 2 0 0 rescuer_th 0000000000 S kblockd
root 47 2 0 0 worker_thr 0000000000 S kworker/4:1
root 48 2 0 0 rescuer_th 0000000000 S devfreq_wq
root 49 2 0 0 rescuer_th 0000000000 S cfg80211
root 50 2 0 0 cpufreq_in 0000000000 S cfinteractive
root 52 2 0 0 rescuer_th 0000000000 S rpciod
root 68 2 0 0 kswapd 0000000000 S kswapd0
root 69 2 0 0 rescuer_th 0000000000 S vmstat
root 70 2 0 0 fsnotify_m 0000000000 S fsnotify_mark
root 71 2 0 0 rescuer_th 0000000000 S nfsiod
root 72 2 0 0 rescuer_th 0000000000 S cifsiod
root 104 2 0 0 irq_thread 0000000000 S irq/224-rockchi
root 105 2 0 0 irq_thread 0000000000 S irq/225-rockchi
root 106 2 0 0 irq_thread 0000000000 S irq/226-rockchi
root 107 2 0 0 irq_thread 0000000000 S irq/227-rockchi
root 108 2 0 0 irq_thread 0000000000 S irq/228-rockchi
root 109 2 0 0 irq_thread 0000000000 S irq/45-ff670000
root 110 2 0 0 rescuer_th 0000000000 S vcodec
root 111 2 0 0 irq_thread 0000000000 S irq/41-ff650000
root 112 2 0 0 irq_thread 0000000000 S irq/40-ff650000
root 113 2 0 0 rescuer_th 0000000000 S vcodec
root 114 2 0 0 irq_thread 0000000000 S irq/43-ff660000
root 115 2 0 0 rescuer_th 0000000000 S bioset
root 116 2 0 0 rescuer_th 0000000000 S bioset
root 117 2 0 0 rescuer_th 0000000000 S bioset
root 118 2 0 0 rescuer_th 0000000000 S bioset
root 119 2 0 0 rescuer_th 0000000000 S bioset
root 120 2 0 0 rescuer_th 0000000000 S bioset
root 121 2 0 0 rescuer_th 0000000000 S bioset
root 122 2 0 0 rescuer_th 0000000000 S bioset
root 123 2 0 0 rescuer_th 0000000000 S bioset
root 124 2 0 0 rescuer_th 0000000000 S bioset
root 125 2 0 0 rescuer_th 0000000000 S bioset
root 126 2 0 0 rescuer_th 0000000000 S bioset
root 127 2 0 0 rescuer_th 0000000000 S bioset
root 128 2 0 0 rescuer_th 0000000000 S bioset
root 129 2 0 0 rescuer_th 0000000000 S bioset
root 130 2 0 0 rescuer_th 0000000000 S bioset
root 131 2 0 0 rescuer_th 0000000000 S bioset
root 132 2 0 0 rescuer_th 0000000000 S bioset
root 133 2 0 0 rescuer_th 0000000000 S bioset
root 134 2 0 0 rescuer_th 0000000000 S bioset
root 135 2 0 0 rescuer_th 0000000000 S bioset
root 136 2 0 0 rescuer_th 0000000000 S bioset
root 137 2 0 0 rescuer_th 0000000000 S bioset
root 138 2 0 0 rescuer_th 0000000000 S bioset
root 139 2 0 0 rescuer_th 0000000000 S bioset
root 140 2 0 0 rescuer_th 0000000000 S nvme
root 141 2 0 0 kthread_wo 0000000000 S spi1
root 142 2 0 0 kthread_wo 0000000000 S spi2
root 144 2 0 0 msleep 0000000000 D kworker/0:1
root 146 2 0 0 worker_thr 0000000000 S kworker/1:1
root 147 2 0 0 irq_thread 0000000000 S irq/115-rk808
root 148 2 0 0 irq_thread 0000000000 S irq/35-rockchip
root 149 2 0 0 rescuer_th 0000000000 S dm_bufio_cache
root 150 2 0 0 worker_thr 0000000000 S kworker/4:2
root 151 2 0 0 irq_thread 0000000000 S irq/26-mmc1
root 152 2 0 0 rescuer_th 0000000000 S bioset
root 153 2 0 0 worker_thr 0000000000 S kworker/1:2
root 154 2 0 0 mmc_queue_ 0000000000 S mmcqd/0
root 155 2 0 0 rescuer_th 0000000000 S binder
root 156 2 0 0 rescuer_th 0000000000 S ipv6_addrconf
root 157 2 0 0 wait_woken 0000000000 S krfcommd
root 159 2 0 0 irq_thread 0000000000 S irq/46-rga
root 160 2 0 0 worker_thr 0000000000 S kworker/2:1
root 161 2 0 0 rescuer_th 0000000000 S deferwq
root 162 2 0 0 rescuer_th 0000000000 S hpd_queue
root 163 2 0 0 irq_thread 0000000000 S irq/55-ff940000
root 164 2 0 0 rescuer_th 0000000000 S gpu_power_off_w
root 166 2 0 0 worker_thr 0000000000 S kworker/3:1
root 167 2 0 0 worker_thr 0000000000 S kworker/u13:1
root 168 2 0 0 rescuer_th 0000000000 S kbase_job_fault
root 169 2 0 0 worker_thr 0000000000 S kworker/u12:2
root 170 2 0 0 worker_thr 0000000000 R kworker/u12:3
root 172 1 5780 1068 poll_sched 00004ccd90 S /sbin/ueventd
root 174 2 0 0 worker_thr 0000000000 S kworker/4:1H
root 175 2 0 0 worker_thr 0000000000 S kworker/5:1H
root 176 2 0 0 kjournald2 0000000000 S jbd2/mmcblk0p10
root 177 2 0 0 rescuer_th 0000000000 S ext4-rsv-conver
root 179 2 0 0 kjournald2 0000000000 S jbd2/mmcblk0p9-
root 180 2 0 0 rescuer_th 0000000000 S ext4-rsv-conver
root 184 2 0 0 kjournald2 0000000000 S jbd2/mmcblk0p11
root 185 2 0 0 rescuer_th 0000000000 S ext4-rsv-conver
root 189 2 0 0 kjournald2 0000000000 S jbd2/mmcblk0p16
root 190 2 0 0 rescuer_th 0000000000 S ext4-rsv-conver
root 192 2 0 0 kjournald2 0000000000 S jbd2/mmcblk0p15
root 193 2 0 0 rescuer_th 0000000000 S ext4-rsv-conver
logd 194 1 18020 3600 sigsuspend 7379817d4c S /system/bin/logd
root 199 2 0 0 kauditd_th 0000000000 S kauditd
root 203 1 5348 2704 __skb_recv 00eb9b24a8 S /system/bin/debuggerd
root 204 1 10288 3340 __skb_recv 7d6b439b24 S /system/bin/debuggerd64
root 205 1 18148 5976 hrtimer_na 7a06161574 S /system/bin/vold
root 206 204 9904 604 __skb_recv 7d6b43a67c S debuggerd64:signaller
root 208 203 5092 536 __skb_recv 00eb9b36dc S debuggerd:signaller
root 215 2 0 0 worker_thr 0000000000 S kworker/0:1H
root 217 1 6432 932 SyS_epoll_ 000047cc78 S /sbin/healthd
root 219 1 8932 2820 SyS_epoll_ 70e5cf0b84 S /system/bin/lmkd
system 220 1 9156 2312 binder_thr 7a1ad4ec74 S /system/bin/servicemanager
system 221 1 262208 40272 SyS_epoll_ 7f33d6cb84 S /system/bin/surfaceflinger
shell 223 1 7716 2576 wait_woken 7e4bc3d67c S /system/bin/sh
shell 224 1 14144 1036 poll_sched 00004a5c90 S /sbin/adbd
root 227 1 4744 300 __skb_recv 0000410c58 S /system/xbin/su
root 231 1 7716 1792 sigsuspend 795014bd4c S /system/bin/sh
root 233 1 2154796 133704 poll_sched 75d819fca4 S zygote64
root 234 1 1592648 119412 poll_sched 00f0c5b734 S zygote
audioserver 235 1 26404 8932 binder_thr 00efd6d68c S /system/bin/audioserver
drm 236 1 13860 6484 binder_thr 00f290f68c S /system/bin/drmserver
root 237 1 9620 2512 unix_strea 784fd2767c S /system/bin/installd
keystore 238 1 12640 4404 binder_thr 74be3bfc74 S /system/bin/keystore
mediacodec 239 1 33192 9416 binder_thr 00ef20268c S media.codec
media 240 1 38440 11984 binder_thr 00f35f068c S /system/bin/mediadrmserver
mediaex 241 1 45224 9992 binder_thr 00e73b168c S media.extractor
media 242 1 67324 14408 binder_thr 00f092868c S /system/bin/mediaserver
root 243 1 26908 5056 binder_thr 7a1ed36c74 S /system/bin/netd
root 244 1 10436 3792 poll_sched 7f11debcbc S /system/vendor/bin/crashlogd
root 246 1 10188 1936 devkmsg_re 728b6a167c S /vendor/bin/log-watch
system 247 1 12328 4300 binder_thr 7432e06c74 S /system/bin/gatekeeperd
root 248 1 8272 2040 hrtimer_na 7d57a7c574 S /system/xbin/perfprofd
root 252 231 10100 4108 poll_sched 77df44acbc S /system/bin/sshd
root 253 1 7716 2548 sigsuspend 7d2c42ed4c S /system/bin/sh
root 262 253 9096 1768 __skb_recv 71da75d6dc S /system/vendor/bin/logcatext
root 279 2 0 0 worker_thr 0000000000 S kworker/3:1H
root 291 2 0 0 rescuer_th 0000000000 S kbase_event
root 549 2 0 0 worker_thr 0000000000 S kworker/2:1H
root 550 2 0 0 worker_thr 0000000000 S kworker/u13:2
system 559 233 2201276 205720 SyS_epoll_ 75d819fb84 S system_server
root 592 2 0 0 worker_thr 0000000000 S kworker/1:1H
root 636 2 0 0 rescuer_th 0000000000 S kbase_event
u0_a15 651 233 1787376 161492 SyS_epoll_ 75d819fb84 S com.android.systemui
system 665 233 1779444 111424 SyS_epoll_ 75d819fb84 S com.android.settings
root 683 2 0 0 rescuer_th 0000000000 S rtw_workqueue
root 687 2 0 0 rescuer_th 0000000000 S kbase_event
media_rw 732 205 0 0 do_exit 0000000000 Z sdcard
root 776 2 0 0 down_inter 0000000000 S RTW_CMD_THREAD
root 779 2 0 0 worker_thr 0000000000 S kworker/0:2
wifi 822 1 14312 7112 poll_sched 7d811decbc S /system/bin/wpa_supplicant
root 932 2 0 0 rescuer_th 0000000000 S kbase_event
u0_a5 961 233 1572436 73564 SyS_epoll_ 75d819fb84 S android.ext.services
system 994 233 1577156 80032 SyS_epoll_ 75d819fb84 S android.rockchip.update.service
system 1009 233 1575600 73236 SyS_epoll_ 75d819fb84 S com.android.keychain
system 1024 233 1776148 140528 SyS_epoll_ 75d819fb84 S com.rigol.launcher
u0_a27 1049 233 1577600 75652 SyS_epoll_ 75d819fb84 S com.android.printspooler
u0_a4 1067 233 1584764 93480 SyS_epoll_ 75d819fb84 S android.process.media
root 1131 2 0 0 rescuer_th 0000000000 S kbase_event
root 1146 2 0 0 worker_thr 0000000000 S kworker/3:2
u0_a7 1156 233 1572632 73624 SyS_epoll_ 75d819fb84 S com.android.managedprovisioning
system 1174 233 1592948 96572 SyS_epoll_ 75d819fb84 S com.rigol.launcher:Watchdog
system 1188 233 1630248 105276 SyS_epoll_ 75d819fb84 S com.rigol.webcontrol
root 1295 2 0 0 worker_thr 0000000000 S kworker/5:2
system 1329 1024 4744 308 do_wait 0000411078 S su
system 1331 1329 4744 140 unix_strea 0000410f70 S su
root 1333 1 4744 140 do_wait 0000411078 S /system/xbin/su
root 1334 1333 4744 148 do_wait 0000411078 S /system/xbin/su
root 1335 1334 7716 2644 pipe_wait 799ae1767c S sh
root 1398 2 0 0 worker_thr 0000000000 S kworker/5:1
root 1407 2 0 0 worker_thr 0000000000 S kworker/1:0
system 1408 233 1689076 116656 hrtimer_na 75d81a0574 S com.rigol.scope
root 1430 2 0 0 worker_thr 0000000000 S kworker/u13:0
root 1431 2 0 0 worker_thr 0000000000 R kworker/u12:0
shell 1433 224 7716 2684 sigsuspend 7490cc4d4c S /system/bin/sh
root 1436 1433 4744 304 do_wait 0000411078 S su
root 1437 1436 6808 140 wait_woken 0000410f70 S su
root 1439 1 4744 140 do_wait 0000411078 S /system/xbin/su
root 1442 1439 4744 148 do_wait 0000411078 S /system/xbin/su
root 1443 1442 7716 2596 sigsuspend 74ae5d4d4c S sh
root 1454 1443 9116 2440 0 751294e67c R ps
rk3399_rigol:/ #
-
Unfortunately...got to ask for some assistance. I just "half-bricked" my scope :-//
After successfully installing @AndyBig's U/I patch and playing around with it a little (really nice add-ons by the way), I decided to change the time zone in "rigol/shell/start_rigol_app.sh" -- pulled it, edited it, pushed it. Upon the next reboot, the scope only booted to the "RIGOL" splash screen, or so it seems. At least no relays are clicking or LEDs flashing. I still can access the scope via "adb" and the web app allows me to make a screenshot...of the "RIGOL" splash screen. Pushed the original "start_rigol_app.sh" back on the scope -- no change. Please see attached the list of running processes if that may be helpful. It seems everything is running, but anyway, no scope app on the screen. Maybe someone has got a hint for me what to try before I restore the SD card image that I took some time ago.
At last, I'm not alone.
I had precisely the same issue. Half-brick after changing the time zone. In my case it eventually booted after I left it sitting powered on, I think it took a few hours. When it finally booted, I restored the original time zone and never touched it again.
-
I just measured the capacitance of the oscilloscope off at 100 kHz:
- oscilloscope input: 17.25 pF
- probe on 1:1 divider (connected to the oscilloscope, of course): 79.34 pF
- probe on 1:10 divider: 13.97 pF
The readings differ slightly between channels, within 0.2 pF.
-
Unfortunately...got to ask for some assistance. I just "half-bricked" my scope :-//
After successfully installing @AndyBig's U/I patch and playing around with it a little (really nice add-ons by the way), I decided to change the time zone in "rigol/shell/start_rigol_app.sh" -- pulled it, edited it, pushed it. Upon the next reboot, the scope only booted to the "RIGOL" splash screen, or so it seems. At least no relays are clicking or LEDs flashing. I still can access the scope via "adb" and the web app allows me to make a screenshot...of the "RIGOL" splash screen. Pushed the original "start_rigol_app.sh" back on the scope -- no change. Please see attached the list of running processes if that may be helpful. It seems everything is running, but anyway, no scope app on the screen. Maybe someone has got a hint for me what to try before I restore the SD card image that I took some time ago.
Thanks,
Thomas
It is better to look at the logcat output a minute after turning on the oscilloscope. Most likely, the reason for the failure to boot will be displayed there.
Under Windows, the adb logcat >logcat.txt command will save the output to the logcat.txt file in the current directory. Run this command, wait 3-5 seconds, interrupt it with Ctrl+C. Nothing is displayed on the screen, everything is written to the file.
Actually, I've changed the time zone in the startup script several times, and this has never happened before. Maybe when editing the script is saved with damage? Like the added UTF-8 header, or replacing \r with \r\n ?
-
Unfortunately...got to ask for some assistance. I just "half-bricked" my scope :-//
After successfully installing @AndyBig's U/I patch and playing around with it a little (really nice add-ons by the way), I decided to change the time zone in "rigol/shell/start_rigol_app.sh" -- pulled it, edited it, pushed it. Upon the next reboot, the scope only booted to the "RIGOL" splash screen, or so it seems. At least no relays are clicking or LEDs flashing. I still can access the scope via "adb" and the web app allows me to make a screenshot...of the "RIGOL" splash screen. Pushed the original "start_rigol_app.sh" back on the scope -- no change. Please see attached the list of running processes if that may be helpful. It seems everything is running, but anyway, no scope app on the screen. Maybe someone has got a hint for me what to try before I restore the SD card image that I took some time ago.
Thanks,
Thomas
rk3399_rigol:/ # ps
USER PID PPID VSIZE RSS WCHAN PC NAME
root 1 0 10524 2024 SyS_epoll_ 00004ccd60 S /init
root 2 0 0 0 kthreadd 0000000000 S kthreadd
root 3 2 0 0 smpboot_th 0000000000 S ksoftirqd/0
root 4 2 0 0 worker_thr 0000000000 S kworker/0:0
root 5 2 0 0 worker_thr 0000000000 S kworker/0:0H
root 7 2 0 0 rcu_gp_kth 0000000000 S rcu_preempt
root 8 2 0 0 rcu_gp_kth 0000000000 S rcu_sched
root 9 2 0 0 rcu_gp_kth 0000000000 S rcu_bh
root 10 2 0 0 smpboot_th 0000000000 S migration/0
root 11 2 0 0 smpboot_th 0000000000 S watchdog/0
root 12 2 0 0 smpboot_th 0000000000 S watchdog/1
root 13 2 0 0 smpboot_th 0000000000 S migration/1
root 14 2 0 0 smpboot_th 0000000000 S ksoftirqd/1
root 16 2 0 0 worker_thr 0000000000 S kworker/1:0H
root 17 2 0 0 smpboot_th 0000000000 S watchdog/2
root 18 2 0 0 smpboot_th 0000000000 S migration/2
root 19 2 0 0 smpboot_th 0000000000 S ksoftirqd/2
root 20 2 0 0 worker_thr 0000000000 S kworker/2:0
root 21 2 0 0 worker_thr 0000000000 S kworker/2:0H
root 22 2 0 0 smpboot_th 0000000000 S watchdog/3
root 23 2 0 0 smpboot_th 0000000000 S migration/3
root 24 2 0 0 smpboot_th 0000000000 S ksoftirqd/3
root 26 2 0 0 worker_thr 0000000000 S kworker/3:0H
root 27 2 0 0 smpboot_th 0000000000 S watchdog/4
root 28 2 0 0 smpboot_th 0000000000 S migration/4
root 29 2 0 0 smpboot_th 0000000000 S ksoftirqd/4
root 31 2 0 0 worker_thr 0000000000 S kworker/4:0H
root 32 2 0 0 smpboot_th 0000000000 S watchdog/5
root 33 2 0 0 smpboot_th 0000000000 S migration/5
root 34 2 0 0 smpboot_th 0000000000 S ksoftirqd/5
root 35 2 0 0 worker_thr 0000000000 S kworker/5:0
root 36 2 0 0 worker_thr 0000000000 S kworker/5:0H
root 37 2 0 0 devtmpfsd 0000000000 S kdevtmpfs
root 38 2 0 0 rescuer_th 0000000000 S netns
root 39 2 0 0 rescuer_th 0000000000 S perf
root 40 2 0 0 console_th 0000000000 S kconsole
root 41 2 0 0 watchdog 0000000000 S khungtaskd
root 42 2 0 0 rescuer_th 0000000000 S writeback
root 43 2 0 0 ksm_scan_t 0000000000 S ksmd
root 44 2 0 0 rescuer_th 0000000000 S crypto
root 45 2 0 0 rescuer_th 0000000000 S bioset
root 46 2 0 0 rescuer_th 0000000000 S kblockd
root 47 2 0 0 worker_thr 0000000000 S kworker/4:1
root 48 2 0 0 rescuer_th 0000000000 S devfreq_wq
root 49 2 0 0 rescuer_th 0000000000 S cfg80211
root 50 2 0 0 cpufreq_in 0000000000 S cfinteractive
root 52 2 0 0 rescuer_th 0000000000 S rpciod
root 68 2 0 0 kswapd 0000000000 S kswapd0
root 69 2 0 0 rescuer_th 0000000000 S vmstat
root 70 2 0 0 fsnotify_m 0000000000 S fsnotify_mark
root 71 2 0 0 rescuer_th 0000000000 S nfsiod
root 72 2 0 0 rescuer_th 0000000000 S cifsiod
root 104 2 0 0 irq_thread 0000000000 S irq/224-rockchi
root 105 2 0 0 irq_thread 0000000000 S irq/225-rockchi
root 106 2 0 0 irq_thread 0000000000 S irq/226-rockchi
root 107 2 0 0 irq_thread 0000000000 S irq/227-rockchi
root 108 2 0 0 irq_thread 0000000000 S irq/228-rockchi
root 109 2 0 0 irq_thread 0000000000 S irq/45-ff670000
root 110 2 0 0 rescuer_th 0000000000 S vcodec
root 111 2 0 0 irq_thread 0000000000 S irq/41-ff650000
root 112 2 0 0 irq_thread 0000000000 S irq/40-ff650000
root 113 2 0 0 rescuer_th 0000000000 S vcodec
root 114 2 0 0 irq_thread 0000000000 S irq/43-ff660000
root 115 2 0 0 rescuer_th 0000000000 S bioset
root 116 2 0 0 rescuer_th 0000000000 S bioset
root 117 2 0 0 rescuer_th 0000000000 S bioset
root 118 2 0 0 rescuer_th 0000000000 S bioset
root 119 2 0 0 rescuer_th 0000000000 S bioset
root 120 2 0 0 rescuer_th 0000000000 S bioset
root 121 2 0 0 rescuer_th 0000000000 S bioset
root 122 2 0 0 rescuer_th 0000000000 S bioset
root 123 2 0 0 rescuer_th 0000000000 S bioset
root 124 2 0 0 rescuer_th 0000000000 S bioset
root 125 2 0 0 rescuer_th 0000000000 S bioset
root 126 2 0 0 rescuer_th 0000000000 S bioset
root 127 2 0 0 rescuer_th 0000000000 S bioset
root 128 2 0 0 rescuer_th 0000000000 S bioset
root 129 2 0 0 rescuer_th 0000000000 S bioset
root 130 2 0 0 rescuer_th 0000000000 S bioset
root 131 2 0 0 rescuer_th 0000000000 S bioset
root 132 2 0 0 rescuer_th 0000000000 S bioset
root 133 2 0 0 rescuer_th 0000000000 S bioset
root 134 2 0 0 rescuer_th 0000000000 S bioset
root 135 2 0 0 rescuer_th 0000000000 S bioset
root 136 2 0 0 rescuer_th 0000000000 S bioset
root 137 2 0 0 rescuer_th 0000000000 S bioset
root 138 2 0 0 rescuer_th 0000000000 S bioset
root 139 2 0 0 rescuer_th 0000000000 S bioset
root 140 2 0 0 rescuer_th 0000000000 S nvme
root 141 2 0 0 kthread_wo 0000000000 S spi1
root 142 2 0 0 kthread_wo 0000000000 S spi2
root 144 2 0 0 msleep 0000000000 D kworker/0:1
root 146 2 0 0 worker_thr 0000000000 S kworker/1:1
root 147 2 0 0 irq_thread 0000000000 S irq/115-rk808
root 148 2 0 0 irq_thread 0000000000 S irq/35-rockchip
root 149 2 0 0 rescuer_th 0000000000 S dm_bufio_cache
root 150 2 0 0 worker_thr 0000000000 S kworker/4:2
root 151 2 0 0 irq_thread 0000000000 S irq/26-mmc1
root 152 2 0 0 rescuer_th 0000000000 S bioset
root 153 2 0 0 worker_thr 0000000000 S kworker/1:2
root 154 2 0 0 mmc_queue_ 0000000000 S mmcqd/0
root 155 2 0 0 rescuer_th 0000000000 S binder
root 156 2 0 0 rescuer_th 0000000000 S ipv6_addrconf
root 157 2 0 0 wait_woken 0000000000 S krfcommd
root 159 2 0 0 irq_thread 0000000000 S irq/46-rga
root 160 2 0 0 worker_thr 0000000000 S kworker/2:1
root 161 2 0 0 rescuer_th 0000000000 S deferwq
root 162 2 0 0 rescuer_th 0000000000 S hpd_queue
root 163 2 0 0 irq_thread 0000000000 S irq/55-ff940000
root 164 2 0 0 rescuer_th 0000000000 S gpu_power_off_w
root 166 2 0 0 worker_thr 0000000000 S kworker/3:1
root 167 2 0 0 worker_thr 0000000000 S kworker/u13:1
root 168 2 0 0 rescuer_th 0000000000 S kbase_job_fault
root 169 2 0 0 worker_thr 0000000000 S kworker/u12:2
root 170 2 0 0 worker_thr 0000000000 R kworker/u12:3
root 172 1 5780 1068 poll_sched 00004ccd90 S /sbin/ueventd
root 174 2 0 0 worker_thr 0000000000 S kworker/4:1H
root 175 2 0 0 worker_thr 0000000000 S kworker/5:1H
root 176 2 0 0 kjournald2 0000000000 S jbd2/mmcblk0p10
root 177 2 0 0 rescuer_th 0000000000 S ext4-rsv-conver
root 179 2 0 0 kjournald2 0000000000 S jbd2/mmcblk0p9-
root 180 2 0 0 rescuer_th 0000000000 S ext4-rsv-conver
root 184 2 0 0 kjournald2 0000000000 S jbd2/mmcblk0p11
root 185 2 0 0 rescuer_th 0000000000 S ext4-rsv-conver
root 189 2 0 0 kjournald2 0000000000 S jbd2/mmcblk0p16
root 190 2 0 0 rescuer_th 0000000000 S ext4-rsv-conver
root 192 2 0 0 kjournald2 0000000000 S jbd2/mmcblk0p15
root 193 2 0 0 rescuer_th 0000000000 S ext4-rsv-conver
logd 194 1 18020 3600 sigsuspend 7379817d4c S /system/bin/logd
root 199 2 0 0 kauditd_th 0000000000 S kauditd
root 203 1 5348 2704 __skb_recv 00eb9b24a8 S /system/bin/debuggerd
root 204 1 10288 3340 __skb_recv 7d6b439b24 S /system/bin/debuggerd64
root 205 1 18148 5976 hrtimer_na 7a06161574 S /system/bin/vold
root 206 204 9904 604 __skb_recv 7d6b43a67c S debuggerd64:signaller
root 208 203 5092 536 __skb_recv 00eb9b36dc S debuggerd:signaller
root 215 2 0 0 worker_thr 0000000000 S kworker/0:1H
root 217 1 6432 932 SyS_epoll_ 000047cc78 S /sbin/healthd
root 219 1 8932 2820 SyS_epoll_ 70e5cf0b84 S /system/bin/lmkd
system 220 1 9156 2312 binder_thr 7a1ad4ec74 S /system/bin/servicemanager
system 221 1 262208 40272 SyS_epoll_ 7f33d6cb84 S /system/bin/surfaceflinger
shell 223 1 7716 2576 wait_woken 7e4bc3d67c S /system/bin/sh
shell 224 1 14144 1036 poll_sched 00004a5c90 S /sbin/adbd
root 227 1 4744 300 __skb_recv 0000410c58 S /system/xbin/su
root 231 1 7716 1792 sigsuspend 795014bd4c S /system/bin/sh
root 233 1 2154796 133704 poll_sched 75d819fca4 S zygote64
root 234 1 1592648 119412 poll_sched 00f0c5b734 S zygote
audioserver 235 1 26404 8932 binder_thr 00efd6d68c S /system/bin/audioserver
drm 236 1 13860 6484 binder_thr 00f290f68c S /system/bin/drmserver
root 237 1 9620 2512 unix_strea 784fd2767c S /system/bin/installd
keystore 238 1 12640 4404 binder_thr 74be3bfc74 S /system/bin/keystore
mediacodec 239 1 33192 9416 binder_thr 00ef20268c S media.codec
media 240 1 38440 11984 binder_thr 00f35f068c S /system/bin/mediadrmserver
mediaex 241 1 45224 9992 binder_thr 00e73b168c S media.extractor
media 242 1 67324 14408 binder_thr 00f092868c S /system/bin/mediaserver
root 243 1 26908 5056 binder_thr 7a1ed36c74 S /system/bin/netd
root 244 1 10436 3792 poll_sched 7f11debcbc S /system/vendor/bin/crashlogd
root 246 1 10188 1936 devkmsg_re 728b6a167c S /vendor/bin/log-watch
system 247 1 12328 4300 binder_thr 7432e06c74 S /system/bin/gatekeeperd
root 248 1 8272 2040 hrtimer_na 7d57a7c574 S /system/xbin/perfprofd
root 252 231 10100 4108 poll_sched 77df44acbc S /system/bin/sshd
root 253 1 7716 2548 sigsuspend 7d2c42ed4c S /system/bin/sh
root 262 253 9096 1768 __skb_recv 71da75d6dc S /system/vendor/bin/logcatext
root 279 2 0 0 worker_thr 0000000000 S kworker/3:1H
root 291 2 0 0 rescuer_th 0000000000 S kbase_event
root 549 2 0 0 worker_thr 0000000000 S kworker/2:1H
root 550 2 0 0 worker_thr 0000000000 S kworker/u13:2
system 559 233 2201276 205720 SyS_epoll_ 75d819fb84 S system_server
root 592 2 0 0 worker_thr 0000000000 S kworker/1:1H
root 636 2 0 0 rescuer_th 0000000000 S kbase_event
u0_a15 651 233 1787376 161492 SyS_epoll_ 75d819fb84 S com.android.systemui
system 665 233 1779444 111424 SyS_epoll_ 75d819fb84 S com.android.settings
root 683 2 0 0 rescuer_th 0000000000 S rtw_workqueue
root 687 2 0 0 rescuer_th 0000000000 S kbase_event
media_rw 732 205 0 0 do_exit 0000000000 Z sdcard
root 776 2 0 0 down_inter 0000000000 S RTW_CMD_THREAD
root 779 2 0 0 worker_thr 0000000000 S kworker/0:2
wifi 822 1 14312 7112 poll_sched 7d811decbc S /system/bin/wpa_supplicant
root 932 2 0 0 rescuer_th 0000000000 S kbase_event
u0_a5 961 233 1572436 73564 SyS_epoll_ 75d819fb84 S android.ext.services
system 994 233 1577156 80032 SyS_epoll_ 75d819fb84 S android.rockchip.update.service
system 1009 233 1575600 73236 SyS_epoll_ 75d819fb84 S com.android.keychain
system 1024 233 1776148 140528 SyS_epoll_ 75d819fb84 S com.rigol.launcher
u0_a27 1049 233 1577600 75652 SyS_epoll_ 75d819fb84 S com.android.printspooler
u0_a4 1067 233 1584764 93480 SyS_epoll_ 75d819fb84 S android.process.media
root 1131 2 0 0 rescuer_th 0000000000 S kbase_event
root 1146 2 0 0 worker_thr 0000000000 S kworker/3:2
u0_a7 1156 233 1572632 73624 SyS_epoll_ 75d819fb84 S com.android.managedprovisioning
system 1174 233 1592948 96572 SyS_epoll_ 75d819fb84 S com.rigol.launcher:Watchdog
system 1188 233 1630248 105276 SyS_epoll_ 75d819fb84 S com.rigol.webcontrol
root 1295 2 0 0 worker_thr 0000000000 S kworker/5:2
system 1329 1024 4744 308 do_wait 0000411078 S su
system 1331 1329 4744 140 unix_strea 0000410f70 S su
root 1333 1 4744 140 do_wait 0000411078 S /system/xbin/su
root 1334 1333 4744 148 do_wait 0000411078 S /system/xbin/su
root 1335 1334 7716 2644 pipe_wait 799ae1767c S sh
root 1398 2 0 0 worker_thr 0000000000 S kworker/5:1
root 1407 2 0 0 worker_thr 0000000000 S kworker/1:0
system 1408 233 1689076 116656 hrtimer_na 75d81a0574 S com.rigol.scope
root 1430 2 0 0 worker_thr 0000000000 S kworker/u13:0
root 1431 2 0 0 worker_thr 0000000000 R kworker/u12:0
shell 1433 224 7716 2684 sigsuspend 7490cc4d4c S /system/bin/sh
root 1436 1433 4744 304 do_wait 0000411078 S su
root 1437 1436 6808 140 wait_woken 0000410f70 S su
root 1439 1 4744 140 do_wait 0000411078 S /system/xbin/su
root 1442 1439 4744 148 do_wait 0000411078 S /system/xbin/su
root 1443 1442 7716 2596 sigsuspend 74ae5d4d4c S sh
root 1454 1443 9116 2440 0 751294e67c R ps
rk3399_rigol:/ #
IMHO timezone was unrelated. See logs with logcat or dmesg.
adb root
adb shell
logcat | more
-
the adb logcat >logcat.txt command will save the output to the logcat.txt file in the current directory. Run this command, wait 3-5 seconds, interrupt it with Ctrl+C. Nothing is displayed on the screen, everything is written to the file.
Should be able to use the "-d" option to have logcat dump current contents of the log then exit. That way you don't need to do the "wait 3-5 seconds, interrupt it with Ctrl+C" dance.
adb logcat -d >logcat.txt
Maybe when editing the script is saved with damage? Like the added UTF-8 header, or replacing \r with \r\n ?
I'll bet you're right about the \r\n - all to easy to do when editing on Windows, and surprising how confused many linux applications are by it.
-
I'll bet you're right about the \r\n - all to easy to do when editing on Windows, and surprising how confused many linux applications are by it.
I think bash doesn't care about line endings. However Im not using Windows (Linux only) for about 20 years, so maybe something was changed.
-
In my case I obviously edited it where the line endings can only be \n, but I don't remember if I used adb to pull/push the boot script. That might be what affected it in some way.
If I ever try this again, I'll pay more attention: md5sum before/after, checking diff, etc.
p.s. as far as I recall, I found literally nothing in the logs. Hope TurboTom has more luck.
-
There is also Rigol logs dir: /data/logs/tools_log/
-
I pulled the logcat output (attached to this message), and as it seems, the watchdog tries to restart the scope app several times without success, outputting something like this:
"ContextImpl: Calling a method in the system process without a qualified user:" ...which may actually be the case ;)
But seriously, could that possibly be related to disabling the signature verification in order to be able to install the patched scope app? Strange thing is that it worked very well before I tried to change the time zone. I made sure that nothing else except Asia/Shanghai -> Europe/Berlin got changed, no CR to CR/LF or whatever mess-up. I also tried putting back the original "rigol/shell/start_rigol_app.sh" from the .GEL firmware update file.
Anyway, thanks a lot for the input so far. If all "repair" attempts fail, I can still write back the SD card image. But I'ld rather understand what caused the trouble...
Cheers,
Thomas
-
Failure that You never experienced before is a very good reason to learn something new.
-
This is strange...
01-18 16:50:32.588 560 560 W PackageManager: Failed to parse /system/app/Sparrow: Package com.rigol.scope at /system/app/Sparrow ignored: updated version 1008000 better than this 1008000
01-18 16:50:32.713 560 560 W PackageManager: Failed to parse /system/app/Webcontrol: Package com.rigol.webcontrol at /system/app/Webcontrol ignored: updated version 1 better than this 1
But later it's being executed and...
01-15 04:14:24.194 1101 1101 E [RIGOL.SCOPE]: [drv_panel.c][DrvPanel_GetHardwareGpioVerion][368]:GPIO SYS FD ERROR
This is strange, like something with DT (Device Tree - which is not in filesystem but on the beginning of SD card) or maybe related with modules.
Please give me output of lsmod and dmesg.
-
Here they are:
rk3399_rigol:/ # lsmod
Module Size Used by
8188eu 2016009 0
Output of dmesg is attached as a text file.
-
Also try this (as root):
echo 148 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio148/direction
echo 1 > /sys/class/gpio/gpio148/value
cat /sys/class/gpio/gpio148/value
cat /sys/kernel/debug/gpio
Pin 148 is not used by this scope (I did huge reverse engineering with my scope).
-
Here they are:
rk3399_rigol:/ # lsmod
Module Size Used by
8188eu 2016009 0
Output of dmesg is attached as a text file.
Forget what I said before. You don't have modules loaded by start_rigol_app.sh (insmod something.ko).
Maybe it doesn't have execution permission.
To check it: ls -l /rigol/shell/start_rigol_app.sh
To fix it: chmod a+x /rigol/shell/start_rigol_app.sh
-
In my case I obviously edited it where the line endings can only be \n, but I don't remember if I used adb to pull/push the boot script. That might be what affected it in some way.
If I ever try this again, I'll pay more attention: md5sum before/after, checking diff, etc.
p.s. as far as I recall, I found literally nothing in the logs. Hope TurboTom has more luck.
It is also possible that the script file loses its attributes after editing.
I just tried to remove the "executable" attributes from the startup script (chmod 666) and the oscilloscope application stopped starting. Everything is like with Shapirus and TurboTom - just a splash screen and nothing happens. I did not find anything related to this script in the logcat and terminal logs via com port.
After restoring the "executable" attributes (chmod 777) everything worked.
-
Maybe something related to this message ?
[ 2.193746] e2fsck: Superblock last mount time is in the future.
-
I just posted about permissions. chmod a+x is good enough. Maybe we shouldn't be stupid as a Rigol workers with chmod 777 on char device (/dev/something).
Maybe something related to this message ?
[ 2.193746] e2fsck: Superblock last mount time is in the future.
Nah, it means You don't have RTC and filesystem last mount time (in Linux ext4 filesystem that is stored in filesystem and checked at every mount). Just ignore it.
-
Here they are:
rk3399_rigol:/ # lsmod
Module Size Used by
8188eu 2016009 0
Output of dmesg is attached as a text file.
Try running these ADB commands (what is highlighted in bold italics):
D:\>adb shell
rk3399_rigol:/ $ su
rk3399_rigol:/ # chmod 777 /rigol/shell/start_rigol_app.sh
rk3399_rigol:/ # reboot now
-
rk3399_rigol:/ # reboot now
Just reboot (without now) should work. On this scope I suggest to do sync (command) before reboot (because of hard reset).
-
Hey, that did the trick! I also changed owner and group back to root (as the other shell scripts in the same directory, don't know if this was necessary). In hindsight it's obvious that if the file isn't executable, it won't work. I should have edited it with "vi" in the shell, but I was too lazy to look up the vi commands since I don't use it frequently...
Anyway, thanks a lot for all your suggestions and assistance, this shows the value of a community like this!
Cheers,
Thomas
Here they are:
rk3399_rigol:/ # lsmod
Module Size Used by
8188eu 2016009 0
Output of dmesg is attached as a text file.
Forget what I said before. You don't have modules loaded by start_rigol_app.sh (insmod something.ko).
Maybe it doesn't have execution permission.
To check it: ls -l /rigol/shell/start_rigol_app.sh
To fix it: chmod a+x /rigol/shell/start_rigol_app.sh
-
Practically it doesn't matter who is owner or group. Root can execute everything only if there is execution permission...
-
I should have edited it with "vi" in the shell, but I was too lazy to look up the vi commands since I don't use it frequently...
I usually edit files on the oscilloscope from the FAR file manager with the FARDroid plugin :)
-
AndyBig, You are wise enough. You can do some reverse engineering with libscope-auklet.so and make new app working with my "Orange Rigol". There are some open source apps already, but for other scopes.
Edit: Now Im using kernel 5.10 on this scope and it's stable. I remade Rigol drivers already - from reverse engineering.
Edit2: boot time is currently 31 seconds. Up to the graphical environment.
-
If all had been done inside Linux, as Norbert does, the execution permissions would have stayed.
I guess Thomas pushed original "start_rigol_app.sh" from Windows and, as such, the file lost its permissions.
-
Debian GNU/Linux for DHO800/DHO900 (Orange Rigol) (https://github.com/norbertkiszka/orangerigol)
BTW, great work!!! :clap: :clap: :clap:
-
Debian GNU/Linux for DHO800/DHO900 (Orange Rigol) (https://github.com/norbertkiszka/orangerigol)
BTW, great work!!! :clap: :clap: :clap:
Thanks. Only display driver for newer kernel (mipi-dsi output diver exactly) alone took literally one moth of work.
Anyway, I think this kernel (5.10.209) now can work with original firmware (Android). It's much more effective (faster) than 4.4 mostly due to changed scheduler for RK3399 CPU which is used in this scope family. But Im too lazy to try it.
-
AndyBig, You are wise enough. You can do some reverse engineering with libscope-auklet.so and make new app working with my "Orange Rigol". There are some open source apps already, but for other scopes.
No, I won't take on that. I know practically nothing about the Linux OS family. And frankly speaking, I don’t see much point :)
Edit2: boot time is currently 31 seconds. Up to the graphical environment.
Rigol boots to the desktop not much slower - 38 sec :)
-
Deep respect for your work! I hope Rigol take your work and learn how things could be better.
Rigol + Android is such an explosive combination that I stopped reading these line of scope threads many months ago. :palm:
-
No, I won't take on that. I know practically nothing about the Linux OS family.
You don't have to do anything related to Linux, GNU or things like that. I already did drivers for Rigol IC's, AFG and FPGA (communication with FPGA is done with XDMA driver from Xilinx as in original Rigol firmware, I just fixed PCIE driver which is used here). All of them works correctly. It's all about reading and writing into files created by the drivers (in Linux everything is a file). Touchscreen also works correctly.
Only one problem is to use some graphical library (GDK or anything) and reverse engineering of that .so library from Rigol.
-
Deep respect for your work! I hope Rigol take your work and learn how things could be better.
Rigol + Android is such an explosive combination that I stopped reading these line of scope threads many months ago. :palm:
I think they don't care and they outsources software development.
-
Hi All,
I designed and printed this bracket that allows 2 of these VESA100 Rigol devices to be mounted together on one mount. Its been working quite nicely.
Have a look at https://www.printables.com/model/1147959-dual-rigol-vesa-whandle (https://www.printables.com/model/1147959-dual-rigol-vesa-whandle)
I hope others find it useful.
-
I think they don't care and they outsources software development.
Sure, but I think this is done to passer-by guys. Not to what we could call a developer team.
-
You don't have to do anything related to Linux, GNU or things like that.
But isn't it this library that requires revision precisely because of the different OS? Or does it need to be modified for another reason?
-
Only app. You don't need to modify system. All drivers are ready to go, as I said previously.
Currently Im working to run container (lxc) with original app to listen to calls to the libs and drivers. Because otherwise I will need to constantly switch SD cards...
-
rk3399_rigol:/ # reboot now
Just reboot (without now) should work. On this scope I suggest to do sync (command) before reboot (because of hard reset).
...says the guy who called me out for adding sync to a script.
-
Hello!
I'm not a programmer, and I don't understand Linux, Android, or even Windows very well.
I noticed that displaying the time in the bottom right corner of the oscilloscope screen caused an issue. I don't have a suggestion for fixing it, but I can share how I managed to display the clock.
When I received my oscilloscope months ago, I read on this forum that it was possible to display the current date and time, unfortunately in the Shanghai time zone.
AndyBig mentioned that this works and the time zone can be changed, but others complained that their oscilloscope froze. I trusted AndyBig and modified the time zone in the start_rigol_app.sh file, but foolishly I used the Note++ program for this. The result was a half-bricked oscilloscope. Fortunately, I had made a backup of the SD card beforehand, so I was able to restore the oscilloscope.
After this, I continued searching and even asked ChatGPT. Eventually, I solved the issue of displaying the current time using these instructions, and it has been working flawlessly ever since. AndyBig was right.
(with my own time zone)
adb shell
su -
cd /rigol/shell
sed -i 's?setprop persist.sys.timezone Asia/Shanghai?setprop persist.sys.timezone Europe/Budapest?' start_rigol_app.sh
sed -i '/insmod \/rigol\/driver\/focaltech_ts.ko/a \necho ":DIS:CLOC 1" |toybox nc -q 2 localhost 5555\nsleep 5' start_rigol_app.sh
-
Using sed to edit two lines in one script and only once, sounds crazy. sed is more like for automation, when You have 1000 files and You need to change one line in every of them.
-
Using sed to edit two lines in one script and only once, sounds crazy. sed is more like for automation, when You have 1000 files and You need to change one line in every of them.
It's clever actually, no risk of messing with the line endings or the file permissions, non interactive and less error prone.
-
Windows user? Personally I cant recall problems with line endings.
-
Using sed to edit two lines in one script and only once, sounds crazy. sed is more like for automation, when You have 1000 files and You need to change one line in every of them.
This comes right after a whole series of posts where somebody messed up their 'scope by trying to edit that same file... :palm:
sed means any non-linux person can copy/paste those two lines and do it safely.
-
Using sed to edit two lines in one script and only once, sounds crazy. sed is more like for automation, when You have 1000 files and You need to change one line in every of them.
It's clever actually, no risk of messing with the line endings or the file permissions, non interactive and less error prone.
And also no requirement to have a text editor on the target system, and often if there is one, it's none other than vi (not even vim), which is next to useless to anyone who is not an alien from an outer space.
Sed is a great tool which works fine and is a natural choice in such situations.
-
Using sed to edit two lines in one script and only once, sounds crazy. sed is more like for automation, when You have 1000 files and You need to change one line in every of them.
It's clever actually, no risk of messing with the line endings or the file permissions, non interactive and less error prone.
And also no requirement to have a text editor on the target system, and often if there is one, it's none other than vi (not even vim), which is next to useless to anyone who is not an alien from an outer space.
Sed is a great tool which works fine and is a natural choice in such situations.
Vi is good enough on this scope to do a simple editing. Personally I prefer nano, because of muscle memory with shortcuts.
Also, there is sshfs which makes possible to use any editor (and any software like file browsing) that You want, because You can mount scope file system via network. All You need is ip address, login and password. Right now Im using Krusader, which can use sshfs without need to call mount - external software (executed from Krusader) in 99.9% cases takes ip and credentials, so I don't need to worry about anything.
-
Vi is good enough on this scope to do a simple editing.
Sure, so long as you grew up using it.
If you never used it you'll fail to do anything with vi.
-
Vi is good enough on this scope to do a simple editing.
Sure, so long as you grew up using it.
If you never used it you'll fail to do anything with vi.
RTFM is good enough. 5 minutes of basic usage and You are good to go. Being too much lazy is not helpful.
-
sed means any non-linux person can copy/paste those two lines and do it safely.
Yep. Notably, GNU 'sed -i' –– the one used in the Rigol –– uses the safe modification pattern, where the output is saved to a new file in the same directory under name starting with .sed, then closed, and if successful thus far, hard-linked over the old file. In all inode-based filesystems, this is the correct, safe pattern. (The only thing one might ask is for an option to do a fsync() after closing the new file before the hardlinking.)
For non-Linux/non-command line users, I recommend nano (nano-editor.org (https://nano-editor.org/)) for modifying files by hand. It is controlled via Ctrl+Key, and the main commands shown at the bottom of the screen, with Ctrl represented by ^ as is common in Unix/POSIX-land. If the distro contains a full installation, it even has syntax highlighting. It's no vi or emacs, but it is simpler, more lightweight, and newbie-frendly: a ten second explanation suffices to get users going (^ = Ctrl key, commands are Ctrl+key, press Ctrl+G for help). However, I do not know whether it is included in the Rigol installation.
-
However, I do not know whether it is included in the Rigol installation.
The nano command is not recognized in the oscilloscope command line.
-
I've been using vi for years. I can't figure out how to exit it.
https://unix.stackexchange.com/questions/3334/how-do-i-quit-from-vi
-
I've been using vi for years. I can't figure out how to exit it.
https://unix.stackexchange.com/questions/3334/how-do-i-quit-from-vi
"SHIFT-ZZ" if you want to write the changes.
":Q!" if you don't.
(Obviously! :) )
-
I've been using vi for years. I can't figure out how to exit it.
https://unix.stackexchange.com/questions/3334/how-do-i-quit-from-vi
"SHIFT-ZZ" if you want to write the changes.
":Q!" if you don't.
(Obviously! :) )
... but with a lower-case «q» ;)
-
OK, I bricked my DH0804.
[attach=1]
The rigol.scope app keeps stopping or stops (both messages I get). I think it's in a state that needs to be reset. But how? I can still access it by adb, so I probably need to "clean" some state. A factory default would be ok.
It happened while I was sending SCPI commands to set the instrument in a certain state.
-
@TheoB: Did you try adb logcat?
-
Now I did, see attachment. It's gzipped, but I had to rename the extension to zip to upload...
My next try would be to reset the app using
adb shell pm clear com.rigol.scope
I just want some advice before I do this and make things worse.
I have made a complete backup of /rigol/data when the scope was new. So I have a backup.
-
..I have made a complete backup of /rigol/data when the scope was new. So I have a backup.
How you did it? Via the adb somehow? (A high time to do it here as well :o )
-
adb pull /rigol/
-
Fixed it :phew:
I send this command to the scope:
:SYSTem:PON DEFaultand rebooted
https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-1-03/msg5636739/#msg5636739 (https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-1-03/msg5636739/#msg5636739)
I also reset the data of the app, but I think it did not help (the rigol app kept restarting, but I did not reboot..)
adb shell am start -a android.settings.SETTINGSThen goto Apps, select RIGOL_SCOPE, Storage, Clear Data
All credits go to @mrisco
-
Is the demo available for download/testing?
-
I've put my project of a modified application on Github in more or less order :)
https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod
-
Thanks!
I've put my project of a modified application on Github in more or less order :)
https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod
-
I think there is a small thing to be desired: The actual version of theminstalled mod is not displayed in the splash screen; see the image.
Could you add in the start menu (next to power) a user customisable button (would love to start the FFT_avg application
from mrisco (https://www.eevblog.com/forum/profile/?u=626612) in that way).
Thanks!
I've put my project of a modified application on Github in more or less order :)
https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod (https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod)
-
I think there is a small thing to be desired: The actual version of theminstalled mod is not displayed in the splash screen; see the image.
I deliberately did not put a specific version number, but left XXX instead. Just so as not to redo the picture every time :) The version number can be seen in the Uitlity -> About menu, there the modification version number will be indicated before the firmware version, for example (a003)00.01.04.00.02.
Could you add in the start menu (next to power) a user customisable button (would love to start the FFT_avg application
from mrisco (https://www.eevblog.com/forum/profile/?u=626612) in that way).
Honestly, I can't imagine how to make it customizable. But even if it is somehow done, you will still need an external keyboard to switch between applications. And having a keyboard, you can do whatever you want without additional buttons in the application :)
-
If you need custom buttons for your DHO800/900 series scope, you can easily do so. The cheap RISC-V microcontrollers with native USB from WCH and others are well suited for custom USB HID devices, and automagically supported in Android (due to Android using the Linux input subsystem), no drivers needed, and you can combine keyboard, mouse, and trackpad/touch in the same HID device without any issues. Development is particularly easy if you have a Linux workstation to work on, both toolchain-wise and because you'll have the same input subsystem to test and examine your minikeypad device on.
(My first actual microcontroller project was a Teensy 2.0++ Arcade controller plank –– well, Baltic Birch 75×25cm glulam board –– so I could play puzzle platformer Flash games online with a nice arcade stick and microswitch buttons. Those Flash games – and web games in general, still - tend to use various keyboard controls, so I added a hexadecimal encoder to select between various layouts, key events each button and digital joystick direction would generate. Love it; I'm tempted to make a desktop cabinet around an old 24" 1920×1080 IPS display I have, and one of my Linux SBCs.)
-
Honestly, I can't imagine how to make it customizable. But even if it is somehow done, you will still need an external keyboard to switch between applications. And having a keyboard, you can do whatever you want without additional buttons in the application :)
I deliberately did not put a specific version number, but left XXX instead. Just so as not to redo the picture every time :) The version number can be seen in the Uitlity -> About menu, there the modification version number will be indicated before the firmware version, for example (a003)00.01.04.00.02.
Could you add in the start menu (next to power) a user customisable button (would love to start the FFT_avg application
from mrisco (https://www.eevblog.com/forum/profile/?u=626612) in that way).
Honestly, I can't imagine how to make it customizable. But even if it is somehow done, you will still need an external keyboard to switch between applications. And having a keyboard, you can do whatever you want without additional buttons in the application :)
-
That is a possibilty, but I was looking for a software only implementation.
If you need custom buttons for your DHO800/900 series scope, you can easily do so. The cheap RISC-V microcontrollers with native USB from WCH and others are well suited for custom USB HID devices, and automagically supported in Android (due to Android using the Linux input subsystem), no drivers needed, and you can combine keyboard, mouse, and trackpad/touch in the same HID device without any issues. Development is particularly easy if you have a Linux workstation to work on, both toolchain-wise and because you'll have the same input subsystem to test and examine your minikeypad device on.
(My first actual microcontroller project was a Teensy 2.0++ Arcade controller plank –– well, Baltic Birch 75×25cm glulam board –– so I could play puzzle platformer Flash games online with a nice arcade stick and microswitch buttons. Those Flash games – and web games in general, still - tend to use various keyboard controls, so I added a hexadecimal encoder to select between various layouts, key events each button and digital joystick direction would generate. Love it; I'm tempted to make a desktop cabinet around an old 24" 1920×1080 IPS display I have, and one of my Linux SBCs.)
-
If you need custom buttons for your DHO800/900 series scope, you can easily do so. The cheap RISC-V microcontrollers with native USB from WCH and others are well suited for custom USB HID devices
It's much easier to buy a ready-made solution like this - https://aliexpress.ru/item/1005005473649108.html :)
A full keyboard plus a trackpad with mouse buttons, all in a miniature wireless design the size of a palm. I use this one.
-
Some people tried to run this scope with fan disconnected and it didn't work when CPU get some temp like 60-70 °C.
Right now I reached 69 °C (almost full CPU load, but PLL is not working, so practically there is no heat from FPGA, DAC and AFE).
-
I updated the modified application a little.
The panel with measurements is now without a background and all items in it are pressed down. This allows you to see the oscillogram better when only 3-4 measurements are active.
And I disabled the vertical scale jumping from left to right and back when opening and closing the measurement panel, it was confusing. Now the scale is always on the left.
https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod/releases/tag/a004_00.01.04.00.02
-
AndyBig, don't do this changes so quick, because we soon will be competition for Rigol with our own scopes made from scratch :)
Anyway, good idea. Looks very useful to me.
-
works perfectly, many, many thanks.
-
The panel with measurements is now without a background and all items in it are pressed down. This allows you to see the oscillogram better when only 3-4 measurements are active.
Very nice. Maybe you could push the measurements up by a few pixels to avoid overlapping the time scale.
-
Another suggestion for the measurements: what about removing the channel indication "(C1)" and instead painting the label (Vmin, Vmax, etc) in the color of the channel? That would save a few pixels horizontally. Also the down arrow could be moved to the same line as the text, that would reduce the height of each measurement.
-
AndyBig, don't do this changes so quick, because we soon will be competition for Rigol with our own scopes made from scratch :)
:D :D
Very nice. Maybe you could push the measurements up by a few pixels to avoid overlapping the time scale.
Do you mean to raise the measurements so that this area does not overlap the readings on the time scale?
[attach=1]
Another suggestion for the measurements: what about removing the channel indication "(C1)" and instead painting the label (Vmin, Vmax, etc) in the color of the channel? That would save a few pixels horizontally. Also the down arrow could be moved to the same line as the text, that would reduce the height of each measurement.
Yes, coloring the dimension name and removing the channel name is a good idea, I'll try to implement it.
Regarding the arrow - I was actually thinking about removing it from the collapsed items. Now the item is expanded by tapping on the right side of the item, it is not necessary to aim at the arrow. But in the expanded dimension, I was thinking of leaving the arrow for collapsing.
-
Do you mean to raise the measurements so that this area does not overlap the readings on the time scale?
Yes
Regarding the arrow - I was actually thinking about removing it from the collapsed items. Now the item is expanded by tapping on the right side of the item, it is not necessary to aim at the arrow.
Good idea
But in the expanded dimension, I was thinking of leaving the arrow for collapsing.
You could remove it as well, once it's understood that tapping expands/collapses the items the arrow becomes useless.
-
Regarding removing channels from measurement result headers and coloring the headers in channel colors.
In single-channel measurements, this looks fine, as in the top item on the screenshot. But what about measurements involving two channels, as in the bottom item on the screenshot? Color the parameters as in the middle item? Won't this make it difficult to quickly read the results?
[attachimg=1]
You could remove it as well, once it's understood that tapping expands/collapses the items the arrow becomes useless.
In the expanded item, you still need to designate the area that you click to collapse :) Besides, the size of the expanded item is already quite large, an extra 5 pixels will not play a big role.
-
Could you keep the channel text in white and underline it with a coloured bar that represents the channels?
As for collapsing/expanding, could we agree on that the right area of a measurement item is for collapsing/expanding I think the arrow can be removed.
Without an arrow, the looks are cleaner also when you take a screen capture.
Regarding removing channels from measurement result headers and coloring the headers in channel colors.
In single-channel measurements, this looks fine, as in the top item on the screenshot. But what about measurements involving two channels, as in the bottom item on the screenshot? Color the parameters as in the middle item? Won't this make it difficult to quickly read the results?
[attachimg=1]
You could remove it as well, once it's understood that tapping expands/collapses the items the arrow becomes useless.
In the expanded item, you still need to designate the area that you click to collapse :) Besides, the size of the expanded item is already quite large, an extra 5 pixels will not play a big role.
-
Quote from: Fungus on 09 February 2024, 06:09:09 (https://www.eevblog.com/forum/index.php?topic=393928.msg5324756#msg5324756)
(I use WinSCP to access the files on the 'scope)
What Login/Password did you use?
-
Well, in principle, it can be read quite well on the oscilloscope screen.
-
This arrow gets half of the vertical space.
-
Could you keep the channel text in white and underline it with a coloured bar that represents the channels?
Probably yes, but it won't solve the problem with channel designations in two-channel measurements.
As for collapsing/expanding, could we agree on that the right area of a measurement item is for collapsing/expanding I think the arrow can be removed.
Without an arrow, the looks are cleaner also when you take a screen capture.
In the expanded measurement item, to collapse it, you need to click not just on the right, but on the bottom right. Therefore, it seems to me that it is better to leave the arrow in the expanded item :)
This arrow gets half of the vertical space.
Yes, but you shouldn't make them too narrow either, otherwise it will be difficult to hit the element with your finger :)
-
These are probably the minimum sizes of measurement elements that still retain fairly easy readability.
-
(I use WinSCP to access the files on the 'scope)
What Login/Password did you use?
I just put my initials and no password
-
FTP not interesting.
MyPhoneExplorer does it much comfortable.
-
Some time ago I did automatic downloader for FTP in this scope, to periodically download new files. However it was written in "ugly and old" PHP language:
https://github.com/norbertkiszka/Sync-new-files-from-FTP
Why I have to download it manually every time, when I can make some 5 minute code?
-
I think I have navigated the mega jargon bomb of this thread. Maybe.
I still cant figure out the meaning of " Send the DHO900-BODE and DHO900-BW15T25 options from those generated in step 3 via the SCPI interface".
I can see how to create these files.
What does 'send' mean in this context and how do i do it?
What happens if it all goes pearshsped. Will I brick my scope?
-
Connect your scope to your lan network. Enter the IP address in your browser and you will see the LXI interface. There you can send SCPI commands (and control the scope remotely or make screenshots.
-
Everyone sings their own song
-
Added text outline to channel labels for better readability against a dense signal background.
The screenshot shows before/after.
-
Very nice. Maybe you could push the measurements up by a few pixels to avoid overlapping the time scale.
Another suggestion for the measurements: what about removing the channel indication "(C1)" and instead painting the label (Vmin, Vmax, etc) in the color of the channel? That would save a few pixels horizontally. Also the down arrow could be moved to the same line as the text, that would reduce the height of each measurement.
I did everything according to your suggestions, they were good ideas, thank you :) Only in two-channel measurements I had to change the letters to capital letters in the measurement types ((f-f), (f-r), etc.) so that their color would be more visible. And the letters themselves are now easier to read.
-
One thing to keep in mind when using only color to indicate something is how that might affect color blind people.
-
I did everything according to your suggestions, they were good ideas, thank you :) Only in two-channel measurements I had to change the letters to capital letters in the measurement types ((f-f), (f-r), etc.) so that their color would be more visible. And the letters themselves are now easier to read.
It looks nice, thank you for implementing this. There is just a contrast issue with the CH4 dark blue on the grey background.
Did you try to completely remove the background and the rounded border?
-
One thing to keep in mind when using only color to indicate something is how that might affect color blind people.
Excellent point. I completely missed that...
It looks nice, thank you for implementing this. There is just a contrast issue with the CH4 dark blue on the grey background.
Did you try to completely remove the background and the rounded border?
Yes, the color of the fourth channel looks very low-contrast on a semi-transparent background. Here you should not remove the background - then the text will be lost against the background of the signals, but on the contrary - make the background opaque black. On a black background it will be readable normally.
-
Very nice. Maybe you could push the measurements up by a few pixels to avoid overlapping the time scale.
Another suggestion for the measurements: what about removing the channel indication "(C1)" and instead painting the label (Vmin, Vmax, etc) in the color of the channel? That would save a few pixels horizontally. Also the down arrow could be moved to the same line as the text, that would reduce the height of each measurement.
I did everything according to your suggestions, they were good ideas, thank you :) Only in two-channel measurements I had to change the letters to capital letters in the measurement types ((f-f), (f-r), etc.) so that their color would be more visible. And the letters themselves are now easier to read.
I'm sorry if it sounds so harsh: This is a very very bad idea!
Like 20% of the male population, I have a red/green visual impairment. I can hardly distinguish between light green and yellow on a screen, for example, and if it's only a few pixels (as with written text, for example), I even can't tell whether something is red or green.
With the specification C1 ... it is usable, without it is useless.
-
I'm sorry if it sounds so harsh: This is a very very bad idea!
Like 20% of the male population, I have a red/green visual impairment. I can hardly distinguish between light green and yellow on a screen, for example, and if it's only a few pixels (as with written text, for example), I even can't tell whether something is red or green.
With the specification C1 ... it is usable, without it is useless.
Yes, I already understood that. Now I'm thinking about the idea of making a switchable view - a wider panel with channel names, and a narrower one with channels designated only by colors.
-
I was a bit playing. I saw that in fullscreen mode the measurement bleeds into the x-axis. Could that be pumped up a little higher?
-
What we should see as the noise background?
When I terminate ch4, for example, with 50ohm terminator and I look at the noise I see 340uVpp BW OFF, and 225uVpp BW 20MHz, DC at 500kSa/s and 1Mpts (after upgrade to 1.04).
Peak-to-peak is not a very meaningful or comparable metric for Gaussian-like noise because the probability distribution is unbounded. Instead, measure the standard deviation (some scopes call it AC RMS).
BW 20MHz Avg. 39uV AC RMS, drops down to 33uV after some time (due to Avg math?)
BW OFF Avg. 60uV AC RMS, drops down to 50uV after some time (due to Avg math?)
FYI - after the 824 mod:
DC at 500kSa/s and 1Mpts
BW 20MHz Avg. 53.6uV AC RMS
BW OFF Avg. 110uV AC RMS
DC at 500kSa/s and 100kpts
BW 20MHz Avg. 24.7uV AC RMS
BW OFF Avg. 49.7uV AC RMS
-
I was a bit playing. I saw that in fullscreen mode the measurement bleeds into the x-axis. Could that be pumped up a little higher?
Yes, I have already raised the bottom edge of the results above the X-axis. I just haven't posted this updated version yet, I want to resolve the issue with the color coding of the channels in the results, based on the fair comments made here.
-
FYI - after the 824 mod:
DC at 500kSa/s and 1Mpts
BW 20MHz Avg. 53.6uV AC RMS
BW OFF Avg. 110uV AC RMS
DC at 500kSa/s and 100kpts
BW 20MHz Avg. 24.7uV AC RMS
BW OFF Avg. 49.7uV AC RMS
Also 824 mod, input locked by 50 Ohm load.
DC at 500kSa/s and 1Mpts
- BW 20MHz Avg. 23.604uV AC RMS
- BW OFF Avg. 49.453uV AC RMS
DC at 500kSa/s and 100kpts
- BW 20MHz Avg. 23.553uV AC RMS
- BW OFF Avg. 49.433uV AC RMS
-
Isn't your original one the 814?? (mine is 804)..
PS: with 2.50MSa/s and higher (w/ 1Mpts and BW OFF) it is 50uV AC RMS Avg..
Below 2.50MSa/s 90-100uV AC RMS Avg..
The minimum is at 156.25MSa/s - 41.3uV AC RMS..
-
Isn't your original one the 814?? (mine is 804)..
Yes I have the original 814 changed to 824.
PS: with 2.50MSa/s and higher (w/ 1Mpts and BW OFF) it is 50uV AC RMS Avg..
Below 2.50MSa/s 90-100uV AC RMS Avg..
Are you closing the input with a load or a shorted connector?
-
With the 50ohm load (a terminator).
-
Directly at the oscilloscope input, without a probe?
Is the vertical limit 500 mV/div?
-
Sure.. :)
-
I've returned the vendor.bin back to 804 and now I see 72uV/47uV AC RMS (no selfcal yet).. Weird..
It could be some parts degraded during the first 2weeks of operation :) ..
PS: tried with 4 different terminators.. the same RMS..
I will do the selfcal with the 804 and we will see..
BTW I did the mod with "-M DHO824" - hopefully I have not messed up something..
-
Then it's strange, I don't remember anyone reporting such a high level of intrinsic noise. The only assumption left is that something is making noise - either the power supply, or something connected to the oscilloscope (if something is connected), or something near the oscilloscope.
Have you looked at the FFT - are there any peaks that stand out?
-
..I will do the selfcal with the 804 and we will see..
So, I did the selfcal and let it running for some time - the values are now at the level as it were 18days back.. Weird..
-
It could easily be (my bet actually) they are selecting/binning the input AFE/ADC chips (or other components there) on noise and thermal coefficients. For the 804 models they might use the lowest grade.
With higher speeds/BW settings (like when modding to the higher models) the 804 components get noisier and/or more prone to the TC of the various offsets.
Therefore, imho, they allow the 250uV lowest V/div with the higher models (because they use chips/components with the lower noise and less TC). And all looks the same on the pcb of all the models, incl. the values of components.. >:D
PS: you may try an another experiment which may support my suspicion - simply let run the scope for couple of hours and make the selfcal. Then let the scope cool down for a day or so and after the powering it on look at the 500uV range (DC) with 50ohm terminator in the BNC. Look at what the initial offset and noise will be and how it moves/changes with time (as the scope heats up)..
-
Therefore, imho, they allow the 250uV lowest V/div with the higher models (because they use chips/components with the lower noise and less TC).
The physical lowest vertical limit for all models is 1 mV/div. 500 and 200 µV/div is software scaling.
-
Fungus published here an adb script/batch for changing the vendor.bin he is using by clicking on it (off his PC).
Would it be possible to do it directly in the scope (no adb needed)??
-
It could easily be (my bet actually) they are selecting/binning the input AFE/ADC chips (or other components there) on noise and thermal coefficients. For the 804 models they might use the lowest grade.
Hmm... I struggle to imagine Rigol going to that length in a mass-manufacturing process. (Or Siglent for their competing entry-level scopes, for that matter.) Given that they do not even specify the noise in the datasheet, why would they bother?
-
The selection could be ("is") done by the chip manufacturer (or a party which makes the packaging of the dies), it may take couple of seconds, full automated. They may do it because their chips are their custom made design and they certainly want increase yield/profitability for any price..
Mind the zillion megatons of fake chips/parts coming from that area via ali/ebay - and they indeed bother to mess with the faking of couple of cents worth parts..
-
Nah. "Binning" is largely a myth.
The percentage of chips that would fit that category ("works at one speed but not another") would be tiny and simply not worth the logistical problem it would create. It's better to improve your process and produce more working chips instead.
They don't manufacture separate batches of each model, they manufacture "working PCBs" and put in different SD cards depending on the incoming orders.
Tests will be pass/fail and the bad chips thrown out.
(dons flame-proof undies).
-
Higher bandwidth always means higher noise. That's just the way it is.
Noise:bandwidth ratio is probably non-linear as you go towards the limits of a device.
-
nb. "Binning" does happen in things like multi-core CPUs where individual cores can be defective and the chip is designed for disabling of individual cores by soldering little configuration resistors to the back of it.
By "speed-grade" though? Not as much as people imagine.
-
Their custom chips were not designed for "1.25GSa/s", sure. They targeted at least 2GSa/s. So they had/have issues with their design or/and technology, thus, imho, they do the binning.
Moreover I doubt the companies like Rigol (a rather small company) might afford itself the selecting of an already populated board like "pass/fail(trashed)".
Anyhow, yes, a higher BW needs a different settings of the AFE and its noise and drift will most probably increase..
-
FYI - my small hw mod.. ;D
-
The physical lowest vertical limit for all models is 1 mV/div. 500 and 200 µV/div is software scaling.
BTW, in Rigol 1054Z, which uses 8-bit ADC, I once tried to enable the 500 uV/div scale. It's interesting the noise at that scale is not higher than at 1 mV/Div. Both the scales use digital zoom and at 500 uV/Div the trace looks more step-like, but the noise level is the same, perhaps due to careful SW processing.
-
BTW, in Rigol 1054Z, which uses 8-bit ADC, I once tried to enable the 500 uV/div scale. It's interesting the noise at that scale is not higher than at 1 mV/Div. Both the scales use digital zoom and at 500 uV/Div the trace looks more step-like, but the noise level is the same, perhaps due to careful SW processing.
If you are referring to the noise quantified in e.g. µV rms, why would it be any different? It's the exact same data, acquired with the same amplification setting. The data are just rendered differently (namely zoomed-in) on the screen.
-
FYI - my small hw mod.. ;D
That's why I don't like that DHOs. This amount of graphics seems appropriate for at least 10" screen. And this external PSU with a mobile phone connector all the way remind user that he's dealing with something very cheap
-
If you are referring to the noise quantified in e.g. µV rms, why would it be any different? It's the exact same data, acquired with the same amplification setting. The data are just rendered differently (namely zoomed-in) on the screen.
Yes it's rendered differently. If you simply increased the zoom level, the noise would be increased proportionally, which is not the case
-
Oke + again, thanks.
...
Yes, I have already raised the bottom edge of the results above the X-axis. I just haven't posted this updated version yet, I want to resolve the issue with the color coding of the channels in the results, based on the fair comments made here.
-
If you are referring to the noise quantified in e.g. µV rms, why would it be any different? It's the exact same data, acquired with the same amplification setting. The data are just rendered differently (namely zoomed-in) on the screen.
Yes it's rendered differently. If you simply increased the zoom level, the noise would be increased proportionally, which is not the case
We seem to have our wires crossed here. My take is: Say the physical amplifier setting 1 mV/div and there is an RMS noise of 50 µV on the acquired signal. If you now enable zoom in software to go to 500 µV/div, it will still be 50 µV RMS noise -- it will just be shown larger on the screen.
Are you contradicting the above and think that clever filtering is required to keep the noise at 50 µV? Or are you saying that the noise does not become visually larger on the screen, and that its µV RMS value is actually getting lower as you zoom in?
-
Is it possible to extend FFT?
-
What we should see as the noise background?
When I terminate ch4, for example, with 50ohm terminator and I look at the noise I see 340uVpp BW OFF, and 225uVpp BW 20MHz, DC at 500kSa/s and 1Mpts (after upgrade to 1.04).
Peak-to-peak is not a very meaningful or comparable metric for Gaussian-like noise because the probability distribution is unbounded. Instead, measure the standard deviation (some scopes call it AC RMS).
BW 20MHz Avg. 39uV AC RMS, drops down to 33uV after some time (due to Avg math?)
BW OFF Avg. 60uV AC RMS, drops down to 50uV after some time (due to Avg math?)
FYI - after the 824 mod:
DC at 500kSa/s and 1Mpts
BW 20MHz Avg. 53.6uV AC RMS
BW OFF Avg. 110uV AC RMS
DC at 500kSa/s and 100kpts
BW 20MHz Avg. 24.7uV AC RMS
BW OFF Avg. 49.7uV AC RMS
The noise is mostly from the lower frequencies:
[attachimg=1]
The scope measures 52.2uV rms.
Below 4MHz noise is dominated by 1/f (flicker) noise. Above that the noisefloor of my scope is -170dBV/sqrt(Hz) at 1mV/div all the way to about 250MHz (BW limit as I upgraded from DHO804 to DHO924 thanks to all the kind hackers on this forum :-+).
Lower vertical settings does not matter as it's only display scaling. The bandwidth becomes limited to 20MHz if 200uV/div is selected. That's what I show on the right.
The noise is measured with a brickwall/boxcar filter using dho-remote (https://github.com/tband/dho-remote)
Here I captured the noise all the way down to 1.25Hz:
[attachimg=2]
Termination with 50 Ohm (left) only matters for the flicker noise. Above a few MHz the white noise is the same.
This second plot suffers from noise folding. All 250MHz bandwidth noise is folded to 625kHz which makes the noise increase by 26dB (in case someone wonders why the noise traces do not match ^-^).
If you see changes then I would not be surprised that it is caused by the lower end of the spectrum below 4MHz. That's the part that is not very well under control in semiconductors. The noise is believed to come from semiconductor interface traps. And from experience I know that that noise can be much higher just for some samples. A manufacturer could select on that, but that's more for the higher tier brands.
-
PS: you may try an another experiment which may support my suspicion - simply let run the scope for couple of hours and make the selfcal. Then let the scope cool down for a day or so and after the powering it on look at the 500uV range (DC) with 50ohm terminator in the BNC. Look at what the initial offset and noise will be and how it moves/changes with time (as the scope heats up)..
I did the following experiment.
The oscilloscope worked for about 4 hours, after which I calibrated it and immediately measured the noise level:
DC at 500kSa/s and 1Mpts
- BW 20MHz Avg. 22.597 uV AC RMS
- BW OFF Avg. 48.554 uV AC RMS
DC at 500kSa/s and 100kpts
- BW 20MHz Avg. 22.546 uV AC RMS
- BW OFF Avg. 48.580 uV AC RMS
After that, I turned off the oscilloscope for about 5 hours. After turning it on, I immediately measured the noise level:
DC at 500kSa/s and 1Mpts
- BW 20MHz Avg. 22.819 uV AC RMS
- BW OFF Avg. 48.190 uV AC RMS
DC at 500kSa/s and 100kpts
- BW 20MHz Avg. 22.554 uV AC RMS
- BW OFF Avg. 47.472 uV AC RMS
I left the oscilloscope turned on for about 2 hours and measured the noise again:
DC at 500kSa/s and 1Mpts
- BW 20MHz Avg. 22.736 uV AC RMS
- BW OFF Avg. 48.686 uV AC RMS
DC at 500kSa/s and 100kpts
- BW 20MHz Avg. 22.484 uV AC RMS
- BW OFF Avg. 48.592 uV AC RMS
Do you disable ROLL in horizontal scanning? Or does your scanning automatically switch to ROLL at 1Mpts?
-
All my previous measurements were made with "WAVEFORM VIEW(ROLL), and it was rolling, indeed.
It set itself automatically in that rolling mode.
With manually set "WAVEFORM VIEW" the situation is as follows:
500kSa/s, 1Mpts, none averaging, DC
BW OFF 37.2uV Avg. AC.RMS
BW 20MHz 24.3uV Avg. AC.RMS
500kSa/s, 100kpts, none averaging, DC
BW OFF 37.1uV Avg. AC.RMS
BW 20MHz 24.2uV Avg. AC.RMS
-
All my previous measurements were made with "WAVEFORM VIEW(ROLL), and it was rolling, indeed.
It set itself automatically in that rolling mode.
With manually set "WAVEFORM VIEW" the situation is as follows:
500kSa/s, 1Mpts, none averaging, DC
BW OFF 37.2uV Avg. AC.RMS
BW 20MHz 24.3uV Avg. AC.RMS
500kSa/s, 100kpts, none averaging, DC
BW OFF 37.1uV Avg. AC.RMS
BW 20MHz 24.2uV Avg. AC.RMS
Well, that's a completely different matter :)
-
..Well, that's a completely different matter :)
I've asked DeepSeek on the typical noise floor of today's oscilloscopes (with 50ohm termination), and, within its reasoning he/she/it mentioned EEVBLOG:
Wait, another approach: check the EEVblog forum or similar resources. From what I remember, Dave Jones mentioned that a typical 1 GHz scope might have around 1 mVrms noise when terminated in 50Ω.
Cool thing the DS.. ;D
-
..Well, that's a completely different matter :)
I've asked DeepSeek on the typical noise floor of today's oscilloscopes (with 50ohm termination), and, within its reasoning he/she/it mentioned EEVBLOG:
Wait, another approach: check the EEVblog forum or similar resources. From what I remember, Dave Jones mentioned that a typical 1 GHz scope might have around 1 mVrms noise when terminated in 50Ω.
Cool thing the DS.. ;D
Heh, I asked the AI that helps me edit the code (Cursor AI) and here's his answer:
The typical noise level (Vertical Noise) for modern digital oscilloscopes with bandwidth up to 500 MHz is usually in the range of:
- For 8-bit oscilloscopes: 0.5 - 1.0 mV RMS at 1 mV/div setting
- For 10-bit oscilloscopes: 0.15 - 0.3 mV RMS at 1 mV/div setting
- For 12-bit oscilloscopes: 0.05 - 0.1 mV RMS at 1 mV/div setting
For example:
- Rigol DS7054 (500 MHz, 10-bit): ≤ 0.4 mV RMS at 1 mV/div
- Tektronix MSO5 (500 MHz, 12-bit): ≤ 0.1 mV RMS at 1 mV/div
- Keysight DSOX3054T (500 MHz, 8-bit): ≤ 0.8 mV RMS at 1 mV/div
The noise level depends on:
- Vertical resolution (number of bits)
- Input coupling (AC/DC)
- Bandwidth limit settings
- Vertical scale setting
- Probe attenuation
- Environmental conditions
He didn't mention Eevblog, but he did give Rigol as an example :)
-
Now, why the rolling waveview is 2-3x higher rms than the none-rolling? DS told me it is because of a different signal processing of the data off the buffers, or something like that.. ??
PS: btw., the coolest stuff with DS is its DeepThink's reasoning, I like it..
And Dave should be carefull what he says and writes as on that the future Mankind Wisdom will be based >:D
-
I guess at these slow time base settings that enable the rolling display mode, the 1/f noise becomes predominant, hence the slower the timebase setting, the higher the RMS noise to be measured. IMO, it would make good sense to agree on an instrument setup for noise measurement "ranking" to produce comparable results.
-
But the sampling rate and time base in the rolling are the same as with the none-rolling, afaik, at least in our above examples (500kSa/s, 1MPts, 100ms, BW 20MHz)..
At 1mV/div the same - rolling 38.2uV, none-rolling 24.5uV (ac.rms)
Closer into the 1/f area (10kSa/s, 1Mpts, 10s, 1mV/div, BW 20MHz):
rolling 45uV ac.rms, not rolling 24uV ac.rms
-
I have the impression that the measurements are not calculated based on the ADC readings, but on the signal displayed on the screen.
-
Yup, but why are the pictures on the screen fatter with rolling than with none-rolling? :)
-
Yes, you are correct -- I could duplicate that. I attached two screenshots of a noise measurement @100ms/div, "Auto" mem depth, open input on CH1, 50Ohms terminator on CH4. A considerable difference can be ovserved in the measurement (69µV "normal" vs. 118µV "roll mode" at the open input channel). What's peculiar is that the measurements are taken much more quickly in roll mode, i.e. the measurement counter is running at a much higher speed. I assume that in normal mode, the measurement is taken only after a complete trace has been recorded (makes sense...) while in roll mode, maybe a measurement is taken everytime a division has been filled (assumption based on the measurement counter speed).
Anyway, still approximately the same RMS noise should be measured, the result in "normal mode" should rather be slightly higher due to the broader measurement window and lower frequency 1/f component that should contribute to the reading. When zooming in on the stopped trace, both normal and roll mode traces look pretty much similar, there's no hint that a different acquisition mode may lead to the contradicting results.
I guess Rigol messed soemthing up here and you found a real bug in the measurement "engine". The question arises, if this roll mode measurement is buggy, how reliable are the others? :-//
-
Would be interesting to compare it with other similar scopes..
-
Heh, I asked the AI that helps me edit the code (Cursor AI) and here's his answer:
For example:
- Rigol DS7054 (500 MHz, 10-bit): ≤ 0.4 mV RMS at 1 mV/div
- Tektronix MSO5 (500 MHz, 12-bit): ≤ 0.1 mV RMS at 1 mV/div
- Keysight DSOX3054T (500 MHz, 8-bit): ≤ 0.8 mV RMS at 1 mV/div
He didn't mention Eevblog, but he did give Rigol as an example :)
Now if only the data the AI gave you had some connection with reality...
There is no published noise spec for the Rigol, and I could not find any numbers during a quick search -- hence no idea where that number came from. Tektronix and Keysight do publish specs, and they differ from the AI data: The Tek MSO5 is worse than claimed, 0.2 mV RMS noise at 500 GHz, 50 Ohms, in High-Res mode -- presumably even worse without High-Res. In contrast, the Keysight is better than stated, specified at 0.3 mV RMS for 1 GHz bandwidth.
Which AI did you use -- ChatGPT, trying to please its users as usual, by never admitting that it doesn't know an answer? ::)
-
Which AI did you use -- ChatGPT, trying to please its users as usual, by never admitting that it doesn't know an answer? ::)
I used claude-3.5-sonnet. Although all AIs are capable of generating nonsense when they don't know the answer :))
-
FYI - here is the thinking and the answer of DS/DT to my Q re the roll vs. none-roll waveview noise difference.. :D
-
FYI - here is the thinking and the answer of DS/DT to my Q re the roll vs. none-roll waveview noise difference.. :D
It's interesting to read his reasoning, but in the end it's clear that nothing is clear :))
-
I think I've solved the problem with displaying channels in measurements. For people who have difficulty distinguishing colors, you can enable the mode with displaying channel names (this is the default mode after turning on the oscilloscope). And those who distinguish colors well and want to reduce the width of the measurement panel can switch to color coding of results, without channel names. Switching between these two modes is done in the standard menu, which is called by clicking on the measurement item. I just added another item to the end of this menu to switch between names and colors.
I also darkened the background a little and made it less transparent so that the blue color of the fourth channel is readable on it.
https://youtu.be/Jm-stwADROI
-
This is coming nicely together, Andy, thanks for your continuing effort.
Maybe it is a personal thing, but I don't like the space between the measurement items where the signals peep through.
Is it possible to have one 'block' and each item separated by a gray line?
-
I'ld also like to express my respect and gratitude for this amazing effort of yours, Andy! IMO it's very generous to offer such an extensive job to the public free of charge.
I don't know how others think about it, but since a long time I disliked the seven-segment style font of the hardware frequency counter function. Do you think it's possible to replace that font with something that better blends in with the other U/I typefaces? I experimented with replacing the "digital_numbers.ttf" font directly on the scope with some sans serif font under the same name but didn't succeed.
Moreover, IMO it would be a substantial improvement if it's possible to detach the frquency counter window from the other measurements and place it arbitrarily on the screen, independent of the "result" box.
Thanks so much and all the best,
Thomas
-
I don't know how others think about it, but since a long time I disliked the seven-segment style font of the hardware frequency counter function. Do you think it's possible to replace that font with something that better blends in with the other U/I typefaces?
That said, though, it should be visually different in some way, because, unlike other measurements that involve, so to speak, postprocessing, frequency counter is special, because it comes raw from a deeper level, probably the zero crossing detector or something like that.
Moreover, IMO it would be a substantial improvement if it's possible to detach the frquency counter window from the other measurements and place it arbitrarily on the screen, independent of the "result" box.
Yes!
-
This is coming nicely together, Andy, thanks for your continuing effort.
Maybe it is a personal thing, but I don't like the space between the measurement items where the signals peep through.
Is it possible to have one 'block' and each item separated by a gray line?
Thank you! Yes, I myself am struck by this gap between the elements of the measurement results. I will probably really try to increase the height of the elements a little due to these gaps. And I will outline each element with a gray line. Or there will be only one line at the bottom of the element, I will have to see how it will look better.
But this is in the next version, and for now I am posting the release with the current changes - https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod/releases/tag/a005_00.01.04.00.02
I'ld also like to express my respect and gratitude for this amazing effort of yours, Andy! IMO it's very generous to offer such an extensive job to the public free of charge.
Thank you! Well, I don't refuse voluntary donations :)) True, they are only possible within my country... But for a monthly subscription to the AI in VS Code, which helps me modify the application, donations have already accumulated :)))
I don't know how others think about it, but since a long time I disliked the seven-segment style font of the hardware frequency counter function. Do you think it's possible to replace that font with something that better blends in with the other U/I typefaces? I experimented with replacing the "digital_numbers.ttf" font directly on the scope with some sans serif font under the same name but didn't succeed.
I think that replacing the font is not a big problem. But honestly, I don't see anything bad in the current segment font. A kind of analogue of a meter with the appropriate stylization :)
Moreover, IMO it would be a substantial improvement if it's possible to detach the frquency counter window from the other measurements and place it arbitrarily on the screen, independent of the "result" box.
Thanks so much and all the best,
Thomas
This, I think, will be quite difficult to do, although theoretically possible. I'm not sure I can implement it :(
-
While I wait for my 804, it should arrive next week, I remain more and more positively impressed by the work of some members.
👏👏👏👏
-
I would perhaps recommend to start using Andy's github for issuing your suggestions for improvements and/or bugs as well (ie in parallel with the discussion here). Thus he will get all on the same place and organized.
-
Could you elaborate?
Do you make a VS-Code plugin? If so please give a pointer?
Thank you! Well, I don't refuse voluntary donations :)) True, they are only possible within my country... But for a monthly subscription to the AI in VS Code, which helps me modify the application, donations have already accumulated :)))
-
Could you elaborate?
Do you make a VS-Code plugin? If so please give a pointer?
Thank you! Well, I don't refuse voluntary donations :)) True, they are only possible within my country... But for a monthly subscription to the AI in VS Code, which helps me modify the application, donations have already accumulated :)))
No, I use a paid extension for VS Code - Cursor AI. This extension helps a lot to understand the decompiled sources of the oscilloscope application :)
More precisely, this is not an extension for VS Code, but a separate VS Code distribution with integrated AI.
-
Are you referring to Helixform (https://github.com/Helixform/CodeCursor)? or this tool (https://docs.cursor.com/get-started/migrate-from-vscode)?
if so, how can I use this to financially help you?
No, I use a paid extension for VS Code - Cursor AI. This extension helps a lot to understand the decompiled sources of the oscilloscope application :)
More precisely, this is not an extension for VS Code, but a separate VS Code distribution with integrated AI.
-
This might be a silly question - I am running Sparrow05 and just noticed that the timezone is wrong on the display - For the life of me I can't seem to find where to change this?
-
Are you referring to Helixform (https://github.com/Helixform/CodeCursor)? or this tool (https://docs.cursor.com/get-started/migrate-from-vscode)?
if so, how can I use this to financially help you?
No, I use a paid extension for VS Code - Cursor AI. This extension helps a lot to understand the decompiled sources of the oscilloscope application :)
More precisely, this is not an extension for VS Code, but a separate VS Code distribution with integrated AI.
Yes, I'm talking about this tool - https://www.cursor.com/ (https://www.cursor.com/)
Thanks for the offer, I don't need help yet :) But I'll keep your offer in mind, thanks again :)
This might be a silly question - I am running Sparrow05 and just noticed that the timezone is wrong on the display - For the life of me I can't seem to find where to change this?
To do this, you need to edit the oscilloscope startup script. This script is hardcoded to the time of Shanghai, China.
Here is a good tip on how to do this without breaking the oscilloscope - https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5783681/#msg5783681 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5783681/#msg5783681)
-
Hi to all and congratulations for wonderfull job.
I bought dso804 and i would like to add the signal generator for bode plot funcion.
As i see, maybe need to add a small board on the main, someone have some good pics for try to copy it?
Thanks in anvance
Antonio
-
Mentre aspetto il mio 804, dovrebbe arrivare la settimana prossima, rimango sempre più positivamente colpito dal lavoro di alcuni membri. 👏👏👏👏👏
Pure io sono in attesa di consegna
-
Hi to all and congratulations for wonderfull job.
I bought dso804 and i would like to add the signal generator for bode plot funcion.
As i see, maybe need to add a small board on the main, someone have some good pics for try to copy it?
Thanks in anvance
Antonio
There is even a circuit diagram of this generator, reconstructed from the board by one of the users.
-
FYI - here is the thinking and the answer of DS/DT to my Q re the roll vs. none-roll waveview noise difference.. :D
Just out of peculiarity, I did some more tests regarding the roll mode noise issue. First, I compared the normal mode to the roll mode peak-to-peak noise, and -- surprise, surprise -- they are very similar. In fact, noise in normal mode is slightly higher due to the wider measurement window and the correponding bigger effect of the 1/f component, see sttached screenshots.
Then I checked the effect of the roll speed. Once again, I found something unexpected: The slower the timebase is set, the higher the measured AC RMS noise. What's quite surprising is that the update rate of the measurenment counter in roll mode stays at the same speed, regardless of the timebase setting. Provided Rigol doesn't use the complete (screen shadow) memory / screen contents to calculate this figure, but only the newly shifted in data, this means, the number of samples that contribute to the sandard deviation calculation gets smaller, the slower the timebase is running.
Due to the possibly higher "granularity" of the smaller sample count, and since the count is in the denominator of the standard deviation calculation, this may lead to higher "indicated" RMS levels, which may even be mathematically correct. If Rigol always used the full screen contents (or the same window width that's being used in normal mode) for the AC RMS calculation, and not only the newly acquired data subset, this whole problem shouldn't exist. But I'm not a statistician and I'm not completely sure if this take is correct. At least, it seems Rigol somehow messed up the math of RMS / AC RMS measurement in roll mode.
P.S. During this testing episode, I noticed that the choice of the region of a measurement is only globally possible -- I cannot apply a measurement of one channel to the main screen while I apply another measurement of a different channel to the zoom window, the setting will always change for both measurements... I guess the price of this scope implies some disadvantages :-//
-
Mentre aspetto il mio 804, dovrebbe arrivare la settimana prossima, rimango sempre più positivamente colpito dal lavoro di alcuni membri. 👏👏👏👏👏
Pure io sono in attesa di consegna
@Carbedd, @Antgue: You might have noticed that English language is used throughout this forum. When you post here, could you please make the effort and run your text through a translator? That way, you have to do the translation once -- rather than every reader who does not speak Italian (and does not want to ignore you) having to do that for himself. Thanks!
-
FYI - here is the thinking and the answer of DS/DT to my Q re the roll vs. none-roll waveview noise difference.. :D
Just out of peculiarity, I did some more tests regarding the roll mode noise issue.
It would be interesting to test this further by manually capturing and calculating RMS values from exported data at different time bases to see if the discrepancies hold up..
-
Sorry, just done 😇
-
The noise is believed to come from semiconductor interface traps.
If You remove driver module (Linux kernel module, comment out line with insmod spi2afe_gpio.ko) of a AFE (SPI communication with IC in AFE for every channel), noise drops significantly (couple times, I don't remember exact values) - I posted this about month ago. Also I recreated this module from reverse engineering if somebody wants to do some experiments with it (GPL licence, free of charge - Im not same idiot like Rigol company).
Also, If You compare photos of DHO800/DHO900 and DHO4000, it looks like most of noise comes from AFE power supply which is DC/DC converter in case of DHO800/DHO900 and ultra-low noise LDO in case of DHO4000. That's why we have bandwidth limited to 250 MHz. After removing LC filters, bandwidth is increased to above 1 GHz, but noise is quite big - still it's useful, but only when measuring digital signals or with average acquisition enabled. I have plans to do modifications and experiments with it, after I do other things...
There is even a circuit diagram of this generator, reconstructed from the board by one of the users.
There is even working source code with two drivers for this AFG. To be more precise, I did it.
-
There is even working source code with two drivers for this AFG. To be more precise, I did it.
If it's public, it's possible to have some info about it?
I don't find how buy this original "generator board" and i'm evaluating if build it or change my dho804 in dho914s
Many thanks
-
Rigol drivers in kernel 4.4.179: https://github.com/norbertkiszka/rigol-orangerigol-linux_4.4.179/tree/main/drivers/rigol (only most important drivers - to handle input data and AFG).
Rigol drivers in kernel 5.10.209: https://github.com/norbertkiszka/Linux-5.10-Rockchip/tree/develop-5.10/drivers/rigol (as above and without AFE, but with some cleanup in code).
In 4.4.179 touchscreen driver was taken from 5.x.
In 5.10.209 xdma drivers (two versions to chose with Kconfig) was moved into more appropriate location: https://github.com/norbertkiszka/Linux-5.10-Rockchip/tree/develop-5.10/drivers/xilinx/xdma
As I said before, all of it was done by reverse engineering. AFG drivers works correctly for 100% - I even tested it with voltmeter (relays).
Anyway, it looks like only voltage dividers and power on/off is controlled by this two drives, but data is sent by FPGA (in real time), which makes sense, because RK3399 is too slow to handle all channels, measurements and AFG at the same time.
For 99% my project "Orange Rigol" will be moved into kernel 5.10, because it's more efficient and it has more bug fixes. I wonder why Rigol didn't use kernel 5.x... Maybe they were too lazy to work with it (to make changes needed to have fully working RK3399).
-
Many thanks, i'll try it when i'll solved the missing AFG hardware.
Unfortunately i'm expert in hardware, but not in software and maybe i'll disturb you again.
Greetings
-
..If You remove driver module (Linux kernel module, comment out line with insmod spi2afe_gpio.ko) of a AFE (SPI communication with IC in AFE for every channel), noise drops significantly (couple times, I don't remember exact values) - I posted this about month ago. ..
What would be interesting: to start play with "the AFE settings", if available.
What I mean - gentle, incremental changes in some relevant numbers there..
Removing the drivers could be the next step before the replacing of the original OS.. :D
-
..If You remove driver module (Linux kernel module, comment out line with insmod spi2afe_gpio.ko) of a AFE (SPI communication with IC in AFE for every channel), noise drops significantly (couple times, I don't remember exact values) - I posted this about month ago. ..
What would be interesting: to start play with "the AFE settings", if available.
What I mean - gentle, incremental changes in some relevant numbers there..
Removing the drivers could be the next step before the replacing of the original OS.. :D
Those are very simple drivers, both original and my "remake", which is recreation 1:1 (beside of hdcode_gpio driver which is writable in my case). In case of AFE and PLL loop, that two drivers use GPIO pins to emulate SPI bus in one direction only. Created device file (/dev/spi_simulate and /dev/spi_3wires_lxm2582), takes data (every write into that file), "dissasembles" it into every single bit and sends it as it is. If You want to play with AFE, You need to decompile libscope-auklet.so.
In case of PLL, used IC is LXM2582 and datasheet is available (https://www.ti.com/lit/ds/symlink/lmx2582.pdf). To overclock this scope (sample rate), most likely we need to overclock and overvoltage RAM by editing devicetree (decompiled DT can be compiled back as it is). Also heatsink for memory modules is necessary in that case.
-
The DHO8/9 and DHO1000 hardware looks the same, but the DHO1000 is 2GSa/s and the DHO8/9 is only 1.25GSa/s, so it would be nice to switch to 2GSa/s sampling as well
-
The DHO8/9 and DHO1000 hardware looks the same, but the DHO1000 is 2GSa/s and the DHO8/9 is only 1.25GSa/s, so it would be nice to switch to 2GSa/s sampling as well
No, they have different hardware and there is no easy way to increase the sampling rate of 800/900.
-
The DHO8/9 and DHO1000 hardware looks the same, but the DHO1000 is 2GSa/s and the DHO8/9 is only 1.25GSa/s, so it would be nice to switch to 2GSa/s sampling as well
I think 1.4 GSa/s or 1.6 GSa/s is more real limit of overclocking FPGA and DDR3 memory.
-
I think 1.4 GSa/s or 1.6 GSa/s is more real limit of overclocking FPGA and DDR3 memory.
I think that raising the clock of the FPGA even by 10-15% will be problematic.
That is, maybe some oscilloscopes will work, but it is unlikely that it will be stable.
-
The DHO8/9 and DHO1000 hardware looks the same, but the DHO1000 is 2GSa/s and the DHO8/9 is only 1.25GSa/s, so it would be nice to switch to 2GSa/s sampling as well
It's not just the ADCs, it's the FPGA, the RAM, many dozens of places in the firmware that do math based on the sample rate, etc.
-
It is enough that the 1000 and 800/900 have completely different FPGAs. This immediately puts an end to any analogies between these oscilloscope lines.
-
The main reason is that the FPGA configuration has been reduced. thank you
-
Next version will have a docked result panel (can be undocked to the former view) and a surprise I can overcome all obstacles
[attachimg=1]
-
I wonder if it's feasible to make it display the math traces in the main window.
-
I wonder if it's feasible to make it display the math traces in the main window.
I try to do it, but there is a lot of changes to do in the apk and maybe the precompiled binary library draws inside of a window with a predefined id. In other models that is possible, but fight with a binary library may not be worth it.
-
@mrisco and @AndyBig,
Both of you are making this scope so much better, thanks for that.
My question is: are you two joining forces, because I sure would like to see all your great adaptions in one package!
-
I wonder if it's feasible to make it display the math traces in the main window.
I try to do it, but there is a lot of changes to do in the apk and maybe the precompiled binary library draws inside of a window with a predefined id. In other models that is possible, but fight with a binary library may not be worth it.
I think that would be very difficult. You might even need to have the math window open anyway to be able to put the trace in a different window.
-
I could open the window and hide it, but the problem is the trace drawing itself.
-
FYI - 804 modded to 824, no selfcal after mod.
50ohm terminator on CH4.
Waveform view.
BW OFF 49.4uV Avg. AC.RMS (+12uV against 804)
BW 20MHz 24.1uV Avg. AC.RMS (the same as the 804)
-
BW OFF 49.4uV Avg. AC.RMS (+12uV against 804)
Of course, because the bandwidth has expanded almost 3 times :)
-
Yep, the noise looks ok.
The model is 824 and time base 2ns.
BUT - I still see only 25M mem depth and the options - see below.
What went wrong?
vendor.bin generated by -o -M DHO824
-
BUT - I still see only 25M mem depth and the options - see below.
What went wrong?
vendor.bin generated by -o -M DHO824
This is because you have two channels active - channel 2 serves the trigger and channel 4 shows the signal.
-
The same with trigger at the same channel.. 25MB max..
OK, the counter and measurement on a diff channel have to be OFF, and I get 50MB.. ::)
What about the options? Is that ok?
PS: why the counter enabled on a different channel limits the max mem depth ? :o
-
What about the options? Is that ok?
Yes :)
PS: why the counter on a different channel limits the max mem depth ? :o
Any access to the channel puts it into full operation, so it takes both the sampling frequency and memory.
-
My question is: are you two joining forces, because I sure would like to see all your great adaptions in one package!
mrisco and I have incompatible economic models :))
-
PS: why the counter on a different channel limits the max mem depth ? :o
Any access to the channel puts it into full operation, so it takes both the sampling frequency and memory.
Hmm, a weird design.. - their counter looks like a 6digit counter gated by 1sec (perhaps 10 lines in verilog). Has nothing to do with sampling into the mem. Looks like a bug to me..
-
Hmm, a weird design.. - their counter looks like a 6digit counter gated by 1sec (perhaps 10 lines in verilog). Has nothing to do with sampling into the mem. Looks like a bug to me..
It seems to me that all operations on the channel - trigger, counter, measurements, etc. - are carried out programmatically based on the ADC readings accumulated in memory.
I agree that this is not the best solution, but apparently they did it this way to reduce the cost of the oscilloscope.
-
I was afraid of that answer.
So now I have a decision to make ....
My question is: are you two joining forces, because I sure would like to see all your great adaptions in one package!
mrisco and I have incompatible economic models :))
-
FYI - 804 modded to 824, no selfcal after mod.
50ohm terminator on CH4.
Waveform view.
BW OFF 49.4uV Avg. AC.RMS (+12uV against 804)
BW 20MHz 24.1uV Avg. AC.RMS (the same as the 804)
When I see the original interface of the DHO, I wonder what happened in the UI design engineering team to release that result bar layout!
It is not to continue the layout of the other models because, for the DHO1000/4000 series it is different (due to the bigger screen) so it is only laziness to adapt the UI properly to a lower resolution.
Let's see, this is with the stock application:
[attachimg=1]
And this is with the extended layout:
[attachimg=2]
In the promotional pictures of the DHO800 series, the result bar had a better layout and was docked to the right:
(https://www.rigolna.com/images/products/DHO800.jpg)
-
We are attempting to use the DHO814 for Transistor Curve Tracer utilizing the XY Mode. Really like the display that includes the X and Y numeric labels, but can't get the display to show enough brightness in XY mode (we have brightness set to max), it's fine in regular Time Domain mode tho.
The results are very faint as shown.
The setup is an AWG used to sweep (0-8V) the X Axis thru a Resistor (Collector 100Ω) and the DSO CH1 connects to Resistor, the AWG other channel is stair-stepped (8 Steps 0-10V) thru a Resistor (Base 50KΩ). Another Resistor (Emitter 10Ω) and DSO CH2 is connected across this resistor to display Current on the Y Axis.
You can see the Siglent DSO displays the result with good brightness while the DHO814 we can't get to display with sufficient brightness.
BTW wish the Siglent would include the XY display numerics like the Rigol, they are nice :-+
Any help is from the Rigol gurus is appreciated.
Best
-
We are attempting to use the DHO814 for Transistor Curve Tracer utilizing the XY Mode. Really like the display that includes the X and Y numeric labels, but can't get the display to show enough brightness in XY mode (we have brightness set to max), it's fine in regular Time Domain mode tho.
The results are very faint as shown.
Turn up the persistence?
-
First thing we tried, makes no difference in XY Mode, but does work in normal TD Mode?
Best
-
In the promotional pictures of the DHO800 series, the result bar had a better layout and was docked to the right:
Honestly, I like the measurement panel on top of the signal window better. When it doesn't make the signal window shrink :)
-
We are attempting to use the DHO814 for Transistor Curve Tracer utilizing the XY Mode. Really like the display that includes the X and Y numeric labels, but can't get the display to show enough brightness in XY mode (we have brightness set to max), it's fine in regular Time Domain mode tho.
The results are very faint as shown.
The setup is an AWG used to sweep (0-8V) the X Axis thru a Resistor (Collector 100Ω) and the DSO CH1 connects to Resistor, the AWG other channel is stair-stepped (8 Steps 0-10V) thru a Resistor (Base 50KΩ). Another Resistor (Emitter 10Ω) and DSO CH2 is connected across this resistor to display Current on the Y Axis.
You can see the Siglent DSO displays the result with good brightness while the DHO814 we can't get to display with sufficient brightness.
BTW wish the Siglent would include the XY display numerics like the Rigol, they are nice :-+
Any help is from the Rigol gurus is appreciated.
Best
Increase the number of samples/Mem Depth in the horizontal panel. Decrease the horizontal scale in the same panel.
-
Honestly, I like the measurement panel on top of the signal window better. When it doesn't make the signal window shrink :)
I want to be able to see the channels, the XY window, and also some measurements while keeping the graph windows uncovered.
But a floating option that we can move around the screen might be the best option.
-
Increase the number of samples/Mem Depth in the horizontal panel. Decrease the horizontal scale in the same panel.
Thanks, that solved the issue :clap:
Now we have a nice looking IV Plot with axis numerics :)
Best
-
Increase the number of samples/Mem Depth in the horizontal panel. Decrease the horizontal scale in the same panel.
Thanks, that solved the issue :clap:
Now we have a nice looking IV Plot with axis numerics :)
Best
Check this: https://www.innovatefpga.com/cgi-bin/innovate/teams2018.pl?Id=AS033 (https://www.innovatefpga.com/cgi-bin/innovate/teams2018.pl?Id=AS033)
-
Check this: https://www.innovatefpga.com/cgi-bin/innovate/teams2018.pl?Id=AS033 (https://www.innovatefpga.com/cgi-bin/innovate/teams2018.pl?Id=AS033)
We've seen your site before, very nice work :-+
We have a restored Tek 577 for any "serious" Curve Tracer work, and created a few custom fixtures including something for SMD components.
https://www.eevblog.com/forum/repair/old-tek-577-return-to-life-story/msg4479919/#msg4479919 (https://www.eevblog.com/forum/repair/old-tek-577-return-to-life-story/msg4479919/#msg4479919)
https://www.eevblog.com/forum/projects/smd-test-fixture-for-the-tektronix-576-curve-tracer/msg4554053/#msg4554053 (https://www.eevblog.com/forum/projects/smd-test-fixture-for-the-tektronix-576-curve-tracer/msg4554053/#msg4554053)
So our efforts are for more towards a "simple passive" Curve Tracer for use with standard DSO and AWGs which most folks should have available.
We are not that well versed (obviously!!) with the Rigol DHO814 and only use it occasionally, we have a couple Siglent DSOs as our "go too" DSOs.
Best
-
I want to be able to see the channels, the XY window, and also some measurements while keeping the graph windows uncovered.
It's convenient for me when I can expand the measurement window for a short time with one tap, look at the readings in it and collapse it back. And now, when 3-5 measurements take up a small part of the screen at the bottom right, they don't interfere with monitoring the signal that much :)
But a floating option that we can move around the screen might be the best option.
Yes, perhaps this would be the most convenient option.
-
I just got a Rigol DHO804 and am having trouble using ADB to connect to it. When I use the command adb connect <IP>, it says it's connected on the command line, but a 'remote cmd error' pops up on the scope. I was wondering if any of you have encountered this problem before and know of a fix.
-
@Chance: Did you use the correct port number?
adb connect <IP>:55555
-
..So our efforts are for more towards a "simple passive" Curve Tracer for use with standard DSO and AWGs which most folks should have available..
Interestingly this has jumped off YT at me today (6 transistors + DUT):
https://www.youtube.com/watch?v=TCh9FG0GR-E (https://www.youtube.com/watch?v=TCh9FG0GR-E)
https://www.eddybergman.com/2017/06/simple-but-effective-transistor-curve.html (https://www.eddybergman.com/2017/06/simple-but-effective-transistor-curve.html)
1980:
https://archive.org/details/ElektorMagazine/Elektor%5Bnonlinear.ir%5D%201980-09/page/n37/mode/2up (https://archive.org/details/ElektorMagazine/Elektor%5Bnonlinear.ir%5D%201980-09/page/n37/mode/2up)
-
I believe so, 5555 right?
-
five fives..
-
Well I feel like an idiot thank you very much
-
..So our efforts are for more towards a "simple passive" Curve Tracer for use with standard DSO and AWGs which most folks should have available..
Interestingly this has jumped off YT at me today (6 transistors + DUT):
https://www.youtube.com/watch?v=TCh9FG0GR-E (https://www.youtube.com/watch?v=TCh9FG0GR-E)
https://www.eddybergman.com/2017/06/simple-but-effective-transistor-curve.html (https://www.eddybergman.com/2017/06/simple-but-effective-transistor-curve.html)
1980:
https://archive.org/details/ElektorMagazine/Elektor%5Bnonlinear.ir%5D%201980-09/page/n37/mode/2up (https://archive.org/details/ElektorMagazine/Elektor%5Bnonlinear.ir%5D%201980-09/page/n37/mode/2up)
That's a very clever circuit, hats off to Eddy Bergman who apparently created it :clap:
The method we mentioned uses your DSO and AWG and 2 or 3 resistors for the simplest implementation. We can elaborate if anyone is interested, but better to start another thread or add to this thread about such.
https://www.eevblog.com/forum/testgear/fooln-around-with-dso-awg/msg4421209/#msg4421209 (https://www.eevblog.com/forum/testgear/fooln-around-with-dso-awg/msg4421209/#msg4421209)
Best
-
I have a new 914 with firmware 1.03. Are there any updated directions on making it identify as a 924?
-
I have a new 914 with firmware 1.03. Are there any updated directions on making it identify as a 924?
No. The old ones still work.
-
Added a small bottom panel in full-screen mode with information about the channel scale and sampling mode/frequency. It can be inconvenient when you are in full-screen mode and do not see this information.
At the same time, I fixed a couple of small errors in the previous version :)
In the coming days, I will post a new release on GitHub.
-
Added a small bottom panel in full-screen mode with information about the channel scale and sampling mode/frequency. It can be inconvenient when you are in full-screen mode and do not see this information.
Good idea, and maybe the full-screen buttton could be used to cycle through 3 modes: normal, full-screen, full-screen with bottom panel.
-
Added a small bottom panel in full-screen mode with information about the channel scale and sampling mode/frequency. It can be inconvenient when you are in full-screen mode and do not see this information.
Good idea, and maybe the full-screen buttton could be used to cycle through 3 modes: normal, full-screen, full-screen with bottom panel.
Nah, it would be annoying to have to press it twice to get out of fullscreen mode Every Single Time.
-
Good idea, and maybe the full-screen buttton could be used to cycle through 3 modes: normal, full-screen, full-screen with bottom panel.
I agree with Fungus - the triple action of the fullscreen icon will reduce the comfort of using fullscreen mode.
Instead, I would suggest something like a small icon in the window title to show and hide the information panel. Although in my opinion this panel is small enough as it is :)
-
Maybe I'm upping the ambition a bit too much, but could we tap into the rotary encoder? From the starting position, one click forward is fullscreen+panel, and one-click backwards is fullscreen?
That gives:
fullscreen <- start-screen -> fullscreen + panel
fullscreen+panel <- full screen -> startscreen
startscreen <- full screen + panel -> fullscreen
Added a small bottom panel in full-screen mode with information about the channel scale and sampling mode/frequency. It can be inconvenient when you are in full-screen mode and do not see this information.
Good idea, and maybe the full-screen buttton could be used to cycle through 3 modes: normal, full-screen, full-screen with bottom panel.
Nah, it would be annoying to have to press it twice to get out of fullscreen mode Every Single Time.
-
Maybe I'm upping the ambition a bit too much, but could we tap into the rotary encoder? From the starting position, one click forward is fullscreen+panel, and one-click backwards is fullscreen?
But all encoders are busy with other functions. Even encoder "2" is busy when cursors are active.
-
The new release a006 is published on GitHub :)
- the space between measurement points has been reduced
- saving and restoring the appearance of measurement points has been made - specifying channels by names or colors
- a bug has been fixed: the "Change item" item in the measurement points menu did not work
- a bug has been fixed: the signal window did not expand to full screen with the first click on the expansion icon
- in full-screen mode, a small panel has been added at the bottom with information about the sampling mode/frequency and channel scale
- when clicking on the scale value in the information panel in full-screen mode, the channel settings window opens
-
Good idea, and maybe the full-screen buttton could be used to cycle through 3 modes: normal, full-screen, full-screen with bottom panel.
I added a small button to the window title, as I wrote earlier. When you click on it, the information panel below can be hidden and shown. Its state is saved even when you turn off the oscilloscope :)
This will appear in the next version.
-
This is a proof of concept of an editable button panel, the configuration file will be a simple text file in JSON format stored in the user storage space, the panel can have many buttons, it is scrollable and currently supports chained SCPI commands and launching applications.
https://www.youtube.com/watch?v=DVXYwBNYM1Y (https://www.youtube.com/watch?v=DVXYwBNYM1Y)
-
This is a proof of concept of an editable button panel, the configuration file will be a simple text file in JSON format stored in the user storage space, the panel can have many buttons, it is scrollable and currently supports chained SCPI commands and launching applications.
https://www.youtube.com/watch?v=DVXYwBNYM1Y (https://www.youtube.com/watch?v=DVXYwBNYM1Y)
Can the scrollable button panel at top right be edited? It would be cool to be able to just replace it with one or two items that don't have a physical button on the front (eg. "decode").
Or make it into one user-selectable button plus this popup.
(After that we'd want an app to configure the user interface options without editing those pesky JSON files. ;) )
-
(After that we'd want an app to configure the user interface options without editing those pesky JSON files. ;) )
Sorry I'm not an Android programmer so that could be take some time, maybe someone could make something simple like select an application and generate the json and create the image with the application icon.
-
Can the scrollable button panel at top right be edited? It would be cool to be able to just replace it with one or two items that don't have a physical button on the front (eg. "decode").
You can use a chain of SCPI commands to create an specific sequence for decoding a signal and put that sequence in a button in the panel.
:BUS1:MODE SPI /*Sets the decoding type to SPI.*/
Or configure the device and save the settings in a STP file and later recover that file using only one button in the panel like the example in the video.
-
A couple of bugs in the latest version 00.01.04.00.02:
1. Cursor brightness settings are not loaded when the oscilloscope is turned on. If you set their brightness to, for example, 30%, then reboot the oscilloscope, you will see that the cursors have 100% brightness. But as soon as you open the display settings, the cursor brightness will immediately return to the previously set ones.
2. In some trigger modes, the mode icon in the top panel does not correspond to the actual mode. If in the "Timeout" or "Over" mode you set Slope to Arbitrary/Either mode, the icon in the top panel will display the Rising mode.
-
Fixed Rigol's bugs with trigger mode icons and added horizontal scale and trigger mode to the full-screen info panel :)
-
There is the bug with the display brightness as well - it always starts 100%.
-
There is the bug with the display brightness as well - it always starts 100%.
It's hardcoded in /rigol/shell/start_rigol_app.sh
-
Yep, I know, it was handled here in past afaik, but for me - as the user - it is a bug.. When I set it 60% it gets 100% after the restart.. The same: the time zone (enabling time/date), the flattop window coeffs, etc.
So perhaps the experts here may create an "automatic process/script" which will handle all those "bugs".
-
Like this very much. Thanks.
Can some ogf the acquire settings (mode, mem depth) also be added to this bar?
Fixed Rigol's bugs with trigger mode icons and added horizontal scale and trigger mode to the full-screen info panel :)
-
Like this very much. Thanks.
Can some ogf the acquire settings (mode, mem depth) also be added to this bar?
...or on the title bar at the top, next to the graphics that shows you how much you can zoom.
(there's enough numbers at the bottom now to have to scan through to pick one out)
-
Please don't do that.
I agree the little bar is becoming full of numbers, but a logical arrangement (trig status/trig info/Hor info/Acquire info/Channel info) can help.
I often crop the top bar out from the final image: it is not displaying anything helpful (until we can have a user-defined caption instead of the default 'waveform view');
Like this very much. Thanks.
Can some ogf the acquire settings (mode, mem depth) also be added to this bar?
...or on the title bar at the top, next to the graphics that shows you how much you can zoom.
(there's enough numbers at the bottom now to have to scan through to pick one out)
-
I, like mrisco, am not an Android programmer, it is difficult to understand all the nuances of building applications... Today I spent the whole day messing around with the cursor brightness loading error, but I finally defeated it! Now after turning on the oscilloscope, the cursors turn on with the brightness that was set earlier, and not with 100% :)
There is the bug with the display brightness as well - it always starts 100%.
Yes, probably in Rigol they think that the decrease in display brightness is only a temporary phenomenon that lasts until the oscilloscope is turned off :) I have written this down in my task list, maybe I can fix it.
Like this very much. Thanks.
Can some ogf the acquire settings (mode, mem depth) also be added to this bar?
Well, there is still some space in the bottom panel, I think this information should fit. I also added it to my task list.
-
Release of a new version of the modification (a007) - https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod/releases/tag/a007_00.01.04.00.02 :)
- added a button in the window title to open/close the information panel in full-screen mode
- added information about the type (icon) and channel of the trigger to the full-screen information panel
- added information about the horizontal scale to the full-screen information panel
- added information about the channel connection (AC/DC/GND) to the full-screen information panel
- added information about the capture mode and memory depth to the full-screen information panel
- the background of the full-screen information panel has been changed to a darker one
- fixed a Rigol bug: the trigger mode icon in the top panel did not correspond to the selected mode in some cases
- fixed a Rigol bug: after turning on the oscilloscope, the cursor brightness is set to 100%, no matter what its setting is, the brightness is brought to the settings only when the display settings window is opened
-
Release of a new version of the modification (a007) - https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod/releases/tag/a007_00.01.04.00.02 :)
TY for the updates.
Question, after installing your version do we need to re-do the FFT flat-top calibration?
-
Question, after installing your version do we need to re-do the FFT flat-top calibration?
No, no calibrations are lost when updating the mod, and FFT files are not overwritten either :)
-
Yep, I know, it was handled here in past afaik, but for me - as the user - it is a bug.. When I set it 60% it gets 100% after the restart.. The same: the time zone (enabling time/date), the flattop window coeffs, etc.
So perhaps the experts here may create an "automatic process/script" which will handle all those "bugs".
I think I found where this error is - when setting the screen brightness, the new brightness value is sent to be saved to the binary library (almost all parameters and settings are saved through it). But for some reason, when reading the saved brightness value back, the library always returns 100%, no matter what value was saved before.
I think I can fix this bug - you just need to save and read the brightness setting not through the library, but in the standard application storage.
-
What if you set a move complex trigger mode, eg. Serial triggers. Does it all fit? :popcorn:
-
There is the bug with the display brightness as well - it always starts 100%.
I fixed this bug :) Now when you launch the application, the display brightness is set to what was set in the settings.
What if you set a move complex trigger mode, eg. Serial triggers. Does it all fit? :popcorn:
Do you mean will the icon correspond to complex trigger modes? Yes, it will :) Each trigger mode has its own icon, or even several icons depending on the polarity, for example.
Although I've just found one bug - in the "Delay" mode, not all submodes are shown with the correct icon. I'll fix it :)
-
Hello God, I would like to ask a question, that is, how to display the time on the screenshot, in addition, how to set the time, in the case of not networking, the switch will not reset the time, my model is DHO804
-
Hello God, I would like to ask a question, that is, how to display the time on the screenshot, in addition, how to set the time, in the case of not networking, the switch will not reset the time, my model is DHO804
It doesn't have internal clock, nothing you can do without networking.
The setting for "time on screenshots" is this:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/?action=dlattach;attach=2504237;image)
-
In the latest version of a007 I made a serious mistake - when cleaning up the garbage in the sources I accidentally deleted the code for updating the trigger channel in the full-screen info panel. So today I released a new release with a fix for this error. At the same time, this release also includes a fix for the Rigol error with the display brightness setting not being saved.
https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod/releases/tag/a008_00.01.04.00.02
-
Whats going on with this zero? It looks, as it is a bit more than zero. ;D
-
Whats going on with this zero? It looks, as it is a bit more than zero. ;D
Isn't this a screenshot from WebControl? It distorts small details of the image. Especially the original, unmodified one. It has a very compressed video stream bitrate.
-
I have checked this option, but only the word DHO804, there is no time watermark after it. There is no RTC module inside this machine? After shutdown, the time automatically goes back to 2013
-
There is no RTC module inside this machine?
No.
-
i install a008 just now,but my device still show （a007）00.01.01.sp1 >:D
-
i install a008 just now,but my device still show （a007）00.01.01.sp1 >:D
Damn, I forgot to change the version ID |O
-
How does the “Settings” button appear under the Start menu?
-
How does the “Settings” button appear under the Start menu?
That is implemented here:
https://www.youtube.com/watch?v=mT4ivaMY7zg (https://www.youtube.com/watch?v=mT4ivaMY7zg)
-
Thank you very much, but i can't open youtube videos in my area :'( :'( :'(
-
How does the “Settings” button appear under the Start menu?
What settings do you mean? Oscilloscope settings? Or Android settings?
-
it‘s :-DD’“Android setting” :-DD
-
Your software "Sparrow_mod" can add this function, that is, in addition to adding "DHO800" when the screenshot, add the date and time, like this
-
it‘s :-DD’“Android setting” :-DD
Your software "Sparrow_mod" can add this function, that is, in addition to adding "DHO800" when the screenshot, add the date and time, like this
I'll have to check, but most likely the screenshots are taken in the binary library, meaning the app mod can't affect this.
-
Tried to connect DHO804 via WiFi. May someone use wireless connection and can tell should it be so bad?
With such lags Webcontol become almost unusable. :(((
LAN connection works flawlessly.
Attaching a ping window screenshot.
Tested using ping command from Windows command prompt:
ping -t xxx.xxx.xxx.xxx
where xxx.xxx.xxx.xxx - scope IP address
-
Tried to connect DHO804 via WiFi. May someone use wireless connection and can tell should it be so bad?
With such lags Webcontol become almost unusable. :(((
LAN connection works flawlessly.
Attaching a ping window screenshot.
Tested using ping command from Windows command prompt:
ping -t xxx.xxx.xxx.xxx
where xxx.xxx.xxx.xxx - scope IP address
I have this on WiFi. On a wired connection, a stable 1 ms.
-
This is a proof of concept of an editable button panel, the configuration file will be a simple text file in JSON format stored in the user storage space, the panel can have many buttons, it is scrollable and currently supports chained SCPI commands and launching applications.
https://www.youtube.com/watch?v=DVXYwBNYM1Y (https://www.youtube.com/watch?v=DVXYwBNYM1Y)
A new version is coming! With powerful features!
-
Tried to connect DHO804 via WiFi. May someone use wireless connection and can tell should it be so bad?
With such lags Webcontol become almost unusable. :(((
LAN connection works flawlessly.
Attaching a ping window screenshot.
Tested using ping command from Windows command prompt:
ping -t xxx.xxx.xxx.xxx
where xxx.xxx.xxx.xxx - scope IP address
I have this on WiFi. On a wired connection, a stable 1 ms.
Thank you so much for your test!
Much better than main. Should look for a better WiFi adapter instead of cheap Chinese crap.
-
It is ready now!! and it is free for all subscribers of the Enhanced Plan in Patreon. It is also free for all who have already purchased the version compatible with firmware 00.01.04. I will write some instructions on how to use and configure the DHO Action Panel. Have fun with it!
[attachimg=1]
In the example, load settings and save settings refer to the device settings, so you can quickly save a configuration and later recall it like a custom default button. Of course, you can create multiple Load settings button linked to STP files in the device. The glyph, caption, and action of each button are user-configurable, but this is not a easy task because I tried to keep the panel light. You can use any browser that can access the normal storage in Android and edit the dhoactions.json file. The result bar/Measurements can be docked/undocked using the popup menu of the items in the bar.
More info here: https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions/9
-
Thank you @AndyBig for your improvement! The scope becoming looks like instrument!
Just installed latest version to try. My scope is 924 was loaded with 1.0.4
Some difference noted during install:
Cache file in dalvik-cache not exists.
It's failed to re-mount system partition as read-only after installing services.jar
Sinked it several time and rebooted without issue
After uninstalling sparrow.apk scope closed it and started again in 1min as 1.0.0.1
Hacked APK installed on top of it - no issue.
I'm very appreciated new look, still plaing with it.
Some optimization is seems to tight for me - measurements font in compact view is too small - in details view it's ok and readable.
Could you please make it the same size as details or higher. DVM :bullshit: looks the best, but it will not enough space for label in 1 row.
[attach=1]
Ideally, selectable font size
Unfortunately, horizontally splitted windows sill waisting to much on window headers. Is it possible to hide window header? Similar to status bar.
In multi-window mode vertical axis scale become too tight, not readable. Is it possible to hide half of it?
-
Hi guys i have a question. How can i clone the sd card from dho800?I like to have one buck up for safety.I run google search and i can"t found the right page on the eev forum.Thanks for any help.
-
Cache file in dalvik-cache not exists.
Yes, a couple of people reported this as well. I still don't understand why some oscilloscopes don't have this file.
It's failed to re-mount system partition as read-only after installing services.jar
In principle, it's not critical, after rebooting the partition will still be mounted as read-only.
Some optimization is seems to tight for me - measurements font in compact view is too small - in details view it's ok and readable.
Could you please make it the same size as details or higher. DVM :bullshit: looks the best, but it will not enough space for label in 1 row.
Ideally, selectable font size
Yeah, I've thought about that myself. Maybe I'll switch between large and small views. It'll be easier to read with a larger font, but fewer items will fit on the screen.
Unfortunately, horizontally splitted windows sill waisting to much on window headers. Is it possible to hide window header? Similar to status bar.
In multi-window mode vertical axis scale become too tight, not readable. Is it possible to hide half of it?
Reducing the headers by half is not a problem, but then it will be difficult to hit them with your finger to drag the window or to close it. In full-screen mode there is much more space for signals, use this mode :)
-
Hi guys i have a question. How can i clone the sd card from dho800?I like to have one buck up for safety.I run google search and i can"t found the right page on the eev forum.Thanks for any help.
It's literally the first post in this thread.
-
I was curios about the actual wasted space on those borders, so i started counting pixels ;D. I counted 39 pixels (vertical pinks lines), and then for comparision, i drew a rectangular with the same height. So by removing those borders, the waveform view could be made significantly bigger, or two lines of information could be displayed on the whole width of the screen. Of course you could do a combination of those.
And there is of course space wasted in the horizontal way.
-
In the next release of the mod, owners of 802/812 models who have changed the model to 824 will be able to disable icons for missing channels :) Disabling icons for channels 1 and 2 is blocked. The settings are saved when the oscilloscope is turned off.
-
What will be extremely useful, is probe multiplier from keyboard, like 11.5x. Sometimes there is a need to make temporary probe and there is no good choice of resistors. Sometimes other reasons.
-
I see two custom firmwares (GUI at least). I think it would be a good idea to combine the efforts. :-+
-
I see two custom firmwares (GUI at least). I think it would be a good idea to combine the efforts. :-+
Adding my own, will be three of them. Currently Im aboard at work and without this scope, so my development is paused.
-
What will be extremely useful, is probe multiplier from keyboard, like 11.5x. Sometimes there is a need to make temporary probe and there is no good choice of resistors. Sometimes other reasons.
I'll be happy to be proven wrong, but it seems like the multipliers are hard-defined in the .so library, and so implementing this may be unfeasible.
-
What will be extremely useful, is probe multiplier from keyboard, like 11.5x. Sometimes there is a need to make temporary probe and there is no good choice of resistors. Sometimes other reasons.
I'll be happy to be proven wrong, but it seems like the multipliers are hard-defined in the .so library, and so implementing this may be unfeasible.
That doesn't make it impossible.
Anyway, I will be happy to have more time for development, because I already started app under Orange-Rigol and I needed to change way to start this app, which is almost done. Right now Im aboard for about 1-2 months. After making it work, it should be quite easy (but time consuming) to reverse-engineer whole app communication with AFE and FPGA, to make or port another working app.
-
That was my idea also, but their economic models are different (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5810783/#msg5810783).
I see two custom firmwares (GUI at least). I think it would be a good idea to combine the efforts. :-+
-
RIGOL DHO814 Screen Problem-Seeking help/Advice
Rigol DHO814 and the Logo does not show and the screen is black but the device is running. do you know what i can do to get the screen to lit up please?
https://youtube.com/shorts/WpYVG8jh5V0?si=JutXuIOF_41T-wpt
-
What will be extremely useful, is probe multiplier from keyboard, like 11.5x. Sometimes there is a need to make temporary probe and there is no good choice of resistors. Sometimes other reasons.
As shapirus wrote above, the .so library has a rigidly defined list of divisors, and the application simply passes the identifier of the selected divisor item to this library, not its value. So, unfortunately, you won't be able to set your own divisor value.
-
I see two custom firmwares (GUI at least). I think it would be a good idea to combine the efforts. :-+
A realistic list of improvements for each version might be useful for each development.
We have different visions in some UI aspects, for example, in my case I prefer the simplicity of the full screen mode without more values than the added in the Result bar, I also like the ability of have a docking mode for it. The way of AndyBig is different in that case, so it is better to have many applications available to choose what you prefer.
I like the possibility of enrichment of the ideas from others. Andy starts with the mod of the Result bar and I was able to give a full screen mode, now both have that function but a little different implementation, so there is the freedom to choose.
-
That gives me an idea:
Can I use your version, add a DHO action and switch to Andy's version?
I see two custom firmwares (GUI at least). I think it would be a good idea to combine the efforts. :-+
A realistic list of improvements for each version might be useful for each development.
We have different visions in some UI aspects, for example, in my case I prefer the simplicity of the full screen mode without more values than the added in the Result bar, I also like the ability of have a docking mode for it. The way of AndyBig is different in that case, so it is better to have many applications available to choose what you prefer.
I like the possibility of enrichment of the ideas from others. Andy starts with the mod of the Result bar and I was able to give a full screen mode, now both have that function but a little different implementation, so there is the freedom to choose.
-
That gives me an idea:
Can I use your version, add a DHO action and switch to Andy's version?
That would be nice. And how about the possibilty, to let the user configure a few things? Like margin around the elements?
-
That gives me an idea:
Can I use your version, add a DHO action and switch to Andy's version?
You can switch between version using ADB.
DHO Actions panel app requires a customized server implemented in the Sparrow Extended apk for all functions to work.
-
Reducing the headers by half is not a problem, but then it will be difficult to hit them with your finger to drag the window or to close it. In full-screen mode there is much more space for signals, use this mode :)
I mean not to make it smaller, but remove completely by the button ( like full screen mode)
-
Reducing the headers by half is not a problem, but then it will be difficult to hit them with your finger to drag the window or to close it. In full-screen mode there is much more space for signals, use this mode :)
I mean not to make it smaller, but remove completely by the button ( like full screen mode)
Yes, in principle it is possible if you figure out how to implement it more elegantly. Add another button on the screen above the windows, like the button for turning into full-screen mode? I don't really like this idea. Some other way?
-
Hi Corsair Ko
I have exactly the same issue as you. I have a thread here https://www.eevblog.com/forum/testgear/rigol-dho800-(814)-failing-to-boot-up/?all (https://www.eevblog.com/forum/testgear/rigol-dho800-(814)-failing-to-boot-up/?all), if that is of any help?
How long have you had the scope? It's strange that this is the only other instance I have seen and it is also an 814, which is what I bought.
RIGOL DHO814 Screen Problem-Seeking help/Advice
Rigol DHO814 and the Logo does not show and the screen is black but the device is running. do you know what i can do to get the screen to lit up please?
https://youtube.com/shorts/WpYVG8jh5V0?si=JutXuIOF_41T-wpt (https://youtube.com/shorts/WpYVG8jh5V0?si=JutXuIOF_41T-wpt)
-
Does anyone have a stock image of the OS?
I'm clutching at straws but figured it can't hurt to try flashing one other image to try to get it to boot up
-
Does anyone have a stock image of the OS?
I'm clutching at straws but figured it can't hurt to try flashing one other image to try to get it to boot up
See the very first post in this thread.
-
I have a usb wifi module, the model is EW-7611ULB, it seems to be rtl8723 driver. It can connect to wifi using the forum method, but it cannot connect to wifi automatically after restarting, and the wifi is disabled in the setting, so adb must be used to deal with it. I would like to ask how to make the wifi automatically reconnect when it restarts, assuming I don't have a keyboard or hub
-
I've tried this image to no avail. Hence trying to see if there is another that I can try with.
It's clear that the problem is pretty isolated, save one other person reporting the exact same failure mode, so I'm doing what I can to try to recover it
-
I've tried this image to no avail. Hence trying to see if there is another that I can try with.
OK, so the problem ISN'T the image. Cross that off the list. No need to look for any more images or post about that.
-
Can anyone advise how I might try and interrogate the scope's boot procedure using ADB? I've installed minimal adb for windows and connected the scope via usb to to my laptop
What sort of commands would I use?
I have tried adb connect, adb-devices and nothing.
Can someone steer me in the right direction?
-
Maybe move these posts to this thread:
https://www.eevblog.com/forum/testgear/rigol-dho800-(814)-failing-to-boot-up/ (https://www.eevblog.com/forum/testgear/rigol-dho800-(814)-failing-to-boot-up/)
This is not about hacking one of these 'scopes.
-
Crazy idea:
to add GhatGPT with voice control for intellectual adjustment
I see no problems for gurus
-
Crazy idea:
to add GhatGPT with voice control for intellectual adjustment
I see no problems for gurus
User -> ChatGPT -> SCPI -> DHO Actions panel https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions/9 (https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions/9)
[attach=1]
[attach=2]
-
Good for beginning
-
Claude 3.5 Sonnet
Yes! Direct control is possible through the Android Debug Bridge (ADB) interface. Since the Rigol DHO800 runs full Android, we can create direct command interfaces to the oscilloscope's hardware control layer. This would allow ChatGPT to:Send direct commands to oscilloscope hardware
- Read measurement data directly from the acquisition system
- Control all oscilloscope functions at the hardware level
- Access real-time waveform data
This direct hardware-level access would be much more efficient than UI automation.
-
Claude 3.5 Sonnet
Yes! Direct control is possible through the Android Debug Bridge (ADB) interface. Since the Rigol DHO800 runs full Android, we can create direct command interfaces to the oscilloscope's hardware control layer. This would allow ChatGPT to:Send direct commands to oscilloscope hardware
- Read measurement data directly from the acquisition system
- Control all oscilloscope functions at the hardware level
- Access real-time waveform data
This direct hardware-level access would be much more efficient than UI automation.
Very generic and imprecise answer, chatGPT gave me a Python code with PyVisa string connection and SCPI commands, and I didn't ask for it.
-
The Goal:
1. ChatGPT lives in Rigol's browser equiped with voice regognition/reproduction.
2. ChatGPT has access to all Rigol's control elements.
3. ChatGPT has experience to control the scope.
-
we can create direct command interfaces to the oscilloscope's hardware control layer
Wait, what??? Android works under Linux kernel. Every hardware access is available via files in /dev directory.
More of that, I recreated Rigol drivers from reverse engineering (on my GitHub and in two kernel versions - 4.4.179 and 5.10.209).
Learn more, instead using AI for everything, because this is a good way to end like in movie "Idiocracy".
-
Tastes differ...
-
Good morning, afternoon or evening depending on where you all are in the world. I have an issue when trying hack my DHO804 on 1.0.4. If i try and follow the instructions on the video and went to the pined link for the updated instructions for the newer firmware. But if i fallow his lead the scope will boot but when i try to see any signals it wont see anything. if i hit auto it says no signal found even if it attach it to the calibration points. If i flash the original vendor.bin file back to the scope it works just fine. As for the instructions with the for the working image file I am unsure what to do with it. Am i flashing it to an SD card and installing it to the scope? If so when i do that i get a blank black screen and when i power it on. I have a separate SD Card i am using so i don't risk losing the original OS. I am sure i am missing something very obvious here and I would be greatly appreciative of any help any one can offer.
-
Good morning, afternoon or evening depending on where you all are in the world. I have an issue when trying hack my DHO804 on 1.0.4. If i try and follow the instructions on the video and went to the pined link for the updated instructions for the newer firmware.
What video? What link? What version does it show after the update?
All you need to do is put it on a USB stick then go to "update" in the utility menu.
-
[/quote]
What video? What link? What version does it show after the update?
All you need to do is put it on a USB stick then go to "update" in the utility menu.
[/quote]
hello, i am referring to the one on page 1 of this topc that is in top post. There is a link to a video under the line "MOD EDIT: Here is the latest instructions:" that Video links to a video for newer firmware above 1.0.1 as the pinned comment. Since my scope is on 1.0.4 i went to that link. its the following video posted by The Retro Channel.
https://www.youtube.com/watch?v=oBfuWxMFSsI (https://www.youtube.com/watch?v=oBfuWxMFSsI)
While that Video dose not state it is for 1.0.4 multiple people hare stated it worked for them. however when i fallow the steps in that video the Scope will boot and report as a 924 when i try and prove probe for a signal it dose not see anything. if i connect the calibration post on the front next to channel 4 and hit auto it just says no signal and will default back to channel one regardless of what channel the probe is on.
I also tired the to fallow the bellow instructions that where also on the original post as well. but i just get a black screen and it never really boots. The only change i had was flashed the image to a new SD card so i didn't lose the current working OS.
@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.
Quote from: Luc7777 on September 22, 2023, 06:48:48 am
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"
-
Ad 1. To make a copy of any disk (including SD card), we don't need to use any "win32 imager" or any other software, beside of anything able to copy files. Because in the /dev directory there are binary (1:1) representations of all disks, SD card or "fake" (loop devices) disks. Source file to make a binary image of SD card: /dev/mmcblk0
To flash SD card with image, we can do the opposite. Copy from image file into SD card device file.
-
I'm just starting the process based on finding the same video, and ordering a Rigol HSO804. I knew they used to be hackable years ago, but didn't realize it was still a thing.
Of course I expect it will also have the latest FW 1.04 so I'm quite interested in your results. I won't have scope for a few days still, but hoping the reflash and recalibration goes smoothly.
Pleas post any updates or if you find a more recent thread. Once I get mine, I'll report if it goes well, or there are any issues.
*** edit ***
I was able to find a more recent post from Dec 2024 with an updated 8xx Model config. Hope that helps.
Also, look at page 61 of this Forum Thread.
As you know, the new firmware version 00.01.04.00.02 supports the new DHO824 model with a bandwidth of 200 MHz and a memory depth of 50M, so you can change your DHO8xx to 824, and not to 924 with its non-working logic analyzer panel.
I recompiled (for Windows) the utility from zelea2, adding the DHO824 model to it.
Other community members also added the 824 model to this utility:
- for Mac OS - https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-v00-01-04-00-02-2024111/msg5729989/#msg5729989 (https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-v00-01-04-00-02-2024111/msg5729989/#msg5729989)
- for Android, to run directly on the oscilloscope - https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-v00-01-04-00-02-2024111/msg5732037/#msg5732037 (https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-v00-01-04-00-02-2024111/msg5732037/#msg5732037)
(Attachment Link)
-
I have a usb wifi module, the model is EW-7611ULB, it seems to be rtl8723 driver. It can connect to wifi using the forum method, but it cannot connect to wifi automatically after restarting, and the wifi is disabled in the setting, so adb must be used to deal with it. I would like to ask how to make the wifi automatically reconnect when it restarts, assuming I don't have a keyboard or hub
See e.g. here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5751479/#msg5751479) and leave ethernet disconnected.
-
So i tried using the 824 model and i ran in to the same issue. but i decided to poke around in the firmware to see if i could figure out what was going on. well i came across the self calibrate option in the software tree and ran that and it fixed my issue. See i thought when they said run the calibration i thought it meant the probe calibration and did not realize their was a calibration option for the system. To be fair this is my Frist scope so its a bit of a learning curve on some of this stuff. but yeah if you fallow the steps in the video i linked and make sure you self calibrate the scope it works. I just tested it on my SNES and i could see my button pushes in real time just like before the hack and i was able to find the clock signal on the right pin.
-
DHOTools waterfall proof of concept
https://www.youtube.com/watch?v=mO99S1H-xRQ (https://www.youtube.com/watch?v=mO99S1H-xRQ)
-
I've installed the latest FW v00.01.04.00.02 to my DHO804 and then replaced the vendor.bin file with the ready one from here:https://github.com/norbertkiszka/rigol_vendor_bin/tree/main/generated_ready_to_use/DHO824 (https://github.com/norbertkiszka/rigol_vendor_bin/tree/main/generated_ready_to_use/DHO824)
And rebooted and in About menu is shown DHO824.
After that I used the generate all options method from 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)
I used the second option - with adb push generate_all_options /rigol/data/ method with the file from here: https://github.com/zelea2/rigol_vendor_bin/releases/tag/v1.3 (https://github.com/zelea2/rigol_vendor_bin/releases/tag/v1.3)
Now I have 25Mpts and 625MSa/s when only one channel is ON...
Anybody know why?
When all 4 channels are ON, then I have 10Mpts and 312.5MSa/s as it should be after the hack, but for 1 channel I don't have the full 50Mpts and 1.25GSa/s...
This is the output from the second step:
WARNING: linker: /rigol/data/generate_all_options: unsupported flags DT_FLAGS_1=0x8000001
Rigol 'vendor.bin' encoder/decoder v1.3 - Zelea
-----------------------------------------------------------
Model: DHO824
SN:
MAC:
-----------------------------------------------------------
Generating options for DHO824
-----------------------------------------------------------
RLU BW7T10 EMBD AUTO COMP
-----------------------------------------------------------
-
Now I have 25Mpts and 625MSa/s when only one channel is ON...
Anybody know why?
Check if you have any measurement or triggers or frequency counters etc. referring to any channel but the one that is enabled.
They still mark the channels they refer to as being in use even if the channel is "disabled" in terms of the front panel button not being lit.
-
As the shapirus said. First of all, You need to switch trigger to same channel as You have enabled, because in that case You have two channels enabled - second one is "hidden", because it still works, but as a trigger.
any measurement
From my experience, measurements never caused this problem. Only trigger must be switched.
-
After SelfCal everything is OK :)
Now I remember, that the trigger was set to channel 3 or 4, but I switched them OFF to see only channel 1.
-
Anyone figured out why trace options are greyed out in xy mode?
(https://i.imgur.com/C0jeldR.png)
-
I think You need to enable test mode (or some other name of this mode - I don't remember right now). Main menu -> utility -> touch (or click) "about" three times.
-
I have got the android system installed and got the models and vendor list but when I try to pull the data it says more the one emulator running and I can't get past this. Help would be appreciated.
-
I think You need to enable test mode (or some other name of this mode - I don't remember right now). Main menu -> utility -> touch (or click) "about" three times.
This is correct.
-
I think You need to enable test mode (or some other name of this mode - I don't remember right now). Main menu -> utility -> touch (or click) "about" three times.
Also, It is enabled by default in the Rigol Sparrow Extended UI
-
I have got the android system installed and got the models and vendor list but when I try to pull the data it says more the one emulator running and I can't get past this. Help would be appreciated.
This is from the Windows itself!
If you have a LAN and WiFi on the PC - unplug the LAN and leave only the WiFi to perform all steps for hacking the Rigol.
Also make a restart of the Windows and on fresh start make the procedures.
-
Or you could use the -s parameter in the connection string, like
adb -s 192.168.232.2:55555
(of course, use your own IP)
I have got the android system installed and got the models and vendor list but when I try to pull the data it says more the one emulator running and I can't get past this. Help would be appreciated.
This is from the Windows itself!
If you have a LAN and WiFi on the PC - unplug the LAN and leave only the WiFi to perform all steps for hacking the Rigol.
Also make a restart of the Windows and on fresh start make the procedures.
-
I never had such issue on Linux. If I had, I will do: `killall adb` or eventually: `killall -9 adb`.
-9 is the same as -SIGKILL and by default it's SIGTERM which is more gentle, because process is responsible to do "something" and kill itself.
-
I have got the android system installed and got the models and vendor list but when I try to pull the data it says more the one emulator running and I can't get past this. Help would be appreciated.
You only need to do adb connect once.
Check you're not trying to connect again.
-
Source code for adb on Windows should be the same as on Linux, beside of system API. So on both it should be impossible to connect twice into the same device. Programmers are not so dumb, not even Google programmers.
-
Just got a DHO914S and have gone through several pages of this thread. Besides the well-known vendor file swap to identify it as a 924S and unlock 250 MHz bandwidth instead of 125 MHz, are there any other hacks available?
Also, I was looking for a centralized, wiki-style summary of all the key information from this massive thread. The EEVblog wiki https://www.eevblog.com/wiki/ (https://www.eevblog.com/wiki/) seemed like the ideal place for something like this, but I couldn’t find any relevant entries. Have similar summaries been created for other long hacking threads about test equipment? If so, maybe we could start one for the DHO series?
-
... are there any other hacks available?...
You can improve the UI of your DHO924
-
Besides the well-known vendor file swap to identify it as a 924S and unlock 250 MHz bandwidth instead of 125 MHz, are there any other hacks available?
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/tree/master
-
https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod
-
... are there any other hacks available?...
You can improve the UI of your DHO924
https://www.youtube.com/watch?v=OXJZxY9YVwE (https://www.youtube.com/watch?v=OXJZxY9YVwE)
In this video, how did you access the launcher with that swipe-down gesture from the top edge of the screen? Also, which launcher are you using?
-
In this video, how did you access the launcher with that swipe-down gesture from the top edge of the screen? Also, which launcher are you using?
I used Zone Launcher
-
are there any other hacks available?
It's also an Android device so you can install a launcher and any other apps you want to.
-
Android device
In my case, it's a Debian Linux device. This can run anything, since it's a regular ARM processor (RK3399).
-
Android device
In my case, it's a Debian Linux device. This can run anything, since it's a regular ARM processor (RK3399).
Have you been able to run the actual scope app under debian yet?
-
Android device
In my case, it's a Debian Linux device. This can run anything, since it's a regular ARM processor (RK3399).
Have you been able to run the actual scope app under debian yet?
Yes, but it was in a temporary way, which made it incredibile slow. In January I was close to make working environment for it, but I had to do my job and I left it as it was.
Anyway, the goal is to run (modified) existing open source app or make a new one. Rigol app working under Debian will make it much easier to do reverse engineering.
-
https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/tree/master
Can anyone explain the differences between them?
-
https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/tree/master
Can anyone explain the differences between them?
Price? Everything other is visible and only one is open source (kinda... because both are based on decompiled code).
The choice is Yours.
-
Can anyone explain the differences between them?
The extended UI version on Patreon is intended for advanced users, you can use the DHO Actions panel to run SCPI scripts, save usage profiles and easily recall them from the same panel, etc. Here is a video showing some of the features:
https://www.youtube.com/watch?v=mT4ivaMY7zg (https://www.youtube.com/watch?v=mT4ivaMY7zg)
-
And this is an example of the DHO Actions panel:
https://www.youtube.com/watch?v=DVXYwBNYM1Y (https://www.youtube.com/watch?v=DVXYwBNYM1Y)
-
Is there a way to save the recording frames to a file? It feels like an obvious feature to have, but I haven’t been able to figure out how to do it. The only related option I found was under “Storage,” which seems to deal with saving waveforms — but nothing that explains how to save a full “recording” of, say, 200 frames all at once to disk.
If this isn’t currently possible, would it be feasible to add this as a feature in the extended UI?
-
Did you try to configure in the Quick menu for Recording and use the Quick button on the front panel?
-
Finally today I added more capacitors parallel with others - after switching regulators and after LDO (is it LDO?). Just in ~11 places, which is less than half of my plans. Result is 2-3 times lower noise on modified channels (3 and 4 - increased bandwidth). Unmodified channels has 1-2 % less noise...
Now it's way more usable with normal acquisition instead of average acquisition (last screenshot).
-
Finally today I added more capacitors parallel with others - after switching regulators and after LDO (is it LDO?). Just in ~11 places, which is less than half of my plans. Result is 2-3 times lower noise on modified channels (3 and 4 - increased bandwidth). Unmodified channels has 1-2 % less noise...
Now it's way more usable with normal acquisition instead of average acquisition (last screenshot).
Where can I find more information about adding more capacitors? and modifying the channels for more bandwidth.
-
Did you try to configure in the Quick menu for Recording and use the Quick button on the front panel?
Yes, I tried that, but it only saves the current waveform regardless of whether the record window was open or not. What I'm looking for is how to save all the recorded frames to either one or multiple files
-
I think there might be an issue related to sleep mode and potential screen burn-in on the oscilloscope. If this has already been discussed, I’d appreciate a link to the relevant thread.
I left the oscilloscope in sleep mode for several hours. When I pressed the power button to wake it, I noticed the RIGOL boot logo appeared with a noticeably brighter area around it. That lighter “shadow” remained visible even after the system fully loaded.
Running a screen test confirmed it — the RIGOL logo from the boot screen was clearly visible during solid color tests. The ghost image faded gradually after repeating the screen test a few times.
Interestingly, while the oscilloscope is in sleep mode, I can still access Web Control via a browser. The remote screen shows the Rigol logo displayed on a black background with a spinning animation. So the screen isn’t truly off — it’s just dimmed to 0 brightness while still displaying the same static image for hours.
This seems to explain the temporary burn-in effect.
-
Where can I find more information about adding more capacitors? and modifying the channels for more bandwidth.
I have 470 nF from Samsung (CL21B474KBFNNNG). I just added to missing places and on top of another. Off course only bypass capacitors. First 12 capacitors gave me result as in my previous post. Currently Im adding more as an trial and error nothing. Still I didn't added anything close to AFE or ADC - that theoretically should give best results - maybe I will do this today.
On this forum, there was a link to a Russian forum, where somebody changed LC filters (just below ADC) from 250 MHz to 400 MHz. Increasing BW to 400 MHz gives little more noise. After removing first or all two stages, noise is quite big, very big. Which makes it almost unusable, unless You are using averaging acquisition or you will decrease noise in another way (like I did). Also, You have to remember, that there is a capacitor before those two stages, added for line termination at higher frequencies (coils impedance). So You have to change it value accordingly - I remember it was something like 10 or 15 pF.
From my own reverse engineering, looks like most noise comes from AFE power supply - as I wrote here before.
I think there might be an issue related to sleep mode and potential screen burn-in on the oscilloscope.
Script quick_boot_test.sh (/rigol/shell/quick_boot_test.sh) and Linux kernel modified by Rockchip, gives some answers. Since GPU, VOP, MIPI, panel-simple, etc drivers are compiled as built-in, LCD screen most likely will not be switched off. If mipi driver will be compiled as module, unloading it (rmmod command) should switch off the panel completely (I made a port of RK3399 MIPI driver from one kernel to another, so I learned code in this module a bit).
Rigol didn't gave source code of kernel, beside of GPL licence that requires them to do it. But I did not one, but two kernels with recreated drivers (based on decompiled code and some tests), so theoretically You should be able to make Your own kernel. Also there was a post of compiling kernel modules from (maybe) original kernel, so maybe it's also an option (with or without drivers that I did).
-
In case of switchers there it would be better to add an LC or CLC filter (would need to cut the trace, however)..
-
Low noise LDO for AFE should give better results than filters.
-
Now I disabled AFE (same as before - commented insmod), measured noise across channels, added capacitors (bypass off course) around ADC (looks like both analog power lines) and I did same measurements. With those capacitors, noise is around 20% less than before.
-
The oscilloscope's normal consumption is around 35W. Are there possible ways to reduce consumption to make it more efficient when using a power bank? What is the lowest consumption you can get with this oscilloscope? Has anyone try it?
-
You can turn off PLL and AFG. It will drop to around 10-15 W.
Edit: put backlight to 0. Somewhere in /sys
-
You can turn off PLL and AFG. It will drop to around 10-15 W.
Edit: put backlight to 0. Somewhere in /sys
The DHO804 doesn't have AFG, my mistake, didn't specify the model I'm refering to. Even lowering the backlight the best I can is 31W.
-
Ok.. so I did some experiments with adding capacitors parallel to existing ones (decoupling only off course) and even I put wires to decrease ground impedance and... I did false positive - as on my previous screenshots from scope, when noise was 2-3 times lower (on modified channels only).
So, at some point I noticed noise came back to original value :-BROKE After some hard thinking, I noticed, that previously I omitted two screws from heatsink.
Finally I developed couple possibilities to make lower noise (practically only on channels with increased bandwidth) - I can't say which one is the best and which one will work at less modified scopes than mine:
1. Remove screws 3 and 4.
2. Remove screw 1.
3. Place electrical tape on shield (between PCB and front panel) under screws 2, 3 and 4.
4. Point 2 and 3 - that's what I have right now.
I also did experiments with other screws, but finally I spent too much time on it. Maybe somebody else will develop something better.
-
I thought he stated at the start that the power bank is 20,000mAh?
-
I thought he stated at the start that the battery pack was 20,000mAh?
-
How practical would it be to hack the scope to display HDMI input?
I don't have a lot of workspace, and it would be nice to be able to have the scope display double up with a schematic or datasheet from my PC, or from my microscope. I guess it would need a 2nd HDMI port and some extra circuitry on a little PCB to switch between the HDMI input and the scope?
Thanks
-
How practical would it be to hack the scope to display HDMI input?
I don't have a lot of workspace, and it would be nice to be able to have the scope display double up with a schematic or datasheet from my PC, or from my microscope. I guess it would need a 2nd HDMI port and some extra circuitry on a little PCB to switch between the HDMI input and the scope?
Thanks
You need to recompile Linux kernel, since display drivers are compiled as built in. Linux kernel is on GPV v2 license, so theoretically Rigol should give source code to You.
-
How practical would it be to hack the scope to display HDMI input?
About 0.000001% practical.
I don't have a lot of workspace, and it would be nice to be able to have the scope display double up with a schematic or datasheet from my PC, or from my microscope. I guess it would need a 2nd HDMI port and some extra circuitry on a little PCB to switch between the HDMI input and the scope?
It's Android so there's lots of ways to do that with no hardware hacking needed:
It has a built in web browser to view web pages.
Installing a PDF viewer is possible.
You can probably install an app (https://answers.microsoft.com/en-us/windows/forum/all/how-to-use-my-android-tablet-as-a-second-monitor/1f19c35d-5630-4c12-81d6-36a39992ac01) to use it as a second monitor for your PC - probably the most useful option but I haven't tried that one yet.
Start by attaching a keyboard and/or one of the "alternate UIs" that are mentioned in this thread so you can easily get to the Android home screen. After that you need an app launcher and your 'scope becomes and ordinary Android device.
You can also install/launch Android apps from your PC using ADB.
-
You can probably install an app (https://answers.microsoft.com/en-us/windows/forum/all/how-to-use-my-android-tablet-as-a-second-monitor/1f19c35d-5630-4c12-81d6-36a39992ac01) to use it as a second monitor for your PC - probably the most useful option but I haven't tried that one yet.
Probably You are user of a magic glass ball.
With a precompiler definitions (Linux kernel config file), screen mirroring is hardcoded. Both output screens are using exact same memory region as a frame buffer. Using it as a separate screen is only possible after recompiling the kernel.
-
With a precompiler definitions (Linux kernel config file), screen mirroring is hardcoded. Both output screens are using exact same memory region as a frame buffer. Using it as a separate screen is only possible after recompiling the kernel.
An app can receive screen data over WiFi and display it independently of the kernel.
-
Does anyone have some decent quality photos of the PCB for the DHO804? I'm trying to ascertain if the board is different from the 814.
-
Does anyone have some decent quality photos of the PCB for the DHO804? I'm trying to ascertain if the board is different from the 814.
It isn't.
-
I apologize if this has been answered before, i've probably read half this thread by now and couldn't find a definite answer.
So, i have a DHO804 on the way. I know about adb with rigol_vendor_bin to change the model and unlock all options, that shouldn't be a problem. I also know about the alternative UIs.
But: Should i go with a DHO824 or a 924 as Model?
Some people wrote that going with the 924 decreases accuracy and makes the scope worse, others said that running the self calibration fixes all potential problems. I'm not sure what is the correct information.
What advantages would the 924 software even have? (Besides the theoretical 200Mhz vs. 250Mhz)
Have people that went the 924 route successfully connected a LA probe to the pin header that exists internally? (Not that i need a LA at the moment..)
-
Personally I have DHO924S and I don't have problem with hacking from 800 to 900, but some people said that 800 with vendor_bin from 900, is not very good idea, because it's not working correctly. So my advise is to hack it up to the 824 with 200 MHz bandwidth and little less decoders.
Eventually You can modify libscope-auklet.so library file to gain everything from DHO924 without issues from vendor_bin. But this is far from simple job.
-
What advantages would the 924 software even have? (Besides the theoretical 200Mhz vs. 250Mhz)
Extras: It has CAN and LIN decoders.
Downsides: More UI clutter on screen and higher bandwidth is more disproportional to the sample rate when you're using more than two channels.
-
So my advise is to hack it up to the 824 with 200 MHz bandwidth and little less decoders.
The 824 has the 50M memory option - important.
-
I have a newly acquired DHO804 with 1.03.00.06 firmware installed and wanted to make a clone of the SD card prior to firmware upgrade in case of corruption. I am using a MacBook and hoped to image the uSD card using Disk Utility or gdd in terminal. However the Rigol uSD card is not recognized and does not mount on the MacBook. Any idea what tools would I need to use in order to achieve this with macOS please (or alternative OS/software if not doable)? I understand I can pull the contents with adb, but I am concerned that in the event of formatting corruption of the card I will be stuck if I go this route. Would feel happier with a known bootable clone before I start to mess with it. Possible?
Also wondering how I can unpack the firmware .GEL file with a Mac (or again, alternative OS/software if not doable)?
-
Also wondering how I can unpack the firmware .GEL file with a Mac (or again, alternative OS/software if not doable)?
You don't have to unpack it.
(It's a Unix .tar file if you just want to look inside)
-
Also wondering how I can unpack the firmware .GEL file with a Mac (or again, alternative OS/software if not doable)?
You don't have to unpack it.
(It's a Unix .tar file if you just want to look inside)
Thanks! That was easy just changing the extension.
-
However the Rigol uSD card is not recognized and does not mount on the MacBook
There is no system that will "recognize" it, because it doesn't have partition table. However, there are partitions inside.
-
I have a newly acquired DHO804 with 1.03.00.06 firmware installed and wanted to make a clone of the SD card prior to firmware upgrade in case of corruption.
Not really necessary.
Firmware is downgradable and there's images out there if things go wrong.
The ONLY thing that makes your Rigol unique are two files in /rigol/data (vendor.bin and RKey.data).
Make a copy of those two files and you're good.
-
I have a newly acquired DHO804 with 1.03.00.06 firmware installed and wanted to make a clone of the SD card prior to firmware upgrade in case of corruption.
Not really necessary.
Firmware is downgradable and there's images out there if things go wrong.
The ONLY thing that makes your Rigol unique are two files in /rigol/data (vendor.bin and RKey.data).
Make a copy of those two files and you're good.
Sorry new to this so not really getting it. If the SD card fails how do I rebuild one with a firmware release? My understanding is that the scope will not boot without the SD card, so I am under the impression that in this event I could not use the scope menu to install new firmware on a blank card as it would not start up. Assuming I had a backup of my original vendor.bin and RKey.data, a firmware release, and a blank 32Gb uSD card, how could I get it going again please?
-
Now I have 62.5 Mpts memory depth in my DHO924S. However only in auto depth.
Originally it was hardcoded to do maximum 100k in auto.
Any questions?
-
Hi all,
Can we run rigol_vendor_bin directly on the scope, as for generate_all_options (I don't have any Windows system) ?
I tried but got this:
./rigol_vendor_bin: not executable: 32-bit ELF file :-\
-
Linux 64 bit without 32 bit libraries?
https://github.com/norbertkiszka/rigol_vendor_bin
-
Any questions?
Of course.
1) how?
2) any issues/side effects?
-
Any questions?
Of course.
1) how?
2) any issues/side effects?
Ad. 1. I did many changes - most of it by low level changes in libscope-auklet.so. Im planing to do a separate and public repository for it, after I test how many changes are needed exactly. Especially because I have also experimental changes - most likely harmless, but I don't want to risk making somebody day bad because of it.
Ad. 2. When I increased limit to 200M and when I increased time base, at some point it was 80M and frequency measurement was bad (like ~10 MHz instead of ~17 MHz). At around 100M or 125M (I don't remember precisely and text with sample rate was hiding part of text of memory depth), waveform was flickering, but single shot (with frequency measurement) was ok - as far I tested. Going further with time base waveform disappeared (likely FPGA temporary stopped his work for some reason) After lowering it to the 62.5M it looks ok - as far I tested.
80M or 100M maybe will work after some further changes. Some of compiled code is from other scopes (You can put vendor.bin from DHO1000 and DHO4000 but it's unusable practically) and that 80M was likely it (not intended by original developers, they just used 'ifs' instead of precompiler directives).
-
Ok, so I made it from scratch and looks like only one change was necessary to do it. Exactly one very small and easy change in libscope-auklet.so.
Additionally I tested 78.125M (which additionally gives "strange" values of sample rate) but measurements was also bad like in 80M. So I reverted it back to 62.5M.
Im not 100% sure, but I think measurements are done by FPGA - which kinda explains why this happens with bad measurements results.
Bon appétit: https://github.com/norbertkiszka/Sparrow_DHO800_DHO900
-
I did more experiments and turns out 125M limit is working ok. I pushed it into my repository.
Likely my other experimental changes (not published) caused problems with more than 62.5M.
-
After so many new hacks and improvements the Rigol's developers r(certainly reading this thread) would perhaps issue a new firmware version soon.. :D
-
After so many new hacks and improvements the Rigol's developers r(certainly reading this thread) would perhaps issue a new firmware version soon.. :D
I don't think so. Rigol company is very bad in my eyes. Especially with bode plot bug which makes it unusable. That's the last product I purchased from Rigol. Never ever more.
-
Sorry new to this so not really getting it. If the SD card fails how do I rebuild one with a firmware release? My understanding is that the scope will not boot without the SD card, so I am under the impression that in this event I could not use the scope menu to install new firmware on a blank card as it would not start up. Assuming I had a backup of my original vendor.bin and RKey.data, a firmware release, and a blank 32Gb uSD card, how could I get it going again please?
Download the image in the first post of this thread. Put it on an SD card. Start 'scope.
Install latest firmware. Copy your files to it.
-
Who told that sinc interpolation can't be hacked on those series?
-
Who told that sinc interpolation can't be hacked on those series?
It sounds like you might be getting close to enabling dot display mode... :)
-
Who told that sinc interpolation can't be hacked on those series?
It sounds like you might be getting close to enabling dot display mode... :)
Nah... Image is generated by FPGA. Interpolation is managed by library which app uses - I hacked that thing only. Im not sure if hacking FPGA is worth of time.
-
Who told that sinc interpolation can't be hacked on those series?
Can be combined with:
https://www.youtube.com/watch?v=ARIZRKmnTb0 (https://www.youtube.com/watch?v=ARIZRKmnTb0)
-
Who told that sinc interpolation can't be hacked on those series?
Can be combined with:
https://www.youtube.com/watch?v=ARIZRKmnTb0 (https://www.youtube.com/watch?v=ARIZRKmnTb0)
Show me the same thing with sqare wave generator with fast rising time. We will know if that points are interpolated or not.
-
Show me the same thing with sqare wave generator with fast rising time. We will know if that points are interpolated or not.
It is interpolated by sure, that is why I said we should combine your mod with the dot display.
-
Show me the same thing with sqare wave generator with fast rising time. We will know if that points are interpolated or not.
It is interpolated by sure, that is why I said we should combine your mod with the dot display.
Knowing where line breaks, we know where are exact samples. In case of software, we just need to find at least one (probably the first data from the FPGA, but who knows?), because all other are in exact same "distance".
-
Who told that sinc interpolation can't be hacked on those series?
There is one thing I don't understand. The screenshot says 1.25GSa/s and 800ps/point, but in the plot, the horizontal spacing of the points that are connected by straight line segments is more in the order of ~5ns.
-
Who told that sinc interpolation can't be hacked on those series?
There is one thing I don't understand. The screenshot says 1.25GSa/s and 800ps/point, but in the plot, the horizontal spacing of the points that are connected by straight line segments is more in the order of ~5ns.
App makes some calculations and sends data to the FPGA, which then it generates image of the waveform and sends it back to the app. I changed data that is going to FPGA. Horizontal scale is different from reality, but the waveform shape is 100% correct.
BTW. in that scenario, it's funny when I try to move waveform horizontally with a knob, because waveform moves faster than pointers of trigger point.
-
Finally I figured it out. It still needs some work tho.
I don't have source code of this app, so all my work is done with deassembled and decompiled code which is very hard to read and understand.
Anyway, I know how to change sample rate in app, but to make it fully work, I need to do one more thing, however I decided to remove sinc interpolation, which was looking as a much easier thing to do.
-
Hello,
I have finally bought the DHO804 (calibration date = december 2024).
Many problems with it :-\
I find it really very noisy :-[
The delta PSU doesn't always give me the red button light, whereas a DELL Laptop USB-C 65W PSU is working great.
Also, sometimes: with the delta PSU: I have a problem with the HDMI port.
Many items seems not to be saved after a reboot/shutdown like brightness, zoom on click ...
Also, I have strange things with all physical buttons:
=>I have some "bounce" effect (sorry, don't know how it is called in english :-\ ):
Many times, when I push a button: it makes 2 activations (or more) and open then instantaneously close the window.
(it is like a mouse-click switch failure).
I don't know if it is a problem of my model, or if there is something to do to fix this ?
(I have updated to the last 1.04 and same problem)
Also, I have tried to install @AndyBig firmware, but without any success.
=>From 1.04 version: after the first "adb uninstall com.rigol.scope" : the DHO804 reboots and the 1.03 version is came back.
So I have put another "adb uninstall com.rigol.scope": but "FAILURE [DELETE_FAILED_INTERNAL_ERROR]": it reboots again and came back the 1.03 FW.
Of course, the "adb install -g -r Sparrow_a008_u.apk" doesn't work as there is already the original APK inside (invalid signature message).
I have made 2 backups about everything from ADB and TotalCommander plugin :-+ (including all the rigol folder with all *.hex files): one after unboxing it with the 1.03 and one after updated it to 1.04 and selfcal made.
I have not made any "hack" inside it (I have my genuine vendor.bin file on my computer).
So I think I will send it back.
Thanks for any help you could provide me :-+
-
I have finally bought the DHO804
From which seller? Aliexpress, Banggood or Amazon?
-
I have finally bought the DHO804
From which seller? Aliexpress, Banggood or Amazon?
Forget to tell that :palm:
Amazon (it is Rigol EU marketplace, and I have had invoice from RIGOL too :-+ )
(I was about buying it from Eleshop, but the price was lower on Amazon).
Brand new, with 3 boxes: the external brown one from Amazon, then a brown one from RIGOL and inside the white one.
-
I think that three resellers are selling those scopes with some problems. I bought mine DHO924S from authorized reseller and I don't have problems (beside of very very rarely hangs up or sd card socket is not always connecting properly - which many people has this problem). Yes, I payed much more than from those three, but I prefer to have something that works more or less correctly (if anybody can say that about those series...) and at least 99.9% of the time.
-
I think that three resellers are selling those scopes with some problems. I bought mine DHO924S from authorized reseller and I don't have problems (beside of very very rarely hangs up or sd card socket is not always connecting properly - which many people has this problem). Yes, I payed much more than from those three, but I prefer to have something that works more or less correctly (if anybody can say that about those series...) and at least 99.9% of the time.
For the MicroSD socket : on mine they have put a big big black tape on it: I can't see it, or access to it at all.
So you think that Amazon with RIGOL Market place could have problems too ?
(I would never buy tools like this at this price on aliexpress or banggood :o )
You have bought yours from which seller ?
Usually I buy from Eleshop/Weletron.
-
There is one authorised reseller in Poland and that's NDN.
https://ndn.com.pl/pl/12_rigol
Anyway Im disgusted because of software bugs and lack of support or even any contact from Rigol at all. Also they promised that they will maintain license terms of software that they used (and they used a lot of GPL code) but they failed miserably.
Only upside is hackability. But if You know assembly, then You can hack it whatever You like, including doing Your own software for the scope (https://github.com/norbertkiszka/Orange-Rigol).
-
There is one authorised reseller in Poland and that's NDN.
https://ndn.com.pl/pl/12_rigol
Anyway Im disgusted because of software bugs and lack of support or even any contact from Rigol at all. Also they promised that they will maintain license terms of software that they used (and they used a lot of GPL code) but they failed miserably.
Only upside is hackability. But if You know assembly, then You can hack it whatever You like, including doing Your own software for the scope (https://github.com/norbertkiszka/Orange-Rigol).
Agree with you :-+
So I end up with it and send it back for refund.
-
Great. Is there a way you and AndyBig could team up and make a version that is the best of both worlds?
Finally I figured it out. It still needs some work tho.
I don't have source code of this app, so all my work is done with deassembled and decompiled code which is very hard to read and understand.
Anyway, I know how to change sample rate in app, but to make it fully work, I need to do one more thing, however I decided to remove sinc interpolation, which was looking much easier thing to do.
-
Great. Is there a way you and AndyBig could team up and make a version that is the best of both worlds?
Finally I figured it out. It still needs some work tho.
I don't have source code of this app, so all my work is done with deassembled and decompiled code which is very hard to read and understand.
Anyway, I know how to change sample rate in app, but to make it fully work, I need to do one more thing, however I decided to remove sinc interpolation, which was looking much easier thing to do.
Im not sure about that idea.
Anyway, Im going further with changes. With my overclocking tests, maximal sample rate that is stable is 1.8 G. However, that gives 555.(5) ps per sample, which is not great ("not great, not terrible"). I had tough decision between 1.6 G (625 ps) and 1.666(6) G (600 ps). I decided for second one (speeeeed).
However, with that sample rate, maximum memory depth is 20 k, because Rigol didn't used fastest DDR3 chip for FPGA.
-
Finally I released it. However I decided to put sample rate back to original, because it needs much much more work to be done and in most cases it requires limiting memory depth to around 20 k for all channels, unless I figure something else.
IMHO 125 M points is more useful in most cases than sample rate like 1.6 G or 1.8 G.
https://odysee.com/@norbert.kiszka:6/dho924s_extended_v0.0.1:0 (https://odysee.com/@norbert.kiszka:6/dho924s_extended_v0.0.1:0)
https://www.youtube.com/watch?v=S4s2UEjmu38 (https://www.youtube.com/watch?v=S4s2UEjmu38)
- Removed sinc interpolation (no interpolation at all - just straight lines from sample to sample).
- No bandwidth limit (About 1 GHz after removing LC filters between AFE and ADC).
- Horizontal scale down to 800 ps / div (one div per sample).
Software options from DHO4000:
- I2S trigger / decode
- CAN-FD trigger / decode
- Flexray decode
- MIL-STD-1553 trigger / decode
No need to change vendor.bin or anything like that. It will ignore if You have options enabled or not. All scopes of this series will have full bandwidth and options out of the box.
Power analysis is not working yet, but option is visible in Utility -> Options.
This is alpha/demo so there is a memory depth limit of 5 M. Further version will have 125 M (yes, that's possible on DHO800 since it has same DDR3 chip for FPGA).
Version: v0.0.1.
Compatible only with 1.04.00.02 firmware.
https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-v0-0-1-1632964 (https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-v0-0-1-1632964)
-
The options show "Power Analysis". It works?
-
The options show "Power Analysis". It works?
Power analysis is not working yet, but option is visible in Utility -> Options.
It can be enabled (from "start" menu) after small change in app, but it displays empty measurement results - at least on my scope. That's why I published it with this option not visible in start menu.
I decided to put this fix on later. Currently Im working on other changes, like better UI and memory depth 125 M (62.5 M for two channels and 31.25 M for 3&4 channels).
I think UPA (power analysis) will be the next one.
Maybe this will be easy fix or maybe it will be a huge rabbit hole. I experienced both at reverse engineering and hacking or even with physically modifying my scope (not related to software).
Maybe also I will do sample rate around 1.5 G if all tests will be ok. It works up to 1.8 G but only if memory depth is limited to 20 k (it can be as a separate app) and noise is little bigger (currently I don't remember how much), because analog path has not very best shielding and ground rail (that explains why they limited bandwidth to the 250 M with LC filters, which can be done also by changing ADC flags, since it has built in filters).
Theoretically switching (real) sample rate by app (without reinstalling every time) is possible, but that's another story. Im not sure how many people will want that option (personally I do), because it will take huge amount of time to do that.
In future, I want to do my own app from scratch, since modification of existing one is time consuming - especially because I don't have source code or detailed documentation.
-
Thanks, I bought it in a heartbeat.
Finally I released it. However I decided to put sample rate back to original, because it needs much much more work to be done and in most cases it requires limiting memory depth to around 20 k for all channels, unless I figure something else.
-
Personally I have DHO924S and I don't have problem with hacking from 800 to 900, but some people said that 800 with vendor_bin from 900, is not very good idea, because it's not working correctly. So my advise is to hack it up to the 824 with 200 MHz bandwidth and little less decoders.
Eventually You can modify libscope-auklet.so library file to gain everything from DHO924 without issues from vendor_bin. But this is far from simple job.
Greetings,
I received my DHO804, upgraded to 1.04, and applied your vendor.bin for the DHO824 (thanks). Everything went smoothly. Although the options screen didn't show CAN and LIN options, as was expected from everything I've read about the DHO824 upgrade, the decoder screen has CAN as a selection. CAN capture/decode options can be set, and it appears it wants to work. I don't have a CAN device to test it with - can you confirm/deny whether it works? I'll attempt to attach screenshots of what I'm seeing, but this is my first post and I'm not sure I've done the attachments right.
- Thanks
-
Has the price of these scopes gone up recently ?
They are quite a bit more expensive now compared to the YouTube movies and the mentioned prices when theses scopes came out.
Any advice where to buy a 802 in Europe?
(As in cheapest way)
-
Personally I have DHO924S and I don't have problem with hacking from 800 to 900, but some people said that 800 with vendor_bin from 900, is not very good idea, because it's not working correctly. So my advise is to hack it up to the 824 with 200 MHz bandwidth and little less decoders.
Eventually You can modify libscope-auklet.so library file to gain everything from DHO924 without issues from vendor_bin. But this is far from simple job.
Greetings,
I received my DHO804, upgraded to 1.04, and applied your vendor.bin for the DHO824 (thanks). Everything went smoothly. Although the options screen didn't show CAN and LIN options, as was expected from everything I've read about the DHO824 upgrade, the decoder screen has CAN as a selection. CAN capture/decode options can be set, and it appears it wants to work. I don't have a CAN device to test it with - can you confirm/deny whether it works? I'll attempt to attach screenshots of what I'm seeing, but this is my first post and I'm not sure I've done the attachments right.
- Thanks
That's great that You can use CAN decoding without changing vendor.bin to the 9xx one. I didn't expect that. Personally I have 924S and it was long time since I was playing around with downgrading it :) :-BROKE
I think two options are probably the best for You. One is to use two ESP32 with cheap transceiver like MCP2562 or similar. Second one is to generate fake CAN data with any microcontroller or USB-UART adapter with some computer (if the device and driver allows for it...).
If You wan't to trigger and decode CAN-FD, then You can use my hacked app (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5916260/#msg5916260) (this scope uses Android and Android app), which Im currently developing, by subscribing: https://www.patreon.com/NorbertKiszka (https://www.patreon.com/NorbertKiszka) and You will get it when I release it. Or if You are in hurry, You can use limited and alpha version here: https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-v0-0-1-1632964 (https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-v0-0-1-1632964) Also, it disables any bandwidth limits on Your scope (no matter what You have in vendor.bin or RKey.dat - if that's not true, please let me know - I will try to fix it soon as possible).
(As in cheapest way)
I noticed one thing. Almost every hardware problem with this series, shared by people on this forum was with scope bought from cheapest seller. One person received fake address to sent it back... Now he have a nice brick to put on shelf - he wasn't able to repair it - at least it appears from his posts on this forum.
If You are in hurry, IMHO it's better to buy used DS1054Z or similar DS model. Or some Siglent, which is much more fair to their clients than Rigol. Those are often available to buy from second hand, because people often will like to buy better scope after some years. And firmware has less bugs than DHO800 and DHO900. Of course DHO800 and DHO900 has some advantages and disadvantages.
-
If You are in hurry, IMHO it's better to buy used DS1054Z or similar DS model.
Not unless you can get one really cheap.
The DHO800 is a huge advance over the DS1054Z.
-
Is the best bang for the buck for features to buy and mod the 804 or to start with the 900 series if you want the logic analyzer?
-
The LA is rather limited, as the FG is. Get the 804, hack it to 100MHz or to 824 and be happy.
The 1024x600 display is so limited in pixel height (minus these fat menues) that you don't really see very much on it with f.e. 8 digital signals. Get an USB LA instead and use your PCs display.
-
The LA is rather limited, as the FG is. Get the 804, hack it to 100MHz or to 824 and be happy.
The 1024x600 display is so limited in pixel height (minus these fat menues) that you don't really see very much on it with f.e. 8 digital signals. Get an USB LA instead and use your PCs display.
Currently Im working on it - see attachments.
Also I get crazy idea to create app for this scope from scratch. More efficient (less laggy) and browser based (it will be working as a web page server).
After I finish (maybe even today), it will be available here: https://www.patreon.com/NorbertKiszka/membership (https://www.patreon.com/NorbertKiszka/membership)
-
If You are in hurry, IMHO it's better to buy used DS1054Z or similar DS model.
Not unless you can get one really cheap.
The DHO800 is a huge advance over the DS1054Z.
We have a Hameg, a Siglent 3254X Plus and a Magnova on the benches but are looking for something more portable for some RS485 decoding and Troubleshooting in the field.
The Micsig MH01 would be a great solution too.
(But double the price of an 804)
-
Who told that sinc interpolation can't be hacked on those series?
It sounds like you might be getting close to enabling dot display mode... :)
Yep, the dot display mode is nice.. We may say then that the "beauty of the signal shape is in the eye of the beholder".. :)
-
Maybe I will do the dot mode, but most likely in a completely new app, because hacking existing binary in assembler is highly time consuming.
-
Any advice where to buy a 802 in Europe?
(As in cheapest way)
Banggood sells the 804 for 350€ shipped from their EU Warehouse. (They also sell the 802, but only from the China Warehouse and it's only 20€ less, so might as well go with the 804.)
-
I found on aliexpress a DHO914s that ships from the US for $616. With code AEUS40 it knocked it down to $576. Now to read this gigantic thread to see how to make it a DHO924s.
-
I found on aliexpress a DHO914s that ships from the US for $616. With code AEUS40 it knocked it down to $576. Now to read this gigantic thread to see how to make it a DHO924s.
You can make it almost DHO4000.
-
Couple things left to do. How it looks right now?
I don't have any idea what to do with all that buttons on the right top. I think some of them should be moved to "start menu" or somewhere else, since those are rarely used. Likely I will change then to normal text - images on that thin strip, probably are not the best thing.
On the bottom (channels, math, etc), I think to make it little thicker and in similar way like the top. Primarily, I calculated this height for waveform area to have round 1000 px when using external monitor with res. 1092*1080.
BTW. I think I damaged HDMI socket or soldering joints, when I was removing HDMI plug :-BROKE That's how they designed it.
-
Anyway, Im going further with changes. With my overclocking tests, maximal sample rate that is stable is 1.8 G. However, that gives 555.(5) ps per sample, which is not great ("not great, not terrible"). I had tough decision between 1.6 G (625 ps) and 1.666(6) G (600 ps). I decided for second one (speeeeed).
What are the available choices?
-
Anyway, Im going further with changes. With my overclocking tests, maximal sample rate that is stable is 1.8 G. However, that gives 555.(5) ps per sample, which is not great ("not great, not terrible"). I had tough decision between 1.6 G (625 ps) and 1.666(6) G (600 ps). I decided for second one (speeeeed).
What are the available choices?
Frequency driving FPGA and ADC can be changed to anything between 20 MHz and 1.8 GHz, which gives maximal sample rate 1:1 as this frequency. 1.8 GHz is the real maximum. Anything above leads to corrupted data from acquisitions. Changing that frequency requires a lot of changes in app, since they hardcoded (precompiler directives?) a lot of things for 1.25 GHz - which is set to it for all the time (FPGA can skip some pulses to lower sample rate).
BTW. From my very short reverse engineering of DHO1000&DHO4000 firmware, probably it changes (different chip) PLL frequency for the current needs. I tried couple times on my DHO924S, to change this frequency on-fly, but it ended with corrupted acquisition data - maybe it will be possible after more reading of its datasheet.
In my current development, this is not on the priority list of my changes. I think to test 1.5625 GHz, which should work without decreasing memory depth and it will give "round" time per sample of 640 ps.
-
In my current development, this is not on the priority list of my changes. I think to test 1.5625 GHz, which should work without decreasing memory depth and it will give "round" time per sample of 640 ps.
It's not really much of a step up from 1.25 GHz though. Still not enough to match the bandwidth of 250MHz with 4-channels.
But I guess it's useful if you modified the front end to 900Mhz bandwidth. :-)
-
LC filters can be removed or changed very easily. Those are pretty cheap elements. But changing it, we need to care about matching impedance.
Even without touching it at all, higher sample rate is still useful, especially if You want to use more channels than only one.
Edit: 1.5625 versus 1.25 is 25% increase, which is still something. With 20 k memory, it can do 1.8.
-
Working with Android layouts is not easy as html and css. But I did something. 91% of the screen height is for the window(s) with waveform or whatever is currently opened.
-
100 uV / D. Currently I have no idea how to get lower that this. 50 uV / D gives no change beside of wrong vertical measurements (100 uV DC is measured as 200 uV).
-
17uVrms is not that bad result.. That is even less we saw in our original 804 measurements some times back (around 22uVrms, afaik, BW 20MHz).
So, you have removed the ADC antialiasing filters and did better decoupling of the AFE?
-
17uVrms is not that bad result.. That is even less we saw in our original 804 measurements some times back (around 22uVrms, afaik, BW 20MHz).
So, you have removed the ADC antialiasing filters and did better decoupling of the AFE?
I have fully removed LC filters on channel 4. Channels 1 and 2 are unmodified (as it was delivered). However, some time ago, I added a lot of capacitors in parallel to existing (decoupling) ones - which can lower the noise, especially on lower frequencies.
Speaking about filters, ADC have built in filters, which can do 250 MHz at -3 dB. I enabled this once (I was testing flags being sent to FPGA). I believe this is better than LC filters, because of much lower phase shift. Right now my ADC is working without any filtering enabled. Likely 70 MHz filter would give me something better. In the decompiled code, there are many settings for LP filters - that will be great thing to manage it, like right now only 20 MHz or "full".
BTW. 20 minutes later I had 15.77 uV (average). After that I tested it with theoretically better PSU (and 15 V instead of 12.5 V) which gave slightly higher noise 16.08 uV.
-
I played around and I tested couple things. Downclocking PLL (probably the best was at half frequency, which is 625 MHz) decreases noise as we can expect, but it's not worthy (requires to restart the app or the whole scope). Enabling channels 3 and 4 somehow also decreased noise and enabling channel 2 had opposite result. After I removed AFE driver and restarted (which makes AFE more silent) gives measured noise mostly between 9 to 14 uV. But channel 3 with every enabled channel (time base and memory depth makes very small changes) has lower and lower nosie, down to ~1.5 uV.
Without AFE driver, I can see ADC offset is fixed (auto calibration) by regulating AFE offset.
-
Btw., after I had lost an usb flash drive (I mean the data after inserting it into my DHO) while trying to save 50MPts waveform off memory to it, I started thinking how to get the data saved on an usb flash into python or excel or whatever..
The CH1 only 50Mpts data saved in .csv is 762MBytes, in .wfm 197MB and in .bin 93MB.
Is there a python lib for messing with DHO800/900 data sets available somewhere?
For example AI recommended to me kindly either read the DS, or to try to ask at EEVblog forum, so I do..
-
Btw., after I had lost an usb flash drive (I mean the data after inserting it into my DHO) while trying to save 50MPts waveform off memory to it, I started thinking how to get the data saved on an usb flash into python or excel or whatever..
The CH1 only 50Mpts data saved in .csv is 762MBytes, in .wfm 197MB and in .bin 93MB.
Is there a python lib for messing with DHO800/900 data sets available somewhere?
For example AI recommended to me kindly either read the DS, or to try to ask at EEVblog forum, so I do..
50 milion points gives 100 milion bytes (1 byte = 8 bits). 100 000 000 / (1024 * 1024) = 95.367431640625 MiB (MiB, not MB !!!). If You have exactly that much, it means it is at it was saved by the FPGA.
I guess You are not every day hacker, so probably You don't even know how to manually read first sample (simple hexdump on Linux console is Your friend). With that real world format, I don't know if there are something on GitHub, but even if there is something, it will don't know offset or scale (You have values like from -1 to 1, which You need to multiply by something and offset it), unless You give necessary data.
csv I guess is a Rigol pseudo-csv format - so You need to look only for Rigol tools.
wfm - I really don't know.
Maybe good old sigrok will be able to open and understand one of these and make some magic that You want.
BTW. If You wan't to use single channel only, without LA, You can use this: https://github.com/norbertkiszka/Sparrow_DHO800_DHO900/raw/refs/heads/main/app/dist/Sparrow.apk (repo (https://github.com/norbertkiszka/Sparrow_DHO800_DHO900)) to have 125 M points, but only in auto. If You want manual and much more things, Im currently working on it.
-
Those MBytes are the numbers I see in windows with the files I stored, not somehow calculated..
In the .csv it saved as floating point strings (like 16chars), therefore aprox those 780MB.
-
Those MBytes are the numbers I see in windows
This is one of many reason, why Im not using Windows, but Debian (with Linux as a kernel, but it also works with *BSD).
-
Those MBytes are the numbers I see in windows
This is one of many reason, why Im not using Windows, but Debian (with Linux as a kernel, but it also works with *BSD).
Yep, you are a happy camper when your files in your linux are just 1/8 of the Windows one.. I have to switch to linux asap :) ..
This could be a good start:
https://rigolwfm.readthedocs.io/en/latest/0-Basics.html?utm_source=chatgpt.com
-
Btw., after I had lost an usb flash drive (I mean the data after inserting it into my DHO) while trying to save 50MPts waveform off memory to it, I started thinking how to get the data saved on an usb flash into python or excel or whatever..
The CH1 only 50Mpts data saved in .csv is 762MBytes, in .wfm 197MB and in .bin 93MB.
Is there a python lib for messing with DHO800/900 data sets available somewhere?
For example AI recommended to me kindly either read the DS, or to try to ask at EEVblog forum, so I do..
The .csv should be easily importable into speadsheet programs (like libreoffice calc or google sheets or ms excel), it's a plain text file with one row per line and columns separated by commas (plus some quoting and escaping techniques). Once imported, you can do whatever you need, including plot visualization or math statistics.
There are many libraries for nearly any language to read CSV files into internal data structures, if you want to write your own data processor.
-
We messed a lot with .csv from Rigols here already (ie Bode), but we are talking 780MB with a single channel (and 50Mpts == 50million .csv lines).
So we need to master the .bin or .wfm formats which are much smaller.
PS: with more channels it will stay the same volume aproximately, as the mem halves with each channel, afaik..
These are the first lines in the .csv file = 16bytes*50.000.000 in total
CH1V,t0 =-5.000000e+01, tInc = 2.000000e-06,
+4.600000e-03,,
+5.600000e-03,,
+3.586666e-03,,
-
We messed a lot with .csv from Rigols here already (ie Bode), but we are talking 780MB with a single channel (and 50Mpts == 50million .csv lines).
So we need to master the .bin or .wfm formats which are much smaller.
PS: with more channels it will stay the same volume aproximately, as the mem halves with each channel, afaik..
You just reminded me, how fast RK3399 (CPU used in those series) really is. handling 100 MB in memory or with PCIE (between FPGA and CPU in those scopes) is not a very big deal (not good not terrible). But they made their app to make it incredibly slow. My analysis of the system and app, gives me a clue, that it was made in India, not in China, since those are more cheap - maybe they don't know what they doing, but it's still very cheap. Boeing doing second version of MCAS (https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Augmentation_System) was outsourced it in India, which ended with sudden lost of life of 346 people, because both sides didn't care about nothing - just like Rigol.
-
We messed a lot with .csv from Rigols here already (ie Bode), but we are talking 780MB with a single channel (and 50Mpts == 50million .csv lines).
So we need to master the .bin or .wfm formats which are much smaller.
The .bin file, judging by the size, must contain a sequence of 50M two-byte records. Plus it should have some header to indicate the sampling interval and perhaps some other info. I would guess that its format should be the same across all Rigol scopes. Internet search gives some results, for example, here someone already parsed it: https://github.com/ngscopeclient/scopehal-apps/issues/287
The .wfm I'm not sure. It may be the same, except with one 32-bit word per sample, or something like that. Of course someone has already solved the task of decoding them too: https://github.com/scottprahl/RigolWFM
-
We messed a lot with .csv from Rigols here already (ie Bode), but we are talking 780MB with a single channel (and 50Mpts == 50million .csv lines).
So we need to master the .bin or .wfm formats which are much smaller.
PS: with more channels it will stay the same volume aproximately, as the mem halves with each channel, afaik..
You just reminded me, how fast RK3399 (CPU used in those series) really is. handling 100 MB in memory or with PCIE (between FPGA and CPU in those scopes) is not a very big deal (not good not terrible). But they made their app to make it incredibly slow. My analysis of the system and app, gives me a clue, that it was made in India, not in China, since those are more cheap - maybe they don't know what they doing, but it's still very cheap. Boeing doing second version of MCAS (https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Augmentation_System) was outsourced it in India, which ended with sudden lost of life of 346 people, because both sides didn't care about nothing - just like Rigol.
You would be surprised how often programming projects are divided into small tasks made by independent (and cheapest) individuals whom often really have no clue or barely grasp the sense of whole project due to secrecy etc
It results in such slow sluggish apps we nowadays have... also frameworks are usually sluggish (but usually not as bad in such devices).
I am kinda a fan - been following your progress from some time - great job so far :)
-
You would be surprised how often programming projects are divided into small tasks made by independent (and cheapest) individuals whom often really have no clue or barely grasp the sense of whole project due to secrecy etc
It results in such slow sluggish apps we nowadays have... also frameworks are usually sluggish (but usually not as bad in such devices).
I have some years done with huge projects. Most known is National Geographic (previous owner, not Burda) ^-^ and little bit as an admin. Sometimes there is a single person, after which I needed to spent more time to fix his code that (s)he did. It's impossible to count how many companies get broke, because of that methods with cheap workers and incredible (but heavily related) small tasks.
Just image oscilloscope, which has candy-looking buttons and borders around windows that takes half of the space available on 7'' screen. And it makes math operations on 200 MB data with scripts. More of that, sending 138 bytes to the PLL via SPI takes almost three seconds. Do You know one model like this?
-
I suppose your fav one 900 series :-DD
-
You would be surprised how often programming projects are divided into small tasks made by independent (and cheapest) individuals whom often really have no clue or barely grasp the sense of whole project due to secrecy etc
It results in such slow sluggish apps we nowadays have... also frameworks are usually sluggish (but usually not as bad in such devices).
I have some years done with huge projects. Most known is National Geographic (previous owner, not Burda) ^-^ and little bit as an admin. Sometimes there is a single person, after which I needed to spent more time to fix his code that (s)he did. It's impossible to count how many companies get broke, because of that methods with cheap workers and incredible (but heavily related) small tasks.
Just image oscilloscope, which has candy-looking buttons and borders around windows that takes half of the space available on 7'' screen. And it makes math operations on 200 MB data with scripts. More of that, sending 138 bytes to the PLL via SPI takes almost three seconds. Do You know one model like this?
it makes math operations on 200 MB data with scripts.
It's crazy. How hard could it be to optimize the math using C, C++ or Rust? :D
sending 138 bytes to the PLL via SPI takes almost three seconds.
Light speed 299,792,458m/s, earth diameter 12,756 km. 3 seconds light around the earth -> 70.5 loops on the earth. (But these 138 bytes hasn't reach yet) :-DD
-
No problem of reading 50million csv lines in python, sure. What could be an issue with those .csv files is their size :) ..
Below a histogram made upon 50MPts coming from my rigol (781MB large csv file).
-
No problem of reading 50million csv lines in python, sure. What could be an issue with those .csv files is their size :) ..
Below a histogram made upon 50MPts coming from my rigol (781MB large csv file).
As has always been.
Saving as a smaller .BIN file format has been the way to go with other brands to convert back to CSV on the PC with a converter utility download available directly from the scope.
-
Hello everyone.
I'm a new Rigol DHO804 users. I saw a several solutions hacks, sparrow app etc. in this topic. I am curious about if someone tried it before to use the DHO800 serias with an USB saleae logic analyzer. It can be possible to reroute the internal app solution UI for example if the version updated to DHO824 the logic analyzer module to work from an USB logic analyzer? It will be really helpfull because it can be extend the capability of the oscilloscope. Really thank you your answers.
-
I don't think so.
There is some hidden (disabled) USB related code, but it's rather USB bus decoding. Maybe some day I will try to make it work.
-
Because i started to thinking on it. Theoritacally if a backend module or app in android can be work and get the information from the saleae, after it need to bind it to to the UI data somehow, but i not see through clearly the UI solutions. I started to check the sparrow source code but i'm not perfect in java,android system codes. It will be good if can be solved somehow because without HW improvement can be make it work the logic analyzer with a DHO800 serias too.
Thank you the answer norbert.kiszka.
-
This is a really nice proposal.
There is an opensource project for protocol analysis called sigrok and It has Android version which can be installed to your osilloscope! https://sigrok.org/wiki/Android (here's the tutorial and source codes)
It's opensource. If it can't be installed. Try to compile 1 apk for ARM64 v8a Android 7.1 platform using Android Studio. Also be sure to embed/compile the corresponding USB kernel module something .ko or .so for pure Linux and anbox and run native Android apps on standalone Linux.
-
It's crazy. How hard could it be to optimize the math using C, C++ or Rust? :D
All three will be much much faster. But I would prefer C (and sometimes assembler), since it's fastest and I have some knowledge and experience with it.
sending 138 bytes to the PLL via SPI takes almost three seconds.
Light speed 299,792,458m/s, earth diameter 12,756 km. 3 seconds light around the earth -> 70.5 loops on the earth. (But these 138 bytes hasn't reach yet) :-DD
You can check it by Yourself: https://github.com/norbertkiszka/Rigol-tool-spi2pll_lxm2582
-
In my current development, this is not on the priority list of my changes. I think to test 1.5625 GHz, which should work without decreasing memory depth and it will give "round" time per sample of 640 ps.
It's not really much of a step up from 1.25 GHz though. Still not enough to match the bandwidth of 250MHz with 4-channels.
But I guess it's useful if you modified the front end to 900Mhz bandwidth. :-)
Probably you should push the Rigol DHO924S to 2.0GSa/s. That's because the new osilloscope from OWON ADS924A which might has the same hardware as DHO924S has been out. The ADS800A is being sold in China now.
https://www.owontech.com/digital-oscilloscopes/benchtop-oscilloscopes/ads900a-series-12bits-multifunction-digital.html (https://www.owontech.com/digital-oscilloscopes/benchtop-oscilloscopes/ads900a-series-12bits-multifunction-digital.html)
The little different between ADS924A and DHO924S is
```markdown
|Spec| ADS924A|DHO924S|
-------------------------------
|Sample Rate| 2G | 1.25G|
|AFG | 30MHz | 25MHz|
|Mem Depth| 100M | 50M|
|Math| Has user defined math | Only simple math|
|Max waveform capture rate| 700,000 wfms/s | 500,000 wfms/s |
```
ADS924A is also running on Android.
If OWON ADS924A uses the same board and ADC chips, 2.0GSa/s should be avaiable and stable.
[attach=1]
-
If OWON ADS924A uses the same board and ADC chips, 2.0GSa/s should be avaiable and stable.
Same FPGA, same DDR3 chip, same PLL and same distance from PLL?
My scope can handle 1.8 GHz (1.8 GSa/s) with memory depth limited to 15875 points. More points above that gives waveform like with some cuts from time to time (I can use 125 M, but only first 15 875 are correct). Higher freq. than 1.8 GHz gives complete pandemonium.
There are three possibilities of this: FPGA is too slow or RAM is too slow or distance from PLL is the distance is too great to handle higher frequency. Zynq 7015 has internal memory of 256 KB - maybe that is used for caching samples or there is a delay in changing pages in RAM chip.
BTW. On that image, BNC sockets at the back are kinda misplaced - DHO9xx has AFG at the top.
-
PS. Without teardown photos and/or firmware I can't do too much. I can just guess and nothing more.
If this has exact the same PCB and exact the same FPGA (eventually same or similar RAM chip) and in same time this really can do 2 GSa/a, SD card image would be really helpful.
BTW. Maybe they used different FPGA firmware?
-
Anyway, I finished one part with handling more memory depth manually. That wasn't easy, I can tell.
Now I need to do limits for more than one channel, average acquisition and LA enabled. Unless somebody want's to get corrupted data from the scope.
Edit: I added two more screenshots.
-
Does anybody know what the extra RAM chips in the DHO900 are for yet?
-
Good job by now.
Nice to see the mem depth 125M is enabled.
Yes without tearing down the Owon ADS900A, we don't know what is inside. We can only guess from the specs. Right now we don't have sources to buy ADS900A but ADS800A is being sold on taobao.com at a decent price like rigol DHO800.
Increasing sampling rate is really important. Nowadays even handheld multimeter/oscilloscope can have 1-2GSa/s. The default Rigol DHO924S 1.25GSa/s is like a joke. Even Siglent cheapest-entry-level SDS800X has 2.0GSa/s, 100M mem depth by default.
BTW, did you test the actual bandwidth of DHO924S after software unlocking the bandwidth (Max 800MHz) using Sine Wave (-3db) test? How is the performance?
-
The extra chip on DHO924S is in this thread. You can check it out by searching in the forum.
I think it's possible to replace with another bigger RAM chip on DHO800/DHO900 to reach higher mem depth. This wouldn't be harder than replacing RAM/SSD for macbook or iPhone and nowadays these are too easy.
-
Good job by now.
Nice to see the mem depth 125M is enabled.
That was the easiest part actually and I did it at least one month ago. Limiting it under certain conditions and making more mem depth options, wasn't so easy.
Yes without tearing down the Owon ADS900A, we don't know what is inside. We can only guess from the specs. Right now we don't have sources to buy ADS900A but ADS800A is being sold on taobao.com at a decent price like rigol DHO800.
Give me firmware update or better, SD card image, so I can do reverse engineering on this.
Maybe I was too dumb or too lazy to read properly PLL datasheet (https://www.ti.com/product/LMX2582). Yesterday I published a tool (https://github.com/norbertkiszka/Rigol-tool-spi2pll_lxm2582) that reads exported registers from TICSPro (https://www.ti.com/tool/download/TICSPRO-SW/1.7.6.2) and compiles tool compatible with Rigol kernel driver (simple SPI bridge (https://github.com/norbertkiszka/Linux-5.10-Rockchip/blob/develop-5.10/drivers/rigol/spi2pll_lxm2582_gpio.c)). If somebody somehow didn't noticed, I did a dump of registers being sent from Rigol tool /rigol/tools/spi2pll_lxm2582 (and timings when it was paused by this tool) in this repository (http://hhttps://github.com/norbertkiszka/Rigol-tool-spi2pll_lxm2582/blob/main/TICSPro_registers/DHO800_DHO900_original_registers_1250_MHz.txt).
With that tool, maybe somebody else will be able to figure out settings for PLL to reach 2 GHz without making pandemonium with acquisition data. Or maybe just mine scope is not able to be stable at anything above 1.8 GHz.
100M mem depth by default.[/url]
Old trick as the whole world. Limiting memory depth causes two things: less time spent on coding limits for it and better sales of higher models. Used memory chip is... cheap, so they didn't have any reason to change it to 2Gb.
BTW, did you test the actual bandwidth of DHO924S after software unlocking the bandwidth (Max 800MHz) using Sine Wave (-3db) test? How is the performance?
Long time ago I tested it with simple and unstable generator (exact frequency depends on the moon phase and number of rabbits in Australia) which had around 400-450 MHz. In CH4 which is without filters, measured Vpp was exactly as the power supply. At overclocked PLL to the 1.8 GHz, rise time was much lower than time of one sample (555 ps). Same AFE and ADC is used in DHO4000 and it has 800 MHz with LC filters... I'm almost 100% sure they used same chips in 1 GHz models (DHO5000 & MHO5000).
I think it's possible to replace with another bigger RAM chip on DHO800/DHO900 to reach higher mem depth.
Not without hacking the app. Maybe also FPGA... but I didn't tested it yet.
-
Ok, so I made it to the point, where I made it stable and usable probably for everyone. I almost lost all my hair because of this.
New features in v0.1:
- 125 M points memory depth for single analog channel (50 M in the original Rigol app).
- 62.5 M points memory depth for two analog channels (25 M in the original Rigol app).
- 31.25 M points memory depth for three or four analog channels (10 M in the original Rigol app).
- 31.25 M points memory depth for Logic Analyzer with or without single analog channel (25 M in the original Rigol app).
- 12.5 M points memory depth for Logic Analyzer with two analog channels (10 M in the original Rigol app).
- 10 M points memory depth for Logic Analyzer with three or four analog channels (1 M in the original Rigol app).
- Same memory depth limits applies for auto memory depth setting (1 M in the original Rigol app in each case).
- 18 memory depth manual options (8 in the original Rigol app).
- Improved and more ergonomic GUI.
- Space for windows (single waveform window at default settings) is increased up to 91% of screen height.
- Acquisition parameters now are displayed as white on black with little bigger and more visible font.
- Smallest fonts in various places are now bigger, with some exceptions.
- Windows background (waveform, math, etc) is now changed to real black instead of dark gray, which increases readability of waveforms and other data which is actually displayed.
- Vertical scale now goes down to 100 uV / D (1x probe ratio). Same as in the higher and more expensive series DHO4000.
- System date and time now are always displayed at the right bottom corner.
Features from v0.0.1:
- Removed sinc interpolation.
- No bandwidth limit from the software side (250 MHz normally and about 1 GHz after removing physical LC filters between AFE and ADC).
- Horizontal scale down to 800 ps / div (one div per sample).
- I2S trigger / decode.
- CAN & CAN FD trigger / decode.
- FlexRay decode.
- MIL-STD-1553 trigger / decode.
As in the previous version, there is no need to change vendor.bin or RKey.data.
Get it from here: https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-normal-1694869 (https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-normal-1694869)
Or from here: https://www.patreon.com/checkout/NorbertKiszka?rid=25898435 (https://www.patreon.com/checkout/NorbertKiszka?rid=25898435)
30% off code for this forum: EEVBLOG
Edit: I decided to make this into four versions:
- Free - some improvements and fixes.
- Demo/Light - some more improvements and fixes.
- Normal - much more improvements and fixes. Personal usage.
- Ultra - professional usage. Earliest updates. That will be someday, when I will done it.
-
- Removed sinc interpolation.
Is it hardcoded or selectable?
-
- Removed sinc interpolation.
Is it hardcoded or selectable?
Currently hardcoded. Eventually as for now, I can do separate app with sinc interpolation and the same everything.
-
Regarding Sparrow extended V0.1
You did a great job. Congratulations.
Sorry, I don't see - the selected ratio of the X1, X10... probes is displayed?
Has the Rigol bug been fixed, to remember the selected total brightness of the display after turning it off?
My model is DHO804. Will the generator and LA control disappear or are they hard-coded?
-
Sorry, I don't see - the selected ratio of the X1, X10... probes is displayed?
Not currently. I stared doing this feature, but coding in Smali and Android layouts is way harder than coding in Assembly, at least for me. That's why I decided to put this into later and this will be as a free update if You purchased v0.1. Likely also other features in the same update - probably increased waveform update rate if this will work in every case - eventually this will be easy to enable/disable by removing or adding single file with adb.
Has the Rigol bug been fixed, to remember the selected total brightness of the display after turning it off?
I didn't change anything around it. Probably I will take a closer look if I will be able to reproduce this bug and fix it. I can't tell how long it will take, since I don't have the source code and knowledge or documentation from the original developers.
My model is DHO804. Will the generator and LA control disappear or are they hard-coded?
Currently it depends of what You have in vendor.bin. Lately I considered to enable those two no matter what's in the file vendor.bin, which likely should work after few small changes. Signal generator can be even made from a couple resistors like a COVOX and eventually a single opamp (also 50 ohm output resistor). LA socket as far I know can be added if You make a hole in the front cover.
You did a great job. Congratulations.
Nice to hear that's useful to someone :)
-
My model is DHO804. Will the generator and LA control disappear or are they hard-coded?
Currently it depends of what You have in vendor.bin. Lately I considered to enable those two no matter what's in the file vendor.bin, which likely should work after few small changes. Signal generator can be even made from a couple resistors like a COVOX and eventually a single opamp (also 50 ohm output resistor). LA socket as far I know can be added if You make a hole in the front cover.
Yesterday I installed Dave DHO800 SD card image with his vendor.bin and RKey.data. After installing my modification v0.1 (same apk file as released), somehow LA and AFG options appeared, which they theoretically shouldn't. I think I will hardcode those options to always have it - just to be consistent in every case.
Maybe also I will get rid of parsing those files completely. Who needs to know serial number from the software side? That should decrease app boot time in exchange.
-
The Histogram - another area for an improvement.. I've been playing with it as it seems it works well for my experiments. What I can see as an "issue" is the way how to setup it. From time to time I get a rectangle which I can resize across the area of my interest (the voltage x time region where it counts the pulses for example), but most of the time I cannot get it setup properly (ie. via the numerical input). Also it has got the max height of 4divs only. Perhaps a separate window would be handy.
-
I just found a bug in versions v0.0.1 and v0.1 with a particular (probably not likely for a long term usage) acquisition settings.
With some settings, waveform and LA data (if LA is connected and enabled) can freeze from time to time or completely.
IMPORTANT: data from acquisition does NOT seem to be corrupted in any way. It just freezes.
Two possibilities to replicate this bug:
- Time base 2 ns / D or lower and in the same time: 3 or 4 channels enabled or 2 channels and LA enabled.
- Time base between 2 ns and 5 ns wasn't tested. 5 ns and above works as it should (no waveform freezing at all).
Lower memory depth causes to freeze waveform more often or completely. Highest mem depth settings makes it very rare and usable.
When waveform is frozen, app is little laggy, but otherwise it works correctly and every setting can be changed - like a higher time base, which solves the issue (5ns/D or more).
When LA is connected, but not enabled, disconnecting it makes no change.
Workarounds for users (chose one of those or more as You like):
- Increase time base to at least 5 ns / D. That solves this issue completely.
- Use not more than two channels and not more than one when LA is connected and enabled.
- Increase memory depth to one of the highest possible settings. With highest mem depth settings, freezes are rare and it lasts for a very short time (like a half a second or shorter).
My current suspicions:
- Bug that I did.
- Bug that Rigol did but it was hidden and it happens because internal (hardcoded) settings was changed by me (similar issue happens when I tried to make "odd" memory depth options like 150 pts, 1.5 M pts or 14 pts - number of points is used to calculate sample rate and they made this calculation in a very lazy method - and not only that...).
- Bug in a FPGA (firmware or physical).
- FPGA firmware wasn't designed/tested to handle such settings (likely hack with disabled sinc interpolation).
If I will find that is caused by a change that removes sinc interpolation (linear instead) and it can't be fixed or be possible to do workaround, I see four possibilities in the next release:
1. App will have added code, that will increase the lowest possible time base limit for a such settings (it will switch time base automatically if needed and likely notification will appear at the center of the screen).
2. Added setting for a interpolation: sinc/linear or maybe sinc/linear/dot.
3. Both changes described in pt. 1 and pt. 2, but the limit will not be changed for the sinc int. and maybe also not for the dot mode.
4. Separate two app versions: one with a sinc and one with a linear interpolation with a code as in pt. 1.
Which one of those will be chosen, it depends on the further investigation and possibilities, which are limited due to lack of the source code. I can tell that first an last options are the simplest for me to do.
Edit: I wrote point 4. completely opposite that I mean - now it's corrected.
-
In the app there is a built in server for a "UltraLab" software. I found Chinese Rigol page (https://mall.rigol.com/item.html?item_id=826), where it's mentioned that they were selling it for 100000.00 ￥ (13,900.43 USD) but not anymore.
I think I will wipe this out for exchange to better app performance.
-
Couple screenshots from my current work.
Also I measured waveform update rate (normal acquisition and 10 kpts) between 40 k and 67 k with average around 55 k.
-
Good job. I see more protocols have been added/unlocked which is so cool!
Did you test the decoding USB2.0 at 480Mb/s? How's the performance? What will it show?
Is the sample rate 1.25GSa/s too low for this. I remembered you said your DHO924S can be stable at around 1.8GSa/s (theortaically at 2.0GSa/s) at a low mem depth.
-
Good job. I see more protocols have been added/unlocked which is so cool!
Those were originally compiled, but hardcoded to disabled. So normally even If You had the best vendor.bin, RKey.data or whatever, You will not have it.
Some or all of those "new" decoders may not work properly or at all - looks like there is no full coverage in code, like a max and min threshold levels that You can set - in this case there is a input, so You can chose whatever You like, as long it's black (I mean 0 V). In such case, I need to add or change some code - likely stolen from a DHO4000.
Believe or not, there is a code for even more decoders and triggers, but that will not be easy to make them work - more or less.
After necessary fixes, each of those must be tested. Probably it's a old code, maybe with some bugs (pretty normal with the Rigol software tho). Comparing this with firmware of DHO4000 and other scopes will take some time.
Did you test the decoding USB2.0 at 480Mb/s? How's the performance? What will it show?
I didn't test any of those decoders in practice. Too lazy... Maybe later. Personally I like the idea to have USB decoding - sometimes it can be really useful, since it's everywhere of course.
You will not believe how many things can be done with this app. There is a lot of code that was compiled. Only time and coffee are the limits here. I wish I had source code of this. Anyway, I can't do everything in one day, because 99% of my work is done in Assembly.
Soon or later, I will recreate this app from scratch - that will extremely speed up development. Coding in Smali and Assembly is not effective - very simple changes can take hours or even days after small and simple mistake.
Is the sample rate 1.25GSa/s too low for this. I remembered you said your DHO924S can be stable at around 1.8GSa/s (theortaically at 2.0GSa/s) at a low mem depth.
At 1.25GS a/s probably it will generate false readings from time to time (around 2.6 sample per pulse). At 2 GSa/s (4.1 per pulse) it should work I think.
Anyway, couple days ago I "succeed" to put this into 2 GSa/s, but there were random spikes added to the waveform, which were shorter than the time of one sample. Obviously those spikes comes from the app, not from the hardware. Lately I found some fragments that probably can be changed to get rid of those spikes.
But first things first - now Im working with the user selectable bandwidth limits (filters in AFE). Currently 20, 70, 100, 125 are working (maybe also 200 - I remember it was working and now it's not...), but that's kinda not much options - at least for me. Something around 250 and 400 would be nice - in that case I will be able to do auto bandwidth option (all options for each channel separately) - lower sample rate will change bandwidth to lower and inversely. I think at least 200 and 250 are possible (DHO4000 has 250 setting - but I don't want to copy huge amounts of code - at least for now).
BTW. I wonder how many users would wan't to have 250 Mpts memory depth. Theoretically it can be done, since 4 Gb chip gives space for 256 M pts. Currently I can easily change 125 M to 128 M (or maybe 2 ^ 27), but I didn't want to fix one Rigol bug just for those 3 Mpts extra - maybe I will one day - 128 M can be divided by 2 many times and that's pretty useful. Hacking for the 250 M pts (or 256 M) will take some time without any warranty to success (FPGA firmware which I didn't touch yet).
-
from practice you need like 4-5 GS/s and 2 GHz scope to really start with issues with USB2.0 otherwise you may (or not) see only big problems
(and that also is a useful thing, I agree but here it would be a bit too much approximation in my opinion)
and still pretty "blind" compared to what 10 GS/s and more bandwidth scope will reveal almost instantly
-
2 GHz
DHO800/DHO900 can do 1 GHz, maybe little more.
-
2 GHz
DHO800/DHO900 can do 1 GHz, maybe little more.
you know with twice the sampling freq (and here with all frontend limitations and lot of wishful thinking too) we perhaps will see some sine signal or a bit distorted sine cause we do not have enough harmonics to have something more (thus they usually use those big, fancy and crazy priced scopes for that) :/
-
2 GHz
DHO800/DHO900 can do 1 GHz, maybe little more.
you know with twice the sampling freq (and here with all frontend limitations and lot of wishful thinking too) we perhaps will see some sine signal or a bit distorted sine cause we do not have enough harmonics to have something more (thus they usually use those big, fancy and crazy priced scopes for that) :/
I never said that AFE doesn't add harmonics. Every analog path adds and removes something from the signal. In the case of this series, analog path is quite good for this bandwidth. Did You tried to remove LC filters (You can do it for one channel and bring it back any time) in it and see how it works without sinc interpolation?
Anyway, we were speaking about decoding, not full analysis as it should be done at the production site. Obviously this ("hidden") code is a copy from the higher Rigol models.
-
actually on that part we both are on same page - I only noted that we cannot overjump physics/rules
yeah it would be good to test it but rn I do not have a possiblity as nobody knows whom actually put hands our on 914s... :-DD
we got early version and it was so buggy that it was circuling around to find it a new home since then and I asked friends whom has it cause I need it for few days (wanted to try your software) and nobody knows... good thing it was cheap :-//
-
we also were thinking about possible firmware solutions to 4000/5000 series when you work that project a bit more but sadly since they went out not any better (we tested also 5000 model) and lost any remaining hope that Rigol is doing something in good direction :(
-
I'm stuck trying to install an alternative Sparrow.apk on my DHO804 (already upgraded to DHO824 by switching vendor.bin). It's my first time using Android so maybe I'm doing something wrong. This is what I'm trying with FW01.04 installed :
adb root
adb shell
am force-stop com.rigol.launcher
am force-stop com.rigol.scope
exit
adb uninstall com.rigol.scope
Success
At this point the scope automatically relaunches com.rigol.scope but this time it's fallbacking to the original 01.03 application?! Subsequent uninstalls produce errors:
adb uninstall com.rigol.scope
Failure [DELETE_FAILED_INTERNAL_ERROR]
I'm not sure how to proceed, maybe someone had this error previously?
-
Try this:
adb root
adb shell
pm uninstall --user 0 com.rigol.scope
mount -o rw,remount /system
rm -rf /data/app/com.rigol.scope-1
rm -rf /data/app/com.rigol.scope-2
rm -f /rigol/app/Sparrow.apk
rm -f /data/dalvik-cache/arm64/system@app@Sparrow@Sparrow.apk@classes.dex
sync
reboot
-
It seems to uninstall for root but not for other users?
rk3399_rigol:/ # pm uninstall --user 0 com.rigol.scope
Success
rk3399_rigol:/rigol/app # pm uninstall --user 0 com.rigol.scope
Failure [not installed for 0]
rk3399_rigol:/rigol/app # pm uninstall com.rigol.scope
Failure [DELETE_FAILED_INTERNAL_ERROR]
I can't install afterwards:
pm install --user 0 Sparrow_1.04_repacked.apk
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.rigol.scope signatures do not match the previously installed version; ignoring!]
-
Did You try exactly as I posted previously?
-
Yes, here's the full log:
das ~/Documents/workspace/rigol/platform-tools adb root
restarting adbd as root
das ~/Documents/workspace/rigol/platform-tools adb shell
rk3399_rigol:/ # pm uninstall --user 0 com.rigol.scope
Success
rk3399_rigol:/ # mount -o rw,remount /system
rk3399_rigol:/ #
rk3399_rigol:/ # rm -rf /data/app/com.rigol.scope-1
rk3399_rigol:/ # rm -rf /data/app/com.rigol.scope-2
rk3399_rigol:/ # rm -f /rigol/app/Sparrow.apk
rk3399_rigol:/ # rm -f /data/dalvik-cache/arm64/system@app@Sparrow@Sparrow.apk@classes.dex
rk3399_rigol:/ # sync
rk3399_rigol:/ # reboot
-
Try to change header of the file AndroidManifest.xml to this:
<?xml version="1.0" encoding="utf-8" standalone="no"?><manifest xmlns:android="http://schemas.android.com/apk/res/android" android:compileSdkVersion="29" android:compileSdkVersionCodename="10" package="com.rigol.scope" platformBuildVersionCode="29" platformBuildVersionName="10">
Eventually, if You want 125 M pts memory depth and couple more things, You can try this mod: https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-normal-1694869 (https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-normal-1694869)
-
It refuses to install anything that hasn't Rigol's signature regardless of the manifest since the old package isn't properly removed.
Eventually, if You want 125 M pts memory depth and couple more things, You can try this mod: [url]https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-normal-1694869[/url]
Well that's more or less what I was looking at, it seems that the app does support 125Mpts on 1 channel and then 62.5 on 2 and 31.25 on 3/4 for both HDO800 and HDO900 (points to the same config) in some structures at the end of libscope-auklet.so but somehow these are never used.
-
Did You try to copy this header (AndroidManifest.xml) from me? It should work.
However once I had some problem. I don't remember what it was, but I changed:
package="com.rigol.scope"
to the:
package="com.rigol.scope2"
-
both HDO800 and HDO900
This mod doesn't care what model You have. Rules of memory depth are listed. Those limits was tested to be working correctly, including LA in DHO900.
-
Did You try to copy this header (AndroidManifest.xml) from me? It should work.
However once I had some problem. I don't remember what it was, but I changed:
package="com.rigol.scope"
to the:
package="com.rigol.scope2"
It fails later on because of a conflict since the real com.rigol.scope is never properly uninstalled. Seems I'm the first with this problem :)
Attached are the structs that contain memory depth options that seemed to be initially supported by Rigol (but never actually used).
-
That struct is for the sample rate modes as far as I remember.
Try to install original apk (1.04.02) back in.
After that, uninstall it with
pm uninstall com.rigol.scope
pm uninstall --user com.rigol.scope
Personally Im more familiar with the "original" Linux/GNU than modified Linux with the rest of the Android . For me, Android is kinda like Windows - sometimes it works and sometimes it doesn't. But I think more likely You had done something wrong.
-
It refuses to install anything that hasn't Rigol's signature regardless of the manifest since the old package isn't properly removed.
You can patch the system to accept the rigol system user: https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions/4
-
Well now it's just stuck on the Rigol screen and doesn't fallback to Sparrow 01.03 anymore :-//
ADB still works though. Are there helpful logs besides logcat to understand the problem?
-
That's normal when there is no scope app installed. Rigol launcher is very simple and it doesn't create desktop like on the phone/tablet. You can install any other launcher that can work on Android 7.1.2.
Now try to install modified app.
-
OK I've managed to recover a working scope after fiddling for an hour. This concludes my adventure trying to mode this scope. :scared:
If someone has the same problem someday the very last thing I did was uninstall + place original /rigol/app/Sparrow.apk back (so you know, save it first) and reboot, it fell back to 1.03 and I was able to re-upgrade to 1.04. Thanks for the help but I'm stopping here, can't risk losing the scope.
-
Even If You don't have backup of the image of SD card, there are couple images on this forum.
Anyway, I have plans to do my next upcoming mod as a .GEL package, so adb and all that staff won't be needed - unless You don't have any usb flashdrive.
-
4 Gb chip gives space for 256 M pts
Yes, it's useful. Just use all the RAM there. That's the meaning of rebuilding this app. more pts can be useful when capturing complicated signal for decoding or recording purposes, which means that the signal generator (AFG) can make signal based on the captured signal more precisely.
Yet about protocols, you are right that some protocols like USB is very universal. It's very very useful even though it can only reach upto USB 2.0.
Packing the file in a zipped .GEL file is wise since it won't break anything and it's easy to maintain. Sometimes it can be very handy to switch back to the original app.
You said your DHO924S now runs at 2GSa/s without problems only with some software-level spikes in the wave window. Probably there is something math/methods about dealing with points inside the original app can be tunned.
Owon ADS924A (Android 7.1, 2GSa/s) is released now on taobao.com
Good job by far! 👍
-
Good job by far! 👍
After some really boring and painful tries to understand decompiled code and observations of raw communication with AFE, I found how to enable two more low pass filters. Exactly 400 MHz and 600 MHz. I know there are also at least 200 and 250 somewhere...
Optional auto bandwidth limit driven by current by sample rate should be useful I think.
-
.line 7342
const-string/jumbo v3, " signatures do not match the "
.line 7341
invoke-virtual {v2, v3}, Ljava/lang/StringBuilder;->append(Ljava/lang/String;)Ljava/lang/StringBuilder;
move-result-object v2
.line 7343
const-string/jumbo v3, "previously installed version; ignoring!"
https://www.youtube.com/watch?v=2nhHUvMA0d0 (https://www.youtube.com/watch?v=2nhHUvMA0d0)
-
I created a AWG daughter board:
https://www.eevblog.com/forum/testgear/awg-function-generator-for-dho800-900-series-oscilloscopes/ (https://www.eevblog.com/forum/testgear/awg-function-generator-for-dho800-900-series-oscilloscopes/)
Created a new thread to prevent overloading of this one here.
-
Successfully hacked a DHO804 to a DHO824. Just wanted to outline what worked for me for any other nooboids like myself. I was initially looking for tools that ran under MacOS but abandoned this in favour of using Windows 10.
(1) Opened up the scope, peeled back the black tape and removed the uSD card. Put that in a card reader and used HDD Raw Copy Tool to make a backup image of the original factory supplied card. This came with Firmware 1.03. The original uSD card in the scope was a Lexar 32GB V10 633x
(2) Purchased a 32Gb V10 uSD card (different brand) and attempted to clone the card to this with the image made in (1) using HDD Raw Copy Tool. Imaging failed due to a write error (tried twice). Did a long reformat of the card from Windows and tried again. Imaging completed successfully but when I attempted to boot the scope with this card I was presented with Android asking me for login credentials. Abandoned using this card.
(3) Purchased a 2 pack of the identical Lexar cards and made a clone of the original card from the image made in (1). This worked and the scope booted from it. Repeated the process for the other blank Lexar card and retained the original card unaltered. Upgraded both cloned cards to Firmware 1.04, and ran calibration with both.
(4) Downloaded Minimal ADB Fastboot 1.4.3 (Portable).zip from androidfilehost.com and also the rigol_vendor_bin.exe (v1.3) from the zelea2 GitHub repository. Pulled vendor.bin and RKey.data from the cloned card with ADB. Ran rigol_vendor.bin.exe with the switch -M DHO824, and then pushed the modified vendor.bin (was .enc) back to the scope. Scope booted as DHO824 and showed 50M points available. Bandwidth now declared as 200 MHz in About menu. Reran calibration routine.
(5) Attempted to quantify the bandwidth response between using the DHO804 uSD card and the modded DHO824 card. Used a TinySA as a sine wave generator set to output at -7 dBm and connected to the scope with the supplied SMA coax, an SMA to BNC adapter, and a 50R BNC passthrough. -7 dBm into 50 ohm should be 282.5mV PP and this was very close to what the scope was measuring at 1MHz, so assumed 0dB at this voltage. Measured Vpp at 1 and 5 MHz and thereafter at 10MHz intervals for both the DHO804 and DHO824 cards and graphed the results (chart attached). There may be a degree of impedance mismatch as I am not sure what the characteristic impedance of the SMA to BNC adapter is (having revisited the amazon listing it usefully says '50ohm/75ohm'). However I don't see any significant reflection induced amplitude swings with frequency so I am assuming the match is half decent.
(6) One thing that I did notice is that when I change the vertical scaling of the trace, the Vpp reported by the Measurement widget can change value quite significantly (like by 20%). Should it not remain roughly the same regardless of scale? Consequently I made all the measurements using the same vertical scale (that picked by Auto at 1 MHz).
-
(6) One thing that I did notice is that when I change the vertical scaling of the trace, the Vpp reported by the Measurement widget can change value quite significantly (like by 20%). Should it not remain roughly the same regardless of scale? Consequently I made all the measurements using the same vertical scale (that picked by Auto at 1 MHz).
Did you hear a relay click when you changed the vertical scale? That relay changes the path of the signal at some point depending on the selected vertical range, and the input capacitance can be slightly different between those two paths. In my case it's measurable (~0.5 pF difference IIRC) and is manifested, for example, as an under- or overcompensated probe depending on which range it was adjusted on after the range is switched.
I'm not sure if that would result in such a big difference in the measured Vpp though.
-
Successfully hacked a DHO804 to a DHO824. Just wanted to outline what worked for me for any other nooboids like myself.
Almost none of that was necessary.
You just need to change one file on the internal storage, you can do it with a network cable without opening it up.
(6) One thing that I did notice is that when I change the vertical scaling of the trace, the Vpp reported by the Measurement widget can change value quite significantly (like by 20%). Should it not remain roughly the same regardless of scale? Consequently I made all the measurements using the same vertical scale (that picked by Auto at 1 MHz).
Did you do a self-cal first?
-
Did you hear a relay click when you changed the vertical scale? That relay changes the path of the signal at some point depending on the selected vertical range, and the input capacitance can be slightly different between those two paths. In my case it's measurable (~0.5 pF difference IIRC) and is manifested, for example, as an under- or overcompensated probe depending on which range it was adjusted on after the range is switched.
I'm not sure if that would result in such a big difference in the measured Vpp though.
No I don't hear any relay switching. I had a cursory look at the phenomenon yesterday and it seems to be most pronounced when the signal frequency is close to or beyond the bandwidth limit. Seems to do it with the original 1.03 firmware as well. I will try and get some screenshots today.
-
Almost none of that was necessary.
You just need to change one file on the internal storage, you can do it with a network cable without opening it up.
Did you do a self-cal first?
Yes I can understand that it was not necessary now. Replacing an edited vendor.bin in /rigol/data/ with ADB would have sufficed. I just wanted to do all edits on a working physical clone in case I corrupted the card. I understand if I did break the card I could then have taken the image from the first post and cloned that as a starting point, but I already ran into difficulty cloning an image to that first 32GB V10 uSD I bought. I looked at that card again yesterday and HDD Raw Copy Tool reports it has a different number of sectors from the Lexar one, so perhaps that caused an issue? I have no idea. Anyway that was the route I felt most comfortable following. But I agree, totally unnecessary if you are 100% sure you know what you are doing.
After creating the two 1.04 cards, I checked they booted the scope and ran the self calibration routine. After I then replaced the vendor.bin on one of them, I checked it booted and reran the self calibration routine.
-
Three days ago there was a international day for a electricians and today we have friday 13th. Jokes aside, I just released v0.2.
New features / bug fixes:
- Fixed issues with the installation.
- Fixed bug (v0.1) that in some cases can cause a crash when app is starting up.
- Two installation methods. One with a fully automated and human friendly posix compatible script and manual.
- Probe attenuation ratio visible at the bottom for each channel.
- Added trigger FlexRay (previously only FlexRay decoding).
- 20 MHz bandwidth filter is no longer forced when real scale is anywhere below 1 mV / D.
- App no longer reads vendor.bin.
- Model, serial number and licenses are hardcoded (DHO924S).
- AFG, LA and four channels are always available - even if the app was installed on the 2 CH scope.
- Added AFE bandwidth filters that can be selected manually for each channel:
- 70 Mhz
- 100 Mhz
- 125 MHz
- 400 MHz
- AFG now can go up to 50 MHz for the sine wave.
- Bode plot can operate up to 50 MHz.
- Possibility to change any app into system app and the opposite (previously it caused an error).
- System will now allow to install older versions of apps than previously installed.
- Added experimental decoders (not tested):
Things possible only when installing by using attached script (instead of manual installation):
- Oscilloscope app will be executed only once after system boot. Previously, when user closed scope app or it crashed for some reason, it was started back again or it was brought to the front, which could be annoying when using other apps.
- Automated backups before installation.
- Timezone automatically set to Your local timezone.
- Increased system performance which results in more waveform updates per second.
- Basic configuration of Nova, unless it was previously installed.
- /system directory now is writable by default.
- Boot time (from power on to fully working scope app) decreased to 50s (without Nova Launcher it should be couple seconds less).
- Install script can work even if there is more than one Android device connected.
- Script will stop installation only on serious errors. Anyway, it can be re-run again any time.
- Added Nova Launcher (Android desktop).
- Added Android navigation bar. It can be swiped out and swiped back in any time - USB keyboard is no longer needed to switch between apps.
- Optionally, You can configure nu.nav.bar (using icon Navigation Bar in Nova menu) in order to have better and more configurable navigation bar. In the exchange for a little bit of system performance.
- > 60 000 waveform updates per second with 10 kpts and time base 50 ns/D or lower.
- Script can be executed from any working directory.
- Script can run on any POSIX capable operating system (Linux/GNU, BSD/GNU, Mac OS, etc).
- Update possible from any firmware previously installed (previously 00.01.04.00.02 was required).
- Added safe web browser called DuckDuckGo.
- Possibility to change system boot logo to a custom one.
Know bugs:
- When time base is set to 2 ns / D or lower and some other conditions are met, waveform can freeze from time to time or completely. Details: https://www.patreon.com/posts/bug-in-versions-130248117 (https://www.patreon.com/posts/bug-in-versions-130248117)
- When memory depth is above 62.5 Mpts, signal has very low frequency (10-100 Hz), acquisition mode is normal, there are some points outside of screen, stop button was pressed (stop, not single shot) and time base was changed, it sometimes results with corrupted rendering of a waveform. Workarounds: use single shot or use lower memory than 100 M or don't change time base with this settings.
Anyone who purchased v0.1 can download v0.2 for free. (https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-normal-1694869)
By the way, in the third screenshot, at the test was a probe from Rigol (PVP2350) at x1 as they supplied it with mine DHO924S.
-
I did a "stupid" experiment with disabling waveform rendering and beside of no waveform (pretty expected), measured waveform update rate exceeded 70 k. I guess this can be useful when this will be used only as a scpi measurement tool.
-
Hello,
A couple of questions:
1. Does your firmware version do anything to fix the problem of the logic analyzer function not being useful for slow logic signals? This is one of the reasons I have not purchased the logic analyser cable set.
2. I assume that I can reload and use/return to the standard Rigol firmware at any time without any issues?
Thanks for an interesting project.
Sam
W3OHM
Sam
-
not being useful for slow logic signals
To be honest, I don't know what You mean by that. I have DHO924S, but my tests with LA and increased memory depth was done with a fake probe (piece of wire to short two pins in LA socket) and test "signal" from floating inputs was good enough to see if memory was overwritten or not.
I assume that I can reload and use/return to the standard Rigol firmware at any time without any issues?
In current package, there are two instructions how to install it.
One is manual, which changes only one system (Android) file, because it fixes problems with the installation - and it changes only that.
Second one (or maybe first?) is with help of the script which makes backups and more changes to the system to make it more efficient / faster boot and also changes boot logo. However I didn't made a script to revert system changes - which can be done manually if You know how.
With both methods, original app can be brought back just by installing it via adb:
adb install -r Sparrow.apk
Where Sparrow.apk can be brought from the backup files or extracted from Rigol firmware update .GEL file.
BTW. About 15 minutes ago I just succeed to make properly working 2 GSa/s (even 2.1 GSa/s which is theoretically close to DDR memory bandwidth limit) after about 20 hours of work... On this screenshot there is a huge voltage offset (-0.5 V) because I temporarily changed ADC registers (which are likely not needed for 2 GSa/s, but I didn't know that earlier). I need to spent at least the same amount of time to make it fully usable with all possible settings.
-
Hi,
I'm not in the market for a 'scope, but if I were (I have occasionally considered buying a small oscilloscope for portable purposes), unfortunately the screenshot is quite bad. I'm only mentioning this because whenever I look at these 'scope screenshots on this thread, they often seem to have the same problem.
The problem is, from those screenshots, I cannot tell much about the signal, which is supposed to be the whole point of the oscilloscope. There is either no triggering, or the timebase is set incorrectly, is it supposed to be a square wave?
Next, the spectrum view is difficult to use, because it's not possible to read the frequencies. I get the idea to have the legends in the same color as the output for the oscilloscope channels in the time-domain view, but it makes less sense for the spectrum view - or at perhaps, have them in the foreground with a black opaque or translucent filled box around them, or make the grid clearer (lines, not dots!) and fix the top labels because I can see that the center is 312.5 MHz, but the span not possible to read. Also, you could indicate the start/stop frequencies if possible too (could be overlaid at the bottom left and bottom right of the spectrum view, or take a look at any spectrum analyzer and borrow some ideas from there). I'm just throwing ideas out there, but it think it merits more thought, and some planning. If you take a look at older spectrum analyzer displays, you'll see how they were very efficient with low-res displays.
And no need to have four significant digits as well as the text 'dBV', it could be just one decimal place, and indicate 'dBv' elsewhere, e.g. just at the first grid line at the top. And again, really no need to color-match it. It could just be white or light-gray and then it might be readable.
One other thing - the peak search table could be reduced in size, to (say) default to just 4 values, that's usually more than enough to see your fundamental and the first few harmonics, and people could then choose to view more if they wanted (or have a scroll bar for that, so only the first few are visible). A smaller table would allow that spectrum view to become larger. Also minor thing, but the style of that table looks very out of place compared to the rest of the screenshot.
-
The problem is, from those screenshots, I cannot tell much about the signal, which is supposed to be the whole point of the oscilloscope. There is either no triggering, or the timebase is set incorrectly, is it supposed to be a square wave?
This is a square wave with frequency of 12 MHz from quartz. This scope for the all measurements originally uses data not directly from ADC, but somewhere from the middle of the screen processing. That's exactly why I set time base to 50 us / D.
the spectrum view is difficult to use
Waveform and "Peak Search" windows can be closed - then You have full screen width (minus literally two pixels) for the FFT.
I changed settings of the FFT to cover full sample rate.
And no need to have four significant digits
For some that can be very useful. Adding another setting for this is time consuming, especially when there is no source code. Beside of making hundreds of not very useful settings that later You need to scroll just to forget of what You where looking for...
One other thing - the peak search table could be reduced in size, to (say) default to just 4 values, that's usually more than enough to see your fundamental and the first few harmonics, and people could then choose to view more if they wanted (or have a scroll bar for that, so only the first few are visible). A smaller table would allow that spectrum view to become larger. Also minor thing, but the style of that table looks very out of place compared to the rest of the screenshot.
Currently Im working with compiled binaries (with some tools) instead of source code as it should be. You can ask Rigol for files with source code - likely they will ignore You and You will get no response at all - don't ask why I know that.
I can do whole (much better) scope software from scratch based on current knowledge and little bit more of reverse engineering, but that will take months to complete anything useful. As for now, I don't see too much people running to support me with that.
-
Thanks for the detailed response. I didn't know the extent of what was feasible or practical in a reasonable timeframe, but now it's clearer. In any case, the spectrum full screen option that you mention probably helps a lot.
-
You could get the frequency values of the peaks using an external application, as shown in the video taken from the screen of a DHO804:
https://www.youtube.com/watch?v=mO99S1H-xRQ (https://www.youtube.com/watch?v=mO99S1H-xRQ)
-
@norbert.kiszka I installed the v0.2 normal edition of your firmware and its working well on my DHO814 (I used the installation script that worked perfectly on the first try). My main motivation was the increased memory length (125M from 50M!!). Initially I though something was wrong because the upper icons were squished, but then I noticed from your screenshots that it was expected as a measure to save screen space and difficulty editing the android app assets, and that's OK (I can only image the effort and headaches that came from modifying the app without the source code! 8)).
So far almost everything is working well. The only thing that I can´t do is to access the Rigol web control: I have already removed and added the connection and I can ping the oscilloscope, but the web connection is refused (already rebooted many times, take out the dongle, reconfigure WiFi at Android level, but nothing). Did you experience anything related?
@mrisco I can see that you created an improved UI for the original firmware. Just to confirm: it is totally a different project from norbert.kiszka, right?
-
@mrisco I can see that you created an improved UI for the original firmware. Just to confirm: it is totally a different project from norbert.kiszka, right?
Yes.
There's now three different ones to choose from...
-
@mrisco I can see that you created an improved UI for the original firmware. Just to confirm: it is totally a different project from norbert.kiszka, right?
Yes, it is different:
https://www.youtube.com/watch?v=mT4ivaMY7zg (https://www.youtube.com/watch?v=mT4ivaMY7zg)
-
@norbert.kiszka I installed the v0.2 normal edition of your firmware and its working well on my DHO814
Good to know. Smallest information about problems or no problems at all are valuable to me, since this is no longer an experiment. With tools which Im using to do this, any information can save me many days of work. Especially with the DHO800 series - I have DHO924S, not any 800. I bought it little bit by accident, because I didn't have too much time to chose back then.
I used the installation script that worked perfectly on the first try
One week of work to make it possible to run on a cheapest toaster :) Probably it will also work on a Android, but I didn't make such a test yet.
Initially I though something was wrong because the upper icons were squished, but then I noticed from your screenshots that it was expected as a measure to save screen space and difficulty editing the android app assets, and that's OK (I can only image the effort and headaches that came from modifying the app without the source code! 8)).
With the source code, some changes that I made, should be done in like 5 minutes (including 4 m 30 sec for coffee) instead of 5 hours or more... Since scope is using a lot of GPL licensed code that requires to give source code for anybody who asks for it, I asked Rigol only for a kernel with modules. They made a promise for that in attached document (which You can read directly from the app) and yet they ignored me from top to bottom. That didn't stop me from making my own Linux kernel with the drivers for their own chips :)
Rigol deliberately made this scope much much worse than it is in reality, because they have better money from You, when You buy any higher model. Im 100% sure that Rigol owners don't have completely any knowledge about software engineering and they struggle when they need to find one button to turn on a computer or to make a call with the phone. Sadly it's typical with the other test equipment and many other things.
Speaking of, there was (still is) widely known in the world case in my country, where one of the biggest train manufacturers, made a "protection" that prevents from servicing it in other places than owned by them. And they did some code that disables engines when there are days and months after some year (likely their software "engineers" didn't know how to lock the train after given date - even worse job than that done by Rigol). And some Polish software hackers was called and they reverse engineered those trains :) I wish that was me, but who am I if I only reverse engineered couple airliners with the cigarette in my mouth at one of the world biggest airports? Speaking of, that font that I used for the boot logo for the scope, was made by Airbus and they used it on the screens that pilots use in flight decks to make You safer - even by making their own font (sadly they made some simple mistakes around redundancy in FBW computers...).
Even with the source code, Android is more like a toy, than operating system. If Android is based around (modified) Linux kernel and it's safer and (as they say...) and more efficient than regular Linux/GNU, then why most expensive data centers (including Google which maintains Android) use "regular" Linux instead?
After countless hours (read: moths) spent on reverse engineering this thing, I have enough knowledge to start making this app from scratch (maybe with the original lib at the beginning) and with a Debian based system that I already did for this scope. At the beginning that will require a lot of time, but later it will save much more of time and bugs that are almost impossible to fix without the source code. There is a lot of owners of those series, but without support, it's very difficult.
Later it should be easy to port this for the Android, because my plan for the UI is very simple - open source API, HTML, CSS and JavaScript (app in the background and browser as the UI and endpoint for the video stream with waveform), so You can make or modify Your own layout very easily without learning low level programming.
Speaking of reverse engineering. Anybody has reeeaaallyy faaaaast scope to borrow? I did a properly working 2 Gsa/s without even overclocking anything, but I don't have proper scope (or at least spectrum analyzer with enough bandwidth) to check PLL with the 2.5 GHz signal - see attached screenshot. Or maybe used DDR chip is too slow, I don't know.
The only thing that I can´t do is to access the Rigol web control: I have already removed and added the connection and I can ping the oscilloscope, but the web connection is refused (already rebooted many times, take out the dongle, reconfigure WiFi at Android level, but nothing). Did you experience anything related?
Yeah... When I was releasing v0.2 I was thinking if it will be that problem or not - at some point it was but later it wasn't. Scope application in reality is made as a three separate apps - one You see on the scope screen, one is managing buttons & leds on the front and one is a web page server. Likely one of those called webcontrol is not executed at boot :-BROKE
But nothing is lost. If that wasn't started at boot, You can start it manually:
adb shell am start com.rigol.webcontrol/.MainActivity
Later I will look what mistake I did, that can prevent it from start at a boot. And I will make an update.
Just to confirm: it is totally a different project from norbert.kiszka, right?
Pretty much separate. Likely also incompatible - at least for the memory depth options, since I changed a lot in this area.
There's now three different ones to choose from...
When people don't have choice, they complain. If there is a choice, they complain. You can do Your own, at there will be four to chose from.
-
@mrisco thank you for your reply. Nice work on that UI!
It's always nice when the hacking community grows around a product: it's more fun and gives more options to everybody and a few shots to begin a hacking journey to newcomers. The downside is if the manufacturer is not open to alternative implementations it can get rough and a lot of work can go wasted in the next update: that is always a risk to invest knowledge and work in a closed platform or ecosystem.
@norbert.kiszka thank you for your suggestion, it worked and provided the web access. Maybe it has something to do with sending the command "am start com.rigol.webcontrol/.MainActivity" to the background. Once I changed line 64 of start_rigol_app.sh it is starting normally every time. The change was only to remove the background operator "&":
am start com.rigol.webcontrol/.MainActivity &
to
am start com.rigol.webcontrol/.MainActivity
In another topic: I noticed that the WiFi dongle doesn´t connect automatically after the scope is rebooted ("Reboot" option), but it works correctly on the first power on and if its power-cycled. When rebooted, the Android WiFi management shows the connection as "Disabled", if I force it to connect, then it works. I don't know if this happened with the stock firmware.
Regarding the whole-rewrite of the software you should definitely calculate the effort required. Not just the initial version, but the maintenance. It can become such a burden of expectations and work. As a personal project it might be a lot of fun but the community support might not be there.
-
I figured out primary cause of webcontrol not starting automatically at boot and a proper fix. That's why I hate Android...
It's just this:
adb shell pm install -r --user 0 /rigol/app/Webcontrol.apk
I updated this in the published package (script) without changing version number.
-
(1) Opened up the scope, peeled back the black tape and removed the uSD card. Put that in a card reader and used HDD Raw Copy Tool to make a backup image of the original factory supplied card. This came with Firmware 1.03. The original uSD card in the scope was a Lexar 32GB V10 633x
could you please check what is the uSD card size in bytes reported by OS?
i've the scope with same card and i'm unable to restore backup from this link
https://www.eevblog.org/files/RigolDHO800-SDcard-dump.zip (https://www.eevblog.org/files/RigolDHO800-SDcard-dump.zip) as the size of card
is lower: 31,299,993,600 instead of required 31,719,424,000 bytes.
could you share your backup with me?
br/Piotr
-
could you please check what is the uSD card size in bytes reported by OS?
Exactly 31 719 424 000 bytes
-
thanks AndyBig but this question was specifically to @pict as he had issue with booting scope after removing uSD card for backup.
i'm in the same situation now and TSG what's going on. certainly my Lexar 32GB is reporting 400MB/819200 sectors less than normal:
Disk /dev/mmcblk0: 29.15 GiB, 31299993600 bytes, 61132800 sectors
if anyone uses custom uSD card which is working fine with this scope please share, i likely need to buy a replacement.
-
For some reasons so called U-Boot (first thing that CPU reads) has problems with other SD cards - at least on my scope. But those SD cards are manufactured in the same way within same brand and model. So if You buy same card or same model with size 64 GB it should work. Lexar brand is probably the cheapest one.
-
the question is why my scope behave differently than most others and uboot expose uSD card as mmcblk0 device instead mmcblk1 as for others. do u have any clue?
-
the question is why my scope behave differently than most others and uboot expose uSD card as mmcblk0 device instead mmcblk1 as for others. do u have any clue?
I think we already talk about it. mmcblk0 instead of mmcblk1 was caused by a sinlge change in the Device Tree in which first MMC port was disabled. If both are enabled, kernel reserves 0 for the first MMC memory, which is not connected, but second one is connected to SD card and that's why more or less everybody has mmcblk1 and You had mmcblk0.
Check how it is currently after installed v0.2:
ls /dev/block/
-
(1) Opened up the scope, peeled back the black tape and removed the uSD card. Put that in a card reader and used HDD Raw Copy Tool to make a backup image of the original factory supplied card. This came with Firmware 1.03. The original uSD card in the scope was a Lexar 32GB V10 633x
could you please check what is the uSD card size in bytes reported by OS?
i've the scope with same card and i'm unable to restore backup from this link
https://www.eevblog.org/files/RigolDHO800-SDcard-dump.zip (https://www.eevblog.org/files/RigolDHO800-SDcard-dump.zip) as the size of card
is lower: 31,299,993,600 instead of required 31,719,424,000 bytes.
could you share your backup with me?
br/Piotr
The Lexar cards that worked for me (V10 633x 32GB) report as 31,706,841,088 bytes capacity (29.5GB) when formatted FAT32. HDD Raw Copy Tool reports the card as LBA 61,952,000 - 31.71GB
This is the Amazon link to the cards I bought that worked. They are identical to the card supplied with the scope:
https://www.amazon.ca/dp/B094866JD3 (https://www.amazon.ca/dp/B094866JD3)
PM me your email and I can send you my original image when I have access to the PC they are on (away at work currently).
-
The Lexar cards that worked for me (V10 633x 32GB) report as 31,706,841,088 bytes capacity (29.5GB) when formatted FAT32. HDD Raw Copy Tool reports the card as LBA 61,952,000 - 31.71GB
This is the Amazon link to the cards I bought that worked. They are identical to the card supplied with the scope:
https://www.amazon.ca/dp/B094866JD3 (https://www.amazon.ca/dp/B094866JD3)
PM me your email and I can send you my original image when I have access to the PC they are on (away at work currently).
Actually, file system internal capacity is always lower than actual size of the physical device (SD card in this case). So what are You talking about?
Every 32 GB SD card has 31 719 424 000 bytes capacity. Doesn't matter if that is Lexar, Samsung, SanDisk or anything else.
Windows and closed source software working only for Windows are highly unreliable. I learned this by myself in a hard way - about 20 years ago. Currently I don't have Windows on any of my computers.
And how You gonna send sd card image with an email? Xzipped image takes about 564 MiB. Email attachments are encoded, because You can't send binary data (without encoding it) within email messages - that increases size to at least 150% of original file.
-
Every 32 GB SD card has 31 719 424 000 bytes capacity. Doesn't matter if that is Lexar, Samsung, SanDisk or anything else.
I'm not sure about that, I got several 32GB cards to make the backup and found slightly differences of some sectors between brands, my backup was a hardware level. I was able to restore the backup on cards with identical size, and in cards with larger size but in the lastest some correction was needed, I don't remember exactly but a password dialog was popup, the password was empty, after that all was normal.
Here is a table that can help clarify these differences (from: https://forums.raspberrypi.com/viewtopic.php?t=371242)
SD Card Info Capacity GiB Capacity GB "Vendor"
SanDisk Ultra (32GB) 29.72 31.91 Manufacturer: SanDisk - Model: ACLCD - Vendor: SD - Product: SD - HW Version: 0x8 - FW Version: 0x0 - Date Manufactured: 04/2017 - Class: A1 Class 10
Kingston (32GB - 25MHz) 28.86 30.99 Manufacturer: Phison - Model: SD32G - Vendor: PH - Product: SD - HW Version: 0x6 - FW Version: 0x0 - Date Manufactured: 08/2021 - Class: A1 Class 10 V10 U1
KIOXIA EXCERIA (32GB) 28.85 30.98 Manufacturer: Toshiba - Model: SA32G - Vendor: TM - Product: SD - HW Version: 0x7 - FW Version: 0x0 - Date Manufactured: 02/2020 - Class: A1 Class 10 V10 U1
Samsung EVO Plus (32GB) 29.81 32.01 Manufacturer: Samsung - Model: EB1QT - Vendor: SM - Product: SD - HW Version: 0x3 - FW Version: 0x0 - Date Manufactured: 02/2021 - Class: Class 10 U1
SanDisk MAX (32GB) 29.72 31.91 Manufacturer: SanDisk - Model: SH32G - Vendor: SD - Product: SD - HW Version: 0x8 - FW Version: 0x0 - Date Manufactured: 01/2022 - Class: A2 Class 10 V30 U3
Transcend (32GB) 28.33 30.42 Manufacturer: Transcend - Model: USDU1 - Vendor: J` - Product: SD - HW Version: 0x2 - FW Version: 0x0 - Date Manufactured: 01/2021 - Class: A1 Class 10 V10 U1
Samsung EVO (32GB) 29.81 32.01 Manufacturer: Samsung - Model: GB1QT - Vendor: SM - Product: SD - HW Version: 0x3 - FW Version: 0x0 - Date Manufactured: 06/2020 - Class: Class 10
Samsung PRO (32GB) 29.81 32.01 Manufacturer: Samsung - Model: JB1RT - Vendor: SM - Product: SD - HW Version: 0x3 - FW Version: 0x0 - Date Manufactured: 11/2021 - Class: Class 10 U1
-
I've found out personally that when OS init fail to mount /system then we got this android password prompt. this means android lost security configuration likely stored on /system partition and fallback to default.
-
I got several 32GB cards to make the backup and found slightly differences of some sectors between brands
That backup was just files stored on SD card or SD card image?
-
That backup was just files stored on SD card or SD card image?
Sector by sector raw image
-
The Lexar cards that worked for me (V10 633x 32GB) report as 31,706,841,088 bytes capacity (29.5GB) when formatted FAT32. HDD Raw Copy Tool reports the card as LBA 61,952,000 - 31.71GB
This is the Amazon link to the cards I bought that worked. They are identical to the card supplied with the scope:
https://www.amazon.ca/dp/B094866JD3 (https://www.amazon.ca/dp/B094866JD3)
PM me your email and I can send you my original image when I have access to the PC they are on (away at work currently).
Actually, file system internal capacity is always lower than actual size of the physical device (SD card in this case). So what are You talking about?
OP asked me a specific question. I answered it.
Every 32 GB SD card has 31 719 424 000 bytes capacity. Doesn't matter if that is Lexar, Samsung, SanDisk or anything else.
I do not believe this. I have different 32GB cards that report different available capacities, and the differences appear brand specific.
And how You gonna send sd card image with an email? Xzipped image takes about 564 MiB. Email attachments are encoded, because You can't send binary data (without encoding it) within email messages - that increases size to at least 150% of original file.
Stick it on Dropbox and share the link by email was the plan.
-
How does it look?
-
v0.2.1 is ready to go. (https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-normal-1694869)
Changelog:
- Fixed issue with webcontrol (external access via web browser) which was not starting at boot.
- Fixed boot problems which can happen for some scopes.
- Fixed installation problems caused by modified Device Tree in newer scopes.
- Fixed trigger source spinner (drop down menu list) not showing digital channels.
- FPGA ChDlyPointTime value restored to 800 ps just in case (previously it was the same as in DHO4000 which is 250 ps).
- Average acquisition memory depth limit now is 25 Mpts for single channel and 12.5 Mpts for two or more channels (previously 1 Mpts in each case).
- Removed "bandwidth indicator" from DVM, since DVM bandwidth is always the same as the channel bandwidth and this takes useful space from measurements results.
- "Squished" buttons in navigation list (top right of the screen) now are changed to text buttons.
- Rarely used options from navigation list was moved into Start Menu and often used in Start Menu was added to navigation list.
- UPA (power analysis) option added to Start Menu as an experimental option.
- Increased width of Start Menu for better readability.
- Fixed sizes of various popup windows.
- Fixed sizes of some spinners (dropdown menus) which was way too big.
- XY advanced settings now are always available ("testModel" is hardcoded to always on).
- Removed some unnecessary "features" that decreases app performance, like a hardware version checking, since it's hardcoded to DHO4000.
- Added more shortcuts to the Start Menu.
- Trigger status (top left screen corner) now is also a run/stop button.
- Removed unnecessary icons from notification bar.
- pm now allows to change app permissions which are "not changeable" or "not requested".
- Increased text size in multi windows (all measure, peak search, etc).
- Removed unnecessary files that can't be used at all but takes useful space and boot time.
Just as a reminder, 30% off code is: EEVBLOG
-
2.1 GSa/s and ~130 Mpts are the limits without any hardware modification.
I think this ADC probably will do 2.5 GSa/s, but not with this FPGA and slow DDR3. Theoretically there are DDR3 chips faster than 2133 MHz.
ADS924A has round memory depth options (1 M, 10 M, 100 M), likely because they used code from Rigol. And Rigol "engineers" likely are very bad at basic math - sample rate vs time base vs memory depth is calculated not by math but with structs (tables)... I fixed it and now we can have any memory depth between ~10 pts and ~130 Mpts.
-
Can we run rigol_vendor_bin directly on the scope, as for generate_all_options (I don't have any Windows system) ?
Yes, see here (https://www.eevblog.com/forum/testgear/rigol-dho800900-new-firmware-v00-01-04-00-02-2024111/msg5732037/#msg5732037).
-
I just wonder, how many would want to have 2 GSa/s for the exchange of limited memory depth to something around 15 kpts. Finishing it will take some time, that why Im asking.
Currently I have no idea why ADS924A can do 2 GSa/s with 100 Mpts.
-
Are you sure both scopes are using the same hardware? In the ADS804 manual they states 1.25GSa/s with 2 channels (channels 1&3 or 2&4).
-
Are you sure both scopes are using the same hardware? In the ADS804 manual they states 1.25GSa/s with 2 channels (channels 1&3 or 2&4).
ADS800 series has 1.25 GSa/s and ADS900 series has 2 GSa/s. And I don't know if they use same hardware - I guess they do, because of the costs. Sample rate can be limited by changing PLL registers.
-
I was referring to Rigol and Owon.
Look a this video. It's a ADS924A disassembly.
https://www.youtube.com/shorts/gBUQlmmF9S0?feature=share (https://www.youtube.com/shorts/gBUQlmmF9S0?feature=share)
-
I was referring to Rigol and Owon.
Look a this video. It's a ADS924A disassembly.
https://www.youtube.com/shorts/gBUQlmmF9S0?feature=share (https://www.youtube.com/shorts/gBUQlmmF9S0?feature=share)
I didn't seen any teardown of this before. I was expecting 100% of the same hardware in slightly different housing.
Anyway, I still wonder which exact FPGA they used for this.
-
My first post on EEVblog. Thanks guys for all the help in here(!)
My situation:
I got the DHO804 (FW 00.01.03) and did the update with the latest rigol_vendor_bin_v1.3 and applied the -M to model DHO924.
All good it seems.
Now probably noob questions:
1) Can I update the fw to the latest 00.01.04 without issues - or should I wait until zelea2 makes a new rigol_vendor_bin_v1.4 ?
2) Before hacking I saw the red dot indicating a new fw was ready to install. However, I did not do that as I was not sure it would work with the vendor.bin 1.3. Now, after the hack I do not see the red dot anymore - and the scope do not see the 1.04 under updates. Is that normal? (it is otherwise still internet connected)
3) So sample rate stay at 1.25GSa/s on the DHO804 no matter this hack right?
Cheers
-
3) So sample rate stay at 1.25GSa/s on the DHO804 no matter this hack right?
Sample rate is driven by the frequency generated in PLL chip, which is constant all the time - if You like it or not. When actual memory depth is lower than is needed to cover whole screen, FPGA will just omit some samples - which makes it look like a lower sample rate.
Actually I hacked that sample rate calculation literally yesterday, because Rigol made it quite bad. Instead of simple math, they used computations based on huge structs for each possible setting... That's why in many cases sample rate is lower than it can be to cover visible screen area.
-
Actually I hacked that sample rate calculation literally yesterday, because Rigol made it quite bad. Instead of simple math, they used computations based on huge structs for each possible setting... That's why in many cases sample rate is lower than it can be to cover visible screen area.
Interesting - thanks!
-
1) Can I update the fw to the latest 00.01.04 without issues
Yes.
-
Are there any upgrade options for the 924s ?
-
Are there any upgrade options for the 924s ?
You can upgrade it to 125 Mpts memory depth, unlock hidden options from DHO4000 and get improved UI.
-
Hi,
Total noob here. I have downloaded the necessary tools to hack my DHO814 into a DHO924, but I am having a problem using adb. I have attached a screenshot that shows what's going on. Please help! :)
-
Maybe Im not the Windows user for last ~20 years, but I see You are not any noob. You are just lazy enough, to not read error message "more than one device/emulator" which clearly tells You in clear English what's the problem.
If You have more than one device and You didn't tell to adb (-s switch, RTFM!) which one You want to use, adb can't make any assumptions - otherwise it can make Your day very bad.
Disconnect other devices or use -s switch.
Edit: If You going to use my modification, You don't need to have vendor.bin at all, because I hacked whole license system, which gives features not only from DHO924S but also some from DHO1000 and from DHO4000.
-
use the -s parameter (https://developer.android.com/tools/adb) with the ip-adres of the scope
-
Ah!
adb -s 192.168.49.222:55555 pull /rigol/data/vendor.bin
Thank you :)
-
Well I tried the hack but I don't think it worked. My 'scope is a DHO814. I followed the instructions to the letter. Also a YouTube video: https://www.youtube.com/watch?v=oBfuWxMFSsI (https://www.youtube.com/watch?v=oBfuWxMFSsI)
After creating a backup of the original vendor.bin file I did this:
C:\Program Files (x86)\Minimal ADB and Fastboot>rigol_vendor_bin -M DHO924
Rigol 'vendor.bin' encoder/decoder v1.3 - Zelea
-----------------------------------------------------------
0000 CRC32: D69FBFB5 (OK)
0004 Length: 196 (OK)
-----------------------------------------------------------
0008 EntrySize: 4
000C Type: 5 (MODEL)
0010 FieldSize: 48
0014 CRC32: 0AB010E3 (OK)
0018 DataSize: 36
001C StringLen: 6
0020 String: DHO814
-----------------------------------------------------------
0044 EntrySize: 4
0048 Type: 7 (SN)
004C FieldSize: 52
0050 CRC32: 946507C4 (OK)
0054 DataSize: 40
0058 StringLen: 14
005C String: DHO8A254202941
-----------------------------------------------------------
0084 EntrySize: 4
0088 Type: 9 (MAC)
008C FieldSize: 60
0090 CRC32: 86A7F839 (OK)
0094 DataSize: 48
0098 StringLen: 12
009C String: 0019AF9E0FBE
-----------------------------------------------------------
Model: DHO924
SN: DHO9A254202941
MAC: 0019AFAE0FBE
New "vendor.enc" file has been created
You may rename it to "vendor.bin"
and install it on your scope Rigol partition
C:\Program Files (x86)\Minimal ADB and Fastboot>dir
Volume in drive C has no label.
Volume Serial Number is E9AE-1DD0
Directory of C:\Program Files (x86)\Minimal ADB and Fastboot
10/07/2025 15:14 <DIR> .
10/07/2025 15:14 <DIR> ..
11/01/2018 18:53 1,784,320 adb.exe
11/01/2018 18:53 97,792 AdbWinApi.dll
11/01/2018 18:53 62,976 AdbWinUsbApi.dll
09/08/2015 13:50 29,882 cmd-here.exe
11/01/2018 18:53 853,504 fastboot.exe
10/07/2025 14:54 148 Key.data
10/07/2025 02:29 71,168 rigol_vendor_bin.exe
10/07/2025 02:27 2,006 unins000.dat
10/07/2025 02:26 717,985 unins000.exe
10/07/2025 14:55 204 vendor.bin
10/07/2025 15:12 212 vendor.enc
11 File(s) 3,620,197 bytes
2 Dir(s) 1,553,010,503,680 bytes free
C:\Program Files (x86)\Minimal ADB and Fastboot>del vendor.bin
C:\Program Files (x86)\Minimal ADB and Fastboot>ren vendor.enc vendor.bin
C:\Program Files (x86)\Minimal ADB and Fastboot>adb connect 192.168.49.222:55555
connected to 192.168.49.222:55555
C:\Program Files (x86)\Minimal ADB and Fastboot>adb -s 192.168.49.222:55555 push vendor.bin /rigol/data/
vendor.bin: 1 file pushed. 0.0 MB/s (204 bytes in 0.039s)
After which I restarted the device. I was expecting to see the 924's Logic Analyzer button appear on the display, but it's not there. Ummm... not certain what to do next. Any ideas?
Thanks :)
EDIT: Originally I omitted the nenaming of vendor.enc to vendor.bin when I was cut and pasting this in. I did do it, as you see here.
-
Hmm I cut out the part where I renamed the file from vendor.enc to vendor.bin. So just saying that this was done. I didn't cut and paste it all correctly.
-
I'm thinking about changing the format of the configuration file for the DHO-Actions, the idea is to simplify the user changes of this file by using a simple text editor, I don't want to include a configuration editor inside the application to keep the resource usage low.
The image shows the current json config structure on the left and the possible new format (TOML) on the right, what do you think?
[attach=1]
-
No problem for me, but would it be challenging to add x,y coordinates representing the upper-left position of a button?
-
No problem for me, but would it be challenging to add x,y coordinates representing the upper-left position of a button?
From the DHO Actions version 1.1 it is possible to customize the size of the DHO Actions panel by adding numColumns and numRows before of the dhoIP value in the JSON settings file:
{
"numColumns":4,
"numRows":2,
"dhoIP":"localhost",
"buttons": [
...
]
}
The buttons are sorted in sequence, so you can move a button by changing its position in the configuration file.
-
I managed to get it working. I updated to v1.04 first and then carried out the procedure in the video. Bingo:)
-
Hi there i recently got a DHO814 the firmware is the 1.03, is anyone have problem when try XY mode? because when i try to select the XY mode, the app crash, and restart. I'm not going to use it much in that mode, but it get me mad :-BROKE jejejejeje, anyways thank if anyone has some solution. Cheers!
-
Hi there i recently got a DHO814 the firmware is the 1.03, is anyone have problem when try XY mode? because when i try to select the XY mode, the app crash, and restart. I'm not going to use it much in that mode, but it get me mad :-BROKE jejejejeje, anyways thank if anyone has some solution. Cheers!
Solution is firmware 1.04.
Warning: Do NOT switch it off in XY mode with firmware 1.03. It might never switch on again.
-
Warning: Do NOT switch it off in XY mode with firmware 1.03. It might never switch on again.
Question for all the hackers: Has anybody figured out a way to wipe the settings and fix this?
-
Warning: Do NOT switch it off in XY mode with firmware 1.03. It might never switch on again.
Question for all the hackers: Has anybody figured out a way to wipe the settings and fix this?
I released an apk with the fix some time ago. Installing this apk should fix the problem.
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/download/EXTGUI/SparrowExt_v00.01.03.apk
-
How does it look?
https://www.youtube.com/watch?v=IEutsFFzu0U (https://www.youtube.com/watch?v=IEutsFFzu0U)
Also I reached 80 k waveform updates per second and doubled sample rate for LA (1.25 G instead of 625 M).
-
It looks cool and very responsive. Does the improved DHO900 can reach to 2.0GSa/s stably now?
-
It looks cool and very responsive. Does the improved DHO900 can reach to 2.0GSa/s stably now?
Only with limited memory depth to not more than 15 kpts (15 750 to be precise).
Im actually finishing v0.3 with the same 1.25 GSa/s. Managing sample rate for different settings is not easy with this mess that Rigol "engineers" created. So it will be somewhere in the future.
-
Adding ElectroDoc to the DHO Actions:
{
"glyph": "electrodoc.png",
"caption": "ElectroDoc",
"type": "APP",
"command": "it.android.demi.elettronica"
},
Your copy of ElectroDoc may have a different application ID. For the Pro version use: it.android.demi.elettronica.pro
Icon
[attachimg=1]
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions/9#discussioncomment-12303439
-
Maybe silly question. Considering this thread is it any sense to buy DHO900 instead of DHO800? Of course except logic analyzer.
-
DHO9xxS has AFG. With DHO924 and DHO924S You will have 350 MHz probes instead of 150 MHz like in other models.
-
Pardon any dumb/obvious questions here, a bit new to the Rigol Oscope upgrade processes and want to verify before acting. I've read through all of the 1000's of posts and am concerned about bricking this or not installing the correct version files that have found to work.
I have a DHO914S with fw 1.01 and would like to upgrade it the memory and bw, but am unclear which procedures to follow. Many of the references are for the 800 series and couldn't find anything specifically for the 914s.
Question:
Which procedures and files should I use with the 914s to upgrade the memory and bandwidth?
I have not yet updated the fw to the 1.04.00.02 yet out of precaution that it might inhibit hacks/mods.
Thanks ahead of time.
Jersey
-
I have not yet updated the fw to the 1.04.00.02 yet out of precaution that it might inhibit hacks/mods
Which mod do You mean? With my latest mod, it doesn't matter what firmware version You have, because the script updates all files that are changed with the firmware upgrade and it's based on 00.01.04.00.02.
Anyway, You can downgrade any time, because there is no version check with the upgrade option. So You can even downgrade from 00.01.04.00.02 to the 00.01.00.00.00 (I have all published versions on my laptop if You want something).
In the worst case scenario, If You or something will brick Your scope on the software side, everything is stored on a uSD card on a socket with easy access. So there is no need to desolder to flash it with a backup. Even If You don't have a backup, You can use SD card image from DHO800, because the only difference is in the two very small files, that app reads and decides what model/serial/options/etc You have. That two files are very easy to change. Speaking of, my mod doesn't reads those files, because I wiped license subsystem and it enables also some options from DHO1000, DHO4000 and other scopes (because they used same code from many other series instead of making it from scratch).
I have DHO924S and I tested SD card image from DHO800 many times (because I was testing installation script of my mod to find eventual bugs).
-
Which mod do You mean?
Desired Upgrades:
BW to 250mhz
Memory increase
How to upgrade?
Do just follow the procedures shown in the first posting? ...or is there something specific to do otherwise to achieve the upgrades?
Anyway, You can downgrade any time, because there is no version check with the upgrade option. So You can even downgrade from 00.01.04.00.02 to the 00.01.00.00.00 (I have all published versions on my laptop if You want something).
I would be interested in having all published version as a backup. is there a central repository where these are kept? Save you from having to send all the files
Thanks!
Jersey
-
BW to 250mhz
Either You change vendor.bin file or install mod that has hacked BW.
Memory increase
I think only my mod increases memory above 50 Mpts.
How to upgrade?
Well, it all depends of what are You looking for.
Do just follow the procedures shown in the first posting?
First posts in this topic remembers era when the dinosaurs was walking on the earth... Currently I can install Steam on this scope and play games if I wanted to.
I would be interested in having all published version as a backup.
I think that's not necessary for anything - whole SD card image with any firmware on it is much more useful. They done little amount of bugfixes in each version. Only once they added a bug that in some cases (XY mode I believe) was bricking scopes.
is there a central repository where these are kept? Save you from having to send all the files
I don't know. I'm keeping those with a believe that will be useful someday, but I have huge doubt about that.
-
How to upgrade?
Well, it all depends of what are You looking for.
[/quote]
Would turning this 914s into a 924s be easy?
UPDATE: Successfully changed it using the process in #1507
-
How to upgrade?
Well, it all depends of what are You looking for.
Would turning this 914s into a 924s be easy?
[/quote]
If You want only 250 MHz bandwidth (or more if You remove LC filters - but I recommend to do this only in the last channel), use modified vendor.bin file. Pregenerated file You can grab from my Github: https://github.com/norbertkiszka/rigol_vendor_bin/raw/refs/heads/main/generated_ready_to_use/DHO924S/vendor.bin (https://github.com/norbertkiszka/rigol_vendor_bin/raw/refs/heads/main/generated_ready_to_use/DHO924S/vendor.bin)
If You want not only bandwidth, but also more memory, more features and better UI, You can use this: https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-normal-1694869 (https://www.patreon.com/NorbertKiszka/shop/rigol-dho800-900-sparrow-extended-normal-1694869)
Currently Im working on v0.3 which will be available as a free update for those who purchased v0.2.1 (unless You want go to the enterprise edition with even more features).
Speaking of, couple days ago I wrote that I reached 80 k waveform updates per second. Today I did round 100 k :)
-
Great works mrisco and norbert.kiszka, I'd really love to see the power analysis feature working - any chance of that happening?
Cheers
-
I'd really love to see the power analysis feature working - any chance of that happening?
Without the source code, it's really hard to debug why this is not working. Maybe in the next week I will try to copy/compare code from DHO1000/DHO4000 because the DHO800/DHO900 firmware is clearly based on old code from DHO1000/DHO4000 (that's also why my mod has many features from DHO4000).
-
Hi guys,
can someone briefly bring me up to speed?
I'm sorry, no I haven't read the many previous posts yet, but I promise to catch up. I don't have the time at the moment though. Why?
I have an offer for a used DHO924S that would not be much more expensive than a new DHO800.
Now I've come across the information that the devices can apparently be hacked and upgraded. This raises the question for me:
Is it even worth buying a DHO924S or can all the features all be easily retrofitted? What can be done with a DHO of the 800 series? What can be done with a 900 series device? Are the devices perhaps even equivalent in the end (after the hacks)?
I'm afraid that the used and cheap DHO924S will be sold to someone else before I can get enough information.
Many thanks in advance!
-
Differences:
1. LA.
2. AFG.
3. 350 MHz passive probes instead of 150 MHz (from what I remeber, even DHO914 has 150 MHz probes).
4. Black housing.
5. Physical buttons for LA and AFG.
-
But in terms of bandwidth, memory and sample rate, can the 800 series and the 924S be tuned to the same limits? Or is the 924S the limit of the shared hardware never the less?
I think what I'm asking is whether the 924S is still superior to an 800 after tuning, or whether you end up with the same device but with different upgrade efforts.
The probes alone appear to have a very high additional benefit.
Just watching some videos and read this thread backwards. Looks like the boards are the same and everything is populated except for the connectors. It looks like even the LA and AFG could be added, although the physical buttons are missing, maybe they can be controlled via the display? I've never needed an LA, YET, but it would come in handy if it could be added later.
Thanks for your very fast response!
-
If I was You and I had opportunity to buy DHO924S with little higher price than DHO804, I would buy it. Especially because I prefer to use physical buttons and black color ...
LA and AFG can be enabled from the screen (kinda) and DHO8xx can be hacked to have 200 or even 250 MHz.
-
and DHO8xx can be hacked to have 200 or even 250 MHz.
About 270 MHz IIRC, if we define bandwidth by the -3db drop -- that's determined by the analog input filter.
Of course it (or any of the 8xx or 9xx scopes) is usable at these frequencies in single-channel mode only, because 1/2 or 1/4 the max sampling rate will not be sufficient to properly display the signal when two or more channels are enabled. Again IIRC these scopes can work with input frequencies only up to about 1/2.5 the current sampling rate, or, more realistically, up to 1/3. This is determined by the signal reconstruction algorithm, which sucks in these scopes (the Siglent's is better, for comparison).
-
This is determined by the signal reconstruction algorithm, which sucks in these scopes (the Siglent's is better, for comparison).
I still want to make whole app (firmware for those who doesn't understand what I mean) on this scope scope from scratch. That will take some months to complete. Maybe even a year.
Analog signal path is great, especially for that price, but the original software was clearly made in hurry for other series (DS7000 I believe) and adapted also in hurry for other series again, again and again.
input frequencies only up to about 1/2.5 the current sampling rate, or, more realistically, up to 1/3
Speaking of basics, both bandwidth and sample rate should be at least 5-10 times more than main signal frequency. So originally with one channel and full sample rate, I can analyse square waves up to 25-50 MHz. After removing LC filter(s) in analog path (just under ADC) I can analyse square wave theoretically up to 125-250 MHz - but it depends on the interpolation. Sinc in those series, as You said, sucks. With linear interpolation it's way better.
Speaking of sinc, it's very strange how they made such simple interpolation - like they wanted to make it in the most difficult way...
Waveform visible on the screen is generated with OpenGL in GPU. App has hardcoded exact 1000 data points that comes from the FPGA. Changing it to like 10 000 will fix many of the problems, but hacking it without the source code is not easy - it's way better to rewrite it.
-
Hello Norbert,
Sorry for being so late on the reply for this but life has kept me off the forum for a while.
On my question regarding the use of the 924S logic analyzer function it appears from what I have read in other posts that when in LA mode the sample rate
is too fast to take advantage of the memory depth when you are trying to analyze logic that is running at a slow rate as opposed to MHz rates. I assume this is due to
limitations of the operating range of the sample clock?
I know I read something on the forum on this issue but I can't seem to find the thread. This limitaton is what is keeping me from buying or building the logic probe set and the reason
I am holding onto my HP/Agilent 54642D for now. Maybe the OP that pointed out that issue can chime in.
On your sparrow replacement project have you made any headway into building that all into a GEL file so it can be installed from a USB stick?
Thanks,
Sam
-
On my question regarding the use of the 924S logic analyzer function it appears from what I have read in other posts that when in LA mode the sample rate
is too fast to take advantage of the memory depth when you are trying to analyze logic that is running at a slow rate as opposed to MHz rates. I assume this is due to
limitations of the operating range of the sample clock?
You mean that sample rate can't be lowered manually or the max sample rate being only 625 MSa/s? In the upcoming v0.3 max sample rate for LA will be 1.25 GSa/s and "waveform" (LA) update rate 55 k per second.
On your sparrow replacement project have you made any headway into building that all into a GEL file so it can be installed from a USB stick?
Currently this is in my plans - a lot of work is needed but not so much support to do this. As for now, it can be easily installed with the script or via adb. This script also increases performance of the system. Only two things that must be done manually, is to give IP address and to confirm installation after automated backups.
-
Finally got around to replacing that shitty noisy fan. I've sandwiched a 92mm Noctua NF-A9x14 PWM with a VESA mount, and used 35mm M4 screws to leave room for airflow. Temps are the same but the noise level is so much more tolerable. I think it could be improved even more by removing the rear grill cover.
Also I upgraded the software to Norbert's 0.2.1 Sparrow. It's more usable than the base app for sure. It also seem to run cooler than the base app (48 vs 53°C)? Although couple of thoughts:
- the currently selected channel is not highlighted in the lower row which is sometimes confusing
- the LA and AFG menus show up on my DHO804, but it doesn't have these outputs so it's a bit of a visual clutter
- the correct ISO date format uses dashes, not slashes :)
-
Finally got around to replacing that shitty noisy fan. I've sandwiched a 92mm Noctua NF-A9x14 PWM with a VESA mount, and used 35mm M4 screws to leave room for airflow. Temps are the same but the noise level is so much more tolerable. I think it could be improved even more by removing the rear grill cover.
Got some photos of the final result?
BTW. I was thinking about making a software fan control (separate app in the background or via the kernel) in order to maintain stable temperature inside. There are at least four GPIO pins (hw code, which is unused in my mod) that can be used for anything. Linux kernel (used in Android) has a PWM driver and even without recompiling it, it should be simple to use modified kernel module from the DHO4000 which uses exact same kernel (change of gpio pin number in the compiled module is very easy). That will require less parts than making it fully electronically.
It's more usable than the base app for sure
It's always nice to hear feedback like this. Any feedback is also good, since I can make things differently or get better ideas.
It also seem to run cooler than the base app (48 vs 53°C)?
This can be an effect of optimizations (much more of this is in the upcoming v0.3, especially if You enable "slow" acquisition mode). Settings can also make a change, especially stop mode or disabled all channels.
the currently selected channel is not highlighted in the lower row which is sometimes confusing
Can You provide a screenshot? All channels are the same? For a comparison, I attached screenshot from the upcoming v0.3, which has exactly the same layout of channels in the "navigation bar" - different color makes it clearly distinguishable, at least for me.
the LA and AFG menus show up on my DHO804, but it doesn't have these outputs so it's a bit of a visual clutter
As I mentioned couple times, I wiped out whole Rigol licensing system. Every time when the app literally asks itself if there is a licence/option/etc for some functionality, it always answer yes. Making a (separate) functionality of showing/hiding things takes time, both from the CPU and mine own, since I don't have the source code, which also makes very easy to make a bug together with a new functionality.
After all, it would be much better to rewrite whole thing from the scratch (with the open source UI part), because it will make a much much faster development and less prone to bugs. But making a very basic functionality (at the beginning) will take at least one month of work.
the correct ISO date format uses dashes, not slashes :)
I didn't change anything in the original clock code, I only hardcoded to always display it. Dashes are wider chars in normal font(s) and likely they wanted to save screen space. Maybe dots will be better?
Speaking of v0.3, I need to fix two things before I release it.
PS. In this screenshot, there are commas instead of dots, because I was testing new Polish translation, because this is my primary language. Rigol used software translator instead of real one. Also I found many typos in the English translation, which proves this is the only one translation that they did manually - more or less.
-
It's always nice to hear feedback like this. Any feedback is also good, since I can make things differently or get better ideas.
There's more showing up on screen which is always good.
Also when moving the vertical graduations they now don't end on stupid offsets such as 0.012V, it's a nice snappy 0V.
That's all I've seen for now, I'm not a power user anyways, it's mostly used for troubleshooting glitching setups.
Got some photos of the final result?
I've attached a picture of the fan hack, nothing much, just opened the scope and plugged the fan to the +12V. The 92mm low profile (15mm) would work with a scope on a bench, not VESA mounted but I'm not sure about a standard fan (25mm IIRC).
BTW. I was thinking about making a software fan control (separate app in the background or via the kernel) in order to maintain stable temperature inside. There are at least four GPIO pins (hw code, which is unused in my mod) that can be used for anything. Linux kernel (used in Android) has a PWM driver and even without recompiling it, it should be simple to use modified kernel module from the DHO4000 which uses exact same kernel (change of gpio pin number in the compiled module is very easy). That will require less parts than making it fully electronically.
This might be helpful for others that don't want to open their scopes. But I don't regret doing the swap, this is much more peaceful. You can probably do it without opening the scope anyways, I just wanted to plug to the original header.
Can You provide a screenshot? All channels are the same? For a comparison, I attached screenshot from the upcoming v0.3, which has exactly the same layout of channels in the "navigation bar" - different color makes it clearly distinguishable, at least for me.
The screenshot shows that I have two channels active, but in the lower bar it doesn't display well which one is selected so it's a game of hit and miss when I want to open its options. I've played with it a bit and now I see that the 1 pixel vertical bar to the right of the selected channel changes color, but it's hard to see really compared to the original interface I was used to. They wasted screen real estate but it made more sense visually at least to me.
-
The question is experienced, I order a Rigol 804 in China and it arrives already converted into a 924, the question is whether to pick it up or refuse.
-
I've attached a picture of the fan hack, nothing much, just opened the scope and plugged the fan to the +12V.
An actual 12V or whatever's on the original fan connector? Because the latter is actually about 8V.
Either way, nice mod. I did similar (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5338634/#msg5338634), but I used a slim 120mm fan (with the voltage reduced further down to 5.4V), and it made using the VESA mount impossible (but I don't need it anyway). Yours still allows to use the VESA mount, which is cool.
-
The question is experienced, I order a Rigol 804 in China and it arrives already converted into a 924, the question is whether to pick it up or refuse.
Does it work? Is it dirty or damaged?
If it works and the price was good then... :-//
Make sure the "warranty void" sticker is intact and the power supply is the original one.
-
There's more showing up on screen which is always good.
I was thinking about making fullscreen mode, more or less like the others did, but when I was fixing bugs related to roll mode and LA, I noticed that waveform screen area is hardcoded in many places. Without the source code it will be very difficult to change those sizes and offsets dynamically. As always I need to manage my work time. Fullscreen mode with only 9% increase of waveform window (or other windows) to make it fully properly, can take maybe even two weeks. I already experienced many times that whole Android, Java and C++ languages are nothing else than reinventing the wheel. But instead of a circle shape, it ended as a triangle... If that things would be written in C with enabled compiler optimizations, it should boot (system+app) in like 10 seconds or maybe even less. Also working with properly written code in C is much easier and faster than working with the crap like the most of Java/C++ "software engineers" do - including Rigol ones.
Currently in my mod, space for the windows (one waveform window by default) as I calculated some time ago, is roughly 91%. I think this is good enough to work comfortably with this scope. Even it's quite good with the LA with all channels enabled. If that is not enough (more windows, decoders, etc), it should be better to connect PC monitor. With my very old 21'' Eizo (much better than today popular crap and current price is around 30 $) I can read everything from a couple meters.
On the side note, in Android framebuffer size can be easily changed to anything - for example, if somebody has a 1920x1080 monitor, it can be used in native resolution without interpolating pixels. But it will also affect internal LCD, which will be more or less unreadable, until framebuffer size will be changed back to the size of this LCD panel (1024x600). GPU in the RK3399 in most cases (it's complicated in details) can make a screen output up to the 1920x1080, so generally this is a maximum.
Once somebody asked here how to use HDMI monitor as a separate screen on this scope. On the hardware side this is possible (proof (https://github.com/norbertkiszka/Orange-Rigol)), but the current kernel has a driver compiled as built-in and with enabled mirroring on the kernel configuration side. I have other reasons to compile more modern kernel version, so this likely should also fit together.
Also when moving the vertical graduations they now don't end on stupid offsets such as 0.012V, it's a nice snappy 0V.
I see three possibilities. You are doing something differently or I did another feature by accident. Like a unintended bug, but it's feature instead. Or it was one of many very small changes that it was too small to make an effort to put this into changelog and later it become completely forgotten. I did a lot of small changes like that.
it's mostly used for troubleshooting glitching setups.
In that case, "fast" acquisition in v0.3 can be useful for You. It does up to 100 k waveform updates per second with 10 kpts mem. depth. With lower mem. depth and linear interpolation, there is a bug in FPGA firmware - on the screen it looks like it's somewhere more than 100 k, but trigger output (AUX socket at the back) gives something around 23 Hz...
BTW. I was thinking about making a software fan control (separate app in the background or via the kernel) in order to maintain stable temperature inside. There are at least four GPIO pins (hw code, which is unused in my mod) that can be used for anything. Linux kernel (used in Android) has a PWM driver and even without recompiling it, it should be simple to use modified kernel module from the DHO4000 which uses exact same kernel (change of gpio pin number in the compiled module is very easy). That will require less parts than making it fully electronically.
This might be helpful for others that don't want to open their scopes. But I don't regret doing the swap, this is much more peaceful. You can probably do it without opening the scope anyways, I just wanted to plug to the original header.
I had in mind unused GPIO pins that are available on PCB (my mod doesn't read hw code, In most places it's hardcoded to 0 like in DHO4000, which enables some features). Originally, both fan and the LCD backlight power (looks like it's doubled...) are driven by the same GPIO pin. "Sleep mode" kills the app and pulls down this one gpio pin. In this case, I think the only one logical option to drive the fan programmatically, is by using "hw code" GPIO pins. But maybe somebody else has better idea than mine.
As I said, point of this is to maintain more or less the same temperature all the time. In that case we should have more stable vertical offset. This is one of the reasons why self calibration exists.
Can You provide a screenshot? All channels are the same? For a comparison, I attached screenshot from the upcoming v0.3, which has exactly the same layout of channels in the "navigation bar" - different color makes it clearly distinguishable, at least for me.
The screenshot shows that I have two channels active, but in the lower bar it doesn't display well which one is selected so it's a game of hit and miss when I want to open its options. I've played with it a bit and now I see that the 1 pixel vertical bar to the right of the selected channel changes color, but it's hard to see really compared to the original interface I was used to. They wasted screen real estate but it made more sense visually at least to me.
I misunderstood You earlier. Right now, You can look at the vertical scale on the grid (1V, 2V, 3V, etc), because it's color is the same as the selected channel color. Original thick background (which had channel color if this one was selected, grey otherwise) literally I changed to the line on the right side. If You watch closely, it changes color in the same way as in the original app. Now You made me idea to make this line thicker. Right now it's 1 px. I think 3 px or maybe 4 px should be good enough to see which one is selected.
On the other hand, probably it will be literally ugly with almost everything else being 1 px thick. Also, Android uses very crazy and developer unfriendly things, so that one change can take much more time than the same thing in CSS used in web pages - in CSS it's just a simple change of a single number in a text file or change line with path with the background image to something like: border: 1px solid color_name_or_value and that's it. Anyway, I will look into that later.
Speaking of the vertical scale, in v0.2.1 and earlier versions it's being moved from right to left when You open measurements. I changed this behavior in v0.3 to be always on the left side.
-
Does it work? Is it dirty or damaged?
I think no. It doesn't work, but it can fly like a rocket.
If it works and the price was good then...
What else You expect?
Make sure the "warranty void" sticker is intact and the power supply is the original one.
I almost choked myself. Somebody sells scope(s) with the hardware modifications - I guess it was opened at least once. Also those stickers on the legal side has no power to void the warranty, but making a hole on the front and back covers is a another story.
What is "original power supply"? Rigol doesn't make PSUs for this series. You are here long enough to know that they supplied those scopes with different PSU brands, in which only one is safe and reliable (Delta).
-
I almost choked myself. Somebody sells scope(s) with the hardware modifications - I guess it was opened at least once. Also those stickers on the legal side has no power to void the warranty, but making a hole on the front and back covers is a another story.
Who said anything about a hardware mod?
He said "I order a Rigol 804".
in which only one is safe and reliable (Delta).
I mean the Delta one, not some deathtrap phone charger or something.
-
Original thick background (which had channel color if this one was selected, grey otherwise) literally I changed to the line on the right side. If You watch closely, it changes color in the same way as in the original app. Now You made me idea to make this line thicker. Right now it's 1 px. I think 3 px or maybe 4 px should be good enough to see which one is selected.
I changed it to the 3 px and it doesn't look as bad as I suspected - quite the opposite. Also I didn't know before, there was a second one line of top of first - because of it, color was not much visible. So I removed it.
I attached screenshots for each channel selected.
-
I mean the Delta one, not some deathtrap phone charger or something.
I don't know if You missed quite long discussion on this forum, but Rigol provided this series with different power supplies. Each one, except Delta, are the death traps.
Maybe in EU selling unsafe products is highly regulated and basically forbidden, but there is no one, that checks what is in the ship containers or packages. Maybe their "authorized resellers" had some issues from authorities or they have seen this discussion and decided to provide Delta brand instead. Hard to tell, because Rigol doesn't give a sh*t, unless situation can cause significant decline in sales.
As I wrote in this mentioned discussion, I tested my own Lite-On with the Riso meter (insulation tester in other words) and very quickly I had a proof that this PSU was very far from being safe.
-
I changed date format from yyyy/MM/dd to the MM.dd.yyyy. How does it look?
-
I did a mistake with editing. Month should be in the middle. Now it's dd.MM.yyyy.
-
Hello. I bought a project V0.2.1 with 125M memory depth, but I don't have time to install it yet. I'll probably make a live usb stick with Debian for easier use.
In the original Rigol application there is a bug related to the overall screen brightness - it doesn't remember it after turning it off and starts at maximum again. Did you manage to fix the problem?
-
Does the USB-C port on the rear support using a USB-C hub to connect USB devices? I know there’s a USB host port on the front, but I’m trying to use a single cable for everything.
-
Hello, didn't found it so if already known please point me to the post, is it known already what ICs are missing at dho800 PCB for logic analyzer? Is there dho900 PCB image available for public somewhere in good resolution?
-
hi,
here is dho800 teardown by David: https://www.flickr.com/photos/eevblog/albums/72177720310962700/with/53165528039 (https://www.flickr.com/photos/eevblog/albums/72177720310962700/with/53165528039)
if u search this thread u might find dho924 internals pics from Norbert.
the LA missing parts are:
- 40 dip connector (2x40P 2.54mm Pitch)
- 2x K4B4G1646E-BCNB DDR3L 2866 (improve LA acquisition speed)
- 1x MPPX3630
- 2x TP1282L1-VR
see https://live.staticflickr.com/65535/53164740007_247a1d6c45_3k.jpg (https://live.staticflickr.com/65535/53164740007_247a1d6c45_3k.jpg) for LA connector and missing op-amp section just above
and https://live.staticflickr.com/65535/53165761460_9c043444ca_3k.jpg (https://live.staticflickr.com/65535/53165761460_9c043444ca_3k.jpg) for FPGA DDR3 memory and (missing) AFG section
br/Piotr
-
Are those ddr3 chips really used? If I flow them in unit will automatically detect extra mem but otherwise will work ok as well?
-
hi,
i've not done modification yet, just ordered parts are ready and awaiting high zen.
here is S2084 vlog showing the difference when doing LA: https://www.youtube.com/watch?v=2jP3XbA_G48 (https://www.youtube.com/watch?v=2jP3XbA_G48)
br/Piotr
-
[attachimg=1]
I would like to express my gratitude for the reception of my work. It allows me to continue improving the usability of our equipment without compromising its main function, which is to work as a calibrated instrument. As usual, all people who have purchased the version compatible with firmware 00.01.04 will have access to the new version free of charge.
Regards
MRiscoC
-
Guys, would it be difficult to add simple averaging of N FFT spectra (by entering N, N=1 to 10000 for example), and an option for creating the FFT graph with log10(frequency), for example?
PS: and the best case - when entering in a pre-amplifier gain (like A=1 to 1E6) it will show the noise power density (or basically a simple math with the FFT bins)?
-
Guys, would it be difficult to add simple averaging of N FFT spectra (by entering N, N=1 to 10000 for example), and an option for creating the FFT graph with log10(frequency), for example?
PS: and the best case - when entering in a pre-amplifier gain (like A=1 to 1E6) it will show the noise power density (or basically a simple math with the FFT bins)?
Something like this?
https://www.youtube.com/watch?v=mO99S1H-xRQ (https://www.youtube.com/watch?v=mO99S1H-xRQ)
-
The "averaging" means that you see the static graph (not a waterfall) in some format (like log-lin, log-log) and the FFT spectra there get smoother and smoother with each new FFT measurement increment..
At X averagings you will see a nice line (not a hairy one).
Here we talk noise signals, but it works for any "stationary signal".
With FFT if you want to be say 1% around the "real mean" with the noise spectra you have to average 10000 FFTs (an example only, it goes 1/sqrt(N), where N is number of averaged spectra).
-
The "averaging" means that you see the static graph (not a waterfall) in some format (like log-lin, log-log) and the FFT spectra there get smoother and smoother with each new increment..
In the upper left plot, the yellow trace is an N-average of the FFT trace.
-
Aaah, ok, I see..
..and to beat the Siglent - could the freq be in log10(freq)? :D
Such we see the bins "evenly" (sort of, they will be not, but such they are visible) distributed through decades?
Like you have 10div each 100secs (example only) so the lowest frequency in the fft could be in milliHertz (or lower) and the highest in XXkHz - that is many decades (afaik the FFT is always max 1Mpts, so 5-6)..
A typical graph people want see after N averagings:
-
Aaah, ok, I see..
..and to beat the Siglent - could the freq be in log10(freq)? :D
Such we see the bins "evenly" (sort of) distributed through decades?
Like you have 10div each 100secs (example only) so the lowest frequency in the fft could be in milliHertz (or lower) and the highest in XXkHz - that is many decades..
You need to press the XLog button on the top row. But you are going to have a non uniform plot:
Image from an old version of DHOtools:
[attachimg=1]
-
Such we see the bins evenly distributed through decades?
This would contradict the mathematical definition of a DFT (or FFT). A DFT calculates linearly spaced frequency domain samples. While you are, of course, free to plot these samples on a log scale, their native spacing remains uniform in linear space.
Rather than sampling the DTFT spectrum of the windowed signal using a DFT, one could use a CZT instead. This would enable the DTFT spectrum to be sampled non-uniformly (e.g. on a logarithmic scale, or even an arbitrary scale). However, the spectrum analysis filter still retains the same shape and bandwidth at each frequency point.
If you want the filter bandwidths of the filter bank to be non-uniform as well, you will need to use something like a wavelet transform, which is no longer a DFT or FFT at all.
-
Sure they will be not as I wrote finally above..
-
Re DHO-824 - do you see "dBm/dBV" in the FFT menu?
I can see that in the user guide, but not here (v 00.01.04.XX) - I can see dBV only..
Also where to get the XX? I upgraded from 1.03 in January, but not sure what was the XX..
-
Rather than sampling the DTFT spectrum of the windowed signal using a DFT, one could use a CZT instead. This would enable the DTFT spectrum to be sampled non-uniformly (e.g. on a logarithmic scale, or even an arbitrary scale). However, the spectrum analysis filter still retains the same shape and bandwidth at each frequency point.
The CZT seems to be lost in time, altho I think someone mentioned Keysight was using it in one of their latest instruments. Back in ~1982 we developed a hand-held (well text book size) Real Time Spectrum Analyzer based upon the CZT, it utilized custom long CCDs for the complex convolution which was performed in the discrete time continuous amplitude (DTCA) domain. It took the computing power of a 1/3 of a Cray One at the time to do the same computations with an FFT!!
Anyway, these new 12bit entry level DSOs seem to be generating some interest in low frequency noise analysis/characterization. Sure hope iMo is successful in getting the noise spectral density plots as shown, that would be really impressive indeed!!
Best
-
Aaah, ok, I see..
..and to beat the Siglent - could the freq be in log10(freq)? :D
Such we see the bins "evenly" (sort of, they will be not, but such they are visible) distributed through decades?
Like you have 10div each 100secs (example only) so the lowest frequency in the fft could be in milliHertz (or lower) and the highest in XXkHz - that is many decades (afaik the FFT is always max 1Mpts, so 5-6)..
A typical graph people want see after N averagings:
This should be great if folks can create graphs like this with these entry level DSOs!!
Maybe we should change the title wrt these noise analysis/characterization uses with these DSOs and not refer only to Siglent.
https://www.eevblog.com/forum/testgear/siglent-fft-uses-for-low-frequency-noise-analysis-and-investigation/ (https://www.eevblog.com/forum/testgear/siglent-fft-uses-for-low-frequency-noise-analysis-and-investigation/)
Overall having all the knowledgeable "low noise DSO folks" concentrated in one thread should prove useful for everyone with whatever brands they have, hopefully not creating the usual DSO wars!!
Best
-
Creating such a functionality which performs well is not easy and usually requires a lot of testing and practical measurements.
I doubt it could be done effectively while communicating with the vendors only (sw and/or hw). Ideally there is a "versatility built in" - allowing the "creating your own functionality upon the existing o'scope ecosystem", like a built-in script language or something like that. We do not have that yet, so the only feasible option I see is to use the scopes as digitizers only and do the math and graphs off line (like in python etc).
On the other hand you do not need an 2Gs/s with 100MB of memory oscilloscope to mess with noise measurements of this nature, almost anything will do as well..
-
What is your opinion: is it possible to extend the bandwidth by replacing the amplifier in the front-end, or even by replacing the entire front-end with one matched to 50 Ω, similar to the approach I have seen in another design built on a custom PCB, soldered directly on top of the original front-end?
-
What is your opinion: is it possible to extend the bandwidth by replacing the amplifier in the front-end, or even by replacing the entire front-end with one matched to 50 Ω, similar to the approach I have seen in another design built on a custom PCB, soldered directly on top of the original front-end?
Front-end in this series (DHO800&DHO900) already has bandwidth above 1 GHz, so why You want to replace it? 50 Ω termination can be added very easily both externally and internally. In the second case, You can use four 49.9 Ω 0.1% 0.25 W resistors and solder them in serial-parallel to the joints of the BNC socket on the PCB. I did it in my scope in one channel along with the increased bandwidth by removing filters.
-
Thanks for all your work on this Norbert!
I'm looking at the DHO804 as a first scope and they're on sale right now, before I go through with this I just want to confirm a few things given the quotes below;
with your firmware / patreon purchase
1. the 70Mhz can be upgraded all the way to 270MHz? (or 250 safely)
2. the logos that appear on the screen during boot and on the interfaces can be changed or customized? is that just by you or can we modify our own logos / images?
3. does no. 2 include font modifications on our end?
4. it's possible to increase the memory depth of the scope beyond the 25/50 points given the physical hardware present on it?
and DHO8xx can be hacked to have 200 or even 250 MHz.
About 270 MHz IIRC, if we define bandwidth by the -3db drop -- that's determined by the analog input filter.
Of course it (or any of the 8xx or 9xx scopes) is usable at these frequencies in single-channel mode only, <...>more realistically, up to 1/3. This is determined by the signal reconstruction algorithm, which sucks in these scopes (the Siglent's is better, for comparison).
that font that I used for the boot logo for the scope, was made by Airbus and they used it on the screens that pilots use in flight decks to make You safer - even by making their own font (sadly they made some simple mistakes around redundancy in FBW computers...).
Even with the source code, Android is more like a toy, than operating system. If Android is based around (modified) Linux kernel and it's safer and (as they say...) and more efficient than regular Linux/GNU, then why most expensive data centers (including Google which maintains Android) use "regular" Linux instead?
There's now three different ones to choose from...
Some or all of those "new" decoders may not work properly or at all - looks like there is no full coverage in code, like a max and min threshold levels that You can set - in this case there is a input, so You can chose whatever You like, as long it's black (I mean 0 V). In such case, I need to add or change some code - likely stolen from a DHO4000.
Believe or not, there is a code for even more decoders and triggers, but that will not be easy to make them work - more or less.
Anyway, couple days ago I "succeed" to put this into 2 GSa/s, but there were random spikes added to the waveform, which were shorter than the time of one sample. Obviously those spikes comes from the app, not from the hardware. Lately I found some fragments that probably can be changed to get rid of those spikes.
But first things first - now Im working with the user selectable bandwidth limits (filters in AFE). Currently 20, 70, 100, 125 are working (maybe also 200 - I remember it was working and now it's not...), but that's kinda not much options - at least for me. Something around 250 and 400 would be nice - in that case I will be able to do auto bandwidth option (all options for each channel separately) - lower sample rate will change bandwidth to lower and inversely. I think at least 200 and 250 are possible (DHO4000 has 250 setting - but I don't want to copy huge amounts of code - at least for now).
BTW. I wonder how many users would wan't to have 250 Mpts memory depth. Theoretically it can be done, since 4 Gb chip gives space for 256 M pts. Currently I can easily change 125 M to 128 M (or maybe 2 ^ 27), but I didn't want to fix one Rigol bug just for those 3 Mpts extra - maybe I will one day - 128 M can be divided by 2 many times and that's pretty useful. Hacking for the 250 M pts (or 256 M) will take some time without any warranty to success (FPGA firmware which I didn't touch yet).
-
1. the 70Mhz can be upgraded all the way to 270MHz? (or 250 safely)
In my mod I removed all Rigol licensing system - which BTW, enables some options from DHO4000 (Rigol used same code to built this firmware). So by default You have as much bandwidth as the hardware will give.
Also, You can select manually (in the channel settings - separately for each channel) AFE filters: full (usually >250 MHz unless You removed or changed LC filters between AFE and ADC), 400 MHz, 125 MHz, 100 MHz and 70 MHz.
2. the logos that appear on the screen during boot and on the interfaces can be changed or customized? is that just by you or can we modify our own logos / images?
If You unpack zip package from my mod in version 0.3 (currently only as a enterprise edition, later also as a home edition after I'll finish fixing bugs) You should have folder named custom_bootsplash. Installation script is looking for a file named image.bmp in this folder. If it exists, it's used as a system bootsplash.
In previous versions (currently v0.2.1 normal edition), script was looking for a file named custom_image1.bmp in the same directory as the installation script.
3. does no. 2 include font modifications on our end?
You can put whatever You like as a bootsplash, like a full screen image with a text only (with any font You like) or some photo or anything else.
4. it's possible to increase the memory depth of the scope beyond the 25/50 points given the physical hardware present on it?
Hardware theoretically should allow to use 268 Mpts, because FPGA DDR chip is 4 Gb (single point takes 16 bit). Likely about half of it is reserved by the FPGA firmware (AFG, LA, screen waveform points, etc), so practical (tested) limit is 134 M. Currently my mod allows You to select up to 125 M. If You are going to use more than 62.5 M in total, I strongly advice to use single shot button instead of stop button, because if You will use stop in such settings and after that You will change time base (still in stop mode instead of single shot), waveform can be disrupted.
Because of the lack of the original source code, I wasn't able to determine why this is happening. I'm planning to do a workaround by adding code to make a single shot when somebody will use stop with such memory setting.
More details about changes that I made, You can find in the changelog for all versions from the beginning (https://www.patreon.com/posts/131407128).
-
What is your opinion: is it possible to extend the bandwidth by replacing the amplifier in the front-end, or even by replacing the entire front-end with one matched to 50 Ω, similar to the approach I have seen in another design built on a custom PCB, soldered directly on top of the original front-end?
you can check mso5k thread where similar mod is evaluated by Neekeetos
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg5175111/#msg5175111 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg5175111/#msg5175111)
-
Hello to All
I am strugling with almost bricker dho804, I want to make afresh starts, I saw reference to a clean SD CARD Image, but those link are dead. and the working one is not clean is with the hack, do anyone can share a link to any fresh sd card image?
thanks and regards
-
Hello to All
I am strugling with almost bricker dho804, I want to make afresh starts, I saw reference to a clean SD CARD Image, but those link are dead. and the working one is not clean is with the hack, do anyone can share a link to any fresh sd card image?
thanks and regards
Look at the very beginning of this thread.
-
I saw one that is already hacked, I need a clean one to start over. now is working but sometime I need to restart 4 times until it boot, I will check again, maybe is there and I did not see it.
thanks
-
still did find it in first page. so if anyone have it, please let me know
-
Laziness become very popular these days.
-
still did find it in first page. so if anyone have it, please let me know
Just use the image in the first page and copy your original /Rigol/data folder.
-
I did that already. and is king of working, but I have to try a few times and remove power to make it boot. may be a problem witn sd card and not image itself. thanks
-
I did that already. and is king of working, but I have to try a few times and remove power to make it boot. may be a problem witn sd card and not image itself. thanks
May I ask which SD card brand You are using?
Did You try to listen UART output?
-
I removed insignificant zeros and increased displayed precision almost in the whole app. How does it look?
If there will be no complaints, I will make final changes and release will be available likely in the next ~24h (as a free update if somebody purchased it earlier).
-
I am using the OEM one that came installed, lexar 32gb
-
I am using the OEM one that came installed, lexar 32gb
Originally used U-Boot somehow can't work on other SD cards than Lexar - that's why I was asking for the brand.
To be honest, I guess Your laziness didn't allow You to answer about UART, which I mentioned earlier.
BTW. After I will release 0.3.2 (or whatever version number it will be) likely I will prepare newer and modified (because of drivers and other things) Android - probably 9.x or 10.x, because of much less bugs, much better performance (faster boot and more wfm/s), possibility to install newer apps and possibility to run it from other SD card brand. But only if there will be enough support for it on my Patreon. Otherwise, I will be working with other oscilloscopes.
-
Originally used U-Boot somehow can't work on other SD cards than Lexar - that's why I was asking for the brand.
The oscilloscope boots and works fine with SD cards other than Lexar.
-
Originally used U-Boot somehow can't work on other SD cards than Lexar - that's why I was asking for the brand.
The oscilloscope boots and works fine with SD cards other than Lexar.
Maybe Your scope, but not mine DHO924S. However my "Orange Rigol" uses also U-Boot with similar version and it can boot from any card.
-
The oscilloscope boots and works fine with SD cards other than Lexar.
Mine too, tested with two other brands. Just make sure the new card has enough space for the complete image.
-
I've booted mine of cheapo no-brand SD cards from Aliexpress.
-
That's very nice. But why no exact model was mentioned? Too much to write this detail?
-
Hello!
I am planning to buy DHO804. As far as I know, it should arrive with firmware 00.01.03.
Please tell me, does this version go up to 924, and is it possible to activate LA?
Thanks in advance!!!
-
1. This version 1.03 has a bug and it is absolutely necessary to update to the latest 04.
2. In order to "altivate" LA, in addition to software, you will need to solder several elements on the PCB.
All of this is described in the topic.
-
Hello! Thanks for the information. If it's not too much trouble, please tell me where to look for modification details, there are already 157 pages in this thread that I'll have to study until I'm old)))
-
There is another way, but it is paid. This one is free.
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)
-
Please tell me, does this version go up to 924, and is it possible to activate LA?
Yes, but there's no connector on the front.
-
As for the LA connector, I understood (after reading part of this thread) that it can be soldered and it will work. Is that true?
-
Is the hardware capable of Wake-on-LAN (WoL)?
-
V0.3.1 is released (https://www.patreon.com/c/norbertkiszka/shop?).
It's a free update for those who previously purchased normal or enterprise edition.
Changelog for the v0.3.1:
- Fixed rare and random no waveform in the roll mode
- Fixed LA labels positions when size is changed to small or medium
- Fixed systemui buttons showing only home button instead of three buttons (back, home, recent apps)
- Fixed waveform rendering for low time base when roll mode is off
- Fixed waveform disruption when scope was in the stop mode (but not after singleshot), memory depth was above 62.5M and time base was changed (while scope was still in the stop mode)
- Fixed reason of crash that happened for one user (unable to reproduce) while using screen keyboard
- Fixed arrows in popup windows self-cal and fft
- Unavailable memory depth options in the roll mode now are hidden to avoid confusion
- Scope app now is executed before rigol.launcher will do it, which decreases total boot time by about 5-10s
- Another translation fixes, mostly in untranslated Chinese
- Performance improvements in initrd (CPU now works at full speed from the early boot)
- FPGA boot address is restored to 0x400000
- Multiple optimizations in the Rigol Launcher, especially in the handling physical buttons and knobs (Launcher is handling input from these, not the scope app)
- Removed Rigol opensource document (html) browser, because it was loaded on each app startup and increased it's time. Document contained only lies from the Rigol they said they will sent source code upon request, which they never did
- Removed buggy network settings in the app, since it was taking a lot of system resources and Android settings can be used instead
- Added shortcut to Android network settings in the Utility Settings, which now is the default subpage
- Added previously hidden Utility option: screen saver
- Optimizations in the multiple app functions (in some places execution time decreased from ~5s to ~1s)
- Optimizations in the math functions, mostly FFT. Measured FFT update rate was more than 30% faster
- Optimizations in deinterleaving channels, which gives more waveform updates when there are two or more channels enabled
- Waveform update rate is increased from ~85 k/s to ~100 k/s for 10 kpts, 50 ns/D and linear interpolation
- LA update rate increased to 56 k/s
- Decreased app startup time by about 10%
- Removed unnecessary '/' at the end of displayed values of time scale and vertical scale
- Displayed dot time now has format 0.#, which means it will display proper time like 1.6 ns instead of 2 ns, which was not true
- Many other displayed values will display one or two more decimal numerals (digits after dot)
- Removed insignificant zeros from values displayed on screen
- Increased visibility of trigger sweep mode displayed as a green letter in the top bar
- Installation script now enables dark (night) mode in Android
- Ethernet driver loading (insmod) is moved from start_rigol_app.sh to the bootApp.sh in case of user error in modifying start_rigol_app.sh
- Posix installation script is more human friendly.
Changelog for the v0.3 is twice that long. (https://www.patreon.com/posts/131407128)
Hello. I bought a project V0.2.1 with 125M memory depth, but I don't have time to install it yet. I'll probably make a live usb stick with Debian for easier use.
In the original Rigol application there is a bug related to the overall screen brightness - it doesn't remember it after turning it off and starts at maximum again. Did you manage to fix the problem?
Sorry for the late response. I had coding marathon in which I fixed this (in version 0.3).
Probably You heard too many myths about Linux/GNU. Actually Android is nothing else than Linux, but without GNU part, different GUI and tools. Current popular distributions like Debian works out of the box, which is complete opposite of the Windows, when You need find and install drivers, which often either doesn't work or makes a crash at boot. Couple years ago I was buying and fixing broken laptops - on each one Debian was working without need to change or install anything - not only Live version, but also swapping disk from one computer to another. Installing anything on the Windows with was often a nightmare. With Debian I only need to flash disk image, which saved my many hours of work.
If You have already flashed image on the USB disk, only thing that You need to do is to change boot device (it depends on Your computer, but usually You only need to press one key from F1-F12 on the keyboard at the BIOS screen after powering up) and after that wait about two minutes and it's ready to go. Using Windows today is good for masochists. Now it has 3 times users than 10 years ago, for this and many more reasons, including it's easier than Windows. But people likes myths. I will just wait until somebody will repeat them here.
As for the LA connector, I understood (after reading part of this thread) that it can be soldered and it will work. Is that true?
There is a post somewhere on this forum with many details how to make it and even there is a pinout and differences in the voltages in this socket between DHO800 aand DHO900. I can't find this in my browser bookmarks, but it is somewhere.
Is the hardware capable of Wake-on-LAN (WoL)?
I think no. Maybe if there is such posibility in the used Etherned chip, but that will require modification of DT in SD card and physical modification. However, it's possible to turn it on by switching of external power supply (and changing one setting in the app). I can confirm that works - at least in my mod.
-
As for the LA connector, I understood (after reading part of this thread) that it can be soldered and it will work. Is that true?
The DHO800 series (including the DHO804) is missing some memory modules and LA connectors from the factory, which are present on the higher-end DHO900 models.
-
Hello again, I Finaly got the log, and just by chance I got one failing and one working. I am thinking is an SD problem. and randonly works and fails.
what do you think?
-
Hello again, I Finaly got the log, and just by chance I got one failing and one working. I am thinking is an SD problem. and randonly works and fails.
what do you think?
Remove the card, blow some air into the socket and clean contacts on SD card. If this problem will repeat (seeing this log I guess it will do), You have either damaged data on SD card or Your SD card is dying. In such case buy a new one and flash it with a backup image. If this will not help, either You have problem with card socket or a cold joints.
-
I think no. Maybe if there is such posibility in the used Etherned chip, but that will require modification of DT in SD card and physical modification. However, it's possible to turn it on by switching of external power supply (and changing one setting in the app). I can confirm that works - at least in my mod.
What did you switch on?
-
I think no. Maybe if there is such posibility in the used Etherned chip, but that will require modification of DT in SD card and physical modification. However, it's possible to turn it on by switching of external power supply (and changing one setting in the app). I can confirm that works - at least in my mod.
What did you switch on?
Utility -> Settings -> Power status.
-
Norbert I saw the announcement for V3.1 and went to your site. I was looking for the installation instructions before I purchase as I would like to prevue that information.
Any chance you would post a link to that document?
Thank you,
Sam
W3OHM
A DHO924S Owner
-
V3.1
v0.3.1 to be precise.
I was looking for the installation instructions
There is a fully POSIX compatible (Linux, MacOS, FreeBSD, OpenBSD and many many others) script, that does all the job including making backups before the installation. For the Windows, things are not so bright, because this system is complicated as hell (both to develop software or just to use it to do basic things), so I only created two simplified .bat scripts that will reduce workload a bit.
Because many people believe in myths (same human genes when many believed in dark magic) and still use this cr*p (I mean MS software), I started working to do a .GEL package, so when I eventually finish it (which I can't guarantee, because I must bypass Rigol and Google stuff), this will be completely system independent.
If You don't use any POSIX capable system, You can simply use any live system working from USB (I suggest this one (https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-13.0.0-amd64-mate.iso)), which doesn't require to install any drivers, because in opposite of Windows, everything is preinstalled, from 40 years old devices to newer ones - including most of the GPUs. Just download image, flash it on USB stick, boot computer from it and run this script. 5 seconds of work and 5 minutes of waiting (plus about minute to boot operating system on a computer). Instead of live system, You can use virtual machine (virtualized computer with same or another OS), which some people did.
Script needs only two things. Correct IP of Your oscilloscope and confirm (by pressing enter) to do installation, which will ask after it will create backups. In case of Debian and Debian based systems (which is ~95% of distributions) You don't even need to install adb, because this script will do it. If You know how to use oscilloscope, I guess You are able to put IP address from the keyboard. Nothing more and nothing less.
If You wonder how to hack Android to make this install possible, this script does it (also fully automatically) in about one minute. To be precise, in current version this script has as many code lines as my scope model is, which is 924. About half of those lines, was done to be idiot proof as much as possible and to make working with modifications that Rigol did, without telling to anybody - and they did such in lately sold DHO800/900 (not only different PSU, but also low level OS changes that can't be done in .GEL packages, at least not without some tricks).
So to be clear:
1. Unpack ZIP package.
2. Run the script.
3. Read what the scripts says. Which is practically only this:
4. Put IP address of Your scope and press enter.
5. Wait until backups are finished.
6. Press enter to confirm installation.
7. Wait about 5 minutes.
-
Nobert,
That appears to be really slick!
So it looks like I could simply use a ethernet crossover cable to do the physical connection and enter the IP address in a browser and run your scripts!
Sounds easy peasy to me!
Thanks,
Sam
W3OHM
P.S. I need to add this to my every expanding project to do list!
-
scripts
In case of POSIX compatible systems, it's only one script. For Windows it's two.
I just had second person which tried installing from Windows and something failed. Sometimes I can't understand why so many engineers (about 80 %) are still using Windows - there is no single day without at least one problem with it. Personally I gave up with it 20 years ago, when one small bug caused to lost all my data on my hard disk. Back then it was hard to have good software for doing electronics on Linux, but today it's quite the opposite.
-
Patreon (I mean service with this name) again did something very bad.
I figured out what went wrong with this Windows scripts and I made new zip file with fixes to put into Patreon. But page told me that product page editing is disabled and it also told that I should make a new product... In other words, Patreon told me that I should make separate product for one quick fix of one bug and (at least) double charge everybody.
Of course, they don't have any link to their contact page (some similarity to scam pages and big corporations) but quick search with Duckduckgo (much better than Google) finds a page to contact with them. I wrote, if they will not fix it in 24h I will go somewhere else. Which I will do. BTW. In EU it's allowed by law to gave opinions about companies. Once I had issue with one lawyer which assumed that I don't know my laws and he regretted it very quickly - with very bad opinion on web. Even offered me money, which I didn't take, mostly because his conditions were a pure scam - long story.
Speaking of these scripts, If somebody had issues and not reported it for some reason, replace and run fixed scripts as in the txt file with instructions. These fixed scripts are here: http://elektrykplakal.pl/installation_scripts_windows.zip (http://elektrykplakal.pl/installation_scripts_windows.zip).
-
The DHO800 series (including the DHO804) is missing some memory modules and LA connectors from the factory
You don't need the memory though, it works fine without it.
Somebody mentioned you get higher waveforms/sec. with the modules installed but I haven't seen confirmation and they aren't required.
-
Great to know that you made some improvements.
BTW, the Rigol MSO5000 has Zone Trigger which is very useful. I haven't found Zone Trigger on DHO4000 yet. Is it possible to have Zone Trigger on DHO800/DHO900?
-
Great to know that you made some improvements.
BTW, the Rigol MSO5000 has Zone Trigger which is very useful. I haven't found Zone Trigger on DHO4000 yet. Is it possible to have Zone Trigger on DHO800/DHO900?
There is a dead (unused, because other code doesn't execute it) code for zone trigger.
To test it and eventually put this into usable code, I need:
1. Change code in Assembly. While binary is compiled and I don't have source code, I can't just add something. I can only change existing machine code. For example, if there is a compiled function with switch-case, I just can't simply add another case, because I will overwrite next function or something else - in compiled binaries all functions takes constant size, one after another and there is no free space.
Because of mentioned lack of source code and other limitations, I need to change one single CPU instruction at the beginning of function to a jump into unused code (at way different memory address). In this unused code I need to make a some condition in machine code (kinda Assembly but I can only modify what is already - small mistake in the middle can force me to make a half of it from scratch, which can take hours of work).
2. After making temporary changes, I need to test it.
At first I need to pray, to not have any crash caused by SIGSEGV or any other problem that will require a lot of time to diagnose and to fix small mistake. Mistakes are extremely easy to do, when dealing with executable binary without source code. I know in C (or C++ which I hate) this is extremely harder to make mistake and extremely easier to fix, but I will repeat once more: I don't have source code, only compiled binary, so this is not the case. Maybe someday there will be somebody brave to (somehow) take source code from Rigol, but I have some doubts about that.
I can't say if making this test code will take 15 minutes, 15 hours or 15 days. Because I don't know how many problems I need to face. This is almost like dealing with the extremely big electronic device without schematics and no documentation - You can never know.
Lets say I finished temporary code and it works. Now I need to pray to be any support in FPGA firmware for this trigger and to be working properly. Hacking compiled FPGA binary firmware is at completely another level - so either it will work or it will not and I lost a lot of my time with nothing in return. I never heard of anybody doing FPGA firmware hacking (personally I tried to achieve more than 134 Mpts which is the current maximum, but it was too much time consuming).
One bright side is: FPGA firmware from DHO4000 works 100% properly on my DHO924S, at least what I tested. Only difference I noticed, is when I call unused function that takes some data - in both firmwares it gives slightly different data, but as I said, it's unused anyway. So if one will not work, I can pray for FPGA firmware from DHO4000.
Lets now say, it looks like it's working (which I will repeat - it's not guaranteed). Now I need to test if that change breaks anything, like other triggers, LA, AFG or self-calibration - this last one is the most annoying when it's not working, because testing fixes, requires to run self-cal again and again, which everytime it takes half hour. Not only highly time consuming but also very boring.
Lets say, we had luck and everything looks good. Now I need to create new code for UI to set-up this trigger by regular user (instead of temporary hacks). I need to make almost everything from scratch, every button, switch or input with values to setup from keyboard with limits set appropriately to current conditions. Normal user doesn't see this, unless something doesn't work properly - in such cases what I can only hear are complaints, as if I did it on purpose...
Anyway, to do UI changes, I need to deal with much more annoying languages. Exactly Smali and Android layouts. Believe or not, but whole Android system was made by idiots (Google, You can sue me, Im waiting.). Android become popular, because of marketing and Android-Studio, which is software that allows most stupid people on earth to make an phone app. But this (extremely slowly) generates code that is very far from being professional or easy to maintain. And when You don't have original files that Android Studio created (beside of only apk file, which we all have), it becomes much more difficult to make any changes, often including changes that can look extremely easy to make for somebody who is not a programmer.
There is a lot of people who told me how usable is my mod and how many other changes they want. But try to take one minute and look at another side, which is me. If somebody wants to have some extremely useful functionality, optimizations (everything working 5x faster), bugfixes or any other changes, don't expect to somebody seating one month and doing this for free or half-free. Either do it by Yourself or become a supporter. Currently what I see, support 3$ per moth is too much for most people, but in same time there is a hundreds of users of this series who wants my mod and future changes.
If those things, will not change, upcoming v0.3.2 will be the last release, at least with a new features/optimizations. I just don't want to spend another months doing something that gives almost nothing in return. Hacking existing software without source code is not like a black magic in Hollywood movie, when somebody screams hocus-pocus and suddenly there is a palace.
Finally answering Your question, there is a chance to make it work. But if I will still have so small support as it is today, I will start doing something completely else.
-
Great to know that you made some improvements.
BTW, the Rigol MSO5000 has Zone Trigger which is very useful. I haven't found Zone Trigger on DHO4000 yet. Is it possible to have Zone Trigger on DHO800/DHO900?
....
If I own this scope I certainly support your work because you are doing a wonderful job. You are implementing on a cheap scope features only available on more expensive ones and for 36 bucks year is like a free meal. Since you're already investing quite some time and neurons, create a final release that you can sell with a fixed price. You know society are used to free software :popcorn:
-
You know society are used to free software
And they think software engineering is simple like a magic in movie, as I said previously.
Speaking of free software. There is a countless open-source developers (or in other word programmers). Many of them are doing completely free software as a job. But they don't live from power of the sun, but rather from donations. Even Google which in last years become a very greedy company (they are even more bad than Rigol is) is still supporting projects like Linux and others. Because without Linux, there is no Google. All (at least most of it) their servers and Android is based on that.
Without new features and bug-fixes in open-source projects, Google and other companies will go bankrupt very quickly. Because of those donations, I can buy a computer where there is not yet (working) driver for a Windows, but everything works with a Linux out of the box - just swap a disk from one computer to other one. Most insane thing in open-sorce are the drivers for GPUs, where there was no documentation (how to communicate for each one feature, which are hundreds) and closed-source driver from manufacturer doesn't work properly - all of it done with extremely tedious reverse engineering. In the end, open-source drivers based on rev. engineering often works much better than "original" ones.
-
I'm not in that field of programmers and software.
But reversing some BIOS's and looking at some source code i see sometimes they use asm in some cases and compiler take care and insert that code as is.
Maybe it is a way, for unknown code yet, leave it in assembly and instruct compiler to insert it at required address.
That way you can build it from source code (your project) with assembly (part of original code) inserted in some places to keep offsets, jumps and calls.
You can jump before or in place of switch-cases then depending of case jump back when required and also add extra cases if enough free space.
-
But this is not the BIOS that has 512 kB when it's compiled. libscope-auklet.so is 12.3 MB. I don't know if there is any software that can turn compiled .so lib into asm file(s) or C with asm inserts, but those 12.3 MB may sound like a small file, but decompiled (in the C pseudo-code, which is very far from working and not able to compile it back) is huge as hell. So it can make it more time consuming - compiling 1 GB (or more) can take forever. Even when somebody will donate some super fast computer, it will take huge amount of power at each compile time - where I live, energy is literally the most expensive in the whole Europe if not in the world...
It will be much better and at some point much faster to rewrite it from scratch. There is no need to understand every each part of the code - I just need to know (both from the current knowledge and future rev. engineering) what to send or receive to/from FPGA/AFE/etc and when, which in many cases is much easier than dealing with it in a current form.
This lib was compiled completely without any optimizations enabled (likely outsourced company was unaware of such thing). Because of that, huge part of it is like a open book for me. Quite have book, but still readable. That's why my mod in some places is even 5-10 times faster than stock one. Doing optimizations usually I don't need to completely understand what is going on is some part - I can just do exactly same mysterious logic, but in a similar way like compilers do when they have enabled optimizations - those also can't understand (source) code, but it's just implementing it in a different way.
Edit: in case of triggers, it looks like that will be not just only adding one condition and execute mentioned dead (unused) code. Free space in this lib is not the problem - currently it's more than enough. Beside of it, there is also UI part, which is very Android dependent - which is the worst part, at least for me.
Java and Android xml layouts looks like deigned by kids for kids. Even very old HTML (which all websites uses) and CSS are 100 times easier to develop or change anything - for many years I was working with widely known websites in the internet, so I know what Im talking about.
-
Does anyone try this command ".\rigol_vendor_bin.exe -N #"?
It seems the serial number will update ramdomly. I try to write the orginal serial number in it but failed.
-
Does anyone try this command ".\rigol_vendor_bin.exe -N #"?
It seems the serial number will update ramdomly. I try to write the orginal serial number in it but failed.
RTFM. Use -h option and read carefully.
-
Does anyone try this command ".\rigol_vendor_bin.exe -N #"?
It seems the serial number will update ramdomly. I try to write the orginal serial number in it but failed.
RTFM. Use -h option and read carefully.
Hello,
Thanks for the reply, I did read it before and try both V1.2 and V1.3 many times,
-n random serial number
-N # set serial number
but neither -n nor -N could write the specificy serial number. I'm still not sure what I have missed.
-
Does anyone try this command ".\rigol_vendor_bin.exe -N #"?
It seems the serial number will update ramdomly. I try to write the orginal serial number in it but failed.
RTFM. Use -h option and read carefully.
Hello,
Thanks for the reply, I did read it before and try both V1.2 and V1.3 many times,
-n random serial number
-N # set serial number
but neither -n nor -N could write the specificy serial number. I'm still not sure what I have missed.
Maybe review other options?
Anyway, why You need to set serial number? Random one works the same as the stock ones.
-
Does anyone try this command ".\rigol_vendor_bin.exe -N #"?
It seems the serial number will update ramdomly. I try to write the orginal serial number in it but failed.
RTFM. Use -h option and read carefully.
Hello,
Thanks for the reply, I did read it before and try both V1.2 and V1.3 many times,
-n random serial number
-N # set serial number
but neither -n nor -N could write the specificy serial number. I'm still not sure what I have missed.
Maybe review other options?
Anyway, why You need to set serial number? Random one works the same as the stock ones.
ah, that seems all. It did works the same, DHO804->DHO824 always change from DHO8A27** to DHO8A25** , just a little, how to say :palm:
-M # set scope model
-n random serial number
-N # set serial number
-a random MAC address
-A # set MAC address
Option strings require 'RKey.data' (or 'Key.data')
-l list available options
-o generate all option strings for the current series
-O # generate option string for feature #
-g generate .lic files instead of SCPI strings
-d debug switch
-
ah, that seems all. It did works the same, DHO804->DHO824 always change from DHO8A27** to DHO8A25** , just a little, how to say :palm:
Same as in the stock scope. I don't know if in rigol_vendor_bin this is forced to always do like that. It's open-source, so You can read and modify whatever You like.
-
ah, that seems all. It did works the same, DHO804->DHO824 always change from DHO8A27** to DHO8A25** , just a little, how to say :palm:
Same as in the stock scope. I don't know if in rigol_vendor_bin this is forced to always do like that. It's open-source, so You can read and modify whatever You like.
Thanks. :phew: |O, This is beyond me :'(
-
Thank you very much, @norbert.kiszka, for your hard work on this. There are so many aspects, both on the hardware and software side, that need to be reverse-engineered. I fully agree with you that creating a pure Linux version of the scope app would be the most practical solution. However, this is also a highly complex process, as all hardware and software functions would need to be reimplemented entirely from scratch.
One possible approach could be to split the project into smaller parts and have people focus on specific areas—for example, firmware for buttons and LEDs, or the FPGA firmware.
In the meantime, your software already looks really impressive — definitely worthy of Patreon support — and I’m looking forward to testing it once I’m back in about four weeks.
Best,
Julian
p.s.: which software do you use for disassembling ? ghidra, ida pro?
-
...split the project into smaller parts...
Or use original .so lib at the beginning to make a quick start. With a fake Android lib for printing logs.
which software do you use for disassembling ? ghidra, ida pro?
Ghidra. It's another software that make me think that all Java developers are kids that doesn't entirely know what they are doing. But I don't have anything better. BTW. about half of this scope app is Java code.
-
Hello everyone! DHO804 with firmware 00.01.03 has finally arrived to me. I decided to update to 00.01.04 right away, because I know that .03 is not quite normal. I downloaded 00.01.04.00.02 from the site, as it says in .txt, copied .gel to the root. I inserted it into the USB, DHO saw the flash drive, but when I click Update, it gives the error "no firmware available". Has anyone encountered this, and how to overcome it? The flash drive is 32 GB, FAT32.
-
Go to "Storage" and then to tab "Upgrade". Select USB drive, select .GEL file and press Upgrade.
-
Go to "Storage" and then to tab "Upgrade". Select USB drive, select .GEL file and press Upgrade.
Thanks for the tip!!! Came home, tried it, and 5 minutes later it updated)))
-
How does it look?
If text (for example time offset value) is longer, it will automatically resize and things on the right will move further into right.
If somebody is not aware, those shortcuts on the right are scrollable left-right.
-
Another change in rendering. White color of the vertical scale instead of the same as the waveform, which reduced readability.
-
Hi everyone,
I recently got the DHO804 and upgraded it to the latest firmware 00.01.04.00.02 through the update function on the scope. I have been using it for a while and decided to change the model to the DHO924 (I did make a backup through ADB, for whatever good it might do me). The issue I have is that on model DHO924 all of the goodies seem to be unlocked but I get no signal whatsoever.
I can change to all models below 924 and everything works just fine. Only 924 and 924S result in no signal being detected.
Has anyone else come across this before and knows how to remedy the situation? (I don't strictly need the 250MHz but having it is better than needing it further down the road)
-
on model DHO924 all of the goodies seem to be unlocked but I get no signal whatsoever
I have DHO924S and it works with SD card image (which holds firmware, including vendor.bin) from DHO804. You are another person who has problems with upgrading DHO800 to DHO900.
My mod works fine on DHO800 models (dozens of users) and it unlocks many goodies both from DHO900 and from DHO4000. Because they didn't made this firmware from scratch, but reused and modified firmware from DHO1000/4000. If You compare both (reverse engineering of firmware) You will see it's almost identical.
-
My mod works fine on DHO800 models (dozens of users) and it unlocks many goodies both from DHO900 and from DHO4000.
Thanks for the update. You mean the apk on your Patreon, right?
-
My mod works fine on DHO800 models (dozens of users) and it unlocks many goodies both from DHO900 and from DHO4000.
Thanks for the update. You mean the apk on your Patreon, right?
Yes, but this is not only apk. I also modified Android operating system, which this scope is using.
-
Don't get me wrong, I didn't intend to diminish the work you've put into it. :-+ I just wanted to clarify that this was what you were referring to and not some other mod that I hadn't seen.
Would I need physical access to the sd-card or can it be done solely via adb?
-
Don't get me wrong, I didn't intend to diminish the work you've put into it. :-+ I just wanted to clarify that this was what you were referring to and not some other mod that I hadn't seen.
Would I need physical access to the sd-card or can it be done solely via adb?
Via adb only as for now. For the next release Im planning to do .GEL, as it's the case with Rigol firmware updates.
There are two sets of script(s). One script fully automatic (and it's also do backups) for all POSIX compatible systems (Linux, MacOS, BSD, etc), which does all the job with exception of connecting Ethernet cable and setting up IP on both sides. And there are two for Windows for half automated installation (instructions are included), but it doesn't make all system changes.
Making any software for Windows is a pain in the You know where. I tried to read documentation, but they made it extremely unfriendly and completely different than what is on all other operating systems - maybe it was on purpose? Anyway, booting computer from USB with Live image is extremely easy - but some people think in front that will be complicated, which is not true.
Edit: in other words, it's all done remotely with adb. Even if the script will crash for some reason (as for today I know one rare bug that I wasn't able to reproduce or figure out), it will work fine after running it second time.
-
That's good to know. ADB is perfectly fine for me and I am on Linux anyway. I tried to compile the rigol_vendor_bin but I wasn't in the mood to install the necessary parts for the 32bit compiler.
Just to let anyone with the same issue know, I have found a solution for my "absent" signal. I re-did the update of the latest firmware from USB, ran a self-calibration on the original model number (DHO804). Then I switched the model, rebooted and finally did another self-calibration. Now, everything looks as if it is in working order. I will have to run a couple of test to see if there are any hidden quirks. For some reason the switch from 900 to 800 works without any issues. However, going from 800 to 900 requires, at least in my case, the steps mentioned.
I like what you've done with the firmware and in due time, I can see myself supporting you and taking advantage of the features.
-
I tried to compile the rigol_vendor_bin but I wasn't in the mood to install the necessary parts for the 32bit compiler.
It works perfectly with 64 bit gcc compiler. I have modified rigol_vendor_bin on my Github (https://github.com/norbertkiszka/rigol_vendor_bin).
-
I didn't even see your version on GitHub. You got rid of the 32bit dietlib that gave me a headache. I'll give this a go once I get home tonight. I'm sure it will work just as expected.
-
The issue I have is that on model DHO924 all of the goodies seem to be unlocked but I get no signal whatsoever.
Has anyone else come across this before and knows how to remedy the situation? (I don't strictly need the 250MHz but having it is better than needing it further down the road)
Never heard that before.
Where did you get your vendor.bin from? What model does it show in system info?
-
Hi, I bricked my Rigol DHO804 by erasing some files from sd card.
I tried to write to sdcard image from 1st link, but my Lexar card says it it too small for image in first link.
I am doing this in windows. If I write it to 64GB SanDisk image My Rigol does not boot up.
I tried with different SW, but I can not get Rigol working again.
How to do proper image write to SDCard?
Regards, Ales
-
Do You know what files or in which directory?
Anyway, last partition can be resized just like that. Because in the MTD data, size of the last partition is set as to the last device (which is sd card) sector. I did it once for somebody.
-
I think I deleted something from android.
Why is my original sdcard different size than backup file?
Should I do anything else after restore image to sdcard?
like set boot partition or something?
-
Android is a one of many Linux based systems. Modern Linux systems uses ext4 type file system, which is very powerful, fast and easy to maintain. Resizing ext4 is not an issue - personally I did it hundred times - literally.
Also there is a simpler and safer way, especially in conditions like with this SD card. Create empty image (empty file or whatever), with size that You want. Use mkfs to make ext4 FS in it. Mount it same as the regular partition (I mean FS) - today You even don't need to add loop option, because it's done automatically. Copy files from original FS into new one (preferably by rsync, because it preserves all details, like modification time). Umount and move this image into SD card image. Use dd to get rid of unwanted junk at the end of SD card image. Pretty simple.
-
So there is only one partition on sdcard?
no boot or some other partition?
-
Hi, I bricked my Rigol DHO804 by erasing some files from sd card.
I tried to write to sdcard image from 1st link, but my Lexar card says it it too small for image in first link.
I am doing this in windows. If I write it to 64GB SanDisk image My Rigol does not boot up.
I tried with different SW, but I can not get Rigol working again.
How to do proper image write to SDCard?
Regards, Ales
My SD card size is also different from what is indicated on the first pages. Apparently in the latest revisions they installed cards with a smaller size. The dump size of my card was 31,299,993,600 bytes. And the Lexar 32GB card that I just received from Aliexpress is the same size.
-
Hi, I bricked my Rigol DHO804 by erasing some files from sd card.
I tried to write to sdcard image from 1st link, but my Lexar card says it it too small for image in first link.
I am doing this in windows. If I write it to 64GB SanDisk image My Rigol does not boot up.
I tried with different SW, but I can not get Rigol working again.
How to do proper image write to SDCard?
Regards, Ales
My SD card size is also different from what is indicated on the first pages. Apparently in the latest revisions they installed cards with a smaller size. The dump size of my card was 31,299,993,600 bytes. And the Lexar 32GB card that I just received from Aliexpress is the same size.
Can you share/send me your sdcard dump?
-
So there is only one partition on sdcard?
no boot or some other partition?
Are You a Windows only user?
Do You know what's the difference between partition and file system?
Why You didn't make at least one backup copy before doing experiments?
-
I can't attach it to the message.
-
So there is only one partition on sdcard?
no boot or some other partition?
Are You a Windows only user?
Do You know what's the difference between partition and file system?
Why You didn't make at least one backup copy before doing experiments?
I am primary windows use. I can do linux also. I am trying now your suggestion with linux file.
It was stupid of me that I didnt make copy, but I thought if I have vendir.bin and RKey.data, I will just reflash sd card.
-
I can't attach it to the message.
I know, can you share it with wetransfer or similar?
-
It was stupid of me that I didnt make copy, but I thought if I have vendir.bin and RKey.data, I will just reflash sd card.
First of all, if Your system (doesn't matter if this is a Windows, Android, Linux or some 2 kB experimental) looks like frozen/hanged it doesn't mean it is.
Around 20 years when I started with Linux based systems, X and graphic drivers were not so perfect like it is today. Once per about a month X crashed (X is a layer between kernel and graphical software) and usually opening console (ALT+CTRL+Fx) didn't work. But ssh was working fine before crash. After crash was working fine too. So from other computer via network I was able to do whatever I wanted and to do a proper system restart instead of making reset and risking to lose data or damage file systems.
If You want make such experiments with Linux based system (Android) and to fix when anything will go wrong, I advice to read some brief about file systems and how to handle them. Just only basics. Otherwise You will not be able to fix anything by Yourself. With such knowledge, You will be able to fix damaged (for any reason, including caused by hardware issues) file systems, without paying thousands of dollars to somebody just to recover only important files.
BTW. Modern Linux based systems (including Android) uses EXT4 type file system. Which is not only extremely powerful, but also fast, very fail safe (in case of power loss) and fast+reliable with automatic repairs (fsck) at system boot. That explains why Rigol "engineers" (read: idiots) did a sudden power down in these scopes instead of normal shutdown like they should.
Speaking of the system boot, Rigol did a hidden counter that counts how many times scope was booted. In my mod I removed it. Nobody want's a expensive paper weight just after warranty.
-
Never heard that before.
Where did you get your vendor.bin from? What model does it show in system info?
Sorry for the delayed reply. I bought the scope from banggood and the vendor.bin came off the scope after I did the update to the latest firmware.
In the about screen it shows model DHO824 (BW 200M). Originally it was DHO804 with 70M as is on the case.
-
Sorry for the delayed reply. I bought the scope from banggood and the vendor.bin came off the scope after I did the update to the latest firmware.
In the about screen it shows model DHO824 (BW 200M). Originally it was DHO804 with 70M as is on the case.
I have no idea what are You referring to. Please use quotes as I did in this post or make it more clear.
-
Now we have UPA :-/O
-
Now we have UPA :-/O
I know IPA, but not UPA...
-
Now we have UPA :-/O
I know IPA, but not UPA...
UPA is the power analysis function from DHO4000. What I mean I just made it work on DHO800/900.
-
Who said LA can't work with time base below 200 ms/D ?
https://www.youtube.com/watch?v=2Qz3MrSVcMw (https://www.youtube.com/watch?v=2Qz3MrSVcMw)
-
I'm a poor old man who could only afford the 2-channel version. I love the work here, and I have joined your Patreon to support you. I hope that being a 2-channel denizen doesn't reflect poorly on me here. :scared:
-
I hope that being a 2-channel denizen doesn't reflect poorly on me here.
In my mod, it's hardcoded to use all four channels. I never tested it on a 2-channel model - theoretically ext trigger should work as a third (fourth) channel. One channel will be dummy, since there is no AFE on PCB.
If You will have any problems, just let me know, so I will be able to make a fix if necessary.
-
I also have the 2-channel model with your mod installed, but I didn’t know I actually gained a crazy extra channel (you’re awesome 🤯). I’ll try it right away!
Mine is the 812 (if I had known earlier, I’d have gone for the 4-channel 70 MHz version 😅). Anyway, everything works perfectly on my side – and even more than expected – especially considering I’m no expert… it’s already a miracle I know where the power button is 🤣🤣🤣.
-
Hi, I tried with the third channel by connecting it to EXT. It does work on the 4th channel, although the calibration square wave is not exactly the same as when measured on CH1 or CH2. If you’d like, I can show you a picture.
-
In DHO8x2 external trigger physically is the same as normal channel, but in the stock firmware You can use it only as a trigger.
Also there are two or three resistors missing on this "trigger-channel". I have no idea why it's like that. But two first channels are identical.
BTW. You can add any DAC with parallel data input (including "COVOX" - resistor ladder) and You have AFG. There is a schematic of original AFG on this forum. All data is single-directional - I didn't noticed anything that check presence/absence of AFG or anything like that.
And You are right. There is no reason to go into higher bandwidth with DHO800 (with DHO924 You will get better probes than with DHO914).
Hi, I tried with the third channel by connecting it to EXT. It does work on the 4th channel, although the calibration square wave is not exactly the same as when measured on CH1 or CH2. If you’d like, I can show you a picture.
I will like to see it. You can make a screenshot ("quick" button is the fastest way) or photo with phone.
Maybe those 2-3 mentioned parts are the reason.
-
I hope that being a 2-channel denizen doesn't reflect poorly on me here.
In my mod, it's hardcoded to use all four channels. I never tested it on a 2-channel model - theoretically ext trigger should work as a third (fourth) channel. One channel will be dummy, since there is no AFE on PCB.
If You will have any problems, just let me know, so I will be able to make a fix if necessary.
Thank you! I will let you know how it goes. My scope arrives Saturday.
-
Here’s the picture (I’ll do all the tests you want, but don’t trust me too much – I might be the one messing something up 😅).
As you can see, channel 4 (the blue one connected on EXT) has the same amplitude, but vertically it looks wrong – at least that’s what I think 😒.
If you’d like me to run more tests, just let me know.
-
One question came to my mind. Did You execute self calibration after installing my mod?
If the answer is yes, then likely those 2-3 parts on this channel are the case. Look at the teardown photos - DHOxx4 has all identical channels. Almost the same with the DHOxx2, with exception of those resistors (or maybe capacitors - I don't remember precisely).
If You didn't, just do it and check in a same way.
BTW. I see one problem that I fixed lately (not yet released) - longer value of trigger point (voltage) doesn't fit in fixed size block - "mV" is partially hidden. Most of the top bar "parts" I changed to have minimal width instead - that also (usually) gives more space for more shortcuts on the right.
-
I haven't even received my scope yet, and I've upgraded to the Enterprise edition. Your work is simply outstanding!
-
Your work is simply outstanding!
Nah... There are people much wiser than me. Like she: https://www.youtube.com/@lauriewired (https://www.youtube.com/@lauriewired) (Github (https://github.com/LaurieWired)) - not only she has nice collection of many scopes, but she writes in much more programming languages than me. In comparison to her, Im just nobody.
-
One's greatness is not something that can be compared to another's. Each one of us possesses some innate talent that allows us to rise above the mundane. Whatever our particular talent may be, we should never diminish it by comparing it to another's - their talent is theirs, and our talent is ours.
-
Don't try to be better than others. Try to be better than You were yesterday.
-
Don't try to be better than others. Try to be better than You were yesterday.
Exactly!
-
Your work is simply outstanding!
Nah... There are people much wiser than me. Like she: https://www.youtube.com/@lauriewired (https://www.youtube.com/@lauriewired) (Github (https://github.com/LaurieWired)) - not only she has nice collection of many scopes, but she writes in much more programming languages than me. In comparison to her, Im just nobody.
She is definitely prettier than you :-)
-
Your work is simply outstanding!
Nah... There are people much wiser than me. Like she: https://www.youtube.com/@lauriewired (https://www.youtube.com/@lauriewired) (Github (https://github.com/LaurieWired)) - not only she has nice collection of many scopes, but she writes in much more programming languages than me. In comparison to her, Im just nobody.
She is definitely prettier than you :-)
on the other hand, beauty is in the eye of the beholder.
-
on the other hand, beauty is in the eye of the beholder.
Every girl with a huge collection of test equipment is pretty :)
-
How does it look?
If there will be no complaints or suggests, this will be in the next release. Maybe in the next few hours.
-
I like it.
-
HI guys, haven't been here for some time. I heard from one guy says that the dho800/900 can reach to bandwidth 400Mhz+ via modify a `inductance`. I have hack my device using `rigol_vendor_bin` and search this thread but not found any thing related how to increase the bandwidth to 400Mhz. Could someone point me out?
-
How does it look?
If there will be no complaints or suggests, this will be in the next release. Maybe in the next few hours.
That looks really good 👍 Nice work!
-
..Could someone point me out?
He removed the antialiasing filter (C and L smds there) in front of the ADC, afaik..
-
..Could someone point me out?
He removed the antialiasing filter (C and L smds there) in front of the ADC, afaik..
Those LC filters was mentioned many times on this forum. Removing them completely (removing and bypassing), gives bandwidth of around 1 GHz, not 400 MHz - which I personally did for one (last one) channel. Any modification with those LC filters requires to make a impedance compensation - originally there is a capacitor before both stages, which compensates impedance for higher frequencies. Without proper compensation it will work, but it will work badly.
Speaking of the filters. In the AFE, there are software driven low pass filters, exactly 20, 70, 100, 125 and 400 MHz. Which can be set separately for each channel in my mod.
There are more low pass filters (at least one, which is 250 MHz), but inside of ADC chip. Hacking it, will take me more or less two days (also changes in UI will take similar amount of time), but I think not many users are interested in this.
-
..Could someone point me out?
He removed the antialiasing filter (C and L smds there) in front of the ADC, afaik..
Those LC filters was mentioned many times on this forum. Removing them completely (removing and bypassing), gives bandwidth of around 1 GHz, not 400 MHz - which I personally did for one (last one) channel. Any modification with those LC filters requires to make a impedance compensation - originally there is a capacitor before both stages, which compensates impedance for higher frequencies. Without proper compensation it will work, but it will work badly.
Speaking of the filters. In the AFE, there are software driven low pass filters, exactly 20, 70, 100, 125 and 400 MHz. Which can be set separately for each channel in my mod.
There are more low pass filters (at least one, which is 250 MHz), but inside of ADC chip. Hacking it, will take me more or less two days (also changes in UI will take similar amount of time), but I think not many users are interested in this.
Now I understand there is a LC circuit as a low pass filter, as I know the LC filter has benefit for anti-aliasing and low the noise. But should we modify the LC value to upper the filter cutoff point instead of directly removing/bypass it? For example since the sample rate is 1.2GSa/s so a proper cutoff point maybe 600Mhz, then if I adjust the LC value to reach this point, will it better than just bypass them?
-
..Could someone point me out?
He removed the antialiasing filter (C and L smds there) in front of the ADC, afaik..
Those LC filters was mentioned many times on this forum. Removing them completely (removing and bypassing), gives bandwidth of around 1 GHz, not 400 MHz - which I personally did for one (last one) channel. Any modification with those LC filters requires to make a impedance compensation - originally there is a capacitor before both stages, which compensates impedance for higher frequencies. Without proper compensation it will work, but it will work badly.
Speaking of the filters. In the AFE, there are software driven low pass filters, exactly 20, 70, 100, 125 and 400 MHz. Which can be set separately for each channel in my mod.
There are more low pass filters (at least one, which is 250 MHz), but inside of ADC chip. Hacking it, will take me more or less two days (also changes in UI will take similar amount of time), but I think not many users are interested in this.
And would soemone pls tell me more details about the LC smd position in PCB ?https://www.flickr.com/photos/eevblog/53164740127
-
Now I understand there is a LC circuit as a low pass filter, as I know the LC filter has benefit for anti-aliasing and low the noise. But should we modify the LC value to upper the filter cutoff point instead of directly removing/bypass it? For example since the sample rate is 1.2GSa/s so a proper cutoff point maybe 600Mhz, then if I adjust the LC value to reach this point, will it better than just bypass them?
It depends of how many channels You want to use at single time and with what sample rate. Because 1.25 GSa/s is only for the single channel mode and only if memory depth is enough to cover whole screen space. That's why I modified only one channel. If You are going to often use more than one channel or often to use low time base, it's no point to make such modification.
And would soemone pls tell me more details about the LC smd position in PCB ?
Look at the traces between AFE and ADC.
-
Thanks! Now I understand. I found there are 4 groups smd component seems should be the LC filter just before the ADC RT8847IQ. I will also try to modify one channel to try. Do you has any suggestion filter cutoff point or suggestion lc component value?
-
Thanks! Now I understand. I found there are 4 groups smd component seems should be the LC filter just before the ADC RT8847IQ. I will also try to modify one channel to try. Do you has any suggestion filter cutoff point or suggestion lc component value?
Easiest way is to remove capacitors, replace inductors with 0 ohm resistors (or a thin wire) and replace "final" resistor to match impedance. But this is Your choice, not mine.
In my case in this one modified channel, I also added four 49.9 ohm 0.1% resistors to the input BNC - two in series and this times two in parallel.
-
Just tried install Enterprise on my 802, and got the following error:
Performing Streamed Install
Success
Warning: Command failed: remote_cmd_quietly pm disable com.teslacoilsw.launcher
Warning: Command failed: remote_cmd_quietly pm disable nu.nav.bar
Warning: Command failed: remote_cmd_quietly pm disable com.duckduckgo.mobile.android
adb: error: cannot stat '/home/kc5jim/Sparrow_Extended_v0.3.1/files_v0.3.1/root_v0.3.1/system/build.prop': No such file or directory
ERR: Command failed: remote_push /home/kc5jim/Sparrow_Extended_v0.3.1/files_v0.3.1/root_v0.3.1/system/build.prop system/build.prop
Script finished due to internal generated error.
Cleaning up.
Screen is on Installation in progress. Any suggestions?
-
adb: error: cannot stat '/home/kc5jim/Sparrow_Extended_v0.3.1/files_v0.3.1/root_v0.3.1/system/build.prop': No such file or directory
Check if this file exists and its size:
ls -l /home/kc5jim/Sparrow_Extended_v0.3.1/files_v0.3.1/root_v0.3.1/system/build.prop
BTW. Right now Im working on a .GEL file for the v0.4.
-
That file was missing. I copied Sparrow over again and the file is there. Ran the script again, and got this:
First stage finished. Oscilloscope will reboot and installation will continue. Please be patient.
Requesting reboot...
Waiting for the oscilloscope operating system to boot...
disconnected 192.168.12.209:55555
already connected to 192.168.12.209:55555
ADB connected.
adb root failed - probably adbd is already running as root.
adb: device offline
ERR: Can't find mmc device...
Script finished due to internal generated error.
Screen now shows Android is starting.
-
Replace script with this one from attachment below. Of course unzip it first. Either by GUI software or from terminal:
unzip install_posix.sh.zip
-
That worked, thank you!
-
Finally v0.4 with a .GEL file (installation from USB stick) (https://www.patreon.com/posts/dho800-900-v0-4-139423366) is released.
As for now, it's enterprise edition only. Home edition will be updated more or less in one hour.
Changelog:
- Fixed not working UPA (power analysis).
- LA now works in the roll mode (time base equal or lower than 50 ms/D) - only in the enterprise edition.
- Top bar elements now use auto width, which prevents from covering longer text (ex. 123.456mV) and makes more space for more shortcuts.
- Vertical scale values for analog channels now are always in white color, which increases readability - before it has same color as waveform, which often caused to be completely unreadable. One exception is in XY, because waveform has completely different color and there are two channels involved.
- Added open source scientific calculator.
- Changed shortcut "Flex knob" in the top bar to the small and floating version of calculator (on top of running app). Bigger version can be opened from it and from Android desktop (Nova launcher).
- Added open source screen keyboard.
- Added open source email client.
- Measurements upper part is now below shortcuts in the top bar, so it will not cover half of the shortcuts.
- Fixed temporary vertical offset after self calibration (no need to press auto after each self-cal as it was in v0.3.1).
- Fixed not working switches start-end in FFT and on/off in UPA (same reason).
- Fixed all issues with FFT scale setting.
- Fixed issues with waveform exporting.
- Fixed SIGSEGV (app crash) at self calibration and after reboot, which was reported only by one person.
- Vertical scale for analog channels now is hidden when LA is enabled. Because otherwise those overlap each other.
- Increased waveform update rate for the time base higher than 50 ns/D - up to 2.2x.
- Multiple optimizations.
- Reduced power usage, especially in the roll mode and scan mode.
- Math low pass filter minimal possible frequency is 50 times lower.
- Math band stop filter minimal frequency is 1000000 lower.
- Changed font size to smaller in table data, because there was no enough space for all UPA data.
- Changed table data backgrounds for better readability. From "silver" (gray) to light gray and from "medium_sea_green" (between gray and white) to white.
- Reverted font in measurements to previous one - B612 wasn't good enough with such small font size.
Edit: because of changes on the Patreon platform, existing users can reach me for the discount code for the upgrade - as for now there is no other option on this platform.
Edit 2: Subscribers are not affected by those changes.
-
Amazing work — I’ll try it right away. One question: do you ever rest? 😂😂 Thanks again.
-
do you ever rest?
Sometimes with the soldering iron :-/O
-
Tried the new version — the .GEL file is incredibly convenient, kudos again! Out of curiosity, I installed it on a Rigol 812, everything works fine.
-
.GEL file main advantage is it works always the same, because everybody has the exact same system on the scope. Unless somebody will spent couple months to create other working system for it...
.GEL required to figure out how to use original upgrade code from Rigol to make it work, without changing the app first.
Installation by using external script is still possible. It gives automated backups saved locally on the host computer, automated change of the timezone in the scope (only if it can be accessed from the host computer - every system is different) and it can be modified if needed.
-
I made an ignorant post on here yesterday. The answer to my question was there in the post, but I didn't pay attention. I removed the post once I realized it was bad. That does not undo the damage, but I want to publicly apologize to Norbert and the forum as a whole.
I've updated my Patreon membership to the highest level. While it's not necessary, I feel that Norbert deserves the extra support for having to deal with users like me.
I'll do better from now on.
-
0.4 Enterprise installed on my DHO802 with no problems.
I love that you've added a keyboard; connecting to WiFi no longer requires a USB hub.
-
I am using the OEM one that came installed, lexar 32gb
Originally used U-Boot somehow can't work on other SD cards than Lexar - that's why I was asking for the brand.
To be honest, I guess Your laziness didn't allow You to answer about UART, which I mentioned earlier.
BTW. After I will release 0.3.2 (or whatever version number it will be) likely I will prepare newer and modified (because of drivers and other things) Android - probably 9.x or 10.x, because of much less bugs, much better performance (faster boot and more wfm/s), possibility to install newer apps and possibility to run it from other SD card brand. But only if there will be enough support for it on my Patreon. Otherwise, I will be working with other oscilloscopes.
Hi Norbert
What are the prospects for a newer Android version?
-
Edit: Returning scope due to a hardware issue.
DHO802 Running 0.4 Enterprise freezing up
I'm seeing the scope freeze up while just sitting powered up, but not being in actual use. This has happened several times, and I re-run the update with no resolution.
Any ideas?
-
Hi, I have the DHO812 model with the mod installed and I haven’t had any issues. It was running for 2–3 hours, I only noticed some small problems with the references but it never froze. Try reinstalling the original software and see if it still happens.
-
I am using the OEM one that came installed, lexar 32gb
Originally used U-Boot somehow can't work on other SD cards than Lexar - that's why I was asking for the brand.
When I copied the factory SD card under Linux using dd and resized the partition under Linux, I didn't encounter any problems.
I don't remember now whether it was Kingmax or Sandisk.
Maybe it was a Sandisk extreme pro, I bought it for a DVR camera back then.
I thought it would be boot faster with a faster card... :-DD
-
Two experimental visors for the DHO:
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/download/DHOvisor/DHOvisor_opencv.exe (https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/download/DHOvisor/DHOvisor_opencv.exe)
https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/download/DHOvisor/DHOvisor_sdl2.exe (https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/releases/download/DHOvisor/DHOvisor_sdl2.exe)
Usage:
.\DHOvisor_opencv.exe --host 192.168.1.105
.\DHOvisor_sdl2.exe --host 192.168.1.105
[attachimg=1]
The SDL2 version may require the SDL2 DLL, but it allows you to resize and move the window while the stream is playing. These visors only play the video stream provided by the Rigol WebControl, which can only serve one client at a time. Therefore, it is not possible to launch more than one client at a time (this includes the web browser client).
Sadly, the stream quality is fixed in the original Rigol Webcontrol APK.
-
I traded my 2-channel DHO802 in for the 4-channel DHO804. The price difference was too little to hobble me with just 2 channels. Norbert's firmware really makes this a spectacular scope.
-
I didn't post on this forum lately, because I wanted to fix some issues with my mod first. Some of them I already fixed, which are published in the prerelease v0.4.2-PR1 (something like a beta release but not in 100%).
Currently most of them are caused either by the user confusion with the modified firmware (too many available options for the user...) or because of the problems on Patreon platform.
I need to find new platform ASAP for the new users and some of the existing ones, which will want to go there.
Issues with the Patreon are huge, like displaying couple times bigger price (at least collected amounts are correct) and replies to my bug reports was like: "update Your browser, if this didn't help, update it again. If still it doesn't work it's Your fault for sure".
Also in one place, when something is free for the subscribers, there is not working button "buy". Later I had to answer questions like "why I need to pay for this second time". Just because of some error done in the code (Patreon, not my mod). Code which I never seen and I don't want to. I can write a book about software bugs on Patreon web pages.
In the past I was working for couple big corporations (one of them everybody knows for sure) as a software developer with web pages. Much bigger and more complicated than Patreon.
In those web pages, either for the end user or used internally (for example reporters uses backend web page to write article about something, weather report and things like that), there was a lot of bugs waiting in the line to fix. But when I was working in the team, we did not only new features or subpages but we also fixed a lot of bugs.
Also we tested everything in multiple web browsers, including older versions. Not like Patreon testing only with one, which I guess is the case.
I have strong feeling that they not fixing any bugs, but they hired the cheapest people with a web page engineering in their resumes, which turned out with ~10 bugs for each added feature.
It's very nice for me to see that many satisfied users of my mod. Some of them are not only supporting with the money (everything has some costs) by also actively, like a making fixes in my script for the issues they experienced, which I implemented with some changes (there is no such thing like a perfect code - no matter who will write it). On the side note, simplified installation via the .GEL file is still available.
Still there are some problems on the human side, like a not reading installation instruction. I tried to do my best to make it short and concisely as possible, with pointing out most important thing, which actually is the least read part - which is the "After installation" part. This contains only six very short sentences - less than one minute to read. But in some cases omitting this caused to lose precious hours for both sides.
I made an ignorant post on here yesterday.
Everybody in this world is making some mistakes from time to time. But not everybody is brave enough to admit it, try to fix it (if it's possible) or to prevent it in the future.
Maybe this is not the perfect place for such conversation, but in the aviation, if You do some unintentional mistake, You have to report it in 48 h, otherwise You can lose Your license. Personally I have only entry cards to restricted areas in the two biggest international airports in Europe :) Anybody heard about famous actor Harrison Ford which almost crashed his private plane on the airliner with people inside and landed on taxiway instead of runway? He didn't lost his licence, not even for 5 minutes.
What are the prospects for a newer Android version?
I had this idea in mind. Little newer Android, like a 9.0 or 10.0 should take out some bugs and make possible to install newer versions of apps. And this also should make it easier to use kernel 5.1.x or newer, which should increase performance a lot (small/big cores in CPU handled more properly by the CPU scheduler in the kernel).
But there are some reasons to not do this. Android by itself is a huge cr*p. It uses (modified) Linux kernel, but this is the end of good things in this system.
Everybody want's to have OS, which is fast, fast to boot, not slowing the apps too much and to have full control over it. Android is not like that - You don't own Your oscilloscope, because Google (creator of Android) owns it. And it uses slow Java for ~95% of things.
Another issue with Android: about one month ago (or something like that) Google announced that they are closing Android source code. This probably is not the biggest issue, but it's not anything good.
In the same time, I already put in a lot of work to develop a working Debian (GNU/Linux) based system to work in this scopes ("Orange Rigol" in my footer), with the 5.10.209 (https://github.com/norbertkiszka/Linux-5.10-Rockchip) kernel with some bug fixes, mipi-dsi driver which I ported (two weeks without any warranty to work it at all).
I don't mean to run any Android app on the GNU/Linux, which is not the greatest idea for some reasons.
Rigol oscillopscope app is almost like a regular Android App. Some part was written in Java (mostly UI) and some part was written in C++.
My idea is to took this compiled C++ part, which requires only one Android lib, make this simple lib from scratch to pass log data into some file or somewhere and wrap it around in another pure C code which will do same things as current Java code. This will make it faster to use it, to maintain, make (more or less) insane and useful features, easier to fix bugs and harder to make a new ones (bug = software engineer mistake).
Some EE probably will not understand what I just said. I mean to rewrite it, but not completely at first. At first will go Java part, which is tied hardly to Android only and is a huge bottleneck both in scope performance and in developing any changes. Later this will allow to rewrite some compiled parts in C++ into pure C, which will help with the things that I just mentioned.
I only noticed some small problems with the references
In the v0.4.1? Anyway, I need to fix it.
I thought it would be boot faster with a faster card... :-DD
Those scopes uses RK3399 as the main CPU (there are three physical processors). It can boot from one of the two MMC (SD card = MMC memory) ports. After initial reset (after powering it up) it executes small internal code (internal ROM), which decides which MMC memory chose to boot from.
This internal bootloader tries to read keys in the another bootloader (named U-Boot) located at the almost beginning of the SD card.
Little later, this U-Boot bootloader does some crazy staff (which is needed since this is not the x86 regular computer) and executes commands from the config file and eventually DT file. It makes initial setup of the SD card, like a frequency, voltages and other magic staff.
At the end of above things, it loads Linux kernel (again... Android uses modified Linux kernel) and couple more things into external DDR3 memory and executes one simple CPU instruction to jump with the code execution into Linux kernel.
Almost at the beginning of booting Linux, it reads DT in which there is a lot of hardware information. Including SD card max frequency and other things.
Later it tries to run first process (process is something like a app) called init. It doesn't care what is this in reality, it just execute this. In this "init", seats Android staff.
In my mod I already modified this DT for the better performance and to have more waveform updates per second. But I didn't even touched SD card related parts in it (beside of enabling unused MMC port for newer scopes - another long story). I think there is a chance to make it go faster.
But (!!!), as they say: "a chain is as weak as its weakest link".
Today we have one huge issue with almost all computers. Most corporate software is done with idea: make this just work and nothing else. You can use the slowest libs software and methods available on the internet. Just make it quick, because people will buy it anyway.
In case of the Rigol firmware (app mostly), if they figured out how to enable compiler optimizations, which is literally one minute of work, this app will be 5-20 (depends in which exact part) times faster. But guess what: they didn't. I think they never figured out this at all. Some people are like: lets learn first better programming language and make some money...
10-20 and more years ago, people was doing something with passion. And this was selling good. Now, You have to buy 10 times more expensive CPU for Your PC, because somebody was not aware of existing such thing as compiler optimizations. I think it's obvious it's going into very bad way.
Speaking of the CPU-s. I just found brand new fan and heatsink for my work laptop, because original one is making noise from the ball bearing and it's not effective as it was before.
12 year old business and very ergonomic laptop. It's highly ergonomic and fast enough. But Im not using Windows "rubbish" and in same time it's 10 times better and more reliable that today new and cheapest ones. BTW it's hard to buy this exact model or parts for it because of high demand.
Back to topic: Orange Rigol (modified Debian) with mentioned 5.10.209 kernel and with much more things executed at boot time, is ready to use after ~30 seconds.
If I will finish my work with rewriting Java part of the app, it should start in about 5 seconds (instead of ~12) and run much faster. After rewriting some parts from the existing .so (C++) lib into C, it will be also faster. So that should give ~35 seconds from pressing power button to using scope as a scope.
with just 2 channels
3 channels to be exact. Last one (used only as a EXT trigger in the stock app) has some missing resistors for AFE, but we have very little data (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg6043623/#msg6043623) if this has to be changed as other channels or not, to work properly - I asked him to do self calibration and to try if this will fix the issue, but he didn't replied yet.
Norbert's firmware really makes this a spectacular scope.
Nah... this is just the beginning of this adventure :scared:
Speaking of the adventure, some people was screaming at me that my price is way too big for simple hack. For such people I wish good luck with 6 months of reverse engineering hardware and software and another 6 moths of making same thing. If somebody will do the same thing twice as fast, I will call such person as a genius.
And how much I earned for this "overpriced" "simple hack"? In the attachment there is the answer for this.
Sadly there is no possibility to change language in the Patreon (...) and they like to show amounts without some fees or sometimes 10 times more that actually is. I added numerical months to the screenshot.
First release was at 15.05.2025. Without time spent on rev. eng. and without all fees and taxes, it's 3028 $ per 5.5 months or 550 $ per month. Which is also the 41% of the minimal wage in Poland or about 21% of minimal wage in Germany.
This post is more or less messy - I just spent whole night fixing one scope remotely - something made one important file to be empty for some reason.
-
Thank you Norbert for all the info, and also thanks for the huge amount of work you’re doing. Unfortunately, I don’t understand a thing about it, but I go crazy seeing people like you with so much passion being able to do things I can only dream of at night. I’m an electrician, far from being a real electronics engineer or programmer (yeah, I program PLCs, but those are programs made especially for us electricians 🤣🤣). Still, I really love the world of electronics and programming, so even if I don’t have the slightest idea of what you’re actually doing, I really appreciate it and thank you for what you do.
As for the calibration of the “third channel,” my answer is no, it doesn’t work. The signal stays perfect in amplitude but is “low” in voltage. I have an 812.
-
Hey Norbert,
thank you very much for your great work! I finally had the chance to install the 0.4.2 PRE version (I’m Julian Decker from Patreon ;) ) and run some first tests. I also did the self-calibration as described in the README.
• First, I simply tested the auto function with the device chassis ground and the probe calibration signal. I got a wrong scale with the auto function (see RigolDS0.png). I tested it again with the original SD card, and that worked fine.
• Then I tested the AFG signal with 5 V, but the device showed around 6 V. I checked the AFG signal with a different oscilloscope, and there the signal was correct at ±5 V.
Do you have an Idea what could cause this deviation ?
Thank you very much,
Julian
-
Do you have an Idea what could cause this deviation ?
I was actually going somewhere and I only did a quick look for Your post. I think You have memory limited to 100 pts. Did You enter license code after installing v0.3 or anything above?
-
Yeah, you’re right – I overlooked that you have to enter it when upgrading from < 0.3. I sent you a message on Patreon. Thank you! Even the .GEL installation worked flawlessly – great job!
Do I need to run the self-calibration again after entering the license code?
-
Yeah, you’re right – I overlooked that you have to enter it when upgrading from < 0.3. I sent you a message on Patreon. Thank you! Even the .GEL installation worked flawlessly – great job!
Do I need to run the self-calibration again after entering the license code?
Running self calibration on only 100 pts is not the best idea.
After entering license code, just check if You can have anything above 100 pts and eventually run self-cal again.
With this prerelease I changed default mem depth to auto, which also should give slightly better results after self calibration.
-
Thank you very much for your assistance, Norbert - the resolution increased with the correct license, and I could perform a self-calibration with the new setup.
Some strange behavior in the vertical system persists.
- With nothing attached, the baseline is below 0.
- Having the channel attached to the chassis ground, there is a significant noise floor.
- Having an AFG rectangle with 5V on channel 1, the amplitude is around +/- 6V; channel 2 - with the same AFG settings, +/- 2.5V.
Calibration was performed after 30 minutes with nothing attached to the Inputs and was stated as successful.
Do you have an Idea what could be wrong ?
Thanks,
Julian
-
Some strange behavior in the vertical system persists.
- With nothing attached, the baseline is below 0.
- Having the channel attached to the chassis ground, there is a significant noise floor.
- Having an AFG rectangle with 5V on channel 1, the amplitude is around +/- 6V; channel 2 - with the same AFG settings, +/- 2.5V.
Calibration was performed after 30 minutes with nothing attached to the Inputs and was stated as successful.
With my understanding, You have problems only with the first channel and three remaining ones are working correctly.
Something is wrong either with the hardware or in the calibration data, which is stored in /rigol/data
I tested same settings, both with the Dave DHO814 calibration data and with my original one.
Only one issue which I encountered with this first one, was a DC offset coming from the AFG.
Did You change anything in the self-cal checkboxes?
If You can, please try to run self-cal with the default check-boxes (as it is after app start) and with the 50 ohm terminator attached to the first channel.
Also, You can use possibility to downgrade via .GEL file, including the stock firmware - to check if this problem remains.
-
Thank you very much for your assistance, Norbert - the resolution increased with the correct license, and I could perform a self-calibration with the new setup.
Some strange behavior in the vertical system persists.
- With nothing attached, the baseline is below 0.
- Having the channel attached to the chassis ground, there is a significant noise floor.
- Having an AFG rectangle with 5V on channel 1, the amplitude is around +/- 6V; channel 2 - with the same AFG settings, +/- 2.5V.
Calibration was performed after 30 minutes with nothing attached to the Inputs and was stated as successful.
Do you have an Idea what could be wrong ?
Thanks,
Julian
I had the same problem with the offset on channel 1 in version 0.4.2PR1. I had it in version 0.3.1 as well, but on channel 3. It disappeared after several self-calibrations. I calibrate with a 50 ohm resistor and PE connected. Thank you again, dear Norbert, for the incredible work you do.
-
I had the same problem with the offset on channel 1 in version 0.4.2PR1. I had it in version 0.3.1 as well, but on channel 3. It disappeared after several self-calibrations.
That's why I like when people do bug reports as early as possible. This often makes debugging and fixing much easier. Also it prevents others from encountering same issue.
One of my planned things to do after mentioned earlier half-rewriting is to make self calibration from scratch. It will allow more control like faster or more precise. With precise I mean up to several uV (with 100 uV/D) instead of like 50 uV offset.
-
Hey Norbert, just wondering — do you prefer us to report bugs here or on the Patreon channel?
I’ve also had a few issues that I mentioned to you in private messages on Patreon.
-
Hey Norbert,
yes, it is only the first channel - 2-4 are working great! So the AFG seems to be fine.
By switching the SD card to the original one with the stock firmware, channel 1 is also working - so probably not a hardware but a problem with the Mod software /firmware (see image attached).
The calibration on the mod version was done with default settings and after around 30 min. Any other options I could try for the calibration ?
Best and many thanks,
Julian
-
Hey Norbert, just wondering — do you prefer us to report bugs here or on the Patreon channel?
I’ve also had a few issues that I mentioned to you in private messages on Patreon.
Hi. Actually I started writing reply to You on there. One of this three issues (AX+B math function) I already fixed, which will be in the next prerelease or release.
About the bug reports, at this moment it doesn't matter. But making this in public, I think is better, because others can see it, test it if they have same issue or not. Or make a point if this also happens in the stock firmware - which changes a lot in the debugging.
This also saves some time for both sides - writing and answering for the bug report with the exact same issue(s) takes time.
Also PM chat on the Patreon platform has some bugs, which is pretty expected there...
Speaking about the Patreon and increadible amount of problems with it, I was thinking about switching it to another similar platform, but now I have better idea. Which is to make my own platform. For many years I was working as a website programmer and sometimes as a graphic web designer - usually companies has their own separate people for this, but they make their work slower than a sloth.
Reporting bugs encountered on the Patreon website is pointless as I said earlier. Making my own page will make possible to make fixes faster than writing bug reports. Also It will help to avoid Patreon fees :) I already have one small private server in the datacenter, which has more than enough unused computation power.
I already sent a question to the datacenter owners about data transfer limits, because right now I don't even know if there is any. Hitting this limit will decrease connection speed from 100 mbit/s (that was promised many years ago, maybe today it's more) to something very slow. With the 89 users as it is right now, it can be a problem.
This will also allow to connect one of the best issue tracker, which is Redmine (https://en.wikipedia.org/wiki/Redmine) and connect users to it. I installed this on a two servers and I used this when I was working with web pages. This is extremely easy to use and quick to find whatever You need in it. Only one problem with it - it uses programming language that Im currently not familiar with - eventually I can just use its SQL database and put there all users data without the need to learn RoR. Every added issue in Redmine is similar to a topic on the forum, in which others can comment.
Patreon has its own API - if this somehow works more or less properly, I will be able to transfer users data. Likely without passwords, but I can generate random new ones and send it via emails for each user.
BTW. I will be able to do some email notification settings in it, because some users may want less notifications, collective notifications or nothing at all. Of course every feature requires time to implement and to test it.
yes, it is only the first channel - 2-4 are working great! So the AFG seems to be fine.
By switching the SD card to the original one with the stock firmware, channel 1 is also working - so probably not a hardware but a problem with the Mod software /firmware (see image attached).
The calibration on the mod version was done with default settings and after around 30 min. Any other options I could try for the calibration ?
As I said, You can try to run self-cal with 50 ohm terminator on this problematic channel.
Also, If You have separate SD card with the stock app which doesn't have this issue, You can extract /rigol/data from it and put it into SD card with my mod, to check if this was caused by calibration data or not.
You can make a local backup of this dir, like in this example:
adb shell
# cd /rigol
# cp -R data data_backup_of_something
After making such backup, You can overwrite or replace this directory with the adb push.
Eventually You can also sent me the contents of this dir, so I can use this with fixing or later when I will start to rewrite whole self calibration.
I have feeling that was caused by lowered time delays in a sel-cal loops - most users didn't have any issues with it, beside of two - or more if somebody didn't reported it.
Edit: optimizations in the self cal was introduced in v0.3, not in v0.3.1.
-
When I tried to to reply on PM, Patreon webpage displayed an error as sometimes it does. I reported this about two months ago and they didn't even answer.
The calibration completes, but it shows an ADC gain offset error.
Most important question: did You had text "success" or "error" at the top?
Did You try to run self-cal again and this remained or not?
Did You saved Android system log (logcat) after this issue? Logs are extremely useful to debug problems.
When you use the reference traces and then remove them, sometimes the labels on the left (e.g., R1) remain visible.
This in the list of the know bugs on the Patreon post with the v0.4.2 Prerelease.
I will try to fix this soon. Right now I need to clean up mess in my lab and to fix issues with my laptop - I attached photo of my brand new heatsink for my 12 years old laptop.
I also wanted to ask if it would be possible to start up with the probe already set to 10x by default.
User interface is the worst place to make any changes, because 99% of it was written in Java - this is the one of many reasons why I want to rewrite it. Currently hardcoding it should be much easier.
Anyway I need to make it carefully, because Rigol used more than a single variable for this. If I will not change every one, it can cause problems with the rendering or with the trigger.
I don't know if everybody will want this hardcoded - but I can do a separate version with this one change.
-
Thanks Norbert, yes — at the end of the calibration it said “failed” but still showed 100% completed.
When I opened the lower menu, everything looked fine except for one error in ADC gain.
Now, just out of curiosity, I tried running the calibration again and it stops almost immediately — I think it’s again due to ADC gain & offset.
-
I hate bugs that I can't reproduce. It makes way harder to fix them. Often it's very close to impossible,
Anyway, can You downgrade to the v0.4.1 and check if this problem remains?
-
PS. waveform looks very noisy in Your screenshot.
BTW. You can use a web browser (IP of the scope as a address) to make screenshots - it's way easier.
-
Hey Norbert, quick update:
After I retried, the scope got very noisy and the calibration failed.
My usual workaround is: exclude ADC gain, run the calibration, then run ADC gain alone — and that normally works.
I saw the same behavior on the previous version; on v3.1 it did not happen.
One question: on a DHO812, does it even make sense to calibrate Channel 3 (the “added” one)? I see the EXT input showing up as Channel 4.
-
On my scope with v0.4.1 I get on 4 channels the same values with GI on 25Mhz and 50Mhz.
I'm surprised that the trace is very clean and crisp with the GI on 50Mhz, with respect to performance of the GI.
-
One question: on a DHO812, does it even make sense to calibrate Channel 3 (the “added” one)? I see the EXT input showing up as Channel 4.
|O Now I see the reason of the problem... I forget that You have 2 channel scope, so You don't have AFE for the CH3. My mod has almost completely wiped out Rigol license system and number of channels is hardcoded (this was a part of this system).
I even changed calls to the function which was returning number of channels to things like mov x0, #0x4 for the better performance (few ns for each call, which can happen many times per second).
So the app tries to make a self-cal by using unexisting chip :-BROKE
Definitely You should unselect CH3.
EXT option available is actually a bug that I left by purpose, because it is a rare case when bug becomes as a feature for a reason.
Eventually You can change CH4 into EXT.
Just in case, You can make a backup of the /rigol/data - in the same way as I wrote earlier.
On my scope with v0.4.1 I get on 4 channels the same values with GI on 25Mhz and 50Mhz.
I'm surprised that the trace is very clean and crisp with the GI on 50Mhz, with respect to performance of the GI.
I didn't changed any code for the rendering waveform, because of my lack of knowledge about OpenGL, which is mostly used for 3D rendering - for example in a computer games.
But If You have low mem depth and You will change acquisition to 'fast', timings in the app will be changed and the waveform rendering usually hides less noise.
Speaking of the AFG, when I overclocked (on my scope for the test) PLL from 1.25 GHz to 2 GHz, AFG was working without any issues with the 1.6 times faster sample rate.
To change sample rate I need also change computation of the output frequency. In such case max output frequency can go up to at least 80 MHz.
Of course there is a LC filter at the output and other bandwidth limiting factors like a opamps and other things. But with the limited amplitude, we can have it.
I already know where is a value in the app that sets AFG sample rate. I didn't touched this (beside of the experiments with PLL to downclock AFG back to original), because I didn't want to make a incorrect output frequency.
-
I’m now running the calibration with the default boxes checked, except for the two channels that don’t exist, and everything seems to proceed correctly.
However, now the auto signal acquisition doesn’t work anymore on Channel 1 — it keeps saying “no signal detected”, while Channel 2 works perfectly fine.
-
Some time ago I also had issues with the auto - either no signal detected or enabled more channels. First thing that came to my mind was to check if the same exact thing happens in the stock app and it was the same.
So I desperately need to rewrite as much and as fast as possible. Sometimes fixing code that was written without any thinking before is pointless. Without the source code it's also difficult.
-
Is there any way to restore or re-initialize Channel 1?
After the calibration it stopped detecting signals (it always says “no signal detected”), while Channel 2 is fine. Maybe the calibration corrupted some offset or gain values?
-
Is there any way to restore or re-initialize Channel 1?
After the calibration it stopped detecting signals (it always says “no signal detected”), while Channel 2 is fine. Maybe the calibration corrupted some offset or gain values?
I doubt this. Try to set CH1 manually and check if it works correctly. Also You can check if restoring settings to default (physical button or start menu) will change behavior of the auto.
-
Problem solved — I reinstalled the previous mod (v4.1).
Before that, I did a few tests and noticed that the only way to make the scope detect the signal with the AUTO button was by setting the probe to 1×, but in that case the signal had a large offset.
However, it’s strange — before I touched the auto-calibration to run some tests, everything was fine.
Now I’ve tried reinstalling the latest mod again, but it still doesn’t detect any signal on CH1.
-
Hello, is it reasonable to buy and hack the DHO804 70MHZ 4 CHANNEL 12 BIT oscilloscope in 2025 or should I wait and buy it until Rigol releases a 14 bit oscilloscope? Rigol DH0804 was an economical solution since it was hacked and went up to 250 MHz. If they release a new model, can this be hacked?
-
Hey Norbert,
i copied the stock calibration files (which are working as shown in the previous image) and did an overwrite of the mod calibration files. The wrong Amplitude in Channel 1 persists. So it seems not to be a Hardware (cause in stock firmware the Channel is working correctly) neither a Calibration (cause even the working calibration files from the stock didn't solve the problem on the mod firmware) problem - or maybe a Calibration interpretation problem in the mod firmware ? I see there is a default folder in the mode version which not exists in the stock firmware?
Attached are the stock and the mod calibration files.
What would you recommend for further debug investigation ?
Best,
Julian
-
I will revert couple changes and I will publish this as a next prerelease (PR-2).
I hope this will fix issues with the offset after self-cal and with the Auto.
Not all compiled code is clear (because all information from source code is lost), but in auto settings (auto buttons and from start menu), there is a moment when time base is temporary changed to 5 us/D. Even before v0.4.2-PR-1 I was thinking about increasing this to something like 5 ms/D or even more. Theoretically that should change Auto to be able to detect signal more precisely.
But this change (m.a. time base) also may cause it to see internal noise as a signal. Beside of little more time needed to finish everything. I will test it on my scope later.
Attached are the stock and the mod calibration files.
Thank You for those files. I tried those from mod-calibration.zip on my scope and as in the attachment, I see even bigger offset. Looks like You have huge hardware DC offset on CH1.
I think I was right with this timings - I guess increasing it back to original value should fix it for 99.9%. In v0.4.2-PR-1 I changed mem depth in default settings, which are used at a self-cal. Acquisition with bigger memory depth takes more time and it can make app to take measurement data little too early.
-
At last I have some free time (not much unfortunately) to make a revision of the oscilloscope software, I think that for the moment the GUI remains as it is and now I want to try some modifications to the binary library. I have read that you use some decompilation tools like IDA in Ghidra, I would like to know if it is enough to download them and use them as they are or it is also necessary to look for additional plugins to support the ARM libraries.
Regards.
-
decompilation
There is no single decompiler that You can use to change anything and compile it back. Only working tools to compile the code are: Your own brain, browser to read a ton of CPU instructions documentation and a incredible amount of coffee.
At least 99% of generated code is a pseudocode being unable to compile it back. And this is not yet the best part. Once Ghidra "decompiled" Assembly code which I wrote and it showed completely different logic than it is in reality. On top of that, it's very slow and it has a lot of bugs.
What can be done in C (or C++ which sadly is the case here) in 5 minutes, You can do the same in Assembly in between 5 hours and 5 days. You can't add or remove the instructions like in Smali. Only change them into different one - slowly one after another.
If You are not familiar how the CPU works and how the functions works from the high level language (like C), be my guest: In C You can wrote function call in a matter of seconds. In Assembly, You need to set up CPU registers (usually up to eight) before a each function call - with that You have to make sure that You didn't overwrite some important register - otherwise You can have a very bad day figuring it out what went wrong and why. I think worse than that are the operations on the stack - one mistake and You have SIGSEGV generated completely somewhere else (good luck to find one simple mistake after some hours).
not much unfortunately
There are a lot of structs, which has a information memory location (only). You have to figure out by Yourself what it does for most of it, because almost all of information from the source code is lost.
Reverse engineering of communication with the hardware, often is almost impossible without using modified Linux kernel - to listen one byte, one after another and to get proper timings and to replace it with Your own data to figure out what You can do and what not so much. Unless You don't want to hack AFE, PLL or the front board (knobs, buttons, leds and power management).
Summary: this is not as simple as the regular scope user thinks (yeah, programmers makes a magic in seconds). One day is not enough to make anything useful in the beginning. Thousands of functions - even with the source code (which nobody has, except Rigol or their outsourced company), it's not easy to read this. At least 30% of the code is a dead code, which usually is not helpful.
Im slowly starting to work with rewriting the app, which will have API to communicate with the open source GUI (HTML, CSS, JS and PHP). And this will have possibility to make Your own GUI from scratch in a quite short time.
HTML+CSS is easy to understand for a monkey, as long as the monkey knows English - Because those two languages are almost just pure English. I think this is the easiest and most comfortable way to make or modify existing GUI (or to make a skin change with the help of OS).
Edit: example of GUI made with HTML+CSS+JS is Steam - most people using computer for a games should be familiar with it.
-
decompilation
There is no single decompiler that You can use to change anything
Thank you, I don't know to much about decompilation, Android or libraries for Android, well I don't know too much about anything but my superpower is persistence and obstinacy, so lets go and see what can be done. My intention is not to change too much only enable things which are already there.
-
only enable things which are already there.
Even with this, You have to do this in Assembly.
-
Actually those tables are a waste of time. This is like picking a lock for a 100 hours of work instead of using angle grinder.
-
Still a waste of time to do hacking like this. All of this was hacked years ago by Zelea or whatever his name is.
-
Still a waste of time to do hacking like this. All of this was hacked years ago by Zelea or whatever his name is.
If it's a learning experience for them, then it's not a waste of time.
-
It's time to use something smarter than me in the coding area. I have a simple Copilot AI on my Windows PC — what if I asked it to produce more readable code? Hmm, there's a size limit on the code I can paste into the Copilot chat area.
Take a look at the code that was rewritten by Copilot AI with a little help from me:
Some will give you a hard time about this, but using any available tools to make the job easier is a smart move.
-
I did all of my modifications without using AI - not even once. And I didn't have to read or understand those Rigol license functions.
As I said previously, this is like a picking a lock in a already opened doors.
-
I did all of my modifications without using AI - not even once. And I didn't have to read or understand those Rigol license functions.
As I said previously, this is like a picking a lock in a already opened doors.
That is understood, but mrisco is still learning, and the best way to hone your skills is to learn new things. It appears that mrisco is approaching this like the Siglent hacks, where you enable features in the licensing system. I believe that is a valid method. Different does not mean worse or better; it means different.
-
I did all of my modifications without using AI - not even once
With the years I learned to use any tool available if that simplify routinary work. Of course anyone also could do this by hand without use computers, keyboards, displays but that is not the idea.
I learned that you are smart if use the tools in the smarter way.
-
And You use IDA?
-
If you are wonder why I don't patch the API_CheckLicense function to always return true, I test it and found undesirable side effects.
That's exactly why I prefer to use my own brain instead of AI. It's better to improve Your own brain instead by terms of intelligence and knowledge than somebody else tool - especially if it comes from a greedy company.
To be honest, I don't know much about ARM opcodes and assembly, so I used this page to find them
If You never learned CPUs internals and the assembly of any CPU architecture, it's a very long way ahead of You.
Thanks to Google search, I understand that the second function is called from an object inherited from the first one, so the patch should be applied to both functions.
Looks like You are not familiar with the low level stuff.
It would be a good idea to create a Python script to automate my patching tasks.
I think this is not useful to anything. You are going to patch exact same file multiple times?
IDA is the tool
There is a reason why everybody showing their work in public is using Ghidra instead. IDA has extremely expensive license and You used free version for a commercial use in public.
Of course Rigol firmware comes without license, so we can do whatever we want with it.
Anyway, still Your methods for me are a waste of time instead of doing it properly.
-
New patch! It enables 200 uV/div in the 800 series, as in the 900 series. This means that we now have two working patches that can be used with my patching Python tool and applied in cascade.
I did 100 uV/div and without forced BW filter. Try to do the same.
-
I did 100 uV/div and without forced BW filter. Try to do the same.
I will not do anything that could potentially damage the calibration or robustness of the instrument.
-
I did 100 uV/div and without forced BW filter. Try to do the same.
I will not do anything that could potentially damage the calibration or robustness of the instrument.
And Why You think like that? There is no correlation between UI limits of values and calibration or robustness.
-
Come on, this isn't a competition. There is no reason to knock someone else's work. Just because they approach it differently than others does not negate their contributions. EEVblog is a place to learn and share. There's room for everyone's ideas/methods here.
-
this isn't a competition
With his methods he is no competition for me. My changes are focused in ergonomy and functionality instead of candy buttons and breaking offsets in the analog waveform at the roll mode or LA in any mode.
There is no reason to knock someone else's work.
Im not knocking anything. Result of his work is the same as patching vendor.bin by a widely available and open source tool called rigol_vendor_bin.
To do same changes that I did, he can't do this without learning Assembly, which also requires knowledge about CPU internal things and some knowledge about how compilers are generating machine code. Also he is doing this in a very ineffective way.
In the same time he is risking legal problems from a company named Hex-Rays SA.
Just because they approach it differently than others does not negate their contributions. EEVblog is a place to learn and share. There's room for everyone's ideas/methods here.
What if somebody approach is both ineffective (which I pointed out - but Im the bad guy here) and illegal?
Using AI to make code that You can't review (because of no knowledge about Assembly) is a very bad idea. Likely this is the reason why he wrote one post about one change with a bad results.
-
I'm convinced that the most knowledgeable person is norbert.kiszka. There's no one more knowledgeable than him.
-
this isn't a competition
With his methods he is no competition for me. My changes are focused in ergonomy and functionality instead of candy buttons and breaking offsets in the analog waveform at the roll mode or LA in any mode.
There is no reason to knock someone else's work.
Im not knocking anything. Result of his work is the same as patching vendor.bin by a widely available and open source tool called rigol_vendor_bin.
To do same changes that I did, he can't do this without learning Assembly, which also requires knowledge about CPU internal things and some knowledge about how compilers are generating machine code. Also he is doing this in a very ineffective way.
In the same time he is risking legal problems from a company named Hex-Rays SA.
Just because they approach it differently than others does not negate their contributions. EEVblog is a place to learn and share. There's room for everyone's ideas/methods here.
What if somebody approach is both ineffective (which I pointed out - but Im the bad guy here) and illegal?
Using AI to make code that You can't review (because of no knowledge about Assembly) is a very bad idea. Likely this is the reason why he wrote one post about one change with a bad results.
Nobody is the bad guy here. I'm just saying that we should recognize that he is learning something new and is excited to share it. Whether he is putting himself in legal jeopardy or not is none of our business. Everyone who is hacking the Rigol firmware/software is breaking the law.
-
UPA Working in a 804 device:
[attachimg=1]
[attachimg=2]
-
I'm convinced that the most knowledgeable person is norbert.kiszka. There's no one more knowledgeable than him.
I think You are wrong with this. There are a lot of people much wiser than me. But most of them are not interested in hacking 300$ scopes.
Everyone who is hacking the Rigol firmware/software is breaking the law.
In which country? In Poland deassembling and decompiling are allowed by law - so even if there will be any fragment in the licence disallowing this, it doesn't have any legal effect.
Selling modified software can be disallowed by license, which is not the case with the software from Rigol. Because there is no licence.
Actually Rigol is the one who breaks the law, because they used a lot of code on GPL licence (which they admitted - even in a document available from the stock app in the scope), which requires to give source code for anybody who asks for it - which they didn't. I asked two years ago couple times and I received only confirmation of received email without any code.
Personally I use only open source software to do my modifications, instead of using illegal copies of IDA, AI or using scripts, when those are not needed.
-
Hey Norbert,
bypassing the last discussion — today I managed to downgrade the device to NK Mod 0.4.1 and performed another calibration. Now even Channel 1 is working correctly without any offset or amplitude error, so as you said, it seems to have been an issue with the calibration interpretation in version 0.4.2 PR1.
Thanks a lot for all your work and for always striving to deliver substantial, fundamental and stable improvements.
-
I'm convinced that the most knowledgeable person is norbert.kiszka. There's no one more knowledgeable than him.
That's a silly statement. Knowledge in one area does not imply knowledge in all areas. We are getting back into the competition thing again. Norbert does things his way, mrisco does things his way, I do things my way, you do things your way. Neither of us is superior to the other. I have patents related to algorithms used in extremely high-level encryption. I doubt that Norbert has that knowledge, but Norbert has knowledge in programming that I do not. I'm no better than him; I'm different, and the same goes for everyone.
Willingly sharing your knowledge is a distinguishing mark of an intelligent person, and virtually everyone on EEVblog fits that description.
-
I'm convinced that the most knowledgeable person is norbert.kiszka. There's no one more knowledgeable than him.
I think You are wrong with this. There are a lot of people much wiser than me. But most of them are not interested in hacking 300$ scopes.
Everyone who is hacking the Rigol firmware/software is breaking the law.
In which country? In Poland deassembling and decompiling are allowed by law - so even if there will be any fragment in the licence disallowing this, it doesn't have any legal effect.
Selling modified software can be disallowed by license, which is not the case with the software from Rigol. Because there is no licence.
Actually Rigol is the one who breaks the law, because they used a lot of code on GPL licence (which they admitted - even in a document available from the stock app in the scope), which requires to give source code for anybody who asks for it - which they didn't. I asked two years ago couple times and I received only confirmation of received email without any code.
Personally I use only open source software to do my modifications, instead of using illegal copies of IDA, AI or using scripts, when those are not needed.
GPL is not a legal license in the sense that one could be sued for not following it. What people don't get when they don't follow the GPL is scorn from the developer community, but nothing can be done to force them to abide by the terms of the GPL.
If I were wrong about the legality of disassembling and decompiling the software, then I stand corrected. Unfortunately, I live in the USA. I am of Polish descent, but not enough to get citizenship.
I support you at the highest level because I believe that what you are providing serves a good purpose for my usage scenario, and I do not expect anything for free. I applaud mrisco's work and his exuberant sharing of it. I'm not currently supporting mrisco financially because his product doesn't meet my current needs. However, I may still support him to encourage him to continue his work.
-
I used IDA 3.85 under MS-DOS when I was young. I'd also like to examine Rigol's protection using binary files. Where can I download the binary files you're working on?
-
I used IDA 3.85 under MS-DOS when I was young. I'd also like to examine Rigol's protection using binary files. Where can I download the binary files you're working on?
They are inside the APK. You need to decompile it using APKtool, and the libscope-auklet.so library is inside the lib folder.
where is the APK?
-
What if somebody approach is both ineffective (which I pointed out - but Im the bad guy here) and illegal?
I measure efficiency as "work done / time", obviously I know about CPUs, FPGAs, programming, etc. but I don't like to go around saying how much I know or where I worked, what awards I earned, etc. I don't need that. I let my work speak for me.
Don't be afraid to use the new tools — you just need to learn how to use them correctly.
-
Hey Norbert,
bypassing the last discussion — today I managed to downgrade the device to NK Mod 0.4.1 and performed another calibration. Now even Channel 1 is working correctly without any offset or amplitude error, so as you said, it seems to have been an issue with the calibration interpretation in version 0.4.2 PR1.
Thanks a lot for all your work and for always striving to deliver substantial, fundamental and stable improvements.
That's why I did a prerelease (beta in simplified words) as a another Patreon post with a warning about it not being fully tested. However I didn't expected that big problem with the self calibration.
Only one change in v0.4.2-PR1 that is affecting self-cal is the default memory depth changed to auto.
I did this change because of the some beginners in electronics, which they didn't set memory depth accordingly to their measurements. And some of them was making rude comments and accusations that is a fault in my mod, while is not. I have bad accusations quite often - mostly when somebody brand new scope has a hardware fault, which can be easily tested by downgrading to the stock app with a .GEL file.
Since auto depth in my mod gives up to 125 Mpts (10 ms/div) instead of 1 kpts as in the stock app, I think this is a good change for the beginners. Theoretically this also should give better results for the self-cal, beside of the problem which was encountered by two people (or more if somebody didn't reported it).
Lately I was testing self-cal on my scope with some reverted changes. Self-cal is taking quite long time, so it doesn't make it easy.
I need to do a more tests with it. I think to either fix this by increasing time delays (when the self-cal thread is waiting for the data) or either by forcing it to use different memory depth than default (same default as it's set by the 'default' button).
On the side note, current latest release is v0.4.1. As it's noted on the Patreon, v0.4.2-PR1 is the prerelease - which is available only for the subscribers.
GPL is not a legal license in the sense that one could be sued for not following it.
Computer code is a intellectual property. No matter if it's good or bad code. License is a resolution of will. How the price (like $0.00) does the change in the law?
If I were wrong about the legality of disassembling and decompiling the software, then I stand corrected. Unfortunately, I live in the USA. I am of Polish descent, but not enough to get citizenship.
Im not familiar with the law in USA too much. But this is legal in Poland.
where is the APK?
Packed in the .GEL file and in the Android file system.
obviously I know about CPUs, FPGAs, programming, etc.
Low level programming is different than high level programming in object oriented languages. You said about making changes in the inherited function - that's why I know You are not familiar with the C and C++ compilers or the lowest level things done in a bare metal (CPU).
Don't be afraid to use the new tools — you just need to learn how to use them correctly.
This is what I was trying to point out.
First of all, You were using illegal copy of IDA and sharing this information in public. There was some people who did some bigger crimes (robbing a bank or killing somebody) and they were caught because they talked too much - even only with the closest family.
Second, as I told You, making those changes with the script is inefficient, but You didn't want to listen. And Im the bad guy, because I was pointing this and other things.
-
...making those changes with the script is inefficient...
Not from my point of view, that script allows me to share the patches, easy test and changes, and document them all at the same time and in only one file.
Where do you share your patches to see more efficient ways of doing things?
You didn't said anything about sharing this before.
BTW. Python scripts are not portable as a Posix shell script. That's how I did my installation script (and later also .GEL file).
-
Coming back to auto settings in my prerelease. I will try to increase mentioned temporary time base in the next prerelease. If this will not fix the issue with the not detected signal, I will try to move change with the auto depth to the end of the procedure instead of the almost beginning (right after saved setting - which are used when taped on the back arrow).
-
There are 51 cross-references to the "API_CheckLicense(OptType)" function.
You patch each place that calls this function. Instead, if you change two places in this function, API_CheckLicense function will always return 1 and will return licensed in all places it is called.
addr 0x001975C0: MOV W0, W19 -> MOV W0, #1 ( E0 03 13 2A -> 20 00 80 52 )
addr 0x001975F4: MOV X0, X19 -> MOV X0, #1 ( E0 03 13 AA -> 20 00 80 D2 )
Address Length Original bytes Patched bytes
00000000001975C0 0x4 E0 03 13 2A 20 00 80 52
00000000001975F4 0x4 E0 03 13 AA 20 00 80 D2
-
I'm convinced that the most knowledgeable person is norbert.kiszka. There's no one more knowledgeable than him.
I think You are wrong with this. There are a lot of people much wiser than me. But most of them are not interested in hacking 300$ scopes.
Everyone who is hacking the Rigol firmware/software is breaking the law.
In which country? In Poland deassembling and decompiling are allowed by law - so even if there will be any fragment in the licence disallowing this, it doesn't have any legal effect.
Selling modified software can be disallowed by license, which is not the case with the software from Rigol. Because there is no licence.
Actually Rigol is the one who breaks the law, because they used a lot of code on GPL licence (which they admitted - even in a document available from the stock app in the scope), which requires to give source code for anybody who asks for it - which they didn't. I asked two years ago couple times and I received only confirmation of received email without any code.
Personally I use only open source software to do my modifications, instead of using illegal copies of IDA, AI or using scripts, when those are not needed.
GPL is not a legal license in the sense that one could be sued for not following it. What people don't get when they don't follow the GPL is scorn from the developer community, but nothing can be done to force them to abide by the terms of the GPL.
If I were wrong about the legality of disassembling and decompiling the software, then I stand corrected. Unfortunately, I live in the USA. I am of Polish descent, but not enough to get citizenship.
I support you at the highest level because I believe that what you are providing serves a good purpose for my usage scenario, and I do not expect anything for free. I applaud mrisco's work and his exuberant sharing of it. I'm not currently supporting mrisco financially because his product doesn't meet my current needs. However, I may still support him to encourage him to continue his work.
:) Humorously in kindergarten, some teachers would say "Sharing is caring". It's nice to see many people are sharing how they made it, not just showing off. "mrisco" not only shared his process but also shares the methodology of doing it which is very valuable.
Based on mrisco's work, people can re-do the unlocking process and create their own firmware locally (relatively safely) and continue modifying the app as they want because the methodology is public (opensource). But based on norbert.kiszka's work, it's NOT easy and intuitive to create your own firmware locally. It feels like a close-source APK app. But based on the demo videos, norbert's personal firmware made nice achievements even though the original firmware had already been published more than 2 years. Until now, no one joined the public modification of the firmware somewhere such as GitHub or so. Or because it's not ready to be open-source or he doesn't want.
As we know the original source code for the App was not published. The reverse engineering takes time. norbert.kiszka said he might can do a new app. I think this confidence is from his findings of the API libs he found from the firmware. But it would take a lot of time for 1 person. If more people can participate, the process could be faster. Some people can do the API reverse engineering and publish API libs for Linux or Android, some can do the UI modification, some can do the testing and someone can even make a small pull-request for a small modification. The hardware is not too slow. It's just the firmware is just too buggy and inefficient. The extra hardware resources SHOULD BE used for user-defined scientific calculations.
And yet I hope the Corp. can publish more documents which can help not only itself for better reputation and sales but also buyers. Otherwise there are so many alternatives. Once people lose interests, people won't buy.
There are many smart people in the world in different countries from different aspects.
It nice to see more people are contributing the the work in different ways selflessly and share the findings so that others can continue in the future. :-+
-
There are 51 cross-references to the "API_CheckLicense(OptType)" function.
You patch each place that calls this function. Instead, if you change two places in this function, API_CheckLicense function will always return 1 and will return licensed in all places it is called.
Check https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg6063471/#msg6063471 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg6063471/#msg6063471)
Maybe make it return true only for valid cases, not always
-
It's ready! Time to run some tests and prepare for the release.
(Attachment Link)
This looks similar to mine oldest release v0.0.1 (https://odysee.com/@norbert.kiszka:6/dho924s_extended_v0.0.1:0), beside of the added triggers from the DHO4000, linear interpolation and no UPA at that time.
:) Humorously in kindergarten, some teachers would say "Sharing is caring". It's nice to see many people are sharing how they made it, not just showing off. "mrisco" not only shared his process but also shares the methodology of doing it which is very valuable.
This is one of many reasons why opensource is usually the best choice. Even with the bad code, somebody can modify it and publish it further. Like a DSRemote which I ported for the DHO800/900 and somebody on this forum modified it to make it work better. However I didn't tested his modification yet.
Until now, no one joined the public modification of the firmware somewhere such as GitHub or so
I have published some work on my GitHub and I have plans to do more.
With my plans to rewrite, it primarily will work on a Orange Rigol system, which is fully open source (modified Debian which uses original Debian repositories) and it's better than Android (which probably will be supported much later). I need to port more drivers for the Rigol things, because now we have about the half of it - AFE, FPGA, touchscreen and right now I don't even remember what else I did.
Nobody will have to be familiar with the Linux, because it's intuitive GUI called Mate. There a lot of myth around Linux being hard etc. How hard is to flash SD card with a image from a single file? Turn it on and You have similar GUI scope app in front of Your eyes. Fighting with those myths is very hard (https://en.wikipedia.org/wiki/Confirmation_bias).
As we know the original source code for the App was not published. The reverse engineering takes time. norbert.kiszka said he might can do a new app. I think this confidence is from his findings of the API libs he found from the firmware. But it would take a lot of time for 1 person. If more people can participate, the process could be faster. Some people can do the API reverse engineering and publish API libs for Linux or Android, some can do the UI modification, some can do the testing and someone can even make a small pull-request for a small modification. The hardware is not too slow. It's just the firmware is just too buggy and inefficient. The extra hardware resources SHOULD BE used for user-defined scientific calculations.
Making everything from scratch is insanely time consuming. That's why my plan is to take .so lib and link it with the code written in C. Mostly I will have to rewrite Java part, which is UI mostly.
As I said couple times, I want to make a open source UI based on HTML+CSS+JS eventually plus any scripting language like a PHP or Python (I have many years of experience with PHP and making PHP code to have good performance). Even some settings management.
Waveform will be working as a video stream (just like Odysee or YouTube), so this will be efficient.
There is a one open source browser engine with a good enough license, which I can use to make it visible and usable like a regular app instead of web browser.
I don't have any plans to rewrite FPGA firmware (there are some problems with the stock one), because my knowledge around FGPAs is weak. Maybe I will come back with my tries to do some small hacks (in FPGA), but likely nothing more with it. Eventually somebody else with my help, because of my knowledge about the communication between the app and the FPGA.
Anyway, when I published months of my work as a open source, a lot of people was using it, but literally nobody supported it to make it going further. I went aboard for a quite long time and later I decided to do what Im doing right now.
(Fully) open source is much better, but most people can't do things for free for 60+ hours per week. A lot of code on GitHub (including my own s***t) is done after hours. Beside of a big open source projects (Linux, Debian, BSD, KDE, Mate and much much more) supported by a big corporations, which they have huge interest in it.
Coming back to my rewriting, I think to start it after releasing v0.4.2. In the meantime likely I will do about 1-3 more releases of this and I will switch completely to a new app, when it will be good enough for the normal usage.
I almost forgot to mention of possibility to do a switch 1.25 -> 2 GSa/s for the price of limited memory depth. I did it already in my mod as a hardcoded change, but to make it usable without source code is not easy. After mentioned partially rewriting, this will be much much easier to do.
If more people can participate, the process could be faster.
With the documentation for the API for the open source UI, that will be more than possible.
I think this confidence is from his findings of the API libs he found from the firmware.
A lot is going on at the app init, but at the beginning it will stay in the modified .so lib, so I will save a lot of time.
Later I can rewrite this too, to make it boot faster for a couple seconds. Five second per day can save 30 minutes per year.
API libs for Linux or Android
With the web based UI, there will be no need to do much. HTML, CSS and JS are parsed by a browser. Maybe somebody will like to do a "browser" by using existing code (browser engine), to make it work fast and on fullscreen (without typical web browser controls).
The hardware is not too slow. It's just the firmware is just too buggy and inefficient.
I would say it's way worse. With my changes on a Assembly level (done manually), some app parts are about 5 times faster. Those things can be even much faster after rewrite.
5 times faster, is not because Im good or something like that. It's because Rigol did everything to just make it work, because people will buy it anyway. They didn't said anything about performance or a increadible amount of bugs in their advertisements...
Current UI (Java and Android layouts) and Android itself are the reasons why I didn't tried to enable the dead code for the zone trigger. Implementing new things in the existing UI is a huge pain in the ...
And yet I hope the Corp. can publish more documents which can help not only itself for better reputation and sales but also buyers. Otherwise there are so many alternatives. Once people lose interests, people won't buy.
Open source firmware and hardware documentation increases sales a lot. But greedy companies knows "better".
Same thing with the piracy. Piracy increases sales, because this is a free advertisement. But most companies instead of making more or better products, they fight piracy instead (even Keysight with a copyright on their scopes documentation...), which in the end hurts legal users the most.
I also implemented license system, which is a nothing else than a copy protection (only one time thing, in the opposite of what some people think about it). I had other reasons than sales to do this. And exactly as I expected, after release with this thing implemented, sales went down very quickly. But there are other more important things than money.
Maybe make it return true only for valid cases, not always
That's the thinking I don't like. Maybe add a 10 another functions to make it 10 times slower than it is originally? Or maybe call a even slower script because it's easier?
In my mod, this function is not even called at all. I removed all calls to all Rigol license system functions for the better performance. Long time ago.
BTW. Who want's to have overclocked AFG to 250 MSa/s? This will give max frequency 80 MHz instead of 50 MHz as it is right now. Only reason why I didn't release it yet, is because of the calculations of the user input (frequency set in a multiple places), which I need to do.
-
I also implemented license system, which is a nothing else than a copy protection (only one time thing, in the opposite of what some people think about it). I had other reasons than sales to do this. And exactly as I expected, after release with this thing implemented, sales went down very quickly. But there are other more important things than money.
The licensing system didn't bother me at all. I did make a foolish mistake by not reading a post thoroughly and thinking I would need to repurchase a new release.
BTW. Who want's to have overclocked AFG to 250 MSa/s? This will give max frequency 80 MHz instead of 50 MHz as it is right now. Only reason why I didn't release it yet, is because of the calculations of the user input (frequency set in a multiple places), which I need to do.
I would be interested in this as I am in the process of building the AFG from here: https://www.eevblog.com/forum/testgear/awg-function-generator-for-dho800-900-series-oscilloscopes/ (https://www.eevblog.com/forum/testgear/awg-function-generator-for-dho800-900-series-oscilloscopes/)
-
I also implemented license system, which is a nothing else than a copy protection (only one time thing, in the opposite of what some people think about it). I had other reasons than sales to do this. And exactly as I expected, after release with this thing implemented, sales went down very quickly. But there are other more important things than money.
The licensing system didn't bother me at all. I did make a foolish mistake by not reading a post thoroughly and thinking I would need to repurchase a new release.
BTW. Who want's to have overclocked AFG to 250 MSa/s? This will give max frequency 80 MHz instead of 50 MHz as it is right now. Only reason why I didn't release it yet, is because of the calculations of the user input (frequency set in a multiple places), which I need to do.
I would be interested in this as I am in the process of building the AFG from here: https://www.eevblog.com/forum/testgear/awg-function-generator-for-dho800-900-series-oscilloscopes/ (https://www.eevblog.com/forum/testgear/awg-function-generator-for-dho800-900-series-oscilloscopes/)
-
I would be interested in this as I am in the process of building the AFG from here: https://www.eevblog.com/forum/testgear/awg-function-generator-for-dho800-900-series-oscilloscopes/ (https://www.eevblog.com/forum/testgear/awg-function-generator-for-dho800-900-series-oscilloscopes/)
Im not sure how it will behave with the 250 MHz input data and 80 MHz output. In the datasheet of DAC IC there is: "210 MSPS", so there is a chance.
My DHO924S with the original and unmodified (yet :) ) AFG works properly with those parameters, beside of the lower amplitude (output opamps and filters).
-
A binary patch can only change one byte for another, so we are restricted in terms of the changes we can make. There are, of course, techniques for code injection, but they are more complicated and perhaps not worth the effort. I have shown that the necessary adjustments can be made at this entry level using only simple binary patches.
Regards.
Indeed but you can use it many times.
I don't see entire function but I think is more complex and space required is enough to fit new code.
Maybe I don't explain it right.
For example
Function that check licence is on area that is 280bytes you write some code in assembly that if is a valid option return true otherwise return false. That result in 148 bytes size code
Then patch 148 bytes
Function is more simple instead of doing all stuff just return true if is asked for valid option
@norbert.kiszka
That discussion is about patching original firmware, not like your case when you rebuild it or make it from scratch.
I don't see how replacing a function with one much simpler result in add a 10 another functions to make it 10 times slower than it is originally
-
In Ghidra is more easy!! you can see the offsets, the opcode the assembly and the c++ code at the same time!
Ghidra makes it easier to understand the code and find things in it but it doesn't make it easy to modify it.
Not at all.
-
That discussion is about patching original firmware, not like your case when you rebuild it or make it from scratch.
Actually it was more discussions in single thread.
I don't see how replacing a function with one much simpler result in add a 10 another functions to make it 10 times slower than it is originally
This was a exaggeration to emphasize a fact. Most of today software engineers just doesn't care about software performance. They just add new code without thinking if that will be very fast or very slow to execute, or easy to maintain in the future. In the stock app, exporting (to a file) and importing settings takes around 5 seconds. After my ~15 minutes of work it does the same job in one second - "only" 5 times faster.
Ghidra makes it easier to understand the code and find things in it but it doesn't make it easy to modify it.
100% agree.
On top of it, there is a built in decompiler which often generates pseudocode with a completely different logic than it is in reality. So every use must be done with caution.
This is one of the reasons why I want to make partial rewrite of it. Instead of doing extremely slow modification of the compiled binary, I will be able to make one or more functions in the separate C code linked with it.
As I said, C, not this C++ "rubbish". C++ code is much slower than same thing done in C.
Try to do a simple hello world (print simple message on the screen and nothing else) in both and compare it in Ghidra or measure time needed to execute. Difference between those is huge. Also C code is easier to maintain, because there is less unnecessary but "fancy" things.
Yes, you need to use the binary file editor of your preference. In Windows, Winhex for example. But I prefer to use a Python script, for easy documentation and automatization.
In this way it's even slower than doing it in Ghidra. Many times slower.
-
C++ code is much slower than same thing done in C.
That's fighting words...
-
C++ code is much slower than same thing done in C.
That's fighting words...
C++ and C are not the same exact language. Compiled binaries are extremely different in many cases (sometimes are identical, but only sometimes).
-
C++ code is much slower than same thing done in C.
That's fighting words...
C++ and C are not the same exact language. Compiled binaries are extremely different in many cases (sometimes are identical, but only sometimes).
Oh, you men hacking C vs. hacking C++.
Yeah, C++ will be messier.
-
C++ code is much slower than same thing done in C.
That's fighting words...
C++ and C are not the same exact language. Compiled binaries are extremely different in many cases (sometimes are identical, but only sometimes).
Oh, you men hacking C vs. hacking C++.
Yeah, C++ will be messier.
Yes, C++ is messy, but what I mean: generated executable binaries are much slower at doing stuff when those are executed and not the best for maintenance (source code).
I hope You understand now what I tried to say.
-
To add F-Droid to Actions panel:
{
"glyph": "fdroid.png",
"caption": "F-Droid",
"type": "APP",
"command": "org.fdroid.fdroid"
},
Icon:
(https://private-user-images.githubusercontent.com/2745567/499701259-a00faa86-0f4d-4c2d-9c9f-0957f626e7f3.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjAxMDM2MjYsIm5iZiI6MTc2MDEwMzMyNiwicGF0aCI6Ii8yNzQ1NTY3LzQ5OTcwMTI1OS1hMDBmYWE4Ni0wZjRkLTRjMmQtOWM5Zi0wOTU3ZjYyNmU3ZjMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MTAxMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTEwMTBUMTMzNTI2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZDhjY2Q0N2FiYWZmOTliZGZjZjM2YmE0MjZlOWQyMTM3OTY4ODVlMWVjZDJiMzk4OGEyMGQ3YjAyMjkzNmQ0NSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.Vdf1pace8HGnLC7GNJkePWgkCU1KdygRMwkYO90KxII)
-
C++ code is much slower than same thing done in C.
That's fighting words...
C++ and C are not the same exact language. Compiled binaries are extremely different in many cases (sometimes are identical, but only sometimes).
Oh, you men hacking C vs. hacking C++.
Yeah, C++ will be messier.
Yes, C++ is messy, but what I mean: generated executable binaries are much slower at doing stuff when those are executed and not the best for maintenance (source code).
I hope You understand now what I tried to say.
What I understand from what you said is that you do not know C++ well. I don't want to argue.
-
C++ code is much slower than same thing done in C.
That's fighting words...
C++ and C are not the same exact language. Compiled binaries are extremely different in many cases (sometimes are identical, but only sometimes).
Oh, you men hacking C vs. hacking C++.
Yeah, C++ will be messier.
Yes, C++ is messy, but what I mean: generated executable binaries are much slower at doing stuff when those are executed and not the best for maintenance (source code).
I hope You understand now what I tried to say.
What I understand from what you said is that you do not know C++ well. I don't want to argue.
This is what I hear quite often from a people experienced in C++ but not so much in C.
Make a some code and compare performance.
*nix operating systems (BSD, Linux, MacOS and others) are written in C and some small parts in Assembly (either hardware stuff or something used very often). You can read/hear developers why they don't want to see any C++ code.
C++ developers like to say that in C You can't call functions by using pointers, which is nothing else than another myth. Everything written in C++ can be implemented in C.
But if You do a bad code, it will be slow - no matter what language You will chose.
Sometimes same thing is with the Java developers - about half of them say that Java is the fastest. Scripting (VM) languages never was the fastest, quite the opposite actually.
-
Everything written in C++ can be implemented in C.
It just takes much, much longer to do.
My answer to C programmers is to ask them why they don't do everything in assembly language?
Whatever their answer is I then say, "and that's the reason I use C++ and not C".
-
Coming back to hacking, I published .GEL file to revert both app and the OS changes done by my mod (any version).
About 5-10% users has to make warranty claim due to hardware issues.
-
Everything written in C++ can be implemented in C.
It just takes much, much longer to do.
My answer to C programmers is to ask them why they don't do everything in assembly language?
Whatever their answer is I then say, "and that's the reason I use C++ and not C".
Whenever I want to do something much faster and I don't care about execution time, Im using scripting language (especially bash which allows to do a lot of stuff just by simple and short one line of code).
I think people learn C++ as the only one language and they are fixated to be the best language. While they never wrote anything in other languages, maybe beside of the simple hello world.
In C++ making one function or method into multiple functions/methods just to handle different variable types is crazy and bad - it doesn't make anything to be faster.
In the Rigol app, even simplest getters are in the separate functions (or methods if You prefer, but after compiling this is a function). Their great C++ developers never heard about possibility to enable compiler optimizations.
Right now in the stock app, in many places if the code wants to read 4 or 8 bytes into single CPU register, it calls thunk function first, which reads pointer to a function from a memory, then executes it (BR in Assembly). Instead of doing it in around 1 ns, it can be like 15 ns. Stock app does less that 30 k waveform updates per second. With my changes it goes up to 108 k. Use Ghidra if You don't believe me.
-
You know C++ at an introductory (or maybe intermediate) level.
-
You know C++ at an introductory (or maybe intermediate) level.
My knowledge level about C++ doesn't change the fact that is slow as hell. Rigol scope app is a great proof of this fact. This is not only my own words.
-
C++ with a good implementation is probably the highest performance general purpose language in common use. Nobody who understands programming or performance really disagrees with this. If you believe otherwise you are simply wrong.
It's not 100% of course. C can be slightly faster in a few situations. As can Rust. Generally they are all close enough the performance differences are rarely important.
That's not to say they are always the best choice, there are many other important factors.
C++ does depend a lot more on the quality of the implementation for performance than simpler languages like C, but all three major implementations are pretty good.
Generally if a program written in any systems language is too slow the problem that the program is written badly. That is of course is possible in any language. C++ is probably middle of the road in terms of making it easy to accidentally do something much slower than you intended.
-
C can be slightly faster in a few situations.
Text (string) situations are not rare. In this case C++ is extremely slower than C.
Generally if a program written in any systems language is too slow the problem that the program is written badly. That is of course is possible in any language.
Correct. Also Dunning–Kruger effect is another factor in every language.
Speaking of the bad code, there are a lot of people using too much try-catch blocks and other C++ things, which ends up as a much slower app than it should be.
-
C can be slightly faster in a few situations.
Text (string) situations are not rare. In this case C++ is extremely slower than C.
It's not. You are just poorly informed. In many ways C++ string handling is faster because the length is stored explicitly which is for many operations much faster than null termination.
-
C can be slightly faster in a few situations.
Text (string) situations are not rare. In this case C++ is extremely slower than C.
It's not. You are just poorly informed. In many ways C++ string handling is faster because the length is stored explicitly which is for many operations much faster than null termination.
1. In C You can use structs and store length if You often need this information.
2. C++ has it's own text format. That requires to do a lot of conversions between ASCII and C++. In the Rigol firmware this is done a lot at the init, which takes literally a couple seconds and later when app is running, multiple times per second, slowing it down.
-
Are you talking about Unicode? That has nothing to do with C vs C++.
-
Are you talking about Unicode? That has nothing to do with C vs C++.
No. C++ has its own format to store and handle text strings.
-
Are you talking about Unicode? That has nothing to do with C vs C++.
No. C++ has its own format to store and handle text strings.
That's just... not true at all. I don't even know what you are talking about.
-
Are you talking about Unicode? That has nothing to do with C vs C++.
No. C++ has its own format to store and handle text strings.
That's just... not true at all. I don't even know what you are talking about.
So what's this: https://www.geeksforgeeks.org/cpp/strings-in-cpp/ (https://www.geeksforgeeks.org/cpp/strings-in-cpp/) ?
It's get even much worse in the Android NDK.
Did You ever tried to see compiled C++ code in Ghidra or any other deaasembler/decompiler?
If the C++ would be same as fast or faster than C, C it wouldn't be so popular to this day.
I ask one more time, why the most of the operating system kernels and other internals are written in C instead of "better" C++?
-
So what's this: https://www.geeksforgeeks.org/cpp/strings-in-cpp/ (https://www.geeksforgeeks.org/cpp/strings-in-cpp/) ?
It's a C++ class that is comprised of a field and a character buffer containing (usually) ASCII data. "Converting" to a C string is a no-op. It's not a different encoding or anything.
And as I said, C++ strings are often faster than equivalent C code. Because the length field is included you avoid extraneous calls to strlen(). For instance to concatenate two C strings, you have to call strlen on both before you allocate or check the destination buffer. With c++ string class you just add two integers. Even just strcpy has to be checking every block it reads for null values before writing to the destination. Copying a c++ string turns into plain memcpy which is considerably faster.
Yes you can do a lot of this in C. It won't be quite as fast, but more importantly that's not how C is written and it's not how C libraries expect strings to be passed.
-
So what's this: https://www.geeksforgeeks.org/cpp/strings-in-cpp/ (https://www.geeksforgeeks.org/cpp/strings-in-cpp/) ?
It's a C++ class that is comprised of a field and a character buffer containing (usually) ASCII data. "Converting" to a C string is a no-op. It's not a different encoding or anything.
And as I said, C++ strings are often faster than equivalent C code. Because the length field is included you avoid extraneous calls to strlen(). For instance to concatenate two C strings, you have to call strlen on both before you allocate or check the destination buffer. With c++ string class you just add two integers. Even just strcpy has to be checking every block it reads for null values before writing to the destination. Copying a c++ string turns into plain memcpy which is considerably faster.
Yes you can do a lot of this in C. It won't be quite as fast, but more importantly that's not how C is written and it's not how C libraries expect strings to be passed.
You just repeated yourself. As I said already, You don't have to call strlen in C multiple times. Checking null byte doesn't make it slower, because in each loop iteration You need to check condition if You need to break or not yet - doesn't matter what exact byte You have to check. But making this condition based on null is faster, because You use same memory location, instead of two.
Speaking about memory. You said class. So there is a at least one object. This object after compilation is a nothing else than malloc (which is not called directly, but instead unnecessary wrapper is used without any reason), which is passed to every method (function in the machine code) - which makes it even slower.
Im pretty sure You didn't tested in reality and You didn't tried to modify compiled code - after those two it's perfectly clear why C is faster and why it's so popular to this day.
Most of the C++ and Java users are like a sect or a Jehovah's Witnesses. Huge confirmation bias (https://en.wikipedia.org/wiki/Confirmation_bias) - no mater what proof You will provide, it will be always worse at each try.
-
Everyone’s debating whether C or C++ is faster… Meanwhile, my Visual Basic “Hello World” finishes before you guys even finish compiling. 😎 :-DD :-DD :-DD
-
Speaking of the bad code, there are a lot of people using too much try-catch blocks and other C++ things, which ends up as a much slower app than it should be.
You haven't understood the single most powerful feature of C++ - stack unwinding ("RAII").
Try-catch isn't fro null pointer exceptions, it's for freeing all the temporary memory allocations when you're six functions deep in a complex file parser and you have an unexpected end of file.
(or things like that)
Checking all the error return codes and freeing your C strings would be a bug-prone mess in that situation. Lines of code could easily double.
-
I don’t really understand much about coding, but I imagine that low-level code is usually more efficient than high-level code.
The problem is that you really need to know how to use it properly.
I guess a program written in C or C++ would still be less efficient than one written in assembly, for example — but the real issue is how hard it is to write and maintain.
That’s probably why, over time, programming languages became more high-level — from C to C++, C#, Java, and so on.
-
C/C++ code written for superscalar processors is more efficient than assembly code. A compiler can optimize parallel pipelines to a degree that assembly programming cannot.
C/C++ code compiled by a good compiler runs more efficiently on superscalar processors than code written in assembly language.
Nowadays, even microcontrollers have parallel pipelines. For example, ARM Cortex-M7s.
-
C/C++ code written for superscalar processors is more efficient than assembly code. A compiler can optimize parallel pipelines to a degree that assembly programming cannot.
C/C++ code compiled by a good compiler runs more efficiently on superscalar processors than code written in assembly language.
Nowadays, even microcontrollers have parallel pipelines. For example, ARM Cortex-M7s.
That is the reason why RISC processors are invented, they are dedicated for compiler code, of course you can program them in assembly but due to the restricted instruction set it is not optimal.
-
You're talking about something different. What I'm talking about is that on superscalar processors, compilers can generate code that makes highly optimized use of parallel pipelines. It's very, very difficult for an assembly programmer to do this at the compiler level. Therefore, C/C++ code can be much more efficient for these architectures. This is different from whether the processor is RISC or CISC.
-
I don’t really understand much about coding, but I imagine that low-level code is usually more efficient than high-level code.
Only for small tasks.
Real speed these days comes from algorithms and data structures, being able to massage and reorganize your code after profiling it. C++ absolutely destroys C there.
It's also much faster to write, you're not constantly re-implementing linked list, by hand, etc.
C just doesn't scale well, either. You simply run out of names for functions after a while, or have to start putting type names in the functions themselves. Objects/classes flip things around and associate function names with their data. You can have as many functions called "add()" as you have objects (more, actually) so the brain load (number of things you have to remember about your code six months from now) is much smaller in C++.
-
The meaning of superscalar processors is that they in one cycle execute multiple instructions but not all ARM CPUs are superscalar processors and I don't know if the CPU used in our Rigol 800/900 is from this type.
We should open another discussion about the C and C++ compiler because it is far from the hacking of the Rigol 800/900 series of oscilloscopes.
-
We should open another discussion about the C and C++ compiler because it is far from the hacking of the Rigol 800/900 series of oscilloscopes.
It's a discussion that's been going on since the 1990s.
I'll just go back to my earlier assertion:
My question for C programmers is, "why don't you write everything in assembler?"
Whatever they answer I then say, "...and that's the reason I use C++ instead of C".
(Note: I started in hexadecimal and went hexadecimal -> assembler -> C -> C++ )
-
That topic become x vs y.
Let's go back to DHO series
-
I just realized that Rigol has copied the modified user interface I created for the DHO800/900 series in their “Limited Edition” oscilloscopes, the MHO98 and MHO900. As Charles Caleb Colton said: "imitation is the sincerest compliment".
https://www.batterfly.com/shop/en/articoli-blog/rigol-mho900-presentazione (https://www.batterfly.com/shop/en/articoli-blog/rigol-mho900-presentazione)
[attachimg=1]
And they are using the full screen bottom bar from @AndyBig
[attach=2]
-
"GPL is not a legal license in the sense that one could be sued for not following it."
What the what???? Exceedingly incorrect sir.
Someone somewhere failed horribly for you to be left with this impression.
The whole point of the GPL is exactly and explicitly to employ the very same legal machinery and principles of ownership and copyright that protects commercial software and literature and artwork, to protect free software.
Breaking the GPL is absolutely breaking a real law just exactly like violating any other copyright.
Something like say quickbooks has terms governing your right to use it. The terms are you have to give them money, you can't redistribute any copies, you for damned sure can't *sell* copies, etc.
Gnucash also has terms. They are different terms, but they are the terms, set by the author(s), using the exact same legal machinery and principles as any other intellectual property.
It doesn't matter if you are violating quickbooks terms or violating gnucash terms, all that matters is that you are violating the copyright of the material.
Merely, probably no one has the time or money or motivation to go after someone violating gnucash copyright because it would be a lot of effort and essentially no reward, unless the offender is making a lot of money from it, like if it turns out quickbooks is actually the one stealing gnucash code. So, sure, probably you will usually *get away* with it, but that is just getting away with it. You can absolutely get sued at any moment, if anyone with an interest in the violated code simply finds out about it and decides it's worth their time to persue it.
-
look at the knobs, all-same fronthaul as dho series, just silverish shining.
this potentially means Norbert could push DHO further into stable 800Mhz/4GS/500Mp/100Mhz AGF ;)
looking forward to Dave's teardown
-
look at the knobs, all-same fronthaul as dho series, just silverish shining.
this potentially means Norbert could push DHO further into stable 800Mhz/4GS/500Mp/100Mhz AGF ;)
looking forward to Dave's teardown
Next week I will get my gold shiny oscilloscope with all options enabled with no need of hacking.
I sold my 924S.
-
Hi Norbert
Your crack works great !!
You mention you have made a gel file to return the machine back to original setup---where can i get it ??.
Regards
Hardy
-
Hi Norbert
Your crack works great !!
You mention you have made a gel file to return the machine back to original setup---where can i get it ??.
Regards
Hardy
It should be right where you downloaded the regular file.
-
Its quite a shame, that the enduser is essentially doing quite a bit of work for the product, that the enduser PAID FOR. And receiving NOTHING for it. At least i did not receive a single cent for quite a few hours i spent, figuring out bugs and try to make Siglent aware of it.
I just realized that Rigol has copied the modified user interface I created for the DHO800/900 series in their “Limited Edition” oscilloscopes, the MHO98 and MHO900. As Charles Caleb Colton said: "imitation is the sincerest compliment".
Have you been paid for the work?
-
Have you been paid for the work?
Of course not, although I do not lose hope that I will receive a MHO98. ;D
-
Wow, this thread has legs.
I think I left it back on page 60 or so.
I still have one of the Andy hacks installed.
Has Rigol released anything stable as of late?
-
[attachimg=4]
It has been released, better than the MHO98 interface in your DHO800/900 device!
Features :
- Full Screen mode with informative bottom bar and clickable elements
- Special A(ction) button to launch the DHO Actions application
- Included a configurable DHO Actions panel that allows to execute SCPI commands, launch applications (Python scripts with PyDroid) and open web pages in the default browser.
- Included DHO visor, allows to display the screen streaming in scaling mode.
- Unlocks extended decoders like LIN, FlexRay, I2S, 1553B
- All DHO series have bandwidth unlocked to 250MHz and Memory depth up to 50M
- Ultra Power Analyzer unlocked for all DHO series
- Enabled advanced settings in XY mode with real functions.
- Compact unified Horizontal bar, Trigger bar and Channel widgets
- Dock/Undock of the Result Bar
- Compact Result / measurements bar with optimized rendering
- Probe attenuation in channel widget
- Trigger coupling indicator
- Better rendering of the chanel scale labels, so they can be readed always no matter what the back color is.
- Automatically show date-time at boot if it is valid
- Start menu settings button allows to open Android system settings
- Fixes alignment of visual elements, color and transparency corrections
- Better UI organization for improvement of screen size utilization
- Code enhancements, removed extra logging for better general performance
- Fixes for bugs reported by the community
- Normal and System versions
-
How stable is the Rigol running with Android? Does it get sluggish at some time, or does it crash sometimes?
-
(Attachment Link)
It has been released, better than the MHO98 interface in your DHO800/900 device!
Features :
- Full Screen mode with informative bottom bar and clickable elements
- Special A(ction) button to launch the DHO Actions application
- Included a configurable DHO Actions panel that allows to execute SCPI commands, launch applications (Python scripts with PyDroid) and open web pages in the default browser.
- Included DHO visor, allows to display the screen streaming in scaling mode.
- Unlocks extended decoders like LIN, FlexRay, I2S, 1553B
- All DHO series have bandwidth unlocked to 250MHz and Memory depth up to 50M
- Ultra Power Analyzer unlocked for all DHO series
- Enabled advanced settings in XY mode with real functions.
- Compact unified Horizontal bar, Trigger bar and Channel widgets
- Dock/Undock of the Result Bar
- Compact Result / measurements bar with optimized rendering
- Probe attenuation in channel widget
- Trigger coupling indicator
- Better rendering of the chanel scale labels, so they can be readed always no matter what the back color is.
- Automatically show date-time at boot if it is valid
- Start menu settings button allows to open Android system settings
- Fixes alignment of visual elements, color and transparency corrections
- Better UI organization for improvement of screen size utilization
- Code enhancements, removed extra logging for better general performance
- Fixes for bugs reported by the community
- Normal and System versions
What is your business model? If I purchase today, am I going to be expected to pay again when you release a new version, or does the one purchase cover future releases?
-
How stable is the Rigol running with Android? Does it get sluggish at some time, or does it crash sometimes?
We have not seen any reports of instability in this forum's bug thread attributable to the Android operating system.
-
What is your business model? If I purchase today, am I going to be expected to pay again when you release a new version, or does the one purchase cover future releases?
Well, I don't see that like a sell anything, but a contribution to my implemented changes/additions, you know, If somebody call me to make a firmware for a new device of course I will charge an amount of at least three digits.
I promised to give this last change for free for people who contributed for the version compatible with the firmware 00.01.04.00.02, I already have that list with the orderID, Usernames, so if somebody already purchase the previous version please contact me through Patreon to give a free access to the new version.
I usually only request another contribution when the changes are too numerous, for example each time Rigol posts a new firmware version, because the changes are not easily portable between versions of the firmware. In previous releases, I posted the updates directly in the same store item so users could download them, but changes to the Patreon store recently meant that it was no longer possible to edit previous publications.
-
Gosh, i have just found out, that Rigol wants you to register, in order to download the firmware... :--
Has this been longer in effect already?
-
This only happens on the official Rigol Europe website. You go to Rigol Shop (https://rigolshop.eu/dho804.html (https://rigolshop.eu/dho804.html)) or Rigol North America (https://www.rigolna.com/products/rigol-digital-oscilloscopes/dho800/ (https://www.rigolna.com/products/rigol-digital-oscilloscopes/dho800/)) and you can download without having to register.
-
What is your business model? If I purchase today, am I going to be expected to pay again when you release a new version, or does the one purchase cover future releases?
Well, I don't see that like a sell anything, but a contribution to my implemented changes/additions, you know, If somebody call me to make a firmware for a new device of course I will charge an amount of at least three digits.
I promised to give this last change for free for people who contributed for the version compatible with the firmware 00.01.04.00.02, I already have that list with the orderID, Usernames, so if somebody already purchase the previous version please contact me through Patreon to give a free access to the new version.
I usually only request another contribution when the changes are too numerous, for example each time Rigol posts a new firmware version, because the changes are not easily portable between versions of the firmware. In previous releases, I posted the updates directly in the same store item so users could download them, but changes to the Patreon store recently meant that it was no longer possible to edit previous publications.
I don't believe Rigol will release a new firmware for this model in the near future, stuck on 00.01.04.00.02 and that's it. No more critical bugs found.
-
How stable is the Rigol running with Android?
Very.
Does it get sluggish at some time, or does it crash sometimes?
No.
(And even if you manually kill the main app it just starts right up again exactly where it was after a couple of seconds. You can use this to switch 'scope models without a reboot - just replace the vendor.bin file and kill the app over Ethernet/WiFi)
-
I don't believe Rigol will release a new firmware for this model in the near future, stuck on 00.01.04.00.02 and that's it. No more critical bugs found.
They might... the new MHO models have some new features/fixes in the firmware, they could trickle down.
-
..I don't believe Rigol will release a new firmware for this model in the near future, stuck on 00.01.04.00.02 and that's it. No more critical bugs found.
There is a serious bug still there -
https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg6014821/#msg6014821 (https://www.eevblog.com/forum/testgear/rigol-dho800900-oscilloscope-bug-reports-firmware/msg6014821/#msg6014821)
Confirmed by Rigol, btw. Fix date unknown..
-
... No more critical bugs found.
So they dont care about the minor bugs, that are still annoying (at best), just like Siglent? Do they sell only a few of them, so there is no real value for them there?
-
Gosh, i have just found out, that Rigol wants you to register, in order to download the firmware... :--
Has this been longer in effect already?
I just downloaded the firmware from https://www.rigolna.com/firmware/ (https://www.rigolna.com/firmware/) without needing to register.
-
Gosh, i have just found out, that Rigol wants you to register, in order to download the firmware... :--
Has this been longer in effect already?
You can enter garbage details, they don't even send you an email.
Or ... just connect it to a network and it'll update itself.
-
DHO8x2 devices now have all the unlocked features without the need to change the product ID, meaning there are no more ghost channels or extra widgets.
[attachimg=1]
-
Or ... just connect it to a network and it'll update itself.
Can autoupdate be turned off?
-
DHO8x2 devices now have all the unlocked features without the need to change the product ID, meaning there are no more ghost channels or extra widgets.
(Attachment Link)
Very nice work!
-
Or ... just connect it to a network and it'll update itself.
Can autoupdate be turned off?
You have to confirm it.
And given the frequency of updates.. not likely to be annoying.
-
Or ... just connect it to a network and it'll update itself.
Can autoupdate be turned off?
I do not see any setting for that. I guess the only way to prevent auto update is to block it from accessing the Internet in your router, or not connecting to a network with Internet access.
-
I do not see any setting for that. I guess the only way to prevent auto update is to block it from accessing the Internet in your router, or not connecting to a network with Internet access.
I don't see any reason why the scope should have access to internet.
We can also blackhole DNS names in /system/etc/hosts
When updates are available, I install them manually. In general, just about year 2026, auto-updates for anything should be avoided when possible.
-
I do not see any setting for that. I guess the only way to prevent auto update is to block it from accessing the Internet in your router, or not connecting to a network with Internet access.
I don't see any reason why the scope should have access to internet.
We can also blackhole DNS names in /system/etc/hosts
When updates are available, I install them manually. In general, just about year 2026, auto-updates for anything should be avoided when possible.
I completely agree.
-
In general, just about year 2026, auto-updates for anything should be avoided when possible.
Indeed, Indeed. Also Products, that need accounts, internet connections or cloud services, as we have seen yesterday...
-
Currently Im doing final tests of the v0.4.2-PR2 and it should be today if all tests will be ok.
Worst thing was with the self-cal, because it looks like DC offset wasn't caused by mem depth and/or timings as I primarily thought. It was just a single CPU instruction, but not easy to find.
Or ... just connect it to a network and it'll update itself.
Can autoupdate be turned off?
You can block Rigol ip's. Or use my mod in which I disabled it.
I don't see any reason why the scope should have access to internet.
No RTC battery and in the same time properly working NTP is the reason to connect it to the internet.
-
V0.4.2-PR2 (second prerelease) is released.
Changelog:
- Fixed crash in Math AX+B function.
- Fixed randomly displayed reference waveform GND pointer, when no reference was used.
- Fixed excessive offset in CH1 after self calibration (needs further testing).
- Fixed probable cause of the crash when USB at the back was connected (unable to reproduce).
- Changed table data from black text on white background to white text on black background to match everything else.
- Table data now uses regular font, including header (first line).
- Removed unnecessary header from all measurements.
- Measurements open/close buttons (icons) are now semitransparent.
- Optimizations in Ultraacquire.
- Added failsafe loop in Posix installation script in case of network problems or bugs in adb.
Let me know if the offset problem after self calibration is properly fixed or not.
-
I’ve installed the new version and everything seems to be working fine.
Just one note — for users with the 2-channel version, if you run the calibration with the default settings, it will probably fail.
The issue can be solved by disabling CH3 and CH4 during calibration.
Other than that, everything looks great — the measurement indicators are super stable, and Ax+B works perfectly.
Thanks, Norbert — excellent work! 👏
-
Someone asked me how to run Python scripts on an oscilloscope, so I created this short demonstration.
https://www.youtube.com/watch?v=7uYD2V7T-2c (https://www.youtube.com/watch?v=7uYD2V7T-2c)
The code:
import pyvisa
import time
CONN = 'TCPIP::localhost::INSTR'
def main():
try:
rm = pyvisa.ResourceManager('@py') # Use pyvisa-py backend
inst = rm.open_resource(CONN)
inst.timeout = 5000 # Set timeout to 5 seconds
idn = inst.query(':LAN:DESCription?')
print(f'Instrument: {idn}')
inst.write(':MEASure:SOURce CHAN1')
# Take 10 measurements, one per second
for i in range(10):
vpp = float(inst.query(':MEASure:ITEM? VPP').strip())
print(f'Measurement {i+1}: Vpp: {vpp} V')
time.sleep(1) # Wait 1 second before next measurement
inst.close()
rm.close()
except pyvisa.VisaIOError as e:
print(f"VISA Error: {e}")
except Exception as e:
print(f"Unexpected Error: {e}")
if __name__ == '__main__':
main()
-
I don't see any reason why the scope should have access to internet.
No RTC battery and in the same time properly working NTP is the reason to connect it to the internet.
An NTP source should be available on local network, if the scope really does need updated time.
I don't allow most of my devices access to internet.
-
Configuration of NTP server on Linux machine is not difficult. Old computer or old laptop for 30$ has more computing power than it's needed for it.
And You can configure network in OS without the (default) gateway or with the fake one and change NTP daemon to grab data from Your local NTP server.
-
Tell me how to make a backup Rigol 804 ?
-
Someone asked me how to run Python scripts on an oscilloscope, so I created this short demonstration.
That is awesome! I guess you could start an single shot acquire (or any other action) with a script? What is the delay from registering a level change, to actually starting the acquire?
-
v0.4.2 is ready to go (https://www.patreon.com/norbertkiszka/shop).
Changelog:
- Fixed crash in FFT when time base was switched to 50 ms/D or below.
- Fixed randomly displayed reference waveform GND pointer, when no reference was used.
- Fixed crash when USB at the back was connected.
- UI changes in self calibration to avoid confusion and wrong user decisions.
- Unhidden info about the last self-cal date and time.
- FFT peak search vertical tab (math popup window) background changed to almost black to increase readability.
- Optimizations, mostly in the math functions.
- Removed some leftovers of the Rigol license system, which was a huge bottleneck of UI performance.
- Removed insignificant zeros in some math displayed values.
- Auto button and auto in start menu changes memory depth to auto.
- Memory depth in default settings is changed to auto (auto gives max 125 Mpts).
- Default interpolation is changed to auto/sinc.
- Changed table data from black text on white background to white text on black background to match everything else.
- Table data now uses regular font, including header (first line).
- Removed unnecessary header from all measurements.
- Measurements open/close buttons (icons) are now semitransparent.
- Added failsafe loop in Posix installation script in case of network problems or bugs in adb.
- Screenshot now are with no header (model name at the left top) by default.
- UPA power quality refresh time is lowered to 2 per second.
- Added chmod for i2c devices which should prevent from problems with loading settings (from FRAM) at the app startup.
- Removed unused dead code from UI (barteksc/pdfviewer).
- Increased time to wait for the signal in auto settings (auto button).
- Optimizations in various functions.
- start_rigol_app.sh checks if there is a file stopstartscope.txt on the connected USB stick, and if there is such file, it stops execution this change should help with the very rare issues with the bootloop without the need of removing internal SD card. Removing USB stick (with mentioned file) will unpause this script.
- start_rigol_app.sh checks if there is a file disablescopeapp.txt on the USB stick and in such case it disables scope apps (pm disable com.rigol.scope and pm disable com.rigol.launcher).
- start_rigol_app.sh checks if there is a file enablescopeapp.txt on the USB stick and in such case it enables scope apps (pm enable com.rigol.scope and pm enable com.rigol.launcher).
- start_rigol_app.sh looks for the apk files in the folder named scopeapk in the USB stick and tries to install all apk files from this directory. After successful installation, file is deleted, otherwise in case of installation failure, file is preserved.
- start_rigol_app.sh looks for a files executemeatstart.sh and executemeatend.sh in the USB stick, and executes it as a bash script (no execute permission needed).
-
FFT waterfall in dho800/900, are there any mods, apk?
-
After rewriting whole app, sure. I was planning to do so, but with not so many supporters, Im not sure if this will come true anytime soon.
-
FFT waterfall in dho800/900, are there any mods, apk?
I'm currently working on the DHO Tools application. As shown in the video, it will have a waterfall mode, but it will only be available as part of the Sparrow Extended bundle and will be launched from the DHO Actions panel. I need to find some free time to make the final adjustments. The last time I had free time was productive, resulting in the current Extended 0.7.1 version. :)
https://www.youtube.com/watch?v=mO99S1H-xRQ (https://www.youtube.com/watch?v=mO99S1H-xRQ)
-
FFT waterfall in dho800/900, are there any mods, apk?
I'm currently working on the DHO Tools application. As shown in the video, it will have a waterfall mode, but it will only be available as part of the Sparrow Extended bundle and will be launched from the DHO Actions panel.
Via SCPI? It will be very slow.
-
DHO8x2 devices now have all the unlocked features without the need to change the product ID, meaning there are no more ghost channels or extra widgets.
(Attachment Link)
То: mrisco
Why is it not 250MHz?
DHO804 converted to DHO824.
When the GUI detects the product code DHO(HDO)824, it sets the label to 200 MHz. Simply return your device to the original product code. This is purely cosmetic.
.line 117
:cond_1
invoke-virtual {v1}, Lcom/rigol/scope/data/UtilityParam;->getModel()Ljava/lang/String;
move-result-object v2
const-string v6, "DHO824"
invoke-virtual {v2, v6}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z
move-result v2
if-nez v2, :cond_2
invoke-virtual {v1}, Lcom/rigol/scope/data/UtilityParam;->getModel()Ljava/lang/String;
move-result-object v2
const-string v6, "HDO824"
invoke-virtual {v2, v6}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z
move-result v2
if-eqz v2, :cond_3
.line 119
:cond_2
sget-object v2, Lcom/rigol/scope/cil/ServiceEnum$Bandwidth;->BW_200M:Lcom/rigol/scope/cil/ServiceEnum$Bandwidth;
Of course, I could change the label to 'BW_800M', but I try to change things that are really necessary and effective.
These are real changes in the bandwidth:
[attachimg=1]
[attachimg=2]
[attachimg=3]
Note the slight reduction in rise time and the simultaneous increase in Vpp for the same sinusoidal signal in all three cases.
Sorry, I don't have currently a source of square waves of high frequency.
-
I have a question:
Is it possible, that the color of the trace of a channel could be changed?
I would then want to change on of the blue channels to green, and put a green label on it.
-
I have a question:
Is it possible, that the color of the trace of a channel could be changed?
I would then want to change on of the blue channels to green, and put a green label on it.
It's hardcoded. Without the source code, it's much easier to change it permanently instead of adding some switch to UI.
-
FFT waterfall in dho800/900, are there any mods, apk?
I'm currently working on the DHO Tools application. As shown in the video, it will have a waterfall mode, but it will only be available as part of the Sparrow Extended bundle and will be launched from the DHO Actions panel. I need to find some free time to make the final adjustments. The last time I had free time was productive, resulting in the current Extended 0.7.1 version. :)
https://www.youtube.com/watch?v=mO99S1H-xRQ (https://www.youtube.com/watch?v=mO99S1H-xRQ)
Is it a mistake that with only 2, 3 or 4 channels enabled, the memory depth can only be a maximum of 25M?
-
FFT waterfall in dho800/900, are there any mods, apk?
I'm currently working on the DHO Tools application. As shown in the video, it will have a waterfall mode, but it will only be available as part of the Sparrow Extended bundle and will be launched from the DHO Actions panel. I need to find some free time to make the final adjustments. The last time I had free time was productive, resulting in the current Extended 0.7.1 version. :)
https://www.youtube.com/watch?v=mO99S1H-xRQ (https://www.youtube.com/watch?v=mO99S1H-xRQ)
Is it a mistake that with only 2, 3 or 4 channels enabled, the memory depth can only be a maximum of 25M?
The FFT tool takes about 1000 samples of the currently drawed FFT math trace and shows the average, peaks, and waterfall.
-
In the app (both DHO800/900 and DHO1000/4000) hardcoded amount of screen points is exactly 1000 points. FPGA does acqusition(s) and those points app reads those points. After that it's processed with OpenGL rendering.
That's exactly why I didn't made a point mode, because those points doesn't match the sample time. It's hardcoded in many many places in different variable types. So I prefer to rewrite app and only then make a point mode.
-
I did try the DHO804 but the screen size is too small for me (older eyes, fat fingers!), and that would stop me buying a '98.
See also: the bean soup theory (https://www.google.com/search?q=bean+soup+theory)
-
I have a question:
Is it possible, that the color of the trace of a channel could be changed?
I would then want to change on of the blue channels to green, and put a green label on it.
It's hardcoded. Without the source code, it's much easier to change it permanently instead of adding some switch to UI.
I did not mean via UI. Hardcoded would be fine, even better if there would be a settings file on the scope. Is that possible?
-
Background:
===========
DHO924S Hardware 8, was running 00.01.04
All features bought up front and was working, never before been patched
Bought the Extended GUI v0.7.1, followed instructions in readme.txt to the letter
Working from MacBook Pro M4, Tahoe 26.1 with VMWare Fusion & Windows 11.
Using Microsoft PowerShell v7.5.4.0
Android Debug Bridge version 1.0.41
Version 36.0.0-13206524
Installed as C:\Users\andre\PlatformTools\adb.exe
Running on Windows 10.0.26100
I tried for hours to find up-to-date instructions to make a backup of the full SD, could not find anything.
Tried TotalCommander with the ADB Plugin, no success.
Eventually decided to take a chance and go ahead, result as follows:
PS C:\Users\andre\PlatformTools> ./adb connect 192.168.1.38:55555
connected to 192.168.1.38:55555
PS C:\Users\andre\PlatformTools> ./adb root
restarting adbd as root
PS C:\Users\andre\PlatformTools> ./adb shell am force-stop com.rigol.launcher
PS C:\Users\andre\PlatformTools> ./adb shell am force-stop com.rigol.scope
PS C:\Users\andre\PlatformTools> ./adb shell pm uninstall com.rigol.scope
Success
PS C:\Users\andre\PlatformTools> ./adb shell pm uninstall --user 0 com.rigol.scope
Success
PS C:\Users\andre\PlatformTools> ./adb shell mount -o rw,remount /system
PS C:\Users\andre\PlatformTools> ./adb shell mv /system/framework/services.jar /system/framework/services_jar.orig
PS C:\Users\andre\PlatformTools> ./adb push services.jar /system/framework/
services.jar: 1 file pushed, 0 skipped. 9.0 MB/s (3179392 bytes in 0.338s)
PS C:\Users\andre\PlatformTools> ./adb shell mount -o ro,remount /system
PS C:\Users\andre\PlatformTools> ./adb shell sync
PS C:\Users\andre\PlatformTools> ./adb reboot
PS C:\Users\andre\PlatformTools> ./adb connect 192.168.1.38:55555
already connected to 192.168.1.38:55555
PS C:\Users\andre\PlatformTools> ./adb root
restarting adbd as root
PS C:\Users\andre\PlatformTools> cd ../Vendors/Rigol/Sparrow
PS C:\Users\andre\Vendors\Rigol\Sparrow> /Users/andre/PlatformTools/adb install -g -r "Sparrow.apk"
Performing Streamed Install
Success
PS C:\Users\andre\Vendors\Rigol\Sparrow> /Users/andre/PlatformTools/adb reboot
PS C:\Users\andre\Vendors\Rigol\Sparrow>
At this stage the scope reboot but after ~30min wait still just showing the "RIGOL" logo on a blank background...
Any suggestions?
-
Not my mod and I shouldn't take my shoes into it, but You can reinstall stock app with:
adb shell pm install -r /rigol/app/Sparrow.apk
-
Background:
===========
DHO924S Hardware 8, was running 00.01.04
At this stage the scope reboot but after ~30min wait still just showing the "RIGOL" logo on a blank background...
Hi! Try rebooting your device by holding down the power button for over 15 seconds. I don't know if you already contact me, if not. This might be the second report. Delete any licensed files and any mod. Check that the services.jar file has been copied correctly, as a bug in some ADB versions removes the last character of the file name. Could be a problem with the permissions of the services.jar file. This version is already running on over 20 devices without any issues, so I need to establish what is preventing it from running on yours.
If you have this dex file in you device: /data/dalvik-cache/arm64/system@framework@services.jar@classes.dex you must delete it by:
adb shell rm /data/dalvik-cache/arm64/system@framework@services.jar@classes.dex
[attach=1]
Please contact me at discussion on Github: https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions
-
Current situation is that the LAN nor Wifi connections come up, no DHCP registered for either.
So probably the only (possible?) option might be USB connection?
Should the USB Type-A at front or the larger Type-B on the back be used?
OR, should I try get a complete DHO924S firmware, open the unit and rewrite the SD flash card?
If so, links to whereI can download the whole Rigol firmware image and some instructions?
-
Current situation is that the LAN nor Wifi connections come up, no DHCP registered for either.
So probably the only (possible?) option might be USB connection?
Should the USB Type-A at front or the larger Type-B on the back be used?
OR, should I try get a complete DHO924S firmware, open the unit and rewrite the SD flash card?
If so, links to whereI can download the whole Rigol firmware image and some instructions?
Maybe this can help you:
Recover a device https://www.eevblog.com/forum/testgear/rigol-dho800-(814)-failing-to-boot-up/msg5837973/#msg5837973 (https://www.eevblog.com/forum/testgear/rigol-dho800-(814)-failing-to-boot-up/msg5837973/#msg5837973)
SD card image: 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)
-
OR, should I try get a complete DHO924S firmware, open the unit and rewrite the SD flash card?
If so, links to whereI can download the whole Rigol firmware image and some instructions?
There's a complete image in the second post of this topic.
-
That's exactly why I wrote a install script with 1068 code lines - mostly to prevent similar situations and user errors.
BTW. One user reported rare problem with v0.4.2 when measurements are stuck with probe ratio 0.1x - changing probe ratio doesn't change ratio in measurements. He reported it as rare and I can't reproduce it. If anybody else has this problem and knows how to reproduce, it will be very helpful.
-
That's exactly why I wrote a install script with 1068 code lines - mostly to prevent similar situations and user errors.
Yes, it's a good idea to package everything in a GEL file. However, it may require a two-stage installation with a reboot in the middle, so the script will need to write or touch a flag file to differentiate the current stage.
-
I tried for hours to find up-to-date instructions to make a backup of the full SD, could not find anything.
Tried TotalCommander with the ADB Plugin, no success.
Any suggestions?
The best, and really the only way, is to take out the sdcard and image it.
My way is using a laptop with bootable linux on usb.
I have USB-A sdcard adapter that is recognized by all linux and windows, any decent adapter/reader should work.
Then use ddrescue to image the sdcard. I recommend you do this before messing around with the hacking, and then another image right after. This way you have an original restore point, and then another right after the hacking-in the new gui or other stuff. Think of it like a windoze restore points. Get some extra sdcards of same size and you can image back to those and store them, and if needed it's an easy swap-out to get the scope back and running quickly.
Another popular thing to do (for those doing continuous hacking) is to move the sdcard using an extension cable so you can easily take it out without cover and tape removal.
-
ddrescue
If the card is not damaged, cp is good enough.
Another popular thing to do (for those doing continuous hacking) is to move the sdcard using an extension cable so you can easily take it out without cover and tape removal.
I just cut ribs in the housing right above SD card and UART socket. And Im using tweezers to remove or to insert SD card.
-
Background:
===========
...
PS C:\Users\andre\PlatformTools> ./adb shell mount -o rw,remount /system
PS C:\Users\andre\PlatformTools> ./adb shell mv /system/framework/services.jar /system/framework/services_jar.orig
PS C:\Users\andre\PlatformTools> ./adb push services.jar /system/framework/
services.jar: 1 file pushed, 0 skipped. 9.0 MB/s (3179392 bytes in 0.338s)
...
For reference, it seems that you forgot to rename/remove the odex file.
Steps from https://github.com/mriscoc/RIGOL_DHO800_DHO900_GUI/discussions/8:
adb connect ###.###.###.###:55555
adb root
adb shell mount -o rw,remount /system
adb shell mv /system/framework/services.jar /system/framework/services_jar.orig
adb shell mv /system/framework/oat/arm64/services.odex /system/framework/oat/arm64/services_odex.orig
Also, if you have a previously patched system or found this particular .dex file you must also execute:
adb shell rm /data/dalvik-cache/arm64/system@framework@services.jar@classes.dex
Perhaps there is a tool that allows you to mount the uSD image and partition, and then remove those files.
-
@MRISCO: I have the same problem with the stuck Rigol logo. The only way to fix it is to press the power button until the scope shuts down, then restart it immediately! Please create an installation guide on Patreon. The current links to the instructions are too prone to errors. The only way to get the scope working again was with Norbert Kiszka's POSIX script. However, since then my time has been wrong. It's still summer time.
-
Hello. Regarding the backup of the SD card. You can make a backup over the network using ADB under Windows, without opening the scope. I tried it. It takes about 2 hours. The method is taken from the Russian forum:
adb connect <IP Address>:55555
adb root
adb connect <IP Address>:55555
adb pull /dev/block/mmcblk0 DHO8xx.img
P.P.
Again taken from the Russian forum. They have successfully restored from a backup to a new SD card with the balenaEtcher. To change the cards, you need to open the scope. :)
I personally haven't tried recovery yet.
-
@MRISCO: I have the same problem with the stuck Rigol logo. The only way to fix it is to press the power button until the scope shuts down, then restart it immediately! Please create an installation guide on Patreon. The current links to the instructions are too prone to errors. The only way to get the scope working again was with Norbert Kiszka's POSIX script. However, since then my time has been wrong. It's still summer time.
Hi, the guide is there, but I know it has many steps and can be confusing. I will try to create a GEL file to avoid installation errors next time I have some free time.
-
The method is taken from the Russian forum:
Not longer than week ago I posted on this forum exact same thing.
Similar method is used for decades with making copy of a running database server being under heavy load and without possibility to shut it down to longer than couple seconds.
-
To everyone that has responded with advice, much appreciated.
Since both USB and LAN interfaces where non-functional it only left the option of opening the unit to remove the SD card.
Since the unit is still under warranty I chose to return it to the local agents to reflash and get working, rather than void the warranty just to try fix it myself.
As soon as the unit is back I will restart the process but this time starting with a complete backup.
@MRISCO
The most important thing missing is a full set of instructions, with step-by-step checks where possible, in 1 place to make the installation process simpler.
I will restart the Extended GUI installation when I have the unit back.
Thanks again...
-
I will restart the Extended GUI installation when I have the unit back.
Thanks again...
You'll 1st image the card, then you can hack it after that. :-+
-
I will restart the Extended GUI installation when I have the unit back.
Thanks again...
You'll 1st image the card, then you can hack it after that. :-+
Image from one DHO800/900 works on every other DHO800/900. Only one problem is with AFG calibration data (only in DHO914S and DHO924S) which is in /rigol/data. It's good to have it backed up separately (/rigol/data contents). Of course it can be extracted from SD card image, but it takes some effort.
-
That's interesting. I installed the MHO98 Webcontrol.apk on the DHO804, and it works better than the original.
-
That's interesting.
More like expected. Rigol is known of saving every penny. Why they would waste couple hours of one employee to compile everything for almost exactly the same device? That's a waste of 3 dollars!!! MHO900 and DHO800/900 are exactly the same beside two ADC, different FPGA and AFG.
-
That's interesting. I installed the MHO98 Webcontrol.apk on the DHO804, and it works better than the original.
better in what aspect?
-
better in what aspect?
The codec seems to have a higher bitrate, and the opened window doesn't create scrollbars in my web browsers (Edge and Chrome on Windows).
-
That's interesting. I installed the MHO98 Webcontrol.apk on the DHO804, and it works better than the original.
Upload it somewhere... :-+
-
It's in the attachment.
-
It's in the attachment.
What's in it?
-
It's in the attachment.
What's in it?
Webcontrol.apk from MHO98 (extracted from Dave SD card image).
-
Automatic 1:1 Square aspect ratio for XY mode
Will be available as a free update in the next version of Sparrow Extended UI v0.7.2
-
Be Quiet! Silent Wings 4 fan.
Almost completely inaudible at 7.6 volts.
To be honest i resent the extra cost and couple of hours this required, bizarre that they would release a product with such a disturbingly noisy fan!
-
For a few dollars on aliexpress you can get a temperature controlled PWM fan driver. Run it off 12V (I assume there is some inside the scope), screw the thermistor to the heatsink, and program in a fan curve. Would be much tidier than a separate power supply!
I have used one for my Keithley 228A, replacing the horrifically loud 120mm AC fan with a good DC fan, programmed it to run at a constant medium speed (idle power is fairly high) until you load the supply and then it ramps up to high when it senses the outlet air temp rising.
-
Would be much tidier than a separate power supply!
I assume you can do it by figuring out the voltage with your lab power supply then just use the correct inline resistor and power it from 12V.
-
AFG (missing board in DHO800) is powered from 12 V. Eventually add some capacitor to suppress noise from the fan.
-
I'm just a beginner, wanted to get this sorted quickly without monkeying around inside!
-
I must have been lucky, because the fan in my DHO804 was barely audible.
-
Just wait until some dust will be on the heatsink and the fun. At some point I was thinking it become much louder because of bearing. I was going to change fan, but I did some other changes, cleaned up the dust and it become much less annoying as it was before.
-
Be Quiet! Silent Wings 4 fan.
Almost completely inaudible at 7.6 volts.
To be honest i resent the extra cost and couple of hours this required, bizarre that they would release a product with such a disturbingly noisy fan!
Beware of the switching noise of that converter board. They can be pretty noisy and will affect your measurements.
-
Just wait until some dust will be on the heatsink and the fun. At some point I was thinking it become much louder because of bearing. I was going to change fan, but I did some other changes, cleaned up the dust and it become much less annoying as it was before.
This is a very good point that many people don't realise - dust on a fan (especially on the leading edge) can make a large difference to the noise. Always clean that before mucking around with any other fan mods.
-
I studied aerodynamics by myself a lot and I know that air turbulence creates audible noise, but I didn't expected that much difference after cleaning.
-
I keep my lab and my equipment very clean.
-
I studied aerodynamics by myself a lot and I know that air turbulence creates audible noise, but I didn't expected that much difference after cleaning.
advantages of practical side of things - also some fans tolerate more the dust than others in terms of noise but here we do not have some Sanyo Denki class, etc
-
I must have been lucky, because the fan in my DHO804 was barely audible.
Check the temperature. Are you sure it's spinning fast enought? :)
-
This thread is driving me nuts. Most of the posts are written in a very private language which most of us dont understand.
What is the "Golang distribution", is it specific to this hack?
Where do I get it from? I've googled for hours trying to find it....... is Golang a slack term for something else I wonder.
-
Can You use quote button? It will give a nice box, not only with a exact post quote, but also a link to that comment.
-
I think they are referring to this post: 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)
Where it's saying to install the Go Programming Language
-
... bizarre that they would release a product with such a disturbingly noisy fan!
Its not bizarre, if you look, what people would buy, or lets say not return. There was one guy here on the forum, that rather would put a device back in the box, and onto the shelf, waiting for an update ( that was unlikely to ever come), rather than returning it.
-
I think they are referring to this post: 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)
Where it's saying to install the Go Programming Language
I think rigol_vendor_bin is much easier to use. I added pregenerated vendor.bin files for every model in my repo (https://github.com/norbertkiszka/rigol_vendor_bin). In same repo, this modification has no problems to compile it on modern Linux distributions.
-
I think that people who are trying to assimilate the knowledge from this thread from beginning to end are getting bogged down in the early attempts at hacking the scope, not realizing that the entire thread has basically boiled down to your hack and mrisco's hack.
I always start reading a very long thread from the end and work my way backwards only as far as necessary.
-
I also wonder why people are trying to read long thread from the beginning and ignore last few pages. Personally and usually Im looking both at the very beginning and at the very end of thread - it saves a lot of time.
-
Hi,
I’m new to this and will receive my DHO-802 tomorrow. I want to hack it to 100 MHz, but I’ve heard it’s recommended to back up the SD card first. Could someone please explain how to back up the SD card before I unlock it to 100 MHz? Thanks! :D
-
You connect the oscilloscope to a network with a PC. If it is wired, it takes about 1 hour. If it is wireless, it takes about 2 hours.
adb connect 192.168.XXX.XXX:55555
adb root
adb connect 192.168.XXX.XXX:55555
adb pull /dev/block/mmcblk0 DHO802.img
If you need to restore the image, you will need to open the oscilloscope.
-
/dev/block/mmcblk0
Sometimes it can be /dev/block/mmcblk1
-
9 days later and the local Rigol office get very little help from Rigol support, somewhere...
The view is that they require an image of the full SD for my DHO924S, assume any DHO9xx (or DHO8xx) image should be a good start.
The file at the link posted at the start of this thread is only 602MB, is that the full image?
If somebody has an image of their DHO9xx SD available and can PLEASE link here or email to me, much appreciated?
-
Between all DHO800/900 models only one significant difference is in directory /rigol/data
For example You can use SD card image from DHO800 and use adb (adb push /local/path/to/data /rigol/) to recover mentioned files.
About 2 years after release, they changed one thing in DT (system staff), but it's insignificant for most of users (unless You are doing some OS hacking).
In all models without S at the end (no AFG installed), You can use any image without recovering /rigol/data but You need to change file vendor.bin and run self calibration.
In S models if You don't have original /rigol/data, You can have DC offset in AFG.
-
Hi All,
I just got my new Rigol DHO804. It show firmware 00.01.04 hardware 12.
I have a wifi dongle identified under Linux as 0bda.8179 RTL8188EU (not EUS).
I cant toogle wifi on.
Thanks for any advice or help.
Philippe
-
Check ID numbers with command:
lsusb
-
Bus 001 Device 004: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Informations is different that what I see with dmesg... Here it is a EUS one !
-
0bda:8179
Looks good to me. I have exact same card (device?).
SOA#2:
Try to turn it off and turn it on.
Leave this WiFi thing in the USB, disconnect Ethernet and restart Your scope.
If this will not help, try to check logcat.
-
Nothing to do, I cant enable wifi.
Is there some requirements about the usb hub ?
I assume it is ok because the keyboard is ok but who know ?...
A direct connection of the dongle on the scope and then power on dont show any light activity on the dongle...
Is there another dongle reference know to work ? I have the list but this TPLink is the only one with a clear commercial reference thats why I choose it.
Regards.
Philippe
-
This the output of logcat when I connect the dongle :
[ 11-15 16:17:44.340 243: 547 D/NetlinkEvent ]
Unknown ND option type 31
-
This the output of logcat when I connect the dongle :
[ 11-15 16:17:44.340 243: 547 D/NetlinkEvent ]
Unknown ND option type 31
It should be anything more in the logcat.
Android is based on Linux kernel and You can read kernel log buffer in the same way as with any Linux/GNU distro, just by calling dmesg.
-
Connecting the TPLink dongle + Logitec keyboard usb dongle with a small hub (because I need also keyboard for wifi key input) I get
01-18 16:50:54.931 0 0 W usbtmc_dev_init: 2327 - E
01-18 16:50:54.938 0 0 W usbtmc_dev_init: 2353 - X
01-18 16:54:18.866 0 0 I usb 3-1 : new high-speed USB device number 2 using xhci-hcd
01-18 16:54:18.987 0 0 I usb 3-1 : New USB device found, idVendor=214b, idProduct=7000
01-18 16:54:18.987 0 0 I usb 3-1 : New USB device strings: Mfr=0, Product=1, SerialNumber=0
01-18 16:54:18.987 0 0 I usb 3-1 : Product: USB2.0 HUB 01-18 16:54:19.013 0 0 I hub 3-1 : 1.0: USB hub found
Connecting the dongle directly into scope usb socket give :
1-18 17:10:15.785 0 0 I usb 3-1 : new high-speed USB device number 4 using xhci-hcd
01-18 17:10:15.906 0 0 I usb 3-1 : New USB device found, idVendor=0bda, idProduct=8179
01-18 17:10:15.906 0 0 I usb 3-1 : New USB device strings: Mfr=1, Product=2, SerialNumber=3
01-18 17:10:15.906 0 0 I usb 3-1 : Product: 802.11n NIC
01-18 17:10:15.906 0 0 I usb 3-1 : Manufacturer: Realtek
01-18 17:10:15.906 0 0 I usb 3-1 : SerialNumber: 00E04C0001
So it seems that something is wrong with the usb hub...
-
Either use different USB hub or use my firmware mod in which You don't need any hub to configure WiFi (directly from the app by using touchscreen).
-
I quickly manufacture a cable so I can power the hub from another source that the scope.
Now the 3 devices enumarate correctly :
the hub itself
the keyboard
the wifi dongle
01-18 16:55:05.566 0 0 I usb 1-1 : new high-speed USB device number 5 using xhci-hcd
01-18 16:55:05.687 0 0 I usb 1-1 : New USB device found, idVendor=214b, idProduct=7000
01-18 16:55:05.687 0 0 I usb 1-1 : New USB device strings: Mfr=0, Product=1, SerialNumber=0
01-18 16:55:05.687 0 0 I usb 1-1 : Product: USB2.0 HUB
01-18 16:55:05.703 0 0 I hub 1-1 : 1.0: USB hub found
01-18 16:55:28.166 0 0 I usb 1-1.2: new full-speed USB device number 6 using xhci-hcd
01-18 16:55:28.249 0 0 I usb 1-1.2: New USB device found, idVendor=046d, idProduct=c52b
01-18 16:55:28.249 0 0 I usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
01-18 16:55:28.249 0 0 I usb 1-1.2: Product: USB Receiver
01-18 16:55:28.249 0 0 I usb 1-1.2: Manufacturer: Logitech
01-18 16:55:28.273 0 0 I logitech-djreceiver 0003: 046D:C52B.0007: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-xhci-hcd.9.auto-1.2/input2
01-18 16:55:28.386 0 0 I input : Logitech K400 as /devices/platform/usb@fe900000/fe900000.dwc3/xhci-hcd.9.auto/usb1/1-1/1-1.2/1-1.2:1.2/0003:046D:C52B.0007/0003:046D:4024.0008/input/input3
01-18 16:55:28.387 0 0 I logitech-hidpp-device 0003: 046D:4024.0008: input,hidraw1: USB HID v1.11 Keyboard [Logitech K400] on usb-xhci-hcd.9.auto-1.2:1
01-18 16:55:37.120 0 0 I usb 1-1.3: new high-speed USB device number 7 using xhci-hcd
01-18 16:55:37.200 0 0 I usb 1-1.3: New USB device found, idVendor=0bda, idProduct=8179
01-18 16:55:37.200 0 0 I usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
01-18 16:55:37.200 0 0 I usb 1-1.3: Product: 802.11n NIC
01-18 16:55:37.200 0 0 I usb 1-1.3: Manufacturer: Realtek
01-18 16:55:37.200 0 0 I usb 1-1.3: SerialNumber: 00E04C0001
The wifi dongle is identified correctly but again no way to activate the wifi (of course I got the log via ethernet but I also give a try after a reboot with ethernet disconnected).
Thanks.
Philippe
-
Hi, I'm new here, but I've been reading the forum for a while. I heard from a "Rigol enthusiast" that you can buy a generator board for a standard DHO924, and interestingly, it can even be a 2-channel generator. Is this true?
-
it can even be a 2-channel generator. Is this true?
As far I know, nobody hacked FPGA firmware yet, so no.
Only one thing what You can hack is the maximum frequency from 25 MHz to 50 MHz with little lower amplitude.
-
This is the list of the usb driver I found into /sys/bus/usb :
MOSCHIP usb-ethernet driver
aiptek
asix
ax88179_178a
catc
cdc_acm
cdc_eem
cdc_ether
cdc_mbim
cdc_ncm
cdc_subset
cdc_wdm
ch341
cp210x
cx82310_eth
dm9601
ftdi_sio
gl620a
gtco
hanwang
hso
hub
int51x1
ipheth
kalmia
kaweth
kbtab
net1080
option
oti6858
pegasus
pl2303
plusb
qcserial
qmi_wwan
r8152
rndis_host
rtk_btusb
rtl8150
sierra
sierra_net
smsc75xx
smsc95xx
snd-usb-audio
trancevibrator
uas
ums-alauda
ums-cypress
ums-datafab
ums-freecom
ums-isd200
ums-jumpshot
ums-karma
ums-onetouch
ums-sddr09
ums-sddr55
ums-usbat
ums_eneub6250
usb
usb-storage
usb_acecad
usbfs
usbhid
usbserial
usbserial_generic
usbtmc
uvcvideo
xpad
zaurus
As you can see none are related to wifi so I have to forgot, no solution at all... I can only use
wired network !
I am curious to see the same list (adb shell ls /sys/bus/*/drivers) for a DHO804 where RTL8188EUS dongle is working.
Philippe
-
From an MHO98, if this helps:
/sys/bus/usb/drivers:
MOSCHIP usb-ethernet driver
aiptek
asix
ax88179_178a
catc
cdc_acm
cdc_eem
cdc_ether
cdc_mbim
cdc_ncm
cdc_subset
cdc_wdm
ch341
cp210x
cx82310_eth
dm9601
ftdi_sio
gl620a
gtco
hanwang
hso
hub
int51x1
ipheth
kalmia
kaweth
kbtab
net1080
option
oti6858
pegasus
pl2303
plusb
qcserial
qmi_wwan
r8152
rndis_host
rtk_btusb
rtl8150
rtl8821cu
sierra
sierra_net
smsc75xx
smsc95xx
snd-usb-audio
trancevibrator
uas
ums-alauda
ums-cypress
ums-datafab
ums-freecom
ums-isd200
ums-jumpshot
ums-karma
ums-onetouch
ums-sddr09
ums-sddr55
ums-usbat
ums_eneub6250
usb
usb-storage
usb_acecad
usbfs
usbhid
usbserial
usbserial_generic
uvcvideo
xpad
zaurus
-
I am trying to create a new SD Card using the image downloaded from the 1st post in this topic.
Should the SD card be s specific size?
Should the SD card be formatted with a specific partition type?
Specific label name?
On macOS I am using BalenaEtcher, any specific instructions to write it with?
All help appreciated.
André
-
I am trying to create a new SD Card using the image downloaded from the 1st post in this topic.
Should the SD card be s specific size?
The one inside the 'scope is 32Gb
-
That I have, but seems the file format at the link is proprietary to the HDD RAW Copy utility, and this is not available on macOS/ARM64
-
This is the references of the main board of the scope.
[attachimg=1]
I am wondering if its possible to get a sector backup (dd ?) of the sd board from somebody else having the same board AND that use a RTL8188EUS dongle, then prepare a sd here and give it a try ?
Thanks.
Philippe
-
Just put the WiFi dongle in, power it on, and send this over Ethernet using ADB:
adb shell am start -a android.settings.WIFI_SETTINGS
No need for USB hub or keyboard or anything else.
Note: The dongle must to be there at power-on. You can't put it in afterwards.
-
Progress !!!
You are right. By your way wifi is activated and I can go to the point where I must put the wifi access code.
How can I do that without keyboard ??? Is it possible with adb ?
Great thanks.
Philippe
-
Got it with :
adb shell input text "wifi_code"
after set the focus on the corresponding field on the scope.
Connected now ! Hourra !!!
-
Progress !!!
You are right. By your way wifi is activated and I can go to the point where I must put the wifi access code.
How can I do that without keyboard ??? Is it possible with adb ?
Great thanks.
Philippe
IIRC, you can use a USB hub.
-
This is the list of the usb driver I found into /sys/bus/usb :
As you can see none are related to wifi so I have to forgot, no solution at all... I can only use
wired network !
I am curious to see the same list (adb shell ls /sys/bus/*/drivers) for a DHO804 where RTL8188EUS dongle is working.
Philippe
The kernel itself has support for usb wifi.
The usb wifi dongle that works has been well documented already. I think it's a $10 item.
-
Now I can do a short abstract on how I get my wifi dongle working on a DHO804 :
Remove all <> surrounding adb command !
For installing adb see other message in this thread.
- connect ethernet on the scope and get an ip
- power off the scope
- install the TPLink TL-WN725N (running a RTL8188EUS) into the scope front usb socket (dont use an usb hub)
- power on the scope and wait boot end
- on a linux or windows computer connected to the same network do <adb connect scope_ip:55555> you should get the connected message
- do : <adb shell am start -a android.settings.WIFI_SETTINGS> this will put the wifi settings window on scope screen
- select the network and then the scope should ask the wifi key
- on the scope set focus into the text zone where the wifi key should be entered
- on the computer do <adb shell input text "your_wifi_code"> this will fill the text zone on the scope
- do "ok" on the scope then the wifi should connect
- on the computer do <adb shell input keyevent 111> (send ESC code) this will close the wifi settings window on the scope
- power off the scope, disconnect ethernet, restart and enjoy wifi !!!
All my problems must be related to a cheap/buggy usb hub. By this way you dont need keyboard nor usb hub.
Thanks to all here that have try to help.
Philippe
-
I'm looking to finally replace my budget really old DSO Nano V2 that actually has served me ok for what ive done with it. Now I have outgrown it and thought of replacing it finally.
Ive been looking at 100 and 200Mhz Oscilloscopes.
Siglent and Rigol is two brand ive been looking at.
I know that there was a model of Rigol that came with 50Mhz that Rigol offered free upgrade to. I think there was a couple of upgrades for that. 50 to 100Mhz for example.
Nice to have a higher bandwidth and resolution than ive currently have.
Is this Rigol DHO800/900 Scope currently worth buying? Or do I have any other alternatives 100-200Mhz oscilloscopes that not brake the bank.
Would say 500 Euro budget.
Prices may vary of course depending where you find one.
-
Is this Rigol DHO800/900 Scope currently worth buying?
The 800 is, the 900 isn't.
You can buy the cheapest one and turn it into any other model with a simple command over Ethernet. The hardware is identical on all models.
-
You can buy the cheapest one and turn it into any other model
Correction: the cheapest of the 4-channel models. The 2-channel ones aren't worth it.
The 800 series lacks the hardware AWG and LA support, compared to 900, but I'm not sure they're worth anything, so yeah, I'll agree that the only scope worth buying (if still worth it at all today) from these series is the DHO804.
-
I wish we could add extra BNC connectors over Ethernet but I'm afraid it's not possible. :)
-
The 800 is, the 900 isn't.
Maybe for You. Some users may want LA, AFG, 350 MHz passive probes instead of 150 MHz and of course black color.
You can buy probes and add AFG and LA by yourself, but sometimes it's not worth it for the money and time needed for this. 350 MHz probes alone are expensive.
-
As you can see none are related to wifi so I have to forgot, no solution at all... I can only use
wired network !
I think You listed built-in and loaded kernel modules (drivers).
When the driver is in a separate file (at the time of compiling the kernel, You can configure what You want and how), You can load it manually with insmod.
Android itself is a very bad OS - that's why it's so problematic, maybe even more than Windows.
Try to load it with insmod - but likely this will not work. Turn on Your scope with a USB wifi already connected - preferably without the USB hub.
I am trying to create a new SD Card using the image downloaded from the 1st post in this topic.
Should the SD card be s specific size?
The one inside the 'scope is 32Gb
The capacity of the SD card (blocks with 512 bytes) must be at least with the size of the image. There is no problem when SD card is bigger - unless there are other reasons like a different communication, voltages, etc.
Speaking about the voltages, SD card doesn't work with the constant voltage. In the worst case scenario, CPU will be not able to read bootloader from it.
There are methods of shrinking SD card images, but I don't want to write a book here.
That I have, but seems the file format at the link is proprietary to the HDD RAW Copy utility, and this is not available on macOS/ARM64
Not at all. I never used "HDD RAW Copy utility" and I don't have Windows. I already confirmed those files being as a real raw binary images of a SD card.
On the Linux I don't need any special software to flash SD card with files from Dave.
-
The 800 is, the 900 isn't.
Maybe for You. Some users may want LA, AFG, 350 MHz passive probes instead of 150 MHz and of course black color.
You can buy probes and add AFG and LA by yourself, but sometimes it's not worth it for the money and time needed for this. 350 MHz probes alone are expensive.
The new MHO900 does all of that way better. The FFT and Bode plot are much improved, too.
The DHO900 has severe sample rate limitations.
-
The DHO900 has severe sample rate limitations.
DHO800/900 LA can work up to 1.25 GSa/s. Right now Im not sure about memory depth limitations in MHO900 with LA.
Sample memory times sample time is only slightly better with MHO900.
-
Right now Im not sure about memory depth limitations in MHO900 with LA.
Looks like the LA on the MHO900 samples with 1GSa/s and the sample memory is 125MPts
-
Right now Im not sure about memory depth limitations in MHO900 with LA.
Looks like the LA on the MHO900 samples with 1GSa/s and the sample memory is 125MPts
DHO800/900 FPGA allows no more than 31.25 Mpts. But still there is 25% faster LA sample rate :)
-
Testing the full screen bar scrolling in side to side mode
https://www.reddit.com/r/ElectronicsNews/comments/1p836hq/dho804_testing_the_scrolling_of_the_fullscreen_bar/ (https://www.reddit.com/r/ElectronicsNews/comments/1p836hq/dho804_testing_the_scrolling_of_the_fullscreen_bar/)
-
Reddit moderators are becoming increasingly unreasonable. They're now banning me from one site just because they don't like something I posted on another.
[attach=1]
-
Reddit moderators are becoming increasingly unreasonable. They're now banning me from one site just because they don't like something I posted on another.
Let me answer this from my perspective.
No matter if somebody likes this or not, but we both are doing some software. Some of it may be for Rigol devices and some of this some, may be not free of charge, which is the case here, but it doesn't matter.
Rigol makes quite good hardware for the price, but the firmware is a crap.
Lately Rigol started selling MHO900 series (I think MHO98 is included in it) and they added small and simple change to "protect" it from unlocking options like a higher bandwidth, memory depth and other things. I breached it in one day, without having any scope from this series and users of MHO934 can use 1 GHz bandwidth without paying 480$. They have two AFG which they already payed for, but Rigol locked it and required to pay "just" 800$ to flip a one bit and make possible to use it.
I breached it, not because Im good or something. But rather because their coders are bad (or cheap if You prefer).
Yesterday I received email from one of my MHO900 mod users. Along the things he said: "few owners of MHO98 being the influencers" (shortened quote).
When they did DHO800/900 firmware, it was a copy od DHO4000 firmware with some changes. Why they disabled a lot of triggers, decoders, UPA and other things? Because they want from You to buy DHO4000 or other very expensive model, just to have one stupid thing in the firmware. Some users maybe will prefer to have small portable scope with those things, even with paying the price for DHO4000, but Rigol doesn't give a f*ck.
Some weeks ago, on this exact forum there was some people accusing me of doing "illegal" things against Rigol company and it was like hurting their feelings, because some "innocent" company from China with small revenue of 23.2 M was going to get broke.
Jokes aside, fighting with it works just like a Streisand effect, which means it's completely opposite result - it's very bad for the company reputation. Funny thing, all accusations from all of them just stopped in the same day - it can mean only one thing: Rigol payed for this.
On this forum there is a lot of people and only one moderator. There was a war and a lot of insults from those people, but this one mod banned me (muted if You like) for one week and nobody else. Coincidence?
Not longer than 10 h ago I got permanent ban on this subreddit too. Coincidence?
Still I have no reply from the mod and I guess both of us will never receive any reply from them. Rigol payed good enough money. I guess 100$ was enough.
[attach=1]
As You can see, I added my posts before this rule was added. They added this rule and my post was deleted. Why they banned me month later? Money from Rigol of course. Some people will do such things for money like 100$, because it's not more than 5 minutes and they feel safe. You will never know neither real name of the mod or even nickname.
Most of the subreddits has a random people as a mod. You can be banned anytime, not because You breaked any rule, but because one person had some interest in it, even purely emotional. Which happened to me once on other not technical subreddit. On the side note, Reddit become much worse for different reasons lately (I heard something about new CEO).
PS. Few months ago Rigol did one change in the SD card for DHO800/900. For 99% it was done to prevent from installing OS modifications. My mod (scripts) was not only installing modified app but also doing changes in OS mostly to increase performance and to add features like a easy access to Android desktop. People reported this problem and it was extremely easy to fix it remotely. Now I automated it in the scripts, so it will not fail, no matter if this is old one or a newer one.
-
Aside the attacks from the Rigol, I have plans to add more bandwidth filters in my mod (binary AFE flags from other models with same exact AFE chip) and to correct existing ones (displayed bandwidth value in the UI).
About the last thing, filter 70 MHz is sending the same AFE flags as in the DHO804, but in the reality it does first order filter (RC filter) with -3 dB at around 100-110 MHz. This 30% difference can be at least annoying.
Those filters are 200 MHz, 250 MHz, 300 MHz, 350 MHz, 400 MHz (maybe...), and 500 MHz. If I will got some luck, I will manually find flags to enable some more - once I did one filter in that way.
As (almost) always, it will be a free update.
-
...Rigol payed good enough money. I guess 100$ was enough...
It's unbelievable and very sad. At the very least, they should purchase our modifications to copy the fixes and improvements. I think that we contribute to their hardware sales.
-
At the very least, they should purchase our modifications to copy the fixes and new implementations.
I doubt that.
Never heard about famous painter from Vienna and his friends fighting to the very end?
Sad thing, from time to time I was helping people on this subreddit. I guess it will never happen again.
-
PS. Few months ago Rigol did one change in the SD card for DHO800/900. For 99% it was done to prevent from installing OS modifications. My mod (scripts) was not only installing modified app but also doing changes in OS mostly to increase performance and to add features like a easy access to Android desktop. People reported this problem and it was extremely easy to fix it remotely. Now I automated it in the scripts, so it will not fail, no matter if this is old one or a newer one.
[/quote]
That at least explains the strange behavior of my device. It was probably manufactured in June 2025. The revert.gel doesn't work for me.
I'm now using the Scope with the original software. This works flawlessly.
PS: Mrisco's mod also doesn't work for me. The Scope hangs very early in the boot process. ADB isn't possible yet because there's no network connection. Communication with the creator was unsuccessful.
-
How to use the scope as an android tablet :)
With sound!
...
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.
Thanks for this great info. The power consumption is in my case approx. 21W before starting the rigol.scope app the first time from my launcher (Nova). With the started rigol app it takes about 38W (measured at the ac socket). But when I switch back to the launcher and kill the rigol app the power stays at about 34W. Even unloading all the modules the rigol app uses and flashing the fpga with zeros brings it back only to 32W. How is it possible to deactivate all scope relevant parts so that the power is again 21W as it was before the first start of the rigol app? Is it possible at all or can only a fresh start (power-off-reboot) bring the hardware back in a pre-rigol-app-start-state?
I am asking because I am planning to regulate the fan with a ntc and it would be nice if it would be quieter at least when the rigol scope is not running. ;-) Thanks for your feedback.
-
That at least explains the strange behavior of my device. It was probably manufactured in June 2025. The revert.gel doesn't work for me.
I don't know if I asked this before, but did You tried to use Dave SD card image? It's from one of the earliest DHO814 and it works properly on my DHO924S.
Only one problem is with AFG DC offset, which can be fixed by reverting original contents of /rigol/data which contains files with calibration data, including AFG.
I am asking because I am planning to regulate the fan with a ntc and it would be nice if it would be quieter at least when the rigol scope is not running. ;-) Thanks for your feedback.
My DHO924S was working without the fan all day long. However it was with different OS.
Nova
My mod (both .GEL and external script) installs Nova, Android soft buttons (auto hide after few seconds) and scope app is started only once after boot.
-
PS. Few months ago Rigol did one change in the SD card for DHO800/900. For 99% it was done to prevent from installing OS modifications. My mod (scripts) was not only installing modified app but also doing changes in OS mostly to increase performance and to add features like a easy access to Android desktop. People reported this problem and it was extremely easy to fix it remotely. Now I automated it in the scripts, so it will not fail, no matter if this is old one or a newer one.
maybe that will explain why in my scope with mod v0.4.2 i lost easy access to Android desktop.
gesture swipe on right screen side is not working, when enable permanent nav bar on bottom
through Settings->Accessability then no reaction on triangle button -> scope app is in god mode.
the NovaLauncher is correctly installed.
but as i remember that was not a case for few first versions installed.
can u share some details? otherwise i'm in need to revert to factory image.
br/Piotr
-
gesture swipe on right screen side is not working
It was always swipe from the top corner to bottom.
It's purely Android code.
BTW. In my mod there is a third party replacement for this, which You can enable manually. It's has a lot of settings and it seems to have less bugs with basic things. Screenshot in the attachment.
If for some reason You still can't get into Nova launcher (Android desktop), connect USB keyboard, ALT+TAB and swipe out the scope app.
-
ADB isn't possible yet because there's no network connection. Communication with the creator was unsuccessful.
You don't have ADB with the original software?
That could suggest a different kind of problem.
-
gesture swipe on right screen side is not working
It was always swipe from the top corner to bottom. It's purely Android code.
nothing like this is working for me. the only corner swipe i spot some reaction is right bottom one.
the difference from no-reaction is i can see some blue'ish hue at bottom, approximately 1/5 of lenght,
aligned right.
BTW. In my mod there is a third party replacement for this, which You can enable manually. It's has a lot of settings and it seems to have less bugs with basic things. Screenshot in the attachment.
i've also tried to disabled it, not change.
If for some reason You still can't get into Nova launcher (Android desktop), connect USB keyboard, ALT+TAB and swipe out the scope app.
the only key combination which works in that "god mode" is Win+n what triggers notification bar from top.
other than that no any std key shortcut works.
the only way to get into launcher is to kill the scope app either via adb or Settings->Apps.
what is interesting, when finally in launcher or any other app than scope, the navbar is visible, however the only key which works is triangle (back), other 2 have no action - dead (circle, square). so after starting any app going back to launcher is again problematic.
when logcat enabled, whenever i press not working nav button i got this sinny set of traces related to audioDevice:
11-28 17:11:21.815 649 649 W TelecomManager: Telecom Service not found.
11-28 17:11:21.821 240 284 D AudioHardwareTiny: start_output_stream device: 2
11-28 17:11:21.821 240 284 D AudioHardwareTiny: card0 id:rockchipes8323
11-28 17:11:21.821 240 284 D AudioHardwareTiny: No exist proc/asound/card1/id, break and finish parsing
11-28 17:11:21.821 240 284 D AudioHardwareTiny: dump out device info
11-28 17:11:21.821 240 284 D AudioHardwareTiny: dev_info SPEAKER card=0, device:0
11-28 17:11:21.821 240 284 D AudioHardwareTiny: dev_info HDMI card=0, device:0
11-28 17:11:21.822 240 284 D AudioHardwareTiny: dev_info SPDIF card=0, device:0
11-28 17:11:21.822 240 284 D AudioHardwareTiny: dev_info BT card=0, device:0
11-28 17:11:21.822 240 284 D alsa_route: route_info->sound_card 0, route_info->devices 0
11-28 17:11:21.822 240 284 D alsa_route: route_set_controls() set route 0
11-28 17:11:21.978 552 605 I WindowManager: Not starting activity because user setup is in progress: Intent { act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 (has extras) }
11-28 17:11:24.925 240 284 D AudioHardwareTiny: do_out_standby,out = 0xea9da180,device = 0x2
11-28 17:11:24.926 240 284 D alsa_route: route_set_controls() set route 24
11-28 17:11:24.926 240 284 D AudioHardwareTiny: close device
11-28 17:11:51.948 240 284 D AudioHardwareTiny: start_output_stream device: 2
11-28 17:11:51.948 240 284 D AudioHardwareTiny: card0 id:rockchipes8323
11-28 17:11:51.948 240 284 D AudioHardwareTiny: No exist proc/asound/card1/id, break and finish parsing
11-28 17:11:51.948 240 284 D AudioHardwareTiny: dump out device info
11-28 17:11:51.948 240 284 D AudioHardwareTiny: dev_info SPEAKER card=0, device:0
11-28 17:11:51.948 240 284 D AudioHardwareTiny: dev_info HDMI card=0, device:0
11-28 17:11:51.948 240 284 D AudioHardwareTiny: dev_info SPDIF card=0, device:0
11-28 17:11:51.948 240 284 D AudioHardwareTiny: dev_info BT card=0, device:0
11-28 17:11:51.949 240 284 D alsa_route: route_info->sound_card 0, route_info->devices 0
11-28 17:11:51.949 240 284 D alsa_route: route_set_controls() set route 0
11-28 17:11:55.073 240 284 D AudioHardwareTiny: do_out_standby,out = 0xea9da180,device = 0x2
11-28 17:11:55.073 240 284 D alsa_route: route_set_controls() set route 24
11-28 17:11:55.073 240 284 D AudioHardwareTiny: close device
seems like most important for it is to play some sound on scope.
my userspace apps list:
AnySoftKeyboard
Calculator++
DuckDuckGo
Explorer
launcher
Lightning
NovaLauncher
RIGOL.SCOPE
Settings
webcontrol
rk3399_rigol:/ # ll /data/app
total 18
drwxrwx--x 9 system system 1024 2025-11-28 17:16 .
drwxrwx--x 43 system system 1024 2025-11-28 16:33 ..
drwxr-xr-x 4 system system 1024 2025-10-27 20:23 com.duckduckgo.mobile.android-2
drwxr-xr-x 4 system system 1024 2025-10-27 20:23 com.menny.android.anysoftkeyboard-2
drwxr-xr-x 4 system system 1024 2025-10-27 20:23 com.rigol.launcher-2
drwxr-xr-x 4 system system 1024 2025-10-27 20:23 com.rigol.scope-2
drwxr-xr-x 4 system system 1024 2013-01-18 08:51 com.rigol.webcontrol-1
drwxr-xr-x 4 system system 1024 2025-10-27 20:23 com.teslacoilsw.launcher-2
drwxr-xr-x 4 system system 1024 2025-10-27 20:23 org.solovyev.android.calculator-2
rk3399_rigol:/ # ll /data/user/0/
total 178
drwxrwx--x 55 system system 3072 2025-11-28 17:16 .
drwxrwx--x 43 system system 1024 2025-11-28 16:33 ..
drwx------ 11 u0_a23 u0_a23 1024 2025-11-28 17:33 acr.browser.barebones
drwx------ 4 system system 1024 2013-01-18 08:50 android
drwx------ 4 u0_a5 u0_a5 1024 2013-01-18 08:50 android.ext.services
drwx------ 4 u0_a21 u0_a21 1024 2013-01-18 08:50 android.ext.shared
drwx------ 5 system system 1024 2025-09-30 20:06 android.rockchip.update.service
drwxr-x--x 4 u0_a28 u0_a28 1024 2025-09-30 19:06 com.ampak.rftesttool
drwx------ 4 u0_a0 u0_a0 1024 2025-09-30 19:06 com.android.backupconfirm
drwx------ 4 bluetooth bluetooth 1024 2025-11-28 17:33 com.android.bluetooth
drwx------ 4 u0_a18 u0_a18 1024 2025-09-30 19:06 com.android.captiveportallogin
drwx------ 4 u0_a19 u0_a19 1024 2025-09-30 19:06 com.android.certinstaller
drwx------ 4 u0_a20 u0_a20 1024 2025-09-30 19:06 com.android.cts.ctsshim
drwx------ 4 u0_a2 u0_a2 1024 2025-09-30 19:06 com.android.cts.priv.ctsshim
drwx------ 4 u0_a3 u0_a3 1024 2013-01-18 08:50 com.android.defcontainer
drwx------ 4 u0_a17 u0_a17 1024 2025-09-30 19:06 com.android.dreams.basic
drwx------ 4 u0_a6 u0_a6 1024 2025-09-30 19:06 com.android.externalstorage
drwxr-x--x 4 u0_a22 u0_a22 1024 2025-09-30 19:06 com.android.htmlviewer
drwx------ 4 system system 1024 2013-01-18 08:50 com.android.inputdevices
drwx------ 5 system system 1024 2025-10-27 20:23 com.android.keychain
drwx------ 4 system system 1024 2013-01-18 08:50 com.android.location.fused
drwx------ 5 u0_a7 u0_a7 1024 2025-09-30 20:06 com.android.managedprovisioning
drwx------ 5 u0_a4 u0_a4 1024 2025-11-24 13:13 com.android.mtp
drwx------ 4 u0_a8 u0_a8 1024 2013-01-18 08:50 com.android.packageinstaller
drwx------ 4 u0_a24 u0_a24 1024 2025-09-30 19:06 com.android.pacprocessor
drwx------ 4 u0_a26 u0_a26 1024 2025-09-30 19:06 com.android.printservice.recommendation
drwx------ 6 u0_a27 u0_a27 1024 2025-09-30 19:06 com.android.printspooler
drwx------ 4 u0_a1 u0_a1 1024 2013-01-18 08:50 com.android.providers.blockednumber
drwx------ 5 u0_a4 u0_a4 1024 2025-09-30 20:06 com.android.providers.downloads
drwx------ 6 u0_a4 u0_a4 1024 2025-09-30 20:06 com.android.providers.media
drwx------ 4 system system 1024 2013-01-18 08:50 com.android.providers.settings
drwx------ 5 u0_a1 u0_a1 1024 2013-01-18 08:52 com.android.providers.userdictionary
drwx------ 4 u0_a9 u0_a9 1024 2025-09-30 19:06 com.android.provision
drwx------ 4 u0_a10 u0_a10 1024 2013-01-18 08:50 com.android.proxyhandler
drwx------ 4 u0_a11 u0_a11 1024 2025-09-30 19:06 com.android.retaildemo
drwxr-x--x 4 system system 1024 2025-09-30 19:06 com.android.rk
drwx------ 4 system system 1024 2013-01-18 08:50 com.android.settings
drwx------ 4 u0_a12 u0_a12 1024 2025-09-30 19:06 com.android.sharedstoragebackup
drwx------ 4 shell shell 1024 2013-01-18 08:50 com.android.shell
drwx------ 4 u0_a29 u0_a29 1024 2025-09-30 19:06 com.android.smspush
drwx------ 4 u0_a13 u0_a13 1024 2025-09-30 19:06 com.android.statementservice
drwx------ 4 u0_a14 u0_a14 1024 2025-09-30 19:06 com.android.storagemanager
drwx------ 4 u0_a15 u0_a15 1024 2013-01-18 08:50 com.android.systemui
drwx------ 4 system system 1024 2025-09-30 19:06 com.android.wallpaperbackup
drwx------ 4 u0_a16 u0_a16 1024 2025-09-30 19:06 com.android.wallpapercropper
drwxr-x--x 4 u0_a30 u0_a30 1024 2025-09-30 19:06 com.android.wallpaperpicker
drwx------ 4 u0_a31 u0_a31 1024 2025-09-30 19:06 com.android.webview
drwx------ 10 u0_a32 u0_a32 1024 2025-11-28 16:48 com.duckduckgo.mobile.android
drwx------ 7 u0_a37 u0_a37 1024 2025-10-28 14:04 com.menny.android.anysoftkeyboard
drwx------ 6 system system 1024 2025-09-30 20:06 com.rigol.launcher
drwx------ 6 system system 1024 2025-09-30 20:06 com.rigol.scope
drwx------ 6 system system 1024 2025-09-30 20:06 com.rigol.webcontrol
drwx------ 4 u0_a25 u0_a25 1024 2025-09-30 19:06 com.svox.pico
drwx------ 8 u0_a33 u0_a33 1024 2025-09-30 19:06 com.teslacoilsw.launcher
drwx------ 6 u0_a36 u0_a36 1024 2013-01-18 08:59 org.solovyev.android.calculator
as one can see factory apps have system user/group, whether the 3pp sideloaded by mod script are userspace
br/Piotr
-
In such case, instead of spending hours with figuring it out, I would chose to flash SD card back again.
Unless You don't want to remove warranty sticker, which I guess You don't have.
-
gesture swipe on right screen side is not working
It was always swipe from the top corner to bottom. It's purely Android code.
nothing like this is working for me. the only corner swipe i spot some reaction is right bottom one.
the difference from no-reaction is i can see some blue'ish hue at bottom, approximately 1/5 of lenght,
aligned right.
BTW. In my mod there is a third party replacement for this, which You can enable manually. It's has a lot of settings and it seems to have less bugs with basic things. Screenshot in the attachment.
i've also tried to disabled it, not change.
If for some reason You still can't get into Nova launcher (Android desktop), connect USB keyboard, ALT+TAB and swipe out the scope app.
the only key combination which works in that "god mode" is Win+n what triggers notification bar from top.
other than that no any std key shortcut works.
the only way to get into launcher is to kill the scope app either via adb or Settings->Apps.
I had the same issue. Today I reflashed the card with Dave's image. Then I updated to the latest version. Afterwards, I installed the NK-Mod via the .gel file. One manual restart is necessary, then everything runs automatically. After entering the license and subsequent self-calibration, everything works as expected. The swipe in the top right corner works, and all three buttons function correctly. Good work, Norbert!
-
Little boring work with some good results. I found a lot of low pass filters.
Summary from my current notes:
Filters in AFE:
- no signal (real AFE GND coupling)
- Test sin 8 MHz: 831 mV -> 448 mV (-5.3 dB)
Test sin 5 MHz: 842 mV -> 620.2 mV (-2.66 dB)
5 MHz - Test sin 10 MHz: 826 mV -> 639.5 mV (-2.21 dB)
Test sin 12 MHz: 798 mV -> 535 mV
12 MHz - Test sin 16 MHz: 777 mV -> 568 mV
Test sin 17 MHz: 780 mV -> 553 mV
Test sin 20 MHz: 821 mV -> 523 mV
~16 MHz - 19.8 ns (18 MHz 23 MHz)
Test sin 16 MHz: 777 mV -> 646 mV
Test sin 18 MHz: 805.3 mV -> 635 mV
Test sin 20 MHz: 821 mV -> 598 mV
Test sin 21 MHz: 760 mV -> 603 mV
Test sin 25 MHz: 941 mV -> 609 mV
~23 MHz - 15.8 ns (22 MHz 28.5 MHz)
Test sin 18 MHz: 805.3 mV -> 695 mV
Test sin 22 MHz: 762 mV -> 673 mV
Test sin 30 MHz: 742 mV -> 520 mV
30 MHz
(used as a 20 MHz in stock app together with SPU filter enabled) - 11.3 ns (31 MHz 40 MHz)
Test sin 40 MHz: 718 mV -> 516 mV
40 MHz - 10 ns (35 MHz 45 MHz)
Test sin 40 MHz: 718 mV -> 551 mV
Test sin 45 MHz: 698.5 mV -> 506 mV
45 MHz - 8.8 ns (40 MHz 51 MHz)
Test sin 45 MHz: 698.5 mV -> 534 mV
Test sin 50 MHz: 669 mV -> 489 mV
50 MHz - 8 ns (44 MHz 56 MHz)
Test sin 50 MHz: 669 mV -> 512 mV
55 MHz
Filters in SPU:
- off
- used with "20 MHz" official filter -> enabled alone gives ~20 MHz cutoff.
For 99% there are more filters :phew:
Adding this to UI will be much more time consuming. Right now it's hardcoded.
-
Accidentally I figured out all binary flags for AFE BW filters. At least I think so.
There are different sets of possible low pass filter(s) settings. Few thousand possible settings in total.
It's possible to calculate theoretical cutoff frequency from those flags. Lowest possible cutoff frequency is 5 MHz.
What was most interesting for me personally, was "OFF" setting. There is a "small" difference between firmware for DHO800/900 and firmware for MHO900/MHO98. Same AFE but different flags for the exact same setting.
"OFF" in MHO900 exactly as I expected is just a little bit above 1 GHz (max official bandwidth of this series is 1 GHz). When OFF and 50 ohm impedance is selected in MHO98, it send flags for 1350 MHz.
While "OFF" in DHO800/900 is... 3150 MHz. Of course this is a theoretical bandwidth, because the whole analog path is a low pass filter. Beside of the low sample rate (~2.1 GSa/s after overclocking) and LC filters on PCB, which BTW can be removed or replaced.
I think Rigol will "like" me much more than in the last few weeks.
-
...Rigol payed good enough money. I guess 100$ was enough...
It's unbelievable and very sad. At the very least, they should purchase our modifications to copy the fixes and improvements. I think that we contribute to their hardware sales.
Lies! Lies! Lies! Completely false! Neither Rigol nor any manufacturer pays to remove posts or ban users who engage in cracking/hacking activities. Administrators usually receive notifications about the laws they are violating and the consequences of continuing to allow such acts through the platform. They usually remove the offender to maintain the platform, which took a lot of work to create. Therefore, Norbert, it's not worth spreading lies just to play the victim. Keep cracking; the only one who might be harmed is the owner of this forum.
As for the software you're cracking, it's normal that it has many bugs because it's a beta version, dumped from the BETA unit sent to Dave, so it's an unfinished version. What you're selling is a beta version with improvements that no one has yet confirmed work well.
And to conclude, you must think that Rigol's engineers are all ignorant fools who don't know how to do their job, right? So, you believe in Santa Claus, do you?
Norbert, since you're a guru of wisdom, why don't you make a Sparrow app from scratch? I'd love to see that.
Rigol, you should fire all the dumb engineers working for you and hire only Norbert; he's the real guru who would make your products unique, bug-free, with extra backdoors for worldwide access. Perfect work of art!
-
Lies! Lies! Lies!
Kid, please go scream at your mommy.
As has been made clear to you previously, no one else is interested in your insults and tantrums, nor your constant attempts to derail technical threads.
-
...Rigol payed good enough money. I guess 100$ was enough...
It's unbelievable and very sad. At the very least, they should purchase our modifications to copy the fixes and improvements. I think that we contribute to their hardware sales.
Lies! Lies! Lies! Completely false! Neither Rigol nor any manufacturer pays to remove posts or ban users who engage in cracking/hacking activities. Administrators usually receive notifications about the laws they are violating and the consequences of continuing to allow such acts through the platform. They usually remove the offender to maintain the platform, which took a lot of work to create. Therefore, Norbert, it's not worth spreading lies just to play the victim. Keep cracking; the only one who might be harmed is the owner of this forum.
As for the software you're cracking, it's normal that it has many bugs because it's a beta version, dumped from the BETA unit sent to Dave, so it's an unfinished version. What you're selling is a beta version with improvements that no one has yet confirmed work well.
And to conclude, you must think that Rigol's engineers are all ignorant fools who don't know how to do their job, right? So, you believe in Santa Claus, do you?
Norbert, since you're a guru of wisdom, why don't you make a Sparrow app from scratch? I'd love to see that.
Rigol, you should fire all the dumb engineers working for you and hire only Norbert; he's the real guru who would make your products unique, bug-free, with extra backdoors for worldwide access. Perfect work of art!
:-- :rant:
Reported for ban for constantly cluttering threads. Take a break from the forum.
-
...Rigol payed good enough money. I guess 100$ was enough...
It's unbelievable and very sad. At the very least, they should purchase our modifications to copy the fixes and improvements. I think that we contribute to their hardware sales.
Lies! Lies! Lies! Completely false! Neither Rigol nor any manufacturer pays to remove posts or ban users who engage in cracking/hacking activities. Administrators usually receive notifications about the laws they are violating and the consequences of continuing to allow such acts through the platform. They usually remove the offender to maintain the platform, which took a lot of work to create. Therefore, Norbert, it's not worth spreading lies just to play the victim. Keep cracking; the only one who might be harmed is the owner of this forum.
As for the software you're cracking, it's normal that it has many bugs because it's a beta version, dumped from the BETA unit sent to Dave, so it's an unfinished version. What you're selling is a beta version with improvements that no one has yet confirmed work well.
And to conclude, you must think that Rigol's engineers are all ignorant fools who don't know how to do their job, right? So, you believe in Santa Claus, do you?
Norbert, since you're a guru of wisdom, why don't you make a Sparrow app from scratch? I'd love to see that.
Rigol, you should fire all the dumb engineers working for you and hire only Norbert; he's the real guru who would make your products unique, bug-free, with extra backdoors for worldwide access. Perfect work of art!
:-- :rant:
Reported for ban for constantly cluttering threads. Take a break from the forum.
Not constantly, just those with explicitly ilegal content or lies on it.
But be my guest snitch it
-
Reported for ban for constantly cluttering threads. Take a break from the forum.
Moderation on this forum is practically non existent and likely biased by number of reports, without reading anything. Instead we have internet trolls funded by Rigol.
It's better to ignore them. It's a waste of time - they make very good advertisement for this projects. Perfect example of Streisand effect.
Speaking of the project, right now Im working on the new UI bandwidth selection. Exactly 48 options of a bandwidth filtering in AFE. I think it should be ready in 1-2 days max.
-
Coming back to insane amount of possible low pass settings in AFE, I did two tests with same exact square wave generator with fast rise time and with overclocked PLL (2 GSa/a).
At first I measured rise time on unmodified CH2 with 50 ohm terminator and with BNC T-connector. Rise time was 1.475 ns (2.36 divided by 1.6, because the app doesn't "know" real sample rate).
After that I switched this generator to CH4 which has bypassed LC filters, changed termination resistors (between AFE and ADC) and added 50 ohm termination directly to the BNC joints on PCB.
On this CH4 I selected filter in AFE with rise time 1.5 ns, which is close enough.
After this and few other experiments, it looks like AFE filter(s) is doing much better job than original LC filters on scope PCB.
Screenshot is in the attachment below. Red line is a reference saved from mentioned CH2. Interpolation is sinc in both cases.
PS. AFE filter flags was hardcoded, so please ignore the bottom bar.
-
Speaking of the project, right now Im working on the new UI bandwidth selection. Exactly 48 options of a bandwidth filtering in AFE. I think it should be ready in 1-2 days max.
I apologize to those using the topic for deviating from the main thread. :-BROKE
These "experiments" are opening up new possibilities, which is good because I just let myself in on DHO804. It'll probably end up under "Your Software."
:palm: For now, it's in quarantine... but here, only in Polish, so as not to offend readers: "Jebie z niego jak od żula po tygodniówce :wtf:|O ".
:-BROKE I haven't smelled such a concentrated stench of burnt plastic in a long time. The whole apartment is filled with the stench.
-
Reported for ban for constantly cluttering threads. Take a break from the forum.
Speaking of the project, right now Im working on the new UI bandwidth selection. Exactly 48 options of a bandwidth filtering in AFE. I think it should be ready in 1-2 days max.
I apologize to those using the topic for deviating from the main thread. :-BROKE
These "experiments" are opening up new possibilities, which is good because I just let myself in on DHO804. It'll probably end up under "Your Software."
:palm: For now, it's in quarantine... but here, only in Polish, so as not to offend readers: "Jebie z niego jak od żula po tygodniówce :wtf:|O ".
:-BROKE I haven't smelled such a concentrated stench of burnt plastic in a long time. The whole apartment is filled with the stench.
Everybody got to do their job right?
Regarding your dho804 don't let it in the box, keep it turn on in a well ventilated room, otherwise the smell will continue for quite some time. Besides, from experience, those who release a really strong intense smell will fall soon, so leave it turned on the longer you can, if it fails you claim the warranty, got it? some lots come out defective.
-
Little bit more work to do. I need to correct some of those BW filter settings, small failsafe for about 0.5 % users and it will be ready for all possible complaints :)
-
Are they still using smelly plastic? :wtf:
It will go away. I left mine powered on in a closed room for a week when I first got it. The power keeps it warm.
-
I never had such issue with my DHO924S. Maybe DHO800 has cheaper plastic.
-
ciao norbert.kiszka
I accidentally activated the SENT protocol decode function, and the oscilloscope rebooted.
I’m using a DHO812.
I would like to ask if there is any possibility to add a custom protocol decode feature.
I was analyzing the signal from a LED strip with WS2812 chips.
I tried using the UART decoder, but the decoding is not always accurate.
Sometimes it works, sometimes it doesn’t.
Is there any way to improve this or add a custom decoder?
-
I was analyzing the signal from a LED strip with WS2812 chips.
I tried using the UART decoder, but the decoding is not always accurate.
UART won't work at all.
WS2812 doesn't have a start bit and the data uses pulse width to distinguish 1 from 0, not voltage level.
-
Ciao.
SENT protocol decode function
This is one of the "hidden" decoders from DHO4000 (Rigol did DHO800/900 firmware by using code from DHO4000). I only "unhidden" it. Those decoders, which are not in the stock app menu, may work or not so much - I never tested any of it - just as it's described in the changelog.
SENT protocol decode function, and the oscilloscope rebooted.
It shouldn't happen, because those decoders may be somewhat incomplete in the code, but likely there is no any code requesting reboot in decoders - because there is no need for reboot in doing decoding. It may be caused by other things, like a bug in Android (which has a lot of bugs) or hardware bug in CPU (this one is rare but it happens).
I would like to ask if there is any possibility to add a custom protocol decode feature.
Is there any way to improve this or add a custom decoder?
Without original source code it's very difficult.
I started making completely new app (with some parts from stock one) working on a completely different operating system (Debian), but I paused doing it, because society support for it is currently too small. I have in plans to make API for open source GUI, decoders and other things. Anyway, likely this is will not happen in this year, because it requires a lot of work.
I tried using the UART decoder, but the decoding is not always accurate.
Sometimes it works, sometimes it doesn’t.
I will take a look into that after releasing my current work with new bandwidth settings. If this is a bug caused by me, likely I will be able to fix it. Otherwise, if this is Rigol bug, debugging it may be a nightmare, which may take moths of work. It will be better to spent this time with making new app almost from scratch.
-
I have a couple of questions about the 0.7.0 update (normal, not system) on a Rigol 804 with 1.4 firmware (shipped with 1.3). I purchased and installed this version of the Sparrow upgrade to it, and I love what I am seeing! I sincerely appreciate all the hard work the author put into this for us to benefit from. It really makes it a far better scope. I'll keep this short on the questions:
1. I don't see the additional BW option - still shows just [OFF] and [20M]. Is that normal for some scopes?
2. The DHO Actions menu says that it can't load actions for some reason when tapped.
3. Is the logic analyzer unlocked in case one wishes to add the header for it?
4. Is there any benefit to changing the model number to 924? I think I recall that here is not, but less than 100% sure.
Thanks in advance for any answers I may receive!! Hopefully, I didn't miss any answers already given. I tried to search for them :)
-
I have a couple of questions about the 0.7.0 update (normal, not system) on a Rigol 804 with 1.4 firmware (shipped with 1.3). I purchased and installed this version of the Sparrow upgrade to it, and I love what I am seeing! I sincerely appreciate all the hard work the author put into this for us to benefit from. It really makes it a far better scope. I'll keep this short on the questions:
1. I don't see the additional BW option - still shows just [OFF] and [20M]. Is that normal for some scopes?
2. The DHO Actions menu says that it can't load actions for some reason when tapped.
3. Is the logic analyzer unlocked in case one wishes to add the header for it?
4. Is there any benefit to changing the model number to 924? I think I recall that here is not, but less than 100% sure.
Thanks in advance for any answers I may receive!! Hopefully, I didn't miss any answers already given. I tried to search for them :)
There are three people doing three (four actually) mods. Which one You have in mind?
-
I apologize for not being more clear. As you can see, I am new to the community (but super excited to have found it!). I didn't realize there were multiple efforts ongoing. The one that I purchased and installed may be found here:
https://www.patreon.com/posts/dho800-900-gui-7-141608043 (https://www.patreon.com/posts/dho800-900-gui-7-141608043)
Installed: Sparrow_Extended_v0.7.1-normal.apk (only)
I think one of the features I was referring to was perhaps only included in a previous version (Sparrow Extended home edition v0.4.2):
User-selectable AFE bandwidth filters for each channel:
- 20 Mhz
- 70 Mhz
- 100 Mhz
- 125 Mhz
- 400 Mhz
On one of my other questions, I think the issue is simply that I didn't install "DHO Actions_1.3.1.apk" (and "Webcontrol.apk" also, because I failed to see these were separate from the main .apk file. As I said, I'm a noob here, but I'm trying to learn. I am a reasonably competent RF engineer and programmer (assembly, C, C++, Python, etc), so perhaps I can be of assistance once I get my bearings!
Thank you for your response...
-
I have a couple of questions about the 0.7.0 update (normal, not system) on a Rigol 804 with 1.4 firmware (shipped with 1.3). I purchased and installed this version of the Sparrow upgrade to it, and I love what I am seeing! I sincerely appreciate all the hard work the author put into this for us to benefit from. It really makes it a far better scope. I'll keep this short on the questions:
1. I don't see the additional BW option - still shows just [OFF] and [20M]. Is that normal for some scopes?
2. The DHO Actions menu says that it can't load actions for some reason when tapped.
3. Is the logic analyzer unlocked in case one wishes to add the header for it?
4. Is there any benefit to changing the model number to 924? I think I recall that here is not, but less than 100% sure.
Thanks in advance for any answers I may receive!! Hopefully, I didn't miss any answers already given. I tried to search for them :)
Hi, If you are using the Sparrow Extended GUI, then it is my mod.
1. I did not change the input filter; it is set to either 'off' or 20 MHz. What was unlocked was the full bandwidth to 250MHz; you can see this in the following image (802 as example) :
[attach=1]
2. You can only open DHO Actions after the Rigol scope application has been loaded. You can force a reconnection between the applications by pressing and holding the [X] button in the DHO Actions panel and then reopening it.
If you are opening the DHO Actions panel from a tablet of phone, the oscilloscope should be operative and connected to the network before to run the panel application. The force connection [X] also works here.
3. Logic Analyzer (LA) is available for devices than normally have it, If you have a modded 804 with a LA then change the device series to a 924
4. You only need to change the model number if you modified the device physically. In any other case, it is unnecessary.
Regards
-
User-selectable AFE bandwidth filters for each channel:
- 20 Mhz
- 70 Mhz
- 100 Mhz
- 125 Mhz
- 400 Mhz
Such bandwidth settings (also OFF, which means full bandwidth) are available in my mod. Much more bandwidth settings (72 in total) will be in the next version - as a free update. Right now I need to make sure it will work properly with the self-cal. If everything will be ok, it will be in the next few hours.
-
Thank you both for your replies. I made the error of thinking that both products were from the same author. Now that I know, I will purchase the other one from norbert.kiszka too, so I can play with both of them!
-
If You want to have LA with sample rate 1.25 G instead of 625 M or to have more acquisition settings, You can checkout enterprise edition. Home edition is more targeted for hobbyists.
-
Thanks for all the info. I will definitely get the enterprise edition!
-
i am a reasonably competent RF engineer and programmer (assembly, C, C++, Python, etc), so perhaps I can be of assistance once I get my bearings!
Thank you for your response...
You can run Python scripts like here:
https://www.youtube.com/watch?v=2Ufc24zl8zw (https://www.youtube.com/watch?v=2Ufc24zl8zw)
Or here:
https://www.youtube.com/watch?v=7uYD2V7T-2c (https://www.youtube.com/watch?v=7uYD2V7T-2c)
-
I would like to ask if there is any possibility to add a custom protocol decode feature.
I was analyzing the signal from a LED strip with WS2812 chips.
Pipe to sigrok: https://www.eevblog.com/forum/testgear/new-sigrokpulseview-hardware-support-(siglent-sds-hd-rigol-dho800-)/ (https://www.eevblog.com/forum/testgear/new-sigrokpulseview-hardware-support-(siglent-sds-hd-rigol-dho800-)/)
Or buy a $10 USB logic analyzer and have access to this: https://sigrok.org/wiki/Protocol_decoders (https://sigrok.org/wiki/Protocol_decoders)
-
Hello, I'm currently looking into how I can hack my DHO804. I watched a few videos on YouTube, but the problem is that I already have firmware version 00.01.03, and all the instructions I found are only for version 00.01.02 and earlier. Can someone help me?
-
Hello, I'm currently looking into how I can hack my DHO804. I watched a few videos on YouTube, but the problem is that I already have firmware version 00.01.03, and all the instructions I found are only for version 00.01.02 and earlier. Can someone help me?
1. Update to v00.01.04.00.02 :
https://www.rigol.com/europe/products/oscilloscope/DHO800.html (https://www.rigol.com/europe/products/oscilloscope/DHO800.html)
https://www.rigolna.com/products/rigol-digital-oscilloscopes/dho800/ (https://www.rigolna.com/products/rigol-digital-oscilloscopes/dho800/)
2. make copy SD card (hdd raw copy tool) and on copy card (use fast sd card sandisk extreme 64/128 ) :
3. 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)
for model use dho824 (200MHz BW)
4. https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod (https://github.com/Andy-Big/Rigol-DHO800-900-Sparrow_mod)
-
Hello, I'm currently looking into how I can hack my DHO804. I watched a few videos on YouTube, but the problem is that I already have firmware version 00.01.03, and all the instructions I found are only for version 00.01.02 and earlier. Can someone help me?
It's the same for all versions.
-
I Finally Invent Something That Works!
Auto bandwidth along with the 72 possible bandwidth settings.
https://www.youtube.com/watch?v=IqssxgXBchw (https://www.youtube.com/watch?v=IqssxgXBchw)