EEVblog #864 - Siglent SDS2000X Series Oscilloscope Teardown

[radar_macgyver]

What additional information this slow fade out give to user? Or do you mean it is cosmetically more "nice".

The fade part is just eye-candy. Well sort-of, I'll get back to that. More important, though, is the "FIFO" behavior you described earlier. Right now, the scope behaves like it has infinite persistence, and someone pushed "Clear Persistence" every 5 seconds. For example, if the scope auto-clears the persistence, and four seconds later a jitter event or runt pulse shows up, it will only stay on screen for 5-4 = 1 second before it is auto-cleared on the next cycle. This doesn't present the same information as true FIFO persistence would.

As for the fade-out, it does help to determine the frequency of occurrence of an event shown on screen. For example, let's say we have a runt pulse occurs once every 3 seconds, and a different runt pulse occurs once every 10 seconds. With the scope set for 10 second persistence, the first runt pulse will appear brighter on screen than the second one. This is how I've used the DPO capability of a Tek scope. Granted, there are other ways to accomplish the same thing, I'm saying that this should be easily achievable with their current display processor hardware. This would fall into a "nice to have" feature. The first part about the way persistence behaves on the SDS2000X is definitely a bug, though.

Fast acquisition and image daata processing is bit time critical process.  I do not accept if example persistence on slows wfm/s speed. If we need keep track for every acquisition  age  it is bit hard.  If there is example 100000 wfm/s there is roughly 4000 acquisitions in each TFT image what are renewed every 40ms with new set of 4000 acquisitions. This is still quite easy case but when we work with random undefined signals scope can not design just for one case, sontinuous repetitive signal. Before this fade out gradattion is good we need time stamp every single acquisition and after time start decay intensity individually for every acquisition. If we now want 5 second persistence and after then say example 5s fade out. Total time for every acquisition is 10s and in "worst" case there is now 1000000 acquisition in ageing queye.

Doesn't have to be done this way. This can be simulated by applying a periodic "decrement" to all the intensity values stored in display RAM. Let's say, for example, we have a 512x512 frame buffer. The display processor FPGA already implements writing (optionally with interpolation vectors) data into the frame buffer, likely using a 'saturating add' raster op (this is how it does intensity grading). Each refresh cycle of the TFT, this frame buffer gets cleared.

To implement fade-out and persistence, don't clear the buffer. Instead, once every n frames, decrement the intensity value of each pixel in the buffer. If it reaches zero, stay at zero (saturating subtract). By changing n, one can achieve various different fade-out rates, corresponding to different persistence times. Even if done in software, this would only take 512x512x2/n = 524288/n operations (compare/branch, decrement) per frame. In practice, this is better handled by the display processor FPGA. If you want to be super-slick, integrate this function into the display DRAM refresh cycles and the operation becomes "free".

Hmm... this almost sounds like something one would do with a GPU. Maybe in the SDS3000? 

[rf-loop]

More important, though, is the "FIFO" behavior you described earlier.

Right now, the scope behaves like it has infinite persistence, and someone pushed "Clear Persistence" every 5 seconds.

This must be The Bug.  Example SDS1000X do not work like you tell. If there is example 1s or 5s persistence... whole time there come new pixels and continuously same time old pixels shut off  like continuous process. I do not know if ageing resolution is 1 image refresh or what it is but with eyes looks quite smooth.
(I know what you mean with this reset and start new 5s collecting and after 5 sec all of and new turn. This is absolutely wrong = must be bug.)

[Siglent America]

Good morning.
This is a bug that had been found earlier. It has been fixed in a new update and is currently undergoing testing at the factory.
Steve

[Wuerstchenhund]

Hmm... this almost sounds like something one would do with a GPU. Maybe in the SDS3000? 

The SDS3000 has proper DPO-like persistence mode (including the fading bit) and had it right from the start. But then, the software in that scope isn't from Siglent (only the hardware is), which means it also came to market without major bugs (and just a few minor ones)

[radar_macgyver]

Another bug to report: serial protocol decode (well, at least UART decode) seems to stop working when digital channels are enabled. Note, this happens even when the protocol decode input is set to one of the analog channels; simply having the digital channels on screen messes up the protocol decoder.

The protocol decoder seems to work only when the beginning of the serial frame is visible on screen, even when the Zoom feature is used (ie, the acquisition hardware has captured enough samples to perform the decode, but only some are shown on screen).

[tautech]

Another bug to report: serial protocol decode (well, at least UART decode) seems to stop working when digital channels are enabled. Note, this happens even when the protocol decode input is set to one of the analog channels; simply having the digital channels on screen messes up the protocol decoder.

The protocol decoder seems to work only when the beginning of the serial frame is visible on screen, even when the Zoom feature is used (ie, the acquisition hardware has captured enough samples to perform the decode, but only some are shown on screen).

Just trying to get my head around your findings. 

Have you read this post:
https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg920669/#msg920669

Sure it's not with the digital channels but if you study the images there might be some clues as to what you're seeing. 
Trigger settings have a lot to do with successful decoding. 

Can you post up some screen captures?

[radar_macgyver]

OK, the first part of my bug report seems like it may have been user error (aka, I was dumb) - I couldn't replicate it after I had made some changes to the arduino code I used to generate the serial test data.

The second part (only showing the decoded data when the beginning of the frame is visible) is illustrated below. In the first image, I have zoomed in such that the start bit of the first character ('6') is on screen. Everything works as expected. In the second image, I scrolled the zoom area so that the start bit of the first character is off to the left of the screen. The decoded data is blank, even though there are several valid characters displayed.

rf-loop had earlier reported that the scope must trigger on the data for the index shown in list mode to be accurate, but he explicitly mentioned that the decode still works in this condition (on an SDS1000X). This lets you capture a bunch of data, then zoom in and scroll around to read the contents. It seems to not be the case for an SDS2000X, as soon as you scroll so that the beginning of the data is off-screen, decode disappears.

[tautech]

In the second image, I scrolled the zoom area so that the start bit of the first character is off to the left of the screen. The decoded data is blank, even though there are several valid characters displayed.

When decoding with analogue while the digital channels are enabled......right?
I'll point Steve @ Siglent USA to this to see if he can replicate it. (not got my 2000X yet to try with.  )

rf-loop had earlier reported that the scope must trigger on the data for the index shown in list mode to be accurate, but he explicitly mentioned that the decode still works in this condition (on an SDS1000X). This lets you capture a bunch of data, then zoom in and scroll around to read the contents. It seems to not be the case for an SDS2000X, as soon as you scroll so that the beginning of the data is off-screen, decode disappears.

The difference between rf-loops and yours are the trigger settings vs the edge of the first bit. Is it different with a falling edge trigger?

[rf-loop]

This is how it works in SDS1000X ! I do not know how it is in 2000X.
 


1.
One transmitted whole string. All is decoded and in table there can scroll and read. (if there is error, bottom blue line have red marks where is error)



2.
Window zoom, scope running and new frames capturing all time. (I send repeating same string)





3.




4.




5.
After captured as in image  1.  or 3.
There can also stop and zoom in full window. But, I hope improve FW so that user always know data byte count from trigger  (and in window zoom also same)
Also without zooming, when there is just example image 1. and user search list to some position in frame there need be visible indicator what show list cursor position on the signal trace.  Also if hope bit more, there can be user defined  example 2-12 sequential character string with boolean so that scope can find this (or these) user defined exist.
(Image bottom orange arrow direction is wrong, it need bend to bottom left corner)

[radar_macgyver]

The difference between rf-loops and yours are the trigger settings vs the edge of the first bit. Is it different with a falling edge trigger?

After posting I noticed I was triggering on rising edge. Behavior remains the same with falling edge triggering as well - as soon as I zoom and pan the left edge of the data off screen, the decoded output changes to a flat blue line (which means line idle, I think). One more difference is that the baud rate I used on my tests is 115200 baud. I re-tested at 9600 baud with the same results.

@rf-loop: Understood. It seems like my 2204X does not behave the same way.

@tautech: Thank you for reporting to Siglent. Hopefully they'll get the issue solved. In the meantime, the scope seems to do most basic stuff just fine. I'll keep exploring the fancier features and let you know if I came across something weird.

If I may, a 'minor annoyance' is that the scope re-arms itself too quickly in auto mode. During these tests with the serial decoder, I had an arduino output a burst of characters once a second. With the trigger set to auto, I would often not see anything on screen, even though the scope indicated it was triggered. I had to switch to Normal mode before I could get the display to show me something. I would have preferred if Auto trigger mode held data on screen for a little longer, before re-arming the trigger.

[tautech]

@tautech: Thank you for reporting to Siglent. Hopefully they'll get the issue solved. In the meantime, the scope seems to do most basic stuff just fine. I'll keep exploring the fancier features and let you know if I came across something weird.

If I may, a 'minor annoyance' is that the scope re-arms itself too quickly in auto mode. During these tests with the serial decoder, I had an arduino output a burst of characters once a second. With the trigger set to auto, I would often not see anything on screen, even though the scope indicated it was triggered. I had to switch to Normal mode before I could get the display to show me something. I would have preferred if Auto trigger mode held data on screen for a little longer, before re-arming the trigger.

As with any perceived problem it's great if you can post some supporting screenshots that we can point Tech support to. 
It's so much easier then to duplicate your findings as there's much info in a screenshot that then doesn't need mention.

After posting I noticed I was triggering on rising edge

[rf-loop]

The difference between rf-loops and yours are the trigger settings vs the edge of the first bit. Is it different with a falling edge trigger?

After posting I noticed I was triggering on rising edge. Behavior remains the same with falling edge triggering as well - as soon as I zoom and pan the left edge of the data off screen, the decoded output changes to a flat blue line (which means line idle, I think). One more difference is that the baud rate I used on my tests is 115200 baud. I re-tested at 9600 baud with the same results.

@rf-loop: Understood. It seems like my 2204X does not behave the same way.

@tautech: Thank you for reporting to Siglent. Hopefully they'll get the issue solved. In the meantime, the scope seems to do most basic stuff just fine. I'll keep exploring the fancier features and let you know if I came across something weird.

If I may, a 'minor annoyance' is that the scope re-arms itself too quickly in auto mode. During these tests with the serial decoder, I had an arduino output a burst of characters once a second. With the trigger set to auto, I would often not see anything on screen, even though the scope indicated it was triggered. I had to switch to Normal mode before I could get the display to show me something. I would have preferred if Auto trigger mode held data on screen for a little longer, before re-arming the trigger.

Try much longer trigger holdoff time. (you need not turn anymore multifunction knob "endless" for adjust it much higher value. Push knob and use virtual keyboard.)

Scope default holdoff need be short, other way we read thousends of negative comments how slow this scope reeact when touch probe to some potential before anything see on the screen. But user can adjust it when really need. (example if you   try look AM modulated signal so that you want trig to modualtion freq, this is fast and practical way to adjust holdoff so that get stabile trig. 

In case where something happends some times and then scope auto trig fast agen and flush old trace out but we want still see it. Persistence is some times useful tool.

Have you tried set trigger mode BUS and then set all trig paramaters for UART?

[radar_macgyver]

As with any perceived problem it's great if you can post some supporting screenshots that we can point Tech support to. 
It's so much easier then to duplicate your findings as there's much info in a screenshot that then doesn't need mention.

I agree. In this case, though, a screenshot wouldn't help since it's a *time* effect. Instead, I'll do what the cool kids are doing these days and post some videos. Please forgive my lack of skill. In all cases, I used the internal waveform generator to produce a 1 Hz pulse, with 50 us pulse width.

Playlist with all the videos: https://vimeo.com/album/3960396

Video 1 is in Auto mode, with ~800 ms holdoff as suggested by rf-loop:

First, every pulse that's displayed has trace data at zero volts everywhere. My interpretation of this is that the scope re-arms itself almost instantly, and tries to display the trace when it's at zero volts. Even worse, the scope seems to trigger, but displays no pulse. For example, at 2 seconds, and then again at 7 seconds. This is bizarre, there should have been one trigger per second.

Video 2 is in Auto mode, with no trigger holdoff:

Here, the scope seems more eager to trigger but not display anything. You can see it happen at the 1 second mark, and then again at the 7 second mark. I couldn't catch it doing so on camera, but on occasion I would see the pulse on screen get mangled - the width would be something completely different from 50 us.

In, video 3 is with the scope in normal trigger mode:

This is what I expected to see. I found that I had to set the waveform generator frequency as high as 8 Hz before auto and normal trigger modes showed the same thing on screen. This means that the re-arm time in auto trigger mode is something less than 0.125 seconds. I think this is too short - it ought to be at least a half second so that the waveforms shown on screen in auto trigger mode can actually be seen. After all, that's the whole point of auto trigger mode - to explore around without knowing what sort of signals to look for.

Finally, here's the same signal on ye olde 54602B:

This scope had the holdoff set to 800 ms as well. It never misses any pulses, and you can clearly see the structure of the pulse. It's misshapen since the probe compensation wasn't adjusted. Due to the large dead time that its acquisition system has, it performed poorly with the holdoff turned down.

After posting I noticed I was triggering on rising edge

Just in case my point got lost - the scope behaved the same whether I was triggering on the rising or the falling edge.

Scope default holdoff need be short, other way we read thousends of negative comments how slow this scope reeact when touch probe to some potential before anything see on the screen. But user can adjust it when really need. (example if you   try look AM modulated signal so that you want trig to modualtion freq, this is fast and practical way to adjust holdoff so that get stabile trig. 

As I noted above, the issue at hand is not fixed by increasing holdoff.

Have you tried set trigger mode BUS and then set all trig paramaters for UART?

If you're referring to my previous post about the serial decoder, it should not matter how the scope acquisition is done. My point is that as soon as the first transition of the data is moved off-screen, the decoding fails. This prevents me from acquiring a burst of serial data, and then zooming in to look at the details.

[rf-loop]

Because it seems that when I talk many separate things in same msg it leads to confusion.

Now I talk only and alone Auto trigger, Trigger holdoff and oscilloscope acquisition speed things. Not Decode or serial trigger.

HP54602B is very slow.  Nearly like if you set Siglent acquisition to slow mode (not exactly)

I have not anymore any 54600 scope here so I can not test its Auto mode free run speed and Trig holdoff.
But you show there is 800ms Trig holdoff and you get stabile auto mode trig to 1s period 50us width pulses.

I test it with SDS1000X and SDS2000
In this particular case, 1s period, 50us width pulse, trigger rising edge, mode Auto. Horizontal speed 10us/div
I set Trigger holdoff 950ms (SDS1kX)  and 960ms (SDS2k).
I run it using pass/fail mask test and they trig rock solid without any loosed pulse and without any extra capture.

This is faster than old HP and so, this also need more care how to do settings.  Also this Auto mode is some amount faster so time gap for adjust Holdoff time is also more narrow. Btw, 200ms is long time.

With 10us/div and Trig Holdoff off and trigger mode Auto, SDS2k (not X)  free run (no trigs from signal) average speed is around 515 capture/s.
Free run (no trigs from signal)  with 5ns/div and other settings for max wfm/s and Trigger mode Auto, Holdoff closed. Average >141000 wfm/s  It do not wait trigger event in Auto trig mode  so long time..  who want scope is more slow.
(there is also images from these tests if need including trigger output images)

We want fast scope but then we want it is slow?

With holdoff around ~960 - <1000ms  trigger to this signal is  rock solid. We can see it do not wait as long time as old HP what wait least 200ms (as you show). Driving modern fighter need more accuracy with settings  than old cessna what can drive with "oops - so what" settings.
Attached these mask tests. Also I have carefully looked that it did not loose any single pulse.

[radar_macgyver]

OK, understood. For the record, I had to set holdoff time to about 950 ms before triggering was stable. I suppose it's the problem with "flying Cessnas" for a long time (54602 at home, MDO4000 at work - perhaps these were yesterday's fighter jets?  ).

So to break it down into simple terms for someone like me, was the effect I saw in video 1 because the scope had just done an acquisition prior to the edge of the 1 Hz signal, and the dead time would cause the pulse to be missed?

[nctnico]

This is what I expected to see. I found that I had to set the waveform generator frequency as high as 8 Hz before auto and normal trigger modes showed the same thing on screen. This means that the re-arm time in auto trigger mode is something less than 0.125 seconds. I think this is too short - it ought to be at least a half second so that the waveforms shown on screen in auto trigger mode can actually be seen. After all, that's the whole point of auto trigger mode - to explore around without knowing what sort of signals to look for.

I think you can debate forever about this and not reach any concensus. On many oscilloscopes the auto trigger re-arm time is very short so you can immediately see what is going on. Tektronix does things a little bit different though. When in auto trigger mode it will wait for half a second before going back to auto trigger mode after it has triggered on something in a signal. This can be handy but it can also be a nuisance if you just want to check a level and get the noise from attaching the probe on screen instead. Another work around is a dedicated force-trigger button. This way you don't need to switch between auto/normal mode. You can just hit a button to get a trace on the screen when in normal trigger mode.

[radar_macgyver]

On many oscilloscopes the auto trigger re-arm time is very short so you can immediately see what is going on. Tektronix does things a little bit different though. When in auto trigger mode it will wait for half a second before going back to auto trigger mode after it has triggered on something in a signal.

Did not know this. Most times I needed to do anything that needed a fast sweep time but with a slow trigger rate (which is pretty much all the time when working with pulsed radars) I always used a Tek. The few times I had to use an Agilent were with much more benign trigger conditions. I quite like that half-second delay, but I can understand that it will get in the way of people who aren't expecting it.

Well, at least Siglent has made the trigger mode controls dedicated buttons. Most others bury it under at least one menu.

[rf-loop]

This is what I expected to see. I found that I had to set the waveform generator frequency as high as 8 Hz before auto and normal trigger modes showed the same thing on screen. This means that the re-arm time in auto trigger mode is something less than 0.125 seconds. I think this is too short - it ought to be at least a half second so that the waveforms shown on screen in auto trigger mode can actually be seen. After all, that's the whole point of auto trigger mode - to explore around without knowing what sort of signals to look for.

I think you can debate forever about this and not reach any concensus. On many oscilloscopes the auto trigger re-arm time is very short so you can immediately see what is going on. Tektronix does things a little bit different though. When in auto trigger mode it will wait for half a second before going back to auto trigger mode after it has triggered on something in a signal. This can be handy but it can also be a nuisance if you just want to check a level and get the noise from attaching the probe on screen instead. Another work around is a dedicated force-trigger button. This way you don't need to switch between auto/normal mode. You can just hit a button to get a trace on the screen when in normal trigger mode.

Using SDS1000X.

It looks that this time is  very close 99ms - 100ms.

With Tek it give more room for signal variations or to user so that example Trigger Holdoff time do not need adjust so careful. With this Siglent it give only 0.1s window for set.
It means, example, that if pulse period is 1000ms  user need set Trig holdoff between 901ms  to 999ms. If time is more short it fall back to autotrig. If time is over, it can not trig all pulses. In other hand if pulse period is variable it do not "accept" more than this ~0.1s variation.

What is good, I do not know. This is compromise but is it good compromise, least I do not know. One want more, one want less.
I like if there is separate adjustments for both so that I can my self adjust this time (what is good name for this time)  and Trigger Holdoff time.



----------------------

But then other thing what I some times nearly hate.
Perhaps some like but I do not.

Automatic force to "Scroll" mode. 

I have not meet this thing so often because it is quite rare I need time base slower than 10ms/div so it have not been problem for me because my typical use is not under 10ms/div.

If need often select different t/div between <=20ms/div - >=50ms.  It is frustrating. Really!
Why I need loose my working time for this stupidity?
I do not like this automatic selection.
Least I want there is selection in setup menu where I can select how it switch to scroll mode. Auto or Manual.