SDS-1104X-E, trigger holdoff feature (it may say test)

[CiscERsang]

Hello guys again,
I've decided to make a separate topic on this matter.
A need has arisen on watching how many times a frame is being sent per second. The point is, I'm not sending that frame with a frequency ~10000 times per second. Physically impossible stuff with my HW.
I've used trigger settings with holdoff feature in order to get only one trigger event per frame appearance (this way I understand how holdoff functions).
And what I have:
Firstly I found out the frame length (ms) by means of coursors. Then I set trigger with holdoff feature.

A question: to me it looks oddly enough that holdoff enable/disable doesn't affect (f=) frequency in any way.

Perhaps I'm doing something wrong.


first pic is where holdoff is enabled




second pic is where holdoff is disabled (as I undestand it's disabled judging on button's state. Or?)

thanks in advance!

P.S. of course I've re-triggered that many times. There's no difference in terms of frequency changing.

[2N3055]

Hello guys again,
I've decided to make a separate topic on this matter.
A need has arisen on watching how many times a frame is being sent per second. The point is, I'm not sending that frame with a frequency ~10000 times per second. Physically impossible stuff with my HW.
I've used trigger settings with holdoff feature in order to get only one trigger event per frame appearance (this way I understand how holdoff functions).
And what I have:
Firstly I found out the frame length (ms) by means of coursors. Then I set trigger with holdoff feature.

A question: to me it looks oddly enough that holdoff enable/disable doesn't affect (f=) frequency in any way.

Perhaps I'm doing something wrong.

(Attachment Link)
first pic is where holdoff is enabled



(Attachment Link)
second pic is where holdoff is disabled (as I undestand it's disabled judging on button's state. Or?)

thanks in advance!

P.S. of course I've re-triggered that many times. There's no difference in terms of frequency changing.

Why this topic? Performa01 already answered.

Holdoff works fine. It's frequency measurement that confuses you.

That frequency measurement you see on the screen is frequency of signal on the screen, not frequency of trigger events.
So it is based on baud rate of packet, not on how many packets you send per second.

In order to get frequency of trigger events, you need to measure frequency of Trig output on the scope.
So connect any device that can measure frequency (multimeter, second scope, frequency counter ) to trigger out and measure.

You might even be able to to do it by looping back Trigger Out to one of input channels on your own scope and try to measure  frequency of THAT channel.

[CiscERsang]

Why this topic? Performa01 already answered.

Holdoff works fine. It's frequency measurement that confuses you.

That frequency measurement you see on the screen is frequency of signal on the screen, not frequency of trigger events.
So it is based on baud rate of packet, not on how many packets you send per second.

In order to get frequency of trigger events, you need to measure frequency of Trig output on the scope.
So connect any device that can measure frequency (multimeter, second scope, frequency counter ) to trigger out and measure.

You might even be able to to do it by looping back Trigger Out to one of input channels on your own scope and try to measure  frequency of THAT channel.

You know, I read your detailed answer. After that I had returned to Performa01's answer and reread his answer one more time. Now, I understand what he meant.

Both answers complement each other or so.

However, still can't get how to check if holdoff is working.

[2N3055]

Why this topic? Performa01 already answered.

Holdoff works fine. It's frequency measurement that confuses you.

That frequency measurement you see on the screen is frequency of signal on the screen, not frequency of trigger events.
So it is based on baud rate of packet, not on how many packets you send per second.

In order to get frequency of trigger events, you need to measure frequency of Trig output on the scope.
So connect any device that can measure frequency (multimeter, second scope, frequency counter ) to trigger out and measure.

You might even be able to to do it by looping back Trigger Out to one of input channels on your own scope and try to measure  frequency of THAT channel.

You know, I read your detailed answer. After that I had returned to Performa01's answer and reread his answer one more time. Now, I understand what he meant.

Both answers complement each other or so.

However, still can't get how to check if holdoff is working.

It is working, don't worry.   
If you set timebase to so your data packet is longer than screen, you might get unstable trigger without holdoff, because it will trigger on the beginning of packet and again on somewhere on the rest of the packet. With trigger holdoff it will insert delay, so it will stabilise...

[CiscERsang]

It is working, don't worry.   
If you set timebase to so your data packet is longer than screen, you might get unstable trigger without holdoff, because it will trigger on the beginning of packet and again on somewhere on the rest of the packet. With trigger holdoff it will insert delay, so it will stabilise...

yes, sometimes the frame skipped left. Now it had stopped doing that.

[Performa01]

Holdoff is working fine, but it's difficult to demonstrate its function in situations where it's not required.

Holdoff just disables the trigger for the set amount of time - and it won't affect the trigger frequency counter (which just tells an average frequency of the gated input signal on the trigger channel).

Holdoff is normally not set to the burst (packet) length, but slightly less than the time interval of the gap between packets and is intended to get a stable trigger on the first trigger condition within a packet. Unstable triggering usually happens when packets with multiple valid trigger conditions are arriving at a high repetition rate and there is not much space in between them.

If for example you have a packet every 4ms and your packet is 2.42ms long, then you could set the Holdoff just below the timespan of the gap between packets, which would be 4 - 2.42ms = 1.58ms.  In this example, 1.57ms Holdoff should work to get a stable trigger.

Btw, seeing the packet rate is easiest done taking advantage of the deep memory. Just increase the timebase until you capture two packets instead of just one. You can then use cursors to measure the time period from packet to packet. If you need it very accurate, you can use zoom to fine-position the cursors.

If the repetition rate of the packets is very low, so that you need to increase the timebase to several seconds per division, you might need to engage peak detect acquisition mode in order to capture the pulses of the packet reliably. In that case, precision of the cursor measurement will be low correspondingly, but for slow actions like this great accuracy is usually not required and you don't need Holdoff in such situations for sure.

[tautech]

Perhaps I'm doing something wrong.

You are.

Some examples.
Half of a CAN pair for clarity.

First, Holdoff = Close (IIRC 70ns)


Because the trigger gets rearmed, stable triggering is not possible as there are several edges within the packet that will be triggered on.


Setting Holdoff to large amounts of time is made simple with use of the virtual keyboard that is accessed by pressing the multifunction knob when Holdoff is selected. This virtual keyboard is available in the same way for many types of adjustments in X and X-E scopes.

Simply we make a setting longer than the longest packet to ensure the trigger is not rearmed until after the packet is finished. By using Run/Stop we can freeze the display and use the graticules to measure the packet length and decide on a suitable Holdoff time.
Trig Out frequency will then be representative of the Holdoff setting and the waveform characteristics.


If we need to determine the Baud rate we can use Cursors set to the Start's of subsequent packets like the quick example below.

[CiscERsang]

Btw, seeing the packet rate is easiest done taking advantage of the deep memory. Just increase the timebase until you capture two packets instead of just one. You can then use cursors to measure the time period from packet to packet. If you need it very accurate, you can use zoom to fine-position the cursors.

That's it! But without holdoff feature I couldn't get any following packets on the screen. Now it's stabilized and I can, and of course now I can measure gap between them.

If we need to determine the Baud rate we can use Cursors set to the Start's of subsequent packets like the quick example below.

hello tautech! How  are you? Hope fine. 
to find out baud rate roughly I do that different way. As a variant.

• measure duration of a single burst by means of cursor option (for example I've got ~52us)
• then 1000000/52 = 19230, this value corresponds 19200 baud standard.

[2N3055]

Btw, seeing the packet rate is easiest done taking advantage of the deep memory. Just increase the timebase until you capture two packets instead of just one. You can then use cursors to measure the time period from packet to packet. If you need it very accurate, you can use zoom to fine-position the cursors.

That's it! But without holdoff feature I couldn't get any following packets on the screen. Now it's stabilized and I can, and of course now I can measure gap between them.

If we need to determine the Baud rate we can use Cursors set to the Start's of subsequent packets like the quick example below.

hello tautech! How  are you? Hope fine. 
to find out baud rate roughly I do that different way. As a variant.

• measure duration of a single burst by means of coursor option (for example I've got ~52us)
• then 1000000/52 = 19230, this value corresponds 19200 baud standard.

Baud rate will simply be 1/t of shortest pulses in a packet.

[tautech]

hello tautech! How  are you? Hope fine. 

Pretty good, and you ?
Pleased with the Professor's selection ?

[CiscERsang]

hello tautech! How  are you? Hope fine. 

Pretty good, and you ?
Pleased with the Professor's selection ?

Sure, I am.
This gear is running ten hours a day since purchasing. it's my eyes when I'm struggling with buses.
Not pleased with buses and other cr*ppy hardware.