Siglent SDS1104X-E and SDS1204X-E Mixed Signal Oscilloscopes

[Gabri74]

Of course I will point Siglent R&D to your posting. You’ve already got some replies from experienced users and I want to add my comments to that:

Thanks a lot

I see your point, but the UI is generally not based on freely movable windows as in modern mid-range DSOs. So the layout is fixed and nothing can be re-positioned. It would require a major re-design and I’m not sure if Siglent is willing to do that. It means so much more than just adding the functionality. You need a user interface for customizing the user interface, including additional menu items, help texts and error messages, which need to be in a bunch of different languages. And then there’s always the concern that long time users already familiar with the current UI might be confused if something behaves very differently all of a sudden, just because they pushed the wrong button at the wrong time by accident.
Maybe an entry level scope is not the best product to start experimenting with a highly flexible new UI concept…

I agree on everything but I can't help thinking that having the possibility to move the decoded traces independently (like it's possible with math channels) and place them near the corresponding waveform could improve the readability. But of course this is a matter of personal preference and is really a minor problem. Overall I really like these decoders and I find the options and configurability do be very good (but I never owned an expensive scope... so my experience is limited)

[tautech]

Of course I will point Siglent R&D to your posting. You’ve already got some replies from experienced users and I want to add my comments to that:

Thanks a lot

I see your point, but the UI is generally not based on freely movable windows as in modern mid-range DSOs. So the layout is fixed and nothing can be re-positioned. It would require a major re-design and I’m not sure if Siglent is willing to do that. It means so much more than just adding the functionality. You need a user interface for customizing the user interface, including additional menu items, help texts and error messages, which need to be in a bunch of different languages. And then there’s always the concern that long time users already familiar with the current UI might be confused if something behaves very differently all of a sudden, just because they pushed the wrong button at the wrong time by accident.
Maybe an entry level scope is not the best product to start experimenting with a highly flexible new UI concept…

I agree on everything but I can't help thinking that having the possibility to move the decoded traces independently (like it's possible with math channels) and place them near the corresponding waveform could improve the readability. But of course this is a matter of personal preference and is really a minor problem. Overall I really like these decoders and I find the options and configurability do be very good (but I never owned an expensive scope... so my experience is limited)

Here's a thought;
Have the Decode line name match the channel trace color it's assigned to.

[Performa01]

Well, even though the screen layout is basically fixed, maybe the option to just reposition the decoder lines vertically might be doable.

Having the label in the color of the associated data channel (even as an additional improvement together with the movable decoder line) sounds good at first, but what if we use the serial decoders together with the digital channels? Well, then they could revert to the default (blue) appearance.

I have notified the responsible persons at Siglent of this discussion and might report back if I get the commitment for any improvements.

[rf-loop]

Of course it also need user learn how to use it because and of course first it may feel "why this and why that"

Not my fault this time and thanks to your screenshot showing the Event Num label which I've never seen I understood the problem:
when the decoding option is on, the Event Num label is hidden behind the decoded traces (see screen1)!
That's why I missed it in the first time and went with that complicate procedure 
When hiding the menu bottom bar (as suggested by Tautech) the Event Num label is visible again (see screen2)

oups...

Now I understand, never seen this due to fact I do not have MSO option here for this model.

Perhaps there is this and that details what need some milling, grinding and polishing in UI and how it display some details.

[Performa01]

oups...

Now I understand, never seen this due to fact I do not have MSO option here for this model.

No, no, no - this has nothing to do with MSO. It is just serial decoding on analog channels ...

... but I haven't seen it either, as I've never used serial decoders together with Event search.

[rf-loop]

oups...

Now I understand, never seen this due to fact I do not have MSO option here for this model.

No, no, no - this has nothing to do with MSO. It is just serial decoding on analog channels ...

... but I haven't seen it either, as I've never used serial decoders together with Event search.

Good correction. Thank you.

[Performa01]

I’ve asked about the most obvious/desirable improvements that resulted from our discussion here. After a brief internal evaluation, Siglent confirmed to support enable/disable for one direction on duplex decoders and remove the disabled decoder line from the screen.

Regarding the other requests, just as I’ve suspected, it’s probably not that simple to even partially change the UI concept that’s currently based on fixed display areas, so this will not be changed.

Siglent mentioned the Event Search function as the current workaround for the missing edge/pulse count. We might still get the automatic measurement though – but not in the near future, as there are some other more urgent tasks pending, like ironing out the remaining flaws in the serial decoders, improving the Bode plot feature and fixing some bugs that I've reported. So yes, I’m to blame (too), for keeping R&D folks at Siglent busy all the time – yet that’s for the benefit of all users serious about T&M out there

[tautech]

Good result....for now.
As they're polishing the upcoming SDS5kX series there's a opportunity to incorporate some of these ideas into this new platform.

[rf-loop]

I’ve asked about the most obvious/desirable improvements that resulted from our discussion here. After a brief internal evaluation, Siglent confirmed to support enable/disable for one direction on duplex decoders and remove the disabled decoder line from the screen.

Regarding the other requests, just as I’ve suspected, it’s probably not that simple to even partially change the UI concept that’s currently based on fixed display areas, so this will not be changed.

Siglent mentioned the Event Search function as the current workaround for the missing edge/pulse count. We might still get the automatic measurement though – but not in the near future, as there are some other more urgent tasks pending, like ironing out the remaining flaws in the serial decoders, improving the Bode plot feature and fixing some bugs that I've reported. So yes, I’m to blame (too), for keeping R&D folks at Siglent busy all the time – yet that’s for the benefit of all users serious about T&M out there

Btw, have you seen what all happen if Event Search find over 700 events (rise events and look white bar (top of display). It looks like it is limited to 700 events beginning from start of acquisition memory. (not big issue itself but, it do not give any limit warning to user. Of course white bar is reduced and user see there is events only in part of acq memory. Least it need give some warning to user that events are not anymore counted from whole memory length - even if it is not very clever to use like this but.

Just set 200us/div. 1MHz pulse freq and example 100ns wide pulses. Set for find pulses under 200ns. (you see events = 700  and these events are just around first 1/4 of acq memory. Of course user fast learn that if it show 700 then check carefully if it is true or not. If 700 is limit with some real reason then need somehow warn user if overflow! If user do not well know how all work - if not educated for use this scope - there is many things what may also feel bug or other way confusing.  One example. If user stop and go to history and zoom in. He can see pulse(s) what match his settings but surprise it have not white even mark. Then he try adjust settings and still no, why it do not regognize this event. Oh.... then he hit this message: Event Num:  700/700.  All event marks are in beginning of memory and not middle where he is zooming. No event marks because all 700 are used beginning of acquisiton memory and rest of matced events are not marked..

But with this small thing, overall it is quite nice feature after first "know your equipment" learning process (I mean this whole Search and Navigate system.)

[Performa01]

I have to admit that I've only checked the Search function briefly, found it basically working and then somehow forgot about it because I've just been busy with other topics. Only yesterday, the discussion here reminded me that I haven't done a review of the Search function yet ...

[wohali]

Has anyone received a new 1104/1204X-E since Lunar New Year? I still have no shipping update from my reseller, and it's been over a month since the Lantern Festival, which marks the traditional end of New Year festivities in China.

[Bear207]

Has anyone received a new 1104/1204X-E since Lunar New Year? I still have no shipping update from my reseller, and it's been over a month since the Lantern Festival, which marks the traditional end of New Year festivities in China.

Received my 1104 last Friday

Sent from my Pixel XL using Tapatalk

[Bob Sava]

I'm told it'll be 2-3 weeks before next batch arrives.

[tautech]

Has anyone received a new 1104/1204X-E since Lunar New Year? I still have no shipping update from my reseller, and it's been over a month since the Lantern Festival, which marks the traditional end of New Year festivities in China.

I got stock just after the Lantern festival but had to wait some weeks for production lead times.

[rf-loop]

Has anyone received a new 1104/1204X-E since Lunar New Year? I still have no shipping update from my reseller, and it's been over a month since the Lantern Festival, which marks the traditional end of New Year festivities in China.

Last arrived two days ago.

[W9GFO]

Has anyone received a new 1104/1204X-E since Lunar New Year? I still have no shipping update from my reseller, and it's been over a month since the Lantern Festival, which marks the traditional end of New Year festivities in China.

I ordered just over two weeks ago from Saelig, at that time they said that it was expected to arrive in one to two weeks. Found out today that they aren't expecting any units in until early May.

[4x1md]

Has anyone received a new 1104/1204X-E since Lunar New Year? I still have no shipping update from my reseller, and it's been over a month since the Lantern Festival, which marks the traditional end of New Year festivities in China.

I received from Saelig some days ago. Ordered on February 27.

Does this oscilloscope have any interesting hacks?

Is the root password known? I can connect using telnet, but don't know the root password.

[djadeski]

I just received the 1204x-e I ordered from Transcat on March 5th. 

Initially I was told 9 week lead time which would have been late April or early May.

[Performa01]

I've moved my reply here in order to not disturb that other thread. Here are the postings I'm referring to:

https://www.eevblog.com/forum/testgear/using-a-ucurrent-with-siglent-sds1204x-e-or-sds1000x-e-series-(feature-request)/msg1474694/#msg1474694
https://www.eevblog.com/forum/testgear/using-a-ucurrent-with-siglent-sds1204x-e-or-sds1000x-e-series-(feature-request)/msg1475772/#msg1475772

I hope Siglent will not just truncate the displayed data (that would be the simplest, 1 second fix to display only one line text ) but instead they will  choose to properly display relatively long decoded packets.

The solution for this is not as straight forward as it might appear. All other decoders display just one data word per line in the list view, hence the message length is only limited by the maximum number of list entries specific for each decoder. The list scroll mechanism is based on the message rather than line number and there is a fixed one by one relationship between message and line. The list window can be configured to have 1-7 lines and chances are that a long multiline message does not fit the displayed list area. Of course all this could be solved, but would require some substantial redesign – just for IIC, as no other current decoder requires that.

The statements above are my personal speculation, but I think I cannot be far off. This is also backed by the fact that Siglent takes a slightly different route:

It has been confirmed that we’ll get a proper solution providing a separate text box (for the currently selected message in the list view I assume). This box will indeed be multi-line and show the complete message.

As a side note : it would be really cool if they could fix the horizontal scrolling of the decoded data as well (sorry if I am asking too much for a 1000 Canadian dollars oscilloscope).

Rest assured that the price shall not be an excuse for any serious flaws.

I take it you're referring to the decoding line at the bottom of the trace view.

As a basis for the discussion, just let’s recall the working principle, even when it’s obvious: since this scope always displays the complete record with all its sample data, you choose the actual record length by selecting an appropriate timebase. In your example you have set 5ms/div, which means a record length of 5ms x 14 = 70ms total (using 1.4Mpts @ 20MSa/s).

Normally, the decoding line would appear compressed and not readable with these settings. In your case, it is perfectly readable and shows the first message truncated by the start of the 2nd one, which in turn contains nonsense. I have never seen a behavior like this before (with short messages) so it certainly has to do with some data buffer overflow and management data being overwritten because of the current bug.

I happen to have a screenshot with the same timebase, but only short messages:


SDS1104X-E_Serial_I2C_Setup

Bottom line decoding is compressed and not readable.

Normally, you’d zoom in until the decoding line becomes readable – either by using the Zoom function during Run or setting a faster timebase in Stop mode after the acquisition is completed. Then you should be able to scroll horizontally by changing the X-position, thus shifting the zoom window and being able to view all parts of the entire message. Here’s an example, showing the last two messages of a long capture with a total of 652 packets:


SDS1104X-E_Serial_I2C_Stop100us_last

So it works as expected with short messages (up to 17 data bytes).

For long messages, the initial decoding line looks weird already and the procedure described above certainly won’t work right now because of the bug that essentially destroys the decoding. So this should certainly be fixed with the coming release as well.

Just let’s wait and see. If something still isn’t fixed or the fix is not satisfactory, we can always discuss it here in the forum as the basis for a solution in a future update.

BTW, the reason why you see an extra 80h byte without acknowledgement at the end of all my messages is because the current IIC decoder expects a high idle level on the SCL line. Even though this is a valid assumption for a properly designed IIC bus system, the decoder should still be robust enough to handle the slightly different situation in my test scenario and this is just another example for an improvement that we’re most likely going to see in the coming firmware release.

In fact I have asked for a status regarding the serial decoders in general and it has been confirmed that the majority of my change requests has been finished by now and will make it into the coming release as well.

[4x1md]

I have a question about 500?V range.

1. When the coupling is set to GND, there is some negative DC offset on most channels.

2. When the coupling is AC or DC, there is also an offset, but it usually changes to positive.

Why does it happen and is there any way to correct it?

[Performa01]

I have a question about 500?V range.

1. When the coupling is set to GND, there is some negative DC offset on most channels.

2. When the coupling is AC or DC, there is also an offset, but it usually changes to positive.

Why does it happen and is there any way to correct it?

This is normal and not bad at all. No way - and even more importantly, no need to fix anything here. I guess you’d have a hard time finding another DSO performing better than this, even if you're willing to spend a lot more money. Finding a scope that provides true full resolution, full bandwidth 500uV/div sensitivity (not the fake software zoom) alone would be quite a challenge already.

The specification in the datasheet is:

±(1%* Offset+1.5%*8*div+500 uV): <=1 mv/div

For zero offset and 500uV/div vertical gain, as for channel 1 in your example, the first term is zero and we can calculate the rest:

±(1.5% * 8 * 500uV + 500uV) = ±(1.5% * 4mV + 500uV) = ±(60uV + 500uV) = ±560uV;

So the specified offset error is ±560uV and your unit is well within specification. If it were not, a self-calibration would usually cure it.

Only few high precision OpAmps have an offset error significantly lower than that, whereas the majority of general purpose OpAmps can be considerably worse. In actual fact we’re not talking about a precision OpAmp here, but a wideband input buffer with >200MHz bandwidth.

The reason why there is a difference between DC, AC and GND input coupling is the fact that this is quite different to a traditional analog entry level scope. I’m not going to go into detail for AC/DC coupling, suffice it to say it is not just a capacitor right at the scope input. And ground coupling is done much further down the signal path and this is also why almost all the noise vanishes with ground coupling, which would not be the case on an analog scope. Switching from input to ground at that later stage causes a different offset error than what the input buffer is calibrated for, hence the different trace position.

[4x1md]

If it is to drive a non-Siglent AWG, maybe they can charge for it.

Maybe ? 
It's very unlikely command protocols will work with other brands.

When doing Bode plots the AWG is swept through many frequencies/second so commands must be correct.

Plotting bode plot with a non-Siglent AWG is possible with a protocol translation software.

At certain point after getting the SDG1204X-E oscilloscope I wanted to know if it might be possible to use the bode plot function with a non-Siglent waveform generator.

After some researching and fuzzing I wrote a program in Python which acts as a small server. The oscilloscope connects to it using LAN and the program makes it think that it communicates with a genuine Siglent AWG. The program extracts the commands sent by the scope to the generator, parses them and translates to the command set, that the connected to the PC non-Siglent AWG is able to understand.

The video shows bode plot of an LPF with R=1kOhm and C=0.22μF. On the left you may see my program running on a netbook. For the first try I took the well known JDS6600 generator which is sold on eBay/AliExpress. Later I'll add drivers for two more AWG models.



I hope to have during the next weeks enough free time to publish the program on GitHub with detailed description on how it works.

[firstcolle]

I was waiting for that!! Looking forward to try It with my rigol awg

[Mr. Scram]

Plotting bode plot with a non-Siglent AWG is possible with a protocol translation software.

At certain point after getting the SDG1204X-E oscilloscope I wanted to know if it might be possible to use the bode plot function with a non-Siglent waveform generator.

After some researching and fuzzing I wrote a program in Python which acts as a small server. When the oscilloscope connects to it using LAN. It thinks that it communicates with a genuine Siglent AWG. The program extracts the commands sent to the generator, parses them and translates to the command set, that the connected to the PC non-Siglent AWG is able to understand.

The video shows bode plot of an LPF with R=1kOhm and C=0.22μF. On the left you may see my program running on a netbook. For the first try I took the well known JDS6600 generator which is sold on eBay/AliExpress. Later I'll add drivers for two more AWG models.



I hope to have during the next weeks enough free time to publish the program on GitHub with detailed description on how it works.

Cool and that's actually fairly close to what I was planning to do. I don't quite understand the fascination with the built in or provided signal generators. It shouldn't be too hard to write a small script that does the same, as long as you have a SCPI scope and signal generator or AWG. You don't even have to depend on the accuracy of the generator, you can just measure the signal before it goes in and after it comes out. Plot to chart and done. If you have a sweep function on the generator it might be even easier.

[Performa01]

Plotting bode plot with a non-Siglent AWG is possible with a protocol translation software.

At certain point after getting the SDG1204X-E oscilloscope I wanted to know if it might be possible to use the bode plot function with a non-Siglent waveform generator.

After some researching and fuzzing I wrote a program in Python which acts as a small server. When the oscilloscope connects to it using LAN. It thinks that it communicates with a genuine Siglent AWG. The program extracts the commands sent to the generator, parses them and translates to the command set, that the connected to the PC non-Siglent AWG is able to understand.

The video shows bode plot of an LPF with R=1kOhm and C=0.22μF. On the left you may see my program running on a netbook. For the first try I took the well known JDS6600 generator which is sold on eBay/AliExpress. Later I'll add drivers for two more AWG models.

Well done! 

AWG control for the bode plotter is a standard feature free of charge and of course it should always be possible to make any signal generator compatible by means of a command translator, as long as it can provide the required frequency resolution.
Wouldn't have guessed someone would go to the effort that soon

After watching your video, there's one little hint about cursor measurements: in many cases (and certainly for the bode plot) it might be beneficial to use auto tracking cursors instead of manual ones.