I tried to fetch faillures using 1993 segments, but then they dont' come up. Important info as well..
I will stop experimenting for now and sit on my thinking stone...
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.
That said, it looks like HendriXML has managed to reproduce the issue using an AWG signal, and that's really excellent, because it means we can give Siglent a fairly foolproof way to reproduce the issue themselves and, thus, track it down and fix it.
The following could also be observed:
Without using pass/fail masks, but with infinite persistence failures can also be seen. But the time between waves can be much shorter (like 30 ms). The reason for this might be that managing masks is more cpu intensive.
Also: the valid trigger condition and the invalid one don't need to be both on screen simultaneously.
The issue *does* reproduce with trigger noise rejection enabled, but it takes quite a bit longer. In this case, it took 45452 mask tests before it reproduced, with an average trigger rate of 24 Hz or less:
Here's the data for it (a 7-zip archive with the CSV, the binary, the setup XML, and the above screenshot): https://app.box.com/s/5zmf6xr4t8xypjjmqmw46oj574r6sab3
With respect to theories like interrupt handling and such, the plain fact here is that the amount of time between events is orders of magnitude longer than what the triggering system is capable of handling. We're talking about a 60 Hz waveform here! If there's a problem with the CPU getting around to handling the trigger conditions fast enough with a 60 Hz waveform, then we'd have every reason to believe that the trigger system would simply fall over with MHz-frequency waveforms. No, I don't think that's likely at all. And that's especially true since this issue reproduces even with trigger noise rejection enabled.
Instead, I'm pretty sure what we're up against here is either a race condition or a failure to properly and consistently impose the trigger conditions. But only the guys at Siglent can truly say.
I'm now in the process of running the test with the 20MHz bandwidth filter enabled on the channel. I'll give it at least 12 hours to reproduce.
With respect to theories like interrupt handling and such, the plain fact here is that the amount of time between events is orders of magnitude longer than what the triggering system is capable of handling. We're talking about a 60 Hz waveform here! If there's a problem with the CPU getting around to handling the trigger conditions fast enough with a 60 Hz waveform, then we'd have every reason to believe that the trigger system would simply fall over with MHz-frequency waveforms. No, I don't think that's likely at all. And that's especially true since this issue reproduces even with trigger noise rejection enabled.
I think the basis of the problem is what I have described. That it doesn't happen on other signals might be due to (unknown) methods to prevent this from normally happening (stuff like hysteresis and ..).
Just a comment, to me that time interval looks awfully close to limit..
I'm not sure signal climbed those two voltages in 1,2-1,4 ms, it could be less than 1,2ms..
Maybe vary that a bit to find out if that influences something to try to find more clues....
Also I find it confusing that L1 is higher than L2 (maybe better naming would be UL-upper limit and LL-lower limit)
Just a comment, to me that time interval looks awfully close to limit..
I'm not sure signal climbed those two voltages in 1,2-1,4 ms, it could be less than 1,2ms..
Maybe vary that a bit to find out if that influences something to try to find more clues....
Also I find it confusing that L1 is higher than L2 (maybe better naming would be UL-upper limit and LL-lower limit)
Have you read everything said in « Reply #1772 on: December 07, 2020, 07:34:46 am » and after it all what handle this trigger engine bug.
Just a comment, to me that time interval looks awfully close to limit..
I'm not sure signal climbed those two voltages in 1,2-1,4 ms, it could be less than 1,2ms..
Maybe vary that a bit to find out if that influences something to try to find more clues....
Also I find it confusing that L1 is higher than L2 (maybe better naming would be UL-upper limit and LL-lower limit)
Have you read everything said in « Reply #1772 on: December 07, 2020, 07:34:46 am » and after it all what handle this trigger engine bug.
No. I'm afraid I didn't. I just made a comment to this image...
I do understand there is a problem, I'm just saying that playing with time limits might reveal something else.
L1 and L2 comment is my comment to Siglent's choice in U/I naming.
13 hours and 480000 mask test frames later, the issue still hasn't reproduced with the 20 MHz bandwidth limiter enabled on the channel. I'll be happy to keep it going for another 12 hours, but it's certainly looking like the 20MHz bandwidth limiter eliminates the issue in my environment. But that's in my environment. It may be that noise at a lower frequency than 20 MHz would just as easily trigger the bug. On that, I can't say. But it would be an interesting test for HendriXML to perform with his setup, seeing how he's able to reproduce the issue more or less at will with an artificially-generated signal.