NEW Keysight HD3

[Zucca]

Some quick peeks:

As always, tv84 delivers...

[AndyC_772]

I can think of another KS/Agilent case - the 34461A DMM only added capacitance measurement in a later firmware rev, though not clear if this was intended at the start as there was no legend on the front panel.

IIRC capacitance measurement was added to 34461A around the same time as 34465A came out, which did include that feature from day one.

Having written the firmware update for 34465A, they probably saw no reason not to port it back to 34461A as well, given that the hardware was clearly able to support it.

I don't think 34461A was advertised as having capacitance measurement early on, though. It might have been slightly odd not to have it, but it was never promised but undelivered.

[KE5FX]

There were a few firmware updates for the 34461A.  Aside from the capacitance feature, which was a nice surprise, the boot time was improved substantially.

I vaguely recall a patch that screwed up the numeric display font, which was reverted in a later release. 

All in all, Keysight does have a history of providing nice firmware tweaks over the market life of an instrument.  Lots of nice features were added to the MSO/DSO6000 series including (again) boot time improvements.  If they say they expect the HD3's boot time to improve, I'd be inclined to believe them.

[CRTbrain]

i got an HD3 unit from a distributor to try.  Severely disappointed to find that measurements and math are not based on 14-bit ADC values, but rather all math and measurement values are based on pixel values..and with the small display this means it doesn't have the accuracy I was expecting.   for a captured risetime SINGLE measure.  When I change the timebase the measurement result changes drastically.  is there a fix for this?  Has anyone else encountered?

I found math works the same way.  but even worse the math menu has a "Analysis Precision" and it's set to 64 kpts by default.  Wow!  The instrument doesn't even do math on full memory unless I change default settings.

I was hoping the 14-bit ADC was more than marketing hype.  Noise is low which I like, but math and measurement calculations being done on screen pixels instead of real 14-bit data is a killer for me.

[hpw]

I found math works the same way.  but even worse the math menu has a "Analysis Precision" and it's set to 64 kpts by default.  Wow!  The instrument doesn't even do math on full memory unless I change default settings.

I was hoping the 14-bit ADC was more than marketing hype.  Noise is low which I like, but math and measurement calculations being done on screen pixels instead of real 14-bit data is a killer for me.

Currently as I see, there are at this forum not that many ...

About the 64kpts: This means also the FFT size?? Currently none tells whether, as mentioned in the user manual, it gets decimated or boxcar.

If you look at the 14 bit ADC spec's, as SFDR or ENOB as SNR, I expect any better as a minimum 10 times better noise figures

While looking for a better/lower noise front end as for LDO/Vref power measurements as using FFT in a 1Hz to 300MHz region.
Currently use a custom made differential probe & LNA.

Even there is no specification given how accurate the internal oscillator is too (look at LeCroy WavePro HD's spec's).

[mikeselectricstuff]

There were a few firmware updates for the 34461A.  Aside from the capacitance feature, which was a nice surprise, the boot time was improved substantially.

I vaguely recall a patch that screwed up the numeric display font, which was reverted in a later release. 

All in all, Keysight does have a history of providing nice firmware tweaks over the market life of an instrument.  Lots of nice features were added to the MSO/DSO6000 series including (again) boot time improvements.  If they say they expect the HD3's boot time to improve, I'd be inclined to believe them.

Yes- optimising boot time is pretty low down on the priority list compared to making sure all the main functionality works - I would imagine things like removing debug logging and making best use of remaining available memory are among the things that get optimised after everything else is sorted.

[mikeselectricstuff]

That might be relevant if the scope supported a screen resolution that could be called "high" - but it doesn't.

Depends what you call "release" - is it actually available to purchase yet?

I assumed so. There's a promotion on for "free" memory which runs from Sept 4th until the end of the year, so presumably it's actually available to order.

https://www.mouser.co.uk/pdfDocs/HD3MaximizeYourMemoryforFreeFlyerC4006.pdf

Farnell and Mouser are showing some stock now. I'm not exactly itching to add one to my basket next time I need something to make up the value to get free delivery though...

[HighVoltage]

The German distributors also show stock and I need a new scope for a client.
Prices are similar to a 4000x.

However, since the HD3 does not offer the SENT protocol trigger and analysis, I just bought a 4000X scope.

[2N3055]

i got an HD3 unit from a distributor to try.  Severely disappointed to find that measurements and math are not based on 14-bit ADC values, but rather all math and measurement values are based on pixel values..and with the small display this means it doesn't have the accuracy I was expecting.   for a captured risetime SINGLE measure.  When I change the timebase the measurement result changes drastically.  is there a fix for this?  Has anyone else encountered?

I found math works the same way.  but even worse the math menu has a "Analysis Precision" and it's set to 64 kpts by default.  Wow!  The instrument doesn't even do math on full memory unless I change default settings.

I was hoping the 14-bit ADC was more than marketing hype.  Noise is low which I like, but math and measurement calculations being done on screen pixels instead of real 14-bit data is a killer for me.

It seems you misunderstood some information.

A simple download of Datasheet, User manual and Programmers guide and quick browse gives us lot of information.

HD3 is NOT making measurements from "screen data". When working, in addition to main acquisition memory (called by Keysight an "acquisition record"), scope makes an copy of data into separate "eavesdrop memory", called by Keysight an "analysis record".

Analysis record is reduced sample decimation (decimation by throwing away samples) of main memory. Not decimation by LP filtering.
Time length, start and stop of analysis record is same as what is shown on the screen. So scope uses same area of data as defined by what is shown on the screen (screen is used for gating what data from analysis record is used)  but not data from the screen (pixel equivalent).

Analysis record length can be from 64k to 32 Mpts, or max memory acquired in certain mode (limited with scope total memory in case you didn't upgrade base memory).
Default is 64k, same as MSOX3000T for instance. To optimize for speed.

This means that, potentially, scope can do longer memory measurements/math.

What would be interesting is to see how much scope slows down when Length is set to 32M or 16M ?
That would be really interesting to compare with other scopes with deep memory.
How fast is the scope when comparing with same (large) amount of data as other scopes?

[Wolfgang]

i got an HD3 unit from a distributor to try.  Severely disappointed to find that measurements and math are not based on 14-bit ADC values, but rather all math and measurement values are based on pixel values..and with the small display this means it doesn't have the accuracy I was expecting.   for a captured risetime SINGLE measure.  When I change the timebase the measurement result changes drastically.  is there a fix for this?  Has anyone else encountered?

I found math works the same way.  but even worse the math menu has a "Analysis Precision" and it's set to 64 kpts by default.  Wow!  The instrument doesn't even do math on full memory unless I change default settings.

I was hoping the 14-bit ADC was more than marketing hype.  Noise is low which I like, but math and measurement calculations being done on screen pixels instead of real 14-bit data is a killer for me.

Forget this. There is no scope that has "real" 14Bits. ENOB of the HD3 is at best 10.something. Its noise and crosstalk limited, so the difference between screen pixels and ENOB os not that large

[hpw]

HD3 is NOT making measurements from "screen data". When working, in addition to main acquisition memory (called by Keysight an "acquisition record"), scope makes an copy of data into separate "eavesdrop memory", called by Keysight an "analysis record".

Analysis record is reduced sample decimation (decimation by throwing away samples) of main memory. Not decimation by LP filtering.
Time length, start and stop of analysis record is same as what is shown on the screen. So scope uses same area of data as defined by what is shown on the screen (screen is used for gating what data from analysis record is used)  but not data from the screen (pixel equivalent).

Analysis record length can be from 64k to 32 Mpts, or max memory acquired in certain mode (limited with scope total memory in case you didn't upgrade base memory).
Default is 64k, same as MSOX3000T for instance. To optimize for speed.

This means that, potentially, scope can do longer memory measurements/math.

What would be interesting is to see how much scope slows down when Length is set to 32M or 16M ?
That would be really interesting to compare with other scopes with deep memory.
How fast is the scope when comparing with same (large) amount of data as other scopes?

Exactly, so I am asking about up to an 32M FFT (or max possible).
Than save the FFT data to a file to see whether we get really an 32M FFT.

This would show the trough as pans off

[jusaca]

I just played around a little with an HD3 today. I did not make any test with deeper meaning, but the overall UX was rather disappointing. No snappy UI at all.

The nice Keysight guy also mentioned, that a separate SA was initially planned to go to the empty space at the front, but it was decided that there is no real market for it. According to the Keysight guy the FFT became so good, that a separate SA moudle did not make sense anymore or they would be cannibalising their real SA units.

So, don't keep your hopes up for an MDO version that fills that void at the front.

[2N3055]

I just played around a little with an HD3 today. I did not make any test with deeper meaning, but the overall UX was rather disappointing. No snappy UI at all.

The nice Keysight guy also mentioned, that a separate SA was initially planned to go to the empty space at the front, but it was decided that there is no real market for it. According to the Keysight guy the FFT became so good, that a separate SA moudle did not make sense anymore or they would be cannibalising their real SA units.

So, don't keep your hopes up for an MDO version that fills that void at the front.

I personally think this is the biggest problem of some manufacturers..

[ballsystemlord]

I just played around a little with an HD3 today. I did not make any test with deeper meaning, but the overall UX was rather disappointing. No snappy UI at all.

The nice Keysight guy also mentioned, that a separate SA was initially planned to go to the empty space at the front, but it was decided that there is no real market for it. According to the Keysight guy the FFT became so good, that a separate SA moudle did not make sense anymore or they would be cannibalising their real SA units.

So, don't keep your hopes up for an MDO version that fills that void at the front.

So how do you guys managed to get hands on with these various tools? Like, do you live near a distributor, or do you call up the companies and ask for a rep to stop in for a few minutes with XX model?

Thanks!

[CRTbrain]

I don't get it.  Can you explain again.  I'm an experienced scope user.  The measurement behavior is foreign.  Here's an example on the scope I'm evaluating.

Connect the probe to the comp signal...autoscale and press stop.  There's a single waveform on the display.  The risetime measure shows about 20ns.   I change the timebase to 10 ns and the measurement value gets faster.  I change the timebase to 10uS and the measurement value now reads about 2 us.  This is 100X difference on the exact same signal.  The signal didn't change.

Can someone help me?  I've never used a scope where a static measurement value would change by 100X just by changing the timebase post acquisition.  There must be a technical explanation.  I didn't understand the analysis record length.  What's the relationship between a stable measurement and needing to adjust something you called analysis record.  I've never worked with a scope that did this.  How much decimation takes place, and is the amount based on the screen resolution and available rows and columns for waveforms?
 

[Martin72]

  Here's an example on the scope I'm evaluating.

The HD3 ?

[egonotto]

Hello,

yes he said: "i got an HD3 unit from a distributor to try"

Best regards
egootto

[2N3055]

I don't get it.  Can you explain again.  I'm an experienced scope user.  The measurement behavior is foreign.  Here's an example on the scope I'm evaluating.

Connect the probe to the comp signal...autoscale and press stop.  There's a single waveform on the display.  The risetime measure shows about 20ns.   I change the timebase to 10 ns and the measurement value gets faster.  I change the timebase to 10uS and the measurement value now reads about 2 us.  This is 100X difference on the exact same signal.  The signal didn't change.

Can someone help me?  I've never used a scope where a static measurement value would change by 100X just by changing the timebase post acquisition.  There must be a technical explanation.  I didn't understand the analysis record length.  What's the relationship between a stable measurement and needing to adjust something you called analysis record.  I've never worked with a scope that did this.  How much decimation takes place, and is the amount based on the screen resolution and available rows and columns for waveforms?
 

You have shown that dialog where you should simply change Analysis Record length to something more than 64k.

You ask how much decimation takes place? Whatever is needed to reduce data that scope captures to Analysis Record length.

If scope is at 2µs/div, it will capture 20µs of data and that will be 64kpoints at 3,2GS/s. So no decimation should happen at that and faster. If you go to 2ms/div (20ms total) that is 64 MPts at full sample rate and you will have 1000x decimation.

Try to increase Analysis Record length and capture Single on longer timebase and then shorten timebase and see if measurements still change a lot. It might be higher resolution on faster timebases but if rise time is, say, 20ns it should stay 20 ns with more decimals, say, 20.1ns and 20.013 ns..

[nctnico]

I don't get it.  Can you explain again.  I'm an experienced scope user.  The measurement behavior is foreign.  Here's an example on the scope I'm evaluating.

Can someone help me?  I've never used a scope where a static measurement value would change by 100X just by changing the timebase post acquisition.  There must be a technical explanation.  I didn't understand the analysis record length.  What's the relationship between a stable measurement and needing to adjust something you called analysis record.  I've never worked with a scope that did this.  How much decimation takes place, and is the amount based on the screen resolution and available rows and columns for waveforms?

There are actually two main ways for a DSO to do measurements: using the raw acquired data or decimated data. The advantage of using the raw acquired data is that you get the best result you can get from samplerate and number of bits. The downside is that it can be super slow if you have a long record length. The advantage of using decimated data is that it is fast but you basically need to have the waveform shape visible on screen in order for the measurement to be accurate. A good DSO which uses decimated data for measurements will refuse to produce a result for data which has been decimated too much to make sense.

DSO manufacturers (in general) have devised various ways to increase speed of measurements / math traces by giving the user control over the amount of data that needs to be processed. For example to use the raw data that makes up the screen or only use the data between cursors (typically called 'gated measurement') besides allowing to use the entire acquired record.

It looks like Keysight has choosen to give users of the HD3 more control over how much the data is decimated for the measurements / math so the user can choose to trade-off accuracy versus measurement / math speed.

[EEVblog]

Tektronix hit back with a comparison to the HD3, which is a kinda lackluster from a marketing perspective.
No HiRes figure?
https://www.tek.com/en/lp/accelerating-insights#compare-table

[David Hess]

The advantage of using decimated data is that it is fast but you basically need to have the waveform shape visible on screen in order for the measurement to be accurate.

That is not universal.  Tektronix uses a larger word size for the processing record to support high resolution mode,  and I assumed all DSOs did this to support higher resolution modes until I studied Rigol.  So everything present after decimation is preserved for processing, and does *not* have to be visible in the display record.

The old standard for Tektronix 8-bit DSOs was to display 200 counts over 8 vertical divisions, leaving at least 25 counts above and below the display that still get included in measurements.  This also prevents vertical aliasing in the display record while simplifying the processing to produce the display record.  The counts get multiplied with averaging or high resolution modes.

A good DSO which uses decimated data for measurements will refuse to produce a result for data which has been decimated too much to make sense.

Tektronix was really good about that in their older DSOs.  Besides indicating if horizontal or vertical resolution was suspect, measurements would vary the number of displayed significant digits to match the quality of the data.  They published the algorithms that they used for calculating the data, but never how they determined significant digits or whether to indicate that resolution was lacking.

[2N3055]

The advantage of using decimated data is that it is fast but you basically need to have the waveform shape visible on screen in order for the measurement to be accurate.

That is not universal.  Tektronix uses a larger word size for the processing record to support high resolution mode,  and I assumed all DSOs did this to support higher resolution modes until I studied Rigol.  So everything present after decimation is preserved for processing, and does *not* have to be visible in the display record.

The old standard for Tektronix 8-bit DSOs was to display 200 counts over 8 vertical divisions, leaving at least 25 counts above and below the display that still get included in measurements.  This also prevents vertical aliasing in the display record while simplifying the processing to produce the display record.  The counts get multiplied with averaging or high resolution modes.

A good DSO which uses decimated data for measurements will refuse to produce a result for data which has been decimated too much to make sense.

Tektronix was really good about that in their older DSOs.  Besides indicating if horizontal or vertical resolution was suspect, measurements would vary the number of displayed significant digits to match the quality of the data.  They published the algorithms that they used for calculating the data, but never how they determined significant digits or whether to indicate that resolution was lacking.

You are confusing vertical resolution with decimation in time axis.

For instance: Siglent uses 16 bit internal resolution for vertical, even for 8 bit touch scopes. Because of HiRes.
Main acquisition memory is mapped to display and separately a large  measurement buffer is formed that is used for the measurements, math. Because of that you can have very accurate measurements even on longer timebases.

So basically what Keysight has now is same as Siglent in general design. If data is too decimated will depend on size of measurement buffer and measurement.

[David Hess]

You are confusing vertical resolution with decimation in time axis.

I did not, however I can see how it could seem that way.  The waveform shape does not have to be visible on screen, unless the display record is used for measurement.

So basically what Keysight has now is same as Siglent in general design. If data is too decimated will depend on size of measurement buffer and measurement.

At least with Tektronix, amplitude measurements operate on a histogram made from the processing record instead of the processing record itself, so would not care about decimation either way as long as enough data was present.  There is a way for timing measurements to be made on the same histogram, but I do not know if anybody does this except maybe LeCroy.   Tektronix did not show this method in their list of algorithms.

Of course Keysight and Siglent do not specify what algorithms they use so who knows what is really going on, and the information about Tektronix may not apply to their current DSOs.

[nctnico]

You are confusing vertical resolution with decimation in time axis.

I did not, however I can see how it could seem that way.  The waveform shape does not have to be visible on screen, unless the display record is used for measurement.

I wrote this as a rule of thumb relevant to the way megazoom based Keysight oscilloscopes work in general. AFAIK Tektronix is using the acquired data for measurements (probably with some optimisations).

[2N3055]

You are confusing vertical resolution with decimation in time axis.

I did not, however I can see how it could seem that way.  The waveform shape does not have to be visible on screen, unless the display record is used for measurement.

So basically what Keysight has now is same as Siglent in general design. If data is too decimated will depend on size of measurement buffer and measurement.

At least with Tektronix, amplitude measurements operate on a histogram made from the processing record instead of the processing record itself, so would not care about decimation either way as long as enough data was present.  There is a way for timing measurements to be made on the same histogram, but I do not know if anybody does this except maybe LeCroy.   Tektronix did not show this method in their list of algorithms.

Of course Keysight and Siglent do not specify what algorithms they use so who knows what is really going on, and the information about Tektronix may not apply to their current DSOs.

Sorry if I misunderstood. But display record is not and does not have to be used. What is used is that time markers defined by what is on the screen is used as boundaries as to what data is included in analysis record.  So you have screen record that is actual pixels, same time extent of data as on screen (same part of captured waveform) in more detail (64k-32Mpts) for measurements and main capture memory with full data. Of course if timebase settings are such that you have more captured in main memory than analysis record, then it will decimate for analysis. If you have exactly the same number of points they will be the same, and what is not clear is what happens when main sample buffer has only say 100 points. Obviously, it will up-interpolate for screen, but I don't know if analysis record will also be up interpolated..

What I wrote about Keysight is based exactly on what they published how they do it: They make decimated version of full acquisition buffer (decimation is performed by skipping, or throwing away, of the samples) and use that to make all measurements and math. This is exactly what they used to do in MSOX3000T (and it's brethren) but before buffer was static 64k, and now it is configurable.
How individual measurements are done I don't know, that is not really documented.

I do know that Siglent uses histograms for certain things (like establishing thresholds for certain measurements baselines.  They also have some algorithms to establish viability of data to produce good measurements, but I can't comment on details.