Oscilloscope Zoom Out Quirk

[tautech]

I was actually making a reference to the Monty Python argument sketch; the conversation is quite illuminating.

Immediately, a good slapping with a wet fish for using a DSO in some obscure manner seems quite appropriate. 

[2N3055]

Off I go first thing in a morning, I'm gonna silly walk to fish market....

[Someone]

The confusion has kicked off once again.

nctnico talks about their way of working that has several things happening at the same time:
slow trigger rate
interesting detail at short time window
possibly interesting detail in the larger capture (but can't rely on another trigger arriving)

[<-------  acquisition ------- [ < screen > ] -------------------- acquisition -----> ]

trigger rate is inherently limited, so on most scopes you have to specifically request this sort of mode rather than leaving a scope on auto memory depth.

Now, this makes no sense to 99% of other oscilloscope users, but nctnico insists on making lots of noise about it every chance they can (for some bizarre reason).

Everyone else does one of the following:
has plenty of triggers and captures another capture at the wider window
uses zoom to view the small time window and full acquisition at the same time
... has some entirely different application that has nothing to do with this extreme corner case use (yep, that'd be just about everyone)

So when nctnico says a scope can't do this very specific (and not fully explained) thing, just ignore it. Because with only a tiny change to any part of the application or acceptable solution, just about any scope will do the job.

[EEVblog]

So when nctnico says a scope can't do this very specific (and not fully explained) thing, just ignore it. Because with only a tiny change to any part of the application or acceptable solution, just about any scope will do the job.

Yeah, but he's not wrong.
It's an interesting and demonstrably potentially useful benefit.

[EEVblog]

What does it mean? Well, when you're on 1ns/div, you get 40000x length worth of data than what is on your screen (10ns to 400us) if you stop it. If you are at 20us/div you get only 2x (200us to 400us).
And from that point on sample rate goes down, and game repeats, changing ratio "screen/stopped capture length" all the time. I guess table could be compiled. It's just I couldn't care less.
I'm not going to base my work based on side-effects of sample engine architecture..

So if you captured something and then thought "gee I wonder what's either side of that, and you knew your scope worked like this, you'd actually rather re-capture instead of just changing the timebase?
That's kinda, well, silly.
If your answer is yes I would, then what happens if your capture was infrequent and wasn't easy to reproduce?
Sorry but I can't see a way to successfully argue this isn't a potentially useful feature.
It's so interesting it's probably worthy of a video.

[tautech]

Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.

To argue that non-standard DSO usage technique limits the convenience of examining captures in greater detail has never been where the industry has headed instead there is industry wide methodology for capturing events.

[EEVblog]

Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.

No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".

[maginnovision]

I can't speak for Nico but when the situation arises I do it on purpose to save some time. It's not as if I set it to trigger on line and then single shot until I see what I'm looking for. It's also not the only way I use an oscilloscope, it's just one of the ways.

[2N3055]

What does it mean? Well, when you're on 1ns/div, you get 40000x length worth of data than what is on your screen (10ns to 400us) if you stop it. If you are at 20us/div you get only 2x (200us to 400us).
And from that point on sample rate goes down, and game repeats, changing ratio "screen/stopped capture length" all the time. I guess table could be compiled. It's just I couldn't care less.
I'm not going to base my work based on side-effects of sample engine architecture..

So if you captured something and then thought "gee I wonder what's either side of that, and you knew your scope worked like this, you'd actually rather re-capture instead of just changing the timebase?
That's kinda, well, silly.
If your answer is yes I would, then what happens if your capture was infrequent and wasn't easy to reproduce?
Sorry but I can't see a way to successfully argue this isn't a potentially useful feature.
It's so interesting it's probably worthy of a video.

You probably didn't read through all the text, to see that I said that i occasionally use that when it's there.  And, no I'm not idiot to deliberately recapture something if it's already there, out of some stupid "principle". I'm saying that if you adopt proper practice, you will rarely get into situation to depend on unspecified behaviour of scope (yes on Keysight 3000T it is unspecified. All numbers I wrote I had to measure and test myself). But I will make sure to think in terms "I want to capture long capture, so I'm going to capture a long time period, and then I will zoom into details at will"   instead  of "I want to capture long capture, so I'm going to set scope on long memory, put it to short timebase to see only trigger point, and then zoom out to see all other stuff that long memory got". It's just backwards way of thinking to me. And on the scope that works like my Keysight and Pico do, my way guarantees I will see everything.  Nico's way might (or might not, depending on scope setting) give me more data outside screen on my Keysight 3000T, and on Pico (and Lecroy and Siglent) won't give me squat.  And because of that, it is exactly wrong way to use on  infrequent and not  easy to reproduce events, for which I use method that guarantees I will get first time every time.
So, yes, my method (not really my method, but industry standard method)  is better general purpose method to recommend to those that learn things.
People with experience will do whatever they do and have their own tricks.

I agree it's worthy of a video. And if you think about it a bit further, you  will see that its one of those "you can do it this way too if planets are aligned..." but not really something to rely on.

[tautech]

Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.

No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".

Right  again user error........oh hang on something that happened before the trigger caused something you didn't expect.....oh hell does this happen in the real world, of course it does and to not have a scope set to allow for and capture it is user error.

[2N3055]

Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.

No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".

I understand what are you saying, but when working on, say,  CAN bus, what are the chances you will happen to capture exactly packet with error if you looking at single edge? You don't capture that way looking at that kind of data. You use larger time period, with hundreds of packets and then search and scroll and zoom in and out.

As I say, it is not something I would forbid on a scope. But I don't rely on it, and try to avoid to rely on it. Instead I simply try to capture larger deliberately and be sure I got the data. And you can have a detailed look at a detail both ways...

[EEVblog]

I agree it's worthy of a video. And if you think about it a bit further, you  will see that its one of those "you can do it this way too if planets are aligned..." but not really something to rely on.

You do know it's entirely predictable, right? (based on timebase and memory depth) It's not some random quirk.
Even the Keysight has a new Digitizer mode that makes it entirely predictable.

[EEVblog]

Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.

No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".

I understand what are you saying, but when working on, say,  CAN bus, what are the chances you will happen to capture exactly packet with error if you looking at single edge? You don't capture that way looking at that kind of data. You use larger time period, with hundreds of packets and then search and scroll and zoom in and out.

You can't say you understand what I'm saying then immediately go into an example where it's not going to be of value. That is completely opposite to my point!
I'll repeat, there is no logical argument you can make to say that this isn't a potentially useful feature in some circumstances.

[stafil]

Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?

[nctnico]

Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?

Yes, but for capturing events which occur at a relatively low rate that doesn't matter at all.

[Someone]

So when nctnico says a scope can't do this very specific (and not fully explained) thing, just ignore it. Because with only a tiny change to any part of the application or acceptable solution, just about any scope will do the job.

Yeah, but he's not wrong.
It's an interesting and demonstrably potentially useful benefit.

But nctnico is wrong to generalise it as something other scopes can't do, because they can but in subtly different ways. Its a very narrow (and poorly/not defined) example to try and push some point like the marketing "comparisons" people keep laughing at.

The case of slow and infrequent triggers allows that type of use, and impedes/prevents acquisition of more rapid events (or they get lost in the long capture). Its a simple tradeoff (or "trap" as you might embellish it) that is chosen for the specific setting.

The inflammatory nature of this discussion has been the refusal of nctnico to acknowledge either the narrow applicability of the use case, or that it can be achieved by using a zoom window/view, or other methods.

Its a massive blow up over different methods to set the memory depth (auto vs manual vs implicit vs explicit).

[Someone]

Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.

No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".

I understand what are you saying, but when working on, say,  CAN bus, what are the chances you will happen to capture exactly packet with error if you looking at single edge? You don't capture that way looking at that kind of data. You use larger time period, with hundreds of packets and then search and scroll and zoom in and out.

You can't say you understand what I'm saying then immediately go into an example where it's not going to be of value. That is completely opposite to my point!
I'll repeat, there is no logical argument you can make to say that this isn't a potentially useful feature in some circumstances.

Yes, but as these seem to keep coming back to:
Poster A says a scope is not worth considering because it can't do some very specific feature..... not mentioning how that feature might be useful or what situations might make it applicable.
Poster B points out the holes in their point and explains other comparable methods.
Poster A keeps narrowing the goalposts to be "right"

Time was wasted by all and a confusing mess is left behind. The generalised answer is there are many corner cases for test/measurement and they generally aren't applicable unless that matches the users application.

[Someone]

Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?

Yes, which is why "automatic" memory depth usually defaults to the shortest record that will fill the screen.

[EEVblog]

Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?

Yes, which is why "automatic" memory depth usually defaults to the shortest record that will fill the screen.

Not on the Keysight. Try it. Unless you are on a slow timebase like 100ms where all the memory is used to fit the screen and it doesn't have any more to give. On 10us or under (which is where it goes to the max 5GS/s), if you press stop and then zoom out it will give you the extra data outside the display window.

[tautech]

We generalise that the 0s trigger point might be in the middle of the display which of course is the most convenient for pre and post trigger capture inspection where in fact many might set the 0s point to the left of the display like a CRO.
A central display 0s setting gives us the greatest advantage of inspecting the largest amount of both pre and post trigger capture and a slow timebase for capture is the ideal allowing for the largest pre and post trigger record.
However we could set the 0s trigger point to the far right of the display if the pre trigger capture will be of greatest interest to us.

These are the very most basic features of a DSO, the power to capture and the power to zoom in on any detail of the capture and anyone ignoring these simple features is not using the tool in front of them to best effect and needs go back to scope school.

[maginnovision]

I feel like you're saying there is never any advantage ever in your life because siglent scopes can't do it. Like it or not I don't want to have a wide timebase to get a capture, zoom in and then zoom back out to catch all the details I want. We're not talking a game changer here, we're talking a shortcut.

[tautech]

I feel like you're saying there is never any advantage ever in your life because siglent scopes can't do it.

Oh FFS, do you actually think I've not used other DSO's ? Really ?

My first DSO had 2.5 Kpts memory/channel so to get the best from it you used it wisely.
Even the other 2 laterTeks I had were similarly pitiful.

What are we actually trying to do here, teach the reader some obscure scope usage method rather than proper well know methods that return universally predictable results from any DSO ?

[Someone]

Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?

Yes, which is why "automatic" memory depth usually defaults to the shortest record that will fill the screen.

Not on the Keysight. Try it. Unless you are on a slow timebase like 100ms where all the memory is used to fit the screen and it doesn't have any more to give. On 10us or under (which is where it goes to the max 5GS/s), if you press stop and then zoom out it will give you the extra data outside the display window.

Thats a "special" behaviour that is only on a minority of scopes. This has cropped up a few times:
https://www.eevblog.com/forum/testgear/new-keysight-scope-1st-march-2017/msg1125192/#msg1125192
https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1282227/#msg1282227
and more recently:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2895750/#msg2895750

Same old names blowing noise and adding FUD left right and centre.

[nctnico]

I feel like you're saying there is never any advantage ever in your life because siglent scopes can't do it. Like it or not I don't want to have a wide timebase to get a capture, zoom in and then zoom back out to catch all the details I want. We're not talking a game changer here, we're talking a shortcut.

Agreed on both points.

Frankly I'm amazed so many people are so opposed to using a clever shortcut which yields results in the real world. 

But since we are here I can make a list with oscilloscope brands which support recording beyond the screen (or not):

GW Instek: yes
Keysight: older models: yes, newer models: single mode only
Lecroy: no
MicSig: yes
Rigol: yes
R&S: yes
Siglent: no
Tektronix: yes
Yokogawa: ?

Edit: added R&S

[2N3055]

I agree it's worthy of a video. And if you think about it a bit further, you  will see that its one of those "you can do it this way too if planets are aligned..." but not really something to rely on.

You do know it's entirely predictable, right? (based on timebase and memory depth) It's not some random quirk.
Even the Keysight has a new Digitizer mode that makes it entirely predictable.

Well, I don't have R&S RTM3000 to try but I believe what Nico say that it WILL be predictable.  An as long as you keep it on same (max)sampling rate it will stay the same.
On Keysight 3000T not so much. It has much smaller memory, and will drop sampling rate fast. Full mem in full sample rate in RUN mode is 400 us.
Also digitizer mode has some limits. When you set digitizer mode, if you set scope to sample at max 5GS and have max 4MS (1ch), scope won't let you set time base to slower than 40us/div. Basically, it starts sampling at that fixed speed and memory buffer. It's not setting sampling speed anymore to allow you to go slower. It behaves as digitizer not GP scope.
But that helps little, because result is the same as in normal mode, if you pay attention and not go slower than 40 us/div in run mode.