Siglent SDS2000X Plus

[Martin72]

It is just displayed as if it were a good message.

First, it would be good when you post it in the bug thread.
Second, what does the other scopes do in this case ? Showing nothing or a failure ?

[RBBVNL9]

First, it would be good when you post it in the bug thread.

Will do. But I first want to do some more testing.

Second, what does the other scopes do in this case ? Showing nothing or a failure ?

The attached screenprints shows three scopes that are offered the same LIN signal with the wrong polarity. (In all three cases I made the polarity wrong in the channel setting, so all three show the same trace).

• The RTB shows it is attempting to decode, see unusually long break fields (because of reversed polarity this are in reality the idle times) and shows data error in its table view. No attempt to show a decoded message.
• The DSOX also shows it is attempting to decode. Shows "THM" (manual says: "If the header exceeds the length specified in the standard, THM will appear red.") No attempt to show a decoded message.
• The SDS, as mentioned before, is showing as if it successfully decoded a message, and shows no errors. But the content is actually garbage: packet ID, data length and payload are not existing in the input signal.

The "shows no errors" on the SDS is something with begs some further investigation. Will do that in a separate post to prevent confusion.

[RBBVNL9]

My tests are bringing me to another question. Related, but not about 'reverse polarity'.

So, I take a 'good polarity' LIN 2.0 9.6kbps signal. I decode it on the three scopes, and I get, as it should, exactly the three same messages. Message ID, packet length, payload, it is all identical for this set of four packets. (those that convert HEX into ASCII will see where this signal came from ;-)

Now, intentional or not, my LIN  signal has various errors in it. And I want to investigate how the three oscilloscopes provide error warnings. The results are attached as three screenprints.

• The RTB, when set to LIN2.x, sees a checksum error in the first packet, a parity error and checksum in the second, and a sync and checksum error in the third package, and a checksum error in the fourth. New screenprint identified as NEW.
• The DSOX when set to LIN2.x, sees a checksum error in the first packet, a parity error and checksum error in the second, and a sync error in the third package, plus a checksum error in the fourth packet.
• The PicoScope, for which no LIN version can be selected, also see various errors (see screenshot for details) New screenprint identified as NEW.

Life is not perfect, they do not see precisely the same errors (partly because the DSOX and PicoScope can show multiple errors in a single packet). But all the scopes clearly show there are a number of errors going on here. 
The RTB and DSOX are in full agreement. The PicoScope picks up several but not all errors.

But the SDS shows... no errors at all!?! 

For instance, the RTB, DSOX and PicoScope all agree that the F03 checksum on the first package is wrong. But the SDS is showing this checksum as if its fine...

Mmm. Is it perhaps the case that the SDS is simply not showing any serial decode errors (LIN? other protocols?) at all in its telegram or list screen?

Trying to see whether the SDS is aware of any of these errors, I tried to find out by serial triggering on them. Results are in three additional screenprints. Interestingly,

• Additional screenprint 1 shows that via serial trigger, shows the SDS knows that packet 1 has a checksum error (unfortunately you need to identify the frame ID and message length first to find out, but it is found).
• Additional screenprint 2 shows that via serial trigger, the SDS knows that packet 2 indeed has a parity error
• Additional screenprint 3 shows that via serial trigger, the SDS knows that packet 3 indeed has a sync error

So, the SDS knows these errors are there (because it can trigger on them), but it is not showing these errors in the regular screen.

What do others think? Is there any way to see these errors (in the telegram or list field) which I overlook? Is this a bug? Is this a design choice (if yes, a choice that does not make me happy - I want to see that a checksum is wrong, that an error occurs).

[RBBVNL9]

Hi PeDre,

I had already looked into the CAN protocol versions and their implications on my observations - but not enough because I found new things after being promoted by you. And you properly deduced this is the LIN signal coming from the RTB ;-)

But I guess the LIN signal from the RTB2000 is version 1

The protocol version of this LIN signal is not documented. But I think it's LIN2.x, not LIN 1.3. Why I think so? If I try to decode it as LIN1.3 on the DSOX it fails altogether. When I decode it as LIN2.x on the DSOX it all works.

If you set to version 2 in the trigger setup, you will also get checksum errors in the 4th packet.

True. And I now also see the RTB (too) can show multiple errors for a single packet. Nice. So the DSOX and RTB are in total agreement about all detected errors. Wil update my previous post to reflect that.

The DSOX and PicoScope will detect the checksum error correctly if they use LIN version 2

For the DSOX that is true and was already the case in the earlier screenprint.
For the PicoScope it's a bit more complex (and I also updated the screenprint in my previous post, I made the display slightly too short and the rightmost value was missing as the decoder was instructed to decode the Current Buffer only). Anyway, the bottom line is that one cannot select the LIN protocol version for the PicoScope decoder (correct me if I am wrong). The PicoScope sees the errors in the first two packets but not in the third and fourth.

[vad]

My 1-week old SDS2104X Plus no longer works. It hangs while booting (see attached picture). Any idea how to troubleshoot it, before calling Siglent on Monday?

[tautech]

My 1-week old SDS2104X Plus no longer works. It hangs while booting (see attached picture). Any idea how to troubleshoot it, before calling Siglent on Monday?

Sure, flick us a PM with your email...... ve have the tools !

Boot freezes are very rare in 2kX+, so rare that only one other that I know of has happened and Siglent had to formulate the recovery package for us to help another member here.
They asked that the SN# of any boot freeze unit be sent to them so to analyze if there was a batch of units that had this problem.

I sure like it when they are so focused on heading off problems. 

[RBBVNL9]

First, it would be good when you post it in the bug thread.

Having done some more testing, I now reported the issue, as well described and documented as I could, in the Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests thread.

[vad]

Sure, flick us a PM with your email...... ve have the tools !

Thank you. I've sent the PM.

[tautech]

Sure, flick us a PM with your email...... ve have the tools !

Thank you. I've sent the PM.

You have mail !

[vad]

Sure, flick us a PM with your email...... ve have the tools !

Thank you. I've sent the PM.

You have mail !

Thank you tautech! The steps helped. I managed to recover after several attempts, and I think I figured out the root cause.
Setting channel units to A and setting custom probe attenuation ratio (to 0.025747:1, AFAIR) caused the freeze after reboot. I was using the latest firmware V1.3.9R6.
Resetting C1 channel settings back to V and 1:1 resolved the issue.

[voltsandjolts]

I don't need another scope but this Siglent has me intrigued, it does seems like a very capable scope for the money.
I know this is frivolous but the front panel design puts me off somewhat, the knobs in particular remind me of the muppets show!



The incoming 12-bitter SDS2000X HD however looks great, maybe I'll have to spend twice the money and get that instead.

[pascal_sweden]

[blurpy]

I asked my local distributor about the SP2035A probes, and was told that the European prices (updated this January) are still not adjusted
Waiting to hear back from Siglent about this being an error or if Europe is excluded from the new lower price.

Good news Turns out that Siglent Europe forgot to update the price, so we get the new price as well.

No stock though, so don't know when I'll get hold of any.

[Angus]

I did some further experiments with the scope during the weekend. I build a step generator and did some measurements on it. I noticed that interpolation sinc and x give significantly different results in terms of waveform jitter. (or to say what looks like waveform jitter).
I used to have the oscilloscope set to x-interpolation in the past with vectors on to avoid possible artifacts.

I have attached screenshots showing the results. Maybe someone can explain to me why x-interpolation with vectors on suggests more serious jitter than the other settings. What would be your fevorite setting and what measurement in my attachment should I trust the most?

Thanks a lot in advance.


P.S.

I've just noticed that I obviously named sinc dots/lines wrong.

[rf-loop]

Note.
There is NO any interpolation when display mode is Dots!
Other words.
What ever interpolation you have selected,  x  or Sinc  it do not interpolate at all when display mode is Dots. Because there is only Dots, true sampled dots. How it and what it then interpolate. Even if it interpolate there is no place where put this interpolation result as long as user have selected display only ADC sampled dots.
Siglent display, in Dots display mode,  only true ADC samples without any interpolated "fake" dots between true Dots, just for avoid fooling user)

If you think what is interpolation,  is it really not clear why it looks different when use x or Sinc or raw dots. If it do not looks like it is example in your images then it is really broken.

With dots mode it need note of course that this is DPO (aka SPO) not conventional old school DSO.  If you do not want randomly interleaved dots in dots mode, turn it working like coinventional DSO. Just turn Acquisition from default Fast to Slow. Then it just acquire one sample buffer for one sequential TFT frame so you do not see randomly interleaved samples in one TFT frame (depending singal and scope other settings)

[Angus]

First thanks for the reply.
What happens when you do a screenshot to usb - if linear/dot and sinc/dot is supposed to be the same the signals and risetimes should aswell, correct?
I do not see any 'blurred' edge in dot mode so I thought that, maybe, linear interpolation shows the jitter by accident.
On the other hand rise-time between the two dot modes are different (without any blurs). I have really no idea what mode to trust the most.

I think this behaviour does not show on your machines?
Any ideas for further tests?


I've just checked: If I turn on dots there is a change in Waveform when I select between 'x' and 'Sinc'. That does not happen when in HiRes Mode but if in 8 bit it happens independant of bandwith.
'x' leads to slightly lower risetime.

[tautech]

First thanks for the reply.
What happens when you do a screenshot to usb - if linear/dot and sinc/dot is supposed to be the same the signals and risetimes should aswell, correct?
I do not see any 'blurred' edge in dot mode so I thought that, maybe, linear interpolation shows the jitter by accident.
On the other hand rise-time between the two dot modes are different (without any blurs). I have really no idea what mode to trust the most.

I think this behaviour does not show on your machines?
Any ideas for further tests?

Have a look at a Single capture to see a single line of sample points instead of the sum of wfps overlays.

[Performa01]

That's really basic stuff.

At 1 ns/div, we're looking at just 20 samples over the entire screen width. Of course, it makes a big difference which interpolation/reconstruction method is used, such as:

• x = linear interpolation, an early, primitive method, that only works reasonably well up to 1/10 of the sample rate. That would be 200 MHz @ 2 GSa/s, corresponding to some 1.75 ns rise time. No wonder we see a bit of a fuzzyness at a measured 1 ns rise time. X interpolation might still be the preferred method for displaying digital signals (pulses), as it avoids Gibbs pehenomenon. But again, only within the speed limits given above.
• sin(x)/x = sinc, this is the true reconstruction of the sampled signal and the prerequisite to make the sample theorem work. Now the highest signal frequency can be up to 1/2.5 of the sample rate, i.e. 800 MHz @ 2 GSa/s and we still get perfectly valid representations of the input signal. If this condition is violated, the reconstruction result might look funny and artificial.
• Dots mode. there is neither interpolation nor reconstruction, hence we always see the true signal - as long as the trigger data is valid, i.e. not disturbed because of aliasing. Thanks to the high trigger rate, we get a lot of acquisitions overlaid in one screen update, so we mostly see a near contiguous line even in dots display mode, as long as we are in Run. In Stop mode (or in History) we do not see more than the 20 dots per screen at 1 ns/div, obviously.

Sometimes folks need to be reminded that the highest signal frequency does not mean just the fundamental frequency. A square wave might have a fundamental frequency of only 10 MHz, but if the rise time is 1 ns, then we have significant signal content up to at least 600 MHz. We would use a DSO with at least 1 GHz bandwidth to analyze such signals.

[Angus]

there is neither interpolation nor reconstruction, hence we always see the true signal - as long as the trigger data is valid, i.e. not disturbed because of aliasing.

Performa01, ohhh so logical. Re-thinking what is going on is a good idea and your post made me. Thanks for that.  (I must admit I should not have struggled with these information)

However I still don't  get why there is a difference in dot-mode when you switch between sinc and x. Dot mode is Dot mode. Am I still missing something? Same signal, same Trigger settings, slightly different dotted waveform. I should (or to say will) further play with that.

[gf]

However I still don't  get why there is a difference in dot-mode when you switch between sinc and x.

Just a guess: The trigger still needs interpolation in order to determine the fractional sample position of the trigger point. I wonder whether it also honors the selected interpolation method. Possibly it does?
EDIT:The determined trigger position on the time axis affects of course how the points of the traces are stitched together.

[rf-loop]

That's really basic stuff.

At 1 ns/div, we're looking at just 20 samples over the entire screen width. Of course, it makes a big difference which interpolation/reconstruction method is used, such as:

• x = linear interpolation, an early, primitive method, that only works reasonably well up to 1/10 of the sample rate. That would be 200 MHz @ 2 GSa/s, corresponding to some 1.75 ns rise time. No wonder we see a bit of a fuzzyness at a measured 1 ns rise time. X interpolation might still be the preferred method for displaying digital signals (pulses), as it avoids Gibbs pehenomenon. But again, only within the speed limits given above.
• sin(x)/x = sinc, this is the true reconstruction of the sampled signal and the prerequisite to make the sample theorem work. Now the highest signal frequency can be up to 1/2.5 of the sample rate, i.e. 800 MHz @ 2 GSa/s and we still get perfectly valid representations of the input signal. If this condition is violated, the reconstruction result might look funny and artificial.
• Dots mode. there is neither interpolation nor reconstruction, hence we always see the true signal - as long as the trigger data is valid, i.e. not disturbed because of aliasing. Thanks to the high trigger rate, we get a lot of acquisitions overlaid in one screen update, so we mostly see a near contiguous line even in dots display mode, as long as we are in Run. In Stop mode (or in History) we do not see more than the 20 dots per screen at 1 ns/div, obviously.

Sometimes folks need to be reminded that the highest signal frequency does not mean just the fundamental frequency. A square wave might have a fundamental frequency of only 10 MHz, but if the rise time is 1 ns, then we have significant signal content up to at least 600 MHz. We would use a DSO with at least 1 GHz bandwidth to analyze such signals.

Some small addendums to Performa01 very exellent text.

x interpolation.
Even it is a primitive method, but it is also useful in some rare cases, at least temporarily. The example checks if the pulse overshoot / pre-shoot is based on the "fake" crossings produced by Sinc as "Gibb's ears". In some circumstances, when watching digital “1-0” type signals, it may even be nice to use x-interpolation so you don’t have to look at Gibb’s ears, they are sometimes confusing. (of course nowadays the scopes are so fast that Dots mode can be used without interpolation ... but sometimes there are so few samples that it is not easy to see visually ... so in these cases you can also try to check by swapping interpolation method - - what's best depends so much on the signal under test and what details we are interested)

Thanks to the high trigger rate, we get a lot of acquisitions overlaid in one screen update, so we mostly see a near contiguous line even in dots display mode, as long as we are in Run

.     ...if we use oscilloscope in fast acquisition mode  (what is default).

But some times we do not perhaps want acquisitions overlaid in one updated TFT frame when we are watching signal on screen. In some rare cases we perhaps want work as  with convential old school DSO.  Trig-capture-display...Trig-capture-display.... and so on, so we get displayed continuously "single shots" as long as scope is running mode and there is trig events.

This mode can find in Acquisition menu.  There is selection Fast/Slow.  Slow mode emulate this old school DSO (max 1wfm/1display update).


Naturally in Siglent scopes what have always bacround running history buffer we can stop scope and when we see overlaid many wfm's we can view each individual overlaid wfm on the screen separately and even time stamped. They are in the history buffer, each separately.

[Performa01]

However I still don't  get why there is a difference in dot-mode when you switch between sinc and x. Dot mode is Dot mode. Am I still missing something? Same signal, same Trigger settings, slightly different dotted waveform. I should (or to say will) further play with that.

At short time bases, where the screen cannot be filled with samples by just the genuine sample rate, i.e. less than some 1000 samples per record (below 50 ns/div @ 2 GSa/s), math and automatic measurements still need complete data without gaps. These data are constructed in a secondary screen buffer, using the interpolation method selected by the user.

Just for completeness: the choice of interpolation x versus reconstruction Sinc is only effective below 50 ns/div. It has absolutely no effect at slower timebase settings.

While the screen only shows the original samples as dots, the secondary buffer for math and measurements (and reference traces) is still updated in the background. This buffer only exists for fast time bases. For the slower ones, math and measurements gather the data directly from the sample buffer. The special handling also has the benefit of increasing the resolution of time measurements at these faster timebases - after all you can measure single digit picoseconds at 1 ns/div, even though the sample period is only 500 ps @ 2 GSa/s.

The update of this buffer takes some processing time. Calculation of linear interpolation (x) is faster than a sin(x)/x filter. The difference that you see in dots mode is because of the different update speed coming from a different trigger rate. The faster the update, the thicker and more solid the trace.

I've checked the situation with a 10 MHz square wave signal at 1 ns/div and 2 GSa/s and measured the waveform update rates:

Linear = X:        33.5 kHz
Sinc = sin(x)/x:   2.8 kHz

That's quite a difference in speed and makes for the huge difference in visual appearance in dots mode.
The difference will be much less at slower timebases such as 10 ns/div:

Linear = X:        63 kHz
Sinc = sin(x)/x:  14 kHz

And as mentioned before, the difference will disappear at 50 ns/div and slower, example 50 ns/div:

Linear = X:        120 kHz
Sinc = sin(x)/x:  120 kHz

[rf-loop]

However I still don't  get why there is a difference in dot-mode when you switch between sinc and x.

Just a guess: The trigger still needs interpolation in order to determine the fractional sample position of the trigger point. I wonder whether it also honors the selected interpolation method. Possibly it does?
EDIT:The determined trigger position on the time axis affects of course how the points of the traces are stitched together.

Both interpolations you see on the screen are totally and fully post processed in Siglent SPO (aka DPO) scopes.
Digital trigger engine is before sample memory just after ADC and full HW samplerate. Example if user see 10kSa/s on screen still trigger engine get example 1GSa/s full stream available before decimation.

You can capture using example dots mode... stop scope and after then turn Sinc or x  and switch between these and you can see trigger position stay perfectly enough in right place between real sample dots independent of which one post processed interpolation you select.
I am not sure what interpolation trigger engine is using but it must be in trigger engine because it need work always, independent of our setting for display waveform. Somehow I do not believe it change this interpolation method depending what user have selected for post process interpolation. I can guess what it is but better to shut up for avoid possible "alternative truth" spreading. 

[Angus]

 
Thank you guys!

[Angus]

Digital trigger engine is before sample memory just after ADC and full HW samplerate.

math and automatic measurements still need complete data without gaps. These data are constructed in a secondary screen buffer, using the interpolation method selected by the user.

I took a measurement with dots. Went to history and selected a frame. The scope remained in stop-mode all the time. So there is no data being updated. The ONLY parameter I changed was x/sinc.


1: dots are a direct representation of the sample values.

2: trigger depends on interpolation in some way. I agree that that won't be a good idea, but if it should happen, the raw data should only move in time.  Remember the scope already sampled; they should not move at all if triggering was done before sampling.

3:if interpolation method has its impact on mathematics and measurements only, the raw data in a frame should not move, because everything that happens with them is, well, visualization.

I think something is unlikely / does not make sense: why would the raw dots of a single frame change their position on screen when the scope is frozen and only that frame is shown? I totally agree with the explanations and assuumptions, but.... something is unlogical for me.

Is here someone from Siglent who could elaborate first hand? I hope I did not introduce myself as too dumb to answer


edit: I modified to hopefully better describe my point