Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[roberthh]

SDS2104x-plus, 1.3.5R10

BUG: Inconsistency between displayed and used settings.

Trying to do a simple test with UART decode I trapped over a pitfall, which I would consider a BUG. Setting the protocol signals, the menu showed fine C1, threshold 1.57V. But it decoded wrong. It turned out, that the threshold was wrong. Even if the menu said 1.57V, the value used for decode was 0. It only came right after I had reset it again to 1.57V. This is a problem which occurs at many places, that the settings shown in the menu do not reflect the actual settings used for the measurement.

I did not test yet how easy of difficult it is to repeat  the error may not be easy to repeat. One may have to change between protocols or go through a power cycle.

P.S.: At first I thought it was a problem in decoding a custom baud rate, but it was not.

@cobra514: when setting the protocol signals, try to set the threshold level again by varying it a little bit.

Edit: It might be that the issue I have seen with 8/10 bit setting and I2C decode is also related to this topic. Using the same test set-up again and deliberately adjusting the threshold for SCL and SDA again, there is not difference between 8 and 10 bit mode. I can however set the threshold for SDA to an value, where 8 bit decodes fine, but 10 bit not. This level was around 2.5 V in my set-up.

[tv84]

Even if the menu said 1.57V, the value used for decode was 0.

If real, this type of bug is a real PITA. One looses confidence... 

[DL2XY]

These are the screenshots of my tests.

DUT is a UHF data receiver unit. It has 3 PLL IC`s (MAX2871) connectet to MCU via SPI. Each PLL has 6 write only register (32bit).
The signal is the initialization sequence requiered: R5 to R0 PLL1 (CS1),R5 to R0 PLL2 (CS2) and R5 to R0 PLL3 (CS3). For testing i repeatet this sequence at 10ms intervall.
The least 3 bits of  32bit  words are defining the register address.


One scan, digital input, triggered on data (CS2,R3)


Long memory test, digital input, only CS2 decoded, triggered on data (R3),


Zoomed to R3, digital input


Analog input, triggered on CLK timeout,  3 PLL's* 6 registers


Zoomed to R3


18 full scans


Analog inputs with CS, trigger on data (R3 CS2), one full scan.



 

[Cobra514]

@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.

Hi roberthh.  Yes, good question.  The reason the CS low/high transition is not visible in some of the pictures is simply due to timebase difference.  But it is present in all of the tests.  After I send a command with my SPI generator, it raises the CS line to prepare it to do a high/low transition.

My generator is set up for ~CS (active low) and per the Siglent User Manual: "The ~CS signal needs a complete falling edge on the screen to be regarded as active."

So therefore I was careful to ensure that the complete falling (and subsequent rising) edge of ~CS is on the screen during the decode.

There should be no problem here.

[Cobra514]

@DL2XY - Thank you for taking some time to post. 

Probably the closest conditions shown there to one of the conditions I have tried would be xxxxpng_5, where the analog channels are used AND the timebase is under 50uS/div AND performing 32-bit decodes.

I actually would not see an issue with decodes as well with the condition you have posted there.

In my situation, I only see a failure on the decode of the last nibble sent and decoded.  I see in  your plot that there is subsequent SPI data.

In other words, if I send (n) 32-bit messages, (n-1) of them will be correct and the (nth) will be decoded incorrectly (for timebase <100us only as well).

Not sure what it means, but for 8-bit decodes I usually miss the last bit of the LSB.  For 32-bit decodes I sometimes miss the entire last nibble and decode "0" regardless of value. 

[TK]

Siglent scopes are bad at keeping serial trigger and decode information after reboot, so every time you reboot, you need to check the serial trigger and decoding settings like channels assigned to signals and the thresholds

[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.

Did you make tests with clk-timeout as CS setting?
Hi roberthh.  Yes, good question.  The reason the CS low/high transition is not visible in some of the pictures is simply due to timebase difference.  But it is present in all of the tests.  After I send a command with my SPI generator, it raises the CS line to prepare it to do a high/low transition.

My generator is set up for ~CS (active low) and per the Siglent User Manual: "The ~CS signal needs a complete falling edge on the screen to be regarded as active."

So therefore I was careful to ensure that the complete falling (and subsequent rising) edge of ~CS is on the screen during the decode.

There should be no problem here.

[Cobra514]

@cobra514: when setting the protocol signals, try to set the threshold level again by varying it a little bit.

Yes, thank you - I did try that.  I actually highlighted the threshold "box" and used the universal knob to vary threshold all the way from GND up to the top of the signal.  My findings were consistent except when at the vary top or bottom of the signal.

[roberthh]

Siglent scopes are bad at keeping serial trigger and decode information after reboot, so every time you reboot, you need to check the serial trigger and decoding settings like channels assigned to signals and the thresholds

That is not a problem as long as it is visible. The issue I have seen was that the menu for (here I2C signals) showed different values than the actual setting, until I changed deliberately each and every entry in that menu again, irrespective of what was already shown.

[Cobra514]

@roberthh

My apologies, you mentioned this before.  Yes, I did try the clk timeout as well.

I attached 2 pictures of subsequent transmissions (seconds apart) using clk timeout.  Both performed with the same data sent.  One OK, One failed decode (last bit).
Both performed at the same timebase as well in this case. 

Each time I click send on my generator I get randomly AC or AD (AD is correct).
I tried the "history" feature as well in this one.

...and if you look closely, the rising edge of ~CS is visible at the left hand side of screen in both screens (since this was a minor difference noted before).

The two patterns are identical save for some mV level noise.  The decodes are different.

*EDIT* As expected, for timebase >100us/div the decode worked perfectly for me every time

[roberthh]

@Cobra514 Hi. I used a micro to simulate a SPI with similar wave than yours. Clock and data transition at exactly the same time.  The result: The last bits are decoded wrong. Instead a 0x33 it shows 0x30, instead of 0x37 it shows 0x30 too. Since a sequence of 1 bits is decoded as 0, that explains why 0xff gets 0x00. My simple USB based logic analyzer works well.

BUT: That was all with a pattern, where the quiet levels of Clk and Data is high. If I change it to Clk & data low when inactive, all decodes well.

Edit: It is the miso line which makes the difference.
Edit 2: It is sufficient that the miso line is low for a short while only. It worked with a 40 ns low state. I could not test further with the little micro I used for pattern generation.

In any case, the active phase of clock was the falling one. And I do not see a setting to cater for a low of high quiet state of the bus. Attached:
spi_high_033.png:  Wrong decoding
spi_low_033.png: Proper decoding
LA2016_0033.png: Decoding with the USB LA
spi_datalow_0013.png. Proper decoding with data returning to 0
spi_data_pulse_0017.png: Proper decoding with a 50 ns low miso pulse at the end

[Cobra514]

@roberthh,

That is very good work, indeed.  Impressive.

For once I am not the only one seeing this

Seems it should be capable of decoding either way.

When I free up again, I might have to try all the options for CPOL, CPHA, and SS (active high and low).

[DL2XY]

Maybe the problem results from incorrect decoder settings. You are decoding 8-bit wise but the bitstream is one 32-bit block!
The transfer ends with the rising transition of CS, so if you put out 32 bits while CS is active you should decode it as a 32 bit word.

[TK]

@Cobra514 Hi. I used a micro to simulate a SPI with similar wave than yours. Clock and data transition at exactly the same time.  The result: The last bits are decoded wrong. Instead a 0x33 it shows 0x30, instead of 0x37 it shows 0x30 too. Since a sequence of 1 bits is decoded as 0, that explains why 0xff gets 0x00. My simple USB based logic analyzer works well.

BUT: That was all with a pattern, where the quiet levels of Clk and Data is high. If I change it to Clk & data low when inactive, all decodes well.

Edit: It is the miso line which makes the difference.
Edit 2: It is sufficient that the miso line is low for a short while only. It worked with a 40 ns low state. I could not test further with the little micro I used for pattern generation.

In any case, the active phase of clock was the falling one. And I do not see a setting to cater for a low of high quiet state of the bus. Attached:
spi_high_033.png:  Wrong decoding
spi_low_033.png: Proper decoding
LA2016_0033.png: Decoding with the USB LA
spi_datalow_0013.png. Proper decoding with data returning to 0
spi_data_pulse_0017.png: Proper decoding with a 50 ns low miso pulse at the end

How did you simulate the SPI signals?  Bit banging?  The signals do not seem to be the same on the different capture examples

[Cobra514]

Maybe the problem results from incorrect decoder settings. You are decoding 8-bit wise but the bitstream is one 32-bit block!
The transfer ends with the rising transition of CS, so if you put out 32 bits while CS is active you should decode it as a 32 bit word.

No.  That's not the problem. 

See failed decode attached.  Note on upper right of screen that "Data Length" = 8 is selected.

Doesn't get much simpler than this...

A single byte (0x11) sent and (0x10) decoded. 
MOSI does end in a high state, however.

[tautech]

See failed decode attached.  Note on upper right of screen that "Data Length" = 8 is selected.

Doesn't get much simpler than this...

A single byte (0x11) sent and (0x10) decoded. 
MOSI does end in a high state, however.

Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high 

[TK]

See failed decode attached.  Note on upper right of screen that "Data Length" = 8 is selected.

Doesn't get much simpler than this...

A single byte (0x11) sent and (0x10) decoded. 
MOSI does end in a high state, however.

Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high 

it is not both rising and falling edges, it has to do with clock polarity and phase and SPI has 4 modes based on the combination of these 2 parameters

[TK]

Maybe the problem results from incorrect decoder settings. You are decoding 8-bit wise but the bitstream is one 32-bit block!
The transfer ends with the rising transition of CS, so if you put out 32 bits while CS is active you should decode it as a 32 bit word.

No.  That's not the problem. 

See failed decode attached.  Note on upper right of screen that "Data Length" = 8 is selected.

Doesn't get much simpler than this...

A single byte (0x11) sent and (0x10) decoded. 
MOSI does end in a high state, however.

What is the SPI decoding setting on the scope, including threshold levels for all signals?

[tautech]

See failed decode attached.  Note on upper right of screen that "Data Length" = 8 is selected.

Doesn't get much simpler than this...

A single byte (0x11) sent and (0x10) decoded. 
MOSI does end in a high state, however.

Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high 

it is not both rising and falling edges, it has to do with clock polarity and phase and SPI has 4 modes based on the combination of these 2 parameters (Attachment Link)

Right, thank you for that however if we study the screenshots edge alignment of all 3 traces they don't make sense. 
CS has no relation to the real CLK other than it's active for way in excess of the packet and the start of CLK is after the start of MOSI.
Certainly conditions that are most unusual.

Garbage in = garbage out.

[TK]

See failed decode attached.  Note on upper right of screen that "Data Length" = 8 is selected.

Doesn't get much simpler than this...

A single byte (0x11) sent and (0x10) decoded. 
MOSI does end in a high state, however.

Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high 

it is not both rising and falling edges, it has to do with clock polarity and phase and SPI has 4 modes based on the combination of these 2 parameters (Attachment Link)

Right, thank you for that however if we study the screenshots edge alignment of all 3 traces they don't make sense. 
CS has no relation to the real CLK other than it's active for way in excess of the packet and the start of CLK is after the start of MOSI.
Certainly conditions that are most unusual.

CS has no relation to when the CLK / MOSI / MISO signals start toggling.  You set CS and you can wait as long as you want to start transmitting.
When the sampling occurs with CLK going low to high, the MOSI line needs to toggle before the first clock toggle, so it is correct that MOSI moves first

[TK]

See failed decode attached.  Note on upper right of screen that "Data Length" = 8 is selected.

Doesn't get much simpler than this...

A single byte (0x11) sent and (0x10) decoded. 
MOSI does end in a high state, however.

Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high 

What are the blue arrows on the top?  It looks like decoding is ending sampling on the second blue arrow, and it is the 7th clock, missing the last clock toggle where bit is 1, but as decode stopped, it shows 0.  You can also see that the white rectangle indicating decoded packet ends on the 7th clock

EDIT: I don't think the blue arrows are limiting the decoding, but it is clearly sampling on clock edge low to high, and the last bit is 0 when the 8th clock starts to transition low to high

[Cobra514]

See failed decode attached.  Note on upper right of screen that "Data Length" = 8 is selected.

Doesn't get much simpler than this...

A single byte (0x11) sent and (0x10) decoded. 
MOSI does end in a high state, however.

Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high 

What are the blue arrows on the top?  It looks like decoding is ending sampling on the second blue arrow, and it is the 7th clock, missing the last clock toggle where bit is 1, but as decode stopped, it shows 0.  You can also see that the white rectangle indicating decoded packet ends on the 7th clock

EDIT: I don't think the blue arrows are limiting the decoding, but it is clearly sampling on clock edge low to high, and the last bit is 0 when the 8th clock starts to transition low to high

The dark blue arrow is merely indicating the trigger.  In that shot I had it detect a SPI pattern (so it needs to see some activity before it triggers.
I have similar plots for the exact same data (and error) where the trigger is at the falling edge of CLK (because I set the trigger for falling edge of CLK).
Last bit is not 0.  This is set for MSB.  Look again.

By the way.  If I set the timebase to 100us/div or higher, it decodes correctly.

[TK]

See failed decode attached.  Note on upper right of screen that "Data Length" = 8 is selected.

Doesn't get much simpler than this...

A single byte (0x11) sent and (0x10) decoded. 
MOSI does end in a high state, however.

Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high 

What are the blue arrows on the top?  It looks like decoding is ending sampling on the second blue arrow, and it is the 7th clock, missing the last clock toggle where bit is 1, but as decode stopped, it shows 0.  You can also see that the white rectangle indicating decoded packet ends on the 7th clock

EDIT: I don't think the blue arrows are limiting the decoding, but it is clearly sampling on clock edge low to high, and the last bit is 0 when the 8th clock starts to transition low to high

The dark blue arrow is merely indicating the trigger.  In that shot I had it detect a SPI pattern (so it needs to see some activity before it triggers.
I have similar plots for the exact same data (and error) where the trigger is at the falling edge of CLK (because I set the trigger for falling edge of CLK).
Last bit is not 0.  This is set for MSB.  Look again.

By the way.  If I set the timebase to 100us/div or higher, it decodes correctly.

I can see what you mean.  I don't like how Siglent serial decoding works, but this bug is the most bizarre one I saw in any scope.  BTW, how are you generating the SPI signals?  Is there a pull-up on the MOSI line?

[Cobra514]

See failed decode attached.  Note on upper right of screen that "Data Length" = 8 is selected.

Doesn't get much simpler than this...

A single byte (0x11) sent and (0x10) decoded. 
MOSI does end in a high state, however.

Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high 

What are the blue arrows on the top?  It looks like decoding is ending sampling on the second blue arrow, and it is the 7th clock, missing the last clock toggle where bit is 1, but as decode stopped, it shows 0.  You can also see that the white rectangle indicating decoded packet ends on the 7th clock

EDIT: I don't think the blue arrows are limiting the decoding, but it is clearly sampling on clock edge low to high, and the last bit is 0 when the 8th clock starts to transition low to high

The dark blue arrow is merely indicating the trigger.  In that shot I had it detect a SPI pattern (so it needs to see some activity before it triggers.
I have similar plots for the exact same data (and error) where the trigger is at the falling edge of CLK (because I set the trigger for falling edge of CLK).
Last bit is not 0.  This is set for MSB.  Look again.

By the way.  If I set the timebase to 100us/div or higher, it decodes correctly.

I can see what you mean.  I don't like how Siglent serial decoding works, but this bug is the most bizarre one I saw in any scope.  BTW, how are you generating the SPI signals?  Is there a pull-up on the MOSI line?

Covered in previous posts. I know - there are many.

[Cobra514]

I'm simply going to move on from this decode topic. 
I have spent too much time on this and have other more important tasks to work on.
Thanks to everybody who looked into it.
Hopefully just something I'm doing on my end here...
...and I can always just use the timebase workaround (although there are times I'd rather not).