Oscilloscope Zoom Out Quirk

[Someone]

To summarise, I think STOP mode or Single Mode should ultislise all available hardware memory regardless of current memory setting and at the fastest sample rate. This is clearly what Keysight have opted to do.
And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".

nctnico's corner case is when there isn't a repetitive trigger to create that larger capture. That "magic" capture when pressing stop only happens under specific circumstances so it can't be relied upon in regular use.

The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?

[nctnico]

And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.

Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.

It seems your understanding of how an oscilloscope works is severely lacking. If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.

[EEVblog]

All that extra memory around the aquisition window kills waveform update rates (a tradeoff which is completely acceptable for some uses). Here is the plot from a Tek DPO4000:

Extending the acquisition buffer each side of the trigger outside the window on the screen is shown with dotted lines toward the right. It knocks orders of magnitude off the update rate.

Although there are more intelligent memory management options, scopes are rather simple/dumb. They won't redraw/paint another trigger until the full memory depth is filled. So at 5GS/s and 10M memory depth, even a perfect zero overhead, instant trigger will only run 500 updates/s.

This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"

[2N3055]

This shows what I'we been explaining. 3000T is capturing only screen full of data from trigger to trigger. It is only when you press stop that it will reassemble some data before begin of the screen, and it will keep capturing until it runs after memory. What I suspect is that it literally goes from RUN to STOP, by capturing one SINGLE capture on next trigger after you press STOP (Just with half of the buffer because of state of capture engine at the time, the ping-pong buffers).

I presume it behaves like that, because, if press stop now, while it's waiting for next trigger, it doesn't get any additional data:
(Attachment Link)

That sounds right. It's doing just the screen worth in Normal or Auto mode because it needs the fastest update rate possible. There is no point capturing continuous updating data outside the screen if the user can't see it.
So yes, doesn't surprise me that this only works in STOP or Single mode, because these modes are, practically by their usage definition, analysis modes were you may want to expand the timebase to view that extra data. So when the scope has been instructed perform STOP or Single mode it makes sense to then capture the entire available memory length regardless of what the user has set, because update rate no longer has any relevance.

Come to think of it this way now, there should be absolutely no reason why the likes of Siglent could not implement this easily with a firmware update. The likely reason they haven't is because they just haven't thought of it before.

To summarise, I think STOP mode or Single Mode should ultislise all available hardware memory regardless of current memory setting and at the fastest sample rate. This is clearly what Keysight have opted to do.

I absolutely agree. Keysight made a very nice trick here, and I would like it to be on all scopes. But history mode (to keep hundreds of previous triggers automatically) is also very nice (i have it on Pico).
Ideally, it should be user's choice.

And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".

That is very good observation, very on point.

[Someone]

And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides.

It's only relevant if designing in this feature was done at the sacrifice of update rate in the design.
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.

Except they are mutually exclusive, the bonus full length capture of the megazoom scopes only occurs when there is another trigger after pressing stop. If you're trying to capture long record lengths of short bursts between infrequent events, pressing stop won't help.

You should use Single mode in that case

NO SHIT SHERLOCK! Or use a zoom window on the full length acquisition window so you can see it all at once without having to zoom in and out.

Can you not see the noise building way above the signal at this point of the thread?

[nctnico]

Exactly. In real world less is less.
You keep forgetting to warn people that what you do makes scope retrigger at a very, very slow rate (few times per second). So you are looking at some edge at nanosecond scale, but your screen  refreshes few times per second or slower.

Again; that trade-off isn't there. Just set the memory shorter (or let the oscilloscope set it by itself). For example: the R&S RTM3004 can do it all.

And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".

No, because that only applies to Keysight. So far only Lecroy and Siglent scopes can't record outside the screen. Don't be fooled by people who try to make capturing beyond the screen is something special. Most DSO do it except it seems very few people realise they (can) work that way.

[nfmax]

And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.

Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.

It seems your understanding of how an oscilloscope works is severely lacking. If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.

Hmm...

I think maybe just having a choice of how much acquisition memory to use is not enough. You need also to tell the scope if it should allocate memory to increasing the sample rate (for zooming in) or increasing the record length (for zooming out), and this should be independent of the X scale setting. I think the Digitizer mode of the X3000T works like this, though I have never explored it.

[Someone]

And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.

Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.

It seems your understanding of how an oscilloscope works is severely lacking. If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.

You can have the choice, more memory and fewer updates, or less memory and more updates. I have that choice too.

But you keep squeezing down the discussion to nonsense points:

capturing beyond the screen has no downsides.

It has a bunch of downsides! But you keep distracting people and adding noise rather than just presenting that as a tradeoff.

[2N3055]

And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides.

It's only relevant if designing in this feature was done at the sacrifice of update rate in the design.
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.

Except they are mutually exclusive, the bonus full length capture of the megazoom scopes only occurs when there is another trigger after pressing stop. If you're trying to capture long record lengths of short bursts between infrequent events, pressing stop won't help.

You should use Single mode in that case

That is exactly the point. It is already invented, it's called SINGLE mode. No need to achieve it trough side effects.

[nctnico]

And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.

Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.

It seems your understanding of how an oscilloscope works is severely lacking. If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.

I think maybe just having a choice of how much acquisition memory to use is not enough. You need also to tell the scope if it should allocate memory to increasing the sample rate (for zooming in) or increasing the record length (for zooming out), and this should be independent of the X scale setting.

For that some oscilloscopes have an 'automatic memory length' setting. That way it will tailor the amount of acquisition memory and samplerate depending on things like zoom mode. These aren't new problems; this has been solved decades ago.

[EEVblog]

The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?

Ah, THAT'S the magic in the capture architecture design!

This just triggered my memory! (pun of the week, surely?)
I independently solved this in my DSOA Mk3 design back in 1998 with 7200 FIFO's.
https://alternatezone.com/electronics/files/dsoamk3.txt

[2N3055]

And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.

Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.

It seems your understanding of how an oscilloscope works is severely lacking. If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.

Hmm...

I think maybe just having a choice of how much acquisition memory to use is not enough. You need also to tell the scope if it should allocate memory to increasing the sample rate (for zooming in) or increasing the record length (for zooming out), and this should be independent of the X scale setting. I think the Digitizer mode of the X3000T works like this, though I have never explored it.

Digizer mode FIXES capture rate AND memory depth. With both at max, for instance, you get 400us of data on every trigger. Retrigger rate drops to 2500 trig/sec.
No Peak detect mode, no Hires, no averaging.
With timebase knob you cannot control anything except a window what are you looking at.  It is not very useful or intuitive for G.P. interactive work. I presume it was introduced for data processing over SCPI.

[EEVblog]

And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".

No, because that only applies to Keysight. So far only Lecroy and Siglent scopes can't record outside the screen.

Err, wouldn't it apply to every scope brand that does this?, not just Keysight.
How else would it be achieved whilst keeping any resemblance of half way decent update rate?

[2N3055]

This just triggered my memory! (pun of the week, surely?)

[Someone]

The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?

Ah, THAT'S the magic in the capture architecture design!

This just triggered my memory! (pun of the week, surely?)
I independently solved this in my DSOA Mk3 design back in 1998 with 7200 FIFO's.
https://alternatezone.com/electronics/files/dsoamk3.txt

Not sure you solved it:

The RAM FILL period is required in order to allow the RAM to be at least half
filled with data. This is to ensure that the data the PC reads back will
always contain half pre-trigger information and half post-trigger
information. If a trigger was to occur before the RAM is half filled, then we
would have an indeterminable number of pre-trigger samples (if any at all).

Thats the same problem of what to do when the pre-trigger buffer isn't filled yet. With modern scopes having Mpts and Gpts of memory the pretirgger period can be substantial if you always have to fill it even when you are on a shorter timebase/memory setting.

There are many intelligent things scopes could be doing to better manage their memory, improve update rates, and retain more data for review. But that will go against the manual control of everything users that are making so much noise here.

[nctnico]

The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?

Ah, THAT'S the magic in the capture architecture design!

This just triggered my memory! (pun of the week, surely?)
I independently solved this in my DSOA Mk3 design back in 1998 with 7200 FIFO's.
https://alternatezone.com/electronics/files/dsoamk3.txt

That is how all DSOs work however not using a FIFO but a circular buffer. After all you never know when a trigger arrives. A couple of years ago I have designed a distributed data acquisition system (for a customer) which triggers on input signals to define the start of a measurement. It nearly is a DSO except for the display and knobs. When an acquisition starts it just fills the memory continously as a circular buffer. But a trigger will only be accepted once there is enough data to meet the pre-trigger requirement. If a trigger occurs during the pre-fill time then it will be lost. The pre-fill time can be avoided by setting the trigger point before the start of the acquisition (which is also something the system I designed supports).

And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".

No, because that only applies to Keysight. So far only Lecroy and Siglent scopes can't record outside the screen.

Err, wouldn't it apply to every scope brand that does this?, not just Keysight.

No. Not at all. See my earlier list.

How else would it be achieved whilst keeping any resemblance of half way decent update rate?

Why is update rate so important? In many cases it just isn't and using all the memory is far more useful. If you still have an R&S scope you can see you can set the memory to auto or use a pre-defined depth. On the R&S (for example) you can have either a short memory depth to achieve a high update rate OR select deep memory. Ofcourse deep memory will slow the acquisition rate but that isn't a problem. A lot of the work I do is in embedded firmware / hardware interaction where messages pass by at a rate of a couple of hundred per second at most.

[nfmax]

If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.

If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains.

I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity

[nctnico]

If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.

If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains.

I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity

Actually not. AFAIK Even Siglent and Lecroy already have the option to set a fixed memory depth. It is only that they choose not to actually use full memory if that results in more sample points necessary to fill the screen. In a way you could even argue that those oscilloscopes don't do what you tell them to. 

[Someone]

If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.

If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains.

I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity

Fewer samples at a lower ADC sample rate can increase the waveform update rate (no scope is completely ideal with zero trigger re-arm and zero processing time), see the huge graph of a DPO4000 above doing exactly that.

The UI control for memory depth isn't too complex, usually just a box in the horizontal settings. Whats annoying is not having an auto setting alongside the manual choices. And as I keep having to bring up, even if the scope doesn't have explicit manual control of memory depth, there are ways to control it with zoom windows etc. Which for many scopes is fewer button presses and/or dedicated controls, but uses the screen real-estate differently (could be better or worse depending on your particular application).

[tv84]

This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"

(Disclaimer: I'm in no position to argue this theme with all the gurus here but, having said that,...)

If that is what KS does, and others don't,  I don't understand why.     We're talking STOP and SINGLE modes, right? So the scope has all the time in the world to process whatever it has to do after trigger and present results to the user.  It seems it would be the way I would implement it!

BUT, I see a problem, the result will be ALWAYS like this:

[<-[ trigger ---------] ----------------------------- acquisition ----------->]

Right?

With this implementation/mode of operation, you'll never be able to do this:

[<------- acquisition ------- [ ---- trigger -----]------- acquisition ------->]

or this:

[<-------------- acquisition ----------------------------[--------- trigger]->]

Am I correct?

(just a fact check to see if I'm understanding you all...)

[Someone]

This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"

(Disclaimer: I'm in no position to argue this theme with all the gurus here but, having said that,...)

If that is what KS does, and others don't,  I don't understand why.     We're talking STOP and SINGLE modes, right? So the scope has all the time in the world to process whatever it has to do after trigger and present results to the user.  It seems it would be the way I would implement it!

BUT, I see a problem, the result will be ALWAYS like this:

[<-[ trigger ---------] ----------------------------- acquisition ----------->]

Right?

With this implementation/mode of operation, you'll never be able to do this:

[<------- acquisition ------- [ ---- trigger -----]------- acquisition ------->]

or this:

[<-------------- acquisition ----------------------------[--------- trigger]->]

Am I correct?

(just a fact check to see if I'm understanding you all...)

The expansion around the screen is mostly (entirely?) symmetric on the mega zoom "bonus" capture, like the middle example. There is no control over where the extra memory is allocated, either for this, or nctnico's case where they manually set the acquisition memory depth wider than the visible window.

So, as mentioned above, the "bonus" full length capture requires a trigger to arrive at just the right time or it doesn't capture the extra acquisition and just keeps the last regular sized one.

[nfmax]

If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.

If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains.

I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity

Fewer samples at a lower ADC sample rate can increase the waveform update rate (no scope is completely ideal with zero trigger re-arm and zero processing time), see the huge graph of a DPO4000 above doing exactly that.

Point taken - but then it is a Tek

The UI control for memory depth isn't too complex, usually just a box in the horizontal settings. Whats annoying is not having an auto setting alongside the manual choices. And as I keep having to bring up, even if the scope doesn't have implicit manual control of memory depth, there are ways to control it with zoom windows etc. Which for many scopes is fewer button presses and/or dedicated controls, but uses the screen real-estate differently (could be better or worse depending on your particular application).

The Megazoom scopes I am familiar with have only recently introduced manual control of the acquisition memory. I think zoom windows are a bit of a distraction here. It's really only a different way of modifying the X scale: one that only lets you zoom in, not out, but shows both the zoomed and full time record. The full time record is exactly the same as a normal capture with no off-screen memory at all

[2N3055]

This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"

(Disclaimer: I'm in no position to argue this theme with all the gurus here but, having said that,...)

If that is what KS does, and others don't,  I don't understand why.     We're talking STOP and SINGLE modes, right? So the scope has all the time in the world to process whatever it has to do after trigger and present results to the user.  It seems it would be the way I would implement it!

BUT, I see a problem, the result will be ALWAYS like this:

[<-[ trigger ---------] ----------------------------- acquisition ----------->]

Right?

With this implementation/mode of operation, you'll never be able to do this:

[<------- acquisition ------- [ ---- trigger -----]------- acquisition ------->]

or this:

[<-------------- acquisition ----------------------------[--------- trigger]->]

Am I correct?

(just a fact check to see if I'm understanding you all...)

When you press STOP, 3000T seems to reconfigure and capture one SINGLE capture on a separate trigger, together with pre trigger time. On highest sampling rate, you always get 40us pre and 360us post trigger.

EDIT: Actually it depends on the where is trigger reference point set. If you set hor.ref point left, than it is -40us/+360us. BUT, if you set hor.ref point to center, than captured buffer is -200us/+200us arround trigger point. Respectively, if you set hor.ref point to right you get -360us/+40us

[Wuerstchenhund]

Well you learn something every day 

Indeed

Yep, another of the corners for nctnico's atypical use case, rejection of zoom mode. You went with the obvious/logical use case!

Well, I start to see why Nico is doing it the way he does, probably because this is a reflection of his general approach to a measurement problem. I still remember similar discussions we had about the importance (or not) of Peak Detect, another feature he seems to consider crucial . I guess this is just his way of doing stuff, and if it works for him then I'm not going to tell him to do anything else.

But while I believe I understand (to some extend) why *he* does it this way, I still fail to see why any real-world advantage of this method (and even less so where the claimed increase in efficiency or time savings should come from). The fact alone that this only works on some scopes (of which most only do this with a single acquisition) while the standard "capture long and then zoom in" methodology (for which deep memory scopes were designed for) works on every scope makes it impractical in a professional setting where you have to work with various different scope models.

Personally, it also doesn't fit me because it sounds a bit arbitrary (like blindly poking around in some circuitry), as I tend to think about what I want to measure and what I expect to see, and then setup the scope accordingly. But that's just me (although most of our engineers are the same "think before you do" types). But hey, whatever fits you best.

The problem I see is that this method is still rather niche, and due to it's various limitations over the standard "capture long and zoom in" method which is widely used it's really not a relevant criteria for a scope unless the user specifically asks for it, and it should not be treated this way.

Zoom mode adds one very important control that is missing when letting the scope expand around the visible window: you gain control of where the trigger is located within the full capture depth.

Not only that. Because there is also the problem that the excess data that even some of the scopes record is not always available.

Take the Rigol DS1000z. We now established that, if you set the memory to manual then it will always record the full selected memory size, no matter what. Great, right? 

But here's the thing: on the DS1000z at least, you can't always access that data. In RUN mode, if you switch to zoom mode, you can still only zoom *in* on the signal on screen, but not zoom *out* to look at off-screen data.

You can, of course, change the timebase, but that just means the screen will show the new timebase length after the next acquisition (i.e. the data of the previous acquisition are gone).

You can, of course, also setup a trigger to a specific event, and then after the capture change the timebase to effectively "zoom out".  However, for this to work there must be no subsequent acquisitions, or the data you want to look at is overwritten (and if that happens after the change of timebase then in effect it's no different to a normal timebase change on any scope).

The test Nico described is essentially this, trigger to a specific event, then stop the trigger and then "zoom out".

Which, consequentially, means that you can *only* look at off-screen data if the scope is no longer acquiring. It doesn't matter here if this is because this was the last in a series of acquisitions (with no subsequent acquisitions following), or if the scope was in SINGLE mode.

In contrast, the standard method of "capture long then zoom in" works irrespective if the scope is halted or still acquiring. With zoom, I can watch live data, jump to a different part of the signal and watch other live data. With Nico's method, I have to acquire, then make sure the scope is not re-triggered and then "zoom out".

With the standard method, on better scopes, I can even have multiple zoom windows, each showing a different segment of the signal. Single or continuous, doesn't matter 


Now, let's look at Nico's example of the SPI frame:

He's setting the scope to max memory, set the trigger to the interesting data segment and set the timebase so that data bit is full screen.

Now if the trigger event is rare or unique (say, the data segment has to reach a specific value) then after capturing the acquisition will essentially stop (waiting for the next trigger). If it's a common event then the scope then the acquisition must be stopped manually as otherwise the outside display data would be inaccessible.

OK, let's say we have looked at the data segment, and now want to see the rest of the frame (which is outside the screen). So we change the timebase setting to the full frame length (whatever that is) and yes, we can see the data that before was off-screen. 

But the thing is that, at this point, our scope is now set to *exactly* the same timebase setting that we would have set it to with the common "capture long and zoom in" method  . Just that the latter would have also allowed us to see both the whole frame as well as a detailed view of the data segment of interest without stopping the scope, i.e. we could observe live behavior. Something which, at least on the DS1000z, isn't possible with Nico's method.

So in the end, Nico's method seems to be a convoluted way to avoid using the scope's zoom function while achieve the same which can be achieved with the standard method.

It's not just with the DS1000z. I suspect all Rigol scopes behave the same (i.e. don't let you zoom outside the screen unless the scope is halted). HPAK's MegaZoom based scopes (InfiniVision and 546xx) for sure do.

Can the R&S scopes "zoom out" to off-screen data in RUN mode, or does it need to be stopped?  I don't know (maybe someone else can try)

In any case, Nico's method sounds more like a pain in the ass than a solution to a problem which actually exists.

[Someone]

If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.

If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains.

I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity

Fewer samples at a lower ADC sample rate can increase the waveform update rate (no scope is completely ideal with zero trigger re-arm and zero processing time), see the huge graph of a DPO4000 above doing exactly that.

Point taken - but then it is a Tek

All scopes do it to some degree, even the vaunted megazoom ASICs. Again, all this is linked above for your reading...

The UI control for memory depth isn't too complex, usually just a box in the horizontal settings. Whats annoying is not having an auto setting alongside the manual choices. And as I keep having to bring up, even if the scope doesn't have implicit manual control of memory depth, there are ways to control it with zoom windows etc. Which for many scopes is fewer button presses and/or dedicated controls, but uses the screen real-estate differently (could be better or worse depending on your particular application).

The Megazoom scopes I am familiar with have only recently introduced manual control of the acquisition memory. I think zoom windows are a bit of a distraction here. It's really only a different way of modifying the X scale: one that only lets you zoom in, not out, but shows both the zoomed and full time record. The full time record is exactly the same as a normal capture with no off-screen memory at all

Zoom windows are a way to set the size of the full acquisition, the trigger point within that full range, and still see some short timescale detail in realtime. It ticks all the boxes for nctnico's bizarre use case except they then added another constraint of "zoom takes up too much of the display" which sounds like a good excuse to consider scopes with better display management and higher resolutions.