Calculator inputs
Example data table
| Scenario | Bounce max (ms) | R (Ω) | C (nF) | τ (ms) | Settle to 1% (ms) |
|---|---|---|---|---|---|
| Mechanical key switch | 12 | 10,000 | 100 | 1.000 | 4.605 |
| Industrial pushbutton | 25 | 22,000 | 220 | 4.840 | 22.300 |
| Hall sensor (clean signal) | 2 | 4,700 | 10 | 0.047 | 0.216 |
Formula used
- RC time constant: τ = R × C
- Settle time to within p%: t = −τ ln(p/100)
- Digital (max rule): td = bouncemax × safety
- Digital (sigma rule): td = mean + k × std
- Digital (percentile): td = mean + z(p) × std
- Hybrid recommendation: t = max(td, tsettle)
How to use this calculator
- Measure switch bounce using a scope or logic analyzer.
- Enter bounce max, and optionally mean and std.
- Choose your debounce approach: digital, RC, or hybrid.
- Set sampling interval to match your firmware timing.
- Review samples needed, then validate on hardware.
Contact bounce and false triggering risk
Mechanical contacts can toggle dozens of times before settling. In practice, bounce durations often land between 2 ms and 30 ms, depending on spring force, oxidation, and actuation speed. Relays can be slower, with 10 ms to 50 ms contact chatter during closure. The calculator converts your measured bounce into a conservative window so firmware ignores transient edges while still recognizing genuine state changes.
Digital timing with measurable statistics
If you have only a worst case value, use a safety factor such as 1.5 to 2.0 to cover temperature drift and aging. When you also know mean and standard deviation, the mean plus k·sigma rule estimates an upper bound for most events. The percentile option uses a z score, which is useful when you target 90% to 99% confidence for safety critical inputs.
RC filtering and settling percentage
An RC network smooths fast transitions by introducing a time constant τ = R×C. For a first order response, settling to 1% requires about 4.6τ, and settling to 0.1% requires about 6.9τ. For example, 10 kΩ and 100 nF gives τ≈1 ms and 1% settling near 4.6 ms. The tool computes settle time directly from −τ ln(p/100) and compares it against your measured bounce.
Sampling interval and stable sample count
Debouncing in software is limited by how often you sample the input. If your polling period is 2 ms, a 20 ms debounce requires at least 10 consecutive stable reads. The calculator reports the sample count and the effective window after rounding, helping you align timers, interrupts, and scheduler ticks without losing robustness.
Design tradeoffs and verification workflow
Long debounce windows improve immunity but increase perceived latency and may miss fast pulses from encoders. Hybrid mode takes the maximum of digital timing and RC settling, a safe choice for noisy installations. Many designs also use separate press and release delays, since bounce can be asymmetric. After selecting a value, validate on hardware with repeated actuations, record worst case bounce, and log any false triggers under vibration, EMI, and supply variation. Adjust factors until response and reliability meet your specification, then freeze the parameters for production testing.
FAQs
What debounce time should I start with for a pushbutton?
Start with your measured bounce max multiplied by 1.5–2.0. If you lack measurements, try 10–20 ms for common pushbuttons, then validate on hardware across temperature and vibration.
When should I choose RC filtering instead of digital timing?
Choose RC filtering when cable noise or EMI causes rapid glitches, or when the input circuit benefits from slower edges. Verify that the added τ does not distort pulse timing or violate input threshold requirements.
How does the percentile option estimate a safe debounce window?
It assumes bounce durations follow an approximate normal distribution. The calculator converts your percentile to a z score and computes mean + z·std, giving a statistically motivated window for your chosen confidence level.
Why does the calculator show a stable sample count?
Software debouncing requires consecutive consistent reads. The stable sample count tells you how many polls must agree before accepting a change, based on your sampling interval and the rounded debounce window.
Can I use different debounce values for press and release?
Yes. Many switches bounce differently on make and break. Measure both edges, then assign separate windows in firmware, or apply asymmetric rules when timing and user experience demand faster release recognition.
What if the recommended debounce exceeds my response target?
Reduce the safety factor, improve the switch hardware, increase filtering quality, or separate debounce from long-press logic. Always re-test to ensure false triggers remain below your acceptable defect rate.