Після того, як ми зібрали емулятор лічильника Гейгера і запрограмували 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: Тестування та висновок

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

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

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

“Ми раді представити наш останній продукт, емулятор лічильника Гейгера GCemu20_V1, на ринку B2C”, – сказав представник компанії. “Цей пристрій розроблений спеціально для радіоаматорів та ентузіастів “зроби сам”, яким потрібно імітувати рівні радіації в своїх проектах, і ми впевнені, що він задовольнить їхні унікальні потреби”.

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

Для отримання додаткової інформації, будь ласка, відвідайте сайт IoT-devices, LLC.

Про компанію IoT-devices, LLC

IoT-devices, LLC – провідний постачальник інноваційних рішень у сфері Інтернету речей. Компанія базується в Києві, Україна, і пропонує широкий спектр продуктів, покликаних допомогти своїм клієнтам покращити знання про Інтернет речей та досвід у сфері “зроби сам” і досягти поставлених цілей.

У даній публікації ми приводимо приклади на двох модулях виробництва IoT-devices LLC:

• модуль контролера ESP12.OLED з ESP8266;
• модуль детектора іонізуючої радіації GGreg20_V3.

Це працюючий у нас лічильник гейгера на базі ESP8266 для самостійного складання.

У якості публічного каналу ThingSpeak як приклад наводимо для наш власний демо-канал, який ми нещодавно створили для вимірювання радіації в київському регіоні.

Примітка: зверніть увагу, що в такий спосіб ви можете підключати до сервера Home Assistant будь-який контролер з будь-яким сенсором, який вже налаштовано на відправку показників у хмару ThingSpeak. У цій статті ми наводимо приклади на пристроях нашого виробництва.

Таким чином, щоб провести з нами разом досліди і реалізувати приклади цієї статті вам необхідно мати: 

• контролер на базі ESP8266, як у нас, або будь-який інший з підтримкою REST (HTTP POST/GET); 
• модуль GGreg20_V3, або будь-який інший сенсор; 
• налаштований публічний канал ThingSpeak: власний (щоб мати змогу вносити зміни), або наш (тільки читання, як приклад); 
• програмний код (у нашому випадку це Lua-скрипт для прошивки NodeMCU), який відправляє дані з контролера у хмару ThingSpeak;
• сервер Home Assistant з доступом адміністратора.

Отже, у нас є модуль ESP12.OLED з прошивкою NodeMCU і розробленим кодом на Lua та підключеним до нього сенсором GGreg20_V3, який вже працює з сервісом ThingSpeak. Нам дуже не хочеться вносити в нього якісь зміни спеціально для Home Assistant. Крім того, сенсор, що у нас вже є, підключено до Twitter через ThingSpeak у якості демонстраційного сенсорного вузла. Тож втручатися в його роботу до наших планів не входить.. Але ми хочемо також отримувати з нього виміри в наш сервер Home Assistant. Ба більше, це може бути сенсор сусіда, який ми також можемо використовувати як джерело даних для нашого Home Assistant. Саме тому ми вирішили скористатися з наявних інструментів і вирішити всі задачі одночасно з мінімальними трудовитратами.

Інформаційні потоки

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

Це можливо зробити завдяки можливостям, які нам надає сервіс ThingSpeak. Схема руху даних наведена на наступному Рис.

Наш демонстраційний канал для модуля GGreg20_V3 на ThingSpeak працює у постійному режимі та має такий вигляд:

Адреса даного каналу така: https://thingspeak.com/channels/1749073

Крім цього каналу ви також можете переглядати та підписатися на твіти нашого демо-модуля у мережі Twitter за посиланням: https://twitter.com/GGreg20_V3

Також рекомендуємо переглянути корисні розділи нашого сайту за цією темою:

Реалізація задачі у Home Assistant

Сервер Home Assistant має всі необхідні механізми та інструменти для реалізації поставленої нами задачі. Таке підключення віртуального сенсора до даних у хмарі вирішується в кілька рядків конфігурації у файлі /config/configuration.yaml сервера:

#YAML 
  - platform: rest 
    name: UA GGreg20_V3 Radiation Sensor Node 
    resource: https://api.thingspeak.com/channels/1749073/fields/2.json?results=1 
    scan_interval: 300 # check every 5 minutes 
    unit_of_measurement: uSv/h  
    value_template: '{{ value_json.feeds.0.field2 }}' 
    headers: 
      Content-Type: application/json 
#YAML 

Результати

Після додавання такого фрагменту конфігурації та перезапуску сервера ми отримуємо новий сенсор в Home Assistant. На наступних Рис. наводимо скріншоти отриманих результатів:

Віджети, які ми створили для перегляду даних сенсора в Home Assistant:

Отримавши на рівні Home Assistant новий сенсор, ми можемо виконувати за його допомогою такі задачі, наче це справжній сенсор: 

• реалізовувати сценарії автоматизації, 
• створювати віджети, 
• сповіщати про рівні радіації за порогами, 
• використовувати значення з сенсора як вхідні дані для інших пристроїв, підключених до Home Assistant, тощо.

Окремо хочемо наголосити, що Home Assistant має у своєму арсеналі не лише прекрасний і потужний Web-додаток для браузера, а ще й має повнофункціональний та зручний додаток для смартфонів з Android / iOS. Також Home Assistant через сервіси Nabu Casa дозволяє користувачам отримувати віддалений доступ до повного функціоналу сервера через Web і мобільний застосунок з будь-якої локації, де є підключення до інтернет.

Висновки

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

У нашому випадку ми легко підключили до Home Assistant абсолютно нестандартний контролер (прошивка NodeMCU з мовою Lua) з таким же нестандартним модулем детектора радіації GGreg20_V3. Жоден з цих пристроїв у такій конфігурації не підтримується та не розпізнається сервером автоматично, але завдяки наявності підтримки REST та завдяки існуванню сервісу ThingSpeak ми спромоглися підключити сенсор ще простіше і швидше, ніж ми підключали б його стандартним методом через прошивку ESPHome.

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

Ось лише погляньте, які задачи інтеграції ми змогли вирішити: 

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

Ми вирішили всі ці питання авдяки протоколу REST (HTTP), сервісу ThingSpeak та серверу Home Assistant. Подяка їх розробникам.

На цьому все. Бажаємо успіхів!

IoT-devices, LLC

І дійсно, чому б не додати на модуль такий зручний інтерфейс? Пропонуємо до вашої уваги наш черговий матеріал, де ми цього разу розмірковуємо про переваги та недоліки оснащення модуля детектора іонізуючої радіації 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, накопичувати імпульси та розраховувати ковзне середнє (MA5) потужності випромінювання (uSV/h) з п’ятихвилинним буфером.
Ви можете знайти репозиторій за наступним посиланням:

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

Модуль LoRa обирали за наступними принципами:

• відносно низька вартість;
• є достатніми, щоб перевірити і зрозуміти технологію LoRa у режимі P2P;
• має простий інтерфейс програмування – UART (сам чіп зазвичай має лише SPI – незручний інтерфейс для LoRa у якості модему)
• підтримка режиму роботи Node – Node, тобто без “LoRa-хаба”.
• також завдяки UART, має легко конфігуруватися у консолі – має бути підтримка

Ми знайшли один такий і придбали комплект для тестування. Це модулі AIThinker RA-06 на базі вже не нового і всім відомого чіпа Semtech  SX1278.

Заздалегідь відомі недоліки

Для цих чіпів немає готових драйверів під ESPHome (читай Home Assistant).

Щоправда, в ESPHome є потенційна можливість: підключення через Custom UART Text Sensor API, але це значить, окрім інтеграційних скриптів на YAML, програмування конекторів/парсерів на С. І це не дуже добре, адже Home Assistant зараз є дуже популярною платформою. Чомусь розробники HA/ESPHome не зробили жодної підтримки для LoRa.

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

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

Саме тому ми все ж вирішили попрацювати з RA-06 SX1278.

Підтримка модуля в прошивці NodeMCU

Тут теж немає готового драйвера ні для модуля AIThinker RA-06, ні для чіпа SX1278, але у складі прошивки NodeMCU є універсальний модуль Soft-UART, що дозволяє підключити модуль до будь-яких двох GPIO ESP8266 і програмувати його на рівні Lua.

На жаль, під час тестування виявилося, що один з параметрів протоколу UART не підтримується обопільно двома цими системами:

• Soft-UART прошивки NodeMCU функціонально обмежений і не підтримує режим Parity: Odd або Even. Доступний лише Parity:None.
• LoRa модуль не підтримує Parity:None, але підтримує Odd чи Even.

Ця дрібничка, на яку зазвичай взагалі ніхто не звертає уваги, не дозволяє працювати з модулем LoRa через програмний Soft-UART.

Апаратний інтерфейс UART контролера ESP8266

Залишається лише можливість використовувати апаратний інтерфейс UART 0 модуля ESP8266.

І тоді все має бути добре. – Якби не прикрість, що цей UART в NodeMCU застосовується для консолі програмування. А ще одного повного TX/RX UART в ESP8266EX немає.

Що ж робити?

Є вихід. Потрібно лишень:

• перенаправити консоль програмування у інший протокол – наприклад, працювати з консоллю через інкапсульований у WiFi і TCP : telnet.
• підключити LoRa модуль на місце консолі (тобто на апаратний UART0)

Про результати спроби запустити LoRa через UART на ESP8266 під керуванням NodeMCU розповімо зовсім скоро у наших наступних публікаціях.

Читати далі