Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[tautech]

 
Are you on 5.4 Uboot version with 1.6.2R5 firmware ?

The other possibility is the Save type has been changed to other than PNG.
Check the Utility/Save menu for Save settings.

Ok thanks I'll check that.

Try a factory Default.

[mon]

Ran into a bug that I couldn't replicate, but I think it's indicative of the new FW being a bit rough around the edges (all the previous notes in this thread give a similar impression - many improvements to features, but a bit buggy).

I have a custom probe scale of 1:20, firstly when I went to select it, it said 1:1 but changed to 1:20 after I tapped it.
Then I turned measurements back on, but it was still showing measurements as if the probe was at 1:1. Took a hot minute to work out what was going on there...
Switching back to 1:1 and then to 1:20 finally convinced it to scale my measurements.

[KungFuJosh]

I have a custom probe scale of 1:20, firstly when I went to select it, it said 1:1 but changed to 1:20 after I tapped it.
Then I turned measurements back on, but it was still showing measurements as if the probe was at 1:1. Took a hot minute to work out what was going on there...
Switching back to 1:1 and then to 1:20 finally convinced it to scale my measurements.

Assuming the tapping isn't related to a questionable mechanical connection...

That's not related to the firmware specifically, it's an annoyance in general with Siglent scopes right now. Certain circumstances prevent the scopes from correctly autosensing the probes. For example, set your scope to default with different probes connected. Only the defaulted setting will show up. If it was 1:10 or 1:1 when your default settings were saved, that's what it will show regardless of what type of probe is connected.

[tautech]

Ran into a bug that I couldn't replicate, but I think it's indicative of the new FW being a bit rough around the edges (all the previous notes in this thread give a similar impression - many improvements to features, but a bit buggy).

I have a custom probe scale of 1:20, firstly when I went to select it, it said 1:1 but changed to 1:20 after I tapped it.
Then I turned measurements back on, but it was still showing measurements as if the probe was at 1:1. Took a hot minute to work out what was going on there...
Switching back to 1:1 and then to 1:20 finally convinced it to scale my measurements.

Please always state the firmware version in use to allow verification of your report.

[mon]

That's not related to the firmware specifically, it's an annoyance in general with Siglent scopes right now. Certain circumstances prevent the scopes from correctly autosensing the probes. For example, set your scope to default with different probes connected. Only the defaulted setting will show up. If it was 1:10 or 1:1 when your default settings were saved, that's what it will show regardless of what type of probe is connected.

None of my probes have the autosense pin, so I don't think that's the issue.

Please always state the firmware version in use to allow verification of your report.

Knew I forgot something... Firmware 1.6.2R5, OS 5.4.0. I tried a few reboots this morning to replicate with no luck.

Stab in the dark - I can't remember if I've used my custom probe multiplier since I upgraded to 1.6, could have been a bug in the settings upgrade routine? I came from 1.5.2R3.

[Pinörkel]

Hello,
I just wanted to do some timing analysis with the logic probes and ran into an issue that made working on this pretty much impossible. I checked the firmware change log, found nothing related but updated to the latest firmware anyways. Re-testing with firmware V1.6.2R5 showed the same result:

Description of the issue:
- I configured the scope to record 4 to 5 digital channels and recorded a data burst of about 1.5 seconds length with the scope set to display 200ms/div.
- The recording then shows up, filling up most of the screen.
- If I just zoom in at the center position, I then can view the data in detail.
- However, if I want to inspect the data at the end of the data burst, center the view on the end of the data burst and then zoom in something strange happens:
  - Zooming in to 50 ms/div works without issues
  - Zooming in to 20 ms/div catapults me to somewhere at the beginning of the data burst, while showing that the timebase offset remained the same.
  - Zooming out to 50 ms/div then gets me where I was before.
  - Trying to scroll from the wrong position at 20 ms/div to the end of the data burst starts showing no data way before I reach the desired position.
  - If I now zoom out at that scrolled position, i can now zoom out to 100 ms/div until the position jumps back again to the and of the data when going to 200 ms/div.
  - The attached images show the observed issue on firmware 1.5.2R1 for zooming in and on firmware V1.6.2R5 when zooming out at the scrolled position.
- Rebooting the scope does not solve the issue.

Is this a known firmware bug or does this maybe hint at a memory hardware defect? I cannot imagine that this behavior is normal, since it affects a basic function and someone else should have stumbled on this way before me. However, I could not find any information on this on the web.

In addition to this, I noticed that with the newer firmware version, I can no longer start recording by pressing the Run/Stop button, but have to press Auto in the trigger section to start recording. Is this the expected behavior?

[2N3055]

Firstly, there is no data outside captured data, obviously.

On none of the images you show you are using Zoom function.
You are changing timebase.

When you are changing timebase, a change happens around reference position. Reference position behaviour can be changed in System settings.
I would recommend browsing through the manual on the topic and some experimentation to understand how it behaves.

Also try using actual Zoom function, where you will have overview of whole capture and magnified portion at the same time, together with obvious marker what part of full capture is magnified.

Hope this helps a little.

[Pinörkel]

Thank you for your reply.

Firstly, there is no data outside captured data, obviously.

Yes, I can agree with that, but do not see a connection to the observerd issue.

On none of the images you show you are using Zoom function.
You are changing timebase.

Sorry, terminology error on my side. By zooming in, I meant shortening the displayed timebase on the recorded data.

When you are changing timebase, a change happens around reference position. Reference position behaviour can be changed in System settings.
I would recommend browsing through the manual on the topic and some experimentation to understand how it behaves.

I have this configured so that the reference position is at the horizontal center of the screen. I think, I have a reasonably good understanding on how this should work on this scope(and others from Tektronix, R&S, etc...), but assuming a user error first, is always a good strategy. I like that.
Being forced to question my methods, I did some further experiments and discovered that I can only reproduce the issue when I set the memory depth to 200M (resulting in 25.0 MSa/s + 50Mpts on the digital channels). I could not observe the issue with the memory depth set to 20M (resulting in 2.5 MSa/s + 5Mpts on the digital channels).
Before doing these tests, I reapplied all available updates and did a factory reset on the scope. While testing, I additionally discovered that after the updates, it is now very difficult to obtain any data by pressing the Run/Stop button to start and end acquisition. Before I did the updates, this worked reliably. After the updates, the scope now only records data in about 1 of 20 attempts. This is not caused by no data being present or bad trigger settings.

Also try using actual Zoom function, where you will have overview of whole capture and magnified portion at the same time, together with obvious marker what part of full capture is magnified.

That was a very good idea because this let me take a screenshot that unmistakably shows that there is a bug. The attached screenshots show the whole data burst and the same data with the zoom function activated. Tin the second screenshot the window position indicator in the overview is located at the end of the burst, but the lower zoom window shows data from the beginning of the data burst (I can recognize that from the data pattern).

Hope this helps a little.

[cte]

@Pinörkel:
From the screenshot you've made, it looks like you have changed timebase while in STOP mode. In your screenshot, I've marked the original acquisitioned frame in magenta color. It looks like you wanted to zoom out one step.

You probably wanted to zoom out, but had the upper window active (slashed border shows the active window). "Zooming" in the upper window will change the Timebase of the acquisition. This will work as long as the acquisition is running, but will have strange effects when in STOP mode.

I guess Siglent behaves differently here than other scope manufacturer. But I don't know for sure.

Ensure the lower window is marked active when zooming and you should be good.

[tautech]

@Pinörkel
Triggering on an inactive channel will always return strange results.

Horizontal Reference Position can be set to be fixed for it not to move when changing the timebase, 2N3055 mentions this.

[Sorama]

Looks like chosen channel for trigger is wrong.

[cte]

@Pinörkel
Triggering on an inactive channel will always return strange results.

I totally missed that. Absolutely right!

[tautech]

@Pinörkel
Triggering on an inactive channel will always return strange results.

I totally missed that. Absolutely right!

In this day and and time of the DSO, many do not understand the absolute power of trigger settings.....they are everything to getting a result, everything.

Those that have lived only with older CRO's are most prone to falling into this trap.....been there, done that and earned the Tee shirt. 

[Pinörkel]

OK, shame on me. Apparently I am not able to describe my original issue well enough for anyone to understand or I put too much distracting other stuff in my description. I will try again:

I understand that my previous screenshots may have contained a lot of stuff that suggested that there might also have been tiggering issues. If triggering on an inactive channel might cause issues with data acquisition, I will prevent doing that that in the future. However, since the tiggering is not related to my original issue, it would be nice if we could, for now, ignore all triggering related matters altogether.

Regarding the Horizontal Reference Position, you mentioned: mine is set to a "Delay 50%" and works exactly as intended when the issue does not occur. If I change it to "Position", it also works as intended, when the issue does not occur.

For reproducing the issue, lets assume that I have recorded a data burst with the memory depth set to 200Mpts and the timebase set to 200 ms/div while not in stop mode. Lets further assume that the trigger was set to D3, armed in single shot mode, caught the correct rising edge and we now have a perfectly fine recorded waveform and the scope is in stop mode again. This state can be seen in following screenshot.



Now in this state, I change the horizontal position to the end of the data burst (which is then in the center of the screen at my set reference position), and then change the timebase from 200 ms/div to 50 ms/div to zoom in a little on the end of the data burst. While changing the timebase, the scope correctly zooms into the position, I defined as reference position (Delay 50% = horizontal center of the screen). Now, if I do one more step to 20 ms/div, the scope does not stay at the correct position, but jumps to somewhere at the beginning of the data burst. If I go to 50 ms/div again it returns to the correct position. While all the changes of the timebase value, the offset of the reference position, displayed at the bottom of the screen stays the same. So obviously, the scope is displaying data at a different position than it pretends to do. Exactly this issue can also be seen if I activate zoom mode at the same position with the timebase set to 50 ms/div or above. To prove this, I have made screenshot in zoom mode that clearly shows that the potion of data shown in the main view and the highlighted potion of data in the overview bar at the top are not the same, although they should be.



So as I see it, my scope cannot access recorded data correctly when the memory depth was set to 200Mpts. Any attempt to display the recorded data at a certain smaller timebase value and below will lead to an incorrect potion of the data to be displayed. It does not matter if this condition is produced by simply lowering the timebase value or activating zoom mode.

I hope this attempt at an explanation was easier to understand.

[tautech]

See datasheet for Digital mode memory depth spec.
Try Zoom mode

[Pinörkel]

See datasheet for Digital mode memory depth spec.

OK, the datasheet mentions a memory depth for the digital channels of 50 Mpts/ch. This is also displayed correctly in my screenshots above. So I am not sure which conclusion I should have drawn from this.

Try Zoom mode

As you should be able to see in my previous post, which includes a screenshot of the scope being in zoom mode while showing the issue, I already did that. In addition to that, I just tried again and observed that the position jumping also occurs in the overview window if you lower the timebase value while the overview window is active.

You mentioning "Digital mode" mode, however, made me think. What if the issue only affects digital channels? So I did a quick test and probed the D3 signal additionally with a probe on channel 1. As expected, both waveforms match up, but only the ones on the digital channels are affected by this position jumping issue. The position on channel 1 stayed exactly where it was supposed to be and did not jump, not when changing the time base, and not when activating the zoom mode. To me, this clearly looks like a memory indexing error, affecting only the digital channels.

[tautech]

I see screenshots with the horizontal trigger position far off the primary timebase display, why ?

Normally in the primary timebase the HPos indicator would remain somewhere on the primary display yet the indicator could be anywhere for the zoomed display.

The sideways pointing indicator shows it’s off the zoomed display which is normal use but the primary timebase HPos indicator should remain on the unzoomed portion.
This should not matter if the Acquisition memory mode is set to Fixed however a time offset of that amount could be part of the problem.

I would test again with a much slower primary timebase and retain the HPos indicator on that display and use the power of more horizontal zoom in the secondary timebase.

[cte]

For reproducing the issue, lets assume that I have recorded a data burst with the memory depth set to 200Mpts and the timebase set to 200 ms/div while not in stop mode. Lets further assume that the trigger was set to D3, armed in single shot mode, caught the correct rising edge and we now have a perfectly fine recorded waveform and the scope is in stop mode again. This state can be seen in following screenshot.

Now in this state, I change the horizontal position to the end of the data burst (which is then in the center of the screen at my set reference position), and then change the timebase from 200 ms/div to 50 ms/div to zoom in a little on the end of the data burst. While changing the timebase, the scope correctly zooms into the position, I defined as reference position (Delay 50% = horizontal center of the screen). Now, if I do one more step to 20 ms/div, the scope does not stay at the correct position, but jumps to somewhere at the beginning of the data burst. If I go to 50 ms/div again it returns to the correct position. While all the changes of the timebase value, the offset of the reference position, displayed at the bottom of the screen stays the same. So obviously, the scope is displaying data at a different position than it pretends to do. Exactly this issue can also be seen if I activate zoom mode at the same position with the timebase set to 50 ms/div or above. To prove this, I have made screenshot in zoom mode that clearly shows that the potion of data shown in the main view and the highlighted potion of data in the overview bar at the top are not the same, although they should be.

I tried to reproduce your steps as best as I could but haven't found any oddities. But I might be missing something...

Your screenshot indicates that your horizontal position is at 1,38s. But in my reproduction attempt, acquisition data ends at 1s. Can you elaborate on your setup or maybe do a screencast of it, starting with sane defaults?

[Pinörkel]

I see screenshots with the horizontal trigger position far off the primary timebase display, why ?

Because I explicitly changed position and timebase so that one could clearly see the issue.

Normally in the primary timebase the HPos indicator would remain somewhere on the primary display yet the indicator could be anywhere for the zoomed display.

The sideways pointing indicator shows it’s off the zoomed display which is normal use but the primary timebase HPos indicator should remain on the unzoomed portion.
This should not matter if the Acquisition memory mode is set to Fixed however a time offset of that amount could be part of the problem.

I would test again with a much slower primary timebase and retain the HPos indicator on that display and use the power of more horizontal zoom in the secondary timebase.

OK, kind of strange, since clear evidence of an issue is already there, but I'll try to see it as a challenge, because the evidence for the existence of the problem will get stronger with each attempt. Next attempt with all requested boundary conditions:

The first image shows a recorded data burst with all previous triggering requirements satisfied in zoom mode with the triggering position still visible in the overview window. Additionally, I have included channel 1 measuring the exact same signal as D3.


Now, if I lower the timebase of the zoomed window by just one step, all the digital channels in the zoomed window get knocked off to somewhere at the beginning of the recording. However channel 1 is still displayed correctly.


Same situation as before, but now I just change the horizontal position of the zoomed window a tiny bit to the right(you can verify this with the small peaks at the bottom of the channel 1 trace), all the digital channels in the zoomed window get knocked off to somewhere at the beginning of the recording. However channel 1 is still displayed correctly. The horizontal position at which this happens is very specific and repeatable.


The issue would not show up if I try the same at a position in the left half of the data recording. It seems to be kind of a requirement to view data in the rightmost third of the recorded data, but I am not completely sure about that. Of course the issue would also show up, like described before, when not using zoom mode but just changing position and timebase of the main display on the recorded data to view the right end of the data burst. I think it should now be quite difficult deny that there is clearly an issue with the digital channels.

[Pinörkel]

I tried to reproduce your steps as best as I could but haven't found any oddities. But I might be missing something...

Hmm, I had a look at the video and could not spot any obvious issues. However, your recording looks very uniform from start to end. It would be difficult to identify a jump, if the data in both regions looked about the same.

Your screenshot indicates that your horizontal position is at 1,38s. But in my reproduction attempt, acquisition data ends at 1s. Can you elaborate on your setup or maybe do a screencast of it, starting with sane defaults?

What settings would you be interested in? I started this off by doing a factory reset, then activated and renamed the digital channels I needed, set the timebase to 200 ms/div and the trigger to rising edge on D3. Then I recorded data with single shot triggering.

[edit]: I forgot that I also set the memory depth to 200M. I just retried this by doing exactly what I described, starting with a factory reset and the issue is still there.

[Pinörkel]

Just a little update on this: I found someone with an SDS2204X+ at work who could reliably reproduce the issue on his scope. Consequently, I created an error description, including steps to reproduce the issue and equipped my dealer with this, to contact Siglent about it. Hopefully, they can locate and fix the issue. Until then, I have to fall back to only using the left half of recorded data.

[Geoff-AU]

2 requests:

Logic analyser traces to have (configurable?) more separation.  They're pretty hard to read, bunched up so tightly.

Logic analyser able to work in Roll mode.

[2N3055]

2 requests:

Logic analyser traces to have (configurable?) more separation.  They're pretty hard to read, bunched up so tightly.

Logic analyser able to work in Roll mode.

You can set position and separation.

As for digital in roll mode, not sure if architecture would allow for it.

[Geoff-AU]

You can set position and separation.

Ah RTFM.. I see it's buried in a menu.  The normal positional controls are repurposed to scroll through the channels, it was confusing enough that I didn't want to delve any further because I was already busy trying to use it to solve a problem.

As for digital in roll mode, not sure if architecture would allow for it.

I thought the whole point of having an FPGA was that you could change the architecture 

Figured that might be a justification for not doing it.  But Roll mode is slow enough for things on human timescales, should be able to poll LA fast enough for a usable display.

[2N3055]

I thought the whole point of having an FPGA was that you could change the architecture 

Figured that might be a justification for not doing it.  But Roll mode is slow enough for things on human timescales, should be able to poll LA fast enough for a usable display.

Firstly, that is not something that is common. So reason not to do is that.
It might seem logical to people used to streaming to USB types of logic analysers. But on scopes that is not the case.

Secondly, there is huge amount of people that take software paradigm and think everything is possible. You just change software.
While in real life, even in software there are many limitations like CPU, memory etc too.

And word architecture here applies to the whole system. Not only hardware, not only software. Architecture exist already as a specification document even before first PCB is spun...

Architecture is a sum of schematics, what is in FPGA and what is in software. All together.  You don't simply change how things work on a whim. You can adjust and refine details.