SM200B Video Trigger

Hi! I have a couple questions / enhancement requests for the Video Trigger.

Hysteresis: I’ve been having a bit of difficulty obtaining stable Rising Edge / Falling Edge differentiation while using Video Trigger. Is there any way to adjust the hysteresis on the video trigger separately from the acquisition bandwidth? I have a kludgy workaround (my own trigger circuit with an Advantest R3271 in zero span, IF Out, detector, comparator, fed into external trigger) but I’d rather do this natively in the SM200B if possible.

Signal Path: Under some settings (pictured: 250MS/s, 160MHz IFBW) it looks like the signal used for video trigger is different from the AM vs Time signal. In this particular case, I suspect it has something to do with video trigger branching off the signal path before the IFBW filter while AM-vs-time is collected after the filter. Ideally I would like the option to trigger on something as similar as possible to the AM-vs-time trace but in the meantime I’d like to make sure I have a correct mental model of what’s going on, especially if there is nuance like “level correction applies to AM-vs-time but not video trigger.” Is there a signal path diagram I can look at?

Thanks!

Attachments:

You must be logged in to view attached files.

I can speak to the signal path portion. When your sample rate exceeds 61.44 MSPS, the video trigger moves from the API to the FPGA. It triggers on the amplitude of the raw 250 MSPS data, before the digital bandpass filter is applied. There is significant rolloff beyond the 160 MHz point, but triggering can still occur. The thought was if you are video triggering on a signal contained within the 160 MHz bandwidth, it would be transparent to the user, but energy just outside the 160 MHz bandwidth is the exception.

This was resolved in the SM200C, since we filter and resample more aggressively on the FPGA and trigger on the PC, but I realize this doesn’t help you.

Hysteresis: I would love to hear more about what you had in mind, and if you can give us a use case. More advanced triggering is something we have talked about and would like to explore. Obviously there are a lot more options at the API level than the FPGA level.

Thanks for the details! Knowing the architecture really does help. Living with 40MHz of bandwidth is relatively easy in this application and if that buys me a relatively precise match between triggers and the traces I see on screen, it’s a worthwhile tradeoff.

I made a separate post to brainstorm about frequency triggers, but hysteresis is probably in scope for this thread. The use case happens whenever signal risetime significantly exceeds (reciprocol) IF bandwidth. As the slowly rising signal reaches the threshold, noise causes it to wander up and down across the trigger threshold, creating both rising edge and falling edge events. The falling edge events are undesired and prevent the user from achieving a stable trigger. Ditto for attempts to trigger on a falling edge being frustrated by spurious triggers on a rising edge. Depending on (edge rise/fall time, noise, IF bandwidth) this is either not a problem at all or it’s a severe enough problem to completely negate any ability to selectively trigger on rising or falling edges.

In terms of FPGA resources and configuration architecture the requirements are fairly modest (I wouldn’t be terribly surprised if it already existed in the FPGA and just hadn’t been brought all the way up into the GUI) but it leads to a substantial quality of life improvement. Some especially keen interfaces put a band around their trigger threshold line to visualize hysteresis (I have a Rohde & Schwarz oscilloscope that does this) but having a stable trigger is desirable enough that the feature doesn’t have to be pretty to deliver its core value.

Thanks again for your detailed reply!

This sounds like perhaps a moving average filter before video trigger would work. We have talked about adding this feature. I’ll chat a bit with the team and see what they think.

[Author]

Posts