Geiger counter with HA integration?

Hello.
You don’t know why RadiationD CJAOE works great with wemos d1 mini pro on pin D7
but it doesn’t respond at all to esp32? on any pin?

connected from the VIN pin on the module directly to the GPIO (I also tried a divider on the esp32)

EDIT:
Only 36 VP gpio pin solved problem.
https://community.home-assistant.io/t/pulse-counter-pin-goes-high/140151/2?u=tiimsvk

this pin and probably also VN gpio 39 have a higher resolution than the others? why does the esp8266 handle it without problems?

1 Like

Don’t know why - GPIO4 and GPIO36 pins are both ADC pins, but this site: ESP32 Pinout Reference: Which GPIO pins should you use? | Random Nerd Tutorials says GPIO36 is input only, so has no pullups on it.

1 Like

We have recently made a new GitHub repo didicated for GGreg20_V3 + generic ESP32 with pulse counter GPIO debounce in microseconds up to SBM20 GM tube’s deadtime (190us). And tested this yaml-config on an ESP32 Wroom (NodeMCU-like module) and used GPIO23 as a pulse counter input.
Previously, we did not notice that the ESPHome Pulse Counter API has the ability to apply a low-pass filter. We hope that this example will help many users to counteract the bounce that can sometimes occur in GM-tubed and high voltage systems.

1 Like

As I completed the weather station and installed the geiger counter, only then did I find a solution using

internal_filter: 190us..

It doesn’t matter, it works well on the high impedance pin

1 Like

But we recommend using a similar filter just to be on the safe side, just to eliminate accidental false positives due to bad contacts, etc.

Thank you for your feedback on your project and experience with Geiger counters.

I recently bought one of these and used similar pulse_counter ESPHome code to get the CPM value and then like @ckglobalroaming did, used a template_sensor to get the µSv/hr value:

sensor:
  - platform: pulse_counter
    pin: GPIO36
    name: Radiation CPM
    id: radiation_cpm
    on_value:
      then:
        - component.update: radiation
  - platform: template
    name: Radiation
    id: radiation
    update_interval: never
    unit_of_measurement: "µSv/hr"
    state_class: measurement
    icon: "mdi:radioactive-circle-outline"
    accuracy_decimals: 3
    lambda: |-
      return (id(radiation_cpm).state/151);

Works great here too! Check it out, with the arrival of spring, I started to see a daily cycling trend of radiation in my house:
image

My goal was to put one outside so I could measure ambient radiation levels but now I’m thinking I’ll get a second one to put outside so I can see if the trend is similar outside and inside!! :stuck_out_tongue: I can’t get enough data… ooof, I just found this youtube video that shows how 405nm light causes false triggering at the very end of the cathode so maybe that’s what my graph above is showing! :expressionless:

Anyway, I don’t really know if the value of the reading is accurate. I got my conversion value (1/151 or 0.00662) from “the guy with a Swiss accent”. He put together a youtube video and a github repo for building up one of these using the same PCB I bought. Specifically, this PDF shows the conversion he used and he said that he calibrated it but then I realized that he’s using a GM tube M4011 and as it turns out mine is marked with: J305βγ.

I read through the conversations above and I’m curious how you guys decided on your values and what value may be most accurate for the J305 tube I’m using. I found this topic on another forum comparing the two tubes and it sounds like the J305 tube is slightly cheaper than the M4011 tube and I’m not surprised that I bought the RadiationD-v1.1 (CAJOE) for $29-shipped with tube from AliExpress. It’s probably pretty valuable information to post your conversion with the type of tube you’ve got but there wasn’t too much mention of that above.

Reading more on this it seems there are at least three kinds of tubes:

  • SBM20 (108mm long and appear to be all metal)
  • M4011 (89mm long glass tube with a filament like an incandescent lightbulb)
  • J305 (86.5mm long glass tube with a filament like an incandescent lightbulb)

I organized the conversions I found from the posts above:

  • 1/123.15 or 0.00812
  • 1/123.46 or 0.00810
    • @ckglobalroaming read from his data sheet (would be willing to post that data sheet?) the conversion rate appears to be for a J305 tube
  • 1/151.00 or 0.00662
    • M4011 @SpikeyGG is using the M4011 conversion from “the guy with the Swiss accent” but my tube is the J305
  • 1/153.85 or 0.00650
  • 1/175.44 or 0.00570

I think it makes sense that the larger SBM-20 would need a lower multiplier since it’s a larger tube and likely more sensitive. This makes me think that I should use a higher multiplier since my tube is among the smaller one. Has anyone actually calibrated their device with a known good Geiger counter and willing to post the results with their tube information?

1 Like

Googled it - I’ve found some documents with various types of tubes and values for each on of them.
Done this so long ago that I forgot details, but it was something like scientific paper/research study.
My tube is J305(β).
Also, needed to shield it from ANY direct sunlight as it gives false positives.

1 Like

Swiss :wink:

1 Like

Hello!
For the J305, we have our own video with a quick UV sensitivity test. You can watch it here:

Regarding the calculation of coefficients for J305, which is equipped with our GGreg20_V3 device and CAJOE device: we have an article planned for this tube. But you can read our technical note for the SBM20 tube - the calculation methodology will be similar for the J305:

The main thing is that you have the datasheet of the tube manufacturer (for the tube that is installed in your device).
As soon as the technical note for the J305 tube is ready, we will provide a link to it here.
We also recommend that you read our new article where we compare SBM20 and J305 tubes in terms of building DIY projects:

Best regards,
Oleksii
Team IoT-devices, LLC

Hello,

Thank you for this valuable project.

I am using an indoor GMC32 Geiger project, but I would prefer an outdoor kit.
Therefore, I purchased a GGreg20_V3 kit with an Olimex ESP32 with POE support.

Just a quick note that it could be valuable to register Geiger counters on GMC Geiger world map
https://www.gmcmap.com/AutomaticallySubmitData.asp

Auto submit data URL format: http://www.GMCmap.com/log2.asp?AID=UserAccountID&GID=GeigerCounterID &CPM=nCPM&ACPM=nACPM&uSV=nuSV

At lease one reading data has to be submitted.

UserAccountID: user account ID. This ID is assigned once a user registration is completed.
GeigerCounterID: a global unique ID for each registered Geiger Counter.
nCPM: Count Per Minute reading from this Geiger Counter.
nACPM: Average Count Per Minute reading from this Geiger Counter(optional).
nuSv: uSv/h reading from this Geiger Counter(optional).

Followings are valid data submission examples:

http://www.GMCmap.com/log2.asp?AID=0230111&GID=0034021&CPM=15&ACPM=13.2&uSV=0.075
http://www.GMCmap.com/log2.asp?AID=0230111&GID=0034021&CPM=15&ACPM=0&uSV=0
http://www.GMCmap.com/log2.asp?AID=0230111&GID=0034021&CPM=15&ACPM=0&uSV=0
http://www.GMCmap.com/log2.asp?AID=0230111&GID=0034021&CPM=15
http://www.GMCmap.com/log2.asp?AID=0230111&GID=0034021&CPM=15&ACPM=13.2

The submition result will be returned immediately. Followings are the returned result examples:

OK.ERR0
Error! User is not found.ERR1.
Error! Geiger Counter is not found.ERR2.
Warning! The Geiger Counter location changed, please confirm the location.
1 Like

Thank you for using our product GGreg20_V3, which is designed and manufactured in Ukraine by IoT-devices, LLC. We hope that your GGreg20_V3 meets your expectations and performs well in your projects.
Also, today we have good news - we have made a new repository on GitHub, which shows the configuration for connecting GGreg20_V3 to Raspberry Pi Pico W using ESPHome firmware. This is another popular and cool controller with Wi-Fi support. Now the Home Assistant community can use our new development:

Best regards,
Oleksii Yanko
Team IoT-devices, LLC

Thank you for your link you posted regarding GMCmap. We have tested this service with our test lab GGreg20_V3. It works simply and quickly via REST (HTTP GET). Here is our screen of our data on GMCmap:


Best Regards,
Oleksii
Team IoT-devices, LLC

hi I’m new here and I managed it to get a CAJOE radiation detector running with your code in HA 2023.8.1.
could you please tell us (me) how you implemented the GMCmap into that.
It would be a great benefit for all to distribute our results into that map (for example a mean over 15 minutes).
thanks

2 Likes

Hello!
Thank you for your interest in our posts.
Please note that we have built sensors for our Home Assistant test server that receive data from the GMCmap cloud server. That is, we do not send data, but read it from the outside to Home Assistant.
Perhaps I misunderstood your question, but it seemed to me that you would be interested in sending data to the GMCmap server on the contrary. Then it would be a completely different solution than the one we use.
To send data to GMCmap, it is enough to send HTTP requests of the following format (HTTP GET) using the Home Assistant according to their documentation:
http://www.GMCmap.com/log2.asp?AID=0230111&GID=0034021&CPM=15&ACPM=13.2&uSV=0.075
Here is the link to the document: Geiger Counter World Map
Of course, you need to register with GMCmap to do this.
On the server side of Home Assistant, you can use the following integration:
RESTful Command - Home Assistant
I hope this will help you with your project.
BR, Oleksii Yanko from IoT-devices, LLC

As you know, starting from version 2023.12.0, ESPHome has new requirements for Pin Reuse Validation of configuration files. These changes have also covered our GitHub repositories. We have already made the necessary changes to the examples for ESP8266, ESP32, Raspberry Pico W for ESPHome firmware. More details are available here:

Any plans to release a self contained, plug and play device that can be used? I would for sure buy one

Yes, we have such plans. But if possible, could you give us a little bit of your attention and tell us how you envision such a product as a user?
I will give you possible options for the realization of such a product:

  • A full-fledged handheld (pocket) device in a case with a display, control keypad, sound and light indicator, with a battery inside (i.e. charging and uninterruptible power supply / PMIC also inside). Firmware based on ESPHome.
  • A standalone device consisting of a sensor and controller module (firmware by ESPHome) in a common battery-powered housing. There is no battery charger inside, so it must be charged separately. It can also be carried in a “pocket”. Indication only via RGB LED and buzzer. Or via Home Assistant app (requires HA server).
  • A stationary device consisting of a controller and a radiation sensor module in a common housing. Powered by USB only. An AC-DC 5V adapter or power bank is required to power the device. You can also receive data from Home Assistant and their Home Assistant App.
    Which option did you have in mind?
    Дякую за цікавість до цієї теми!
    Thank you for your interest in this topic!
    Best Regards,
    Oleksii

I think my personal preference is for the last one, followed by the first one.

I generally think any sort of self contained device, that can be connected to HA and
be directly wired/powered is ideal. Though my preference for powering said device would be using POE rather then USB. Ideally then the device can get power and data and not need to worry/deal with Wifi either.

1 Like

Thanks to your thoughts and input!

Hi there! We just released some more stories on conversion factor calculations:

  1. Geiger tube J305: How to calculate the conversion factor of CPM to μSv/h. Technical note - Electronics manufacturer for IoT
  2. Geiger tube J305 conversion factor: differences between the coefficient for source radiation power and absorbed dose. Technical note - Electronics manufacturer for IoT

Hope this helps!
BR, Oleksii
IoT-devices Team

2 Likes