Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[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

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

Yes, by bit banging. The micro has a SPI engine, but I used bit banging to have full control over all signals. So I can shift the CS slopes in relation to the data, levels of data and clock lines, etc...

[Frank_MV]

If I have read the Siglent SDS2000x Plus manual correctly, the internal Waveform Generator has no sweep function.
Can someone please confirm this.
Thanks.

[roberthh]

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, it's not. I can always decode a message as 8 bit quantities. And this issue is the same for messages of 1, 3, or 5  bytes length. It is related to the miso or mosi level after the end of the transfer. The SPI papers do not require a specific level of the data lines outside the message window. So it should decode properly with any level.

And, b.t.w., simple USB logic analyzers with public domain software can handle that signal pattern properly. So I would consider that as a topic for improvement by Siglent, politely spoken.

[roberthh]

If I have read the Siglent SDS2000x Plus manual correctly, the internal Waveform Generator has no sweep function.
Can someone please confirm this.
Thanks.

The user interface to the internal waveform generator is pretty simple. No sweep, no modulation, just simple settings. You can however control it through SCPI commands, changing frequency or amplitude in steps.  Similar is obviously done doing the Bode plots. The speed of setting changes is however limited by the time it takes to send a command. So you cannot do something like AM or FM modulation.

[Frank_MV]

If I have read the Siglent SDS2000x Plus manual correctly, the internal Waveform Generator has no sweep function.
Can someone please confirm this.
Thanks.

The user interface to the internal waveform generator is pretty simple. No sweep, no modulation, just simple settings. You can however control it through SCPI commands, changing frequency or amplitude in steps.  Similar is obviously done doing the Bode plots. The speed of setting changes is however limited by the time it takes to send a command. So you cannot do something like AM or FM modulation.

Ok, thanks

[roberthh]

@Cobra514 and others: I should add that this habit of decoding the last byte wrong if the value is odd does extend to the previous bytes. In fact it fails at a trailing sequence of 1 bits of any length, up to the full message.

[DL2XY]

My last post on topic SPI decode bug: There is no bug.

At least if signals are SPI conform and setup is correct.
There are four possible mode on SPI, defined by combinations of clock polarity (CPOL) and clock phase (CPHA).
Siglent only supports the setting of polarity, there is no setting for phase.
The user has to choose clock polarity on both CPOL and CPHA of the signal:

CPOL   CPHA   EDGE
--------------------
0         0        Rise
0         1        Fall
1         0        Fall
1         1        Rise

If you choose the wrong setting you are sampling data bits at its transitions. Unfortunal this may work, for example if the probes are slightly different compensated, but this would be higly instable.

Here are proofs of all 4 possible modes:

CPOL=0, CPHA=0 , Clock rising


CPOL=1, CPHA=0 , Clock falling


CPOL=0, CPHA=1 , Clock falling


CPOL=1, CPHA=1 , Clock rising
   

If you are not sure wich mode your signal is, you may look at clock idle level for CPOL and wich clock transition hits data in settled state.

Hope that helps
   

PS: can someone tell me how to get the pics in the right place ?! 

[tautech]

My last post on topic SPI decode bug: There is no bug.

Thanks for your efforts. 

PS: can someone tell me how to get the pics in the right place ?!

Yes the within text image insertion no longer works and instead you need insert the thumbnail image URL into where you want them and its URL address between image flags.
I post first then edit replacing placeholders (1,2,3,4...a,b,c, etc) with the image URL within the image flags ([ img]image url[ /img])
Edit works better for this than Modify as in Edit you still have access to image URL's. 

[roberthh]

My last post on topic SPI decode bug: There is no bug.

At least if signals are SPI conform and setup is correct.
There are four possible mode on SPI, defined by combinations of clock polarity (CPOL) and clock phase (CPHA).
Siglent only supports the setting of polarity, there is no setting for phase.
The user has to choose clock polarity on both CPOL and CPHA of the signal:

CPOL   CPHA   EDGE
--------------------
0         0        Rise
0         1        Fall
1         0        Fall
1         1        Rise

If you choose the wrong setting you are sampling data bits at its transitions. Unfortunal this may work, for example if the probes are slightly different compensated, but this would be higly instable.

Here are proofs of all 4 possible modes:

CPOL=0, CPHA=0 , Clock rising
(Attachment Link)

CPOL=1, CPHA=0 , Clock falling
(Attachment Link)

CPOL=0, CPHA=1 , Clock falling
(Attachment Link)

CPOL=1, CPHA=1 , Clock rising
(Attachment Link)    

If you are not sure wich mode your signal is, you may look at clock idle level for CPOL and wich clock transition hits data in settled state.

Hope that helps
   

PS: can someone tell me how to get the pics in the right place ?! 

I'm sorry, but I disagree. In the examples of  @cobra514 and mine the sampling was in the stable clock  phase of the data. We took care of that aspect. The difference between working an failing is the level of the data line miso or mosi at the end of the transmission. If the data line is low, all works fine. If the data line is high after the end of transmission, there is the problem with the trailing run of 1 bits. Upfront from the last 0 bit in the data bit sequence, everything is decoded well. For a proper decoding, the high/low transition of the data line has to be in the capture window. It may be later that the SS deassertion.

In your examples the data line is low after the transmission. Therefore you do not see the error. The SPI standard has no requirements for the data line level outside the transmission. For MOSI, it is undefined (xxxx), for MISO the slave must set the line to high-Z. So it may have any level. And in the pictures of @Cobra514 you see it floating. So please repeat your test with a high level data line set-up.

Other SPI decoders do NOT have this issue. It is just the one in the scope.

Obviously, if you choose a wrong polarity/phase setting, you may get other errors. But we are not talking about these. And the Siglent decoder does not care about the four clock/polarity options. It simply asks for the Rising/falling edge. Which is the important difference.

Edit: I attached two screen shots. The data is  four bytes 00 00 00 ff. Pretty simple. Clock phase/polarity problem do not apply with that data.
The difference it the level of the data line at the end of the data.

[tautech]

Obviously, if you choose a wrong polarity/phase setting, you may get other errors. But we are not talking about these. And the Siglent decoder does not care about the four clock/polarity options. It simply asks for the Rising/falling edge. Which is the important difference.

Edit: I attached two screen shots. The data is  four bytes 00 00 00 ff. Pretty simple. Clock phase/polarity problem do not apply with that data.
The difference it the level of the data line at the end of the data.

Yet without setting a protocol trigger your trigger settings can corrupt results.....as can Holdoff if it's not long enough to prevent retriggering until after a packet.
Look here, a Normal trigger on ch2 rising.

Reassign it to something more meaningful at the start of the packet and see if the result is better.

[thinkfat]

There's no reason why the trigger settings should influence the decoder, though. The scope captured all relevant data, it should be able to decode without error in this case.

[TK]

My last post on topic SPI decode bug: There is no bug.

At least if signals are SPI conform and setup is correct.
There are four possible mode on SPI, defined by combinations of clock polarity (CPOL) and clock phase (CPHA).
Siglent only supports the setting of polarity, there is no setting for phase.
The user has to choose clock polarity on both CPOL and CPHA of the signal:

CPOL   CPHA   EDGE
--------------------
0         0        Rise
0         1        Fall
1         0        Fall
1         1        Rise

If you choose the wrong setting you are sampling data bits at its transitions. Unfortunal this may work, for example if the probes are slightly different compensated, but this would be higly instable.

Here are proofs of all 4 possible modes:

CPOL=0, CPHA=0 , Clock rising
(Attachment Link)

CPOL=1, CPHA=0 , Clock falling
(Attachment Link)

CPOL=0, CPHA=1 , Clock falling
(Attachment Link)

CPOL=1, CPHA=1 , Clock rising
(Attachment Link)    

If you are not sure wich mode your signal is, you may look at clock idle level for CPOL and wich clock transition hits data in settled state.

Hope that helps
   

PS: can someone tell me how to get the pics in the right place ?! 

I'm sorry, but I disagree. In the examples of  @cobra514 and mine the sampling was in the stable clock  phase of the data. We took care of that aspect. The difference between working an failing is the level of the data line miso or mosi at the end of the transmission. If the data line is low, all works fine. If the data line is high after the end of transmission, there is the problem with the trailing run of 1 bits. Upfront from the last 0 bit in the data bit sequence, everything is decoded well. For a proper decoding, the high/low transition of the data line has to be in the capture window. It may be later that the SS deassertion.

In your examples the data line is low after the transmission. Therefore you do not see the error. The SPI standard has no requirements for the data line level outside the transmission. For MOSI, it is undefined (xxxx), for MISO the slave must set the line to high-Z. So it may have any level. And in the pictures of @Cobra514 you see it floating. So please repeat your test with a high level data line set-up.

Other SPI decoders do NOT have this issue. It is just the one in the scope.

Obviously, if you choose a wrong polarity/phase setting, you may get other errors. But we are not talking about these. And the Siglent decoder does not care about the four clock/polarity options. It simply asks for the Rising/falling edge. Which is the important difference.

Edit: I attached two screen shots. The data is  four bytes 00 00 00 ff. Pretty simple. Clock phase/polarity problem do not apply with that data.
The difference it the level of the data line at the end of the data.

first byte only has 7 clock transitions

[roberthh]

@tautech: No, Sir. I started the patterns manually, one by one. So there is no re-trigger or display of the wrong data (as it was in the UART case). It is just that single data frame that came along.  And whatever the trigger is, the data must be decoded right. The difference is the level of that data line after the transmission. It can get be permanent low, or just for a short pulse. 50 ns is enough. It is not the setting of the instrument that makes the difference, it is the structure of the data.

Just because you think another trigger would make the difference, two more screen shots. The data sent is  0x55 0x00 0xff 0xff in both cases. Trigger is on the 0x55. And for the data high one the device is in stop mode. The decoded data shows 00 00 at the end instead of ff ff. The data pattern is easy enough so you can decode it manually. Whatever the clock/phase setting is, these trailing 16 bits should not all decode as 0.

[thinkfat]

first byte only has 7 clock transitions

No, data is just sampled on falling edge in that case, not rising.

[roberthh]

first byte only has 7 clock transitions

a) I'm counting 8 falling clock transitions. It is bit-bang programmed, so all bytes are the same.
b) And we are talking about the last bits, which are decoded wrong.
c) setting the data line to 0 at the end causes proper decoding. No change in the clock.
d) using other SPI implementations give the same result. trailing data level high -> wrong decoding

[TK]

@tautech: No, Sir. I started the patterns manually, one by one. So there is no re-trigger or display of the wrong data (as it was in the UART case). It is just that single data frame that came along.  And whatever the trigger is, the data must be decoded right. The difference is the level of that data line after the transmission. It can get be permanent low, or just for a short pulse. 50 ns is enough. It is not the setting of the instrument that makes the difference, it is the structure of the data.

Just because you think another trigger would make the difference, two more screen shots. The data sent is  0x55 0x00 0xff 0xff in both cases. Trigger is on the 0x55. And for the data high one the device is in stop mode. The decoded data shows 00 00 at the end instead of ff ff. The data pattern is easy enough so you can decode it manually. Whatever the clock/phase setting is, these trailing 16 bits should not all decode as 0.

in the first case with data ending high, if it decodes correctly when you change the timebase to 100us, then it is a bug

[Martin72]

Nevertheless, I´ve reported this in the general Siglent support thread.
When it´s not a bug, they should explain on how to do it right or correct it.

Martin

[TK]

Here I have an SPI capture with Keysight 1000X scope.  I generated the SPI signal with STM32 microcontroller.  It goes from 0x75 to 0x76 to 0x77 and leaves the MOSI signal in the last state, high or low.  It decodes correctly the values in all the cases... so it is almost sure the behavior on the Siglent is a BUG

[roberthh]

@tautech: No, Sir. I started the patterns manually, one by one. So there is no re-trigger or display of the wrong data (as it was in the UART case). It is just that single data frame that came along.  And whatever the trigger is, the data must be decoded right. The difference is the level of that data line after the transmission. It can get be permanent low, or just for a short pulse. 50 ns is enough. It is not the setting of the instrument that makes the difference, it is the structure of the data.

Just because you think another trigger would make the difference, two more screen shots. The data sent is  0x55 0x00 0xff 0xff in both cases. Trigger is on the 0x55. And for the data high one the device is in stop mode. The decoded data shows 00 00 at the end instead of ff ff. The data pattern is easy enough so you can decode it manually. Whatever the clock/phase setting is, these trailing 16 bits should not all decode as 0.

in the first case with data ending high, if it decodes correctly when you change the timebase to 100us, then it is a bug

I decodes wrong with any timebase setting, that captures the full event.

[roberthh]

SDS2104x-plus, Firmware 1.3.5R10

Topic: Controlling the AWG with SCPI command

Maybe someone could explain the intention of the SCPI commaArbnds with regards to the AWG. I tried a few. Most work as expected, like Basicwave (mostly, some glitches), Output, Storlist (huge list!).
What does not seem to work is ArBWaVe. What did I do:

1. Switch output on with:   c1:outp on   
    result:  Output is on, TE shows AWG menu
2. Switch basic waveform to Arb:  c1:BSWV WVTP,ARB
    result: Menu shows Wave Type Arb.., Arb type stair-up, And that is visible in the trace
3. Try to change the arbtype with: c1:ARWV NAME,PPULSE
    A short glitch, then still stair-up.

Assuming, that the TE might have changed the Waveform for a short moment, I

a) selected manually Trapezia as the waveform
b) set the slope trigger such that is triggers on the trapezia waveform, but  not on the ppulse waveform
c) set the waveform manually back to PPulse (no trigger)
d) send the SCPI command: c1:ARWV index,7
    Result: Triggered with a surprising pattern. A mix of trying to switch to trapezia and then again falling
    back to Ppulse. Screen shot below.
    I could repeat that a few times. After a while, the TE did not respond any more at all to the
    ARWV command.

Another strange effect:
Sending the command "C1:ARWV index,47" or "C1:ARWV index,25" breaks the SCPI interface. No command accepted any more, not even *idn?, until I disconnected and reconnected, or even had to reboot the TE.  Sometimes it causes the TE GUI to completely freeze. No touch, no button press, no nothing, although the waveform update still worked. I had to power cycle the TE to revive it.

[DL2XY]

Finally i was able to reproduce the issue by manipulating the output of the SPI_Master component of a PSOC3 uC and to track down the cause.

First: You can do anything you want with MOSI / MISO level as long as you do it outside CS active window, decode will be correct.




If you hold MOSI / MISO high after last bit inside CS window, the decode algorithm fails.
It looks like it depends on "return to zero' within time window between last falling clock  and rising CS to get the last bit evaluated.




In the real (hardware) world this time window is used to transfer the content of the shift register to the final data buffer.
Since the  behaviour of MOSI / MISO at the end of CS is not explicitly defined in SPI you may or may not get problems with real world chips appling such maipulated signals.

I personally would prefer an instrument alerting me in case of possible inconsistence than one what pretending everything is fine.   

[roberthh]

@DL2XY

First: You can do anything you want with MOSI / MISO level as long as you do it outside CS active window, decode will be correct.

In your example you have a falling data pulse after the last valid data bit, assuming you had decoded on the rising slope. So it decodes right. You can have the falling slope on data even outside the CS window, as long as it is inside the captured trace. And a low pulse may be very short. I tested it down to 50 ns, limited by my micro for signal generation.

[DL2XY]

@DL2XY

First: You can do anything you want with MOSI / MISO level as long as you do it outside CS active window, decode will be correct.

In your example you have a falling data pulse after the last valid data bit, assuming you had decoded on the rising slope. So it decodes right. You can have the falling slope on data even outside the CS window, as long as it is inside the captured trace. And a low pulse may be very short. I tested it down to 50 ns, limited by my micro for signal generation.

Yes, the siglent decoder needs a return to zero, regardless of if  it is in CS window or not.

What i ment is: In every implementation of SPI master i have seen so far the MOSI is reset to zero before raising CS.
This might be, depending on implementation of the receiver chip, vital for transfering shift-register to data register.

Your bitbang implemention does not do this, and the siglent decoder gets irritated.

[roberthh]

@DL2XY. It started from the observation of the board member @Cobra514, where his device left the miso line floating. And I have also a device, which leaves the MOSI line at the last state. Since, as you said, the status of MOSI and MISO is undefined after the last bit, it can be either level.
Besides that, the decoding must only depend on the level of the data line at the active clock transition inside the SS window, not on anything else.

[TK]

Looks like this BUG is being carried by Siglent for a long time.  Look at this old post about the SDS1104X-E.  If you look at the signals, it should decode to 05 A5 A5 A5, but it is decoded as A5 A5 A5 A0.

https://www.eevblog.com/forum/testgear/impressive-keysight-1000x-series-(edux1002g-modded)-spi-triggering-rate/msg2421777/#msg2421777