Everyday bench scope, a 3 way race, EDUX1002A, GDS-1054B, SDS1202X-E

[nctnico]

That is what I wrote: you need the zoom-mode work-around which eats away screen space.

It's not a workaround. It is exactly the same thing, except with more or less screen space.
And if you want to have an overview where you are, zoom mode is a plus, a good thing not a defect.
Of course, saving screen space is good too.

But it decodes whole memory. With different user interface presentation.

Basically, if they could minimize (hide) overview window, that would satisfy your requirement.

And that would be very nice and would be my suggestion to Siglent.

That is the bottom line of my point: if they can decode the entire memory anyway then why require the zoom window? Also the automatic memory length can be a nuisance.  I often look at signal details but want to be able to scroll/zoom to parts outside the screen if I spot something out of the ordinary. This is one of the advantages of having deep memory in the first place. I don't know if this can be overridden permanently on Siglent oscilloscopes so you can have a preset memory length.

[rf-loop]

That is what I wrote: you need the zoom-mode work-around which eats away screen space.

Siglent decode full memory length,  so please stop repeating this stupid claim that it do not decode full memory or ask if some later day also Siglent can do it. I'm really wondering why you do this time after time, months and years. I think after years you can walk over this post traumatic situation with this historical sad case between you, Siglent and one distributor.

What you win with this bullshit. If you know and understand only one way how to use oscilloscope why it need repeat all time like.

Of course Siglent can also do full image zoom so that it use "full window zoom" like many others and then hide part of trace out from display and this is bad. Adding visual blind time. It is easy to do.  (also Siglent made it in history, in some older models where really is not brute force for this better method now (there was not at all decode or other advanced functions). Example in simple SDS1000CML/CNL series.)
It also can save processing power minimizing amount of samples what need use for produce image with or without decimation for image.
But it is true that splitted screen give less room. This is why I do not at all like these 7" 800x480 display formats. Example Owon use 800x600. 
Also IF Siglent want they can divide display different. So that upper part height is less and zoom window more height. Personally I do not understand idea when they both have same height. When user use window zoom he want look details so priority is there. Example Owon have done this, upper part is much less than zoomed bottom part (and also they have much better TFT).

Of course in stop mode can also decode fully post process what ever is captured and with full memory length also, including history and segments. In this case full memory length decode works also with full window zooming.

Look these images and repeat and show  reasult here with yours bit more expensive GoodWill 2000E.
I'm waiting.

[2N3055]

That is what I wrote: you need the zoom-mode work-around which eats away screen space.

It's not a workaround. It is exactly the same thing, except with more or less screen space.
And if you want to have an overview where you are, zoom mode is a plus, a good thing not a defect.
Of course, saving screen space is good too.

But it decodes whole memory. With different user interface presentation.

Basically, if they could minimize (hide) overview window, that would satisfy your requirement.

And that would be very nice and would be my suggestion to Siglent.

That is the bottom line of my point: if they can decode the entire memory anyway then why require the zoom window? Also the automatic memory length can be a nuisance.  I often look at signal details but want to be able to scroll/zoom to parts outside the screen if I spot something out of the ordinary. This is one of the advantages of having deep memory in the first place. I don't know if this can be overridden permanently on Siglent oscilloscopes so you can have a preset memory length.

This proves the point of people being different. I absolutely don't expect for scope to capture more data than it is instructed to do. To me capturing large buffer and zooming in is more logical and deterministic. But I appreciate that zoom implementation takes too much screen. It should be smaller or even better user configurable size. Overview window doesn't have to be much thicker than windows scrollbar..

[rf-loop]

That is what I wrote: you need the zoom-mode work-around which eats away screen space.

It's not a workaround. It is exactly the same thing, except with more or less screen space.
And if you want to have an overview where you are, zoom mode is a plus, a good thing not a defect.
Of course, saving screen space is good too.

But it decodes whole memory. With different user interface presentation.

Basically, if they could minimize (hide) overview window, that would satisfy your requirement.

And that would be very nice and would be my suggestion to Siglent.

That is the bottom line of my point: if they can decode the entire memory anyway then why require the zoom window? Also the automatic memory length can be a nuisance.  I often look at signal details but want to be able to scroll/zoom to parts outside the screen if I spot something out of the ordinary. This is one of the advantages of having deep memory in the first place. I don't know if this can be overridden permanently on Siglent oscilloscopes so you can have a preset memory length.

This proves the point of people being different. I absolutely don't expect for scope to capture more data than it is instructed to do. To me capturing large buffer and zooming in is more logical and deterministic. But I appreciate that zoom implementation takes too much screen. It should be smaller or even better user configurable size. Overview window doesn't have to be much thicker than windows scrollbar..

Yes. With window zoom layout can be better (or even user settable).
One problem is this display form factor for verticallly splitted displays. 800x480 pixel is not much.
Personally I do not like at all this 5:3 aspect ratio. Specially with window zoom I miss more room for bottom window. Example Rigol 1kZ do it.

If look example Owon what use here 800x600 display. (4:3)
even with 4:3 aspect ratio 8" monitor they give more room for zoomed window together with full adc range vertical range with 10 div.

I hope some day Siglent rethink this and make it better - more room for zoomed window.


Zoomed Next falling edge after trigged falling edge.
(as can see Owon programmer do not care if she use Kelvin or kilo.  what KelvinHz ... I had to )

[luxetveritas]

For me, oscilloscope serial decoding is almost a "who-gives-a-rat's-behind".  USB logic analyzers have a lot of advantages and cost only a few dollars (or tens of dollars for a really good one).  Here are a couple of detailed videos that show what goes on in the Saleae and some others:

[rf-loop]

That is what I wrote: you need the zoom-mode work-around which eats away screen space.

This is naturally true, of course, if one banana is divided for 2 then both have  less than whole banana. Now Siglent divide it half and half and this is perhaps not best division ratio and and this ratio can be criticized.


Nice you drop now out this claim/suspect about lack of decode entire capture memory length what was much more severe claim/suspect. I hope you now remember this and do not again come bact to this question about decode length whole captured length or not.

Things have disadvantages and advantages (zoom with panorama view (vertically splitted) or zoom without using full window zoom).

Zoom with panorama view for entire length:

Disadvantage is:  less vertical room for detailed view. But still enough resolution for 8bit ADC.

(But if really do not want look this panorama to whole length user can take piece of paper and hide it. Now he have less information on the screen.) Or Siglent can add button: "hide it" 

I think that advantage is more important: Simultaneous overview of the total memory length. For example, there may be a pause in data transmission or, for example, a serious level change. Or the entire memory length may have different length messages and breaks. This makes it easy, least for me, to move, for example, to a message that is essentially different in length. Without a panoramic view of the entire length of the memory, it is at least sometimes more difficult. But why hide this information. We have enough brute force in system for display it.

Do we need divide vertically half and half. My opinion is: No. Other ratio is perhaps more optimal - not technically but for human eye.
Of course this half-half division is simple. ADC is 8bit. Signal vertical area height is 400pixels. Display is divided to eight divisions (whole ADC range is bit over 10 div, bottom and top around one div unvisible) One division is 50pixel on screen.
Without zoom every ADC  level step is 2 pixel height. With half-half splitted zoom every ADC level step is 1 pixel. So, still both windows can show full resolution. But, small 7" 800x480 pixel display is small for human eye, least for my far over 60 years old eyes. (70 is more close than 60).
But if it can divide for 1/3 and 2/3 height windows  or 1/4 and 3/4 least I feel it better.
Also this 5:3 aspect ratio for oscilloscope display, Personally I do not like - fashion or not.
Perhaps if I design I set 4:3 screen and long side vertically. For modern oscilloscopes what may also have digital channels.  If one use 5:3 display why nearly all need copycat this. I want zoom and I want also room for it, vertically, including possible digital channels. So turn this 5:3 or what ever display 90 degree. Is it fun. No but perhaps more ergonomic in some situations.
(Yes I remember also one LeCroy)
"Golden ratio" or near in Architecture and Art is another thing. I think T&M instruments need look from different approach angle.



In previous message I wrote my wish for repeat this same what can see in my images with some other scopes:

I'm very interested to see after someone repeat this same example with EDUX1002A or GDS-1054B.
Least this Keysight EDUX drops out like chicken if it try fly in this test (but have also advantages in some cases with its speed). How about OP's third example model GoodWill 1054B.

.

I look forward with interest. Maybe it's a too big wish -- as usually.

[TK]

Siglent SDS1104X-E decodes full memory.  If you do a single capture and it shows the decode information, you can scroll part of the waveform out of the screen and still will show the correct decoded value.

But decoding is slow, around 4Hz (Using 14Mpts MemDepth, it could be faster with smaller sample memory, but I have not tested it).  I implemented a UART counter and on Keysight I can delay 100ms between the refresh of each digit on the counter and I can see all the values passing by, but on the Siglent, the delay cannot be less than 250ms to be able to see all the digit values being counted.  If the delay is decreased less than 250ms, then it skips digits.

Of course this is not a limitation as you will probably do a single capture and review the waveform + decoded info or activate the protocol LIST

[rf-loop]

Siglent SDS1104X-E decodes full memory.  If you do a single capture and it shows the decode information, you can scroll part of the waveform out of the screen and still will show the correct decoded value.

But decoding is slow, around 4Hz (Using 14Mpts MemDepth, it could be faster with smaller sample memory, but I have not tested it).  I implemented a UART counter and on Keysight I can delay 100ms between the refresh of each digit on the counter and I can see all the values passing by, but on the Siglent, the delay cannot be less than 250ms to be able to see all the digit values being counted.  If the delay is decreased less than 250ms, then it skips digits.

Of course this is not a limitation as you will probably do a single capture and review the waveform + decoded info or activate the protocol LIST

Can you explain this all with real settings and information about decoded data stream etc.
Is it difficult to give full data about test. Now this information value is zero.

Then you talk about Siglent with 14M memory but this undefined Keysight have how much (1M ?).
I believe Keysight decode IS faster than Siglent but also with severe disadvantages but let's not talk about it just now (example decoding offline).

Now I'm interested to hear how you exactly tested and what is just your "UART counter (specs)" and so on and so on. Just all with enough data and setup explanation. It takes some seconds also get screen image out from Siglent, perhaps also from Keysight.  (None of us are clairvoyants. - Least I do not have these skills)

[TK]

Siglent SDS1104X-E decodes full memory.  If you do a single capture and it shows the decode information, you can scroll part of the waveform out of the screen and still will show the correct decoded value.

But decoding is slow, around 4Hz (Using 14Mpts MemDepth, it could be faster with smaller sample memory, but I have not tested it).  I implemented a UART counter and on Keysight I can delay 100ms between the refresh of each digit on the counter and I can see all the values passing by, but on the Siglent, the delay cannot be less than 250ms to be able to see all the digit values being counted.  If the delay is decreased less than 250ms, then it skips digits.

Of course this is not a limitation as you will probably do a single capture and review the waveform + decoded info or activate the protocol LIST

Can you explain this all with real settings and information about decoded data stream etc.
Is it difficult to give full data about test. Now this information value is zero.

Then you talk about Siglent with 14M memory but this undefined Keysight have how much (1M ?).
I believe Keysight decode IS faster than Siglent but also with severe disadvantages but let's not talk about it just now (example decoding offline).

Now I'm interested to hear how you exactly tested and what is just your "UART counter (specs)" and so on and so on. Just all with enough data and setup explanation. It takes some seconds also get screen image out from Siglent, perhaps also from Keysight.  (None of us are clairvoyants. - Least I do not have these skills)

I have been doing some additional tests last night and went down on the memory of the Siglent to 14Kpts, which accelerates the decode but still slower than the Keysight and the GDS1054B.  For now the confirmation is visual but I will make an animated GIF to show all three scopes with the same decoding task and post details of the test setup.

[rf-loop]

Siglent SDS1104X-E decodes full memory.  If you do a single capture and it shows the decode information, you can scroll part of the waveform out of the screen and still will show the correct decoded value.

But decoding is slow, around 4Hz (Using 14Mpts MemDepth, it could be faster with smaller sample memory, but I have not tested it).  I implemented a UART counter and on Keysight I can delay 100ms between the refresh of each digit on the counter and I can see all the values passing by, but on the Siglent, the delay cannot be less than 250ms to be able to see all the digit values being counted.  If the delay is decreased less than 250ms, then it skips digits.

Of course this is not a limitation as you will probably do a single capture and review the waveform + decoded info or activate the protocol LIST

Can you explain this all with real settings and information about decoded data stream etc.
Is it difficult to give full data about test. Now this information value is zero.

Then you talk about Siglent with 14M memory but this undefined Keysight have how much (1M ?).
I believe Keysight decode IS faster than Siglent but also with severe disadvantages but let's not talk about it just now (example decoding offline).

Now I'm interested to hear how you exactly tested and what is just your "UART counter (specs)" and so on and so on. Just all with enough data and setup explanation. It takes some seconds also get screen image out from Siglent, perhaps also from Keysight.  (None of us are clairvoyants. - Least I do not have these skills)

I have been doing some additional tests last night and went down on the memory of the Siglent to 14Kpts, which accelerates the decode but still slower than the Keysight and the GDS1054B.  For now the confirmation is visual but I will make an animated GIF to show all three scopes with the same decoding task and post details of the test setup.

This is depending what want do. Example. I run serial (UART 38400, N, 1) send 100mS period 1 byte counter (values 0x00 to 0xFF and after then 0x00 and continuing...). If I look scope screen with decode and 20us/div, 50MSa/s, 14k). My eyes can not realiable read all  as fast as it update. I continue looking this, decode running, and after time I stop scope and then look history (1891 last acquisitions), every single serial 1 byte messages are there, of course nothing dropped out.

I have not tested what is minimum transmit period in this special case what do not drop out any message  but with 80ms period it looks like it can not print all decode results to display in real time (but of course they are still captured). If I then stop and look history, they are all there.
Of course using fast segment acquisition it can capture lot of faster and also there do not come time cap what happen every 40ms when it refresh image and during this,  blind time is longer.

Other tesdt what I did was so that time base 5 second/div and 14M memory. (one acquisition length 70 second).  This same UART 38400,N,1,  Transmit period 80ms. All captured 873 one byte messages decoded at once.

[2N3055]

This is depending what want do. Example. I run serial (UART 38400, N, 1) send 100mS period 1 byte counter (values 0x00 to 0xFF and after then 0x00 and continuing...). If I look scope screen with decode and 20us/div, 50MSa/s, 14k). My eyes can not realiable read all  as fast as it update. I continue looking this, decode running, and after time I stop scope and then look history (1891 last acquisitions), every single serial 1 byte messages are there, of course nothing dropped out.

I have not tested what is minimum transmit period in this special case what do not drop out any message  but with 80ms period it looks like it can not print all decode results to display in real time (but of course they are still captured). If I then stop and look history, they are all there.
Of course using fast segment acquisition it can capture lot of faster and also there do not come time cap what happen every 40ms when it refresh image and during this,  blind time is longer.

Other tesdt what I did was so that time base 5 second/div and 14M memory. (one acquisition length 70 second).  This same UART 38400,N,1,  Transmit period 80ms. All captured 873 one byte messages decoded at once.

This..

I have Keysight 3000T. Nothing is faster than that. It decodes super fast, so fast that, in fact, packets that are changing fast become unreadable blur. I don't know about you, but I can't read blurringly fast stream of hex off the screen, Matrix style. I'm not Neo.

As long as decoding doesn't slow down scope triggering, final result is all the same, You capture and stop and go trough the packets. If looking at specific packet, you make smart trigger. You use segments if you need super fast or have very long sequences. In any case, you will appreciate large memory. You will also appreciate that you can enable decode after the fact, or even on a waveform loaded from USB that somebody sent you via E-mail. Those things might be useful to you. Interactive decoding that is faster than you can read looks very cool, but is not really useful, realy.

[TK]

What I am trying to point out is that Siglent has a significant delay from the time when the signal is being detected and when the information is displayed in the screen.  It can definitely trigger on serial data faster, it shows the waveform (I know it has been decoded in memory as it was triggered correctly), then the decode information shows up like 200-250ms later.  I think there is room for improvement and can enhance the UI experience and make this scope (which I like a lot, by the way) a lot better.

I will test SPI decoding (>= 8MHz) as UART is not pushing the limit enough to detect if any packet is missing from triggering.

The SDS1104X-E is ALMOST my perfect 4-channel scope... and I say ALMOST because of this decoding to display LAG and also my hacked Keysight EDUX1002G offers I2S and a bunch of advanced serial decoding.

For serious serial decoding, I use a logic analyzer, but the convenience of having all in one in a single instrument is nice.  And when you are coding microcontrollers with SPI and i2c, even when you cannot read all the information that is being refreshed, it can give you a hint if your circuit + source code is sending the signals at the rate you expect... if it shows 4 updates per second, you need to do a long capture, then start going through all the code and check the timing... it is very helpful when you can have an instant visual confirmation that the information is going out from your microcontroller at the rate you expect.

[nctnico]

I agree. I regulary use decoding to look at what comes from -for example- an ADC realtime. It sucks if there is a long time between turning a knob to change a voltage and see the result in the decoded stream.

[2N3055]

What I am trying to point out is that Siglent has a significant delay from the time when the signal is being detected and when the information is displayed in the screen.  It can definitely trigger on serial data faster, it shows the waveform (I know it has been decoded in memory as it was triggered correctly), then the decode information shows up like 200-250ms later.  I think there is room for improvement and can enhance the UI experience and make this scope (which I like a lot, by the way) a lot better.

I will test SPI decoding (>= 8MHz) as UART is not pushing the limit enough to detect if any packet is missing from triggering.

The SDS1104X-E is ALMOST my perfect 4-channel scope... and I say ALMOST because of this decoding to display LAG and also my hacked Keysight EDUX1002G offers I2S and a bunch of advanced serial decoding.

For serious serial decoding, I use a logic analyzer, but the convenience of having all in one in a single instrument is nice.  And when you are coding microcontrollers with SPI and i2c, even when you cannot read all the information that is being refreshed, it can give you a hint if your circuit + source code is sending the signals at the rate you expect... if it shows 4 updates per second, you need to do a long capture, then start going through all the code and check the timing... it is very helpful when you can have an instant visual confirmation that the information is going out from your microcontroller at the rate you expect.

That is exactly the thing why I have 3000T, but there is a point where delay is perceptible but not annoying. Also hardware decode would visually show you there is some activity, you would still need to capture and verify individual packets timing and data, relative to some timing reference.

Just to check whether some packet goes out, you can see that on the waveform..

I guess what I want to say that I agree with both you and nctnico in principle. That is why I did buy fast scope. But that is because I could afford both a fast one and one with long memory, and the high res one . So I can have best tool for the job.

But if I had to buy only one scope, it would be one with long memory and software decode because it has all of the advantages, and Keysight 1000 has only hardware decode working for it. That is useful but I would give up little speed for other benefits.
I guess it highly depends what you do and how you do it..
That is why we have these discussions,  so all options are clearly laid out, so everyone can make informed decision for themselves..

Regards,

[TK]

I am generating a 18MHz SPI signal (complete loop from Frame 1 to Frame 8 is 90uS, so I have 11,111 loops in 1 second):

Frame 1: "0"
Frame 2: "1S"
Frame 3: "2Si"
Frame 4: "3Sig"
Frame 5: "4Sigl"
Frame 6: "5Sigle"
Frame 7: "6Siglen"
Frame 8: "7Siglent"

And I am triggering on the value 't' (0x74) and the Siglent SDS1104X-E is able to trigger and the displayed decode info refresh rate seems comparable to the Keysight EDUX1002G and the GDS1054B.

The only "issue" for me is still the LAG between the waveform display and the decoded information.  The GDS1054B uses the same ZINQ device and is able to update the decoded information very rapidly, I assume Siglent can fix this LAG if they look closely into it.

The Keysight 1000X (and I guess it applies also to 2000X, 3000X) SPI trigger needs the value for the full SPI frame.  As I am triggering on the letter 't' (Frame 7), the full frame has 8 bytes, you need to specify the values for all 8 bytes.  Fortunately you can indicate all X except for the last byte to be 0x74. 

I have 11,111 loops (Frame 1 to Frame in 1 second, and the letter 't' appears once per loop, so I should have 11,111 triggering events.

The SDS1104X-E can trigger 334 to 1000 per second, so it is finding around 10% of all 't's in a second.  Similar for GDS1054B.
Keysight EDUX1002G can trigger approx 11,000 (Trigger out shows a measured frequency of 11.05KHz) times per Second, so it apparently is finding all the letter 't' in a Second.  Really hardware decoding makes a difference.

If there is a random byte in the SPI stream, it is probable that the Keysight will be able to trigger on it, but the chances for the SDS1104X-E and GDS1054B to capture it is about 10% of the Keysight.

My next test will be generating a specific byte like 0xFF at a random interval and see which scope can catch it.  I think I already have the answer...

[2N3055]

I am generating a 18MHz SPI signal (complete loop from Frame 1 to Frame 8 is 90uS, so I have 11,111 loops in 1 second):

Frame 1: "0"
Frame 2: "1S"
Frame 3: "2Si"
Frame 4: "3Sig"
Frame 5: "4Sigl"
Frame 6: "5Sigle"
Frame 7: "6Siglen"
Frame 8: "7Siglent"

And I am triggering on the value 't' (0x74) and the Siglent SDS1104X-E is able to trigger and the displayed decode info refresh rate seems comparable to the Keysight EDUX1002G and the GDS1054B.

The only "issue" for me is still the LAG between the waveform display and the decoded information.  The GDS1054B uses the same ZINQ device and is able to update the decoded information very rapidly, I assume Siglent can fix this LAG if they look closely into it.

The Keysight 1000X (and I guess it applies also to 2000X, 3000X) SPI trigger needs the value for the full SPI frame.  As I am triggering on the letter 't' (Frame 7), the full frame has 8 bytes, you need to specify the values for all 8 bytes.  Fortunately you can indicate all X except for the last byte to be 0x74. 

I have 11,111 loops (Frame 1 to Frame in 1 second, and the letter 't' appears once per loop, so I should have 11,111 triggering events.

The SDS1104X-E can trigger 334 to 1000 per second, so it is finding around 10% of all 't's in a second.  Similar for GDS1054B.
Keysight EDUX1002G can trigger approx 11,000 (Trigger out shows a measured frequency of 11.05KHz) times per Second, so it apparently is finding all the letter 't' in a Second.  Really hardware decoding makes a difference.

If there is a random byte in the SPI stream, it is probable that the Keysight will be able to trigger on it, but the chances for the SDS1104X-E and GDS1054B to capture it is about 10% of the Keysight.

My next test will be generating a specific byte like 0xFF at a random interval and see which scope can catch it.  I think I already have the answer...

Those are good measurements and info.

I'm curious... What happens on SDS1104X-E and GDS1054B if you setup SPI trigger, but don't enable decode?
Will trigger rate still be that slow?

What I'm trying to say is that software decoding (if properly implemented) shouldn't have any impact on trigger rate. Decoding and display should be in a completely separate display loop that should skip (decimate) decode data that it cannot show in real time, but triggers and waveform display and save to history segments should keep on running without slowdown.

So if it can't keep up with screen refresh it doesn't matter, but when you stop acquisitions, if you go into history buffers it's all there.
That would be a good compromise for a software decoding scope, that would guarantee that you won't miss packets that are too fast to see anyways...
And if you are looking into waveform, you will see something is changing so you know you need to investigate trough decode table.

Randomly sent specific packet will be detected at the same rate under same settings. If it is spaced to more than 1 ms apart it will be detected 100% of the time, if closer than that, only first one will be detected (triggered on).
But, as I said, I would like to see what is a trigger rate without decode on.

Also it would be nice to try with fast segment mode on. And I will tell you why: On 3000T I pretty much use segmented mode all the time if I need to  capture multiple packets because of very small memory. If you don't use segmented memory you can barely capture few packets.
And on Keysight segmented memory behaves same as fast segments on Siglent: screen is blank until it captures all segments.

All of this is actually my point: you are benchmarking 3 scopes to see how fast are they doing specific test. But that particular test has limited relationship with real time usage, same as synthetic benchmarks on a computer.

To summarize so far:

1. You proved that enabling decode on the on SDS and GDS slows down triggering rate. I agree it doesn't have to be implemented that way, even for software decode.
2. You noticed that SDS has noticeable pause displaying data that similar hardware on GDS doesn't. I agree Siglent could optimise that If GW Instek could.
3. You proved that hardware decoding Keysight doesn't slow down triggering rate if you enable decodes. It agrees with their specs and marketing.

That brings us to these observations:

4. You couldn't visually see any difference on display that would show SDS and GDS and Keysight had any difference in refresh rate.
5. You had to measure Trig Out frequency to actually figure out trigger rate. Super fast Keysight looked pretty much the same on the screen.
6. So only useful info from that measurement is not decoded data from 11000 frames, but only trigger frequency. Which is useful to, for instance, measure how many times a second sensor sends specific data. In which case you don't need decoding. You setup triggers to SPI and don't decode. Just measure trigger frequency. Of course, that is if SDS is dropping trigger rate because of decode and not for trigger itself being slow.
7. If you wanted to actually capture those 11000 frames to verify something, you will have to put all of them in segment mode. In which case (a fully unlocked) keysight 1000 will have a maximum of 50 segments. SDS supports up to 80000 segments.. So pretty much no limit. GDS seems not to have segmented memory officially, seems that hacked one does..

So that is actually what I want to say: if you are just looking at the scopes display you won't see a difference (apart from that lag) in screen refresh rate. Your eyes can't see a difference if scopes are triggering 1000x a second or 10000x a second. You won't see individual packets. You have to measure triggering frequency to know the difference, in which case you can simply disable decodes.. Because you can't read all of the 10000 packets in that second. On all of those scopes you will see just random packets that happen to coincide with screen refresh rate, and when you STOP you will see last one. On all of them.

With SDS you have the option to set triggers with no decodes, capture 10s of thousands of packets, stop it, enable decodes and then have all of them decoded, and with exact timing information for each one. You will have to do the same on Keysight but will have a max of 50 segments.

Don't get me wrong. 50 segments is plenty for most of cases. It's just that when we are comparing different designs, we cannot compare them directly. Every architecture will have it's strengths and weaknesses, and different ways to do same things and extract maximum from the instrument.
Because of much bigger memory, on Siglent you might as well just grab one single huge chunk of capture with hundreds of packets inside and just use search to find packets you want..

Keysight has 2GS/sec sampling rate (which helps with aliasing) and because of hardware decodes it doesn't slow down when you enable decodes.

Everything else is seriously better on Siglent. Memory, segmented memory(it is much larger that basic buffers), history buffers that run all the time, FFT, measurements that can be over whole memory buffer (Keysight runs over decimated subbuffer, even on 3000T series).. GDS will also be much better, except no history and only one 1GS/s A/D, and some other stuff it has like digital filters...

So depending of how you decide to use instrument, one or the other will be better.

[nctnico]

A few remarks:
1) On the Keysight you can't enable decoding after the fact. Decoding has to run in parallel with the acquisition.

2) Decoding can slow down the trigger rate if each acquisition is shown & decoded on screen.  In some cases decoding is skipped to keep the trigger speed high. Some oscilloscopes have the option to hide the traces during acquisition to reduce the dead time between acquisitions.

[TK]

I am generating a 18MHz SPI signal (complete loop from Frame 1 to Frame 8 is 90uS, so I have 11,111 loops in 1 second):

Frame 1: "0"
Frame 2: "1S"
Frame 3: "2Si"
Frame 4: "3Sig"
Frame 5: "4Sigl"
Frame 6: "5Sigle"
Frame 7: "6Siglen"
Frame 8: "7Siglent"

And I am triggering on the value 't' (0x74) and the Siglent SDS1104X-E is able to trigger and the displayed decode info refresh rate seems comparable to the Keysight EDUX1002G and the GDS1054B.

The only "issue" for me is still the LAG between the waveform display and the decoded information.  The GDS1054B uses the same ZINQ device and is able to update the decoded information very rapidly, I assume Siglent can fix this LAG if they look closely into it.

The Keysight 1000X (and I guess it applies also to 2000X, 3000X) SPI trigger needs the value for the full SPI frame.  As I am triggering on the letter 't' (Frame 7), the full frame has 8 bytes, you need to specify the values for all 8 bytes.  Fortunately you can indicate all X except for the last byte to be 0x74. 

I have 11,111 loops (Frame 1 to Frame in 1 second, and the letter 't' appears once per loop, so I should have 11,111 triggering events.

The SDS1104X-E can trigger 334 to 1000 per second, so it is finding around 10% of all 't's in a second.  Similar for GDS1054B.
Keysight EDUX1002G can trigger approx 11,000 (Trigger out shows a measured frequency of 11.05KHz) times per Second, so it apparently is finding all the letter 't' in a Second.  Really hardware decoding makes a difference.

If there is a random byte in the SPI stream, it is probable that the Keysight will be able to trigger on it, but the chances for the SDS1104X-E and GDS1054B to capture it is about 10% of the Keysight.

My next test will be generating a specific byte like 0xFF at a random interval and see which scope can catch it.  I think I already have the answer...

Those are good measurements and info.

I'm curious... What happens on SDS1104X-E and GDS1054B if you setup SPI trigger, but don't enable decode?
Will trigger rate still be that slow?

What I'm trying to say is that software decoding (if properly implemented) shouldn't have any impact on trigger rate. Decoding and display should be in a completely separate display loop that should skip (decimate) decode data that it cannot show in real time, but triggers and waveform display and save to history segments should keep on running without slowdown.

So if it can't keep up with screen refresh it doesn't matter, but when you stop acquisitions, if you go into history buffers it's all there.
That would be a good compromise for a software decoding scope, that would guarantee that you won't miss packets that are too fast to see anyways...
And if you are looking into waveform, you will see something is changing so you know you need to investigate trough decode table.

Randomly sent specific packet will be detected at the same rate under same settings. If it is spaced to more than 1 ms apart it will be detected 100% of the time, if closer than that, only first one will be detected (triggered on).
But, as I said, I would like to see what is a trigger rate without decode on.

Also it would be nice to try with fast segment mode on. And I will tell you why: On 3000T I pretty much use segmented mode all the time if I need to  capture multiple packets because of very small memory. If you don't use segmented memory you can barely capture few packets.
And on Keysight segmented memory behaves same as fast segments on Siglent: screen is blank until it captures all segments.

All of this is actually my point: you are benchmarking 3 scopes to see how fast are they doing specific test. But that particular test has limited relationship with real time usage, same as synthetic benchmarks on a computer.

To summarize so far:

1. You proved that enabling decode on the on SDS and GDS slows down triggering rate. I agree it doesn't have to be implemented that way, even for software decode.
2. You noticed that SDS has noticeable pause displaying data that similar hardware on GDS doesn't. I agree Siglent could optimise that If GW Instek could.
3. You proved that hardware decoding Keysight doesn't slow down triggering rate if you enable decodes. It agrees with their specs and marketing.

That brings us to these observations:

4. You couldn't visually see any difference on display that would show SDS and GDS and Keysight had any difference in refresh rate.
5. You had to measure Trig Out frequency to actually figure out trigger rate. Super fast Keysight looked pretty much the same on the screen.
6. So only useful info from that measurement is not decoded data from 11000 frames, but only trigger frequency. Which is useful to, for instance, measure how many times a second sensor sends specific data. In which case you don't need decoding. You setup triggers to SPI and don't decode. Just measure trigger frequency. Of course, that is if SDS is dropping trigger rate because of decode and not for trigger itself being slow.
7. If you wanted to actually capture those 11000 frames to verify something, you will have to put all of them in segment mode. In which case (a fully unlocked) keysight 1000 will have a maximum of 50 segments. SDS supports up to 80000 segments.. So pretty much no limit. GDS seems not to have segmented memory officially, seems that hacked one does..

So that is actually what I want to say: if you are just looking at the scopes display you won't see a difference (apart from that lag) in screen refresh rate. Your eyes can't see a difference if scopes are triggering 1000x a second or 10000x a second. You won't see individual packets. You have to measure triggering frequency to know the difference, in which case you can simply disable decodes.. Because you can't read all of the 10000 packets in that second. On all of those scopes you will see just random packets that happen to coincide with screen refresh rate, and when you STOP you will see last one. On all of them.

With SDS you have the option to set triggers with no decodes, capture 10s of thousands of packets, stop it, enable decodes and then have all of them decoded, and with exact timing information for each one. You will have to do the same on Keysight but will have a max of 50 segments.

Don't get me wrong. 50 segments is plenty for most of cases. It's just that when we are comparing different designs, we cannot compare them directly. Every architecture will have it's strengths and weaknesses, and different ways to do same things and extract maximum from the instrument.
Because of much bigger memory, on Siglent you might as well just grab one single huge chunk of capture with hundreds of packets inside and just use search to find packets you want..

Keysight has 2GS/sec sampling rate (which helps with aliasing) and because of hardware decodes it doesn't slow down when you enable decodes.

Everything else is seriously better on Siglent. Memory, segmented memory(it is much larger that basic buffers), history buffers that run all the time, FFT, measurements that can be over whole memory buffer (Keysight runs over decimated subbuffer, even on 3000T series).. GDS will also be much better, except no history and only one 1GS/s A/D, and some other stuff it has like digital filters...

So depending of how you decide to use instrument, one or the other will be better.

I really appreciate your detailed analysis.

SDS without decode has the same trigger rate, so decode is not slowing down the refresh rate.

In my past life I worked in performance tuning at OS and application level for large enterprise systems, probably that is why I focus on refresh rate and LAG issues.

I agree that the measurements I am trying to make might not have real life use case implications.  Just experimentation and at the same time learn about scope architecture and STM32 microcontroller programming.

[TK]

OK, last test.  I upgraded to 180MHz on the STM32 microcontroller, generating the same SPI signal but with 22.5MHz SCK clock.

I am generating around 35,000 Frame 1 to Frame 8 cycles.

SDS and GDS keep same trigger rate of around 400Hz to 1-3KHz (huge variation).  Keysight increases trigger rate to 35,000 so it still captures 100% of the 0x74 bytes.

What I noticed is that SDS does not measure the SCK frequency correctly and it varies widely depending on the timebase setting.  It goes from detecting the correct 22.5MHz SCK when only 8 clock cycles are in screen to less than 10MHz when timebase is decreased to show more SCK cycles.

Can anyone explain this behavior?

Pictures attached.

[2N3055]

I really appreciate your detailed analysis.

SDS without decode has the same trigger rate, so decode is not slowing down the refresh rate.

In my past life I worked in performance tuning at OS and application level for large enterprise systems, probably that is why I focus on refresh rate and LAG issues.

I agree that the measurements I am trying to make might not have real life use case implications.  Just experimentation and at the same time learn about scope architecture and STM32 microcontroller programming.

And I understand your point. And not saying you're wrong. Me,  on the other hand, is all about being realistic and not buying marketing crap.
If I can pay less and have more I like it, even if I have to change how I work. I adapt and overcome..
Idea is that by discussing we can learn from each other. And I learned few interesting facts from you. Thanks for that.
Best regards,
Sinisa

[TK]

And SDS at some point runs out of decode memory as you can see in the captured picture...

[rf-loop]

And SDS at some point runs out of decode memory as you can see in the captured picture...

These limits have explained previously (SDS1000X-E).

One example here (also if I remember right more in some thread in eevblog but not remember where).

[nctnico]

Can anyone explain this behavior?

You get the average frequency and not the highest. You have to set gating (measure between two cursors or a defined area).

[rf-loop]

Can anyone explain this behavior?

You get the average frequency and not the highest. You have to set gating (measure between two cursors or a defined area).

Yes in SDS1000X-E there is measurement gate and gate time window defined using gate cursors, A and B . A for gate start and B for gate end.

[tautech]

OK, last test.  I upgraded to 180MHz on the STM32 microcontroller, generating the same SPI signal but with 22.5MHz SCK clock.

I am generating around 35,000 Frame 1 to Frame 8 cycles.

SDS and GDS keep same trigger rate of around 400Hz to 1-3KHz (huge variation).  Keysight increases trigger rate to 35,000 so it still captures 100% of the 0x74 bytes.

What I noticed is that SDS does not measure the SCK frequency correctly and it varies widely depending on the timebase setting.  It goes from detecting the correct 22.5MHz SCK when only 8 clock cycles are in screen to less than 10MHz when timebase is decreased to show more SCK cycles.

Can anyone explain this behavior?

When doing the BW tests and on previous Decode examples posted on EEVblog these variables have been encountered to impact on Decode and/or frequency measurements plus measurements in general.
In no specific order:
1. Trigger position.
2. Threshold settings
3. Probe compensation.

All 3 can have an impact at any one time depending on the task being performed and especially with waveforms displaying ringing which reduces the real vertical amplitude where Threshold and Trigger can operate without error.
When I see this I know it is my error and generally results from attempting to get accurate results in too much hurry but I am not accusing you of the same mistake and only bring this to your attention in case it is acting on your frequency measurement.

Thank you TK and Sinisa for your detailed investigations. 

Can anyone explain this behavior?

You get the average frequency and not the highest. You have to set gating (measure between two cursors or a defined area).

Yes in SDS1000X-E there is measurement gate and gate time window defined using gate cursors, A and B . A for gate start and B for gate end.

Yes any interrupted clock will not return the correct frequency measurement without defining a measurement Gate.