CPM not counted on (certain) ESP32 Model (D1 Mini, ESP32-WROOM-32)

[Kedalux]

Note: I already fixed the issue myself, but this is for users experiencing the same issue and for the staff to understand why this happens (Because i don't)
Also i've closed my duplicated issue in the wrong repo (ggreg20-v3-homeassistant-esphome-example) since it fits better here.

So i've bought two GGreg_V3 Sensors to monitor background radiation.

I use the following ESP32 Model: https://wiki.csgalileo.org/_media/projects/internetofthings/d1_mini_esp32_-_pinout.pdf
The Chip itself is labelled ESP32-WROOM-32.

I flashed the Chip using the Home-Assistant Add-On ESPHome and the Configuration from here.

Everything went smoothly until i discovered that CPM is only "counted" immediatly when the GGreg board is being connected/being turned on. I guess this has something to do with the issue.
pulse_counter always shows 0 otherwise, so radiation over time is calculated wrong too.

I could verify this because the board is beeping around 22 times a minute and always reports 0, unless connected/disconnected while the ESP is on.

If the "OUT" Pin is connected to the wrong GPIO CPM tends to be in the thousands. I discovered this playing around with my ESP.

The only thing needed to fix this is changing the yaml configuration:
The following values of the two lines need to be swapped:

rising_edge: INCREMENT
falling_edge: DISABLE # GGreg20_V3 uses Active-Low logic

Before failing_edge was INCREMENT and rising_edge DISABLE.

With this configuration the CPM counting works as expected, i verified this by counting the beeps and comparing it to the transmissioned stats.

I don't know why this happens, i don't know if it's the specific model, that treats GPIO Pins differently (Your Example is for Generic ESP32).

I did specify the correct model in ESPHome to be sure the Pinout is correct. I also checked for hardware defects with multiple ESPs from the same model and the second GGreg_V3 Board i ordered.
I also double-checked with different GPIO Pins, but the behaviour is always the same.

Maybe someone could look into it and change the readme with a note.

Merry Christmas Guys!

[iotdevicesdev]

Thank you for sharing your experience with GGreg20_V3.
To better understand why the configuration we suggested was not suitable for your project by default, I would ask you to tell us more about the following:

• what voltage level the GGreg20_V3 is supplied with;
• what voltage level is used to power the ESP32;
• which module the power supply is connected to (i.e. who powers whom)
• exactly what are the connections between the GGreg20_V3 and the ESP32 (describe all connections in detail);

Thank you very much for your help!

Regards,
Oleksii

[iotdevicesdev]

Merry Christmas!

[Kedalux]

Hi Oleksii,

• i tested this bevahiour with both 3.3V and 5V supplied to the GGreg20_V3. Changing the voltage didn‘t make a difference.

• The ESP32 is powered by a 5V USB-A to Micro-USB cable by a 5V fixed voltage USB PSU. (I also tested the USB-A Port on my PC)

• The ESP32 powers the GGreg20_V3

• I will use the PDF Link i provided to describe the connections i tried and resulted in the same behaviour:

• • ESP32 VIN+5V connected to GGreg20_V3 BAT +
• • ESP32 Ground connected to GGreg20_V3 BAT -
• • ESP32 GPIO27 connected to GGreg20_V3 OUT
• • Optional, but i tried: ESP32 Ground connected to GGreg20_V3 (OUT) GND

I also tried connecting ESP32 +3.3V instead of VIN+5V to GGreg20_V3 BAT + which didn‘t change the behaviour.
I triple checked i used the right GPIO Pins and everything was connected correctly.
I also used the wiring diagram provided in this repo.

Only by changing the values above i could bring the ESP to count CPMs.

[iotdevicesdev]

Hello Kedalux,
I couldn't find exactly the same ESP32 module as yours in our lab. So I'm asking (if possible) if you could make some measurements for me.
Namely, I am interested in the resistance on the GPIO27 you have chosen.
I would be grateful if you could do the following:

1. Turn off the power of the ESP32 module
2. Disconnect all other modules from the ESP32 module (such as GGreg20_V3)
3. Measure the resistance (with an ohmmeter) between the following points:
   3.1 ESP32 GPIO27 <-> ESP32 GND
   3.2 ESP32 GPIO27 <-> ESP32 3V3
   3.3 ESP32 GPIO23 <-> ESP32 GND
   3.4 ESP32 GPIO23 <-> ESP32 3V3
   These measurements should give us an idea of whether your ESP32 module has built-in external pull-ups / pull-downs on GPIO27 and, for comparison, on GPIO23, if any.

We look forward to hearing what you find.
Thanks a lot!

Best regards,
Oleksii

[Kedalux]

Hi Oleksii,

luckily i‘ve had an multi-meter with me so i could get those measurements.
I‘ve followed your steps, (and also tested my Multimeter with the resistor labelled „223“ on the GGreg20_V3 because i thought my readings are inaccurate. It measured 19.4k-ohms, which is not accurate according to the specification, but good enough to tell if my device actually works properly.)

All the measurements you wanted, i took, but they all ended in an „Open Line“, even when putting it to 2M-Ohms measuring range. I couldn‘t measure any resistance.

I also need to underline, that i‘ve tested this with GPIO23 as well as GPIO15 and the results i described initially stayed the same.
I also needed to invert the values for the ESP32 to register pulses from the GGreg20_V3, so i can confirm that the ESP32 „acts“ the same on every GPIO pins.

Sorry i can‘t be of more help. I will order another, basic version of the ESP32 and test it out again.

[iotdevicesdev]

Today I spent most of the day experimenting with the usual ESP32-Wroom module in the NodeMCU format.
Here's what I found:

1. Our initial YAML example really stopped counting pulses. Moreover, it stopped working both for the Arduino framework and for the ESP-IDF framework:

esp32:
  board: esp32dev
  framework:
    type: arduino

esp32:
  board: esp32dev
  framework:
    type: esp-idf

2. Since the last time we tested our YAML example, there have been changes in the ESPHome firmware related to the pulse_counter component.

3. To say for sure what causes the YAML example to fail, we need to conduct a detailed study of the changes in the source code that have occurred in the ESP-IDF as well.

4. To ensure that the example works, it is enough to disable filter control by commenting out the lines like this:

# use_pcnt: False
# internal_filter: 190us # for SBM20 tube, for J305 tube use 180us

5. Thus, the correct part of the example YAML code will be as follows:

...
- platform: pulse_counter
  pin:
    #: 23
    inverted: True
    mode: 
      True input: True 
      # No pullup or pulldown on ESP32 side because of internal pullup set in hardware at GGreg20_V3 pulse output side
      pullup: False
      pulldown: False
  unit_of_measurement: 'CPM'
  name: 'Ionizing Radiation Power CPM'
  count_mode: 
    'rising_edge': DISABLE
    falling_edge: INCREMENT # GGreg20_V3 uses Active-Low logic
  update_interval: 60s
  accuracy_decimals: 0
  id: my_cpm_meter
...

6. Removing the filter means the following in practice:
   Instead of the Geiger tube deadtime filter of 190 microseconds that we need, the default hardware filter with a value of 13 microseconds will be applied.
   Unfortunately, this is not what we want, but otherwise, ESPHome pulse_counter internal filter is not working for reasons unknown to us.

7. Regarding your workaround by using a rising edge instead of a falling edge, we believe that also automatically removes the 190 microseconds filter. This is not clearly stated in the documentation, but there is a hint (https://esphome.io/components/sensor/pulse_counter.html#configuration-variables):

... “If you enable this, set the count_mode to increase on the falling edge, not the leading edge.”....

8. And finally, it would be nice if you, as an ESPHome user, based on everything we've discussed, opened an issue there as well. Otherwise, this bug may go unnoticed for years.

https://github.com/esphome/issues/issues

9. Also, here's some information I saw today that might be related to the ESPHome pulse_counter changes I mentioned above:

• https://esphome.io/changelog/2024.12.0.html#esp-idf
• https://esphome.io/changelog/2024.10.0 (Allow use of all pulse count unit channels if needed, Allow use of all pulse count unit channels if needed. esphome/esphome#7550).

10. One more thing: compiling with the ESP-IDF framework gave me the following messages today:

Compiling .pioenvs/esp32-ggreg20-v3/src/esphome/components/pulse_counter/pulse_counter_sensor.cpp.o
In file included from src/esphome/components/pulse_counter/pulse_counter_sensor.h:10,
                 from src/esphome/components/pulse_counter/pulse_counter_sensor.cpp:1:
/data/cache/platformio/packages/framework-espidf/components/driver/deprecated/driver/pcnt.h:15:2: warning: #warning “legacy pcnt driver is deprecated, please migrate to use driver/pulse_cnt.h” [-Wcpp]
   15 | #warning “legacy pcnt driver is deprecated, please migrate to use driver/pulse_cnt.h”
      | ^~~~~~~
src/esphome/components/pulse_counter/pulse_counter_sensor.cpp: In static member function 'static void esphome::pulse_counter::BasicPulseCounterStorage::gpio_intr(esphome::pulse_counter::BasicPulseCounterStorage*)':
src/esphome/components/pulse_counter/pulse_counter_sensor.cpp:32:12: warning: '++' expression of 'volatile'-qualified type is deprecated [-Wvolatile]
   32 | arg->counter++;
      | ~~~~~^~~~~~~
src/esphome/components/pulse_counter/pulse_counter_sensor.cpp:35:12: warning: '--' expression of 'volatile'-qualified type is deprecated [-Wvolatile]
   35 | arg->counter--;
      | ~~~~~^~~~~~~

This may also indicate that something has happened to the pulse_counter component (most likely at the ESP-IDF level) - some changes that we have not been told about yet.
How the changes in the ESP-IDF then get into the ESPHome firmware based on the Arduino framework for ESP32, I unfortunately do not know. I can only note that there were no such messages as from the ESP-IDF when the firmware was compiled with Arduino framework in config.

11. What I plan to do:
    to make changes to the YAML example and temporarily remove the lines for applying the 190 microseconds software filter.

# use_pcnt: False
# internal_filter: 190us # for SBM20 tube, for J305 tube use 180us

I hope this information will help.
Regards,
Oleksii