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.