Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[roberthh]

@TK Except that the sd2000x+ decodes that as A5A5A5A4. 1 bit progress. Not very promising, if a bug has not been fixed for so long. But maybe no one addressed that.
Edit: Looking at that linked data again, the decoding is right. The most-left pattern is indeed A0. The setting seems indeed to be LSB, not MSB

[TK]

@TK Except that the sd2000x+ decodes that as A5A5A5A4. 1 bit progress. Not very promising, if a bug has not been fixed for so long. But maybe no one addressed that.
Edit: Looking at that linked data again, the decoding is right. The most-left pattern is indeed A0. The setting seems indeed to be LSB, not MSB

You are right, it is LSB

[Cobra514]

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

FWIW:
I am using a Total Phase SPI generator that has been in production for years.  No issues ever with other 'scope manufacturers.

To be sure, I just tested my exact patterns as was failing, but with a cheap "brand" name 'scope - and it decodes perfect.

BTW, I too have another generator on my bench that defaults to low.  Never tried, but suspect the Siglent would work on that one.

So that's 50/50 here for how it is implemented in my limited sample set LoL. 

Even if one particular implementation were to be more common - that does not mean there is not a problem here.
If returning to LOW happens to be more common though, that *may* explain why Siglent employees did not catch it in testing (who knows how they generated the test vectors).

Either way - it is a bug - as the Mot. SPI standard allows for either from my interpretation.

[Cobra514]

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.

I have not looked into this, but I can say I have duplicated essentially the same on my end.
Screenshot attached.

*EDIT* For what it's worth, I'm using NI VISA over USB

*EDIT #2*  I did a bit of research on this.  Here are a few things I found:

1) The SDS Series Programming Guide notes that the index #s for the waveforms shown in the document are "just an example".  One needs to query the device to figure out the actual index mapping for a specific model.  That was aggravating (because documenting that for users is so expensive? - it's a table that takes up 1/3 of a [digital] page). 

2) Going through the Arb Type menus I counted 45 types + 2 under the "Stored" tab.  Consistent with the datasheet.
I queried and got index values ranging from 2 (StairUp) to 46 (Acot).

@roberthh: this is a guess, but maybe that is why you had a lockup on index 47?  I did as well.  I did not have a freeze on index 25, however (which is a valid index - Logrise tripuls).  But I only tried once.  Even if that is the case, that is terribly poor error trapping on the part of Siglent. 
2a) So in the manual, one can disregard index 0 (Sine) and index 1 (Noise) and 47 (Square).  These waveforms are located under BaSic_WaVe for our model.
2b) Additionally, index 37 in the manual (Harris) is actually BlackmanH internally and index 38 (Bartlett) is actually Bartlett-Hann.

3) I am not able to send *ANY* ARB waveform type changes via commands (only locally on the TE).  I tried both "name" and "index" ARbWaVe syntax variations.  I also tried both "long" and "short" form commands.
I believe consistent with @roberthh's findings, I usually just get a glitch that looks like the generator is attempting to switch, then it reverts back to current waveform.  I tried many waveform types.
I am able to send BaSic_WaVe commands, however.

Maybe I'm not sending commands properly, but I am taking them right out of the Siglent manual.
I tried turning off the output via commands in-between switching waveforms to no avail.
I also performed a few power cycles and set the TE to "DEFAULT" settings upon boot before attempting commands, just to make sure I was not in some incompatible mode.

Either there is another bug here - or I missed something in the manual regarding programming ARB.
Maybe there are some subtle peculiarities to programming this device that elude me.
Seems it shouldn't be so difficult.

[roberthh]

@roberthh: this is a guess, but maybe that is why you had a lockup on index 47?  I did as well.  I did not have a freeze on index 25, however (which is a valid index - Logrise).  But I only tried once.  Even if that is the case, that is terribly poor error trapping on the part of Siglent. 
2a) So in the manual, one can disregard index 0 (Sine) and index 1 (Noise) and 47 (Square).  These waveforms are located under BaSic_WaVe for our model.
2b) Additionally, index 37 in the manual (Harris) is actually BlackmanH internally and index 38 (Bartlett) is actually Bartlett-Hann.

The freeze happens not all the time. You may have to repeat that ARWV command several times until it happens. Looks like an internal memory corruption.

About 47 (not 42):
I recall that I had tried to load a waveform called square.csv to the TE, generated with Easywave. If I now enter:
"ARWV name, square"
and then
"ARWV?"
I get
"C1:ARWV NAME,square.bin"
as response. Which is strange The output still shows the StairUp pattern. And at the command, the output shortly stops. The trigger I use the to show that effect is: negative pulse for >= 1 ms. Easier than the slope trigger I used before.

The manual tells that the waveform table is just a sample, and one should use the STL? command to get the list of installed waveforms. This list is pretty long and shows 198 waveforms. It is the same as in the manual. And I choose 47 (square), because I wanted to see if that square has a better rise time than the basic waveform.

Edit: Trying to load a waveform mywave,csv from USB results in mywave.csv being shown in the menu, without any change to the signal.
And: Any index > 45 freezes the TE.

Besides that, here is a pretty-print of that list.

Code: [Select]

           2,StairUp         52,RoundHalf          102,LFPulse           152,Duty16
           3,StairDn          53,RoundsPM            103,Tens1           153,Duty18
           4,StairUD        54,BlaseiWave            104,Tens2           154,Duty20
            5,Ppulse         55,DampedOsc            105,Tens3           155,Duty22
            6,Npulse          56,SwingOsc             106,Airy           156,Duty24
          7,Trapezia         57,Discharge          107,Besselj           157,Duty26
            8,Upramp            58,Pahcur          108,Bessely           158,Duty28
            9,Dnramp            59,Combin        109,Dirichlet           159,Duty30
           10,ExpFal               60,SCR              110,Erf           160,Duty32
          11,ExpRise       61,Butterworth             111,Erfc           161,Duty34
          12,LogFall        62,Chebyshev1          112,ErfcInv           162,Duty36
          13,LogRise        63,Chebyshev2           113,ErfInv           163,Duty38
             14,Sqrt                64,TV         114,Laguerre           164,Duty40
            15,Root3             65,Voice           115,Legend           165,Duty42
              16,X^2             66,Surge         116,Versiera           166,Duty44
              17,X^3             67,Radar          117,Weibull           167,Duty46
             18,Sinc            68,Ripple        118,LogNormal           168,Duty48
         19,Gaussian             69,Gamma          119,Laplace           169,Duty50
         20,Dlorentz          70,StepResp          120,Maxwell           170,Duty52
        21,Haversine       71,BandLimited         121,Rayleigh           171,Duty54
          22,Lorentz            72,CPulse           122,Cauchy           172,Duty56
         23,Gauspuls           73,CWPulse             123,CosH           173,Duty58
        24,Gmonopuls          74,GateVibr           124,CosInt           174,Duty60
          25,Tripuls          75,LFMPulse             125,CotH           175,Duty62
          26,Cardiac           76,MCNoise             126,CscH           176,Duty64
            27,Quake                77,AM             127,SecH           177,Duty66
            28,Chirp                78,FM             128,SinH           178,Duty68
          29,Twotone               79,PFM           129,SinInt           179,Duty70
              30,SNR                80,PM             130,TanH           180,Duty72
          31,Hamming               81,PWM            131,ACosH           181,Duty74
          32,Hanning               82,EOG            132,ASecH           182,Duty76
           33,kaiser               83,EEG            133,ASinH           183,Duty78
         34,Blackman               84,EMG            134,ATanH           184,Duty80
         35,Gausswin      85,Pulseilogram            135,ACsch           185,Duty82
         36,Triangle          86,ResSpeed            136,ACoth           186,Duty84
        37,BlackmanH              87,ECG1         137,Bartlett           187,Duty86
    38,Bartlett-Hann              88,ECG2        138,BohmanWin           188,Duty88
              39,Tan              89,ECG3          139,ChebWin           189,Duty90
              40,Cot              90,ECG4       140,FlattopWin           190,Duty92
              41,Sec              91,ECG5        141,ParzenWin           191,Duty94
              42,Csc              92,ECG6        142,TaylorWin           192,Duty96
             43,Asin              93,ECG7         143,TukeyWin           193,Duty98
             44,Acos              94,ECG8           144,Duty01           194,Duty99
             45,Atan              95,ECG9           145,Duty02        195,demo1_375
             46,Acot             96,ECG10           146,Duty04        196,demo1_16k
           47,Square             97,ECG11           147,Duty06         197,demo2_3k
          48,SineTra             98,ECG12           148,Duty08        198,demo2_16k
          49,SineVer             99,ECG13           149,Duty10                     
           50,AmpALT            100,ECG14           150,Duty12                     
           51,AttALT            101,ECG15           151,Duty14                     


[roberthh]

sds2104x+, 1.3.5R10

I just noticed a strong microphonic effect on the inputs. Not really a problem on a quiet table, and also pretty common to that kind of design, but string. Reading in the forum, that seems to apply to quite a few vendors, even the "big" names.

[Cobra514]

The manual tells that the waveform table is just a sample, and one should use the STL? command to get the list of installed waveforms. This list is pretty long and shows 198 waveforms. It is the same as in the manual. And I choose 47 (square), because I wanted to see if that square has a better rise time than the basic waveform.

Very nice work and reporting @roberthh.  Nice table formatting :-)

Yes, I do get a big list as well from STL?.  Too big.

My first guess is that the table was a copy/paste from some other (higher model) firmware (because we don't have access to all those waveforms in the table).

So I did some detective work....
First I checked the "flagship" 5000 series manual.  It also states only 45 arb waveforms.
Then I jumped to the SDG6000X Waveform Generator features.  Sure enough - it has 196 waveforms!
Note that the STL? list ends at location 198....but it starts at location 2....so the total is 196 waveforms.  Probably not a coincidence.
My guess is that the table is a copy/paste from some other TE (like a dedicated function generator).

Since the User Manual states that there are 45 built-in and 2 custom arb waveforms, I believe the table that STL? returns is misleading (they show more than we have access to).
I get valid index/name queries from index 2 thru index 46 (for a total of 45 arb waveforms).

For me, queries of 0 or 1 are ignored (but 'scope remains operational), from 2 to 46 queries work fine, and queries above 46 cause the TE to lockup - requiring a power cycle to recover - *BAD*.  That's bad coding practice, but I suppose I can give them a pass on considering it a bug.

Seems the firmware is attempting to keep us restricted to 45 arb waveforms, it's just that the invalid command trapping works below the lower boundary (2) and locks up above the upper boundary (46).

But I can live with the subset of the STL? table, since I was only expecting a total of 45 arb waveforms anyway.

Nevertheless, it is safe to say that the implementation of the STL? command is a BUG.
(for reporting an incorrect list of waveforms for our model)

[roberthh]

@cobra514 Thanks for the analysis of the waveform list and usage. For me, the AWG topic may rest until eventually Siglent fixes it. With AWG, I count six bugs:

1. Not being able to load own waveforms form USB
2. When trying to select a waveform by index > 46 though SCPI commands, the TE stalls. Clearly a missing check for wrong values.
3. No reasonable activity when trying lo load a waveform from a channel. Art least the channel should be selected. But the only thing that happens is switching off the output.
4. Not being able to select a Waveform with a SCPI command. The TE shortly switches to the requested waveform, and then back to the one set in the Menu. That could be a GUI bug.
5. The List reported by the STL? command is wrong. It contains waveforms not present
6. No support through EasyWave. There is not even a version assigned to that TE. The existing EasyWave versions allow to extract a channel pattern from the TE, but you cannot send a waveform.

Again, that all is nothing that would stop one using the TE with success and pleasure, but especially #1 - #4 should be fixed.

[roberthh]

SDS2104x+, 1.3.5R10

FFT function, Linear vertical scale setting
a) Setting scale by keypad is weird
b) changing the scaling for the input channel sets back the FFT scaling to default values

ad a) When you are using the Unit Vrms for the vertical scale, the default setting for Scale and Ref Level is 100V and 500V. Setting that to a lower level is strange. You cannot set the Scale via keypad to 1V. It you try, you get 10V. You can enter 100mV, in which case you get 1V. Then you can dial down. You can set the ref Level to 1V.

ad b) When you change the V/div setting of the related input channel, the FFT Scale and Ref Level is set back to 100V / 500V. That's annoying.

You might ask why I used the linear scale in FFT: Just to see linear changes in the spectrum of a signal. For that it's useful.

Edit: It's not understandable why the default setting for FFT Scale and Ref Level is set as the works case, instead of just taking the actual numbers of the respective input channel. These should match.

[sdouble]

Not really a bug, and it may just be me. I usually look at tiny (couple of mV) signals from  amplifiers of variable offset from 1 unit to another.  I would like to adjust the offset  at say 20 mV/div sensitivity and then zoom down the 1mV/div. Problem : the offset is not kept when changing sensitivity.

[tautech]

Not really a bug, and it may just be me. I usually look at tiny (couple of mV) signals from  amplifiers of variable offset from 1 unit to another.  I would like to adjust the offset  at say 20 mV/div sensitivity and then zoom down the 1mV/div. Problem : the offset is not kept when changing sensitivity.

In the Utility menu you have choices to set vertical or horizontal traces to a fixed position so when zooming in they do not move.

[roberthh]

SDS2104X, 1.3.5R10.

Topic: Unexpected high event count when measuring

This is just a strange observation during measurement which is somewhat irritating.
Set-up:
Input signal 0.5 Hz suqre wave with 50% Duty cycle at 3.3Vpp, trigger at 1.V
Trigger: Auto-Trigger,
Horizontal: 500 ms/div, Roll enabled (this is a slow signal)
Measurement enabled for period.
The value for the period is fine, only the measurement count increases by 2 about twice per second, in total 4 per second. Which is kind of surprising for a 0.5 Hz signal. I could understand if it increments once per second, because at that rate a new edges comes in. Setting the Horizontal scale to 1s/div changes that to about 8/sec increment. Edit: With a burst of 100 cycles it counted 378 periods and 485 falling slopes.
When switching off roll mode, the counting of events is reasonable.

Edit: Another observation:
In roll mode, no input signal at all, all items from the Miscellaneous tab seem to increase by ~ 2 per second.
In Auto mode the increase every sweep.

That looks strange if there is no signal. But the count item seems to count measurement cycles, not the indicated items. E.g. even if the count increases, the number of edges stays 0. Still, that behavior is different between the miscellaneous items and the items from the other tabs.

[roberthh]

There is a new firmware now. 1.3.7R5.
Works so far. A few results:
- The Display options are fine. Changing the colors for the channels may be useful. I have doubts whether it was worth the coding effort.
- Bode Plot seems to be a little bit faster. On a second attempt to run Bode plots it completely failed. Reason: Sequence sampling was enabled. That may have been a phenomenon before too.
- I could not tell how to set the serial trigger as source for counting (topic 7). That was already mentioned for version 1.3.5R5.
- Zooming in roll-stop mode works
- AWG waveform loading works now. Choosing an Wavorm by e.g. Index 47 still freezes the device.  I did not test the other AWG bugs.

- The bug of not being able to scroll to the first element of a list seems to be gone (was not mentioned in the change log) Note: Not fixed. It is still not possibel going to the first element using the scroll bar.
- Pushing the lower right corner opens LAN setting (not mentioned in the change log)

No more test right now. I have no source for the new protocol decoders, so I cannot test them. They are as usual enabled for a trial period, but not available for purchase yet.

[roberthh]

 A few more results:
- Setting the ARWV with "C1:ARWV index, number" works. (not mentioned in the change log) Setting the waveform by name fails.
- The List returned by STL? is still wrong.
- The generated waveform does not have to be 16384 points, it can be fewer. Tested with 4096

- The SPI decode failure seems to be fixed. Decoding works even when the data line stays high. (not mentioned in the change log)

[Martin72]

not mentioned in the change log

It seems, they like telling not everything - A "nice" game for users to find out...

[rf-loop]

- The Display options are fine. Changing the colors for the channels may be useful. I have doubts whether it was worth the coding effort.

Example my eyes (and mind) are very allergic when I see some non harmonized or "ugly" colors mixes on the screen.
But more seriously, humans eyes are different. Also age makes some changes what may affect also what colors are better for visibility.

Why only traces. All, everything on screen must have free adjustable colors.

It was old time one R&S bit better Spectrum analyzer have this feature. When get all adjusted for just my taste and eyes it was very nice to use and look... even if need use extremely long periods, also if need work in bit dim lab it is very important to have colors what do not destroy eyes dark sensitivity and what support good eyes accommodation and focus. Most users are young peoples and eyes are much more adaptive. Young peoples do not understand this at all, they simply do not have experience using older eyes - nearly same as try explain milk color to born blind people.
Of course then one important group are peoples whoi have some anomaly in color visibility and differentiation.

I want that I can adjust every single item on display. Period. And it do not need difficult programming at all. One of simplest things in scope FW.

ugh...

[roberthh]

@rf-loop My eyes get old too, but the problem is more with contrast & reflections

About the firmware:

+ the protocol decoding speed seems to be improved a lot. Especially UART was sometimes extremly slow. Now it
is more snappy.

- loading AWG waveforms is a little bit rough. Sometimes I have to retry it a few times. Simply pushing at the file name works sometimes, sometimes not.
- The title "stored" waveform is misleading. Imported waveform are not stored beyond the time of using them. If you switch to another waveform and want to use the loaded waveform again, you have to re-load it. And the Channel option still does not work. It just switches off the AWG.
- There is no setting for using the counter for trigger events. I would have expected it in the counter source section. I have no clue what the change log tries to tell me.


Last not least: No update of the documentation or the programming manual. Will come, I hope.

[Szybkijanek]

SDS2104X, 1.3.7R5.

Web Server remote it doesn't work for me.
" alt="" class="bbc_img" />

[roberthh]

That worked for me, using both Firefox@Linux, Chrome@Linux and Edge@Windows. Did you check the LAN settings on the device? Did you set a password?

[Szybkijanek]

I set a static IP and the oscilloscope connects to the network as you can see in the screenshot, but I can't see the oscilloscope screen, 4 buttons work.
" alt="" class="bbc_img" />

Ok, work on InternetExplorer but not with latest Chrome...

[roberthh]

Can you issue SCPI commands like *IDN?

[Szybkijanek]

All works perfectly on Internet Explorer but something is with my Chrome browser.

[Martin72]

My colleagues at work don´t use any serial trigger, they always use the edge trigger for decoding(We use SPI)...

[Martin72]

Done the upgrade today, will test some things later.
But first of all, this let the sun goes up in my heart....
BTW., what means "floating" in the menu style ?

[2N3055]

Done the upgrade today, will test some things later.
But first of all, this let sun go up in my heart....
BTW., what means "floating" in the menu style ?

It means menu will not resize screen but will go over the waveform...