Author Topic: Functional comparison of R&S RTB2000, Siglent SDS2000X and Keysight DSOX1000  (Read 32181 times)

skench and 5 Guests are viewing this topic.

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4130
  • Country: fi
  • Born in Finland with DLL21 in hand
Just tested it with one other Siglent scope model (not just SDS2000X Plus because I do not have it now). ETA 2022-04-16: yes it was unpublished SDS2000 HD what I can tell now after Performa01 have published it.
what have around same memory, samplerate and royghly same wfm speed specs.
Only for show that different settings give different result.
Also looked how dots/vectors x/Sinc  affect in this case and no notable changes.
This is NOT comparable directly with SDS2000X Plus!! So for it this is nonsense but only show that different setup give different result.

Same signal and only to CH1  and same trig. CH2, 3 and 4 just only on without signal.
All memory lengths same as displayed wfm length (display width 2ms (200us/div))
10k memory, 5MSa/s  ~317 acquistion/s (wfm/s)
100k memory 50MSa/s ~319 acquistion/s (wfm/s)
1M memory 500MSa/s ~245 acquistion/s (wfm/s)
2M memory 1GSa/s ~179 acquistion/s (wfm/s)

Same signal and only to CH1  and CH4 just on without signal,  same trig.
20k memory, 10MSa/s  ~319 acquistion/s (wfm/s)
200k memory 100MSa/s ~313 acquistion/s (wfm/s)
2M memory 1GSa/s ~179 acquistion/s (wfm/s)
4M memory 2GSa/s ~91 acquistion/s (wfm/s)

Same signal and only to CH1,  same trig.
20k memory, 10MSa/s  ~326 acquistion/s (wfm/s)
200k memory 100MSa/s ~326 acquistion/s (wfm/s)
2M memory 1GSa/s ~179 acquistion/s (wfm/s)
4M memory 2GSa/s ~91 acquistion/s (wfm/s)
All these "memory" lengths mean true current acquisition lenght (not max memory length set value - if it differ)
And this length is same as displayed signal lenght.

Measured trig out using HP 53131A HS010 using 1s Gate time. Peak values are, or may be, slightly higher.

And now I repeat again.
Please, @RBBVNL9,  can you tell what was different scopes current true acquisition lengths (samples) and sampling speed. (in your image)
« Last Edit: April 16, 2022, 02:22:07 pm by rf-loop »
BEV of course. Cars with smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the (strong)wises gone?
 

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 329
  • Country: nl
In reponse to 2N3055 and rf-loop:

Quote
Please can you clarify every oscilloscope sampling speed and current acquisition true memory length used in this image.
Quote
Could you check something on Siglent? If you go into Acquistion  menu, do you have Slow or Fast mode set there? You need to be in the dot mode also..

Below are the settings that were used for the measurement reported earlier (in the PicoScope screen print): 

RTB:
-   Record length: 10 kSa. Note: at 200kSa I start to see a slight reduction in trigger events per second. At 10Msa there are roughly half the number of trigger events per second.
-   Sample rate is 4.81 MSa/s (this number changes when other record lengths are selected)
-   Trigger output pulse set to 1ms using TRIGger:OUT:PLENgth 1E-3
-   Only Channel 1 activated.

SDS
-   Record length (parameter “MAX record length”) setting is 20k. Interestingly, any other setting (200k, 2M, 20M, 200M) does not make any difference for this measurement
-   Sample rate is 10.0 MSa/s (this number changes when other record lengths are selected)
-   “Acqu Mode” set to “Fast”. Interestingly, changing it to “Slow” does not make any difference for this measurement
-   “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS 100ms in between, so a considerable drop in the number of trigger events per second.
-   Display Type = Vectors. But setting it to dots makes no difference whatsoever.
-   Only Channel 1 activated.

DSOX
-   Sample rate is 500MSa/s. ASAIK this rate is simply a function of the chosen timebase setting, there is no other way to choose this.
-   Segmented memory is off (but when turned on, that has no impact on the number of trigger out pulses)
-   Only Channel 1 activated.


Those are the kind of relevant parameters, I guess. But perhaps there are others that matter? 
« Last Edit: April 05, 2022, 12:12:23 pm by RBBVNL9 »
 
The following users thanked this post: 2N3055

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4130
  • Country: fi
  • Born in Finland with DLL21 in hand
In reponse to 2N3055 and rf-loop:

Quote
Please can you clarify every oscilloscope sampling speed and current acquisition true memory length used in this image.
Quote
Could you check something on Siglent? If you go into Acquistion  menu, do you have Slow or Fast mode set there? You need to be in the dot mode also..

Below are the settings that were used for the measurement reported earlier (in the PicoScope screen print): 

RTB:
-   Record length: 10 kSa. Note: at 200kSa I start to see a slight reduction in trigger events per second. At 10Msa there are roughly half the number of trigger events per second.
-   Sample rate is 4.81 MSa/s (this number changes when other record lengths are selected)
-   Trigger output pulse set to 1ms using TRIGger:OUT:PLENgth 1E-3

SDS
-   Record length (parameter “MAX record length”) setting is 20k. Interestingly, any other setting (200k, 2M, 20M, 200M) does not make any difference for this measurement
-   Sample rate is 10.0 MSa/s (this number changes when other record lengths are selected)
-   “Acqu Mode” set to “Fast”. Interestingly, changing it to “Slow” does not make any difference for this measurement
-   “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.
-   Display Type = Vectors. But setting it to dots makes no difference whatsoever.

DSOX
-   Sample rate is 500MSa/s. ASAIK this rate is simply a function of the chosen timebase setting, there is no other way to choose this.
-   Segmented memory is off (but when turned on, that has no impact on the number of trigger out pulses)

DSOX have 1us and SDS have 2us max trig interval in segment & sequence mode.

Quote
SDS
-   “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.

This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and  when I look segments   time stamps they have all 3ms (3000us) delta time. So 333.33  segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33...  segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)...  still all 19 segments delta time is 3ms.... 333.33... segment/s

What is this your 100ms or  (or mS as you said, aka milli Siemens what is conductance SI derived unit)

In SDS2000X Plus is some severe bug in Sequence mode or some external reason... ;)

« Last Edit: April 05, 2022, 10:32:34 am by rf-loop »
BEV of course. Cars with smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the (strong)wises gone?
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 4685
  • Country: au
    • send complaints here
They also mention casually memory sizes, but 3000T has only 500k of sample memory when doing 4ch+ digital normal mode (4 buffer-2 per ch-1 with digital -0.5  Mpts for ping pong buffers. 1Mpts for Single mode). Scope with 100Mpts will be 100x slower everything else being equal. Scope with 500MPts will have soo much more work to do.
You can keep pulling up the same "small memory" argument, except it is common for memory to change in different acquisition settings across most scopes. Those characteristics are not avoided in the Keysight data sheets or left as only up-to/maximum/peak values, and made very clear in the manuals (contrasting to these other examples discussed here where it is not clear at all what is expected).

But you make the false claim that there is a comparison with memory depth, the waveform capture measurements that competitors use keep the memory depth very short to inflate their numbers. Look at how much slower the competitors are despite choosing less memory! (when at same memory they are far behind). Scopes are not some computer system where the parts are put together in imbalanced ways by the end user, they are a finished product from the manufacturer who has decided on the system performance. Keysight make a real time scope with 100Mpts of memory, the EXR or MXR series, without a significant drop in waveform rate (keeping the system balanced).

Where you keep falling over is trying to make out like all scopes work/function the same. The Keysight megazoom method has been to decouple display and waveform memory, they are two different paths that dont interact. Acquisition data is piped to the display plotter/memory (through decimation etc) separately to the waveform memory. As you say before, to make things fast they chose to put most of the emphasis/features on the decimated view (positive example: fast eye diagrams). Most other scopes draw the waveforms from the acquisition memory, and take measurements from the original data (Lecroy being the extreme example of that, positive example: higher resolution measurements). Completely different with advantages and disadvantages, for comparisons they are best listed as characteristics rather than put as a good/bad binary check box against specific/your preference.
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 4685
  • Country: au
    • send complaints here
SDS
-   “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.

This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and  when I look segments   time stamps they have all 3ms (3000us) delta time. So 333.33  segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33...  segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)...  still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc

Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.
 
The following users thanked this post: rf-loop

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 329
  • Country: nl
OK, lots of input from various persons, need to find some time to digest all of it (got other work to do today...)

Quote
(or mS as you said, aka milli Siemens what is conductance SI derived unit)

You caught me there! It usually upsets my when people make errors in SI units or prefixes, but here I had a slip of the pen and did it myself  :(
 

Online 2N3055

  • Super Contributor
  • ***
  • Posts: 7008
  • Country: hr
They also mention casually memory sizes, but 3000T has only 500k of sample memory when doing 4ch+ digital normal mode (4 buffer-2 per ch-1 with digital -0.5  Mpts for ping pong buffers. 1Mpts for Single mode). Scope with 100Mpts will be 100x slower everything else being equal. Scope with 500MPts will have soo much more work to do.
You can keep pulling up the same "small memory" argument, except it is common for memory to change in different acquisition settings across most scopes. Those characteristics are not avoided in the Keysight data sheets or left as only up-to/maximum/peak values, and made very clear in the manuals (contrasting to these other examples discussed here where it is not clear at all what is expected).

But you make the false claim that there is a comparison with memory depth, the waveform capture measurements that competitors use keep the memory depth very short to inflate their numbers. Look at how much slower the competitors are despite choosing less memory! (when at same memory they are far behind). Scopes are not some computer system where the parts are put together in imbalanced ways by the end user, they are a finished product from the manufacturer who has decided on the system performance. Keysight make a real time scope with 100Mpts of memory, the EXR or MXR series, without a significant drop in waveform rate (keeping the system balanced).

Where you keep falling over is trying to make out like all scopes work/function the same. The Keysight megazoom method has been to decouple display and waveform memory, they are two different paths that dont interact. Acquisition data is piped to the display plotter/memory (through decimation etc) separately to the waveform memory. As you say before, to make things fast they chose to put most of the emphasis/features on the decimated view (positive example: fast eye diagrams). Most other scopes draw the waveforms from the acquisition memory, and take measurements from the original data (Lecroy being the extreme example of that, positive example: higher resolution measurements). Completely different with advantages and disadvantages, for comparisons they are best listed as characteristics rather than put as a good/bad binary check box against specific/your preference.

I'm not sure what I wrote was false.

Fact is that real time processing of 250 Mpts is harder than 4 MPts.  Which, I agree with you, is no problem if you're sampling at such sample rate and timebase  that all scopes take only 1000 samples..
I wasn't attacking anything and was not commenting OP specific results on this test but in general this old (you surely remember massive talk about this on previous many occasions) topic.
Keysight was always big on marketing this Wfms/s advantage (which is real) against other scopes from competition. Always pointing out that this is very important advantage of Megazoom IV to other scopes that don't have it, conveniently forgetting their own higher ends scopes also having 100 Wfms/s if they had same large memory as competition.
And thank you for pointing out that Keysight managed to make new gen of scopes that manage to have large memory and fast Wfms/s. Only problem is that those still barely achieve 200000 Wfms/s, same as lowly 1000X. And that despite massive processing power of high end scope with prices north of 20000 USD.. That shows you what price and performance is needed to make a 200 Mpts scope that will achieve high Wfms/s rates.
So in a range of prices of several thousands USD, compromises will exist. One extreme is 1 MWfms/s on KS 3000T  with small memory. Other side is hundredths of MPts at slower update rate.
An it is not about sheer amount of data being processed. It is about architecture that changes with larger memories and high bandwidths needed.
Architecture can be more easily optimised if you have small memory. I suspect KS is using dual port memory architecture somewhere in side Megazoom IV to achieve simultaneous sampling in one buffer and rendering from another to achieve ping pong double buffering.. Or maybe hardware bank switching of memory pages onto two separate address/data spaces.. To achieve bandwidths needed, they use wide words and banks, and interleaving.
Bottom line small memory (full size small memory) allowed them to optimize architecture to fastest possible for fast acquisition in circular buffer/trigger/switch to other buffer/render in parallel.
FPGAs, as powerful as they are, are not as flexible as ASIC, where you can really draw up what you want (*).

That means that even with same sizes of data, Megazoom will be faster. It is optimized for that.
For instance, datapath on Megazoom IV is 8 bit. On SDS2000X+ is 16 bit, courtesy of 12+bit capable architecture.
Etc etc...

I'm not trying to pretend that all scopes function the same way. Quite the opposite. General population are thinking of them like they work the same way. They don't, and those types of comparisons end up being looked upon as comparisons which one is better, instead of  which one is different and how. And how can you best utilize the tools they provide.
They each are best when used and considered in a specific way. These comparisons end up being perceived as some scoring competition, instead of nice resource for people to dig in to make their own decision based on good quality resource. I believe Rudy's original intention was exactly that.
And I try to explain that and you say the same, except I'm wrong... I think that sometimes you overestimate my English. Although I'm quite eloquent on occasion, it takes a lot of effort to find right words. It is hard to express what you think in foreign language, despite good command of it in general. False modesty on the side, I know my English is quite OK, but far from efortles or perfect.

In a short, I agree with your last paragraph (except first sentence), that is exactly what I try to say. You cannot simplistically compare these platforms based on few numbers taken out of context.

Honestly, I miss MSO5000 from Rigol in this. It would have been good to add it to what so far I see as very good and impartial research by Rudy. There have been quite a few discussions where there are no good info on real performance form real life MSO5000 users. I know there are quite a few of them out there, but maybe one or two contribute quality info.


(*) "I'm not bad. I'm just drawn that way." Jessica Rabbit
 

Online 2N3055

  • Super Contributor
  • ***
  • Posts: 7008
  • Country: hr
SDS
-   “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.

This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and  when I look segments   time stamps they have all 3ms (3000us) delta time. So 333.33  segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33...  segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)...  still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc

Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.

Touchscreen Siglents indeed run Segmented capture in circular (forever as you say :-) mode if you start it in RUN mode. They will get one burst, and again and again with a slight pause in between. In order to get a single segmented burst you must press Single while in segmented mode..
 

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 329
  • Country: nl
Quote
Honestly, I miss MSO5000 from Rigol in this. It would have been good to add it to what so far I see as very good and impartial research by Rudy. There have been quite a few discussions where there are no good info on real performance form real life MSO5000 users. I know there are quite a few of them out there, but maybe one or two contribute quality info.

Thanks for the nice words. I have been thinking of buying a Rigol MSO5000 for this comparison. Buts it's quite an investment if I do so only for these videos. Also, this comparison plus its videos have proven to be quite time-consuming (surprise, surprise). I have some work trips and a sabbatical leave coming up (was offered a guest professor position in Tokyo for that leave, and I am not going to drag any test equipment along ;-) With less time, adding an extra scope means it would delay the completion of the series. 
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 4685
  • Country: au
    • send complaints here
They also mention casually memory sizes, but 3000T has only 500k of sample memory when doing 4ch+ digital normal mode (4 buffer-2 per ch-1 with digital -0.5  Mpts for ping pong buffers. 1Mpts for Single mode). Scope with 100Mpts will be 100x slower everything else being equal. Scope with 500MPts will have soo much more work to do.
You can keep pulling up the same "small memory" argument, except it is common for memory to change in different acquisition settings across most scopes. Those characteristics are not avoided in the Keysight data sheets or left as only up-to/maximum/peak values, and made very clear in the manuals (contrasting to these other examples discussed here where it is not clear at all what is expected).

But you make the false claim that there is a comparison with memory depth, the waveform capture measurements that competitors use keep the memory depth very short to inflate their numbers. Look at how much slower the competitors are despite choosing less memory! (when at same memory they are far behind). Scopes are not some computer system where the parts are put together in imbalanced ways by the end user, they are a finished product from the manufacturer who has decided on the system performance. Keysight make a real time scope with 100Mpts of memory, the EXR or MXR series, without a significant drop in waveform rate (keeping the system balanced).

Where you keep falling over is trying to make out like all scopes work/function the same. The Keysight megazoom method has been to decouple display and waveform memory, they are two different paths that dont interact. Acquisition data is piped to the display plotter/memory (through decimation etc) separately to the waveform memory. As you say before, to make things fast they chose to put most of the emphasis/features on the decimated view (positive example: fast eye diagrams). Most other scopes draw the waveforms from the acquisition memory, and take measurements from the original data (Lecroy being the extreme example of that, positive example: higher resolution measurements). Completely different with advantages and disadvantages, for comparisons they are best listed as characteristics rather than put as a good/bad binary check box against specific/your preference.
I'm not sure what I wrote was false.

Fact is that real time processing of 250 Mpts is harder than 4 MPts.
Right there, the opening statement. You keep bringing it back to memory depth.

The main limitation of waveform update rate is the throughput of the plotter, the plotting rate of dots/vectors per second that is sometimes reported. By separating the acquisition memory and waveform plotter/display the Keysight megazoom IV continues fast realtime display with the full ADC rate out to 20GS/s in the higher end uses of it (with a proportionally slower waveform update rate from the higher sample rate). There is no compromising on waveform rate as the display window (and acquisition memory depth) gets larger, if they had more acquisition memory they wouldn't slow down at all, because the plotting keeps up at the highest ADC sample rates already. This is also why the intensity graded display doesn't show aliasing, it has data oversampled enough to produce the real time plotting. No trade off for memory depth vs update rate as they are largely independent.

That is a fundamentally different way of operating compared to other scopes, that buffer the acquisition as a continuous (often decimated/filtered) waveform and then turn that data into a waveform for display. Needing the waveform kept in memory while it is being processed for display, blocking further acquisitions, producing longer blind times.

Parallel vs Serial. Night vs Day.
« Last Edit: April 05, 2022, 10:00:31 pm by Someone »
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4130
  • Country: fi
  • Born in Finland with DLL21 in hand
SDS
-   “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.

This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and  when I look segments   time stamps they have all 3ms (3000us) delta time. So 333.33  segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33...  segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)...  still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc

Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.

It was nice you rise this circular mode up.

Siglent do not have it (least yet afaik)
 
It works sequentially. (kind of burst)

It take one sequence (user defined n amount of segments in one fast *) sequence)  and after this is ready, it processes all of these for display - stacking (overlay) them all, without interleaving together in one TFT image. And this take time, in some cases it may take really long time and during this it do not capture signal at all (just total blind).  After then (in continuous mode) it start new squence. Trigger mode Normal (and also Autyo) mode is this repeating sequence mode and Single run just one single sequence and after all n seqments captured it stop and then processes all these for display n segments overlaid.

In some cases it may be useful if there is "circular" or this kind of continuous mode where it can capture as normal fast sequence mode but without user defined n, working just as circular buffer or fifo... how want think it. It capture segments until user or some signal stop it.
After then can look last captured segments (limited by total available memory and user defined seegment length). Only after stop it can display what is captured. (Siglent HW can not simultaneously handle displaying signal and run fast sequence mode capturing.) But this kind of mode is not implemented.
Is this kind of mode useful or not... and if, when.

*) fast mean that it can repeat trig "fast". (fastest trig interval 2us)

BEV of course. Cars with smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the (strong)wises gone?
 
The following users thanked this post: Someone

Online nctnico

  • Super Contributor
  • ***
  • Posts: 27424
  • Country: nl
    • NCT Developments
SDS
-   “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.

This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and  when I look segments   time stamps they have all 3ms (3000us) delta time. So 333.33  segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33...  segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)...  still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc

Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.

It was nice you rise this circular mode up.

Siglent do not have it (least yet afaik)
AFAIK the history buffer should work thay way (although likely not with fast sequence mode).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 4685
  • Country: au
    • send complaints here
It was nice you rise this circular mode up.

Siglent do not have it (least yet afaik)
I am not fully familiar with all these models, thanks for confirming how the Siglent handles it: burst - display - burst - display - etc

As I recall the Keysight 1100 and 1200 have a (speed crippled in the 1100) segmented buffer, that does not display them until you stop and manually request it. But it can be switched between circular and one shot. The run/single buttons are not used as the obvious controls for that, more confusions.

Would be interesting to hear more on what options and controls the R&S (optional?) segmented and history modes have, looks like more depth/options than the other two.

My favourite implementation of history/segmented memory is the Lecroy Wavejet 300 (oem: Iwatsu) it is a good balance of realtime update rate, and continuous "replay" segment history. Priced well above the comparisons considered here though.
« Last Edit: April 05, 2022, 01:45:48 pm by Someone »
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 4685
  • Country: au
    • send complaints here
SDS
-   “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.

This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and  when I look segments   time stamps they have all 3ms (3000us) delta time. So 333.33  segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33...  segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)...  still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc

Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.
AFAIK the history buffer should work thay way (although likely not with fast sequence mode).
Looking at the manual, and getting the confirmation from rf-loop, the Siglent does not have any continuous mode. While the Keysight does not have any mode where it will do displays along the way. Quite different, orthogonal, and singular/forceful/narrow minded in their approaches!
 

Online egonotto

  • Frequent Contributor
  • **
  • Posts: 846
Hello,

RBBVNL9 wrote:
"
"RTA behave little wilder."
Can you perhaps elaborate on what you mean here?
"

in RTB the blind time seems has always the same length just as the non blind time, so the picture looks almost periodic.

Different in RTA there has the blind time several length as the non blind time. It looks noway periodic.

Best regards
egonotto
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4130
  • Country: fi
  • Born in Finland with DLL21 in hand
SDS
-   “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS in between, so a considerable drop in the number of trigger events per second.

This is really weird. Even If I test with this same signal with SDS1104X-E and 200us/div and Sequence. I take oneshot sequence with 50MSa/s 140k length and  when I look segments   time stamps they have all 3ms (3000us) delta time. So 333.33  segments in second.
Then I change it to 14k memory so 5MSa/s and look 1900 segment single sequence. Every single segment in sequence time stamp delta time is 3ms. So 333.33...  segment/s
Then with 1GSa/s 2.8M current mem lenght (one segment length)...  still all 19 segments delta time is 3ms.... 333.33... segment/s
I think the explanation is good, with the sequence mode in run mode:
[n sequences without gaps] 100ms processing interval [n sequences without gaps] 100ms processing interval... etc

Interesting it was not in a circular mode (does not support it?) where the sequences capture around forever until stop is pressed.

It was nice you rise this circular mode up.

Siglent do not have it (least yet afaik)
AFAIK the history buffer should work thay way (although likely not with fast sequence mode).

Yes it works as continuous FIFO (always bacround). When stop there is always last segments available.
But even when it (SDS1kX-E) may have up to >100kwfm/s  (ksegment/s) average speed in second! (1 channel on, 50ns/div and display mode dots, measurements off).
This mode quaranteed speed is extremely slow. So if it is important to be sure it do not drop out any single trig event...  example with SDS1104X-E if measurements off theree can be 3.5ms pause. So quaranteed speed may example 280wfm/s (segment/s) and with measurements on example 24ms pause (with average speed example around ~70kwfm/s) means quaranteed speed around 40wfm/s.
Many times in segmented mode we need some quarenteed speed to be sure any trig event is not dropped out. If this is not important then of course this mode can use as continuous segment mode (fifo mode) and after stop last segments are in buffer and every segment can analyze.

« Last Edit: April 06, 2022, 02:28:37 am by rf-loop »
BEV of course. Cars with smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the (strong)wises gone?
 

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: us
SDS
-   Record length (parameter “MAX record length”) setting is 20k. Interestingly, any other setting (200k, 2M, 20M, 200M) does not make any difference for this measurement
-   Sample rate is 10.0 MSa/s (this number changes when other record lengths are selected)
-   “Acqu Mode” set to “Fast”. Interestingly, changing it to “Slow” does not make any difference for this measurement
-   “Seq. Acq. Switch” set to off. When it is turned on, I see sets of n acquisitions (where n is the number set by the “Seq Segment” parameter” with almost 100mS 100ms in between, so a considerable drop in the number of trigger events per second.
-   Display Type = Vectors. But setting it to dots makes no difference whatsoever.
-   Only Channel 1 activated.

I was able to reproduce this, but there's a caveat that I'll explain below.   My suspicion is that you set the final memory depth after you set your timebase and that your initial memory depth was at least 20M.  From what I've seen it makes all the difference in the world.

Once you have your acquisition settings finalized, change the timebase and the settings will "take".  Sometimes that's not necessary, while other times it is (with the timebase set as you have, going from 20M or 200M to anything less than 20M will necessitate a twiddle of the timebase to get the new waveform update rate to take hold).

With the timebase set as you have (200 us/div), with a 1 kHz waveform, here's what I get for trigger output frequency (average), which presumably is a representation of the internal waveform update rate:

PointsSamples/secFrequency (avg)
--------------------------------------
20k10M333
200k100M300
2M1G153
20M (actual: 4M)2G30
200M (actual: 4M)2G30


If I start with maximum memory depth, set up the timebase and volts/div, I get 30 Hz as described above.  If I then set my memory depth to 200k, it will stay at 30 Hz until I twiddle the timebase.  Twiddling other settings (including things like hitting the "normal" trigger button again) makes no difference.  Only the timebase seems to actually cause the update rate to change under these conditions.
« Last Edit: April 08, 2022, 01:26:54 am by kcbrown »
 
The following users thanked this post: rf-loop, Someone, RBBVNL9

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 329
  • Country: nl
@ kcbrown,

Thanks a lot for replicating this, leading to what seems to be a quite important finding!

So it seems a change in memory depth setting (and hence sample rate) only takes effect if the user afterwards changes the timebase settings... That would be strange and non-intuitive behaviour from the user's point of view, but it would certainly explain a lot about the low (re-)trigger rate we were observing.

Hope to have some time tonight to test this myself, and also find out what this means for the poor visual observation of infrequent glitches (which I talked about in my video episode 7 at 47:27) and the ability to observe mask failures (for which I have some preliminary measurements mentioned in the comparison document V61 on page 33).

So, thanks again! Excellent work!
. rudi


 

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: us
@ kcbrown,

Thanks a lot for replicating this, leading to what seems to be a quite important finding!

So it seems a change in memory depth setting (and hence sample rate) only takes effect if the user afterwards changes the timebase settings...

Not necessarily.  Going from a smaller memory depth to a larger memory depth seems to make the new setting have an immediate effect on the waveform update rate (which might be a small change, as it was when going from 20k to 200k).  I haven't tested other timebases and, thus, other maximum capture lengths.  It may be that the issue only happens when the capture size you're going from is limited by the maximum sample rate versus the screen width in time, as it is with 20M and 200M at 200 us/div (which limit the capture size to 4M).  So a bit more testing is needed to fully characterize this.

I do think it's safe to say, though, that if you change the memory depth, then changing the timebase will make the new setting have the appropriate effect on the waveform update rate if that effect hasn't already taken place.


Quote
So, thanks again! Excellent work!
. rudi

You are most welcome!
 

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1688
  • Country: at
As has been mentioned before, the trigger engine in the SDS2000X Plus is not working properly.
That it fails to apply changes in max. record length without a detour (nice finding, @kcbrown!) might add to the problems, but it's certainly not the only one.

I did a test with the yet unreleased sibling of the SDS2000X Plus, the new 12 bit SDS2000X HD, since it doesn't seem to have a comparable bug.

The max. record length is important. We need to limit it to 200kPts to get 333 wfms/s peak (325.86 average). At 2 Mpts the average rate is about 180 Wfms/s and at 4 Mpts it is around 100 Wfms/s. So this sounds as if it is faster than the RTB, just as was to be expected from the technical data. display mode dots or vectors doesn't make a difference, the same is true for x or sin(x)/x of course.

In general, dots mode is only effective at timebase settings faster than 50 ns/div, where any interpolation errors such as Gibbs ears can be avoided and the wavform update-rate sped up at the same time.

See attached two screenshots:

SDS2504X HD_Signal_Square_1kHz_Mem200k
This is the test signal, a ~1kHz square wave on the SDS2000X HD. Vector Mode, Sin(x)/x, "Fast" Acquisition. We certainly won't get more than 30 Wfms/s in "Slow" mode.

Trig_Out_1kHz_Mem200k
This is the Aux Out (triggger out) signal, monitored by another scope with the counter application including statistics.

 
The following users thanked this post: Martin72

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 329
  • Country: nl
Performa01, thanks for the input.

Quote
That it fails to apply changes in max. record length without a detour (nice finding, @kcbrown!) might add to the problems, but it's certainly not the only one.

Can you explain exactly what you believe these other problems are with the SDS2000X+ in terms of its trigger engine?

Thanks!
 

Offline RBBVNL9Topic starter

  • Frequent Contributor
  • **
  • Posts: 329
  • Country: nl
Dear all,

A new episode is ready on the comparison series, now on Bode Analysis. On paper, the Siglent SDS2000X Plus has the best cards of our three instruments. Is this true?

(Spoiler: yes, but you need to be very patent, and the specs don’t tell you the full story…)

The updated comparison document is available here.


 
The following users thanked this post: Performa01, nctnico, egonotto, DaneLaw, Markus2801A, Anthocyanina, pope, Detlev, arvidb

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1688
  • Country: at
Performa01, thanks for the input.

Quote
That it fails to apply changes in max. record length without a detour (nice finding, @kcbrown!) might add to the problems, but it's certainly not the only one.

Can you explain exactly what you believe these other problems are with the SDS2000X+ in terms of its trigger engine?

Thanks!
Sorry for the late reply...

See reply #3274 in thie thread below:

https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg4061779/#msg4061779

Topics 3 an 4 in that post might not be valid though, as I only saw them once after a FW-update and wasn't able to reproduce it after a reboot.

 

Offline Performa01

  • Super Contributor
  • ***
  • Posts: 1688
  • Country: at
Dear all,

A new episode is ready on the comparison series, now on Bode Analysis. On paper, the Siglent SDS2000X Plus has the best cards of our three instruments. Is this true?

(Spoiler: yes, but you need to be very patent, and the specs don’t tell you the full story…)

The updated comparison document is available here.

Thanks for that episode, nicely done!

A few remarks:
  • The Bode Plot in the Siglent is slow, especially at low frequencies. There might be reasons for this, like frequency selective detector and averaging for precise measurement results even at very low input signal levels in high dynamic range measurements.
  • Your simple tests did not reveal anything about the dynamic range of the measurements, where I expect the up to 120 dB dynamic to be another significant advantage for the Siglent. And it's mainly the dynamic range that makes up for a useful analysis tool in this area.
  • Your complaint about not being able to set fine steps for the amplitude axis has aready been addressed in the SDS2000X HD and will be available in the next SDS2000X Plus firmware. We can now set the scale in 1 dB increments.
  • Your complaint about not being able to have a look at the time domain view has aready been addressed in the SDS2000X HD and will be available in the next SDS2000X Plus firmware.
 
The following users thanked this post: 2N3055

Online 2N3055

  • Super Contributor
  • ***
  • Posts: 7008
  • Country: hr
@Performa
This time you were faster..  :-DD

Just to add, if you watch triggering lights on Siglent at very low frequencies, you will see it takes 5 measurements and than averages that data point. Like Performa said, it uses frequency selective algorithm, and together with averaging, it will have much improved software gain and it will be resilient to outside interference. That makes it have very good dynamic range and more robust if you are not working in a Faraday cage.
 
The following users thanked this post: Performa01


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf