EEVblog #1312 - Siglent Oscilloscopes CRIPPLING History Mode!

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