New Tektronix TBS2000 oscilloscopes

[nctnico]

OK, so on a DSO-X3kT with 4Mpts and 5GSa/s, that would mean a best case (single channel) 2Mpts in normal acquisition mode, which at 5GSa/s takes 400us to fill. Even on a perfect scope with zero blind time, 400us per acquisition translate into only 2,500 acquisitions per second. Which means to reach the very high waveforms the DSO-X3kT can achieve it would have to dramatically reduce the amount of memory used, i.e. at 500k acquisitions per second that just leaves 2us for acquisition + blind time, so even that perfect scope with no blind time would have to reduce the sample memory size to 10k.

As I wrote before your math is too simplified.

No, it's not. It's simply one of the critical limitations in linear sampling systems.

You don't have to fill the entire acquisition memory if you know the data is not going to be used. This is the case when a new trigger arrives before the acquisition memory is completely filled. After all at short time/div settings you'll be looking at a fraction of the acquisition memory anyway. The rest is outside the screen.

Yes, you don't have to fill the entire memory, that is clear. But if the scope doesn't then where should it get its data to zoom out from?

No new trigger means the memory is filled completely and then the data required to show the signal outside the screen will be there. Don't think in terms of fixed memory lengths. It is like starting with a new task and abandoning the old task. new trigger = reset acquisition memory addres counter.

[Someone]

We know that the DSO-X uses half memory (2Mpts) in NORMAL/AUTO mode on the *last* acquisition made after pressing STOP.

We know that the DSO-X uses a lot less than the available memory (which would be 2Mpts best case) for all acquisitions in NRM/AUTO except for the last one to maintain its very high update rates (again, it uses the full available memory on the last acquisition after pressing STOP).

So what about when the scope is in NRM and you press STOP and no further trigger appears? The scope will not have made a longer 'last' acquisition as it hasn't been triggered anymore. And the acquisitions made before STOP was pressed would only have used a small part of the available memory as otherwise the update rates would have dropped like a rock (see the formula I stated, for which there is no way around). And with the last acquisition only using a small part of the memory, there simply is no data to zoom out.

You're once again saying things are fact which you dont understand, every capture in run mode is filling a sample buffer of the same size (the halved memory). It is rendered out to the screen at a smaller resolution without dropping any of the points from every single one of those buffers. As soon as you press stop the last of those complete buffers is available to navigate/zoom through. The case of waiting for the next trigger is when you request that functionality by pressing not stop, but the single button to rearm acquisition.

Increasing the memory depth of those rigol scopes further reduces their acquisition rates, same with the Tektronix examples David is talking about, its like this with most scopes and well known.

Thanks Captain Obvious, but the point was not if scopes get slower with larger sample memory (they do) but the why. David seems to believe it's because of processing, but in reality this is simply down to basic math.

There is no basic maths you can apply to determine how fast a particular scope will update

There's basic math which tells you how long it takes to capture a specific segment, a time that no scope no matter how fast is able to beat, which is

T_capture [seconds] = size_memory [Samples] / f_sampling [Samples per second]

Knowing this, it should really be no surprise why a long memory scope will take more time to complete an acquisition cycle than a short memory scope.

I did mention the theoretical maximum capture rates, very few scopes approach those limits, and their peak performance is typically found by drastically reducing the memory depth and/or sample rate as shown in the example I presented. You cannot come up with "simple maths" to determine how fast any particular scope model will update.

David was pretty clear in his articulation about the long memory being counterproductive to update rates.

More processing power was also required to allow deep acquisition memories but both were the result of increases integration and processing power has fallen behind making very deep acquisition memories *less* useful in a general sense.  Maybe high end DSOs avoid this problem but my experience with the DSO/MDSO5000 series is that they do not; using high record lengths results in waiting for processing of each record which is fine for single shot applications where long record lengths are especially useful but it is aggravatingly slow otherwise.

This processing power problem with long record lengths is not new.  The ancient Tektronix 2230/2232 DSOs support 1k and 4k record lengths which seems laughably short by today's standards but why did they support a 1k record length at all?  Why wasn't more acquisition memory included?  It would have been trivial to do and only moderately expensive.  I suspect it was because the limited processing power available at the time could handle 1k records significantly faster so for a *better user experience*, a selectable 1k record length was made available.

My point was that the display record processing makes these DSOs operate more like they are limited by the display record length than the record length given in the specifications which in only available for saved acquisitions.  This is a deliberate tradeoff because they cannot process their full record length in an acceptable time.

[urill]

It has been a year since they released this scope. The search/marker buttons still do nothing.

[Wuerstchenhund]

No new trigger means the memory is filled completely and then the data required to show the signal outside the screen will be there. Don't think in terms of fixed memory lengths. It is like starting with a new task and abandoning the old task. new trigger = reset acquisition memory addres counter.

That would make sense but is this really what happens? Has anyone tried?

So what about when the scope is in NRM and you press STOP and no further trigger appears? The scope will not have made a longer 'last' acquisition as it hasn't been triggered anymore. And the acquisitions made before STOP was pressed would only have used a small part of the available memory as otherwise the update rates would have dropped like a rock (see the formula I stated, for which there is no way around). And with the last acquisition only using a small part of the memory, there simply is no data to zoom out.

You're once again saying things are fact which you dont understand

Well physical facts are physical facts and remain so no matter if you believe in them or not.

But actually you're right, there's something I don't understand:

every capture in run mode is filling a sample buffer of the same size (the halved memory). It is rendered out to the screen at a smaller resolution without dropping any of the points from every single one of those buffers. As soon as you press stop the last of those complete buffers is available to navigate/zoom through. The case of waiting for the next trigger is when you request that functionality by pressing not stop, but the single button to rearm acquisition.

I get the rest, but the highlighted part is impossible (i.e. the scope filling the complete 2M/1M/500k in every acqusition in NORM/AUTO mode).

http://literature.cdn.keysight.com/litweb/pdf/5989-7885EN.pdf page 08 lists the update rates for the Keysight DSO-X 3000 (considering the document is dated 2017 I assume it's the 3000T not 3000A), i.e.

- 1,030,000 updates/s at 10ns/div timebase
- 960k updates/s at 20ns/div
- 170k updates/s at 200ns/div

Let's see (and for simplicity I'll assume the scope has zero blind time):


1,030,000 updates/s at 10ns/div[/b]
10ns/div at 10 divisions => 100ns displayed segment; 100ns @ 5GSa/s => 500pts memory required to capture the displayed segment.

Now let's see how much is really captured at each acquisition:

1,030,000 updates/s means each update can't take longer than 9.7E-07s or 970ns;  970ns @ 5GSa/s results in 4850pts, i.e. each acquisition can only fill 4,850pts or less.


960k updates/s at 20ns/div[/b]
20ns/div => 200ns displayed segment; 200ns @ 5GSa/s => 1k memory required for the displayed segment.

960,000 updates/s => 1.04E-06s or 1.04us per update; 1.04us @ 5GSa/s => 5,200 points memory, i.e. each acquisition can only fill 5,200pts or less.


170k updates/s at 200ns/div[/b]
200ns/div => 2us displayed segment; 2us @ 5GSa/s => 10kpts memory req'd for the displayed segment.

170,000 updates/s => 5.88E-06s or 5.88us; 5.88us @ 5GSa/s => 29,400pts memory, i.e. each acquisition can fill no more than 29,400pts of sample memory.


Tl;dr: The scope can impossibly fill 2Mpts at each acquisition while maintaining its excessive update rates in NORM/AUTO mode. So yes, the DSO-X is 'cheating' as normal acquisitions only use a small amount of sample memory and the max available memory (2M) is only used in the last acquisition.


You still think I'm wrong? Fine, prove it.

[Wuerstchenhund]

David was pretty clear in his articulation about the long memory being counterproductive to update rates.

And while we agreed on the last part, his argumentation is still wrong.

More processing power was also required to allow deep acquisition memories but both were the result of increases integration and processing power has fallen behind making very deep acquisition memories *less* useful in a general sense.  Maybe high end DSOs avoid this problem but my experience with the DSO/MDSO5000 series is that they do not; using high record lengths results in waiting for processing of each record which is fine for single shot applications where long record lengths are especially useful but it is aggravatingly slow otherwise.

This processing power problem with long record lengths is not new.  The ancient Tektronix 2230/2232 DSOs support 1k and 4k record lengths which seems laughably short by today's standards but why did they support a 1k record length at all?  Why wasn't more acquisition memory included?  It would have been trivial to do and only moderately expensive.  I suspect it was because the limited processing power available at the time could handle 1k records significantly faster so for a *better user experience*, a selectable 1k record length was made available.

My point was that the display record processing makes these DSOs operate more like they are limited by the display record length than the record length given in the specifications which in only available for saved acquisitions.  This is a deliberate tradeoff because they cannot process their full record length in an acceptable time.

And that's where he's just wrong. The fact that acquiring a longer memory sample takes more time has *nothing* to do with processing power, simply because deep memory scopes don't process the whole memory content in normal acquisition mode (they only process enough data to build the display record and perform measurements, with sample sizes comparable to short memory scopes).

The simple fact is that at a given sample rate it takes a fixed amount of time to acquire and fill a certain size of sample rate. This is one of the most fundamental laws for linear samplers, and shouldn't take much to understand.

Processing power comes into play when the memory content is analyzed, i.e. through FFT.

And because the time to fill sample memory at a given sample rate is fixed, pretty much any deep memory scope (aside from the HPAK 54600/InfiniVision) allows to manually reduce the used memory size to reduce the time needed for the acquisition to complete, thus increasing the update rate (and on scopes that lock up like Tektronix scopes do) responsiveness.

So going back to David's original argument, no, there's no advantage of having a scope with small sample memory.

[Wuerstchenhund]

It has been a year since they released this scope. The search/marker buttons still do nothing.

And they'll probably still do nothing when this scope series is retired.

Seems not much has changed with Tek 

[nctnico]

No new trigger means the memory is filled completely and then the data required to show the signal outside the screen will be there. Don't think in terms of fixed memory lengths. It is like starting with a new task and abandoning the old task. new trigger = reset acquisition memory addres counter.

That would make sense but is this really what happens? Has anyone tried?

If the Keysight scopes achieve higher waveforms/s than they should given the amount of memory versus samplerate then this is what they must be doing.

[Someone]

You still think I'm wrong? Fine, prove it.

I have so carefully framed the discussion yet you take it off in directions that make no sense, if you wanted to talk about fast sweep times then why not say that originally instead of writing several pages of off topic thread derailment?

Ideally you wouldn't have to compromise on memory depth, it would always be as deep as possible for the horizontal window. You are limited by sample rate for short captures, and memory depth for long captures, but in the in-between where neither is limiting people still choose to have a shorter memory depth than they could capture because it slows down aspects of the scope such as the waveform display rate. You can measure this so I took a rigol 1054 and did the comparison setting both scopes to 50us per division:

Waveforms	wfms/s
Rigol	Memory	Vector	Dots	Sample Rate
1054Z	12k	363	624	10MS/s
	120k	217	298	125MS/s
	600k	178	192	1GS/s
	1200k	160	170	1GS/s
	12M	60	61	1GS/s
	24M	35	36	1GS/s
Keysight
1000/2000X	500k	1800		1GS/s
3000X	500k	1746		1GS/s
3000X	2M	780		4GS/s

The theoretical zero blind time rate is 2000 wfms/s for the Keysight, and 1667 wfms/s for the Rigol (extra 2 divisions horizontal display). They're all able to run at 1GS/s for this test but the Keysight gives you no direct options to change to other memory depths, while the Rigol with all its choices fails to match the realtime performance. It even lets you choose longer depths that are captured outside the display but not shown until you stop and zoom around the capture, at the shorter memory depths the Rigol is dropping its sample rate and not putting 1GS/s data onto the screen which is why comparisons need to be made carefully. Processing (and/or memory bandwidth) is limiting the ability to draw more information to the screen and the reason why many scopes offer the choice of shorter memory depths.

Its stands as a representative example of two different scopes both of which increase their realtime update rate when showing fewer points despite it being the same acquisition time window.

To pull out the careful framing of this:

You are limited by sample rate for short captures, and memory depth for long captures, but in the in-between where neither is limiting people still choose to have a shorter memory depth than they could capture because it slows down aspects of the scope such as the waveform display rate.

There are limits but they are entirely constant with the displayed sample rate. Which leads onto this:

Tl;dr: The scope can impossibly fill 2Mpts at each acquisition while maintaining its excessive update rates in NORM/AUTO mode. So yes, the DSO-X is 'cheating' as normal acquisitions only use a small amount of sample memory and the max available memory (2M) is only used in the last acquisition.

The Keysight X series always use as much memory as possible to fill the acquisition time window, at the fastest sample rate possible. Yes when its running at fast sweep speeds then the sample rate limits the amount of memory that can be shown on the screen, and when pressing stop in such a situation you either get no more than that memory depth available or when hit with a repetitive signal the entire 1/2M buffer so there is some mystery around how its managing the acquisition memory and what might be available when you press stop. Contrast this to the rigol example above which you can ask it to sample a buffer much larger than is on the display and it will dutifully do so, continuing to show only whats on the display but capturing a large window to either side into the memory while the auto memory depth mode picked a memory depth to fit the acquisition window and no more.

But if you want to have the full memory outside the visible window to navigate through after stopping why run it realtime in such a narrow sweep window to begin with? Just set the sweep time to capture whats needed and use zoom to look at a small window if its that interesting.

Back in the real world people choose to run their scopes at less than the maximum memory depth because the processing power/memory bandwidth limitations mean it will operate faster and/or update the screen faster with more waveforms. I even managed to pull this same behaviour out in the Keysight 3000X.

No new trigger means the memory is filled completely and then the data required to show the signal outside the screen will be there. Don't think in terms of fixed memory lengths. It is like starting with a new task and abandoning the old task. new trigger = reset acquisition memory addres counter.

That would make sense but is this really what happens? Has anyone tried?

If the Keysight scopes achieve higher waveforms/s than they should given the amount of memory versus samplerate then this is what they must be doing.

There is something not obvious happening when you press stop, but its not ever giving less memory depth than the sample rate * acquisition width, sometimes more but never less.

[nctnico]

No new trigger means the memory is filled completely and then the data required to show the signal outside the screen will be there. Don't think in terms of fixed memory lengths. It is like starting with a new task and abandoning the old task. new trigger = reset acquisition memory addres counter.

That would make sense but is this really what happens? Has anyone tried?

If the Keysight scopes achieve higher waveforms/s than they should given the amount of memory versus samplerate then this is what they must be doing.

There is something not obvious happening when you press stop, but its not ever giving less memory depth than the sample rate * acquisition width, sometimes more but never less.

When you press 'stop' triggers which start a new acquisition are blocked so the memory can be filled. Nothing non-obvious happens. BTW I used to own a DSO7104A so I'm quite familiar with how Megazoom based Agilent/Keysight scopes work.

[Wuerstchenhund]

You still think I'm wrong? Fine, prove it.

I have so carefully framed the discussion yet you take it off in directions that make no sense, if you wanted to talk about fast sweep times then why not say that originally instead of writing several pages of off topic thread derailment?

If this thread derailed then it's because you replied to some postings you didn't even read and argued points that everyone else was in agreement.

But I guess the main trigger was that I said the DSO-X is 'cheating' during normal acquisitions, which as shown it does.

Anyways,...

Tl;dr: The scope can impossibly fill 2Mpts at each acquisition while maintaining its excessive update rates in NORM/AUTO mode. So yes, the DSO-X is 'cheating' as normal acquisitions only use a small amount of sample memory and the max available memory (2M) is only used in the last acquisition.

The Keysight X series always use as much memory as possible to fill the acquisition time window, at the fastest sample rate possible.[/quote]

Thank you! So now with your now re-worded statement it looks like we're finally in agreement 

Yes when its running at fast sweep speeds then the sample rate limits the amount of memory that can be shown on the screen, and when pressing stop in such a situation you either get no more than that memory depth available or when hit with a repetitive signal the entire 1/2M buffer so there is some mystery around how its managing the acquisition memory and what might be available when you press stop.

There shouldn't be a mystery how the acquisition memory is managed. While I'm not a friend of the auto-only memory management in the DSO-X I can see that it's adequate for most common measurement situations entry-level scopes are normally facing, however I still think the scope should at least show how much memory is A) available and B) actually in use.

There is something not obvious happening when you press stop, but its not ever giving less memory depth than the sample rate * acquisition width, sometimes more but never less.

Obviously, as otherwise it wouldn't be able to draw a complete waveform on the screen.

[nctnico]

There shouldn't be a mystery how the acquisition memory is managed. While I'm not a friend of the auto-only memory management in the DSO-X I can see that it's adequate for most common measurement situations entry-level scopes are normally facing, however I still think the scope should at least show how much memory is A) available and B) actually in use.

Keysight will never ever do that because the actual memory depth the scope has available can be over 8 times less than it says on the badge (all analog + digital + reference channels enabled). How to explain that?

[Someone]

You still think I'm wrong? Fine, prove it.

I have so carefully framed the discussion yet you take it off in directions that make no sense, if you wanted to talk about fast sweep times then why not say that originally instead of writing several pages of off topic thread derailment?

If this thread derailed then it's because you replied to some postings you didn't even read and argued points that everyone else was in agreement.

But I guess the main trigger was that I said the DSO-X is 'cheating' during normal acquisitions, which as shown it does.

You frame "cheating" in a very curious position, cheating is where something is doing an underhanded trick but the scope is showing all the information clearly:
The horizontal sweep time
The sample rate which it is captured at

Yes, its not capturing the data outside the window, but it never claims to be doing that. There are some occasions where it will capture the data around the screen when stopping acquisition of a repetitive signal but its not something which is documented. If you want that data outside the screen on other scopes you would set the memory depth to instruct it to capture that area, on the X series scopes you would make the acquisition window wide enough to capture that same time period.

Its different ways of working that achieve the same end result, and some of us prefer not having to manually adjust memory depths and would rather use the single horizontal control to do the same. If you don't like working that way its fine but you make out like its some huge deficiency with the product which it simply isn't.

More processing power was also required to allow deep acquisition memories

Actually, no, longer memory doesn't require more processing.

But essentially every scope on the market is limited in its realtime update/throughput rate because none of them hit the theoretical maximums attainable. There is something limiting it, its processing/computing/memory bandwidth.

The entire "argument" about needing memory depth controls is that the user needs it for some reason, in the Agilent/Keysight X series thats not needed because there is never so rarely a reason for the user to capture a smaller memory depth (even though it could be nice for some applications where the data is being offloaded).

The DSO-X, like any HPAK InfiniVision scope, is cheating as the only time it acquires a long memory segment in normal acquisition is at the last acquisition made after pressing STOP, otherwise it uses just enough memory to fill the display record.

You try and connect display record with the acquisition buffer, which are different lengths and shapes. In the non sample rate limited examples I showed the display record (of note when measurements are derived from it) is much shorter in horizontal samples than the acquisition record, which is maximised under all conditions to the speed of the sweep.

Note that on Auto, some scopes will not utilise the full sample rate and memory depth available because that would degrade the realtime/interactive performance/rate of the scope, because they have limited processing to keep up with the longer memory depths. Yet you spend several pages trying to disguise this simple point with discussion about the way that the Keysight X series which always maximise the memory depth (even where that is reducing the update/throughput rate) is somehow less ideal.

[Someone]

No new trigger means the memory is filled completely and then the data required to show the signal outside the screen will be there. Don't think in terms of fixed memory lengths. It is like starting with a new task and abandoning the old task. new trigger = reset acquisition memory addres counter.

That would make sense but is this really what happens? Has anyone tried?

If the Keysight scopes achieve higher waveforms/s than they should given the amount of memory versus samplerate then this is what they must be doing.

There is something not obvious happening when you press stop, but its not ever giving less memory depth than the sample rate * acquisition width, sometimes more but never less.

When you press 'stop' triggers which start a new acquisition are blocked so the memory can be filled. Nothing non-obvious happens. BTW I used to own a DSO7104A so I'm quite familiar with how Megazoom based Agilent/Keysight scopes work.

When zooming out on these long captures there is both pre and post trigger expansion of the memory, it could just be a side effect of the pointers but that would block the pingpong memory allocation which increases memory throughput. So given its related to the frequency of the repetitive signal I think there might be a short timer after pressing stop where it will accept a new trigger and fill out the memory (8Hz and up measured quickly here).

[nctnico]

Try a signal with a much longer interval and you'll see it won't wait for a new signal after pressing stop.

[Someone]

Try a signal with a much longer interval and you'll see it won't wait for a new signal after pressing stop.

Yes, there appears to be some maximum time between pressing stop and the next trigger after which it wont make the extra (and sometimes longer) capture.

[Wuerstchenhund]

But I guess the main trigger was that I said the DSO-X is 'cheating' during normal acquisitions, which as shown it does.

You frame "cheating" in a very curious position, cheating is where something is doing an underhanded trick but the scope is showing all the information clearly:
The horizontal sweep time
The sample rate which it is captured at

The used memory size - Oops, it doesn't show that.

Yes, its not capturing the data outside the window, but it never claims to be doing that. There are some occasions where it will capture the data around the screen when stopping acquisition of a repetitive signal but its not something which is documented.

Great

The point is that on every other decent scope I know what is going on in any situation, and not just how fast it samples but also how much sample memory is used (even Keysight's other scopes show this).

If you want that data outside the screen on other scopes you would set the memory depth to instruct it to capture that area, on the X series scopes you would make the acquisition window wide enough to capture that same time period.

So essentially if you want to capture a longer segment in NORM/AUTO mode you have to make sure the whole period fits on the screen, i.e. you have to treat a deep memory scope like a small memory scope (i.e. fit the whole period into the few thousand points it uses during repetitive acquisitions), and potentially suffer from the drawbacks (i.e. a drop of sample rate because of the extension of the time base). While on every other decent scope you just set the scope to use more memory, and be done with it, without a drop in sample rate.

Yes, I can clearly see the advantage of not having any control about the memory use in the DSO-X 

Its different ways of working that achieve the same end result, and some of us prefer not having to manually adjust memory depths and would rather use the single horizontal control to do the same. If you don't like working that way its fine but you make out like its some huge deficiency with the product which it simply isn't.

Well, having no control and not even indications about the memory use is an issue (your mentioned workaround is just a crutch and as stated has its own problems), and while you might not have come across it doesn't mean it's not a problem. Most of our engineers like the DSO-X (we don't have any of the smaller ones just a bunch of DSO/MSO-X4104A and DSO/MSO-X4154As, plus I think one or two DSO-X6004As), but still for the more complex tasks they're pretty much sitting on the shelf and a different scope on the bench, because you have no control over the sample memory. So yes, it's an issue for us.

You're also ignoring the fact that the DSO-X is pretty much the only decent scope without memory controls. Every other scope, even those that do offer automatic memory management, allow the user to setup memory manually (and keep the user informed about how much memory is in use). If having no control over the sample memory wasn't a problem as you seem to believe then there must really be a lot of stupid product developers out there who could have easily saved the cost of implementing manual controls. But then, the fact that even Keysight's non-InfiniVision scopes do allow manual memory control should already have told you something.

More processing power was also required to allow deep acquisition memories

Actually, no, longer memory doesn't require more processing.

But essentially every scope on the market is limited in its realtime update/throughput rate because none of them hit the theoretical maximums attainable. There is something limiting it, its processing/computing/memory bandwidth.

Yes, but that is pretty much by choice. Excessively waveform update rates have been achievable before (>1M waveforms/s isn't really new), but there's obviously a cost due to the higher memory BW and processing requirement, which means a more expensive product, or if you go HPAK's way (using an special purpose ASIC architecture of which principal development has concluded 20 years ago and where the initial development costs have been recouped by now) you save on monetary costs but end up with a scope that is pretty much optimized for excessive waveform update rates at the cost of features and flexibility.

Taking the Rigol DS1054z that seems to be a preferred example, it's obviously limited in both memory BW and processing power, but that was a conscious choice by Rigol to reach the very low price point the DS1054z is sold at.

You try and connect display record with the acquisition buffer, which are different lengths and shapes. In the non sample rate limited examples I showed the display record (of note when measurements are derived from it) is much shorter in horizontal samples than the acquisition record, which is maximised under all conditions to the speed of the sweep.

Thanks again, Captain obvious. It's not like I already showed that in my calculations above, is it?

You really need to start paying attention.

Note that on Auto, some scopes will not utilise the full sample rate and memory depth available because that would degrade the realtime/interactive performance/rate of the scope, because they have limited processing to keep up with the longer memory depths.

That's wrong (if you disagree, name these scopes!). Pretty much every decent scope will of course utilize the full sample rate and the setup memory depth in AUTO mode. And as stated already, scopes don't process the whole memory content during normal acquisitions, just a smaller part required for display content generation and measurements, so there is no processing penalty from longer memory in normal acquisition mode.

Or are you talking about automatic memory management on other scopes? If so, then you're still wrong, as scopes will always maintain the sample rate which is possible at the given timebase setting (based on what the physically available sample memory allows for) and only adjust the used record length to capture enough for screen generation and measurements.

Also, aside from Tek scopes, the UI performance is independent on the record length, i.e. they don't lock up the UI until the acquisition is finished but will rather abort the current acquisition alltogether if the user input demands so. So long memory acquisitions have no impact on the interactive performance, just on the update rate.

Yet you spend several pages trying to disguise this simple point with discussion about the way that the Keysight X series which always maximise the memory depth (even where that is reducing the update/throughput rate) is somehow less ideal.

OK First, it was you who started a discussion about the DSO-X, as before then it was simply about old short memory scopes and newer deep memory scopes, and if the deep memory really is a benefit or just a marketing gimmick. Second, you came in addressing points that weren't even debated, and without even understanding the scope you feel the need to defend 'til death (i.e. like your comment about the DSO-X fully using the available free sample memory in every acquisition, which was nonsense). And third, while I appreciate that you found your own way around the limitations, you ignore that not everyone has the same requirements, as well as the fact that pretty much every other decent scope does offer memory controls and tells its user about the memory in use, which is for a reason.

If your DSO-X3000A (if I remember right) works fine for you, great, more power to you. But don't fall into the trap to extrapolate your own use case on the rest of the EE world.

[Someone]

If you want that data outside the screen on other scopes you would set the memory depth to instruct it to capture that area, on the X series scopes you would make the acquisition window wide enough to capture that same time period.

So essentially if you want to capture a longer segment in NORM/AUTO mode you have to make sure the whole period fits on the screen, i.e. you have to treat a deep memory scope like a small memory scope (i.e. fit the whole period into the few thousand points it uses during repetitive acquisitions), and potentially suffer from the drawbacks (i.e. a drop of sample rate because of the extension of the time base). While on every other decent scope you just set the scope to use more memory, and be done with it, without a drop in sample rate.

Again you run in as many different claims as possible into a simple point.

So essentially if you want to capture a longer segment in NORM/AUTO mode you have to make sure the whole period fits on the screen,

Yes, what would be the value in having information off the screen but still captured? Reading the Lecroy WS3000 manual is says that the maximum memory setting is overridden and shorter memory depths are used at fast sweep speeds, not capturing the extra samples around the sweep window just like the Keysight X series does. But even if you want that its possible to do something similar so its not a lacking feature...

i.e. you have to treat a deep memory scope like a small memory scope (i.e. fit the whole period into the few thousand points it uses during repetitive acquisitions)

No, you again jump to the conclusion that there will be some small memory depth used when I'm explaining how to access the full memory depth. Its right there in plain sight if you want to capture the full memory depth available, just keep winding out the horizontal sweep until you've got it all in the acquisition window (or go one step further, watch the sample rate drop and return back to the maximum depth). Its then acquiring that entire memory depth, not "thousands of points".

and potentially suffer from the drawbacks (i.e. a drop of sample rate because of the extension of the time base).

The limitations of memory depth and sample rate tradeoff are the same on all scopes, this isn't something particular here. You can access the full memory depth if you wish to, or not. The major limitation is not being able to request a lower memory depth and drop the sample rate for a given time acquisition window, but as discussed above thats a narrow use case where you might want to increase the waveform rate (which you say is already "excessive") or then offload a particular number of samples for processing.

While on every other decent scope you just set the scope to use more memory, and be done with it, without a drop in sample rate.

Lengthening the memory depth of the record either a) increases sample rate, or when limited by sample rate b) increases the acquisition window both of these are available on the X series, there is no drop in sample rate. Or are you moving the goal posts once again and trying to make comparisons of unmentioned specific conditions where the shorter maximum memory depth of the X series scopes could be compared to some other scope? More memory is also a nice thing to have for some situations, but thats getting wildly off track again.

Note that on Auto, some scopes will not utilise the full sample rate and memory depth available because that would degrade the realtime/interactive performance/rate of the scope, because they have limited processing to keep up with the longer memory depths.

That's wrong (if you disagree, name these scopes!). Pretty much every decent scope will of course utilize the full sample rate and the setup memory depth in AUTO mode. And as stated already, scopes don't process the whole memory content during normal acquisitions, just a smaller part required for display content generation and measurements, so there is no processing penalty from longer memory in normal acquisition mode.

Or are you talking about automatic memory management on other scopes? If so, then you're still wrong, as scopes will always maintain the sample rate which is possible at the given timebase setting (based on what the physically available sample memory allows for) and only adjust the used record length to capture enough for screen generation and measurements.

The rigol example above (a low end scope being compared in a thread about another competitors low end scope) doesnt use the full memory depth when set to Auto.

And as stated already, scopes don't process the whole memory content during normal acquisitions, just a smaller part required for display content generation and measurements, so there is no processing penalty from longer memory in normal acquisition mode.

You're looping back around and not qualifying this, are you still trying to talk about the fast sweep speeds where most of the acquisition record is off the screen? Because I was clearly talking about auto memory mode where the scope has latitude to pick a memory depth to fill the entire sweep window, where they do need to process all the acquisition memory depth and draw it to the screen, and its well known that increasing the memory depth (increasing sample rate at the same time as the window is a constant width) greatly reduces the update rate of most scopes.

I'll pull up some figures for a tek DPO4000 at different memory depths to illustrate later (a scope with no Auto setting for memory depth). There are some scopes that you can set into modes where the acquisition records aren't all being drawn to the screen, and they can have extremely low blind time but only for the n number of acquisitions that are held in memory, unlike accumulating acquisitions into a graduated display/eye diagram/etc which is processing intensive.

[Someone]

More processing power was also required to allow deep acquisition memories but both were the result of increases integration and processing power has fallen behind making very deep acquisition memories *less* useful in a general sense.  Maybe high end DSOs avoid this problem but my experience with the DSO/MDSO5000 series is that they do not; using high record lengths results in waiting for processing of each record which is fine for single shot applications where long record lengths are especially useful but it is aggravatingly slow otherwise.

This processing power problem with long record lengths is not new.  The ancient Tektronix 2230/2232 DSOs support 1k and 4k record lengths which seems laughably short by today's standards but why did they support a 1k record length at all?  Why wasn't more acquisition memory included?  It would have been trivial to do and only moderately expensive.  I suspect it was because the limited processing power available at the time could handle 1k records significantly faster so for a *better user experience*, a selectable 1k record length was made available.

I had some free time to record and chart some of this behaviour, in a Rigol 1104Z and a much older Tek DPO4000. As always the results are interesting.




Each scope has the same behaviour of capturing the memory depth selected by extending the acquisition buffer each side of the trigger outside the window on the screen, this region of operation is shown with dotted lines toward the right. At the other extreme aliasing did occur in both scopes and captures that were unrecognisable from aliasing are shown dotted to the left. Turning on zoom on the Tek drops the capture rate, as it does if maths/FFT is enabled but more on that later. The trigger was set to the middle of the screen and then peak capture rates were measured at each horizontal setting against the benchmark 1MHz square wave. This has the Rigol running in vector mode as that is where most people would be using it, I'm well aware the capture rates jump up if you turn on dots mode but this is about comparing scopes doing the same thing (as near as possible).

The Tek DPO hugs the theoretical maximum update rate closely until 10us/div and bizarrely gets lower update speeds at the 1k record length throughout much of the operating range which is likely related to memory packing and bandwidth (in-)efficiencies in the DDR2 ram:
https://www.eevblog.com/forum/repair/repairing-tektronix-dpo4000mso4000-series-scopes/
Then there is the other odd drop off as the short memories zoom in on the middle of their acquisition. As memory depth is increased no surprises the update rate drops off quickly suggesting a limit in the rendering system.

Turning instead to the Rigol it has less change in the rates between the different memory depths, but doesnt extend to the same high extremes as other scopes do. Its doing a much better job of keeping up with the 10M/12M deep memory but there is some path in getting the rendering to the display limiting all the modes to less than the Tek (not just explained by the difference of 10/12 divisions). Going back to processing when turning on the FFT (in its normal mode) the Rigol doesnt slow down the acquisition rate as its taking the data from the display, this limits its length in points but keeps it running with a respectable and useful speed as discussed previously.

DSOX1000 64k point FFT, 3 updates/second
DS1054Z 64k point FFT, 1 update/second

DSOX1000 1k point FFT, 60 updates/second
DS1054Z 1k point FFT, 3 updates/second
DS4000 1k point FFT, 8 updates/second

But the Tek DPO4000 did drop its capture rates when processing its FFTs or maths, and putting its FFT update rates in context:

DPO4000 1M point FFT, 0.08 update/second (greater than 13 seconds between FFT completions!)

DPO4000 100k point FFT, 1 update/second

DSOX1000 64k point FFT, 3 updates/second
DS1054Z 64k point FFT, 1 update/second

DPO4000 10k point FFT, 10 updates/second

DSOX1000 1k point FFT, 60 updates/second
DS1054Z 1k point FFT, 3 updates/second
DS4000 1k point FFT, 8 updates/second
DPO4000 1k point FFT, 24 updates/second

If we can collect enough data this too could make an interesting plot, but it needs a relatively high speed camera to accurately measure.

So the ageing Tektronix is still "better" than the low end Rigol in most respects, but they're limited in subtly different ways. The surprise is that the processing for the "deep" memory has in fact improved in the Rigol despite its low cost.

[Wuerstchenhund]

[...]

Seems you're a very slow learner, so I'll quickly summarize the relevant points for you:

1.) David and I were discussing if deep memory is actually useful or just a marketing gimmick (David thought it's more of a gimmick, I think it's very useful, as demonstrated on an example used in an older posting of mine).

2.) We both are well aware that at a given sample rate more sample memory means lower waveform rates, the point of discussion was about the 'why' (David believed this was due to increased processing, which was wrong as the additional data in a long memory scope is not processed during normal acquisitions; the lower wavform rate comes simply from the fact that more memory needs longer to be filled).

3.) When David and I were talking about long memory and it's relation to a scope's processing, we were referring to what was technically feasible back in the mid-'90s.

4.) Yes, the Keysight DSO-X, like all InfiniVision scopes back to the HP 54600 Series, is 'cheating' in normal acquisition mode as it only uses a small record size to maintain high waveforms, makes only use of the available free sample memory (half, quarter or 1/4th of 4M on the DSOX3k) in the last acquisition after pressing STOP, and only uses the full sample memory in a SINGLE acquisition, all while giving the user zero indication about the actual memory used.

I guess the last point made you jump in (as for some reason you seem to always do as soon as someone criticizes the DSO-X Series) as you clearly (according to your own statements) believed somehow the DSOX uses the full available sample memory (half, quarter or 1/4th of 4M on the DSOX3k) in every acquisition in normal acquisition mode, which as I've shown is physically impossible.

Even worse than you not knowing how your own scope works though is that you constantly jump in arguing about stuff no-one else was arguing about, which is the only reason this thread has derailed so much. For example, when David and I were debating the usefulness (or not) of deep memory, I cited an earlier post of mine showing the sample rate drop in a Tek TDS694 small memory scope vs a LeCroy WavePro 900 deep memory scope on longer time bases, on which for some reason beyond me you jumped in saying I shouldn't hamper on scopes with advanced analysis functions, even though such functionality wasn't even part of the discussion And this wasn't the only time you argued stuff no-one else was debating.

It appears you have a serious problem reading and actually comprehending written English, it seems you just skim over the text, jump to some conclusion about what it probably was about, and then rush out arguing whatever you think is worth doing so. It would be more productive if you'd just read carefully, maybe twice, then think about what the text really says before posting. I've seen some good posts from you but your tendency to argue points that weren't even an issue is seriously letting you down.

I had some free time to record and chart some of this behaviour, in a Rigol 1104Z and a much older Tek DPO4000. As always the results are interesting.

Yes, but like most what you have said in this thread it's also completely irrelevant to both what has been discussed and the topic of this thread (which is Tek's TBS2000). It really seems you've lost the plot completely now (FFT rates of a $300 and a $15k scope? WTF?).

Anyways, I'm no longer sure what points you're really arguing about, so that's the point I think I should leave you to yourself

[MrW0lf]

1.) David and I were discussing if deep memory is actually useful or just a marketing gimmick (David thought it's more of a gimmick, I think it's very useful, as demonstrated on an example used in an older posting of mine).

Interestingly enough Pico has just come up with feature called "DeepMeasure" that will chew up to 1M wfms (100M pts) and format as Excel-style table:
https://www.picotech.com/library/oscilloscopes/deepmeasure?hpc3

However I am in deep sadness as auto-measurement aficionado because this feature seems to be limited to USB 3.0 scopes and my 2408B is USB 2.0

[Wuerstchenhund]

1.) David and I were discussing if deep memory is actually useful or just a marketing gimmick (David thought it's more of a gimmick, I think it's very useful, as demonstrated on an example used in an older posting of mine).

Interestingly enough Pico has just come up with feature called "DeepMeasure" that will chew up to 1M wfms (100M pts) and format as Excel-style table:
https://www.picotech.com/library/oscilloscopes/deepmeasure?hpc3

However I am in deep sadness as auto-measurement aficionado because this feature seems to be limited to USB 3.0 scopes and my 2408B is USB 2.0

Hm...

Limitations
- DeepMeasure works with up to 100 million samples in each acquisition.
- Maximum number of cycles that can be processed in each acquisition is one million. (So not a very severe limitation!)
- While running, the number of cycles updated live is limited to 50,000. Additional cycles are processed and displayed when the acquisition is stopped, or with single shot acquisition.
- Multiple buffers in PicoScope can be set to trigger and capture successive waveforms; - DeepMeasure will process each buffer, up to the 100 million samples total limit.
- DeepMeasure works with PicoScope 3000, 4000, 5000 and 6000 Series instruments.

I assume 'cycle' refers to the waveform's cycle, or do they mean something else (i.e. screen cycle)?

Anyways, it's an interesting approach but without knowing more or having seen it in use I can't see any big advantages over say the histogram function on a good bench scope, which also works for a lot more measurements.

But then I don't have any noteworthy experience with PicoScopes (a few colleagues use them in automated test environments, we don't use them on the bench) so I could be missing something.

[MrW0lf]

...well at last they clearly state limitations so one can do informed decision, not buy a pig in designer bag like it might happen with certain other brands
Otherwise Im quite convinced that they refer to actual waveform cycle, since "screen" has little meaning in Pico software.
The point here seems to be event correlation, just like with regular vs time-correlated FFT. Probably you click line-of-interest in table and get navigated to specific place in record, where can inspect wfm in detail + events on other channels (digital or analog).
Further from this can only guess. Seems no demo feature for this. Some glitch in the matrix, actually it shows up in new beta demo mode.

[egonotto]

Hi,

in https://www.picotech.com/library/picoscope/picoscope-release-6.13.1-beta you read:

"
DeepMeasure is compatible with PicoScope 3000, 4000, 5000 and 6000 Series deep memory instruments
"
DeepMeasure seems only in PicoScope 6.13.1 Beta  from Aug 17 2017 available.

Perhaps I try it.

It is very new.

Best regards
egonotto

[Someone]

2.) We both are well aware that at a given sample rate more sample memory means lower waveform rates, the point of discussion was about the 'why' (David believed this was due to increased processing, which was wrong as the additional data in a long memory scope is not processed during normal acquisitions; the lower wavform rate comes simply from the fact that more memory needs longer to be filled).

Yet you keep only considering the case where adding more memory depth increases the acquisition depth and not the number of those points making it to the screen, and never framed that even when I was explicitly discussing the much more typical operation of an oscilloscope increasing the memory depth where there is sample rate available to keep the entire acquisition on the screen.

But even if you look at the cases where there is a tiny portion of the memory depth displayed on the screen as in the plots above, the Tektronix DPO in its 10M memory depth fails to get close to its theoretical acquisition rate of 250 acquisitions/second, a similar ratio between theoretical maximum and the peak in operation is seen in its 1M mode. Its limited by its ability to process the data, in the case you frame, in the typical use cases, in all cases...

Not all scopes follow that pattern of operation, and adding more memory around the visible portion is some narrow use case very rarely needed (which you have not even attempted to describe its practical applications) but you focus intently on that (without explaining it) and not the more realistic cases.

And as stated already, scopes don't process the whole memory content during normal acquisitions, just a smaller part required for display content generation and measurements, so there is no processing penalty from longer memory in normal acquisition mode.

Its this sort of unqualified statement you keep making that is so obnoxious, during normal acquisitions scopes do process the entire memory depth to the display....
when that acquisition length is the length of the display, which is the most common operation of scopes, such as when set to automatic memory depth.
In this (most common case) then reducing the memory depth will generally increase acquisition rates, which are limited by the processing of the scope.

There are examples from Lecroy and Keysight that wont let you set a memory depth larger than this and always reduce the memory depth to whats on the screen. To say the condition never exists with such certainty is plainly ridiculous.

[blanchae]

We purchased this model scope (18 scopes) for our electronic labs and had high expectations. But we have run into a few issues with it:

1. Random lockups and misconfigurations that require hitting the "default setup" to clear and restart the scope.
2. The menu configuration process is just plain awkward, almost to the point of frustrating
3. These are noisy scopes - the noise floor is excessive as far as I'm concerned
4. The timebase trigger is "weak", difficult to trigger on low amplitude signals

I don't trust the on screen measurements that the scope displays (Vpp, min, max, etc..) The values depend on what your amplitude setting is set to. I've used oscilloscopes since the early 70s and when you start to question your measurement instrument's reading then that is a problem.