Rigol HDO1000 and HDO4000 12bit oscilloscopes launched in China

[thm_w]

Referring to the user guide this scope doesn’t have sin(x)/x interpolation and the display mode is vector only, to my knowledge it’s the same as in the MSO5000 scopes.
Check section 19.1, page 238 in the user guide.
(Attachment Link)

Did you even watch Daves video?   

I meant a display where the signal isn't being represented using signal theory math.

(or, at least, the best approximation to it which can be done within the constraints of the device)

If you turn off sin(x)/x then what do you use to display the signal? Linear interpolation?

Old school dot mode.
edit: can find some examples here https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg1174881/#msg1174881

[David Hess]

1M tests used an open input. If I used an external 50ohm termination then that's effectively the same as the 50 ohm mode, unless there is actually different paths for the 50ohm and 1M input which is usually not the case for scopes.
So that graph you just posted in correct. I thought you wanted an open input?

In a good design, noise is dominated by the impedance converter at the input, but there are several noise sources there.  The input FET has its inherent voltage noise, and usually horrible flicker noise because it is a UHF part.

In series with the FET gate as part of the protection circuit is a roughly 470 kilohm series resistance bypassed with like 1000 picofarads, so the thermal noise from this resistor has bandwidth of about 340 Hz which is likely obscured by flicker noise from the FET.  The shunt 1 megohm resistance is in parallel with about 15 picofarads, so its noise bandwdith is about 10 KHz and it contributes considerable low frequency noise; that is the increase in noise that you see when the 50 ohm termination is not present.

As far as "low noise", I measured Tektronix 7000 series 200 MHz vertical amplifiers from the 1970s and 1980s with 18 microvolts RMS noise over 100 MHz, which is considerably better than the same noise level over 20 MHz.  They perform better than most modern instruments because they use JFET instead of CMOS impedance converters, and have the advantage of being designed for a lower bandwidth; software bandwidth upgrades were for the future.  Besides the use of CMOS, an 800 MHz design will be higher noise even with bandwidth limiting because of the required parts selection.

The bandwidth is automatically switched at higher sensitivity volts/div settings because high noise levels lead to a largely meaningless display.  (1) This feature is hardly a new thing, and it was common in old oscilloscopes that supported x10 vertical magnification; activating the vertical magnification deliberately engaged the bandwidth limit to control noise.  (2) Another example of controlling noise is the Tektronix 7A13 differential comparator.  It necessarily has high input noise, like 100 microvolts over 100 MHz, because of its bootstrapped differential input configuration, so to support even a 1 mV/div sensitivity, it has a 5 MHz bandwidth limit; even 20 MHz would have been too high for its noise level.

Some early DSOs had noise levels approaching the quantization noise of their 8-bit digitizer, which is a little weird when you first see it.  It looks like the DSO is broken when there is just a straight line with an occasional peak-to-peak "bump" in it.

(1) This is also why you do not find vertical sensitivities greater than about 1 mV/div without bandwidth limiting or some type of noise reduction; the input noise is too high for it to make any sense.  In the past they considered even 2mV/div questionable.

(2) Instruments like these did not even *have* a separate bandwidth control.  If you wanted to limit the bandwidth, then you activated the x10 vertical magnification.

[David Hess]

For the comparison of the RMS noise with the 20 MHz filter enables the type of filter can make a difference, as the noise BW is different from the -3dB BW.

The noise bandwidth is always different from the -3-dB bandwidth because of the shape factor of the filter, unless you manage a brick wall.  A single pole rolloff, which will be typical for a 20 MHz filter, yields a noise bandwidth 1.6 times the -3dB bandwidth.  Even some old oscilloscopes use higher order filters, but it was pretty rare.  DSOs could of course do all kinds of weird things, but it is important to have a physical filter to prevent aliasing of the noise unless filtering is done during decimation.

[JeremyC]

Referring to the user guide this scope doesn’t have sin(x)/x interpolation and the display mode is vector only, to my knowledge it’s the same as in the MSO5000 scopes.
Check section 19.1, page 238 in the user guide.
(Attachment Link)

Did you even watch Daves video?   

Yes, I did. In min. 20:53 he mentioned that he can’t turn off sin(x)/x mode…
The reason is that the sin(x)/x interpolation is not implemented in this scopes.

 vector != sin(x)/x

Please check the user guide as I mentioned in my message.

[JeremyC]

The HDO4000 doesn’t have bode plot option, nor sin(x)/x

It's got Sinx/x, but you can't turn it off.

Referring to the user guide this scope doesn’t have sin(x)/x interpolation and the display mode is vector only, to my knowledge it’s the same as in the MSO5000 scopes.
Check section 19.1, page 238 in the user guide.
(Attachment Link)

Dave:
Could you try 100MHz square wave on this scope? The scope is 200MHz, and if it’s sin(x)/x interpolation you should see sine wave.
Maybe you’re correct and the user guide suck (?)

Edited:
I forgot it’s 4GS/s scope. Maybe decreasing sample rate to 1GS/s and 200 MHz square wave would be more adequate for this test.
I’m guessing decreasing sample rate in Rigol scopes can be accomplished by decreasing memory depth.

[AmericanLocomotive]

Can anyone explain to me what Agilent/Keysight does differently than anyone else that lets their scopes have highly responsive UIs? I watched Dave's video of the Rigol, and I'm just immensely disappointed by how clunky the UI seemed to operate. Input lag on the touchscreen, moving waveforms around causes all of the updating to stop, and the UI seems to slow to to like 8 FPS, and so on.

...then you go watch Dave's video of the Agilent 3000 series from 11 years ago, and the UI is consistently fast/responsive. The scope keeps updating even when moving things around on the screen, and the whole thing seems to run at a constant 30 (60?) FPS.

11 years later, and other scopes still don't match it. What's the deal here? You'd think 11 years of embedded CPU improvements (I saw the Rigol has a 6-core CPU!) would allow other manufactures to catch up. Does Keysight just do something inherently different with their architecture compared to everyone else?

[adonishong]

Can anyone explain to me what Agilent/Keysight does differently than anyone else that lets their scopes have highly responsive UIs? I watched Dave's video of the Rigol, and I'm just immensely disappointed by how clunky the UI seemed to operate. Input lag on the touchscreen, moving waveforms around causes all of the updating to stop, and the UI seems to slow to to like 8 FPS, and so on.

...then you go watch Dave's video of the Agilent 3000 series from 11 years ago, and the UI is consistently fast/responsive. The scope keeps updating even when moving things around on the screen, and the whole thing seems to run at a constant 30 (60?) FPS.

11 years later, and other scopes still don't match it. What's the deal here? You'd think 11 years of embedded CPU improvements (I saw the Rigol has a 6-core CPU!) would allow other manufactures to catch up. Does Keysight just do something inherently different with their architecture compared to everyone else?

IMHO, I will not consider this as an "ability" issue. As a product manager, I guess the requirement of "keep updating waveform when moving it around" is just not list in product requirement document ...

[Someone]

Can anyone explain to me what Agilent/Keysight does differently than anyone else that lets their scopes have highly responsive UIs? I watched Dave's video of the Rigol, and I'm just immensely disappointed by how clunky the UI seemed to operate. Input lag on the touchscreen, moving waveforms around causes all of the updating to stop, and the UI seems to slow to to like 8 FPS, and so on.

...then you go watch Dave's video of the Agilent 3000 series from 11 years ago, and the UI is consistently fast/responsive. The scope keeps updating even when moving things around on the screen, and the whole thing seems to run at a constant 30 (60?) FPS.

11 years later, and other scopes still don't match it. What's the deal here? You'd think 11 years of embedded CPU improvements (I saw the Rigol has a 6-core CPU!) would allow other manufactures to catch up. Does Keysight just do something inherently different with their architecture compared to everyone else?

The waveforms on those Agilent/Keysight scopes are drawn to the screen with an ASIC in hardware, so the CPU is just doing UI stuff. But even the Keysight stuff can be a little slow to respond some times and will stop acquisitions while moving traces. Other brands have done the same path with ASICs (R&S) and while the FPGA platforms that Rigol and Siglent use dont quite have the same throughput capabilities it is just a programming/system design choice that they feel slower/lag more, they could be very snappy with some work on the software side.

[EEVblog]

Can anyone explain to me what Agilent/Keysight does differently than anyone else that lets their scopes have highly responsive UIs? I watched Dave's video of the Rigol, and I'm just immensely disappointed by how clunky the UI seemed to operate. Input lag on the touchscreen, moving waveforms around causes all of the updating to stop, and the UI seems to slow to to like 8 FPS, and so on.

...then you go watch Dave's video of the Agilent 3000 series from 11 years ago, and the UI is consistently fast/responsive. The scope keeps updating even when moving things around on the screen, and the whole thing seems to run at a constant 30 (60?) FPS.

11 years later, and other scopes still don't match it. What's the deal here? You'd think 11 years of embedded CPU improvements (I saw the Rigol has a 6-core CPU!) would allow other manufactures to catch up. Does Keysight just do something inherently different with their architecture compared to everyone else?

The Keysight MegaZoom IV ASIC does the dedicated work drawing the screen:



The only thing that Keysight are "stuck" with is the internal 4M sample memory.
If the Megazoom V just had external memory it would still be a killer today.

[EEVblog]

It's got Sinx/x, but you can't turn it off.

Turning it off would produce a mathematically incorrect display.

Turning it off allows you to see what and where the actual samples are.
Digital scope have had switchable Linear and Sinx/x interpolation and also dot/line mode since time immortal for this very reason.

And Sinx/x isn't "mathematically correct", it's simply a way to get a closer approximation to what the actual signal might be doing between samples. And there are also right and wrogn ways to implement the display of sinx/x data too. Not being able to turn it off or turn on dot mode means you can't see how exactly they have implemented sinx/x on the display.

[2N3055]

Can anyone explain to me what Agilent/Keysight does differently than anyone else that lets their scopes have highly responsive UIs? I watched Dave's video of the Rigol, and I'm just immensely disappointed by how clunky the UI seemed to operate. Input lag on the touchscreen, moving waveforms around causes all of the updating to stop, and the UI seems to slow to to like 8 FPS, and so on.

...then you go watch Dave's video of the Agilent 3000 series from 11 years ago, and the UI is consistently fast/responsive. The scope keeps updating even when moving things around on the screen, and the whole thing seems to run at a constant 30 (60?) FPS.

11 years later, and other scopes still don't match it. What's the deal here? You'd think 11 years of embedded CPU improvements (I saw the Rigol has a 6-core CPU!) would allow other manufactures to catch up. Does Keysight just do something inherently different with their architecture compared to everyone else?

The Keysight MegaZoom IV ASIC does the dedicated work drawing the screen:



The only thing that Keysight are "stuck" with is the internal 4M sample memory.
If the Megazoom V just had external memory it would still be a killer today.

Yes an no. Megazoom scopes render waveform on tiny screens on even tinier screen area.They would need to to make a new one with higher resolution. Megazoom 4 screen would look like a thumbnail photo on screens of any of new touchscreen scopes. It's hard coded plotting area is 640x400. It would need to quadruple pixel count (screen area). Megazoom is fast because it deals with little data and because what it does is hardcoded. It calculates on decimated data, has very limited FFT points etc.. What many people say are virtues (fast response time for people who think that is most important feature) was made by sacrificing other capabilities. While there are many other people out there who think large memory, advanced measurements of full data etc.. are more important. Market seems to need both and both are being sold. Tool for the job.

[Kleinstein]

As long as the scope works with the full 4 GSPS the interpolation is not really critical  and it is also hard to tell if the interpolation is sinx/s or linear, as the sampling rate is much higher than the BW limit.
It can become relevant when the sampling rate is reduced. With the rather large memory and good ADC speed the cases where the sinx/x makes a difference are rare - so maybe they skipt it in favor of speed.

For the comparison of the RMS noise with the 20 MHz filter enables the type of filter can make a difference, as the noise BW is different from the -3dB BW.

The noise bandwidth is always different from the -3-dB bandwidth because of the shape factor of the filter, unless you manage a brick wall.  A single pole rolloff, which will be typical for a 20 MHz filter, yields a noise bandwidth 1.6 times the -3dB bandwidth.  Even some old oscilloscopes use higher order filters, but it was pretty rare.  DSOs could of course do all kinds of weird things, but it is important to have a physical filter to prevent aliasing of the noise unless filtering is done during decimation.

The noise curve with the 20 MHz filter shows a rather steep edge suggests that there is digital filterings. Not so sure that there is an actual analog fitler, as there are ranges where the noise comes up again, which is possible as an artifact from a simple digital filter. An analog fitler could reduce such artifacts of a simple (for performance reasons) digital filter.
Using the 20 MHz BW linit does not necessary mean a reduced sampling / data set. This was traditionally common when memory was limited, but with plenty of memory they could still keep the full data, or alt least more than absolutely needed. Using filtering during decimation is the logical method, especially for a low noise design.

[EEVblog]

Can anyone explain to me what Agilent/Keysight does differently than anyone else that lets their scopes have highly responsive UIs? I watched Dave's video of the Rigol, and I'm just immensely disappointed by how clunky the UI seemed to operate. Input lag on the touchscreen, moving waveforms around causes all of the updating to stop, and the UI seems to slow to to like 8 FPS, and so on.

...then you go watch Dave's video of the Agilent 3000 series from 11 years ago, and the UI is consistently fast/responsive. The scope keeps updating even when moving things around on the screen, and the whole thing seems to run at a constant 30 (60?) FPS.

11 years later, and other scopes still don't match it. What's the deal here? You'd think 11 years of embedded CPU improvements (I saw the Rigol has a 6-core CPU!) would allow other manufactures to catch up. Does Keysight just do something inherently different with their architecture compared to everyone else?

The Keysight MegaZoom IV ASIC does the dedicated work drawing the screen:



The only thing that Keysight are "stuck" with is the internal 4M sample memory.
If the Megazoom V just had external memory it would still be a killer today.

Yes an no. Megazoom scopes render waveform on tiny screens on even tinier screen area.They would need to to make a new one with higher resolution.

Yes, that too, and whatever newer features are around. The point being that they probably wouldn't have to radically change the underlying structure, or try and go to 10Mwfm/c or something. The 1Mwfm/s is still industry leading stuff 11.5 years later.

[Fungus]

Out of curiosity: Where is the noise floor (dB) in FFT mode on this 'scope?

[rf-loop]

Can anyone explain to me what Agilent/Keysight does differently than anyone else that lets their scopes have highly responsive UIs? I watched Dave's video of the Rigol, and I'm just immensely disappointed by how clunky the UI seemed to operate. Input lag on the touchscreen, moving waveforms around causes all of the updating to stop, and the UI seems to slow to to like 8 FPS, and so on.

...then you go watch Dave's video of the Agilent 3000 series from 11 years ago, and the UI is consistently fast/responsive. The scope keeps updating even when moving things around on the screen, and the whole thing seems to run at a constant 30 (60?) FPS.

11 years later, and other scopes still don't match it. What's the deal here? You'd think 11 years of embedded CPU improvements (I saw the Rigol has a 6-core CPU!) would allow other manufactures to catch up. Does Keysight just do something inherently different with their architecture compared to everyone else?

The Keysight MegaZoom IV ASIC does the dedicated work drawing the screen:



The only thing that Keysight are "stuck" with is the internal 4M sample memory.
If the Megazoom V just had external memory it would still be a killer today.

Yes an no. Megazoom scopes render waveform on tiny screens on even tinier screen area.They would need to to make a new one with higher resolution. Megazoom 4 screen would look like a thumbnail photo on screens of any of new touchscreen scopes. It's hard coded plotting area is 640x400. It would need to quadruple pixel count (screen area). Megazoom is fast because it deals with little data and because what it does is hardcoded. It calculates on decimated data, has very limited FFT points etc.. What many people say are virtues (fast response time for people who think that is most important feature) was made by sacrificing other capabilities. While there are many other people out there who think large memory, advanced measurements of full data etc.. are more important. Market seems to need both and both are being sold. Tool for the job.

And it (IV) do not have digital trigger engine at all. (afaik ...  Correct if I'm wrong.)

[EEVblog]

The HDO4000 doesn’t have bode plot option, nor sin(x)/x

It's got Sinx/x, but you can't turn it off.

Referring to the user guide this scope doesn’t have sin(x)/x interpolation and the display mode is vector only, to my knowledge it’s the same as in the MSO5000 scopes.
Check section 19.1, page 238 in the user guide.
(Attachment Link)

Have you watched my video?
The zoomed in waveform in not linear vector based, it's sinx/x
I asked Rigol if I could turn off Sinx/x and they said no I can't.
I do know what that manual is showing, but that's not how the scope i have actually works.

[coppice]

I meant a display where the signal isn't being represented using signal theory math.

(or, at least, the best approximation to it which can be done within the constraints of the device)

If you turn off sin(x)/x then what do you use to display the signal? Linear interpolation?

WTF is signal theory math?

If you turn off sin(x)/x you get the raw samples, to treat how you will. If you turn on sin(x)/x you get one filtered version of the samples, which is probably the best kind of filter for a broad range of applications. However, like all filters it has plus and minus points, especially with regard to how the phase get mangled. There is nothing magically "correct" about sin(x)/x.

[nctnico]

I meant a display where the signal isn't being represented using signal theory math.

(or, at least, the best approximation to it which can be done within the constraints of the device)

If you turn off sin(x)/x then what do you use to display the signal? Linear interpolation?

WTF is signal theory math?

If you turn off sin(x)/x you get the raw samples, to treat how you will. If you turn on sin(x)/x you get one filtered version of the samples, which is probably the best kind of filter for a broad range of applications. However, like all filters it has plus and minus points, especially with regard to how the phase get mangled. There is nothing magically "correct" about sin(x)/x.

No, sin x/ x is not a filter!  sin x/x is a method for constructing a visible signal from samples. By definition, the trace you get from sin x/x reconstruction goes through all the sample points. There is no phase mangling, no adding fictional information or whatever.

[coppice]

I meant a display where the signal isn't being represented using signal theory math.

(or, at least, the best approximation to it which can be done within the constraints of the device)

If you turn off sin(x)/x then what do you use to display the signal? Linear interpolation?

WTF is signal theory math?

If you turn off sin(x)/x you get the raw samples, to treat how you will. If you turn on sin(x)/x you get one filtered version of the samples, which is probably the best kind of filter for a broad range of applications. However, like all filters it has plus and minus points, especially with regard to how the phase get mangled. There is nothing magically "correct" about sin(x)/x.

No, sin x/ x is not a filter!  sin x/x is a method for constructing a visible signal from samples. By definition, the trace you get from sin x/x reconstruction goes through all the sample points. There is no phase mangling, adding fictional information or whatever.

At low frequencies it works really well. The closer you get to the Shannon rate the more fiction occurs between the actual samples, and most displays don't even highlight where the actual samples are. You can get very misleading images.

[Fungus]

WTF is signal theory math?

Start here: https://en.wikipedia.org/wiki/Signal_processing

[nctnico]

I meant a display where the signal isn't being represented using signal theory math.

(or, at least, the best approximation to it which can be done within the constraints of the device)

If you turn off sin(x)/x then what do you use to display the signal? Linear interpolation?

WTF is signal theory math?

If you turn off sin(x)/x you get the raw samples, to treat how you will. If you turn on sin(x)/x you get one filtered version of the samples, which is probably the best kind of filter for a broad range of applications. However, like all filters it has plus and minus points, especially with regard to how the phase get mangled. There is nothing magically "correct" about sin(x)/x.

No, sin x/ x is not a filter!  sin x/x is a method for constructing a visible signal from samples. By definition, the trace you get from sin x/x reconstruction goes through all the sample points. There is no phase mangling, adding fictional information or whatever.

At low frequencies it works really well. The closer you get to the Shannon rate the more fiction occurs between the actual samples, and most displays don't even highlight where the actual samples are. You can get very misleading images.

Again no. There is a limit where sin x/x stops working and that is slightly over fs / 2.5 . IOW: sin x/x works for cases where the samplerate is 2.5 times the bandwidth of the signal. There is no fiction involved.

[Fungus]

At low frequencies it works really well. The closer you get to the Shannon rate the more fiction occurs between the actual samples, and most displays don't even highlight where the actual samples are. You can get very misleading images.

I'm not sure what "Shannon rate" has to do with it but with sin(x)/x you know the curve passes through all the sample points. There will be no points outside the displayed curve.

Maybe you can explain how seeing the sample points would lead to less "misleading" images. Do you have a better reconstruction filter in your head? One that can deal with aliasing, etc.?

I'd be very surprised is this 'scope doesn't have a "dot" mode so you can use it.

The manual that was posted earlier appears unfinished, I wouldn't rely on it for a complete+accurate list of features.

[Kleinstein]

The interpolation filter can not deal with aliasing. This happens during display, not during taking the data. The interpoation gets more important when the bandwidth is relatively large compared to the sampling rate. The sinx/x way is trying to get a smooth curve without sharp peaks that does not contain much frequency content high then fs/2, as there is not way to know how the part beyound fs/2 is. Essentially not amplitude is somewhat safe bet.

With the 200 MHz version and 4 GSPS the interpolation is not critical as there is essentially no aliasing or need to reconstruct the part close to the limit. One may get something close to a sinx/x reconstruction if part the 200 MHz BW limit is actually realized digital and not analog. The curve may than look quite a bit like a sinx/x interpolated signal, though with more points than one would have with sinx/x.

For looking at the details of the scope performance it would help to also get the raw dot mode. For normal use it should not really matter with the relatively high sampling rate. This may be a bit different with 4 channels and thus 1 GSPS and than the top 800 MHz BW version. In this case the interpolation makes a difference. Here not really.

[Fungus]

The interpolation filter can not deal with aliasing.

Hence ntnico's statement that: "sin x/x works for cases where the samplerate is 2.5 times the bandwidth of the signal."

One may get something close to a sinx/x reconstruction if part the 200 MHz BW limit is actually realized digital and not analog.

This sure looks like a digital filter to me...

[maxwell3e10]

The manual that was posted earlier appears unfinished, I wouldn't rely on it for a complete+accurate list of features.

I am not sure if it's the manual or the scope that is unfinished. For example, the manual talks about a header in the binary file. But the files Dave posted contained no such header (assuming they come directly from saving on scope).