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

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

הנתונים: מה אנחנו רוצים לדעת

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

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

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

הזיכרון: איפה יושבים הנתונים

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

פרמטר נוסף הוא השרידות הנדרשת עבור הנתונים: האם ייתכן מצב של הפסקת חשמל במערכת, שיחייב זיכרון בלתי נדיף (NVM)? וכיוון שרוב סוגי ה-NVM מוגבלים במספר הכתיבות שניתן לבצע בהם, באילו אופנים ובאיזו מידה נוכל "למתוח את החבל" ולחסוך בכתיבות? האם עדיף רכיב זיכרון EEPROM זול? כרטיס מבוסס FLASH זולל-זרם שאפשר להחליף בקלות? או רכיב FRAM זריז ו"נצחי" אבל יקר ומוגבל בנפח? ואולי הפתרון הנכון יהיה מבוסס בכלל על SRAM? אין תשובה אחת שמתאימה לכל המערכות, וכאמור זו שאלה של מציאת איזון נכון בין הדרישות השונות.

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

החשמל: הדיקטטור הגדול

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

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

התקשורת: לשם כך התכנסנו

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

ארדואינו: כן או לא?

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

סיכום

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