Siglent SDS1104X-E and SDS1204X-E Mixed Signal Oscilloscopes

[HendriXML]

It's always hard to find the rational of a bug. 

I think it is a bug, but probably limited to trigger location and not a "false positive".

From a gut feeling I don't think the logic which causes the bug is acting on raw / primary data. I guess it is preprocessed and handling on thing like crossings and slopes and times between them and other stuff. Resuse of some preprocessing between trigger types might be the reason. Maybe this preprocess outputs stuff which was not expected by the programmer. While only handling rawdata this specific triggertype seems not to hard to get right. But maybe the functional requirements are more complex than I think. For instance I don't understand the need for some hysteresis yet.

Maybe I'll put your (noisy) wave in my awg and see if that replicates the bug. With an awg more manipulations can be done, thus more experiments / hour 

It's sad that my awg only handles 16k of samples. But putting min/max voltages after each other should give a comparable wave.

Also simpler waves can be tried.

[kcbrown]

It's always hard to find the rational of a bug. 

This is definitely true!

I think it is a bug, but probably limited to trigger location and not a misfire.

I'm not sure I follow.  What's the difference between when the trigger fires and the "location" of the trigger?   The "location" of the trigger is, I thought, defined by when it fires.   There can be preconditions (latches) that are set as part of the trigger operation, but when it fires is its location.

There are two pieces of evidence which say that the trigger is firing when it shouldn't:

• The trigger location is exactly halfway into the capture when the issue happens, exactly as it is when the trigger fires normally
• The waveform at the trigger location always meets the final condition of the trigger (here, a rising edge through 4.5V).

From a gut feeling I don't think the logic which causes the bug is acting on raw / primary data.

That's possible.   But that contradicts what rf-loop has repeatedly insisted about how the trigger works, namely that it operates directly on the basis of the ADC output.

I guess it is preprocessed and handling on thing like crossings and slopes and times between them and other stuff. Resuse of some preprocessing between trigger types might be the reason. Maybe this preprocess outputs stuff which was not expected by the programmer. While only handling rawdata this specific triggertype seems not to hard to get right. But maybe the functional requirements are more complex than I think. For instance I don't understand the need for some hysteresis yet.

That, too, is possible.  But if I had to speculate as to the cause of the issue, I'd say that it's happening as a result of the trigger mechanism failing to reset the initial condition latch (which, in this case, is the rising edge requirement through 3.5V at t between -1.5ms and 0.5ms), and firing again after it had already fired on the earlier section of the waveform.

Hmm...that suggests the possibility of a test.  Is there anything that indicates, down to the picosecond, when the trigger fired?  I ask because I can set the memory depth to 1.4Mpoints, and that would give me 10 segments worth of captures.  If the segment data includes the relative time at which the trigger fired, then we can look at the time of the incorrect capture segment relative to the time of the immediately prior segment.  If the difference is less than one waveform period then we'll know for sure that the issue is with the initial condition latch not being reset.

Hmm...looks like if you enable the list in the segment history, it'll show you the time of the segment.  It doesn't take you all the way down to the picosecond, but it may be good enough for our purposes here.  I've got a test running now with that setup, but it hasn't reproduced yet.  Should be interesting to see what happens.

Maybe I'll put your (noisy) wave in my awg and see if that replicates the bug. With an awg more manipulations can be done, thus more experiments / hour 

It's sad that my awg only handles 16k of samples. But putting min/max voltages after each other should give a comparable wave.

Also simpler waves can be tried.

It'll be very interesting to see what you find!   What AWG do you have?

[HendriXML]

A SDG1032

Hardware wise it can act on raw data from the ADC, but I mean software wise there can be separated pieces of logic. Programmers like to create "engines", but these may hide or introduce stuff.. mostly it is going from lower level decision making to higher level decision-making.

The trigger system is propably run on a FPGA, which I have no experience with, but I imagine it involves "piping" data between different logic blocks. 

In my thinking a trigger is what stops the continuous capture of samples. At that moment there's pretrigger data. Post trigger data need some more samples.
(It doesn't need to be 50%/50%. The horizontal position knob can make it more or less.
In that sense it seems not buggy. However showing the location and the amount of pre/post trigger data is faulty. Hence giving a wrong impression of what actually triggered it.
This is just guessing, someone has to dive into the software to get the "rational" behind the bug. But by experimenting more can be known about it.

[rf-loop]

In my thinking a trigger is what stops the continuous capture of samples. At that moment there's pretrigger data. ...

Excuse me but ... What 


These speculations after speculations goes now so wild that... perhaps some other things are more useful.

In solving problems, it is essential to question all assumptions all the time. Likewise, a so-called negation test must be performed at each bend.
Break the reasoning chains often enough based on some assumptions that make it easy to see other options, dead ends, or closed-circle conclusions.

Exclude things, in good order, but only when they can be ruled out using real hard core facts. Proceed logically.
Unfortunately, in this case, it also requires knowledge of the details of the internal HW structure of the device as well as the SW structure, which is not public information.

All, go on, keep going!... I look at the side. I'm bit too old fox for playing fun.  Yes it is "laying fun" because it can not solve here.
But other ways this level and kind of "playing fun" can be also overall really useful for learning purposes.

Lets hope Siglent can repeat this problem in lab and find root reason.    if not find any other explanation but error in system

[kcbrown]

A SDG1032

Hardware wise it can act on raw data from the ADC, but I mean software wise there can be separated pieces of logic. Programmers like to create "engines", but these may hide or introduce stuff.. mostly it is going from lower level decision making to higher level decision-making.

Of course, with FPGAs, the line between software and hardware is rather blurred.   

In my thinking a trigger is what stops the continuous capture of samples. At that moment there's pretrigger data. Post trigger data need some more samples.
(It doesn't need to be 50%/50%. The horizontal position knot can make it more or less.

It's probably more like that the trigger indicates at what point in the stream of data that the trigger conditions have been met, and then the scope would put markers in the appropriate places at the appropriate times.   There are lots of ways to approach that problem, some more efficient than others.

In that sense it seems not buggy. However showing the location and the amount of pre/post trigger data is faulty. Hence giving a wrong impression of what actually triggered it.
This is just guessing, someone has to dive into the software to get the "rational" behind the bug. But by experimenting more can be known about it.

Well, see, this is where the fact that the final condition is always met at time 0 comes into the picture.  Yeah, if that weren't the case, then maybe it would just be a problem with the time indicators.  But in this case that final condition is *always* met at t = 0.

[kcbrown]

That, too, is possible.  But if I had to speculate as to the cause of the issue, I'd say that it's happening as a result of the trigger mechanism failing to reset the initial condition latch (which, in this case, is the rising edge requirement through 3.5V at t between -1.5ms and 0.5ms), and firing again after it had already fired on the earlier section of the waveform.

Hmm...that suggests the possibility of a test.  Is there anything that indicates, down to the picosecond, when the trigger fired?  I ask because I can set the memory depth to 1.4Mpoints, and that would give me 10 segments worth of captures.  If the segment data includes the relative time at which the trigger fired, then we can look at the time of the incorrect capture segment relative to the time of the immediately prior segment.  If the difference is less than one waveform period then we'll know for sure that the issue is with the initial condition latch not being reset.

Hmm...looks like if you enable the list in the segment history, it'll show you the time of the segment.  It doesn't take you all the way down to the picosecond, but it may be good enough for our purposes here.  I've got a test running now with that setup, but it hasn't reproduced yet.  Should be interesting to see what happens.

Turns out that at 1ms/div, the standard acquisition rate of a 60Hz signal is just too slow to make it clear whether or not the trigger is firing in that way, with acquisitions happening somewhere between 50ms and 66ms per frame.  In order to ensure consistent acquisition at 16ms per frame (i.e., at the period of the signal itself), I had to drop to 500us per division and 140k points per frame.  With that setup, I get a consistent 16ms per frame even with the mask test enabled, and I'm now running that test.  Should be interesting to see what comes of it.

[HendriXML]

In my thinking a trigger is what stops the continuous capture of samples. At that moment there's pretrigger data. ...

Excuse me but ... What 

That got you triggered   
Yes that is my "user point of view". And I cannot imagine it being to far off, with a bit of flexible thinking.

But yor response got me triggered as well 

The best way to attack this problem would be to have a Siglent engineer to enter the party and look at the buggy logic.
Without that speculation is needed to come to new testcases.

As said I don't think thorough knowledge of the system is required for that. You could sit by and relax for that matter..

For me this exercise is purely for fun, I don't get paid. In meanwhile interesting techniques might come by, like showing settings in a readable format, creating Excel graphs, transferring waveform to arw. For me its about being creative, and thus flexible. My guess this accounts for many of the forummembers.

As said before much more can be said..
Like about approaching problems and maybe life itself, rigid vs flexible. For hobiest it should not only be about progressing in greater understanding of electronics, but mostly about keeping it enjoyable. Otherwise the hobby might kill it self, or worse continue as a source of frustration.

[2N3055]

Datapump, digital trigger, buffer management all of that is not that simple in real life scope for "little Johny" approach.
While it might seem simple on the outside, there are many tricks to make it work. Most of the real details how it works on specific scope won't be revealed by manufacturer, and never will be.
They don't care for your, mine or anybody's curiosity. They are not open source.  It is their, sometimes very expensive intellectual property.

This relationship works by customers finding a bug, reporting it, both customer and vendor work on proving there is a bug and how to repeat it , so it can be reported to engineers. Engineers than have to analyse problem and find cause. Then they devise solution, and test that in house. Once it is solid enough in their internal testing, it gets merged in next release, where it also gets tested as a release. Then it gets released..

Explaining things to you or me is nowhere in that list..

[HendriXML]

I´ll show the steps I take to get a waveform ready for the Awg. Recently I did the same with a recorded wave of a car battery cranking the engine. To test a battery guard circuit I designed, good fun!

First step: it needs to be smaller than sample memory of AWG:
So I limited the samples to 16384, decimating by taking from each 855 samples a minimal and maximal value.
Thus kind of maximizing the noise (important in this case). I've put them also in the right order. That might be important.
Time wise, all the resulting samples will be a bit off (I don't think that will matter much.). The awg can't use timestamps of each sample, its just plays them like a wav-file one sample after another on a set clock speed. From my understanding this can be only be done this way by a true arbitrary wave generator like the SDG1032. A Direct Digital Synthesis generator has a fixed frequency and will skip or duplicate samples.

I did remove quite a few samples from the beginning. In basic wave mode waves will be repeatly played, and a large voltage difference between end and start, would lead to "spikes". In the example wave this wasn't even bad, but I still optimized it a bit.

I will now take those samples and upload them to the AWG. This means finding the min/max values of the complete wave and map them to 16 bit integers.
Because the awg waves can also be played in burst mode, the following: In that mode the waves can be seperated in time by x second, played a certain times and more. It then becomes important where the midpoint of the wave is (int: 0).
For example we could map the lowest voltage 3.30 V to the lowest integer -16384 but then the offset voltage of the burst wave would need be much higher than 3.30V. Thus after each wave playback it would jump to that higher voltage.
If we map the lowest voltage to integer 0, we can take a offset of 3.30V and no sudden jumps shall be made. But with the loss of a bit of resolution. The Awg has a 14 bits dac, relative to the scope that is more than enough.

[kcbrown]

Turns out that at 1ms/div, the standard acquisition rate of a 60Hz signal is just too slow to make it clear whether or not the trigger is firing in that way, with acquisitions happening somewhere between 50ms and 66ms per frame.  In order to ensure consistent acquisition at 16ms per frame (i.e., at the period of the signal itself), I had to drop to 500us per division and 140k points per frame.  With that setup, I get a consistent 16ms per frame even with the mask test enabled, and I'm now running that test.  Should be interesting to see what comes of it.

And of course, at 140k points, the sample rate drops to 20MS/s.  Worse, it seems that even at 140k points, I'm not reliably getting 16ms between captures (the issue *did* reproduce at 140k points, once, and the time difference between the good frame and the bad frame was longer than 16ms, but the problem is that the time difference between some of the good frames was 32ms, and that makes the result inconclusive).  So I've dropped the capture size to 14k points, which drops the capture rate to 2MS/s.  That's low enough that it might not see the noise in the same way.  So far, after a number of hours, the issue has not reproduced itself under these capture conditions.

I'll keep it going, but I'm starting to lose hope as to being able to definitively determine whether the issue is the result of the final condition (passage through 4.5V on the rising edge) firing twice in quick succession, or if the issue is the result of the final condition failing to fire when it should.

[HendriXML]

I uploaded the wave to the awg and had it capture by the scope.

The limited sample memory results in coarse noise, other than that it might be usefull to replicate the bug.

Currently it triggers as it should, but I think it needs some further tweaking. No scopes are the same.

Might have to create a script to automate subtile changes. In that case the script should also be able to differentiate between valid and invalid triggering.

[kcbrown]

Have you looked more long time that if you turn 20MHz BW filter on then it never do this in this test setup or is it so that it do but much more rarely. If it totally stop this fail it is one important finding.

I still haven't run this test for a massively long duration.  If you can give me an idea of how long I should run a 20MHz bandwidth filter test, I'll be happy to do it.  Otherwise I'll presume that running it for, say, 12 hours, is sufficient.

I have one question about the acquisition system.  When I reduce the memory per capture, it drops the sample rate.  That's to be expected: it's having to spread the same amount of time over a smaller number of points with respect to what gets saved.  My question is this: does the ADC actually still run at a full 1GS/s for the triggering mechanism, and then the captured points are decimated to fit into the smaller number of sample points in the buffer?  Or is the ADC actually run at the stated sample rate and, thus, that sample rate is also what the triggering mechanism sees?

It matters, *a lot*.  If the sample rate really is reduced for the triggering mechanism then that could easily cause the issue to disappear if it's somehow time-dependent.

[HendriXML]

Have you looked more long time that if you turn 20MHz BW filter on then it never do this in this test setup or is it so that it do but much more rarely. If it totally stop this fail it is one important finding.

I still haven't run this test for a massively long duration.  If you can give me an idea of how long I should run a 20MHz bandwidth filter test, I'll be happy to do it.  Otherwise I'll presume that running it for, say, 12 hours, is sufficient.

I have one question about the acquisition system.  When I reduce the memory per capture, it drops the sample rate.  That's to be expected: it's having to spread the same amount of time over a smaller number of points with respect to what gets saved.  My question is this: does the ADC actually still run at a full 1GS/s for the triggering mechanism, and then the captured points are decimated to fit into the smaller number of sample points in the buffer?  Or is the ADC actually run at the stated sample rate and, thus, that sample rate is also what the triggering mechanism sees?

It matters, *a lot*.  If the sample rate really is reduced for the triggering mechanism then that could easily cause the issue to disappear if it's somehow time-dependent.

It has been said/confirmed that the trigger system always runs at max speed.

[kcbrown]

It has been said/confirmed that the trigger system always runs at max speed.

Ah, yes, so it has, and not too long ago at that: https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3360130/?topicseen#msg3360130

Sorry, my scope's memory is clearly better than mine ...

OK, so that raises the obvious question: should there be a difference in the ease of reproducing the issue on the basis of the capture size?   One would think not, given the above.

[bdunham7]

It has been said/confirmed that the trigger system always runs at max speed.

Ah, yes, so it has, and not too long ago at that: https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3360130/?topicseen#msg3360130

Not that this would matter in any other circumstance than discussing a bug in the trigger setup, but a more correct statement would be that the trigger subsystem is always receiving information from the ADC at the full sample rate.

How it chooses to look at that information is another matter.  It occurred to me that in the case of your slope trigger, we typically think of condition 1 as 'arming' the trigger and condition 2 as 'firing' it.  However, the logic could just as well wait for condition 2 and then go back and look at the data in the appropriate period and see if condition 1 was met.  Unless you have the source code you really aren't going to know. 

[HendriXML]

In pc programming such trigger system would preferably not be solved by searching in memory. There is no need to, because it is easy to solve single pass.
One could say event driven. Each sample is an event. In the case of the slope trigger the sample can be classified as low, mid or high.
The next thing is to create a "state machine". These consist of different states a system can be in. For the slope it could be:
Start, InLow, InMidpassed, InMid, inHigh
The machine starts with Start. From that it acts on events.
If the first sample is low, there is a state transition to InLow. If the second is low, it stays in there.
If then a mid event is handled, there is a state transition to InMidPassed, meaning it is in mid and the low pass condition is met.
If then a high event is handled, there is a state transition to InHigh, because it is out of InMidPassed we now know there was a slope.
If then a mid event is handled, there is a state transition to InMid, meaning it is in mid without the low pass condition
While handling events some extra data need to saved like time of last sample in low.

But as one can see, no need for searching..

As a statemachine this is a very simple one, it would strange in this situation to go from high to mid and end up in state InMidPassed..

One can also imagine that 2 of those systems can be linked. That one is acting on low-level events, creating high level events for the other. A valid way of creating complex systems - real-time. Actions are taken as fast as possible.

My guess is that the triggering system is such a chain.

[kcbrown]

OK, so that raises the obvious question: should there be a difference in the ease of reproducing the issue on the basis of the capture size?   One would think not, given the above.

And the answer is: there *is* a difference in the ease of reproducing on the basis of the capture size.  I am able to reproduce this most easily at 14M points and reasonably easily at 1.4M points.  It is nearly impossible to reproduce at 140k points (I reproduced it only once with that setting), and seems utterly impossible to reproduce at 14k points.

How do I know?  Because when I switch from 140k points to 1.4M or 14M points, I've had the issue reproduce right then and there, more than once.   Nothing of the sort has ever happened going the other direction.

Additionally, the mask display will show the number of frames it saw before failure, and that number grows significantly as the sample size decreases.

This has me scratching my head about what's going on here.  Unless the triggering system is using the number of sample points in some way, I can't explain how the number of sample points could possibly affect the probability of reproduction.   But it does.

[ballen]

It is explained bit more but unfortunately "scrambled by natural enigma". Our "enigma" is our Finnish language what is said is second difficult after Chinese in world. 
In some images there is some english/finglish explanations. But more deep text explanations just with Finnish.
https://siglent.fi/oskilloskooppi-tietoa-sds1004x-e--wfm-speed.html

I am slowly reading through this with help from Google translate.  It's very helpful, thank you for writing it!

PS: there is a typo in the second (all yellow) table shown in Figure 1, in the line with t/div= 1ms.  Column 6 contains 1G sa/s. It should read 1M sa/s.

Typing mistake corrected, thank you.

Something that would be very useful for me would be a block diagram of the scope.  This would help me to construct a good internal model for what it's doing.  Just a page or two back you posted a nice block diagram showing the input front end, the DAC for offsets, the ADC feeding the triggering system, but then it gets less precise.  Is there a more complete block diagram that shows the acquisition/history/sequence/frame system in some detail?

There is not this like of functional "block diagram" what also somehow give imagination what user then see when he is using scope.
Also I miss this kind of block diagram not for me but for perhaps for user guidance and counselling.
What I have is just my own made some kind of teaching "flip chart" material in mind what need also explanations by talking when show these images... but they are as they are now. There is some what give rough imagine about sequence, history  and so on but they only give very rough basic fuzzy imagine what is going on there.

Let me propose a collaboration.  If you provide some sketches for me (any standard software or format is OK) then I will write the text, and share it with you.  You can give me comments to help me correct it, and we can iterate.  After we are both satisfied, we can post it here as a teaching/learning aid for others.

[kcbrown]

So I decreased the time per division to 200us.  At 14M points, the issue still reproduces.  The reason I did that is that the processing is fast enough to fairly reliably activate the trigger every 16ms (the period of the full waveform).

What I've found is that when the issue occurs, the time difference between the prior good capture and the bad capture is 22ms.  This timing is very consistent when I have things set up so that it fires reliably every 16ms.

This is interesting because apparently what's happening, then, is that the trigger is somehow not firing on the rising edge, but instead is (when the issue reproduces) firing on the subsequent falling edge at the point it passes through 4.5V.

For instance:





In fact, interestingly, I've seen a case where it misfired twice in succession, yielding a 22ms delay between the good event and the first bad event, and then 16ms to the next bad event.  Here's the last good capture:




And the first bad capture:




And the second bad capture:




This is obviously very strange, but maybe this will help in getting this problem fixed.

@rf-loop, can you suggest any other tests I should perform aside from the 20MHz bandwidth test?  I'm about to set that one up and leave it running overnight.

[rf-loop]

Not related to previous "slope trig fail" things.

Many times I have seen peoples wonder what data trigger engine get when system use low sample rates.

Earlier, I presented some superficial conceptual picture of the principal structure of a system with respect to where the trigger engine is in the system. It is after ADC. It do not use decimated sample rate.

Next two images show one example how it affect in practice. This working mode we can name as SARI. Sequential Acquisitions Random Interleaving. Siglent do not tell anything about it. Example in next image signal 1st harmonic (base) is 1.8 times over fNyquist and it have least over 5 times fNyquist frequency components what are high level.

Of course this example is done for demonstrate what happen there so usually no one use just these settings for just this signal. Also there is CH2 open for nothing... except for drop ADC real samplerate to 500M. Also memory is set small for rise decimation to 10:1 just for better demonstrate this SARI.

Signal is 45MHz "square" but its true risetime is also nearly what can see.  As can see scope display sample rate 50MSa/s.
First image, gif animation, have 16 TFT frames repeating. It looks nearly as scope looks in real but real world it looks bit better.
Display mode is dots. SARI mode need dots mode.
Persistence is turned of for also better imagine situation so that really can see it continuously trig and trig position is right.

Every TFT frame include, least mostly, 16 acquisitions overlaid. Every single acquisition have 7 samples.
Every single acquisition sample interval is constant 20ns naturally but these 7 sample groups are in random time time position.

1st image is this continuously running situation as much as in real word with this setup. Oscilloscope true frame interval is continuous and roughly 40ms.

2nd image. It is one single frame from this 1st image animation.
If you count dots it can see there is 16 sequential acquisition. I have marked one individual acquisition with red circles.

Now if you think The Trigger Engine.
Look one red marked acquisition. It do not look like at all this signal. But it is right positioned. Trig'd, and well.
It need know that even if we have just only one single shot what is this red marked trace (7 dots) it is Trig'd.
But as can see these dots do not meet trigger at all. So, it have trig'd but display do not show reason!!
It is still part of our signal and well match with it... if we get more these well trig'd group of sequential samples we can see they are perfectly trig'd and positioned and show our signal. If you take just one shot it trig but then you look image... no reason, is it false trig... no. It is not.
We are working lot of over fNyquist. And our scope trig. But now carefully. This is not ETS! 
This mode can show signal image if signal is enough continuous just also as in ETS mode. But this SARI works ONLY with decimated samplerates!!!  It still can be good to know and use in some special situations. Of course this do not work at all if you turn interpolation on. Sinc or linear. It just can not. Naturally.

It also demonstrate in practice this fact that Trigger engine in this scope get really other than decimated sample rate.

Look, think carefully, do not loose thinking logic. Keep fun.


SARI mode. Scope do not have ETS but it have SARI what works something like ETS with decimated sample rates. True frame interval is roughly 40ms "
Sidenote. In this example with this setup wfm/s is very low around 400. Theoretical maximum is over 7000 with this setup with "ideal scope" but of course it do not exist in real world in this time layer.




One single frame from upper animation.
One single acquisition marked red in this single frame.

Can you see this red marked one acquisition displayed data that it have something why it is trig'd.
(I repeat, this have nothing to with fail slope trig discussed at same time in this thread, this is just only for demonstrate what it also mean when Trigger engine get true ADC data instead of decimated data.)

Look it, think carefully, do not loose thinking logic. And Keep Fun.

Note, this not "Siglent only". Of course same kind of things are in many modern scopes with digital trigger engine. Not perhaps same but something like this. How it perform - some better - some worse.

[rf-loop]

@rf-loop, can you suggest any other tests I should perform aside from the 20MHz bandwidth test?  I'm about to set that one up and leave it running overnight.

Just try to get evidence with this kind of other settings that BW On reject or stop wrong time captures.
Also please test overall can you find any effect using Trigger  Noise Reject ON.  I think previously you tried an no effect. But now you have more experiment with this fail so it is god to ask again.

[HendriXML]

OK, so that raises the obvious question: should there be a difference in the ease of reproducing the issue on the basis of the capture size?   One would think not, given the above.

And the answer is: there *is* a difference in the ease of reproducing on the basis of the capture size.  I am able to reproduce this most easily at 14M points and reasonably easily at 1.4M points.  It is nearly impossible to reproduce at 140k points (I reproduced it only once with that setting), and seems utterly impossible to reproduce at 14k points.

How do I know?  Because when I switch from 140k points to 1.4M or 14M points, I've had the issue reproduce right then and there, more than once.   Nothing of the sort has ever happened going the other direction.

Additionally, the mask display will show the number of frames it saw before failure, and that number grows significantly as the sample size decreases.

This has me scratching my head about what's going on here.  Unless the triggering system is using the number of sample points in some way, I can't explain how the number of sample points could possibly affect the probability of reproduction.   But it does.

This is something I've kept in mind as well.
In programming using statemachines could have one drawback, loss of context. (However fetching only a bit of context (timing for instance) can be done easily.)
So it is probable to have one part of the system acts fast, but doesn't keep context. And a second part of the system doing it again (with different logic) but building up context. (Even searching trough memory  )
With the scope one part could for example run on the FPGA, the other on the CPU.
These kind of bugs are harder to reproduce. Absolutely no certainty that this is the case, but we have go by smell anyway.

[thaistatos]

Has already someone botherd to exchange the Intensity/Adjust encoder with a detented encoder?

I've been wondering the same thing. 

I have done it right after purchasing bc this non-detent encoder was driving me nuts - pretty weird design decision given that they have detented ones for vertical/horizontal anyway.
In fact, I've even taken the photos to dump here, but I'm a lazy arse so that never happened. 
I can't remember the P/N of the original non-detented one, but it turned out to be some sort of Chinese unobtanium. After searching a bit through what ALPS/Bourns/Omron offer, the closest I was able to find dimension-wise was Bourns PEC12R-4220F-S0024.
To my taste it has a bit too much detent force, otherwise it has been working absolutely fine for the last half year.
(Attachment Link) (Attachment Link)

UPD:
I still have the original part, it has no P/N, but LJV embossed on it.

Thank you, that was the information, I was looking for!

I have done such a mod to my 2 other scopes and the only regret was, not doing it in the fist place.

Chris

have you performed the mod?
Are there pictures available?
which parts have to be taken apart? I do not want to ruin my new scope while it is still under guarantee.
Is there a possibility to open it without destroying the siglent label?

[HendriXML]

Yesterday I didn't have time to play.
Just now I started, and wanted to add some offset to the signal, but it couldn't it was maxed out.
So I went to HZ, and without 50 ohm terminator.
Now it very frequently shows the isue, 32 fail / 68 pass.

Using a mask is a good technique , so no need to do it in script.

I'll try to get it up to 100% fails.

[HendriXML]

Tuning with the offset and amplitude, It doesn't go to 100% fail.

It seems that number of passes is about 2x the number of fails. That be very important info, maybe different trig signals (on different time) have an influence on another (software wise). So it could be about "between trigger timings", as mentioned..