Siglent's new product- MSO/SDS2000 Series

[tautech]

I have not seen 28 M shown on screen so i wonder how the memory depth is allocated.

28 Mpts memory depth is available only @ 1 mS timebase setting with 1 ch displayed. With 2 ch on 14 Mpts is available.
@ 1 nS timebase 28 pts are available with 1 ch displayed. With 2 ch on 14 pts are available.

Throughout time base settings faster than 500 uS memory depth is halved with 2 channels on.
 EDIT: Addition of more channels did not alter memory depth further.

This is most interesting as most memory depth data I have seen is presumably for only 1 channel on.

Which begs the question: what other scopes halve the memory depth available with 2 channels on?

[marmad]

Which begs the question: what other scopes halve the memory depth available with 2 channels on?

Many DSOs. The memory depth is, like the sampling rate, often specified for a single channel - then halved for two.

But you should ask Siglent about the Trigger Out rate - why is it the same across all sample sizes? Something is weird with it: if the DSO shows the same Trigger Out frequency for the smallest and the largest sample size, logic would dictate that it's correct for the smallest size (not the largest). But if that's true, then what is the DSO doing when it's supposed to be capturing 14M or 28M at slower time bases? If it's not true - and the 67 wfrm/s IS correct for 28M - why does it not capture more waveforms with smaller sample sizes?

[tautech]

But you should ask Siglent about the Trigger Out rate - why is it the same across all sample sizes? Something is weird with it: if the DSO shows the same Trigger Out frequency for the smallest and the largest sample size, logic would dictate that it's correct for the smallest size (not the largest). But if that's true, then what is the DSO doing when it's supposed to be capturing 14M or 28M at slower time bases? If it's not true - and the 67 wfrm/s IS correct for 28M - why does it not capture more waveforms with smaller sample sizes?

I remember some sample rate tables early in this thread(maybe of your making) with some erroneous results at the fast end of timebase settings.
By tweaking(optimizing) capture rates with firmware,could these results be modified to what we have seen here?
Just a suspicion thats whats happening. Would you not agree the results are ok, just not what was expected.

[Hydrawerk]

But you should ask Siglent about the Trigger Out rate - why is it the same across all sample sizes?

This reminds me the old Owon SDS7102.

[marmad]

I remember some sample rate tables early in this thread(maybe of your making) with some erroneous results at the fast end of timebase settings.
By tweaking(optimizing) capture rates with firmware,could these results be modified to what we have seen here?
Just a suspicion thats whats happening. Would you not agree the results are ok, just not what was expected.

As I've mentioned elsewhere, the SDS2000 seems like a great DSO (with very good hardware), but the results (with deep memory at the slower time bases) seem a bit hard to believe - and it would be good to know why the Trigger Out rates don't change with memory depth.

The problem is one of throughput: with large memory depths @ slower time bases, there is a massive amount of data that has to be not only captured (which is the least math-intensive aspect), but also decimated and moved from sample memory into the intensity buffer. If these rates are correct for the Siglent at 14M, 28M, etc, it means that, as shown in the chart, not only is it's throughput almost 400% higher than any of the other comparable DSOs at 1ms (and other) time bases - but it's highest throughput of ~1.9GB is higher than the throughput at ANY time base setting on the 1 million wfrm/s Agilent X-3000 series (which has a max. throughput of ~1.6GB - and where much of the work takes place on a single ASIC).

Again, the Siglent's numbers aren't necessarily impossible - but they certainly raise questions. It's Trigger Out rates at the slower time bases are quite similar to the Rigol DS2000's rates when using the 14k sample size - but not when using the 14M sample size.

[marmad]

@tautech: Perhaps there's just a bug in what the Siglent is reporting as the selected memory size?

I assume if you set the time base to 1ms/div and input a 10MHz sine wave, you will get images similar to the attached for 14k memory depth (aliasing) and 14M (or AUTO) memory depth?

[tautech]

Again, the Siglent's numbers aren't necessarily impossible - but they certainly raise questions. It's Trigger Out rates at the slower time bases are quite similar to the Rigol DS2000's rates when using the 14k sample size - but not when using the 14M sample size.

Yes it does raise questions...very interesting ones.(not meaning your results)

Is your table correct for all brands @ 1 mS timebase setting?
The 1 mS Siglent result is skewed by virtue of the much higher(28 M) sample that is only available at that timebase setting.
I could provide other data for further comparison if needed.

[Mark_O]

I sent my DS2000 a series of 50ns pulses spaced 100us apart, in Normal acquire mode (not Peak Detect - which would obviously void the experiment), and saved an image while running using 14M sample depth - and then 14k. You can see the differing results when decimating from a larger or smaller sample size.

Just wanted to check what I'm seeing.  At that rate (1Msa/s with 14k depth), there are 1000 samples per division, or only 20 per display point.  Is this curve because after triggering on one pulse, the samples slowly drift out of sync with the pulses (decreasing the average amplitude), to the point where all the samples fall into the 99.95% dead space?

[rf-loop]

Very interesting... but I don't understand how they're keeping the waveform update rate constant. Is it possible to decimate/post-process, for example, 945kB (14k * 67.5) and 1.8GB (28M * 67.5) at the same speed?

What happens if you perform an experiment such as the following?

I sent my DS2000 a series of 50ns pulses spaced 100us apart, in Normal acquire mode (not Peak Detect - which would obviously void the experiment), and saved an image while running using 14M sample depth - and then 14k. You can see the differing results when decimating from a larger or smaller sample size.

~100us period, 50ns pulse width

First acquire stopped.
1ms/div. 14k and 14M memory (but it use 28M memory, due to construction -> note 2GSa/s)
Then zoomed in this 14M(28M) capture so that separate captured samples visible.
(Also .CSV file proof that it really use 28Mpoints)

Then scope run.. just first this zoomed (5ns/div)

Then scope run and images using 14k and 14M (28M) memory.

28000000 sample points with 2GSa/s takes of course 14ms. Without blind time theoretical maximum is 71.4  full waveform per second. Also it need note that all what is out from screen area need include to "blind" area. In Siglent SDS2000 this kind of "blind" time is zero. (captured waveform lenght is equal to displayed area)
Between every waveform is roughly 1ms time and also during this 14ms acquire time there can do many things. Why it is so mysterious if Siglent do this. Perhaps Agilent have not even done any work for rise slow horizontal speeds update rate because "up to" rates are what sell....

SDS2304-28M-100u-50ns.CSV
667 MB (699 986 090 bytes)

Source,CH1
Second,Volt
 
-0.00699999938,-1.52000,
.....etc

one data pair is like this.. so there is around 28M data pairs.
This "proofs" that 28Mpoint is true. (also stop, zoom and count sample points proofs it)

(btw, it takes long time when scope produce and save this 667MB .csv file.... )

Note for 14k memory capturing. Samplerate is 1MSa/s.
With 50ns wide pulses it means that what there is on the scope screen displayed is "alias".  Sampling period is 1us!  Pulse width is 1/20 of sample period!
(not so seriously ; )  but...
I do not fully understand what the idea of ??such a test? Is that the way it looks when the user does not know what he is doing with an oscilloscope? Of course, when we see pictures of the aliasing is very exciting art, but why do we have to test what kind of aliasing instrument to draw pictures. Possibly by playing Nintendo would produce the same garbage and then with a group could be some surprise and wonder why and what's going on and see if it is right or wrong ... )

[tautech]

@tautech: Perhaps there's just a bug in what the Siglent is reporting as the selected memory size?

No not a bug. My Siglent info states 28 M memory depth is available 1 mS/div to 50 S/div.

My quote:

The 1 mS Siglent result is skewed by virtue of the much higher(28 M) sample that is only available at that timebase setting.

is wrong.
Info from Siglent indicates this is to be rectified with a forthcoming firmware release.

@ marmad
My tests did not use Stop as  rfloop The Master of his craft has. 

[rf-loop]

Well, something's odd. As mentioned, if the Siglent can do ~67 wfrm/s when it's capturing and processing over 1.8GB of samples per second (28M sample depth), why can't it go faster when it's capturing and processing only 0.00025% of that amount (7k sample depth)?

28Mpoints capturing using 2GSa/s takes as long time as 14kpoints using 1MSa/s. Both need 14ms.
7kpoints memory with 500kSa/s also take 14ms
1/0.014 = 71.4. And this limit can not break. Worth of money to try get closer this limit? From around 67 up to 71. I do not give any jiao for get this more fast.  Real visible time is nearly 95% of total time. 


So, how much faster you think... (no need answer )

[marmad]

First acquire stopped.
1ms/div. 14k and 14M memory (but it use 28M memory, due to construction -> note 2GSa/s)
Then zoomed in this 14M(28M) capture so that separate captured samples visible.
(Also .CSV file proof that it really use 28Mpoints)

As you know, stopping and then zooming in or saving memory to file proves nothing about what the DSO is doing when it's running. As the Agilent X-Series proves, the DSO can just fill the entire sample memory when STOP is pushed; what matters (in terms of waveform updates) is the real displayed waveform and how much data it contains.

Between every waveform is roughly 1ms time and also during this 14ms acquire time there can do many things.

Let's look at this idea closer. At ~67.5 wfrm/s, the total acquisition time is 14.8ms - so more like 800us between captured waveforms. That means, with a 28MB sample length, the DSO would have ~28.7ps of processing time for each sample (if ignoring the actual acquisition time) - or ~528ps per sample if calculating based on the entire acquisition time - which is still exceptionally fast. Perhaps the following chart would give a better idea about why I'm curious as to what the Siglent is doing:

Why it is so mysterious if Siglent do this. Perhaps Agilent have not even done any work for rise slow horizontal speeds update rate because "up to" rates are what sell....

Not necessarily mysterious - but certainly enough different from other DSOs to make it, IMO, worth wondering about.

one data pair is like this.. so there is around 28M data pairs.
This "proofs" that 28Mpoint is true. (also stop, zoom and count sample points proofs it)

Again, this alone proves nothing: only that 28M is filled with samples when the DSO is stopped.

With 50ns wide pulses it means that what there is on the scope screen displayed is "alias".  Sampling period is 1us!  Pulse width is 1/20 of sample period!
I do not fully understand what the idea of ??such a test? Is that the way it looks when the user does not know what he is doing with an oscilloscope?

The whole idea was to see the aliasing - looking for a method of determining how much data the DSO is actually decimating when it's running. As you've posted yourself before, rf-loop, a Trigger Out signal alone proves nothing - other than the DSO is putting out a signal @ XX Hz. For example:

Who can proof me that in all cases example every trig out means also real displayed waveform and how much data it contain.

With the Rigol DS2000, I can capture time-stamped segments which indicate the waveform update rate with deep memory depths (no Trigger Out is needed). Is there a method on the Siglent to 'see' the waveform update rate besides the Trigger Out signal?

I can clearly see a fast update rate at smaller memory depths in the posted GIFs of Herman; as mentioned, I'm just curious about the deeper memory settings due to the speed of the throughput (as shown in the chart above).

28Mpoints capturing using 2GSa/s takes as long time as 14kpoints using 1MSa/s. Both need 14ms.
7kpoints memory with 500kSa/s also take 14ms

As already mentioned several times, it's NOT about acquire time: it's about post-processing time; i.e. 1.9GB of samples to display memory vs. 952kB samples to display memory. They don't require nearly the same amount of time to post-process to the display.

I wonder why Tinhead doesn't give his opinion here? I remember he had much to say before when discussing the idea of the Rigol capturing 35 wfrm/s with a 56M memory depth 


So what happens when you set the memory depth to 14M @ 50ns/div. What is the Trigger Out frequency then? Still ~135 wfrm/s?

And what are the segmented memory abilities of the DSO? There doesn't appear to be any specific info in the released documents.

[Carrington]

That's what I thought too:

Not enough time, I think - unless the DSO double-buffers the sampling (like the Agilent does with a much smaller memory size). So if that wfrm/s rate is true for 28MB, I would probably assume that the DSO is using two different banks of 28MB - sampling to each one alternately.

SDS2000 maybe not only "duplicates" the memory, maybe they have also "duplicates" the processing and therefore it uses a large FPGA.

And what are the segmented memory abilities of the DSO? There doesn't appear to be any specific info in the released documents.

Yeap. I have not seen/read anything about this.

[Carrington]

Could be something like this? Perhaps this is absurd.
The processing time is the same as you mentioned, but and if acquisition and processing are overlapping?



Sorry for this graphic.

[tautech]

@ marmad

So what happens when you set the memory depth to 14M @ 50ns/div. What is the Trigger Out frequency then? Still ~135 wfrm/s?

Trigger out frequency approx 33.6 KHz

And what are the segmented memory abilities of the DSO? There doesn't appear to be any specific info in the released documents.

The scheduled firmware updates indicate that Segmented memory is about to be enabled.
I can not find any specific mention of it throughout the menus in my unit.

As rfloop has stated, these scopes have not yet reached full functionality.... one can only go by the published info as to just how good they will be.
 Possibly class leading...only time will tell. 

[marmad]

@ marmad

So what happens when you set the memory depth to 14M @ 50ns/div. What is the Trigger Out frequency then? Still ~135 wfrm/s?

Trigger out frequency approx 33.6 KHz

OK, so the Trigger Out frequency is not connected (in this instance) to the number of waveforms captured of the currently selected memory depth.

The maximum number of 14M waveforms that ANY DSO sampling at 2GSa/s could capture in 1 second is ~143 - and that would be with 0% blind time; i.e. 1 / (500ps * 14M).

[tautech]

OK, so the Trigger Out frequency is not connected (in this instance) to the number of waveforms captured of the currently selected memory depth.

The Trigger out waveform is a pulse train with 800 nS pulse width @ 50 nS timebase if that helps any calcs.

Edit.
Pulse width varies with timebase, not at any linear rate either.
2 uS width @ 200 nS.

Appears it may be linked to Memory depth as this also changes at these timebase settings

[Carrington]

Trigger out frequency approx 33.6 KHz

33.6 KHz @ 14Mpts and 50ns/div LOL...

[marmad]

33.6 KHz @ 14Mpts and 50ns/div LOL...

It's not a problem - if it's connected to the 1.4k samples that are actually displayed at 50ns (the Agilent X-Series does the same thing with it's update rate) - it's just important to know exactly what it's doing.

But I don't understand why at time bases >= 1us/div, the Trigger Out frequency doesn't change with the sample size - since then more sample points than the smallest memory depth (14k) start to be displayed.

[tautech]

Further info:
To go back to the 1 mS testing:

The pulses I have mentioned are @ 1 mS time base 7.4 mS at the 67.5 Hz Trig out frequency and that pulse is @ 50% duty cycle of Trig out.
If captures are only happening on that pulse then is the sample half of that that has been calculated?

[Carrington]

33.6 KHz @ 14Mpts and 50ns/div LOL...

It's not a problem - it can just be connected to the 1.4k samples that are actually displayed at 50ns (the Agilent X-Series does the same thing with it's update rate) - it's just important to know exactly what it's doing.

So: (2e9)^-1 * 1.4k = 50ns/div * 14 = 700ns (one screen)

I'm sorry, but when I wrote this was 3 AM here, what I wanted to say is:

50ns/div * 14div = 700ns (one screen) -> Mem.Dep = 700ns * 2GSa/s = 1K4

So the trigger output is only linked to the screen (what we can see, with their 1400 pts in this case). No point to do otherwise. And in a similar way to other timebases. But draw more points (when is possible) on the same screen width, should cost more. I don't know how but for the SDS2000 this does not seem to be a problem, and this is awesome.

But I don't understand why at time bases >= 1us/div, the Trigger Out frequency doesn't change with the sample size - since then more sample points than the smallest memory depth (14k) start to be displayed.

I hope that someone clarify what technique is used.

[tautech]

But I don't understand why at time bases >= 1us/div, the Trigger Out frequency doesn't change with the sample size - since then more sample points than the smallest memory depth (14k) start to be displayed.

But the Trigger pulse width does

Smallest Memory depth is 7 K

[Carrington]

But the Trigger pulse width does

Can you upload some screenshots to see how varied the width?

[tautech]

But the Trigger pulse width does

Can you upload some screenshots to see how varied the width?

I will build a table....this may take some time. 
Shit 32 timebase settings. 

[Carrington]

Ok, no problem, I see it tomorrow, it's bedtime here.
Cheers!

Shit 32 timebase settings. 

LOL... Do it only for 1ms/div (for example) with different memory depths.