Siglent SDS1000X and (MSO) SDS1000X+ series oscilloscopes

[tautech]

Some little insight to the Mask.
It does not operate in Zoom mode.
Results are dependent on the timebase setting when you create a mask.
There are X & Y adjustments that can be made.
Violations can be set to Stop the scope or it can continuously run counting Fails, beeping OR not and digital output via rear Pass/Fail BNC.

Ramblings:
For a I2C stream that I had on hand it was possible to set a mask for a complete packet and violations were triggered with a different length packet. With a stream of different packets at regular intervals it was also possible to create a mask for the largest packet then which there were zero violations for the data stream.

[kcbrown]

Some little insight to the Mask.
It does not operate in Zoom mode.
Results are dependent on the timebase setting when you create a mask.
There are X & Y adjustments that can be made.
Violations can be set to Stop the scope or it can continuously run counting Fails, beeping OR not and digital output via rear Pass/Fail BNC.

Ramblings:
For a I2C stream that I had on hand it was possible to set a mask for a complete packet and violations were triggered with a different length packet. With a stream of different packets at regular intervals it was also possible to create a mask for the largest packet then which there were zero violations for the data stream.

Can you create your mask at a faster timebase and then set a slower timebase before beginning the test run?  If so, what are the consequences of setting a sufficiently slower timebase that it forces a lower sampling rate?

[tautech]

Some little insight to the Mask.
It does not operate in Zoom mode.
Results are dependent on the timebase setting when you create a mask.
There are X & Y adjustments that can be made.
Violations can be set to Stop the scope or it can continuously run counting Fails, beeping OR not and digital output via rear Pass/Fail BNC.

Ramblings:
For a I2C stream that I had on hand it was possible to set a mask for a complete packet and violations were triggered with a different length packet. With a stream of different packets at regular intervals it was also possible to create a mask for the largest packet then which there were zero violations for the data stream.

Can you create your mask at a faster timebase and then set a slower timebase before beginning the test run?  If so, what are the consequences of setting a sufficiently slower timebase that it forces a lower sampling rate?

No.
If the timebase is changed from the setting the mask it was made in, it lays the waveform in violation to the mask. The mask is specific to the timebase setting it was made in.

[kcbrown]

Can you create your mask at a faster timebase and then set a slower timebase before beginning the test run?  If so, what are the consequences of setting a sufficiently slower timebase that it forces a lower sampling rate?

No.
If the timebase is changed from the setting the mask it was made in, it lays the waveform in violation to the mask. The mask is specific to the timebase setting it was made in.

Then the Siglent's approach to buffer management is a major fail here, since it is impossible to see the waveform's surroundings upon a mask failure with the Siglent's approach.  The other scopes score a major win over the Siglent for this.

Since the Siglent's buffer management mechanism provides no significant advantages (previously, it had no significant disadvantages either), but now has a significant disadvantage, that means that the approach taken by other scopes is superior overall.

Siglent could rectify this by allowing you to define your mask on the basis of the zoomed waveform and to perform the application of the mask against the zoomed portion during capture and test.  But as of now, Siglent loses this contest between buffer management mechanisms.  And that's quite a shame -- there's a lot to like about the Siglent.

[tautech]

Can you create your mask at a faster timebase and then set a slower timebase before beginning the test run?  If so, what are the consequences of setting a sufficiently slower timebase that it forces a lower sampling rate?

No.
If the timebase is changed from the setting the mask it was made in, it lays the waveform in violation to the mask. The mask is specific to the timebase setting it was made in.

Then the Siglent's approach to buffer management is a major fail here, since it is impossible to see the waveform's surroundings upon a mask failure with the Siglent's approach.  The other scopes score a major win over the Siglent for this.

Since the Siglent's buffer management mechanism provides no significant advantages (previously, it had no significant disadvantages either), but now has a significant disadvantage, that means that the approach taken by other scopes is superior overall.

Siglent could rectify this by allowing you to define your mask on the basis of the zoomed waveform and to perform the application of the mask against the zoomed portion during capture and test.  But as of now, Siglent loses this contest between buffer management mechanisms.  And that's quite a shame -- there's a lot to like about the Siglent.

The buffer is not involved in Pass/Fail tests, it is done at full speed.

See:
https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg925172/#msg925172

[kcbrown]

Since the Siglent's buffer management mechanism provides no significant advantages (previously, it had no significant disadvantages either), but now has a significant disadvantage, that means that the approach taken by other scopes is superior overall.

The buffer is not involved in Pass/Fail tests, it is done at full speed.

The buffer is involved in what is captured at the point the pass/fail test automatically stops the scope.  You can tell the scope to stop on a pass or fail, right?  If not, then it's even worse than I thought.

I'm using "buffer management mechanism" to refer to the mechanism that decides how much time to capture in the buffer.  Siglent's is dirt simple: it captures the amount of time represented on the screen into the size of the buffer that one manually selects.  Other oscilloscopes use different mechanisms.  Whatever the term for what I'm referring to here (if there's some widely used term for it, I'd like to know what that is), the point is that when the scope automatically stops as a result of a pass/fail violation, the only thing you get with the Siglent is what's on the screen, while what you get with other scopes is whatever's in the capture buffer, which is usually more than what's on the screen.  That makes other scopes more useful for examining what went on near the failure point.

[tautech]

Since the Siglent's buffer management mechanism provides no significant advantages (previously, it had no significant disadvantages either), but now has a significant disadvantage, that means that the approach taken by other scopes is superior overall.

The buffer is not involved in Pass/Fail tests, it is done at full speed.

The buffer is involved in what is captured at the point the pass/fail test automatically stops the scope.  You can tell the scope to stop on a pass or fail, right?  If not, then it's even worse than I thought.

See reply #175, as already stated the scope can be set to Stop or continue running the Pass/Fail tests.

I've always thought Pass/Fail tests were production/quality control related but of course they can be used along with  or instead of a comprehensive Trigger suite to find signal abnormalities so unlike you I believe Siglent's implementation of Pass/Fail is appropriate for production use. If there is desire to enhance it's functionality instead of using the Trigger suite available then we need call for some user/owner input on how it might be implemented better.
Thanks for the discussion and as always constructive feedback is best for us to pass on to the engineers.

[JPortici]

i have the manual here: scope stops, external trigger pulse and/or beep.

Siglent could rectify this by allowing you to define your mask on the basis of the zoomed waveform and to perform the application of the mask against the zoomed portion during capture and test.  But as of now, Siglent loses this contest between buffer management mechanisms.

yep. i think they tought pass/fail just as a mean to look at edges/eye diagrams. As you say, being able to define the mask only in the zoomed area should be possible and would solve this problem

And that's quite a shame -- there's a lot to like about the Siglent.

yep.

[tautech]

i have the manual here: scope stops, external trigger pulse and/or beep.

I have the scope here: Scope can be configured to Stop or not, Pass/Fail BNC signal out (not Ext Trig) and Beep or not.
Edit
And count violations.

Image shows a previous mask BUT the test is not running but still shows violations.
Using the Mask Setting softkey another menu is accessed and in which a single command is made to create a new mask. The second page of the mask menu shown has the beeper on and off plus Stop or not setting.

It is very quick and simple to use.

[kcbrown]

See reply #175, as already stated the scope can be set to Stop or continue running the Pass/Fail tests.

So you did!

I've always thought Pass/Fail tests were production/quality control related but of course they can be used along with  or instead of a comprehensive Trigger suite to find signal abnormalities so unlike you I believe Siglent's implementation of Pass/Fail is appropriate for production use.

Unless a trigger suite includes a mask capability, it's not "complete", really.  That's because a mask gives you the capability of implementing what amounts to arbitrary trigger conditions, which is very powerful.

If there is desire to enhance it's functionality instead of using the Trigger suite available then we need call for some user/owner input on how it might be implemented better.
Thanks for the discussion and as always constructive feedback is best for us to pass on to the engineers.

My pleasure.  Like I said, there's a lot to like about the Siglent, and I do like the fact that there's no guesswork as to how much time is captured with Siglent's implementation.  But it does have this shortcoming.  As I mentioned, that can be easily addressed by making it possible to define the mask with the zoomed portion of the zoom view.  The rate at which tests could be performed would then be determined by the frequency that the trigger fires and how much later the zoom window was relative to the trigger point at the time the mask was defined (because that delta determines how long the scope has to wait after the trigger fires before it can perform the mask test).

[nctnico]

Pass/fail .... but of course they can be used along with  or instead of a comprehensive Trigger suite to find signal abnormalities so ...

Definitely no. A trigger system works as a sliding window and catches all anomalies with 100% certainty. A pass/fail system no matter how fast it is will never achieve that level of certainty (you can prove this by math). Also when using pass/fail in a production test setup you have to control the trigger moment and signal going into the scope so you test what you need to test. What I find missing in typical pass/fail testing is the use of long (multi megapoint) records. If a long record is allowed you could check a circuit with (for example) a sweeped sine wave to check it's frequency characteristic including phase in one go.

[kcbrown]

Then the Siglent's approach to buffer management is a major fail here, since it is impossible to see the waveform's surroundings upon a mask failure with the Siglent's approach.  The other scopes score a major win over the Siglent for this.

I have another question about Siglent's memory handling here.

When you have the window showing a large range (i.e, the bit you want to actually capture), if multiple trigger events happen within that window, will the scope capture all of them?   Or does it presume one trigger event per window range?

If the latter, then the usability of the memory mechanism is potentially more limited than that of a "normal" implementation, since it means that you can't simultaneously have a large capture and a fast update rate.  A simultaneous large capture and fast update rate is possible to implement if the trigger mechanism just records pointers into the capture memory.  You can get what amounts to "segments" that way.

For instance, suppose my window covers 1 millisecond worth of time, but my trigger event happens every 10 microseconds.  A scope that can capture 100K wfm/s could keep up with the trigger event rate, but a naive implementation would insist on capturing 1K wfm/s due to the window size and assumption that only one trigger event can be recorded within the window.  Alternatively, it might waste a bunch of memory by storing what amounts to overlapping samples, thus limiting the number of captured segments.   

A good implementation would, I should think, normally perform a continuous capture and have the trigger mechanism note where within the capture the trigger events can be found.  The display subsystem could then just grab a window's worth of data around the trigger point and display it.  If the display subsystem is too slow to keep up with the trigger events, it can skip forward to the latest trigger point for which a full window's worth of data is available in the buffer, and display that, then lather, rinse, repeat.   But if one then stops the scope, all of the trigger events would be available and one could then review it either as "segments" or as a continuous stream.

The downside of that model is when a trigger event fails to materialize within the remaining amount of memory after the previous capture -- you'd be forced to start discarding the earliest part of the buffer, which has trigger events, in order to continue to capture data which might have none.   Which is why you also want an explicit segmented capture mode.  The way I'd do this would be to perform continuous, contiguous streaming as long as trigger events happen more often than the segment width, but once the distance from the last sample to the last trigger event exceeds 1.5 segment widths, the scope would treat the segment's width worth of memory immediately preceding the last sample as a circular buffer, and continue capture into that until half a segment's width of captures have been gathered after the trigger point, at which point capture mechanism would continue the capture in the memory starting immediately after the end of that last captured segment.   This whole approach might have some fatal flaws (I don't spot any off the top of my head, but the presumption in this approach is that you can arbitrarily change the target address of the capture system between the prior sampling operation and the next, something that might prove difficult to achieve when sample rates are happening at CPU clock speeds or greater -- it would definitely require ASIC hardware to pull it off).


Oh, and apologies if any of the above looks incoherent.  I'm operating on rather little sleep.

[tautech]

A lot of what you seek is in the first 2 pages of this thread in the tables prepared by rf_loop.
Although it's somewhat academic with a new version of these models, the X-E with more processing power not far away.
Waveform update rates are to rise ~50% and these new models will need to examined further for more info on memory use and allocation.

That might lead this discussion towards the HW in the SDS2kX series which has twice the update rate of the SDS1kX and 10x the memory.
The below thread was started when the V2 firmware was released that the SDS1kX and at that time SDS2k shared and of course the 2k has been further upgraded to SDS2kX.
A good place to pick up on this thread is here where the first tables start and member Performa01 takes the stand with his in-depth findings.
https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg810344/#msg810344

[rf-loop]

Then the Siglent's approach to buffer management is a major fail here, since it is impossible to see the waveform's surroundings upon a mask failure with the Siglent's approach.  The other scopes score a major win over the Siglent for this.

I have another question about Siglent's memory handling here.

When you have the window showing a large range (i.e, the bit you want to actually capture), if multiple trigger events happen within that window, will the scope capture all of them?   Or does it presume one trigger event per window range?

If the latter, then the usability of the memory mechanism is potentially more limited than that of a "normal" implementation, since it means that you can't simultaneously have a large capture and a fast update rate.  A simultaneous large capture and fast update rate is possible to implement if the trigger mechanism just records pointers into the capture memory.  You can get what amounts to "segments" that way.

For instance, suppose my window covers 1 millisecond worth of time, but my trigger event happens every 10 microseconds.  A scope that can capture 100K wfm/s could keep up with the trigger event rate, but a naive implementation would insist on capturing 1K wfm/s due to the window size and assumption that only one trigger event can be recorded within the window.  Alternatively, it might waste a bunch of memory by storing what amounts to overlapping samples, thus limiting the number of captured segments.   

A good implementation would, I should think, normally perform a continuous capture and have the trigger mechanism note where within the capture the trigger events can be found.  The display subsystem could then just grab a window's worth of data around the trigger point and display it.  If the display subsystem is too slow to keep up with the trigger events, it can skip forward to the latest trigger point for which a full window's worth of data is available in the buffer, and display that, then lather, rinse, repeat.   But if one then stops the scope, all of the trigger events would be available and one could then review it either as "segments" or as a continuous stream.

The downside of that model is when a trigger event fails to materialize within the remaining amount of memory after the previous capture -- you'd be forced to start discarding the earliest part of the buffer, which has trigger events, in order to continue to capture data which might have none.   Which is why you also want an explicit segmented capture mode.  The way I'd do this would be to perform continuous, contiguous streaming as long as trigger events happen more often than the segment width, but once the distance from the last sample to the last trigger event exceeds 1.5 segment widths, the scope would treat the segment's width worth of memory immediately preceding the last sample as a circular buffer, and continue capture into that until half a segment's width of captures have been gathered after the trigger point, at which point capture mechanism would continue the capture in the memory starting immediately after the end of that last captured segment.   This whole approach might have some fatal flaws (I don't spot any off the top of my head, but the presumption in this approach is that you can arbitrarily change the target address of the capture system between the prior sampling operation and the next, something that might prove difficult to achieve when sample rates are happening at CPU clock speeds or greater -- it would definitely require ASIC hardware to pull it off).


Oh, and apologies if any of the above looks incoherent.  I'm operating on rather little sleep.

If you go to sleep now, you perhaps can meet this dream miracle oscilloscope.


Siglents memory handling?

Is it better to ask  first how basic digital oscilloscopes works in principle.
Perhaps somewhere is room for start new topic where can handle common questions about basic principles how things work. This is not Siglent question.

Is it so that first we need handle:
what is "trigger" 
what is "capture"

Why we need name Siglent here. I can answer. Name Siglent is here for nonsense.
This is why I think this trivia is best to start in its own thread - What is oscilloscope and how it works.


But here is simple answer:  After triggered it capture and during this period running capture not interrupted what ever happen in trigger system.  It continue to capture memory (at this time you can think trigger system is "blind")  end and after then, bit later, it can trigger again.

In old analog oscilloscope:
waiting trig - Trig - visible sweep from left to right with selected speed - blind return - waiting trig...........

Underlined time: you can think, whole trigger is just sleeping.

There is now one main difference in (today) digital scope usually but no need go now to details.

Siglent trigger do not differ from common principle.




But then as sidenote:
It can easy understand why these and many other things are so difficult to imagine and understand. Thanks for example this kind of material what Keysight do not even shame to publish @2016
https://community.keysight.com/community/keysight-blogs/oscilloscopes/blog/2016/09/01/understanding-oscilloscope-trigger-system-basics-why-you-should-care

Still in year 2016 even  Keyshit teach:

How It Works
Most real-time oscilloscopes have an “analog” trigger system. This system is actually a mishmash of analog circuitry and digital counters but it relies on input from analog comparators fed from the scope pre-amp. Some oscilloscopes now feature a “digital” trigger, meaning that the trigger system is entirely digital and is fed with integer data from the ADC output. Both types of systems perform the same function; evaluating whether or not all of the configured trigger conditions are met at a given moment in time. Because fully digital trigger systems are fairly rare, we’ll focus on analog trigger systems.

Pity.

[kcbrown]

If you go to sleep now, you perhaps can meet this dream miracle oscilloscope.

Well, I just woke up and, sadly, no, I didn't meet it.   

Siglents memory handling?

Is it better to ask  first how basic digital oscilloscopes works in principle.
Perhaps somewhere is room for start new topic where can handle common questions about basic principles how things work. This is not Siglent question.

Is it so that first we need handle:
what is "trigger" 
what is "capture"

Why we need name Siglent here. I can answer. Name Siglent is here for nonsense.

No.  We need Siglent's name here because how one configures what the Siglent 1000X and 2000X scopes capture differs from other scopes, and that has implications.

This is why I think this trivia is best to start in its own thread - What is oscilloscope and how it works.


But here is simple answer:  After triggered it capture and during this period running capture not interrupted what ever happen in trigger system.

OK, let's be clear here.  By "capture", I mean that the scope records samples produced by the ADC into memory.

Clearly, the trigger event doesn't start capture, because you can see parts of the waveform on the screen that preceded the trigger event.  So the capture mechanism was obviously operating before the trigger fired.

It continue to capture memory (at this time you can think trigger system is "blind")  end and after then, bit later, it can trigger again.

Right.  So again, going back to the Siglent, does the Siglent wait until the end of the window before re-arming the trigger?

It's important, because unlike most other scopes, what it captures is only what is in the display window.  If the Siglent waits until the end of the window before rearming the trigger, then that means that other scopes can achieve a higher waveform rate for a given capture size than the Siglent can.


Let's take that 1 millisecond window size again.  On the Siglent, that represents the size of the capture.  If the Siglent waits until the end of the window to rearm the trigger, then that means the Siglent can, with a capture size of 1ms, capture at most 1k waveforms/sec.   On other scopes, the size of the capture exceeds the size of the window (potentially by quite a lot).  You could, for instance, set up a window size of 100us, and get a capture rate of 10k waveforms/sec while capturing 1ms worth of data for each.  That's precisely because there is nothing at all that demands that the scope wait until the end of the buffer before rearming the trigger.

[rf-loop]

Please show me scope what stop acguisition and start new one before used acquisition length is reached if there exist something what match trigger settings.  If I meet this kind of scope I will send it for repair.

[kcbrown]

Please show me scope what stop acguisition and start new one before used acquisition length is reached if there exist something what match trigger settings.  If I meet this kind of scope I will send it for repair.

Hmm....I thought my Rigol did that, but then I went and looked and sure enough, it also waits for the end of the capture buffer before allowing another trigger!

Why in the world do scopes do this?  What possible advantage can there be for it???

[rf-loop]

Please show me scope what stop acguisition and start new one before used acquisition length is reached if there exist something what match trigger settings.  If I meet this kind of scope I will send it for repair.

Hmm....I thought my Rigol did that, but then I went and looked and sure enough, it also waits for the end of the capture buffer before allowing another trigger!

Why in the world do scopes do this?  What possible advantage can there be for it???

Is it better to ask: Why in the world oscilloscope need work different?

But some times we need example fast segmented memory acquisition but even there once trigged it do one segment length acquisition  and do not interrupt it if during this exist new trig.

If not need long memory, why use long memory. Some times even 10 points memory length is enough. (or 14 sample points what is minimum with Siglent SDS1kX and 2kX)

[kcbrown]

Please show me scope what stop acguisition and start new one before used acquisition length is reached if there exist something what match trigger settings.  If I meet this kind of scope I will send it for repair.

Hmm....I thought my Rigol did that, but then I went and looked and sure enough, it also waits for the end of the capture buffer before allowing another trigger!

Why in the world do scopes do this?  What possible advantage can there be for it???

Is it better to ask: Why in the world oscilloscope need work different?

Seriously?  The answer is that the oscilloscope is (or should be) a general purpose waveform acquisition and display instrument.  A high trigger rate with a small buffer is not as useful as the same trigger rate with a larger buffer, because the latter allows you to stop the scope and examine much more of the surroundings than does the former, and a high trigger rate, especially when combined with a good persistence display, allows you to see glitches more readily.   The existing approach apparently forces you to choose between seeing glitches more readily versus deep capture, and that is obviously not necessary.

But some times we need example fast segmented memory acquisition but even there once trigged it do one segment length acquisition  and do not interrupt it if during this exist new trig.

Who said anything about interrupting the capture?   You're limiting your thinking to how the scope currently works, but how it currently works seems to impose artificial limitations that don't have to be there.  Or, at least, I don't see any reason they have to be there.  That's why I asked what I did: why does the trigger rate have to be limited by the capture size?   What could possibly be gained by imposing such a limitation?

If not need long memory, why use long memory. Some times even 10 points memory length is enough. (or 14 sample points what is minimum with Siglent SDS1kX and 2kX)

Yeah, but we're not talking about the case where you don't want (or don't care about) long memory.  We're talking about the case where you do want long memory.   Why do you have to give up trigger/capture rate in order to get that?

If I set up my window to display 100us and my buffer is large enough to capture 1ms worth of data, why must my trigger detection rate be limited to 1k trigger events per second, instead of 10k trigger events per second?   Or even more, for that matter   Nothing says that the trigger rate need be limited by the window size, either.  If I'm displaying a 100KHz sine wave, why can't my trigger fire at a rate of 100KHz if the trigger system itself is capable of keeping up with that?

[nctnico]

That is true. After all you only need to get the full acquisition record after the last trigger. There are more 'if when how why & whats' to it (math and decoding for example) but the basic idea is that you can use the displayed width as the driving factor of the trigger rate instead of the acquisition length to maximise the waveforms/s rate.

[rf-loop]

If I set up my window to display 100us and my buffer is large enough to capture 1ms worth of data, why must my trigger detection rate be limited to 1k trigger events per second, instead of 10k trigger events per second?

If simplify this thinking and set as it is in principle in analog scope.
Let's think trigger position is beginning of display, left border and starting of capture memory is same.
Lets think that display width is this 100us  and sample rate is 1GSa/s. This means that this displayed part on capture memory length is 100000 samples. 100k
* Lets also think that whole capture memory length in use is 1ms. This means acg. memory total length is 1000000 samples. 1M. (900k after display border.)
*(this can not be Siglent because next capture can do after display right border is reached and after trigger is rearmed)


Now think it trig and start  capturing to memory and then arrive to position where is captured first 100us. Now trigger circuit find there exist something in signal what meets user defined trigger rules.  What you want now do.
Reject the trigger and continue capturing to end of defined memory and after then start waiting signal meets trigger settings and trig  new capture.   
Or, do you want that after this 100us position if trigger find new trig event it start new capture from beginning and do not use rest of capture memory, what if it happen in  this turn at 150us position from start and next time 200us position and next turn 107us and it vary so that every turn is different. Or do it keep some fixed length of capture memory or what?.  Or do it just stop fill memory at  display border and wait next trig.  In this last case capture length is fixed 100k.

Remember that what ever you overlay stack on the screen, every single waveform  trigger time position need very precise adjust to same as previous trigger position. Using much smaller time interval  what is sampling interval. This is why there is fine interpolation.
But  first how you want do with these triggers and capturing in real world.

[kcbrown]

If I set up my window to display 100us and my buffer is large enough to capture 1ms worth of data, why must my trigger detection rate be limited to 1k trigger events per second, instead of 10k trigger events per second?

If simplify this thinking and set as it is in principle in analog scope.

You could do that, but a DSO is not actually an analog scope -- it is capable of so much more -- so to limit the DSO to the behavior of an analog scope is to artificially limit the capability of the device.

Let's think trigger position is beginning of display, left border and starting of capture memory is same.
Lets think that display width is this 100us  and sample rate is 1GSa/s. This means that this displayed part on capture memory length is 100000 samples. 100k
* Lets also think that whole capture memory length in use is 1ms. This means acg. memory total length is 1000000 samples. 1M. (900k after display border.)
*(this can not be Siglent because next capture can do after display right border is reached and after trigger is rearmed)


Now think it trig and start  capturing to memory and then arrive to position where is captured first 100us. Now trigger circuit find there exist something in signal what meets user defined trigger rules.  What you want now do.

Reject the trigger and continue capturing to end of defined memory and after then start waiting signal meets trigger settings and trig  new capture.   

Nope.  No need to reject the trigger.

Or, do you want that after this 100us position if trigger find new trig event it start new capture from beginning and do not use rest of capture memory, what if it happen in  this turn at 150us position from start and next time 200us position and next turn 107us and it vary so that every turn is different.

You don't start a new capture (more precisely, you don't start writing to the beginning of the buffer again).  You record the location of where in the buffer the trigger fired, and you keep recording samples to memory.   Meanwhile, you have a decimation processor that goes to the previously recorded trigger points and does the proper sample combining starting at those points to store into the histogram buffer.

You have the display processor display the contents of the histogram buffer as quickly as it can, during which it'll decrement the values it finds in the histogram buffer (which is sized the same as the waveform display area in terms of pixels).  The acquisition system continues to acquire data during this period of time, and continues to record the locations of trigger events in the buffer.

When the display processor finishes showing the waveform, it repeats its display of the histogram buffer, over and over.

It should be obvious that the display processor operates in parallel with the acquisition system, as does the decimation processing.

Or do it keep some fixed length of capture memory or what?.  Or do it just stop fill memory at  display border and wait next trig.  In this last case capture length is fixed 100k.

If we're talking about the scope operating in "normal" trigger mode, then it would obviously continue to capture in the other buffer (this would be a double buffered setup, precisely so that acquisition can continue while preserving the contents of the prior capture) after filling the current acquisition buffer up to the point that precedes the trigger point by 500us, or however much precedes the trigger point, whichever is shorter.   Remember that the buffer is circular and doubled.   Why 500us?  to put the trigger point precisely in the center of the capture.

If the scope is operating in "auto" trigger mode then the "auto" trigger mechanism will insert periodic fake triggers into the system, which the downstream processing can treat as normal triggers.

Once the scope is stopped, the scope can show the locations of all the trigger events in the capture, if there are any aside from the "current" trigger event (about which the scope would attempt to center the capture).

Remember that what ever you overlay stack on the screen, every single waveform  trigger time position need very precise adjust to same as previous trigger position. Using much smaller time interval  what is sampling interval. This is why there is fine interpolation.
But  first how you want do with these triggers and capturing in real world.

Of course.  See above.  It's a rough idea, but hopefully I'm describing the idea well enough.

[rf-loop]

I take this here because for more polite I do not want smudge royal R&S thread for this.

Just for compare, (previous detail image from R&S  @agdr
Same settings (afaik)
Around same ballpark (note BW diffeerence R&S 300MHz  / Sig measured BW around 200MHz, nameplate  BW 100MHz)

Noise comparisons have to use the same analog bandwidth, same memory depth, same sample rate, and same update rate, otherwise they are not apples-apples.

1. I told, using my whole experience and knowledge, They are "around same ballpark" and I stay ground under my legs behind this until real evidence about anything else.

Of course this answer also include knowledge how different these scopes are - just in very different performance class and in very different price class. There is not from me ANY even single doubt that R&S is higher class scope and this was not reason. There was also not reason to "compete" with R&S using just Siglent.  Whole reason was that I can see there images where was enormous noise visible on the R&S screen in first phase and knowing R&S it feels very strange.  Also there was shown that there was used quite good signal generator. After then I want show that even simple and cheap Siglent with even Siglent function generator have lot of less noise - so there must be something wrong.

After then, later,  I realize that this some signal image enormous noise was from really noisy signal generator. (even in case there was used 60dB attenuation. (Also I use - 60dB attenuator).

After then I can see there was scope base noise images without signal.
There was averaging and so on but one trace what show quite low noise also without any trics, exept that trace was dimmed so that peak values nearly invisible and eye may think this more clearly visible trace was including peak values. But after change image Gamma It was clear that peaks was just nearly hidden if look fast this image. There was R&S measurements on but very very pity, only peak (900uV)

After then Dave throwing this a simple answer.

"Noise comparisons have to use the same analog bandwidth"

No. This is for him who have low experience and  unable to evaluate and  calculate the aid with the assessment.
How much BW itself affect. And here we talk mostly random noise.
Everyone who do anything with signals know this: 10 log (BW1/BW2)
If compare 100MHz and 1000MHz BW random noise there is around 10dB difference.
Between 100MHz and 300MHz there is around 4.8dB difference. (if this and that and those things are same and so on)
But in practice, (I do not say just this R&S) many times 100MHz scope analog BW is well over 150MHz, in this case around 180MHz.  Bit I doubt that R&S BW is not 3 times more. Perhaps 2 - 2.5x.
If it is 2.5x  then 4dB and if 2 then 3dB

Now, R&S 900uV peak. Siglent ~600uV.  Difference around 3.5dB. (peaks. So do not put too much weight for this!) 
Siglent RMS we know. Roughly around 64uV mean with 10uV SD.

"same memory depth, same sample rate, and same update rate"

Of course, when we talk random "white noise" peak values.

This is why in my example there is RMS and not only peak.
But if peak alone.
Update rate do not mean. Measurements are made from single acquisition data, not from screen pixels.
Visual trace fatness may rise with fast update rate. But, when intensity gradation works well, visually it also give image about noise distribution (situation here is terrible if not intensity gradation). Both scopes show it clearly. And if have experience it can very easy say they are Roughly around same ball park. Also in both can see not only only one or two highest peaks.  If look carefully these images can get good image about noise distribution.
On Siglent screen width there is 280000 samples. Every frame have visible not only single shot but around 60 acquisitions so around 16.8 Msamples  mapped and visible on the screen. So there is well enough also for peaks.
I do not know how much data there is in R&S screen.  But I doubt that not so much more, more I think less.
My estimate was that this do not  make big difference and not prevent me with my experience to make decision "Roughly around same ballpark"

For make more comparative measurements it is very important to use noise RMS.
(This is why I also show it there)
For visual image compare need be really careful if acquisition and collected data is not enough comparable. 

If we use peak values, it need think bit more deeply how comparable measurements are if they do not have same amount of data.  Samplerate rise amount of data but.... But it need note that also this is not so trivial how it affect. Higher samplerate generated more data may even have adverse effect.  If we have 1MHz BW and samplerate say example 10MSa/s and we collect 10M ssample data. Then we use 10Gsa/s for this 1MHz BW. And we take sequential 10Msample. Now we have same amount of data.  But from 1000 times less time gap. Probability for get highest peaks is less! (note Samplefrequency/BW)

Of course also need take to account that random white noise is only part of truth in practice.
Also need take care that if scope is example 500MHz it is well possible that without selectable BW rejection aand also in some scopes most sensitive vertical setting is perhaps not with full resolution (this may rise or hide some noise) there still may be less BW for most sensitive V/div settings. In Siglent SDS1kX 100MHz even 500uV/dif is full resolution and full BW.

[sp2iqw]

Before I bought Siglent SDS1102X oscilloscope, I analyzed what I would get for the money.
When I turned on and performed few sessions of  measurements I came across unpleasant surprises.
I am almost inclined to return the oscilloscope. I suppose the cause is not the malfunction of this particular unit, but a design error, or rather firmware.

Check short report: https://drive.google.com/open?id=0ByQgomgYIGXpY1pjSFhUN0hRMUU

Will somebody take me away from this step?

Michal

[tautech]

Before I bought Siglent SDS1102X oscilloscope, I analyzed what I would get for the money.
When I turned on and performed few sessions of  measurements I came across unpleasant surprises.
I am almost inclined to return the oscilloscope. I suppose the cause is not the malfunction of this particular unit, but a design error, or rather firmware.

Check short report: https://drive.google.com/open?id=0ByQgomgYIGXpY1pjSFhUN0hRMUU

Will somebody take me away from this step?

Michal

Nowhere do I see you mention the firmware # your unit has installed, the latest 13R5 is available here:
http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS1000X%20_V1.1.1.2.13R5.rar
I have had a look at your pdf and I see a possible explanation for some of the things you see, that being mostly 1M termination. Did you try 50 ?
The only other comment I can add is that memory depth settings seem low, have you tried to adjust them to the max for each timebase setting ? Did you notice now the memory depth has halved when you enable the second channel ?......less data points = less accurate waveform reconstruction.
Another thing I ask; is this your first DPO as there is much more waveform info placed on the display for you to interpret.....don't want it....use Dot mode. 

For the LAN connection to work you must also have the correct version of MS .NET framework installed.