GGreg20_V3 Differences in Conversion-Factor Article Photo

Ми раніше вже писали про те, як розрахувати коефіцієнти для трубки SBM20 та трубки J305, які постачаються з нашим модулем лічильника Гейгера GGreg20_V3 для DIY / IoT проектів.
Але у тих статтях ми багато зробили наголосу на формулах розрахунку і майже випустили з уваги дуже важливу деталь: коли ми розраховуємо коефіцієнт перетворення кількості імпульсів трубки Гейгера, то маємо бути свідомими того, яку саме величину ми бажаємо отримати на виході.

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

Як рахувати коефіцієнти ми докладно розповідаємо у попередніх наших публікаціях, тому зараз не будемо витрачати час читача.
Краще ми спробуємо показати відмінності розрахованих коефіцієнтів і як краще ними скористатися для DIY проекту

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

У попередніх наших публікаціях ми йшли з початку до кінця: маємо імпульси -> хочемо тримати значення у μSv/h.
Сьогодні ми спробуємо йти навпаки: крокуючи від мети DIY-проекту крізь послідовні дій її досягнення.

Як користувачі DIY лічильника Гейгера, скоріше за все ми хотіли б отримати доступ до наступної інформації на дисплеї нашого пристрою:

Кількість зареєстрованих імпульсів на хвилину отримана від лічильника, CPM;
Потужність джерела випромінювання зареєстрована лічильником, μSv/h;
Поглинута людським тілом доза за певний період часу, μSv.

Подивіться уважно на ці величини. Секрет правильного їх розрахунку полягає не лише у правильних формулах та коефіцієнтах, а також і у розумінні загального процесу:

джерело випромінює;
лічильник реєструє;
людське тіло поглинає;

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

Кількість імпульсів

Кількість імпульсів ми отримуємо від модуля лічильника Гейгера. Для зручності розрахунків, а також виходячи із щільності імпульсів під час вимірювання нормального фонового випромінювання, цей показник найкраще розраховувати у імпульсах за хвилину, CPM (Counts per Minute).

Наприклад, виробник J305 зазначає у даташит, що при нормальному фоновому випромінюванні трубка має видавати 25 імпульсів на хвилину. Інакше кажучи 25 CPM.

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

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

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

Потужність джерела випромінювання

Коли ми хочемо оцінити потужність джерела випромінювання, ми маємо застосовувати коефіцієнт перетворення CPM у μSv/h отриманий шляхом розрахунків на базі даних зазначених у даташит на трубку від виробника:

Для трубки J305 виробник вказує чутливість 44 імп/c при 1 мР/год від джерела Co-60;

Зробимо необхідні нам перетворення цих даних:

Перетворимо в імпульси на хвилину при 1 мР/год:

CPS / mR/h → CPM / mR/h: 44 * 60 = 2640;

Перетворимо в імпульси на хвилину при 1 мкЗв/год:

CPM / mR/h → CPM / μSv/h: 2640 / 10 = 264;

Ціна одного імпульсу за хвилину у мкЗв/год:

1 / ( CPM / μSv/hr ) = 1 / 264 = 0,00378;

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

1 імп/хв = 0,00378 мкЗв/год;

або

μSv/h = CPM * 0,00378

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

Еквівалент поглинутої людським тілом дози

Для отримання значення еквіваленту дози випромінювання поглинутої людським тілом застосуємо модель фантому людського тіла:

Перетворимо імп/с у імп/хв при 1 мР/г:

44 * 60 = 2640 імп/хв / мР/год

Перетворюємо імп/хв при 1 мР/г у імп/хв при 1 Р/год:

2640 * 1000 = 2640000

Знаходимо значення дози експозиції R/h при 1 імп/хв:

1 / 2640000 = 0,0000003787878788

Знаходимо air-kerma (Ka, kinetic energy released per unit mass / in matter):

Рівняння має наступний вигляд:

Ka [Gy] = 0,00877 [Gy/R] x exposure [R]

де 0,00877 – коефіцієнт поглинання дози радіації людським тілом на фантомній моделі під впливом фотонних енергій 100 keV – 3 MeV

0,00877 * 0,0000003787878788 = 0,000000003321969697 Ka[Gy]

Перетворимо Ka[Gy] у Ka[μSv] (тобто перейдемо від Грей до мкЗв):

0,000000003321969697 * 1000000 = 0,003321969697 Ka[μSv]

Таким чином, формула еквівалентної поглинутої дози тілом людини радіації для трубки Гейгера-Мюллера J305 з гамма- чутливістю по Co-60 44 cps / mR/hr наступна:

μSv/h = CPM x 0,00332

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

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

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

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

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

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

Практика та приклади

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

Кількість імпульсів за хвилину, це завжди лише кількість імпульсів – безрозмірна величина. Але за потреби також може бути застосовано коефіцієнт перетворення чи усереднення (у цій статті не розглядаємо);
Для потужності радіоактивного джерела CPM * 0,00378 [μSv/h];
Для еквівалентної дози поглинутої людським тілом CPM x 0,00332 [μSv/h] знаходячи при цьому суму щохвилинних значень [μSv] за весь час вимірювань.

Приклад для ESP32 + GGreg20_V3 + J305 у ESPHome

# 1. Сенсор кількості імпульсів від лічильника з циклом вимірювання 60 секунд

 sensor:
- platform: pulse_counter
  pin:
    number: 23
    inverted: True
    mode: 
      input: True 
      pullup: False
      pulldown: False
  unit_of_measurement: 'CPM'
  name: 'Ionizing Radiation CPM'
  count_mode: 
    rising_edge: DISABLE
    falling_edge: INCREMENT # GGreg20_V3 uses Active-Low logic
  use_pcnt: False
  internal_filter: 180us # for J305
  update_interval: 60s
  accuracy_decimals: 0
  id: my_cpm_meter

# 2. Сенсор потужності джерела випромінювання з циклом вимірювання 60 секунд

- platform: copy
  source_id: my_cpm_meter
  unit_of_measurement: 'uSv/Hour'
  name: 'Ionizing Radiation Power'
  accuracy_decimals: 3
  id: my_power_meter
  filters:
    - multiply: 0.00378 # for J305

# 3. Сенсор еквівалентної дози поглинутої людським тілом на годину з циклом вимірювання 60 секунд

- platform: copy
  source_id: my_cpm_meter
  unit_of_measurement: 'uSv/Hour'
  name: 'Ionizing Radiation Equivalent Absorbed Energy'
  accuracy_decimals: 3
  id: my_dose_meter
  filters:
    - multiply: 0.00332 # for J305

# 4. Кумулятивна еквівалентна доза поглинутої людським тілом радіації за час з початку вимірювання (читай, з моменту подачі живлення)

- platform: integration
  name: "Total Ionizing Radiation Equivalent Absorbed Energy Dose"
  unit_of_measurement: "uSv"
  sensor: my_dose_meter # link entity id to the pulse_counter values above
  icon: "mdi:radioactive"
  accuracy_decimals: 5
  time_unit: min # integrate values every next minute
  filters:
    # cumulative absorbed dose. Converting it from uSv/hour into uSv/minute: [uSv/h / 60] OR [uSv/h * 0.0166666667]. 
    - multiply: 0.0166666667
    # but if my_dose_meter in CPM, then [0.00332 / 60 minutes] = 0.000055; so CPM * 0.000055 = dose every next minute, uSv.
    #- multiply: 0.000055 # for J305

Висновки

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

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

Тепер ми вважаємо, що краще рахувати окремий коефіцієнт під кожну сутність сенсора в залежності від типу та призначення. Можливо, ми навіть зробимо оновлення YAML-файлів у наших прикладах на GitHub.