Oscilloscope Zoom Out Quirk - Page 1
Forum section: electronics / testgear

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: May 08, 2020, 09:18:13 am
content: Quote from: EEVblog on May 08, 2020, 08:18:12 amNico 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 frameThe method I know would be:- Set the trigger to the data point of interest-Set memory to maxNot 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 acquisitionActually, 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 outThe 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 08, 2020, 09:31:29 am
content: Quote from: Wuerstchenhund on May 08, 2020, 09:18:13 amYou 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 & settingsKeep 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.

author: EEVblog
author_rank: Unknown
timestamp: May 08, 2020, 09:36:44 am
content: Quote from: Wuerstchenhund on May 08, 2020, 09:18:13 amExactly the same as what I'm doing, except I couldn't be arsed to use any dataYou don't need the data, it's obvious when the samples run out as the trace stops at both ends.QuoteI 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.

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: May 08, 2020, 09:54:57 am
content: Quote from: EEVblog on May 08, 2020, 09:36:44 amIt's the story of my life, the data I need are always just after the scope runs out of memory

author: 2N3055
author_rank: Super Contributor
timestamp: May 08, 2020, 10:09:15 am
content: Quote from: nctnico on May 08, 2020, 09:31:29 amBut 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.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: May 08, 2020, 10:38:55 am
content: Quote from: nctnico on May 08, 2020, 09:31:29 amThat's entirely possible.QuoteI 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).QuoteI 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.QuoteWell, 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).QuoteI get the overall idea, but I still struggle to see it in practice.QuoteWell, 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).QuoteThis 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).QuoteI 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.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: May 08, 2020, 10:56:11 am
content: Quote from: EEVblog on May 08, 2020, 09:36:44 amExactly the same as what I'm doing, except I couldn't be arsed to use any dataYou don't need the data, it's obvious when the samples run out as the trace stops at both ends.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).QuoteSo 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.

author: EEVblog
author_rank: Unknown
timestamp: May 08, 2020, 11:24:40 am
content: Quote from: Wuerstchenhund on May 08, 2020, 10:56:11 amNope, it worked on both stopped and triggerd aquisitions.QuoteThe 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.

author: 2N3055
author_rank: Super Contributor
timestamp: May 08, 2020, 11:35:19 am
content: Quote from: EEVblog on May 08, 2020, 11:24:40 amAbsolutely 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.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: May 08, 2020, 12:35:36 pm
content: Quote from: EEVblog on May 08, 2020, 11:24:40 amIt 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.QuoteTrue. 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.QuoteAnd 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.

author: JPortici
author_rank: Super Contributor
timestamp: May 08, 2020, 01:50:46 pm
content: Quote from: Wuerstchenhund on May 08, 2020, 08:12:56 amalso Picoscope

author: nctnico
author_rank: Super Contributor
timestamp: May 08, 2020, 02:15:57 pm
content: Quote from: Wuerstchenhund on May 08, 2020, 12:35:36 pmThis 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).

author: 2N3055
author_rank: Super Contributor
timestamp: May 08, 2020, 04:32:26 pm
content: Quote from: nctnico on May 08, 2020, 02:15:57 pmYou 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 08, 2020, 04:54:23 pm
content: Again (4th time I'm explaining this): Keysight has changed the behaviour on the more modern models!

author: 2N3055
author_rank: Super Contributor
timestamp: May 08, 2020, 05:09:50 pm
content: Quote from: nctnico on May 08, 2020, 04:54:23 pmOther 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.

author: maginnovision
author_rank: Super Contributor
timestamp: May 08, 2020, 05:23:02 pm
content: Quote from: Wuerstchenhund on May 08, 2020, 08:12:56 amLittle 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.

author: 2N3055
author_rank: Super Contributor
timestamp: May 08, 2020, 05:37:50 pm
content: 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..

author: nctnico
author_rank: Super Contributor
timestamp: May 08, 2020, 06:02:15 pm
content: Quote from: 2N3055 on May 08, 2020, 05:37:50 pmSorry 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.

author: 2N3055
author_rank: Super Contributor
timestamp: May 08, 2020, 06:08:19 pm
content: Quote from: maginnovision on May 08, 2020, 05:48:39 pmThank 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.

author: 2N3055
author_rank: Super Contributor
timestamp: May 08, 2020, 06:16:30 pm
content: Quote from: nctnico on May 08, 2020, 06:02:15 pmIf 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.

author: 2N3055
author_rank: Super Contributor
timestamp: May 08, 2020, 07:57:04 pm
content: Quote from: jemangedeslolos on May 08, 2020, 06:56:47 pmI 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 measurementBut 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.

author: 2N3055
author_rank: Super Contributor
timestamp: May 08, 2020, 08:02:32 pm
content: Quote from: Gandalf_Sr on May 08, 2020, 07:36:40 pmTo 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,

author: tautech
author_rank: Super Contributor
timestamp: May 08, 2020, 08:06:37 pm
content: Quote from: 2N3055 on May 08, 2020, 06:16:30 pmBingo !Quote from: Gandalf_Sr on May 08, 2020, 07:36:40 pmArgument ?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.

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: May 08, 2020, 09:37:58 pm
content: I was actually making a reference to the Monty Python argument sketch; the conversation is quite illuminating.

author: 2N3055
author_rank: Super Contributor
timestamp: May 08, 2020, 09:49:48 pm
content: Quote from: Gandalf_Sr on May 08, 2020, 09:37:58 pmDarn, I'm losing it... Didn't catch it... Sorry!! Off I go for a refresher course...