Yeah, but it's not visible in the data!
The data shows that the *minimum* value captured for the trigger precondition is 4.33V, which is 0.7V *above* the 3.5V threshold that the trigger precondition should be passing through.
Can you use the scopes GUI to zoom in on that glitchy area 1.4-1.5ms before the trigger (the entire area that is eligible for triggering purposes in your setup) and look at the trace, not the data? This might seem wierd, but since the trigger (AFAIK) doesn't use the data, but rather the sinx/x function of it, under certain noise or glitch conditions the calculated trace and trigger level could be well outside the actual data. That seems farfetched, but I'm grasping at straws here--there doesn't seem to be a good explanation for this behavior. And noise reject fixes it.
Obviously there is some glitch firing the rising trigger as seen within the higher level in this screenshot.
To examine this better the timebase needs zooming in so to see the spikes that are firing the trigger.
Even with sin(x)/x interpolation, there should be something in the data that would cause the interpolated waveform to dip below 3.5V here (remember that 3.5V is more than 1V less than the typical voltage seen at around -1.5 ms). It means there should be *something* at or near that voltage level in the data. And there just isn't.
Either the trigger mechanism is consistently detecting a voltage swing that is present in the signal but isn't being captured by the sampler, or the trigger mechanism is malfunctioning.
Hint: It need now note that he use SLOPE trigger!
The sinc function can give surprising results sometimes, especially if the bandwidth is not correctly accounted for. Is your scope hacked to 200MHz? It does seem that the trigger is seeing or calculating something not in the trace.
It's entirely possible that there's something in the signal that the trigger is latching onto that is somehow not making it to the capture. I can understand that happening occasionally. But this is happening often enough that it makes me suspicious that there's something else going on, possibly something subtle about how the slope trigger mechanism works that I'm not accounting for.
It's entirely possible that there's something in the signal that the trigger is latching onto that is somehow not making it to the capture. I can understand that happening occasionally. But this is happening often enough that it makes me suspicious that there's something else going on, possibly something subtle about how the slope trigger mechanism works that I'm not accounting for.
Do you have an AWG so that you can replicate this signal by DDS?
As far as how it happens, I would think that it has to be a combination of something your circuit is doing and a susceptibility in the trigger design. But if it does the same thing with a signal from a different source at the same point in the waveform, then the problem is just the trigger design. Is there anything happening in the input circuit at the point in the waveform that the occasional mistrigger occurs?
Type: slope
Slope: rising
Voltage boundaries: 3.5V to 4.5V
Limit range type: [-- . --]
Limit range values: 1.2ms to 1.4ms
Noise reject: off
Well, the point of the triggering mechanism is that it should trigger only when all of the conditions you define are actually present. Therein lies the crux of the matter -- I've seen no evidence that all of the conditions really *are* present. Its possible that there's something on the input side of the circuit that is ultimately resulting in the kind of noise spike that would have to be present for the triggering mechanism to fire the way it is, but I haven't gone looking for that. But now that you mention it, I should probably be sampling that on a different channel so I can see if there's anything unusual there.
First, this scope whole trigger system is all after ADC. Trigger engine do not see ANY single thing but just 8 bit data bytes coming from ADC. If in this data stream is not spike or what ever, these can not also affect triggering. Absolutely and infinitely. I know it deeply enough for this claim.
Also every single byte from ADC, what have moved to acquisition memory after possible decimation, is also display mapped..... Siglent is "bullet proof" in this. It do not decimate when samples density is much more than pixel density.
And thank you again. To paraphrase, dots are samples, provided that the display isn't too crowded. But would a one-sample spike be visibly displayed on a screen with 14Mpts, even in Normal mode and not Peak?
Of course then ADC data is decimated, from 100 raw samples it take only one to acquisition memory and rest it throw away. But in this case peaks can affect and they are not visible because Primary Trig engine is before this decimation!!!
And note, of course trigger engine see sample interval and its resolution is this but of course this is not at all enough.
There need interpolate between these 2 or 1 ns sample points for final positioning.
Well, the point of the triggering mechanism is that it should trigger only when all of the conditions you define are actually present. Therein lies the crux of the matter -- I've seen no evidence that all of the conditions really *are* present. Its possible that there's something on the input side of the circuit that is ultimately resulting in the kind of noise spike that would have to be present for the triggering mechanism to fire the way it is, but I haven't gone looking for that. But now that you mention it, I should probably be sampling that on a different channel so I can see if there's anything unusual there.
First, this scope whole trigger system is all after ADC. Trigger engine do not see ANY single thing but just 8 bit data bytes coming from ADC. If in this data stream is not spike or what ever, these can not also affect triggering. Absolutely and infinitely. I know it deeply enough for this claim.
kc, I'll do a little exercise with your triangular waveform later in the evening when I've got some real time as the rising Slope trigger is giving unexpected results and we need get to the bottom of this.
Will have something for you to examine come your morning.
Awesome, thanks! Should be interesting.
kc, I'll do a little exercise with your triangular waveform later in the evening when I've got some real time as the rising Slope trigger is giving unexpected results and we need get to the bottom of this.
Will have something for you to examine come your morning.
Awesome, thanks! Should be interesting.It was and user error was confirmed.
Slope triggering works as expected if you RTFM !
Expressly this:
The slope trigger looks for a rising or falling transition from one level to another level in greater than or less than a certain amount of time.
P71
https://siglentna.com/wp-content/uploads/dlm_uploads/2020/11/SDS1000X-ESDS1000X-U_UserManual_UM0101E-E05A.pdf
However there is a little trap for the inattentive in that once Levels have been set and then Limit Range (time between levels) the trigger Levels cannot be adjusted without starting from scratch again.
So how to pick a valid Limit Range.....with Cursors or just eyeballing the graticules of course and then all works as expected while the limit range time is met between the Levels.
OK, I did this, and here are the results.
The attached screenshots show the captured waveform in full. One with the mask, and one without.
Also, I've attached the CSV of the data from -1.5ms to 0ms (I had to use 7zip to archive it because zip didn't compress it enough). My analysis of it shows that the minimum voltage seen in that interval is seen at -27 ns, with a value of 4.33V.
Is it perfectly just this screen shot what is also this .CSV.
There can not see exactly what was all important settings just when this happen.
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.
But for further analyze you need tell exactly what setup was for this screen shot with this CSV. Sad there is not CSV from this part where can assume trigger need happen in just this "sweep".
Btw, are you hunting some nanosecond things from this signal or why you use full BW.
Sidenote. Normal default trigger hysteresis, what is fully hidden from user, is roughly 0.3 div.
When user select [noise reject on] no where is displayed inform to user what it do and many may think it is some kind of freq filter. Its (main) function is make this hysteresis "window" more wide. With noise reject on it is roughly 0.8div. And it need also note this hysteresis position depends direction. If we are going up this hysteresis is before aka under threshold level and if we are going down hysteresis is before aka over thresold level and this is also in slope trigger and for both thresholds. So if user example turn noise reject on and he loose trigger it need also check if this invisible Mr.Hysteresis have arrived to room making his magic...
It is good to know but not reason in this case.
More Slope trigger tests....some not triggering due to settings used.
Screenshots should speak for themselves.
More Slope trigger tests....some not triggering due to settings used.
Screenshots should speak for themselves.
In each test you're performing, you're using a "<=" type of time definition, meaning the first transition point can occur any time between the defined time and zero before the second transition point.
More Slope trigger tests....some not triggering due to settings used.
Screenshots should speak for themselves.
In each test you're performing, you're using a "<=" type of time definition, meaning the first transition point can occur any time between the defined time and zero before the second transition point.No look at them again, <=, >= and both rising and falling for each.
Haven't tried [-- . --] yet..........and maybe not tonight as it's getting late and needing beauty sleep !
In the next 24hrs I promise.
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.
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
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.
Have you tried same with analog side BW reject.
Have you tried it with more wide slope steep. Example 1ms / 2ms. Do it change situation.
Have you tried using Trigger noise reject ON. (more wide hysteresis).
Have you tried using 1x probe (now with 10x probe your real input is 50mV/div) .... oh but you have 4V DC offset...
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?
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.
Also this language barrier make me wonderin this your explabnation about slope trig timing.
Have you tried same with analog side BW reject.