GW Instek MDO-2302A delayed trigger bug?

[evgus]

Hi everyone!

I encountered a problem using delayed trigger in GW-Instek MDO-2302A.
Sometimes it works as intended, but sometimes wrong.
For example, if I want to trigger on the second pulse in a packet, I use delayed trigger mode with event count set to 1 and it works fine. But then I change event count to 2, and it triggers randomly on the first, second or third pulse. If I set event count to 3 it works correctly again, and so on.
The same problem in ‘Delay time length’ mode. At some ‘delay times’ it works correctly, at some – just triggers on the first edge with no delay at all.

Here is video demonstration: https://youtu.be/JL_RYlNBuN0

Have someone encountered issues like that? Is it a problem of exact device, or is it a firmware bug (latest firmware installed)?
May be I’m doing something wrong?
Any ideas?

Thanks
Eugene

[tautech]

Welcome to the forum.

For simple trigger timeout on datastreams a simple mistake is to use a timeout not quite long enough and a longer packet comes along and mucks it all up. 

The remedy of course is dead simple; increase the trigger timeout.

[2N3055]

Hi everyone!

I encountered a problem using delayed trigger in GW-Instek MDO-2302A.
Sometimes it works as intended, but sometimes wrong.
For example, if I want to trigger on the second pulse in a packet, I use delayed trigger mode with event count set to 1 and it works fine. But then I change event count to 2, and it triggers randomly on the first, second or third pulse. If I set event count to 3 it works correctly again, and so on.
The same problem in ‘Delay time length’ mode. At some ‘delay times’ it works correctly, at some – just triggers on the first edge with no delay at all.

Here is video demonstration: https://youtu.be/JL_RYlNBuN0

Have someone encountered issues like that? Is it a problem of exact device, or is it a firmware bug (latest firmware installed)?
May be I’m doing something wrong?
Any ideas?

Thanks
Eugene

Are you in Auto or Normal trigger mode? 
You need to change to Normal trigger mode.

EDIT: I apologize, I saw the video and you did change to Normal mode. Disregard my question.

You shouldn't have such a large holdoff value. Try setting holdoff to time just bigger than pulse burst , say 12-15 usec.
With pulse trigger you use you shouldn't need holdoff at all.

Also you use rising pulse as trigger start, you should use falling edge, so it's not triggering on first falling pulse and count from there but from somewhere else.

I don't have that scope, but it seems to me that this particular trigger works a bit different than you''re trying to use it.

[evgus]

Welcome to the forum.

Thanks!

For simple trigger timeout on datastreams a simple mistake is to use a timeout not quite long enough and a longer packet comes along and mucks it all up. 
The remedy of course is dead simple; increase the trigger timeout.

I mean "trigger timeout" is the same as "Holdoff time", am I correct?
The problem shows up even on short test packet of just 8 pulses.
Even if holdoff time is much longer than packet duration.

[tautech]

For simple trigger timeout on datastreams a simple mistake is to use a timeout not quite long enough and a longer packet comes along and mucks it all up. 
The remedy of course is dead simple; increase the trigger timeout.

I mean "trigger timeout" is the same as "Holdoff time", am I correct?

Yes.
Try a falling edge trigger which is more normal for simple decoding.

[evgus]

You shouldn't have such a large holdoff value. Try setting holdoff to time just bigger than pulse burst , say 12-15 usec.
With pulse trigger you use you shouldn't need holdoff at all.

Also you use rising pulse as trigger start, you should use falling edge, so it's not triggering on first falling pulse and count from there but from somewhere else.

I don't have that scope, but it seems to me that this particular trigger works a bit different than you''re trying to use it.

Thanks for your reply!
I've tried to vary holdoff time and even set it to minimum value (effectivly disable it at all). Nothing have changed. Setting edge to falling also doesen't help - trigger still happens randomly if "delay count" set to 2.

I completely agree that "this particular trigger works a bit different than you''re trying to use it"
This is definitly not the first scope throughout my career, but this is the first time I put so much effort (in vain so far) trying to make such simple function (trigger on N-th pulse in packet) work 

[2N3055]

You shouldn't have such a large holdoff value. Try setting holdoff to time just bigger than pulse burst , say 12-15 usec.
With pulse trigger you use you shouldn't need holdoff at all.

Also you use rising pulse as trigger start, you should use falling edge, so it's not triggering on first falling pulse and count from there but from somewhere else.

I don't have that scope, but it seems to me that this particular trigger works a bit different than you''re trying to use it.

Thanks for your reply!
I've tried to vary holdoff time and even set it to minimum value (effectivly disable it at all). Nothing have changed. Setting edge to falling also doesen't help - trigger still happens randomly if "delay count" set to 2.

I completely agree that "this particular trigger works a bit different than you''re trying to use it"
This is definitly not the first scope throughout my career, but this is the first time I put so much effort (in vain so far) trying to make such simple function (trigger on N-th pulse in packet) work 

I tried to look into manual, but it is not well written. You should definitely write mail  to Instek support. Even if it's not a bug per se, it is really not explained well how it works..
Regards,

[armandine2]

I'm keen to recreate this test for my GW Instek MDO-2302A

will need to recreate OP's original pulse packet on my Keysight EDU33212A arbitrary waveform gen

evgus was explicit about how he used the scope - but I guess for the arb the assumption is this is a simple waveform to recreate  - I think I could do something like it with a square wave high 3.3V low 0V say 60% duty cycle and 1/1.4 us frequency in a 8 cycle 1 second burst ; not as pulse though?
[Ed.1 may be: offset +3.3V, high level 0V, and low -3.3V] 

[armandine2]

I didn't manage to get a dc offset in burst with my Keysight EDU waveform generator - but I can (with no dc offset), nonetheless confirm that for my GW Instek MDO-2302A:

 a one second burst of eight 3.3V, 1.4us, and 60% duty cycle pulses, I only caught on event delays 1, 3, and 7 

so if you do the same thing you will likely get the same result - which is kinda obvious.

Whether this really is a bug - not exactly sure.

[armandine2]

Bumped up, in case some further light can be shown on the problem.