EEVblog #1312 - Siglent Oscilloscopes CRIPPLING History Mode!

[EEVblog]

Siglent oscilloscopes have a crazy crippling automatic waveform History mode that is always on, you can't switch it off, and it gobbles up all your sweet juicy sample memory.
Why?

[tom66]

This is a design decision.

You can capture a longer timebase and zoom in. That's essentially the same as what you're asking for.  Siglent have just traded off memory for a history function. The default setting on most newer Rigol scopes is the same - when in 'Auto' mode there is almost no memory saved outside of the capture area.  To do what you are asking,  Siglent would have to capture ~100ms of data for every acquisition, which would seriously drop the acquisition frame rate, and customers might not understand that the memory depth setting affects this.

I did notice that the Siglent scope we had on loan did not have any auto memory depth setting which I found strange.

[Kleinstein]

It is a design decision to use the horizontal scale knob to set the length of the captured signal.
It is a little odd in the single mode - but not a big deal, as one can start slower first and than zoom in. So there is an easy work around.
A separate setting in run mode may make sense: one may need the display to manually judge the signal and than decide to capture and in this case may want the data well before that event.
The question is a little what does the memory depth setting do than ?
If used for the lenght of the segments one would need a finer granularity, not just decades.

[mroek]

This is something I never really noticed, but now that I know, it is kinda annoying that Siglent does it this way. I would prefer to be able to make this choice myself, and if one could actually turn off history mode and instead have the scope use all the memory for the single capture, that would provide the best of two worlds. History mode/segmented memory is a useful thing, but it should be up to the user how the memory is utilized.

The workaround using zoom mode is doable, but quite clumsy compared to just zooming out on whatever is on your screen. Anyways, thanks for the video, at least I learned something new.

[David Hess]

So now we have to start carefully distinguishing between memory depth and record length.  Marketing will of course advertise the former rather than the later because it will be larger.

How does this limitation make sense for performance when the same amount or even less of the data would be processed?  What requires more processing when a smaller part of the acquisition record is displayed and the sample rate did not change?

[tom66]

So now we have to start carefully distinguishing between memory depth and record length.  Marketing will of course advertise the former rather than the later because it will be larger.

How does this limitation make sense for performance when the same amount or even less of the data would be processed?  What requires more processing when a smaller part of the acquisition record is displayed and the sample rate did not change?

It has always been record length.

The Rigol DS1000Z, for instance, has 64MB of DDR(2/3) memory tied to the FPGA.  In normal acquisition, only 24Mpt of memory is available in any configuration: 1ch/2ch/4ch, with the memory divided between enabled channels. However, the full memory length is available when segmented memory is selected, in individual segments.

Why they made this choice is not understood by me,  but it might be because they want two buffers of memory available (plus scratchpad for trigger correction or other management), and alternately stream one or the other to the processor. Or, it might simply be a marketing decision, to not compete with their higher-end models and offer the full memory space in normal acquisition.

In the Siglent, the full record length is available by increasing the timebase, and Siglent have made the decision that the true acquisition length should always set the memory depth.  This appears to be a technical decision rather than a marketing decision, but doesn't seem to imply any hardware or software limitation. If you want to capture the full 200Mpt, simply zoom the instrument out, capture the data, and zoom in.  If the instrument was continuously capturing the 200Mpt samples, then it would need to acquire and potentially process all of those while displaying only 0.01% of the actual acquisition.  This would reduce the acquisition rate considerably.

I've noticed a "Tek Mode" buried in the utility/settings page of the SDS5000X;  perhaps that would change this behaviour?

[0xdeadbeef]

I tend to disagree with Dave here that it's a crippling and insane decision to not always capture the full memory. At least for lower sampling rates, it would take very long to fill the whole buffer. E.g. at 1MSa/s, it would need 200s to fill the buffer. I'd think nobody would accept a single shot mode that needed more than a second to display a signal after the trigger. On the Keysight scopes that people like to present as the gold standard, you usually only have less than 2MPts or so which kinda eliminates this problem due to a simple lack of deep memory.
Of course there would be cleverer ways to solve this by e.g. dynamically limiting the memory to ensure a relatively quickly (few hundred milliseconds) reaction in single trigger mode dependent on the sample rate. I'm sure that even then people would complain about the incomprehensible memory usage. So Siglent went the easy way. IMHO this is a reasonable decision and actually having a permanent history is a cool feature, isn't it?

[Fungus]

You can capture a longer timebase and zoom in. That's essentially the same as what you're asking for. 

No it isn't.

It's of no use whatsoever when the event only happens infrequently and you just managed to capture one and want to know what happened before/after.

[David Hess]

So now we have to start carefully distinguishing between memory depth and record length.  Marketing will of course advertise the former rather than the later because it will be larger.

It has always been record length.

I checked the Siglent marketing material before posting and it only refers to memory depth.

Why they made this choice is not understood by me,  but it might be because they want two buffers of memory available (plus scratchpad for trigger correction or other management), and alternately stream one or the other to the processor. Or, it might simply be a marketing decision, to not compete with their higher-end models and offer the full memory space in normal acquisition.

In the Siglent, the full record length is available by increasing the timebase, and Siglent have made the decision that the true acquisition length should always set the memory depth.  This appears to be a technical decision rather than a marketing decision, but doesn't seem to imply any hardware or software limitation. If you want to capture the full 200Mpt, simply zoom the instrument out, capture the data, and zoom in.  If the instrument was continuously capturing the 200Mpt samples, then it would need to acquire and potentially process all of those while displaying only 0.01% of the actual acquisition.  This would reduce the acquisition rate considerably.

Honestly I prefer that the acquisition record be the same size as or lightly larger than the viewed area unless I specify otherwise if it means a higher acquisition rate.  Maybe Dave will go back and see how the acquisition rate changes at different time/div settings when the record length is being limited.

[nctnico]

Honestly I prefer that the acquisition record be the same size as or lightly larger than the viewed area unless I specify otherwise if it means a higher acquisition rate.  Maybe Dave will go back and see how the acquisition rate changes at different time/div settings when the record length is being limited.

There is a long thread about this but the point is that for some use (for example embedded software debug & verification) it is very handy to have data which goes far beyond the screen (without needing to resort to zoom modes which are clumsy).  With memory length under full user control the user can make the decission between deep memory or fast waveform updates.

I tend to disagree with Dave here that it's a crippling and insane decision to not always capture the full memory. At least for lower sampling rates, it would take very long to fill the whole buffer. E.g. at 1MSa/s, it would need 200s to fill the buffer. I'd think nobody would accept a single shot mode that needed more than a second to display a signal after the trigger. On the Keysight scopes that people like to present as the gold standard, you usually only have less than 2MPts or so which kinda eliminates this problem due to a simple lack of deep memory.

But now you are optimising for update rate. In some case that doesn't even matter. Recently I used 5s/div in roll mode to measure something; for long time/div you tend to use roll mode anyway. If you need to trigger then you get set a shorter memory depth either manually or automatically (like R&S allows to do).

Of course there would be cleverer ways to solve this by e.g. dynamically limiting the memory to ensure a relatively quickly (few hundred milliseconds) reaction in single trigger mode dependent on the sample rate. I'm sure that even then people would complain about the incomprehensible memory usage. So Siglent went the easy way. IMHO this is a reasonable decision and actually having a permanent history is a cool feature, isn't it?

The way Siglent implemented it: no; it is half assed. For example R&S and Yokogawa allow to trade-off record length and history depth manually to have maximum control.

[tom66]

You can capture a longer timebase and zoom in. That's essentially the same as what you're asking for. 

No it isn't.

It's of no use whatsoever when the event only happens infrequently and you just managed to capture one and want to know what happened before/after.

I think you misunderstand ...

If you set a non-Siglent scope to 200Mpt depth and a timebase of, say, 1us/div across 10 divisions, it only displays 10us of data at 2GSa/s = 20kpt.   The full buffer is captured but this is equivalent to having the scope set to a timebase of 10ms/div and zoomed in. 

There is *no difference* in acquisition performance, trigger performance or oscilloscope results, to a scope set to a long memory depth and zoomed in, or the same long memory depth and zoomed out to fit the entire acquisition on the display.  They are functionally equivalent and capture exactly the same data.

In both cases you will capture your "glitch" that you want to observe.  It may be helpful to set the trigger up initially at a short timebase, and then zoom out to capture a wider span.

And indeed Siglent offers this with the "zoom" function ... they have just decided, that by default, the instrument always uses the highest update rate configuration.  Whether that is a sensible decision or not, I suppose, is down to the application and user.

[SMB784]

Of course there would be cleverer ways to solve this by e.g. dynamically limiting the memory to ensure a relatively quickly (few hundred milliseconds) reaction in single trigger mode dependent on the sample rate. I'm sure that even then people would complain about the incomprehensible memory usage. So Siglent went the easy way. IMHO this is a reasonable decision and actually having a permanent history is a cool feature, isn't it?

The way Siglent implemented it: no; it is half assed. For example R&S and Yokogawa allow to trade-off record length and history depth manually to have maximum control.

The question in my mind is: is this something that could be changed in software so that the trade-off could be added as a feature?  Or is this tied to hardware.

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

[NiHaoMike]

I tend to disagree with Dave here that it's a crippling and insane decision to not always capture the full memory. At least for lower sampling rates, it would take very long to fill the whole buffer. E.g. at 1MSa/s, it would need 200s to fill the buffer.

Why would you slow down the ADC that much? At 1GHz sample rate, it would be a very reasonable 0.2s.

[bdunham7]

In my view this is related to the klunkiness of the  FFT function in that the record length is tied inextricably with the displayed data.  I would like to see more user control, just so that the scope behaves the way the user wants it to.

I can easily set up the scope to capture what I want it to, but it requires wasting half my screen on something that generally yields no visible information.  To be fair here, this allows me to see the waveform at just a few cycles, but it has captured a full 14M points and if I stop the scope, I can scroll through the capture for the rest of the day.  No real issue in capturing a long record while looking at the trigger point up close, but it does take an additional step.



Now that doesn't look to bad, but you do have to set it up beforehand and it cannot be configured as the default, and as I said, you've wasted half the screen.  Here everything is clear, but add in the FFT and some measurements and you have a mess.



I can't change the FFT to full screen without losing my zoomed-in waveform, which is what I typically really want to see instead of the unusable information on the top half. 

Just another 'feature' of an almost-pro tool. 

[nctnico]

Of course there would be cleverer ways to solve this by e.g. dynamically limiting the memory to ensure a relatively quickly (few hundred milliseconds) reaction in single trigger mode dependent on the sample rate. I'm sure that even then people would complain about the incomprehensible memory usage. So Siglent went the easy way. IMHO this is a reasonable decision and actually having a permanent history is a cool feature, isn't it?

The way Siglent implemented it: no; it is half assed. For example R&S and Yokogawa allow to trade-off record length and history depth manually to have maximum control.

The question in my mind is: is this something that could be changed in software so that the trade-off could be added as a feature?  Or is this tied to hardware.

I think this is likely a couple of hours of work for Siglent to change. All the functionality is there in the software; it just needs to be wired a bit differently. The changes come down to adding an auto / fixed memory setting and create a hidden zoom function which is set the memory length selected by the user.

[bdunham7]

I think this is likely a couple of hours of work for Siglent to change. All the functionality is there in the software; it just needs to be wired a bit differently. The changes come down to adding an auto / fixed memory setting and create a hidden zoom function which is set the memory length selected by the user.

It does seem simple.  The most basic step would be to allow the often-useless display of the full capture to be turned off.  The next would be to allow a configurable option of A) how it is now, where the 'MEM DEPTH' function determines how many triggered frames are stored in memory, or B) 'MEM DEPTH' controls how many points are stored in a single acquisition and if you choose a lower amount, then perhaps you get a certain amount of history captures, but with each one at that full specified record length. 

Then we could talk about allowing the MEM DEPTH to be set in increments other than decades and setting the record length directly.  Same for FFT.

[kevinpt]

I believe this is a carry over from the LeCroy 9300 series stretching back 30 years. Those scopes started out with a 68020 processor with support for an unprecedented level of math operations. These needed to be restricted to the displayed record to be functional on such limited hardware.

The 9300s and direct descendants have a similar scheme for configuring acquisition where you set a maximum record length and the scope computes the optimal sampling rate for the current timebase as well as a potentially shorter record length if it decides the maximum is too big for the screen. The whole idea at the time being to limit how much data you can choke the processor with so that the scope stays more responsive. For long acquisitions you were expected to set a slower timebase and use the zoom waveforms to inspect the results in detail. HP MegaZoom hadn't been invented yet.

It also works in conjunction with the segmented acquisition where you need to set a limit on the length of each segment. Once you've configured an acquisition with more segments than will fit in memory, it will drop the segment length to allow more to fit. These were some of the most advanced deep memory scopes at the time when the competition was happy to max out at 4k acquisition records. I don't know how the current modern scopes behave but if you drop the (max) record length way down, the sample rate may drop as well so that the screen can still be filled.

This is akin to Tek keeping the cursors locked to the screen on zoom and scroll to replicate their analog scope cursors.

[EEVblog]

Martin72 posted this table in another thread:



There is absolutely no excuse for not allowing the user to manually select any memory depth at all timebase settings.

[EEVblog]

I tend to disagree with Dave here that it's a crippling and insane decision to not always capture the full memory.

That's not what I was saying. I was saying that it's crippling and insane that they don't give you the option to do it.

[rambling@midnight]

I'm a newbie looking for my first scope which I'm saving up for ^_^. I was really set on the SDS1104X-E because of the great price, but this is really disturbing. Do we think Siglent will listen and fix this in a firmware update? (can it be fixed in firmware?)
Also can someone make a video showing how to use the dual display mode hack to get the sampling we want? (maybe demonstrating with trigger/single shot)

[mroek]

I'm a newbie looking for my first scope which I'm saving up for ^_^. I was really set on the SDS1104X-E because of the great price, but this is really disturbing. Do we think Siglent will listen and fix this in a firmware update? (can it be fixed in firmware?)
Also can someone make a video showing how to use the dual display mode hack to get the sampling we want?

It can most likely be "fixed" in firmware, but as others have mentioned, this is a design choice, so it is doubtful that they will change it.

No need for a video, I think. It is dead simple. Adjust the horizontal to whatever you want (you can see the number of samples captured on the screen), then press the horizontal knob to go into zoom mode. The original waveform is shown on top, and on the bottom you have a zoomed version of the sama data. If you now adjust the horizontal, you will adjust the zoomed one, and you can use the position knob to choose which part of the full waveform you want to see.

[tautech]

I'm a newbie looking for my first scope which I'm saving up for ^_^. I was really set on the SDS1104X-E because of the great price, but this is really disturbing. Do we think Siglent will listen and fix this in a firmware update? (can it be fixed in firmware?)
Also can someone make a video showing how to use the dual display mode hack to get the sampling we want? (maybe demonstrating with trigger/single shot)

Welcome to the forum.

Reply #14 shows you what you need to see with the first image in classic Zoom mode with the primary timebase setting adjusted to display max mem depth. The small sliver in the middle of the display represents the lower zoomed portion. Single or Stop the acquisition and you can pan through the upper primary timebase with the zoomed portion.
As SDS1104X-E is entry level the Zoom split is 50/50 whereas SDS2000X Plus models are ~75/25 split.
Very simple to use once you embrace it.

Edit
Added for simplicity.

[rambling@midnight]

Thanks guys. Maybe I will end up still getting the aforementioned model. I really dislike the visual layout of the Rigol's with the dual columns of buttons on either side and tiny on-screen icons, and the two shades of blue in the channels. Siglent looks really clean.

[tautech]

Thanks guys. Maybe I will end up still getting the aforementioned model. I really dislike the visual layout of the Rigol's with the dual columns of buttons on either side and tiny on-screen icons, and the two shades of blue in the channels. Siglent looks really clean.

You won't be disappointed.
The video that bought you here is making a mountain from a molehill when those 'smart' guys that really want to give it some real thought of the reason why Siglent has implemented memory management the way they have.................and that's just started a flame war. 

[Fungus]

Thanks guys. Maybe I will end up still getting the aforementioned model. I really dislike the visual layout of the Rigol's with the dual columns of buttons on either side and tiny on-screen icons, and the two shades of blue in the channels. Siglent looks really clean.

You know those buttons do something useful and that you'll use them a lot, right? They're not just there because Rigol wanted to impress people.

Without them you'll spend weeks of your life fiddling around with popup dialogs and horrible item navigation.

[rambling@midnight]

You know those buttons do something useful and that you'll use them a lot, right? They're not just there because Rigol wanted to impress people.

Without them you'll spend weeks of your life fiddling around with popup dialogs and horrible item navigation.

they seem to significantly crowd the viewing space. you use them that frequently? I suppose you eventually memorize the symbols/position, so you don't bother squinting at their text anymore...
hacking the DS1054Z up to 100mhz seems like a great price...

[bdunham7]

I'm a newbie looking for my first scope which I'm saving up for ^_^. I was really set on the SDS1104X-E because of the great price, but this is really disturbing. Do we think Siglent will listen and fix this in a firmware update? (can it be fixed in firmware?)
Also can someone make a video showing how to use the dual display mode hack to get the sampling we want? (maybe demonstrating with trigger/single shot)

Don't be disturbed.  This is not a serious limitation for an entry level scope and the 1104X-E (and 1202X-E) are pretty far up there in bang-for-the-buck.  They have a large number of features that work OK to pretty well and things like this issue are better described as quirks rather than shortcomings.

[bdunham7]

Thanks guys. Maybe I will end up still getting the aforementioned model. I really dislike the visual layout of the Rigol's with the dual columns of buttons on either side and tiny on-screen icons, and the two shades of blue in the channels. Siglent looks really clean.

You won't be disappointed.
The video that bought you here is making a mountain from a molehill when those 'smart' guys that really want to give it some real thought of the reason why Siglent has implemented memory management the way they have.................and that's just started a flame war. 

I think the point is not "why Siglent implemented memory management the way they have", rather it is "why don't they give us the option to manage it in the way that works best for us in our particular use case".  I'm willing to accept a limited range of options and a little awkwardness in a $500 scope that provides a fantastic feature set once you get to know your way around all the quirks.  If I was forking out $5K or whatever for a professional use case, I want a UI designed to that standard.  When I can walk up to one of your competitor's scopes that I've never used before and have it set up and showing me the picture I want in under 60 seconds, that is an intuitive, well-designed UI. 

The flexibility asked for here wouldn't be that hard to implement AFAIK.  I'm sure we all have other suggestions as to features that would sell some scopes and it isn't all about bandwidth and MB of memory.  Perhaps Siglent should ask us!

[nctnico]

Let's see how Siglent reacts to this video and the one showing the comparison to their competitors. Perhaps there has been a conversation between the CEO and the R&D department already:

CEO: Why are our oscilloscopes different compared to all of the competitors?
R&D: The people from Lecroy said...
CEO: Don't care about what Lecroy said. Dave made us look stupid! And dumb! And more stupid. How much time to fix?
R&D: A couple of hours tops I guess.
CEO: Make it so! New firmware by the end of the week!
R&D: OK boss.

And once it is implemented/released Tautech will go on raving for years how using all of the memory is the best feature Siglent ever added to their oscilloscopes! 

[tautech]

Let's see how Siglent reacts to this video and the one showing the comparison to their competitors. Perhaps there has been a conversation between the CEO and the R&D department already:

CEO: Why are our oscilloscopes different compared to all of the competitors?
R&D: The people from Lecroy said...
CEO: Don't care about what Lecroy said. Dave made us look stupid! And dumb! And more stupid. How much time to fix?
R&D: A couple of hours tops I guess.
CEO: Make it so! New firmware by the end of the week!
R&D: OK boss.

Alternative:
~1 month ago resulting from beta tester emails:

CEO: We need allow for capture zoom out.
R&D: Why ? Pico and LeCroy don't support it.
CEO: Apparently some can't embrace the capture analysis tools we offer so we need to make it much easier for them.
R&D: OK we will look into it but we really should be fixing the few bugs already reported.
CEO: Yes, OK then get onto it when you can.

Yes you heard it here first !
ETA, unknown.

[snoopy]

Thanks guys. Maybe I will end up still getting the aforementioned model. I really dislike the visual layout of the Rigol's with the dual columns of buttons on either side and tiny on-screen icons, and the two shades of blue in the channels. Siglent looks really clean.

You won't be disappointed.
The video that bought you here is making a mountain from a molehill when those 'smart' guys that really want to give it some real thought of the reason why Siglent has implemented memory management the way they have.................and that's just started a flame war. 

Serial decoding is one feature why I might buy this scope but what happens if I do a serial decode and I need to see data from outside the grabbed screen ? Will I lose the data on the siglent ?? Also does the history mode maintain proper data decoding across multiple segments in relation to the capture point ?

I remember trying to do serial serial decode with the rigol 1054Z and it was ok for a couple of data packets but for debugging huge packet payloads was almost useless because as soon as you zoom out the data would be too small to see on the screen and if you tried to pan the display the data would lose its reference point and become jibberish.

cheers

[EEVblog]

The video that bought you here is making a mountain from a molehill when those 'smart' guys that really want to give it some real thought of the reason why Siglent has implemented memory management the way they have.................and that's just started a flame war. 

No, it's a very simple thing. When you manually set X memory depth you expect X depth, not "sorry but we don't think you should have that, we know better than you that you really want 10k instead of 10M and a History function instead."
It's just such a dumb decision I can't believe anyone would try and justify it as a sensible approach.

[TK]

Thanks guys. Maybe I will end up still getting the aforementioned model. I really dislike the visual layout of the Rigol's with the dual columns of buttons on either side and tiny on-screen icons, and the two shades of blue in the channels. Siglent looks really clean.

You won't be disappointed.
The video that bought you here is making a mountain from a molehill when those 'smart' guys that really want to give it some real thought of the reason why Siglent has implemented memory management the way they have.................and that's just started a flame war. 

Serial decoding is one feature why I might buy this scope but what happens if I do a serial decode and I need to see data from outside the grabbed screen ? Will I lose the data on the siglent ?? Also does the history mode maintain proper data decoding across multiple segments in relation to the capture point ?

I remember trying to do serial serial decode with the rigol 1054Z and it was ok for a couple of data packets but for debugging huge packet payloads was almost useless because as soon as you zoom out the data would be too small to see on the screen and if you tried to pan the display the data would lose its reference point and become jibberish.

cheers

Siglent only decodes what is in the screen.  If the signal was not captured, you cannot decode it.  Even when you zoom in from a large capture, it will decode only what you see, so it sometimes misses the packet start, showing wrong decoded information for the initial data.

It also has limitation on the number of packets it can decode.  You can capture all 200Mpts, but decoding is limited to 12,000 packets on the SDS2104X plus and 3,000 packets on the SDS1104X-E

[snoopy]

Thanks guys. Maybe I will end up still getting the aforementioned model. I really dislike the visual layout of the Rigol's with the dual columns of buttons on either side and tiny on-screen icons, and the two shades of blue in the channels. Siglent looks really clean.

You won't be disappointed.
The video that bought you here is making a mountain from a molehill when those 'smart' guys that really want to give it some real thought of the reason why Siglent has implemented memory management the way they have.................and that's just started a flame war. 

Serial decoding is one feature why I might buy this scope but what happens if I do a serial decode and I need to see data from outside the grabbed screen ? Will I lose the data on the siglent ?? Also does the history mode maintain proper data decoding across multiple segments in relation to the capture point ?

I remember trying to do serial serial decode with the rigol 1054Z and it was ok for a couple of data packets but for debugging huge packet payloads was almost useless because as soon as you zoom out the data would be too small to see on the screen and if you tried to pan the display the data would lose its reference point and become jibberish.

cheers

Siglent only decodes what is in the screen.  If the signal was not captured, you cannot decode it.  Even when you zoom in from a large capture, it will decode only what you see, so it sometimes misses the packet start, showing wrong decoded information for the initial data.

It also has limitation on the number of packets it can decode.  You can capture all 200Mpts, but decoding is limited to 12,000 packets on the SDS2104X plus and 3,000 packets on the SDS1104X-E

Well that's a deal breaker for me. I had the same trouble with the Rigol and struggled with it at the time. To avoid that in the future I ended up buying a USB logic analyzer with truck loads of memory. I can live with the 2nd issue but not the first Don't think the history mode would help either !

cheers

[TK]

Thanks guys. Maybe I will end up still getting the aforementioned model. I really dislike the visual layout of the Rigol's with the dual columns of buttons on either side and tiny on-screen icons, and the two shades of blue in the channels. Siglent looks really clean.

You won't be disappointed.
The video that bought you here is making a mountain from a molehill when those 'smart' guys that really want to give it some real thought of the reason why Siglent has implemented memory management the way they have.................and that's just started a flame war. 

Serial decoding is one feature why I might buy this scope but what happens if I do a serial decode and I need to see data from outside the grabbed screen ? Will I lose the data on the siglent ?? Also does the history mode maintain proper data decoding across multiple segments in relation to the capture point ?

I remember trying to do serial serial decode with the rigol 1054Z and it was ok for a couple of data packets but for debugging huge packet payloads was almost useless because as soon as you zoom out the data would be too small to see on the screen and if you tried to pan the display the data would lose its reference point and become jibberish.

cheers

Siglent only decodes what is in the screen.  If the signal was not captured, you cannot decode it.  Even when you zoom in from a large capture, it will decode only what you see, so it sometimes misses the packet start, showing wrong decoded information for the initial data.

It also has limitation on the number of packets it can decode.  You can capture all 200Mpts, but decoding is limited to 12,000 packets on the SDS2104X plus and 3,000 packets on the SDS1104X-E

Well that's a deal breaker for me. I had the same trouble with the Rigol and struggled with it at the time. To avoid that in the future I ended up buying a USB logic analyzer with truck loads of memory. I can live with the 2nd issue but not the first Don't think the history mode would help either !

cheers

If I understood Tautech's post correctly, it looks like a change is being considered by Siglent R&D about this issue.

[maginnovision]

Just don't buy a scope hoping something changes.

[snoopy]

Just don't buy a scope hoping something changes.

I'll wait and see because this scope could easily be a giant killer if Siglent crosses all of the t's and dot's all of the i's

cheers

[tom66]

Change was also considered for the Rigol DS1000Z serial decoder which is basically useless because it only decodes ~1000 points at any one time, making it useless for all but the shortest packets.

This issue doesn't seem to affect the SDS5000X we tried out, maybe it varies between models.

[tautech]

If I understood Tautech's post correctly, it looks like a change is being considered by Siglent R&D about this issue.

Apparently so but I know little about it as yet.

My guess is the auto memory management will remain as it is in that the users choice of max memory they want the scope to work within in Run mode and the DSO will still auto manage memory so to maintain high throughput.

What concerns me is how the memory currently available and assigned for History might be impacted by enabling zoom out equally to pre and post trigger capture depths.
How all these scenarios might be addressed will be interesting particularly to minimize the impact on the suite of tools we have already. 

[0xdeadbeef]

No, it's a very simple thing. When you manually set X memory depth you expect X depth, not "sorry but we don't think you should have that, we know better than you that you really want 10k instead of 10M and a History function instead."

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.
 

It's just such a dumb decision I can't believe anyone would try and justify it as a sensible approach.

It's a lazy decision, there would have been better solution for single trigger but it's really neither dumb nor crippling.

[bdunham7]

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. 

As for the rest, those questions can easily be answered.  Yes, the logical default is to center the entire capture around the trigger, although an option to shift the trigger within the record as was done in older DSOs with limited memory might be nice as well.  As for measurements, gates and definitions, give us menus!  Entry-level scopes with a bucketload of non-pro features that sort of work can get away with stuff like only performing measurements from the screen buffer, but what I really want is to be able to make a single capture of full memory length and then work with that record afterwards--set gate points, perform measurements, decoding, etc.  All the hardware is there, most of the software is there, so it is frustrating to think about what could be done but isn't. 

[Fungus]

Well, we agree that the maximum memory has to be ignored in normal trigger mode since else the trigger/update rate would drop dramatically?

I disagree. If the memory is treated as a single circular buffer then the update rate won't be affected at all.

Think: The trigger point is usually at the center of the screen so that's the way it has to work internally, ie. you must be recording something before the trigger point or it can't work.

Besides who defines what "outside" the screen has to be captured?

Most other manufacturers seem to have agreed that the trigger point should be at the center of the capture.

[Kleinstein]

One can just record as much data before the trigger as are available and if present note multiple trigger events, even inside the screen or before and after the displayed part. From the memory use this should be OK and would not add to the response time.

One may still want to limit the record lenght so that one gets a given minimum number of history steps even of the trigger events are far separated. The relevant parameter could be the min. number of segments / triggers or the maximum time before and after a trigger event. However limiting the time before trigger could be tricky as this could result in freeing data in smaller chunks - so the implementation would be tricky and may need a kind of compromise, like discarding non needed data only in larger chunks or ignoring a 2 nd trigger inside a segment.
Memory management could become messy if it gets to flexible.

With so much memory trigger always in the center may be OK - worst case use twice the memory and have one setting less to learn and confuse users. If used a few setting like 20%, 50%, 80 % before trigger would probably be enough choice.

[maginnovision]

One can just record as much data before the trigger as are available and if present note multiple trigger events, even inside the screen or before and after the displayed part. From the memory use this should be OK and would not add to the response time.

One may still want to limit the record lenght so that one gets a given minimum number of history steps even of the trigger events are far separated. The relevant parameter could be the min. number of segments / triggers or the maximum time before and after a trigger event. However limiting the time before trigger could be tricky as this could result in freeing data in smaller chunks - so the implementation would be tricky and may need a kind of compromise, like discarding non needed data only in larger chunks or ignoring a 2 nd trigger inside a segment.
Memory management could become messy if it gets to flexible.

With so much memory trigger always in the center may be OK - worst case use twice the memory and have one setting less to learn and confuse users. If used a few setting like 20%, 50%, 80 % before trigger would probably be enough choice.

I think R&S power of 10 scopes handle it well. They have history(paid option) and auto/manual memory lengths. They don't let you use the entirety of the memory for 1 segment but they do let you use a fair amount. However they don't specify the scopes having the memory they have only as the maximum depth for a segment. Other than that when you press stop you'll have some number of triggers stored based on the auto memory length(typically about screen width) or manual which gives you quite a few options.

The RTM3000 for example is 40M sample per segment(max option for manual memory depth) or 80M for interleaved. It's also how they market the memory("Up to 80 Msample"). However the history memory is 200M samples per channel(400M samples interleaved). So you can have 5 x 40 M sample segments per channel. When in Auto mode it goes for max sample rate and full screen data until you hit max memory then it lowers the sample rate. It doesn't matter if you have trigger at the left, right or center. At this point it's about being honest. 200M isn't 200M when they decide how you use it.

[nctnico]

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. 

As for the rest, those questions can easily be answered.  Yes, the logical default is to center the entire capture around the trigger, although an option to shift the trigger within the record as was done in older DSOs with limited memory might be nice as well.  As for measurements, gates and definitions, give us menus!

Yes and no. The memory split should be around the time=0 position on the screen because the trigger point can be way outside the screen.

@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 optimise the oscilloscope for a particular job.

[tom66]

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.

I disagree. If the memory is treated as a single circular buffer then the update rate won't be affected at all.

The acquisition is not a singular circular buffer though, is it.  It is a pre-trigger buffer, which is circular, and a post-trigger buffer, which is linear.  If you have a purely circular buffer, then the post trigger could overwrite the pre-trigger, unless the whole buffer is 50% bigger than it needs to be.  (Of course, this complicates copying, but it saves you RAM and reduces acquisition time, and that's far more valuable.)

[Fungus]

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:

[nctnico]

I disagree. If the memory is treated as a single circular buffer then the update rate won't be affected at all.

The acquisition is not a singular circular buffer though, is it.  It is a pre-trigger buffer, which is circular, and a post-trigger buffer, which is linear.  If you have a purely circular buffer, then the post trigger could overwrite the pre-trigger, unless the whole buffer is 50% bigger than it needs to be.  (Of course, this complicates copying, but it saves you RAM and reduces acquisition time, and that's far more valuable.)

No. All of the DSO architectures I'm aware of do double buffering which needs at least twice the amount of acquisition memory. Even the Keysight Megazoom ASICs. Having two buffers which need to be stitched together would make the logic more complex than necessary so circular buffer it is (at least two of them and more when using segmented / history mode).

[JPortici]

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.

[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

[tautech]

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 ?

Clock falling edge, visible in the Trigger setting box.   

What happens if the packet size is different for each frame ?

Don't think they are from this STB3.

Will the history automatically record packets of varying length ??

No reason why it shouldn't.

I can see this method saving a lot of record memory that is wasted dead time between packets Interesting if it works like this

I believe it does and I'll come back with a screenshot soon....not entirely sure.

[tautech]

This shot with trigger centered and traces moved upwards is the same source and settings as before but with Cursors added to measure the inactivity time between packets. Live running capture whereas previous shots were in History from a Stop capture. List ON.


So yes this below shot posted before indicates a pile of trace inactivity time removed but that will be related to timebase settings with triggering dictating the # of frames captured and no doubt History playback setting also.

[TK]

@snoopy: I don’t think history mode can capture different timebase intervals. It will be fixed and if tou have variable frame length I am not sure how any scope will do such capture. I will test later on a KS and GDS1054B with segmented memory with variable SPI frame size

[nctnico]

@snoopy: I don’t think history mode can capture different timebase intervals. It will be fixed and if tou have variable frame length I am not sure how any scope will do such capture. I will test later on a KS and GDS1054B with segmented memory with variable SPI frame size

History mode / segmented recording will always work with fixed buffer sizes. AFAIK the only oscilloscopes which can show decoded packets from all segments in one list view are from Keysight. It is a rather unique feature which can be very useful though.

[2N3055]

@snoopy: I don’t think history mode can capture different timebase intervals. It will be fixed and if tou have variable frame length I am not sure how any scope will do such capture. I will test later on a KS and GDS1054B with segmented memory with variable SPI frame size

History mode / segmented recording will always work with fixed buffer sizes. AFAIK the only oscilloscopes which can show decoded packets from all segments in one list view are from Keysight. It is a rather unique feature which can be very useful though.

I agree, and that is my problem with Siglent (and RTM3000 from R&S) SDS2000X+ and SDS5000X. That, and search on protocols.

Just wanted to add (I know I'm boring everybody with it, sorry ) but Picoscope also decodes current buffer or all segments or history buffers. It also can use DeepMeasure over both current or all history buffers.

[TK]

I ran some SPI decoding tests some time ago on KS and Siglent and posted here: https://www.eevblog.com/forum/testgear/impressive-keysight-1000x-series-(edux1002g-modded)-spi-triggering-rate/msg2413935/#msg2413935

It is interesting how KS screen display and decoding buffer seem to go through different paths inside the scope.  Even when the waveform is very distorted, it can decode correctly

[2N3055]

I ran some SPI decoding tests some time ago on KS and Siglent and posted here: https://www.eevblog.com/forum/testgear/impressive-keysight-1000x-series-(edux1002g-modded)-spi-triggering-rate/msg2413935/#msg2413935

It is interesting how KS screen display and decoding buffer seem to go through different paths inside the scope.  Even when the waveform is very distorted, it can decode correctly

It doesn't seem, it literally does have dual paths to A/D converter and to digital edge detector. And, you are correct, it is sometimes simply weird how it decodes nicely when signal is completely scrambled on screen...

[Triodos]

Hi, I'm new here, and few days ago I bought SDS1104X-e with SDG1032X.
And I was really happy until today I discovered that thread ...

I was wondering why I cannot put whole 14 Mpts all the time and now i see why.
I work mostly in analog domain, and zooming out before single shot is not a big deal.
Playing with horizontal know it is easy to to find a point where whole memory is used for one single shot.

But I agree that it would be nice to let me choose the way the memory is used and be able just to zoom out after single shot if I want it.

[tautech]

Hi, I'm new here, and few days ago I bought SDS1104X-e with SDG1032X.
And I was really happy until today I discovered that thread ...

I was wondering why I cannot put whole 14 Mpts all the time and now i see why.
I work mostly in analog domain, and zooming out before single shot is not a big deal.
Playing with horizontal know it is easy to to find a point where whole memory is used for one single shot.

But I agree that it would be nice to let me choose the way the memory is used and be able just to zoom out after single shot if I want it.

Welcome to the forum.

Key is understanding capture strategies and embracing the methodology to obtain the result you seek.
Zoom out, capture, then zoom in and navigate is not hard to get a handle on. 

Understand interleaving also helps so the channels selected use all the memory available. 1+3, 1+4, 2+3, 2+4 utilize the available memory to best effect.

[Triodos]

Hi, I'm new here, and few days ago I bought SDS1104X-e with SDG1032X.
And I was really happy until today I discovered that thread ...

I was wondering why I cannot put whole 14 Mpts all the time and now i see why.
I work mostly in analog domain, and zooming out before single shot is not a big deal.
Playing with horizontal know it is easy to to find a point where whole memory is used for one single shot.

But I agree that it would be nice to let me choose the way the memory is used and be able just to zoom out after single shot if I want it.

Welcome to the forum.

Key is understanding capture strategies and embracing the methodology to obtain the result you seek.
Zoom out, capture, then zoom in and navigate is not hard to get a handle on. 

Understand interleaving also helps so the channels selected use all the memory available. 1+3, 1+4, 2+3, 2+4 utilize the available memory to best effect.

Oh, that was what I forgot, that there are two ADCs for 4 channels 1-2 and 3-4. Thanks for a tip

[tom.holzwurm]

Sorry for being late, but I hadn't seen this discussion and the video just now:
My good old Tek 754D hasn't of course such much memory but a nice zoom function, which I use very often, You can see the origial signal and can zoom in using a sliding magnifying window.
I still do not understand, whats the difference from the Siglents nasty? behaviour to that of my scope ?
Thanks for enlightening me,
Regards
Tom
PS: I'm currently looking for a replacement, that's why I'm asking.

[TK]

All scopes can zoom in, but not all can zoom out from a fresh capture. In the siglent, when you zoom out after capture you see no additional data because it just used enough sample memory to what is in the display, even when you indicate you want to use more

[tautech]

All scopes can zoom in, but not all can zoom out from a fresh capture. In the siglent, when you zoom out after capture you see no additional data because it just used enough sample memory to what is in the display, even when you indicate you want to use more

RTFM on mem depth management.
In Zoom mode it's a totally different scenario.

Embrace how Pico, LeCroy and Siglent manage captures and there are no disadvantages,

[nctnico]

Sorry for being late, but I hadn't seen this discussion and the video just now:
My good old Tek 754D hasn't of course such much memory but a nice zoom function, which I use very often, You can see the origial signal and can zoom in using a sliding magnifying window.
I still do not understand, whats the difference from the Siglents nasty? behaviour to that of my scope ?

It depends on what you are doing but for some measurements you don't want to have the zoom windows around in order to save space (to have measurements or the waveform on screen). Or you just didn't enable it. Or it turns out you forgot to reset the screen position before doing a new measurement. Being able to scroll left / right / zoom out saves you time. Especially if doing the actual measurement takes a long time. At that point not being able to zoom out would get seriously in the way of being efficient. That is it in a nutshell; there is much more to it. AFAIK your TDS754D should also be able to zoom out; just disable 'fit to screen' and you can scroll left/right just like every other DSO out there (except for Lecroy and Siglent). However it seems Siglent is working on a fix but no ETA yet.

[tom.holzwurm]

 Not to be misunderstood: I heavily use the zoom function on my Tek, I was wondering if the Siglent is able to provide the same option, which it doesn't according to this article.

[0xdeadbeef]

This is not about zoom, it's about some people expecting a scope to capture data outside the screen area defined by the operator since obviously the operator didn't really know what he wanted to look at.

[2N3055]

Not to be misunderstood: I heavily use the zoom function on my Tek, I was wondering if the Siglent is able to provide the same option, which it doesn't according to this article.

Complete topic is BS. It has very well implemented zoom. It has also well implemented history mode that will keep thousands of previous triggered captures without performance impact. Sort of transparent segmented mode always running in the background.

[nctnico]

Not to be misunderstood: I heavily use the zoom function on my Tek, I was wondering if the Siglent is able to provide the same option, which it doesn't according to this article.

Complete topic is BS.

It is not. An oscilloscope which works like Siglent is useless for many of my measurements because it would seriously slow me down. You just don't see the how and why. That is fine. Since you're not a Siglent sales agent I don't get why you are calling this BS. It doesn't make sense. Many people have pointed out that capturing beyond the screen is useful to them. Who are you to tell them different?

[2N3055]

Not to be misunderstood: I heavily use the zoom function on my Tek, I was wondering if the Siglent is able to provide the same option, which it doesn't according to this article.

Complete topic is BS.

It is not. An oscilloscope which works like Siglent is useless for many of my measurements because it would seriously slow me down. You just don't see the how and why. That is fine. Since you're not a Siglent sales agent I don't get why you are calling this BS. It doesn't make sense. Many people have pointed out that capturing beyond the screen is useful to them. Who are you to tell them different?

I agreed, after lengthy discussion, that it is not useless. But it is obscure, and NOBODY even understood what are you talking about before you took some lengthy explaining how you do it. 
So yes using word "crippling" for something nobody knew about (except you) until then is BS. Utter BS. And so is proclaiming that History mode is useless (which is something LeCroy users use all the time for many years) and that it is a mistake doing History mode instead very rarely (or never) used arcane feature.
I have History mode on Picoscope and use it all the time...

[nctnico]

Not to be misunderstood: I heavily use the zoom function on my Tek, I was wondering if the Siglent is able to provide the same option, which it doesn't according to this article.

Complete topic is BS.

It is not. An oscilloscope which works like Siglent is useless for many of my measurements because it would seriously slow me down. You just don't see the how and why. That is fine. Since you're not a Siglent sales agent I don't get why you are calling this BS. It doesn't make sense. Many people have pointed out that capturing beyond the screen is useful to them. Who are you to tell them different?

I agreed, after lengthy discussion, that it is not useless. But it is obscure, and NOBODY even understood what are you talking about before you took some lengthy explaining how you do it. 

So it is not BS then. 

And that nobody understood what I was on about isn't true. If you look at the forum threads and Youtube comments it turns out lots of people take the 'capture beyond the screen' for granted. It is like being able to ride a bicycle. But now try to explain how to ride a bicycle exactly.

[2N3055]

Not to be misunderstood: I heavily use the zoom function on my Tek, I was wondering if the Siglent is able to provide the same option, which it doesn't according to this article.

Complete topic is BS.

It is not. An oscilloscope which works like Siglent is useless for many of my measurements because it would seriously slow me down. You just don't see the how and why. That is fine. Since you're not a Siglent sales agent I don't get why you are calling this BS. It doesn't make sense. Many people have pointed out that capturing beyond the screen is useful to them. Who are you to tell them different?

I agreed, after lengthy discussion, that it is not useless. But it is obscure, and NOBODY even understood what are you talking about before you took some lengthy explaining how you do it. 

So it is not BS then. 

That is very example how you try to provoke people's reaction by outright lying what I said by simply ignoring rest of my sentence..
Good work! 

[PickNickOnPluto]

Being new to digital scopes (I've used a Bitscope for years, but it's not in the same league), this discussion has been enlightening. But it shows that even experienced users don't seem to understand a lot of the fine points. It would be a great help, I think, if someone could write a really detailed guide or manual that describes, firstly, what each of the menu options really does, and secondly, how it can be used for specific measurement problems, and how it interacts with other options. I find again and again that I don't understand exactly what an option is doing, and I don't know where to get an answer. I was mystified by the fact that my SDS2202x-e seems to hang when you start a long capture, doesn't react to most button presses. If somewhere I were told that this was necessary to get maximum capture rate, I wouldn't have been so annoyed, but I'm still not sure it's not a bug that should be reported. What does "Acq Mode Slow" in triggering "Type Edge" do? Is it equivalent to a long holdoff time? Why is there no holdoff time for "Type Slope"? I don't see why we should have to speculate about these things -- it's as if we were dealing with some sort of exotic biological creature.

[SMB784]

Being new to digital scopes (I've used a Bitscope for years, but it's not in the same league), this discussion has been enlightening. But it shows that even experienced users don't seem to understand a lot of the fine points. It would be a great help, I think, if someone could write a really detailed guide or manual that describes, firstly, what each of the menu options really does, and secondly, how it can be used for specific measurement problems, and how it interacts with other options. I find again and again that I don't understand exactly what an option is doing, and I don't know where to get an answer. I was mystified by the fact that my SDS2202x-e seems to hang when you start a long capture, doesn't react to most button presses. If somewhere I were told that this was necessary to get maximum capture rate, I wouldn't have been so annoyed, but I'm still not sure it's not a bug that should be reported. What does "Acq Mode Slow" in triggering "Type Edge" do? Is it equivalent to a long holdoff time? Why is there no holdoff time for "Type Slope"? I don't see why we should have to speculate about these things -- it's as if we were dealing with some sort of exotic biological creature.

What you are describing is called the user manual for the scope, and the SDS2202x-e has one that you should read.  These things are all described there.  You can find the link to the manual here