І дійсно, чому б не додати на модуль такий зручний інтерфейс? Пропонуємо до вашої уваги наш черговий матеріал, де ми цього разу розмірковуємо про переваги та недоліки оснащення модуля детектора іонізуючої радіації GGreg20_V3 інтерфейсом I2C.

Одразу зазначимо, що серед інших інтерфейсів передачі даних нам дуже подобається послідовна шина I2C за її простоту, функціональність та надійність роботи. Ви можете ознайомитися з іншими публікаціями, де ми розглядаємо цю чудову шину:
Як правильно вибрати I2C чіпи. Або про приховану програмну проблему вибору
апаратних модулів / How to choose the right I2C chips. Or the hidden software problem of
choosing hardware modules

Application of I2C bus interface splitter

Втім, під час роботи над GGreg20_V3 нашою метою було і є забезпечити якомога ширшу сумісність цього нашого продукту з різними системами.

Ось подивіться:

(1) Коли якийсь модуль чи мікросхема має інтерфейс комунікації I2C (чи SPI, UART), це автоматично вимагає написати для такого пристрою низькорівневий драйвер-коннектор.

(2) Також такий пристрій взагалі не може інтегруватися з іншими компонентами, які заздалегідь не підтримують певний інтерфейс обміну даними чи керування, як-от I2C. Буває купа проектів, у яких немає I2C, або ж під шину I2C не вистачає вільних GPIO.

(3) Модуль вимірювання радіації, за певних умов, має бути спроможним застосовуватися у польових умовах, без підключення до головного контролера. Користувач має мати змогу використати такий пристрій незалежно від умов, в яких він опинився. Без програмування чи апаратних доробок.

(4) Оснащення модуля інтерфейсом I2C вимагає розташування на модулі вбудованого контролера-компаньйона, який забезпечує підготовку даних для споживача та комунікацію у режимі підпорядкованого пристрою (Slave Device) відповідно до специфікації I2C. Хоча це може бути простий і недорогий контролер, його наявність підвищує вартість, а також збільшує розміри модуля. Також потрібно виділити додаткове місце на платі модуля під площадки вибору адреси.

(5) Модуль з інтерфейсом I2C обов’язково потребує наявності головного контролера та дисплею, щоб ним можливо було користуватися за призначенням. І це при тому, що на модулі вже є вбудований контролер – компаньйон. Головні контролери бувають дуже різні. Хтось використовує Raspberry Pi, або ж Arduino, а комусь важливо мати можливість застосувати ESP32 / ESP8266. Саме тому ми не ставимо головний контролер на плату модуля GGreg20. Ми вважаємо, що користувач має право обирати контролер, платформу чи середовище розробки незалежно та самостійно. А наша задача – забезпечити якомога ширшу сумісність та універсальність нашого продукту.

З електричної точки зору, оснащення пристроїв даної категорії інтерфейсом I2C переваг теж не має, адже живлення та інтерфейс передачі даних що у I2C-варіанті, що у варіанті з імпульсним виходом, як у GGreg20_V3, потребують однакової кількості сигнальних дротів у шлейфі. Гарячу заміну, яку підтримує шина I2C, для модулів даного типу теж важко назвати бажаною, вже не кажучи про обов’язковість наявності такої функції.

На Рис. наводимо схематичні зображення двох модулів – поточної версії GGreg20 без I2C, та версії з інтерфейсом I2C, щоб показати, наскільки довелося б змінити модуль з урахуванням реальних розмірів (10х10 мм) додаткової мікросхеми вбудованого контролера-компаньйона.

Рис. Якби GGreg20_V3 мав інтерфейс I2C (червоним показано вбудований контролер-компаньйон, що забезпечує режим I2C Slave Device)

Єдиними перевагами для обґрунтування доцільності оснащення нашого модуля радіації інтерфейсом I2C є наступні:

• можливість підключення декількох пристроїв на I2C-інтерфейс головного контролера;
• розрахунок користувацьких значень засобами вбудованого контролера-компаньйона.

Але якщо ретельно зважити потенційні здобутки та цілком конкретні втрати від запровадження I2C у даному пристрої, стане очевидним, що для користувача краще мати універсальний модуль з широкою драйверною підтримкою і можливістю застосування у “ручному” режимі, ніж отримати купу переваг шини I2C, якими ще потрібно зуміти скористатися.

Додатково до вже викладеного вище наведемо дві ключові проблеми, котрі ми хотіли б окреслити для потенційних користувачів. Цих проблем немає в GGreg20_V3, але їх неодмінно матиме (у тих чи інших варіаціях) модуль вимірювання радіації з інтерфейсом I2C.

Проблема #1 Польові умови / Надзвичайна ситуація 

Обдумайте таку ситуацію: у вас в шухляді лежить сенсор радіації і чекає, коли ж ви його нарешті почнете програмувати, а в наступний момент вам вже потрібно якнайшвидше покинути будинок з одним наплічником у руках і, можливо, мерщій починати вимірювати рівень радіації, бо настала ситуація природного чи техногенного лиха, і ви знаходитеся поруч з епіцентром таких подій. 

Ми в Україні дуже добре знаємо ці обставини і враховуємо накопичений у найважчі для країни часи досвід, щоб зробити системний дизайн наших продуктів якомога кращим.

Наш модуль GGreg20_V3 достатньо лише заживити від павербанка (чи навіть кількох батарейок АА/ААА) чи сонячної панелі – і все: можна вручну проводити вимір за спалахами світлодіода та секундоміром чи власним відліком. 

Кількість спалахів за хвилину помножена на коефіцієнт перетворення – і є рівень радіації у mkSv/hour. 

Коефіцієнт перетворення для трубки SBM20 є рівним 0.0054. Таким чином маємо просту формулу: 

CPM x 0.0054 = mkSv/hour. 

де CPM – кількість спалахів на хвилину (Counts per Minute).

Для Києва [20 – 48] спалахів – це нормальний рівень (0.10 – 0.26 mkSv/h).

На противагу GGreg20_V3, модуль з інтерфейсом I2C в польових умовах буде дуже складно використати за призначенням. Адже модуль також потребує наявності головного контролера, дисплея, засобів програмування, розробки програмного коду, та спеціальних знань і навичок, що дозволять взаємно підключити необхідні компоненти та запрограмувати їх. Це означає, що звичайний користувач без спеціальних знань не зможе провести вимірювання сенсором з інтерфейсом I2C, навіть якщо він, за гарним збігом обставин, матиме такий у своєму наборі доступних інструментів.

Проблема #2 Драйверна підтримка

Навіть якщо все гаразд з обстановкою, що оточує користувача, і модуль сенсора радіації експлуатується в умовах цивілізації, все одно з варіантом дизайну модуля, що має інтерфейс I2C є проблеми. Проблеми виникають у користувачів, які хочуть використовувати улюблені системи / платформи / середовища / архітектури розробки для IoT. 

Систем і смаків дуже багато, і навіть самі передові і популярні системи мають драйвери далеко не для всіх пристроїв, що зазвичай купують та намагаються підключити споживачі. 

Завдяки неоднорідності протоколів інтеграції іноді доводиться писати драйвер самостійно, або чекати кілька років, доки розробники системи звернуть увагу на цей конкретний комерційний пристрій і розроблять відповідний драйвер-конектор.

Наведемо порівняльну таблицю поширених платформ з вбудованою підтримкою I2C сенсорів радіації та платформ з підтримкою лічильника імпульсів на GPIO, щоб читач міг осягнути масштаб цієї проблеми.

Ці дані дуже промовисто вказують, що сенсор з імпульсним виходом, такий як GGreg20_V3, набагато легше підключити до будь-якої платформи, або ж використовувати модуль взагалі автономно, за необхідності. 

Звісно, що кожен модуль з інтерфейсом I2C зазвичай має власні бібліотеки, розроблені виробником або небайдужими учасниками спільноти програмного забезпечення з відкритим вихідним кодом. Наприклад, модуль GGreg20_V3 має кілька таких бібліотек для популярних платформ:

Примітка. Хоча кожна сучасна платформа для IoT, як правило, забезпечує підтримку шини I2C, також має бути наявним драйвер для кожного конкретного апаратного модуля (виробник, модель, версія). Підтримка має бути як на боці платформи, так і на боці головного контролера, до якого підключається модуль.

Наявність бібліотек, подібних до тих, що наведено у таблиці, вже добре. Але це не дає жодних гарантій, що ці бібліотеки підтримуються їх авторми та є актуальними, а також що користувач знайде таку бібліотеку саме до своєї улюбленої платформи і зможе її інтегрувати до неї і запрограмувати кінцевий пристрій.

У випадку ж з лічильником імпульсів на GPIO абсолютно інша ситуація: усі платформи підтримують таку функцію і дуже просто програмуються.

Замість висновків

Попри очевидні переваги шини I2C, якщо ми і приймемо в майбутньому рішення додати підтримку I2C у модуль GGreg20, то це буде ще один, альтернативний пристрій з такими можливостями. А споживачі самі зможуть обирати, який з варіантів їм підходить найкраще.

Купуйте детектор іонізуючої радіації GGreg20_V3 з імпульсним виходом.

Бажаємо успіхів!

Також сторінку бібліотеки GGreg20_V3 було додано на сайт компанії Arduino.

Тепер користувачі платформи Arduino можуть легко знайти бібліотеку на сайті компанії та встановити бібліотеку для модуля GGreg20_V3 у кілька кліків не виходячи з додатку Arduino IDE.Бібліотека знаходиться у розділі Sensors менеджера бібліотек та на сайті.
Пряме посилання на бібліотеку: https://www.arduino.cc/reference/en/libraries/ggreg20_v3/

Бібліотека знаходиться у вільному доступі і розповсюджується компанією IoT-devices як продукт з відкритим вихідним кодом. Відтепер усі користувачі платформи Arduino можуть підключати модуль GGreg20_V3 у свої проекти через готовий і зручний інтерфейс.
Бібліотека надає на вихід готові дані про рівень потужності іонізуючою радіації із застосуванням ковзного середнього з буферизацією 5 хвилин (всього 5 вимірів по 1 хвилині у масиві). Значення uSv/h доступне вже після першої хвилини вимірювання.

Репозиторій бібліотеки: https://github.com/iotdevicesdev/GGreg20_V3
Сторінка продукту: https://iot-devices.com.ua/product-uk/ggreg20_v3-ionizing-radiation-detector-with-geiger-tube-sbm-20/
Проект GGreg20_V3 на Hackaday: https://hackaday.io/project/183103-ggreg20v3-ionizing-radiation-detector

Вихід GGreg20_V3 підтримує пряме підключення до Arduino і ми рекомендуємо живити обидва модулі віж одного джерела живлення і вмикати їх одночасно.
Але у випадку, якщо за задумом проекту потрібно керувати вмиканням / вимиканням сенсора GGreg20_V3 незалежно від вмикання головного контролера, наступна інформація може бути корисною для вас.

Наприклад, може бути ситуація, коли детектор GGreg20_V3 має окреме живлення та GGreg20_V3 вмикається не одночасно з контролером, а окремою командою з контролера чи фізичним перемикачем вручну.
В цьому випадку між пристроями виникають процеси, які за різниці напруг 3V3 на виході і 5V на вході можуть призводити до встановлення недетермінованого стану на порту контролера. Що у свою чергу призводить до зупинки обробки переривань і як наслідок до припинення вимірювання кількості імпульсів, що поступають з сенсора.

В такому разі необхідно виконати узгодження логічних рівнів за напругою між цими двома компонентами.

Рекомендуємо це зробити шляхом виконання наступних кроків:
1. Необхідно (так як і зазвичай) використовувати режим GPIO-порту INPUT_PULLUP.
Для Arduino відповідний код має наступний вигляд:
pinMode(pin, INPUT_PULLUP);
де pin – номер порта вводу-виводу; INPUT_PULLUP – константа.
Обробник переривання має звичайні налаштування для обробки вхідного сигналу і виглядає так:
attachInterrupt(digitalPinToInterrupt(pin), ISR(), LOW);
де pin – номер порта вводу-виводу; ISR() – ідентифікатор фунції обробника переривань; LOW – константа.

2. Необхідно у сигнальний ланцюг (провід між імпульсним виходом сенсора та вхідним GPIO контролера) послідовно включити керамічний конденсатор 0.1uF. На рисунку показано схему та фотографію як підключається конденсатор. Наявність конденсатора унеможливлює блокування входу контролера і схема буде стабільно працювати.
Зауважте, що таке рішення враховує складні внутрішні процеси, що виникають між з’єнаними електронними компонентами, які неможливо описати у обмеженому об’ємі цього документу і було обране спеціалістами як оптимальне для вирішення цієї конкретної задачі.