So basically Nico relies that his "full memory capture" will hopefully, maybe, with any luck, capture all of the stuff he needs...And will keep calculating in his head if that is going to happen or not.
Here your reasoning goes wrong. A modern DSO has 10, 40, 80, 100Mpts worth of memory. At 2 Gs/s 10Mpts is already 5ms worth of data. A time span of 5ms is more than enough to capture 5000 bits of SPI data clocked at 1MHz (which is low for typical SPI). So even when limited to the maximum samplerate you are very likely to capture all of the relevant data you need. There is no luck involved. Ofcourse there are situations where you may need to capture over a longer period of time but that doesn't mean 'my' way of working is useless to begin with. And increasing memory depths on DSOs keep pushing that boundary further away.
But guess what, there is a very good way to deterministically do this. Easy too.
You set scope to capture whole time span with timebase (in this case 1ms/div, 10ms full screen if 10 divisions), set memory depth to make sure you have sample rate that is adequate for what you're doing (and verify both settings right there on the screen),capture whole thing in first try, and then zoom in and out of area of interest at will , for as long as you want to.. And it will do exactly as you commanded. Every time.
That is way too much work for me. The DSO is there for me, not the other way around. The less twiddling knobs and the less clutter on the screen, the better.
No I'm not wrong. And you were mentioning, for instance, Keysight DSO7000A / B that don't have 100MS memory.
What you don't understand is that
my way of working and
your way of working is exactly the same...
We
both get
same amount of data, except you do mental math (as you did in your response) to
calculate sample size to get amount of data you want, capture and then
zoom out (
with timebase knob), and I simply use timebase
to capture whole event exactly, and use
zoom in...
Neither is wrong, my way is a bit
simpler (no mental math, all is already displayed on screen), and both get same results.
Only thing that is wrong is that you, quite theatrically if I may add, proclaim scopes useless if they don't conform to your way of use. And while I, on occasion, when looking at some fast edge, was able to zoom out with timebase, to see some parts of curve afterwards without need to reacquire, it is not something I rely on. The way I see it it is not a favorable feature, but more of your bad habit to capture data on wrong timebase, relying on scope to compensate for that. Sorry, that is my stance on the issue.
But I agree with you that:
- Most of the scopes use too much screen space for zoom mode. It should be tiny scroll bar just to get general idea of waveform and position in the buffer
- Preferably zoom window size should be user configurable (half, quarter screen, minimum, or even better infinite variable like R&S)
- Taking long capture at high sample rate is priceless. I have a deep mem scope because of that.
- When stopped, you should be able to "zoom in and out" with timebase and hor.pos. knob over full capture, like a sorts of "full screen zoom mode". That makes "zoom mode screen problems" go away completely, and is intuitive (same behaviour running and stopped).
Best regards,