Rigol's New DHO800 Oscilloscope unbox & teardown

[Fungus]

...
At the moment you can buy the Siglent SDS1104X-E at Batronix for € 386.10 (net).
The Rigol DHO814 costs € 499.- (net).

Except you wouldn't buy the 814, you'd buy the €399 804 and hack it into an 814.
...

And he would buy the € 386.10 SDS1104X-E and hack it into an SDS1204X-E

The DHO804 might be hackable to 250Mhz. Time will tell...

[skander36]

All noise measurements should be done at 1mV/div. 200uV and 500uV/div are software magnifications. Front end does only 1mV/div in hardware, unlike, for instance, SD2000X HD that have actual 500uV/div range.

Dave has obtained that value (18 uV) with those settings: 1mV/div, 1ms, BW filter, 50ohm input. Without 50 ohm the noise increase at 42-43. With HDO1000 I have obtained the same values putting a 50 ohm terminator on input of the scope.
I am curious what AC RMS value you obtain with SD2000X HD with the same parameters.
Maybe Tautech can post AC RMS value for SDS 1000X HD with the same parameters.
 

[Nikki Smith]

For the SD card Dave dumped, it really looks to me like a bog-standard Android system image.
One that has not been optimized, and is, uh, quite "vanilla", indicating that with some systems integration work, the boot-up time could be shortened significantly, for example.  I wonder how receptive Rigol would be towards such suggestions?
(It really depends on whether they used some external team to cobble something together for them, or whether they set up their own team that is still getting up to speed on how to optimize Android for appliance use.  I'm really hoping for the latter, because that means future updates could be really nice for users, also showing how to leverage their chosen hacker-friendly stance for actually creating a better end product.  Time will tell.)

How realistic do you think it would be for an external team to cobble together a low-power standby mode? Put the RK3399 into a low power mode, turn off the screen and a low power state for the Xilinx FPGA? Obviously keeping the RAM state. Then "instant on" if any button is pressed?

Presumably Android has a lot of that built-in as every tablet & smartphone needs to preserve battery life?

[2N3055]

All noise measurements should be done at 1mV/div. 200uV and 500uV/div are software magnifications. Front end does only 1mV/div in hardware, unlike, for instance, SD2000X HD that have actual 500uV/div range.

Dave has obtained that value (18 uV) with those settings: 1mV/div, 1ms, BW filter, 50ohm input. Without 50 ohm the noise increase at 42-43. With HDO1000 I have obtained the same values putting a 50 ohm terminator on input of the scope.
I am curious what AC RMS value you obtain with SD2000X HD with the same parameters.
Maybe Tautech can post AC RMS value for SDS 1000X HD with the same parameters.

I don't have time to search right now for details, but I published data in 2000X-HD.

It was around 22uV Stdev (AC RMS) with those settings at 50 Ω, at 1MΩ around 32 uV Stdev.

But make a note that when you enable 20 MHz BW on Rigol it enables lowpass filtering in software.
That is equivalent of enabling ERES on Siglent, which Siglent does not do automatically.

If we enable appropriate ERES then we get 17-18uV at 50Ω, and 29-30 at 1 MΩ.

Make note that Siglent has less noise at higher frequencies and Rigol a bit less at low frequencies.

[RAPo]

Reading about fans, touchscreens, Android, binwalks, etc. is all very good.

But I want to see what bugs I can expect in a few weeks.
So Dave, please do a bugs bonaza/40 minutes rant video just like you did for the MSO5000.

[mawyatt]

I don't think Siglent is working on any ASICs, and without them? Not gonna happen at this price point.

I tend to agree.

Same here!! Taking on an ASIC development involving a custom relative High Speed and Resolution ADC is a huge undertaking, both risk and financial-wise.

It took Rigol many years and two or three iterations to get it right, eg. The MSO5000 series was ASIC-based but quite noisy.

I could be wrong but it seems they started work on the ASIC after the DS1054Z was  launched. That's how long it took them.

Think we know where the 12 bit ADC design came from, and Rigol hedged their bets by licensing this IP

Where? Surely they don't need to license an ADC - it's a well-known tech.

Well known to whom may I ask

Obviously you have no clue as to what's involved in actual ASIC chip design, much less an ADC, and much more less than a moderately high speed/resolution ADC that Rigol has developed. Very few can do this, and without significant "outside" help Rigol didn't pull this off by themselves.

You can learn semiconductor physics to details you never were exposed to in grad school, spend years in the lab playing around with ADCs, read all the IEEE papers you want, learn and play around with exotic IC layout tools that make PCBs look like kindergarden, learn and become proficient in 2 and 3D field solvers, get very comfortable and extremely proficient with many Cadence exotic tools (this is not Spice!!), and so on, then you might have a snowballs chance in a very hot place of pulling off an ADCs like Rigols.

You can't make changes like add components, add jumpers, cut traces, change component types, change component values, move components, easily view circuit waveform details,  add heat sinks and so on with a custom chip design. Have you ever designed anything that worked from the get-go without a single change to anything, then look at the detailed complexity of a typical ADC IC, the required precision, intrinsic noise, timing, routing, coupling (yes femtofarads make a difference), thermal, analog input, digital I/O, power supply sensitivity, reference sensitivity & drift, and so on, then consider the ADC we are discussing!! Now consider the cost and time of correcting a single design error of almost an infinite possible variety, or overlooked parameter, the rerun fab costs are huge ($M), and the timeline for a rerun can be a fractions of a year!!

So one should not be surprised that it's takes years to initially develop such an ADC, and more years to get it right!!

The folks that can do this are few and likely not employed by Rigol, nor Siglent for that matter, they are good enough to write their own paychecks, and worth every penny

Anyway, to just write this off as "Surely they don't need to license an ADC - it's a well-known tech" indicates you a clueless about the what's involved

Best,

[mawyatt]

But make a note that when you enable 20 MHz BW on Rigol it enables lowpass filtering in software.
That is equivalent of enabling ERES on Siglent, which Siglent does not do automatically.

If we enable appropriate ERES then we get 17-18uV at 50Ω, and 29-30 at 1 MΩ.

Make note that Siglent has less noise at higher frequencies and Rigol a bit less at low frequencies.

This might hint that Rigol's custom input chip is implemented in SiGe BiCMOS rather than pure CMOS, since the SiGe bipolar transistors have lower intrinsic 1/f corners.

Someday maybe "noopy" will get ahold of one of these Rigol custom chip sets and we can have a look inside

Best,

[skander36]

It was around 22uV Stdev (AC RMS) with those settings at 50 Ω, at 1MΩ around 32 uV Stdev.

But make a note that when you enable 20 MHz BW on Rigol it enables lowpass filtering in software.
That is equivalent of enabling ERES on Siglent, which Siglent does not do automatically.

If we enable appropriate ERES then we get 17-18uV at 50Ω, and 29-30 at 1 MΩ.

Make note that Siglent has less noise at higher frequencies and Rigol a bit less at low frequencies.

This make me interested about 1000X HD. I'm curious enough to wait for it ...

[Mortymore]

...
At the moment you can buy the Siglent SDS1104X-E at Batronix for € 386.10 (net).
The Rigol DHO814 costs € 499.- (net).

Except you wouldn't buy the 814, you'd buy the €399 804 and hack it into an 814.
...

And he would buy the € 386.10 SDS1104X-E and hack it into an SDS1204X-E

The DHO804 might be hackable to 250Mhz. Time will tell...

That would be great, but 4 new probes to comply with the increased BW (70 or 100MHz -> 250MHz), may be needed.
As far as I know, there's no need for new probes in the Siglent case in consideration.

What probes came with the 804/814? I don't recall to see that

PS: I was dreaming with them being all the same model from DHO802 to DHO924 

[RAPo]

From the spec sheet:

DHO814/DHO804: Passive Probe x4 (150 MHz)
DHO812/DHO802: Passive Probe x2 (150 MHz)

DHO924/DHO924S: Passive Probe x4 (350 MHz)         
DHO914/DHO914S: Passive Probe x4 (150 MHz)         

[Aldo22]

Thank you!

...
At the moment you can buy the Siglent SDS1104X-E at Batronix for € 386.10 (net).
The Rigol DHO814 costs € 499.- (net).

Except you wouldn't buy the 814, you'd buy the €399 804 and hack it into an 814.
...

And he would buy the € 386.10 SDS1104X-E and hack it into an SDS1204X-E

The DHO804 might be hackable to 250Mhz. Time will tell...

Yes, time will tell.
It may simply be too early for these considerations.
Anyway, the DHO814 doesn't seem to be a good choice according to this price list.
€ 100.- more (net) for only 30MHz more? Nothing else is different there, right?
Then rather put another hundred on it for a DHO914.

The SDS1104X-E is still not a bad option for € 386.10 (net).

If 8-bit is really "dead", maybe these devices will become cheaper.
Time will tell... 

[Nominal Animal]

Most of the systems integrations teams doing this stuff know too little about Linux and Android to do it "properly".  This has been so ever since wireless routers started using Linux, and I see no significant change in quality, except possibly when they simply fork OpenWRT and add their own look-and-feel.  (Do note that OpenWRT, while good, isn't any kind of a pinnacle either; it's very generic and modular, is all.)

For the SD card Dave dumped, it really looks to me like a bog-standard Android system image.
One that has not been optimized, and is, uh, quite "vanilla", indicating that with some systems integration work, the boot-up time could be shortened significantly, for example.  I wonder how receptive Rigol would be towards such suggestions?
(It really depends on whether they used some external team to cobble something together for them, or whether they set up their own team that is still getting up to speed on how to optimize Android for appliance use.  I'm really hoping for the latter, because that means future updates could be really nice for users, also showing how to leverage their chosen hacker-friendly stance for actually creating a better end product.  Time will tell.)

How realistic do you think it would be for an external team to cobble together a low-power standby mode? Put the RK3399 into a low power mode, turn off the screen and a low power state for the Xilinx FPGA? Obviously keeping the RAM state. Then "instant on" if any button is pressed?

Sleep modes for the RK3399 are supported by the kernel already, so it's really only a matter of the FPGA.  The FPGA is a black box; I don't know if they even implemented software power control for it.  Anything else is doable.  Even hibernation (suspend to disk), although I wouldn't want to do that with an SD-card based storage.

Thus, the answer is: it depends on how they control the power to the FPGA.  If the control is sane-ish, very realistic.  If there is no software power control, and the FPGA circuits are designed to be powered whenever the power is on, then it won't work.


I myself have much 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.  Something like 15 seconds would sound more reasonable for this hardware, although the SD card could be a bottleneck here.  Not necessarily the bandwidth, but the IOPs, i.e. scattered small-file read speed.  On SD cards, it is often under 1 MB/s.  The maximum bandwidth for the SD card on the RK3399 is 104 MB/s per SD3.0.

Note that using the eMMC 5.1 HS400 interface that the same subsystem on RK3399 supports as an alternative (but would use more pins than SD card) would top at 400 MB/s.  This alone would not make a big difference to the boot time, I believe, but it would allow options with better scattered small-file read speed.

Presumably Android has a lot of [power state and sleep stuff] built-in as every tablet & smartphone needs to preserve battery life?

Absolutely.  There are even tools designed to help linearize the file access patterns on bootup, to speed up booting for devices that tend to have slow scattered small file I/O access.  The vendors don't do their own tools for this, they use the standard Android tools to finesse their systems integration.  Which, I must admit, on phones (and most TVs and TV boxes) is pretty impressive, overall.  If I recall correctly, I saw some of these in the system image Dave grabbed –– but I only did a quick look-see to get an overview, not any kind of examination.

Hibernation, also known as suspend-to-disk, would also be a viable option if the mass storage medium was more reliable.  I don't think phones use that (because the radios need to be on or wake up regularly), so it is rare on Android; but the kernel does have the necessary doodads for this, and it is widely used in Linux.  here is a Linux ARM suspend to disk summary from 2014, for example.

[RAPo]

Good thinking.

Then rather put another hundred on it for a DHO914.

The SDS1104X-E is still not a bad option for € 386.10 (net).

If 8-bit is really "dead", maybe these devices will become cheaper.

[RoGeorge]

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/

[2N3055]

...
At the moment you can buy the Siglent SDS1104X-E at Batronix for € 386.10 (net).
The Rigol DHO814 costs € 499.- (net).

Except you wouldn't buy the 814, you'd buy the €399 804 and hack it into an 814.
...

And he would buy the € 386.10 SDS1104X-E and hack it into an SDS1204X-E

The DHO804 might be hackable to 250Mhz. Time will tell...

not with 312.5 MSp/s

[2N3055]

Apart from 45 seconds boot time not really being a problem (like Martin says, you need to achieve working temp) scope is not a phone or a video game. There is significant circuitry to be initialized, FPGA loaded, self test, calibrations, verifications...

[Aldo22]

Apart from 45 seconds boot time not really being a problem (like Martin says, you need to achieve working temp) scope is not a phone or a video game. There is significant circuitry to be initialized, FPGA loaded, self test, calibrations, verifications...

It takes 54 seconds from pressing the power button until the splash screen disappears.
It takes about 8 seconds after switching on until only the splash screen appears.

This is a long time. SDS1104X-E is ready after about 25 seconds afair.
And you don't always want to measure, especially in the beginning you might just want to look up an option in the menu or check the version etc..

You can argue that it doesn't bother you, but it's not a plus, just like the howling fan isn't desirable.

[Fungus]

So one should not be surprised that it's takes years to initially develop such an ADC, and more years to get it right!!

They did take years.

The folks that can do this are few and likely not employed by Rigol, nor Siglent for that matter, they are good enough to write their own paychecks, and worth every penny

What prevents Rigol from hiring that person?

[2N3055]

It was around 22uV Stdev (AC RMS) with those settings at 50 Ω, at 1MΩ around 32 uV Stdev.

But make a note that when you enable 20 MHz BW on Rigol it enables lowpass filtering in software.
That is equivalent of enabling ERES on Siglent, which Siglent does not do automatically.

If we enable appropriate ERES then we get 17-18uV at 50Ω, and 29-30 at 1 MΩ.

Make note that Siglent has less noise at higher frequencies and Rigol a bit less at low frequencies.

This make me interested about 1000X HD. I'm curious enough to wait for it ...

I would wait for DHO800 to be released to sales and actually available to test before decision, regardless of 1000X HD..

I see too many little (and not so little) possible annoyances of not fully finished product with many weird design choices and price mandated compromises...

And you can see lot's of people that would buy it to tweak fan and play with it.
Which is fully OK, if your hobby is playing with the scope. If you want to do things with the scope in reliable manner and use to do other electronics (hobby and/or pro) I would wait and see how it actually works in real life.
Just a good frontend and 12 bit is not enough if scope as a whole is limited or avkward and buggy. There is an Owon hires scope for quite some time on market. It never was much of a sucess, because hires is only part of the story.

[2N3055]

Apart from 45 seconds boot time not really being a problem (like Martin says, you need to achieve working temp) scope is not a phone or a video game. There is significant circuitry to be initialized, FPGA loaded, self test, calibrations, verifications...

It takes 54 seconds from pressing the power button until the splash screen disappears.
It takes about 8 seconds after switching on until only the splash screen appears.

This is a long time. SDS1104X-E is ready after about 25 seconds afair.
And you don't always want to measure, especially in the beginning you might just want to look up an option in the menu or check the version etc..

You can argue that it doesn't bother you, but it's not a plus, just like the howling fan isn't desirable.

My Keysight 3000T that was a 12kUSD scope boots for 90 seconds..
It is not a plus but is irrelevant in most cases. I have bad back, so need an occasional excuse to stand up and stretch legs a bit. Highly recommended to all.

[switchabl]

The DHO804 might be hackable to 250Mhz. Time will tell...

not with 312.5 MSp/s

That's the same as the DHO900 though. I mean, on the one hand, if the frontend has the bandwidth anyway and you have a way to switch filters for single-channel mode, why not. On the other hand, neither the datasheet nor the manual seems to mention lower bandwidth with two/four channels active. So maybe they just continue the questionable trend of entry-level scopes having ever higher bandwidths without the sample rate to back it up.

Apart from 45 seconds boot time not really being a problem (like Martin says, you need to achieve working temp) scope is not a phone or a video game. There is significant circuitry to be initialized, FPGA loaded, self test, calibrations, verifications...

Nah, that's just normal Android boot time. I would be surprised if hardware initialization is more than a couple of seconds.

[pmaster]

I myself have much 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.  Something like 15 seconds would sound more reasonable for this hardware, although the SD card could be a bottleneck here. 

One reason for the long bootup time is the fact that Rigol is using an userdebug build. An user build (which doesn't offer e.g. adb root) boots much faster. I'd assume 5-20 seconds boot time reduction.

[Nikki Smith]

How realistic do you think it would be for an external team to cobble together a low-power standby mode? Put the RK3399 into a low power mode, turn off the screen and a low power state for the Xilinx FPGA? Obviously keeping the RAM state. Then "instant on" if any button is pressed?

Sleep modes for the RK3399 are supported by the kernel already, so it's really only a matter of the FPGA.  The FPGA is a black box; I don't know if they even implemented software power control for it.  Anything else is doable.  Even hibernation (suspend to disk), although I wouldn't want to do that with an SD-card based storage.

Thus, the answer is: it depends on how they control the power to the FPGA.  If the control is sane-ish, very realistic.  If there is no software power control, and the FPGA circuits are designed to be powered whenever the power is on, then it won't work.

Thanks. I don't pretend to know much about FPGAs, but I did glance over the datasheet (see Power Management, p.22)
https://www.datasheets.com/en/part-details/xc7z015-2clg485i-xilinx-61370287#datasheet

it sounds like the full sleep mode is complex because it relies on Rigol having wired it with independent power rails for logic & processing, and you'd have to reconfigure all the logic when coming out of standby (how long does that take?). Alternatively "PS Clock Control" can take the (FPGA) Arm processor from 766MHz to 30MHz which would save power in a standby mode, but I don't know if that would also underclock the power-hungry logic?

[Aldo22]

Nah, that's just normal Android boot time.

Yes.
The difference is that any "normal" Android device can go into sleep/suspend/standby mode, so you usually don't have to boot it.
That is just missing here.

[Fungus]

The difference is that any "normal" Android device can go into sleep/suspend/standby mode, so you usually don't have to boot it.
That is just missing here.

If the FPGA and/or ASICs can't  be powered down then it might still consume a lot of power and need the fan.

People would complain about that, too.