Та найголовніша його перевага у тому, що він працює через I2C шину. 

Чому ці термометри є недооціненими

Хтось може зауважити, що LM75 це не найкращий сенсор за своїми технологічними особливостями і виконанням у вигляді мікросхеми. І дійсно, є багато інших типів сенсорів температури, такі як 1-Wire Dallas  DS18b20. Ці сенсори мають одно-провідне підключення та багато інших конструктивних переваг, таких як вологозахищені металізовані корпуси у вигляді капсули, тощо. На шину 1-Wire можливо підключити багато термометрів на одному дроті, 1Wire підтримує контроль помилок та ідентифікацію пристроїв, тощо, тощо.

Але у шини 1-Wire є один і найголовніший недолік – для цієї шини не випускають інших пристроїв, крім термометрів. Точніше не так, їх випускають, але це настільки не популярний сегмент, що їх неможливо купити.

Коли нам потрібно побудувати пристрій середньої складності, як-от метеостанція, одразу декілька різноманітних сенсорів та інших периферійних пристроїв необхідно підключати до головного контролера (перелік, наприклад):

• Сенсор BME680 / BME280 I2C / SPI;
• Сенсор DS18b20 1-Wire;
• Дисплей SPI / I2C;
• Сенсор блискавки AS3935 SPI / I2C;
• Сенсор освітленості MAX44009 I2C;
• Сенсор температури та вологості HDC1080 I2C;
• Сенсор CCS811 I2C;
• Сенсор SCD4X I2C;

І навіть в ситуації з потужним ESP32 (не кажучи про ESP8266 та подібні контролери, як-от Arduino чи RPI Pico W), ми будемо вимушені вирішувати задачу оптимізації кількості інтерфейсів та протоколів. Адже обробка кількох різних протоколів рано чи пізно вплине на нашу розробку і буде вимагати спрощення не лише на боці апаратного забезпечення (бюджет вільних портів вводу-виводу), а і програмної реалізації драйверів для різних протоколів та інтерфейсів, які мають крутитися паралельно в головному циклі контролера.

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

Тому, на нашу думку варто одразу обирати рішення, які буде можливо легко розширювати та експлуатувати в майбутньому. 1-Wire- та SPI- пристрої мало придатні до таких вимог і через це ми радимо їх не розглядати крім випадків, коли це дійсно необхідно (як у випадку з SPI: дисплеями високої роздільної здатності, чи вимірюванням величин з швидкостями наближеними до реального часу).

Варто спробувати будувати оптимальне програмно-апаратне рішення – робимо крок у бік шини I2C. Тобто, оскільки у нас на головному контролері буде дисплей SSD1306 з I2C, кейпад I2CUI4_V1 з I2C – навіщо нам ставити сенсори температури з якимось іншим інтерфейсом? – Так і вирішили, буде лише один інтерфейс: шина I2C. Всі з’єднання будуть через поділювач / хаб I2CHUB_V1, який підтримує підключення до контролера 5 пристроїв одночасно.

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

Вбудовані у ESPHome драйвери

Втім, коли ми робимо пошук на сайті ESPHome, то виявляється, що сенсор LM75, який ми зібралися використати у проекті в якості термометрів, не підтримується – вбудованого драйвера немає.

Починаємо проводити власне невелике розслідування щодо наявних драйверів у ESPHome для сенсорів температури подібних до LM75 (0.89 USD на Mouser). І виявляємо, що є два інші термометри, для яких вже написано вбудований драйвер у ESPHome:

• MCP9808 (1.39 USD на Mouser)
• TMP1075 (0.74 USD на Mouser)

Обидва сенсори нас би влаштували технічно. Вони є в наявності на Mouser та інших подібних майданчиках. Але ми не змогли знайти готові модулі з цими мікросхемами за ціною, яка була б наближено до ціни на модулі з LM75. 

Ми подумали, що це нас не влаштовує, як не влаштувало б і більшість наших читачів. З огляду на подібність цих чіпів, ніхто не воліє переплачувати за модуль термометра 5-10 разів, якщо у кожному магазині можна купити модуль на базі LM75.

Цікаво, що сенсор TMP1075 є сумісним зі специфікацією LM75 (про це чітко вказано у даташит), яка дефакто є галузевим стандартом. Відтак, ми зробили висновок, що можемо спробувати підключити наш LM75-термометр з драйверами для TM1075, які є вбудованими у ESPHome.

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

Примітка. Чесно кажучи, нам досі не зрозуміло, чому розробники та контрибутори ESPHome, досі не зробили вбудованого драйвера для LM75. Нам би не довелося писати цю публікацію і проводити купу часу за дивними експериментами.

Тому ми повернулися у вихідну точку і зробили так, як потрібно було зробити з самого початку. 

Підключення драйвера ззовні

Як ви мабуть знаєте, в ESPHome є щонайменше два механізми підключення власних драйверів пристроїв ззовні: Custom Component та External Component. 

Custom component наразі вважається застарілим варіантом інтеграції і не рекомендується документацією ESPHome до використання. 

Натомість, документація радить використовувати інший, альтернативний спосіб, який на наш погляд, є наразі єдиним, найпростішим та найкращим для виконання інтеграції драйверів власноруч – External Component. 

Відмінність External Component полягає у тому, що користувач ESPHome не прописує вручну інтерфейси для потоків даних з сенсора через манівці, а застосовує цілком регламентовані механізми, які до речі застосовуються також всіма іншими компонентами ESPHome:

Отже, щоб підключити External Component, спочатку потрібно правильно описати його обвязку. Ми не будемо тут занурюватися у деталі програмування та конфігурацій, адже ми знайшли на GitHub вже готовий компонент для LM75.

Щоб додати сенсори LM75, у YAML-конфіг пристрою в ESPHome, потрібно додати лише кілька рядків:

• підключити зовнішній компонент (External Component):

• додати сутності сенсорів LM75

Для зручності ми форкнули репозиторій esphome-lm75, який надано https://github.com/btomala на GitHub у свій акаунт https://github.com/iotdevicesdev/esphome-lm75

Приклад, як виглядає підключення драйверів LM75 для контролера ESP12.OLED_V1 виробництва IoT-devices, LLC у ESPHome:

# YAML Config Example
esphome:
  name: esp12oled-lm75
  friendly_name: esp12oled-lm75
  comment: "Configuration example of two LM75 for ESP12.OLED_V1 with ESPHome firmware"
  project:
    name: "iot-devices.esp12oled-lm75"
    version: "1.0.0"


external_components:
  - source: github://iotdevicesdev/esphome-lm75
    components: [ lm75 ]


esp8266:
  board: nodemcuv2


logger:


api:
  encryption:
    key: "8tDDLc3S5dnSjADItGR5+7KxoUBhUIqeOiJZIXy"


ota:
  password: "c15e9a44e1408352d945b8cd35b79"


wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password


  ap:
    ssid: "Test-Node Fallback Hotspot"
    password: "rtF1XxDZ9"


captive_portal:


i2c:
  sda: 4
  scl: 5
  id: i2c_bus


sensor:
  - platform: lm75
    id: temperature
    name: "LM75 temperature"
    update_interval: 30s
    address: 0x48


  - platform: lm75
    id: temperature2
    name: "LM75 temperature2"
    update_interval: 30s
    address: 0x49
# END YAML Config Example

Примітка. Цей код також є на нашому GitHub: github.com/iotdevicesdev/ESP12.OLED_V1-LM75-ESPHome 

Склад проекту

1 x Модуль ESP12.OLED_V1 з прошивкою ESPHome 2023.12.5;

1 x Модуль I2CHUB_V1;

1 x Модуль LM75 (no brand);

1 x Модуль CJMCU-75.

Результати проекту

Головне, що ми хотіли вам розповісти у цьому тексті:

1. Ми підключили LM75 через механізм External Component настільки легко і просто, що самі не повірили у успіх після складних експериментів з драйвером для TMP1075.
2. Конфігурації підтягуються напряму з GitHub, або можуть лінкуватися з локального сховища на вашому ESPHome / HomeAssistant диску. Підключений таким чином External Component автоматично включається у прошивку під час її компіляції.
3. Ми перевірили, що з цим компонентом не виникає проблем з адресацією кількох сенсорів LM75 одночасно.
4. Все настільки ж просто, як підключити у ESPHome сенсор для якого є вбудований драйвер на кшталт BME280. Простота застосування готового компоненту через метод External Component не йде ні в яке порівняння з застосуванням застарілого методу Custom Component, який ми колись робили для інших своїх задач із сенсором ультрафіолету VEML6070.  

Як можна бачити на наступних скріншотах, наш проект успішно виконано:

• LM75 підключено до контролера ESP12.OLED_V1 з прошивкою ESPHome;
• Два сенсори LM75 одночасно працюють з головним контролером. Там де працює два сенсори, може працювати і вісім (за потреби, LM75 має три піни конфігурації I2C адреси, що дозволяє одночасно працювати з вісьмома сенсорами на кожній шині I2C);
• Дані з сенсорів потрапляють у Home Assistant та виводяться на Dashboard;
• Далі значення сенсорів можуть або автономно виводитися на дисплей контролера ESP12.OLED_V1 засобами прошивки ESPHome, та/або можуть застосовуватися у сценаріях автоматизації Home Assistant.

Значення сенсорів LM75 на Dashboard сервера Home Assistant:

Графіки з Logbook сервера Home Assistant:

Значення сенсорів LM75 у меню Developer Tools сервера Home Assistant:

Скріншоти консолі ESPHome:

• Пристрої знайдено під час сканування шини I2C (дисплей і два термометри)

• Драйвери для сенсорів LM75 ініціалізовано

• Дані з сенсорів отримує ESPHome та передає у Home Assistant

Це наразі все, що ми запланували розповісти за цією темою.

Дякуємо за увагу!

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

https://journals.kntu.kherson.ua/index.php/visnyk_kntu/article

У проєкті використані наші модулі GGreg20_V3 та ESP12.OLED_V1

Проаналізовано відкриті дані показників радіаційного забруднення повітря у м. Києві та здійснено візуалізацію даних за допомогою аналітичних інструментів мови програмування Python.

Після того, як ми зібрали емулятор лічильника Гейгера і запрограмували ESP8266, ми можемо протестувати його, щоб переконатися, що він працює правильно.

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

Як можна бачити, підключення емулятора дуже просте: кабель живлення micro USB та сигнальні дроти імпульсного виходу, а також за бажанням можна підключити debug-консоль через UART.

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

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

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

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

Відомі обмеження

Серед обмежень даного методу створення емулятора лічильника Гейгера, які наразі нам відомі, є кількість пам’яті контролера ESP8266, у якій ми створюємо в циклі необхідну кількість одноразових таймерів з випадковим часом спрацювання. Кожен таймер по суті є функцією, яка займає певну оперативну пам’ять.

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

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

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

Це наразі все, що ми запланували розповісти. Тепер ви знаєте нашу версію того, як можна самостійно зробити емулятор лічильника Гейгера, а також для чого і кому може бути корисним такий пристрій. Втім, якщо ви бажаєте придбати готовий до застосування емулятор, це можливо зробити на нашому сайті, або на Tindie.

Сайт IoT-devices.com.ua: GCcemu20_V1

tindie.com: GCcemu20_V1

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

Початок статті:

Емулятор лічильника Гейгера GGreg20_V3 засобами ESP8266: Частина 1. Вступ та загальний огляд

Емулятор лічильника Гейгера GGreg20_V3 засобами ESP8266: Частина 2 Створення емулятора

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

Команда IoT-devices LLC

Для побудови емулятора лічильника Гейгера нам знадобляться наступні деталі та матеріали:

• ESP8266 #1 як основний (MCU_A, модуль NodeMCU);
• ESP8266 #2 як емулятор GGreg20_V3 (MCU_B, модуль ESP12.OLED);
• Дроти для перемичок;
• USB кабель для програмування та живлення.

Далі нам потрібно буде запрограмувати основний контролер MCU_A та код скрипту емуляції програмного забезпечення GGreg20_V3 для MCU_B.

Примітка 3. Ми будемо наводити приклади у цій публікації на модулях власного виробництва ESP12.OLED. Втім, якщо у вас немає модуля ESP12.OLED, ви також можете застосувати плату розробника на базі ESP8266, наприклад NodeMCU, і самостійно розробити програмне забезпечення керуючись прикладами, що наведено у тексті. Якщо ж ви бажаєте одразу користуватися готовим пристроєм, будь-ласка, дочитайте цю статтю до кінця, адже далі ми даємо посилання на наш готовий до використання модуль емулятора, який можливо придбати.

Примітка 4. У цій, як і у інших наших публікаціях ми будемо наводити приклади простою та потужною скриптовою мовою програмування Lua, що доступна у популярній програмній прошивці NodeMCU.

Бюджет необхідних нам входів/виходів

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

На модулі емулятора лічильника Гейгера нам необхідно буде вже трохи більше портів. Тут необхідно задіяти порти вводу/виводу: для емуляції вихідних імпульсів, для RGB світлодіода та для кнопки перемикання режиму роботи емулятора.

Схема підключення

Щоб взаємодія головного контролера з емулятором модуля GGreg20_V3 виглядала реалістично, пропонуємо скористатися вбудованими властивостями певних портів вводу/виводу плати ESP12.OLED і обрати на контролері емулятора MCU_B наступні GPIO:

• для емуляції імпульсного виходу GGreg20_V3 рекомендуємо використовувати GPIO4 / D2 (GPIO D-index в Lua);
• для перемикання режимів роботи емулятора ми можемо використати вбудовану на платі ESP12.OLED кнопку Flash – GPIO0 / D3;
• вбудований RGB-світлодіод на модулі ESP12.OLED займає GPIO14 / D5; GPIO12 / D6; GPIO13 / D7.

На модулі головного контролера MCU_A, пропонуємо обрати наступний порт для лічильника вхідних імпульсів:

• GPIO14 / D5.

Примітка 5. У якості довідкового матеріалу за нумерацією портів рекомендуємо наступні матеріали:

Стандарт планування та застосування пінів, розроблений alterstrategy.lab: ttps://alterstrategy.com/recommended-pin-use-standard/

Документація на прошивку NodeMCU: https://nodemcu.readthedocs.io/en/latest/modules/gpio/

Документація на модуль ESP12.OLED на сайті: https://iot-devices.com.ua/en/product/esp12oled-universal-esp8266-mcuboard-oled-en/

та на Tindie: https://www.tindie.com/products/iotdev/esp12oled-universal-esp8266096oled-mcu-board/

Оновимо таблицю з урахуванням конкретних портів вводу/виводу, які ми обрали:



Режими роботи емулятора

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

Натискаючи кнопку Flash (D3), користувач може поперемінно перемикати режими, щоб вибрати необхідний.

Для зручності користування емулятором RGB-світлодіод модуля ESP12.OLED блимає різними кольорами, які легко розрізняються людським оком. За кожним режимом роботи емулятора закріплено свій колір. Тож коли емулятор видає на імпульсний вихід сигнал про вдаване “спрацювання”, світлодіод також буде блимати кольором поточного режиму роботи.

Діапазони рівня радіації

Пропонуємо реалізувати емуляцію наступних діапазонів радіаційного випромінювання оточуючого середовища, яке буде імітувати MCU_B:

Режим 0. Немає імпульсів (імітація помилки сенсора);

Режим 1. Природне фонове випромінювання: 0.1 – 0.2 мкЗв/год;

Режим 2. Припустимий рівень: 0.2 – 0.3 мкЗв/год;

Режим 3. Підвищений рівень: 0.3 – 0.6 мкЗв/год;

Режим 4. Небезпечний рівень: 0.6 мкЗв/год – 1.5 мкЗв/год.

За замовчуванням модуль буде стартувати після подачі живлення з “Режиму 1”. Цей режим ми обрали як початковий лише через те, що це зручно, коли подавши живлення ми одразу отримуємо імпульси на рівні фонового випромінювання.

Реальний модуль GGreg20_V3 оснащено трубкою Гейгера радянського виробництва СБМ-20. Ця трубка має наступний коефіцієнт перерахунку імпульсів на хвилину у мікрозіверти на годину:

мкЗв на годину = CPM * 0.0057

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

CPM = мкЗв на годину / 0.0057

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

Режим 0. 0 CPM;

Режим 1. від 18 CPM до 35 CPM;

Режим 2. від 36 CPM до 52 CPM;

Режим 3. від 53 CPM до 105 CPM;

Режим 4. від 106 CPM до 264 CPM.

Співвіднесення кольору спалахів RGB-світлодіода певному режиму роботи є наступним:

Тепер нам лишається написати відповідний програмний Lua-код для ролі MCU_A та для ролі MCU_B.

Приклад. Код лічильника Гейгера для головного контролера (роль MCU_A)

Ми візьмемо цей код з GitHub за наступною адресою:

https://github.com/iotdevicesdev/ggreg20-v3-nodemcu-lua-example

Код з GitHub повністю готовий до застосування. Щоб запускати код з GitHub, треба його скачати з інтернет і завантажити у контролер, наприклад у модуль NodeMCU, як у нашому випадку. Також необхідно написати ще один Lua-скрипт і його теж завантажити у контролер:

-- filename: mcu_a.lua
-- MCU_A Lua code example
-- Copyright 2022 IoT-devices LLC, Kyiv, Ukraine
dofile('ggreg20_v3_nodemcu_firmware_lua_example.lua')
init(5, 1, 60000)

function snsrUpd()
ma5_rad_lvl, cpm, minutes = read()
print(ma5_rad_lvl, cpm, minutes)
end

snsrUpd_tmr = tmr.create()
snsrUpd_tmr:register(60000, tmr.ALARM_AUTO, function() snsrUpd() end)
snsrUpd_tmr:start()

Приклад. Код для емулятора модуля GGreg20_V3 (роль MCU_B)

Документація на мову Lua нам підказує, що у швидкісних задачах необхідно робити перепризначення глобальних ідентифікаторів на локальні, що додає швидкості виконання у десятки разів. Тому ми це зробимо у такий спосіб:

local gpio = gpio
local mode = gpio.mode
local trig = gpio.trig
local write = gpio.write
local read = gpio.read
local INT = gpio.INT
local OUTPUT = gpio.OUTPUT
local FLOAT = gpio.FLOAT
local HIGH = gpio.HIGH
local LOW = gpio.LOW
local PULLUP = gpio.PULLUP
local print = print

local tmr = tmr
local create = tmr.create
local now = tmr.now
local delay = tmr.delay
local alarm = tmr.alarm
local ALARM_SINGLE = tmr.ALARM_SINGLE
local ALARM_SEMI = tmr.ALARM_SEMI
local ALARM_AUTO = tmr.ALARM_AUTO
local register = tmr.register
local start = tmr.start
local stop = tmr.stop

local node = node
local heap = node.heap
local random = node.random

Також нам необхідно налаштувати GPIO, які у нас будуть відповідати за свої функції (див. вище):

mode(3,INT,FLOAT)
mode(4,OUTPUT, PULLUP)
write(4, HIGH)

Щоб генерувати імпульси, які імітують вихідний інтерфейс GGreg20_V3, нам потрібно випадковим чином запускати ось таку функцію:

local function pulseOut()
	write(4, LOW)
	delay(10)
	write(4, HIGH)
end

Але щоб у повній мірі забезпечити емуляцію лічильника Гейгера, нам недостатньо просто запустити pulseOut() визначену кількість разів на хвилину. Насправді все складніше, і нам необхідно таким чином запускати pulseOut(), щоб виконувалася справжня випадковість виникнення імпульсів на виході ESP8266.

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

Для цього нам знадобиться скористатися генератором випадкових чисел, який відповідно до документації на прошивку NodeMCU здатен генерувати справжні випадкові числа. У прошивці для цього ми маємо готовий метод node.random().

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

create():alarm(timer timeout, timer type, callback function)

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

Тож функція, яка у циклі створює випадкові таймаути запуску pulseOut(), має наступний вигляд:

local t_start = 0
local count = 0
local function randGen(pulses)
	for i = 1, pulses do -- pulses
			create():alarm(random(60000), ALARM_SINGLE, 
				function()
						print(heap(), count, i, (now() - t_start)/1000000)
						pulseOut()
				end
			)
	end
end

Працюючи у парі, розроблені нами функції randGen(pulses) та pulseOut() створюють необхідну нам кількість абсолютно випадкових імпульсів на виході ESP8266 тривалістю 10 мікросекунд кожен в межах однієї хвилини.

Кількість імпульсів на хвилину задаємо за допомогою параметра pulses.

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

radMode = 1
rand_tmr = create()
rand_tmr:register(1000, ALARM_AUTO, 
	function()
		if radMode == 0 and running == 0 then 
			print(heap(), 'Mode0:Snsr Err emu')
			return 0
		end
		local num = 0
		if radMode == 1 then 
			num = random(math.ceil(18),math.ceil(35))
		elseif radMode == 2 then
			num = random(math.ceil(36),math.ceil(52))
		elseif radMode == 3 then
			num = random(math.ceil(53),math.ceil(105))
		elseif radMode == 4 then
			num = random(math.ceil(106),math.ceil(264))
		end
		if num ~= 0 then print('count:',count + 1,'mode:',radMode, 'num:',num); randGen(num) end
	end
)

rand_tmr:start()

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

Останнє, що нам необхідно передбачити у емуляторі, це перемикання режиму потужності радіації за допомогою вбудованої кнопки Flash / GPIO0 / D3:

trig(3, 'down', 
	function(lvl, ts, cnt)
		if radMode < 4 then radMode = radMode + 1 else radMode = 0 end
		print ('New radMode:', radMode)
	end
)

Повний програмний код емулятора

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

Примітка 6. Наведений у даному розділі код є лише прикладом. Ви можете самостійно завантажити і налагодити роботу даного прикладу у власному емуляторі лічильника Гейгера, або придбати готовий до використання апаратний модуль з прошивкою та повнофункціональним програмним забезпеченням у нашому магазині чи на Tindie за наступними посиланнями:

Сайт: GCcemu20_V1

Tindie: GCcemu20_V1

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

-- filename: mcu_b.lua
-- MCU_B Lua code example
-- Copyright 2022 IoT-devices LLC, Kyiv, Ukraine
local t_start = 0
local count = 0
radMode = 0

local gpio = gpio
local mode = gpio.mode
local trig = gpio.trig
local write = gpio.write
local read = gpio.read
local INT = gpio.INT
local OUTPUT = gpio.OUTPUT
local FLOAT = gpio.FLOAT
local HIGH = gpio.HIGH
local LOW = gpio.LOW
local PULLUP = gpio.PULLUP
local print = print

local tmr = tmr
local create = tmr.create
local now = tmr.now
local delay = tmr.delay
local alarm = tmr.alarm
local ALARM_SINGLE = tmr.ALARM_SINGLE
local ALARM_SEMI = tmr.ALARM_SEMI
local ALARM_AUTO = tmr.ALARM_AUTO
local register = tmr.register
local start = tmr.start
local stop = tmr.stop

local node = node
local heap = node.heap
local random = node.random

mode(3,INT,FLOAT)
mode(4,OUTPUT, PULLUP)
write(4, HIGH)

local function pulseOut()
	write(4, LOW)
	delay(10)
	write(4, HIGH)
end

local function randGen(pulses)
	for i = 1, pulses do -- pulses
			create():alarm(random(60000), ALARM_SINGLE, 
				function()
						print(heap(), count, i, (now() - t_start)/1000000)
						pulseOut()
				end
			)
	end
end

rand_tmr = create()
rand_tmr:register(1000, ALARM_AUTO, 
	function()
		if radMode == 0 and running == 0 then 
			print(heap(), 'Mode0:Snsr Err emu')
			return 0
		end
		local num = 0
		if radMode == 1 then 
			num = random(math.ceil(18),math.ceil(35))
		elseif radMode == 2 then
			num = random(math.ceil(36),math.ceil(52))
		elseif radMode == 3 then
			num = random(math.ceil(53),math.ceil(105))
		elseif radMode == 4 then
			num = random(math.ceil(106),math.ceil(264))
		end
		if num ~= 0 then print('count:',count + 1,'mode:',radMode, 'num:',num); randGen(num) end
	end
)

rand_tmr:start()

trig(3, 'down', 
	function(lvl, ts, cnt)
		if radMode < 4 then radMode = radMode + 1 else radMode = 0 end
		print ('New radMode:', radMode)
	end
)

Початок статті: Емулятор модуля лічильника Гейгера GGreg20_V3 засобами ESP8266: Частина 1. Вступ та загальний огляд

Завершення статті за кілька днів у наступній публікації:
Емулятор модуля лічильника Гейгера GGreg20_V3 засобами ESP8266: Частина 3. Тестування та висновок

Оновлено: Під час написання цієї статті, ми подумали і вирішили зробити окремий комерційний продукт – емулятор лічильника Гейгера GCemu20_V1.

Частина 1: Вступ та загальний огляд

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

https://web.archive.org/web/20170321162556/http://esp8266-re.foogod.com/wiki/Random_Number_Generator

Увага. У тексті застосовується два різних поняття, які мають однакову назву. Так історично склалося, що на ринку існує апаратний модуль NodeMCU, а також програмна прошивка NodeMCU.

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

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

Для чого потрібен емулятор лічильника Гейгера

Перш ніж розпочати побудову емулятора лічильника Гейгера, необхідно розглянути для чого ж і кому може бути потрібен такий програмно-апаратний комплекс.

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

Ось кілька думок, що розлого пояснюють мотиви, якими ми керувалися, коли задумали розробити емулятор модуля лічильника Гейгера GGreg20_V3.

1. Немає високої напруги

Емулятор GGreg20_V3, на відміну від справжнього модуля, не має високої напруги на платі, тому його дуже зручно використовувати під час розробки на столі і не боятися випадкового ураження струмом.

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

2. Спрощений навчальний процес

Емулятор лічильника Гейгера добре лягає у набір для навчальних закладів. Викладач може поступово поглиблювати практичні заняття з студентами.

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

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

3. Нижча вартість

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

Роботи з налагодження стенду чи проекту з таким емулятором можуть виконуватися без залучення відповідно кваліфікованого персоналу.

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

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

4. Справжнє джерело радіації не потрібне

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

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

З емулятором жодної з цих проблем не буде. Прилад вміє імітувати 5 різних режимів потужності іонізуючого випромінювання. Емулятор лічильника Гейгера створює вихідні імпульси аналогічні імпульсам справжнього модуля GGreg20_V3 у діапазоні від 0 до 1.5 мкЗв/год (якщо брати за аналогічний еталон трубку СБМ-20). На виході генеруються хаотичні (із застосуванням генератора справжніх випадкових чисел ESP8266) імпульси однакової амплітуди з тривалістю повного періоду імпульсу 10 мікросекунд кожен.

5. Ресурс емулятора не виснажується

Трубка СБМ-20, яку встановлено у GGreg20_V3, має відносно великий, але все ж таки обмежений ресурс частинок, які вона може детектувати за своє життя.

Заявлений у документації ресурс трубки СБМ-20 складає не менше 2*10¹⁰ імпульсів.

Примітка 1. За фонового випромінювання 0.15 мкЗв/год з коефіцієнтом 0.0057 трубка СБМ-20 детектувати близько 27 імпульсів на хвилину.

Таким чином, за нормальних умов ресурсу трубки вистачить на 2*10¹⁰ / (27 * 60 * 24) = 20 000 000 000 / (26 * 60 * 24) = 514403 днів. І здавалося б, що це цілком достатній потенційний строк експлуатації однієї трубки.

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

Наведемо приклад:

На своєму сайті компанія Images Scientific Instruments наводить перелік дозволених до ввозу граничних рівнів радіоактивного випромінювання для тестових джерел:

https://www.imagesco.com/geiger/radioactive-sources-int.html

Візьмемо два джерела з наведеного за посиланням переліку:

1. Co-60 1.00 uCi, 37000 Bq;
2. Cs-137 0.25 uCi, 9250 Bq;

Якщо припустити, що під впливом такого тестового джерела половина частинок від радіоактивних розпадів потрапляють у трубку Гейгера СБМ-20, то ресурс такої трубки складе:

1. 20 000 000 000 / (37000 / 2 * 60 * 60 * 24) = 12 днів (для Co-60);
2. 20 000 000 000 / (9250 / 2 * 60 * 60 * 24) = 50 днів (для Cs-137).

Як можемо бачити, якщо ми хочемо ставити експерименти (чи тестувати свої пристрої, у складі яких є лічильник Гейгера) на реальній трубці, то ми виснажуємо її наявний ресурс реальним джерелом радіації досить швидко.

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

6. Дані налагодження в UART

Емулятор модуля GGreg20_V3 у процесі своєї роботи виводить у порт UART-консолі оперативні дані своєї роботи (імпульси, час, кількість, цикли і т.п.), які за необхідності може реєструвати і обробляти студент, розробник чи радіоаматор щоб навчатися, або порівнювати з вимірами своєї системи, яка тестується чи розробляється.

Такої вбудованої можливості у справжнього модуля GGreg20_V3 та аналогічних модулів інших виробників немає і не може бути.

Примітка 2. Для підключення до UART-консолі, модуль ESP12.OLED, на якому базується емулятор GGreg20_V3, має на друкованій платі окремо виведені лінії інтерфейсу UART (отвори з кроком 2.54 мм під пайку). Для підключення емулятора до комп’ютера користувачеві додатково потрібно мати власний перетворювач USB-UART. Далі у тексті буде наведено схему підключення.

Продовження статті у наступних публікаціях:
Емулятор модуля лічильника Гейгера GGreg20_V3 засобами ESP8266 Частина 2 Створення емулятора
Емулятор модуля лічильника Гейгера GGreg20_V3 засобами ESP8266 Частина 3: Тестування та висновок