After-capture adjustable glitch filter

Voters 18

C
F
M
L
U
+ 12 voters
C
A
D
K
J
A
A
M
M
T

Open
Subscribe

David

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

18-06-2020 -

Activity Newest / Oldest

Tim

(#86978)
"I cannot use the glitch filter as I cannot capture the data again. It would be great to have a feature that lets you set a channel to whatever logic value you want between two time points t1 and t2 thereby allowing the user to manually suppress any logic transitions they want."

Tim

(#86757)
"Often, I find myself running a capture and only noticing afterwards that I need a glitch filter. Especially with SPI and UART."

Tim

discuss.saleae.com/t/post-recording-glitch-filtering/2378
"We have a couple of Logic-Pro-16s around and where recording traces from several QSPI experiments over the past months by using this awesome Python automation API.
It is super nice!
So, please imagine that at this point there are Terabytes of logic traces captured under different scenarios.

As the decoding of QSPI is not officially supported by you, we are using this six year old solution, which still works like a charm!

However, we have now some issues with glitches. The decoder does not decode correctly, when there exist glitches on chip-select or data lines.

Post-Recording (read only session) glitch-filtering is not supported.

Exporting to CSV, filtering the glitches and importing the filtered data to Logic2 is also not supported."

Tim

(#81423)
"in Logic 1 I could set a glitch filter for a signal and it was immediately applied to that signal, now it seems you must recapture a new signal for it to be applied. If I have a problem on my screen and want to see it without glitches, I can’t."

Tim

discuss.saleae.com/t/logic-16-pro-capture-intermittently-incorrect/2116/7
"@timreyes it would be really nice to be able to post process a capture with glitch filtering on!"

Tim

(#77508) Somewhat related request, but here is another scenario which causes confusion around applying the glitch filter (primarily caused by our glitch filter being applied during a capture, rather than after a capture).

1. Capture is taken
2. User enables glitch filter
3. Nothing seems to happen (due to the expectation that the glitch filter is applied as a post-process)

Daniel

Restore this functionality in logic2!! A must-have!

Tim

(#72938)
"hi,
can i delete the glitch after the wave have got?"

Allan

You can! If you use Logic version 1.x..

Tim

(#62773)
User is running into ReadTimeouts when glitch filter is enabled...post-process of glitch filters would help in this case.

"When I removed all glitch filter, it seems to be ok. Waiting for trig for about 30 minutes and Saleae still ongoing and waiting for trig, good."

Tim

twitter.com/ghidraninja/status/1406609162054815745
"Is this something I can expect to change soon? Completely breaks version 2 for me, I don't know how noisy my signals might be until AFTER I recorded it😶

Is there any workaround or so I can use to fix my trace?"

Tim

(#59837)
"That reminds me of a question that came up to me when switched from Logic 1 to Logic 2. Why did you change the behavior of the glitch filter so massively? In Logic 1 it was a matter of post processing. Now you have to determine glitch filter settings before you start capturing. This is very inconvenient. Imagine you try to catch a very shy event and you need a long time to get one capture of it. Then you look at the data and realize that you have glitches on some channels. Now you are forced to throw away everything and start over. From experience I can tell that it often needs multiple attempts until you get the glitch filters configured satisfactorily. In Logic 2 this forces you to also capture your event multiple times. This is really annoying. In my opinion glitch filtering belongs to post processing and this would automatically solve the RAM issue. But I don’t know your reasons for the design decisions you made."

Tim

(#58263)
"In Logic 1, you could enable glitch filter *after* a log was already captured. In Logic 2, I get a warning that the session is read-only when I try to enable glitch filter on an existing log. This may not actually be a bug, but is definitely functionality that I would like to be available in Logic 2."

Matthew

Post-capture glitch filter adjustments would be very helpful in that you can try the different settings without having to recapture an event. Useful for logs which you may not have initially realized had glitches.

Tim

"I understand that glitch filter must be set up prior to recording in Logic 2.x - in Logic 1.x it could be applied after recording.
Are there any plans making it possible to do after capture in 2.x in the future? It is really annoying to finally capture some situation and then realize that there are some noise so e.g. UART decoding doesn't work. Or even more annoying; the filtering was set up, but some noise pulses turn out to be a little longer than expected..
But I really love your products. I work as an embedded SW engineer, and it is really a cool tool that makes my life so much easier - thanks!!"

(#57309)

Neel

Status changed to: Open

Mark

Status changed to: Under review

Mark

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.