While trying to measure the speed of the outputs of a GPIO expander, some very short anomalies appear. In the example below, two of them last 4 ns each.
I can get rid of those anomalies by applying a glitch filter and setting the duration at eg. 8 ns.
- However, what are those glitches?
The critical question here is:
- Are they coming from the circuit I am analysing, or are they generated by the Saleae logic analyser hardware, firmware or software?
The first case may invite me to consider another IC. As the glitches are appearing randomly, using an oscilloscope to record a long time and spot the exact period when they appear may be difficult.
- What recommendation, if any, to prevent those glitches from appearing?
In an other configuration with channel 5 and 6 used for I2C, I have noticed the signal from channels 4 and 7 are more prone to raise glitches.
- Should shielded cables be used instead for the signals?
Configuration: Saleae 8 Pro, Logic 2.3.30 running on Debian
@rei_vilo Our Logic Pro 8 is implemented with comparators instead of standard CMOS buffers. That makes the input-low and input-high threshold voltages very close to each other (i.e. very minimal hysteresis). Therefore, glitches are most likely appearing because of rise/fall times on edges being slow to cross the comparator threshold.
The specific voltage thresholds are described below for each of our models:
I2C is the most common culprit due to the rise/fall times being affected by pull up resistors. Unfortunately, shielded cables would likely not help since the rise/fall times are typically the cause.
Given that our comparators have minimal built-in hysteresis, using the glitch filter would be the best way to prevent glitches from confusing an analyzer from decoding data properly.
Thank you for the answer. I’ll use the filters.
Note that grounding can make a difference and noisy power supplies in the device under test can be an issue.
Sometimes it is helpful to look at the signal as an analog signal. That won’t find 4ns glitches, but it will tell you about the quality of the signal and whether the voltage levels are correct. You can capture the same input as both an analog signal and as a digital signal.
@P.Jaquiery : I’m running into glitches, as well, but only when operating at “1.2 Volts” logic level. When selecting “3.3 + Volts” as the logic voltage, the issue goes away.
When compared to the analog signal, the digital line transitions low at about the right time, but then reverts to high for about 2µs longer until it finally goes low again. Snapshot below showing the issue.
Perhaps it’s related to the undershoot voltage of ~128mV on the pin. FWIW, the signal that is being observed is on an isolated circuit so perhaps there is some parasitic capacitance in the system that is playing into the issue.
From your screen captures it looks like your device under test is running at much higher than 1.2V so 3.3V+ is appropriate. Is there some reason you need to use 1.2V?
If you must use 1.2V because other logic in the system is running at that level you may need to whip up external level translators so Logic sees the same logic level for all inputs.
I wouldn’t worry about the small negative value. In my experience the analog inputs have a small negative offset (about 50mV for my unit).
@P.Jaquiery : No, I don’t need to use 1.2V, it’s just that was the default value that I had been using until now.
I hadn’t seen glitches like this previously, which would be a tremendous problem in my circuit if they were real. When the analog signal didn’t back up the digital traces, I thought that some new bug had crept into this release.
I came prepared to report a bug, but instead I got a little more education on the Salea hardware implementation. I hope my experience can help clear up questions for others coming to the forum.
@ethan I wanted to chime in and provide a bit more background behind how the voltage threshold works in hardware, and hopefully might further explain why you might be seeing these glitches.
Logic Pro 8 and Logic Pro 16 employ fixed voltage threshold options with little to no hysteresis (we don’t characterize the hysteresis amount either). Typically, this means that, if the rising/falling edges have a relatively gradual slope, any inline noise might trigger these glitches (due to the little to no hysteresis around the threshold). The voltage threshold options are discussed in more detail in the support article below.
The analog bandwidth on our products is much lower than the digital bandwidth, and therefore, analog captures on the same channel as the digital one may not show the high frequency noise that might be triggering the digital glitches during the rising/falling edges. We also have internal hardware and software filters that change depending on the sampling rate selected. We describe this in more detail below:
For the reasons above, we usually recommend enabling the glitch filter in cases like this.
Thanks, @timreyes ! That’s what I learned from reading through your original response.
For my circuit, I was able to avoid the glitch filter computational overhead by setting the expected voltage range to “3.3 + Volts”. But if the system get’s difficult in the future, I’ll keep the glitch filter in mind.