Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[RBBVNL9]

thanks for reporting and your effort to trace it down!

I'm wondering if, beside LIN and CAN error detection and decoding issues, the 1553B is also affected?
Can someone check this?

You're welcome! In the end this took way more time and energy than I was expecting to spend in it :-|

Whether the MIL-STD-1553B decoder is affected as well I don't know. I would need a 1553B coded signal with known errors in there to check, and preferably a couple of other devices that can decode this standard as comparison points.

However, in contrast with most other protocol decoders in the SDS, the 1553 protocol bus display has a column called "Error". It's all the way on the right. This suggests that for this protocol, errors are indeed shown. But someone would need to test to be sure.

[Martin72]

If I would take my scope at work, I could decode 1553 - But causing an error on the bus...Must talk to our software guy.
Couldn´t do that immediately, so have patience everyone.

[RBBVNL9]

If I would take my scope at work, I could decode 1553 - But causing an error on the bus...Must talk to our software guy.
Couldn´t do that immediately, so have patience everyone.

Just a thought: perhaps mix a good 1553 signal with some infrequent, disturbing pulses coming from a function generator? I guess this would at least lead to some forms or decode error (and see whether that get displayed in telegram or bus display), and check that error also via serial trigger (where I see eight error categories the SDS distinguishes). This approach could lead to some testing, but obviously not to all types of errors being tested.

But it would save you having to ask software engineers to write code for you! 

[nctnico]

How about recording a piece of 1553 data with a scope, edit the waveform to add errors and transfer it to an AWG? Or skip the recording part and create a waveform using a script and load that into an AWG. You can create all kinds of errors and bit time variations that way.

[RBBVNL9]

How about recording a piece of 1553 data with a scope, edit the waveform to add errors and transfer it to an AWG? Or skip the recording part and create a waveform using a script and load that into an AWG. You can create all kinds of errors and bit time variations that way.

A similar thought crossed my mind. Also to be able to send the captured waveform to others so they can test it on their devices. Perhaps capture it and save from the SDS itself, so it can be easily played from the SDS AWG.

If I have time I might try something like this...

The limitations here is that this is only (in a simple way) possible with 1-wire protocols. With protocols requiring more than one pin, a single channel AWG is not sufficient. I assume it should be possible to play such multi-pin waves from the RTB though, as it has a 4-pin pattern generator, which allows ARB patterns, and this hardware is in fact used by the RTB to make its own UART, I2C, SPI, CAN and LIN training/demo sequences. Of course, it needs to fit in the specific specifications of that pattern generator (timing speeds, etc.) So, if anyone cares to make such patterns for MIL-STD-1553B, FlexRay, CAN FD, SENT, or Manchester, with or without deliberately inserted errors, do share them in the community!

 

[Deichgraf]

How about recording a piece of 1553 data with a scope, edit the waveform to add errors and transfer it to an AWG? Or skip the recording part and create a waveform using a script and load that into an AWG. You can create all kinds of errors and bit time variations that way.

The 1553 standard allows the BC (Bus Controller) to inject certain type of errors for test & sw-evaluation purpose. So, if the bus is "driven" by some BC-Simulation HW/SW (e.g. CoPilot or similar), then this would be a very quick task by defining 1553 messages with error injection (manchster coding, crc ...) stuff.

[IAmBack]

Missing feature: lack of high/low/bandpass filter in math section (or in any other place). Today I needed this feature, and ended up playing with 1054z... Or I couldn't find it.

[Martin72]

You can search as long as you could, you won´t find it...
None of the siglent models have these functions and I´ve added them to my wishlist "long time ago" too.
You may ask why siglent doesn´t implement it so far, while "even" a rigol ds1054z got it.
I had the bigger, stronger, faster model mso5000 and of course it got the filters, but they don´t work proper as expected.
And this may be the point and this is what I like on siglent:
If you can´t be sure that it works as it should, don´t do it.
Maybe they find a way to implement it with proper function someday.
But I don´t think that is a high priority point for siglent, even the sds6000a doesn´t got it.

[RBBVNL9]

Small question for the SDS experts 

These instruments allow the user to set the horizontal reference strategy (Utility > Menu > Reference position). It is described in the manual on page 337.

• You can choose between a "Fixed Delay' (simply called 'Delay' on the screen of the device). Then the reference point is simply in the middle of the screen, and when the horizontal timebase scale is changed, the waveform expands/contracts around the center of the display.
• Then there is "Fixed Position" (simply called 'Position' on the screen of the device). Here the user can select a reference position from 0% (outer left of the screen) to 100% (outer right of the screen). Then the waveform expands/contract from that chosen position.

This is a welcome function indeed.

Now the question... In the current FW 1.3.9R6, when ‘position’ is selected (i.e., the button turns blue), the position entry field disappears, and if you select “delay”, the horizontal entry field re-appears.

Could it be that the labels on these two buttons are accidentally switched in the user interface?

(Also, I find the terminology position vs. delay used kind of confusing. It would be more intuitive calling this "Centre Position" and "Adjustable" Position", or simply a single parameter that is default at 50% and can be changed. Just my two cents.)

[IAmBack]

You can search as long as you could, you won´t find it...
None of the siglent models have these functions and I´ve added them to my wishlist "long time ago" too.

Pity.
Measuring low level, low frequency signals was (almost) impossible on Siglent due to hf excessive noise. Rigol did it without a problem. Even it's noisy front-end was not a problem.
Well, at last I have good excuse for not selling my second, sorry, third... Sorry. Just not selling this little scope.

[Performa01]

Small question for the SDS experts 

These instruments allow the user to set the horizontal reference strategy (Utility > Menu > Reference position). It is described in the manual on page 337.

• You can choose between a "Fixed Delay' (simply called 'Delay' on the screen of the device). Then the reference point is simply in the middle of the screen, and when the horizontal timebase scale is changed, the waveform expands/contracts around the center of the display.
• Then there is "Fixed Position" (simply called 'Position' on the screen of the device). Here the user can select a reference position from 0% (outer left of the screen) to 100% (outer right of the screen). Then the waveform expands/contract from that chosen position.

This is a welcome function indeed.

Now the question... In the current FW 1.3.9R6, when ‘position’ is selected (i.e., the button turns blue), the position entry field disappears, and if you select “delay”, the horizontal entry field re-appears.

Could it be that the labels on these two buttons are accidentally switched in the user interface?

(Also, I find the terminology position vs. delay used kind of confusing. It would be more intuitive calling this "Centre Position" and "Adjustable" Position", or simply a single parameter that is default at 50% and can be changed. Just my two cents.)

This setting alters the function of the horizontal position knob, and everything is labelled correctly.

If we use the “fixed delay” strategy, then the trigger delay with respect to the reference position is set by the horizontal position knob. The reference position on the other hand can be set to anything between 0 and 100 % of the display width in the Horizontal Ref. Pos. field, where 50 % is the default value.

It means that the delay remains constant and because of this, the trigger position changes with timebase and can get shifted far outside the visible screen quite easily. That’s fine if you want to observe a certain region of the waveform that has a certain delay with respect to the trigger point – this is the reference position, that remains constant, regardless of the timebase.

For example, if you have a trigger delay set to 1 µs and the reference position to 20 % in constant delay mode, the trigger point will be at 10 % of the screen width at 1 µs/div and you get the part of the waveform at the reference position at 20 %, that is exactly 1 µs after the trigger event. Now if you change the timebase to e.g. 100 ns/div, the trigger point is far outside the visible screen area, but you still see a zoomed version of that 1 µs delayed part of the waveform at the reference position, which you had set to 20 % of the screen width.


If we use the “fixed position” strategy, then the trigger position is always equal to the reference position and both can be adjusted simultaneously using the horizontal position knob. The only problem is the hollow triangle that remains at 50 % of the screen width, suggesting there is anything of importance there – actually, there is not.

It means that the reference = trigger position remains constant with various timebase settings. That’s fine if you want to observe the trigger point in a waveform regardless of the timebase setting.

For example, if you set the horizontal position to 20 % in constant position mode, the trigger point will be at 20 % of the screen width at any timebase setting.


You can ask yourself why we need the two different modes – after all, “constant delay” already does everything we need. Well, trigger delay is a concept dating back to the times where memoryless storage scopes (from Tek) were a thing and we needed a set of crouches to overcome the limitations going with it. Nowadays, with deep memory and well implemented zoom modes, trigger delay is not nearly as important as it used to be, so we might prefer just setting the trigger position with the position knob quickly, instead of digging into a menu.

[Performa01]

You can search as long as you could, you won´t find it...
None of the siglent models have these functions and I´ve added them to my wishlist "long time ago" too.

Pity.
Measuring low level, low frequency signals was (almost) impossible on Siglent due to hf excessive noise. Rigol did it without a problem. Even it's noisy front-end was not a problem.
Well, at last I have good excuse for not selling my second, sorry, third... Sorry. Just not selling this little scope.

You’re not serious, are you?

Siglent’s SDS2000X Plus of all things should not be able to measure low level low frequency signals (within the constraints of a general purpose oscilloscope), whereas a noisy Rigol is? And the excellent HF noise of the Siglent, which is somewhere between 2.4 and 3.5 nV/sqrt(Hz) should be a problem for LF measurements?

It’s not the first time that I’ve demonstrated low level, low frequency measurements with a Siglent DSO.

There are so many measures to ensure proper measurements under challenging conditions, including the trigger noise rejection function and HF-rejection coupling.

For the acquisition we have 10 bits mode, 20 MHz bandwidth limiter and average and ERES math functions. ERES is a lowpass filter by the way.

In the attached screenshot you can see a 10 Hz, 1.1 mVpp sinewave directly captured with 10 bits and 20 MHz bandwidth limit. Perfectly usable already, no further measures required. Is that not low frequency low level? Can you demonstrate how the Rigol does it so much better?

But there are two additional math traces. F1 is ERES 3.0, boosting the total resolution up to 16 bits. By limiting the record length to only 200 kpts the ERES lowpass has a corner frequency of just 7 kHz. Since its not the HF noise, but the 1/f noise that is a problem with all general purpose oscilloscopes, we still see some significant LF noise at the sensitivity of 500 µV/div. The measurements are pretty close, so neither the resolution enhancement nor the lowpass filter was really required.

F2 shows the result of 16x averaging. Since this is a static signal, it is the more effective measure, because it also reduces the LF noise. Still not a huge difference.

Finally it would be possible to combine ERES with averaging in a single math trace by means of the formula editor.

SDS2354X Plus_1mVpp_10Hz_200kpts(ERES7kHz)

[nctnico]

You can search as long as you could, you won´t find it...
None of the siglent models have these functions and I´ve added them to my wishlist "long time ago" too.

Pity.
Measuring low level, low frequency signals was (almost) impossible on Siglent due to hf excessive noise. Rigol did it without a problem. Even it's noisy front-end was not a problem.
Well, at last I have good excuse for not selling my second, sorry, third... Sorry. Just not selling this little scope.

You’re not serious, are you?

Siglent’s SDS2000X Plus of all things should not be able to measure low level low frequency signals (within the constraints of a general purpose oscilloscope), whereas a noisy Rigol is? And the excellent HF noise of the Siglent, which is somewhere between 2.4 and 3.5 nV/sqrt(Hz) should be a problem for LF measurements?

It’s not the first time that I’ve demonstrated low level, low frequency measurements with a Siglent DSO.

That is not the issue. In some cases the signal coming into the oscilloscope has a lot of noise in frequency bands that you are not interested in. It is very handy if the oscilloscope can do digital filtering on the signal to get rid of those unwanted frequencies. It is one of the reasons that I hang on to my GW Instek DSO. Digital filtering is a very handy feature if you develop digital signal processing applications; you can use the filtering in the DSO to get a feel of how well (or not) a signal will clean up in the digital domain.

[RBBVNL9]

This setting alters the function of the horizontal position knob, and everything is labelled correctly.

Thanks for the response, will soon dig deeper into that.

Can't help though to think that even if there is no mistake, this could all be much more intuitive. Leaving out on the screen the word fixed for the Fixed Delay mode and the Fixed Position mode creates unnecessary confusion. (I mean, if I read Position on a menu item then I kind of expect that here I can change the position. if I read Fixed position then I understand I cannot change the position...)

(And we do have seen SDS screen interface elements being accidentally switched in earlier firmware versions, see the above thread.)

But thanks again.

[Performa01]

Can't help though to think that even if there is no mistake, this could all be much more intuitive. Leaving out on the screen the word fixed for the Fixed Delay mode and the Fixed Position mode creates unnecessary confusion. (I mean, if I read Position on a menu item then I kind of expect that here I can change the position. if I read Fixed position then I understand I cannot change the position...)

Either the delay or the position can remain unchanged (= stay fixed) when the timebase is changed.

With fixed delay, the trigger position wil change according to the timebase.
With fixed position, the delay has to change according to the timebase.

Only exception: if the reference position is at 50 % and the delay is zero. In this case neither of them changes, regardless what timebase is used.

[IAmBack]

You can search as long as you could, you won´t find it...
None of the siglent models have these functions and I´ve added them to my wishlist "long time ago" too.

Pity.
Measuring low level, low frequency signals was (almost) impossible on Siglent due to hf excessive noise. Rigol did it without a problem. Even it's noisy front-end was not a problem.
Well, at last I have good excuse for not selling my second, sorry, third... Sorry. Just not selling this little scope.

You’re not serious, are you?

Siglent’s SDS2000X Plus of all things should not be able to measure low level low frequency signals (within the constraints of a general purpose oscilloscope), whereas a noisy Rigol is? And the excellent HF noise of the Siglent, which is somewhere between 2.4 and 3.5 nV/sqrt(Hz) should be a problem for LF measurements?

It’s not the first time that I’ve demonstrated low level, low frequency measurements with a Siglent DSO.

There are so many measures to ensure proper measurements under challenging conditions, including the trigger noise rejection function and HF-rejection coupling.

For the acquisition we have 10 bits mode, 20 MHz bandwidth limiter and average and ERES math functions. ERES is a lowpass filter by the way.

In the attached screenshot you can see a 10 Hz, 1.1 mVpp sinewave directly captured with 10 bits and 20 MHz bandwidth limit. Perfectly usable already, no further measures required. Is that not low frequency low level? Can you demonstrate how the Rigol does it so much better?

But there are two additional math traces. F1 is ERES 3.0, boosting the total resolution up to 16 bits. By limiting the record length to only 200 kpts the ERES lowpass has a corner frequency of just 7 kHz. Since its not the HF noise, but the 1/f noise that is a problem with all general purpose oscilloscopes, we still see some significant LF noise at the sensitivity of 500 µV/div. The measurements are pretty close, so neither the resolution enhancement nor the lowpass filter was really required.

F2 shows the result of 16x averaging. Since this is a static signal, it is the more effective measure, because it also reduces the LF noise. Still not a huge difference.

Finally it would be possible to combine ERES with averaging in a single math trace by means of the formula editor.

SDS2354X Plus_1mVpp_10Hz_200kpts(ERES7kHz)

Thank You for Your input!
I'm describing below what happened, and why I would like to have filters.
I've set minimal amplitude (2mV pk-pk) @ 1kHz on SDG2042x. This signal was connected to the input of the transformer with ratio about 1:1. There was a reason to keep amplitude of test signal low. The signal on the output was "enriched" with the spikes from a different psu-s around, therefore syncing was troublesome. I tried to average signal, but it started to... dissapear (as syncing was unstable due to "spikes", averaging was approaching to the value of 0). Limiting input bandwith to 20M didn't helped. I was thinking about using ERES, but unfortunatelly I'm not as familiar with my scope as I wish to be, so limiting memory depth wouldn't be solution I might want to try. Thank You for this trick!!!

On the DS1054 I turned math with lpf, set filter's bw to 3kHz and it was done.

[Performa01]

In some cases the signal coming into the oscilloscope has a lot of noise in frequency bands that you are not interested in. It is very handy if the oscilloscope can do digital filtering on the signal to get rid of those unwanted frequencies. It is one of the reasons that I hang on to my GW Instek DSO. Digital filtering is a very handy feature if you develop digital signal processing applications; you can use the filtering in the DSO to get a feel of how well (or not) a signal will clean up in the digital domain.

I've never said that digital filters can't be useful. Yet when someone complains about"HF noise", then we need a lowpass, right? Consequently I've listed the appropriate features to limit the bandwidth (10-bit mode, bandwidth limit, ERES math-function).

I've also never said that we might not get a filter package eventually. But then folks will most likely complain if they cannot get a 20 kHz lowpass at 1 GSa/s sample rate.

[bdunham7]

On the DS1054 I turned math with lpf, set filter's bw to 3kHz and it was done.

It sounds like the issue here is getting a stable trigger and I'm not seeing how LPF in a MATH function would help that.  Why/how did the DS1054 get a stable trigger when the other scopes didn't?  Or did you just use a single shot?

[Performa01]

Thank You for Your input!
I'm describing below what happened, and why I would like to have filters.
I've set minimal amplitude (2mV pk-pk) @ 1kHz on SDG2042x. This signal was connected to the input of the transformer with ratio about 1:1. There was a reason to keep amplitude of test signal low. The signal on the output was "enriched" with the spikes from a different psu-s around, therefore syncing was troublesome. I tried to average signal, but it started to... dissapear (as syncing was unstable due to "spikes", averaging was approaching to the value of 0). Limiting input bandwith to 20M didn't helped. I was thinking about using ERES, but unfortunatelly I'm not as familiar with my scope as I wish to be, so limiting memory depth wouldn't be solution I might want to try. Thank You for this trick!!!

On the DS1054 I turned math with lpf, set filter's bw to 3kHz and it was done.

The user manual UM0102XP-E01B, on page 209, contains a table that lists how to calculate the ERES bandwidth from the number of bits and the sample rate.

With deep memory, the sample rate remains pretty constant of a wide range of horizontal timebase settings, but at slower timebases and by limiting the max. memory in the Acquisition menu you can get an appropriate sample rate for your timebase. A future firware might bring a more convenient constant sample rate setting exactly for these purposes (the SDS6000 already has it).

Even a dedicated filter package will need such tricks, because ressources go through the roof if you want low frequency, high resolution at still high sample rates. Try looking at just the audio band using even an 1 Mpts FFT at 2 GSa/s effective FFT sample rate. And then 1 Mpts certainly isn't an option for a realtime DSP filter...

[nctnico]

In some cases the signal coming into the oscilloscope has a lot of noise in frequency bands that you are not interested in. It is very handy if the oscilloscope can do digital filtering on the signal to get rid of those unwanted frequencies. It is one of the reasons that I hang on to my GW Instek DSO. Digital filtering is a very handy feature if you develop digital signal processing applications; you can use the filtering in the DSO to get a feel of how well (or not) a signal will clean up in the digital domain.

I've never said that digital filters can't be useful. Yet when someone complains about"HF noise", then we need a lowpass, right? Consequently I've listed the appropriate features to limit the bandwidth (10-bit mode, bandwidth limit, ERES math-function).

I've also never said that we might not get a filter package eventually. But then folks will most likely complain if they cannot get a 20 kHz lowpass at 1 GSa/s sample rate.

You are not understanding the use case here. My GW Instek can low-pass filter to less than 20kHz with 1Gs/s input data just fine... For a project I did a couple of years ago I had a lot of noise coming from a circut at around 150kHz (nothing to do about that due to the nature of the circuit) but I needed to see signals in the several kHz range that got buried in the noise (edit: well, not noise perse but non interesting content in a different frequency band). In such cases there is no other way than to use filtering and it is extremely handy if the DSO can do that digitally (adjustable). In the end Eres and bandwidth limiting only get you so far because the unwanted content can alias back into your signal with lower samplerates; the minimum samplerate has to be high enough to meet nyquist for the signal content you want to get rid of otherwise it will alias. And there may also be cases where a highpass or bandpass filter come in very handy. Think about protocols that are modulated onto mains.

Edit: added some clarifications; replace 'noise' by 'unwanted signal content'.

[mawyatt]

Think having selectable/settable digital filters of various types would be a great asset to the Siglent line of DSOs. In addition to the practical value in the field and lab, the value for educational purposes would be tremendous, where students could "see" in real time the effects of various analog approximations (IIR) and digital (FIR) filters on different analog input signals

Maybe someone from Siglent is listening 

Best,

[RBBVNL9]

Think having selectable/settable digital filters of various types would be a great asset to the Siglent line of DSOs.

Fairly recently, R&S added various digital filters to their RTB series by means of a firmware update.
They have proven quite useful to me...

Maybe someone from Siglent is listening 

Hope so!

[bdunham7]

You are not understanding the use case here. My GW Instek can low-pass filter to less than 20kHz with 1Gs/s input data just fine...

Is that filtering pre or post-trigger?  IOW, can it prevent triggering on HF spikes?

I agree that this would be a very useful feature if properly implemented, and at first glance I don't think it would be particularly difficult.  I don't know about the computational resources needed to do it in real time so as to mimic an analog front end filter.  I have high-impedance 10:1 analog front end filters that go as low as 4kHz, they're fairly easy to make.  Being able to just dial those in and get the exact same function would be quite useful.

[IAmBack]

On the DS1054 I turned math with lpf, set filter's bw to 3kHz and it was done.

It sounds like the issue here is getting a stable trigger and I'm not seeing how LPF in a MATH function would help that.  Why/how did the DS1054 get a stable trigger when the other scopes didn't?  Or did you just use a single shot?

No matter how stable triggering on 1054z was, I got reliable pk-pk measurement, which was what I wanted to get.

[IAmBack]

Thank You for Your input!
I'm describing below what happened, and why I would like to have filters.
I've set minimal amplitude (2mV pk-pk) @ 1kHz on SDG2042x. This signal was connected to the input of the transformer with ratio about 1:1. There was a reason to keep amplitude of test signal low. The signal on the output was "enriched" with the spikes from a different psu-s around, therefore syncing was troublesome. I tried to average signal, but it started to... dissapear (as syncing was unstable due to "spikes", averaging was approaching to the value of 0). Limiting input bandwith to 20M didn't helped. I was thinking about using ERES, but unfortunatelly I'm not as familiar with my scope as I wish to be, so limiting memory depth wouldn't be solution I might want to try. Thank You for this trick!!!

On the DS1054 I turned math with lpf, set filter's bw to 3kHz and it was done.

The user manual UM0102XP-E01B, on page 209, contains a table that lists how to calculate the ERES bandwidth from the number of bits and the sample rate.

With deep memory, the sample rate remains pretty constant of a wide range of horizontal timebase settings, but at slower timebases and by limiting the max. memory in the Acquisition menu you can get an appropriate sample rate for your timebase. A future firware might bring a more convenient constant sample rate setting exactly for these purposes (the SDS6000 already has it).

Even a dedicated filter package will need such tricks, because ressources go through the roof if you want low frequency, high resolution at still high sample rates. Try looking at just the audio band using even an 1 Mpts FFT at 2 GSa/s effective FFT sample rate. And then 1 Mpts certainly isn't an option for a realtime DSP filter...

Ok, but what if I would like to eliminate something from low-band side? Eg. 50Hz hum?