|
Tim |
Decoding protocols (such as I2C) can commonly fail due to the presence of glitches caused by slow rise/fall times.
We should auto-apply a glitch filter by default in analyzer settings (user can turn it off).
Better yet, we should automatically determine when glitches are present and suggest to the user to enable the glitch filter.
Activity Newest / Oldest
Lucas
For me glitches not only occur on slow rise and fall times but also in noisy environments. (e.g. close to transformers)
Tim
(#86757)
"feature request to add a glitch filter to the protocol analyzers"
Tim
(#68337)
"I used the glitch filter with a default value and the output
from the i2c analyzer is perfect. Many thanks..."
Tim
Glitches are fairly common when capturing I2C data. A glitch filter is typically recommended when decoding I2C, due to the reasons below:
- The pullup resistor causing slow rise/fall times
- Our internal comparators having very minimal hysteresis
Ideally, we should add the ability for the I2C analyzer to detect and ignore glitches without needing to add a glitch filter.
For now, the workaround is to use a glitch filter as described below:
support.saleae.com/protocol-analyzers/analyzer-user-guides/using-i2c
Tim
Merged with: I2C Analyzer to Ignore Glitches
Tim
discuss.saleae.com/t/i2c-decoding-concern/1133
"Take a look at how its interpreting the bits of the address incorrectly, the first data byte incorrectly, and the ACK/NACK wrong. And the up-arrows on the SCL rising edges are missing? Maybe I’m missing something - it’s been a long day."
Tim
#61160
"That did it, thanks!
I’m trying to figure out where this glitch is coming from. My oscilloscope shows a clean signal during SCL HIGH, so not sure why logic-16 is seeing a glitch here.
Is this a sampling artifact or something?"