Siglent SDS1104X-E and SDS1204X-E Mixed Signal Oscilloscopes

[Performa01]

Am I the only one seeing this behavior?

No, you're certainly not.

Everyone who is analysing signals at slow timebases on a DSO with long memory and deep measurements will experience some lag - and the SDS1000X-E entry level DSOs are certainly not the worst in this regard, even when compared to instruments that cost 10 times more.

Automatic measurements on the SDS1000X-E analyze the full record length up to 14Mpts. This means that you get the full signal analysis capabilities of a modern DSO, as you can measure e.g. the period, duty cycle and rise/fall times of a PWM signal with good accuracy all at the same time even at a slow 1ms/div timebase.

Some other DSOs use a much shorter secondary buffer for math and measurements, and some are even limited to just the screen buffer, which sets them back to the capabilities of an analog scope where you need to zoom in for meaningful transition time measurements and cannot get even remotely accurate period or duty cycle measurements at all.

[blurpy]

Thanks for the explanation, Performa01! It's good to know that it's not something wrong with my scope.

From an ignorant users standpoint, the behavior does look like a bug to me. I can definitely understand that it's processing a lot of data, and presenting that data will not always be real time. But as I could clearly see, presenting the data is not a bottleneck in itself, as it's quite fast when the memory length is shorter.

So the fact that the trace lags when updating measurements makes it look like the classic "doing background work on the ui thread" issue. Usually solved by doing time consuming work in the background and updating the ui when done. There could be good reasons for doing it the current way, including technical difficulties or complexity, accuracy (though since it only updates once a sec anyway it's not really representing any current state), or they don't worry about it since no one has complained.

[tautech]

Thanks for the explanation, Performa01! It's good to know that it's not something wrong with my scope.

From an ignorant users standpoint, the behavior does look like a bug to me. I can definitely understand that it's processing a lot of data, and presenting that data will not always be real time. But as I could clearly see, presenting the data is not a bottleneck in itself, as it's quite fast when the memory length is shorter.

So the fact that the trace lags when updating measurements makes it look like the classic "doing background work on the ui thread" issue. Usually solved by doing time consuming work in the background and updating the ui when done. There could be good reasons for doing it the current way, including technical difficulties or complexity, accuracy (though since it only updates once a sec anyway it's not really representing any current state), or they don't worry about it since no one has complained.

Try this and this observed behavior is somewhat different:
A faster timebase
Another channel using the same ADC.

As Performa01 points out, it's indicative of the sample size processed and additional active channels and/or a different timebase will result in smaller sample size to be processed.
Not all use cases will be impacted.......

[Performa01]

Thanks for the explanation, Performa01! It's good to know that it's not something wrong with my scope.

From an ignorant users standpoint, the behavior does look like a bug to me. I can definitely understand that it's processing a lot of data, and presenting that data will not always be real time. But as I could clearly see, presenting the data is not a bottleneck in itself, as it's quite fast when the memory length is shorter.

So the fact that the trace lags when updating measurements makes it look like the classic "doing background work on the ui thread" issue. Usually solved by doing time consuming work in the background and updating the ui when done. There could be good reasons for doing it the current way, including technical difficulties or complexity, accuracy (though since it only updates once a sec anyway it's not really representing any current state), or they don't worry about it since no one has complained.

I understand what you're saying - and I also can only speculate about the reasons.

On the other hand, I had quite some discussions with Siglent R&D about measurements and I know that they do care - even though quite often I am the only one complaining about something

The fact that it works smooth with 1.4Mpts record length (which you generally should not take for granted) shows that the implementation in the Siglent DSOs isn't that bad after all. Manufacturers usually don't specify the max. data length for math and measurements, but you can bet not many will actually analyze up to 14Mpts. There is one particular (expensive) brand whose DSOs are infamous for getting unresponsive as soon as they have anything demanding (like math or measurements) to do. I'm not sure you'd like such an approach better?

The bottleneck is certainly processing and bus transfer speed as well as the (limited) size of fast internal memory, and embedded platforms (even with the pretty powerful Xilinx Zynq) cannot be compared to a modern PC (which is what upper-midrange and high-end DSOs are based on). We cannot acquire and display new data while analyzing the sample memory at the same time, because the analyzed data need to remain consistent during analysis. With 14Mpts record length, there are "only" 3 records in the history (42Mpts total per channel pair!), hence the currently analysed record gets overwritten by the acquisition process much faster than the CPU can analyse it to get all the measurements. As a consequence, the acquisition process has to be halted until analysis is complete.

A 4 channel SDS1004X-E has a total of 28Mpts sample memory (up to >100Mpts in History and Sequence mode). If we were able to take a "snapshot" of the sample memory, i.e. copy the entire 28Mpts to some internal memory of the ARM CPU (on a separate memory bus) and then analyse it locally in the background, then the interruptions of the acquisition and consequently display process could certainly be much shorter and would most likely not be noticable at all even with 14Mpts record length. But my guess would be that there is just no local memory on a separate bus that is as big as the maximum record length for all channels together (at least 28MB) ...

To cut a long story short, neither the UI nor the display is blocked by the measurements, it is actually the acquisition that needs to be briefly paused in order to prevent it from corrupting the data just being analysed. With shorter record lengths (either by limiting it in the Acquisition menu or selecting a faster timebase) this problem eases pretty quickly.

[tv84]

I think you resumed it pretty well.

Just want to add that with the new development toolchains available to these new embedded procs, there is a tendency to have more overhead in all of the code (the tradeoff of faster time-to-market...). This overhead also penalizes the speed.

These equipments are no more compatible with fully Assembly development project (optimized to the extreme).

[blurpy]

@tautech - Good tips, I'll do some more experiments when I get back to the scope.

@Performa01 - I've never used another scope, so I don't know what I'm missing (good or bad), but while researching I was looking into the Rigol 1054Z, and the Siglent seemed to be quite a lot more responsive from what I could see (on YouTube). So I see your point I'm generally very happy with the performance and the device. Great theory btw! What you're describing with memory limits during acquisition seems plausible. Siglent is maybe not able to improve it much further because of hardware, but possibly their more expensive DSOs have the capabilities to avoid it.

[Performa01]

@Performa01 - I've never used another scope, so I don't know what I'm missing (good or bad), but while researching I was looking into the Rigol 1054Z, and the Siglent seemed to be quite a lot more responsive from what I could see (on YouTube). So I see your point I'm generally very happy with the performance and the device. Great theory btw! What you're describing with memory limits during acquisition seems plausible. Siglent is maybe not able to improve it much further because of hardware, but possibly their more expensive DSOs have the capabilities to avoid it.

The Rigol DS1000Z series do not have deep measurements, quite the opposite - they are essentially limited to the screen buffer. It certainly would be very embarassing if measurements would cause any noticeable lag in these devices.

Even the current Siglent flagship DSO SDS5000X is based on the Zynq platform. Of course it has a lot more acquisition memory, faster ADCs and I would also assume a more powerful version of the Zynq chip. The fundamental problem remains though - the ARM CPU has to access (and lock) the sample memory while analyzing it to get the measurement values. The fast internal memory is not nearly big enough and the external CPU memory is certainly not fast enough.

As mentioned before, even much more expensive so called "A-brand" DSOs get laggy pretty quickly when performing deep measurements on embedded platforms.

Only non-embedded upper midrange or high-end platforms can effectively circumvent this, because there is a clear separation between acquisition memory and the (huge) main memory of the PC platform. Then we can do what I've described before: transfer the acquisition data to the PC main memory via a high speed interface as needed, thus causing little interference on the acquisition process. There is a downside too - since there is no direct access to the sample data, these scopes cannot offer intesity or color grading as a standard, but need a special "persistence" mode for this, which comes with its own bunch of limitations.

[borjam]

I think you resumed it pretty well.

Just want to add that with the new development toolchains available to these new embedded procs, there is a tendency to have more overhead in all of the code (the tradeoff of faster time-to-market...). This overhead also penalizes the speed.

These equipments are no more compatible with fully Assembly development project (optimized to the extreme).

That overhead can also help write less buggy code and make it much easier to maintain. So there is always a reason. Of course there is a balance and sometimes it's difficult to strike.

[mematyi]

Hi!

I am in search of a new (first) budget DSO, and I recently met this SDS1104X-e scope. I have had some analog ones, but I wanted a digital scope for years. I've read various reviews of it, and it seems to be the budget king of this category of scopes. My price point is exactly this scope, about 500Euros max.

I am in absolutely not a hurry buying a DSO, that is why I am asking you for an advice.
Do you think that in this budget scope dump, Siglent or Owon or Rigol, any budget brands will come out with a new model that has even better specifications and worth waiting a few more months?
This scope mentioned in this thread is about 2 years old, still way newer than the Rigol 1054Z, but I wonder if a new buyer with moderate, but certainly not beginner electrical experience should wait some more time.

I have seen the new Rigol DS1202Z-e, but it is only 2 channel, and I wasn't able to find and pros compared to the Siglents. Perhaps Rigol might come out with an upgraded 4-banger.

[Gabri74]

I am in search of a new (first) budget DSO, and I recently met this SDS1104X-e scope

Go for it!
I'm an happy previous owner of a Rigol 1054Z and now an happier owner of a Siglent SDS1204X-e (the 200MHz version).
Some random plus points of the Siglent:
- obviously newer design
- measures and decoders use full memory buffer. Rigol is limited to display memory
- faster interface, even with measures and decoding and cursors on the interface is not too slow
- firmware is (in my opinion) quite stable. Siglent seems to be faster in addressing bugs and community feedback
- has all decoders included, and also can decode CAN bus (Rigol can't)
- Remote web interface is really good for an instrument of this price range
- Logic analyzer and bode plot available as options
- History (segmented memory) is really useful once you learn how to use it (Rigol also has a kind of segmented memory option but is unusable)

You can find in the forum the really good deep review by Performa01 for the Siglent

[CiscERsang]

Greeting all,

While decoding...
what are the red dots at bytes as per pic attached?
Some bytes don't have that, some have.

thanks

[mematyi]

Thanks for your reply!
I have gone through those reviews. I am low on precious freetime, as I am still writing my Master Thesis currently, but as far as I can recall, they were mostly very positive.
No doubt this is a fine scope, I am particularly interested in the upcoming releases, if anybody has manufacturer or R&D info, to buy this scope or wait a bit for an even better deal. As far as I can see, Memory depth and software functions are skyrocketing even on very low-end scopes. The automated Bode-plotting function seems to be awesome for the first sight. I wish only the screens were bigger and better resolution. The 800x480 is a joke for even a mobile phone these days.

[Martin72]

Go for it!

Subscripe this.
Got the 1054Z and the 1104x-e, the siglent doesn´t have the tons of feature the rigol comes with.
But what it got, it works..
The UI in general seems more "adult" to me and the "enhanced resolution" filter function is a killer feature against the rigol.

[Performa01]

While decoding...
what are the red dots at bytes as per pic attached?
Some bytes don't have that, some have.

The red dot indicates that the display of the decoded value does not fit the box - in your case, the closing apostrophe of most ASCII decodes is truncated.

This appears to be some borderline situation though and it is certainly funny that '1' fits the space, whereas the firmware thinks that e.g. 'i' does not

[CiscERsang]

While decoding...
what are the red dots at bytes as per pic attached?
Some bytes don't have that, some have.

The red dot indicates that the display of the decoded value does not fit the box - in your case, the closing apostrophe of most ASCII decodes is truncated.

This appears to be some borderline situation though and it is certainly funny that '1' fits the space, whereas the firmware thinks that e.g. 'i' does not

Moreover, it doesn't know how looks like, for example, the "question mark" and may be other chars which I didn't try.
Anyway there's a lot of to do with the next FW update. I have a list of wishes in terms of decoding. 

Thank you!

[mematyi]

It might be a dumb question, but I noticed on the pictures, that the scope has a menu on/off button at the bottom left corner.

Does it actually switches off menus and enhancing the viewing area, or  the menu items turn off and the space remains blank?

[TauIs2Pi]

It might be a dumb question, but I noticed on the pictures, that the scope has a menu on/off button at the bottom left corner.

Does it actually switches off menus and enhancing the viewing area, or  the menu items turn off and the space remains blank?

Disabling the menus leaves a blank space. That blank space is then used for the decoding lanes which would otherwise crop the bottom of the display when menus are enabled.

[Gabri74]

Disabling the menus leaves a blank space. That blank space is then used for the decoding lanes which would otherwise crop the bottom of the display when menus are enabled.

I use it also to close any opened pop-up menu without making any choice. I find it more handy than pushing the multifunction/variable knob, because sometime It makes me wrongly choose the above/below option.

[mematyi]

Thanks!

Can you please tell me the diameters of the screen?

Is it standard 16:9 7", or some odd(preferably larger area) type?

I am really liking this scope, but the screen seems to be on the smaller side, given the mobile phones are around 6" these days.

[HendriXML]

The way i see it:
The resolution of the screen matches the bit depth (200 adc values) just fine. The size of the screen matches the resolution just fine. Before I bought it, I wished for large screens (was used to a usb scope on a monitor), now I think its fine as it is.

[daveyk]

Hello Gabri74,

The display is excellent.  My main issues, that most likely do NOT affect 99% of other scope users is:

• Personally, I find the cursors, difficult to operate.  I know you hit the bottom and it cycles between adjusting one or the other or both.  It should just cycle between adjust one or the other.  If four cursors are shown, same thing.  It is difficult for me to know which one is currently the one the will be adjusted.  That may be picking, but use a Tektronix TDS3000 series.  You easily know exactly which cursor you are about to move. Maybe it is not as versatile, but when troubleshooting, making measurements and what not, I want to concentrate on what I am testing and not having to waste attention on the scope or having to squint to figure out what cursor (or two cursors at once) are about to move when I turn the knob.  Maybe I'm dumb, or just use to a much easier scope to operate.
  
  
• You can not set the scope reference levels for pulse width measurement.  The entire world does not measure pulse width ar 50%. Sometimes, it is measured between 10% and 10%, or 90% and 90%.  I coulds accept that for a cheap scope, but I have email them and was told that's a good idea and the idea was sent on to engineers in China 1.5 years ago. Since then, I have seen two software updates released and that issue has not been address.  I don't know if they are even planning on it.  Maybe that should be a feature for a $3000-$10000 scope?  It probably would be so easy to add the feature in the scope's firmware?  I personally would have bought one more of them, and I think I could have sold a few to my colleagues with that feature added.  So since last year, I just purchased another used Tek TDS3032 and so have my colleague that uses my software.  My SDS1204X-E has basically set in my storage closet for 6+ months now without being turned on.  i get it out and get it certified once a year in case I have to rely on it as a manual backup scope.

[/li]
[/list]

Other than those two issues, I do like the scope and its presentation is so beautiful.  It has a great LCD.

Dave

P.S. - Communications back and forth with the scope works fine through the network connection.  I never could get the USB connection to work reliably.

[17_29bis]

Hello,

I already forgot if we have a dedicated thread for Siglent SDS1204X-E bugs but this is what I found strange in the latest firmware  6.1.33
I am curios  about the trigger voltage level reported when different trigger types are selected:

Example 1  - correct behavior,trigger type: PULSE,  trig. level - 0V:



Example 2 - strange behavior, trigger type: EDGE, trig level - 29V




Is a bug or it  has some explanation?

EXPLANATION: those 2 screenshots show that for triggering we use different channels. And while CH3 is actually turned off this is what creates the confusion, so this not a bug but the operator's  error. On the other hand I am not sure why CH3 is allowed to be used for triggering at all if its turned off.

Secondly: when trigger coupling is set to AC or LF filter the trigger voltage level trace is not visible. It is worth mentioning that in DC/HF filter mode the trigger voltage  level trace becomes visible only after the user changes (no matter how much) the trigger level.

[2N3055]

Sometimes you want to trigger off some signal, but don't want it use screen space, because there is nothing interesting about it.
In that case you trigger from that channel and switch it off the screen. Which is exactly same behaviour as if you use External Trigger input.
Most of the scopes nowadays allow switching channel off while using it for trigger. It is a useful thing that I use very often.

[17_29bis]

Sometimes you want to trigger off some signal, but don't want it use screen space, because there is nothing interesting about it.
In that case you trigger from that channel and switch it off the screen. Which is exactly same behaviour as if you use External Trigger input.
Most of the scopes nowadays allow switching channel off while using it for trigger. It is a useful thing that I use very often.

This particular oscilloscope allows you to hide a particular channel (its  trace) but the channel should be turned on. I assumed that if the channel is turned off then it becomes nonfunctional i.e. it cannot be used for anything (triggering etc). Am I wrong? 

[Performa01]

It's correct, you cannot trigger from a disabled channel (but you can hide the trace of any enabled channel).

Each trigger has its individual settings, so when browsing through the various trigger types the trigger channel as well as the trigger level(s) change accordingly.

The trigger setup doesn't allow you to select a disabled channel for triggering, but the stored settings for the individual trigger types do not change because of this. Consequently you are able to set the trigger to a non-active channel by selecting a different type that previously used that channel.
This is only a minor inconvenience in my book, especially as there is no real solution for this; if the originally stored trigger channel for a certain trigger type is not active, what should the DSO choose for you? The lowest enabled channel? Chances are that this isn't what you want in certain situations either.

Apart from that, I'm constantly reminding Siglent of one fundamental rule:
Never ever permanently change any user settings.

The AC (and LF-reject) trigger can be highly dynamic and the absolute trigger level position would change all the time, hence would have to be displayed permanently. This might consume valuable processing power and would be visually distracting on top of that. You still see the selected relative trigger level in the trigger info tab.