NEW Keysight HD3

[Someone]

In many cases the trigger is in the center of the screen. So there is only half a screen (and maybe a little overhead for zoom out) worth of data with before the visible trace is done. So allowing for a retrigger after half a screen would not be that odd. They just need to also process the pre-trigger data.
The rate on how fast they can process the pre-trigger data could limit the speed. It could still be possible to handle the data faster than new data coming in (especially at lower samplig rates), or allow a new trigger when just processing old pre-trigger data.

It doesn't matter fundamentally where the trigger position is, as long as it is on the screen. If the trigger is in the middle, then after collecting the data on the right half of the screen, the scope has to wait to collect enough pre-trigger data before it can trigger again. Otherwise, it can't fill in all the data on the left.

Assume the scope is always putting all the samples to memory, why does it have to stop/wait ? There is no fundamental/physical requirement for the scope to stop putting ADC data into memory.

It's like someone who insists that vehicles have a limited range because of the size of the fuel tank.... until you add in flight/motion refuelling. Same thing here.

Scopes can continuously put all samples into memory otherwise pretrigger memory wouldn't work.
What most (all? general purpose) oscilloscopes do once a trigger has arrived is stop collecting samples, and then transform the captured waveform to the screen view.
There is no need to stop collecting samples if the processing/transform can be done faster than the incoming data.

So, even slightly exceeding 1 MHz update rate in this case is akin to exceeding slightly the speed of light - its impossible. Either Dave's measurements are wrong (like counting both rising and falling edges of the trigger out) or the scope does some very creative interpretation of the trigger out (like outputting trigger signal even if it does not correspond to a new waveform record)

n number of scopes could be chained with their trigger out -> trigger in of the next scope, using an edge-then-edge trigger to overlap their captures as per the image above. There is nothing stopping a single device/object doing the same thing. If it can be cobbled together out of off-the-shelf parts today then it is clearly not impossible.

[Martin72]

I've just had a look at the data sheet...
Since even the standard decoder types are only optional, I think it's a bit poor.
What would interest me, however, is how to read the information on sample rate and memory.
Max 3.2 GSa/s/channel, does this mean that if all 4 channels are active, the sample rate remains at max 3.2GSa/s?
Or is a distinction made between interleaved and non-interleaved, as is usual elsewhere?
The same applies to the memory:
Max 100Mpts (optional...What else) per channel.
In other words, if all channels are active, does each channel have a maximum of 100Mpts available?

[2N3055]

I've just had a look at the data sheet...
Since even the standard decoder types are only optional, I think it's a bit poor.
What would interest me, however, is how to read the information on sample rate and memory.
Max 3.2 GSa/s/channel, does this mean that if all 4 channels are active, the sample rate remains at max 3.2GSa/s?
Or is a distinction made between interleaved and non-interleaved, as is usual elsewhere?
The same applies to the memory:
Max 100Mpts (optional...What else) per channel.
In other words, if all channels are active, does each channel have a maximum of 100Mpts available?

From what I understood, there are 4x 3.2GS/s ADC and 4x100MPts of memory, each ADC with it's own memory bank.
They did that right...

[Martin72]

Indeed.

[KungFuJosh]

I skip straight to the warranted (worst case) specs. 

Sounds like me when I go straight to the 1 star reviews on Amazon. 😉

[gslick]

The same applies to the memory:
Max 100Mpts (optional...What else) per channel.

Just buy one before the end of 2024 and get the 100 MPts/channel option for free:

Eligible Products
InfiniiVision HD3 Series Oscilloscopes
Model Number Description
HD302MSO InfiniiVision 300 HD-Series Mixed Signal Oscilloscope, 2+16 Channel
HD304MSO InfiniiVision 300 HD-Series Mixed Signal Oscilloscope, 4+16 Channel
Free 100 MPts/channel memory model number for the HD3 Series: HD300MSO-100
How to Claim Your Free Software
• Buy an eligible oscilloscope online at www.keysight.com/find/buyonline
• Contact a Keysight-authorized partner to place an order at www.keysight.com/find/partners
• Complete the claim form after receiving your purchase at www.keysight.com/find/HD3memoryclaim
• Contact us if you have any questions regarding this promotion

[Martin72]

If I had 10000€ over for a scope and had to decide between an HD3 (would be about the entry price for the 200Mhz model) or MX04 (sorry, but Siglent doesn't have a 12 bit scope for that price, only from 20000), I would tend towards the MX04.
What really bothers me about the Keysight is the small screen.
The thing costs so much money, why does it have a 10” screen....
Siglent SDS6000A (only available here as 8bit, so no competition) has 12“, Lecroy WS4000HD has 12”, R&S MX04 has 15”....
Why the hell only 10”....

[David Hess]

Assume the scope is always putting all the samples to memory, why does it have to stop/wait ? There is no fundamental/physical requirement for the scope to stop putting ADC data into memory.

...

Scopes can continuously put all samples into memory otherwise pretrigger memory wouldn't work.
What most (all? general purpose) oscilloscopes do once a trigger has arrived is stop collecting samples, and then transform the captured waveform to the screen view.
There is no need to stop collecting samples if the processing/transform can be done faster than the incoming data.

There are several different reasons:

1. The trigger rearm time may be significant.  This is not a problem now with digital triggering, but not all triggering circuits have high throughput.

2. Processing of the acquisition record may not keep up with the digitizer.  DPO style DSOs solve this by writing into the display record in real time.

3. Bandwidth of the acquisition memory may not support simultaneous full speed access from the digitizer and processor.

[EEVblog]

What really bothers me about the Keysight is the small screen.
The thing costs so much money, why does it have a 10” screen....
Siglent SDS6000A (only available here as 8bit, so no competition) has 12“, Lecroy WS4000HD has 12”, R&S MX04 has 15”....
Why the hell only 10”....

My guess would be because they started the desing of the Megazoom V ASIC many years ago (6-7 years maybe?) and unlike other scope designs, the screen resolution is baked into the ASIC to get the high update rate which no one else can match.
Megazoom IV was 800x480 and they figured that 1280x800 was a decent enough step up for Megazoom V.
Then Full HD 1920x1080 scopes came out and they couldn't go back and change the ASIC at that point.
As for actual size, 10.1", maybe they just wanted a smaller scope for market reasons. Not everyone wants a big scope. The 4000X for example is 12" but still only had the same old 800x600 resolution.

I'd expect to see a bigger screen HD4 version at some point. But I doubt you'll see a full HD resolution screen.

[EEVblog]

From what I understood, there are 4x 3.2GS/s ADC and 4x100MPts of memory, each ADC with it's own memory bank.
They did that right...

Correct. Whether or not that's 4 x physical ADC chips we'll have to wait for the teardown.

[Someone]

Assume the scope is always putting all the samples to memory, why does it have to stop/wait ? There is no fundamental/physical requirement for the scope to stop putting ADC data into memory.

...

Scopes can continuously put all samples into memory otherwise pretrigger memory wouldn't work.
What most (all? general purpose) oscilloscopes do once a trigger has arrived is stop collecting samples, and then transform the captured waveform to the screen view.
There is no need to stop collecting samples if the processing/transform can be done faster than the incoming data.

There are several different reasons:

1. The trigger rearm time may be significant.  This is not a problem now with digital triggering, but not all triggering circuits have high throughput.

2. Processing of the acquisition record may not keep up with the digitizer.  DPO style DSOs solve this by writing into the display record in real time.

3. Bandwidth of the acquisition memory may not support simultaneous full speed access from the digitizer and processor.

Yes, as I keep saying there are practical/economic reasons why scopes do not currently process faster than the incoming data. But that does not make it impossible (which maxwell3e10 has repeatedly claimed). None of those reasons you suggest for why a particular scope may be limited; is a fundamental limitation which cannot be solved with different hardware.

[Someone]

My guess would be because they started the desing of the Megazoom V ASIC many years ago (6-7 years maybe?) and unlike other scope designs, the screen resolution is baked into the ASIC to get the high update rate which no one else can match.
Megazoom IV was 800x480 and they figured that 1280x800 was a decent enough step up for Megazoom V.
Then Full HD 1920x1080 scopes came out and they couldn't go back and change the ASIC at that point.

MXR-B/EXR scopes are 1920x1080 which:
" leverages a 100M+ gate CMOS ASIC from our UXR B-Series oscilloscope, and acts as an 'oscilloscope on a chip'"
So the technology was already there. Yet the UXR(-B) is XGA resolution.

[EEVblog]

My guess would be because they started the desing of the Megazoom V ASIC many years ago (6-7 years maybe?) and unlike other scope designs, the screen resolution is baked into the ASIC to get the high update rate which no one else can match.
Megazoom IV was 800x480 and they figured that 1280x800 was a decent enough step up for Megazoom V.
Then Full HD 1920x1080 scopes came out and they couldn't go back and change the ASIC at that point.

MXR-B/EXR scopes are 1920x1080 which:
" leverages a 100M+ gate CMOS ASIC from our UXR B-Series oscilloscope, and acts as an 'oscilloscope on a chip'"
So the technology was already there. Yet the UXR(-B) is XGA resolution.

They have 200k waveform update rate vs 1.3M in the Megazoom.

[Someone]

My guess would be because they started the desing of the Megazoom V ASIC many years ago (6-7 years maybe?) and unlike other scope designs, the screen resolution is baked into the ASIC to get the high update rate which no one else can match.
Megazoom IV was 800x480 and they figured that 1280x800 was a decent enough step up for Megazoom V.
Then Full HD 1920x1080 scopes came out and they couldn't go back and change the ASIC at that point.

MXR-B/EXR scopes are 1920x1080 which:
" leverages a 100M+ gate CMOS ASIC from our UXR B-Series oscilloscope, and acts as an 'oscilloscope on a chip'"
So the technology was already there. Yet the UXR(-B) is XGA resolution.

They have 200k waveform update rate vs 1.3M in the Megazoom.

16GS/s vs 3.2GS/s = 5x
1M wfms/s vs 200k wfms/s = 5x

Coincidence? No.

[KungFuJosh]

the high update rate which no one else can match.

Are you saying nobody can match the 1.3M wfms/s?

What about the MXO4 and MXO5 with 4.5M wfms/s?

[Wolfgang]

My guess would be because they started the desing of the Megazoom V ASIC many years ago (6-7 years maybe?) and unlike other scope designs, the screen resolution is baked into the ASIC to get the high update rate which no one else can match.
Megazoom IV was 800x480 and they figured that 1280x800 was a decent enough step up for Megazoom V.
Then Full HD 1920x1080 scopes came out and they couldn't go back and change the ASIC at that point.

MXR-B/EXR scopes are 1920x1080 which:
" leverages a 100M+ gate CMOS ASIC from our UXR B-Series oscilloscope, and acts as an 'oscilloscope on a chip'"
So the technology was already there. Yet the UXR(-B) is XGA resolution.

... no wonder. The UXRs have 10Bit ADCS, and the ENOBs at higher GHz frequencies drop down so fast that even XGA resolution is an overkill

[nimish]

What really bothers me about the Keysight is the small screen.
The thing costs so much money, why does it have a 10” screen....
Siglent SDS6000A (only available here as 8bit, so no competition) has 12“, Lecroy WS4000HD has 12”, R&S MX04 has 15”....
Why the hell only 10”....

My guess would be because they started the desing of the Megazoom V ASIC many years ago (6-7 years maybe?) and unlike other scope designs, the screen resolution is baked into the ASIC to get the high update rate which no one else can match.
Megazoom IV was 800x480 and they figured that 1280x800 was a decent enough step up for Megazoom V.
Then Full HD 1920x1080 scopes came out and they couldn't go back and change the ASIC at that point.
As for actual size, 10.1", maybe they just wanted a smaller scope for market reasons. Not everyone wants a big scope. The 4000X for example is 12" but still only had the same old 800x600 resolution.

I'd expect to see a bigger screen HD4 version at some point. But I doubt you'll see a full HD resolution screen.

It would be moronic to design such a limitation into the silicon. The screen only updates at 60Hz, there's nothing tying the waveform update and processing speed to the display timing controller. They chose 10.1" and low res because they wanted to cut costs. High-res industrial/automotive grade LCDs have existed for eons now, if they wanted to use one they could have done so easily.

[EEVblog]

Are you saying nobody can match the 1.3M wfms/s?
What about the MXO4 and MXO5 with 4.5M wfms/s?

Have you seen my video?
That 4.5M on the MXO4 drops by many orders of magnitude when you turns on measurements and FFT. This is the single biggets advantage of the Megazoom ASIC.

[Someone]

The screen only updates at 60Hz, there's nothing tying the waveform update and processing speed to the display timing controller.

Resolution of the screen plotter is one of the expensive constraints in the pipeline, so resolution can form a limiting edge. Upping from 1280x800 to 1920x1080 is only double the pixels so that doesn't explain the larger drop in update rate between the HD3 and MXR (assuming they use the same ASIC and not just "technology from") but it is still a limitation.

[EEVblog]

The screen only updates at 60Hz, there's nothing tying the waveform update and processing speed to the display timing controller.

Resolution of the screen plotter is one of the expensive constraints in the pipeline, so resolution can form a limiting edge. Upping from 1280x800 to 1920x1080 is only double the pixels so that doesn't explain the larger drop in update rate between the HD3 and MXR (assuming they use the same ASIC and not just "technology from") but it is still a limitation.

The MXR does not use the Megazoom V ASIC AFAIK. The HD3 is the first scope using it.

[maxwell3e10]

Yes, as I keep saying there are practical/economic reasons why scopes do not currently process faster than the incoming data. But that does not make it impossible (which maxwell3e10 has repeatedly claimed). None of those reasons you suggest for why a particular scope may be limited; is a fundamental limitation which cannot be solved with different hardware.

You are making it too complicated, it is a very simple point. A scope can process data faster than the rate of incoming data, but it can't make new data faster than the incoming data. Imagine you are standing at a conveyer belt, taking "data" from the belt and placing it somewhere (on the screen). If you are not fast enough, maybe you won't pick up everything from the conveyer belt (dead time). Once you are fast enough, you will pick up everything, but there is no way to go any faster. Now you could "show off" and pick up the same data again and place it on the screen a second time. One could have a waveform update that has exact same data again. I don't think any scope would do it because there is no reason to and it would mess up measurement statistics.

[Someone]

The screen only updates at 60Hz, there's nothing tying the waveform update and processing speed to the display timing controller.

Resolution of the screen plotter is one of the expensive constraints in the pipeline, so resolution can form a limiting edge. Upping from 1280x800 to 1920x1080 is only double the pixels so that doesn't explain the larger drop in update rate between the HD3 and MXR (assuming they use the same ASIC and not just "technology from") but it is still a limitation.

The MXR does not use the Megazoom V ASIC AFAIK. The HD3 is the first scope using it.

Lets see what the teardown reveals! There is a general lack of detail on this in the public documents.

[Someone]

Yes, as I keep saying there are practical/economic reasons why scopes do not currently process faster than the incoming data. But that does not make it impossible (which maxwell3e10 has repeatedly claimed). None of those reasons you suggest for why a particular scope may be limited; is a fundamental limitation which cannot be solved with different hardware.

You are making it too complicated, it is a very simple point. A scope can process data faster than the rate of incoming data, but it can't make new data faster than the incoming data. Imagine you are standing at a conveyer belt, taking "data" from the belt and placing it somewhere (on the screen). If you are not fast enough, maybe you won't pick up everything from the conveyer belt (dead time). Once you are fast enough, you will pick up everything, but there is no way to go any faster. Now you could "show off" and pick up the same data again and place it on the screen a second time. One could have a waveform update that has exact same data again. I don't think any scope would do it because there is no reason to and it would mess up measurement statistics.

ADC data written to memory, can be read arbitrary number of times so that is not comparable at all. It is more like taking photos of the items going past, with enough cameras and processing you can take photo of every single object in the middle of the frame despite there being the other items around it and appearing in multiple photos.

David Hess provided some limitations which exist in practice, and how they affect the result.

You have not explained any limitation which prevents drawing more waveforms to the screen than the horizontal sweep time. I'm continuously pushing to keep it as simple as possible and you add all the confusion and "what if". Several scopes interconnected could currently deliver this claimed "impossibility" of wfms/s being higher than the horizontal sweep, so a single hypothetical (plausible/feasible/practical) one could in theory.

[maxwell3e10]

Yes, as I keep saying there are practical/economic reasons why scopes do not currently process faster than the incoming data. But that does not make it impossible (which maxwell3e10 has repeatedly claimed). None of those reasons you suggest for why a particular scope may be limited; is a fundamental limitation which cannot be solved with different hardware.

You are making it too complicated, it is a very simple point. A scope can process data faster than the rate of incoming data, but it can't make new data faster than the incoming data. Imagine you are standing at a conveyer belt, taking "data" from the belt and placing it somewhere (on the screen). If you are not fast enough, maybe you won't pick up everything from the conveyer belt (dead time). Once you are fast enough, you will pick up everything, but there is no way to go any faster. Now you could "show off" and pick up the same data again and place it on the screen a second time. One could have a waveform update that has exact same data again. I don't think any scope would do it because there is no reason to and it would mess up measurement statistics.

ADC data written to memory, can be read arbitrary number of times so that is not comparable at all. It is more like taking photos of the items going past, with enough cameras and processing you can take photo of every single object in the middle of the frame despite there being the other items around it and appearing in multiple photos.

David Hess provided some limitations which exist in practice, and how they affect the result.

You have not explained any limitation which prevents drawing more waveforms to the screen than the horizontal sweep time. I'm continuously pushing to keep it as simple as possible and you add all the confusion and "what if". Several scopes interconnected could currently deliver this claimed "impossibility" of wfms/s being higher than the horizontal sweep, so a single hypothetical (plausible/feasible/practical) one could in theory.

You have one ADC giving you a digital stream. Yes, you can draw it on screen multiple times, if you want, but it would be pointless since it is digitally identical no matter how you chop it. If Keysight is really doing it, it would be a pure marketing gimmick. And if you don't do it uniformly (every waveform "updated" twice), it would mess up various properties of the data.

[Someone]

Yes, as I keep saying there are practical/economic reasons why scopes do not currently process faster than the incoming data. But that does not make it impossible (which maxwell3e10 has repeatedly claimed). None of those reasons you suggest for why a particular scope may be limited; is a fundamental limitation which cannot be solved with different hardware.

You are making it too complicated, it is a very simple point. A scope can process data faster than the rate of incoming data, but it can't make new data faster than the incoming data. Imagine you are standing at a conveyer belt, taking "data" from the belt and placing it somewhere (on the screen). If you are not fast enough, maybe you won't pick up everything from the conveyer belt (dead time). Once you are fast enough, you will pick up everything, but there is no way to go any faster. Now you could "show off" and pick up the same data again and place it on the screen a second time. One could have a waveform update that has exact same data again. I don't think any scope would do it because there is no reason to and it would mess up measurement statistics.

ADC data written to memory, can be read arbitrary number of times so that is not comparable at all. It is more like taking photos of the items going past, with enough cameras and processing you can take photo of every single object in the middle of the frame despite there being the other items around it and appearing in multiple photos.

David Hess provided some limitations which exist in practice, and how they affect the result.

You have not explained any limitation which prevents drawing more waveforms to the screen than the horizontal sweep time. I'm continuously pushing to keep it as simple as possible and you add all the confusion and "what if". Several scopes interconnected could currently deliver this claimed "impossibility" of wfms/s being higher than the horizontal sweep, so a single hypothetical (plausible/feasible/practical) one could in theory.

You have one ADC giving you a digital stream. Yes, you can draw it on screen multiple times, if you want, but it would be pointless since it is digitally identical no matter how you chop it. If Keysight is really doing it, it would be a pure marketing gimmick. And if you don't do it uniformly (every waveform "updated" twice), it would mess up various properties of the data.

There is no gimmick in putting all the waveforms aligned overlaid, this is routine for eye diagrams (while keeping the edges before and after visible at the same time). Something which is a marketing feature of the next class/category of Keysight scope upwards where they have eye diagram update rate faster than the peak realtime rate. It's pretty much the driver for fast wfm/s rates.

Nowhere does this change/mess-up/ruin statistics or measurements. How would plotting more triggers to the screen change that?

So has this gone from impossible to something you cant imagine a use for ?