Siglent SDS1104X-E and SDS1204X-E Mixed Signal Oscilloscopes

[kcbrown]

Have you tried swapping the Level positions ?
See how they are half pointers.....and you're using a rising trigger.

It doesn't let me do that.  In the soft menu item, it has them labeled as "lower" and "upper", and there they're correct: 3.5V for lower, 4.5V for upper.  It doesn't let me switch them.

To be clear, the trigger *does* work, in that it will actually trigger on the rising edge most of the time.  The problem is that it will also occasionally trigger on the falling edge inexplicably.   I'm using "normal" trigger mode, so it would be obvious if it weren't triggering properly.

[HendriXML]

Wouldn't a mask fail not also stop the aquisition?

Indeed level 1 is the high level, level 2 the low, which surprised me when decoding the scpi response.

[2N3055]

Are you using normal or auto trigger mode?

[kcbrown]

Wouldn't a mask fail not also stop the aquisition?

The mask feature can be configured to stop the acquisition upon failure, and that's how I've got it configured here.  It's really handy if you want to catch a misbehaving waveform in the act.

[kcbrown]

Are you using normal or auto trigger mode?

Normal.

[HendriXML]

Wouldn't a mask fail not also stop the aquisition?

The mask feature can be configured to stop the acquisition upon failure, and that's how I've got it configured here.  It's really handy if you want to catch a misbehaving waveform in the act.

So we're not looking at a triggered stop in the screenshot. 

[HendriXML]

Maybe using segments and review them for a failing trigger is an idea? Thus not using masks ar all?

[kcbrown]

Wouldn't a mask fail not also stop the aquisition?

The mask feature can be configured to stop the acquisition upon failure, and that's how I've got it configured here.  It's really handy if you want to catch a misbehaving waveform in the act.

So we're not looking at a triggered stop in the screenshot. 

The trigger just determines when the waveform is captured.  I'm using the mask to automatically stop the scope when a violation of the expected waveform is detected.  They're completely different subsystems that work in tandem.

The issue here is that the triggering mechanism is capturing waveforms when I wouldn't expect it to.  When that happens, the mask mechanism detects it and stops the scope, thus allowing you to see the waveform that was captured and which failed the mask.

[HendriXML]

Wouldn't a mask fail not also stop the aquisition?

The mask feature can be configured to stop the acquisition upon failure, and that's how I've got it configured here.  It's really handy if you want to catch a misbehaving waveform in the act.

So we're not looking at a triggered stop in the screenshot. 

The trigger just determines when the waveform is captured.  I'm using the mask to automatically stop the scope when a violation of the expected waveform is detected.  They're completely different subsystems that work in tandem.

The issue here is that the triggering mechanism is capturing waveforms when I wouldn't expect it to.  When that happens, the mask mechanism detects it and stops the scope, thus allowing you to see the waveform that was captured and which failed the mask.

But there're now 2 things in play...
Either the triggering does not work as you expect OR the masking and when it stops doesn't work as you expect... It seems like a good idea to take one away..

[bdunham7]

But there're now 2 things in play...
Either the triggering does not work as you expect OR the masking and when it stops doesn't work as you expect... It seems like a good idea to take one away..

You don't need the mask to see that the trigger has happened in the wrong spot and the mask doesn't affect the trigger or the capture, it just stops the scope and prevents any future triggers.  What you see is exactly what you would see if you got lucky with a single shot and captured the mistrigger.  The mask isn't anything to worry about here, but I'm a bit puzzled as to the operation of the trigger.

[bdunham7]

The issue here is that the triggering mechanism is capturing waveforms when I wouldn't expect it to. 

Can you change the timebase to 1ms/div so that you get the full 1GS/s sample rate and then do the same test to see if it mistriggers? 

[kcbrown]

Maybe using segments and review them for a failing trigger is an idea? Thus not using masks ar all?

Sure, I could do that too.  The problem is that in order to do that, I have to reduce the number of samples captured, thus reducing the chance that I'll see what the triggering mechanism saw.  I'd also have to manually stop the scope quickly enough that the errant waveform is still in one of the segments.  I could use a 14k point sample buffer, and that'd give me lots of segments, but that would also minimize the chance that I'd see the problem that the triggering mechanism saw.

I did try that just now, by the way (using a 14k sample buffer), but haven't yet found a waveform where it was apparent that the triggering mechanism was doing the right thing by triggering on what looks like the falling edge.

[HendriXML]

But there're now 2 things in play...
Either the triggering does not work as you expect OR the masking and when it stops doesn't work as you expect... It seems like a good idea to take one away..

You don't need the mask to see that the trigger has happened in the wrong spot and the mask doesn't affect the trigger or the capture, it just stops the scope and prevents any future triggers.  What you see is exactly what you would see if you got lucky with a single shot and captured the mistrigger.  The mask isn't anything to worry about here, but I'm a bit puzzled as to the operation of the trigger.

Maybe it is a combination of mask and trigger, so I would first start to look for the simplest setup that causes the issue. If it doesn't happen without a mask thats good info. If it also happens without a mask the screenshot might give a better insight. For now it seems that the inverse of the mask would have given a valid trigger.. thats puzzling.. and cannot be discarded imo.
Edit..
Not really puzzling,  that how the mask get synced off course.

[kcbrown]

The issue here is that the triggering mechanism is capturing waveforms when I wouldn't expect it to. 

Can you change the timebase to 1ms/div so that you get the full 1GS/s sample rate and then do the same test to see if it mistriggers?

Sure thing.  That's in progress now.  Watch it not mistrigger because it knows it'll get caught redhanded with this setup.   

[HendriXML]

Sure, I could do that too.  The problem is that in order to do that, I have to reduce the number of samples captured, thus reducing the chance that I'll see what the triggering mechanism saw.  I'd also have to manually stop the scope quickly enough that the errant waveform is still in one of the segments.  I could use a 14k point sample buffer, and that'd give me lots of segments, but that would also minimize the chance that I'd see the problem that the triggering mechanism saw.

In aquisition menu, you can set the number of segments you want to capture and then it stops. These can then be replayed, I think a wrong one should be easy to spot then. Using a script the segments can be analysed automatically,  but that might be a bridge to far..

[kcbrown]

Sure, I could do that too.  The problem is that in order to do that, I have to reduce the number of samples captured, thus reducing the chance that I'll see what the triggering mechanism saw.  I'd also have to manually stop the scope quickly enough that the errant waveform is still in one of the segments.  I could use a 14k point sample buffer, and that'd give me lots of segments, but that would also minimize the chance that I'd see the problem that the triggering mechanism saw.

In aquisition menu, you can set the number of segments you want to capture and then it stops. These can then be replayed,

Interesting, I didn't know that.  That could come in handy.  But it presumes that the failure rate is high enough for a failure to occur within the number of segments you specified.  That said, I suppose you could just keep running it until a failure is seen.

If you're not using the mask mechanism, then you'd have to see the failure with your own eyes.  Not impossible, certainly.  Might be worth doing if we really want to eliminate the mask mechanism as a contributing factor.

And, it turns out that it's not that hard at all.  I did this, with 140k points per capture.  There was one failed waveform in just over 200 segments.  That one waveform does not show any evidence as to the trigger's stated conditions being met, despite the fact that the trigger fired.

I think a wrong one should be easy to spot then. Using a script the segments can be analysed automatically,  but that might be a bridge to far..

Wouldn't be that hard, actually.  But it raises a question: how do you save all of the segments?  I see no option in the save/restore menu to do that.

[tautech]

And, it turns out that it's not that hard at all.  I did this, with 140k points per capture.  There was one failed waveform in just over 200 segments.  That one waveform does not show any evidence as to the trigger's stated conditions being met, despite the fact that the trigger fired.

Yes because it rearmed. Use Single and it should capture it at any timebase setting.

[kcbrown]

Quote from: bdunham7 on Today at 07:15:16 am>Quote from: kcbrown on Today at 07:01:10 am

The issue here is that the triggering mechanism is capturing waveforms when I wouldn't expect it to. 

Can you change the timebase to 1ms/div so that you get the full 1GS/s sample rate and then do the same test to see if it mistriggers?

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.

[tautech]

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.

As posted before, use the blue Print button to grab screenshots and send them straight to a USB stick.

[HendriXML]

Wouldn't be that hard, actually.  But it raises a question: how do you save all of the segments?  I see no option in the save/restore menu to do that.

Using script the data of a segment can be retrieved when it is in view, to get all the script needs to place them in view one after another. Using the gui could be time consuming if it even can be done like that.

[kcbrown]

Obviously there is some glitch firing the rising trigger as seen within the higher level in this screenshot.

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.

To examine this better the timebase needs zooming in so to see the spikes that are firing the trigger.

As posted before, use the blue Print button to grab screenshots and send them straight to a USB stick.

I'll have to remember that about the print button.

Zooming in is good for examining the waveform visually, but that's no substitute for using a program to examine the values captured by the scope.  The latter is what I've used and directly shows that the minimum value recorded within 1.5ms prior to the trigger firing is nowhere near small enough to have fired the trigger.

What I'm doing to detect that is pretty straightforward if you're familiar with Unix/Linux and its utilities:

Code: [Select]

kevin@ubuntu:/tmp$ cat FAIL1GS.csv | awk -F, 'BEGIN {min = 100.0; mintime = 0;} { if ($1 >= -1.5E-03 && $1 <= 0 && $2 < min) { min = $2; mintime = $1; } } END {print mintime, min}'
-2.700000E-08 +4.330000E+00

[tautech]

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.

[kcbrown]

And, it turns out that it's not that hard at all.  I did this, with 140k points per capture.  There was one failed waveform in just over 200 segments.  That one waveform does not show any evidence as to the trigger's stated conditions being met, despite the fact that the trigger fired.

Yes because it rearmed.

I'm not sure I follow.  It rearmed after it fired.  Firing causes the capture.  Because the capture contains the point in time that the trigger fired, and because the time span of the display (which defines the time span of the capture) is enough to capture the preconditions of the trigger, it follows that the captured waveform would, in a perfect world, contain the data for both the trigger precondition (rising past 3.5V somewhere between 1.2 and 1.4ms before the trigger fires, which means a voltage value below 3.5V *must* be present somewhere prior to, and relatively close to, the precondition point seen by the triggering mechanism) and the trigger activation itself (rising past 4.5V at the point when the trigger fires).

A segment is a full capture, and what I was referring to is where one of the segments shows an improper capture.

Use Single and it should capture it at any timebase setting.

I did this, with a 14 megasample capture buffer, captured with peak detect, and finally managed to stop myself from pressing the "single" button after seeing a problem capture.   

I've attached a screenshot of the end result, as well as a 7-zip archive with the CSV of the data from -1.5ms to 0ms.

And the analysis of the data shows the same absence of a valid initial condition, with 4.33V being the minimum voltage seen between -1.5ms and the trigger (zero) time:

Code: [Select]

kevin@ubuntu:/tmp$ cat FAIL1GS-SINGLE.csv | awk -F, 'BEGIN {min = 100.0; mintime = 0;} { if ($1 >= -1.5E-03 && $1 <= 0 && $2 < min) { min = $2; mintime = $1; } } END {print mintime, min}'
-1.062040E-04 +4.330000E+00


[bdunham7]

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.

[kcbrown]

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.

I've no idea how much noise there has to be on the signal to reproduce this.  The source of my signal is the output of a Schmidt trigger run through an RC circuit and a diode.  There's some noise making it into the circuit, obviously.

Seeing how this issue can be seen via direct single triggering without the mask enabled, I think it's clear that the issue is independent of the use of the mask, thankfully.