NEW Keysight HD3

[2N3055]

Just noticed two things:
- the HD3 is in 1MOhm (not in 50 Ohm like the MXO4), so it should lower the noise floor if it were in 50 Ohm
- the HD3 is in dBV and the MXO4 in dBm, so the -110 dBm in the R&S would be -123 dBV

Damn, I'll make the excuse that I was drunk.

[maxwell3e10]

In conventional scope operation only one trigger is allowed in the horizontal time span. So signals triggered on periods 1, 2 and 3 cannot be combined. Otherwise one would get something akin to a messy eye diagram for general (not perfectly periodic) signals. If you want to argue that one can make an eye diagram with faster update rate, I will grant you that, but that is not what we are talking about for basic waveform update testing.  Signal triggered on period 4 can be combined with 1, giving zero dead time.

Pray tell what is a conventional scope ?
If you mean a DSO that statement is wildly untrue.

OK, maybe be you can educate me then, give me a link to a youtube video where more than one trigger is used, other than aformentioned eye diagrams.

Why do you think an eye diagram is significantly different to other displays? At your request I showed a diagram with approximately the same signal as was used in the video for the testing (3 cycles of a square wave). Referring back to this diagram:
https://www.eevblog.com/forum/testgear/new-keysight-infiniivision-hd3-oscilloscope/msg5635709/#msg5635709
Why is it more correct to show any particular sequence of edges (possible/available triggers) in the middle of the screen than any others? Why is showing every single possible triggering edge/event in the middle of the screen less desirable or wrong in any way?

It's not wrong, but in most cases one would like to see a single trace that "retraces" on subsequent waveform updates. That's what one would consider stable triggering.  Usually one uses a hold-off or separate trigger channel to get a stable display. For example, a digital stream would have variable width of square pulses, so they won't overlap if  every trigger edge is shifted to the same point. It also applies to any other non-trivial signal, like a decaying sine wave or a frequency chirp.

Regarding FFTs, it could be that both scopes are decimating before FFT without anti-alias filter. That would explain why turning on HD reduces the noise, since it effectively provides anti-aliasing.

[nctnico]

IMHO waveform update rate is as interesting as torque on a car engine... its just a number for marketing wank.

What is more important is the number of measurements / tests that fault finder feature on the HD3 can perform per second. In the end you are not going to stare to a screen to find a random fault. You let the oscilloscope find these for you and record them while you are having dinner and after that a good nights sleep. By the looks of it, 'fault finder' takes mask testing to a new level.

[tggzzz]

What is more important is the number of measurements / tests that fault finder feature on the HD3 can perform per second.

Arguably "misses" is as important as "finds".

[2N3055]

IMHO waveform update rate is as interesting as torque on a car engine... its just a number for marketing wank.

What is more important is the number of measurements / tests that fault finder feature on the HD3 can perform per second. In the end you are not going to stare to a screen to find a random fault. You let the oscilloscope find these for you and record them while you are having dinner and after that a good nights sleep. By the looks of it, 'fault finder' takes mask testing to a new level.

Actually HP is wank and torque is important. Power is just torque at certain RPM.
Torque is the force that accelerates you. Max power only defines max speed, which in any car is more than legal limit, and on some by large margin at that.

Back to scopes: 
Legendary MSOX3104T on my desk is capable of 1.1 M triggers per second at 500ps/div. Sounds impressive.

That means it triggers every cca 910 ns. Triggers, take 5ns of data, waits for 905ns, triggers... Meaning scope is blind 99,5% of time....

What also they don't tell you that every 1/60th of the second (probably screen refresh) it makes 250µs pause when it does not trigger.
In 500ps/div timebase full screen of data is 5ns wide. That means that, 60 times a second, scope is blind for what is equivalent of 50000 screens wide period of time, in addition to baseline 99.5% blind time.

So yeah unless someone does make a zero blind time scope it is all just marketing and statistical games.

[maxwell3e10]

What one really needs to do is to put Trigger out signal on a different oscilloscope, so one can really see the trigger timing structure and dead times. MXO4 claims pretty high live fraction, but could also have some longer dead times.

[nctnico]

IMHO waveform update rate is as interesting as torque on a car engine... its just a number for marketing wank.

What is more important is the number of measurements / tests that fault finder feature on the HD3 can perform per second. In the end you are not going to stare to a screen to find a random fault. You let the oscilloscope find these for you and record them while you are having dinner and after that a good nights sleep. By the looks of it, 'fault finder' takes mask testing to a new level.

Actually HP is wank and torque is important. Power is just torque at certain RPM.
Torque is the force that accelerates you. Max power only defines max speed, which in any car is more than legal limit, and on some by large margin at that.

You just failed your basic physics exam.  What you need to make anything go forward (or up) is energy. Only engine rating which relates to energy is power. The more power you can put into an object, the faster it will acellerate. Hint: a gearbox works just like a balun / transformer to optimise power transfer. Torque just falls out of the equation. When buying a car I never look at engine torque, only which RPM the maximum power is at. Maximum power gets the car uphill the fastest.

Back to scopes: 
Legendary MSOX3104T on my desk is capable of 1.1 M triggers per second at 500ps/div. Sounds impressive.

That means it triggers every cca 910 ns. Triggers, take 5ns of data, waits for 905ns, triggers... Meaning scope is blind 99,5% of time....

What also they don't tell you that every 1/60th of the second (probably screen refresh) it makes 250µs pause when it does not trigger.
In 500ps/div timebase full screen of data is 5ns wide. That means that, 60 times a second, scope is blind for what is equivalent of 50000 screens wide period of time, in addition to baseline 99.5% blind time.

So yeah unless someone does make a zero blind time scope it is all just marketing and statistical games.

Yep.  In many cases it is better to acquire a long, continuous piece of data and use analysis to find malformed pulses. Or use a specific trigger condition. It would be interesting to see if the fault finding function uses the trigger engine only or whether it uses post-processing as well (which could slow down the number of tests per second quite a bit).

[2N3055]

What one really needs to do is to put Trigger out signal on a different oscilloscope, so one can really see the trigger timing structure and dead times. MXO4 claims pretty high live fraction, but could also have some longer dead times.

That is what I did, measured with another scope.
But even if we disregard some pausing, if you know triggers/s and timebase it is easy to see that in 1ns/div (that is 10ns per trigger), you would need massive 50MWfms/s to achieve 50% blind time. So 1MWfms/s or even 5MWfms/s is still 99% or 95% blind...

And that is the reason why zero blind time scope is not existing at the moment.
You would need a 100 times more processing power that it is in new HD3 to get close.

[maxwell3e10]

What one really needs to do is to put Trigger out signal on a different oscilloscope, so one can really see the trigger timing structure and dead times. MXO4 claims pretty high live fraction, but could also have some longer dead times.

That is what I did, measured with another scope.
But even if we disregard some pausing, if you know triggers/s and timebase it is easy to see that in 1ns/div (that is 10ns per trigger), you would need massive 50MWfms/s to achieve 50% blind time. So 1MWfms/s or even 5MWfms/s is still 99% or 95% blind...

And that is the reason why zero blind time scope is not existing at the moment.
You would need a 100 times more processing power that it is in new HD3 to get close.

Well, to be fair at 1ns/div each waveform has 30-50 points, so the scope is not efficient in processing them. There is a certain sweet spot where number of points is roughly equal to number of horizontal pixels.

[nimish]

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 display can only update every 16ms. Oscilloscope makers don't have magical LCD display tech that somehow refreshes a display every time a waveform trigger happens, it has the same latency as any other display using app.

Someone should do one of the display latency tests with a scope display just to show how long it actually takes from "trigger to photon"

[EEVblog]

Legendary MSOX3104T on my desk is capable of 1.1 M triggers per second at 500ps/div. Sounds impressive.

That means it triggers every cca 910 ns. Triggers, take 5ns of data, waits for 905ns, triggers... Meaning scope is blind 99,5% of time....

What also they don't tell you that every 1/60th of the second (probably screen refresh) it makes 250µs pause when it does not trigger.
In 500ps/div timebase full screen of data is 5ns wide. That means that, 60 times a second, scope is blind for what is equivalent of 50000 screens wide period of time, in addition to baseline 99.5% blind time.

So yeah unless someone does make a zero blind time scope it is all just marketing and statistical games.

Ok, stick to using a Rigol DS1052E or a Tek TDS220 then, no need for that marketing wankery of waveform update rate.   

Obviously a faster updating scope is going to be better than a slower updating scope, you simply have more chance of capturing an event, either using a specifc trigger setup or while just manually probing around.

[Anthocyanina]

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 display can only update every 16ms. Oscilloscope makers don't have magical LCD display tech that somehow refreshes a display every time a waveform trigger happens, it has the same latency as any other display using app.

Someone should do one of the display latency tests with a scope display just to show how long it actually takes from "trigger to photon"

That's what intensity grading is for. the scope acquires then processes thousands of trigger events and each frame shown is an aggregate of those thousands of events, with the more frequent ones showing up brighter than the more infrequent ones. even scopes without intensity grading do a similar thing, they just draw everything with the same brightness, but it's still an aggregate of hundreds to thousands of waveforms shown on each frame

[Someone]

In conventional scope operation only one trigger is allowed in the horizontal time span. So signals triggered on periods 1, 2 and 3 cannot be combined. Otherwise one would get something akin to a messy eye diagram for general (not perfectly periodic) signals. If you want to argue that one can make an eye diagram with faster update rate, I will grant you that, but that is not what we are talking about for basic waveform update testing.  Signal triggered on period 4 can be combined with 1, giving zero dead time.

Pray tell what is a conventional scope ?
If you mean a DSO that statement is wildly untrue.

OK, maybe be you can educate me then, give me a link to a youtube video where more than one trigger is used, other than aformentioned eye diagrams.

Why do you think an eye diagram is significantly different to other displays? At your request I showed a diagram with approximately the same signal as was used in the video for the testing (3 cycles of a square wave). Referring back to this diagram:
https://www.eevblog.com/forum/testgear/new-keysight-infiniivision-hd3-oscilloscope/msg5635709/#msg5635709
Why is it more correct to show any particular sequence of edges (possible/available triggers) in the middle of the screen than any others? Why is showing every single possible triggering edge/event in the middle of the screen less desirable or wrong in any way?

It's not wrong, but in most cases one would like to see a single trace that "retraces" on subsequent waveform updates. That's what one would consider stable triggering.  Usually one uses a hold-off or separate trigger channel to get a stable display. For example, a digital stream would have variable width of square pulses, so they won't overlap if  every trigger edge is shifted to the same point. It also applies to any other non-trivial signal, like a decaying sine wave or a frequency chirp.

No one is suggesting anything other than stable triggering. Two scopes next to each other with slightly different blind times would show different triggers on the screen in the test Dave did, they are all possible and "correct" triggers but most are lost or show up at non-trigger locations on the screen. Yet it would be possible to show all the trigger points in the middle of the screen without losing anything, and end up with the wfms/s being faster than 1.0/(horizontal sweep time)

Some other signal which requires added hold-off to show the correct framing.... another "what if" that you're imagining and would not be negatively affected by the ability to capture all triggers.

Regarding FFTs, it could be that both scopes are decimating before FFT without anti-alias filter. That would explain why turning on HD reduces the noise, since it effectively provides anti-aliasing.

Some antialiasing, not always very effective.

[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 display can only update every 16ms. Oscilloscope makers don't have magical LCD display tech that somehow refreshes a display every time a waveform trigger happens, it has the same latency as any other display using app.

Where is latency mentioned?

Between the firehose of XXGS/s of ADC data coming in and the screen going out at what? 300MB/s there is a collection of processing steps in between. That in-between bit is what limits the wfms/s update rate. Currently it is throughput limited in one or more areas, px/s, GS/s, etc which results in less than 100% capture rate (more than 0 blind time) because the processing of samples to screen cannot keep up with the rate of samples arriving.

If you want to draw more waveform pixels to the screen that is one of the limitations of throughput. Most scopes would drop the waveform update rate with any increase in resolution as they are not leaving any significant overhead/unutilised performance unused.

And that is the reason why zero blind time scope is not existing at the moment.
You would need a 100 times more processing power that it is in new HD3 to get close.

Indeed, quite the change.

[tautech]

Legendary MSOX3104T on my desk is capable of 1.1 M triggers per second at 500ps/div. Sounds impressive.

That means it triggers every cca 910 ns. Triggers, take 5ns of data, waits for 905ns, triggers... Meaning scope is blind 99,5% of time....

What also they don't tell you that every 1/60th of the second (probably screen refresh) it makes 250µs pause when it does not trigger.
In 500ps/div timebase full screen of data is 5ns wide. That means that, 60 times a second, scope is blind for what is equivalent of 50000 screens wide period of time, in addition to baseline 99.5% blind time.

So yeah unless someone does make a zero blind time scope it is all just marketing and statistical games.

Ok, stick to using a Rigol DS1052E or a Tek TDS220 then, no need for that marketing wankery of waveform update rate.   

Obviously a faster updating scope is going to be better than a slower updating scope, you simply have more chance of capturing an event, either using a specifc trigger setup or while just manually probing around.

Define what that means.

WFPS means nothing at slow sampling rates.

Sampling speed and trigger capability are paramount.

[EEVblog]

Obviously a faster updating scope is going to be better than a slower updating scope, you simply have more chance of capturing an event, either using a specifc trigger setup or while just manually probing around.

Define what that means.

I know you know exactly what that means.

WFPS means nothing at slow sampling rates.

Who was talking about slow sampling rates?

[nimish]

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 display can only update every 16ms. Oscilloscope makers don't have magical LCD display tech that somehow refreshes a display every time a waveform trigger happens, it has the same latency as any other display using app.

Someone should do one of the display latency tests with a scope display just to show how long it actually takes from "trigger to photon"

That's what intensity grading is for. the scope acquires then processes thousands of trigger events and each frame shown is an aggregate of those thousands of events, with the more frequent ones showing up brighter than the more infrequent ones. even scopes without intensity grading do a similar thing, they just draw everything with the same brightness, but it's still an aggregate of hundreds to thousands of waveforms shown on each frame

And that means that the screen res is independent of the triggering subsystem, so the choice of low res displays is economic. Which was the whole point of my post -- Keysight product managers chose a shitty low res screen not out of technical limitation, but because they simply didn't care about it. There is no technical limitation preventing them from rendering at, say, 8k with exactly the same waveform update rate beyond their GPU.

On an $8k+ scope in 2024 whose selling points include having 4x the resolution of everyone else, it's certainly a choice to use 2005-era bargain-bin displays.

[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 display can only update every 16ms. Oscilloscope makers don't have magical LCD display tech that somehow refreshes a display every time a waveform trigger happens, it has the same latency as any other display using app.

Someone should do one of the display latency tests with a scope display just to show how long it actually takes from "trigger to photon"

That's what intensity grading is for. the scope acquires then processes thousands of trigger events and each frame shown is an aggregate of those thousands of events, with the more frequent ones showing up brighter than the more infrequent ones. even scopes without intensity grading do a similar thing, they just draw everything with the same brightness, but it's still an aggregate of hundreds to thousands of waveforms shown on each frame

And that means that the screen res is independent of the triggering subsystem, so the choice of low res displays is economic. Which was the whole point of my post -- Keysight product managers chose a shitty low res screen not out of technical limitation, but because they simply didn't care about it. There is no technical limitation preventing them from rendering at, say, 8k with exactly the same waveform update rate beyond their GPU.

You say there is no limit, so go ahead and write us a software implementation that does it. Others of us can calculate the computational task and know it is non-trivial and there are limits.

[David Hess]

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.

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.

I looked at this problem a couple years ago in connection with a DPO type of design where acquisition produces a histogram in real time, and has a minimum of blind time.  The most important limitation was memory access throughput; the fastest memory simply was not fast enough, whether it was CPU cache, SRAM, or FPGA RAM.  Maybe it is different with an ASIC.

The solutions were to use wider but less deep memory to multiply the throughput, obviously, and divide the acquisition memory into banks, but this divides the record length by the number of banks.  Using separate banks allows writes to go to one bank while reads go to the other, and then the banks swap, like with double buffering.  Then splitting into further banks allows parallelism, but further divides the record length.

If the acquisition record is not kept and only the histogram is generated and preserved, then multiple banks dividing the record length are still required to get enough memory throughput and parallelism.

The point of this is that increasing the supported display size of the Megazoom IC takes more than just adding memory depth.  The memory and processing organization likely has to be changed also to achieve enough throughput.

[EEVblog]

The 16 level intensity graded display was a datasheet typo!

Quote from the dev team:

16-level intensity grading was a data sheet error.  It is actually 256 (compared with 64 in DSOX3000).  So Dave was right when he said it looked better.

[EEVblog]

Teardown photos for those who can't wait.
I can't get the ADC & Megazoom heatsink off, waiting on a phone-a-friend before I try and apply more wiggly force.
Front end cans are soldered 

https://www.flickr.com/photos/eevblog/albums/72177720320207221/

[mikeselectricstuff]

Front end cans are soldered 

Only at the corners....

[Frex]

Wow !

A 12.6V 32A 400W power supply (very well build) !
That seem huge for a scope !..
I hope It won't no need to evacuate all of such power...

Frex

[EEVblog]

A 12.6V 32A 400W power supply (very well build) !
That seem huge for a scope !..
I hope It won't no need to evacuate all of such power...

In my video I think I measured something like 40W consumption?

[SWB]

There's totally a plan for something there. J302 looks to be an unpopulated footprint for exactly the same connector used for the other two modules. And there are similarly located mounting holes.