Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[TK]

See where H Pos pointer in unzoomed window is after the start of the packet which is consistent with the UART trigger setting. If the selected UART trigger bit doesn't match the zoom window H Pos trigger position bit then indeed it is a bug. Magnify the zoomed window further for confirmation of the result.

Not really. The data it triggers on is not at the start of the packet. And the data at the trigger point there is indeed the intended data. But the trace and the decoded data do not match. It's just that the final screen update of the decoded data is missing. As soon as I expand the zoom or push e.g. a track button, the decoded data is updated and displayed fine. Another example below.

what is the value of decoding threshold?

[roberthh]

I should say that I consider this a good scope. The core feature, handling analog data, looks flawless. What we are discussing here are the "extra" features and GUI aspects. Not that these should not work, but the most important task for an oscilloscope is visualizing analog data.

[roberthh]

what is the value of decoding threshold?

The test device runs at 3.3V. The decoding threshold is set to ~1.6 V, right in the middle. And that's not the problem, because the data is decoded properly, once the decoded data and the trace align. And the trigger is also always at the right place.

[Cobra514]

I believe a bug is present in at least the SPI decode "result list" (and possibly other serial decode lists?)

Here is how to replicate - it's very simple.

Get some data in the result list (the number of visible lines from 2 to 7 set up does not matter).
Use the down arrow (or drag the scroll handle) at right side of result list to obscure item #1.
Now, it is not possible via the up arrow or the handle to make the 1st item in the list appear again.
items 2-8 can be seen via scrolling, however.

To see item #1 appear again:
Press "Decode" hard button
Press "Result List" on spring up menu
Press/highlight "Scroll" box
Turn universal knob to scroll thru the list (which will show item #1 if you scroll all the way up).

-OR- (and this is strange)
While holding down the up arrow with one finger, press the Zoom hard button.
This also will expose the 1st item.
That is just plain ridiculous of course.

So the most reasonable workaround is to always leave the DECODE LIST soft menu up while decoding so you can scroll up down as needed.  But of course that chews up real precious real estate (~15% of screen - I measured)

I've attached photos of the bug with 3 decode lines set up.
In one picture I'm holding down the up arrow but can't go higher than item #2.
In the other picture I've utilized the DECODE LIST menu to bring the scroll focus to the universal knob.

I'm sure there are those who will say "just use the zoom feature to get your decodes and forget the list".
What's the point of the list, then?
Besides, for the work I need to perform, I only have a handful of commands sent at a time.
It is *much* easier to read a list then to zoom in and scroll around (especially with the weak rotational velocity performance on the zoom horiz. roll).
Also, considering how the decoding performs best with large timescales (timebases), the values are not legible directly (since octagons are too small at large timescales).

Again, my apologies if this has been posted before.

Seems like a very simple fix for Siglent.

[tautech]

See where H Pos pointer in unzoomed window is after the start of the packet which is consistent with the UART trigger setting. If the selected UART trigger bit doesn't match the zoom window H Pos trigger position bit then indeed it is a bug. Magnify the zoomed window further for confirmation of the result.

Not really. The data it triggers on is not at the start of the packet. And the data at the trigger point there is indeed the intended data. But the trace and the decoded data do not match. It's just that the final screen update of the decoded data is missing. As soon as I expand the zoom or push e.g. a track button, the decoded data is updated and displayed fine. Another example below.

STOP it first and then magnify to check the trigger bit setting matches the displayed bit. They should match.
TK found a decode bug in the X-E where the trigger setting did not match the displayed bit.
This might be the same bug IDK yet. 

[Cobra514]

It seems it depends on the CS transition to be in the capture window. If that is given, I can go to smaller time base values, like 50µs/div shown below.

Edit: Using clk-timeout as CS, I can go beyond that limit. See the second screen shot.

Edit2: Nevertheless, it looks as if the oscilloscope is not the preferred instrument for logic protocols. That's more the job for a logic analyzer. Even a 10 USD Saleae clone is easier to use, left alone the size of the probes.

Thank you roberthh for also looking at this.

For what it is worth:
I repeated my test with CS transition low and high both on the screen.
Also tried with CLK Timeout as CS Type.
Set the timebase to 50us/div.

Still got the same decode error.
It the attached picture, the last bytes (line 7 in list) should be "EEFF", not "EE00".

Oh well.  This is just a feature I will not be able to use until firmware is corrected.  It simply can't be trusted.

[LootMaster]

Ya'll find them bugs now.

I got my 2352X-E on the way...

Cmon guys... Find those bugs.

And let Tautech know.... Bugs are bad ! 

[roberthh]

STOP it first and then magnify to check the trigger bit setting matches the displayed bit. They should match.

I agree that you can do something after acquiring like pushing STOP to make the screen consistent. But my expectation was, that the screen IS consistent when a measurement has done. I made a short python script which produces the error. It runs here on a ESP32 with micropython, but that may not be mandatory. The trigger is set to serial trigger on the data value 0x34 (Ascii letter 4), Normal trigger mode. The mismatch does not happen on every combination of timebase and Mem Depth. Some suitable settings:

Timebase  Mem Depth
5 ms/div    20M
2 ms/div    20M
10 ms/div   2M

Here's the script

Code: [Select]

import sys
import time
import random

nmsg = "1234" + "abcdefghijklmnopqrstuvwxyz"*2
nlen = len(nmsg)

def run():
    while True:
        ch = sys.stdin.read(1)
        if ch == "q":
            break

        for i in range(20):
            print(nmsg[:random.randint(0, nlen)])
            time.sleep(0.005)

        for i in range(10):
            print("1234567890")
            time.sleep(0.005)

run()



[roberthh]

I believe a bug is present in at least the SPI decode "result list" (and possibly other serial decode lists?)

I'll repeat that for the SPI. On UART decode I do not see this phenomenon.
About the previous not on decodinge the last byte wrong:
a) At which level did you set the decoding of the MISO line? It should be about Level/2.
b) I see that the MISO and MOSI line start floating after the message. Did you try to pull them up or down to have them fast at a well defined level?

[kev_in_cornwall]

Just to round off the story of my glitch "problem", they seem to be single pixel wide and if i try and zoom in on them they don't exist (or at least they move around to a different position. My conclusion it that they are not ADC or front end sampling errors (so not a fault as such) and are somehow related to a bug in graphical interface (yellow and Magenta?) or the 10 bit interpolator (but that's strange because it only affects Ch1 and 2). If I change from vector to dot mode they are no longer noticable (so not distracting) so I can live with that. I wonder if it is a SW bug and nobody else has experienced it because you all use dot mode (I read in another thread that it is preferred). Below are some pictures with persistance turned on in vector and then dot mode, and you can see it is only on ch1 and ch2 and the magnitude seems to be a function of the voltage on the channel. Interestig but not a real problem I now think.  Maybe its a brand new feature only on the very latest scopes which is why nobody else has seen it (or maybe I'm just too fussy ). Im now SW 1.3.5R10, Uboot OS 5.0, FPGA version 2020-04-26, CPLD version 03, HW version 2.0.
Thanks to everyone for the advice, help.

[roberthh]

@kev_in_cornwall: I think it's a bug specific to your instrument, and I would return it. It is visible bot in vector and dot mode, and it definitely should not be there. A new device must not have such problems. I have inverted your pictures with gimp, such that the wrong spikes are better visible.

[roberthh]

I believe a bug is present in at least the SPI decode "result list" (and possibly other serial decode lists?)
.................
Get some data in the result list (the number of visible lines from 2 to 7 set up does not matter).
Use the down arrow (or drag the scroll handle) at right side of result list to obscure item #1.
Now, it is not possible via the up arrow or the handle to make the 1st item in the list appear again.
items 2-8 can be seen via scrolling, however.
..................

I confirm this bug here. It seems not to be possible to move in the list to item 1 with either the 'up' arrow or the scroll bar. When the first line has been selected with the scroll dial, moving down with the 'down' arrow directly jumps to line 3. Looks like a simple offset 0 or 1 error for the first element when displaying the  list.

Edit: The same problem happens with UART, I2C and CAN decode. So it looks like a generic but marginal issue. If the list contains only two elements, you cannot move with the arrows at all, unless you used the Scroll dial to go to line 1 first.

[roberthh]

After dealing with the device for a few days, I see some possible improvements:

Software:

1. Help Page: Enlarge the (or create a) cancel button. The small X in the
    upper right corner is hard to hit with big fingers, and hard to
    see on the Browser screen.

2. Allow the selection of the items in the menu column on the right side with the
   universal dial. If you open that menu, the universal dial should allow
   to move the selection up/down, and when you push it, that element is selected
   for changing. Changing the trace intensity is already in the display tab.

3. An acceleration behavior of move buttons (e.g. horizontal, long lists, etc.
   when the button is turned. Moving is rather slow.

4. AWG: Bursts, setting and triggering manual and by SCPI command.

5. Speed up UART Decoding, which is very slow for large memory depth settings.

6. Use mouse wheel for universal dial turns

    Allow using the mouse wheel for changing the value when the focus in in a
    field which is changeable with the universal dial. Using a (rf) mouse is very
    convenient

7. Put all elements for a specific setting in one menu.
    For instance window or runt trigger has the level and channel/timing
    entries in two different menus, which have to be opened separately.

8. Option to increase vertical space. The title bar could for instance be
    switchable via the display or utility button or collapse into a small button
    in the left or right upper edge. It could be hidden when enabling Zoom.

    Enabling/disabling the side bar menu could be by pushing the time/date
    area which has no active purpose so far. Whether this information is needed
    is questionable. There are other sources of time/date, and the LAN status
    can be displayed in the LAN config menu.
 
    Edit: Maybe only a "Full Screen" (toggle) button for the trace area. That would
    interfere less with the actual layout.

9. Continuous move in history list. Moving the the history list with the up/down
    arrows or the scroll bar should scroll the  content continuously instead of
    page by page.

10. Configure the timeout of auto trigger mode

Hardware:

1. Reduce the Fan noise. It's nod bad, but could be less.

2. AWG: It's not understandable why the rise/fall time of the arbitrary signals
   is ~7 ns min, while the square signal's rise/fall time is at 24 ns. Add a
   square wave arb template (and fix waveform import).

3. Where is WiFi?
   Almost every piece of Electronics from 1USD devices on has WiFi? That's not
   luxury, it's base level standard.

[Cobra514]

I believe a bug is present in at least the SPI decode "result list" (and possibly other serial decode lists?)

I'll repeat that for the SPI. On UART decode I do not see this phenomenon.
About the previous not on decodinge the last byte wrong:
a) At which level did you set the decoding of the MISO line? It should be about Level/2.
b) I see that the MISO and MOSI line start floating after the message. Did you try to pull them up or down to have them fast at a well defined level?

Good questions.
a) MISO is disabled under Decode -> Protocol Signals -> MISO
   This is valid use for write-only devices such as displays.
b) I tried pullups on both CS and MOSI and verified the signals were held high when not actively driven.
   Still had same errors.

Actually, since CS has a monotonic falling/start and rising/end the 'scope should have no issue detecting the valid decode window.
My Total Phase SPI generator is simply getting off the bus when not actively driving data as I would expect.

The thresholds for CS, MOSI, and CLK are all set to 50%.

[DL2XY]

Please check the signal integrity of your generator. Bit counter starts with first active SCLK edge after chip select or timeout interval if set. Active edges of SCLK must fall on stable level of MOSI/MISO (Cursors). At very high bitrates the scope need at least 2 ADC-Sample clocks between edges of SCLK and MOSI/MISO (Nyquist).

Start of 32bit write cycle



If have done exessive tests on SDS2504X+ with no problems at all:

-Analog Inputs 8bit
-Analog Inputs 10 bit
-Digital Inputs
-Decoding on short memory
-Decoding with long memory (more than 3000 decodes in list)
-Decoding on zoomed area
-Triggering on decoded data

I have done a couple of screenshot, if someone is interested i may post them here.

 

[Cobra514]

Please check the signal integrity of your generator. Bit counter starts with first active SCLK edge after chip select or timeout interval if set. Active edges of SCLK must fall on stable level of MOSI/MISO (Cursors). At very high bitrates the scope need at least 2 ADC-Sample clocks between edges of SCLK and MOSI/MISO (Nyquist).

Start of 32bit write cycle
(Attachment Link)


If have done exessive tests on SDS2504X+ with no problems at all:

-Analog Inputs 8bit
-Analog Inputs 10 bit
-Digital Inputs
-Decoding on short memory
-Decoding with long memory (more than 3000 decodes in list)
-Decoding on zoomed area
-Triggering on decoded data

I have done a couple of screenshot, if someone is interested i may post them here.

That's great news!
Do you recall what timebase the decodes were performed at?

[DL2XY]

Please check the signal integrity of your generator. Bit counter starts with first active SCLK edge after chip select or timeout interval if set. Active edges of SCLK must fall on stable level of MOSI/MISO (Cursors). At very high bitrates the scope need at least 2 ADC-Sample clocks between edges of SCLK and MOSI/MISO (Nyquist).

Start of 32bit write cycle
(Attachment Link)


If have done exessive tests on SDS2504X+ with no problems at all:

-Analog Inputs 8bit
-Analog Inputs 10 bit
-Digital Inputs
-Decoding on short memory
-Decoding with long memory (more than 3000 decodes in list)
-Decoding on zoomed area
-Triggering on decoded data

I have done a couple of screenshot, if someone is interested i may post them here.

That's great news!
Do you recall what timebase the decodes were performed at?

Between 10us/div for a single 32bit register over 200us/div for a complete scan over 3 chips with 6 registers up to 500ms/div for long memory tests.

[Cobra514]

Please check the signal integrity of your generator. Bit counter starts with first active SCLK edge after chip select or timeout interval if set. Active edges of SCLK must fall on stable level of MOSI/MISO (Cursors). At very high bitrates the scope need at least 2 ADC-Sample clocks between edges of SCLK and MOSI/MISO (Nyquist).

Start of 32bit write cycle
(Attachment Link)


If have done exessive tests on SDS2504X+ with no problems at all:

-Analog Inputs 8bit
-Analog Inputs 10 bit
-Digital Inputs
-Decoding on short memory
-Decoding with long memory (more than 3000 decodes in list)
-Decoding on zoomed area
-Triggering on decoded data

I have done a couple of screenshot, if someone is interested i may post them here.

Here are two captures.  500kHz bitrate.
See the last byte in decode list.

One picture shows the correct byte decode, the other is an incorrect byte decode (that's 8 sequential incorrect 'bit' decodes actually).
Only difference is 50us vs 100us timebase (I changed timebase after decode to see signals better, but decode list didn't change).

Threshold and edge select are shown on the screen. *EDIT* MOSI also set to 2V threshold.
MOSI is perfectly stable at the threshold chose during rising edge of CLK.  CLK edge is perfect.

[roberthh]

@Cobra514: Could it be the same problem that I have seen in the UARt decode. Which was, that the decode pattern and the signal trace did not match. Try Single trigger, or push Stop after the device has triggered. Or push the screen to hide the side menu, or push a channel button. Anything that forces a screen  redraw.

[Cobra514]

@Cobra514: Could it be the same problem that I have seen in the UARt decode. Which was, that the decode pattern and the signal trace did not match. Try Single trigger, or push Stop after the device has triggered. Or push the screen to hide the side menu, or push a channel button. Anything that forces a screen  redraw.

Yes I was thinking the same.  I have tried run-normal-stop and single trigger....and bringing up side menu and removing.

It's funny.  I am looking at single byte messages failing now.
Only odd values, however (since it seems to miss last bit).

So 00,22,44,66, etc work fine....while 11,33,55,77, etc all fail (again, only at timebases <100us/div).
11 will decode as 10; 33 will decode as 32; 55 will decode as 54, etc...

[roberthh]

Yes I was thinking the same.  I have tried run-normal-stop and single trigger....and bringing up side menu and removing.

It's funny.  I am looking at single byte messages failing now.
Only odd values, however (since it seems to miss last bit).

So 00,22,44,66, etc work fine....while 11,33,55,77, etc all fail (again, only at timebases <100us/div).
11 will decode as 10; 33 will decode as 32; 55 will decode as 54, etc...

I had that effect of wrong or no decoding at small timebase settings when the high/low transition of CS was not in the captured trace. In my test object, the CS transition was far off the signal. I changed the CS setting in the scope from the signal level to clock timeout. That allowed proper decoding.

[DL2XY]

Please check the signal integrity of your generator. Bit counter starts with first active SCLK edge after chip select or timeout interval if set. Active edges of SCLK must fall on stable level of MOSI/MISO (Cursors). At very high bitrates the scope need at least 2 ADC-Sample clocks between edges of SCLK and MOSI/MISO (Nyquist).

Start of 32bit write cycle
(Attachment Link)


If have done exessive tests on SDS2504X+ with no problems at all:

-Analog Inputs 8bit
-Analog Inputs 10 bit
-Digital Inputs
-Decoding on short memory
-Decoding with long memory (more than 3000 decodes in list)
-Decoding on zoomed area
-Triggering on decoded data

I have done a couple of screenshot, if someone is interested i may post them here.

Here are two captures.  500kHz bitrate.
See the last byte in decode list.

One picture shows the correct byte decode, the other is an incorrect byte decode (that's 8 sequential incorrect 'bit' decodes actually).
Only difference is 50us vs 100us timebase (I changed timebase after decode to see signals better, but decode list didn't change).

Threshold and edge select are shown on the screen. *EDIT* MOSI also set to 2V threshold.
MOSI is perfectly stable at the threshold chose during rising edge of CLK.  CLK edge is perfect.

Please repeat this test with aqquire/peak-detect and display/color-grading on. That would reveal every ns-glitch which eventually confuses decoding.

[roberthh]

@Cobra514: Looking at the pictures of your first series, the ones that decode right have the CS low/high slope in the captured trace, the one that fail do not have it. What is the CS type setting in the Protocol Signals tab? For a low level CS it has to be ~CS (or CLK Timeout, if the CS transition is too far off or if there is no CS). Due to the CLK synchronous nature w/o timeout the decoder cannot tell from CLK and Data alone where a data item starts. So it needs some other indication.
If the CS setting changes the decoding, still the question arises about the difference between odd/even numbers.

[tautech]

I have a new SDS2104X Plus out now after installing option promotion codes from the factory and ready for Decode tests to examine the reported faults.
One thing I see in all screenshots except those from DL2XY are trigger errors; trigger position within the packet and edge selection errors. Simple mistakes they are as are trigger positions off the display when there are tools in this scope to keep the trigger on the display regardless of the timebase setting.
Big day and tired now but some examples of Decode later................

[roberthh]

I have a new SDS2104X Plus out now after installing option promotion codes from the factory and ready for Decode tests to examine the reported faults.
One thing I see in all screenshots except those from DL2XY are trigger errors; trigger position within the packet and edge selection errors. Simple mistakes they are as are trigger positions off the display when there are tools in this scope to keep the trigger on the display regardless of the timebase setting.
Big day and tired now but some examples of Decode later................

If you trigger on data then the trigger position is in the packet at the end of the respective data element. That's fine. If you capture a sample and then zoom into it, the trigger position may move out of the visible window. Still the visible parts of all traces (including the decoded data) must show the same part of the data.
Edit: Even when the trigger point is outside the captured data, decoding can be done for protocols which can resync, like UART, I2C. Even SPI, if the data resync specifier is a CS transition within the captured data. In my tests that also worked fine with UARTm CAN.