Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[tv84]

Maybe a bug or the bug is in front of the scope....

 

Patch the string with a \0.

[Martin72]

Patch the string with a \0.

 

[DL2XY]

\0 denotes an empty string, so nothing would be displayed. 

[Martin72]

Well...yes...But doesn´t help me to understand the "Zone is too small" message.
Which zone, why...
I´ve only set the attentuation...

[2N3055]

Probably some Zone triggering bug...


Happy New Year everybody, hope new one will be better and wish everybody is safe!!

[Martin72]

Same to you Sinisa - It could only going better...

The only positive aspect in 2020 for me was, for our case here, to change the scope brand..

[casterle]

Algorithm and data structure selection is paramount, because that's the sort of thing that makes orders of magnitude worth of difference.

Absolutely agree. You can't optimize away a bad plan by twiddling code, regardless of how well you know the processor and associated tricks.

Anyway, we can go to PM if you want to talk about this stuff further.

I think we've beat this topic sufficiently. 

I sometimes think that the best development environment for embedded stuff like the scope might be a development target in which everything runs at, say, a tenth of the speed of the actual hardware that's being targeted

I used to have a fast dev machine, and a slow test machine for just this purpose...back in the day.

[casterle]

New bug introduced in latest firmware?

I was unable to get Dot Mode working. Original question/answer posted here:

https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3395528/#msg3395528

[roberthh]

Can't confirm. Dot mode is working. But anyhow a strange screen shot. Are the dots properly connected in vector mode? What kind of signal did xou capture.

Example screen shot below with a 1.3.7R5 firmware.

[roberthh]

OK. At least I could reproduce a similar strange signal like yours, by
a) make a single shot of just an open channel at 1v/div
b) turning the vertical scale up in stop mode to 20 mV/div.

Then I have these sharp edges. The funny thing us the difference between sinc and x interpolation. Sinc goes really haywire.

But still, dots are shown properly.

[roberthh]

Using the same setup as before:
a) capturing a 100 mV pp 50 MHz sine signal from the AWG at 1V/div as single shot
b) turning up vertical scale to 20 mv/div

I get strange results from the was the lines are drawn between the dots. That seems to add a lot of visible noise by itself, even visible in low scale. Just look at all the vertical steps added where are definitely not dots to join.

Maybe it's intended, nevertheless surprising. At least for the X interpolation I would draw the lines by hand different.

[roberthh]

Looking at the detail it seems, that the interpolation itself creates noise to the displayed signal.
Also, in dot mode, while the instrument is in stop mode, switching between sinc and x interpolation, some dots move. That's strange too. And sinc seems to make the worse moves.

[kcbrown]

New bug introduced in latest firmware?

I was unable to get Dot Mode working. Original question/answer posted here:

https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3395528/#msg3395528

When I went to check this on my scope, I saw the same thing, with version 1.3.7R5 of the firmware (which is what came with the scope).  It didn't seem to matter what I did, the scope insisted on connecting the dots (whether via sinc or via straight lines).  Recalling the default settings cleared it with the same signal and trigger settings on the same channel.

I honestly haven't a clue what caused the bug to manifest itself.

[Martin72]

@roberthh:

Can reproduce it too.

Additionnaly I´ve played with several sinefrequencies/timebases ( to get more mempoints), amplitudes, always the same behaviour regardless of the stored points.
Last example was a 100Hz 2Vpp Sinewave, stopped by 2V/div. then decreasing to 500mV/div.
Running with 500mV/div then stop is no problem.
But everytime you decrease the V/div. in Stop-Mode, it seems, as if there was not enough "information" to form a proper signal.
Trying the same in 10bit mode, signal appears more polished.

[roberthh]

@kcbrown about dot mode:

I had a similar picture when setting 'Persistence' to 'infinite'. But in you screen shot it was set to off. Just as a blind shot: could you try to set 'Persistence' to 'infinite' and then to 'off' again. Maybe some setting is stuck in the memory.

[roberthh]

About screenshots, very loosely related to the actual discussion,

A few days after getting my SD2104+ and as an exercise, I made a little Python script to download screenshots with a command line command. It is based on the Python example in the SCPI documentation. Code attached. You have to change the IP address accordingly and eventually specify python3 in the first line, depeding on your defaults.  In my view, using this command is a little bit more convenient than using the browser option, because I can specify the name. In a different way convenient is storing screenshots to a USB disc by just pushing the print button. But then you have to rename the files later.

Edit: One Option (way down the preference list) for the save button would be to send the screen shots to  a server instead of storing them to the USB disk. The server could be a standard type (like ftp) or a specialized one. The latter could handle the file naming itself, making the configuration at the scope easier (just the IP address of the server).

[tautech]

One Option (way down the preference list) for the save button would be to send the screen shots to  a server instead of storing them to the USB disk. The server could be a standard type (like ftp) or a specialized one. The latter could handle the file naming itself, making the configuration at the scope easier (just the IP address of the server).

Existing web server functionality offers a Save Screenshot virtual key that sends PNG screenshots directly to your browsers download folder incrementing the PNG file # as you go.
Of course they still need renaming however once on your PC that's very easy.

[roberthh]

Existing web server functionality offers a Save Screenshot virtual key ........

I know that and I used it. The difference is where the user actions takes place, at the PC or at the instrument. Obviously, the difference is minor if the PC and the instrument are placed side-by-side.

[Martin72]

About screenshots, very loosely related to the actual discussion

I don´t think so, see text in the post.

[casterle]

Color Grade Bug or Operator Error?

The signal in the following screenshots is from the internal AWG. I believe it was a 100mV sine but reset the 'scope while trying to understand figure this out, so I don't know for sure. I think the important point is that the signal is from a consistent source. The data is from a single shot capture.

The first screenshot displays the bottom band at a higher temperature than the others. This should indicate more points around that level if I understand correctly.

The second screenshot, zoomed to show the data, shows this isn't the case; the dots are hard to see even with the graticule off, but there are an equal number of points in each band. The color grade, however, indicates equal data in all bands.

Is this expected behavior, and if so, why?

Thank you for your insight!

[roberthh]

It would be interesting on how you have set the AWG. I get a similar picture with teh AWG set to 25 MHz. At a sampling rate of 4 ms/s, this is by far undersampled. That's why you get these 4 bands. Besides that I would not expect to get anything reasonable from this measurement.
As far as I understand, the color grade indeed tells how often a certain band in a trace is hit. But i do not know how that applies to a undersampled trace. Repeating single shots I get all kinds of color assignments.

Edit: If you switch back the display to vectors you may see a sine. In my case it is a 1 MHz sine, sampled from a 25 MHz signal. Complete nonsense, but to be expected.

Edit2: At least I see that you got dot mode working.

[casterle]

It would be interesting on how you have set the AWG.

I could kick myself for not saving the settings before I reset the 'scope.

That's why you get these 4 bands.

Agreed. But note that each band is comprised of the same number of points.

As far as I understand, the color grade indeed tells how often a certain band in a trace is hit. But i do not know how that applies to a undersampled trace.

I'm not sure how under-sampling could affect the math. With the same number of points in each band, should not each band display in the same color?

Given that color temperature should indicate the degree of difference from one area to another, the colors in the first screenshot would indicate a large difference between the top 3 bands and the bottom band; no such difference exists as illustrated by dot mode (I had no idea how useful dot mode can be).

Also note that the all bands are displayed in the same color in the 2nd screenshot. Why?

Edit: If you switch back the display to vectors you may see a sine. In my case it is a 1 MHz sine, sampled from a 25 MHz signal. Complete nonsense, but to be expected.

Agreed.

Edit2: At least I see that you got dot mode working.

I did, with help from this fine community. 

I was playing with dot mode when I stumbled into my color grading question.

[casterle]

Help Formatting

It's nice to have a help system. It would be nicer if it were a bit more readable. 

[Martin72]

Ssshh...secret tip....user manual....Sssh..

[rf-loop]

Ssshh...secret tip....user manual....Sssh..

Who can write manual about scope users to scope designers and FW programmers.