Closed Vladimir-by closed 2 months ago
And what would be the best way to test these? Just asking "for a friend" ;)
Dear friend, we will check it under normal environmental operating conditions. We won’t go to the nuclear power plant :))
I recently bought one of those things from Ali (not with a tube like this, which is probably more sensitive to alpha radiation) And I was surprised how few radioactive stuff I have.
I don't have any old (greenish coloured) lenses, no 50's red pottery or any old smoke detector. The old pieces of kitchen table top with black stripes in them I use as support for my 3D printers also don't emit any measurable radiation.
I did order a few of those "magic amulet" thingy which claim to stop radiation and those are for sure as harmful as you wouldn't dare to think. The actual radiation is about 4x-5x the base radiation level, so isn't that high. But it sure is dangerous if you keep it always at the same place on your body or even worse if you break it and inhail some of its dust.
So when adding support for this, I will also add some detailed info on this topic as it for sure needs some warnings on how to use it responsible.
The RadSens sensor will be included in the weather station for round-the-clock environmental monitoring. At the moment, the ESPEasy firmware with pulse counting is used. A Chinese Geiger counter J305 (similar to M4011) is used. Measurement interval 600 seconds, conversion %value%*100/1510. I wanted to switch to a more modern RadSens module with an I2C bus connection. The RadSens module will be of interest to many project participants as part of the ESPEasy firmware, as a modern option and a replacement for outdated models. https://mysku.club/blog/china-stores/78189.html
Just to get an idea of what this I2C version is doing... What kind of data does it collect? I always got the impression such meters are merely a pulse counter.
The RadSens module has its own microcontroller STМ32, which counts pulses and transmits the finished result via the I2C bus
It would be better, of course, if the developer participates in the forum (I wrote to the ClimateGuard team). Based on the sources, there should be at least three values from RadSens https://github.com/climateguard/RadSens/blob/master/examples/I2C_rad_test/I2C_rad_test.ino
I don't think what they're selling is too expensive, absolutely not as the parts alone will cost you at least 35-ish euro. But I don't think you will be getting any better or worse readings compared to just counting pulses yourself. So if someone is considering building a dosimeter, this might be a good option to start. (no idea what shipping of the units will add to the costs)
Only main advantage (apart from the relative small size) is that the counter can continue to count when the ESP is in deep sleep for example. I don't know how much current you need to run a geiger counter, so no idea if it even makes sense to try running it on batteries for a long time.
I don't know how much current you need to run a geiger counter, so no idea if it even makes sense to try running it on batteries for a long time.
The website claims it uses max. 50 mA, but it doesn't state if that's with the tube included/installed, as it also claims that for the modules without a tube.
In my case, the rectified voltage will constantly be supplied to the RadSens module and the weather station as a whole. The transition to backup power is carried out from a 18650 lithium battery when the main one is unavailable.
I have reserved P163 as the plugin ID for this sensor.
The website claims it uses max. 50 mA, but it doesn't state if that's with the tube included/installed, as it also claims that for the modules without a tube.
The tube itself does not add much to the consumption under normal ambient conditions (assuming you are not in Chernobyl forest), so those 50 mA seem quite realistic for the simple mcu controlled HV power stage. However, best example I had consumed just ~20 uA without load, so there's much space for improvement. Basically, the idea of always on low power pulse counter makes sence, I even have a prototype based on MSP430, it can count pulses from the Geiger tube in LPM3 (RTC clock enabled) mode consuming roughly just ~1 uA and periodically write the data into FRAM. It can then wake up the ESP and send bulk data to the broker, just as the cache reader plugin does.
Dear developers, I understand how busy you are in developing the project and maintaining the stability of its work. But can I ask about the RadSens plugin, how soon can we expect support in ESPEasy?
Well the past 2.5 months I have been 100% busy implementing support for ESP-IDF5.1 and adding support for ESP32-C2 and -C6 and IPv6 so we can soon add support for Matter. I have not even ordered this board for implementing support for it, so there is no ETA of when it will be implemented.
Thank you, I understand, if necessary, I can test RadSens remotely on the created versions of ESPEasy
@Vladimir-by I've created a new plugin in PR #5104, and a GH Actions run is working on the build. I don't own such RadSens device, so I hope you're available for testing. At the moment, ~only~ available in the ESP32 Collection G builds (4 MB units) and MAX builds (requires 8 MB or 16 MB ESP32, ESP32-s3 or ESP32-c6 unit), ~but I'm working on a solution to make it available for ESP8266 4MB builds and ESP32 4MB builds too~. For ESP8266 builds, a Custom build has to be created, as documented here.
Edit2: Updated GH Actions run.
We decided to not add this plugin in any default build for ESP8266, as that platform is practically feature-frozen for ESPEasy.
For those that need an ESP8266 build, a Custom
build can be created, as documented here (start at the top for setting things up properly, and continue until you reach the chapter where a custom build using Custom.h is described).
For ESP32 this plugin is, besides the MAX
builds, also available in the Collection G
builds.
And just to explain why we consider ESP8266 as 'feature frozen'... I have spent many hundreds of hours in the last few years to make ESPEasy fit again on ESP8266 builds. It just takes too much time which cannot be spent on new features, bugfixes, etc. Espressif called ESP8266 "End-of-life" years ago and we will still make sure stuff can be built on ESP8266, but just not include it in 'collection' or 'display' builds anymore.
Some features may not be made to work on the ESP8266 anymore, like encryption or other feature which simply take up too much memory the ESP8266 simply does not have.
Perhaps it's time to announce a strategy for ESP8266, set it aside with current features and move ahead with ESP32 family?
I do not understand in which assembly to look for plugin 0163?
You can use an ESP32 Collection G build for 4MB Flash units, or an ESP32 MAX build for 8MB and 16 MB Flash units. For ESP8266 you'll need to create a Custom build (compile yourself, from source...).
Perhaps it's time to announce a strategy for ESP8266, set it aside with current features and move ahead with ESP32 family?
Yep, that's what I was thinking about. Nearly everything we add causes ESP8266 builds to fail, so we really need to make a final decision on what to do with the ESP8266.
Made some improvements to the plugin, to use the Count-average (when available) for checking the threshold. A GH Actions run is available here.
Friends, I have a problem when using this plugin. When I check the Stats checkbox and click Submit, the web interface hangs. F5 doesn't help, the interface still hangs. If I press the back button in the browser and remove the CheckBox, everything starts working fine.
I guess you're using an ESP8266, I haven't tested that (yet), might have memory capacity issues. Can you test on an ESP32?
Edit: To get more detailed info, you can check the log while the page is submitted (extra tab on your browser on the Tools/Log page, or via an USB port on your computer, using some (serial)terminal software).
I guess you're using an ESP8266, I haven't tested that (yet), might have memory capacity issues. Can you test on an ESP32?
No, I'm not using an ESP8266, I'm using a
ESP Chip Frequency: | 240 [MHz] ESP Crystal Frequency: | 40 [MHz] ESP APB Frequency: | 80 [MHz] ESP Chip Model: | ESP32-D0WDQ5-V3 ESP Chip Features: | Wi-Fi bgn / BLE ESP Chip Revision: | 3.0 ESP Chip Cores: | 2 ESP Board Name: | Espressif Generic ESP32 4M Flash ESPEasy 1810k Code/OTA 316k FS Flash Chip ID: | Vendor: 0x68 Device: 0x4017 Flash Chip Real Size: | 8192 [kB] Flash IDE Size: | 8192 [kB] Flash Chip Speed: | 80 [MHz] Flash IDE Speed: | 80 [MHz]
and yes, I also noticed that when setting CheckBox Status, if you wait VERY long, the interface comes to life, but in the dev list the Enable dev is false.
Do you have the counter board connected to the ESP? As it will fail initialization if the library can't find the counter.
Can you run an I2C Scan from the Tools page? It should list all I2C devices detected (by address).
I2C Addresses in use Supported devices 0x66 (Device) Environment - RadSens I2C radiation counter RadSens
and if you send the command taskenable,<devicenr>
where you supply the name or number of the device in the Devices list?
Again you could have a look at the log in another browser-tab, to see what's being logged there.
Hmm, that save is taking ridiculously long, especially for a non-LittleFS build 🤔
And you're expected to enable the Stats
option for Count
, as that's to be used for the averaging, the other stats will only be used for presenting the values over time.
It seems the sensor is working, as I can see you have values in the rightmost column, so that part seems successful 😄
Did you also get the log output from Tools/Log (or via a serial connection to the ESP)? Explicitly the part when the task is initialized.
When using a terminal software, f.e. putty on Windows, you can also type commands to the unit. You'll not see what you are typing until you press <Enter>
, but you'll get the best logging available, directly when the command is processed.
The command you could send is taskenable,5
, that should report successful initialization, the ChipID (hexadecimal number) and Firmware version (decimal number).
I'll kick off a new build with the latest ESPEasy changes, possibly something went wrong with this build (that sometimes seem to happen, mostly Github issues we can't control). In ca. 40 minutes from now you can re-download a fresh ESP32 Collection G build from this Actions run.
1642951: EVENT: Clock#Time=Thu,16:31 1653516: WD : Uptime 28 ConnectFailures 0 FreeMem 223308 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init 207: ^^^INIT : Booting version: ESP_Easy_mega_20240813_collection_G_ESP32_4M316k, (GitHub Actions) HEAD_a91b804 (ESP32 SDK 4.4.6) 218: INIT : Free RAM:284436 221: INIT : Soft Reboot #300 Last Action before Reboot: PLUGIN_READ: Task Last systime: 2 - Restart Reason: CPU0: Software reset CP 243: FS : Mounting... 274: FS : SPIFFS mount successful, used 142066 bytes of 290156 291: CRC : Settings CRC...OK 317: ESPEasy console using ESPEasySerial 338: CRC : SecuritySettings CRC...OK 348: Current Time Zone: STD time start: 1970-12-27 03:00:00 offset: 180 min 361: INIT : I2C 364: INIT : Check for Priority tasks 366: INIT : SPI not enabled 367: Set Network mode: WiFi 470: WIFI : Set WiFi to STA 691: ESPEasy console using ESPEasySerial 692: INIT : Free RAM:238776 717: ESPEasy console using ESPEasySerial 718: INFO : Plugins: 79 ['Normal','Collection_G ESP32'] (ESP32 SDK 4.4.6) 730: EVENT: System#Wake 807: EVENT: System#BootMode=1,1,0,0,1,0 808: WIFI : Set WiFi to OFF 1019: WIFI : Set WiFi to STA 1146: WIFI : Connecting WiFiNAME 58:8B:F3:65:CC:E8 Ch:3 (0dBm) open attempt #0 2162: WIFI : Arduino wifi status: WL_IDLE_STATUS 0 ESPeasy internal wifi status: DISCONNECTED 2168: Webserver: start 2182: EVENT: System#Boot 2187: WIFI : Connected! AP: WiFiNAME (58:8B:F3:65:CC:E8) Ch: 3 Duration: 935 ms 2189: EVENT: WiFi#ChangedAccesspoint 2203: EVENT: WiFi#ChangedWiFichannel 2490: WIFI : DHCP IP: 192.168.1.105 (NODE-05-32-E3533C) GW: 192.168.1.1 SN: 255.255.255.0 DNS: 192.168.1.1 / 0.0.0.0 duration: 395 2500: UDP : Start listening on port 65500 2501: firstLoopConnectionsEstablished 2506: Internal command: All checked OK 2514: EVENT: WiFi#Connected 2517: Webserver: stop 2678: NTP : NTP replied: delay 128 ms round-trip delay: 130 ms offset: 19957T13:31:42.117,^ t0: 1724332889.992,^ t1: 2.545,^ t2: 2691: Time set to 1724333504.794 2692: Current Time Zone: STD time start: 2024-12-29 03:00:00 offset: 180 min 2705: Local time: 2024-08-22 16:31:44 2710: Webserver: start 2714: EVENT: p2pNode#Connected=5,'NODE-05-32-E3533C','20240813' 2720: EVENT: Time#Initialized 2964: EVENT: Clock#Time=Thu,16:31 3531: WD : Uptime 0 ConnectFailures 0 FreeMem 228560 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init 207: ^^^INIT : Booting version: ESP_Easy_mega_20240813_collection_G_ESP32_4M316k, (GitHub Actions) HEAD_a91b804 (ESP32 SDK 4.4.6) 218: INIT : Free RAM:284436 221: INIT : Soft Reboot #311 Last Action before Reboot: PLUGIN_READ: Task Last systime: 2 - Restart Reason: CPU0: Software reset CP 243: FS : Mounting... 274: FS : SPIFFS mount successful, used 142066 bytes of 290156 291: CRC : Settings CRC...OK 317: ESPEasy console using ESPEasySerial 338: CRC : SecuritySettings CRC...OK 348: Current Time Zone: STD time start: 1970-12-27 03:00:00 offset: 180 min 361: INIT : I2C 364: INIT : Check for Priority tasks 366: INIT : SPI not enabled 367: Set Network mode: WiFi 470: WIFI : Set WiFi to STA 693: ESPEasy console using ESPEasySerial 694: INIT : Free RAM:238776 719: ESPEasy console using ESPEasySerial 720: INFO : Plugins: 79 ['Normal','Collection_G ESP32'] (ESP32 SDK 4.4.6) 732: EVENT: System#Wake 809: EVENT: System#BootMode=1,1,0,0,1,0 810: WIFI : Set WiFi to OFF 1021: WIFI : Set WiFi to STA 1148: WIFI : Connecting WiFiNAME 58:8B:F3:65:CC:E8 Ch:3 (0dBm) open attempt #0 2164: WIFI : Arduino wifi status: WL_IDLE_STATUS 0 ESPeasy internal wifi status: DISCONNECTED 2170: Webserver: start 2183: EVENT: System#Boot 2187: WIFI : Connected! AP: WiFiNAME (58:8B:F3:65:CC:E8) Ch: 3 Duration: 959 ms 2199: EVENT: WiFi#ChangedAccesspoint 2204: EVENT: WiFi#ChangedWiFichannel 2489: WIFI : DHCP IP: 192.168.1.105 (NODE-05-32-E3533C) GW: 192.168.1.1 SN: 255.255.255.0 DNS: 192.168.1.1 / 0.0.0.0 duration: 366 2499: UDP : Start listening on port 65500 2500: firstLoopConnectionsEstablished 2515: Internal command: All checked OK 2522: EVENT: WiFi#Connected 2526: Webserver: stop 2762: NTP : NTP replied: delay 190 ms round-trip delay: 191 ms offset: 19957T13:32:17.736,^ t0: 1724332889.994,^ t1: 2.568,^ t2: 2775: Time set to 1724333540.497 2776: Current Time Zone: STD time start: 2024-12-29 03:00:00 offset: 180 min 2789: Local time: 2024-08-22 16:32:20 2794: Webserver: start 2798: EVENT: p2pNode#Connected=5,'NODE-05-32-E3533C','20240813' 2804: EVENT: Time#Initialized 2964: EVENT: Clock#Time=Thu,16:32 3530: WD : Uptime 0 ConnectFailures 0 FreeMem 228480 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init 6460: EVENT: p2pNode#Connected=2,'NODE-02-32M-DECE04','20240414' 10123: HTTP: taskenable,5 10175: RadSens: Initialized, ChipID: 0x7d, Firmware: 31 13380: EVENT: TaskInit#RadSens=5,1
Not sure why you have multiple restarts of the unit. Maybe the power supply is instable under load or the voltage a bit low (should really be 5V on the 5V pin for an ESP32 Classic, better even 5.1 or 5.2V). Adding an extra 100 to 470 uF electrolytic capacitor close to the 5V and GND of the ESP could help here (watch the polarity!). When the ESP is on a breadboard, then thicker wires should be used for powering the device, as the regular 'Chinese' patch wires are often very thin, and work more like resistors, instead of conductors, causing all kinds of issues.
Thank you, I understand, if necessary, I can test RadSens remotely on the created versions of ESPEasy
@Vladimir-by, try to confirm or deny this error please (see my video)
Not sure why you have multiple restarts of the unit.
@tonhuisman Couldn't attach the video, it's large. I sent taskenable,5 and after that every time ESP went soft reboot
If you don't set the STAT flag, there is no problem and everything works GREAT
1 minute later.... oopssss, I set the STAT flag for Count and no problem, everything works fast.
5 min. latter......,.., If it's important, I am using P2P and there on the head ESP32 (Build: ESP_Easy_mega_20240812_max_ESP32_16M1M Aug 12 2024) I am collecting RadSens data. I check the STAT boxes and see no problems, it works fast and graphs.
Ton already found the issue, new build is pending :) It was for sure a bug in de code and glad you found it while testing.
I've found a small code issue, that I have now fixed 😅. Build should be ready in ca. 40 minutes from this Actions run
I'm glad I was able to be helpful.
I have another question, I did not find the data entry field setting “A command for configuring the sensitivity to adjust calibration for a different type of Geiger tube (impulses per microrad).”. Mentioned here https://github.com/letscontrolit/ESPEasy/pull/5104
That command is to be sent via http, serial or Rules, and is documented in this file in the PR. This will be available in the ESPEasy ReadTheDocs once the PR is merged into mega
.
Here's a screenshot of how the Commands section will look like in the docs:
I updated, checked, and the problem disappeared
Another question has arisen. Does the documentation state that the Count should be reset when the reading is taken? But I see that it is incriminated before restarting the ESP.
I checked with the manufacturer and he replied in the affirmative, “Unless this software (ESPeasy) accumulates them, but the board itself should not accumulate them.”
:-(
All values are read from the counter using the available library functions, and presented as received, overwriting previous values in ESPEasy. No autonomous counting or addition is done by ESPEasy on the values. AFAICS, there is no way of resetting the values, at least not via the RadSens library.
The only 'special' handling is calculating the average value of counts for use as the trigger-delta to smoothen the sensitivity, but that's not stored other than in memory, and can also be seen in a graph when re-opening the Device configuration for the active sensor.
On further investigation, the RadSens library does increment it's count value, without ever resetting it. And as the sources for that library haven't changed in over a year, I would expect that this is the intended behavior 🤔.
If resetting the count after each read is the desired behavior, I can add that to the library, and also make it optional in ESPEasy, to either fetch the accumulated count like it is now, or get and reset the last available count.
Rather not try to 'write' it to the sensor. It is easier to just keep track of the latest value and just show the difference. However it is probably best to have an ever increasing value as it will tell you about the total radiation exposure which is important for health issue.
I wonder if I'll write to the manufacturers, since they insist it should reset.
I wonder if I'll write to the manufacturers, since they insist it should reset.
Most likely they are talking about the counter, and not the library. So we're both right 😆
I'll fix the library (and make a PR there for my fixes), and add extra options to the plugin, just hang in there for a bit...
@bubastic I've added the requested features to the plugin, a new build is in this Actions run
Build: [ESP_Easy_mega_20240822_max_ESP32_16M1M Aug 22 2024]
I was sure MAX included it.
Which build did you try? This Dosimeter plugin is not yet finished and thus not merged into the main branch.
This build should have it... https://github.com/letscontrolit/ESPEasy/actions/runs/10523288609
@bubastic I've added the requested features to the plugin, a new build is in this Actions run
I have received indirect confirmation that the meter does not reset when Count is read, contrary to the technical documentation, and some users confirm this information. I also see that you have made a change to the plugin. Thank you.
ClimateGuard offers ready-made solutions for environmental monitoring with RadSens and RadSens Mini radiation sensors. Please add this module for I2C operation as part of the ESPEasy firmware. Links to the ClimateGuard project: https://climateguard.info/ https://github.com/climateguard/RadSens/ https://climateguard.info/radsens/ https://climateguard.info/radsens_mini/