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

[alpher]

Well, seeing so many threads on the subject I've thought why not! 
I'm going to have to return Rigol 1054Z that I've had on loan  for last couple of years, no love lost here.
One thing I can say about the experience is that I just hate shared channel controls. I really do, most will say that you can get used to it,  I somehow  can't.
Already have a good analog scope (2465A ) and a decent high bandwidth DSO (54845A ), but firing up 1.5ghz hovercraft behemoth every time i want to see something simple on the screen ?
Tek being analog has it's issues also, that's where the trusty Rigol came to the rescue.
Now since I have to return the 1054z I'm looking for a replacement.
Requirements are in order of importance:

Separate controls for each channel (it's a must)
Responsive interface (nothing like sluggish 1054z)
Being hackable (since I will need serial decoding etc.)
4 channels would be nice but not absolutely necessary as long as serial decoding can use EXT trigger as a 3rd channel.
Decent display and nice fonts as my eyesight is not as it used to be.

Honestly I'm leaning towards the Keysight scope, as it will be more fun to hack (it requires quite a bit of hardware changes ) and when fully hacked will have arguably the best specs of the 3 (2Gsa, 250MHz).
But I'm open to any suggestions, especially from people that have 2 of them or more and can compare the experience.

Aha, the budget, they all within $500 ~$550 canadian rupies right now, Keysight being the cheapest at $503.

Thanks guys.

[Mortymore]

I believe that deep inside you already made a choice.

Go on and take the most fun out of it. After all you already are scope served.

[nctnico]

IMHO the EDUX1002A had too little memory (even with a hack). Remember that for an actual usage scenario the memory depth on a Keysight scope is 1/4 of what it says on the badge (and even less if you have digital channels).

[alpher]

IMHO the EDUX1002A had too little memory (even with a hack). Remember that for an actual usage scenario the memory depth on a Keysight scope is 1/4 of what it says on the badge (and even less if you have digital channels).

You have a valid point here, haven't thought about that. Could you elaborate a bit here?
Keysight 1Mpt, versus GWI 10Mpt, Siglent 7Mpt, in real word usage scenario will I see a big difference?

[nctnico]

The keyight has 250kpts (not 1Mpts) and yes this will make a big difference. With deep memory you can capture one trace at a slow time/div setting and scroll/zoom in on the details. You don't really have to care about the exact trigger condition. With shallow memory you'll loose details quickly which leads to needing multiple acquisitions and tedious trigger settings. You'll be wasting your time. Keysight makes great oscilloscopes (and other test equipment) but there just isn't enough memory in their oscilloscopes to be worth buying given the alternatives.

[alpher]

When talking about EDUX1002A I'm mentally jumping to the hacked specs so it should be 1Mpts.
But that aside if not Keysight then what?
Which of the 2 remaining? GW-Instek or Siglent?

[nctnico]

I'd get 4 channels if the budget allows it. IMHO 4 channels is a minimum requirement when you are designing circuits. Besides that: with 2 channels you can't do SPI decoding.

[alpher]

Do you really need 4 channels for spi ?
What about this then "
DSOX1EMBD Decodes and analysis for I2C, SPI, UART(RS-232) protocols Compatible with DSOX1102A or DSOX1102G"

Also Siglent lists spi available, while being 2 channel too?

[nctnico]

For SPI you need at least clock, data and enable.  But then you can only look at one side of the SPI bus and not on data-in and data-out. The Keysight uses the trigger input as a third channel so technically it can do SPI decoding. I don't know how the SDS102X-E handles SPI decoding. Maybe only clock and data but the absense of the select signal could make things difficult in situations where you have more then one SPI device connected to the same SPI bus.

[tautech]

For SPI you need at least clock, data and enable.  But then you can only look at one side of the SPI bus and not on data-in and data-out. The Keysight uses the trigger input as a third channel so technically it can do SPI decoding. I don't know how the SDS102X-E handles SPI decoding. Maybe only clock and data but the absense of the select signal could make things difficult in situations where you have more then one SPI device connected to the same SPI bus.

Exactly this ^

Other SDS1202X-E info
Quiet fan
All Decodes are free I2C, SPI, UART, CAN and LIN
Non hackable.....as in there's nothing that be hacked.

My current most popular seller.

[alpher]

How does the SDS1202X-E interface feels like? compared to the other 2 ?
I mean responsiveness and the display'font quality/size?
Also the cheapest I could find it in Canada was over $550, quite a bit more than both Keysight and GWI, (both around $500 ) .
Do you know a decent NA dealer that will sell for less than that?

[tautech]

How does the SDS1202X-E interface feels like? compared to the other 2 ?
I mean responsiveness and the display'font quality/size?
Also the cheapest I could find it in Canada was over $550, quite a bit more than both Keysight and GWI, (both around $500 ) .
Do you know a decent NA dealer that will sell for less than that?

These three 2ch models should offer similar responsiveness as they've all been around at least a couple of years.

I've not used the KS or GWI but I have no issues with how the SDS1202X-E behaves. Font's readability is related to colors used and the background they are on. Menus are on gray and channel display fonts (yellow or magneta) are on a black background.

Suppliers, well I guess you have some US/Canada border taxes so maybe Saelig pricing is not so hot however they do offer members here a discount. US list price is $ 379

Otherwise these are the authorized Canadian sellers for Siglent:
RCC Electronics
 905-669-6644
 www.rcce.com
 sales@rcce.com

Techno-Test
 450-681-5777
 www.Techno-Test.com
 info@techno-test.com

Test-Pal
 800-456-0961
 www.test-pal.com
 info@test-pal.com
 

[2N3055]

When talking about EDUX1002A I'm mentally jumping to the hacked specs so it should be 1Mpts.
But that aside if not Keysight then what?
Which of the 2 remaining? GW-Instek or Siglent?

Hacked specs mean 250kS per channel. 1MS divided by 4.
It is a big disadvantage for decoding.
If you plan to use decoding, Get a 4ch scope with long memory.
Also, if you do things where you need to take longer capture and then look at details you need long memory.

[nctnico]

Perhaps it is best to get both and return the one you like the least. When it comes to the UI preference is very personal.

One advantage of the GDS-1054B may be that it has vertical and horizontal menu buttons along the screen. This means that the menu structure is very flat and easy to use. I used to own an Agilent scope which only had one row of buttons at the bottom of the screen and navigating through the menu was a real nuisance compared to the GDS-2204E (the GDS1054B's big brother) I have.

[alpher]

When talking about EDUX1002A I'm mentally jumping to the hacked specs so it should be 1Mpts.
But that aside if not Keysight then what?
Which of the 2 remaining? GW-Instek or Siglent?

Hacked specs mean 250kS per channel. 1MS divided by 4.
It is a big disadvantage for decoding.
If you plan to use decoding, Get a 4ch scope with long memory.
Also, if you do things where you need to take longer capture and then look at details you need long memory.

Are you sure about that? I mean the specs sheet says 1Mpt for dsox series?
If what you're sayin is true then there is no contest , GDS is the winner?

[tautech]

IMHO the EDUX1002A had too little memory (even with a hack). Remember that for an actual usage scenario the memory depth on a Keysight scope is 1/4 of what it says on the badge (and even less if you have digital channels).

You have a valid point here, haven't thought about that. Could you elaborate a bit here?
Keysight 1Mpt, versus GWI 10Mpt, Siglent 7Mpt, in real word usage scenario will I see a big difference?

Oh and to point out 7M/ch.

[alpher]

Perhaps it is best to get both and return the one you like the least. When it comes to the UI preference is very personal.

One advantage of the GDS-1054B may be that it has vertical and horizontal menu buttons along the screen. This means that the menu structure is very flat and easy to use. I used to own an Agilent scope which only had one row of buttons at the bottom of the screen and navigating through the menu was a real nuisance compared to the GDS-2204E (the GDS1054B's big brother) I have.

I'll be buying it from Newark and honestly don't know about their return policy?
Never returned anything before , will I have to pay return shipping cost?

[nctnico]

I suppose you have to pay for return shipping but I'm not familiar with the Canadian laws regarding returns. But you better ask if they have a loan/test unit available. I doubt it for a relatively low cost piece of test equipment but you never know.

[nctnico]

Slow zoom/deep memory must be a problem specific for the Owon. The GW Instek will have no problem using long memory together with scrolling and zooming. I'm quite sure the same will apply to the Siglent.

[alpher]

Keysight 1Mpt, versus GWI 10Mpt, Siglent 7Mpt, in real word usage scenario will I see a big difference?

I run a 500kpts Keysight for years yet to see a need for more.
I had an Owon with 10Mpts, but at 10Mpts it takes too long to render so the screen update is not satisfiable for seeing glitches. I always had to dumb it down to 100kpts.

If you can set triggers properly, you should always never need to zoom out of your view.
And if you use Nth trigger, hold-off and segmented memory properly, you should always never need to zoom in either.

Wohoo , and to think that I was almost convinced to go with GWI?
Funny thing is that when I started this thread I was almost sure that I wanted a Keysight scope, yet deep down was expecting to be swayed to GWI first and finally to Siglent?
If I have to pay return shipping, buying all or even 2 of them is not an option.
I really don't want to spend more than necessary.

[Bud]

EDUX 1002A ticks many boxes in the wish list. You can't beat its hackability.

[nctnico]

But not 4 channels.

[tautech]

But not 4 channels.

Yep.
Channels, BW or memory. Pick any two.

[Mortymore]

Funny thing is that when I started this thread I was almost sure that I wanted a Keysight scope...

I had a feeling 

Well... If decoding you want, 4 channels you must.
So if... Keysight and Siglent... you know were that leads you.

Not speaking for the Keysight, I only would go to Siglent if it was the 4 channel version, but the vertical setup is like the Rigol you didn't like. I have a 2074E (GWI alike), not exactly the 1054B you are looking for, but I think you wouldn't be wrong with it.

[alpher]

Funny thing is that when I started this thread I was almost sure that I wanted a Keysight scope...

I had a feeling 

Well... If decoding you want, 4 channels you must.
So if... Keysight and Siglent... you know were that leads you.

Not speaking for the Keysight, I only would go to Siglent if it was the 4 channel version, but the vertical setup is like the Rigol you didn't like. I have a 2074E (GWI alike), not exactly the 1054B you are looking for, but I think you wouldn't be wrong with it.

 , You made my day here, but true it is?
Do you really must have 4 channels for serial work?
Wonder I?

[Mortymore]

For serial decoding it's not a requirement, if the external trigger will help.

sds1202x-e
https://www.siglent.eu/sds1202x-e.html

[tautech]

Do you really must have 4 channels for serial work?

What protocols do need you work with ?

For serial decoding it's not a requirement, if the external trigger will help.

sds1202x-e
https://www.siglent.eu/sds1202x-e.html

Last time I checked we couldn't use Ext trigger for Decode in Siglents.

I'll get a SDS1202X-E out and take a look to see if anything's changed.

@ alpher, any particular protocol you want a screenshot of ?

[nctnico]

But not 4 channels.

Yep.
Channels, BW or memory. Pick any two.

AFAIK the GDS1054B can be hacked to 200MHz but that will be supported on 2 channels only due to limited samplerate with 3 or more channels active.

[Mortymore]

Last time I checked we couldn't use Ext trigger for Decode in Siglents.

Hum... I thought that for SPI, 3 channels  (or 2+EXT) would be required, but seems I might be mistaken then, and extra channels are just handy.

[alpher]

Do you really must have 4 channels for serial work?

What protocols do need you work with ?

For serial decoding it's not a requirement, if the external trigger will help.

sds1202x-e
https://www.siglent.eu/sds1202x-e.html

Last time I checked we couldn't use Ext trigger for Decode in Siglents.

I'll get a SDS1202X-E out and take a look to see if anything's changed.

@ alpher, any particular protocol you want a screenshot of ?

Nothing in particular, maybe can?

[nctnico]

Even so with only 2 channels you run out of steam quickly. Even with 4 channels I try to use least channels as possible for decoding. Often there are other signals of interest. I wouldn't buy a scope with less than 4 channels for developing circuits (and preferably I'd buy an MSO so there are digital channels as well).

[alpher]

Even so with only 2 channels you run out of steam quickly. Even with 4 channels I try to use least channels as possible for decoding. Often there are other signals of interest. I wouldn't buy a scope with less than 4 channels for developing circuits (and preferably I'd buy an MSO so there are digital channels as well).

That is you, I most certainly can do with 2+ 1 .

[Mortymore]

I was checking the Siglent manual and it seems it is generic for the 1000X-E series since the manual states on the page 86:

Setup for SPI Signals

Setting the SPI (Serial Peripheral Interface) signal includes two steps:
connecting the CLK,  MISO,  MOSI  and  CS  signals  to  oscilloscope;  specifying  the  parameters  of  each input signal.

Of course this can't be applied to the 2 channel scope version, so, for SPI decoding with 2 channels, should be CLK mandatory and then MISO or MOSI, the one of interest, and SS ignored, as not really needed.
This would avoid the need for external trigger. Right?

I have to play more with decoding on my scope. 

PS: I thought that it would be each chanel for MOSI, MISO and EXT for CLK. But guessing now that it's not that way.

[tautech]

I was checking the Siglent manual and it seems it is generic for the 1000X-E series since the manual states on the page 86:

Setup for SPI Signals

Setting the SPI (Serial Peripheral Interface) signal includes two steps:
connecting the CLK,  MISO,  MOSI  and  CS  signals  to  oscilloscope;  specifying  the  parameters  of  each input signal.

Of course this can't be applied to the 2 channel scope version, so, for SPI decoding with 2 channels, should be CLK mandatory and then MISO or MOSI, the one of interest, and SS ignored, as not really needed.
This would avoid the need for external trigger. Right?

I have to play more with decoding on my scope. 

PS: I thought that it would be each chanel for MOSI, MISO and EXT for CLK. But guessing now that it's not that way.

Correct, there is no provision (with current latest firmware) to use EXT for any of the Decode Clock Sense.
So when we assign the channels in Decode, EXT is not available to select.

[tautech]

Nothing in particular, maybe CAN ?

CAN bus

Suitably stable triggering with just the correct Edge setting and some Holdoff. Zoom mode.


Decode ON.



List ON
The grayed out line represents the packet after the trigger point and so those that come before it are pre-trigger and those after post-trigger. It is always 1/2 way through the List. You can see this relationship in the timestamps.


Appropriate settings added in the Trigger menu (can be transferred with just a button press while in Decode menu)

[nctnico]

I suppose you can also trigger on specific CAN messages (address)? Usually there are several devices with different messages on a CAN bus so being able to trigger on specific messages is very handy (understatement) when dealing with a CAN bus.

[tautech]

I suppose you can also trigger on specific CAN messages (address)? Usually there are several devices with different messages on a CAN bus so being able to trigger on specific messages is very handy (understatement) when dealing with a CAN bus.

Yes, see last screenshot where the various Decode CAN trigger options are showing. They each have a further in-depth menu.

[alpher]

Looks really good, are these screen shots from SDS1202X-E ?

[nctnico]

One of the things to look out for is to see whether an oscilloscope decodes the entire memory or only what is on screen. I don't know if Siglent still only decodes what is on screen or whether they have fixed this. A work-around is to use the zoom function (as Tautech shows) on the Siglent scopes but that eats away part of the screen.

[tautech]

Looks really good, are these screen shots from SDS1202X-E ?

Yep, bright and shiny straight out of the box. ~ 1 month since production.

One of the things to look out for is to see whether an oscilloscope decodes the entire memory or only what is on screen. I don't know if Siglent still only decodes what is on screen or whether they have fixed this. A work-around is to use the zoom function (as Tautech shows) on the Siglent scopes but that eats away part of the screen.

No fix required, it's Siglent's way of doing the same thing.

There is a small off-display decode and I've shown that in previous posts.

There are many tricks one can use to use a scopes feature set and IIRC rf-loop decoded 1000 packets into the memory......but that may have been with the SDS1104X-E, I'd have to hunt the post out to check.
Here:
SDS1104X-E
https://www.eevblog.com/forum/testgear/(ask)-about-my-oscilloscope-i-recently-bought/msg2319450/#msg2319450

[Mortymore]

Dave Jones might be of some help about decoding on Siglent 1000X-E



I saw this video long time ago, but forgotten about it 

PS: Note however, that some things may have changed in the meantime due to firmware upgrades

[nctnico]

One of the things to look out for is to see whether an oscilloscope decodes the entire memory or only what is on screen. I don't know if Siglent still only decodes what is on screen or whether they have fixed this. A work-around is to use the zoom function (as Tautech shows) on the Siglent scopes but that eats away part of the screen.

No fix required, it's Siglent's way of doing the same thing.

I was hoping Siglent had abandoned that but appearantly not. Too bad because every other oscilloscope I know of decodes the entire memory.

[rf-loop]

One of the things to look out for is to see whether an oscilloscope decodes the entire memory or only what is on screen. I don't know if Siglent still only decodes what is on screen or whether they have fixed this. A work-around is to use the zoom function (as Tautech shows) on the Siglent scopes but that eats away part of the screen.

One of the things to look out for is to see whether an oscilloscope decodes the entire memory or only what is on screen. I don't know if Siglent still only decodes what is on screen or whether they have fixed this. A work-around is to use the zoom function (as Tautech shows) on the Siglent scopes but that eats away part of the screen.

No fix required, it's Siglent's way of doing the same thing.

I was hoping Siglent had abandoned that but appearantly not. Too bad because every other oscilloscope I know of decodes the entire memory.

SDS1000X-E decode works always with full memory. This have been discussed several times over long time. I do not understand why you spread this question/bullshit in every corner time after time.

And more. what ever is current used acquisition memory lenght it is always same as visible trace length when scope is running without anmy exception. (no hidden unvisible part of trace out of display) Sigleent have selectet this method and that's it. Others can do how they want, Siglent do not need copycat these.
Of course all methods have advantages and disadvvantages. But as told and proofed many times, Siglent decode online or offline full memory length as long as there is not other things what reduce decoded data length. Also it do it from history.
If it is impossible to understand that whole memory length is always on screen when scope is running then - no one can help.  Of course in stop mode diplay can be small portion of whole length but still it decode from acquisition memory and not from display buffer.

Of course you can  still continue endless this bullshit. I hope it make you happy. Period.

[tautech]

Dave Jones might be of some help about decoding on Siglent 1000X-E



I saw this video long time ago, but forgotten about it 

PS: Note however, that some things may have changed in the meantime due to firmware upgrades

Heaps has changed. First, that was a pre-release SDS1102X-E that has never been released into western markets where we have only ever seen SDS1202X-E.
10 specifically identified Decode bug fixes listed in the firmware release notes:
https://www.siglentamerica.com/wp-content/uploads/dlm_uploads/2018/09/SDS1000X-E_Release_Notes.pdf

One need always take old videos with a grain of salt until some simple homework is done.

[Mortymore]

One need always take old videos with a grain of salt until some simple homework is done.

For sure!
That's why I added the note about firmware upgrades may have changed things. That, and because I knew when you saw this, you would bring some clarification. 
Thanks

[nctnico]

One of the things to look out for is to see whether an oscilloscope decodes the entire memory or only what is on screen. I don't know if Siglent still only decodes what is on screen or whether they have fixed this. A work-around is to use the zoom function (as Tautech shows) on the Siglent scopes but that eats away part of the screen.

One of the things to look out for is to see whether an oscilloscope decodes the entire memory or only what is on screen. I don't know if Siglent still only decodes what is on screen or whether they have fixed this. A work-around is to use the zoom function (as Tautech shows) on the Siglent scopes but that eats away part of the screen.

No fix required, it's Siglent's way of doing the same thing.

I was hoping Siglent had abandoned that but appearantly not. Too bad because every other oscilloscope I know of decodes the entire memory.

SDS1000X-E decode works always with full memory. This have been discussed several times over long time. I do not understand why you spread this question/bullshit in every corner time after time.

You never understood how decoding should work. The way Siglent works makes operating the oscilloscope way more tedious compared to other oscilloscopes. There is no argueing around that. Get some other oscilloscopes and you'll see why. And 'full memory' means full memory and not a part of what is on screen. I nearly forgot about all the strange ways Siglent scopes work compared to other brands so thanks for reminding me. Siglent doesn't want to copycat so they put square wheels on their car 

[2N3055]

One of the things to look out for is to see whether an oscilloscope decodes the entire memory or only what is on screen. I don't know if Siglent still only decodes what is on screen or whether they have fixed this. A work-around is to use the zoom function (as Tautech shows) on the Siglent scopes but that eats away part of the screen.

Nctnico,
for some time now I've been meaning to ask you what do you mean by "decode entire memory"?

Let's take single shot mode.
Scope takes a sample that is a time length of screen. There is no data before or after what is on the screen. I don't need data before or after what I instructed scope to capture, perfectly aligned to trigger event. Screen is entire memory. In segmented mode, there will be several such screens each complete memory for that captured segment. Also each segment aligned around it's trigger even, as instructed.

So if I wan't to grab 100 ms worth of data, I set scope to grab 100 ms worth of data. There are 10 SPI packets in there for instance. I open table decode view and I see all of them. In graphic decode, I don't se anything, it's too small. So I zoom in to individual packet, and I also see graphic decode for the zoomed portion, together with full table for the whole capture.
Good decoders will be able to handle when you zoom in to two partial packets, and will show correctly decodes for only portion of packet on the screen.

This is something that didn't work on Rigol DS1000Z. It would properly decode in the table long full screen of data, but as soon as you would zoom in on portion, it would only decode zoomed in part like the rest of the buffer didn't exist. Also decodes didn't work for segmented memory.
That is a bad implementation, absolutely agree.

But that was only 1000Z. Other Rigols (2000, 4000) this worked well. I don't know, but Siglents shouldn't have that problem either.

Is that what you mean?

Or you are referring to how with Keysight , on a stopped capture, if you change timebase after capture, it still shows a full table decode for whole captured initial screen, although you are showing only portion of capture? That is pretty much equivalent to using zoom, but without overview window.  no, wait, that is exactly the same thing as using zoom without overview window.
I could see it being useful to optimize screen usage, but to me using zoom has advantage that i have zoom overview window so I know where I am in the capture.

Regards,

[rf-loop]

One of the things to look out for is to see whether an oscilloscope decodes the entire memory or only what is on screen. I don't know if Siglent still only decodes what is on screen or whether they have fixed this. A work-around is to use the zoom function (as Tautech shows) on the Siglent scopes but that eats away part of the screen.

One of the things to look out for is to see whether an oscilloscope decodes the entire memory or only what is on screen. I don't know if Siglent still only decodes what is on screen or whether they have fixed this. A work-around is to use the zoom function (as Tautech shows) on the Siglent scopes but that eats away part of the screen.

No fix required, it's Siglent's way of doing the same thing.

I was hoping Siglent had abandoned that but appearantly not. Too bad because every other oscilloscope I know of decodes the entire memory.

SDS1000X-E decode works always with full memory. This have been discussed several times over long time. I do not understand why you spread this question/bullshit in every corner time after time.

You never understood how decoding should work. The way Siglent works makes operating the oscilloscope way more tedious compared to other oscilloscopes. There is no argueing around that. Get some other oscilloscopes and you'll see why. And 'full memory' means full memory and not a part of what is on screen. I nearly forgot about all the strange ways Siglent scopes work compared to other brands so thanks for reminding me. Siglent doesn't want to copycat so they put square wheels on their car 

It decode full current acquisition memory length. Your continuous claim or suspect have been that it do not. It decode full acquisition memory length - only exception is if maximum amount of decoded data is reached what limit can see in next images.

In next two images. This is only limit when it do not decode full memory length.
There is decoded 2 fully independent I2C bus. Other decoder (2) reach max 1000msg (32000 bytes) around half of memory and decoder 1 nearly end of memory reach limit 1000msg (including 32000 bytes also).
Of course decode result can not see in bottom because density. But decode table include all but it can display only one selected decoder. Next image show same zoomed to details and all is decoded. I can not see any reason why we need remove this upper half of image what show whole memory length. It also give information to user even if in this case not much. What it helps if we remove this whole memory diosplay. Many scopes leave lot of signal out from display. Yes I know it take some processing power for display whole length and map it for display without decimation. Why want make user blind for more or less amount of whole length and then advertise we decode full memory like some miracle happen. Oh well, Siglent do not even need advertise it. It is natural that all displayed and so also whole memory length is decoded without any extra explanation that we decode full length. It do it always and also give user some overall vision about what happen there in whole length, what some others want hide, example some pause in transmission or so on. Why anyone want make user blind and hide part of trace out from display.





Same with SDS1202X-E but now only one decoder can use of course, no possible for two simultaneous independent decoder due to lack of channels in this case.


I'm very interested to see after someone repeat this same example with EDUX1002A or GDS-1054B.
Least this Keyshit EDUX drops out like chicken if it try fly. How about OP's third example model GoodWill 1054B.

[nctnico]

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

[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.

[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.

[TK]

I applied Gated measurement and now the reported frequency is correct

[TK]

All these extensive tests paid off... I found a bug in the serial trigger function.  The Data bits you set for triggering get reset to all 0 when the scope is turned off, so you turn the scope on to continue your work and you need to set again the data bits.

[Rerouter]

Out of curiousity TK if you save it as a setup, does it recall correctly after startup?, Currently looking into how and where the siglent preserves settings over power cycles.

[TK]

Saving it as a setup, does NOT recall it correctly.  Recalled value is all 0s.

[TK]

I modified the code to generate an SPI packet with single byte 0x75 when a button is pressed, and asked the Siglent to trigger on this value.  My test setup is generating 280,000 SPI packets per second and the scope was able to trigger on every single byte value 0x75 I put out with the button.  I am trying to see if it can still trigger for 0x75 (and do a SINGLE capture) while at the same time is triggering (NORMAL mode) on byte value 0x74, but I am not finding an easy solution to do it.

The test case is getting complex and I don't think there a real life use case for it, so I am stopping my tests for now.

[TK]

OK, thanks to a suggestion from user 2N3055 to use SPI trigger on 0x74 and a mask on 0x75, I was able to test the new challenge on the Keysight and the Siglent

I had to change the bytes to 0x37 and 0x3F (because the Keysight expects a trigger on all the bits of the SPI frame), but you can indicate only the first byte if you are triggering on the first byte, but need to indicate all the bits of the frame if it is the last byte.

So I changed the code to generate 0x3F when a button was pressed.  Defined the Pass/Fail mask on 0x37 and set to trigger on 0011 X111 to trigger on 0x37 or 0x3F. 

When I pressed the button several times on the Keysight, it catches 50% to 75%.  So far, I cannot get the SDS1104X-E to catch a single one.  It catches 100% if I set the trigger on 0011 0111, but does not catch 0011 1111 when the trigger is set to 0011 X111.

[alpher]

Jeez guys you're still going at this?
Quite frankly I felt even dumber (if that's possible) after reading first couple of pages of replies.
So I just went with my first instinct, bought an EDUX, quite busy right now getting my RV ready for the season, so any hackin' has to wait.
Thank you anyway, very informative reading.

[TK]

I increased the SPI clock speed to 45MHz.  It means 50,000 x 8 = 400,000 SPI messages per second.  50,000 messages containing the byte 0x37.  Siglent SDS1104X-E can trigger 3,000 per second.  It does not detect the random glitch (byte value 0x3F) when the button is pressed.  Keysight EDUX1002G can trigger all 50,000 per second!.  It still can detect the random glitch, but around 10-30% of the time.

[BillB]

Jeez guys you're still going at this?
Quite frankly I felt even dumber (if that's possible) after reading first couple of pages of replies.
So I just went with my first instinct, bought an EDUX, quite busy right now getting my RV ready for the season, so any hackin' has to wait.
Thank you anyway, very informative reading.

You've chummed the waters and are surprised there is a frenzy?  I can't even think of a topic that would garner more activity than a scope n-way p*ssing contest...

Anyway, congrats on making a decision and moving on with life!  Remember, those afflicted with TEA don't have it so easy.   

[Old Printer]

I spent 2 years making my decision for my first digital scope, though I had picked up an AD2 to go with my Tek 2225 so I wasn't naked while I deliberated. A few weeks ago I pulled the trigger on a SDS1104X-E and so far very happy. Then I see TK's tests and my heart sank, my choice was not doing well, but then I realize I don't really know what he is doing and it is unlikely to ever have any impact on me - I hope Have not even bothered to hack it yet.

[TK]

I spent 2 years making my decision for my first digital scope, though I had picked up an AD2 to go with my Tek 2225 so I wasn't naked while I deliberated. A few weeks ago I pulled the trigger on a SDS1104X-E and so far very happy. Then I see TK's tests and my heart sank, my choice was not doing well, but then I realize I don't really know what he is doing and it is unlikely to ever have any impact on me - I hope Have not even bothered to hack it yet.

Please don't feel bad about your decision on the SDS1104X-E.  I like it very much.  As I said before, I worked long time on performance tuning on large computing systems, so that is why I run these tests, just out of curiosity.  I am not sure if it has any real use case... and the Keysight 1000X does not have serial decoding list function and the sample memory is only 1Mpts, but has a very fast scrolling horizontal knob 

[tautech]

I spent 2 years making my decision for my first digital scope, though I had picked up an AD2 to go with my Tek 2225 so I wasn't naked while I deliberated. A few weeks ago I pulled the trigger on a SDS1104X-E and so far very happy. Then I see TK's tests and my heart sank, my choice was not doing well, but then I realize I don't really know what he is doing and it is unlikely to ever have any impact on me - I hope Have not even bothered to hack it yet.

Please don't feel bad about your decision on the SDS1104X-E.  I like it very much.  As I said before, I worked long time on performance tuning on large computing systems, so that is why I run these tests, just out of curiosity.  I am not sure if it has any real use case... and the Keysight 1000X does not have serial decoding list function and the sample memory is only 1Mpts, but has a very fast scrolling horizontal knob 

TK, you know a fairer comparison would be between similar Sa/s rate DSO's eg. SDS2000X-E models that have the same sampling rate as your KS.
Double the sample passing through the scope will impact on signal triggering.
We saw how much higher frequency it could accurately resolve vs a 1 GSa/s DSO in your BW testing thread.
Unfortunately they're only available in 2ch models. 

[2N3055]

I spent 2 years making my decision for my first digital scope, though I had picked up an AD2 to go with my Tek 2225 so I wasn't naked while I deliberated. A few weeks ago I pulled the trigger on a SDS1104X-E and so far very happy. Then I see TK's tests and my heart sank, my choice was not doing well, but then I realize I don't really know what he is doing and it is unlikely to ever have any impact on me - I hope Have not even bothered to hack it yet.

What TK said..

Despite fact that it has slower triggering frequency, I still firmly believe SDS1104X-E is much better all rounder and much better bang for the buck than Keysight 1000.
If you just want digital replacement for your analog scope Keysight is great at that.
But if you use new digital scope as a new digital scope with all advantages that carries, SDS1104X-E is more capable in several areas.

There is no practical use for 50000 triggers per second on SPI packets.
If you wanted to catch elusive random glitch (byte value 0x3F) in a sea of 50,000 messages containing the byte 0x37, you would just set trigger to byte value 0x3F and catch them 100% of the time until there is several thousands of them per second. In which case I wouldn't call them elusive.

If anything, this kind of investigations show how advanced these inexpensive instruments are.

[TK]

I spent 2 years making my decision for my first digital scope, though I had picked up an AD2 to go with my Tek 2225 so I wasn't naked while I deliberated. A few weeks ago I pulled the trigger on a SDS1104X-E and so far very happy. Then I see TK's tests and my heart sank, my choice was not doing well, but then I realize I don't really know what he is doing and it is unlikely to ever have any impact on me - I hope Have not even bothered to hack it yet.

Please don't feel bad about your decision on the SDS1104X-E.  I like it very much.  As I said before, I worked long time on performance tuning on large computing systems, so that is why I run these tests, just out of curiosity.  I am not sure if it has any real use case... and the Keysight 1000X does not have serial decoding list function and the sample memory is only 1Mpts, but has a very fast scrolling horizontal knob 

TK, you know a fairer comparison would be between similar Sa/s rate DSO's eg. SDS2000X-E models that have the same sampling rate as your KS.
Double the sample passing through the scope will impact on signal triggering.
We saw how much higher frequency it could accurately resolve vs a 1 GSa/s DSO in your BW testing thread.
Unfortunately they're only available in 2ch models. 

Actually my test is making the KS to sample at 1 GSa/s because I am using the external input.  It keeps 2 GSa/s when using up to 2 analog channels, but goes down to 1 GSa/s when the external input is enabled.

[Old Printer]

I spent 2 years making my decision for my first digital scope, though I had picked up an AD2 to go with my Tek 2225 so I wasn't naked while I deliberated. A few weeks ago I pulled the trigger on a SDS1104X-E and so far very happy. Then I see TK's tests and my heart sank, my choice was not doing well, but then I realize I don't really know what he is doing and it is unlikely to ever have any impact on me - I hope Have not even bothered to hack it yet.

Please don't feel bad about your decision on the SDS1104X-E.  I like it very much.  As I said before, I worked long time on performance tuning on large computing systems, so that is why I run these tests, just out of curiosity.  I am not sure if it has any real use case... and the Keysight 1000X does not have serial decoding list function and the sample memory is only 1Mpts, but has a very fast scrolling horizontal knob 

TK, you know a fairer comparison would be between similar Sa/s rate DSO's eg. SDS2000X-E models that have the same sampling rate as your KS.
Double the sample passing through the scope will impact on signal triggering.
We saw how much higher frequency it could accurately resolve vs a 1 GSa/s DSO in your BW testing thread.
Unfortunately they're only available in 2ch models. 

Not to worry, really. It was just a second of second guessing myself before it registered that these are just hobby machines. We have come so far in what is available and at what prices, that at least I tend to get greedy. I would have cherry picked options from four different machines to get all the stuff i wanted, individual channel controls, HDMI output etc. At some point you just have to draw a line and say enough is enough, unless you have some particular needs but I really did not.

[2N3055]

Not to worry, really. It was just a second of second guessing myself before it registered that these are just hobby machines. We have come so far in what is available and at what prices, that at least I tend to get greedy. I would have cherry picked options from four different machines to get all the stuff i wanted, individual channel controls, HDMI output etc. At some point you just have to draw a line and say enough is enough, unless you have some particular needs but I really did not.

I wouldn't even say that they are hobby machines. Pretty much all other scopes except Megazoom based Keysight scopes will have same or worse retrigger rate than lowly SDS1104X-E.
In real world work it doesn't matter. Professionals don't spend time benchmarking scopes, they use them to design and troubleshoot stuff they work on.

In real life superfast rettriger rate of my Keysight 3000T is rarely useful, and even more rarely necessary.
On a Picoscope with 512 MPoints mem, I can grab ALL of 50000 packets in one go, and then make detailed analysis of data and timings.
I can create analysis of packet time distribution, data distribution, and try to correlate problematic data with outside world...

With  SDS1104X-E you can do more of that than on a scope with 28 times less memory and only 50 segments....


 

[branchmispredictor]

On a Picoscope with 512 MPoints mem, I can grab ALL of 50000 packets in one go, and then make detailed analysis of data and timings.
I can create analysis of packet time distribution, data distribution, and try to correlate problematic data with outside world...

Would a Picoscope be a good supplement to a SDS1104X-E then, for capturing high speed data? Which one would you recommend?

[TK]

On a Picoscope with 512 MPoints mem, I can grab ALL of 50000 packets in one go, and then make detailed analysis of data and timings.
I can create analysis of packet time distribution, data distribution, and try to correlate problematic data with outside world...

Would a Picoscope be a good supplement to a SDS1104X-E then, for capturing high speed data? Which one would you recommend?

If you want to supplement an SDS1104X-E, the best option is to get a logic analyzer.  I use the Zeroplus which offers over 100 protocols, but the software only runs on Windows.  It has it's own sample memory and triggers in hardware.  You can get the basic one with 16 channels and 64K memory for around $130, you have other options with more channels and more memory, up to 32 channels and 2Mb per channel, but price jumps over $1000.  You can use the SDS1104X-E for signal integrity and trigger the zeroplus or viceversa (it has trigger in and trigger out).

Saleae runs on windows, linux and mac os x... but I consider the hardware to be pretty limited and overpriced, usually captures to PC memory and does post processing, with no or limited on device sample memory.

Another option is an open source logic analyzer with pulseview.

[Old Printer]

I wouldn't even say that they are hobby machines. Pretty much all other scopes except Megazoom based Keysight scopes will have same or worse retrigger rate than lowly SDS1104X-E.
In real world work it doesn't matter. Professionals don't spend time benchmarking scopes, they use them to design and troubleshoot stuff they work on.

In real life superfast rettriger rate of my Keysight 3000T is rarely useful, and even more rarely necessary.
On a Picoscope with 512 MPoints mem, I can grab ALL of 50000 packets in one go, and then make detailed analysis of data and timings.
I can create analysis of packet time distribution, data distribution, and try to correlate problematic data with outside world...

With  SDS1104X-E you can do more of that than on a scope with 28 times less memory and only 50 segments....

I understand what you are saying, I just meant it is a hobby machine for me and at my level of experience I could have bought a much less capable tool, but I like my toys to be as good as I can afford.

[jemangedeslolos]

Hello TK,

I wanted to test quickly high speed SPI decoding on my SDS2204X ( I don't have a SDS1000X-E ).
So I made a program on my NucleoF446 with 45Mhz SPI clock.....and I have very strange result.

With my SP2030A, the clock signal is...ugly. I have much better result with my cheap P6100 100Mhz probe !
I never used SPI clock that high, maybe I made something wrong with my measure but with the P6100, the clock signal integrity looks OK.

I saw post from Performa01 who test different probe and it seems that there is no issue with the SP2030A.
Maybe you use a specific technic to measure 45Mhz clock ?

[jemangedeslolos]

Hello,

My daugther is sick, so I took with me the oscilloscope and now I have no issue with the same SP2030A on the same channel...
Very strange as I double check connections on my lab at work.

So I configure my NucleoF446 and now I wondering how do you compute the triggering rate ?
With the time on the decode list or there is hidden option are a specific technic ?

Thank you

I have a SDS2204X and a Rigol MSO5074 so maybe my result will be usefull for someone.

[TK]

To measure the trigger rate, you connect the trigger out from the Siglent to another scope input and just measure the frequency.

[jemangedeslolos]

Ah ok, I don't know why, I was convinced that the SDS1000X didn't have a trigger out BNC   
 
Thank you TK