NEW Keysight HD3

[EEVblog]

Is it 15µV which is passed through an attenuator and then reduced again

Yes.

[EEVblog]

Why do they have the illuminated buttons and also the LEDs next to them? Do they do different things?

The button illumination indicates the channel is being displayed on the screen.
The LEDs indicate which channel the gain and offset knobs will modify.

Correct.

[coppercone2]

IMO those illuminated buttons are crappy, you can barely see them. I would prefer more LED

In a realistic lab setting the scope might be higher then you if your doing something complicated on a regular work bench, so I am a fan of old LED that stick out a bit.

They egotistically assume that the scope is going to be the most important thing in the circuit, but if you are triggering to evaluate equipment or something, its not. That is my experience for today with a $contactusk MFOscope while studying pulse parameters

[AmericanLocomotive]

I'm not a huge scope user (A 1054Z is about the fanciest scope I've used), but it kills me that the "laggy UI disease" has infected Keysight now. There were quite a few times where Dave was swiping something and the scope was a half-second behind, or he'd close/open something and it'd take a full 1+ second for the scope to respond. It also looked like most of the UI was running at 25-30 FPS.

One of the huge benefits of the MegaZoom ASIC was that the it was handling all the heavy lifting, allowing the application processor to have a much easier time. When you look at videos of MegaZoom 4 scopes, the UI was much snappier and seemed to respond to inputs much faster. Even the touchscreen ones. If a crappy $100 Android phone can run the UI at 60 FPS, a scope that costs nearly two orders of magnitude more should have a responsive 60 FPS UI, too.

...and I get it. The beauty of this scope is the hardware's performance. But the UI/UX is still an important aspect.

[bret]

UI is seriously bad, looks rushed. Looks like the "essence" of InfiniiVision is lost. It'll be hard for me to convince the bosses to switch.

For starters ...

• Inconsistent padding/margin and vertical spacing. The padding in tables look fine, but probably because a library is used. Anywhere else, it is bad. The scales on the right needs some left-padding when not overlapping with the waveform.
• Inconsistent (and mostly horribly-sized) buttons in the menu.
• No design language used in general, and especially in menus.
• The zone trigger box shouldn't be covering the signal ... it should be transparent like the RS.

I know realistically the HW, functionality and price should be the main consideration for upgrading, but really don't want to be facing an intern-level UI throughout office hours.

[Martin72]

Is it 15µV which is passed through an attenuator and then reduced again

Yes.

Thanks, and your FFT settings ?

[ogoun]

Thanks Dave, for a very informative review of this scope!

Looks like this will be a worthwhile scope upgrade for me, after a few software updates, a hardware bugfix version spin, and some time for the clever folk on here to work out how to enable all the features

Also, a larger screen model, like my MSOX4000A.

I will start saving my pennies for a future upgrade, assuming the teething problems are sorted out.


Also, I note that none of the Agilent/Keysight scopes will do Dallas "1-Wire" serial protocol decode.. Seems like quite an oversight.. I had to get a Picoscope just to do this..

I wonder if they will ever release a tool to allow us to write our own protocol decoder.. I think the HP/Agilent 16700/800/900 series of logic analyzers had this feature..

Cheers,

Pete

[tggzzz]

Two buck probe being "just as good" for what, exactly? A £20 100MHz scope yes, but not a £20000 1GHz scope - certainly not.

Bullshit. There is a long history of DIY coax probes being used for high end measurement work. The commercial ones exist because most people with a budget want something that's already characterised.

Since you didn't indicate the type of probe, I assumed you were referring to the bog-standard stupidly cheap probes on fleabay/aliexpress etc.

I am well aware of homebrew Z0 probes, and regard them as zero cost throwaway items. Doesn't everybody have 50ohm coax and 500ohm resistors lying around waiting to be used?

A useful test for you to do would be to measure the VSWR or impedance vs frequency of the 50ohm inputs. Too many scopes simply slap a 50ohm resistor across the 15/20pF input, with poor results at VHF and above. Use a NanoVNA or simply sweep a siggen from 100MHz to 1GHz and observe the amplitude of the trace.

[tggzzz]

Also, I note that none of the Agilent/Keysight scopes will do Dallas "1-Wire" serial protocol decode.. Seems like quite an oversight.. I had to get a Picoscope just to do this..

I wonder if they will ever release a tool to allow us to write our own protocol decoder.. I think the HP/Agilent 16700/800/900 series of logic analyzers had this feature..

Once you have used an analogue domain tool to assure analogue signal integrity, flip to the digital domain and use a digital domain tool such as a logic analyser or protocol analyser (or printf()). Much cheaper and more effective.

[2N3055]

I would like to make note that FFT settings for Keysight and R&S are nowhere close and that invalidates any comparison, really. Noise floor will highly depend on RBW and it is not set the same.

Also, Keysight FFT is factor 10-20x slower than R&S.  I tested today, and on Siglent SDS3000xHD at similar FFT settings as Keysight, even with 4x averaging, i get comparable speeds to Keysight. With measurements, without measurement it is visibly faster.

It certainly does not seem there is much "special ASIC acceleration" for FFT in HD3. Unlike R&S that really looks like realtime SA at settings shown.

[EEVblog]

It certainly does not seem there is much "special ASIC acceleration" for FFT in HD3.

There isn't. The ASIC is not doing the FFT (at least that's not mentioned in any of the literature).
How the ASIC works is that it handles the data flow from the ADC directly to the screen, bypassing the CPU. It can also do serial decoding and mask trigger in the ASIC.
So it doesn't matter what the CPU is doing or whatever extra processing it has with doing FFT, measurements or whatever, this will never slow down the waveform update rate which bypasses the CPU entirely.
The CPU then pushes the extra info like FFT into the ASIC and is then included in the next screen update by the ASIC.
This is it appears as though the ASIC is doing the FFT but it's not.

[EEVblog]

Two buck probe being "just as good" for what, exactly? A £20 100MHz scope yes, but not a £20000 1GHz scope - certainly not.

Bullshit. There is a long history of DIY coax probes being used for high end measurement work. The commercial ones exist because most people with a budget want something that's already characterised.

Since you didn't indicate the type of probe, I assumed you were referring to the bog-standard stupidly cheap probes on fleabay/aliexpress etc.

I gave you the timestamp in the video.

[EEVblog]

Also, I note that none of the Agilent/Keysight scopes will do Dallas "1-Wire" serial protocol decode.. Seems like quite an oversight.. I had to get a Picoscope just to do this..
I wonder if they will ever release a tool to allow us to write our own protocol decoder.. I think the HP/Agilent 16700/800/900 series of logic analyzers had this feature..

The serial decoders are built into the ASIC silicon.
They could add it on the CPU code side a guess, nothing stopping that, but it won't be quick. Not that 1-wire quick, so likely not a problem.

[nctnico]

Also, I note that none of the Agilent/Keysight scopes will do Dallas "1-Wire" serial protocol decode.. Seems like quite an oversight.. I had to get a Picoscope just to do this..
I wonder if they will ever release a tool to allow us to write our own protocol decoder.. I think the HP/Agilent 16700/800/900 series of logic analyzers had this feature..

The serial decoders are built into the ASIC silicon.
They could add it on the CPU code side a guess, nothing stopping that, but it won't be quick. Not that 1-wire quick, so likely not a problem.

Nowadays an ASIC or FPGA isn't the only viable solution to get signal processing done quickly. A GPU is very power efficient, dirt cheap and very versatile. I think there are quite a few DSOs out there which leverage GPU processing power resulting in a much better performance for a wider range of functions at lower NRE (development costs). But even then, the protocol decoders are likely running on a dedicated piece of programmable logic inside the Megazoom ASIC. I highly doubt it is 'hard-coded' as this would require dedicated logic for each protocol and no way to fix bugs / add features & protocols afterwards.

[EEVblog]

But even then, the protocol decoders are likely running on a dedicated piece of programmable logic inside the Megazoom ASIC. I highly doubt it is 'hard-coded' as this would require dedicated logic for each protocol and no way to fix bugs / add features & protocols afterwards.

Yes, you could be right there.

[tggzzz]

Two buck probe being "just as good" for what, exactly? A £20 100MHz scope yes, but not a £20000 1GHz scope - certainly not.

Bullshit. There is a long history of DIY coax probes being used for high end measurement work. The commercial ones exist because most people with a budget want something that's already characterised.

Since you didn't indicate the type of probe, I assumed you were referring to the bog-standard stupidly cheap probes on fleabay/aliexpress etc.

I gave you the timestamp in the video.

Let's not forget that my initial comment was about the misnamed "high impedance" probe shown in your video about the HD3, and how some of my probes are better at 1GHz.

If your comment is limited to comparing the marginal price difference between one Z0 probe and another Z0 probe, then I agree with you. I find that uninteresting compared with the differences between Z0 and the misnamed "high impedance" passive probes.

(As I've mentioned ad nauseum (inc. in this thread), I'm not going to sit through yootoob adverts only to eventually find out that the content isn't interesting to me.)

[Someone]

Nowadays an ASIC or FPGA isn't the only viable solution to get signal processing done quickly. A GPU is very power efficient, dirt cheap and very versatile. I think there are quite a few DSOs out there which leverage GPU processing power resulting in a much better performance for a wider range of functions at lower NRE (development costs). But even then, the protocol decoders are likely running on a dedicated piece of programmable logic inside the Megazoom ASIC. I highly doubt it is 'hard-coded' as this would require dedicated logic for each protocol and no way to fix bugs / add features & protocols afterwards.

Will have to wait for a teardown to see, my money is on there being an FPGA backing the front end trigger ASIC like in other Keysight scopes.

[EEVblog]

If your comment is limited to comparing the marginal price difference between one Z0 probe and another Z0 probe, then I agree with you. I find that uninteresting compared with the differences between Z0 and the misnamed "high impedance" passive probes.

That's naming is pretty standard convention. It's used to differentiate it from a Z0 resistive probe. Everyone with any clue knows that a "high impedance" probe has capacitance and that lower the impedance with frequency, it's probing 101 knowledge.
So you have a standard "high impedance" probe, resistive probes, and active FET probes.

(As I've mentioned ad nauseum (inc. in this thread), I'm not going to sit through yootoob adverts only to eventually find out that the content isn't interesting to me.)

Ad free link, again 13:45 timestamp and you can play it at x2 speed if you want.
https://odysee.com/@eevblog:7/eevblog-1367-5-types-of-oscilloscope:2

[tggzzz]

Also, I note that none of the Agilent/Keysight scopes will do Dallas "1-Wire" serial protocol decode.. Seems like quite an oversight.. I had to get a Picoscope just to do this..
I wonder if they will ever release a tool to allow us to write our own protocol decoder.. I think the HP/Agilent 16700/800/900 series of logic analyzers had this feature..

The serial decoders are built into the ASIC silicon.
They could add it on the CPU code side a guess, nothing stopping that, but it won't be quick. Not that 1-wire quick, so likely not a problem.

Nowadays an ASIC or FPGA isn't the only viable solution to get signal processing done quickly. A GPU is very power efficient, dirt cheap and very versatile. I think there are quite a few DSOs out there which leverage GPU processing power resulting in a much better performance for a wider range of functions at lower NRE (development costs). But even then, the protocol decoders are likely running on a dedicated piece of programmable logic inside the Megazoom ASIC. I highly doubt it is 'hard-coded' as this would require dedicated logic for each protocol and no way to fix bugs / add features & protocols afterwards.

Just so.

It only costs £50 to tx and rx 1-wire (and others) in a dedicated device with regular firmware updates, e.g. a BusPirate5.

OTOH, if a scope decodes messages contents in realtime and uses those as a trigger for the analogue waveform capture, that would be advantageous in some cases. I don't see that being done in software, but would be happy to be corrected.

[tggzzz]

If your comment is limited to comparing the marginal price difference between one Z0 probe and another Z0 probe, then I agree with you. I find that uninteresting compared with the differences between Z0 and the misnamed "high impedance" passive probes.

That's naming is pretty standard convention. It's used to differentiate it from a Z0 resistive probe. Everyone with any clue knows that a "high impedance" probe has capacitance and that lower the impedance with frequency, it's probing 101 knowledge.
So you have a standard "high impedance" probe, resistive probes, and active FET probes.

It is indeed standard naming convention, and wasn't too much of an issue with 10MHz scopes used for TV repair. But even in the 1970s LSTTL logic needed >=100MHz scopes[1], and the capacitive loading was becoming an issue.

Nowadays ordinary jellybean logic operates with significant energy well into microwave frequencies[2], and the "high impedance" name is simply false. It demonstrably misleads too many people who don't understand probing theory, as shown by many examples in this forum!


[1] I have a 1970 (not 70s) scope where the sales literature claims its 200ps risetime is necessary with (original) TTL. I think that was an over-the-top claim, but it was certainly valid by the mid/late 80s.

[2] extreme example: I've pushed 74LVC to put 2.5V into 50ohms with a clean ~250ps risetime

[David Hess]

The noise is specified as 34 microvolts RMS for the 1 megohm input over 100 MHz.  My typical old analog oscilloscopes have a noise of 28 microvolts RMS over 100 MHz for a 200 MHz input.

So I will give them credit for achieving low noise for a 500 MHz or 1 GHz input because I have nothing to compare with, but they did not achieve low noise in comparison to obsolete slower oscilloscopes.  This may be because the design to support 500 MHz or 1 GHz will be inherently higher noise at lower frequencies.

It is indeed standard naming convention, and wasn't too much of an issue with 10MHz scopes used for TV repair. But even in the 1970s LSTTL logic needed >=100MHz scopes[1], and the capacitive loading was becoming an issue.

Nowadays ordinary jellybean logic operates with significant energy well into microwave frequencies[2], and the "high impedance" name is simply false. It demonstrably misleads too many people who don't understand probing theory, as shown by many examples in this forum!

[1] I have a 1970 (not 70s) scope where the sales literature claims its 200ps risetime is necessary with (original) TTL. I think that was an over-the-top claim, but it was certainly valid by the mid/late 80s.

TTL, even fast TTL families, have slower rise and fall times compared to CMOS logic and compared to their propagation delays, so I think the bandwidth requirements were exaggerated.

[2] extreme example: I've pushed 74LVC to put 2.5V into 50ohms with a clean ~250ps risetime

LVC would be my first choice for the fastest commonly available logic since it gets a speed boost from operating at 5 volts, but I wonder if it would be even faster driving the emitter of an NPN cascode RF transistor to produce a clean output.  I mean to try this some day with a microwave layout and an 74LVC125.

[2N3055]

Also, I note that none of the Agilent/Keysight scopes will do Dallas "1-Wire" serial protocol decode.. Seems like quite an oversight.. I had to get a Picoscope just to do this..
I wonder if they will ever release a tool to allow us to write our own protocol decoder.. I think the HP/Agilent 16700/800/900 series of logic analyzers had this feature..

The serial decoders are built into the ASIC silicon.
They could add it on the CPU code side a guess, nothing stopping that, but it won't be quick. Not that 1-wire quick, so likely not a problem.

Nowadays an ASIC or FPGA isn't the only viable solution to get signal processing done quickly. A GPU is very power efficient, dirt cheap and very versatile. I think there are quite a few DSOs out there which leverage GPU processing power resulting in a much better performance for a wider range of functions at lower NRE (development costs). But even then, the protocol decoders are likely running on a dedicated piece of programmable logic inside the Megazoom ASIC. I highly doubt it is 'hard-coded' as this would require dedicated logic for each protocol and no way to fix bugs / add features & protocols afterwards.

GPU thing sounds fun, but practice proves different. GPU might have math capability but has no input data throughput, at least on many implementations out there. It is powerful, but in a wrong place of the data path. Many CPU have powerful DSP blocks/instructions and that is used instead. If someone made a FPGA where GPU block had full BW of memory interface and you could make a pipe: ADC/Trig/decimation block/GPU/CPU and memory to be at same level then it would be interesting. But as in crypto, as FPGA DSP blocks are competing with GPU, so people simply use DSP blocks inside FPGA.

Protocol decoders are probably not fully running inside Megazoom ASIC. They never had, even in M.Z. IV. There is no need for it. Hardware only did tokenization, but final decode for screen was in software.
But said tokenization accelerates things many folds (you don't need render time scanning of full analog data to depict digital states), and also was (is?) done on full sample rate, preserving digital BW even when analog one plummeted because of small sample memory. If they are doing same thing with new scope, it might be able to do seriously long decode captures, provided they didn't limit it in number of packets.

It is a brand new platform, seems to be based on parts of EXR type of software (Fault finder for instance), brand new visuals and architecture. New hardware architecture is based on new front end preamplifier (ASIC?), new ADC (separate chip), based on their previous 10 bit converters, reconfigured for more bits and less sample rate. And there is logic chip that holds Megazoom V "technology", which happens to be ASIC.

So this is not same as old Megazoom that was single chip scope that you only needed to add human interface.  This scope (funny enough) by it's architecture is chipset based, VERY much alike what Rigol did.
And also at this point this is also what Siglent does, except digital ASIC is in FPGA, and ADC is off the shelf.

It will be interesting to see, when in few years we see yet another generation of FPGAs, whether MZ V ASIC will still be faster for logic function......

Like I said, it is all VERY new. And Keysight released VERY early, some basic functions are still missing..
What it really can, and how well will it do, we will see in year....
Yes, I think it will take at least a year to get this new line to Keysight's own highly set bar for software/product  quality.
And then we will really see what these scopes really can do.
As for old Infiniivision "everything just works" refinement, it will take years to get there. You cannot jump steps. It takes time.
But if Keysight keeps platform longterm, they will get there and in long term it will become a good product.

[Someone]

OTOH, if a scope decodes messages contents in realtime and uses those as a trigger for the analogue waveform capture, that would be advantageous in some cases. I don't see that being done in software, but would be happy to be corrected.

The scope this thread is about does break out its triggers to SW and HW types in the datasheet. So not 100% one way or the other.

[Wolfgang]

... exactly. The noise is why their ENOB values are not really spectacular, as might be hoped from th 14bits ADC resolution.

[Someone]

The noise is specified as 34 microvolts RMS for the 1 megohm input over 100 MHz.  My typical old analog oscilloscopes have a noise of 28 microvolts RMS over 100 MHz for a 200 MHz input.

A big improvement over the scope they replaced, which was around 4x noisier across most conditions:
https://www.eevblog.com/forum/testgear/new-keysight-infiniivision-hd3-oscilloscope/msg5609003/#msg5609003
quite a bit of that is noise folding down from insufficient antialiasing! a significant advantage that pure analog has.