EEVblog #1312 - Siglent Oscilloscopes CRIPPLING History Mode!

[JPortici]

The way Siglent implemented it is like you need to know beforehand what you want to capture and set the right timebase before.  I used the SDS2104X plus to capture SPI data, decoded information in screen was not enough and wanted to see more... You cannot.  You need to set a new timebase and capture again.  You might have lost your golden opportunity of capturing the fault.  You end up doing 3-5 captures until you get what you want to see.  Or like some member said, capture and zoom in... it is ridiculous.  In my new GW-Instek GDS1054B, I capture and then zoom out and in as I like to find what I want to see in detail.  This is why UI responsiveness is important.  Rigol can capture full memory, but scrolling is painful.  Keysight is ultra fast and GW-Instek is fast too.

EVERY time i had to do this i could retrigger the capture at any given time so nothing of importance was lost, adjust and re-do it.
OR since my scope is not retarded and decodes data from memory, not screen, i set a stupidly slow timebase, acquire and then zoom in to the incriminated packets

[maginnovision]

Automatic history mode is one of the most useful features of the scope.
I get it, you are not used to having it because your scope has a different design philosophy.

But stop asking them to cripple our scopes because you can't get it.

My primary scope literally has that feature. It also has user selected memory depths that work.

[tom66]

I would be genuinely surprised if any <$5,000 USD scope can process 2GSa/s of real data and display it.

You'd better sit down before you watch this:

500k waveforms/sec is not the same as rendering 2GSa/s of data.  It is impressive, no doubt, but the instrument still has blind time.    To render every single sample that is captured, the processor needs to be able to plot 2 billion pixels per second, which would put it at the speed of a desktop-class GPU.

There's a simple test to see if the Rigol is doing this: at the timebase that offers the maximum 500kwaves/sec acquisition rate, how long is the record?  It would need to be 2,000 entries long (assuming 2GSa/s acquisition.)  Anything less, and it has blind time. Even the 1 million wfm/sec Keysights have blind time.

Still, I stand to be corrected.

[Fungus]

...would put it at the speed of a desktop-class GPU.

It has a custom ASIC for the job, yes.

(...presumably because even a custom ASIC is cheaper than an FPGA with enough power)

[tom66]

...would put it at the speed of a desktop-class GPU.

It has a custom ASIC for the job, yes.

(...presumably because even a custom ASIC is cheaper than an FPGA with enough power)

I thought the ASIC was for acquisition, not display. This diagram (pg 2) seems to indicate rendering points is done in either an FPGA or DSP/CPU and is not part of Phoenix II:
https://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0907/1/-/-/-/-/MSO5000_datasheet.pdf

As I understand it, the push towards ASIC is primarily cost.  The FPGA required to do some of the high-performance stuff that Rigol is now doing would get rather expensive.  Cheaper to get an ASIC taped out now. 

[tautech]

Well, we agree that the maximum memory has to be ignored in normal trigger mode since else the trigger/update rate would drop dramatically? Besides who defines what "outside" the screen has to be captured? Will "outside" left and "outside right" be the same? Obviously everything outside the screen is pretty much undefined and implementing something there will raise a lot of other questions like if the measurements are limited to the onscreen area, how to move measurement gates offscreen etc.

No, I can't accept the presumption that I always want a fast update rate.  2Gsa/S with 200M pts is still 10 frames per second, less overhead.  If that's not fast enough, I can lower the memory to a measly 20M pts.

I would be genuinely surprised if any <$5,000 USD scope can process 2GSa/s of real data and display it.  Realistically, it's going to be around 1-2 frames a second because the instrument will be only able to process and render so many samples. At which point the user wonders, why *is* it so slow?  Piece of junk!

I do think Siglent should make this behaviour more intuitive or optional though.  It's nice to see the history mode built into the normal usage of the scope (so often it is buried away in menus and doesn't function the same as normal acquisition) but the behaviour of setting a long record length and not getting that record length is not obvious.

It is if you RTFM.
https://siglentna.com/wp-content/uploads/dlm_uploads/2020/01/SDS2000X_Plus_UserManual_UM0102XP-E01B.pdf
P 81

[nctnico]

The way Siglent implemented it is like you need to know beforehand what you want to capture and set the right timebase before.  I used the SDS2104X plus to capture SPI data, decoded information in screen was not enough and wanted to see more... You cannot.  You need to set a new timebase and capture again.  You might have lost your golden opportunity of capturing the fault.  You end up doing 3-5 captures until you get what you want to see.  Or like some member said, capture and zoom in... it is ridiculous.  In my new GW-Instek GDS1054B, I capture and then zoom out and in as I like to find what I want to see in detail.  This is why UI responsiveness is important.  Rigol can capture full memory, but scrolling is painful.  Keysight is ultra fast and GW-Instek is fast too.

EVERY time i had to do this i could retrigger the capture at any given time so nothing of importance was lost, adjust and re-do it.

But it is more work and for some measurements it means needing a lot more time due to the rarity of an event. It just isn't an efficient way to work especially if nobody is paying for the extra time spend on a problem.

Let me ask you: would you rather sit on a wooden stool or a comfortable office chair while you work? Most people will choose the latter; why would someone have to put up with tools which don't offer comfort?

Automatic history mode is one of the most useful features of the scope.
I get it, you are not used to having it because your scope has a different design philosophy.

But stop asking them to cripple our scopes because you can't get it.

Why do you believe it is going to cripple anything? For example: Yokogawa and R&S scopes (RTB2000 & RTM3000) can operate in both ways perfectly without any downsides. It just adds more flexibility. I fail to see why people insist that adding more flexibility is somehow limiting other features. It doesn't! People who claim allowing to select between automatic and full memory mode is somehow impacting history mode are just spreading FUD.  Don't give in to fear for the unknown.

You know what: I'll buy your Siglent scope for the retail price (at that time) if it turns out adding support for fixed memory length recording somehow cripples history mode in automatic memory length mode.

[0xdeadbeef]

@0xdeadbeef: you are overthinking things and focussing way too much on waveforms/s. On all DSOs which do capture beyond the screen you can either choose auto mode or set the memory very short to get the highest waveform/s rate. On most DSOs I have come across you can set a gate for the measurements at any point in the acquisition record OR just scroll the screen left/right so that is covered too. There are no trade-offs; just more flexibility for the user to optimize the oscilloscope for a particular job.

I'm not focusing on display (intensity graded) waveforms/s in the Agilent/Keysight way of thinking at all. My main focus is to get as many automatic measurements per second as possible with as little deadtime as possible. So it's more about measurements per second than "displayed" (intensity graded) waveforms per second. And I certainly don't want to change the maximum memory size all the time when I change the time scale just to make sure that I get the fastest possible update rate with the current time scale without deliberately sacrificing capture rate due to memory limitations. This would be severely crippling functionality from my point of view. Also, as mentioned before, gating might be necessary for measurements. And setting up the gates is only sensibly possible if they are displayed inside the well defined onscreen area.
BTW: what everybody seems to ignore is that (at least in the manual) the memory setting is called "maximum memory depth". I think in LeCroy scopes, it's actually called "maximum" in the menu. And that's what it is: it is the maximum memory that will be used if the horizontal settings require it. It doesn't say "guaranteed", so claiming that Siglent's wouldn't use the memory as configured just shows that people didn't read or understand the manual.

So sorry, but from my point of view using all the configured maximum memory by default despite of the horizontal settings would only make sense in single trigger mode and I'd actually welcome this change in the Siglent firmware since there aren't any obvious drawbacks if done properly. Note though that even in single trigger mode, there are several things to be considered, i.e. if decoding and measurement is done on the complete buffer or only the onscreen area - again this also a problem of moving the gates outside the screen which is somewhat unfeasible. Anyway, for normal mode, I'd only accept using all the configured maximum memory per capture if this could be turned off in favor of the more sensible default mode (capture only onscreen to avoid futile dead time). Nobody would complain about an additional feature but changing a sensible default into something that would actually be a severe limitations for existing users is most certainly not desirable.

But again, not having this feature is neither dumb nor crippling. When setting up a trigger properly, there shouldn't be the need to rely on some more or less randomly captured  data outside the screen. IMHO this is partly an ideological debate between uers of pseudo-analog scopes like Agilent/Keysight and users of real DSOs optimized for measurements like LeCroys.

[nctnico]

Ask yourself why you couldn't use normal mode if you have control over the trigger events externally. In such a case resetting single mode for each measurement  is just an unnecessary step. And I'm not thinking about something hypothetical here; I am using oscilloscopes in this way. The less I have to mess with setting up an oscilloscope the better.

I also don't think you have to seperate between real or pseudo analog oscilloscopes. It is clear oscilloscopes are made for a certain market segment. However the more competition across segments the better.

Today I have used both my Lecroy and GW Instek (with the latter sitting on top of the former). The Lecroy is nice for making measurements while the GW Instek is more conventient to use for circuit debugging.

[snoopy]

The way Siglent implemented it is like you need to know beforehand what you want to capture and set the right timebase before.  I used the SDS2104X plus to capture SPI data, decoded information in screen was not enough and wanted to see more... You cannot.  You need to set a new timebase and capture again.  You might have lost your golden opportunity of capturing the fault.  You end up doing 3-5 captures until you get what you want to see.  Or like some member said, capture and zoom in... it is ridiculous.  In my new GW-Instek GDS1054B, I capture and then zoom out and in as I like to find what I want to see in detail.  This is why UI responsiveness is important.  Rigol can capture full memory, but scrolling is painful.  Keysight is ultra fast and GW-Instek is fast too.

When you zoom out on the siglent and start panning the data across the screen does the data become corrupted and change value as it is moved along the screen or is the trigger reference point for the decoding always preserved ?

Can someone do a video on this comparing different scopes because I know the Rigol 1054Z fails this test.

cheers

[TK]

The way Siglent implemented it is like you need to know beforehand what you want to capture and set the right timebase before.  I used the SDS2104X plus to capture SPI data, decoded information in screen was not enough and wanted to see more... You cannot.  You need to set a new timebase and capture again.  You might have lost your golden opportunity of capturing the fault.  You end up doing 3-5 captures until you get what you want to see.  Or like some member said, capture and zoom in... it is ridiculous.  In my new GW-Instek GDS1054B, I capture and then zoom out and in as I like to find what I want to see in detail.  This is why UI responsiveness is important.  Rigol can capture full memory, but scrolling is painful.  Keysight is ultra fast and GW-Instek is fast too.

When you zoom out on the siglent and start panning the data across the screen does the data become corrupted and change value as it is moved along the screen or is the trigger reference point for the decoding always preserved ?

Can someone do a video on this comparing different scopes because I know the Rigol 1054Z fails this test.

cheers

I sold my scope, so from memory I can tell you that scrolling while zoomed out, it will give you packet errors unless you have a valid frame starting within the screen.

[snoopy]

The way Siglent implemented it is like you need to know beforehand what you want to capture and set the right timebase before.  I used the SDS2104X plus to capture SPI data, decoded information in screen was not enough and wanted to see more... You cannot.  You need to set a new timebase and capture again.  You might have lost your golden opportunity of capturing the fault.  You end up doing 3-5 captures until you get what you want to see.  Or like some member said, capture and zoom in... it is ridiculous.  In my new GW-Instek GDS1054B, I capture and then zoom out and in as I like to find what I want to see in detail.  This is why UI responsiveness is important.  Rigol can capture full memory, but scrolling is painful.  Keysight is ultra fast and GW-Instek is fast too.

When you zoom out on the siglent and start panning the data across the screen does the data become corrupted and change value as it is moved along the screen or is the trigger reference point for the decoding always preserved ?

Can someone do a video on this comparing different scopes because I know the Rigol 1054Z fails this test.

cheers

I sold my scope, so from memory I can tell you that scrolling while zoomed out, it will give you packet errors unless you have a valid frame starting within the screen.

Thanks, you just confirmed this scope is not much better than Rigol 1054Z with regards to serial decoding In other words it is broken

cheers

[EEVblog]

Why do you believe it is going to cripple anything? For example: Yokogawa and R&S scopes (RTB2000 & RTM3000) can operate in both ways perfectly without any downsides. It just adds more flexibility. I fail to see why people insist that adding more flexibility is somehow limiting other features. It doesn't! People who claim allowing to select between automatic and full memory mode is somehow impacting history mode are just spreading FUD.

Indeed.
The Siglent even has a physical HISTORY button with a LED behind it. Wouldn't it be amazing if that button actually worked to turn History mode on or off based on the needs of the user. I know it's a radical concept, and I'm probably asking too much, but worth a thought...

[tautech]

Why do you believe it is going to cripple anything? For example: Yokogawa and R&S scopes (RTB2000 & RTM3000) can operate in both ways perfectly without any downsides. It just adds more flexibility. I fail to see why people insist that adding more flexibility is somehow limiting other features. It doesn't! People who claim allowing to select between automatic and full memory mode is somehow impacting history mode are just spreading FUD.

Indeed.
The Siglent even has a physical HISTORY button with a LED behind it. Wouldn't it be amazing if that button actually worked to turn History mode on or off based on the needs of the user.

I doubt zoom out capture will be implemented like that based on the email I had from the product manager yesterday....yes Sunday ! 
History is a long standing strategy paired with existing the Stop and Single memory depth strategy which should remain untouched to suit existing users workflow but of course the History buffer is where capture depth will be sourced from.

I know it's a radical concept, and I'm probably asking too much, but worth a thought...

Existing strategies are unlikely to change IMO only what the DSO returns in Stop, Single and Normal will be altered.
And it could be simply another selection in the Acquire menu, Capture Default memory (screen width) or Full (user selected max memory).

[tautech]

The way Siglent implemented it is like you need to know beforehand what you want to capture and set the right timebase before.  I used the SDS2104X plus to capture SPI data, decoded information in screen was not enough and wanted to see more... You cannot.  You need to set a new timebase and capture again.  You might have lost your golden opportunity of capturing the fault.  You end up doing 3-5 captures until you get what you want to see.  Or like some member said, capture and zoom in... it is ridiculous.  In my new GW-Instek GDS1054B, I capture and then zoom out and in as I like to find what I want to see in detail.  This is why UI responsiveness is important.  Rigol can capture full memory, but scrolling is painful.  Keysight is ultra fast and GW-Instek is fast too.

When you zoom out on the siglent and start panning the data across the screen does the data become corrupted and change value as it is moved along the screen or is the trigger reference point for the decoding always preserved ?

Can someone do a video on this comparing different scopes because I know the Rigol 1054Z fails this test.

cheers

I sold my scope, so from memory I can tell you that scrolling while zoomed out, it will give you packet errors unless you have a valid frame starting within the screen.

Thanks, you just confirmed this scope is not much better than Rigol 1054Z with regards to serial decoding In other words it is broken

cheers

Just got round to a look at this with a SDS5000X. SDS2000X Plus should behave exactly the same.
A series of screenshots should give you what you need to know.
Original Stop capture in Zoom mode (#2) and further shots out of Zoom mode panned to the limit of correct decode which was 112 ms before the trigger point in the case of this 20 ms timebase setting so 1/2 division off the display for image 6.

But this whole the point of Zoom mode, there are no such limitations within the Zoomed window and we can roll back through the record with Navigate if we wish.

[TK]

First and third image shows the limitation.  It is not showing the packet because first clock pulse is missing from the screen.  I am not sure why in the third image the whole decoding is wrong and not only the first packet

[tautech]

First and third image shows the limitation.  It is not showing the packet because first clock pulse is missing from the screen.  I am not sure why in the third image the whole decoding is wrong and not only the first packet

Third First and last images decoding in Zoom mode may have been just that particular packet whereas if the list is displayed there are no errors.
Again, decodes in the zoomed window from the primary timebase work perfectly.
Note, images above are not using a protocol trigger, only increased Holdoff so the trigger doesn't see another edge until after the packet.

[nctnico]

First and third image shows the limitation.  It is not showing the packet because first clock pulse is missing from the screen.  I am not sure why in the third image the whole decoding is wrong and not only the first packet

Third image decoding in Zoom mode may have been just that particular packet whereas if the list is displayed there are no errors.

No. The oscilloscope can't find the start of the packet and spits out random garbage. It is simple as that.

[snoopy]

First and third image shows the limitation.  It is not showing the packet because first clock pulse is missing from the screen.  I am not sure why in the third image the whole decoding is wrong and not only the first packet

Third image decoding in Zoom mode may have been just that particular packet whereas if the list is displayed there are no errors.
Again, decodes in the zoomed window from the primary timebase work perfectly.
Note, images above are not using a protocol trigger, only increased Holdoff so the trigger doesn't see another edge until after the packet.

The third image looks like what the Rigol does. As soon as you pan the reference point off the screen the data turns into junk which makes it useless for long packet lengths. Maybe the reason why the table is still in tact is because it only updated once at the trigger point only.

Looks like there are two or more issues with this scope regarding serial decode.

1. You can't zoom out and take full advantage of the memory depth
2. You can't pan the display because as soon as you lose the reference point off the screen the decoded data becomes corrupted
3. I guess you can't mark and search on long packets of data either ?

You need to fix these issues to make this scope useful.

cheers

[tautech]

First and third image shows the limitation.  It is not showing the packet because first clock pulse is missing from the screen.  I am not sure why in the third image the whole decoding is wrong and not only the first packet

ThirdFirst and last images decoding in Zoom mode may have been just that particular packet whereas if the list is displayed there are no errors.
Again, decodes in the zoomed window from the primary timebase work perfectly.
Note, images above are not using a protocol trigger, only increased Holdoff so the trigger doesn't see another edge until after the packet.

The third image looks like what the Rigol does. As soon as you pan the reference point off the screen the data turns into junk which makes it useless for long packet lengths. Maybe the reason why the table is still in tact is because it only updated once at the trigger point only.

Looks like there are two or more issues with this scope regarding serial decode.

1. You can't zoom out and take full advantage of the memory depth
2. You can't pan the display because as soon as you lose the reference point off the screen the decoded data becomes corrupted
3. I guess you can't mark and search on long packets of data either ?

You need to fix these issues to make this scope useful.

cheers

Correction edit added ^ due to hurried post. 

1. No problem in dual timebase Zoom mode. Period !
2. Same as #1.
3. No marking capability at this time however the Search while not organised for packet searches can return you to a list of pulses that meet criteria set within its UI.
I have to think if there is a way to mark a point on a waveform in the UI, another play tonight should find it. Too busy today.

There are ways around most seemingly impassable obstacles with a little imagination. 

[snoopy]

First and third image shows the limitation.  It is not showing the packet because first clock pulse is missing from the screen.  I am not sure why in the third image the whole decoding is wrong and not only the first packet

ThirdFirst and last images decoding in Zoom mode may have been just that particular packet whereas if the list is displayed there are no errors.
Again, decodes in the zoomed window from the primary timebase work perfectly.
Note, images above are not using a protocol trigger, only increased Holdoff so the trigger doesn't see another edge until after the packet.

The third image looks like what the Rigol does. As soon as you pan the reference point off the screen the data turns into junk which makes it useless for long packet lengths. Maybe the reason why the table is still in tact is because it only updated once at the trigger point only.

Looks like there are two or more issues with this scope regarding serial decode.

1. You can't zoom out and take full advantage of the memory depth
2. You can't pan the display because as soon as you lose the reference point off the screen the decoded data becomes corrupted
3. I guess you can't mark and search on long packets of data either ?

You need to fix these issues to make this scope useful.

cheers

Correction edit added ^ due to hurried post. 

1. No problem in dual timebase Zoom mode. Period !
2. Same as #1.
3. No marking capability at this time however the Search while not organised for packet searches can return you to a list of pulses that meet criteria set within its UI.
I have to think if there is a way to mark a pint on a waveform in the UI, another pay tonight should find it. Too busy today.

There are ways around most seemingly impassable obstacles with a little imagination. 

Is there a video serial decoding using this dual time base mode ?? I would like to see how this works

cheers

[tautech]

Is there a video serial decoding using this dual time base mode ?? I would like to see how this works

Older SDS2000X model so 50/50 split display instead of 25/75 and there are a few changes in the UI but basically works the same as newer SDS2kX Plus and SDS5kX.
From 6 minutes is using Zoom mode:
https://youtu.be/mXJN7FwpKHg

[snoopy]

Is there a video serial decoding using this dual time base mode ?? I would like to see how this works

Older SDS2000X model so 50/50 split display instead of 25/75 and there are a few changes in the UI but basically works the same as newer SDS2kX Plus and SDS5kX.
From 6 minutes is using Zoom mode:
https://youtu.be/mXJN7FwpKHg

From that video it works as long as you have predetermined the memory depth/sample rate before hand to show all of the data you want to see and then you can zoom in and the panning seems to work on that scope in the video. Does the serial decode still work in history mode ? Would be nice to flip through segments in history mode and view the data either as a waveform with decodes or from a table etc ?? Is this possible ?

cheers

[tautech]

Is there a video serial decoding using this dual time base mode ?? I would like to see how this works

Older SDS2000X model so 50/50 split display instead of 25/75 and there are a few changes in the UI but basically works the same as newer SDS2kX Plus and SDS5kX.
From 6 minutes is using Zoom mode:
https://youtu.be/mXJN7FwpKHg

From that video it works as long as you have predetermined the memory depth/sample rate before hand to show all of the data you want to see and then you can zoom in and the panning seems to work on that scope in the video. Does the serial decode still work in history mode ? Would be nice to flip through segments in history mode and view the data either as a waveform with decodes or from a table etc ?? Is this possible ?

cheers

Snoopy, this is from a SDS5000X and the SDS2000X Plus should perform exactly the same albeit with a tiny bit less memory depth. (250 vs 200 Mpts)
Setting used was 62.5 Mpts, being 1/2 of the full available mem depth as we are using 3 channels for which the max is 125 Mpts/ch.

Settings returned 433 History frames that we can step through one at a time or play them in forward or reverse order.
No particular order other than what the Frame # signifies.

[snoopy]

Is there a video serial decoding using this dual time base mode ?? I would like to see how this works

Older SDS2000X model so 50/50 split display instead of 25/75 and there are a few changes in the UI but basically works the same as newer SDS2kX Plus and SDS5kX.
From 6 minutes is using Zoom mode:
https://youtu.be/mXJN7FwpKHg

From that video it works as long as you have predetermined the memory depth/sample rate before hand to show all of the data you want to see and then you can zoom in and the panning seems to work on that scope in the video. Does the serial decode still work in history mode ? Would be nice to flip through segments in history mode and view the data either as a waveform with decodes or from a table etc ?? Is this possible ?

cheers

Snoopy, this is from a SDS5000X and the SDS2000X Plus should perform exactly the same albeit with a tiny bit less memory depth. (250 vs 200 Mpts)
Setting used was 62.5 Mpts, being 1/2 of the full available mem depth as we are using 3 channels for which the max is 125 Mpts/ch.

Settings returned 433 History frames that we can step through one at a time or play them in forward or reverse order.
No particular order other than what the Frame # signifies.

So you are triggering on start of frame or when chip select asserted ? What happens if the packet size is different for each frame ? Will the history automatically record packets of varying length ?? I can see this method saving a lot of record memory that is wasted dead time between packets Interesting if it works like this

cheers