Least I can say this is not trigged from this signal data if your previously told trigger slope etc settings are used and last 1.5ms data before trig time position is what is in CSV.
This signal that you see in the screenshot *did* cause the trigger as I defined it above to fire. That's the point. I see no reason it should have, but it did anyway.
No.
Perhaps some language barrier.
What I mean.
There in .CSV can not find anything what can explain this trig in this place. Btw how you know it is trigged. have you seen trig out signal just for this. So we do not even know if it is trigged or captured without true trig due to example some rare well hidden bug what now pop up in just with all your settings.
Ah. Yes, I agree, there's nothing in the data that explains why the trigger fired. Rest assured, what was captured *is* the result of the trigger firing. How do I know?
- Because I had the trigger operation mode as "normal".
- Because (as you can see from the screenshot), I had the mask operation turned on and set to stop the scope upon violation of the mask, and the capture happens only when the trigger fires when in "normal" mode.
- Because in the CSV you can see that the second condition (passing through 4.5V from below -- well, 4.49V is what the time zero value is. Close enough, especially with sin(x)/x interpolation) *was* met at time zero.
I've posted at least 3 different instances of the issue, along with CSV data to back it up. One of them was in response to Tautech when he suggested I use "single" mode to reproduce the issue. I did, and the end result is the same: the CSV data doesn't show anything to explain why the trigger fired, but the screenshot shows clearly that it did.
At this point, I don't know what other evidence I can supply, but the conclusion from the data is clear: the slope trigger mechanism, at least when using a bracketed time range, is buggy, and will fire when it shouldn't, unless the trigger mechanism is keying off data that is *consistently* failing to land in the capture.
Have you tried same with analog side BW reject.
Limiting the bandwidth helps. I'm running a test now to see if the issue reproduces at all with a 20 MHz bandwidth limit on the input. But limiting the bandwidth shouldn't be necessary. What if you're trying to find high-frequency noise in the signal? The point here is that
if noise causes the trigger to fire and the trigger mechanism exclusively uses ADC output, that noise should be present in the capture! But it wasn't, and isn't.
Have you tried it with more wide slope steep. Example 1ms / 2ms. Do it change situation.
Good question. I don't know. I'll have to test that as well. But that said, it's unclear what to expect to gain from it. 200us is plenty of time when the sample rate is 1GS/s. It's not like that time window approaches the limitations of the speed of the scope or anything.
Have you tried using Trigger noise reject ON. (more wide hysteresis).
Yes. It does increase the amount of time to reproduction, but I have seen the issue reproduce even with that in place.
Have you tried using 1x probe (now with 10x probe your real input is 50mV/div) .... oh but you have 4V DC offset...
I've not tried that.
When it do wrong looks like trig, do it happen always in same time position related to signal, same place in this slow falling edge?
Looks that way.
So this signal data, so what can see in this CSV, can not be source for this trig if settings are all as told and if this works as I think it is designed and done.
Agreed.
Also this language barrier make me wonderin this your explabnation about slope trig timing.
Well, let me try explaining how I think it works a different way.
When you're using the time range option for the slope trigger, what you're really doing is defining a bounding box with a section of the bottom (when using "rising" mode) side of the box that the waveform must pass through and a corner that it must also pass through for the trigger to fire. Like this:
The above shows the trigger configuration I used: a rising slope trigger with a time range of 1.2ms to 1.4ms, a lower voltage of 3.5V, and an upper voltage of 4.5V. The squiggly waveform I've drawn shows a waveform segment that would correctly cause the trigger to fire.
In this case, there are two gates through which the waveform must pass in order for the trigger to fire. The first gate is at T = -1.4ms to -1.2ms (meaning, 1.4ms to 1.2ms before the trigger fires), i.e. anywhere within that range is fine, and the threshold voltage through which the waveform must pass is 3.5V. The second gate is the 4.5V threshold. It must occur between 1.2ms and 1.4ms after the first threshold was passed. If that timing requirement is met at the point the waveform passes through 4.5V, the trigger fires.
Now, it would make the most sense for a rising slope trigger to insist on a rising edge when it passes through the threshold voltages, and I happen to think that such is strictly necessary, because otherwise the trigger could fire on a rising slope that is much greater than that which the trigger conditions specify. What *is* necessary, regardless, is that the waveform pass through the voltages in question while meeting the time requirements for each transition.
Of course, there's an additional requirement: the waveform must never pass below the 3.5V threshold at any time between T = -1.2ms and T = 0. If it does, then that would invalidate the trigger conditions. Another way of stating it is that the *last* time the waveform passes through the 3.5V threshold must be between 1.4ms and 1.2ms prior to the time when it passes through 4.5V.
Maybe the above makes what I've got in mind more clear. If not, I'll do my best to clarify further.