SDS2000X Plus waveform update rate information

[AJ528]

Hello All,

I was browsing the massive Siglent SDS2000X Plus Thread, and I saw a post by rf-loop where they had a large table showing the waveform updates per second for other Siglent oscilloscopes under various conditions (the post on this page: https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/1725/).

I think a table like that is very useful, and I'm curious if something similar has been made for the SDS2000X Plus oscilloscope. If not, I'm thinking of making a simplified version of that table myself. But, before I do that, I wanted to see if something like that already exists. Does anybody know if that data already exists somewhere?

I don't think I can tag people, but I'm hoping rf-loop sees this. They certainly seem to have a precise test procedure to accurately measure this characteristic.

[rf-loop]

Hello All,

I was browsing the massive Siglent SDS2000X Plus Thread, and I saw a post by rf-loop where they had a large table showing the waveform updates per second for other Siglent oscilloscopes under various conditions (the post on this page: https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/1725/).

I think a table like that is very useful, and I'm curious if something similar has been made for the SDS2000X Plus oscilloscope. If not, I'm thinking of making a simplified version of that table myself. But, before I do that, I wanted to see if something like that already exists. Does anybody know if that data already exists somewhere?

I don't think I can tag people, but I'm hoping rf-loop sees this. They certainly seem to have a precise test procedure to accurately measure this characteristic.

NOTE: This table is NOT revised after last FW... and I can not do it until I get new SDS2000X Plus(perhaps next week, but I have no time for test it for this until some later. )
Do not blind trust this table, also I do not fully trust... but . It is perhaps  around ok but...
I will recheck it after I have again this model and time for it.

Read it with the caveat that there may be something to be corrected, i.e. it is not the official "truth".

Read it with the caveat that there may be something to be corrected, i.e. it is not the "truth".

[AJ528]

Hi rf-loop!

Thanks for the quick reply and providing your data! I totally understand that these may be rough measurements, and I won't take anything I see as gospel. That being said, this is a great starting point and certainly very informative. While looking this over, I did have a couple questions about this information.

First, why do some rows have a single measurement for the 4 columns, and others have 4 measurements? If there's a single measurement, does that mean the update rate was identical for all 4 conditions? Or is that just a single data point and you haven't had a chance to collect all the data for some of the "t/div" rows?

Second, why did you decide to change the frequency of the test signal as your timebase changed? Did you find it affected the update rate? I wouldn't expect that to impact the waveform update rate, so I'm surprised to see that was varied.

I don't think it should matter one way or the other, but do you remember if the trigger mode was set to "normal" or "auto" when you took this data?

Lastly, I'm surprised to see the update rate was affected by the interpolation mode when the scope was displaying dots. I would have guessed that, since no interpolation is occurring, it wouldn't matter what that setting is. I wonder what the code is doing behind the scenes...

[rf-loop]

Hi rf-loop!

Thanks for the quick reply and providing your data! I totally understand that these may be rough measurements, and I won't take anything I see as gospel. That being said, this is a great starting point and certainly very informative. While looking this over, I did have a couple questions about this information.

1)
First, why do some rows have a single measurement for the 4 columns, and others have 4 measurements? If there's a single measurement, does that mean the update rate was identical for all 4 conditions? Or is that just a single data point and you haven't had a chance to collect all the data for some of the "t/div" rows?

2)
Second, why did you decide to change the frequency of the test signal as your timebase changed? Did you find it affected the update rate? I wouldn't expect that to impact the waveform update rate, so I'm surprised to see that was varied.

3)
I don't think it should matter one way or the other, but do you remember if the trigger mode was set to "normal" or "auto" when you took this data?

4)
Lastly, I'm surprised to see the update rate was affected by the interpolation mode when the scope was displaying dots. I would have guessed that, since no interpolation is occurring, it wouldn't matter what that setting is. I wonder what the code is doing behind the scenes...

1.
Rows where is one value for 2 or 4 conditions, you can see there is combined columns. It means same value for these conditions. ( or difference is very insignificant)

2.
In some cases signal affect to speed (more or less). If I want look 10MHz signal usually I do not look it using 1ms/div  so I have selected even somehow usable freq for t/div. Test signal is not selected for best possible speed. Many things affect wfm/s speed... including signal figure. It  can somehow understand if think how intensity or color gradation is produced. It need some brute force. Also there is somehow two separate things in this process. Inside one wfm intensity some gradation and then sequential overlaid wfms intensity gradation. Think if there is 100k points data for one single capture (aka wfm). On the screen there is 1000 columns for this data. Every 100 sample need plot to one column and next 100 samples to next column... now if samples value is same they need plot to same "pixel"... (Siglent do not decimate data what is mapped for display)
Then come next waveform what is plotted to these same places on display and now... roughly said... how much these data collide on screen more intensity.
(difficult to explain using foreign language)   
And also, this all happen independent of display mode and what is interpolation)
If display refresh rate is 30Hz and we have 120kwfm/s speed it mean 3600 sequential acquisition data is mapped to one display frame with intensity gradation. And more, in final when it produce this image for display it still keep also all these acquisitions in memory with full data. (In history buffer)

3.
Trigger is Edge, Rising.  With these speeds it do not matter if trig is normal or auto because there is not so long pause between trigger even in signal that Auto trig start generate trig.

4.
It depends...
But think about it so that in every case signal displayed on screen need be on the screen so that trigger position is perfect. If sampling interval is example 1ns (1GSa/s) and we use 1ns/div Horizontal scale. Still if we do not draw line to display still we need somewhere fine interpolate  trigger position between real sample data points... Still you can see that also using dots mode trigger time axis position on screen is quite perfect.  Position is based to interpolation between individual samples. 1ns is long time... I do not remember what is fine positioning interval.. but when data sheet tell about trigger: Jitter CH1～CH4: <10 ps rms.  It means that fine interpolation between real samples need do very finely divided. I don't want to speculate or say anything about which part belongs deep in the "digital trigger engine" area between the ADC and memory and which is post-processed display positioning. Siglent will publish more in-depth information about the operating principle if it wishes to do so. Now there is no such public information.
But in every case, this process also need some processing brute forge and it can not happen without consuming time.
Yes, this would be a nice place for a dedicated ASIC, and ping pong acq. principle for speed but now there isn't... Buyers don't release enough money from their pockets for this.

After around 1 week is will try quick check if there is any major changes in table (latest FW latest HW)
If no major differences then new revised table later after suitable time for it. (Also it need note that this wfm/s speed

The importance of this speed should also not be exaggerated (still it is nonsense but no need over estimate). A modern oscilloscope has many other features that can reduce the importance of this speed. Very few people look for rare random distractions by looking at a screen. A person can do something wiser and entrust such work to a modern oscilloscope. It's worth remembering that Keysight, one of the wfm/s hypemen, is married to their old ASIC chip system, where the triggering is handled by an ancient analog sidepath trigger system, which is still pretty good at it. However, it does somewhat limit the triggers that can be harnessed for that bug hunt. In addition, oscilloscopes do many other things. I use it to analyze the signal in many ways. And many analyzes do not require a million wfm/s. Sometimes when you read Kysight wfm/s hyping advertisements, it feels like they have nothing else to do.

[AJ528]

Okay, I think I understand what you are saying. Test signal frequency can definitely affect the wfm/s speed, but you aren't looking for the maximum wfm/s for each t/div. Instead, the test signal is somewhat representative of the signal you might actually be measuring, so your wfm/s measurement better represents what you expect to get when actually measuring a signal. That makes sense.

What do you mean when you say "Siglent do not decimate data what is mapped for display"? I understand taking 100 samples and using those values to determine where to plot the pixel, but I'm don't know what "decimate data" means.

Still if we do not draw line to display still we need somewhere fine interpolate  trigger position between real sample data points

ohhhh, that's an excellent point. I didn't think about the triggering mechanism, but you're right, it probably needs to do interpolation there so it knows when to trigger.

The importance of this speed should also not be exaggerated (still it is nonsense but no need over estimate). A modern oscilloscope has many other features that can reduce the importance of this speed.

You make a good point. As I was looking through this data, I was thinking about what utility this data really has. If you have a solid signal feature to trigger from (edge, pulse, runt, etc.) then the wfm/s speed probably matters very little. I suppose this type of information is more useful when you don't have anything to trigger off of and you're trying to catch a spurious event.

If you're trying to catch a spurious event without a trigger, the best way to do that is probably minimizing dead time. I actually found an old whitepaper (here: https://www.newark.com/pdfs/techarticles/agilent/BestWaveformUpdateRates.pdf) by Agilent that specifically brags about the advantages of a high update rate. The Tek and LeCroy listed as counter-examples have terrible update rates (30 wfm/s? really?!), but when I do the same probability calculations with the SDS2000X Plus data, the probabilities really seem very good.

If 0% dead time is required and you are trying to capture a spurious signal, would the best way to accomplish that be by setting a very large t/div (like 10 or 50 s/div) and change the acquisition from "Normal" to "Peak"? After reading about peak acquisition mode, I'm a little confused by it. Does that mean when it's collapsing 100 samples into 1 pixel, does it just choose the maximum? Or the minimum? Or something else?