Seamless Integration of Radiation Monitoring

The ggreg20_v3 component is designed for smart home enthusiasts and developers who seek to add ionizing radiation monitoring capabilities to their devices.

It provides a comprehensive set of data points essential for complete environmental control, including:

• Radiation Power (μSv/h)
• Equivalent Absorbed Dose (μSv/h)
• Total Accumulated Dose (μSv)
• Counts Per Minute (CPM) over the defined measurement period
• Instantaneous pulse count value
• System Status (alerts for danger, normal levels, or sensor errors)

This component autonomously handles all complex calculations, including dead time correction for the tube, delivering all necessary data for seamless automation within Home Assistant.

Key Advantage: Cross-Controller Compatibility

The core value of the component developed by IoT-devices LLC lies in its versatility. The ggreg20_v3 component is cross-controller compatible, supporting any microcontroller that runs ESPHome (including ESP32, ESP8266, Raspberry Pi Pico W, and others).

This eliminates the need to write individual code for different hardware platforms, allowing users to rapidly integrate radiation monitoring regardless of the specific controller used for their projects.

“We built ggreg20_v3 with the ESPHome community in mind. Our goal is to make environmental monitoring as accessible and reliable as possible by providing a single, flexible solution that works across all supported controllers,” commented IoT-devices LLC representatives.

How to Get Started

The ggreg20_v3 component is available as an external Git component.

To install: Add our repository to your ESPHome configuration and follow our detailed documentation.

• GitHub Repository: [https://github.com/iotdevicesdev/esphome_external_components]
• Documentation: Review the README.md file for full installation and configuration instructions.

IoT-devices LLC welcomes the community to test, provide feedback, and contribute to the component’s development.

Testing methodology

To conduct the measurements, we developed a special test bench based on the Home Assistant platform. The central element of the system was the Raspberry Pi Pico W controller with ESPHome firmware, which controlled the operation of the GGreg20_V3 module. To accurately measure the energy consumption, we used an INA219 sensor connected to a NodeMCU/ESP8266 controller also running ESPHome firmware. We used a laboratory power supply as a power source for the GGreg20_V3, which set the exact voltage level during testing.

Since the GGreg20_V3 module supports a wide range of supply voltages, from at least 3.0V to 5.5V, we used the three most common supply voltage levels to show how the test result differs: 3.3V, 3.7V, 5.0V. These voltages give us an idea of the module’s consumption when powered by:

• another controller or source with a voltage of 3.3V;
• a 3.7V lithium battery;
• another controller or source with a voltage of 5V.

It is important to note that the INA219 sensor measured only the power consumption of the GGreg20_V3 module, while the controllers were powered separately. This allowed us to obtain the most accurate data.

Also note that the supply voltage level did not change over time during the 60-minute test. Therefore, you should not expect that we have performed a complete emulation, for example, of a lithium battery that discharges under load and, accordingly, loses voltage from 4.2V to 2.5V during the test. Although this would have been a really useful and interesting experiment, we decided not to bother with it that much.

Test bench

Software on the side of the measuring sensor of consumed electric energy based on ESP8266 + INA219 with ESPHome firmware:

sensor:
 - platform: ina219
 address: 0x40
 shunt_resistance: 0.1 ohm

 current:
 name: "INA219 Current"
 accuracy_decimals: 5
 id: current_value

 power:
 name: "INA219 Power"
 accuracy_decimals: 5
 id: power_value

 bus_voltage:
 name: "INA219 Bus Voltage"
 accuracy_decimals: 5

 shunt_voltage:
 name: "INA219 Shunt Voltage"
 accuracy_decimals: 5

 max_voltage: 32.0V
 max_current: 3.2A
 update_interval: 1min

 - platform: integration
 name: "Total Energy Consumed"
 id: total_energy
 sensor: power_value
 time_unit: min
 accuracy_decimals: 5
 unit_of_measurement: "Wh"
 filters:
 - multiply: 0.0166666666666667

 - platform: integration
 name: "Total Current Consumed"
 id: total_current
 sensor: current_value
 time_unit: min
 accuracy_decimals: 5
 unit_of_measurement: "Ah"
 filters:
 - multiply: 0.0166666666666667

This YAML configuration snippet provides all the necessary data for our planned testing of the GGreg20_V3 radiation sensor module in terms of power consumption during operation under normal background radiation conditions.

Measurement process

The power consumption was measured every minute, with data accumulated for previous periods. The test lasted for an hour, which allowed us to obtain the real consumption of the GGreg20_V3 module for 60 minutes for each of the three supply voltages.

The Home Assistant platform was used to collect and record sensor data. It also provided tools for creating visual graphs of electricity consumption.

Results and conclusions

Thanks to the testing, we have obtained detailed data on the power consumption of the GGreg20_V3 module at different supply voltages. These results allow users to optimize the power consumption of their DIY projects using this module.

Power supply with a voltage of 3.3V

Power supply with a voltage of 3.7V

Power supply with a voltage of 5.0V

Summary of results

The power consumption of the GGreg20_V3 module was tested for 60 minutes at different voltages under normal conditions. INA219 measurement update cycle: 1 minute

Test dates: 27.08. – 31.08.2023

No deviations in radiation level measurements were observed during testing

Testing was performed in the default settings of the GGreg20_V3 module. The buzzer is enabled. The Schottky protection diode is installed. Blue power supply LED lights constantly. The supply voltage remained unchanged throughout the test cycle.

Appendix. Theoretical battery discharge diagram

We also decided to show the theoretical discharge graph at three different voltages when the GGreg20_V3 module is powered by batteries of different chemistry and capacity.

The basis for our calculations was the battery characteristics available on the Internet:

However, please note once again that this graph is a theoretical assumption and does not take into account the discharge of real batteries under load over time and changes in voltage and current consumption during discharge.

About GGreg20_V3

The Geiger counter module GGreg20_V3 manufactured by IoT-devices, LLC is the company’s flagship product, which has found its users in more than 30 countries.

All over the world, radio amateurs use GGreg20_V3 to create their own DIY projects, learn and conduct experiments related to radiation measurement.

When developing this product and improving it since 2020, we tried to make the module compact, ready-to-use, compatible with as many DIY platforms and systems as possible, undemanding in terms of power supply voltages, easy to program, and harmonized in terms of operating characteristics with various Geiger tubes.

We have also developed a number of examples and posted them on GitHub for various hardware and software platforms such as Arduino UNO, ESP32, ESP8266, Raspberry Pi Pico W, NodeMCU, ESPHome, Tasmota, MicroPython, Home Assistant.

And we, at IoT-devices Company, hope that our Customers will have a great user experience and real pleasure by implementing this module in their projects.

We also thank everyone for supporting and choosing this product designed and manufactured in Ukraine. We really appreciate it!

Keywords

Geiger counter

GGreg20_V3

Testing of energy consumption

DIY-projects

Home Assistant

Raspberry Pi Pico W

ESPHome

INA219

NodeMCU

ESP8266

I2C

WiFi

YAML

But its main advantage is that it works via the I2C bus.

Why these thermometers are underrated

Someone may say that LM75 is not the best sensor in terms of its technological features and design as a chip. Indeed, there are many other types of temperature sensors, such as 1-Wire Dallas DS18b20. These sensors have a one-wire connection and many other design advantages, such as waterproof metallized capsule-shaped housings, etc. It is possible to connect many thermometers to the 1-Wire bus on a single wire, 1-Wire supports error detection and device identification, etc.

But the 1-Wire bus has one and the most important drawback – there are no other devices for this bus except thermometers. That’s not exactly true, they are produced, but it’s such an unpopular segment that they are impossible to buy.

When we need to build a device of medium complexity, such as a weather station, several different sensors and other peripherals need to be connected to the main controller (a list, for example):

• BME680 / BME280 I2C / SPI;
• DS18b20 1-Wire;
• SPI / I2C display;
• Lightning sensor AS3935 SPI / I2C;
• Light sensor MAX44009 I2C;
• Temperature and humidity HDC1080 I2C;
• CCS811 I2C sensor;
• SCD4X I2C sensor.

And even with the powerful ESP32 (not to mention the ESP8266 and similar controllers, such as Arduino or RPI Pico W), we will have to solve the problem of optimizing the number of interfaces and protocols. After all, the processing of several different protocols will sooner or later affect our development and will require simplification not only on the hardware side (budget of free I/O ports), but also the software implementation of drivers for different protocols and interfaces that must run in parallel in the main loop of the controller.

Note. We are not writing about SPI here, because it is a specialized protocol with a completely different purpose and strengths that apply only to exceptional situations when it comes to sensors.

Therefore, in our opinion, you should choose solutions that can be easily expanded and operated in the future. 1-Wire and SPI devices are not well suited for such requirements and therefore we recommend not considering them unless it is absolutely necessary (as in the SPI case for high-resolution displays or measuring values at near real-time speeds).

It is worth trying to build an optimal hardware and software solution – we take a step towards the I2C bus. That is, since we will have an SSD1306 display with I2C on the main controller, an I2CUI4_V1 keypad with I2C, why would we need to install temperature sensors with any other interface? – So we decided to use only the I2C bus. All connections will be made through the I2CHUB_V1, splitter/hub, which supports the connection of 5 devices to the controller at the same time.

Note. As a reminder, I2C is a great bus – it not only allows you to connect many devices simultaneously, but also provides the ability to identify devices on the bus, control erroneous data, and hot-swap (connect and disconnect devices by the user on the go).

Built-in drivers in ESPHome

However, when we search on the ESPHome website, it turns out that the LM75 sensor, which we were going to use in the project as a thermometer, is not supported – there is no built-in driver.

We begin to do our own little investigation into the available drivers in ESPHome for temperature sensors like the LM75 ($0.89 USD on Mouser). And we find out that there are two other thermometers for which a built-in driver is already written in ESPHome:

• MCP9808 (1.39 USD on Mouser)
• TMP1075 (0.74 USD on Mouser)

Both sensors would have suited us technically. They are available on Mouser and other similar platforms. But we could not find ready-made modules with these chips at a price that would be close to the price of modules with LM75.

We thought that this was not acceptable to us, as it would not be to most of our readers. Given the similarity of these chips, no one wants to overpay 5-10 times for a thermometer module if you can buy an LM75-based module in every store.

Interestingly, the TMP1075 sensor is compatible with the LM75 specification (this is clearly stated in the datasheet), which is de facto the industry standard. Therefore, we concluded that we could try to connect our LM75 thermometer with the drivers for TM1075 that are built into ESPHome.

Unfortunately, we failed to make such a connection, even though the addressing on the bus and the internal registers are identical for the mentioned sensors. The only difference is that the TMP1075 also has a special identification register, which the LM75 sensor does not have. But even attempts to make changes to the sensor type checking at the CPP-code level of this driver did not allow us to use it with the LM75 chip.

Note. To be honest, we still don’t understand why the developers and contributors of ESPHome haven’t made a built-in driver for the LM75 yet. We wouldn’t have to write this article and spend a lot of time doing strange experiments.

So we went back to the starting point and did what we should have done from the very beginning.

Connecting the driver externally

As you probably know, ESPHome has at least two mechanisms for connecting custom device drivers from the outside: Custom Component and External Component.

Custom component is currently considered an obsolete integration option and is not recommended by the ESPHome documentation.

Instead, the documentation recommends using another, alternative way, which in our opinion is currently the only, easiest and best way to perform driver integration yourself – External Component.

The difference of the External Component is that the ESPHome user does not manually write interfaces for data flows from the sensor through low-code roundabouts, but uses fully defined mechanisms, which, by the way, are also used by all other ESPHome components:

So, to connect an External Component, you first need to describe its mapping correctly. We won’t dive into the details of programming and configurations here, because we found a ready-made component for the LM75 on GitHub.

To add LM75 sensors, you only need to add a few lines to the YAML configuration of the device in ESPHome:

• connect an external component (External Component):

• add LM75 sensor entities:

For convenience, we have forked the esphome-lm75 repository provided by https://github.com/btomala on GitHub to our account https://github.com/iotdevicesdev/esphome-lm75

An example of how the connection of LM75 drivers for the ESP12.OLED_V1 controller manufactured by IoT-devices, LLC looks like in 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

Note. This code is also available on our GitHub: github.com/iotdevicesdev/ESP12.OLED_V1-LM75-ESPHome

Project components

1 x ESP12.OLED_V1 module with ESPHome 2023.12.5 firmware;

1 x I2CHUB_V1 module:

1 x LM75 module (no brand);

1 x CJMCU-75 module.

Project results

This is the main thing we wanted to tell you in this text:

1. We have connected the LM75 via the External Component mechanism so easily and simply that we could not believe it ourselves after some complicated experiments with the TMP1075 driver.
2. The dependencies are pulled directly from GitHub, or can be linked from a local repository on your ESPHome/HomeAssistant drive. The External Component connected in this way is automatically included in the firmware during its compilation.
3. We have verified that there are no problems with addressing multiple LM75 sensors simultaneously with this component.
4. It’s as simple as connecting a sensor with a built-in driver like BME280 to ESPHome. The simplicity of using an off-the-shelf component via the External Component method is nothing compared to using the obsolete Custom Component method that we used to do for our other applications with the VEML6070 UV sensor.

As you can see in the following screenshots, our project has been successfully completed:

• LM75 is connected to the ESP12.OLED_V1 controller with ESPHome firmware;
• Two LM75 sensors work simultaneously with the main controller. Where two sensors work, eight can work (if necessary, the LM75 has three I2C address pins, which allows you to work with eight sensors on each I2C bus at the same time);
• The data from the sensors is sent to Home Assistant and displayed on the Dashboard;
• Further, the sensor values can either be displayed independently on the ESP12.OLED_V1 controller display using the ESPHome firmware, and/or can be used in Home Assistant automation scenarios.

LM75 sensor values on the Home Assistant server Dashboard:

Graphs from the Home Assistant server’s Logbook:

LM75 sensor values in the Developer Tools menu of the Home Assistant server:

Screenshots of the ESPHome console:

• Devices found during I2C bus scan (display and two thermometers)

• Drivers for LM75 sensors initialized

• ESPHome receives sensor data and transmits it to Home Assistant

That’s all we have planned to discuss on this topic for now.

Thank you for your attention!

Good luck!

After we’ve built the emulator and programmed the ESP8266, we can test it to make sure it’s working correctly.

Having made the physical diagram and developed and loaded/compiled the Lua code into the controllers, we run the emulator and the main controller to check how our testbed works.

As you can see, the connection of the emulator is very simple: the micro USB power cable and the pulse output signal wires, and you can also connect the debug console via UART if desired.

The following screenshots show the diagnostic data and their measurements. We also show an example of event distribution at the emulator output, that we built to clearly show how the random number generator of the ESP8266 controller works according to our proposed implementation via timers.

As we can see, the events that the emulator generates at the output are chaotic, that is, they have a character where a cursory examination does not show a certain graphical pattern.

Here is another graph of a test set of 175 events per minute, but in a slightly different format. Note the horizontal axis. The value of the initial sequence numbers of events in the loop are arranged chaotically on this graph, as they happened in reality at the output of the emulator:

Of course, the verification of true randomness of events is not the goal of this publication and is far beyond its scope. We simply rely on the thesis that the ESP8266 has a hardware true random number generator.

Known limitations

Among the known limitations of this method of creating a Geiger counter emulator is the memory size of the ESP826 controller, in which we create in a loop the required number of one-shot timers with random times of firing. Each timer, in fact, is a function that takes a certain amount of RAM.

When the timers are fired, the memory is immediately released. The execution of the code we developed resembles a spring, which in a cycle once a minute is sharply compressed and slowly uncompressed within the available memory of the controller.

Thus, the maximum possible number of events generated by our chosen method of generating random events at the emulator output directly depends on the amount of free RAM and the speed of the controller.

Experimentally we found that ESP8266 with NodeMCU firmware and Lua language can confidently generate about 260 events per minute. This is more than enough pulses per minute for the emulator project and the radiation levels it supposedly registers.

That is all we planned to tell you about. Now you know our version of how you can make your own Geiger counter emulator, as well as what and who can benefit from such a device. However, if you want to buy a ready-made emulator, you can do it on our website or on Tindie.

Site IoT-devices.com.ua: GCcemu20_V1

tindie.com: GCcemu20_V1

Overall, building a Geiger counter module emulator can be a fun and educational project. It allows you to simulate the readings of a Geiger counter module without the need for radioactive sources. We hope this guide has been helpful, and we encourage you to experiment with different components and programming techniques to customize your emulator further.

The beginning of the article:

Geiger counter emulator of GGreg20_V3 module by means of ESP8266 Part 1: Introduction and Overview

Geiger counter emulator of GGreg20_V3 module by means of ESP8266 Part 2 Building the Emulator

Good luck!

IoT-devices LLC Team.

To build the Geiger counter module emulator, we’ll need the following parts and materials:

• ESP8266 #1 as the main one (MCU_A, NodeMCU module);
• ESP8266 #2 as GGreg20_V3 emulator (MCU_B, ESP12.OLED module);
• Jumper wires;
• USB cable for programming and power.

Next, we’ll need to program the main controller MCU_A and emulation software script code GGreg20_V3 for MCU_B.

Note 3. We will give examples in this publication with our own ESP12.OLED modules. However, if you do not have an ESP12.OLED module, you can also use an ESP8266-based development board such as the NodeMCU and develop the software yourself, following the examples in the text. If you wish to use an off-the-shelf device please read the rest of this article because we have provided a link to our ready-to-use emulator module which you can buy further on.

Note 4. In this, as in other publications, we will give examples using the simple and powerful Lua scripting language available in the popular NodeMCU firmware.

The budget of the inputs/outputs we need

On the main layout controller, we must define the input/output ports that will perform the task of recording input pulses from the Geiger counter emulator module.

On the Geiger counter emulator module we need a bit more ports. Here we need I/O ports: for emulation of output pulses, for RGB LED and for the switch button of the emulator operation mode.

Wiring diagram

To make the interaction between the main controller and the GGreg20_V3 module emulator look realistic, we suggest taking advantage of the built-in properties of some I/O ports of the ESP12.OLED board and select the following GPIOs on the MCU_B emulator controller:

• we recommend using GPIO4/D2 (GPIO D-index in Lua) to emulate the pulse output of GGreg20_V3;
• we can use the Flash button (GPIO0/D3) built into the ESP12.OLED board to switch the emulator operation modes;
• the built-in RGB LED on the ESP12.OLED module takes GPIO14/D5; GPIO12/D6; GPIO13/D7;

On the main module of the MCU_A controller we propose to select the following port for the input pulse counter:

• GPIO14 / D5.

Note 5. We recommend the following materials as background information on port numbering:

The standard for planning and applying pins was developed by alterstrategy.lab: https://alterstrategy.com/recommended-pin-use-standard/

NodeMCU firmware documentation: https://nodemcu.readthedocs.io/en/latest/modules/gpio/

Documentation for the ESP12.OLED module is on the website: https://iot-devices.com.ua/en/product/esp12oled-universal-esp8266-mcuboard-oled-en/

and on Tindie: https://www.tindie.com/products/iotdev/esp12oled-universal-esp8266096oled-mcu-board/

Let’s update the table with the specific I/O ports we selected:



Emulator operating modes

In order for our GGreg20_V3 emulator to be able to simulate operation under conditions of different radiation levels, we propose to implement the possibility to switch the radiation power range, which is as if measured by the device and fed to the pulse output.

By pressing the Flash button (D3), the user can alternately switch modes to select the desired one.

To make the emulator easy to use, the ESP12.OLED’s RGB LED flashes in different colors that can be easily distinguished by the human eye. Each emulator operating mode has its own color assigned to it. Therefore, when the emulator gives the pulse output a signal about a simulated detection the LED will also blink in the color of the current mode of operation.

Radiation level ranges

We propose to implement the emulation of the following ranges of ambient radiation, which MCU_B will simulate:

Mode 0. No pulses (sensor error simulation);

Mode 1. Natural background radiation: 0.1 – 0.2 µSv/h;

Mode 2. Acceptable level: 0.2 – 0.3 µSv/h;

Mode 3. Increased level: 0.3 – 0.6 µSv/hour;

Mode 4. Dangerous level: 0.6 µSv/hour – 1.5 µSv/hour.

By default, the module will start after applying power, from “Mode 1”. We chose this mode as the initial one only because it is convenient when, after applying power, we immediately receive pulses at the level of background radiation.

The real GGreg20_V3 module is equipped with a Soviet-made SBM-20 Geiger tube. This tube has the following conversion factor of pulses per minute to microsieverts per hour:

μSv per hour = CPM * 0.0057

Let’s perform the reverse operation to calculate for the radiation ranges the appropriate number of pulses per hour that the emulator would have to generate while operating in a certain mode:

CPM = μSv per hour/ 0.0057

We make a rough calculation so as to form power ranges which do not overlap in value:

Mode 0. 0 CPM;

Mode 1. 18 CPM to 35 CPM;

Mode 2. 36 CPM to 52 CPM;

Mode 3. 53 CPM to 105 CPM;

Mode 4. від 106 CPM до 264 CPM.

The correlation of the color of the RGB LED flashes to a certain mode of operation is as follows:

Now we have to write the appropriate Lua-code for the MCU_A role and for the MCU_B role.

Example. Geiger counter code for the main controller (MCU_A role)

We take this code from GitHub here:

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

The code from GitHub is completely ready to use. To run the code, you need to download it from the Internet and upload it to the controller, for example to the NodeMCU module, as in our case. You also need to write another Lua-script and load it into the controller as well:

-- 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()

Example. Code for the GGreg20_V3 module emulator (MCU_B role)

The Lua documentation tells us that in high-speed tasks we need to reassign global identifiers to local identifiers, which increases execution speed by a factor of ten. Therefore, we will do it as follows:

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

We also need to configure the GPIOs that will be responsible for their functions (see above):

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

To generate pulses that simulate the output interface of GGreg20_V3, we need to randomly run the following function:

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

But in order to fully emulate the Geiger counter, it is not enough to just run pulseOut() a certain number of times per minute. In fact it is more complicated and we need to runpulseOut(), in such a way that the real randomness of the appearance of pulses on the ESP8266 output is performed.

Given the extensive capabilities of the platform, we could even suggest several ways to implement this functionality, but we will limit ourselves to one of them, the one that, in our opinion, reproduces the pulse randomness of the real Geiger counter module as much as possible.

To do that we need to use a random number generator, which, according to the NodeMCU firmware documentation, is capable of generating real random numbers. The firmware has a ready-made method node.random() for this purpose. node.random().

To distribute a chosen number of pulses chaotically for one minute, we will use timers, which can be created in a theoretically unlimited number:

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

The only limitation is the amount of free RAM of the controller. Experimentally, we found that we can easily create about 260 pulses per minute in this way, which fits into our requirements for the maximum level of virtual radiation that our emulator can reproduce.

Thus, the function that creates randompulseOut(), start timeouts in the loop looks like this

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

Working together, our developed functions randGen(pulses) and pulseOut() create on the ESP8266 output the necessary number of absolutely random pulses of 10 microseconds each per one minute.

We set the number of pulses per minute with the parameter pulses.

In order for the emulator to work in different power modes of simulated radiation it is necessary to provide a random value of the number of impulses pulses, falling as a task at the input of the randGen() function randGen(). . This can be done as follows:

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()

By setting the value of the global variable radMode, the user can specify one of five modes of ionizing radiation power reproduced at the emulator output.

The last thing we need to provide in the emulator is to switch the radiation power mode using the built-in Flash/GPIO0/D3 button:

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

Full emulator software code

We don’t have a ready-made example for this controller role, as was the case with the main controller (MCU_A). So we will write the necessary code from scratch. Here is the minimum required code capable of emulating Geiger counter pulses.

Note 6. The code in this section is an example. You can download and set up this example yourself in your own Geiger counter emulator, or purchase a ready-to-use hardware module with firmware and fully functional software from our shop or Tindie at the following links:

IoT-devices.com.ua: GCcemu20_V1

Tindie: GCcemu20_V1

Warning! This example code has its own limitations and differs significantly from the code we have developed for commercial use and sell as part of the emulator product on our website and other commercial sites.

-- 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
)

Початок статті: Geiger counter emulator of GGreg20_V3 module by means of ESP8266: Part 1. Introduction and Overview

The conclusion of the article will be in the next publication in a few days:
Geiger counter emulator of GGreg20_V3 module by means of ESP8266: Part 3. Testing and Conclusion

Updated: When writing this article, we decided to make a separate commercial product – the Geiger counter emulator GCemu20_V1.

Part 1: Introduction and Overview

It is known that the Espressif ESP8266 module has a very high quality random number generator. We could not find any official details about the actual implementation of this generator, so we propose to read the material on this subject, published by a radio amateur and saved on the Internet:

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

Warning. Two different concepts with the same name are used in the text. Historically, there is a NodeMCU hardware module on the market as well as NodeMCU software firmware.

The NodeMCU firmware is a compilable, open-source microprogram that can be written to hardware modules with Espressif’s ESP8266 controller. One of the many products based on the ESP8266 controller, is the NodeMCU hardware module.

Thus the NodeMCU firmware can be written to the NodeMCU hardware module. Later in this article we will try, if possible, to clarify what is meant by the name NodeMCU: module or firmware.

What is a Geiger counter emulator for

Before proceeding to create a Geiger counter emulator, it is necessary to consider what for and who may need such a hardware-software device.

The main idea of any emulator in the field of DIY electronics is to temporarily, at certain stages, use a virtual substitute component instead of a real module in the process of IoT device development or experimenting / learning to reproduce the operation and characteristics of a real device with high accuracy. The emulator should simplify and speed up development, as well as add convenience in the initial stages of a planned project or performing unit tests.

Below we present some theses explaining our motives for developing the GGreg20_V3 Geiger counter module emulator.

1.No high voltage

The GGreg20_V3 emulator, unlike the real module, has no high voltage on the board, so it is very convenient to use when developing on the table without fear of accidental electrocution.

At the same time, in terms of the electrical interface of the outgoing pulses, the emulator is a completely similar radiation sensor module, generating random pulses of the same shape and duration as the genuine GGreg20_V3.

2. Simplified learning process

The Geiger counter emulator is suitable for educational institutions. The instructor can gradually deepen practical lessons with students.

First, all classes can be conducted using safe and cheap Geiger counter emulators, and then with real modules with Geiger tubes and high voltage on the tube side. Just like in the Army: familiarization and training is done first with blank cartridges, and only then with live ones.

The emulator fully reproduces the results of the real GGreg20_V3 module, so there is no problem of insufficient number of real modules in the classroom: each student can work with his module independently and complete the learning process without dividing into groups or queues, as it usually happens when resources of training devices and stands in the lab are limited.

3. Lower cost

The emulator has a lower cost than the real GGreg20_V3 module, so it is convenient to use it primarily for debugging and harmonizing the circuit or software of the system being designed or studied.

Debugging a test bench or a project with such an emulator can be performed without the need for specially qualified personnel.

If the emulators are used by students, then the teacher will not need to control the work with the devices, as would be necessary to do with the real Geiger counter module.

Low-cost emulators can be purchased in large quantities and given to students for the duration of their studies, not just for the time they work in the school’s laboratory.

4. No real source of radiation is needed

When we work with a real GGreg20_V3, we need a true source of radiation to reproduce the various situations that need to be considered in the software of the measurement system that is being designed or tested. In order to buy a test radiation source, the radio amateur must first solve a number of problems:

• to determine by physical and chemical parameters which source is needed;
• to find a supplier and buy a test source;
• some countries require customs notification and an import permit;
• the test source can only be of a certain power;
• you must properly store and dispose of the radioactive source;
• the price of the radiation source and its storage system exceeds many times the price of the Geiger counter.

With the emulator, none of these problems will occur. T he device can simulate 5 different modes of ionizing radiation power. The Geiger counter emulator generates output pulses similar to those of the real GGreg20_V3 module in the range from 0 to 1.5 µSv/h (taking the SBM-20 tube as a similar reference). At the output are generated chaotic (using a true random number generator ESP8266) pulses of the same amplitude with a total pulse period of 10 microseconds each.

5. Emulator resource cannot be depleted

SBM-20 tube, installed in GGreg20_V3, has a relatively large, but still limited resource of particles, which it can detect during its lifetime.

The resource of the SBM-20 tube declared in the documentation is at least 2*10¹⁰ pulses.

Note 1. With a background radiation of 0.15 μSv/h with a coefficient of 0.0057, the SBM-20 tube detects about 27 pulses per minute.

Thus, under normal conditions, the resource of the tube will be enough for 2*10¹⁰ / (27 * 60 * 24) = 20 000 000 000 / (26 * 60 * 24) = 514403 days. And it would seem that this is quite a sufficient potential life of one tube.

A completely different picture is observed when it comes to operating a tube with a test source of radiation.

Here’s an example:

On its website, Images Scientific Instruments provides a list of the radiation limits allowed for import for test sources:

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

Let’s take two sources from the list at the link:

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

If we assume that under the influence of such a test source, half of the particles from radioactive decays enter the Geiger tube SBM-20 then the lifetime of such a tube would be:

1. 20 000 000 000 / (37000 / 2 * 60 * 60 * 24) = 12 days (for Co-60);
2. 20 000 000 000 / (9250 / 2 * 60 * 60 * 24) = 50 days (for Cs-137).

As you can see, if we want to experiment (or test our devices that include a Geiger counter) on a real tube, then we deplete its available resource with a true source of radiation rather quickly.

There is no such problem with the emulator. Using the emulator first instead of the tube is economically feasible.

6. Debugging data in the UART

The emulator of GGreg20_V3 module outputs operational data (pulses, time, counts, cycles, etc.) to the UART console port during operation, which, if necessary, can be recorded and processed by the student, developer or radio amateur for training or comparison with the measurements of his tested or developed system.

Genuine GGreg20_V3 counter modules and similar modules of other manufacturers do not and cannot have such a built-in feature.

Note 2. To connect to the UART console, the ESP12.OLED module , on which the emulator is based, has separately led UART interface lines (2.54 mm pitch holes for soldering) on the PCB. To connect the emulator to the computer the user additionally needs to have his own USB-UART converter. Further in the text the connection diagram will be given.

The article will be continued in the following publications:
Geiger counter emulator of GGreg20_V3 module by means of ESP8266 Part 2 Building the Emulator
Geiger counter emulator of GGreg20_V3 module by means of ESP8266 Part 3: Testing and Conclusion

The GCemu20_V1 is a compact device that simulates radiation sensors compared to real Geiger counter radiation sensors. Its advanced features make it ideal for testing various radiation detection applications.

The GCemu20_V1 Geiger Counter Emulator with Pulse Output is not only a great tool for radio amateurs and DIY enthusiasts but also an ideal device for those involved in radiation detector development, tuning, testing, and studying.

The GCemu20_V1 Geiger Counter Emulator with Pulse Output is a perfect choice for anyone needing to simulate radiation levels in their projects or for hobbyists interested in experimenting with radiation detection.

“We are excited to introduce our latest product, the GCemu20_V1 Geiger Counter Emulator, to the B2C market,” said a company representative. “This device is designed specifically for radio amateurs and DIY enthusiasts who need to simulate radiation levels in their projects, and we are confident it will meet their unique needs.”

The GCemu20_V1 Geiger Counter Emulator with Pulse Output is now available for purchase.

For more information, please visit the IoT-devices, LLC website.

About IoT-devices,

LLC IoT-devices, LLC is a leading provider of innovative IoT solutions. Based in Kyiv, Ukraine, the company offers a wide range of products designed to help their clients to improve their Internet of Things knowledge and DIY experience and achieve their goals.

For now, to satisfy curiosity, we can only say that these will be software and hardware IoT devices that have the following properties:

• dual purpose devices: stock and custom firmware;
• absence of rigid binding to IoT-devices LLC as a vendor;
• easy configuration and quick start of use;
• Plug & Play connection of additional sensors;
• data proxy by nodes, as mesh networks do;
• connectionless and serverless architecture;
• component compatibility with ESPHome;
• and thus support in Home Assistant.

On the screenshot, we solve the problem of connecting various sensors to the ESP8266 controller. More precisely, the task of compact and meaningful coding of measurement data into sensor packages so that they are useful for a mobile application that will process them on a smartphone and are readable enough for the users if they don’t want to use the app.

Most importantly, the new devices will have a dual purpose. The user can turn on the device he just bought with the firmware ready and immediately use its functions without complicated setup and connection procedures. Or he can develop his own firmware, because the well-known ESP8266 will be inside the devices.

Second part of the description, see the link: Connecting the GGreg20_V3 Radiation Sensor to the Home Assistant Server via ESP Home Integration – part 2

Note . This publication is suitable for all versions of the ionizing radiation detector manufactured by IoT-devices: GGreg20_V1, GGreg20_V2, GGreg20_V3
Since the entire line of these detectors is focused on the SBM-20 tube, all versions of the devices have the same algorithm and coefficients for calculating the power level and dose of ionizing radiation.
The accuracy of the measurement is affected only by the individual properties of the SBM-20 tube installed in each GGreg20_V3 detector. The specifications of the tube manufacturer indicate a limit range of measurement accuracy of 20% . On practice, this means that two identical GGreg20 devices, but with different SBM-20 tubes, can give results (not more than) with the specified deviation in the number of pulses.

Steps to connect GGreg20 to Home Assistant – continued.

Step 8. Check the log of the new ESP8266 controller with GGreg20 connected
Step 9. Check for new entities on the server side
Step 10. Add GGreg20 radiation sensor widgets to the Dashboard
Step 11. Add a push notification automation script to the Home Assistant application for crossing thresholds

Entities and values of the device on the server

Step 8 . Check the log of the new ESP8266 controller with GGreg20 connected

Here is an example of an active device console with GGreg20 and yaml settings similar to the ones we developed above.

Fig. Output to the device console (Logs) via the ESP Home interface

Step 9 . Check for new entities on the server side

There are two ways to verify that the corresponding GGreg20 entities are formed in the ESP Home plug-in and that the Home Assistant server sees them:

• go to the Developer Tools menu on the sidebar of the Home Assistant interface and search for the relevant data as shown in Fig.

Fig. Find the right entities through the Developer Tools menu

• or go to the menu Configuration -> Integration and search as shown in the following figures.

Fig. Search for the desired entities through the menu Configuration -> Integration

Fig. Search for the required entities through the menu Configuration -> Integration : Devices / Entities

Visualization and Automation

Step 10 . Add GGreg20 radiation sensor widgets to the Dashboard

Here is an example of a demo tab from an active server for two devices GGreg20_V1 and GGreg20_V3 located in different coordinate axes. Each device uses the same yaml file as we created above.

Fig. The dashboard shows widgets with radiation level data from two sensors GGreg20_V1 and GGreg20_V3 located on different coordinate axes.

Step 11 . Add a push notification automation script to the Home Assistant application for crossing thresholds

Once we have made sure that the new device works and sends reliable data, it is possible to move on to the main task – Automation. This powerful tool is available to the administrator through the menu Configuration -> Automation.

Because the entities with the power and dose of ionizing radiation created by ESP Home are available through all components and functions of Home Assistant, the administrator can create any events, functions, scenarios with their use.

For example, it is possible to create an automated exceeding notification of the normal power threshold of ionizing radiation with a message on a smartphone. And so on.

However, these topics go far beyond this publication and we do not have the opportunity to consider them here.

Conclusions

In parts one and two , we covered the steps

Server
Step 1. Install (or start) the Home Assistant server

ESP Home plugin for Home Assistant
Step 2. Connect the ESP Home extension for the Home Assistant server via the Supervisor -> Add-on Store menu

YAML-config of the new ESP device with GGreg
Step 3. Download the ready example of a batch yaml-configuration file of the GGreg20_V3 device for ESP8266 from our website
Step 4. Create (based on the example) in ESP Home the appropriate yaml configuration file

Hardware connection GGreg20_V3 and controller
Step 5. Select the GPIO pin on the controller that will register the pulses from GGreg20
Step 6. Connect the GGreg20_V3 radiation detector to the ESP8266 controller via the Out connector to the selected GPIO of the controller

Flashing the ESP device with GGreg
Step 7. Build and write firmware for the controller

Next, we performed the following steps to connect GGreg20 to Home Assistant:

Step 8. Check the log of the new ESP8266 controller with GGreg20 connected
Step 9. Check for new entities on the server side
Step 10. Add GGreg20 radiation sensor widgets to the Dashboard
Step 11. Add a push notification automation script to the Home Assistant application for crossing thresholds

We have considered in detail the easiest way to connect the GGreg20 detector with the ESP8266 controller to the Home Assistant server with the ESP Home plug-in.

And we made sure that it is not difficult at all, because all the work for us is performed by :

• Detector GGreg20_V3 – Immediately registers the pulses and transmits them to ESP8266;
• ESP Home plugin – provides an interface for building firmware and programming ESP8266;
• Ready-to-use yaml-file frees us from self-writing guidelines for sensor GGreg20;
• The Home Assistant server allows us to conveniently connect, administer and receive information from any of our devices.

That’s all. Good luck!