After-capture adjustable glitch filter


I would like to apply a glitch filter “after the fact” on a finished recording, but cannot activate it (apparently the session is read-only). On the initial recording, the glitch filter was deactivated. During manual inspection of the recording, I found a few glitches that may not have been caused by the DUT (not so sure about that, though). What I was aiming at was: playing around with the glitch filter settings to see what values change; ultimately, I’m trying to find an error in my DUT, and I’d like to check if (with “correct” glitch filter settings) the SPI communication would become “correct” (in terms of my problem domain). The only thing I see is that the byte values in the data table/terminal do not match the datasheet specifications.

See discuss.saleae.com/t/feature-request-change-glitch-filter-in-read-only-session/591


Activity Newest / Oldest



We still need to decide what to do here, but I would love to make the glitch filter editable after the capture. It's quite a challenge though. Would love to hear more about what situations people need this for.
Also, we've been talking internally about detecting glitches (pulses only a few samples wide) during the capture and informing the user.

Peter Jaquiery

Back in the Logic 1 time frame we had screwed up the pull up resistor for an I2C bus so the rise time was slower than ideal. That allowed a little noise on the edge to completely wreck the I2C analyser because the analyser was seeing the glitches as extra clock pulses.

The correct fix of course was to change the resistor. Sometimes it ain't so easy!

Often when glitches are an issue it's because the thresholds for the logic analyser inputs don't quite match the DUT so the collected data doesn't match what the device sees on the line. That is a harder problem to solve! Often the mismatch is because either some weird chip is being used, or because there are mixed logic levels in the system so a compromise is made.



Status changed to: Under review