Rigol's New DHO800 Oscilloscope unbox & teardown

[EEVblog]

I tried to read the 32GB SD card that was glued into place on the board, but can't see anything. I tried using DiskINternals Linux Reader but it doesn't read it.
Anyone know what it's for?

Can you post a picture of the card? Let's assume it ain't there only to consume power so, if the controller is not customized, one should be able to read it...

Just a 32GB Lexar micro SD card. It was glued into the SD card slot. I'll try and boot without it.

[Nikki Smith]

The missing small stuff appears to be one power supply and some auxiliry analog sample and hold circuits (CMOS OpAmps) to supply config/threshold voltages to the MSO / AWG sections.

There apprears to be no AWG harwdare except for a buffer driver on the output? 

@Azusa posted that the AWG hardware is a plug-in module?
https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg4965322/#msg4965322

No one has posted photos of it yet, but @souldevelop got a DHO914S today and is investigating.

[TurboTom]

...

There apprears to be no AWG harwdare except for a buffer driver on the output? 

As mentioned, the AWG is a piggyback module that's to be installed on the headers  next to the rear BNCs --  just like it's been the case with the DS1000Z and DS2000(A) series. There's no AWG buffer amp on the main PCB, the AWG output is routed directly from the small header to the BNC.

[Howardlong]

I have some questions on the LA on the DHO900 series.

Are the LA channels at the expense of analogue channels on these scopes?

On the MSO1074Z, you can have
4 analogue / 0 digital
3 analogue / 8 digital
2 analogue / 16 digital

In practice, due to the limitations of the screen real estate, I found that this is typically less of a problem than it might otherwise perceived to be.

I'm also wondering if the LA sampling rate directly reflects the analogue sampling rate?

Furthermore, presumably the memory depth is shared between the analogue and digital channels. I can't remember if it was a Siglent or a Rigol, but the memory depth on the digital channels was significantly less than that available to the analogue channels.
 
Another issue I found with the MSO5000 was that the decode search available on the analogue channels was unavailable on the digital channels.

There is also a 1ns trigger/display delay discrepancy on the MSO5000 digital channels that I don't believe has ever been fixed.

[Howardlong]

...

There apprears to be no AWG harwdare except for a buffer driver on the output? 

As mentioned, the AWG is a piggyback module that's to be installed on the headers  next to the rear BNCs --  just like it's been the case with the DS1000Z and DS2000(A) series. There's no AWG buffer amp on the main PCB, the AWG output is routed directly from the small header to the BNC.

A bit of swings and roundabouts here, the DS1000Z AWG was two channel but limited to +/-2.5V, whereas the DHO900S is single channel with a 10V output range up to 10MHz (Don't know if this includes offset or not).

Edit: would've been nice to have the connector on the front panel too.

[EEVblog]

Boot output from the Rockchip and the FPGA flash UARTS (115K 8N1)
The Rockhip is too big to include as embedded code in this post, download the TXT file.

Code: [Select]

Xilinx First Stage Boot Loader

Release 2020.2 May 21 2023-11:29:05
Devcfg driver initialized
Silicon Version 3.1
Boot mode is QSPI

Single Flash Information
FlashID=0xEF 0x40 0x18
WINBOND 128M Bits
QSPI is in single flash connection
QSPI is in 4-bit mode
QSPI Init Done
Flash Base Address: 0xFC000000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 3
Partition Number: 1
Header Dump
Image Word Len: 0x000D6468
Data Word Len: 0x000D6468
Partition Word Len:0x000D6468
Load Addr: 0x00000000
Exec Addr: 0x00000000
Partition Start: 0x000045D0
Partition Attr: 0x00000020
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xFFD78A86
Bitstream
In FsblHookBeforeBitstreamDload function
PCAP:StatusReg = 0x40000A30
PCAP:device ready
PCAP:Clear done
Level Shifter Value = 0xA
Devcfg Status register = 0x40000A30
PCAP:Fabric is Initialized done
PCAP register dump:
PCAP CTRL 0xF8007000: 0x4C00E07F
PCAP LOCK 0xF8007004: 0x0000001A
PCAP CONFIG 0xF8007008: 0x00000508
PCAP ISR 0xF800700C: 0x0802000B
PCAP IMR 0xF8007010: 0xFFFFFFFF
PCAP STATUS 0xF8007014: 0x00000A30
PCAP DMA SRC ADDR 0xF8007018: 0xFC011741
PCAP DMA DEST ADDR 0xF800701C: 0xFFFFFFFF
PCAP DMA SRC LEN 0xF8007020: 0x000D6468
PCAP DMA DEST LEN 0xF8007024: 0x000D6468
PCAP ROM SHADOW CTRL 0xF8007028: 0xFFFFFFFF
PCAP MBOOT 0xF800702C: 0x0000C000
PCAP SW ID 0xF8007030: 0x00000000
PCAP UNLOCK 0xF8007034: 0x757BDF0D
PCAP MCTRL 0xF8007080: 0x30800100
...................................................................................................

DMA Done !


FPGA Done !

In FsblHookAfterBitstreamDload function
Partition Number: 2
Header Dump
Image Word Len: 0x00003002
Data Word Len: 0x00003002
Partition Word Len:0x00003002
Load Addr: 0xFFFF0000
Exec Addr: 0xFFFF0000
Partition Start: 0x000DAA40
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xFFF3C348
Application
PCAP:StatusReg = 0x40000F30
PCAP:device ready
PCAP:Clear done
PCAP register dump:
PCAP CTRL 0xF8007000: 0x4C00E07F
PCAP LOCK 0xF8007004: 0x0000001A
PCAP CONFIG 0xF8007008: 0x00000508
PCAP ISR 0xF800700C: 0x00030004
PCAP IMR 0xF8007010: 0xFFFFFFFF
PCAP STATUS 0xF8007014: 0x50000F30
PCAP DMA SRC ADDR 0xF8007018: 0xFC36A901
PCAP DMA DEST ADDR 0xF800701C: 0xFFFF0001
PCAP DMA SRC LEN 0xF8007020: 0x00003002
PCAP DMA DEST LEN 0xF8007024: 0x00003002
PCAP ROM SHADOW CTRL 0xF8007028: 0xFFFFFFFF
PCAP MBOOT 0xF800702C: 0x0000C000
PCAP SW ID 0xF8007030: 0x00000000
PCAP UNLOCK 0xF8007034: 0x757BDF0D
PCAP MCTRL 0xF8007080: 0x30800110


DMA Done !

Handoff Address: 0xFFFF0000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1
This is MultiBoot Image 3!!!
FlashID=0xEF 0x40 0x18
Recv Command Boot!!!
Target Addr: 0x00400000
Running Command Prog!!!
Try MultiBoot
Send Software Reset!!!


Xilinx First Stage Boot Loader

Release 2020.2 May 21 2023-11:29:05
Devcfg driver initialized
Silicon Version 3.1
Boot mode is QSPI

Single Flash Information
FlashID=0xEF 0x40 0x18
WINBOND 128M Bits
QSPI is in single flash connection
QSPI is in 4-bit mode
QSPI Init Done
Flash Base Address: 0xFC000000
Reboot status register: 0x60480000
Multiboot Register: 0x0000C080
Image Start Address: 0x00400000
Partition Header Offset:0x00400C80
Partition Count: 3
Partition Number: 1
Header Dump
Image Word Len: 0x000D6468
Data Word Len: 0x000D6468
Partition Word Len:0x000D6468
Load Addr: 0x00000000
Exec Addr: 0x00000000
Partition Start: 0x000045D0
Partition Attr: 0x00000020
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xFFD78A86
Bitstream
In FsblHookBeforeBitstreamDload function
PCAP:StatusReg = 0x40000A30
PCAP:device ready
PCAP:Clear done
Level Shifter Value = 0xA
Devcfg Status register = 0x40000A30
PCAP:Fabric is Initialized done
PCAP register dump:
PCAP CTRL 0xF8007000: 0x4C00E07F
PCAP LOCK 0xF8007004: 0x0000001A
PCAP CONFIG 0xF8007008: 0x00000508
PCAP ISR 0xF800700C: 0x0802000B
PCAP IMR 0xF8007010: 0xFFFFFFFF
PCAP STATUS 0xF8007014: 0x00000A30
PCAP DMA SRC ADDR 0xF8007018: 0xFC411741
PCAP DMA DEST ADDR 0xF800701C: 0xFFFFFFFF
PCAP DMA SRC LEN 0xF8007020: 0x000D6468
PCAP DMA DEST LEN 0xF8007024: 0x000D6468
PCAP ROM SHADOW CTRL 0xF8007028: 0xFFFFFFFF
PCAP MBOOT 0xF800702C: 0x0000C080
PCAP SW ID 0xF8007030: 0x00000000
PCAP UNLOCK 0xF8007034: 0x757BDF0D
PCAP MCTRL 0xF8007080: 0x30800100
...................................................................................................

DMA Done !


FPGA Done !

In FsblHookAfterBitstreamDload function
Partition Number: 2
Header Dump
Image Word Len: 0x00003002
Data Word Len: 0x00003002
Partition Word Len:0x00003002
Load Addr: 0xFFFF0000
Exec Addr: 0xFFFF0000
Partition Start: 0x000DAA40
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xFFF3C348
Application
PCAP:StatusReg = 0x40000F30
PCAP:device ready
PCAP:Clear done
PCAP register dump:
PCAP CTRL 0xF8007000: 0x4C00E07F
PCAP LOCK 0xF8007004: 0x0000001A
PCAP CONFIG 0xF8007008: 0x00000508
PCAP ISR 0xF800700C: 0x00030004
PCAP IMR 0xF8007010: 0xFFFFFFFF
PCAP STATUS 0xF8007014: 0x50000F30
PCAP DMA SRC ADDR 0xF8007018: 0xFC76A901
PCAP DMA DEST ADDR 0xF800701C: 0xFFFF0001
PCAP DMA SRC LEN 0xF8007020: 0x00003002
PCAP DMA DEST LEN 0xF8007024: 0x00003002
PCAP ROM SHADOW CTRL 0xF8007028: 0xFFFFFFFF
PCAP MBOOT 0xF800702C: 0x0000C080
PCAP SW ID 0xF8007030: 0x00000000
PCAP UNLOCK 0xF8007034: 0x757BDF0D
PCAP MCTRL 0xF8007080: 0x30800110


DMA Done !

Handoff Address: 0xFFFF0000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1
This is MultiBoot Image 3!!!
FlashID=0xEF 0x40 0x18



[Fungus]

I tried to read the 32GB SD card that was glued into place on the board,

Can you post a picture of the card?

[Fungus]

BTW: Rigol still uses an FRAM chip to store configuration information and other frequently changed data, here it's a MB85RC64TA (64kbit), located at the "back" of the PCB -- Nice!

They have to use FRAM. The current state has to be stored after almost every button press or knob twist. Flash or EEPROM would wear out in no time.

[2N3055]

They could use CSI to transport data between FPGA and CPU and just use RAM there.

It's a fierce data rate.

1Mpts for 4 ch actually makes sense now.

No it doesn't. Data is data, doesn't matter if it's interleaved or not.

It is cheapest 12bit scope ever made. Compromises will exist.

Obviously.

Reducing it to only six chips will help a lot with the price.

CSI is pretty fast.. Since there is no local RAM on FPGA, they have to stream to CPU...But they will trigger and do some preconditioning in FPGA.
And interleaving more channels and taking care of triggering and such is not same as simple trigger-stream for just one channel...

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

[faveri97]

I purchased a DHO914S in July when the second batch of presales began in China. The firmware version was 00.01.00 (2023/07/21).
The scope worked fine until I turned on the AWG and adjusted the output frequency to somewhere above 100kHz. The output of the AWG was some random DC voltage, and the scope software crashes if you continue to increase the output frequency using the front panel knobs.
I contacted Rigol about this problem, and they reproduced the crash but not the output issue on their DHO914S running the same up-to-date firmware, so I returned the scope. They confirmed that my unit was faulty and would resend me a new one.
During my playing around I also found some more quirks:

• No hi-res acquisition mode.
• The RTC seems non-functional and all dates begin somewhere in 2013.
• The intensity graded waveform display is not as good as the MSO5000 series in my eyes.

Otherwise, I liked the scope, especially for its form factor and UI design.

[souldevelop]

The DHO914S looks pretty good installed on the VESA100. This VESA100 shelf costs about $10~20 in China.

[souldevelop]

Guys, I'm back, I self-calibrated DHO914S and tested the noise floor, which is probably between ......

Thanks for sharing. I am extremely interested in the HDMI output. Could you please connect the scope to an external monitor and show us how it looks?

Sorry, I saw this problem for a long time, the external connection monitor uses HDMI I don't think the image quality will be reduced, because I use the web control way to show it resolution beyond my imagination, but I don't have a very long HDMI cable now so I can only show you later.

[Njk]

It was obvious to me as soon as I saw the oscilloscope that there is a capacitive glass touch sensor on top of the LCD screen same as all other oscilloscopes with touch or any tablet. The screen and capacitive glass touch sensor are two separate components.

It's not always necessary to use oversized touch screen panel. In handheld devices such as a tablet that has its whole top surface covered by glass, a wide bezel around the LCD is necessary, otherwise user can't hold the device without obscuring part of the picture by finger. So in that applications it's natural to use oversized touch screen. But when the screen is only a part of the front panel composition, the touch sensor panel can be of the same size as the LCD panel. Some touch sensitivity impairments in the edge areas can be worked around by don't placing GUI control elements there. That designs are also known. As for the oscilloscopes, it seems the oversized glass is a matter of fashion. With that trick, on the ad leaflets, the screen looks larger than it actually is. Never mind though.

8bit is just 256 so easy to fit 1:1 on any screen.

In DS/MSO1000Z series (8 bits), the LCD has 480 pixels in the Y direction. One waveform point takes 4 pixels (2x2). So only 200 ADC levels can be displayed in the drawing area, the rest 80 pixels are consumed by the top/bottom GUI elements. A waveform of pp amplitude greater than 200 levels always looks clipped. That was widely discussed here over the years. What I'm trying to say is that if similar approach is taken in the new model, one associated inconvenience is that it's not always easy for user to find out if the waveform is actually clipped because the amplitude has already reached full-scale ADC range or it's only visually clipped and there will be no clipping in the waveform data downloaded with SCPI commands. The scope does not provide related indication.

Besides, there are more interesting things, which are related to ENOB and stuff that is related to the analog circuitry. I'm hoping that will be revealed here soon. You can use 1000 bits ADC but with mismatching analog part the actual resolution will be not so great. It also affects the math function results such as FFT. In my opinion, Rigol can be differentiated by its FFT implementation. It's not so nice looking as that of the competitors, but it's fair because it does not provide user with false sense of confidence. No data or evident garbage is better than not reliable data that looks plausible. Economy-class analog part and a 12-bit ADC. An interesting combination.

[Fungus]

The only thing I'm not looking forward to is having the BNC connectors on the front. It takes up way more space on the bench like that. It didn't matter much in the days of huge CROs but as things get slimmer and slimmer it gets worse and worse.

The one true place for BNC connectors is along the top like Micsigs do. Down the side would be a second choice. On the front? 

Edit: Maybe something like this will help...

[egonotto]

Hello,

Can someone please post two wavefile in bin format with the following settings:
1 mV/div 0.05 ms/div 1 Mpts and
1 V/div 0.05 ms/div 1 Mpts.
And accompanying screenshots. 
Each with an open input and full bandwidth.

It is important that 1.25 GSa/s is used so that the device cannot sugarcoat the data.

If it's not too much work, corresponding files with 20 MHz bandwidth would be very nice.


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.

Thanks and best regards
egonotto

[Serg65536]

If DHO802's ADC chip is the same as DHO4000 (as the chip marking claims), and DHO1000 board is exactly the same (except for frontend output traces and missing one ADC chip), then it's theoretically possible to buy DHO802 (320$) and DHO1074 (1000$), to move ADC from 802 to 1074, to change frontend traces, to solder ADC power ICs, to flash 4804 firmware, and
enjoy 4600$ DHO4804 scope just for 1320$    (minus price of the DHO802 sold for parts)....
And I know, it's crazy idea 

[tv84]

And I know, it's crazy idea 

And if you program a custom FW, it can become even better that the DHO4804!!!

Now, let's land the ship and get back to work.

[Anthocyanina]

why couldn't they be bothered to properly align the dots of the graticule? or use the perfectly good looking and informative graticle from the previous series? 

[tv84]

why couldn't they be bothered to properly align the dots of the graticule? or use the perfectly good looking and informative graticle from the previous series? 

Maybe because of the benefits of having a Android resizeable screen that can have n resolutions... It can also have its drawbacks.

[Nominal Animal]

why couldn't they be bothered to properly align the dots of the graticule? or use the perfectly good looking and informative graticle from the previous series? 

They're obviously using OpenGL ES for the UI and the graticule, and making the typical coordinate errors for graphics programmers when applying scaling.

For example, if your graticule dots are logically a radius 1.0 dot, the display width is W units, height is H units, and origin is at the center of the screen, they will give the wrong answer as to at what coordinates the dot will be fully visible, partially visible, or fully hidden.  If they even care, that is.

It took quite a few years for games graphics programmers to learn this stuff, producing graphics with edges that did not exactly line up, so I'm not surprised Android-based oscilloscope app programmers do not have a hang of it yet either. 

[TurboTom]

...

They have to use FRAM. The current state has to be stored after almost every button press or knob twist. Flash or EEPROM would wear out in no time.

Yes, I agree, the "sane" EE should think like this. Yet, I remember some discussion several months ago about why certain Siglent instruments don't memorize configuration changes a certain time (a minute or so IIRC) before (hard) powering them down. It turned out that they store all the config data in flash memory since they didn't install an FRAM, and so they had to limit write access frequency.

Since the DHO800 / 900 series is Rigol's new "bottom-of-the-barrel" scope, I wasn't so sure they didn't economize the FRAM, hence I'm positively surprised to find it.

[ataradov]

There is no issues using regular flash for saving configuration. Your encoders have similar operating life to the flash. If you use wear leveling, your encoders and buttons will break sooner than the storage.

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

To me using FRAM for this sounds "insane". It is a huge overkill for no reason.

[tv84]

There is no issues using regular flash for saving configuration. Your encoders have similar operating life to the flash. If you use wear leveling, your encoders and buttons will break sooner than the storage.

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

To me using FRAM for this sounds "insane". It is a huge overkill for no reason.

I tend to disagree given the purpose. Agree that you could do it with flash but, given the usual "plain vanilla" access methods used to store this kind of info, some zones of the flash would wear out.

[Anthocyanina]

why couldn't they be bothered to properly align the dots of the graticule? or use the perfectly good looking and informative graticle from the previous series? 

They're obviously using OpenGL ES for the UI and the graticule, and making the typical coordinate errors for graphics programmers when applying scaling.

For example, if your graticule dots are logically a radius 1.0 dot, the display width is W units, height is H units, and origin is at the center of the screen, they will give the wrong answer as to at what coordinates the dot will be fully visible, partially visible, or fully hidden.  If they even care, that is.

It took quite a few years for games graphics programmers to learn this stuff, producing graphics with edges that did not exactly line up, so I'm not surprised Android-based oscilloscope app programmers do not have a hang of it yet either. 

I'll take it! i guess for 400$, the graticule alignment would be the least of one's worries

[ataradov]

I tend to disagree given the purpose. Agree that you could do it with flash but, given the usual "plain vanilla" access methods used to store this kind of info, some zones of the flash would wear out.

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.

Nobody would use that scope at -40 or 85 C and it would not be relevant in 20 years. A typical MCU flash at room temperature easily lasts over 100K cycles. I tried to do an experiment on some devices at room temp and I stared seeing erase/write issues as well over 1M cycles, but I suspect that retention and reliability would have suffered earlier. 

And if you use 10 sectors for wear-leveling, your scope will fall apart sooner than this flash will wear out.

In any case, all modern devices store settings in the flash and it is never an issue.