Siglent SDS1000X and (MSO) SDS1000X+ series oscilloscopes

[rf-loop]

So many times there is claims that Siglent decode only from display.
If people is not familiar with oscilloscope what use:
What ever acquisition memory length is, it is always same as displayed waveform length on the screen.

Wait.  Just to be clear, you're saying that if you set your time base to 100ns per division, and you have 1GS/s acquisition rate available to you, then your memory length is automatically set to 1400 points and there's nothing you can do to increase it save for setting a different timebase??

Even if you set it up to stop after triggering?

Siglent do not never hide part of acquisition length outside of display window.

So if you hit the "stop" button and then zoom out, you get nothing??


That's, er, interesting if that's the case.

Yes.

Why need stop scope for look whole captured length using zoom out.   In my view, it is a bit clumsy way.
Stop and zoom out, stop and zoom out...  I have so limited time for live so I do not want spend it like this.

No less clumsy than selecting a 50,000 foot view because you're forced to do so in order to see the surrounding context, and then zooming in to see the actual bit of waveform that you triggered on in the first place, i.e. the method that the Siglent forces you to use.

I selected the example I did in order to make a very specific point: the Siglent won't let you zoom out even when there is no additional detail to be gained by zooming in -- it minimizes the amount of memory available to you in a given capture.  And while the method the Siglent uses gets you the maximum number of waveforms possible in the history buffer, that presumes that what you're triggering on is highly repeatable.


The best memory configuration and waveform view is dependent upon what you're trying to do, and those two things (memory configuration and waveform view) are not always best joined at the hip.

Both principles can do same work without any doupt. Both have pros and cons. But both need bit different driving style. Also front-wheel drive and rear-wheel drive car need bit different driving style some times. First, the user must learn and adapt to it. Same we can see in many other things also, example between RPN and arithmetic  calculator. Who have adapted for arithmetic calculator say that RPN is just terrible and useless.

Pretty much.  But the point here is that when you can't select the configuration yourself, you're forced to use a driving style that isn't necessarily optimized for your use case, and indeed may prove quite clumsy.

Perhaps (?) Siglent can add later also manual "force memory length" function - (if there is real need for this)
Personally I have not missed this feature anymore.

I suspect some might be surprised by Siglent's approach here.  The ability to specify the capture length wouldn't be the worst feature Siglent could add.  Indeed, there are some novel ways to specify it that they could add that might prove more intuitive or more appropriate for certain use cases, e.g. rather than directly specifying the capture length in terms of samples, you might instead specify the maximum number of waveforms to capture in the history buffer, or you might specify the capture length in terms of a multiple of the timebase or a multiple of the window size.

Honestly I do not understand all what you say.

But lets's think we have oscilloscope what capture full 14 Msample even when you use 100ns/div time base and samplerate is 1GSa/s.

After you stop this scope, you can zoom out up to so that you can see whole length on the screen or you can zoom. In this case you can zoom out to 1ms/div down to example 5ns/div. In and out just as want and also scroll to what ever position.

But when you run this scope you just see  only  this 100ns/div and rest of captured length is outside display. Visible is 1 part (in this case 1400 sample points) of whole length and unvisible is 99999 part (13998600 sample points) 
Visible time and visual blind time ratio is enormous.


Then stop this scope so that there is this 100ns/div screen visible (1400ns screen width in time). Now you can zoom out, up to 1ms/div, so that whole 14ms is visible.  Just zoom in and out as you want. But, run time you never can see whole length as long as captured lengths is more than screen width.  All are there in run time but you can not see, you are blind for these.  Then you think there may be some intersting and then you stop scope and now you can zoom out or scroll these details what you want.


This kind of oscilloscope you want you can see here. 



Is it now good. It meet  what you want. Now stop and zoom out or in and runtime lot of blind time.
(if some people use Siglent and want emulate this other usual DSO "feature", just cover upper haalf of display with piece of carton) and stop scope.
Now you can do just exactly what you want. You can zoom from 100ns/dif to 1ms/div and see all what was unvisible in runtime.



But let us improve your scope.
Run scope again with same settings.   Now take this piece of carton out. Oh well, now you have scope what you previously want but with extra feature, now you can see also whole captured memory length. We now just add feature to your previous model.
And now it looks like this:

[nctnico]

But I'm bit unhappy if I have scope what can  not show full capture length before I stop it and zoom out.

I remember time when I first meet this working principle. My mind was adapted to work with scopes what only show small portion from acquisition memory.

This really makes no sense other than trying to make something which is bad look better. At short timebases you can see a part of the trace and using zoom mode you can see the same signal at two different timebase settings on DSOs which use full record length. Why would you want to limit the record length to the screen width by default? It actually limits the useability of the scope. For example: there are many cases where I want to scroll to a different part of the signal and that is easier with a fixed (maximum) record length because I don't need to change the timebase for the next capture. Also for decoding you might need more memory to also capture the start of the message even if it is off-screen (but Siglent doesn't do that anyway so why bother).

[kcbrown]

Honestly I do not understand all what you say.

I'll be happy to clarify anything that you didn't understand.  Please let me know what was unclear in my message and I'll explain further.

But lets's think we have oscilloscope what capture full 14 Msample even when you use 100ns/div time base and samplerate is 1GSa/s.

After you stop this scope, you can zoom out up to so that you can see whole length on the screen or you can zoom. In this case you can zoom out to 1ms/div down to example 5ns/div. In and out just as want and also scroll to what ever position.

Right.  14 Msamples with 14 divisions on the scope means 1Msamples per division when zoomed out as far as you can go and still fill the screen, hence 1ms per division.

But when you run this scope you just see  only  this 100ns/div and rest of captured length is outside display.

Yes, until you zoom out, that is what you see.  However, if the nature of the waveform you're interested in is such that it shows best at 100ns/div, then the effect is that you immediately see that which you're most interested in, and can then zoom out or scroll (or some combination of those) to see other parts of the waveform which preceded the trigger point or which followed the trigger point.

Then stop this scope so that there is this 100ns/div screen visible (1400ns screen width in time). Now you can zoom out, up to 1ms/div, so that whole 14ms is visible.  Just zoom in and out as you want. But, run time you never can see whole length as long as captured lengths is more than screen width.  All are there in run time but you can not see, you are blind for these.

That's true until you stop the scope, of course, at which point you can correct for that by zooming/scrolling until you see what you're secondarily interested in (one presumes you're triggering on what you're primarily interested in and have set the scope's timebase to display that in the most suitable way).

Then you think there may be some intersting and then you stop scope and now you can zoom out or scroll these details what you want.

Exactly.

Is it now good. It meet  what you want. Now stop and zoom out or in and runtime lot of blind time.

Well, the blind time and the small history buffer (in terms of waveforms captured) are obviously tradeoffs that you have to be aware of when you're using the largest memory depth available for a single capture.

But let us improve your scope.
Run scope again with same settings.   Now take this piece of carton out. Oh well, now you have scope what you previously want but with extra feature, now you can see also whole captured memory length. We now just add feature to your previous model.
And now it looks like this:

So the Siglent is capable of showing a "zoomed in" portion of the waveform at runtime, so that you can always simultaneously see the entire capture and the portion of interest even while the scope continues to capture waveforms?  If that's the case, then the Siglent's implementation is better than I thought, provided that:

• The "timebase" of the zoomed view is shown (that does seem to be the case here -- excellent)
• The zoomed view can be configured to always show the portion of the waveform that triggered the capture.

If those attributes are not present in the Siglent, then what you're showing is still inferior to the mechanism other scopes use for this particular use case.  But if those attributes are present, then the Siglent's approach is as good as other implementations for this use case, and I'd then have to give props to Siglent for that implementation.  It requires that one understand how the scope works, but that's true of any scope.

[nctnico]

Any DSO (even the 20+ year old ones) with zoom mode (or better put: dual timebase mode) can do that while acquiring data. There is nothing special about that.

[kcbrown]

Any DSO (even the 20+ year old ones) with zoom mode (or better put: dual timebase mode) can do that while acquiring data. There is nothing special about that.

Oh, well, if that's the case, then there's hardly anything to complain about with respect to the Siglent.  It's just "different", not actually worse.

[rf-loop]

Any DSO (even the 20+ year old ones) with zoom mode (or better put: dual timebase mode) can do that while acquiring data. There is nothing special about that.

And many of these, in runtime, least with some time/div settings hide part of acquisition length outside from display and let's take this whole case again and start new turn. In Siglent, always in runtime, display width = whole acquisition length. There is  nothing out of display, never. What is acquired you also can see without stop and zoom out.

[MrW0lf]

Overall I think that well implemented zoom system is better than having some part of wfm hidden. But cannot understand one thing - so does Siglent decode only from zoomed part or from whole wfm (while zoomed!)? Logical would be to have event table for everything and stuff from zoomed part somehow highlighted. So how it is?

[nctnico]

Any DSO (even the 20+ year old ones) with zoom mode (or better put: dual timebase mode) can do that while acquiring data. There is nothing special about that.

And many of these, in runtime, least with some time/div settings hide part of acquisition length outside from display and let's take this whole case again and start new turn. In Siglent, always in runtime, display width = whole acquisition length. There is  nothing out of display, never. What is acquired you also can see without stop and zoom out.

But this is not what I want. I want my DSO to use the full acquisition memory (or the length I have selected) because that is easier to work with. In several cases there will be interesting events outside the screen so it is usefull to be able to scroll left/right. In some cases you'll even need that data. Think about looking at an edge somewhere in a decoded data stream (for example where I2C SDA switches from input to output on a slave device). I don't care about the start but the protocol decoder will need the beginning of the message to decode it properly.

[znroot]

Yes I think that should be the best mode to acquire signal because I often want to see signals out of the screen to check things or simply to move the signal's segment to decode.
So no matter how the decode work but the scope should always acquire to fill the memory.

[MrW0lf]

But this is not what I want.

I do not understand what is the problem with "zoom logic" - you just set time/div for example at 5ms/div, zoom in 1000x, this will give 5us/div effective (or any other combo). Scroll back forth all day long stopped or live. Only potential problem is that cheap DSO w tiny screen you lose vertical pixels if zoom overview is shown. Not so much problem with PC based scope and 4k screen But thats all tiny nuances, cannot see any fault with general logic.
Moreover, if use other logic - hide some part of wfm - and my favorite autom. measurements are enabled... what if there is some nasty crap going on in hidden part that will force wrong reading to auto measurement. User would never suspect...
BTW since GWI has option to use full mem on all timebases, maybe nctnico post some pics of his use cases in GWI 2000 thread? Otherwise all same talk goes in circles.

[kcbrown]

But this is not what I want. I want my DSO to use the full acquisition memory (or the length I have selected) because that is easier to work with. In several cases there will be interesting events outside the screen so it is usefull to be able to scroll left/right. In some cases you'll even need that data. Think about looking at an edge somewhere in a decoded data stream (for example where I2C SDA switches from input to output on a slave device). I don't care about the start but the protocol decoder will need the beginning of the message to decode it properly.

There's always the possibility that there are interesting events outside the capture buffer.

Ultimately, I think how workable the Siglent approach is depends greatly upon how easy it is to use the zoom view.  If it's as easy to get around that, to change the zoom window settings, etc., as it is to use the primary view, especially as regards multiple traces and the like, then the only real difference is the amount of vertical real estate you'll have during capture.

Moreover, Siglent's approach gives you much finer control over the size of the capture buffer compared with other scopes, since it's guaranteed that the amount captured is the amount shown on the screen (in the unzoomed portion if one is in zoom mode) -- the buffer size setting puts a cap on that, and the scope will adjust the sample rate accordingly.  And finally, Siglent's approach makes it obvious, once you're aware of how it works, exactly how much time will be captured in the buffer.  This is in sharp contrast with the way most other scopes work, where what you're working with is the number of points in the buffer and you have to work backwards from there in order to arrive at the amount of time the capture buffer represents (and even that is variable since the buffer remains the same size even if you change the timebase).

Make no mistake: while Siglent's approach is certainly different from most, it does have its advantages. 

Note that you can set the size of the sample buffer, so you can control the minimum number of waveforms that are captured.

[nctnico]

Try and use it and you'll see it is not a good choice. As I wrote before: if the sample buffer is adjusted depending on time/div you always have to set it to a long time, take a measurement and scroll/zoom in to an area of interest. Often I find myself looking at a specific region of a signal and once I'm satisfied I zoom out (or sometimes I just forget to adjust the timebase and zoom out after capturing data). With a fixed (long) record length the workflow is less prone to operator error and you have to adjust less on the scope and all in all work faster. The devil is in the small details. Also I don't recall any DSO which automatically chooses a smaller record length based on the time/div setting so I wonder what they have been smoking at Siglent when they came up with this idea.

[MrW0lf]

Also I don't recall any DSO which automatically chooses a smaller record length based on the time/div setting

Hm, Pico sort of does if, it always shows full capture. But control of sample points is separate from timebase, so if needed sampling rate can be reduced. Never had any trouble with this, quite logical. You just pick main timebase according to slowest signal. From there 2 options: Just zoom in single viewport or use multiple viewports. Then it basically turns to multi trace timebase scope up to digitizer limits. Did little example with demo. 3 viewports (but can be almost any combo):
Scope 1 / CH1: 50ns/div (100,000x zoom)
Scope 2 / CH2: 5ms/div (no zoom, set with main timebase)
Scope 3 / CH3: 25us/div (200x zoom)
Spectrum 1: FFTs over all traces
Other channels are hidden from viewports on purpose (can be shown if needed).

To me seems Siglent follows silmilar logic, just limited to small screen. If you untie sampling rate and buffer length completely from timebase, it would probably create problems for novice users and soon there would be whining about slow wfm updates while sitting at single viewport, 1ns/div and full mem length & sampling rate...

[rf-loop]

With a fixed (long) record length the workflow is less prone to operator error and you have to adjust less on the scope and all in all work faster. The devil is in the small details. Also I don't recall any DSO which automatically chooses a smaller record length based on the time/div setting so I wonder what they have been smoking at Siglent when they came up with this idea.

Previously when I have adapted to use other kind of system it feel ok and only right way. But not anymore after adapted to this working principle. Just as 40 years I drive always rear-wheel drive car and my opinion in every place was that this is only right way. Now I drive front wheel drive car and - after this one year training time - as far as I drive under 3500kg small car  I do not miss at all rear-wheel drive car. 

I think you do not like Hewlett-Packard/Agilent/Keyshit.  Do you know what they have smoked ?
I do not know what they smoked in Agilent but when I'm some times home in China I smoke China Tobacco Guangxi Industrial Corporation made  "Zhenlong".

Still HP - best scopes what ever I have used.



Of course there Siglent can add "fixed length" acquisition (or its near equivalent full window zoom) if some peoples and enough peoples "nicely ask".
But I can not imagine why?

[MrW0lf]

I do not miss at all rear-wheel drive car.

OT: After youve worn thru front tires on your FWD (while rear still perfect) strongly suggest try AWD If business good maybe even try AWD with rears a bit wider than front...

[rf-loop]

I do not miss at all rear-wheel drive car.

OT: After youve worn thru front tires on your FWD (while rear still perfect) strongly suggest try AWD If business good maybe even try AWD with rears a bit wider than front...

Perhaps, if possible AWD full electric.

But realistic prognose for my next "car" is this or near similar

[znroot]

I'm sure is pretty a mistake to talk about such things on a baseline scope, also remembering the price slice of these scopes (SDS1000X I mean) 

However, the Siglent method is different from most but I think they have their logic to do this and it's all about to well know the instruments you're working on. That goes beyond the instrument and the brand of that: you HAVE to know the instrument to better use it. So, if Siglent  prefers "Zoom logic" and you're working with Siglent scope you have to use that "Zoom logic" (you like it or not).

But let's assume this case (don't keep in count statistical calculation averaged on more of one screen Tw time)

• 100us  => Tw = 1.4 ms. Siglent set memory length to 1.4M (1/10 of the total)
• square wave at 10 KHz (14 periods at screen)
• repetitive, periodic square spike, width 500ns, repetition frequency: about 143 Hz (one spike every 5 screen periods).

With Siglent method (keeping in mind that you're using a 1Gsample scope) memory have a resolution of 1ns, so you have in memory only one screen (about 1.468 ms).
So if you don't enable waveform persist you will see a small line 1/5 of the times the screen is refreshed (this is valid if you don't keep in count any other statistical calculation averaged on more of one screen time, as said above).

[/size]This isn't the best scope settings if you expect the spike: with Siglent you need to put the scope to show Tw >= 7 ms and you will see that spike correctly with zooming in.But if you didn't expect it you may lose it if you stop the scope in the wrong instant. That could be avoided using full memory despite of the screen time Tw and doing some more signal elaboration once data are in memory. But this mean a 10 time faster process of acquired data (if you want to maintain the same screen update rate) and maybe some other fast buffer and almost surely a faster memory.So, in my opinion, you have to well know the instruments you use first of all.

[rf-loop]

I'm sure is pretty a mistake to talk about such things on a baseline scope, also remembering the price slice of these scopes (SDS1000X I mean) 

However, the Siglent method is different from most but I think they have their logic to do this and it's all about to well know the instruments you're working on. That goes beyond the instrument and the brand of that: you HAVE to know the instrument to better use it. So, if Siglent  prefers "Zoom logic" and you're working with Siglent scope you have to use that "Zoom logic" (you like it or not).

But let's assume this case (don't keep in count statistical calculation averaged on more of one screen Tw time)

• 100us  => Tw = 1.4 ms. Siglent set memory length to 1.4M (1/10 of the total)
• square wave at 10 KHz (14 periods at screen)
• repetitive, periodic square spike, width 500ns, repetition frequency: about 143 Hz (one spike every 5 screen periods).

With Siglent method (keeping in mind that you're using a 1Gsample scope) memory have a resolution of 1ns, so you have in memory only one screen (about 1.468 ms).
So if you don't enable waveform persist you will see a small line 1/5 of the times the screen is refreshed (this is valid if you don't keep in count any other statistical calculation averaged on more of one screen time, as said above).

[/size]This isn't the best scope settings if you expect the spike: with Siglent you need to put the scope to show Tw >= 7 ms and you will see that spike correctly with zooming in.But if you didn't expect it you may lose it if you stop the scope in the wrong instant. That could be avoided using full memory despite of the screen time Tw and doing some more signal elaboration once data are in memory. But this mean a 10 time faster process of acquired data (if you want to maintain the same screen update rate) and maybe some other fast buffer and almost surely a faster memory.So, in my opinion, you have to well know the instruments you use first of all.

Think some other scope what use full 14M memory and same 100us/div. Think carefully what you can see with your eyes. And when you stop scope this peak may also be out from screen. If you think it is perhaps there. Of course you can zoom out and see it. 

But if you talk about refresh time. How you think this other scope capture this out from screen part - without time? Or how. So, final result is same, turn Siglent for 14M and that's it. Just depending what user is doing, or set this 500us/div as in your example. Now it can see, and - without any stop and zoom.  And more, you can see, if want, upper window whole 7ms and lower window this 1.4ms part or as deep detail as want.
And more. If want  user can stop scope and push one key. Key name is "history". Now he can play couple of previous 1.4M acquisitions if originally was this your example setting 100us/div. And quite sure you can see this one "walking" spike there. Also, depending if this other spike meetss trigger it may also trig it if it occurs next after trigger rearm. 

But if case is that it did not appear just in this screen refresh, in many cases it may appear in history buffer. In buffer, with this setting there is 38 last 1.4M acquisitions (if scope have done 38 acquisitions after last change in settings) (In this case it can use over 53M memory for this history buffer)
Always when scope is running every single acquisition with current memory length is also pushed to wfm history buffer. After stop scope you can run this buffer forward and backward slow or fast or manually every single waveform there. There also can use full window zoom in and out, window zoom, cursors, measurements, FFT, just as for what ever wfm after stop. There can also dipslay only ADC raw sample dots or lines or Sinc intepolation independent of what was case in capture time.

Just stop using stop or history key. And push < button and it play all wfms captured before stop and then > and forward or select acquisition order number what you want look or just scroll manually turning knob  (also every wfm there have time stamp)

[znroot]

Think some other scope what use full 14M memory and same 100us. Think carefully what you can see with your eyes. And when you stop scope this peak may also be out from screen. If you think it is perhaps there. Of course you can zoom out and see it. 

But if you talk about refresh time. How you think this other scope capture this out from screen part - without time? Or how. So, final result is same, turn Siglent for 14M and that's it. Just depending what user is doing, or set this 500us as in your example. Now it can see, and - without any stop and zoom.  And more, you can see, if want, upper window whole 7ms and lower window this 1.4ms part or as deep detail as want.

The example I've wrote show that Siglent or full-memory acquire is very similar if you know the scope. Of course you can zoom out, but the key point is how the data are processed, not a scope feature. SDS1000X "could" run 5 time faster than a scope with full-memory acquiring (you need to acquire the waveform, right?) and so if you do not use the zoom feature but pretend to see the spike with these settings (not talking about history!):
-other can
-Siglent can't
This is mean without keeping in count history and any other data processing averaged in more than one acquisition time. At this point Siglent is not fully wrong because:
-with these settings it is 5 times faster to show the waveform from acquisition to screen
-if you use zoom feature and adjust the scope to 500us the scope will run "at the same speed" of others
So it's just a different mode of acquiring signals and showing them.




[/size]

And more. If want  user can stop scope and push one key. Key name is "history". Now he can play couple of previous 1.4M acquisitions if originally was this your example setting 100us. And quite sure you can see this one "walking" spike there. Also, depending if this other spike meetss trigger it may also trig it if it occurs next after trigger rearm. 

But if case is that it did not appear just in this screen refresh, in many cases it may appear in history buffer. In buffer, with this setting there is 38 last 1.4M acquisitions (if scope have done 38 acquisitions after last change in settings) (In this case it can use over 53M memory for this history buffer)
Always when scope is running every single acquisition with current memory length is also pushed to wfm history buffer. After stop scope you can run this buffer forward and backward slow or fast or manually every single waveform there. There also can use full window zoom in and out, window zoom, cursors, measurements, FFT, just as for what ever wfm after stop. There can also dipslay only ADC raw sample dots or lines or Sinc intepolation independent of what was case in capture time.

Just stop using stop or history key. And push < button and it play all wfms captured before stop and then > and forward or select acquisition order number what you want look or just scroll manually turning knob  (also every wfm there have time stamp)

Yes, history is useful in these cases but my example was using basic scope settings, not history. The scope has also history and this is another (good) thing. But it wasn't the object of my reply to analyze any other feature. My reply contains only consideration about pros and cons on siglent approach in a particular situation in which full acquisition memory make a difference in measurements.

[rf-loop]

In mainstream yes.

-----------------

Here in this table can see also what is difference example between 14M and 1.4M (1ms/div and 100us/div) wfm/s speeds. Also amount of max  availabe segments in sequence mode  and amount of waveforms in waveform history buffer.

[JPortici]

Preparing my chart...

Overall I think that well implemented zoom system is better than having some part of wfm hidden. But cannot understand one thing - so does Siglent decode only from zoomed part or from whole wfm (while zoomed!)? Logical would be to have event table for everything and stuff from zoomed part somehow highlighted. So how it is?

I agree. Of course, you and I are thinking on how things are done in a picoscope.

My understanding on what is happening on the siglent sds1000x is:
decoding is done on the portion of waveform memory displayed/zoomed on screen..

this means that with no zoom you are decoding from the acquired data, not from undersampled data passed to the screen buffer. This is great, excellent!

however, it was decided that when you zoom in the event table is adjusted so that only the events displayed inside the zoomed area are listed.
this sounds like a contraddiction do me, two fundamentally different ways to do the same thing: decoding from waveform memory or decoding from screen memory

Siglent should keep the event list the same. you zoom in and then select the event you want to center the zoom to. Even better, if as on the picoscope you could also show decoded data from past acquisitions (in this case history/segmented memory)

Or maybe, still keep the event list the same but adjust the index so that list entry zero is the leftmost displayed in zoomed area (previous with negative index)
it sounds silly just by writing it but hey, if they MUST do something different.. at least let it be something that doesn't cripple the functionality

Another question: can the logic channels be used for serial decoding and triggering? what about the sds2000x? (BTW: can't find the topic)

[rf-loop]

Preparing my chart...

Overall I think that well implemented zoom system is better than having some part of wfm hidden. But cannot understand one thing - so does Siglent decode only from zoomed part or from whole wfm (while zoomed!)? Logical would be to have event table for everything and stuff from zoomed part somehow highlighted. So how it is?

I agree. Of course, you and I are thinking on how things are done in a picoscope.

My understanding on what is happening on the siglent sds1000x is:
decoding is done on the portion of waveform memory displayed/zoomed on screen..

this means that with no zoom you are decoding from the acquired data, not from undersampled data passed to the screen buffer. This is great, excellent!

however, it was decided that when you zoom in the event table is adjusted so that only the events displayed inside the zoomed area are listed.
this sounds like a contraddiction do me, two fundamentally different ways to do the same thing: decoding from waveform memory or decoding from screen memory

Siglent should keep the event list the same. you zoom in and then select the event you want to center the zoom to. Even better, if as on the picoscope you could also show decoded data from past acquisitions (in this case history/segmented memory)

Or maybe, still keep the event list the same but adjust the index so that list entry zero is the leftmost displayed in zoomed area (previous with negative index)
it sounds silly just by writing it but hey, if they MUST do something different.. at least let it be something that doesn't cripple the functionality

Also I hope Siglent rethink and develop it in some future FW.
If turn zoom off, decode table have whole memory.
I hope that also with zoom they keep full list and then some how show (example some indicator in table so that zoom window area can easy sdetect in table.  But, this is too simply explanation. A detailed definition requires a much longer description.

Another question: can the logic channels be used for serial decoding and triggering? what about the sds2000x? (BTW: can't find the topic)

SDS1000X = SDS2000X in this case, and in many other things functions are same
Serial trigger sources can be CH1, CH2 or D0 - D15 
Serial decoding, signals can come from CH1, CH2 or D0 - D15  (free mix, example Clock can be CH1, CS from D1, MOSI D2 and MISO CH2)

[JPortici]

very good to hear. Since i'm in the market for a new bedroom-scope to be get until end of the month, i'm considering all options

judging by datasheets and manuals i already came out to the conclusion that besides sample rate and memory 1000x and 2000x were the same.. but 2000x come in 4 channels. wish they had a promotion with at least the decoders for free too.

considering all options i am currently set on the new keysight (on ebay from scopemonth winners, hopefully) or the sds1000x

even though i can already see cases where i could need 3 or 4 analog channels, all costs considered it would be 2x the price, for sds2104x + decode or GDS2104E...
2 channels + LA will cover 95% of my use cases

re: wish they would change the decode too, is there somebody to contact? maybe, i say maybe, if enough people will gently ask..

[kcbrown]

@rf-loop: Does the masking function operate on the zoomed area, or on the unzoomed area?

It matters.  A lot.  The reason it matters is that if you're looking for a waveform that does not fit the mask and want to see what surrounds it (especially on other channels), if it operates on the unzoomed area, then you'd (presumably) have to define the mask to cover the entire period of time of the capture.

Other scopes don't have a problem here, because they'll capture parts of the waveform that aren't being displayed, but the Siglent doesn't operate that way.

If the Siglent's masking function operates on the capture area then you won't be able to use it to detect a violation of the mask and be able to see the surrounding waveform after the violation is captured. 

Unless, that is, they make it possible for the mask to cover only a subset of the displayed waveform.  Then you'd set your timebase to show the part of the waveform to create the mask from (it's obvious that the mask should cover the trigger point), then create the mask, then set the timebase to reflect the capture length you're interested in, and then run the test.  Note that in this case, the mask might well not be visible at all if you're capturing enough.  Siglent would have to contend with certain problems at that point, such as the possibility that the mask's resolution is greater than the capture resolution, since we're talking about altering the timebase between mask definition time and capture time.

So: how does the mask function intersect with the "what you see is all you get" approach that Siglent takes here?

[kcbrown]

Also I hope Siglent rethink and develop it in some future FW.
If turn zoom off, decode table have whole memory.
I hope that also with zoom they keep full list and then some how show (example some indicator in table so that zoom window area can easy sdetect in table.  But, this is too simply explanation. A detailed definition requires a much longer description.

It would be very easy for them to do.  The list display just shows you a subset of the captured list, for any nontrivial capture.  They could set it up so that zooming or changing the timebase (when stopped, of course) causes the scope to change what the list view is showing such that the first item shown is the first decoded item shown on the waveform screen.  Entries that precede that point are still in the list, and can be reached either by scrolling the list or scrolling the waveform view.  The scope could place markers in the list indicating the boundaries that correspond to the edges of the waveform view, so that if you choose to view some other part of the list, you can always know where the waveform display boundaries are within that list.