כיול של נוכחות

בדף הזה מוסבר איך להגדיר ולכייל את הדרישות של כיול הנוכחות במכשירים עם Android מגרסה 14 ואילך.

כדי לוודא שהמכשירים החכמים של המשתמשים פועלים היטב יחד, חשוב שכל המכשירים בסביבה העסקית של Android יוכלו לקבוע את הקרבה היחסית בין המכשירים. ב-Android 14 נוספו דרישות כיול בנושא נוכחות, שמפרטות את הביצועים המקובלים של טכנולוגיות רדיו זמינות שמשמשות לקביעת קרבה, כמו פס רחב במיוחד (UWB),‏ Wi-Fi ו-Bluetooth עם צריכת אנרגיה נמוכה (BLE).

מכשיר להתייחסות

כדי לכייל את המכשיר כך שיעמוד בדרישות הנוכחות, צריך להשתמש באחד ממכשירי הייחוס הבאים לכל הכיולים.

  • (מומלץ) טלפון Pixel
  • אם לא משתמשים בטלפון Pixel, צריך להשתמש במכשיר מאותו יצרן ובאותו דגם של המכשיר שנבדק.

גורמי צורה

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

דרישות ל-UWB

הדרישות לגבי UWB מפורטות בקטע 7.4.9 במסמך CDD.

הגדרת כיול UWB

כדי לכייל את המכשיר בהתאם לדרישות של UWB, צריך להשתמש בהגדרה הבאה.

דרישות כלליות להגדרה

  • נדרשים שני מכשירים עם חומרה של UWB, אחד בתור DUT ואחד בתור מכשיר ייחוס.

  • צריך שני חצובות כדי להחזיק את המכשירים.

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

דוגמה להגדרת כיול של UWB מוצגת באיור 1 ובסרטון 1.

הגדרת ייחוס לכיול BLE

איור 1. הגדרת ייחוס לכיול UWB.

סרטון 1. הגדרת ייחוס לכיול UWB.

אימות התאימות של CDD 7.4.9 [C-1-6] ו- [C-1-7]

כדי לוודא שהמכשיר תואם ל-CDD 7.4.9 [C-1-6] ו-[C-1-7], מריצים את הבדיקה RangingMeasurementTest#test_distance_measurement_accuracy multidevice CTS של מדידת מרחק. זוהי בדיקת CTS ידנית.

run cts -m CtsUwbMultiDeviceTestCase_RangingMeasurementTests -t RangingMeasurementTest#test_distance_measurement_accuracy

אם יש יותר משני מכשירים שמחוברים למחשב המארח של CTS, צריך לציין את מזהה ה-DUT ואת מזהה מכשיר הבדיקה הווירטואלי בפקודה run cts.

run cts -m CtsUwbMultiDeviceTestCase_RangingMeasurementTests -t RangingMeasurementTest#test_distance_measurement_accuracy --shard-count 2
-s DUT_ID -s REFERENCE_DEVICE_ID

במקרה הבדיקה של CTS לריבוי מכשירים, מתחילה סשן של מדידת מרחק באמצעות UWB בין המכשיר הנבדק לבין מכשיר הייחוס, ומתבצעות 1,000 מדידות באמצעות המכשיר הנבדק. לאחר מכן, המדידות מעובדות אוטומטית בבדיקה ונקבע אם המכשיר עבר את הבדיקה או לא, באופן הבא:

  1. ממיינים את המדדים בסדר עולה.

  2. מחשבים את הטווח כך: הטווח = המדידה ה-975 – המדידה ה-25.

  3. דיווח על הטווח בבדיקת CTS מרובת מכשירים. כדי שהבדיקה תעבור, הטווח צריך להיות קטן מ-30 ס"מ.

  4. דיווח על ערך החציון (500) בבדיקת CTS במספר מכשירים. כדי לעמוד בדרישות, הערך צריך להיות בין 0.75 מ' ל-1.25 מ' כולל.

הדרישות לשימוש ב-Wi-Fi Neighbor Awareness Networking

בקטע CDD 2.2.1. חומרה כוללת דרישות לתאימות ל-Wi-Fi Neighbor Awareness Networking (NAN).

אימות התאימות של CDD 2.2.1 [7.4.2.5/H-1-1]

כדי לוודא עמידה בדרישות של CDD 2.2.1 [7.4.2.5/H-1-1]:

  1. מתקינים את אפליקציית CTS Verifier‏ (CTS-V) במכשיר הנבדק ובמכשיר הייחוס (אם היא לא מותקנת בהם), ופותחים אותה. בדיקת CTS-V לדרישה הזו נמצאת בקטע Presence Test > NAN Accuracy Test.

  2. ממקמים את המכשיר הנבדק במרחק הבדיקה של 10 ס"מ מהמכשיר הייחוס, בלי שום דבר ביניהם.

  3. במסך הבדיקה של מכשיר הייחוס, מוודאים שתיבת הסימון Is reference device (האם זה מכשיר ייחוס) מסומנת, ואז מקישים על Start publishing (התחלת הפרסום).

  4. בפעילות CTS-V ב-DUT, בוחרים את מרחק הבדיקה של 10 ס"מ, ומקישים על התחלת הבדיקה. לאחר מכן, כלי CTS Verifier מבצע 100 מדידות של טווח, ומחשב ומתעד את טווח המדידות ביומני CTS-V. בסיום הבדיקה, בודקים אם הטווח המחושב נמצא בטווח הצפוי באפליקציית CTS Verifier ב-DUT.

  5. חוזרים על שלבים 1 עד 4 לגבי מרחקי הבדיקה האחרים של מטר אחד, 3 מטרים ו-5 מטרים. הבדיקה עוברת אם הטווחים של כל מרחקי הבדיקה נמצאים בטווח הצפוי. אחרת, במסך CTS-V מוצגים מרחקי הבדיקה שבהם הבדיקה נכשלה.

דרישות לגבי RSSI של BLE

בסעיף 7.4.3 בנושא CDD. ‫Bluetooth כולל דרישות לתאימות ל-BLE RSSI.

הגדרת כיול

כדי לכייל את המכשיר כך שיעמוד בדרישות של BLE RSSI משתמשים בהגדרה הבאה.

דרישות כלליות להגדרה

  • לקבלת תוצאות אופטימליות, מומלץ להשתמש בחדר אנהדרואי כדי למזער את ההפרעות למדידות.

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

  • מכינים את מכשיר בדיקה וירטואלי ואת המכשיר שנבדק:

    • חשוב לוודא שלשני המכשירים יש מספיק סוללה כדי להשלים את הבדיקות.
    • מנתקים את שני המכשירים מהחשמל במהלך הבדיקה.
    • מסירים את כל הכיסויים, החוטים המחוברים ופריטים מחוברים אחרים שיכולים להשפיע על הביצועים של תדרי הרדיו (RF).

  • מחברים כל מכשיר לחצובה באמצעות מתקן למכשיר.

    • מומלץ שחצובות ומחזיקי מכשירים יכילו כמה שפחות מתכת.
    • קפיץ מתכת קטן במחזיקי מכשירים הוא בסדר.

  • מסירים חפצי מתכת שמפרידים בין שני המכשירים.

הגדרת ייחוס לכיול BLE

איור 2. הגדרה לדוגמה לכיול BLE.

אימות התאימות של CDD 7.4.3 [C-10-1]

כדי לאמת את התאימות ל-CDD 7.4.3 [C-10-1]:

  1. מתקינים את אפליקציית CTS Verifier‏ (CTS-V) במכשיר הנבדק ובמכשיר הייחוס (אם היא לא מותקנת בהם), ופותחים אותה. בדיקת ה-CTS-V לדרישה הזו נמצאת בקטע Presence Test > BLE RSSI Precision Test.

  2. ממקמים את המכשיר הנבדק במרחק של מטר אחד מהמכשיר הייחוס, בהתאם להגדרת הכיול של BLE.

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

  4. כשאיסוף הנתונים מסתיים (אחרי שנאספים 1,000 סריקות ב-DUT), הבדיקה עוברת או נכשלת באופן אוטומטי, בהתאם לטווח המחושב. כדי לעמוד בדרישה, הטווח צריך להיות שווה ל-18 dBm או פחות.

אימות התאימות של CDD 7.4.3 [C-10-2]

כדי לוודא עמידה בדרישות של CDD 7.4.3 [C-10-2]: ספק השבבים יכול למדוד את השטיחות של הערוץ ולזהות את ההבדלים בין ליבות וערוצים.

בהמשך מפורטים טיפים לזיהוי בעיות בליבות לא מכוילות ובערוצים לא מכוילים, שהם שתי סיבות אפשריות לפיזור רחב של עוצמת האות.

ליבות לא מכוילות

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

נתוני סריקה לדוגמה של מכשיר עם ליבות לא מכוילות

איור 3. דוגמה לנתוני סריקה של מכשיר עם ליבות לא מכוילות.

ערוצים לא מכוילים

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

דוגמה לנתוני סריקה של מכשיר עם ערוצים לא מכוילים

איור 4. דוגמה לנתוני סריקה של מכשיר עם ערוצים לא מכוילים.

אימות התאימות לדרישות של CDD 7.4.3 [C-10-3] ו- [C-10-4]

גם אם שבב רדיו BLE מכויל בצורה מושלמת, עוצמת אות הרדיו (RSSI) שנמדדת במכשיר מסוים תלויה באיכות האנטנה ובמיקום שלה במוצר המסוים (דגם המכשיר). הדבר יוצר בעיה ביכולת הפעולה ההדדית בין המכשירים.

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

כדי להבטיח יכולת פעולה הדדית בין כל המכשירים במערכת האקולוגית, צריך למדוד את היסט ה-Rx של כל מכשיר ולשנות את ה-RSSI שמדווח במכשיר כדי לוודא ש-RSSI של BLE עומד בתקן של 1 מ' ב-ADVERTISE_TX_POWER_HIGH.

גם כששבבי הרדיו של BLE מכוילים בצורה מושלמת, המקלט האידיאלי קורא RSSI שונה בהתאם לאיכות האנטנה ולמיקום האנטנה במכשיר הפרסום. הדרישה לגבי Rx מבטיחה שכל המכשירים יוכלו לפרסם עם אותה עוצמה, בתנאי שכל שאר הפרמטרים זהים.

במכשירים עם Android מגרסה 14 ואילך, כדי לוודא שהמכשיר עומד בדרישות של Rx ו-Tx:

  1. מתקינים (אם לא הותקנה קודם) ופותחים את אפליקציית CTS Verifier (CTS-V) גם במכשיר הנבדק וגם במכשיר בדיקה וירטואלי. בדיקת CTS-V לדרישה הזו נמצאת בקטע Presence Test > BLE Rx/Tx Offset Precision Test.

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

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

  4. ב-DUT, מקישים על הפעלת הבדיקה. בבדיקה הזו, כדי לאמת את דרישת ה-Rx, מכשיר ההפניה מבצע סריקות ברקע במקביל לזמן שבו מתחיל הפרסום.

    כשאוספים את כל הנתונים (1,000 סריקות בשני המכשירים), הבדיקה עוברת אם החציון המחושב (המדידה ה-500) של שתי הבדיקות Rx ו-Tx הוא בין ‎-65 dBm ל-‎-45 dBm. הבדיקה נכשלת אם החציון המחושב של בדיקת ה-Rx או ה-Tx לא נמצא בטווח המקובל.

  5. מבצעים כיול של המכשירים כדי לפצות על ההיסט של Rx ועוצמת השידור (Tx) כדי להבטיח עוצמת אות חציונית (RSSI) של ‎-55 dBm.

    • המלצה: כדי להתאים את עוצמת האות (RSSI), צריך להגדיר את מאפיין המערכת bluetooth.hardware.radio.le_rx_path_loss_comp_db לערך (dB) שמפצה על ההיסט של עוצמת האות (Rx) כדי להבטיח עוצמת אות חציונית של BLE של ‎-55 dBm במרחק של מטר אחד. מערך הפרוטוקולים של Bluetooth מתאים את עוצמת האות (RSSI) כך שתהיה שווה ל-RSSI בתוספת הערך של bluetooth.hardware.radio.le_rx_path_loss_comp_db.

      פרטים נוספים זמינים במאמר le_scanning_manager.cc.

    • ‫Tx: משנים את עוצמת השידור על ידי הגדרת מאפיין המערכת bluetooth.hardware.radio.le_tx_path_loss_comp_db לערך (dB) שמפצה על עוצמת השידור כדי להבטיח ערך חציוני של RSSI ב-BLE של ‎-55 dBm במרחק של מטר אחד. מערך הפרוטוקולים של Bluetooth מתאים את עוצמת השידור (Tx) לעוצמת השידור בתוספת הערך של bluetooth.hardware.radio.le_tx_path_loss_comp_db.

      פרטים נוספים זמינים במאמר le_advertising_manager.cc.