Products > Test Equipment
Waveforms/second in Siglent and other scopes -- limits due to capture handling
Someone:
--- Quote from: kcbrown on June 20, 2024, 11:03:01 pm ---I didn't say I want the segments to be independent of triggers, I said I want to remove the 1:1 mapping between the two. Quite obviously, a segment should contain at least one trigger event and should be generated as a consequence of at least one trigger event.
--- End quote ---
Then say that plainly, not this many post wall of text. Oh wait, that's how scopes ALREADY work.
--- Quote from: kcbrown on June 20, 2024, 11:03:01 pm ---
--- Quote from: Someone on June 20, 2024, 10:04:28 pm ---That padding might be some novel feature but it sounds rather complex to implement and produce a useful UI for that isn't confusing.
--- End quote ---
Complex to implement? Perhaps. It's hard to see how it would be terribly complicated. It can be as simple as "stop the current capture after X amount of time since the last trigger was seen".
--- End quote ---
"how hard can it be?" :-DD
Design your own scope and get back to us on that.
--- Quote from: kcbrown on June 20, 2024, 11:03:01 pm ---
--- Quote from: Someone on June 20, 2024, 10:04:28 pm ---Why not just have your segments be larger than your expected largest packet? and position the trigger within that to have pre and post padding? We have this right now and you're asking for some minor improvement over that, at great complexity.
--- End quote ---
Because that presumes I know what my largest expected packet will be. That's not a given, at all, and my original SPI bus example should make that plain.
Moreover, it forces me to sacrifice capture memory, because it forces the capture length of every capture to be the maximum expected length. And for what? What benefit do I get from capture memory that contains waveform points that I have no interest in?
--- End quote ---
Not adding layers of complexity and work for some corner case benefit. Development is not free, and either adds cost or takes away from some other area.
--- Quote from: kcbrown on June 20, 2024, 09:36:28 pm ---
--- Quote from: Someone on June 20, 2024, 10:04:28 pm ---
--- Quote from: kcbrown on June 20, 2024, 09:36:28 pm ---Perhaps another way of saying it is: the waveform update rate should be independent of the capture size.
--- End quote ---
Technically/literally/mathematically/physically impossible.
--- End quote ---
Really?
[... add specific constraints]
--- End quote ---
Capture/wavewform/display lengths define an upper limit to the waveform update rate, if you want to invent your own terminology and not explain it then don't get pissy when no-one else understands what you are trying to say. Few devices even approach the theoretical limits because they are not practically useful to be worth investing resources into.
--- Quote from: kcbrown on June 20, 2024, 11:03:01 pm ---
--- Quote from: Someone on June 20, 2024, 10:04:28 pm ---As far as I can tell you're trying to extend the zoom out nonsense with a new dimension of:
"why cant my scope do both at the same time"
--- End quote ---
Yes, why can't it?
--- End quote ---
Because like zoom out, its some corner case with little practical value. If you think it is such a valuable tool, go out and fund its development. If you want some magical for purpose device then stop complaining and make it happen rather than asking why no-one else is giving it to you for free.
--- Quote from: kcbrown on June 20, 2024, 11:03:01 pm ---
--- Quote from: Someone on June 20, 2024, 10:04:28 pm ---Well, that's because it would need to double/duplicate various parts of the system for this imagined need.
--- End quote ---
What would need to be duplicated in order to accomplish what I describe? The display is simply showing some part of the already-captured waveform. That's the case even with current implementations. The trigger is simply firing on the basis of acquired points. That's also the case even with current implementations. All I'm suggesting is a change in how and when the system displays the waveform, and how and when the system begins a new capture in memory. So far, it seems the most complicated part is the notion that captures could now differ from each other in length.
--- End quote ---
Without realising, you've asked for not one but several different things. Pretty much all of them would have some tradeoff in either requiring additional hardware or compromising some other aspect of operation. This is engineering with multiple complex interactions that you simply dismiss in your ignorance of them.
So far this appears like a lot of consumer wishes you see on forums, which boil down to:
"I want other people to spend time aggressively optimising a complex system for my narrow and unusual use case. WHY ISNT IT HAPPENING THIS IS SO SIMPLE EVEN I CAN IMAGINE IT"
I'll just throw out my usual chuckle about scopes that implement high-res/averaging mode at higher bit depths with the same capture length as the normal modes. Do I go around shouting about scopes are throwing away the memory and not using all of it, HOW DARE THEY. No, I don't do that because it has no purpose/value. These devices are made in small volumes for specialist markets, I'm not surprised they have compromises and aren't ruthlessly optimised to use 100% of everything in all situations.
kcbrown:
--- Quote from: Someone on June 20, 2024, 11:37:03 pm ---
--- Quote from: kcbrown on June 20, 2024, 11:03:01 pm ---I didn't say I want the segments to be independent of triggers, I said I want to remove the 1:1 mapping between the two. Quite obviously, a segment should contain at least one trigger event and should be generated as a consequence of at least one trigger event.
--- End quote ---
Then say that plainly, not this many post wall of text. Oh wait, that's how scopes ALREADY work.
--- End quote ---
I did say that plainly:
--- Quote from: kcbrown on June 20, 2024, 09:36:28 pm ---That may be. But I'm not arguing that we should dispense with segments. I'm arguing that we should dispense with the 1:1 mapping between captures and trigger events, that the display update rate should be defined by the time delay between trigger firings or optionally the time width of the display (whichever is longer, if the time width of the display is considered) even if the capture width is longer than both.
--- End quote ---
But, apparently, not plainly enough.
As a general rule, I presume that if someone doesn't get what I mean, then I'm not saying it properly, and that applies here. In any case, hopefully you get where I'm coming from now.
As for the claim that it's how scopes already work, if that's truly the case, then explain why it is that, for any scope I'm aware of, the trigger doesn't rearm until after the capture completes, at least for the purpose of the waveform updates and trigger out mechanism.
--- Quote ---"how hard can it be?" :-DD
Design your own scope and get back to us on that.
--- End quote ---
I suspected that would be coming next. :)
I would if I could. But note that saying "design it yourself" is not the same as saying "here's why it can't be done". You're asserting it can't be done, and so I ask why that's so.
Now, why hasn't it been done? That's a different question, and not one I'm asking. I understand that these things take development work, and may well simply be covering a corner case that isn't worth the R&D to address. On that, I can't say. All I can say is that I've run into situations in which the mechanism I describe would be useful, because it's more flexible (near as I can tell, at any rate) than the mechanisms that are currently in use.
--- Quote ---Capture/wavewform/display lengths define an upper limit to the waveform update rate,
--- End quote ---
Yes, they do, with current implementations. Now why must that be the case? Explain in detail. Feel free to point at external documents that answer the question.
I'm not being facetious here. If there are good engineering reasons for these limits being defined as they are, I'd like to know what they are. Because as far as I can tell, they're defined that way in large part because the original implementation upon which digital scopes were modeled after are analog scopes for which that is true.
--- Quote ---if you want to invent your own terminology and not explain it then don't get pissy when no-one else understands what you are trying to say.
--- End quote ---
What makes you believe I'm getting "pissy"? I'm not annoyed or anything of the sort. I'm simply explaining (or, at least, attempting to -- badly, it seems) an approach to the problem of acquisition and display that occurred to me, that differs from the current approach and which would (it seems, at least on the surface) retain the current capability while addressing others that no implementation I'm aware of addresses.
--- Quote from: kcbrown on June 20, 2024, 11:03:01 pm ---Because like zoom out, its some corner case with little practical value.
--- End quote ---
Zoom out is a corner case with little practical value???
Nctnico would likely disagree strongly with that.
If it's truly a corner case with little practical value, then explain why most scopes are implemented such that the capture width exceeds the display coverage, i.e. they make limited zooming out possible by default.
--- Quote ---If you think it is such a valuable tool, go out and fund its development. If you want some magical for purpose device then stop complaining and make it happen rather than asking why no-one else is giving it to you for free.
--- End quote ---
Again, I must reiterate that I am not complaining here! I'm simply proposing an alternate approach that on its face seems more flexible than the current approach and which, if it has substantial disadvantages, I'm not aware of them. My lack of awareness of those disadvantages doesn't mean they're not there. I'm putting this whole thing out there so that I can learn those disadvantages.
--- Quote ---Without realising, you've asked for not one but several different things. Pretty much all of them would have some tradeoff in either requiring additional hardware or compromising some other aspect of operation. This is engineering with multiple complex interactions that you simply dismiss in your ignorance of them.
--- End quote ---
Curing my ignorance is exactly why I brought this whole thing up in the first place. I tossed the idea out in order to see what's wrong with it. So if I'm ignoring something important, then by all means please enlighten me. I can't learn from statements that say I'm ignorant. I can learn from statements that show with specificity what I'm ignorant of.
--- Quote ---No, I don't do that because it has no purpose/value. These devices are made in small volumes for specialist markets, I'm not surprised they have compromises and aren't ruthlessly optimised to use 100% of everything in all situations.
--- End quote ---
I'm not surprised by that either. That doesn't mean there isn't room for improvement. Maybe what I suggest addresses only what amounts to a corner case or two. Maybe it's not so limited as all that. But I will say this: the oscilloscope is a general-purpose instrument. It wouldn't have the plethora of capabilities it has otherwise. Some number of its capabilities are there to address corner cases, no?
I don't mind holes being poked in what I'm suggesting here. I encourage it. It's why I raised it to begin with. And if someone takes it and runs with it and produces something more capable than what we currently have, then we'll all be better off for it. If not, then so be it.
Someone:
--- Quote from: kcbrown on June 21, 2024, 01:48:16 am ---As for the claim that it's how scopes already work, if that's truly the case, then explain why it is that, for any scope I'm aware of, the trigger doesn't rearm until after the capture completes, at least for the purpose of the waveform updates and trigger out mechanism.
--- End quote ---
Which is inconsistent with what you already stated:
--- Quote from: kcbrown on June 20, 2024, 11:03:01 pm ---I didn't say I want the segments to be independent of triggers, I said I want to remove the 1:1 mapping between the two. Quite obviously, a segment should contain at least one trigger event and should be generated as a consequence of at least one trigger event.
--- End quote ---
A capture can contain more than 1 trigger event, your statement which is what the reply was based of. Of course once a capture ends there will be some gap before the next one. What use is retriggering more capture when there is already capture occurring? (that goes back to needing additional hardware if you want to follow that path). As already shown, it's relatively common to show multiple triggers within a single capture window/record.
You're talking about multiple things (unknowingly?) and trying to impossibly simplify it down.
--- Quote from: kcbrown on June 21, 2024, 01:48:16 am ---
--- Quote from: Someone on June 20, 2024, 11:37:03 pm ---Capture/wavewform/display lengths define an upper limit to the waveform update rate,
--- End quote ---
Yes, they do, with current implementations. Now why must that be the case? Explain in detail. Feel free to point at external documents that answer the question.
I'm not being facetious here.
--- End quote ---
How is twisting well understood techniques/methods into your own ill defined and illogical thing helping? Update rate where contiguous sequences of data are painted overlaid on a screen cannot happen faster than the data is arriving, and in the context of scopes do not happen faster than the horizontal sweep time (although a pathological implementation could it would be wildly costly). How can you put more information to the screen than is arriving? There is always an upper limit.
--- Quote from: kcbrown on June 21, 2024, 01:48:16 am ---But note that saying "design it yourself" is not the same as saying "here's why it can't be done". You're asserting it can't be done, and so I ask why that's so.
--- End quote ---
--- Quote from: kcbrown on June 21, 2024, 01:48:16 am ---Curing my ignorance is exactly why I brought this whole thing up in the first place. I tossed the idea out in order to see what's wrong with it. So if I'm ignoring something important, then by all means please enlighten me. I can't learn from statements that say I'm ignorant. I can learn from statements that show with specificity what I'm ignorant of.
--- End quote ---
So far you cannot even start to discuss your ideas or explain them coherently. What you are suggesting is unclear and seems to be inconsistent and changing. It's not on me to educate you to the level you desire. I've pointed out the holes in your thinking and you've apparently done nothing to go back and learn on your own.
If you want to challenge what's possible then you need to clearly lay out what you are actually trying to achieve, using the commonplace industry terms. Which you are still failing to do and then extending that into some grand "prove me wrong" bait.
Like the perpetual motion people.....
kcbrown:
--- Quote from: Someone on June 21, 2024, 02:16:49 am ---A capture can contain more than 1 trigger event, your statement which is what the reply was based of. Of course once a capture ends there will be some gap before the next one. What use is retriggering more capture when there is already capture occurring? (that goes back to needing additional hardware if you want to follow that path). As already shown, it's relatively common to show multiple triggers within a single capture window/record.
You're talking about multiple things (unknowingly?) and trying to impossibly simplify it down.
--- End quote ---
Perhaps so.
It may be that I lack the proper terminology for what I'm trying to explain, or that I'm badly mangling the terminology I'm using. My apologies for that.
Maybe it's simpler if I start from scratch, define all my terms, and use those terms to describe what I have in mind. Doing this with sufficient rigor to satisfy you is going to take some time, so stay tuned.
tautech:
I believe this is based on your experiences with SDS2000X Plus KC ?
Not all Siglent models manage memory and captures in the same way as they do....but can.
Eg, Zoom out of a capture is not a problem for some models.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version