Waveforms/second in Siglent and other scopes -- limits due to capture handling - Page 1
Forum section: electronics / testgear

author: kcbrown
author_rank: Frequent Contributor
timestamp: May 23, 2024, 05:56:53 am
content: I've been asked to start a new thread on the topic, since this originated in the Magnova scope thread:https://www.eevblog.com/forum/testgear/magnova-oscilloscope/?allQuote from: 2N3055 on May 17, 2024, 07:09:39 amWhich scopes? Certainly not Siglent, unless it's changed since the 2000X+ series.On the Siglent, each history item is a complete capture. There is no overlap between them in terms of time, at least that I've ever seen. If it worked the way I described (for those who haven't seen it, I described it here:https://www.eevblog.com/forum/testgear/magnova-oscilloscope/msg5503027/#msg5503027), then therewouldbe overlap between the history items, and furthermore it would be possible to zoom out within a history item such that other trigger events would become visibleeven if the original time range covered by the history event's capture was smaller than the total size of memory. Moreover, one could then zoom way in while the scope is running, see the waveforms updating on the screen in the way one would normally expect (with persistence and everything), stop the scope, and then examine the history items, replay them, etc., just as we can do so now, but with the added advantage of being able to zoom way out from within each history item to see what surrounded it. There would be no need for a "search", because the trigger events would have already been recorded and become part of the history.In essence, the entirety of memory becomes your capture buffer, and trigger events are then just pointers to locations within it, and history items are merely trigger events as well.No scope I know of implements things in quite that fashion. History items, in particular, seem to be coupled to some predefined time length (whether the result of the timebase selection, or the predefined capture buffer size divided by the sample rate). The way you tell is that if it implements it as I describe, then the time distance between history items can besmallerthan the time width of the screen as it was when the trigger fired. I know of no scope for which that's true.QuoteThenwhy can't you zoom out from within any history item and see other trigger events from within that zoomed out view of the history item? At least, I've never been able to do that on any of the scopes I have (including my 2104X+).QuoteThat presumes that processing of data can't happen in parallel with the triggering mechanism. I'm skeptical. The main issue I see with this is parallel memory access.If I'm not mistaken, the trigger re-arm time isalwayslonger than the amount of time represented by the capture buffer. And if that's so, then that proves my point. What I describe decouples things such that the trigger re-arm time is essentially a constant, just long enough for the scope to reset the hardware associated with the triggering mechanism (e.g., registers and other things that are used in the FPGA logic), record the event time and other required items associated with the trigger event, and to, if necessary, resume capturing (presuming that capturing isn't independent of trigger re-arm).QuoteTrue enough. I'll have to play with it with very long capture lengths to see how it behaves and how often it updates under those conditions.

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 11, 2024, 10:10:20 pm
content: Quote from: kcbrown on May 23, 2024, 05:56:53 amYep, that works just as you described, even with very long captures. That proves that the approach I described can potentially work.It occurs to me that the rate at which the trigger point is recorded doesn't have to keep up with the rate at which the trigger fires. When necessary, the trigger points can be "backfilled", with the history mechanism built from recorded and backfilled trigger points. The trigger point recording just has to fire often enough to keep the display processing mechanism happy and reasonably accurate (for things like glitch display and such).Now, I should note that you obviously want the option of limiting your capture size, not for the purpose of determining how long the trigger delay is (that's a separate setting), but rather so that if the delay between trigger firings is longer than what you're interested in, then you can ensure that the capture memory isn't used up needlessly by waveform data you'd have no interest in. So you'll want to be able to define the maximum width of a capture. To make sense, the width of a capture when defined like this would have to actually be some integer fraction of total capture memory.What would the history look like if you use that mechanism? No different than it would if you used the entirety of memory for a capture, save for one thing: the degree to which you could "zoom out" from a given history event trigger point would be limited by the capture size. You could still have multiple trigger events per capture, and thus multiple history events per capture, and the history mechanism would still simply switch you between views of a given capture. The difference is that instead of a single large capture in which all history events are contained, you'd have multiple captures in which those events are contained.

author: nctnico
author_rank: Super Contributor
timestamp: June 11, 2024, 11:04:42 pm
content: One thing you need to keep in mind is that history mode is often of limited use. Doing analysis, decoding, search through a bunch of acquisitions in the history / segmented buffer is often harder or impossible compared to having a single, long capture. Abilities differ vastly between oscilloscopes and there is little functional overlap amongst manufacturers. For example: Keysight is the only manufacturer (I know of) which supports showing a decode table for all segments in the memory (with the ability to hop from one segment to the other based on selecting a row in the decode table). GW Instek OTOH supports doing statistical analysis / measurements over segments in memory. In most cases the segments are treated as seperate, non related acquisitions which reduces the usefullness. You coud get a lot more information if you can do analysis / measurements which spans all or a selection of segments.

author: TomKatt
author_rank: Frequent Contributor
timestamp: June 11, 2024, 11:24:07 pm
content: Quote from: nctnico on June 11, 2024, 11:04:42 pmThis is one reason I think I’d really like to try a Pico scope…. Seems like using the pc for some kind of buffer / storage would allow that kind of flexibility. There’s probably a limit to how quickly you can go for the timebase, but still…

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 18, 2024, 01:45:46 am
content: Quote from: nctnico on June 11, 2024, 11:04:42 pmThat seems to argue in favor of the approach I described, wherein history elements are mere references to trigger locations within captures andnotto captures themselves. What I describe makes history elements a many-to-one mapping onto captures, such that you can have many history elements within a single capture. What you're talking about here is with respect to captures, and the history mechanism in the case you describe is merely a means of reviewing those captures. One reason history mode is of limited use is that in all the implementations I've seen, it's mapped one-to-one with captures. But with a many-to-one mapping, the number of captures you have can be as little as one while the number of history elements will be as many as there are trigger events in the capture. Multiple captures with that kind of architecture would be useful only if you explicitly need uncaptured dead time between trigger events, which can be the case if the time between events is much larger than the amount of time of interest, or so large that a single capture would exceed the memory capacity of the scope.Regardless, I agree, you really do want the ability to perform analysis on all selected or stored captures, not just the one being viewed, as you mention.

author: 2N3055
author_rank: Super Contributor
timestamp: June 18, 2024, 09:34:07 am
content: Quote from: nctnico on June 11, 2024, 11:04:42 pmTo you buddy. To you.People don't use scopes only for decoding. Point in fact, many don't use them for decoding at all.Picoscope can decode across the previous triggers and segments. Also can do DeepMeasure over previous triggers.Siglent can do statistical analysis across History. And also can search across the History for various analog parameters.

author: 2N3055
author_rank: Super Contributor
timestamp: June 18, 2024, 10:16:16 am
content: Quote from: kcbrown on June 18, 2024, 01:45:46 amYou are talking all the time about single long acquisition that happens in circular, always rewriting buffer (basically FIFO), and then a triggering/tagging engine that keeps a list to "trigger equivalent" places in that buffer.Ok fine, I get that.What is the purpose?If I have such timebase that I have 20 periods on the screen the scope will internally have 20 trigger events just for that single screen. Why? I already have them on screen..What exactly we show on the screen? If I have long (100 MPt) buffer I can have, say, 20000 "trigger equivalent" points inside that buffer. What do I render for screen? Where do I start? What do I show?What do you do with measurements? On what data you do measurements? How do you handle that?Whole point of triggering is to wait for an event in order to ignore irrelevant data or synchronizing waveform display with signal in a way to ensure stable repetitive waveform.This way I can capture for hours to get 10 events I need.With your architecture I cannot EVER have any history of events that are older than what scope can capture in buffer at current sample rate.... Your proposed scope always keep rewriting anything older than certain short time.If you have 5GS/s scope with 250MPts buffer you will never, at any time, have more than 50ms worth of historic data from the moment you stopped the scope.You always have only what is equivalent to single long capture. And what you call "trigger" is simply a search function that finds every "trigger equivalent" place in that capture.

author: Someone
author_rank: Super Contributor
timestamp: June 18, 2024, 11:58:55 am
content: Quote from: 2N3055 on June 18, 2024, 10:16:16 amEnds up being like Lecroy wavescan or other brands "search". Even the baby Siglents have that sort of capability these days.

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 19, 2024, 12:13:30 am
content: Quote from: 2N3055 on June 18, 2024, 10:16:16 amThe purpose of decoupling the trigger events from the buffer like that is performance, flexibility, and (arguably) ease of use.Look at what happens right now. Right now, the scope operates roughly this way:It continuously records samples into the capture buffer, where the width of the capture buffer is at a minimum the points width of the screen (time width of the screen multiplied by sample rate), until a trigger event occursWhen a trigger event occurs, it continues to record samples until it reaches the capture widthOnce the capture width is reached, it processes the data,waits until some amount of processing is complete, andthenresumes acquisition in a new capture buffer.But with what I'm proposing, data is acquired continuously (unless the user has specified that the capture memory is to be split into segments for the purpose of not capturing too much "dead time") until the scope is stopped, and all processing happensin parallelwith that. The trigger exists for the purpose of notifying external hardware of a trigger event and for aligning waveform display operations.I was going to write this up separately, but in light of the above, I think it's a good response to some of the points you raised:Thinking about this further, it occurs to me that with adigitaltrigger system, the only real reason for performing any sort of real-time recording of the locations of trigger events that occur within a capture, aside from the one from which the beginning of the capture is defined (the result of the capture size and the location of the trigger point within it, typically halfway towards the end of the capture), might be for the purpose of updating statistics and updating the display, for the "trigger out" signal, and for optimization of after-the-fact processing. But even for those things, they don't need to berecorded, they only need to beprocessed(or, in the case of the trigger out signal, propagated). The display processing, for instance, has to build what amounts to a 2D histogram at a rate of at most 30 times per second. Other statistics arguably need to be updated at only that rate as well (if that -- a third of that rate would be just fine), since ultimately their purpose is to be displayed to the user.But the implication of that is clear: save for notification of external hardware, the trigger mechanism exists for the purpose of causing the scope to do somethingonlywhen the amount of time since the last trigger event exceeds the display refresh period.Everything else can be determined through after-the-fact processing.This makes the "waveforms per second" metric, when the architecture takes advantage of the above, almost meaningless. Trigger events could be recorded anyway, but doing so would be solely for the purpose of optimization, and the recording mechanism would in principle need to record at most only one trigger event per time width of the display -- everything else could be derived after the fact if necessary. "Waveforms per second" then becomes a measure of how many trigger events can be processed per second for display purposes.Oddly, though, this argues in favor of many of the characteristics of current approaches, more or less, with one caveat: current approaches don't allow for a fast update rate of the display when the display is showing a relatively short period of timewhen the capture buffer is far larger. They force you to choose between the two, between a fast display update rate and a large capture buffer. Andthatis one of the primary advantages of the approach I'm speaking of here.To illustrate, suppose your capture buffer allows for a capture of one second's worth of data, but your display is showing one millisecond of time, and the waveform has trigger events within it every, say, microsecond. The approach taken by scopes currently would result in the display updating once per second. The approach I'm proposing here would allow for the display to update as often as 30 times a second (or even 60, if the processing can support it)despitethe fact that the capture buffer is 1 second in length. The display would simply show an aggregate of 1 millisecond frames within the larger capture (with the usual intensity grading and all that). How does this differ from simply setting the time width of a capture to 1 millisecond and letting the history store the individual captures that result? Simple: it allows you to, with the scope stopped,zoom out from the 1 millisecond view all the way to the largest 1 second view, seamlessly. It combines the advantages of a 1 millisecond capture and a 1 second capture. It also makes "history" something that can be shown relative to thecurrentdisplay time width in thesame capture. To illustrate what I mean by that, suppose you've stopped the scope and are viewing one millisecond's worth of time. Flipping to the next history event would then move you to the next millisecond's worth of data in the capture, more or less (this is so because there's a trigger event every microsecond, so there would be 1000 trigger events within the next millisecond's worth of data, one of which will be exactly 1 millisecond after the trigger event that defines the history event you had just been viewing). Now let's say you zoom in so that the time on the screen is 100 microseconds. Flip to the next history event gets you to the next100 microseconds'worth of data in the capture (or, optionally, to the next trigger location even if it's within the current view, which could be more than 100 microseconds away from the current trigger point or even, depending on preferences, present in the current view, thus shifting your view by one microsecond). Again, this is so because there's a trigger event every microsecond. History, here, simply becomes a way of paging through the data, with one difference from scrolling through the capture: the history viewing mechanism is relative totrigger events, not just time. This is different from simply scrolling through the waveform (which you can also do) because it's oriented around trigger events.To illustrate the difference, suppose that within the above capture there's a section where no trigger occurred for, say, 10 milliseconds. In that case, flipping from the last history item that immediately precedes the gap to the next history item would take you to the first trigger event after that gap, while scrolling through the waveform obviously would force you to scroll past the gap manually to get to the next trigger event.QuoteYou might have them on the screen but that doesn't guarantee that they're obvious to you just by looking at the waveform. That depends on the trigger parameters. Even so, something indicating the trigger points is something you'd want control over.QuoteHow much of the buffer are you showing on the screen? All of it? If all of it, then obviously you could only show a subset of the trigger points. How much you can show, and how it would be presented, depends on the view you're showing of the capture.QuoteIt dependsa loton whether the scope is stopped or is running. A running scope imposes far more constraints on the measurements that can be performed than a stopped scope. A stopped scope can update the measurements on the basis of all recorded points, while a running scope almost certainly requires decimation of the points.QuoteI don't see how my proposed approach conflicts with that.QuoteThat remains the case even with the approach I mentioned, because: "Now, I should note that you obviously want the option of limiting your capture size, not for the purpose of determining how long the trigger delay is (that's a separate setting), but rather so that if the delay between trigger firings is longer than what you're interested in, then you can ensure that the capture memory isn't used up needlessly by waveform data you'd have no interest in. So you'll want to be able to define the maximum width of a capture. To make sense, the width of a capture when defined like this would have to actually be some integer fraction of total capture memory."But even that might not be sufficiently flexible. This is so because specifying the capture size in that way means that you're artificially limiting the length of your capturefrom the time of the first trigger point in the capture, while you might well need to, instead, specify the maximum amount of "dead time" after thelasttrigger point in the capture. See below for an example of why you might want to do this.Rather than breaking up memory into equal-sized segments, it may make more sense to capture sections of trigger activity, even if they're of varying sizes.QuoteThat's trueonly if you set the capture buffer to span the entirety of memory. But as I mentioned, you don'thave todo that. It's clearly advantageous to be able to specify capture buffers that are smaller than the entirety of memory, precisely because you want to account for the possibility of long periods between trigger events.There are situations in which you want to be able to see, in "real time", a small but continuously updating subset of the entire capture, and youdon'tknow in advance how long your capture needs to be in order to get everything of interest. A serial decoding session of something that is emitting messages of arbitrary length at arbitrary times might be a good example of this. I ran into a situation like this when I was examining the SPI bus used by a computer for fetching data from the BIOS. I was forced to either perform a single capture of a long period of time, or to perform multiple captures where each was of a fixed width, when the nature of the data I wanted to capture was that it had bursts ofarbitrary lengthactivity with arbitrary amounts of dead time between each burst. That presents a situation that no scope I'm aware of can deal with properly. But the architecture I'm proposing can.

author: 2N3055
author_rank: Super Contributor
timestamp: June 19, 2024, 06:36:22 am
content: Quote from: kcbrown on June 19, 2024, 12:13:30 amIt is hard for me to understand how you don't see contradictions in your own explanations.Let me try to explain through practical examples.1. You have bursts of data 10-35 µs in length coming in every 100ms to 2 sec. You have 100 Mpts scope memory. Scope is sampling at 1GS/s. Make note that per your request, you have no knowledge of data beforehand. How many packets of data you can have in memory at any time?2. You have bursts of data 10-35 ms in length coming in every 100ms to 2 sec. You have 100 Mpts scope memory. Scope is sampling at 1GS/s. Make note that per your request, you have no knowledge of data beforehand. How many packets of data you can have in memory at any time?3. You have bursts of data 10-35 µs in length coming in every 100ms to 20 sec. You have 100 Mpts scope memory. Scope is sampling at 1GS/s. You setup scope and let it run. You go to lunch.Make note that per your request, you have no knowledge of data beforehand. How many packets of data you can find in memory at that time?4. You have bursts of data 10-35 ms in length coming in every 100ms to 20 sec. You have 100 Mpts scope memory. Scope is sampling at 1GS/s. You setup scope and let it run. You go to lunch.Make note that per your request, you have no knowledge of data beforehand. How many packets of data you can find in memory at that time?

author: Someone
author_rank: Super Contributor
timestamp: June 19, 2024, 11:23:21 am
content: Quote from: kcbrown on June 19, 2024, 12:13:30 amThen you'll need to explain it better, instead of a wall of text describing things it will solve but not how it will do that in a new way.There are already scopes where you can adjust the memory depth of the segments (i.e. change the number of segments/history pages while keeping the total memory use maximised) from 1 to some arbitrary high number.Maintaining a continuous recording (a la digitiser) falls apart because few scopes have human scales of recording in memory at the full sample rate. Scopes are triggered for a reason. When sample memory is 10x higher than sample rate then it might appear as a feature.

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 20, 2024, 09:22:59 pm
content: Quote from: 2N3055 on June 19, 2024, 06:36:22 am100 Mpts of scope memory at 1GS/s gets you 100 ms worth of memory at that sample rate. If you have no options save for performing a single capture then, with the bursts coming in every 100ms to 2 seconds, clearly you'd only get one burst.But I'm not arguing that the architecturemustuse the entirety of memory for a single capture. As I said previously:Quote from: kcbrown on June 19, 2024, 12:13:30 amSo let's suppose that the mechanism I describe above is in play. How many bursts you can capture depends on the capture termination conditions and the signal characteristics. Let's suppose that the data is an active high signal with a maximum high time of 1 us, so just to keep things safe you define a capture termination condition of 10 us after the last trigger (meaning: if 10 us elapses without the trigger firing, the capture stops and the scope prepares to gather a new capture in the remaining memory). You also define the maximum amount of capture prior to the capture's trigger to be 10 us, using whatever mechanisms are appropriate for that. So the capture will contain 20 us of padding plus whatever the length of the burst is. Now each capture ranges between 30 us and 55 us in length. With 100 ms of capture memory, that amounts to a minimum of 1818 captures, and (if all bursts happen to be of 10 us duration) a maximum of 3333.QuoteNow the bursts are 3 orders of magnitude longer. Let's suppose that the maximum high time is now 1 ms. Knowing that you have limited memory, you have to compromise on your capture start and termination conditions, so let's suppose you give it 5ms before and 5ms after, for 10 ms worth of padding. If you can't change your sample rate then that'll give you captures of a duration somewhere between 20 ms and 45 ms, so now you get somewhere between 2 and 5 captures.QuoteThe answer here is the same as the answer to your first question.QuoteThe answer here is the same as the answer to your second question.

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 20, 2024, 09:36:28 pm
content: Quote from: Someone on June 19, 2024, 11:23:21 amPerhaps my last reply to 2N3055 will help clarify things somewhat.QuoteYes, there are. Butall of themdefine the screen refresh period (when the trigger fires often enough, of course) on the basis of thecapture size, not thedisplayed time period. Some scopes (like most Siglent scopes, save perhaps for the most recent models) define those two things to be the same.QuoteThat 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 oroptionallythe 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.Perhaps another way of saying it is: the waveform update rate should beindependent of the capture size.Maybe I can illustrate my point with a question: suppose you're looking at an SPI bus signal, you've got the display zoomed in so that it's showing a single decoded value, and your trigger is set up so that it fires for every value. How often will your display refresh to show a new value, and how many such values will you acquire in a single capture? What will happen to the waveform data between displayed values?What you want tosee in real timeand what you want tocaptureare not necessarily the same thing.

author: Someone
author_rank: Super Contributor
timestamp: June 20, 2024, 10:04:28 pm
content: Quote from: kcbrown on June 20, 2024, 09:36:28 pmPerhaps start with getting the terminology correct. Displays/screens refresh at their own rate (generally some video standard like 24/25/30/50/60Hz) and is basically disconnected entirely from triggering and waveform memory.Quote from: kcbrown on June 20, 2024, 09:36:28 pmBased on your new explanation above this is all getting even more inconsistent:Quote from: kcbrown on June 20, 2024, 09:22:59 pmSo you say you want the segments independent of triggers, yet they should be only from triggers + some additional padding before ... and after some definition of "idle".That padding might be some novel feature but it sounds rather complex to implement and produce a useful UI for that isn't confusing.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.Quote from: kcbrown on June 20, 2024, 09:36:28 pmTechnically/literally/mathematically/physically impossible.Quote from: kcbrown on June 20, 2024, 09:36:28 pmThat depends on so many variables its impossible to answer (many of those are hidden or stochastic! and can only be determined by testing thespecificapplication).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"Well, that's because it would need to double/duplicate various parts of the system for this imagined need. Just usetwoscopes if it's that important to have both high waveform update rate, and a continuous/wide acquisition of the same events.

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 20, 2024, 11:03:01 pm
content: Quote from: Someone on June 20, 2024, 10:04:28 pmApologies. I meant displayupdaterate, i.e. the rate at which what the display is showing is updated.QuoteI didn't say I want the segments to beindependent oftriggers, I said I want to remove the1:1 mapping between the two. Quite obviously, a segment should containat leastone trigger event and should be generated as a consequence of at least one trigger event.QuoteThe padding before is something we can already define in scopes currently, and usually get by default: it's all the captured points that precede the trigger that the capture is oriented around.It's the padding afterwards that we can't currently define in the way I described. Right now that "padding" is defined relative to thefirst trigger event in the capture, and what I'm suggesting is that it be optionally defined relative to thelasttrigger event in the capture.QuoteComplex 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".It does mean that captures would then be variable length, whereas right now their length is predefined. How much of an effect would that have on current implementations? I simply can't say.QuoteBecause thatpresumes I knowwhat 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 ofeverycapture 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?QuoteReally?If my display width is 1 millisecond, my capture length is 100 milliseconds, and my trigger firing rate is every microsecond, why can't I update the display every 17 milliseconds by shifting the display's time position within the capture by 17 milliseconds (there's clearly no need to update it every millisecond. 17 milliseconds corresponds to 60 Hz), and have the usual intensity grading on the basis of the prior 16 milliseconds worth of waveform? What's technically/literally/mathematically/physically impossible about that?What's technically impossible about the trigger firingeverytime its conditions are met (after the minimal re-arm period, of course), irrespective of the capture size or the display width, and having it activate the external trigger-out line each time? This already effectively happens for the frequency counter, so clearly that it fires doesn't automatically imply that it has to be used for everything it could be used for, right?QuoteYes, whycan'tit? That question is the fundamental basis of all improvements. That, of course, doesn't necessarily mean that what I'm suggesting is possible (though I don't see how/why it isn't), but if it truly can't do both at the same time, then it would be helpful to know why.QuoteWhat 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.QuoteThat's certainly one approach to some of it, but it doesn't address the problem of what to do when you need variable-length captures. It doesn't address my SPI bus example.

author: Someone
author_rank: Super Contributor
timestamp: June 20, 2024, 11:37:03 pm
content: Quote from: kcbrown on June 20, 2024, 11:03:01 pmThen 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"how hard can it be?"Design your own scope and get back to us on that.Quote from: kcbrown on June 20, 2024, 11:03:01 pmNot 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 pmCapture/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 pmBecause 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 pmWithout realising, you've asked for not one but severaldifferentthings. 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 wantother peopleto 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.

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 21, 2024, 01:48:16 am
content: Quote from: Someone on June 20, 2024, 11:37:03 pmIdidsay that plainly:Quote from: kcbrown on June 20, 2024, 09:36:28 pmBut, 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 untilafterthecapturecompletes, at least for the purpose of the waveform updates and trigger out mechanism.QuoteI suspected that would be coming next.I would if I could. But note that saying "design it yourself" isnotthe 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, whyhasn'tit 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.QuoteYes, they do, with current implementations. Nowwhymustthat 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 areanalogscopes for which thatistrue.QuoteWhat 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 pmZoom 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 whymostscopes are implemented such that the capture widthexceedsthe display coverage, i.e.they make limited zooming out possible by default.QuoteAgain, I must reiterate that I amnotcomplaining 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 canlearnthose disadvantages.QuoteCuring my ignorance isexactly whyI brought this whole thing up in the first place. I tossed the idea out in order to see what'swrongwith 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. Icanlearn from statements that show with specificity what I'm ignorant of.QuoteI'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.

author: Someone
author_rank: Super Contributor
timestamp: June 21, 2024, 02:16:49 am
content: Quote from: kcbrown on June 21, 2024, 01:48:16 amWhich is inconsistent with what you already stated:Quote from: kcbrown on June 20, 2024, 11:03:01 pmA 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 amHow 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 amQuote from: kcbrown on June 21, 2024, 01:48:16 amSo 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.....

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 21, 2024, 07:56:55 am
content: Quote from: Someone on June 21, 2024, 02:16:49 amPerhaps 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.

author: tautech
author_rank: Super Contributor
timestamp: June 21, 2024, 08:46:17 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: June 21, 2024, 09:44:39 am
content: Quote from: 2N3055 on June 18, 2024, 09:34:07 amYou are stuck in dealing with repetitive signals while overlooking the fact that when dealing with circuits containing a microcontroller or other digitial chips, things happen in a sequence which can span many seconds. A very nifty feature of my Tektronix logic analyser is the ability to do segmented recording but contrary to a DSO, it will show the segments on a single timeline (*) instead of overlapped on top of eachother. I don't recall a DSO which can show the recorded segments on a single timeline. This would be extremely handy for dealing with sequential events. Keysight allowing to show protocol decoding results across all segments is the feature which comes closest to having segments on a single timeline that I have seen on a DSO. When using a DSO I typically use roll-mode for looking at sequential events but the samplerate becomes very low and details may be lost (which then need to be measured seperately and thus taking more time).* The user has a choice to show the dead-time between the segments or just stick the segments together. However, cursors will still show the correct relative time.

author: 2N3055
author_rank: Super Contributor
timestamp: June 21, 2024, 10:16:15 am
content: Quote from: nctnico on June 21, 2024, 09:44:39 amMe stuck? LOL, that's rich coming from you ...Scope is not one show pony. It has to be useful for repetitive and non repetitive signals, slow and fast ones, etc etc...Showing segmented captures in single timeline is just display mode. Where if you have short packets coming in slowly, you get huge "NIL to data" ratios and display that is practically useless. But that kind of display is possible with today's scopes... You show packet, than bunch of placeholder space saying "BLANK" and another packet and so on. It might even be useful as an sort of overview window.... Like the overview window in zoom..Decoding across the segments is something I said is useful before you (I have both Picoscope and Keysight, unlike you) and not in the slightest connected with this discussion.Truth is OP sees one thing he/she/it does and would like scope specifically tailored for that. Same as you.So you sympathise with OP.Except you are reasonable, for you simply a scope that has huge memory that can be fixed separate from timebase and that decodes from whole memory regardless of timebase is a winning combination.Fact that I disagree with you as to that is the only way to achieve that goal, does not distract from the fact that what you want is not unreasonable as it is achievable with today's technology and in fact there are scopes out there that can do it.So I really don't understand what your comment has to do with OP "new way that scope would work".Read carefully what he proposes and you will see that it is ether not a solution to anything, not possible, or as we start asking how to deal with real life examples his answers start converging to fact that he would like a scope with unlimited memory, with segmentation and zero retrigger time, that processes 160GBytes/s in real time for screen, math measurements, masks, counter, etc etc.......And I say to you same as I said him: take a pencil and piece of paper and start sketching HOW you would achieve that. Hint? You won't.

author: nctnico
author_rank: Super Contributor
timestamp: June 21, 2024, 10:29:27 am
content: Quote from: 2N3055 on June 21, 2024, 10:16:15 amThe answer is actually in your face. Look at my avatar picture. That is a USB oscilloscope protoype with 1Gpts/channel (assuming a big enough memory module is fitted) I designed about 20 years ago. Nowadays the amount of memory can easely be a multitude of that using the same concept.Once again, I'm not trying to take anything away. Just add more features. I don't understand how more features can ever be bad.

author: 2N3055
author_rank: Super Contributor
timestamp: June 21, 2024, 11:33:43 am
content: Quote from: nctnico on June 21, 2024, 10:29:27 amI know what you designed. It has nothing to do with what OP speaks about. Nobody said your design wasn't good.I said try to sketch what HE proposes. Not that you cannot design classic scope of your own design.

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 22, 2024, 01:58:44 am
content: Quote from: tautech on June 21, 2024, 08:46:17 amRight, I realize that the latest models allow for greater flexibility in the capture definition, thus allowing a zoom out.Hopefully my next write-up on this will bring clarity to my thinking here.

author: tautech
author_rank: Super Contributor
timestamp: June 22, 2024, 02:10:56 am
content: Quote from: kcbrown on June 22, 2024, 01:58:44 amNot really.SDS5000X, SDS2000X HD and all 8&12bit models above.Initially SDS5000X was not offered with a Fixed Memory mode but it was added in a later FW.

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 22, 2024, 07:55:08 am
content: Quote from: tautech on June 22, 2024, 02:10:56 amI guess time must be passing faster than I thought. Yeah, those were the ones I was thinking of.How many generations with the current memory management capabilities does that make?QuoteIt's a shame they didn't also provide it for the 2000X+, but honestly, I'm not really unhappy about it or anything. With respect to memory management, about the only thing that would be useful on the 2000X+ that it doesn't already have is a configurable sample rate so that you could get more segments for a given capture time. "What you see is all you get" doesn't generally bother me, particularly given the 2000X+'s excellent zoom mode.

author: kcbrown
author_rank: Frequent Contributor
timestamp: June 28, 2024, 03:10:03 am
content: Quote from: Someone on June 21, 2024, 02:16:49 amPerhaps 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, and define my terms.Capture: a contiguous set of samples acquired from an analog or digital input to the scope, stored in sample memoryCapture buffer: the memory into which a capture is storedCapture width: the amount of time the capture coversCapture window: the range of time covered by the captureDisplay buffer: memory containing the pixel data to be shown on the displayDisplay refresh: an operation in which the display shows the current contents of the display bufferDisplay refresh period: the amount of time between display refresh operationsDisplay sample width: the number of samples the display is configured to showDisplay update: an operation in which the contents of the display buffer are updatedDisplay update interval: the amount of time between display updatesDisplay width: the amount of time the display is configured to showDisplay window: the range of time within the capture (or segment, when the scope is stopped) that the display currently coversEnd of capture: the point in time that the capture terminatesSegment: a recorded captureStart of capture: the point in time that the capture startsTrigger event: the trigger point which actually caused capture initiation (https://www.keysight.com/used/us/en/knowledge/glossary/oscilloscopes/what-is-a-trigger-event-in-electronics)Trigger point: a location within the capture where the waveform characteristics meet the requirements of the trigger configurationTrigger position: the location in the display that the trigger event (or trigger update event) is shown.Trigger update event: the trigger point which causes the display window to shift its viewWaveform update event: the point in time when the waveform data is processed for displayAs far as I know, all current implementations behave something like this:1. The scope continuously records sample points into the current capture buffer unless stopped. The current capture buffer is treated as a circular buffer for this. Other available sample memory outside of the current capture buffer is not used for the current capture. Save perhaps for one-shot operation, the capture buffer can be at most half of sample memory (the other half is needed to store the prior capture in case the scope is stopped while acquisition is still happening and no trigger event has occurred since the last capture) or a smaller subset, depending on whether or not segments are in use.2. When a trigger event occurs, the start of capture is recorded. At this point, the capture window is known and well-defined.3. If segments are in use and the current capture buffer is filled and contains a trigger event, the oldest segment is thrown away and its sample memory is used for the purpose of continued acquisition.4. The display window is generally centered within the capture (when it is smaller than the capture. Most Siglents by default have the display window and the capture window the same, thus yielding "what you see is all you get"), though its actual position in the capture can be altered via the trigger position. Regardless of its positioning, its position is fixed on at least a per-capture basis until the scope is stopped (I think some scopes will throw away all the prior segments if the trigger position is changed while the scope is running).5. The start of capture is a predetermined point preceding the trigger event, half of the capture width prior to the trigger event6. The end of capture is a predetermined point in time following the trigger event, half of the capture width after the trigger event7. When the end of capture is reached, the capture is recorded (when segments are in use, which is always the case for Siglent scopes), statistics updated, etc.8. The display always shows a single subset of time within the capture (in Siglent scopes, the default is that the display width and the capture width always match, such that changing the display width changes the capture width)9. The display isn't updated until, at a minimum, the capture has completed10. When the scope is commanded to stop, the scope ceases acquisition immediately if no trigger event has occurred since the last capture, or if a trigger event has occurred, can (depending on implementation) continue to record samples into the capture buffer until the end of capture is reached, at which point acquisition ceases.11. When the capture width is smaller than some fraction of the display update interval (for this it could be, in principle, as much as half of the display update interval), the capture is processed such that the portion that intersects the display window will contribute intensity towards the final displayed waveform. In this case, when the display update interval is reached, the processed data from all processed waveform portions of prior captures and the current capture will be written to the display buffer.12. When the scope is stopped, it shows the latest capture. If segments are in use, then prior captures can be reviewed. Movement and zoom within a given segment can be done. No scope I'm aware of makes it possible to view contiguous captures as if they were a single capture, but the standard architecture doesn't prevent that.13. Decoding and other such operations occur at the segment level.The approach I'm suggesting involves two different cases:A. When there are no capture termination conditions definedB. When there are capture termination conditions definedFor case A:1. The scope continuously records sample points unless stopped.The entirety of sample memory is initially used. Memory is treated as a circular buffer. If a trigger point has been seen and the scope exhausts sample memory, then the half of sample memory containing the trigger point at its center is made unavailable to the acquisition mechanism, with the rest being treated as a circular buffer. This is to ensure that if the scope is stopped, at least one trigger point and its surrounding samples are retained.2. The display window is a conditionally shifting view of the contiguous samples. It shifts whenever one of these conditions happens, whichever occurs thelongestamount of time since the last display window shift:a. A trigger update event occurs, meaning the trigger conditions are met by a portion of the waveform that is at least a display window's width later than the currently viewed trigger update event, and there is enough waveform data to fill the remaining part of the shifted display window after the trigger update eventb. The display update interval passesc. The display width period passes (I'd previously been thinking about making this optional, so that the window could shift to the next trigger point regardless of the display width, but intensity grading with that, when the trigger point interval is less than the display width, would yield a confusing display, so I'm abandoning that idea).3. When the display window shifts, it shifts so that its left edge is located at or after the prior location of the right edge of the display window, such that the latest trigger update event is located at the trigger position.4. The display window shift will cause all (or some subset, if the scope lacks the horsepower to process all) prior valid window-sized non-overlapping sections of sample memory between the right edge of the prior display window and the left edge of the current display window to be incorporated via intensity grading into the current display. A "valid section" here means one that contains a trigger point located at the trigger position within the section.5. When the scope is stopped, acquisition ceases and the display shows the last display window it has on hand or, if there is no such window (meaning the trigger conditions were never met anywhere within sample memory), the beginning (in terms of time) of sample memory.6. When the scope is stopped, movement within sample memory is possible just as it is within a capture of a standard scope. But now, history is not a list of segments, but instead is a list of trigger points within sample memory, and reviewing history means moving between those trigger points, which means placing the trigger point under review at the trigger position and showing the acquired samples around it.7. Alternatively (and something I'd prefer to be configurable), moving to the next history item would mean moving the display window to whichever trigger point follows the current one and which places the left edge of the display window at or after the current right edge of the display window. Zooming out and moving between history items would result in more movement of the display window each time one moves to the next history item.8. Alteration of the trigger conditions when the scope is stopped would result in the regeneration of trigger points found in sample memory and, thus, history that can be reviewed. This makes is possible to use the existing acquisition to test trigger definitions.9. Decoding and other similar operations occurs over the entirety of sample memory, at least when the scope is stopped, unless per-segment decoding is desired.Case B is identical to case A save for:1. When the capture termination conditions are met, the sample memory from the start of the current capture to the current sample is saved and acquisition resumes into the remaining sample memory. The capture termination conditions can include a predefined time after the first trigger point seen in the capture, a predefined time after last trigger point seen in the capture, the right edge of the window, a predefined time after start of capture, a predefined time after start of capture when a trigger point exists in the capture, and perhaps others. The idea here is to make it possible for this mechanism to yield behavior identical to traditional scopes, but to also give greater flexibility than that.2. When acquisition memory is exhausted, the memory from the oldest segment is reclaimed.3. Until a trigger event occurs, the amount of memory used for the current capture will not exceed the time distance between the left edge of the display window and the trigger position.4. When the scope is stopped, acquisition ceases immediately unless a trigger event was detected, in which case it continues until at least the right edge of the display window before stopping.5. Moving to the next history event can involve moving to the next segment, not merely remaining in the current segment.There are surely some problems that I haven't considered in coming up with the above, and some of them might well be fundamental, and perhaps even fatal. It's one of the reasons for putting this here.