NEW Keysight HD3

[tooki]

Sadly it’s par for the course at this point. The Rohde & Schwarz MXO4 was introduced two years ago, but the Zone Trigger hardware button on the front panel was useless until the firmware update released 2 weeks ago…

[Bud]

The boot screen bitmap is pathetic, looks as it was made for a bigger screen size.
The whole thing looks a prototype.

[MarkL]

A couple of notes on the acquisition rate comparison from the video...

It seems that the R&S MXO4 has rate thresholds related to record length.  In the initial rate test in the video, the Keysight HD3 was getting 1.03M wfms/sec and the MXO4 was 408k wfms/sec.  The HD3 was using 6.4kpts per record and the MXO4 was 6kpts.  I think the 6kpts must have been manually entered into the MXO4, as the scope does not choose that value by itself.

If you let the MXO4 choose a value close by, it will pick 5kpts.  With a 5kpts record length, the rate goes up to 904k wfms/sec.  It still doesn't top the HD3, but is much closer.

Turning on plain measurements, standard deviation (RMS) and Pk-Pk from the video, does NOT affect the 904k wfms/sec on the MXO4.

However, what does kill it is the statistics, which Dave had on by default on both scopes.  With statistics on and 5kpts record length, the MXO4 rate drops to 2k wfms/sec, which is awful.

Maybe R&S will move statistics to hardware computation?  (Yet another post-release thing?)

[artur0089]

Performance should be compared after resetting to factory settings.

[Martin72]

Sorry, don't remember. I'd have to set it up again.

That would be good and in this context you might want to check the settings on the MX04 again.
The measurement result from the HD3 could now be easily reproduced with the SDS3000X HD and SDS2000X HD - it is very unlikely that an MX04 is “worse” than these two models.
Perhaps the ADC test part (37:10 - 38:14) should be revised again, see this post:

https://www.eevblog.com/forum/testgear/siglent-sds3000x-hd-and-upgraded-sds1000x-hd/msg5633247/#msg5633247

[maxwell3e10]

A couple of notes on the acquisition rate comparison from the video...

It seems that the R&S MXO4 has rate thresholds related to record length.  In the initial rate test in the video, the Keysight HD3 was getting 1.03M wfms/sec and the MXO4 was 408k wfms/sec.  The HD3 was using 6.4kpts per record and the MXO4 was 6kpts.  I think the 6kpts must have been manually entered into the MXO4, as the scope does not choose that value by itself.

If you let the MXO4 choose a value close by, it will pick 5kpts.  With a 5kpts record length, the rate goes up to 904k wfms/sec.  It still doesn't top the HD3, but is much closer.

Turning on plain measurements, standard deviation (RMS) and Pk-Pk from the video, does NOT affect the 904k wfms/sec on the MXO4.

However, what does kill it is the statistics, which Dave had on by default on both scopes.  With statistics on and 5kpts record length, the MXO4 rate drops to 2k wfms/sec, which is awful.

Maybe R&S will move statistics to hardware computation?  (Yet another post-release thing?)

So, I looked back at Dave's video closely, he uses 100 nsec/div scale, or 1 usec full time range. And HD3 shows waveform update rate of 1.03 MHz. Now that is impossible, it can't be more than 1 MHz !  An update rate of 904 k waveforms/sec is reasonable, about 90% recording fraction.

[Someone]

So, I looked back at Dave's video closely, he uses 100 nsec/div scale, or 1 usec full time range. And HD3 shows waveform update rate of 1.03 MHz. Now that is impossible, it can't be more than 1 MHz !  An update rate of 904 k waveforms/sec is reasonable, about 90% recording fraction.

Its not impossible, but it would be a significantly new/improved way of operating if that was overlapping multiple time segments from the same stream.

[maxwell3e10]

So, I looked back at Dave's video closely, he uses 100 nsec/div scale, or 1 usec full time range. And HD3 shows waveform update rate of 1.03 MHz. Now that is impossible, it can't be more than 1 MHz !  An update rate of 904 k waveforms/sec is reasonable, about 90% recording fraction.

Its not impossible, but it would be a significantly new/improved way of operating if that was overlapping multiple time segments from the same stream.

That's not how a scope works, it should have one trigger per screen, show one continuous waveform around the trigger and hold off to trigger again until the end of the waveform.  Of course the scope can output anything it wants on the trigger out signal, maybe just the activation of the trigger circuit that does not lead to a new  acquisition. 

[Jay_Diddy_B]

Hi,

Here is a test that I ran on my Tektronix MSO46 4-BW-500 12-bit scope. I have connected a signal generator set to -96dBm (3.5uV), this is 15uV - 12 dB, to channel 1:



The signal is very clearly visible in the FFT display.

Jay_Diddy_B

[Someone]

So, I looked back at Dave's video closely, he uses 100 nsec/div scale, or 1 usec full time range. And HD3 shows waveform update rate of 1.03 MHz. Now that is impossible, it can't be more than 1 MHz !  An update rate of 904 k waveforms/sec is reasonable, about 90% recording fraction.

Its not impossible, but it would be a significantly new/improved way of operating if that was overlapping multiple time segments from the same stream.

That's not how a scope works, it should have one trigger per screen, show one continuous waveform around the trigger and hold off to trigger again until the end of the waveform.  Of course the scope can output anything it wants on the trigger out signal, maybe just the activation of the trigger circuit that does not lead to a new  acquisition.

Not how most scopes work but that does not mean it is impossible, or no scopes shall ever do it. Some scopes already use such a "trick" of overlaying multiple triggers within the horizontal sweep time when drawing eye diagrams for example.

[maxwell3e10]

So, I looked back at Dave's video closely, he uses 100 nsec/div scale, or 1 usec full time range. And HD3 shows waveform update rate of 1.03 MHz. Now that is impossible, it can't be more than 1 MHz !  An update rate of 904 k waveforms/sec is reasonable, about 90% recording fraction.

Its not impossible, but it would be a significantly new/improved way of operating if that was overlapping multiple time segments from the same stream.

That's not how a scope works, it should have one trigger per screen, show one continuous waveform around the trigger and hold off to trigger again until the end of the waveform.  Of course the scope can output anything it wants on the trigger out signal, maybe just the activation of the trigger circuit that does not lead to a new  acquisition.

Not how most scopes work but that does not mean it is impossible, or no scopes shall ever do it. Some scopes already use such a "trick" of overlaying multiple triggers within the horizontal sweep time when drawing eye diagrams for example.

Well, take a periodic signal and try to draw a diagram how you would overlap multiple segments of it on top of each other so the signal lines up and the trigger lines up - you can't. For eye diagrams clearly the signals don't line up. Incidentally, to get maximum update rate the period of the signal should either be  close to a an integer fraction of the time window or be much smaller than the time window, so the scope does not have to wait long for the next trigger after finishing the previous waveform. So the 904 kwfs/sec could potentially be improved slightly depending on signal used.

One possibility is that the counter trigger was not setup correctly in Dave's video, so it would count both rising and falling edges of the trigger out and in reality the update rate is half as big.

[Someone]

So, I looked back at Dave's video closely, he uses 100 nsec/div scale, or 1 usec full time range. And HD3 shows waveform update rate of 1.03 MHz. Now that is impossible, it can't be more than 1 MHz !  An update rate of 904 k waveforms/sec is reasonable, about 90% recording fraction.

Its not impossible, but it would be a significantly new/improved way of operating if that was overlapping multiple time segments from the same stream.

That's not how a scope works, it should have one trigger per screen, show one continuous waveform around the trigger and hold off to trigger again until the end of the waveform.  Of course the scope can output anything it wants on the trigger out signal, maybe just the activation of the trigger circuit that does not lead to a new  acquisition.

Not how most scopes work but that does not mean it is impossible, or no scopes shall ever do it. Some scopes already use such a "trick" of overlaying multiple triggers within the horizontal sweep time when drawing eye diagrams for example.

Well, take a periodic signal and try to draw a diagram how you would overlap multiple segments of it on top of each other so the signal lines up and the trigger lines up - you can't. For eye diagrams clearly the signals don't line up.

A picture you say? The demo in the video had multiple periods of the waveform fitting in the horizontal sweep time. The possible trigger points in the waveform are no less valid just because they ended up by chance in the dead/redraw/prefill/postfill periods.

It is unlikely the HD3 scope is doing this because you'd have expected the marketing team to go into overdrive solving what you claimed was "impossible". It is not impossible or wrong to overlap multiple triggers onto a screen even where they share data, just a different view (which can contain more information).

[maxwell3e10]

If I understand your diagram, you start multiple separate acquisitions in the horizontal time span of the screen, but what does it get you? The question is how do you overlap the next waveform on top of the previous one. A real signal may not be exactly periodic (like a variably duty square wave) or there can be different channels with different periods.  A scope has to produce an accurate snapshot in time. Otherwise one gets flickering waveforms, which is what an eye diagram is, with long persistence.

[Someone]

If I understand your diagram, you start multiple separate acquisitions in the horizontal time span of the screen, but what does it get you? The question is how do you overlap the next waveform on top of the previous one. A real signal may not be exactly periodic (like a variably duty square wave) or there can be different channels with different periods.  A scope has to produce an accurate snap shot in time. Otherwise one gets flickering waveforms, which is what an eye diagram is, with long persistence.

Scopes already overlap multiple triggers over each other, and the points are referenced to trigger time. Why add a whole pile of "but what ifs" when it comes back to an oscilloscope shows waveforms around a trigger and its up to the user to setup the view so they can see something useful.

Existing scopes have a trigger re-arm time that is at least as long as the horizontal sweep, but that is not insurmountable. What fundamental limitation prevents a system from triggering on every instance of the trigger in the waveform? It is possible given enough resources to have the trigger re-arm time arbitrarily short, less than the horizontal sweep, down to the impractical every single sample if desired/needed.

Is that a commercially viable product? probably not. But it is not impossible.

[Kleinstein]

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.

[mikeselectricstuff]

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 centre is almost never the right place  - you're usually intrested in what happens before or after the trigger, not both.
Most higher-end scopes understand this and let you set the trigger point near the left or right of the screen - mine is pretty much always to the left.
Many cheaper scopes get this wrong and only allow centre trigger position.

[maxwell3e10]

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.
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).

[Kleinstein]

One does not have to record new data for the new pretrigger buffer.  The buffer for the pretrigger part has to be kind of circular anyway, as it is not know upfront when the trigger comes. So the pretrigger part could as well use data already in the buffer. The main point that the trigger has to do is mark the position in the buffer and than start the job of transfering data from the sampling buffer to the result (e.g. scale and add to the intensity grading and maybe do some math function). The post trigger data could be used directly as they come, but the pretrigger data need to come from memory.
With a very fast trigger rate and more than 1 trigger event on the screen one may end up the using the same data more than once.

Trigger in the center is usually the default, kind of a compromise. Usually one still wants some pretrigger data.

It could be interestring to see if it make a difference to the update rate where the trigger is on the screen. The post trigger data could in theory be faster to acess, as they don't have to come from the memory.

[David Hess]

They should be doing the same thing that old DSOs with "fast frame" capability did.  During the acquisition, the trigger records the trigger positions in the acquisition buffer, and then those trigger points are overlaid in the display record.  The difference now is that this can be done in real time like a DPO style of DSO.

Fast frame is useful because the original acquisition record is still available for processing and automatic measurements, whereas a DPO style of processing produces a histogram and does not preserve the acquisition record.

[2N3055]

I got in the mail Keysight marketing brochure:
Why Is Oscilloscope Vertical Accuracy Important?
Evaluating oscilloscope signal accuracy

Quality of the document is very low and it is really shame what Keysight published here. It literally bends the truth to push narative that their scope is so great.

To explain how bad  it is I attached older document on same topic. That older document is accurate in engineering and mathematical way. It is their own document, to make it worse..

I would suggest marketing (or whoever wrote this new piece of propaganda) to educate them self before making a new version of this shameful pamphlet and make it actually factually correct. No need to look far, Keysight own whitepapers are (used to be?) good source for education.

For decades HP/Agilent/Keysight were the gatekeepers of engineering integrity. Their manuals and whitepapers were requested reading material and sometimes best way to learn some very advanced topics.
This document made me simply sad.

But they are saying truth about one thing: vertical accuracy is important. For that purpose, Siglent actually makes several scopes that are designed to have vertical DC accuracy in 0,5% class.  In fact even their cheapest SDS800xHD has better vertical DC accuracy then their new wonder.. By factor of 3X....

[Hydrawerk]

OK, the HD3 series scope is as expensive as a used car. Is there going to be a HD2 scope??

[Neganur]

But they are saying truth about one thing: vertical accuracy is important. For that purpose, Siglent actually makes several scopes that are designed to have vertical DC accuracy in 0,5% class.  In fact even their cheapest SDS800xHD has better vertical DC accuracy then their new wonder.. By factor of 3X....

I Disagree. Same as with IC data sheets, you should be cautious when comparing values labelled as "typical".

[Martin72]

Same as with IC data sheets, you should be cautious when comparing values labelled as "typical".

Not really.
You have a min limit and a max limit, and then you have values from umpteen series of measurements on real devices, these are the typical values.
In the case of Siglent, for example, the typical values mentioned are more of an understatement.

[2N3055]

But they are saying truth about one thing: vertical accuracy is important. For that purpose, Siglent actually makes several scopes that are designed to have vertical DC accuracy in 0,5% class.  In fact even their cheapest SDS800xHD has better vertical DC accuracy then their new wonder.. By factor of 3X....

I Disagree. Same as with IC data sheets, you should be cautious when comparing values labelled as "typical".

Did you read it ?

1.5% of Full scale. For 500µV/div and 1mV/div a 2mV/div is used. Which means 6%  and 3% respectively.

EDIT: I forgot DC Offset :

DC vertical offset accuracy ± 0.1 div ± 1mV ± 1.5% of offset setting.
Here we have "clever" looking, very innocuous ± 0.1 div. That converts to 2.5%.

so it is : ± 2.5% ± 1mV ± 1.5% of offset setting


As opposed to SDS800xHD:
0.5 mV/div ~ 4.95 mV/div: ±1.5 %;
5 mV/div ~ 10 V/div: ±0.5 %;
Offset accuracy ± (0.5% of the offset setting + 0.5% of full scale + 1 mV)

That is cheapest 12bit Siglent scope you can get. And that is with much larger offset ranges than HD3.

I will double check with Siglent but as far as I know "typical" means "no worse than" in this context..
And all of 12 bit scopes from them I personally have (4 pieces, from 4 different price classes) were all well within the specs.
I do know that is not statistically significant , but does hint at trend. They do excellent job.

[nctnico]

To nitpick: 'typical' means it can be better or worse. Only 'warranted' specs are worst case limits. So if Siglent's numbers are worst case, then they should list them under 'warranted specifications'. Not typical. Typically I don't even bother to look at typical specs, I skip straight to the warranted (worst case) specs.