Rigol's New DHO800 Oscilloscope unbox & teardown

[Martin72]

The DHO800_UserGuide_EN says:
"When three channels or all four channels are enabled (only available for four-channel models), the memory depths available include Auto, 1 kpts, 10 kpts, 100
kpts, and 1 Mpts" so 1 Mpts seems to be no error at most.

I can still faintly remember that "back then" with the DHO4204 I could not always select/use the full, expectable memory.
This also had something to do with the selected acquisition mode, either the amount of memory was limited or you could only select "Auto".
Ah yes,
With the big Rigol, there was only a vector mode for the display, no dot mode.
Is that also the case with the small ones?

[adam4521]

Flash has way higher practical erase cycle count. The typical 10k cycles is a very conservative number, which is true for the full temperature range (-40 - +85 C) for 20-40 years retention.

I’m not sure that ‘wear’ is necessarily the problem experienced — more that the settings are saved in a ‘file’, the OS has a cache, and sometimes people are unlucky that the flush to disk happens just when they power down (pull out the USB plug). And it next boots up in an inconsistent state. Or, maybe the disk writes have indeterminate scheduling and messes things up in other ways. They might be designing to avoid those kinds of problems?

[ataradov]

If it is a full Android with RW file system, then settings would be the least of my concern. Android likes to spam a ton of log files and other temporary crap. If this is not locked, like on typical phones, you should expect a huge speed degradation over 3-5 years. But this also may be fine, in 5 years there will be a new and better scope.

And it being Android, makes me pause and wait until others test drive it. I would not be surprised if there are quite a few issues in the first units.

[tautech]

I’m not sure that ‘wear’ is necessarily the problem experienced — more that the settings are saved in a ‘file’, the OS has a cache, and sometimes people are unlucky that the flush to disk happens just when they power down (pull out the USB plug). And it next boots up in an inconsistent state. Or, maybe the disk writes have indeterminate scheduling and messes things up in other ways. They might be designing to avoid those kinds of problems?

No different to a power cut when an instrument does not get the chance to power down gracefully and save settings.
In that case they normally reboot to the previous boot settings.

[EEVblog]

But as I said before, we need someone to confirm only 1MPts in all channel mode. That first.

I just tested it. 4CH or 3CH mode is only 1M maximum. 2CH is 10M maximum. 1CH is 25M.

[EEVblog]

I can confirm that the scope does not boot when the SD card is removed. Nothing out of the serial debud port at all.
So I can only presume that the entire android OS and firmware is on the card.
But I still can't read the contents of the card...

[ataradov]

For Android it likely does not have standard partition table. You would need some tool that can read raw data. Under Linux it would be trivial using "dd", I'm not sure what is there for Windows.

It would likely have the bootloader code right in the first sectors.

[porter]

Are there  Android aging problems with  Micsig scopes? I did a search on this site and nothing popped up, yet.

[tautech]

I can confirm that the scope does not boot when the SD card is removed. Nothing out of the serial debud port at all.
So I can only presume that the entire android OS and firmware is on the card.

SD card replacement recovery for bricked scopes. 

[mwb1100]

This tool might be some help in unpacking the image(s) from the sdcard:

  - imjtool: an Android boot image extractor

It's been a long while since I've used it, but looks like it has been maintained (the archive has files from Jan 2023) so I think there's a good chance it'll be useful. Make a `dd` image of the sdcard to a file, then try running the tool on that file:

Code: [Select]

imjtool <filename> extract
You might need to look for an "ANDROID!" signature marker to find out if there sectors in the image that need to be skipped.  See the examples given on the tool's page.

[ataradov]

If SD card is the only non-volatile memory in the whole scope, it is very good news. It would be possible to easily make backups and swap the cards. Plus they manage wear on their own, so this is not a concern at all.

Having card image would be great for poking around.

[EEVblog]

Teardown:

[EEVblog]

If SD card is the only non-volatile memory in the whole scope, it is very good news. It would be possible to easily make backups and swap the cards. Plus they manage wear on their own, so this is not a concern at all.
Having card image would be great for poking around.

Agreed, this is great.

[EEVblog]

This tool might be some help in unpacking the image(s) from the sdcard:

  - imjtool: an Android boot image extractor

It's been a long while since I've used it, but looks like it has been maintained (the archive has files from Jan 2023) so I think there's a good chance it'll be useful. Make a `dd` image of the sdcard to a file, then try running the tool on that file:

Code: [Select]

imjtool <filename> extract
You might need to look for an "ANDROID!" signature marker to find out if there sectors in the image that need to be skipped.  See the examples given on the tool's page.

I only run Windows.

[ataradov]

This looks like the approximate equivalent of "dd" with GUI for Windows https://hddguru.com/software/HDD-Raw-Copy-Tool/ I have not tried that myself, but I can see a number of positive reviews.

The claim it that "The program also supports low-level duplication of FLASH cards (SD/MMC, MemoryStick, CompactFlash, SmartMedia, XD) using a card-reader."

And imjtool is something you run on the resulting file anyway, so the dump has to happen first.

[Fungus]

Flash is super cheap and configuration is tiny, you can do a lot of wear-leveling without any issues.

You simply can't take that risk as a manufacturer though. The damage it could cause if they all start failing after a few years is unacceptable.

FRAM isn't that expensive.

[Fungus]

But as I said before, we need someone to confirm only 1MPts in all channel mode. That first.

I just tested it. 4CH or 3CH mode is only 1M maximum. 2CH is 10M maximum. 1CH is 25M.

Very strange... 

I can't think of a single logical reason for that. It should be linear.

[Dacian]

The power consumption is unexpectedly high. Hopefully there is good thermal contact with that custom heatsink and it will not degrade much over time.
The OS is sure on that SD card and that is a good thing. It is incredible that they can manage all this for the price.

[Fungus]

Are there  Android aging problems with  Micsig scopes? I did a search on this site and nothing popped up, yet.

I'm not sure what an "android aging" problem is but I never heard of a Micsig dying of old age.

[ataradov]

You simply can't take that risk as a manufacturer though.

You are not taking a risk with wear-leveling and sticking to the 10k erase cycles. Especially if settings are stored on the SD card, where this would happen automatically.

If you are working with a plain flash, allocate 1000 sectors for the settings and you've got 10mil erase cycles.

This is done all the time, including for automotive products where manufactures really care. It is not a real issue.

[EEVblog]

This looks like the approximate equivalent of "dd" with GUI for Windows https://hddguru.com/software/HDD-Raw-Copy-Tool/ I have not tried that myself, but I can see a number of positive reviews.

Thanks, that worked, done!
Here is the compressed dump, 800MB. That software offered RAW or compressed, I hope compressed is fine?
https://www.eevblog.org/files/RigolDHO800-SDcard-dump.imgc

[gslick]

Teardown:

No battery anywhere? I didn't see one. The big brother 1000 and 4000 series have batteries in their teardown photos.

No RTC maintained across power off? I think someone else mentioned that on the forum.

Does it at least have an NTP client that will sync to network time if a network connection is available? Nice to have an in sync RTC for timestamps on images and data files saved to USB flash devices.

[DEV001]

Thanks, that worked, done!
Here is the compressed dump, 800MB. That software offered RAW or compressed, I hope compressed is fine?
https://www.eevblog.org/files/RigolDHO800-SDcard-dump.imgc

Here is basic binwalk info from the SD card you uploaded. I just started looking at it but it seems to be the OS.

[mwb1100]

It looks like the compressed image is some format proprietary to HDD Raw Copy:

Code: [Select]

C:\temp>file RigolDHO800-SDcard-dump.imgc
RigolDHO800-SDcard-dump.imgc: HDD Raw Copy Tool 1.10 - HD model: Lexar microSD RDR serial: 000000008051

I'm guessing that imjtool needs a raw copy.  That can be created from the compressed image using the HDD Raw Copy tool (the uncompressed image is 32 GB).

I'll try to get imgtool to read the uncompressed image later (HDD Raw Copy isn't particularly fast, even when sdcard media isn't involved).  I'll post results once I get them if I haven't been Beaten to the punch by someone else.

(HDD Raw Copy is 1/3 the way to creating an uncompressed image - I started it before typing this post...)

[ataradov]

That tool can decompress into a raw image. And it runs under Wine just fine.

There is definitely no standard partition table. The first 32 KB of the raw image are 0, then there is a bootloader, then a huge chunk that is 0 and the main OS goes. It is not readily recognized by the imjtool.