Products > Test Equipment
Oscilloscope Zoom Out Quirk
<< < (29/113) > >>
nctnico:

--- Quote from: EEVblog on May 10, 2020, 11:27:43 am ---
--- Quote from: Someone on May 10, 2020, 11:16:42 am ---The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?
--- End quote ---

Ah, THAT'S the magic in the capture architecture design!

This just triggered my memory! (pun of the week, surely?)
I independently solved this in my DSOA Mk3 design back in 1998 with 7200 FIFO's.
https://alternatezone.com/electronics/files/dsoamk3.txt

--- End quote ---
That is how all DSOs work however not using a FIFO but a circular buffer. After all you never know when a trigger arrives. A couple of years ago I have designed a distributed data acquisition system (for a customer) which triggers on input signals to define the start of a measurement. It nearly is a DSO except for the display and knobs. When an acquisition starts it just fills the memory continously as a circular buffer. But a trigger will only be accepted once there is enough data to meet the pre-trigger requirement. If a trigger occurs during the pre-fill time then it will be lost. The pre-fill time can be avoided by setting the trigger point before the start of the acquisition (which is also something the system I designed supports).


--- Quote from: EEVblog on May 10, 2020, 11:34:00 am ---
--- Quote from: nctnico on May 10, 2020, 11:22:41 am ---
--- Quote from: EEVblog on May 10, 2020, 11:10:38 am ---And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".

--- End quote ---
No, because that only applies to Keysight. So far only Lecroy and Siglent scopes can't record outside the screen.
--- End quote ---

Err, wouldn't it apply to every scope brand that does this?, not just Keysight.

--- End quote ---
No. Not at all. See my earlier list.

--- Quote ---How else would it be achieved whilst keeping any resemblance of half way decent update rate?

--- End quote ---
Why is update rate so important? In many cases it just isn't and using all the memory is far more useful. If you still have an R&S scope you can see you can set the memory to auto or use a pre-defined depth. On the R&S (for example) you can have either a short memory depth to achieve a high update rate OR select deep memory. Ofcourse deep memory will slow the acquisition rate but that isn't a problem. A lot of the work I do is in embedded firmware / hardware interaction where messages pass by at a rate of a couple of hundred per second at most.
nfmax:

--- 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
nctnico:

--- 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 ---
Actually not. AFAIK Even Siglent and Lecroy already have the option to set a fixed memory depth. It is only that they choose not to actually use full memory if that results in more sample points necessary to fill the screen. In a way you could even argue that those oscilloscopes don't do what you tell them to.  >:D
Someone:

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

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 explicit 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).
tv84:

--- 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...)
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod