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.

[jyaron]

“This was resolved in the SM200C, since we filter and resample more aggressively on the FPGA and trigger on the PC…”

Is this why the MATLAB API support file SMIQReceiver.m (for the SM200C) does not offer any support for triggered captures using video, ext or FMT (like SM200BWidebandIQ.m)?

Is triggering expected to be performed by MATLAB code? Since not sure this processing horsepower is possible.

Is it safe to assume that the SM200B is likely a better choice if the most robust MATLAB support is desired?

Are there any plans for an SM200C FW/API update to support optional triggering features similar to SM200BWidebandIQ.m so that extensive MATLAB trigger processing during streaming is not required?

Also, does the SM200C have internal 2sec capture memory (like the SM200B)… allowing for support of future native SM200C based triggered capture features?

Thanks.

• This reply was modified 1 year ago by jyaron.

[Andrew]

jyaron,

Yes, triggering for any I/Q acquisition other than the SM200B/SM435B 250MS/s I/Q capture mode needs to be performed in the customers application. There are no current plans for any firmware updates to the SM200C to enable this functionality on device. The SM200C does not have the 2 second I/Q acquisition mode that the SM200B does, it only supports full 200MS/s (with decimation) streaming. It uses the internal memory for buffering to support full streaming operation.

MATLAB did struggle to even maintain full 200MS/s rates in our testing, so I agree that performing triggering directly in MATLAB at the 200MS/s rate might be difficult. Consider building a small C++ wrapper around our API that performs the triggering that you can call into from MATLAB.

I will add this idea to our customer wish list. It would be interesting to add a triggering interface for customers who do not need streaming I/Q but would like a triggered capture instead.

I appreciate the feedback.

Andrew

• This reply was modified 1 year ago by Andrew.

[Author]

Posts