Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[Martin72]

Uh, so much text in the last posts...
So what is now the bug in short form ?

[casterle]

There turn out to be multiple things that cause the history to get nuked.  Just moving the waveform up or down will do that, as will shifting the trigger point.

Do I understand correctly that merely adjusting the position of the displayed waveform nukes history?

[2N3055]

No, I keep repeating scope already can do that in superior way with no redundant (overlapping)data.
You capture the lot, full 100 ms of it, and use search to find all of the points that you would usually trigger on.
Also I nowhere mentioned trigger delay. If you fit whole event in a screen, by using proper timebase for it, you can set trigger point in reference to where in capture buffer it will be. So on a trigger event you get 20ms of data, 10 before and 10 after the trigger.. It is all visible on the screen and clearly defined. No need for mental acrobatics...

You have to decouple in your mind sampled data buffer and viewpoint (zoom). Once you have buffer you can zoom in and traverse anywhere in the buffer..

Also scopes do all kinds of tricks managing the memory, both in hardware and in software, and between separate buffers, not necessarily in same memory space or even physical chips . To make it deterministic and as fast as possible, not all kind of buffoonery is realistically possible.

Zoom mode should be designed to be as efficient and ergonomic as possible. Maybe a bit more control of screen use.

History mode should be made to better retain useful data.
Some data should not be retained in history, maybe, user might not want to keep old data after they changed some settings, because it makes old captures not something comparable with new ones. Or it can be left to user to choose.

Enhance history/segemented buffer handling analysis.

Enhance search.

Etc etc.

No need to invent arcane contraptions to fix usability problems stemming from some features not being fully or most elegantly implemented. Most logical, easiest correct way is to fix/upgrade those to full potential of architecture. Otherwise you end up with spaghetti monster that is confusing and does nothing right.

[kcbrown]

There turn out to be multiple things that cause the history to get nuked.  Just moving the waveform up or down will do that, as will shifting the trigger point.

Do I understand correctly that merely adjusting the position of the displayed waveform nukes history?

You do indeed.

[kcbrown]

No, I keep repeating scope already can do that in superior way with no redundant (overlapping)data.

Sure, it can.  But the downside is that, firstly, the waveform update rate is now limited by the time width of the capture and, secondly, you now need two independent trigger identification implementations in order to see all of the trigger events one of which (search) only has access to decimated data and thus could easily fail to see trigger events that were actually present.  That you need two completely different trigger detection implementations is, in part, why the search is a very small subset of the trigger set -- it requires that much additional effort to implement.   The only real upside to having a trigger event search is that it makes it possible for you to look for trigger events that differ in their characteristics from the trigger setup that resulted in the capture.

You capture the lot, full 100 ms of it, and use search to find all of the points that you would usually trigger on.

That's not necessarily good enough.  Search only has access to decimated data.  The trigger mechanism has access to the full sample rate of the scope at all times.  The two are not comparable except by chance.

Also I nowhere mentioned trigger delay. If you fit whole event in a screen, by using proper timebase for it, you can set trigger point in reference to where in capture buffer it will be. So on a trigger event you get 20ms of data, 10 before and 10 after the trigger.. It is all visible on the screen and clearly defined. No need for mental acrobatics...

Nothing prevents that from remaining the case.  In the implementation I outlined, the trigger point, by its position, guarantees the minimum amount of data that will be captured before and after any given trigger point.  It still has the meaning one would expect.

The difference is that the implementation I outlined ensures that the scope will save all of the trigger events that the trigger system is capable of seeing irrespective of your timebase setting.  Save for the additional memory that the pointers would need (and that could be considerable), I see no downside to this in principle.

I mentioned the trigger holdoff because right now, the trigger re-arming mechanism has an implied holdoff based on the time width of the screen, and my proposed implementation does away with that.

You have to decouple in your mind sampled data buffer and viewpoint (zoom). Once you have buffer you can zoom in and traverse anywhere in the buffer..

I do decouple that.   In the implementation I outlined, a capture is just a contiguous series of samples that are bundled into a single entity.  Its beginning is defined by the left edge of the screen and the trigger point.  Its end is defined by the right edge of the screen relative to the first trigger event in the series that had a time delta between it and the subsequent trigger point greater than the amount of time between the trigger point definition and the right edge of the screen.   The capture is an internal representation.

For presentation purposes, the manufacturer would have a couple of options.  He could arrange things so that the history always shows the same size segments as it does right now, and moving to the next history entry just has the effect of showing that subset of the capture that the screen defined at the time of capture.  The only difference between the current implementation and this is that, for the implementation under discussion, the time delta between two subsequent history events could be much smaller than the screen time width as it was at the time of capture, while the current implementation imposes the screen time width as the minimum time between history events.

Or the manufacturer could (and I would argue should, given the data the system would make available), make moving to a new history frame show you the portion of the waveform on the screen relative to that trigger event in the history frame, but instead of limiting the data in the frame to that which was represented by the screen's time width at the time of capture, it would allow you to see the entire capture if you zoom out enough.  Which is to say, if the capture itself occupies more time than what the screen's time width at time of capture was, then you should be able to see everything in it if you so choose, or zoom in to any part of it, as you so choose.  Your position in the history list would then be dictated by which capture you're looking at and where your view of the capture is relative to a history event, and you should be able to move between history events (really, recorded trigger events) either by moving within the list or by moving within the capture, as you see fit.

Also scopes do all kinds of tricks managing the memory, both in hardware and in software, and between separate buffers, not necessarily in same memory space or even physical chips . To make it deterministic and as fast as possible, not all kind of buffoonery is realistically possible.

Oh, I'm quite well aware of that.  I don't claim that what I'm proposing here is possible without faster hardware.  On that, I simply can't say.

Zoom mode should be designed to be as efficient and ergonomic as possible. Maybe a bit more control of screen use.

History mode should be made to better retain useful data.
Some data should not be retained in history, maybe, user might not want to keep old data after they changed some settings, because it makes old captures not something comparable with new ones. Or it can be left to user to choose.

I completely agree.

Enhance history/segemented buffer handling analysis.

Enhance search.

Etc etc.

No need to invent arcane contraptions to fix usability problems stemming from some features not being fully or most elegantly implemented. Most logical, easiest correct way is to fix/upgrade those to full potential of architecture. Otherwise you end up with spaghetti monster that is confusing and does nothing right.

You'd certainly need to keep things simple and understandable for the user, no question about that.  I don't see why that isn't possible while doing what I described.

Remember: the purpose of what I described is to make it possible to see trigger events that currently go completely unnoticed even though they were present, without sacrificing capture length in the process.  Put another way, trigger events and capture length should be decoupled, and right now they're not.

[kcbrown]

Uh, so much text in the last posts...
So what is now the bug in short form ?

Heh.

Well, two bugs so far.

Firstly, changing the waveform position, volts/div, or timebase, should be smooth as butter.   Right now it's not, and given that the scope stops everything in its tracks when you're doing any of this, I see no reason for it to not be.

Secondly, there are multiple circumstances in which the history buffer is nuked, and it probably shouldn't be.  Why should changing the voltage offset or volts/div nuke the history buffer??  I can think of no good reason for that.  Changing the timebase, sure, I could see some justification for that (lame as it might be), since doing that could change the memory required by a capture.

[Martin72]

Hi,

The second could be a bug, in my opinion.
For the first I wasn´t sure actually, but I´ve seen this behaviour on other scope brands as well.
Check this next year on our lecroy scopes at work.

BTW, still "buggy":

When activating the power analyzer, additional activated channels won´t be deactivated when deactivate this function, instead they remain, you have to turn them off manually.
The same was by using the bode plot - I don´t check this after the new firmware, but when the power analyzer thing is still the same, I think, the bode bug will still remains.
Check this tomorrow.

[kcbrown]

Hi,

The second could be a bug, in my opinion.
For the first I wasn´t sure actually, but I´ve seen this behaviour on other scope brands as well.

It would be interesting to know if, firstly, those scopes also stop visual processing and, secondly and more importantly, whether they stop capturing.  The Siglent does both, and that's why I regard it as a bug.  If you're going to stop everything in its tracks, then you've got the entirety of the scope's processing power available to you for the purpose of handling the control inputs, so why in the world wouldn't it be buttery smooth?

[rf-loop]

Secondly, there are multiple circumstances in which the history buffer is nuked, and it probably shouldn't be.  Why should changing the voltage offset or volts/div nuke the history buffer??  I can think of no good reason for that.  Changing the timebase, sure, I could see some justification for that (lame as it might be), since doing that could change the memory required by a capture.

When you change settings after then all what is already in buffer is not anymore compatible with new incoming ones and so old need reset. Buffer do not include settings. You need know v/div, offset, t/div. If you loose them, what you can measure or what you compare. This is instrument for analyze signals not for record fun figures about smoke what goes inside copper wires and components (and some times smoke leaks out and things stop working).
Thinking helps more than questions. If instrument do not work as imagined instrument,  where is bug.. in this imagined instrument or real instrument. If you do not see reasons you have not think enough and enough wise.
Just one poor very simple example.

You capture unknown signal and it is also filling acquisition buffer. Some time signal have changes, what ever changes, then also you twiddle adjustments as game machine joystic etc. After then you stop scope or it stops due to no trigger.   
After then you go to look history and perhaps start inspect carefully these every wfm in this buffer for look what happen in signal. For every segment (wfm) in buffer fifo you may use automatic measurements, FFT, use cursors, gated measurements and what ever.
Who keep now book about what change in signal is based to your scope settings changes and what are based to signal itself changes. Do you think every single wfm is recorded with setup data header or even every ADC sample. 
Of course all can do but you do not want pay it.
Simple solution is. Buffer include only data where all changes are in captured signal, so every single segment (wfm) is based to same settings and directly comparable, only variable is signal.  It must be so and it is so - until we do something very very different animal.
Of course it can do so that it store continuous wfm with setup data, and if user change anything it must close this already stored data block and then make new block with new settings and after any change, again close this block and start new block with new settings. After then some player or journalist twiddle knobs and start ranting why this and why that...
Professional way to use instrument is first design what to measure and why, then design how to measure/analyze and in tghis point need be familiar with instrumet(s) used for this and then also design how to probe it without destroying signal, how to set scope for it and finally after brain work start moving muscle --- opposite road is... this forum is (partially) full of this.
  Period.

[drwho9437]

Just wanted to thank Siglent for the configurable colors.

I can finally tell channel 4 from channel 1 now. I know this happened in Nov but time off in the holidays let me notice the upgraded firmware version.

[kcbrown]

When you change settings after then all what is already in buffer is not anymore compatible with new incoming ones and so old need reset.  Buffer do not include settings. You need know v/div, offset, t/div. If you loose them, what you can measure or what you compare. This is instrument for analyze signals not for record fun figures about smoke what goes inside copper wires and components.

It may be that Siglent's specific implementation of what is stored demands what you're talking about here, but that's implementation-specific.  Nothing says that Siglent can't store the capture's specific parameters along with each capture, so as to be able to properly interpret the saved data, or store the timestamped capture parameters in a separate list so that captures can be properly reconstructed after the fact.  Nor is there anything that says that Siglent can't simply store the voltage values directly, and a sample rate along with the trigger time, thus bypassing the entire problem (though that, of course, would require a conversion step as part of the primary acquisition loop, something that is likely to be more expensive than it's worth unless it can be pipelined so as to retain the existing throughput).

Thinking helps more than questions. If instrument do not work as imagined instrument,  where is bug.. in this imagined instrument or real instrument. If you do not see reasons you have not think enough and enough wise.
Just one poor very simple example.

Perhaps.  But at the same time, just because a given implementation doesn't do something doesn't automatically mean it can't or shouldn't do something.  And neither does it mean that a different implementation would have the same limitations.  All we see as users is what the scope presents to us.  How exactly are we supposed to know that what we believe should be possible is, in fact, not?  We can work backwards from what we see, but in doing so we end up having to make assumptions that aren't necessarily valid.

You capture unknown signal and it is also filling acquisition buffer. Some time signal have changes, what ever changes, then also you twiddle adjustments as game machine joystic etc. After then you stop scope or it stops due to no trigger.   
After then you go to look history and perhaps start inspect carefully these every wfm in this buffer for look what happen in signal. For every segment (wfm) in buffer fifo you may use automatic measurements, FFT, use cursors, gated measurements and what ever.
Who keep now book about what change in signal is based to your scope settings changes and what are based to signal itself changes. Do you think every single wfm is recorded with setup data header or even every ADC sample.

Considering that all you need to record are the screen boundary parameters, the trigger location within those boundaries, and the voltage offset, and considering that most of the time, a capture's parameters will be the same as the previous one's, the amount of overhead represented by the data necessary to properly interpret a capture independently of the other captures isn't exactly overpowering unless you want to be inefficient in how you store it...

I mean, look, at the very least the current history already has to record the time of acquisition.  So you're already recording a capture-specific piece of data for every capture: the trigger time.  Recording the other parameters necessary to reconstruct the waveform isn't a major deal.  As an even better alternative, as you say, you can simply store the requisite parameters into a linked list of such parameters immediately prior to the scope restarting acquisition, along with either a timestamp or a pointer to the last capture (which is the capture immediately before the one it would apply to), and then you'll have everything you need to properly reconstruct the waveform of any history entry.

There are probably lots of things that could be done, some of which represent minimal overhead.  Siglent has chosen to simply nuke the entire history.  While that's certainly the simplest approach, the simplest approach isn't always the best one.

Of course all can do but you do not want pay it.

Perhaps so.  It would certainly be more overhead than what we currently have, admittedly.

Simple solution is. Buffer include only data where all changes are in captured signal, so every single segment (wfm) is based to same settings and directly comparable, only variable is signal.  It must be so and it is so - until we do something very very different animal.
Of course it can do so that it store continuous wfm with setup data, and if user change anything it must close this already stored data block and then make new block with new settings and after any change, again close this block and start new block with new settings. After then some player or journalist twiddle knobs and start ranting why this and why that...

Journalists do that anyway.   There's no escape.   

Professional way to use instrument is first design what to measure and why, then design how to measure/analyze and in tghis point need be familiar with instrumet(s) used for this and then also design how to probe it without destroying signal, how to set scope for it and finally after brain work start moving muscle --- opposite road is... this forum is (partially) full of this.
  Period.

LOL.  True.   

It just seemed like a surprising limitation given the acquisition design of the scope.  But I can certainly see how it simplifies things.  In any case, I'm perfectly happy to call this out as a feature request and not a bug.

Now then: why does it nuke the history when you press the "normal" or "auto" button when the scope is already acquiring with that mode?      Actually, that probably should be regarded as a bug: the scope shouldn't nuke your history just because you change the trigger mode from "auto" to "normal" or even "single", because you're not changing anything about the acquisition mechanism that isn't already being recorded on a per-capture basis.

[kcbrown]

Bug: moving around or changing the zoom level of the zoomed portion of zoom mode, while the scope is running, nukes the history buffer.  Say all you want about the necessity of nuking it when the acquisition parameters change -- there is no good reason at all for nuking it when the zoom mode view of the unchanged acquisition changes.

I also noticed that moving around like that stops acquisition while you're moving around.  That's fine as far as it goes, seeing how it might be necessary to maintain the necessary responsiveness.  But it shouldn't nuke the history as a side effect.   They're probably just using common code for both this situation and the normal un-zoomed situation in which acquisition parameters are changing.  It's still a bug.

[casterle]

Do I understand correctly that merely adjusting the position of the displayed waveform nukes history?

You do indeed.

I've responded in your "Christmas Present" thread, and it was this thread to which I referred.

I can't (don't want to) believe that nuking history like this was a design decision. Surely it's a bug that will soon be no more. Or an oversight that will be addressed. Or a design decision by a junior designer who will be counseled to make better decisions.

I pray it's not a decision forced by the hardware design; this seems most unlikely as automatic history is a major feature (according to Siglent's marketing team, at least). I await clarification from the horse's mouth.

[casterle]

<Interesting stuff removed>

You seem to have a firm grasp of how my new toy handles its buffers. New to the Siglent Way, I need to learn how this works, especially the implications and unwanted/unconsidered side-effects of which I am surely unaware. The manual tells me which buttons to push and little more.

Having pulled what was for me was an expensive trigger, new toy in hand, I seek deep understanding. How did you learn so much about how buffering works? Have you found a tech reference that spells everything out in detail?

Healthy Holidays and a Healthy New Year to You and Yours

[2N3055]

I can't (don't want to) believe that nuking history like this was a design decision. Surely it's a bug that will soon be no more. Or an oversight that will be addressed. Or a design decision by a junior designer who will be counseled to make better decisions.

Well it's your prerogative to have an attitude, no matter how wrong you might be..

What is the use of history buffers?  Something similar to command line history that simply takes historic record of all of trigger events in a past until it runs from the memory?
So it will remember, say, 1000 last triggers, regardless of you switching channels on and off, change timebase, vertical sensitivity and offset.....
So you can twiddle through history buffers, reliving nice memories of probing through your last repair.

Or you might want capture last 1000 triggers captured with exactly the same settings from first to last, so you can compare the data...

History buffers in Siglent are implemented for second scenario.  Think of it as history buffers of current capture session (session being defined as group of captures with exactly the same settings)..

First scenario is not very useful. I could see it maybe useful for documentation, but you could simply keep pressing save button on screens you need and get it that way.

I heard similar argument some time ago when someone was outraged that changing settings clears the screen and restarts when in roll mode...
Not understanding that voltage/time diagram makes no sense when time (x) axis has random values...

Of course, it should clear and restart only if it is currently in RUN mode, or after you press RUN or SINGLE button. If you are in STOP mode (acquisitions stopped), no amount of button twiddling should touch memory.... If it does, that is a bug... You should be able to traverse buffers, zoom in and out, and move zoom window inside each buffer.

Once you press RUN it nukes everything and starts a new session.  It is basically same thing as segmented capture, except scope keeps running normally, and retrigger time is bit slower.

[kcbrown]

I can't (don't want to) believe that nuking history like this was a design decision. Surely it's a bug that will soon be no more. Or an oversight that will be addressed. Or a design decision by a junior designer who will be counseled to make better decisions.

I pray it's not a decision forced by the hardware design; this seems most unlikely as automatic history is a major feature (according to Siglent's marketing team, at least). I await clarification from the horse's mouth.

Seeing how my 1204X-E behaves the same way, I think it's a design decision.   Certain not the best design decision in my opinion (others are welcome to differing opinions on that), but a design decision nonetheless.

[Martin72]

Hi,

The posts of 2N3055 and rf-loops seeming reasonable to me, that this not a bug nor a "design decision".
Only a logical fact.

[casterle]

You capture unknown signal and it is also filling acquisition buffer. Some time signal have changes, what ever changes, then also you twiddle adjustments as game machine joystic etc. After then you stop scope or it stops due to no trigger.   
After then you go to look history and perhaps start inspect carefully these every wfm in this buffer for look what happen in signal.

I didn't expect that history would include associated parameters for frame reconstruction. If so, that would be wonderful but sans the data, don't choose for me. Put up a small warning when displaying history as circumstances dictate, but don't mess with my data!

Need them or not, I don't want training wheels on such a fine vehicle.

[2N3055]

Need them or not, I don't want training wheels on such a fine vehicle.

Well it seems  that you kinda need them... 

Look, you paid lots of money to get something smart and capable.. Now you only need to learn how to use it..
Just take a good look at all the triggering options. Many of those need some thinking up front to setup right.
You'll need take some time to learn it to be able to use it to full potential..

Scope doesn't mess with your data, you are if you're twiddling knobs all the time... History of that is not very useful.

[kcbrown]

<Interesting stuff removed>

You seem to have a firm grasp of how my new toy handles its buffers. New to the Siglent Way, I need to learn how this works, especially the implications and unwanted/unconsidered side-effects of which I am surely unaware. The manual tells me which buttons to push and little more.

Having pulled what was for me was an expensive trigger, new toy in hand, I seek deep understanding. How did you learn so much about how buffering works? Have you found a tech reference that spells everything out in detail?

Keep in mind that the mechanism I described might be close to how the actual implementation works, but doesn't seem to be all that close to it.

I do computer software for a living and have done for the past 35 years.  I learned about things like low level memory handling and such because back when I started, those were things you had to do yourself -- there didn't exist things like automatic garbage collection and such, and even memory protection and hardware page handling was something primarily found in larger machines.  And I've always had a keen interest in the fundamentals of computer operating systems.  Much of what I describe flows from thinking about the problem and how to optimize a solution to it.  Treating memory like a circular buffer and storing pointers to locations within it seems like a logical way to (a) minimize the amount of memory required for both the process of acquisition and for the storage of captures, and (b) minimize the amount of copying that would otherwise have to be done to preserve captures.   But just because that's a logical way to do it doesn't mean it's how Siglent has done it.  In fact, there is evidence that Siglent might actually be copying data out of the active acquisition buffer to save captures into capture storage, meaning Siglent does not merely store pointers or something of that sort.  The evidence for this is the fact that the amount of time between trigger events seems to increase with the amount of memory used per frame when everything else is held constant.  If Siglent were just using a circular buffer approach like I described, the amount of time between trigger events would be unaffected by the amount of memory per capture, since the capture itself would just be a subset of memory written by a continuously running acquisition process.  The fact that increasing the memory used per capture while leaving the timebase alone results in a larger amount of time between trigger events is proof that Siglent is performing some sort of processing of the samples prior to re-arming the trigger.  But why do that processing within the main acquisition loop unless you have to?  There might be other reasons for performing sample processing within the main acquisition loop, but the only one I can think of right now is to save the acquisition off into capture memory.

Operationally speaking, what does seem to be the case is that the delay between trigger events is never smaller than the screen width, even when the trigger event interval is less than the time represented by the screen.  So we can pretty safely say that the trigger mechanism has a minimum holdoff that is imposed and which is based on the screen.


As a practical matter, properly characterizing the scope's behavior is going to require a lot of experimentation.  This is so because the specifics of the scope's behavior is highly dependent upon the scope in question.  There will be a lot of similarities within a family (so, e.g., we can expect the 2104X+ to behave similar to the 1204X-E as regards the foundations), but the presence of some features in one and not the other might profoundly affect the behavior of one versus the other in at least some circumstances.  That said, rf-loop has, as I recall, provided things like block diagrams and such showing how the scope does its thing, and that can provide a lot of insight into what the scope does.  I'll have to search for that.  (EDIT: Hmm...maybe not: https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3361154/#msg3361154)

Healthy Holidays and a Healthy New Year to You and Yours

And to you!

[kcbrown]

Look, you paid lots of money to get something smart and capable.. Now you only need to learn how to use it..
Just take a good look at all the triggering options. Many of those need some thinking up front to setup right.
You'll need take some time to learn it to be able to use it to full potential..

Completely agree with this.

Scope doesn't mess with your data, you are if you're twiddling knobs all the time... History of that is not very useful.

But this, I don't agree with.  It's on the user, not the scope manufacturer or anyone else, to decide whether or not the history is useful and under what circumstances (that said, the manufacturer clearly has to balance the pros and cons of clearing the history under various circumstances since the manufacturer is implementing the history mechanism, the capture mechanism, etc., so the manufacturer has to make a guess as to the usefulness of the history under various circumstances so as to perform that balancing act as best as he can).  As a practical matter, merely moving the trace vertically (i.e., changing the voltage offset of the trace) doesn't seem to be something that of necessity would invalidate the usefulness of the frames that were captured right up to that point.  Maybe you can make a compelling argument for that, but merely asserting it isn't very convincing. 

[kcbrown]

Another bug related to history preservation: moving the cursors while the scope is performing acquisitions will nuke your history.  In fact, just enabling or disabling the cursors will cause this.

It turns out that the history buffer is cleared upon the next acquisition after something like the above.  If it's just sitting there waiting for the trigger to fire (i.e., you're in normal trigger mode and a trigger event hasn't yet happened), then it won't touch the history buffer.

Hitting the "normal", "single", or "auto" buttons will clear the history immediately, however.

[Martin72]

Just don´t move them, while recording...
It´s like in good old times, when you´re taking a record with tape from the radio.
Choose your settings once, then record.

[kcbrown]

Just don´t move them, while recording...
It´s like in good old times, when you´re taking a record with tape from the radio.
Choose your settings once, then record.

Heh, well, yes, you can always try to work around it.

But here's the problem: you can't stop the scope, then twiddle the cursors, then start the scope, without also losing your history.

Which is to say, once you decide you need to move your cursors and then continue acquisition for whatever reason, whether the scope is running while you move the cursors or not, you can say goodbye to your history up to that point.

I can think of no advantage to this, at all.

[casterle]

Well it's your prerogative to have an attitude, no matter how wrong you might be..

What am I so wrong about?

What is the use of history buffers?

Not much if Siglent is going to decide when my data is no longer of use on my behalf. And yes, even if I do all those things that might invalidate old data, the most (and least, come to think of it) they should do is display a small warning along with the history frames. If I screw up, let me figure it out and make corrections. Training wheels neither required nor desired, if you please.

I heard similar argument some time ago when someone was outraged that changing settings clears the screen and restarts when in roll mode...

That wasn't me, and no one's talking about data captured during parameter changes.

I didn't give up traditional full-buffer captures for Siglent's "what you see is all you get" approach easily. Reading these forums I'd come to believe that there were advantages to Siglent's approach, so I bit the bullet.

Today I learned that the feature I didn't want (auto-history), which replaced something I wanted (traditional captures), has been hobbled, perhaps so I don't hurt myself with it. Of course I'm not happy. I'm not saying I would have passed on the 'scope for this reason, but I would have done some more digging first.

Maybe your attitude would be more like mine were you in similar circumstances?

BTW, this discussion of including required parameters with the frame data would be a powerful addition to this fine machine.