At last, Siglent's SDS5054X touchscreen DSO...

[Performa01]

Here’s a demonstration how search across the history works on the SDS5000X with FW 0.8.2R1.

Look at the first screenshot:


SDS5104X_PRBS_10Mbps_Capture

Here we can see – well, nothing but a green wall

It is the 1ms capture of a 10Mbps PRBS-28 signal and let’s see how often we can find a positive 1.6µs wide pulse in that data stream.

Next step is to hit the [Stop] button and analyze the current record data. For this a search for positive pulses between 1.59 and 1.61µs is set up:


SDS5104X_PRBS_10Mbps_Search_Current

Search didn’t yield any result yet. The small note “Event Num 0” hints on zero hits for the current search. Now we have to enter History (we could have done that before already instead of hitting [Stop], but I didn’t want to proceed too fast):


SDS5104X_PRBS_10Mbps_Search_History_86

In the history, we ‘re still looking at the most recent acquisition frame and we already know that there is no hit. So we just activate the “Stop On Search Event” function and then press the reverse playback button. Within less than a second we find the one and only matching record. Please note that the playback speed can be freely defined – in this example it was set to 1ms per frame.


SDS5104X_PRBS_10Mbps_Search_History_24

The event got a white marker at the top of the trace display and the (end of the) event is centered on the screen. We can engage zoom in order to see the waveform and verify that we’ve indeed found a 1.6µs wide positive pulse.

If you look at these pictures, you’ll notice that we’ve captured a total of 86 frames of 5Mpts each in the history.

Record length is 5Mpts, so let’s do the math:
86 x 5Mpts = 430Mpts
This means that even though 250Mpts is huge already, we get even more for the history and also sequence recording, where the SDS5000X has low blind time and provides a maximum of  >500kWf/s.


Now let’s try something different. Here’s the 50ms capture of a 200Mbps PRBS-28 data stream and we’re looking for positive pulses 79 to 80ns wide:


SDS5104X_PRBS_200Mbps_Search_Overview

No history here, we’ve captured 250Mpts at once. Search works much faster in this case – it only takes a fraction of a second to find all 34 occurrences of the 80ns wide positive pulses in the record. Each of them has a white marker at the top of the display window. For closer inspection we need to engage zoom and then we use the [Navigate] function to find the individual search events:


SDS5104X_PRBS_200Mbps_Search_01

If we turn the event list on, then all events are displayed with their respective timestamps. We can scroll through the list and select any of the entries in order to have it centered in the zoom window. Here’s an example for event #21:


SDS5104X_PRBS_200Mbps_Search_Eventlist_21

Now let’s try this with segmented memory. Of course this is not a realistic test scenario; segmented memory is best suited for infrequent trigger events and of course I could set up one for the PRBS stream, but then the search event would most likely be found either in all segments or in none of them. That’s why I have to stick with the unspecific edge trigger.

History frame #60 contains the first hit, i.e. a positive pulse width of 80ns:


SDS5104X_PRBS_200Mbps_Search_History_01

History frame #3958 contains the next (2nd) hit:


SDS5104X_PRBS_200Mbps_Search_History_02

And finally, here’s the last (14th) hit in history frame #49154:


SDS5104X_PRBS_200Mbps_Search_History_14

Search through the segmented memory takes a lot longer than within a single record – we can search about 12500 history frames per second. Consequently, a search through the maximum of 100k history frames takes 8 seconds. So it’s not the memory size, but overhead of the list structure with 100k entries that takes its toll. Here we can see one of the reasons why e.g. a Keysight MSOX3000T can be so responsive: If the SDS5000X where limited to just 1000 history frames, it could search through the entire segmented memory within just 80ms …

[jemangedeslolos]

Hello,

Thank you for all your answers.
I haven't yet taken the time to test in depth my MSO5074.
The only criticism I can emit for now is that the user interface is slow ( compared to my SDS2204X ).
It is not a big deal but it is nice to use a responsive scope for everyday use.

I'm sure to not make a mistake buying an SDS5000X. I saw the extensive test from Performa01 and it seems that it is a solid plateform.
I have logic probe from my SDS2204X I can re-use so it is a good point.....but nobody seems to be interessted in buying my SDS2204X.
So there is the money problem....there is a 2000€ difference between MSO5074 and SDS5000X.

Im still a yound player so Im not as experimented as Performa01 or ntnico.
When looking at their scope test, I learned techniques that I didn't know before....
95% of my job is playing with high speed digital signal and low level analog signal from sensor but I don't know what project I will work on in 2 years

Serial decoding and triggering, deep memory, FFT and a good analog front end are important for me.
If I can have a touch screen and a silent and responsive scope I will be very happy.
I'm interested in the SVA1000X for the EMI pre compliance measurement kit too because for the first time, I will design a product that need to meet standards.
Maybe the SDS5000X can offer basic EMI testing that MSO5000 can't and allows me not to buy the SVA1000X ?

[bugi]

Search through the segmented memory takes a lot longer than within a single record – we can search about 12500 history frames per second. Consequently, a search through the maximum of 100k history frames takes 8 seconds. So it’s not the memory size, but overhead of the list structure with 100k entries that takes its toll. Here we can see one of the reasons why e.g. a Keysight MSOX3000T can be so responsive: If the SDS5000X where limited to just 1000 history frames, it could search through the entire segmented memory within just 80ms …

Hmm.. I may be lacking some background info about the process of searching matches within sample data between single record vs. segmented stuff.. but for me, the way I think it should work, the overhead of having separate frames should add negligible overhead (as long as the ratio between frames and total samples is sane, not like 10 samples per frame), and this kind of slowdown smells like bad coding. E.g. the array/list access being unnecessarily deep inside nested loops, or doing unnecessary display updates about the frames as the search keeps going (a bit like the difference of searching matches from a file with vs. without writing the contents of the file while doing it, orders of magnitude slower to write it all), or similar.  Would be interesting to learn the reason of the current performance difference; either I learn something new, or Siglent developers get a chance to optimize the code better.

[Performa01]

Serial decoding and triggering, deep memory, FFT and a good analog front end are important for me.
If I can have a touch screen and a silent and responsive scope I will be very happy.
I'm interested in the SVA1000X for the EMI pre compliance measurement kit too because for the first time, I will design a product that need to meet standards.
Maybe the SDS5000X can offer basic EMI testing that MSO5000 can't and allows me not to buy the SVA1000X ?

If you work with analog sensors, then the low-noise frontend with 500µV/div sensitivity is certainly a bonus compared to the (true) 4mV/div of an MSO5000. Yes, there is a 200MHz bandwidth limit, but it doesn't seem like you're planning to probe ultralow signals in the UHF range anyway

The 2Mpts FFT is excellent already and there are several improvements planned for it in the future. A first step has been taken already, namely markers and peak list, which have just been introduced for the SDS1004X-E series. Here you can see the effect of the new platform: more than one year after introduction, the SDS1004X-E still gets nice new features added - to the benefit of all existing and future users.

As stated before, there is more to come with regard to the FFT, but we did not define an EMI precompliance test package and I don't think this is an oversight. EMI precompliance tests usually require 1GHz bandwidth (minimum), which an SDS5100X can deliver, but also a set of well defined resolution bandwidths, which might be difficult to maintain with a DSO FFT, where RBW is affected by so many factors and cannot be fine-tuned to a certain value.

Finally, EMC directives have been introduced some 30 years ago and back then engineers still performed pre compliance tests, using an ordinary analog spectrum analyzer without any software running on it. Only requirement was the availability of the standardized resolution bandwidths for this task.

The SDS2204X can be had for about €1.300,- (ex. tax) in the EU right now. So you cannot expect too much from selling yours anyway. But if you found your SDS2204X responsive, then you'd really love the SDS5000X because the excellent touch UI speeds operation up quite significantly. It is less noisy and the serial decoders are better implemented as well.

[Performa01]

Search through the segmented memory takes a lot longer than within a single record – we can search about 12500 history frames per second. Consequently, a search through the maximum of 100k history frames takes 8 seconds. So it’s not the memory size, but overhead of the list structure with 100k entries that takes its toll. Here we can see one of the reasons why e.g. a Keysight MSOX3000T can be so responsive: If the SDS5000X where limited to just 1000 history frames, it could search through the entire segmented memory within just 80ms …

Hmm.. I may be lacking some background info about the process of searching matches within sample data between single record vs. segmented stuff.. but for me, the way I think it should work, the overhead of having separate frames should add negligible overhead (as long as the ratio between frames and total samples is sane, not like 10 samples per frame), and this kind of slowdown smells like bad coding. E.g. the array/list access being unnecessarily deep inside nested loops, or doing unnecessary display updates about the frames as the search keeps going (a bit like the difference of searching matches from a file with vs. without writing the contents of the file while doing it, orders of magnitude slower to write it all), or similar.  Would be interesting to learn the reason of the current performance difference; either I learn something new, or Siglent developers get a chance to optimize the code better.

Navigation though History generally displays every single frame on the screen. This is pretty much like normal operation, so the speed cannot be much faster than the waveform update rate for the settings in use. It comes down to the number of samples per record that need to be displayed and the reconstruction/interpolation requirements, which was 2.5k points (and because of the high number of samples there was no need for sin(x)/x reconstruction, just linear interpolation) in this example at 50ns/div timebase. During normal operation, we get a waveform update rate of some 10.3kWfm/s with these settings, so history playback is even a bit faster than that.

Search through History is currently just a normal playback that stops when the search event was found.
Maybe we could change that and skip the screen update during search - I'll have to discuss this with R&D.

[Mr Nutts]

The 3000 is quite an old scope by now though. Over 10 years old.

Neither MDO3000 nor Keysight 3000T are that old. The MDO is I think from 2013 and the 3000T from 2015

The 3000t underlying hardware is the same as the A.

The X3000T hardware is based on the X4000A

And even the X3000A is not ten years old. In fact, none of the Infinivision X scopes are that old (I think the first Infinivision X came out in 2012, that's just 7 years)

[2N3055]

The X3000T hardware is based on the X4000A

That is correct.. 3000T IS basically 4000 with smaller screen. To the point that there are some leftover references to 4000 in 3000T user manual..
All the software options are the same, except that:
- 4000 is available also in 1,5GHz version that has ETS sampling then.
- it has 2 ch siggen as opposed to 1 on 3000T
- 2 USB ports
- While 3000T has full active probe interface, it doesn't have enough power for all of them and can't support connecting more probes at the same time, depending on power needed. 4000B can supply full 4 ch of active probes.
All else is pretty much the same.

Keysight Infiniivision 3000T is good and fast and stable and just works. It is also a platform that has some funny priorities. For instance I would have liked to have 8Mpoints at 500kWfms/s instead of  4Mpoints at 1MWfms/s. Or even 16Mpoints at 250kWfms/s. Or give us a way to choose.
It is also deliberately stripped down in features :
- No ETS, although 4000 has it. Not a showstopper, but useful sometimes. It's in there, deliberately disabled.
- No colour grading.... 350 USD scopes have it. Color grading with inverse palette is very useful to see rare events..
- No histogramming in any form.. Cmon, histograms are common and very useful. All the data is in the scope.

SDS5000X has no such artificial limits. All major manufacturers always put  advanced analysis features only on high bandwidth scopes, asking huge sums.
I hold high hopes that this "new Chinese wave" changes that. And with current B brands getting better every day, A brands will have to keep up. They already lost entry level scopes segment, and are on a way to lose lower mid segment if they don't keep up.
Some of them seem to have decided to give up on that segment (LeCroy is simply rebadging Siglent, so they have can have full catalog of products), Tektronix don't care, R&S is pretending not to care, but will soon probably stop with making anything less than RTB2000....
Keysight has manufacturing structure that could compete with B brands, but they are paranoid not to mess with their own product placement structure and nice profit margins they managed to keep so far capitalizing on strong company image. So it is questionable if they are willing to go hand to hand with B brands and make big changes in current lines. Like Tektronix, if they wan't to reinvent Infiniivision series, they need it all new, from 2000 to 6000.
But can't make it much different (loyal customers swear it's their favorite UI), they can't add more options and protocols (they already have  pretty much all of them), so all they can do now is add more sample memory which would mean new MegaZoom and wastly faster processor and FPGA on mainboard, because they have to keep it REALLY FAST, so it's no worse than the old one despite 100x more memory they would have to add..

So I don't see much happening with A brands soon. So at the moment, SDS5000X looks real promising.

[bugi]

Search through History is currently just a normal playback that stops when the search event was found.
Maybe we could change that and skip the screen update during search - I'll have to discuss this with R&D.

Hopefully not full screen freeze, i.e. UI should preferably still respond to touches (say, cancel the search) and show other events (if such are possible, e.g. over-voltage on a probe input should be shown immediately). And something to indicate that the search is progressing is still nice (say, a frame counter "1234/50000" and hit counter, which would not even need to be updated for every single frame processed, but e.g. 10 times per second).  A really nice way would be to do the search "behind the scenes" until the first hit is found, then immediately show that frame on the display, but continue looking for more hits. That way the user can already analyze the first hit while the rest is being searched, perhaps to realize the search conditions were incorrect and thus press cancel to stop wasting time (though hopefully that wasted time will be shorter anyway, due to speedup of the search when not continuously doing big updates on the screen).

[2N3055]

Search through the segmented memory takes a lot longer than within a single record – we can search about 12500 history frames per second. Consequently, a search through the maximum of 100k history frames takes 8 seconds. So it’s not the memory size, but overhead of the list structure with 100k entries that takes its toll. Here we can see one of the reasons why e.g. a Keysight MSOX3000T can be so responsive: If the SDS5000X where limited to just 1000 history frames, it could search through the entire segmented memory within just 80ms …

Hmm.. I may be lacking some background info about the process of searching matches within sample data between single record vs. segmented stuff.. but for me, the way I think it should work, the overhead of having separate frames should add negligible overhead (as long as the ratio between frames and total samples is sane, not like 10 samples per frame), and this kind of slowdown smells like bad coding. E.g. the array/list access being unnecessarily deep inside nested loops, or doing unnecessary display updates about the frames as the search keeps going (a bit like the difference of searching matches from a file with vs. without writing the contents of the file while doing it, orders of magnitude slower to write it all), or similar.  Would be interesting to learn the reason of the current performance difference; either I learn something new, or Siglent developers get a chance to optimize the code better.

Navigation though History generally displays every single frame on the screen. This is pretty much like normal operation, so the speed cannot be much faster than the waveform update rate for the settings in use. It comes down to the number of samples per record that need to be displayed and the reconstruction/interpolation requirements, which was 2.5k points (and because of the high number of samples there was no need for sin(x)/x reconstruction, just linear interpolation) in this example at 50ns/div timebase. During normal operation, we get a waveform update rate of some 10.3kWfm/s with these settings, so history playback is even a bit faster than that.

Search through History is currently just a normal playback that stops when the search event was found.
Maybe we could change that and skip the screen update during search - I'll have to discuss this with R&D.

Keysight shows only progress bar while analysing segments, and it takes few seconds despite two orders of magnitude smaller memory.
I don't think 8 seconds for going through 400Ms of memory is that slow.  Faster is always better, but it is already faster than Keysight 3000T for that, comparatively.
I would put priority to complete search trough segments for protocol decodes. That is a killer feature.

[rf-loop]

Search through History is currently just a normal playback that stops when the search event was found.
Maybe we could change that and skip the screen update during search - I'll have to discuss this with R&D.

Hopefully not full screen freeze, i.e. UI should preferably still respond to touches (say, cancel the search) and show other events (if such are possible, e.g. over-voltage on a probe input should be shown immediately). And something to indicate that the search is progressing is still nice (say, a frame counter "1234/50000" and hit counter, which would not even need to be updated for every single frame processed, but e.g. 10 times per second).  A really nice way would be to do the search "behind the scenes" until the first hit is found, then immediately show that frame on the display, but continue looking for more hits. That way the user can already analyze the first hit while the rest is being searched, perhaps to realize the search conditions were incorrect and thus press cancel to stop wasting time (though hopefully that wasted time will be shorter anyway, due to speedup of the search when not continuously doing big updates on the screen).

Did you note "History".  Searching in History means searching from wfm history buffer (independent of how it is captured, in normal run when it is always saving in backround or using fast sequence mode) and as far as I know this history memory we can analyze only when scope is stopped - except if SDS5kX changes all....

[JPortici]

SDS5000X has no such artificial limits. All major manufacturers always put  advanced analysis features only on high bandwidth scopes, asking huge sums.

And that's because the 5000X IS the most advanced instrument from siglent available today. It makes complete sense to enchance it as much as possible

[2N3055]

SDS5000X has no such artificial limits. All major manufacturers always put  advanced analysis features only on high bandwidth scopes, asking huge sums.

And that's because the 5000X IS the most advanced instrument from siglent available today. It makes complete sense to enchance it as much as possible

Exactly!!

We are at the same point as with Japanese products many years ago. Best model (then very cheap) Honda had better equipment, better performance and better reliability than cheapest (still much more expensive than Honda) car from premium manufacturer, that had no equipment, was slow and not ver< reliable.... Same was with Yamaha and Ibanez musical instruments at the beginning..

Rigol chipset is more powerful than Keysight's Megazoom IV. But that is not the whole scope. I think Rigol made a mistake using Keysight as a model. Because of that Rigol's U/I is not very logical, and is limited. It would have been better if they took R&S or LeCroy as an inspiration, as those are U/I concepts made for touch...
That is why Siglent feels so much better now, because they realized modern scope is all about this layer between A/D converters and users, and not about chasing some hardware specifications.

 

[bugi]

Search through History is currently just a normal playback that stops when the search event was found.
Maybe we could change that and skip the screen update during search - I'll have to discuss this with R&D.

Hopefully not full screen freeze, i.e. UI should preferably still respond to touches (say, cancel the search) and show other events (if such are possible, e.g. over-voltage on a probe input should be shown immediately). And something to indicate that the search is progressing is still nice (say, a frame counter "1234/50000" and hit counter, which would not even need to be updated for every single frame processed, but e.g. 10 times per second).  A really nice way would be to do the search "behind the scenes" until the first hit is found, then immediately show that frame on the display, but continue looking for more hits. That way the user can already analyze the first hit while the rest is being searched, perhaps to realize the search conditions were incorrect and thus press cancel to stop wasting time (though hopefully that wasted time will be shorter anyway, due to speedup of the search when not continuously doing big updates on the screen).

Did you note "History".  Searching in History means searching from wfm history buffer (independent of how it is captured, in normal run when it is always saving in backround or using fast sequence mode) and as far as I know this history memory we can analyze only when scope is stopped - except if SDS5kX changes all....

I didn't notice that "history", but I think I was still thinking the appropriate mode of operation. I'm assuming with "when scope is stopped" you mean that the scope signal inputs are not being recorded/processed, but e.g. UI could still be operated.

While going back in the thread trying to find out what sort computation ICs they use (found onle a rumor/mention of zynq for the main CPU), I noticed JPortici wrote a while ago that "UI is always responsive. The trace will take some time to update during high memory captures at low time/div, or when doing FFT at 2MPts at some time/div settings, but that's to be expected because it phisically takes some time to acquire the waveform."
... which makes me think I don't need to worry, Siglent seems to have learned this particular stuff and a trace not being updated is not a problem as long as the UI otherwise keeps responsive. And if the main SoC is indeed a Zynq, it is definitely capable of doing multi-threading etc. to keep UI and data processing nicely asynchronous, should the software be done properly.

[Performa01]

Search through History is currently just a normal playback that stops when the search event was found.
Maybe we could change that and skip the screen update during search - I'll have to discuss this with R&D.

Hopefully not full screen freeze, i.e. UI should preferably still respond to touches (say, cancel the search) and show other events (if such are possible, e.g. over-voltage on a probe input should be shown immediately). And something to indicate that the search is progressing is still nice (say, a frame counter "1234/50000" and hit counter, which would not even need to be updated for every single frame processed, but e.g. 10 times per second).  A really nice way would be to do the search "behind the scenes" until the first hit is found, then immediately show that frame on the display, but continue looking for more hits. That way the user can already analyze the first hit while the rest is being searched, perhaps to realize the search conditions were incorrect and thus press cancel to stop wasting time (though hopefully that wasted time will be shorter anyway, due to speedup of the search when not continuously doing big updates on the screen).

We already have that for Sequence mode recording. Screen waveform update can take anything between 0.4s to 26.5s, depending on the settings and a progress bar is shown. Yet we can cancel sequence recording anytime by pressing [Stop] or even switching Sequence mode off on the touch UI.

I think that “background search” – while certainly a charming approach – would take matters a little too far. Without the screen update, I’d expect the search being an order of magnitude faster and I just cannot believe any user would be so desperate and unable to wait for a second or two until the next search event is found.

Keysight shows only progress bar while analysing segments, and it takes few seconds despite two orders of magnitude smaller memory.
I don't think 8 seconds for going through 400Ms of memory is that slow.  Faster is always better, but it is already faster than Keysight 3000T for that, comparatively.
I would put priority to complete search trough segments for protocol decodes. That is a killer feature.

Thanks for clearing this up. Even though I do have access to both Keysight MSOX3000A and 3000T at work, I rarely have the time to play with them. For my job, a Picoscope MSO is much better suited, so this is what I have on my desk all the time.

I also don’t think that having to wait for 8 seconds (worst case, if no hit is found) is too much asked, but then I have an open (low priority!) request to expand the number of history frames even more, so this topic might gain relevance some day.

With regard to the search for serial trigger conditions, it’s on the list, but not with high priority right now. Since you’re strongly advocating that feature, I’ll do my best to push it a little

Did you note "History".  Searching in History means searching from wfm history buffer (independent of how it is captured, in normal run when it is always saving in backround or using fast sequence mode) and as far as I know this history memory we can analyze only when scope is stopped - except if SDS5kX changes all....

You are absolutely correct. Whenever you enter History mode, the scope automatically changes to Stop mode. During Run, the History acts as a circular buffer that gets continuously updated, hence there is absolutely no point in attempting to analyze anything there.

SDS5000X has no such artificial limits. All major manufacturers always put  advanced analysis features only on high bandwidth scopes, asking huge sums.

And that's because the 5000X IS the most advanced instrument from siglent available today. It makes complete sense to enchance it as much as possible

Yes, exactly. This platform is continuously developed to match all the requirements of the final SDS5000X and then even beyond that. All the current and future models based on this platform can benefit from that, as some of the improvements might trickle down even to lower end models – or even get prototyped there first, as we can currently see with FFT markers and Bode Plot II.

[nctnico]

Just wondering: is it possible to set the SDS5000 to a fixed (selectable) memory depth?

[JPortici]

No, it's the same as the other siglent (and other scopes)
You select the maximum memory depth. Then, according to the selected timebase the optimal memory/samplerate settings will be used in order to have 10 divisions worth of data, adjusting the samplerate in order to have the highest number of samples possible

[nctnico]

No, it's the same as the other siglent (and other scopes)
You select the maximum memory depth. Then, according to the selected timebase the optimal memory/samplerate settings will be used in order to have 10 divisions worth of data, adjusting the samplerate in order to have the highest number of samples possible

OK, that pretty much sucks then. In many cases I want to be able to zoom out to see what is beyond the screen when something interesting has appeared. It saves from needing to adjusting the timebase all the time (and re-measure if I forgot it). My MO is to capture large amounts of data and then look for interesting stuff instead of doing small acquisitions with targetted trigger settings. The latter is A) tedious and time consuming and B) an anomaly (caused by something earlier on) may not show up again the same way. The SDS5000 wouldn't work for me if it can't have a fixed memory depth setting regardless of the time/div setting.

[JPortici]

yes yes yes i know. Let's wait for the usual "but you're using it wrong".
Then again, it hasn't been an issue to me. Current samplerate and memory depth is shown on the bottom right and to me that's fine. I'm used to this sort of behaviour because i mostly use scopes that work this way

[jemangedeslolos]

Thank you very much, but asking my question on a SDS5000X topic is not a very clever thing to do for my money 

I priced down my SDS2204X with full option at 800€ without the SPL2016. I don't know if it a reasonable price or not.

[bugi]

I priced down my SDS2204X with full option at 800€ without the SPL2016. I don't know if it a reasonable price or not.

Considering what the scope manufacturers themselves ask for some stuff (e.g. options that are basically same between series, but hugely different price when listed on a pricier series), anything is reasonable, it is just a matter of point of view (and/or marketing). Or, as more commonly said, (non-literal translation, I wonder if there is an English saying for this) "stupid is not who asks (a high amount of money), but the one who pays".

[maginnovision]

The 3000 is quite an old scope by now though. Over 10 years old.

Neither MDO3000 nor Keysight 3000T are that old. The MDO is I think from 2013 and the 3000T from 2015

The 3000t underlying hardware is the same as the A.

The X3000T hardware is based on the X4000A

And even the X3000A is not ten years old. In fact, none of the Infinivision X scopes are that old (I think the first Infinivision X came out in 2012, that's just 7 years)

Sure, so it's based on 6-7 year old hardware. My only point was it's significantly older than the sds5000, once it's updated they'll probably get away from magnification from 4mV/div.

[jemangedeslolos]

I have a last question 

It is regarding knob quality....the ones on the SDS2000X are a little cheap ( no detents ones ).
Is there an improvement at this level regarding the SDS5000X ?

It may seem stupid as a question but it is important for me when I buy equipment of this price that the global quality is here.

[tautech]

I have a last question 

It is regarding knob quality....the ones on the SDS2000X are a little cheap ( no detents ones ).
Is there an improvement at this level regarding the SDS5000X ?

It may seem stupid as a question but it is important for me when I buy equipment of this price that the global quality is here.

Same.

IIRC the multipurpose encoder is still not detented although it matters far less as in most operations the touch display is somewhat easier and faster to use.
My SDS5kX first impressions:
https://www.eevblog.com/forum/testgear/at-last-siglent_s-sds5054x-touchscreen/msg2426481/#msg2426481

[JPortici]

The only knods with detent are the horizontal and vertical scale. all others (position/level) are without detent.
All knobs can be pressed and have their function (select/zoom/zero/fine/50%) but to press the button while rotating them you must have to be a carefree elephant

[bugi]

In Dave's review video (), around 13:15 and 47:23, he mentions about knob behavior. Seems Siglent still hasn't figured out how to do the rotation input handling properly (i.e. looks a bit similar to SDS2000X after the firmware improvements, i.e. usable, but still not nice).  Couple years of time to improve it (or even redo from scratch) and still at level of embedded development basics course exercise, barely passed   (And no, touchscreen is not a valid excuse, because for many parameters knobs win in usability 10-0. Or would, if working nicely.)

PS. How does one have link to a youtube video without the forum turning it into a preview image?