This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TLC372-EP: Input Glitch rejection

Part Number: TLC372-EP

What is the debounce time for inputs of the comparator TLC372MDREP? i.e. I am trying to understand what duration of glitches on the input signal will be filtered out by the device and not change its state due to those glitches

I see a propagation delay of 200nsec. Do we have some characterization data showing when the output begins to change as a function of input overdrive & pulsewidth?

  • Hi Steve,

    I have acknowledged your post and I will get back to you by the end of business tomorrow (10/22).

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

  • Hello Steve,

    What you are asking for is called "Minimum Pulse Width" - the narrowest pulse that the comparator will accept cleanly. Some of the higher speed devices do have this characterized, but not for this device.

    Normally this can be estimated by adding the prop delay plus the output rise and fall times.

    In the case of the TLV372, the 5mV prop delay (worst case) is 650ns. The rise and fall time are typically around 50ns. So the theoretical minimum pulse width would be 650ns+50ns+50ns, or 750ns.

    The output just does not fail when the pulse gets too narrow. Instead, the amplitude of the output starts to decrease before failing.

    This is because the output still responds to the input edge and the output starts to slew. But then the narrow input edge changes before the output has reached the final value and reverses. This results in the output starting to distort (triangle-ish or exponential-ish - depending on output type) and decreasing in amplitude before finally failing to respond.

    We do not recommend using the comparator as a "filter", as the actual device prop delay value varies over so many parameters. It would be better to have a more predictable discrete (R-C) filter on the input using a comparator with plenty of prop delay margin.