1. State the decision and output polarity
A comparator requirement begins with the input condition that the application needs to distinguish. For a threshold monitor, describe which side of the threshold represents the asserted condition and what logical result the receiving function expects. A phrase such as threshold detector can omit this relationship, leaving the intended decision ambiguous even when the comparator family is known.
TI's reference-design explanation uses an inverting example: an input above the comparison threshold produces a low result, and an input below it produces a high result. Retain this as the polarity of the named example. It is not a universal statement that all comparator applications use that relationship, nor does it identify the physical connections of another circuit.
Logical polarity describes what the result means in relation to the compared input. Output-stage topology describes how that result is presented electrically. A push-pull or open-drain label cannot resolve the inequality the application needs to detect. Conversely, calling a result active low does not independently identify the comparator's output-stage type or establish its receiving interface.
2. Explain repeated crossings near one threshold
With one switching threshold, an input that moves back and forth across it can repeatedly reverse the comparator decision. TI illustrates this issue through a noisy input approaching the boundary. The underlying problem is the repeated crossing, rather than uncertainty about which output-stage category the component uses. A correctly identified interface can still carry unwanted repeated decisions.
A slowly changing wanted signal makes the near-threshold region relevant because disturbances can move the instantaneous input between the two sides before the intended transition is complete. This gives the application a more useful question than whether the input is generally noisy. Ask what disturbance accompanies the wanted crossing and what repeated changes the receiving function must avoid.
The consequence depends on what uses the result. A monitor receiving repeated transitions faces a different decision history from one receiving a single intended state change. That explains why threshold behavior belongs in the requirement. It does not establish a fault in an unidentified system or prescribe how a controller should interpret, delay or process the comparator output.
3. Define separate rising and falling thresholds
Hysteresis introduces separate switching boundaries for the two directions of input change. In TI's inverting example, crossing the upper boundary causes the low transition, while crossing the lower boundary causes the high transition. The direction of the crossing therefore matters. One nominal threshold cannot fully describe this behavior because it omits the separation between those boundaries.
Within the interval between them, the previous state remains relevant to the decision. An input moving upward and an input returning downward do not necessarily trigger a change at the same intermediate level. This is the useful meaning of the two-threshold description. It should remain understandable without turning the article into a resistor-selection method or assigning numerical thresholds to the reader's application. This makes the interval a decision-history question as well as a threshold question. A requirement should explain the wanted assertion and release crossings together, instead of selecting one boundary and leaving the return behavior implicit.
The disturbance must also be considered against the hysteresis interval. TI explicitly notes that a disturbance exceeding that interval can cause additional transitions. Hysteresis is therefore a defined decision behavior with an application-dependent rejection question. The label alone should not become an unconditional noise-immunity promise, and a wider interval is not automatically the right answer to an unspecified measurement requirement.
4. Keep threshold behaviour separate from output stage
The engineering requirement should state which rising and falling events matter to the monitored condition. Those events describe when the result should change, while the output-stage requirement describes how the receiving circuit obtains that result. Keeping these two questions visible prevents a suitable open-drain or push-pull selection from being mistaken for a completed threshold assessment.
For example, a circuit may need to assert a condition on one crossing and release it only after the input returns past a different boundary. That is a hysteresis question even if the electrical interface remains unchanged. A proposal changing the comparator's output stage instead raises a separate interface question, and neither change should silently answer the other.
Ask the reviewer to relate the wanted crossings, input disturbance and receiver interpretation to the exact comparator implementation. The named TI example explains why those relationships matter; it does not choose component values or establish the behavior of the customer's monitor. No wiring instruction, simulation or measured waveform is supplied. The sourcing decision becomes clearer when decision polarity, threshold separation and output identity each retain their own role.
Sources and further reading
TI TIDU020A physical pages 3–6 were reread as saved text on 15 October 2026 for the inverting example, repeated crossings and distinct hysteresis thresholds. No numerical values, resistor design, wiring, plotted waveform or tested immunity is supplied.