Siglent Technical Support join in EEVblog

[tautech]

Is there a way to directly report to Siglent this kind of potential bugs/strange issues?

Done !
Thanks for your clear write up of it. 

[Martin72]

For the sds2000X+ model:

Bugs and wanted/missing Features Thread

[sequoia]

Product Type: SPD3303X-E
Software version: 1.01.01.02.05
Hardware version: V3.0


SCPI support appears to be broken, several SCPI commands (as documented in the manual) do not work, when sent to device terminated with NL (ASCII 0x0a) character:

*SAV
*RCL
INSTrument
MEASure
OUTPut


This appears to be pretty clear bug  since other commands work normally (and against SCPI/IEEE 488.2-1992 spec).


Here are examples of each failing command:

Code: [Select]

*RCL 1
*SAV 1
INST CH1
MEAS:CURR? CH1
MEAS:VOLT? CH1
MEAS:POWE? CH1
OUTP CH1,ON
OUTP:TRACK 1
OUTP:WAVE CH1,ON

When these commands are sent to instrument (with NL as command terminator as specified in the specs), unit responds with "beep" and sets following error:

Code: [Select]

SYST:ERR?
3  Command keywords were not recognized


Oddly enough unit seems to accept these commands, if no NL character is used to terminate command sent to the unit (as reported in this thread from last year: https://www.eevblog.com/forum/testgear/spd3303x-e-scpi-interface-issues/)

[Danjo]

Hello, I have a sds12052dl+ that I am unable to update.  I have downloaded the ads file and loaded it to an usb flash drive root menu, fat32 formatted.  Once connected to the scope, I initiate the update, the file screen opens and I can see my renamed ads file.  But the scope freezes there and I have to cycle power to free it.  But it does boot back up.  Any ideas to what I am doing wrong.  Also, this unit has software version 6.02.01.07.   Thanks in advance for any help .   

[tautech]

Hello, I have a sds12052dl+ that I am unable to update.  I have downloaded the ads file and loaded it to an usb flash drive root menu, fat32 formatted.  Once connected to the scope, I initiate the update, the file screen opens and I can see my renamed ads file.  But the scope freezes there and I have to cycle power to free it.  But it does boot back up.  Any ideas to what I am doing wrong.  Also, this unit has software version 6.02.01.07.   Thanks in advance for any help .

Welcome to the forum.

Just checking with you, your model is SDS1052DL+ correct ?
And you got the new firmware from here ?
https://siglentna.com/service-and-support/firmware-software/digital-oscilloscopes/#sds1000dl-series

Did you exactly follow the Firmware Update Instructions in the update package ?

[Danjo]

Yes, that is my model.  And yes that is where I downloaded my firmware and I followed the instructions; I renamed my file to something with less than 9 letters.  I also now have tried a different usb drive.  With this drive it freezes when I press single while I am in the black update firmware screen.  I have to cycle power to unfreeze it.  Thanks for helping med figure this out.  Any c;ue what I am doing wrong?

[tautech]

Yes, that is my model.  And yes that is where I downloaded my firmware and I followed the instructions; I renamed my file to something with less than 9 letters.  I also now have tried a different usb drive.  With this drive it freezes when I press single while I am in the black update firmware screen.  I have to cycle power to unfreeze it.  Thanks for helping med figure this out.  Any clue what I am doing wrong?

It can be the USB drive size and small ones are better.
I use 8 GB max and with an activity LED so you can see any activity when the file uploads into the scope.

If you have a 4 GB drive I suggest you try it.

[MathWizard]

Hey Tautech what is this glitch or setting problem. I have 1104x-e hacked to 1204, and 1-2 month old firmware.


Just stated the machine, CH2 only, defaulted to 10V/div, something like 500ns or 50ns timebase. AC trigger 0V . So I start zooming out, and it can't keep up at all. Right now I'm on 2s/div, and the trace is just a sliver (timewise), it's still only displaying a few ms wide trace.

So I hit auto. it starts zoomed in around 50ns again, I start zooming back out, and the same thing stats happening.

So I stop at some ms ranges, wait fort it to aqquire, and draw a full trace, then got to 200ms and had a full trace, then jumped to 2s, and it won't draw it, it only draws the 200ms wide trace, centered, and so looks like about 1 block wide. If I zoom back into 200ms, the trace is full width, but I zoom back out to 2s, and it just shrinks the trace, to 1div wide, centred.

Now in the 5minutes it took me to type this, it just managed to display a full 14s wide trace, at 2s/div.


So what's going on, it seemed if I wait long enough at each timebase, for it to draw a full time-width trace, then it was ok, but if I zoomed out faster, it skips stuff, and only displays the trace, from the smaller timebase.

It will say acquiring over and over, way longer than normal, and show nothing new.

The memory depth is at 14Mpts, 500kSa/s, at 2ms, everything should be more or less default, I barely changing anything since hitting "default" last.



I hope that makes sense, I'll snap a pic quicker next time. Any thoughts ? I keep having issues related to timebase or something......

Ran self-test/auto-cal 2 days ago, reports nothing


I hit default, and it's back to normal I guess. But IDK what I could have changed really, I don't touch the settings I don't use/know what they are.

[tautech]

MW, some usage tips....in no particular order or importance.

@ 50ms/div Auto Roll mode is engaged. Use the dedicated Roll mode button for a very different experience if you need slow timebase settings.
Each time you change timebase the Roll mode acquisition starts again.
Keep the Trigger DC coupled....only on rare occasions we need an AC coupled trigger.
Use the blue Pint button for screenshots straight to a USB stick.

[Danjo]

Sds1052dl+ firmware update issues


I tried updating with a 1gb USB drive to no avail.  I did notice a peculiarity; when attempting to update the scope with the USB formatted in fat, the scope opens the file manager page and I can see the firmware update, but it freezes there and I must cycle power to unlock it.  When attempting with the USB formatted with fat32 the scope freezes at the initial black screen when I press the single button.  I am not sure if this info can help any, but it is new information. I have also tried loading the file onto the USB from another computer, same conclusion.  Any idea what my next course of action should be?  Thank you for your time.

[tv84]

Change USB disk. Have you seen my pm?

[Fratink]

Hey @tautech (or anyone else that might know),

I have a SDS1202X-E that I just received a few days ago.  It has the latest firmware.

I'm working on a automotive application, specifically working with ISO9141 for my car.  I captured a sequence of responses from my car to decode and I couldn't get that decoding to work on the scope.  It doesn't appear that the scope is even attempting to decode the serial signal.  My baud is set correctly (10.4k), decode level is set midway on signal, but no go.  I attached a couple pictures to show what I was capturing. 

I also tried setting it to decode uart but this also didn't work, where I would have expected at least some error to be displayed.

I think this post might be related: https://www.eevblog.com/forum/testgear/siglent-sds1202x-e-impressions-and-a-couple-of-bugs-to-be-aware-of/
Any idea if this is fixed in the latest firmware?  I had my scope probe set to 10x and only found this post after attempting this in the car.

Thanks!

[tautech]

Hi Fratink
In preparing a reply I was under the impression most vehicles used CAN....how wrong was I ! 

Just a look at this page a bit later put me straight and scrolling down to the table Vehicle Messaging Protocols shows a few in common use.
https://en.wikipedia.org/wiki/Vehicle_bus
So when looking up some links for ISO9141 I stumbled on another Wikipedia page with this:
https://en.wikipedia.org/wiki/On-board_diagnostics
ISO 9141-2. This protocol has an asynchronous serial data rate of 10.4 kBaud. It is somewhat similar to RS-232; however, the signal levels are different, and communications happen on a single, bidirectional line without additional handshake signals. ISO 9141-2 is primarily used in Chrysler, European, and Asian vehicles.

RS-232 is considered similar to UART so that's what I'd initially try which it seems you have.

For any protocol we must determine what the idle state is in relation to the data packet and for most it is idle high therefore the first edge of all packets is falling so it's best to set our trigger for such.

I like to start by obtaining rock solid triggering on the edge of any old packet and for this to happen you require 2 very simple settings to be correct:
Edge, already mentioned and the prevention of retriggering until after any packet has finished.
This is accomplished by first determining the widest packet and setting trigger Holdoff for a little more.

How to do it.
Set a timebase with a few packets displayed, it doesn't matter that triggering isn't stable and press Run/Stop.
Find the widest packet and in the timebase you are using count the graticules that packet is covering. Multiply this count by the timebase setting and you have your holdoff value.
Now, in the Trigger Setup menu with the correct edge set and holdoff sufficient until after the packet is finished press Run/Stop and you should have rock solid stable triggering. Don't proceed until you have.

Now it's time to make settings to decode, first by selecting the correct protocol, baud rate, assigning channels and setting thresholds then engage decode Display.
Next, depending on the timebase chosen will determine how many packets are displayed and if there is enough room on the decode line to show the decoded result.
We can use the H Pos control to shift the trigger position left so to fit the result on the display or preferably zoom out so many packets are displayed and then engage Zoom for a dual timebase split display where we will have many packets in one window and just a portion of these in the zoomed display.
In the zoomed portion we can use the H Pos to pan through the whole primary timebase inspecting decoded results all the way.

So if you have your head around all that we can look at methods to capture the very start of a stream or packets within it.
For the first packet we could just use Single shot so when the packet stream starts (key switch or whatever) we capture the edge of the first packet and then as many as the scopes memory can hold.
This is where a slow primary timebase is your friend as memory depth is greatest and it's not unusual to capture 100's of packets to then be inspected with the zoomed timebase.
Packets within a stream need use of protocol trigger settings which are somewhat more involved which set specific bits on which to trigger on.

Sounds hard but it's not and procedures like these are the real power of a DSO with good memory depth.

I'll leave you with a selection of screenshots with a step by step walk through of how I've done it before preparing this reply albeit they are in CAN. 

[Fratink]

Hello tautech,

Yes, ISO 9141-2 is more like RS232 with Tx and Rx tied together.  Kinda like a 12V one-wire protocol.  It's similar enough to RS232 that would actually decode correctly using the uart decoder most likely,

My car is using ISO 9141-2 at 10.4kBaud as mentioned.  ISO9141 is also the underlying physical protocol used in LIN bus, which the 1202X-E is supposed to be able to decode. This is why I was very surprised that it wasn't able to decode LIN. It isn't even able to decode the 5-baud init. 

I'll try using the trigger and see if that works but I'm not super hopeful.

Edit: I may be incorrect, the LIN bus might be more complicated than the ISO9141 / OBD comms and thus could be decoding incorrectly.  I'll have to play around with it.

Cheers,

[tautech]

Hello tautech,

Yes, ISO 9141-2 is more like RS232 with Tx and Rx tied together.  Kinda like a 12V one-wire protocol.  It's similar enough to RS232 that would actually decode correctly using the uart decoder most likely,

My car is using ISO 9141-2 at 10.4kBaud as mentioned.  ISO9141 is also the underlying physical protocol used in LIN bus, which the 1202X-E is supposed to be able to decode. This is why I was very surprised that it wasn't able to decode LIN. I may have to ask about returning it as it was the sole reason i purchased it. 

I'll try using the trigger and see if that works but I'm not super hopeful.

Cheers,

It can easy do LIN but you must have the settings correct and first have rock solid stable triggering.
Study my post above for the steps to success.
Good luck.

PS, I can put LIN decode screenshots up later after other jobs...........

[Fratink]

Hello Tautech,

Thanks for the help, I think my error was in that the LIN protocol shares the same electrical specification but doesn't communicate exactly the same as ISO 9141.  I think the decoder is expecting a break before decoding and thus isn't working.  What I actually need is more akin to an inverted UART decoder I think.  ISO 9141 / K-line / KWP 2000 are all basically uart over ISO 9141 where LIN appears to be somewhat different.

Very unfortunate on my part.

Thanks for the help, i think that really helped me figure it out.

[tautech]

Hello Tautech,

Thanks for the help, I think my error was in that the LIN protocol shares the same electrical specification but doesn't communicate exactly the same as ISO 9141.  I think the decoder is expecting a break before decoding and thus isn't working.  What I actually need is more akin to an inverted UART decoder I think.  ISO 9141 / K-line / KWP 2000 are all basically uart over ISO 9141 where LIN appears to be somewhat different.

Very unfortunate on my part.

Thanks for the help, i think that really helped me figure it out.

If you have the settings correct in Stop mode it will still decode.
Electrical spec is so another device communicating with the stream matches the same offset and thresholds although they matter less for scope decoding.
All that matters for the scope is the protocol.

[Fratink]

Hey tautech,

So I figured it out.  As I surmised, ISO 9141 is really just a weird UART comms protocol.  What I did was to set the scope up to decode uart, set the baud-rate to 10400, trigger threshold around 4V, Data length 8, partity-none, stop bit 1.  All that didn't really work until I set the  the idle level to HIGH.  Then BAM!  it works.

Which means I didn't need to buy a scope with LIN haha.  Oh well, at least I have CAN bus decoding when I get to that.

Thanks for everything and hopefully this helps someone else.

[tautech]

Hey tautech,

So I figured it out.  As I surmised, ISO 9141 is really just a weird UART comms protocol.  What I did was to set the scope up to decode uart, set the baud-rate to 10400, trigger threshold around 4V, Data length 8, partity-none, stop bit 1.  All that didn't really work until I set the  the idle level to HIGH.  Then BAM!  it works.

Which means I didn't need to buy a scope with LIN haha.  Oh well, at least I have CAN bus decoding when I get to that.

Sweet, good job and well done.   

Thanks for everything and hopefully this helps someone else.

Yep, that'e the plan but this sorts stuff gets buried in threads unfortunately.

We should really start a Decoding 101 thread.

[Fratink]

Hey tautech,

So I figured it out.  As I surmised, ISO 9141 is really just a weird UART comms protocol.  What I did was to set the scope up to decode uart, set the baud-rate to 10400, trigger threshold around 4V, Data length 8, partity-none, stop bit 1.  All that didn't really work until I set the  the idle level to HIGH.  Then BAM!  it works.

Which means I didn't need to buy a scope with LIN haha.  Oh well, at least I have CAN bus decoding when I get to that.

Sweet, good job and well done.   

Thanks for everything and hopefully this helps someone else.

Yep, that'e the plan but this sorts stuff gets buried in threads unfortunately.

We should really start a Decoding 101 thread.

That could be helpful.  If you do decide to let me know and I can probably help with ISO 9141, perhaps others.

[CharlotteSwiss]

I just had another hard crash related to saving, which required an unplug.

Save / Recall > Press to Save.  Machine hung for several minutes till I unplugged it. I don't have the details on the save type, as I noticed when I've restarted my changes were lost. I'll try to be more systematic but am becoming shy about anything related to saving.

I also have a new SD card via an adapter plugged in to the USB port.

Mark

i see that hais only encrypt two messages in the forum .. did you find any solution then? always if you still read this forum ..
 

[CharlotteSwiss]

I just had another hard crash related to saving, which required an unplug.

As I have also had too many "USB Print" related crashes, I went back to FW 1.3.23 and they were gone - for ever!!! Please do me a favour and also go back, just observing USB savings vs. crashes: If you also have no problem with 1.3.23 at all, it has something to do with 1.3.26! ...it is better to have a working Scope with 1.3.23, than too many crashes with always being forced pulling the plug...

SDS1202X-E Firmware (2-Channel Model) – 1.3.23 (Release Date 09.27.18)
https://www.siglent.eu/downloads

so passing to the previous firmware there are no more blocks with print key? would be great!
But this means that Sigòent could make a subsequent firmware that corrects the Print bug, but keeps the updates of version 1.3.26
From the Siglent engineers, a lot of people out here are waiting for your progress
 

Note to Siglent engineers:
if as the user says, with the previous firmware 1,3.23 we do not have the Print button bug, while with the latest firmware we have it (1.3.26), it should be one of the additions to cause it, among these:
1. Channel waveform can be hidden
2. Added a pop message: If there are too many serial frames in one sample, the Scope does not decode all of the serial frames and pop up message of 'Decoding to maximum frame number limitation!'
3. Fixed the bug: Save/Recall setup of trigger and scale issue
4. Fixed the bug: In fine adjust mode, some scale such as 302 mV/DIV is in the wrong position
5. Fixed the bug: LIN decoder doesn't decode frames with zero-length response
6. Fixed the bug: If the Courser Offset is not a multiple of zoom time base, the curser will be replaced when zoomed
7. Fixed the bug: The measurements made with the cursor in Ref. Give wrong values for all the different probes of X1
8. Fixed the bug: Measures fairs with GATE give completely random values in signals of low frequency
9. Fixed the bug: Normal trigger can show more-than-one trigger event on the display at one time
10. Fixed the bug: Erratic triggering, randomly jumping between the first and the second edge of a signal

 

[tautech]

Factory on holidays until the 8th Oct.

[Martin72]

Probably some decoding issues on sds2000X+ series

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