Oscilloscope Zoom Out Quirk

[nctnico]

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

No. When using single mode you'd need to press the single button every time. In case of slow events (which can be generated manually) it is much easier to press stop when something of interest appears on the screen instead of having to bother with the oscilloscope all the time. And you only have two hands. Starting something on the DUT and holding a probe already needs 2 hands.

[Someone]

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.

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.

Another inconsistency, you making me crazy...

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

Phew! I thought it was mostly symmetric (generally working with symmetric trigger setups), thanks for the extra details. Its far too fiddly to rely/plan on any of that, I just use a scope as it works.

[nctnico]

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.

But you don't know what you don't know. If you are looking for a bug you start with a blank slate. So how are you going to setup your scope if you don't know what you are looking for? If you already know what a signal looks like there is no use measuring it. Often something interesting turns up which makes me want to see want came before and after. There is no way to know until there is something on screen. Maybe you'll capture it again after an hour. Same goes for design verification. Something odd may pop-up. It is nice if you don't have to recapture to see the rest but just zoom out. In some of my cases it can take several minutes to make a new measurement.

And there are also cases where it is just quicker to capture something visually rather than setting up a complex trigger condition. Remember my way of working stems from saving time & effort.

Come to think of it: it makes no sense needing to use zoom mode to have all the memory available. I already told the oscilloscope to use a certain amount of memory.

Anyway, it seems that you have a very narrow view of how an oscilloscope should be used and are unable to see beyond that to streamline operations. It reminds me of my chief when I was working in a chocolate factory: 'you must carry those trays with both hands because god gave you two hands'.

[Wuerstchenhund]

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.

Indeed.

The other thing is that zoom, after all, is actually just a math function ('window' function) over the acquired waveform, and on better scopes you're not limited to a single zoom mode but you can actually have multiple, each zooming into a different part of the signal, all showing live data if you want.

These zoom modes can then also be used as an input for further analysis.

Which means zoom mode is just more than just stretching the displayed signal segment.

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.

I agree, this is just a case of a poor UI on a particular scope, not a problem that's inherent to zoom as a function.

[2N3055]

Phew! I thought it was mostly symmetric (generally working with symmetric trigger setups), thanks for the extra details. Its far too fiddly to rely/plan on any of that, I just use a scope as it works.

Exactly my point.

[tv84]

Come to think of it: it makes no sense needing to use zoom mode to have all the memory available. I already told the oscilloscope to use a certain amount of memory.

You're contradicting yourself. You have to choose: fill all the memory or don't fill all the memory. If not, you'll be defending Siglent's way in a hurry...

[nctnico]

Come to think of it: it makes no sense needing to use zoom mode to have all the memory available. I already told the oscilloscope to use a certain amount of memory.

You're contradicting yourself. You have to choose: fill all the memory or don't fill all the memory. If not, you'll be defending Siglent's way in a hurry...

I'm not contradicting myself. Needing to use zoom made in order to make the oscilloscope use the memory depth I set is making the same setting twice.

[nctnico]

I agree, this is just a case of a poor UI on a particular scope, not a problem that's inherent to zoom as a function.

It is not; I'm using all DSOs like this. Like several others you are trying to argue less is somehow more while grasping at straws no thicker than a hair trying to ridcule me. Just give up.

[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

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.

Yeah but you only have to pre-fill memory once after the uses presses the START button. In most usage cases and non-slow timebases that's practically an instant, and is actually the price you pay when you have defined the (default) horizontal trigger position to be center memory. There is no way around doing it once unless you copied your sample memory to display/plot memory and then continued to sample in the background. That would be a huge design trade-off for so little gain.

[nfmax]

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.

Yeah but you only have to pre-fill memory once after the uses presses the START button. In most usage cases and non-slow timebases that's practically an instant, and is actually the price you pay when you have defined the (default) horizontal trigger position to be center memory. There is no way around doing it once unless you copied your sample memory to display/plot memory and then continued to sample in the background. That would be a huge design trade-off for so little gain.

Or use two swinging buffers, even in Single mode. But that halves your maximum record length, which seems like a poor choice.

[EEVblog]

I think zoom windows are a bit of a distraction here.

I agree. No need to complicate the operational understanding here.

[nfmax]

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.

On the DSO1014A (a Rigol design), with Zoom off, in Run mode, but with no triggers happening, you can use the horizontal scale & position knobs to move the displayed trace around within the offscreen captured data, and change the displayed duration. If you then turn Zoom on, you get a zoomed view of the currently displayed part of the captured data, even if it was originally off screen. The horizontal scale & position knobs change mode to operate as zoom and pan within the displayed window. Turn off Zoom and you can move to a different part of the captured data, rinse & repeat.

This could actually be quite useful: I didn't know you could do this! Do the more recent Rigols work in the same way? I'll check the X3000T as well now, I'm intrigued.

[Wuerstchenhund]

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.

But you don't know what you don't know. If you are looking for a bug you start with a blank slate. So how are you going to setup your scope if you don't know what you are looking for?

You never start from a blank slate. For a start, you need to have some idea as to what the spectral content of the signal is, because that determines your scope BW.

You also need to have some idea as to the voltage levels, as you need this to select suitable probes and prevent damage to your scope and your human body.

Furthermore, you normally should have some rough idea what the UUT (i.e. a PCB) does, which gives you some hints as to what kind of signals (AC? DC? Discretes? Serial comms? Parallel comms?) you can expect to find. If you don't know then you have a closer look to get an idea what this thing actually is (although I believe it's pretty rare you're asked to probe something of which you don't know what it is).

Now when you identified what that thing on your bench does and you have an idea what kind of signals you expect, what the voltage levels are, and the approx frequency band, but still don't know what exactly the signal will be, you set your deep memory scope to a long timebase (as long as it makes sense, i.e. as long as the period of the slowest signal you could reasonably expect to see) and start capturing.

You'll quickly see if it's just DC, some AC, or if the signal looks more complex (like a Discrete or serial comms packet). If it's the latter then you can use zoom to look closer, get the different parameters for some of the level shifts, and if you don't already recognize a specific pattern then use the measurements to compare with the in-spec parameters for the type of signals that could reasonably be found on this UUT.

Or you try the serial decoders and see if they come up with sensible data.

In any case, a methodological, stepped investigative approach is usually the best approach.

Besides, I doubt it's very common for an engineer to get some UUT you really know nothing about and get told "measure something"

But in any case, capturing long makes it easy to quickly assess different parts of the signal.

If you already know what a signal looks like there is no use measuring it.

So in your view things like interference or spec compliance (which usually needs to be demonstrated by measurements) doesn't exist?

There are many reasons why you want to measure signals, even if you know how it looks like.

And there are also cases where it is just quicker to capture something visually rather than setting up a complex trigger condition. Remember my way of working stems from saving time & effort.

You stated this repeatedly but I'm sorry it doesn't make sense (and as we already established, there is no difference in trigger config between your method and the standard äcquire long and zoom in" method). You're not saving time and effort, all you do is to go to extreme lengths to avoid using the zoom function, and as a result you make do with various limitations, all which can be avoided with the standard method.

The only "time saving" I could possible see is that, with your method, you don't spend time thinking about what you actually want to do, but which bites you in the backside later because of the additional things you need to do to when you find out that you ran into a dead end, and you have to reconfigure your tools to get the information you want, all which the standard method would very likely have given you anyways.

But at the end of the day, and from a professional angle, even if your method would save 10 button presses over the standard method, it wouldn't matter one bit. First of all, we don't sit next to our engineers with stop watches, so this isn't captured, and even if an engineer would have to to this 100x a day the impact on any timelines and schedules would be neglegible. Our engineers get the bucks to do engineering (i.e. to work on cutting edge technology), and how they do this is up to them (aside from standard and specs we don't dictate methodology engineers use for scoping, although there are regular exchanges to discuss test methodology to find out what we can do better). So far, no-one has ever asked for something like you describe. Go figure.

[Wuerstchenhund]

I agree, this is just a case of a poor UI on a particular scope, not a problem that's inherent to zoom as a function.

It is not; I'm using all DSOs like this.

You can't, because clearly not all scopes even allow you to use your method.

Like several others you are trying to argue less is somehow more while grasping at straws no thicker than a hair trying to ridcule me. Just give up.

So you're arguing that if the zoom window on a scope is too small that this is something other than a UX/screen size problem?

[Wuerstchenhund]

On the DSO1014A (a Rigol design), with Zoom off, in Run mode, but with no triggers happening, you can use the horizontal scale & position knobs to move the displayed trace around within the offscreen captured data, and change the displayed duration. If you then turn Zoom on, you get a zoomed view of the currently displayed part of the captured data, even if it was originally off screen.

Well, it's a work-around. You first change the actual timebase ("zoom out") which then becomes the new in-screen signal part, and then use zoom to "zoom in"to that new "in-screen" data.

What you are doing is essentially using the standard method ("capture long and zoom in") but add another step (capture short but also outside the screen, then change to a long timebase) which, essentially, adds nothing over if you just had captured long and then zoomed in in the first place 

And your scope must still be on hold, i.e. not get re-triggered, or your method doesn't work.

The horizontal scale & position knobs change mode to operate as zoom and pan within the displayed window. Turn off Zoom and you can move to a different part of the captured data, rinse & repeat.

I think that would work on the DS1000z as well, but as I said it all adds up with extra steps with no actual benefit.

This could actually be quite useful: I didn't know you could do this! Do the more recent Rigols work in the same way? I'll check the X3000T as well now, I'm intrigued.

Again, it's not really useful ifyou think about it, but if you prefer this method why not

[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!"

I think what Dave concludes here sums all this thread very well. There is no justification to not filling up the whole memory (if it's not already filled) in order to have an after SINGLE/STOP zoom out.

The preferred way people use their scope is somewhat irrelevant (and something of a religion among the gurus here) to that fact.

Never crossed my mind that Siglent (and others) wouldn't implement it that way (like KS seems to do it). Maybe it is a simple change to correct that...

What is the point of having all that memory and not being able to take advantage of it? And if that's an unsurpassable obstacle, why the well do they allow the zoom out? Just to see blank screen? Or for us to validate that the scope doesn't have more samples?

[nctnico]

So you're arguing that if the zoom window on a scope is too small that this is something other than a UX/screen size problem?

Not just that. Just less buttons to push. How hard is that to see? See my earlier analogy; you keep insisting to use an automatic gearbox in manual mode only. That is making life harder; not easier. And with 4 channels, some bus decoding, a few measurements and cursors active (not an a-typical use case for me) an oscilloscope screen gets crowded quickly no matter how big it is. Having to add a zoom window doesn't increase comfort so if you can get rid of the zoom window it is a good riddance. I shouldn't even have to point this out.

[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!"

I think what Dave concludes here sums all this thread very well. There is no justification to not filling up the whole memory (if it's not already filled) in order to have an after SINGLE/STOP zoom out.

The preferred way people use their scope is somewhat irrelevant (and something of a religion among the gurus here) to that fact.

Never crossed my mind that Siglent (and others) wouldn't implement it that way (like KS seems to do it). Maybe it is a simple change to correct that...

What is the point of having all that memory and not being able to take advantage of it? And if that's an unsurpassable obstacle, why the well do they allow the zoom out? Just to see blank screen? Or for us to validate that the scope doesn't have more samples?

Well on Siglent it's not wasted to blank screen. Depending on mem depth, you can have thousands of previous triggers i history buffers. Siglent adopted LeCroy way of doing this. It basically always runs in segmented mode, except normally has screen updates that slow down retriggering, and when in dedicated segmented mode, display refresh is disabled and retrigger time is much faster.. With this you can do something also useful: You see something on the screen and than go back trough previous captures to see how it behaved before.. But, yes, I would like it would be user configurable.

[nfmax]

On the DSO1014A (a Rigol design), with Zoom off, in Run mode, but with no triggers happening, you can use the horizontal scale & position knobs to move the displayed trace around within the offscreen captured data, and change the displayed duration. If you then turn Zoom on, you get a zoomed view of the currently displayed part of the captured data, even if it was originally off screen.

Well, it's a work-around. You first change the actual timebase ("zoom out") which then becomes the new in-screen signal part, and then use zoom to "zoom in"to that new "in-screen" data.

What you are doing is essentially using the standard method ("capture long and zoom in") but add another step (capture short but also outside the screen, then change to a long timebase) which, essentially, adds nothing over if you just had captured long and then zoomed in in the first place 

And your scope must still be on hold, i.e. not get re-triggered, or your method doesn't work.

The horizontal scale & position knobs change mode to operate as zoom and pan within the displayed window. Turn off Zoom and you can move to a different part of the captured data, rinse & repeat.

I think that would work on the DS1000z as well, but as I said it all adds up with extra steps with no actual benefit.

This could actually be quite useful: I didn't know you could do this! Do the more recent Rigols work in the same way? I'll check the X3000T as well now, I'm intrigued.

Again, it's not really useful ifyou think about it, but if you prefer this method why not

I'm not suggesting this as a better way to operate, rather that it overcomes the drawback that the ordinary Rigol 'zoom' mode doesn't let you zoom out from the initial displayed window. It's a kluge, but this 'zoom zoom' trick works.

[tv84]

But, yes, I would like it would be user configurable.

Damn, stop right there and  we can all get back to sleep!   

(Love this discussion. I've been learning quite a few things!)

[tv84]

Depending on mem depth, you can have thousands of previous triggers i history buffers. Siglent adopted LeCroy way of doing this. It basically always runs in segmented mode, except normally has screen updates that slow down retriggering, and when in dedicated segmented mode, display refresh is disabled and retrigger time is much faster.. With this you can do something also useful: You see something on the screen and than go back trough previous captures to see how it behaved before..

Ah, OK, also useful indeed.  But, it's all software.  In the end, you get what you pay for...

BUT, I should be able to have a final capture (to fill up memory) after the STOP/SINGLE if I'd choose so... no excuse.   

[Wuerstchenhund]

So you're arguing that if the zoom window on a scope is too small that this is something other than a UX/screen size problem?

Not just that. Just less buttons to push. How hard is that to see?

I'm sorry I can't see it. Both your method and the standard method of "capture long and zoom in" are the same, the only difference is you start with a short timebase and then "zoom out", while the standard method is the other way around. On the scope this works, the number of button presses are the same (+/-1 if anything). 

See my earlier analogy; you keep insisting to use an automatic gearbox in manual mode only. That is making life harder; not easier.

Like most car analogies, it fails here, too. But staying with car analogies for the moment, if anything, it's *you* who want to use the automatic gearbox (memory management) in manual mode only, contrary to the principle deep memory scopes are designed for (which is to capture long sequences and zoom in on the detail). Because in effect, you are arguing that driving a powerful car with automatic transmission in manual mode because of the perceived better acceleration makes absolute sense while on the I-405 during rush hour   

And with 4 channels, some bus decoding, a few measurements and cursors active (not an a-typical use case for me) an oscilloscope screen gets crowded quickly no matter how big it is.

That's not true. For example, we often have 8 or more traces plus decoding and measurements active, and it's never been an issue for any of our engineers to work with the data. Granted, the scopes we use are not the typical bottom-of-the barrel ones like a DS1054z, but still. For example, the new Keysight UXRs we got can easily display 10 or more different graphs (i.e. traces, math, FFT, whatever), each in their own window and with their own graticule, and it's not overloaded.

I may remember wrong but didn't you buy a LeCroy WavePro 7k some time ago? Even this (some 15+ year old) scope can comfortably display 8 traces + data, all in their separate graticule. If that 10.3" is still to small you can connect say a 24" monitor so you got an even larger screen with an even larger resolution.

Yes, the DS1054z screen is tiny, and while you can display four channels plus serial decode, it's rarely practical because there is only one graticule and it's all overlaid and so small it's barely usable (at least for a guy of my age). My Infiniium 8k isn't much better, the 8.4" screen is just way to small for the old HP GUI and the amount of information it can display (and it's way to small to use the touch functions sensibly). But that is down to the scope's small screen and cramped GUI.

The thing is that if your scope sux when displaying all this shit then it will suck no matter what method you use for performing your measurements. It's what it is.

So yes, your complaint about the zoom trace taking away screen estate is definitely an UX issue.

Having to add a zoom window doesn't increase comfort so if you can get rid of the zoom window it is a good riddance. I shouldn't even have to point this out.

I don't use a scope for "comfort",  I use it to get data. The more data I can get less steps the better. The best approach to need less steps with complkex signals is usually to capture everything and zoom in on the details, often with multiple zoom windows each pointed to a different part of the signal.

At the end of the day, this is what DSOs where designed for, it's how every scope is sold, and it's how every engineer I worked with has been doing stuff.

Don't get me wrong, I'm not trying to do things differently, if it works for you be my guest. But so far I have seen no data which shows any benefit of your method over the standard way, and I don't believe the need of a scope to support such a (clearly very niche) methodology should be very high on a list of recommendations.

[nfmax]

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.

On the DSO1014A (a Rigol design), with Zoom off, in Run mode, but with no triggers happening, you can use the horizontal scale & position knobs to move the displayed trace around within the offscreen captured data, and change the displayed duration. If you then turn Zoom on, you get a zoomed view of the currently displayed part of the captured data, even if it was originally off screen. The horizontal scale & position knobs change mode to operate as zoom and pan within the displayed window. Turn off Zoom and you can move to a different part of the captured data, rinse & repeat.

This could actually be quite useful: I didn't know you could do this! Do the more recent Rigols work in the same way? I'll check the X3000T as well now, I'm intrigued.

I can confirm the X3000T works in the same way, in Stop/Single mode. If there is off-screen captured data, you can use the horizontal controls in ordinary mode to bring it on screen, then use the zoom mode to zoom in on the displayed part.

One more wrinkle: you only get off-screen data from the 'magic' last capture in Stop/Single mode if the ADC sample rate is 5GHz (with one channel of each pair active). Presumably, if the sample rate is any lower, all the available memory is in use anyway.

[tv84]

Gentlemen, you are ALL talking the same language!

Nico starts with zoom in and likes to be able to zoom out. The others start with zoom out and like to be able to zoom in.

It's all the same, but in reverse order.

All the rest are just details (and personal preferences or lifelong habits)!

[Gandalf_Sr]

I'm with TV84 on this, it's 6 or one and half a dozen of the other.

To go back to the transmission analogy, I learned to drive on a manual and hated automatics as I always knew (thought) I could do better, even when I had an Audi A6, IMHO I did a better job than the transmission.

Now my 2.0 liter Ford Escape (Kuga) has a transmission that's basically a 6 speed manual operated by a computer, I have a manual mode but never use it as the transmission IS always in the right gear; the new 2020 models have an improved 8 speed version of mine and are reportedly even better.