אם הגעתם לעולם האלקטרוניקה דרך ארדואינו, ויצא לכם לבנות מעגל עם לחצן, סביר להניח שמימשתם (או העתקתם) את שיטת ה-debounce שמוצגת באתר הרשמי: מסתכלים על הקלט מהלחצן, ואם הוא שונה ממה שהיה קודם, מחכים כמה אלפיות השניה ואז בודקים שוב כדי לוודא שמדובר בלחיצה (או שחרור) אמתית. סביר להניח גם שזה עבד בסופו של דבר. אבל הנה שאלה שאולי לא חשבתם עליה: כמה פעמים, אם בכלל, קרה שבדיקת הווידוא הזו נכשלה?
השאלה היא אמנם שאלה אמפירית, אבל אם נחשוב רגע מה בעצם אנחנו מנסים לעשות, אנחנו עשויים להגיע למסקנות שונות לגמרי לגבי הגישה שלנו מלכתחילה ל-debounce (למי ששכח: לחצנים מכאניים לא עוברים בצורה חלקה ממצב למצב אלא "רועדים" קצת בין לבין [bounce] למשך כמה אלפיות שניה. ה-debounce היא כל שיטה שמטרתה לסנן את הרעידות האלה ולתת למערכת שלנו אות נקי).
בואו נסתכל על הסיגנל שאמור להתקבל מלחצן טיפוסי עם Bounce, כשהוא עובר ממצב X למצב Y (משמאל לימין):
xxxxxxxxxxx?????yyyyyyyyyyy
כל סימן שאלה בפני עצמו מייצג ערך לא ידוע: יכול להיות שנקבל שם X או Y, באופן אקראי לגמרי. כעת, נניח שאנחנו מבצעים debounce בשיטה שתוארה למעלה: ברגע שמופיע ה-Y הראשון (וזה יהיה כנראה אחד מסימני השאלה), אנחנו נמתין פרק זמן שאמור לכסות את כל הטווח של סימני השאלה, ואז נבדוק… רגע, בשביל מה לבדוק? האם ייתכן שאחרי פרק הזמן הזה הסיגנל לא יהיה Y?
יש שני מצבים שבהם הסיגנל עלול להיות שונה מ-Y. המצב הראשון הוא כאשר פרק הזמן שחיכינו ארוך מדי והמשתמש כבר עזב את הלחצן. המצב השני עלול להופיע אם יש במערכת רעשים אקראיים קצרים שבכלל לא קשורים ללחיצות של המשתמש. שני המצבים האלה בעייתיים כשלעצמם, ובדיקת הווידוא לא פותרת את הבעיה כלל.
אותו הדבר נכון לגבי שיטה אחרת ל-debounce באמצעות תוכנה, שמופיעה גם היא באתר ארדואינו הרשמי: בדיקה של הקלט במרווחי זמן שווים, ו"הכרזה" על ערך יציב רק אם התקבל ערך זהה לאורך N מדידות. מבחינת היעילות בתסריט שתואר, זה די דומה לשיטה הקודמת – פרט לעובדה שבמקרים מסוימים זה עלול לגרום לעיכוב נוסף בזיהוי הלחיצה (או השחרור), ואם מספר המדידות או הרווח ביניהם גדול, העיכוב הזה יכול להגיע לרמה שתורגש על ידי המשתמש – וזה כמעט אף פעם לא רצוי.
אם אנחנו יכולים להניח ברמת וודאות גבוהה שאין רעשים אקראיים במערכת, מספיק בהחלט לזהות שינוי אחד ויחיד, ואז פשוט לא לבדוק שוב עד שאנחנו בטוחים שה-bounce נגמר. לעומת זאת, אם יש סיכוי להפרעות חיצוניות, צריך לבדוק מה האופי שלהן ולנטרל אותן במקור, או להתאים את שיטת ה-debounce למקרה הספציפי.
אין שיטת debounce אחת "נכונה" שמתאימה לכל המקרים, וגם בנושא טריוויאלי-לכאורה שכזה מסתתרת מורכבות שצריך להכיר כשעוברים ממשחקים על מטריצה אל העולם האמתי. לקריאה נוספת (ומרתקת) בנושא, הנה מאמר של ג'ק גנסל, אדם שמבין דבר או שניים בעולם ה-Embedded: