Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[tautech]

Wondering if this is a bug in the I2C decoder.

BTW, please state firmware version in use.

[tautech]

But acquisition is stopped. The data signal is right there with all the bits, and a clean-looking clock too. Why can't it be decoded? I also fail to see how triggering could get in the way.

If it need be Stop'ed, Trigger or some other decode setting are not optimal.

[ebastler]

But acquisition is stopped. The data signal is right there with all the bits, and a clean-looking clock too. Why can't it be decoded? I also fail to see how triggering could get in the way.

If it need be Stop'ed, Trigger or some other decode setting are not optimal.

... or you might just admit that you misunderstood the problem and gave irrelevant advice. Happens to the best of us...

We don't know if it had to be stopped to decode at all, or was just stopped to take the screenshot. And in any case, tweaking the triggering will not help because there is apparently another issue, which was shown to cause decoding problems even when triggering is taken out of the game entirely.

[tautech]

But acquisition is stopped. The data signal is right there with all the bits, and a clean-looking clock too. Why can't it be decoded? I also fail to see how triggering could get in the way.

If it need be Stop'ed, Trigger or some other decode setting are not optimal.

... or you might just admit that you misunderstood the problem and gave irrelevant advice. Happens to the best of us...

We don't know if it had to be stopped to decode at all, or was just stopped to take the screenshot. And in any case, tweaking the triggering will not help because there is apparently another issue, which was shown to cause decoding problems even when triggering is taken out of the game entirely.

Yes well I am considering getting a 2kX Plus out and showing results......
First we need see which FW was being used. 

[Martin72]

I currently have a Plus model in the house, but my STB-3 board is still a bit buggy when it comes to I²C decoding.

[tautech]

I currently have a Plus model in the house, but my STB-3 board is still a bit buggy when it comes to I²C decoding.

Yep yours is and when I visit Siglent next year you can be sure I'll be taking it up with them as all I have heard back about yours is crickets ! 

[MathWizard]

Ok I'll check into warranty on the probes, thanks. I never yanked on them or tripped over them, so IDK.

Now I'm afraid that my "good probes" which cost +$100 for 4, also had a problem way early than I expected, and that's why I was using these new included probes from day 1. Or was I just giving the old ones a rest?

[tautech]

Ok I'll check into warranty on the probes, thanks. I never yanked on them or tripped over them, so IDK.

They are much better now however we did have a poor batch of P215 and Siglent have worked with their supplier to improve quality.
The shield connection was often poor and would make/break when flexed.

Member xrunner had one replaced and went on to fix the faulty one.
Here and investigations are in previous posts:
https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg4667176/#msg4667176

[Slartibartfast]

Why do you think triggering is related to the issue?

The spikes on Ch2 here:

Those spikes are real and are there because the master released data a little earlier than the slave asserts it for the ACK. They are harmless, because they happen during clock being low, hence they are ignored. They are not due to premature re-triggering. Please note there is no retriggering, as single acquisition was used. Acquisition is stopped, as ebastler pointed out before me.

From my point of view, there are traces that show signals from a specific time window of 200µs at some instance in time. This acquired data is what the decoder has to work on. Now, it is clear that if the traces would start right in the middle of an ongoing transmission, the decoder has nothing to sync on at the beginning of the trace, but even then it should resynchronise when it sees START or STOP conditions. But even that is not the case. The trace starts at a time when the bus is idle, and consequently the decoder start decoding porperly, and then suddenly looses sync. Later in the trace, the decoded information is inconsistent with the traces. This should not happen.

I completely fail to see any connection to the triggering.

225us trigger offset is NOT Holdoff !

I never claimed it is. I still don't see what's the issue with hold-off. I don't use it (in this case). Why should I?

Using Holdoff and a Falling Edge for simple decoding illustrations is how I do it too but to trigger on specific bits one must use a decode trigger.

I do not trigger on bits, but on the first clock edge.

Holdoff is never shown/displayed so set it to a bit longer than a packet and show us the result.

I did that anyway, and as I expected(*), the result ist basically the same. It lost sync one byte earlier, but repeating a few times I found it sometimes looses sync on one, sometimes on the other byte. This indeed seems to suggest that the decoder fails to cope with the borderline pull-ups, i.e. not rapidly enough rising edges. No issue for the chips on the bus, though, the I2C communication seems to work properly.

(*) With single acquisition, and the last clock edge many seconds to minutes before the trigger point, what's the point of hold-off?

BTW, please state firmware version in use.

The firmware is obviously the latest, 1.5.2r3. What's the point of trying to identify a firmware bug if the firmware weren't the latest?

[tautech]

With single acquisition, and the last clock edge many seconds to minutes before the trigger point, what's the point of hold-off?

Sure for single it shouldn't be needed however in Run mode the correct Holdoff gives rock solid triggering although with multiple packets coming through the payload is often changing.

I need make room on the bench to setup some examples......

[Slartibartfast]

But acquisition is stopped. The data signal is right there with all the bits, and a clean-looking clock too. Why can't it be decoded? I also fail to see how triggering could get in the way.

If it need be Stop'ed, Trigger or some other decode setting are not optimal.

Sorry, but this is bullshit. There are always cases where picking a specific instant in time (and none later) in a complex, non-repetitive signal is just not within the trigger capabilities of any given scope. This is particularly frequent on digital buses. You want to see that instant, and avoid having the scope re-triggering on later events, you choose single acquisition. That's what it's for. And after it triggered, it stops.

[Slartibartfast]

We don't know if it had to be stopped to decode at all, or was just stopped to take the screenshot.

In this case, I'm debugging firmware. I wanted to see the very first few transactions on the bus because those are the only ones where I know precisely what data is supposed to be transferred. So I set the scope to single trigger, and reset the MCU.

[ebastler]

Sure for single it shouldn't be needed however in Run mode the correct Holdoff gives rock solid triggering although with multiple packets coming through the payload is often changing.

I need make room on the bench to setup some examples......

I don't think examples will be needed. Nobody is doubting that a holdoff time can be useful when triggering on complex recurring sequences. All we are saying is that holdoff is a solution which has nothing to do with slartibartfast's present problem. 

[Slartibartfast]

I had a hunch, and it looks as if it was right.

In the wild, perfect signals are the exception, usually signals are messy in one or the other way. Here, the borderline pull-ups. I added additional pull-up resistors (i.e. in parallel) up to the point where the resistance becomes so low that the EEPROM is getting close to the limit of it's driving capability. The signals are cleaner in the sense of rising much more rapidly. And lo and behold! The decoder works a lot better!

The first screenshot shows the previously shown first read transaction on the bus. Now the decoder keeps sync perfectly and decodes properly. The same is true in the second picture where it has to work with less samples per bit. On a side note: Here is in fact a bug in the firmware of the device I'm working on: It writes 15 bytes in a row, which these standard EEPROMs cannot handle this way.

So it seems to me that it is not a bug in the I2C decoder per se what I have observed, but a really lousy capability of dealing with less-than-perfect signals. This really could do with an improvement, as my original signals were still clean enough for the chips involved, so test equipment should also be up to the task.

Apart from that, a few minor observations and wishes on the scope:

• After one of the last upgrades (don't know which) it seems the option of choosing the storage path seems to have disappeared, I cannot find it anymore. Where is it? It is not where the manual says it is.
• I like the option to not include the menu bar in the screenshot, but can we get rid of the mouse pointer as well? That would be really good for using shots in documentation, where they should be clean. A menu bar is easy to edit out, a mouse pointer, possibly covering a bit of a trace, not so.
• After hitting the PRINT button, a box appears saying "Saved to file ... / Next save as file ...". Is there a way to make that box disappear automatically?
• I believe it normally is not necessary to specifically unmount a USB drive before disconnecting it. At least, neither Linux nor Windows complains about an inconsistent file system, and I also found no hint of any such requirement in the manual. In addition, I cannot find in any menu any button that would trigger an unmount. However, I observed a few times, that after pulling out a USB stick, even after allowing several extra seconds to complete the write, the scope would not accept any USB sticks anymore.

Beyond these, I'm still very happy with the scope.

Cheers  Peter

[Martin72]

After hitting the PRINT button, a box appears saying "Saved to file ... / Next save as file ...". Is there a way to make that box disappear automatically?

Should come with the next update - On my HD this has been already "fixed".
Edit:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-missing-features-and-bugs/msg5114079/#msg5114079

[2N3055]

I had a hunch, and it looks as if it was right.

In the wild, perfect signals are the exception, usually signals are messy in one or the other way. Here, the borderline pull-ups. I added additional pull-up resistors (i.e. in parallel) up to the point where the resistance becomes so low that the EEPROM is getting close to the limit of it's driving capability. The signals are cleaner in the sense of rising much more rapidly. And lo and behold! The decoder works a lot better!

The first screenshot shows the previously shown first read transaction on the bus. Now the decoder keeps sync perfectly and decodes properly. The same is true in the second picture where it has to work with less samples per bit. On a side note: Here is in fact a bug in the firmware of the device I'm working on: It writes 15 bytes in a row, which these standard EEPROMs cannot handle this way.

So it seems to me that it is not a bug in the I2C decoder per se what I have observed, but a really lousy capability of dealing with less-than-perfect signals. This really could do with an improvement, as my original signals were still clean enough for the chips involved, so test equipment should also be up to the task.

Apart from that, a few minor observations and wishes on the scope:

• After one of the last upgrades (don't know which) it seems the option of choosing the storage path seems to have disappeared, I cannot find it anymore. Where is it? It is not where the manual says it is.
• I like the option to not include the menu bar in the screenshot, but can we get rid of the mouse pointer as well? That would be really good for using shots in documentation, where they should be clean. A menu bar is easy to edit out, a mouse pointer, possibly covering a bit of a trace, not so.
• After hitting the PRINT button, a box appears saying "Saved to file ... / Next save as file ...". Is there a way to make that box disappear automatically?
• I believe it normally is not necessary to specifically unmount a USB drive before disconnecting it. At least, neither Linux nor Windows complains about an inconsistent file system, and I also found no hint of any such requirement in the manual. In addition, I cannot find in any menu any button that would trigger an unmount. However, I observed a few times, that after pulling out a USB stick, even after allowing several extra seconds to complete the write, the scope would not accept any USB sticks anymore.

Beyond these, I'm still very happy with the scope.

Cheers  Peter

It seems that nobody asked how thresholds for clock and data signals in decode setup was set?
Sometimes with edges that are slow, voltage threshold can, to significant degree, move where detection point is in time and screw up timing...
One thing that is sometimes confusing is that thresholds for trigger and decode are separate (you can copy them though).

[Slartibartfast]

It seems that nobody asked how thresholds for clock and data signals in decode setup was set?

This is a good point, I should have mentioned that I had set the threshold to exactly the same voltage as the trigger: 2V. Maybe I forgot because indirectly the info is there: in the trigger box. 

Why do you talk about thresholds (plural)? I can only set one threshold, presumably valid for both clock and data.

Cheers  Peter

[Performa01]

So it seems to me that it is not a bug in the I2C decoder per se what I have observed, but a really lousy capability of dealing with less-than-perfect signals. This really could do with an improvement, as my original signals were still clean enough for the chips involved, so test equipment should also be up to the task.

As 2N3055 has pointed out, the threshold levels play a major role when dealing with slow signals. This would be the first place to do any tweaking. And yes, decoders and triggers are completely separate modules, only connected by the possibility to copy settings either direction. The preferred way to deal with that is to set up the decoding until it works fine and the copy these settings to the trigger engine, which should then enable the triggering on specific messages.

• After one of the last upgrades (don't know which) it seems the option of choosing the storage path seems to have disappeared, I cannot find it anymore. Where is it? It is not where the manual says it is.

What does the manual say? The latest manual (EN01D) gives the same example as older versions to set the image format, default path and basis filename for screenshots together with some options for the visual appearance in chapter 29.3.2 on page 317. This is still valid even for the unreleased V1.6.0 beta firmware. This example isn’t a particularly good one, because BMP is certainly not the screenshot format of choice; what we really want is PNG!

• I like the option to not include the menu bar in the screenshot, but can we get rid of the mouse pointer as well? That would be really good for using shots in documentation, where they should be clean. A menu bar is easy to edit out, a mouse pointer, possibly covering a bit of a trace, not so.

I’ve never tried it (I do not use a mouse), but it’s said that the mouse pointer is not visible in the screenshot if you move it to the border of the screen.

• After hitting the PRINT button, a box appears saying "Saved to file ... / Next save as file ...". Is there a way to make that box disappear automatically?

It’s already in the V1.6.0 firmware and works exactly like in the SDS2000X HD and SDS6000A.

• I believe it normally is not necessary to specifically unmount a USB drive before disconnecting it. At least, neither Linux nor Windows complains about an inconsistent file system, and I also found no hint of any such requirement in the manual. In addition, I cannot find in any menu any button that would trigger an unmount. However, I observed a few times, that after pulling out a USB stick, even after allowing several extra seconds to complete the write, the scope would not accept any USB sticks anymore.

Since I’ve currently not set up a network connection, I do all picture transfers via USB stick at the moment. This includes 4 DSOs, where the SDS2000X Plus and HD see the most use by far and the USB stick is plugged and unplugged dozens of times a day. Never ever did I have any issues like that.

[2N3055]

It seems that nobody asked how thresholds for clock and data signals in decode setup was set?

This is a good point, I should have mentioned that I had set the threshold to exactly the same voltage as the trigger: 2V. Maybe I forgot because indirectly the info is there: in the trigger box. 

Why do you talk about thresholds (plural)? I can only set one threshold, presumably valid for both clock and data.

Cheers  Peter

I2C Protocol Signals menu.
For I2C protocol you have separate thresholds for SCL and SDA.

If you want for scope to "see" same thing as your hardware, check hardware thresholds and set it to similar value.

[Performa01]

Why do you talk about thresholds (plural)? I can only set one threshold, presumably valid for both clock and data.

Huh?


SDS2354X_Plus_Serial_I2C_Thresholds

[Slartibartfast]

Why do you talk about thresholds (plural)? I can only set one threshold, presumably valid for both clock and data.

Huh?

Sorry for that, I messed that up, talking from memory, rather than checking.

In my measurements, both were set to 2V.

Cheers  Peter

[rf-loop]

And if we want make better.
Oscilloscope decoder need have more settings for signals.
Now there is only one threshold for one signal.
In I2C is is better if there are separate thresholds for High state and Low state.
Typical definition is that signal level is High if level is >70% and it is Low if level is <30%
Or different depending circuits used.
Other possibility is set threshold and hysteresis.

The decoder should use as precisely as possible the specified limit values according to the specification or the values used by the examined bus. Otherwise, the decoding may show an error even though the actual traffic is working or vice versa.

Anyway, it kind of bothers me that only one HI/LO threshold (with unknown hysteresis)  is set for each signal (in this case for SCL and SDA) when in reality there is an accepted level window for 1 and an accepted level window for 0 and the level window between these are "undefined" status. Although these are not really hardcore analyzers. Still, it would be good to strive for better.

[Slartibartfast]

The preferred way to deal with that is to set up the decoding until it works fine

  Rookie's method (trial and error) to set up the decoding?

I prefer to use an informed choice for the thresholds.

PS.: I think rf-loop has an important point.

What does the manual say? The latest manual (EN01D) gives the same example as older versions to set the image format, default path and basis filename for screenshots together with some options for the visual appearance in chapter 29.3.2 on page 317. This is still valid even for the unreleased V1.6.0 beta firmware. This example isn’t a particularly good one, because BMP is certainly not the screenshot format of choice; what we really want is PNG!

Shame on me, I was still on EN01C. But as you say, EN01D is no different (well, they chose to replace a font in EN01C that was really nice to read, particularly on screen, by one in EN01D that's rather awful on anything but printed on paper).

On the issue of the default path: Pages 312 to 314 each show a menu that has the option "Save Path" or "Recall Path" with "Internal" and "External". These options do not exist on my scope. When saving/recalling via mouse or on-screen-finger one can choose this via the file manager. This does not work, though, when hitting the PRINT button. So, concrete question: How do I set the scope up such that after powering up, without messing with menus first (i.e. by default), hitting PRINT saves the screenshot in a particular folder, that is not called 'SIGLENT', on the thumb drive?

The page you're mentioning explains all a sort of things by using menus. It does not explain how to set up defaults. In fact, the only sentence in the manual where the word 'default' refers to a path, is "The default save path is \SIGLENT\." (Page 318 EN01D)

I’ve never tried it (I do not use a mouse), but it’s said that the mouse pointer is not visible in the screenshot if you move it to the border of the screen.

I do not use a mouse either, as it takes too much space on a lab table. A trackball is just perfect for this purpose. What I cannot stand at all is fatty fingerprints on screens.

In any case, your suggestion is off the point. During normal workflow I would create screenshots during the development work, and when writing documentation, I choose from those. During development I do not have documentation on my mind, and certainly would not care where the pointer is. I wonder if this would be much different for anybody.

Since I’ve currently not set up a network connection, I do all picture transfers via USB stick at the moment. This includes 4 DSOs, where the SDS2000X Plus and HD see the most use by far and the USB stick is plugged and unplugged dozens of times a day. Never ever did I have any issues like that.

Same for me, I also used to save directly to my NAS, but I'm without network at the moment. So it's possible the issue was there before, I just didn't notice because I did not use thumb drives at the time. Well, I'll keep watching out, might be a hardware issue.

Cheers  Peter

[Slartibartfast]

And if we want make better.
Oscilloscope decoder need have more settings for signals.
Now there is only one threshold for one signal.

Sorry, that was my mistake. There are indeed two settings, separate for CK and D. But I share your opinion

In I2C is is better if there are separate thresholds for High state and Low state.
Typical definition is that signal level is High if level is >70% and it is Low if level is <30%
Or different depending circuits used.
Other possibility is set threshold and hysteresis.

and would even prefer high / low thresholds over having separate thresholds for the two lines.

The decoder should use as precisely as possible the specified limit values according to the specification or the values used by the examined bus. Otherwise, the decoding may show an error even though the actual traffic is working or vice versa.

Correct. However, AFAIK I²C does not specify the thresholds. The values for the involved chips could be used, however the chips on the bus do not all have the same thresholds, and sometimes the master, sometimes a slave drives the D line, or listens to the level. A perfect decoder that takes all that into account is immensely complex, as it needs to figure out which device is driving the line at any particular moment.

Cheers  Peter

[rf-loop]

And if we want make better.
Oscilloscope decoder need have more settings for signals.
Now there is only one threshold for one signal.

Sorry, that was my mistake. There are indeed two settings, separate for CK and D. But I share your opinion

No, there IS only one threshold for one signal in SDS2000X Plus, SDS2000X HD and many other Siglent oscilloscopes (and many others too). Example SCL (this is one signal in my context) have just one threshold. Can not define threshold for High state level and Low state level.

Here's an example of how NXP says general information related to their stuff and views on I2C definitions.