אי-שם בהיסטוריה, במקום ובזמן שטרם הצלחתי לאתר, מישהו חשב על הרעיון המחוכם להעביר מידע ממחשב למכשיר אחר באמצעות הבהובים על המסך. ההבדל בעוצמת האור בין ריבוע שחור לריבוע לבן על גבי המסך יכול להיקלט בקלות באמצעים גסים יחסית, והמחשב יכול בקלות לתזמן ולצייר את הריבועים הללו כדי לייצג ביטים או סיגנלים אחרים.

השיטה הזו הופעלה בהצלחה לא פעם, אך יש לה כמה מגבלות בולטות. קודם כל, היא איטית להחריד: קצב הרענון של מסך טיפוסי כיום הוא 60Hz, מה שמגביל אותנו – במקרה הכי אופטימי! – ל-7.5 בייטים בשניה, וזה לפני שדיברנו על מחשבים שמחליטים פתאום לבצע איזו משימה "כבדה" אחרת ולחרב את התזמון. כמו כן, בגלל שוני בבהירות בין מסכים שונים ובסביבות עבודה שונות, האמינות של זיהוי הביטים עלולה להיפגע וזה מחייב התייחסות.

במקום לשחזר אחד מהפרוטוקולים הקיימים, על חולשותיו, ולהסתפק בו, החלטתי ליצור פרוטוקול חדש שישלב את היתרונות של אלה הקיימים ויהיה מהיר, אמין ופרקטי לא פחות.

היתרון הדיפרנציאלי

נניח שאני משתמש בארדואינו ובנגד תלוי אור (LDR) שמוצמד למסך כדי לקרוא את ההבהובים. בשלב מסוים אני מקבל את הקלט האנלוגי-לדיגיטלי 600. האם זה ריבוע לבן במסך חלש, או שחור בסביבה בהירה? מה קורה אם אני מזיז קצת את החיישן תוך כדי שידור, או שמישהו מדליק ומכבה את האור בחדר, והערכים משתנים?

פטנט מתוחכם להתגברות על הבעיה, שקיים גם במקומות אחרים (כגון בתקן התקשורת הקווית RS485), הוא לא להסתמך על הערך האבסולוטי אלא על הערך הדיפרנציאלי, ההבדל בין שני אותות שמגיעים בו-זמנית. כפי שהראיתי בפסקה הקודמת, יהיה לי קשה לדעת בוודאות אם אזור מסוים על המסך הוא לבן או שחור – אבל אם אני מסתכל על שני אזורים בו-זמנית, באותו מסך, ואני יודע בוודאות שאחד מהם הוא בהכרח לבן והשני בהכרח שחור, יש לי סיכוי הרבה יותר טוב לדעת מי זה מי. במקום פרוטוקול פשוט של ריבוע אחד שמהבהב, אני מוסיף ריבוע שמראה תמיד את הצבע ההפוך, ואם אחזיק את זוג החיישנים בכיוון הנכון אוכל להסתמך על ריבוע העזר ולקבל קריאה מדויקת של המידע.

מקבילי, מקבילי מדי

אם כבר הוספתי חיישן בשביל המדידה הדיפרנציאלית, למה לא להוסיף עוד חיישנים לצורך שידור וקליטה של מספר ביטים במקביל? פתרון כזה יכול לעבוד, אך מכניס לעניין שיקולים נוספים: כמה פינים אני יכול להקצות במיקרו-בקר מסוים לצורך הקריאה? או שאולי עדיף לקרוא את החיישנים סדרתית באמצעות Multiplexer? ואיך בדיוק לחשב את הדיפרנציאליות כשיש מספר ביטים שכל אחד מהם יכול להיות שחור או לבן?

כפשרה בין כל השאלות האלה, בחרתי בפרוטוקול שנעזר בארבעה ריבועים/חיישנים (מכאן השם שבכותרת), ולמען הקומפקטיות החלטתי שהם יהיו מסודרים בריבוע, 2×2. יש 16 אפשרויות לצבוע ריבוע כזה בשחור ולבן, אך שתיים מהן נפסלות מכיוון ש"הכל שחור" או "הכל לבן" לא מתאימים לבדיקה הדיפרנציאלית. ארבע-עשרה האפשרויות הנותרות כוללות, בהכרח, גם שחור וגם לבן, מה שהופך את הבדיקה הדיפרנציאלית למעשית. המספר 14 לא מתחלק בצורה נוחה לביטים, אבל אפשר לנצל חלק מזה להעברת מידע ואת השאר לשימושים נוספים, כגון סימוני "התחלת שידור", "סיום שידור" וכדומה.

עניין של זמן

פרוטוקולי ההבהובים שמצאתי עד כה הסתמכו – עד כמה שהצלחתי לפענח – על תזמון מסודר, בין אם רווחי זמן שווים או ריבוע של "אות שעון" ממש. כפי שציינתי קודם, לא תמיד אפשר לסמוך על המחשב שירענן את התצוגה בזמן (אם למשל הוא בדיוק טוען במקביל איזו תוכנה כבדה), והקצאה של חיישן לשעון בלבד מרגישה קצת מבוזבזת. לכן, החלטתי שגם בנושא של הפרדה בין קטעי הנתונים השונים, הפרוטוקול שלי יסתמך על דיפרנציאליות.

כלומר, במקום 8 תבניות שחור/לבן שונות שמייצגות את שמונת המצבים של שלושה ביטים (בבינארי 000,001,010,011,100,101,110,111) בהתאמה של אחד-לאחד, יהיו לי 9 תבניות שחור/לבן שונות, וצירוף שלושת-הביטים הנוכחי יחושב לפי המרחק בין התבנית הנוכחית לתבנית הקודמת, מינוס 1. לדוגמה, אם קודם שידרתי את הצירוף 110, ואני רוצה לשדר אותו שוב, אני לא אציג את אותה תבנית אלא תבנית אחת אחריה (ההפרש ביניהן פחות 1 הוא אפס). לעומת זאת, אם אני רוצה לשדר את 111 (שגדול ב-1 מ-110), אציג את התבנית שנמצאת שני מקומות קדימה. כמובן, החישוב יידע להתחשב במחזוריות של התבניות ולא ייתקע באיזשהו "קצה".

השלב הבא: פרטים קטנים

אם כל הנ"ל יעבדו כמצופה, יהיה לי בסיס מוצק לפרוטוקול אמין ומהיר (יחסית). מה שנותר לקבוע הוא אופן הטיפול בנתוני "מטא": איך תאורגן תחילת השידור, איך תבוצע בקרת שגיאות וכדומה. צריך גם לקחת בחשבון את האפשרות שהמיקרו-בקר "יתפוס" את המסך בדיוק באמצע רענון התבנית, כאשר רק חלק ממנה הספיק להשתנות. יש לי רעיונות לגבי כל אלה, ועליהם אדבר בפוסט ההמשך – בשאיפה, גם עם תוצאות של ניסויים ראשוניים.