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 …
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 ?
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.
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
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.
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.
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).
SDS5000X has no such artificial limits. All major manufacturers always put advanced analysis features only on high bandwidth scopes, asking huge sums.
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
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....
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).
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.
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....
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
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
I priced down my SDS2204X with full option at 800€ without the SPL2016. I don't know if it a reasonable price or not.
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)
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.