EEVblog® Electronics Community Forum
Products => Test Equipment => Topic started by: PELL on September 21, 2025, 03:57:39 am
-
Haven't been here for a long time :), I don't browse this forum much often now.
Rigol just launch their new scope MHO98 and MHO900 series, thanks to my friend "依人如梦言如许", we now have an inside look of MHO98 :-+
-
According to my firmware analysis, the main processing chip is a rebranding FPGA from Fudan Microelectronics, part number is FM230T. They make 1:1 Xilinx compatible FPGA :popcorn:
-
大佬速度就是快
-
At least no crusty trimmers in the frontend. Interesting though that the input stages of the four channels are not totally symmetrical. It looks like 1+3 are the same and 2+4 are the same, but e.g. 1+2 differ.
-
The front-end chips, ADCs, and “CPU” are the same as in the DHO800....DHO4000(DHO800...DHO100 1 ADC, DHO4000 2 ADCs).
The two relays per channel in the front end indicate a 50-ohm input, although I cannot find any corresponding resistors.
But I hadn't found it in the DHO4000 teardown pictures either, too blind I guess.
edit correction of ADCs.
-
According to my firmware analysis, the main processing chip is a rebranding FPGA from Fudan Microelectronics, part number is FM230T. They make 1:1 Xilinx compatible FPGA :popcorn:
Fudan were blacklisted by the US a few days ago, but AFAIK that only restricts export of American equipment to them, not imports of their products. Maybe Rigol branded it just in case ;).
-
The front-end chips, ADCs, and “CPU” are the same as in the DHO800....DHO4000(DHO800 1 ADC, DHO1000 2 ADCs, DHO4000 4ADCs)
The two relays per channel in the front end indicate a 50-ohm input, although I cannot find any corresponding resistors.
But I hadn't found it in the DHO4000 teardown pictures either, too blind I guess.
Small correction: There's one ADC in the DHO1000 and two in the DHO4000. So this hardware is probably very close in performance and configuration to the DHO4000 plus the additional digital interface. Seems Rigol also included a battery-backed RTC on this board. I'm quite curious how "well" this device performs sampling-rate-wise with the digital channels enabled... ;)
-
Thanks, I´ve corrected it.
I don't know how I got the idea that the 4000 has 4 ADCs, but a glance at the picture makes it clear that there are only two:
https://www.flickr.com/photos/eevblog/52393925309/in/album-72177720302521598/ (https://www.flickr.com/photos/eevblog/52393925309/in/album-72177720302521598/)
But now help a blind man out, where did Rigol hide the 50 ohms? :D
With Siglent and Co, they are quite easy to identify because they are quite large SMD resistors and then 2x 24R9 or 25 ohms.
-
Maybe on the other side, but the resolution of that image is not high enough to be sure.
-
According to my firmware analysis, the main processing chip is a rebranding FPGA from Fudan Microelectronics, part number is FM230T. They make 1:1 Xilinx compatible FPGA :popcorn:
So it's Xilinx fallen out of a truck that went to laser engraver or true cold war style 1:1 silicone clone?
Or spec sheet clone, new design that is binary compatible?
-
Maybe on the other side, but the resolution of that image is not high enough to be sure.
I took a look at 4000 pics. There are no termination resistors on either side. It could be that front end chip is directly terminating input. That would be fun for overloads...
P.S. Took another look.
First relay chooses 50Ω or 1MΩ path.
There seem to be 2 50Ω inputs on chip, actually 2 paths that are switched by 2nd relay together with corresponding PI attenuators.
50Ω is DC coupled all the time. 1MΩ path goes to PhotoMOS and capacitor for AC/DC coupling. All range switching
for 1MΩ is solid state in frontend chip.
There are no external termination resistors. Front end chip is terminating.
-
Thank you, so I'm not blind after all, because I had searched through all the images I could find.
That would be fun for overloads...
Oh yes, instead of replacing a resistor, it's the IC's turn—a disaster for the customer. :palm:
One can only hope that Rigol has incorporated appropriate safety measures, because it is easier than one might think to “overdrive” the 50-ohm input.
Do I believe that? No...
-
According to my firmware analysis, the main processing chip is a rebranding FPGA from Fudan Microelectronics, part number is FM230T. They make 1:1 Xilinx compatible FPGA :popcorn:
So it's Xilinx fallen out of a truck that went to laser engraver or true cold war style 1:1 silicone clone?
Or spec sheet clone, new design that is binary compatible?
From a trusty source: Fudan actually got Xilinx's help when making these chip, Fudan now even has some RFSoC clone. And it's not made by TSMC!
My personal guess is: At first, Fudan was trying to reverse engineering Xilinx FPGA then sell it to defense related company in China, but the result wasn't ideal. At the same time, Xilinx also wants to sell FPGA to these companies, but due to obvious reason they can't sell it directly.
Then somehow Fudan convince Xilinx to help them build the clone chip, and now both Xilinx and Fudan make big buck of money out of this, it's basically a win-win deal from company standpoint. :popcorn:
Note: I don't want to involve politics in this topic
-
the ADC is same model with the one in DHO800, except it has 2 ADC. How is the 4GSa/s is calculated? Is it means 2G per ADC then multiple 2=4GSa/s? Does that prove that the DHO800 serials can "update" to 2GSa/s and 1G bandwidth? Is there anyone knows who has hacked the sample rate of DHO800 serials before?
-
the ADC is same model with the one in DHO800, except it has 2 ADC. How is the 4GSa/s is calculated? Is it means 2G per ADC then multiple 2=4GSa/s? Does that prove that the DHO800 serials can "update" to 2GSa/s and 1G bandwidth? Is there anyone knows who has hacked the sample rate of DHO800 serials before?
You should ask norbert.kiszka, he is currently hacking the DHO800/900 :popcorn:
-
the ADC is same model with the one in DHO800, except it has 2 ADC. How is the 4GSa/s is calculated? Is it means 2G per ADC then multiple 2=4GSa/s? Does that prove that the DHO800 serials can "update" to 2GSa/s and 1G bandwidth? Is there anyone knows who has hacked the sample rate of DHO800 serials before?
Its sequential sampling, yes 2G per ADC, then add the data together for 4.
DHO800 will be limited by the front end bandwidth and the processing power of the CPU/FPGA. It has a different lower power part than DHO1000 and this MHO98 I assume. I'm not sure if we have any details on this "RT6888IF" IC.
-
The CPU is not included in this comparison, as the DHO800 has the same CPU as the DHO1000 and DHO4000 (Rockchip 6-core).
FPGA could be another one, and as already mentioned, the front end might not even be capable of operating at up to 1 GHz.
You should ask norbert.kiszka, he is currently hacking the DHO800/900
And you can pay for it. ;)
-
At least no crusty trimmers in the frontend. Interesting though that the input stages of the four channels are not totally symmetrical. It looks like 1+3 are the same and 2+4 are the same, but e.g. 1+2 differ.
There's 2 ADCs so maybe the difference is to multiplex them.
eg. 1+2 might be on one ADC and 3+4 on the other.
-
At least no crusty trimmers in the frontend. Interesting though that the input stages of the four channels are not totally symmetrical. It looks like 1+3 are the same and 2+4 are the same, but e.g. 1+2 differ.
There's 2 ADCs so maybe the difference is to multiplex them.
eg. 1+2 might be on one ADC and 3+4 on the other.
SDcard as booting device, so booting time around 80 secs? will this be a standard on newer oscilloscopes?
-
eg. 1+2 might be on one ADC and 3+4 on the other.
This would be a typical layout, but I saw a video that claimed that any two channels could be uses in 2ch mode.
Then again, who knows. Might be also a wrong display of sampling rate and memory due to firmware bugs.
After all, the displayed sampling rate also doesn't seem to change when adding the LA channels.
-
the ADC is same model with the one in DHO800, except it has 2 ADC. How is the 4GSa/s is calculated? Is it means 2G per ADC then multiple 2=4GSa/s? Does that prove that the DHO800 serials can "update" to 2GSa/s and 1G bandwidth? Is there anyone knows who has hacked the sample rate of DHO800 serials before?
First thing first, ADC is just ADC. It is not self clocked.
So you have external clock source, and FPGA. Both of those are tailored for 1.25GS/s clock rate and corresponding data volume.
-
After all, the displayed sampling rate also doesn't seem to change when adding the LA channels.
Since the LA section uses its own high speed comparators and not the analog front ends' ADCs then, assuming the FPGA/CPU have enough grunt, LA sampling could be interleaved with the analog to maintain the sample rate of the latter.
-
Since the LA section uses its own high speed comparators and not the analog front ends' ADCs then, assuming the FPGA/CPU have enough grunt, LA sampling could be interleaved with the analog to maintain the sample rate of the latter.
The problem here is that there is nothing specified about the LA sampling rate or memory in the MHO900/MHO98 data sheets and actually also not in any other Rigol data sheet I looked at.
The LA on Siglent scopes uses its own sampling rate and memory, but this doesn't seem to be the case for recent Rigol scopes. At least for the DHO900 line, activating the LA reduces sampling rate and memory just as if an additional analog channel was activated. I.e. there are resources shared with analog channels, mainly memory but obviously also (memory/transfer) bandwidth.
As many others, I would have assumed that this is also the case on the MHO900/MHO98. But obviously activating the LA doesn't show the same effect on sampling rate and memory there as on the DHO900. I.e. activating one channel and the LA still shows 4GSa/s and 500 Mpts just as without the LA.
Now, the question is: does the MHO900/98 really have a different architecture there or is it just a firmware bug that leads to not displaying the effect on sampling rate and memory correctly?
-
Might be also a wrong display of sampling rate and memory due to firmware bugs.
After all, the displayed sampling rate also doesn't seem to change when adding the LA channels.
Logic channels don't go through the ADC so why should the sample rate drop... :-//
The unusual thing is why it does drop on other devices. It must be a limit on the FPGA or something in those models. Maybe they require the data to be interleaved with the analog samples and this one doesn't.
(Was that the idea behind the DHO900's extra RAM chips but it never got implemented...?)
-
Logic channels don't go through the ADC so why should the sample rate drop... :-//
As I suggested in the posting you quoted, I suggested memory/transfer bandwidth.
If there is no dedicated LA memory, the main acquisition memory must be used. So, most obviously, the memory depths for analog channels is reduced.
But also memory/transfer bandwidth that is usually used for an analog channel is used by the LA in this case.
I.e. the memory/transfer bandwidth is reduced for analog channels and hence the sampling rate drops.
-
https://www.youtube.com/watch?v=B4Ndm4nnaHI (https://www.youtube.com/watch?v=B4Ndm4nnaHI)
-
https://www.youtube.com/watch?v=B4Ndm4nnaHI (https://www.youtube.com/watch?v=B4Ndm4nnaHI)
"a spring ground is included" :)
-
At Meilhaus.de the info on the MHO98 is:
Special limited edition - only available in an amount of 1998 units worldwide, sales period limited to 2 months: October 13. - December 13., 2025
Analog channels 4 (input impedance 50 Ω/1 MΩ), 1 AUX Out
1 GHz (single-channel);
800 MHz (half-channel);
400 MHz (all channels)
Rise time 420 ps/channel
Memory depth 500 Mpts (single channel), 250 Mpts (half-channel), 125 Mpt (all channels)
They don't offer the MH098 though. I mean i didn't see any price. In Brasil the price seems to be about R$ 17 000, roughly € 2750. This compares to a MHO984 with 500 Mpts memory depth option.
Regards, Dieter
-
As discussed in the other thread (https://www.eevblog.com/forum/testgear/rigol-mho98-and-mho900-oscilloscope-series/275/), it's still sold directly by Rigol, either through Amazon or from their own website.
But in might take 2-3 weeks until the next shipment arrives in Europe:
https://rigolshop.eu/mho98.html (https://rigolshop.eu/mho98.html)
Price here in Germany is and always was €1099 excluding VAT and €1307.81 including 19% VAT.
-
For some reason Im very interested with a image of this SD card :)
-
For some reason Im very interested with a image of this SD card :)
would be interesting if the contained apk modules would work on a DHO8xx/9xx as well - maybe thier decoders will work there as well.
-
For some reason Im very interested with a image of this SD card :)
Teach us how to create such a copy :popcorn:
-
I would guess it boils down to opening the scope and taking out the SD card :)
Actually, I would like to backup the card just to be safe, but I don't want to tear the seal of warranty just after receiving the scope.
-
For some reason Im very interested with a image of this SD card :)
Why not buy a scope, then you can ruin the warranty yourself.
You'll recoup the money by selling the hacks, which you'll surely offer with Rigol's consent.
-
For some reason Im very interested with a image of this SD card :)
Teach us how to create such a copy :popcorn:
maybe something like with the Android debugging tool and ethernet:
adb connect ###.###.###.###:55555
adb root
adb shell
dd if=/dev/mmcblk0 of=<usb_mount_point>/backup.img bs=4096
where ###.###.###.### the IP of the scope is and
<usb_mount_point> the mounting point of the inserted USB-memory-stick is.
/mnt/<something> or /media/<something> or /storage/<something> or similar.
you have to look around with ls, where you find the content of your mounted USB stick.
but this makes an image of the running SD card. in case there will be write opperation going on during creating the backup, it might result in a corrupt filesystem inside that backup.img or inside its partition.
EDIT: does the Rigol mount ext4 filesystems? i guess FAT filesystems are not able to create files bigger than 4GByte. so the USB stick must have another filesystem than FAT.
-
For some reason Im very interested with a image of this SD card :)
Teach us how to create such a copy :popcorn:
Somehow I missed this post...
adb connect ###.###.###.###:55555
adb root
adb shell
dd if=/dev/mmcblk0 of=<usb_mount_point>/backup.img bs=4096
Android uses modified Linux kernel. Some people can't believe in this, but this is true (https://source.android.com/docs/core/architecture/kernel/android-common).
SD card data (image accessible all the time like a regular file) should be either in /dev/block/mmcblk0 or /dev/block/mmcblk1 (RK3399 can handle two MMC memory and this 0/1 depends on the settings in so called Device Tree).
Instead of dd, cp can be used safely.
Finally it should look like this:
adb connect ###.###.###.###:55555
adb root
adb shell
dd if=/dev/block/mmcblk0 of=/mnt/media_rw/...replace this part with usb FS label name.../backup.img
Or in a much easier way (especially for Windows only users) and directly in the file stored on used computer:
adb connect ###.###.###.###:55555
adb root
adb shell
adb pull /dev/block/mmcblk0
EDIT: does the Rigol mount ext4 filesystems? i guess FAT filesystems are not able to create files bigger than 4GByte. so the USB stick must have another filesystem than FAT.
All modern Linux distributions, including Android, uses EXT4 by default. EXT4 is extremely reliable - small damages (like in a dumped image from a running system on it) can be easily fixed by fsck in no time.
When I started using Linux, power loss with huge HDD (disk with spinning plates, not this SSD rubbish), a lot of small files and with EXT3 on it, resulted in 30 minutes of waiting to FSCK finish scanning and repairing. When I used same disk and same data, but I upgraded to EXT4, it was literally seconds, in the worst scenario, about one minute.
Also Android by default mounts /system as a read only. Apps and user data are stored in a separate FS - if any of those will be damaged beyond fixing, it's not a problem.
-
Why not buy a scope, then you can ruin the warranty yourself.
I wish I could.
You'll recoup the money by selling the hacks
About one month ago, I shared my "extreme" earnings. Which are not enough for living. And I can forget about buying any scope.
which you'll surely offer with Rigol's consent.
Did You see any license of software provided by Rigol (beside of their lies about sharing modified open source code)? If there is no license, it means same as: do whatever You want with it.
Rigol used a lot of GPL code in their devices without any consent from creators. Main rule of GPL license is: if You provided compiled binary, You have to give source code to every person who asks for it. Im waiting 2+ years for code from Rigol - and they give no sh** to this very day.
-
Is it known how large the SD card image is? 32GB? This will take a while over WLAN :(
And is there any personalized data in it like the serial number or license information?
-
Much faster with the Ethernet.
And is there any personalized data in it like the serial number or license information?
I don't need serial number or license files. You can mount image and delete all those files (but leave /rigol/data/default - those are calibration files)
Eventually make a backup of those, make a dump and then recover those files.
-
Much faster with the Ethernet.
Yeah, I was lazy and just wanted to check if it's working in principle, but now I'm at 16GB and don't think it's worth to restart.
I don't need serial number or license files. You can mount image and delete all those files (but leave /rigol/data/default - those are calibration files)
Let's see if I will be able to delete these files with something like Ext2explore. If opening the image will work at all.
Besides, the question is how feasible it is to upload such a large image somewhere. Any idea how big this will be if zipped?
-
Ext2explore.
I guess this is a Windows thing.
On Linux You can use this (https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5046892/#msg5046892).
Besides, the question is how feasible it is to upload such a large image somewhere. Any idea how big this will be if zipped?
Most of this is a empty space. It should be around 6-8 GB.
You can use LZMA, XZ, GZ or whatever compression. On a Debian (Linux) I can handle all of them, including extremely rare and old compression methods.
-
Let's see if I will be able to delete these files with something like Ext2explore.
Probably not.
Use ADB, it lets you execute Unix command line functions with "shell".
eg.adb connect 192.168.0.XXX:55555
adb shell ls /rigol/data
adb shell rm /rigol/data/vendor.bin
You can copy files between 'scope and PC with pull and push (do this first!):
adb pull /rigol/data/vendor.bin
adb push vendor.bin /rigol/data/
-
Yeah, I wasn't aware that mounting or even opening/checking a sector based (DD?) image of an Android device would be such a PITA under Windows.
At the moment, I don't think I will be able to delete serial number and the like from that image.
And most I certainly won't mess around with the file system and delete/remove/rename files there while the scope is running.
This being said, the image I downloaded is 31299993600 bytes in size. If I browse if with a hex editor, it sure contains readable data (and a lot of zeroes).
Zipped with 7zip it's surprisingly only 459MB.
-
This being said, the image I downloaded is 31299993600 bytes in size. If I browse if with a hex editor, it sure contains readable data (and a lot of zeroes).
It's mostly empty.
And most I certainly won't mess around with the file system and delete/remove/rename files there while the scope is running.
The 'scope really is just an android app running on Android. You can delete the entire Rigol app and the 'scope will boot just fine and you can use ADB to reinstall it.
I don't see why anybody needs an entire disk image though. It's not more helpful than just the firmware file (is that downloadable?)
If you run "/rigol/build_gel.sh" on the command line it will zip up your current firmware and files into a .GEL file that somebody else could install their 'scope. It's how Rigol devs make firmware update files from their development 'scopes.
You could do that and upload the .GEL file for the hackers. It has no personal info in it.
The destination file is embedded in "build_gel.sh". You can pull that file and see what file it makes (probably "MHO900_Update.GEL"). It goes in "/rigol/"
-
Let's see if I will be able to delete these files with something like Ext2explore.
Probably not.
And why You think like that?
I can access and modify any FS from image - no matter if there is a partition table or not.
-
Yeah, I guess under Linux there are ways to mount the Ex4 partitions in this sector dump, but none of the diverse tools I tried under Windows found any kind of partition in there.
I guess I would have to store partitions from the dump in separate files to open them with Ext4 tools. It's a bit shocking though that none of the tools like OSF Mount or Arsenal Image Mounter is able to detect any kind of partition in there though they claim to support DD files.
-
No surprise for me. Windows and Windows-only software is almost always useless.
-
Yeah, I guess under Linux there are ways to mount the Ex4 partitions in this sector dump, but none of the diverse tools I tried under Windows found any kind of partition in there.
I guess I would have to store partitions from the dump in separate files to open them with Ext4 tools. It's a bit shocking though that none of the tools like OSF Mount or Arsenal Image Mounter is able to detect any kind of partition in there though they claim to support DD files.
Disk Emulation software is not a partition type translation software usually so you can not access it in expected way (Arsenal has some translator built in but I find it very simple) plus they are very picky in terms of what you feed em ;)
It is far less problematic from under Linux but Ext2Explore may work for you if all is done properly.
-
Limited success:
[attach=1]
The trick here seems to be do download the partitions separately:
/dev/block/mmcblk0p10 2031440 970644 1060796 48% /system
/dev/block/mmcblk0p9 124912 116 124796 1% /cache
/dev/block/mmcblk0p11 12016 40 11976 1% /metadata
/dev/block/mmcblk0p16 26855292 293568 26561724 2% /data
/dev/block/mmcblk0p15 495944 202964 292980 41% /rigol
->
adb pull /dev/block/mmcblk0p15
adb pull /dev/block/mmcblk0p16
Still, while there is a "delete" in Ext2explore.exe, it's grayed out...
@Norbert: it would be easier for me to extract file/folder that you need from the Rigol partition. Any specific wishes?
-
This probably will not give bootloader, DT, and other staff. But still most useful are contents from /system, /rigol and probably in /data
-
For some reason Im very interested with a image of this SD card :)
would be interesting if the contained apk modules would work on a DHO8xx/9xx as well - maybe thier decoders will work there as well.
I don't know how much MHO98 decoders has. But in my mod currently it looks like this:
-
Looks like "DiskGenius" could actually delete files in a mounted image:
[attach=1]
So, which are the critical files?
vendor.bin, BND.lic, RLU05.lic, key.data? Something else?
-
Definitely I don't need .lic files, because Im hacking app directly.
Vendor.bin and Key.data contains serial number, model name, MAC address and staff like that.
-
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
-
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
As they say: everything is open source if You can read Assembly.
After some old school hacking in the upcoming days-weeks, I will make a new app from the scratch - primarily linked with the original .so lib (because it will be much faster). With fast and open source API - at least for the separate UI (also open source).
-
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
They aren't "plugins", if that's what you mean.
They're all in the app and enabled with license files.
-
Looks like "DiskGenius" could actually delete files in a mounted image:
(Attachment Link)
So, which are the critical files?
vendor.bin, BND.lic, RLU05.lic, key.data? Something else?
But ... is the info overwritten or does it just remove them from the directory?
-
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
They aren't "plugins", if that's what you mean.
They're all in the app and enabled with license files.
It can be enabled by hacking You forget to say (as usual...).
New can be added by writing in Assembly.
-
Looks like "DiskGenius" could actually delete files in a mounted image:
(Attachment Link)
So, which are the critical files?
vendor.bin, BND.lic, RLU05.lic, key.data? Something else?
But ... is the info overwritten or does it just remove them from the directory?
In DHO800/900 (stock app) additional licenses are saved in FRAM in a separate IC.
-
But ... is the info overwritten or does it just remove them from the directory?
Both is possible. I used overwrite with 0 :)
-
I was curious about the app (apk) and why it crashes on my DHO924S.
Code that made a crash was a part of completely different license system. This time they were more clever than using XOR or similar easy to hack things as they did before. So rigol_vendor_bin likely will not work here - at least not in the same way.
Anyway, still this is not a problem for me, because Im just bypassing those license functions. So the function contents doesn't matter.
-
I bypassed communication with the FPGA and app now works on my DHO924S - as in the attachment.
Hacking it should be easy.
-
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
They aren't "plugins", if that's what you mean.
They're all in the app and enabled with license files.
It can be enabled by hacking You forget to say (as usual...).
Yes, because the question (and therefore my answer) was about writing custom decoders, not about how unlockable the existing ones are.
-
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
They aren't "plugins", if that's what you mean.
They're all in the app and enabled with license files.
It can be enabled by hacking You forget to say (as usual...).
Yes, because the question (and therefore my answer) was about writing custom decoders, not about how unlockable the existing ones are.
Correct. I was wondering whether Rigol had some sort of non-public mechanism that dynamically loaded (call it a plugin if you want) decoders. Where, if you could implement the same interface and drop a binary in the right place, you could sneak in your own. It sounds like the answer is no (I'll assume the decoders are all compiled into the same binary). Thanks for the answers.
-
My teardown pics are up:
https://www.flickr.com/photos/eevblog/albums/72177720330041928 (https://www.flickr.com/photos/eevblog/albums/72177720330041928)
-
My teardown pics are up:
https://www.flickr.com/photos/eevblog/albums/72177720330041928 (https://www.flickr.com/photos/eevblog/albums/72177720330041928)
In such case, hacking scope firmware without having exact scope model is quite easy :) All I need is stock firmware (which I have already) and photos from teardown.
-
My teardown pics are up:
https://www.flickr.com/photos/eevblog/albums/72177720330041928 (https://www.flickr.com/photos/eevblog/albums/72177720330041928)
The standard 4-pin fan header will make fan upgrades/mods easy :-+
-
My teardown pics are up:
https://www.flickr.com/photos/eevblog/albums/72177720330041928 (https://www.flickr.com/photos/eevblog/albums/72177720330041928)
The standard 4-pin fan header will make fan upgrades/mods easy :-+
In my preliminary reverse engineering I noticed PWM kernel module - for sure it's used to drive fan. Knowing Rigol, they did this management in scope app instead of separate process - that's bad, because when app will crash and nobody will restart it, everything can overheat.
-
The standard 4-pin fan header will make fan upgrades/mods easy :-+
I haven't looked for alternatives yet, but yes, the fan is annoyingly loud. 57W power consumption.
-
FYI:
https://www.youtube.com/watch?v=6lBU4NwmY7s (https://www.youtube.com/watch?v=6lBU4NwmY7s)
-
No surprise for me. Windows and Windows-only software is almost always useless.
Just to be fair: "DiskGenius" is also able to find all the partitions in the complete raw "mmcblk0" SD card dump:
[attach=1]
It's the only (somewhat) free Windows tool I found up to now which can actually do that.
This also allows inspecting (dumps of) SD cards from other Linux systems, e.g. Raspberry Pi.
Unfortunately, the free version is limited to extracting small files.
-
My teardown pics are up:
https://www.flickr.com/photos/eevblog/albums/72177720330041928 (https://www.flickr.com/photos/eevblog/albums/72177720330041928)
The standard 4-pin fan header will make fan upgrades/mods easy :-+
In my preliminary reverse engineering I noticed PWM kernel module - for sure it's used to drive fan. Knowing Rigol, they did this management in scope app instead of separate process - that's bad, because when app will crash and nobody will restart it, everything can overheat.
Hopefully it has a fan controller that will revert to 100% if not constantly commanded to hold a lower speed (like on PCs).
-
Yeah but if the app crashes while the fan is set to a low speed I assume it will just not update the PWM value and cook itself.
-
Yeah but if the app crashes while the fan is set to a low speed I assume it will just not update the PWM value and cook itself.
That's the worst-case scenario, and it might be the case if they are using what is literally only a PWM circuit. But if it's a fan controller, they fail-safe to 100% speed (or to a temperature-based speed control if fancy enough and configured to).
-
As a side note, I didn't have the impression that there is any kind of fan regulation. It seems to always run a the same speed.
-
As a side note, I didn't have the impression that there is any kind of fan regulation. It seems to always run a the same speed.
Maybe it will speed up when temperature will be higher.
# V03以及之后的硬件版本
if [ "$hdcode_val" -ne 1 ] && [ "$hdcode_val" -ne 2 ]; then
# 配置风扇驱动
echo "insmod /rigol/driver/pwm_fan.ko"
insmod /rigol/driver/pwm_fan.ko
chmod 777 /dev/pwm_fan
fi
I sugest to check if this module is loaded with one command:
adb shell lsmod
-
As a side note, I didn't have the impression that there is any kind of fan regulation. It seems to always run a the same speed.
I haven't heard it change.
-
I left it one for several hours to dump the SD card image (twice) and all the partitions and while it definitely got hot, the fan noise never changed at all.
Worked perfectly fine using a Ugreen "Nexode Pro" 100W USB PD power supply btw. and from what I can tell, it never used more than 60W (usually 55W or so).
I sugest to check if this module is loaded with one command:
adb shell lsmod
Sorry, I was lazy, but now I tried:
>adb shell lsmod
Module Size Used by
usbtmc_dev 41918 2
libcomposite 60749 1 usbtmc_dev
focaltech_ts 213735 0
8821cu 3514198 0
afe_rms_gpio 2864 0
dac_gpio 3663 1
beeper_gpio 3684 1
spi2afe_gpio 5571 1
xdma 99943 2
pcie_rockchip 20793 0
fpga_gpio 3923 0
spi2pll_gpio 4744 0
motorcomm 17303 0
pwm_fan 8802 2
hdcode_gpio 3046 0-> looks like "pwm_fan" is loaded...
-
Has anyone tried a 65W supply? Sounds like that would be enough and would be very handy as it's a common power rating, but is below the spec they ask for.
-
Has anyone tried a 65W supply?
Keep in mind that most USB PD supplies are meant as chargers, not as permanent supplies. I.e. it's not uncommon that they can't keep their specified maximum load for more than 1-2 hours.
E.g. the Nexode Pro 100W that I used is known to drop to 65W after 1-2h under full load (100W). If a 65W supply would drop to e.g. 45W after 2h at 55W, this would mean that the scope would shut down in the middle of usage.
-> it seems safer to use a 100W PD supply just for this safety margin.
-
Has anyone tried a 65W supply? Sounds like that would be enough and would be very handy as it's a common power rating, but is below the spec they ask for.
Dave measured consumption at nearly 60W so 65W is far too close for comfort. I doubt many power banks are designed to run at 100% for long periods of time.
I'd be looking for at least 80W and preferably 100W.
-
Was thinking more along the lines of laptop PSUs than power banks - these scopes are portable enough that it would be nice to run off the same PSU as the laptop you are likely also carrying. Most are 65W or so unless you have some awful tank of a laptop.
For fixed use for sure would use something chunkier.
-
Some 100W USB-PD supplies are pretty small (e.g. the Ugreen Nexode Pro I used). Again, they are also not exactly meant to deliver 100W for multiple hours, but there seems to be enough safety margin to run the MHO98 for several hours.
-
For fixed use for sure would use something chunkier.
Maybe the one Rigol supplied in the box...? :-//
-
For fixed use for sure would use something chunkier.
Maybe the one Rigol supplied in the box...? :-//
Yep - my interest in smaller supplies is so that I can keep the Rigol supplied one on the bench and use something else (e.g. the 65W laptop one I normally carry) when taking advantage of the scope's portability (half the reason I am getting one).
-
Yep - my interest in smaller supplies is so that I can keep the Rigol supplied one on the bench and use something else (e.g. the 65W laptop one I normally carry) when taking advantage of the scope's portability (half the reason I am getting one).
Same idea here. Besides, it's really somewhat problematic to fit everything including the logic probe and the original power supply in the bag.
But the 100W supply I tried is really not that much bigger compared to a (very small) 65W supply:
[attach=1]
-
... one on the bench and use something else (e.g. the 65W laptop one I normally carry) when taking advantage of the scope's portability
You can try it and see what happens ... but battery chargers are usually OK with less than 100% current, it just means the battery charges slower.
Oscilloscopes? Not so much.
-
Why not run this directly from a battery pack as with DHO800/900?
-
I left it one for several hours to dump the SD card image (twice) and all the partitions and while it definitely got hot, the fan noise never changed at all.
Worked perfectly fine using a Ugreen "Nexode Pro" 100W USB PD power supply btw. and from what I can tell, it never used more than 60W (usually 55W or so).
I sugest to check if this module is loaded with one command:
adb shell lsmod
Sorry, I was lazy, but now I tried:
>adb shell lsmod
Module Size Used by
usbtmc_dev 41918 2
libcomposite 60749 1 usbtmc_dev
focaltech_ts 213735 0
8821cu 3514198 0
afe_rms_gpio 2864 0
dac_gpio 3663 1
beeper_gpio 3684 1
spi2afe_gpio 5571 1
xdma 99943 2
pcie_rockchip 20793 0
fpga_gpio 3923 0
spi2pll_gpio 4744 0
motorcomm 17303 0
pwm_fan 8802 2
hdcode_gpio 3046 0-> looks like "pwm_fan" is loaded...
I did quick reverse engineering of this module. Looks like it reads some settings from the DT. And DT can be easily edited (only if You use Linux tho).
Beside of the DT, I suggest to look into /sys to find any files that can be edited to change this module behavior.
-
Does it load the DT from somewhere easily writable? If so I'll have a poke around when mine arrives. Also interested if there are any tweaks that can be done to the DT to make the damn thing boot faster - was this the case on the DHO8/900, or did that also need app tweaks?
I have a fair bit of experience hacking on device trees on Jetson devices, but have not played with any on other platforms or Android vs straight linux (assuming little difference there though).
-
It's not in any FS. Just inside Android boot image. You can find it with binwalk and extract it with dd.
-
I extracted and decompiled DT from the Dave SD card image (attachment).
Part of the decompiled PWM module code:
iVar6 = of_property_read_variable_u32_array
(pdVar11,"cooling-levels",lVar9,(long)iVar5,0);
if (iVar6 < 0) {
dev_err(pdVar1,"Property \'cooling-levels\' cannot be read!\n");
iVar5 = iVar6;
goto LAB_001008a4;
}
There is no such entry in DT :-BROKE
From the Linux kernel documentation about it (https://www.kernel.org/doc/Documentation/devicetree/bindings/hwmon/pwm-fan.yaml):
...
cooling-levels:
description: PWM duty cycle values corresponding to thermal cooling states.
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
maximum: 255
...
DT can be edited, compiled back and saved into sd card (externally via adb and dd). The problem is with the size of compiled DT - there is no much space available. In such case whole Android boot image has to be extracted and generated again.
Eventually we can lower the size with deleting some entries. Which is not the easiest task to chose what can be deleted and what not so much.
-
I would think that if Rigol decided to use a static value there, it's best not to mess with it.
The MHO98 gets pretty warm after some time. Even if the fan speed might be optimized for somewhat warmer Asian temperatures, it seems risky to lower it without any kind of temperature regulation in place.
It's somewhat disappointing though that Rigol didn't care about some kind of temperature controlled fan regulation (again).
But yeah, it's not killing me. Everyone who ever sat next to some PC based Agilent/Keysight/LeCroy gear might find the noise level to be pretty low anyway ;)
-
As You can see in my previous post, it looks like they started doing PWM control and abandoned it later - maybe they were in hurry to release it?
-
Do the DHO models have fan control?
-
Do the DHO models have fan control?
Currently only on/off (together with couple other things) and also currently Im working on a way to change it. Actually Im going to make a whole kernel for it, which also will increase performance a lot.
Some GPIO pins are free to use on a PCB - just add a wire and we have PWM to drive the fan speed.
This will not only give less noise, but most importantly, more stable temperature.
-
You're probably aware already, but the DHO1000 series was reported to have pwm fan control. Just saying, in case you wanted to try similar here on MHO.
Just discovered that 'su' command works ... so its enough to type echo X> /sys/devices/platform/pwm_fan/hwmon/hwmon5/pwm1 , where X is a value from 0 to 255.
I expected this value to be changed by the system periodically but ... it does not seems the case ???
I'm monitoring temps with PWM = 100, there is a small increase, the monitored ones are still under 50 °C with a room temp of 18 °C.
-
You're probably aware already, but the DHO1000 series was reported to have pwm fan control. Just saying, in case you wanted to try similar here on MHO.
It should be easier to copy this part of the DT instead of making new entries. But I don't have MHO to test it - unless somebody will wan't to help with that (with testing).
-
From a trusty source: Fudan actually got Xilinx's help when making these chip, Fudan now even has some RFSoC clone. And it's not made by TSMC!
My personal guess is: At first, Fudan was trying to reverse engineering Xilinx FPGA then sell it to defense related company in China, but the result wasn't ideal. At the same time, Xilinx also wants to sell FPGA to these companies, but due to obvious reason they can't sell it directly.
Then somehow Fudan convince Xilinx to help them build the clone chip, and now both Xilinx and Fudan make big buck of money out of this, it's basically a win-win deal from company standpoint. :popcorn:
Note: I don't want to involve politics in this topic
This is extraordinary if true. Xilinx is one of the most important suppliers to US aero/defense industries. Hard to believe they could get even tacit approval for something like this.
-
From a trusty source: Fudan actually got Xilinx's help when making these chip, Fudan now even has some RFSoC clone. And it's not made by TSMC!
My personal guess is: At first, Fudan was trying to reverse engineering Xilinx FPGA then sell it to defense related company in China, but the result wasn't ideal. At the same time, Xilinx also wants to sell FPGA to these companies, but due to obvious reason they can't sell it directly.
Then somehow Fudan convince Xilinx to help them build the clone chip, and now both Xilinx and Fudan make big buck of money out of this, it's basically a win-win deal from company standpoint. :popcorn:
Note: I don't want to involve politics in this topic
This is extraordinary if true. Xilinx is one of the most important suppliers to US aero/defense industries. Hard to believe they could get even tacit approval for something like this.
Rigol gives a sh*t to GPL software license conditions. So no surprise they did a copy of Xilinx FPGA.
-
Mastering high end Xilinx/AMD chips clones is not so easy for China, imho.
The chip there could easily be a clone of an older type, like 15y old tech (virtex-6 40nm, or virtex-7 28nm).
Or simply a home made ASIC..
-
It should be easier to copy this part of the DT instead of making new entries. But I don't have MHO to test it - unless somebody will wan't to help with that (with testing).
Once mine arrives (late this month) and I'm sure it's working right then I might be able to have a go at messing with the DT. Need to make sure I can reflash the stock SD card image if there's any hardware faults that require return to Rigol though - I'll have a look at Dave's teardown to see how hard it is to open up without leaving evidence.
-
Once mine arrives (late this month) and I'm sure it's working right then I might be able to have a go at messing with the DT. Need to make sure I can reflash the stock SD card image if there's any hardware faults that require return to Rigol though - I'll have a look at Dave's teardown to see how hard it is to open up without leaving evidence.
Apart from the warranty sticker, trivial to open, 4 screws back lifts off, access to everything.
-
Actually they have a cooperation with China about development chips for their market and they hold shares in those enterprises so they might not need to even steal anything but they most probably can use older tech on agreements basis which would explain using 3 years old chips.
-
For some reason Im very interested with a image of this SD card :)
LOL I thought someone posted a pic of the SD card, that you're so interested in.
I'm interested in these 500-1,000Mhz scopes, I haven't checked the prices yet, but it's good to know 1GHz scopes can be had by mere mortals with little money I guess, compared to the big names.
If it does the business just for that part, I wouldn't mind not having all the other options.