BLE הוא לא "עוד פיצ'ר" — הוא ארכיטקטורה

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

תכנון שירותי GATT: ה-API של המוצר שלכם

מבנה ה-GATT — שירותים (Services) ומאפיינים (Characteristics) — הוא חוזה בין הקושחה לאפליקציה. כמה עקרונות שחוסכים כאבי ראש:

  • השתמשו בשירותים סטנדרטיים היכן שקיימים — סוללה, מידע התקן, מדידות מוגדרות. אפליקציות וכלי בדיקה מכירים אותם אוטומטית.
  • תכננו את המאפיינים סביב תרחישים, לא סביב רגיסטרים. אפליקציה שצריכה לקרוא חמישה מאפיינים כדי להציג מסך אחד תהיה איטית; עדיף מאפיין אחד עם מבנה נתונים ארוז.
  • Notify במקום Polling. קריאה יזומה חוזרת מהאפליקציה מבזבזת אנרגיה בשני הצדדים; עדכון יזום מהקושחה כשיש נתון חדש — יעיל בהרבה.
  • גרסאות מהיום הראשון. מאפיין גרסת פרוטוקול פשוט מונע שבירת תאימות כשהמוצר בשטח והאפליקציה מתעדכנת. חשוב במיוחד לקראת עדכוני קושחה מהאפליקציה (DFU).

פרסום (Advertising): הפשרה המרכזית

מכשיר BLE שלא בחיבור משדר פרסום במרווח קבוע — וכאן יושבת פשרה ישירה בין חוויית משתמש לצריכת חשמל. מרווח קצר (20–100 מילישניות) נותן גילוי וחיבור מיידיים אך שורף סוללה; מרווח ארוך (1–2 שניות) חסכוני מאוד אך המשתמש מחכה. דפוס מקובל: פרסום מהיר ל-30–60 שניות אחרי אירוע (הדלקה, לחיצת כפתור), ואז ירידה למרווח איטי או הפסקה מלאה. תכולת הפרסום עצמה חשובה: שם, שירותים מזוהים ונתוני יצרן צריכים להספיק לאפליקציה כדי לסנן את המוצר שלכם בסריקה — ראו איך זה נראה מצד הטלפון במאמר איך אפליקציה מתחברת למוצר בבלוטות'.

פרמטרי חיבור: המקום שכולם שוכחים

אחרי החיבור, מרווח החיבור (Connection Interval), ה-Slave Latency וה-Supervision Timeout קובעים גם את קצב הנתונים וגם את הצריכה. סטרימינג של מדידות דורש מרווח קצר; מוצר שמדווח פעם בדקה יכול לבקש מרווח ארוך ו-Latency גבוה ולחסוך פי עשרות באנרגיה. חשוב לזכור שהטלפון הוא שמאשר את הפרמטרים, וכל מערכת הפעלה מתנהגת אחרת — הקושחה חייבת לטפל גם בסירוב.

צריכת חשמל: המספרים שקובעים את חיי הסוללה

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

קצב נתונים: מה BLE באמת מסוגל להעביר

BLE אינו ערוץ לווידאו — אבל הוא מפתיע כשמכווננים אותו. עם משא-ומתן על MTU גדול (עד 247 בייט שימושיים) והרחבת אורך פקטה, אפשר להגיע בפועל לעשרות עד מאות קילוביט בשנייה — מספיק להעברת לוגים, גלי מדידה ואפילו קובצי DFU בזמן סביר. הטעות הנפוצה: להשאיר MTU ברירת מחדל של 23 בייט ולתהות למה סנכרון של יומן מדידות לוקח דקות. תכננו את פרוטוקול ההעברה כך שינצל את מה שהטלפון מאשר בפועל, עם נפילה חיננית לערכים נמוכים.

אבטחה ובדיקות

צימוד (Bonding) עם הצפנה הוא המינימום למוצר מסחרי; מוצר שמשדר נתונים אישיים בלי הצפנה הוא בעיה משפטית, לא רק טכנית. ובבדיקות — BLE ידוע ברגישותו להבדלי התנהגות בין טלפונים: מומלץ מטריצת בדיקות עם מגוון מכשירים, וכלי סריקה ייעודיים לניפוי. תשתית הקושחה שמסביב — בחירת RTOS או Bare Metal — משפיעה ישירות על ניהול האירועים והשינה.

כמה זה עולה ומה הלאה

שילוב BLE מוסיף לרוב שבועות בודדים עד חודשים לפיתוח הקושחה, תלוי במורכבות ה-GATT ובדרישות הצריכה — סדרי גודל במאמר כמה עולה פיתוח firmware. עוד בנושאי קושחה — בעמוד פיתוח תוכנה embedded.

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.