Oscilloscope Zoom Out Quirk

[Wuerstchenhund]

Wouldn't this make a nice topic for one of your videos? Maybe coupled with a comparison of the nctnico method vs everyone else's method? 

What's his method again?, I must have missed that.
I just set the scopes max memory depth and a 1us timebase and STOP it. If it lets me zoom out to slower timebases and still show data then it passes.
Then repeat using a trigger signal just in case there is a difference between manual STOP mode and a trigger event capture.

Nico has used the example of an SPI frame where you are interested in a certain bit but also want to check the whole frame.

Nico's method (if I understand it correctly!) is this:
 
- Set the trigger to the data point of interest
- Set memory to max
- Set the time base so the specific data point fills the screen (i.e. max detail)
- Perform a single acquisition, then STOP
- Check out the data point
- Then zoom out to check out the rest of SPI frame

The method I know would be:
- Set the trigger to the data point of interest
- Set memory to max Not necessary as scopes will usually maximize the memory to an sufficient extend automatically
- Check what the length of that SPI frame is and set the timebase to capture the whole frame (say 100us)
- Perform a single acquisition Actually, I might not want to but prefer to look at life data, so I leave the scope on normal mode
- Check out the frame
- Zoom in to the datapoint of interest and check that out

The result is the same, it's just the opposite way of doing it. Nico's method is also perfectly valid, however won't be possible unless the scope allows him to zoom out (which many don't, especially on very short time bases). While the method I have described works on every DSO.

The other difference is that, when it comes setting up your scope and avoiding excessive acquisition time (keeping in mind that time saving was one of the arguments for his method!), Nico needs to know how much memory he needs to use, so he not only needs to establish what the frame lenght is but also how in how many points this translates in terms of sample memory. While the second method just requires knowledge of the frame length.

Keep in mind this is *not* "zooming out"as having your scope in normal mode and just changing the timebase so you can see more of the signal, which again works on every scope. It's really about if a scope can record beyond its screen on very short timebases when the memory is set accordingly, which is only visible in a single acquisition.

The contentious point was actually not about the methods itself (I just never heard of anyone doing it this way before) but if a scope should be expected to accommodate Nico's method and what the relevance of this is in real life.

[nctnico]

Wouldn't this make a nice topic for one of your videos? Maybe coupled with a comparison of the nctnico method vs everyone else's method? 

What's his method again?, I must have missed that.
I just set the scopes max memory depth and a 1us timebase and STOP it. If it lets me zoom out to slower timebases and still show data then it passes.
Then repeat using a trigger signal just in case there is a difference between manual STOP mode and a trigger event capture.

Nico has used the example of an SPI frame where you are interested in a certain bit but also want to check the whole frame.

Nico's method (if I understand it correctly!) is this:
 
- Set the trigger to the data point of interest
- Set memory to max
- Set the time base so the specific data point fills the screen (i.e. max detail)
- Perform a single acquisition, then STOP
- Check out the data point
- Then zoom out to check out the rest of SPI frame

The method I know would be:
- Set the trigger to the data point of interest
- Set memory to max Not necessary as scopes will usually maximize the memory to an sufficient extend automatically
- Check what the length of that SPI frame is and set the timebase to capture the whole frame (say 100us)
- Perform a single acquisition Actually, I might not want to but prefer to look at life data, so I leave the scope on normal mode
- Check out the frame
- Zoom in to the datapoint of interest and check that out

The result is the same, it's just the opposite way of doing it. Nico's method is also perfectly valid, however won't be possible unless the scope allows him to zoom out (which many don't, especially on very short time bases). While the method I have described works on every DSO.

The other difference is that, when it comes setting up your scope and avoiding excessive acquisition time (keeping in mind that time saving was one of the arguments for his method!), Nico needs to know how much memory he needs to use, so he not only needs to establish what the frame lenght is but also how in how many points this translates in terms of sample memory. While the second method just requires knowledge of the frame length.

Keep in mind this is *not* "zooming out"as having your scope in normal mode and just changing the timebase so you can see more of the signal, which again works on every scope. It's really about if a scope can record beyond its screen on very short timebases when the memory is set accordingly, which is only visible in a single acquisition.

The contentious point was actually not about the methods itself (I just never heard of anyone doing it this way before) but if a scope should be expected to accommodate Nico's method and what the relevance of this is in real life.

You are missing a few fine details:
- I'm not using single acquisition in most cases. I stop the oscilloscope when I see something of interest and in some cases I leave it in run mode because I have control over generating the trigger events somewhere else.
- I don't care about the time base setting and I'm not going to calculate how much memory I need. If it turns out to be not enough then I have to fallback to presetting the time base. The deeper the memory, the less this is necessary.

The key point to my method is that you don't need to worry about setting up the time/div and horizontal position of the scope properly before doing a measurement. Sometimes I forget to put the horizontal position back to the trigger point. With the oscilloscope recording outside the screen I can just scroll back to the trigger point. The benefits of my method are:

- Scope time/div setup is not critical to catch all data in many cases
- Least twiddling with knobs & settings


 Keep in mind that this usage mostly happens during debugging interaction between software and hardware. In the end it saves time. I think I already mentioned this workflow in my review of the SDS2204 I did 5 or 6 years ago. I have not checked that yet.

[EEVblog]

Wouldn't this make a nice topic for one of your videos? Maybe coupled with a comparison of the nctnico method vs everyone else's method? 

What's his method again?, I must have missed that.
I just set the scopes max memory depth and a 1us timebase and STOP it. If it lets me zoom out to slower timebases and still show data then it passes.
Then repeat using a trigger signal just in case there is a difference between manual STOP mode and a trigger event capture.

Nico has used the example of an SPI frame where you are interested in a certain bit but also want to check the whole frame.

Nico's method (if I understand it correctly!) is this:
 
- Set the trigger to the data point of interest
- Set memory to max
- Set the time base so the specific data point fills the screen (i.e. max detail)
- Perform a single acquisition, then STOP
- Check out the data point
- Then zoom out to check out the rest of SPI frame

Exactly the same as what I'm doing, except I couldn't be arsed to use any data 
You don't need the data, it's obvious when the samples run out as the trace stops at both ends.

The contentious point was actually not about the methods itself (I just never heard of anyone doing it this way before) but if a scope should be expected to accommodate Nico's method and what the relevance of this is in real life.

I don't see it as contentious, it has obvious use. It lets your trigger thing or interest and then say "gee I wonder what happened before or after that". If you have a scope that captures outside the display then you don't have to retrigger again at longer time base. This could actually be vital on something you can only trigger off intermittently for example.

[Gandalf_Sr]

Exactly the same as what I'm doing, except I couldn't be arsed to use any data 
You don't need the data, it's obvious when the samples run out as the trace stops at both ends.

It's the story of my life, the data I need are always just after the scope runs out of memory 

[2N3055]

Wouldn't this make a nice topic for one of your videos? Maybe coupled with a comparison of the nctnico method vs everyone else's method? 

What's his method again?, I must have missed that.
I just set the scopes max memory depth and a 1us timebase and STOP it. If it lets me zoom out to slower timebases and still show data then it passes.
Then repeat using a trigger signal just in case there is a difference between manual STOP mode and a trigger event capture.

Nico has used the example of an SPI frame where you are interested in a certain bit but also want to check the whole frame.

Nico's method (if I understand it correctly!) is this:
 
- Set the trigger to the data point of interest
- Set memory to max
- Set the time base so the specific data point fills the screen (i.e. max detail)
- Perform a single acquisition, then STOP
- Check out the data point
- Then zoom out to check out the rest of SPI frame

The method I know would be:
- Set the trigger to the data point of interest
- Set memory to max Not necessary as scopes will usually maximize the memory to an sufficient extend automatically
- Check what the length of that SPI frame is and set the timebase to capture the whole frame (say 100us)
- Perform a single acquisition Actually, I might not want to but prefer to look at life data, so I leave the scope on normal mode
- Check out the frame
- Zoom in to the datapoint of interest and check that out

The result is the same, it's just the opposite way of doing it. Nico's method is also perfectly valid, however won't be possible unless the scope allows him to zoom out (which many don't, especially on very short time bases). While the method I have described works on every DSO.

The other difference is that, when it comes setting up your scope and avoiding excessive acquisition time (keeping in mind that time saving was one of the arguments for his method!), Nico needs to know how much memory he needs to use, so he not only needs to establish what the frame lenght is but also how in how many points this translates in terms of sample memory. While the second method just requires knowledge of the frame length.

Keep in mind this is *not* "zooming out"as having your scope in normal mode and just changing the timebase so you can see more of the signal, which again works on every scope. It's really about if a scope can record beyond its screen on very short timebases when the memory is set accordingly, which is only visible in a single acquisition.

The contentious point was actually not about the methods itself (I just never heard of anyone doing it this way before) but if a scope should be expected to accommodate Nico's method and what the relevance of this is in real life.

You are missing a few fine details:
- I'm not using single acquisition in most cases. I stop the oscilloscope when I see something of interest and in some cases I leave it in run mode because I have control over generating the trigger events somewhere else.
- I don't care about the time base setting and I'm not going to calculate how much memory I need. If it turns out to be not enough then I have to fallback to presetting the time base. The deeper the memory, the less this is necessary.

The key point to my method is that you don't need to worry about setting up the time/div and horizontal position of the scope properly before doing a measurement. Sometimes I forget to put the horizontal position back to the trigger point. With the oscilloscope recording outside the screen I can just scroll back to the trigger point. The benefits of my method are:

- Scope time/div setup is not critical to catch all data in many cases
- Least twiddling with knobs & settings


 Keep in mind that this usage mostly happens during debugging interaction between software and hardware. In the end it saves time. I think I already mentioned this workflow in my review of the SDS2204 I did 5 or 6 years ago. I have not checked that yet.

But you do have lots of twiddling of knobs while you are looking at the data....

Like I said, what you do is runaround way doing same thing as I do simpler.  I put Pico to 200 MS depth, set it to 200 ms, and let it rip..
Sometimes in run mode where I stop it and look around, or zoom in to a window ( On Picoscope zoom mode is still full screen, no loss of size) and keep looking at that time in run  mode. Or I have a burst of something that I get in single mode and look at it.
I literally bought Picoscope for that purpose.... And many protocols, deep mem, and huge PC screens (plural) is much better for that than any standalone scope.

[Wuerstchenhund]

You are missing a few fine details:

That's entirely possible.

- I'm not using single acquisition in most cases. I stop the oscilloscope when I see something of interest and in some cases I leave it in run mode because I have control over generating the trigger events somewhere else.

I see, but if you use RUN mode then the discussion is mood, as any change in the time base (say to "zoom out") would be a normal change of the acquisition parameters and thereby completely unaffected if a scope allows capturing events outside the screen area or not. 

The problem (can you capture outside the screen or not) only affects single acquisition (or, on a InfiniVision scope, the last acquisition after pressing STOP).

- I don't care about the time base setting and I'm not going to calculate how much memory I need. If it turns out to be not enough then I have to fallback to presetting the time base. The deeper the memory, the less this is necessary.

I understand, but that would then run counter to your argument that your method saves time. Which it doesn't, as not caring about the memory means you are likely to use too much (i.e. unnecessarily extending the acquisition time), or to use too little (undersampling) and then need to re-adjust and repeat.

The key point to my method is that you don't need to worry about setting up the time/div and horizontal position of the scope properly before doing a measurement.

Well, you still need to twiddle the knobs until the screen shows what your want, right? It shouldn't really matter if you do that visually or parameter based (actually twiddling might even take longer than just setting the scope to a specific parameter).

Sometimes I forget to put the horizontal position back to the trigger point. With the oscilloscope recording outside the screen I can just scroll back to the trigger point.

I get the overall idea, but I still struggle to see it in practice.

The benefits of my method are:

- Scope time/div setup is not critical to catch all data in many cases

Well, to some extend it is, because you need to make sure your timebase setting isn't so low that the sample rate drops below what you want, and you need to make sure that your memory setting isn't too small (undersampling) or too excessive (increased acquisition time).

- Least twiddling with knobs & settings

This is what I don't see. To me your method, while valid, seems to be overly limiting (it only works on a few scopes if you want to use single acquisition), and while you may not have to calculate memory you still have to balance timebase and memory settings so you are capturing long enough at a high enough sample rate but not too much to avoid extended waiting times for the acquisition to finish.

The method I described on the other side works on every scope, in RUN or single acuisition, all I need to know is how long my sequence is (and you need to know that for being able to assess if the timing parameters of your signal are correct or not anyways) and use this one parameter to setup the timebase. That's it. I then see the whole sequence, and if I want to see a specific detail I just zoom in (i.e. pinch to zoom, drag a box around the point of interest, or use the zoom knob, depending on the scope). If I want to see more I can happily move around as I wish, all without ever having to touch the timebase knob (unless of course, the timebase know is also your zoom knob).

Keep in mind that this usage mostly happens during debugging interaction between software and hardware. In the end it saves time. I think I already mentioned this workflow in my review of the SDS2204 I did 5 or 6 years ago. I have not checked that yet.

I get the situation, and I can follow your line of intention, I just don't see the advantage (and I see a number of disadvantages).

As I said, I've never heard anyone doing it this way (i.e. trying to capture in single acquisition mode beyond the screen to zoom in) but I find your approach interesting. I just don't fully "see" it as practical.

[Wuerstchenhund]

Nico's method (if I understand it correctly!) is this:
 
- Set the trigger to the data point of interest
- Set memory to max
- Set the time base so the specific data point fills the screen (i.e. max detail)
- Perform a single acquisition, then STOP
- Check out the data point
- Then zoom out to check out the rest of SPI frame

Exactly the same as what I'm doing, except I couldn't be arsed to use any data 
You don't need the data, it's obvious when the samples run out as the trace stops at both ends.[/quote]

Well, if you want to zoom out then your scope must be capturing the complete sequence, so there must be enough memory to capture screen area plus the area of interest outside the screen.

So on a KS InfiniVision scope this only work in SINGLE or for the last acquisition in STOP mode as otherwise the scope will only capture enough for the period that's shown on the display. So it only works with a stopped acquisition.

For a Rigol scope you'd have to set the memory manually to something high to capture beyond the screen. Which, as with the KS, only makes sense in SINGLE or as the last acquisition after pressing STOP.

If you care about time then at least on the Rigol you'd also have to make sure the memory setting isn't excessive (capturing more than you need).

The contentious point was actually not about the methods itself (I just never heard of anyone doing it this way before) but if a scope should be expected to accommodate Nico's method and what the relevance of this is in real life.

I don't see it as contentious, it has obvious use. It lets your trigger thing or interest and then say "gee I wonder what happened before or after that". If you have a scope that captures outside the display then you don't have to retrigger again at longer time base. This could actually be vital on something you can only trigger off intermittently for example.

So where is the benefit over triggering to the same point of interest (i.e. same trigger) and just setting the timebase to show the whole sequence on the screen, and then just zoom in to a detail of interest? You'd still not have to retrigger, and it works on every scope. 

[EEVblog]

So on a KS InfiniVision scope this only work in SINGLE or for the last acquisition in STOP mode as otherwise the scope will only capture enough for the period that's shown on the display. So it only works with a stopped acquisition.

Nope, it worked on both stopped and triggerd aquisitions.

So where is the benefit over triggering to the same point of interest (i.e. same trigger) and just setting the timebase to show the whole sequence on the screen, and then just zoom in to a detail of interest? You'd still not have to retrigger, and it works on every scope. 

The point is you may not have been interested (or know) in the whole timebase length, you were just interested in the event so that's what you triggered from. But as I said, if then you think, see I wondered that happened before or after that, bingo, it's there for you to zoom out to see.
Could be very handy.

If that's not how you work then that's fine, but it's undeniable it could be an advantage to some.

[2N3055]

The point is you may not have been interested (or know) in the whole timebase length, you were just interested in the event so that's what you triggered from. But as I said, if then you think, see I wondered that happened before or after that, bingo, it's there for you to zoom out to see.
Could be very handy.

If that's not how you work then that's fine, but it's undeniable it could be an advantage to some.

Absolutely agree with you, and as I said, it did come in handy few times. But I don't depend on it, and would not discard otherwise good scope because of it...
I mix using Keysight 3000T (that is like that) and Picoscopes (that are not) and see no problem using either.
My philosophy is that I will use some unforeseen advantage if I can, but I can't (and won't) depend on something that is not guaranteed.

[Wuerstchenhund]

So on a KS InfiniVision scope this only work in SINGLE or for the last acquisition in STOP mode as otherwise the scope will only capture enough for the period that's shown on the display. So it only works with a stopped acquisition.

Nope, it worked on both stopped and triggerd aquisitions.

It doesn't. Because all InfiniVision scopes only capture enough for the period displayed on screen and only use all the memory during the last acquisition when you press STOP (or on a single acquisition).

The only way you can "zoom out" during a in normal (continuous) mode is if you change the time base setting to something longer, after which the scope adjusts the memory usage to the new screen period and then performs the next acquisition with the new parameter. You're still not recording out of screen data.

So where is the benefit over triggering to the same point of interest (i.e. same trigger) and just setting the timebase to show the whole sequence on the screen, and then just zoom in to a detail of interest? You'd still not have to retrigger, and it works on every scope. 

The point is you may not have been interested (or know) in the whole timebase length, you were just interested in the event so that's what you triggered from. But as I said, if then you think, see I wondered that happened before or after that, bingo, it's there for you to zoom out to see.
Could be very handy.

True. But on the Rigol you still need to setup the memory (so you need to have some idea about the length of the overall sequence you want to watch) or you may end up with too little memory, and in the KS you can't really "zoom out" unless you're in STOP mode.

If that's not how you work then that's fine, but it's undeniable it could be an advantage to some.

And I just try to understand where that advantage is, and why would you require a scope to do that.

Doesn't seem to be a widely requested feature, though.

[JPortici]

LeCroy scopes don't, and as Siglent follows LeCroy their scopes don't, either.

also Picoscope

[nctnico]

So on a KS InfiniVision scope this only work in SINGLE or for the last acquisition in STOP mode as otherwise the scope will only capture enough for the period that's shown on the display. So it only works with a stopped acquisition.

Nope, it worked on both stopped and triggerd aquisitions.

It doesn't. Because all InfiniVision scopes only capture enough for the period displayed on screen and only use all the memory during the last acquisition when you press STOP (or on a single acquisition).

This depends on the version of InfiniVision scope you are using. The DSO7104A I used to own could record outside the screen in any mode. The newer models seem to only do this in single mode (if I interpret the user manual correctly).

[2N3055]

So on a KS InfiniVision scope this only work in SINGLE or for the last acquisition in STOP mode as otherwise the scope will only capture enough for the period that's shown on the display. So it only works with a stopped acquisition.

Nope, it worked on both stopped and triggerd aquisitions.

It doesn't. Because all InfiniVision scopes only capture enough for the period displayed on screen and only use all the memory during the last acquisition when you press STOP (or on a single acquisition).

This depends on the version of InfiniVision scope you are using. The DSO7104A I used to own could record outside the screen in any mode. The newer models seem to only do this in single mode (if I interpret the user manual correctly).

You don't understand what Wuerstchenhund  is saying.

When running Infiniivision captures only "screeen lenght". If you change timebase , it will change what it captures, and again, will capture only  "screen length"every trigger.
But, if you press STOP, it will practically reconfigure engine for SINGLE mode ( with half of max mem) and will keep some data before first triggered frame, and will keep on capturing until it runs out of buffers.

So to you, it does look like it takes full mem, but it doesn't do that all the time but only on last capture when you stop.
When stopped it seems all the same to you, but Wuerstchenhund  is right, while running it's not.

How we know that? Well, if you put 3000T to 50 ns/div (500 ns per screen) it will retrigger at rate of 980 kHz. Slightly more than 1 us per trigger event.
Then you stop it and voila, you get 400us of capture. 40 us before trigger point, and 360us after trigger point.
And as you go from 50ns/div to 20us/div, it will keep sample rate of 5GS/s, while running keeps taking only what is "screen lenght" worth in every trigger, and if you stop it you get, again, you get 400us of data. Than sample rate goes down.

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

P.S to be exactly technically correct it doesn't always capture exactly screen length. Sometimes it will capture a bit more, depending on division ratios of time/sample rate/buffer size chunks. But on every trigger event it captures only smaller sub buffer (compared to what it returns when stopped), minimum size to fit screen full of data necessary.

[nctnico]

Again (4th time I'm explaining this): Keysight has changed the behaviour on the more modern models!

[2N3055]

Again (4th time I'm explaining this): Keysight has changed the behaviour on the more modern models!

Other people (other than you) started to think that 3000/4000 series behave the way you said. They don't.
Well, they do, sort of, but not in consistent and always useful way.

[maginnovision]

Well, this workflow (zooming out after a capture) is available on many DSOs. It is the standard (or at least configurable) on Tektronix, Rigol, GW Instek, R&S, the older Keysight scopes (DSO7000A / B series and derivatives), the original Siglent SDS2000 series and probably several others. However you have to realise that 'capture outside' the screen only works if there is memory left over after filling the screen. So it won't be the case at time/div settings where the maximum samplerate  is dropped. I have been using DSOs like this forever. I strongly recall being very annoyed by the Siglent SDS2000 not remembering this setting in the early firmware.

Sorry, I stand corrected, I had a brain fart, you are right. Both Rigol (2000) and (modern Megazoom IV) Keysight do this, they will capture full memory depth and allow you to "zoom out" from a shorter time base trigger capture.
Siglent (5000X) however does not do this, it captures the screen and that's it, you can't "zoom out" either in STOP mode or single shot triggered mode.
The Siglent sampling architecture must be implemented very differently.

Indeed, it seems the Keysight InfiniVision scopes perform the last sample at full max memory independent on the timebase.

The Rigols seem to do it when memory is set manually (well, the memory management is pretty basic).

However, Keysight Infiniium scopes (at least for DSO8k and newer) don't.

LeCroy scopes don't, and as Siglent follows LeCroy their scopes don't, either.

Tek MDO3k & Co do through a trick (leaving the timebase longer and zooming in when selecting shorter ones), other ones don't (I can't remember so I have to rely on 3rd paty info here).

R&S I don't remember but I don't believe they do.

Through habit I guess I've just learned not to rely on this when capturing.

Now I'm curious to see a list of scopes that do this and those that don't. But this should have it's own thread.

Wouldn't this make a nice topic for one of your videos? Maybe coupled with a comparison of the nctnico method vs everyone else's method? 

I would watch that 

Little late but it isn't just Nico's method, I've done this also. I typically generate my triggers onboard(cpld or fpga) then depending on how everything looks I may need to pull the timebase out to see more. If not great if so it saves me another capture. I can't see both things in one timebase easily since it's data and timing validation initially but if timing is good and data bad I have to see why. Waiting for another error could take time and slow down debugging as well.

[2N3055]

Yes I did too. But that is not method. You were looking at stuff at wrong time base for that kind of analysis.
It is a lucky happenstance that scope, on it's own captured some more data than it was supposed to, so you could take a look at something else too..
And it worked in your favor. But it's not reliable all the time and on all time-bases. And different on every scope type.
I capture all in one long capture and can look at both slow and fast at will all the time.
That is how it's done if you were to use logic analyser for decoding. You capture the lot and zoom in into details..

[nctnico]

Yes I did too. But that is not method. You were looking at stuff at wrong time base for that kind of analysis.
It is a lucky happenstance that scope, on it's own captured some more data than it was supposed to, so you could take a look at something else too..

Sorry but you are trying to reason a moot point here. If you want recording outside the screen then select a scope which does. If not then don't. It has nothing to do with luck so don't try to ridicule a working method which is very efficient in real use cases. If you don't see it then you don't see it. As they say: you can lead a horse to water but it has to start drinking by itself.

[2N3055]

In my case that's not true. If I pulled out initially to always see everything I'd spend more time calculating the timing measurements of the different signals than I would simply viewing the waveforms. Another issue I've run into is some scopes changing measurement resolution based on timebase in a way I lose the resolution I needed. I don't use $20k - $50k scopes though, I only need and use general purpose scopes. Maybe some more expensive scopes are better about that.

Thank you for explaining. That makes sense.
Proper deep memory scope is made exactly to work around this. And this is why I bought Picoscope. It works on full (not decimated) buffer.
It will keep resolution. It is cheapest analytical scope you can get. And decodes tons of protocols. Only problem is no protocol triggers. But i use it for bulk captures anyway.

[2N3055]

Yes I did too. But that is not method. You were looking at stuff at wrong time base for that kind of analysis.
It is a lucky happenstance that scope, on it's own captured some more data than it was supposed to, so you could take a look at something else too..

Sorry but you are trying to reason a moot point here. If you want recording outside the screen then select a scope which does. If not then don't. It has nothing to do with luck so don't try to ridicule a working method which is very efficient in real use cases. If you don't see it then you don't see it. As they say: you can lead a horse to water but it has to start drinking by itself.

If you want to capture outside screen, just don't. If you know what needs to be captured upfront, just do propper capture...
And leading a horse to water is a nice one. Thanks for that.  It applies nice to you who writes this outside screen nonsense EVERY SINGLE TIME anybody on EEVBLOG mentions oscilloscope.
Over and out.  I'm done here. I explained my opinion, explained how it applies to scopes I own and use. Rest is up to anybody else to form their own opinion.
And I don't want you to change what you believe and and contest what works for you. If you're happy with it, good for you.

All the best to all.

[2N3055]

Which Picoscope model do you have 2N3055?
It seems interessting to investigate 

I have 3406D MSO. But they have few scopes that have more than 500 MS. Even 2000 series goes to 128 MS mem depth.
I also have 4262, a 16bit 2ch 5MHz scope that is excellent for low frequency low noise measurement
But to be honest, they are not very cheap, and are more of a specialized instrument.
To me they are great complement to Keysight 3000T.
Many people would not like having Picos as only scope, but you could make a combination of smaller cheaper scope (like Siglent SDS 1104X-E, MSO5000, or maybe Keysight 1000) for interactive work and Pico for analysis.

[2N3055]

Is this the right forum for an argument?

To be honest,  there is no right place for an argument. That's why I plan not to continue with it, all is already said and repetition is not productive. And I don't think Nico is asking for one either, just trying to stand by his opinion. Which is his right. We disagree on this topic. That's fine, We agree on many other things. That's fine too..
All the best,

[tautech]

Yes I did too. But that is not method. You were looking at stuff at wrong time base for that kind of analysis.
It is a lucky happenstance that scope, on it's own captured some more data than it was supposed to, so you could take a look at something else too..

Sorry but you are trying to reason a moot point here. If you want recording outside the screen then select a scope which does. If not then don't. It has nothing to do with luck so don't try to ridicule a working method which is very efficient in real use cases. If you don't see it then you don't see it. As they say: you can lead a horse to water but it has to start drinking by itself.

If you want to capture outside screen, just don't. If you know what needs to be captured upfront, just do propper capture...
And leading a horse to water is a nice one. Thanks for that.  It applies nice to you who writes this outside screen nonsense EVERY SINGLE TIME anybody on EEVBLOG mentions oscilloscope.
Over and out.  I'm done here. I explained my opinion, explained how it applies to scopes I own and use. Rest is up to anybody else to form their own opinion.
And I don't want you to change what you believe and and contest what works for you. If you're happy with it, good for you.

All the best to all.

Bingo !

Is this the right forum for an argument?

Argument ? 

This is a technical discussion of what's an appropriate usage style of the modern DSO based on the understanding of the acquisition HW design and the selection of tools at your disposal.

[Gandalf_Sr]

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

[2N3055]

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

Darn, I'm losing it... Didn't catch it... Sorry!! Off I go  for a refresher course...