| Products > Test Equipment |
| Oscilloscope Zoom Out Quirk |
| << < (30/113) > >> |
| Someone:
--- Quote from: tv84 on May 10, 2020, 11:53:22 am --- --- Quote from: EEVblog on May 10, 2020, 11:17:42 am ---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!" --- End quote --- (Disclaimer: I'm in no position to argue this theme with all the gurus here but, having said that,...) If that is what KS does, and others don't, I don't understand why. :-// We're talking STOP and SINGLE modes, right? So the scope has all the time in the world to process whatever it has to do after trigger and present results to the user. It seems it would be the way I would implement it! BUT, I see a problem, the result will be ALWAYS like this: [<-[ trigger ---------] ----------------------------- acquisition ----------->] Right? With this implementation/mode of operation, you'll never be able to do this: [<------- acquisition ------- [ ---- trigger -----]------- acquisition ------->] or this: [<-------------- acquisition ----------------------------[--------- trigger]->] Am I correct? (just a fact check to see if I'm understanding you all...) --- End quote --- The expansion around the screen is mostly (entirely?) symmetric on the mega zoom "bonus" capture, like the middle example. There is no control over where the extra memory is allocated, either for this, or nctnico's case where they manually set the acquisition memory depth wider than the visible window. So, as mentioned above, the "bonus" full length capture requires a trigger to arrive at just the right time or it doesn't capture the extra acquisition and just keeps the last regular sized one. |
| nfmax:
--- Quote from: Someone on May 10, 2020, 11:49:48 am --- --- Quote from: nfmax on May 10, 2020, 11:43:37 am --- --- Quote from: nctnico on May 10, 2020, 11:17:27 am ---If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better. --- End quote --- If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains. I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity --- End quote --- Fewer samples at a lower ADC sample rate can increase the waveform update rate (no scope is completely ideal with zero trigger re-arm and zero processing time), see the huge graph of a DPO4000 above doing exactly that. --- End quote --- Point taken - but then it is a Tek ;) --- Quote from: Someone on May 10, 2020, 11:49:48 am ---The UI control for memory depth isn't too complex, usually just a box in the horizontal settings. Whats annoying is not having an auto setting alongside the manual choices. And as I keep having to bring up, even if the scope doesn't have implicit manual control of memory depth, there are ways to control it with zoom windows etc. Which for many scopes is fewer button presses and/or dedicated controls, but uses the screen real-estate differently (could be better or worse depending on your particular application). --- End quote --- The Megazoom scopes I am familiar with have only recently introduced manual control of the acquisition memory. I think zoom windows are a bit of a distraction here. It's really only a different way of modifying the X scale: one that only lets you zoom in, not out, but shows both the zoomed and full time record. The full time record is exactly the same as a normal capture with no off-screen memory at all |
| 2N3055:
--- Quote from: tv84 on May 10, 2020, 11:53:22 am --- --- Quote from: EEVblog on May 10, 2020, 11:17:42 am ---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!" --- End quote --- (Disclaimer: I'm in no position to argue this theme with all the gurus here but, having said that,...) If that is what KS does, and others don't, I don't understand why. :-// We're talking STOP and SINGLE modes, right? So the scope has all the time in the world to process whatever it has to do after trigger and present results to the user. It seems it would be the way I would implement it! BUT, I see a problem, the result will be ALWAYS like this: [<-[ trigger ---------] ----------------------------- acquisition ----------->] Right? With this implementation/mode of operation, you'll never be able to do this: [<------- acquisition ------- [ ---- trigger -----]------- acquisition ------->] or this: [<-------------- acquisition ----------------------------[--------- trigger]->] Am I correct? (just a fact check to see if I'm understanding you all...) --- End quote --- When you press STOP, 3000T seems to reconfigure and capture one SINGLE capture on a separate trigger, together with pre trigger time. On highest sampling rate, you always get 40us pre and 360us post trigger. EDIT: Actually it depends on the where is trigger reference point set. If you set hor.ref point left, than it is -40us/+360us. BUT, if you set hor.ref point to center, than captured buffer is -200us/+200us arround trigger point. Respectively, if you set hor.ref point to right you get -360us/+40us |
| Wuerstchenhund:
--- Quote from: Gandalf_Sr on May 09, 2020, 11:57:28 pm ---Well you learn something every day :) --- End quote --- Indeed :) --- Quote --- --- Quote from: Someone on May 09, 2020, 11:52:42 pm --- --- End quote --- Yep, another of the corners for nctnico's atypical use case, rejection of zoom mode. You went with the obvious/logical use case! --- End quote --- Well, I start to see why Nico is doing it the way he does, probably because this is a reflection of his general approach to a measurement problem. I still remember similar discussions we had about the importance (or not) of Peak Detect, another feature he seems to consider crucial ;). I guess this is just his way of doing stuff, and if it works for him then I'm not going to tell him to do anything else. But while I believe I understand (to some extend) why *he* does it this way, I still fail to see why any real-world advantage of this method (and even less so where the claimed increase in efficiency or time savings should come from). The fact alone that this only works on some scopes (of which most only do this with a single acquisition) while the standard "capture long and then zoom in" methodology (for which deep memory scopes were designed for) works on every scope makes it impractical in a professional setting where you have to work with various different scope models. Personally, it also doesn't fit me because it sounds a bit arbitrary (like blindly poking around in some circuitry), as I tend to think about what I want to measure and what I expect to see, and then setup the scope accordingly. But that's just me (although most of our engineers are the same "think before you do" types). But hey, whatever fits you best. The problem I see is that this method is still rather niche, and due to it's various limitations over the standard "capture long and zoom in" method which is widely used it's really not a relevant criteria for a scope unless the user specifically asks for it, and it should not be treated this way. --- Quote ---Zoom mode adds one very important control that is missing when letting the scope expand around the visible window: you gain control of where the trigger is located within the full capture depth. --- End quote --- Not only that. Because there is also the problem that the excess data that even some of the scopes record is not always available. Take the Rigol DS1000z. We now established that, if you set the memory to manual then it will always record the full selected memory size, no matter what. Great, right? :-+ But here's the thing: on the DS1000z at least, you can't always access that data. In RUN mode, if you switch to zoom mode, you can still only zoom *in* on the signal on screen, but not zoom *out* to look at off-screen data. You can, of course, change the timebase, but that just means the screen will show the new timebase length after the next acquisition (i.e. the data of the previous acquisition are gone). You can, of course, also setup a trigger to a specific event, and then after the capture change the timebase to effectively "zoom out". However, for this to work there must be no subsequent acquisitions, or the data you want to look at is overwritten (and if that happens after the change of timebase then in effect it's no different to a normal timebase change on any scope). The test Nico described is essentially this, trigger to a specific event, then stop the trigger and then "zoom out". Which, consequentially, means that you can *only* look at off-screen data if the scope is no longer acquiring. It doesn't matter here if this is because this was the last in a series of acquisitions (with no subsequent acquisitions following), or if the scope was in SINGLE mode. In contrast, the standard method of "capture long then zoom in" works irrespective if the scope is halted or still acquiring. With zoom, I can watch live data, jump to a different part of the signal and watch other live data. With Nico's method, I have to acquire, then make sure the scope is not re-triggered and then "zoom out". With the standard method, on better scopes, I can even have multiple zoom windows, each showing a different segment of the signal. Single or continuous, doesn't matter :) Now, let's look at Nico's example of the SPI frame: He's setting the scope to max memory, set the trigger to the interesting data segment and set the timebase so that data bit is full screen. Now if the trigger event is rare or unique (say, the data segment has to reach a specific value) then after capturing the acquisition will essentially stop (waiting for the next trigger). If it's a common event then the scope then the acquisition must be stopped manually as otherwise the outside display data would be inaccessible. OK, let's say we have looked at the data segment, and now want to see the rest of the frame (which is outside the screen). So we change the timebase setting to the full frame length (whatever that is) and yes, we can see the data that before was off-screen. :-+ But the thing is that, at this point, our scope is now set to *exactly* the same timebase setting that we would have set it to with the common "capture long and zoom in" method |O. Just that the latter would have also allowed us to see both the whole frame as well as a detailed view of the data segment of interest without stopping the scope, i.e. we could observe live behavior. Something which, at least on the DS1000z, isn't possible with Nico's method. So in the end, Nico's method seems to be a convoluted way to avoid using the scope's zoom function while achieve the same which can be achieved with the standard method. It's not just with the DS1000z. I suspect all Rigol scopes behave the same (i.e. don't let you zoom outside the screen unless the scope is halted). HPAK's MegaZoom based scopes (InfiniVision and 546xx) for sure do. Can the R&S scopes "zoom out" to off-screen data in RUN mode, or does it need to be stopped? I don't know (maybe someone else can try) :-// In any case, Nico's method sounds more like a pain in the ass than a solution to a problem which actually exists. |
| Someone:
--- Quote from: nfmax on May 10, 2020, 11:58:10 am --- --- Quote from: Someone on May 10, 2020, 11:49:48 am --- --- Quote from: nfmax on May 10, 2020, 11:43:37 am --- --- Quote from: nctnico on May 10, 2020, 11:17:27 am ---If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better. --- End quote --- If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains. I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity --- End quote --- Fewer samples at a lower ADC sample rate can increase the waveform update rate (no scope is completely ideal with zero trigger re-arm and zero processing time), see the huge graph of a DPO4000 above doing exactly that. --- End quote --- Point taken - but then it is a Tek ;) --- End quote --- All scopes do it to some degree, even the vaunted megazoom ASICs. Again, all this is linked above for your reading... --- Quote from: nfmax on May 10, 2020, 11:58:10 am --- --- Quote from: Someone on May 10, 2020, 11:49:48 am ---The UI control for memory depth isn't too complex, usually just a box in the horizontal settings. Whats annoying is not having an auto setting alongside the manual choices. And as I keep having to bring up, even if the scope doesn't have implicit manual control of memory depth, there are ways to control it with zoom windows etc. Which for many scopes is fewer button presses and/or dedicated controls, but uses the screen real-estate differently (could be better or worse depending on your particular application). --- End quote --- The Megazoom scopes I am familiar with have only recently introduced manual control of the acquisition memory. I think zoom windows are a bit of a distraction here. It's really only a different way of modifying the X scale: one that only lets you zoom in, not out, but shows both the zoomed and full time record. The full time record is exactly the same as a normal capture with no off-screen memory at all --- End quote --- Zoom windows are a way to set the size of the full acquisition, the trigger point within that full range, and still see some short timescale detail in realtime. It ticks all the boxes for nctnico's bizarre use case except they then added another constraint of "zoom takes up too much of the display" which sounds like a good excuse to consider scopes with better display management and higher resolutions. |
| Navigation |
| Message Index |
| Next page |
| Previous page |