ארגון משימות בקבוצות

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

מהי צבירה?

ארגון בקבוצות מתייחס לאחסון ב-buffer של אירועי חיישנים ב-Sensor Hub ו/או ב-FIFO של החומרה, לפני הדיווח על האירועים דרך Sensors HAL. המיקום שבו אירועי החיישן נשמרים במאגר (רכז חיישנים ו/או FIFO בחומרה) נקרא 'FIFO' בדף הזה. כשאוסף האירועים של החיישנים לא פעיל, אירועי החיישנים מדווחים מיד ל-HAL של החיישנים כשהם זמינים.

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

אפשר לבצע קיבוץ רק אם החיישן כולל FIFO בחומרה ו/או יכול לאחסן אירועים במאגר בתוך מרכז חיישנים. בכל מקרה, חיישן חייב לדווח על המספר המקסימלי של אירועים שאפשר לקבץ בבת אחת באמצעות SensorInfo.fifoMaxEventCount.

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

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

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

אם חיישן לא תומך בקיבוץ ו-AP נמצא במצב שינה, רק אירועי חיישן של התעוררות ידווחו ל-AP, אסור לדווח ל-AP על אירועים שאינם של התעוררות.

פרמטרים של אשכולות

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

sampling_period_ns

המשמעות של הפרמטר sampling_period_ns תלויה במצב הדיווח של החיישן שצוין:

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

מידע נוסף על ההשפעה של sampling_period_ns במצבים השונים זמין במאמר מצבי דיווח.

בחיישנים רצופיים ובחיישנים שמתעדכנים בזמן אמת:

• אם הערך של sampling_period_ns קטן מ-SensorInfo.minDelay, הטמעת ה-HAL צריכה לכוונן אותו ל-max(SensorInfo.minDelay, 1ms) ללא הודעה. מערכת Android לא תומכת ביצירת אירועים בתדירות של יותר מ-1,000 Hz.
• אם הערך של sampling_period_ns גדול מ-SensorInfo.maxDelay, הטמעת ה-HAL צריכה לקצר אותו ל-SensorInfo.maxDelay ללא הודעה.

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

אם התדירות המבוקשת היא	במקרה כזה, התדירות בפועל צריכה להיות
מתחת לתדירות המינימלית (<1/maxDelay)	בין 90% ל-110% מהתדירות המינימלית
בין התדירות המינימלית לתדירות המקסימלית	בין 90% ל-220% מהתדירות המבוקשת
מעל התדירות המקסימלית (>1/minDelay)	בין 90% ל-110% מהתדר המקסימלי, מתחת ל-1,100 Hz

max_report_latency_ns

max_report_latency_ns מגדיר את הזמן המקסימלי, בננו-שניות, שבו אירועים יכולים להתעכב ולהישמר ב-FIFO של החומרה לפני שהם ידווחו דרך ה-HAL בזמן שה-AP פעיל.

ערך אפס מציין שצריך לדווח על האירועים ברגע שהם נמדדים, על ידי דילוג על ה-FIFO לגמרי או על ידי ריקון ה-FIFO ברגע שאירוע אחד מהחיישן נמצא.

לדוגמה, תאוצה שמופעל ב-50 Hz עם max_report_latency_ns=0 יגרום להפעלה של הפסקות 50 פעמים בשניה כשה-AP פעיל.

כשהערך הוא max_report_latency_ns>0, אין צורך לדווח על אירועי חיישנים ברגע שהם מזוהים. אפשר לאחסן אותם באופן זמני ב-FIFO ולדווח עליהם בקבוצות, כל עוד אף אירוע לא מתעכב יותר מ-max_report_latency_ns ננו-שניות. המשמעות היא שכל האירועים מתחילת הרצף ועד לקבוצה הקודמת מתועדים ומוחזרים בבת אחת. כך מצמצמים את כמות ההפרעות שנשלחות לנקודת הגישה ומאפשרים לנקודת הגישה לעבור למצב צריכת אנרגיה נמוכה יותר (פעילות במצב המתנה) בזמן שהחיישן מתעד נתונים ומקבץ אותם.

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

האפשרות לשמור אירועי חיישנים באופן זמני ב-FIFO לא משנה את ההתנהגות של שליחת האירועים ל-HAL. אפשר לשלב אירועים ממכשירי חיישנים שונים, וכל האירועים מאותו חיישן מסודרים לפי זמן.

אירועי התעוררות ואירועים ללא התעוררות

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

באופן דומה, אירועי חיישנים מחיישנים ללא התעוררות חייבים להיות מאוחסנים ב-FIFO אחד או יותר ללא התעוררות.

בכל המקרים, אי אפשר לשלב בין אירועים של חיישן התעוררות לבין אירועים של חיישן שאינו התעוררות באותו FIFO. אירועי התעוררות חייבים להיות מאוחסנים ב-FIFO של התעוררות, ואירועים שאינם התעוררות חייבים להיות מאוחסנים ב-FIFO שאינו התעוררות.

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

התנהגות מחוץ למצב השהיה

כש-AP פעיל (לא במצב השהיה), האירועים מאוחסנים באופן זמני ב-FIFOs כל עוד הם לא מתעכבים יותר מ-max_report_latency.

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

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

לדוגמה, אם החיישנים הבאים מופעלים:

• מד תאוצה בקבוצה עם max_report_latency = 20 שניות
• נתוני ג'ירוסקופ שנאספו בקבוצה עם max_report_latency = 5 שניות

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

התנהגות במצב השהיה

צבירת נתונים שימושית במיוחד לאיסוף נתוני חיישנים ברקע בלי להשאיר את הנתב במצב פעיל. מאחר שמנהלי החיישנים וההטמעה של HAL לא מורשים להחזיק ב-wake-lock*, ה-AP יכול להיכנס למצב השהיה גם בזמן איסוף נתוני החיישנים.

ההתנהגות של החיישנים בזמן שה-AP מושעה תלויה בכך אם החיישן הוא חיישן התעוררות. פרטים נוספים זמינים במאמר חיישני התעוררות.

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

כשה-FIFO של ההתעוררות מתמלא, או כשהזמן max_report_latency של אחד ממכשירי החיישנים להתעוררות חולף, החומרה צריכה להעיר את ה-AP ולדווח על הנתונים.

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

*יש חריג משמעותי לכך שדרייברים לא יכולים להחזיק את נעילת ההתעוררות, והוא מופיע כשחיישן התעוררות עם מצב דיווח רציף מופעל עם max_report_latency < 1 שנייה. במקרה כזה, הנהג יכול להחזיק את נעילת ההתעוררות כי לאפליקציית ה-AP אין זמן להיכנס למצב השהיה, כי היא תתעורר על ידי אירוע התעוררות לפני שהיא תגיע למצב השהיה.

אמצעי זהירות כשמקבצים חיישני התעוררות

בהתאם למכשיר, יכול להיות שיעברו כמה אלפיות השנייה עד שה-AP יצא לגמרי ממצב ההשהיה ויתחיל לנקות את ה-FIFO. צריך להקצות מספיק מקום ב-FIFO כדי לאפשר למכשיר לצאת ממצב ההשהיה בלי שה-FIFO של ההתעוררות יעלה על גדותיו. אף אירוע לא יאבד, וצריך לפעול בהתאם ל-max_report_latency.

אמצעי זהירות כשמקבצים חיישנים שלא מתעוררים כשיש שינוי

חיישנים שמגיבים לשינויים יוצרים אירועים רק כשהערך שהם מודדים משתנה. אם הערך שנמדד משתנה בזמן שה-AP נמצא במצב השהיה, האפליקציות אמורות לקבל אירוע ברגע שה-AP מתעורר. לכן, אם החיישן משתף את ה-FIFO שלו עם חיישנים אחרים, צריך לבצע בקפידה את הקיבוץ של אירועי חיישן ללא התעוררות שמתרחשים כשיש שינוי. תמיד צריך לשמור את האירוע האחרון שנוצר על ידי כל חיישן שמגיב לשינויים מחוץ ל-FIFO המשותף, כדי שלא תהיה אפשרות להחליף אותו באירועים אחרים. כשה-AP מתעורר, אחרי שכל האירועים מ-FIFO דווחו, צריך לדווח על אירוע החיישן האחרון שחל בו שינוי.

כדאי להימנע מהמצב הבא:

1. אפליקציה נרשמת למונה הצעדים ללא הפעלה (בזמן שינוי) ולמכשיר ה-accelerometer ללא הפעלה (רציפה), ושניהם משתפים את אותו FIFO.
2. האפליקציה מקבלת אירוע של ספירת צעדים step_count=1000 stepscode>.
3. ה-AP עובר למצב השהיה.
4. המשתמש צועד 20 צעדים, וכתוצאה מכך האירועים של ספירת הצעדים ושל חיישן התאוצה מחולקים ביניהם, והאירוע האחרון של ספירת הצעדים הוא step_count = 1020 steps.
5. המשתמש לא זז במשך זמן רב, וכתוצאה מכך אירועי ה-accelerometer ממשיכים לצבור ב-FIFO, ובסופו של דבר מחליפים את כל אירועי ה-step_count ב-FIFO המשותף.
6. ה-AP מתעורר וכל האירועים מ-FIFO נשלחים לאפליקציה.
7. האפליקציה מקבלת רק אירועים מהתאוצה, ומסיקה שהמשתמש לא הלך.

שמירת האירוע האחרון של ספירת הצעדים מחוץ ל-FIFO מאפשרת ל-HAL לדווח על האירוע הזה כשה-AP מתעורר, גם אם כל שאר האירועים של ספירת הצעדים הוחלפו על ידי אירועים של תאוצה. כך האפליקציה מקבלת את הערך step_count = 1020 steps כשה-AP מתעורר.

הטמעת קיבוץ

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

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

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

עדיפות הקצאה לפי FIFO

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

ערך גבוה: חישוב מיקום לפי תנועה (dead reckoning) של הולכי רגל עם הספק נמוך

זמן היעד לאיסוף נתונים ברצף: דקה עד 10 דקות

חיישנים לקבוצה:

• גלאי שלב ההתעוררות
• וקטור סיבוב של משחק התעוררות ב-5 Hz
• מד לחץ אטמוספרי להפעלה ב-5 Hz
• מגנטומטר לא מכויל להפעלה מחדש ב-5 Hz

צבירת הנתונים האלה מאפשרת לבצע חישוב מסלול משוער (dead reckoning) של הולכי רגל תוך כדי השבתה של נקודת הגישה.

ערך גבוה: זיהוי פעילות או תנועה לסירוגין בעוצמה בינונית

זמן היעד לאיסוף נתונים בכמות גדולה: 3 שניות

חיישנים לאיסוף ברצף: מד תאוצה ללא התעוררות ב-50 Hz

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

ערך בינוני: זיהוי תנועות או פעילות רציפה בעוצמה בינונית

זמן היעד לאיסוף נתונים בכמות גדולה: 1 עד 3 דקות

חיישנים לאיסוף ברצף: מד תאוצה להפעלה מחדש ב-50 Hz

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

ערך בינוני-גבוה: הפחתת עומס ההפרעות

זמן היעד לצבירה: פחות משנייה

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

אם הגדרת הגירוסקופ היא 240 Hz, גם צבירה של 10 אירועי גירוסקופ בלבד יכולה לצמצם את מספר ההפרעות מ-240 לשנייה ל-24 לשנייה.

ערך בינוני: איסוף נתונים רציף בתדירות נמוכה

זמן היעד לאיסוף נתונים ברצף: דקה עד 10 דקות

חיישנים לקבוצה:

• ברומטר להפעלה ב-1 Hz
• חיישן לחות להפעלה ב-1 Hz
• חיישני התעוררות אחרים בתדר נמוך ובקצבים דומים

מאפשרת ליצור אפליקציות מעקב בצריכת חשמל נמוכה.

ערך בינוני-נמוך: איסוף רציף של נתונים מכל החיישנים

זמן היעד לאיסוף נתונים ברצף: דקה עד 10 דקות

חיישנים לאיסוף ברצף: כל חיישני ההתעוררות, בתדרים גבוהים

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