11.3. הרדיו ושכבת הקישור

שתי השכבות התחתונות של מחסנית ה-BLE כמעט אוטומטיות לחלוטין מנקודת מבטו של Python – סיליקון הרדיו והשכבות ש-MicroPython רץ מעליו מטפלים בכול, מבחירת ערוץ ועד שידור מחדש של מנה אבודה. שלוש מהבחירות שהם עושים עדיין מבצבצות אל ה-API הפונה למשתמש: צריכת חשמל, טווח ותפוקה.

11.3.1. הרדיו

BLE משתמש באותו פס Industrial-Scientific-Medical (ISM) של 2.4 GHz כמו Wi-Fi, תנורי מיקרוגל ורוב התקשורת האלחוטית האחרת לטווח קצר. הפס מחולק ל-40 ערוצים ברוחב 2 MHz.

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

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

40 ערוצי ה-BLE בפס 2.4 GHz. שלושה משמשים לפרסום, השאר נושאים תעבורה על חיבור פתוח.

הרדיו משדר מנות קצרות – באורך של מילישניות ספורות לכל היותר – וישֵן בין לבין. אותה שינה היא מה שהופך את הטכנולוגיה לאנרגיה נמוכה. peripheral טיפוסי של BLE מבלה הרבה פחות מאחוז אחד מזמנו בשידור בפועל; השאר הוא הרדיו כבוי בין אירועים מתוזמנים.

11.3.2. שכבת הקישור

שכבת הקישור היא היחידה הקטנה ביותר של BLE שמדברת עם מקבילתה בהתקן אחר. היא מטפלת בארבע משימות.

• מסגור מנות. כל מנה נושאת כותרת קצרה (כתובת גישה לערוץ, אורך מנה, ביטי בקרה), מטען, ו-CRC. המקלט בודק את ה-CRC ומשליך כל דבר שהושחת.

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

• תזמון חיבור. ברגע ששני התקנים מתחברים, שכבת הקישור מתזמנת אירועי רדיו תקופתיים על רצף הקפיצה – במרווח connection interval קבוע – וארוזת לכל אחד מהם את כל הנתונים שבתור משכבת ה-GATT שמעליה. שני הצדדים חוזרים לישון בין אירועים. ה-connection interval הוא בורר שהאפליקציה יכולה לבקש (ראו חיבורים).

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

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

11.3.3. מה שהמצלמה ועמית חולקים

הרדיו בשני הקצוות מסכים בזמן החיבור על קומץ פרמטרים השולטים בשיחה:

• ה-connection interval – כל כמה זמן שני הצדדים מתעוררים כדי להחליף מנות, בכל מקום בין 7.5 ms ל-4 שניות.

• ה-peripheral latency – כמה מרווחים רצופים ה-peripheral רשאי לדלג אם אין לו מה לומר, כדי לחסוך בחשמל.

• ה-supervision timeout – כמה זמן כל צד ממתין לפני שהוא מכריז על הקישור כאבוד כאשר הצד האחר משתתק.

• ה-MTU – המנה היחידה הגדולה ביותר שכל צד ימסור ל-GATT (ברירת המחדל 23 בייטים, ניתן לנהל עליה משא ומתן כלפי מעלה).

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

11.3.4. מה ש-Python רואה מכל זה

כמעט כלום. ה-API של bluetooth ושל aioble אינם חושפים ערוצים, רצפי קפיצה, CRC של מנות או טיימרי שידור מחדש; כל אלה מטופלים בתוך פורט ה-BLE והרדיו. החלקים שכן מבצבצים הם אלה שהמשא ומתן בזמן החיבור חושף – connection interval, MTU, סוג כתובת.