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!