GeigerLog Activity
Python program for Geiger counters and Environmental Sensors
Brought to you by:
ullix
Activity for GeigerLog
-
Adam Szewczyk modified a comment on discussion Feature Request
BTW. There is a project in which someone bypassed MCU in hdk101 and getting the data from the diodes.
-
BTW. There is a project in which someone bypased MCU in hdk101 and getting the data from the diodes.
-
I just tested it. There is a bug that stop the geigerlog from connect to a sensor. Code for wifiserver GDK101 not setting success variable. After adding it, it can connect and get the data. As for the geiger counter with tasmota I will be interested but first I have to find out why my HW not working. Will it be OK for you if I start another topic and ask for help to figure it out?
-
ullix posted a comment on discussion Feature Request
If you have the GDK hardware at hand, you can try it with the latest Devel GeigerLog: Put this next config into file custom.cfg and replace the IP 10.0.0.199 with that of your ESP32. Please report the outcome. [WiFiServerDevice] WiFiServerActivation = yes WiFiServer = yes, Tasmota, GDK101, 10.0.0.199, 80, CPM3rd, CPS3rd, Temp, Press, Humid # it delivers: RadiationAvg1Min, RadiationAvg10Min, status, vibration, measurement
-
You may be interested in this Tasmota-Geiger-Counter pre-release of GeigerLog: GeigerLog Version 2.2pre01 https://sourceforge.net/p/geigerlog/discussion/devel2/
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The usage of IOT over MQTT, and the setting up of a mosquitto server is well described in the GeigerLog manual, take a look. However, if the world-wide scale is NOT needed by the user, having to do all this server setup is just an inconvenience to the user. For use within the local WiFi, HTTP and a browser is enough. You may be interested in a new feature coming up in GeigerLog. GL can convert a regular Tasmota on an ESP32 to a "Tasmota Geiger Counter". See the discussion page (in German): GeigerLog's...
-
The usage of IOT over MQTT, and the setting up of a mosquitto server is well described in the GeigerLog manual, take a look. However, if the world-wide scale is NOT needed by the user, having to do all this server setup is just an inconvenience to the user. For use within the local WiFi, HTTP and a browser is enough. You may be interested in a new feature coming up in GeigerLog. GL can convert a regular Tasmota on an ESP32 to a "Tasmota Geiger Counter". See the discussion page (in German):
-
The usage of IOT over MQTT, and the setting up of a mosquitto server is well described in the GeigerLog manual, take a look. However, if the world-wide scale is NOT needed by the user, having to do all this server setup is just an inconvenience to the user. For use within the local WiFi, HTTP and a browser is enough. You may be interested in a new feature coming up in GeigerLog. GL can convert a regular Tasmota on an ESP32 to a "Tasmota Geiger Counter". See the discussion page (in German): https...
-
Over http you need to use: http://<ip>/cm?cmnd=Status%2010 and respons will lokk like this: {"StatusSNS":{"Time":"2025-12-21T21:57:21","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.09,"RadiationAvg1Min":0.12,"Status":1,"Vibration":0,"Measurement":"0T00:05:31"}}}
-
Over http you need to use: http://<ip>/cm?cmnd=Status%2010 and respons will lokk like this:</ip> {"StatusSNS":{"Time":"2025-12-21T21:57:21","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.09,"RadiationAvg1Min":0.12,"Status":1,"Vibration":0,"Measurement":"0T00:05:31"}}}
-
Over http you need to use: http://<ip>/cm?cmnd=Status%2010 and respons will lokk like this:</ip> {"StatusSNS":{"Time":"2025-12-21T21:57:21","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.09,"RadiationAvg1Min":0.12,"Status":1,"Vibration":0,"Measurement":"0T00:05:31"}}}
-
And since for MQTT you don't need to poll for data you can just subscribe to telemetry topic and wait when device itself send them: mosquitto_sub -h localhost -p 1883 -t "tele/tasmota_E496E7/SENSOR" {"Time":"2025-12-21T13:03:50","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.00,"RadiationAvg1Min":0.00,"Status":1,"Vibration":0,"Measurement":"0T00:00:08"}}
-
-
And since for MQTT you don't need to poll for data you can just subscribe to telemetry topic and wait when device itself send them: mosquitto_sub -h localhost -p 1883 -t "tele/tasmota_E496E7/STATE" {"Time":"2025-12-21T12:24:40","Uptime":"0T00:00:10","UptimeSec":10,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Wifi":{"AP":1,"SSId":"vlan13","BSSId":"7A:9A:18:15:C8:40","Channel":1,"Mode":"11n","RSSI":56,"Signal":-72,"LinkCount":1,"Downtime":"0T00:00:04"},"Hostname":"tasmota...
-
And since for MQTT you don't need to poll for data you can just subscribe to telemetry topic and wait when device itself send them: mosquitto_sub -h localhost -p 1883 -t "tele/tasmota_E496E7/STATE" {"Time":"2025-12-21T12:24:40","Uptime":"0T00:00:10","UptimeSec":10,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Wifi":{"AP":1,"SSId":"vlan13","BSSId":"7A:9A:18:15:C8:40","Channel":1,"Mode":"11n","RSSI":56,"Signal":-72,"LinkCount":1,"Downtime":"0T00:00:04"},"Hostname":"tasmota...
-
For testing purposes you can use such mosquitto.conf: allow_anonymous true listener 1883 0.0.0.0 this will allow you to ignore user/password settings.
-
For testing pourposes you can use such mosquitto.conf: allow_anonymous true listener 1883 0.0.0.0 this will allow you to ignore user/password settings.
-
Ok, I'm back. I was have finally some free time to setup test environment and answer you. Why MQTT? It is currently a standard in IOT and Home Automation. It is fast, lightweight, can be secured and is more reliable then http. If someone have some Home Automation server (like Home Assistant or similar) it probably have MQTT broker already installed, or can be setup in few clicks. As my test setup I deploy a docker container with mosquitto-broker on my daily driver machine, You can use this guide...
-
Ok, I'm back. I was have finally some free time to setup test environment and answer you. Why MQTT? It is currently a standard in IOT and Home Automation. It is fast, lightweight, can be secured and is more reliable then http. If someone have some Home Automation server (like Home Assistant or similar) it probably have MQTT broker already installed, or can be setup in few clicks. As my test setup I deploy a docker container with mosquitto-broker on my daily driver machine, You can use this guide...
-
Ok, I'm back. I was finally some free time to setup test environment and answer you. Why MQTT? It is currently a standard in IOT and Home Automation. It is fast, lightweight, can be secured and is more reliable then http. If someone have some Home Automation server (like Home Assistant or similar) it probably have MQTT broker already installed, or can be setup in few clicks. As my test setup I deploy a docker container with mosquitto-broker on my daily driver machine, You can use this guide as reference....
-
Ok, I'm back. I was finally some free time to setup test environment and answer you. Why MQTT? It is currently a standard in IOT and Home Automation. It is fast, lightweight, can be secured and is more reliable then http. If someone have some Home Automation server (like Home Assistant or similar) it probably have MQTT broker already installed, or can be setup in few clicks. As my test setup I deploy a docker container with mosquitto-broker on my daily driver machine, You can use this guide as reference....
-
Ok, I'm back. I was finally some free time to setup test environment and answer you. Why MQTT? It is currently a standard in IOT and Home Automation. It is fast, lightweight, can be secured and is more reliable then http. If someone have some Home Automation server (like Home Assistant or similar) it probably have MQTT broker already installed, or can be setup in few clicks. As my test setup I deploy a docker container with mosquitto-broker on my daily driver machine, I configured it to allow anonymous...
-
What is really behind the use of MQTT? I understand that it is good when you have transkontinental data transfer, But when you have to setup a local mosquitto server, it defeats the need for mqtt, because you are in a local - probably wifi - setting anyway, and there is no need for mqtt! It can be done without setting up a local server, no matter how easy it might be, by using the http method. Easy to understand, no need for setup, because all you need is a browser. And it is faster and easier to...
-
I have it. Yesterday I reflashed my device with Tasmota firmware (unfortunately they don't merge it into default tasmota-sensor.bin build so I have to enable the sensor and build it myself). I have also doubts about using public brokers, but setting up a a local broker is not such hard task. You could do it for development purposes on your daily driver. Just install mosquitto and mosquitto-clients using packages manager. And then use simplest config for use it in local network. For me it is a bit...
-
If this is the answer to a "status 10" command, it is really easy to implement. Do you actually have a Tasmota device with GDK101 in hand, or is this theoretical planning? I am very concerned about about using MQTT via free MQTT servers! I got burned myself, because there are scammers out there, who interfere with your commands and insert damaging code into the returns! I advise STRONGLY against such free servers! So you either need to rent MQTT access, or run your own MQTT servers. This complicates...
-
stat/tasmota_E496E7/STATUS10 = {"StatusSNS":{"Time":"2025-11-29T21:48:32","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.00,"RadiationAvg1Min":0.00,"Status":1,"Vibration":0,"Measurement":"0T00:00:21"}}} it is published periodically and can be triggered with the command.
-
stat/tasmota_E496E7/STATUS10 = {"StatusSNS":{"Time":"2025-11-29T21:48:32","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.00,"RadiationAvg1Min":0.00,"Status":1,"Vibration":0,"Measurement":"0T00:00:21"}}}
-
stat/tasmota_E496E7/STATUS10 = {"StatusSNS":{"Time":"2025-11-29T21:48:32","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.00,"RadiationAvg1Min":0.00,"Status":1,"Vibration":0,"Measurement":"0T00:00:21"}}}
-
This is the real json from the log console: {"Time":"2025-11-29T21:23:11","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.00,"RadiationAvg1Min":0.00,"Status":1,"Vibration":0,"Measurement":"0T00:00:09"}} I will setup some mosquito broker in the free time and check topics and full messages.
-
Ok, I looked into the code and read basics about how Tasmota sends data (before I just add it to the broker and let Home Assistant do the parsing for me). So, measurements are read from the sensor every 10s. Then every TelePeriod they will be send to telemetry topic. After sending cmnd/<device-topic>/Status 10 Tasmota will also send data but not to the telemetry topic but to stat/<device-topic>/STATUS10. Data will be available inside StatusSNS field and according to code should look like that: {...
-
Ok, I looked into the code and read basics about how Tasmota sends data (before I just add it to the broker and let Home Assistant do the parsing for me). So, measurements are read from the sensor every 10s. Then every TelePeriod they will be send to telemetry topic. After sending cmnd/<device-topic>/Status 10 Tasmota will also send data but not to the telemetry topic but to stat/<device-topic>/STATUS10. Data will be available inside StatusSNS field and according to code should look like that: {...
-
Ok, I looked into the code and read basics about how Tasmota sends data (before I just add it to the broker and let Home Assistant do the parsing for me). So, measurements are read from the sensor every 10s. Then every TelePeriod they will be send to telemetry topic. After sending cmnd/<device-topic>/Status 10 Tasmota will also send data but not to the telemetry topic but to stat/<device-topic>/STATUS10. Data will be available inside StatusSNS field and according to code should look like that: ~~~{...
-
Also I think that If geigerlog handle gdk101 as Tasmota device I can emulate it in the Home Assistant automation and use my esphome device the same way.
-
Also I think that If geiger log handle gdk101 as Tasmota device I can emulate it in the Home Assistant automation and use my esphome device the same way.
-
Ok, I looked into the code and read basics about how Tasmota sends data (before I just add it to the broker and let Home Assistant do the parsing for me). So, measurements are read from the sensor every 10s. Then every TelePeriod they will be send to telemetry topic. After sending cmnd/<device-topic>/Status 10 Tasmota will also send data but not to the telemetry topic but to stat/<device-topic>/STATUS10. Data will be available inside StatusSNS field and according to code should look like that: {...
-
Ok, I looked into the code and read basics about how Tasmota sends data (before I just add it to the broker and let Home Assistant do the parsing for me). So, measurements are read from the sensor every 10s. Then every TelePeriod they will be send to telemetry topic. After sending cmnd/<device-topic>/Status 10 Tasmota will also send data but not to the telemetry topic but to stat/<device-topic>/STATUS10. Data will be available inside StatusSNS field and according to code should look like that: {...
-
That is what exactly I'm asking for. The support for the GDK101 is already inside the Tasmota (see provided github link). I worked on that few years ago (there was some old unmerged PR, so I updated it and was able to make it finally merged, then I also contributed that sensor for esphome project). I will check how the communication with that device work in a free time, and get back to you, but as far as I remember it just sending all the measurement every TelePeriod. It also should send the measurements...
-
That is what exactly I'm asking for. The support for the GDK101 is already inside the Tasmota (see provided github link). I worked on that few years ago (there was some old unmerged PR, so I updated it and was able to make it finally merged, then I also contributed that sensor for esphome project). I will check how the communication with that device work in a free time, and get back to you, but as far as I remember it just sending all the measurement every given period. If some improvements would...
-
That is what exactly I'm asking for. The support for the GDK101 is already inside the Tasmota (see provided github link). I worked on that few years ago (there was some old unmerged PR, so I updated it and was able to make it finally merged, then I also contributed that sensor for esphome project). I will check how the communication with that device work in a free time, and get back to you, but as far as I remember it just sending all the measurement every given period.
-
I will not spend time in putting GDK101 into a Tasmota system. It's an interesting technical thing, but it's not worth using it for serious purposes. However, since I have the GDK already in GeigerLog, I would put it in as a Tasmota device, if you provide the required info. Which is: the command to send to Tasmta to send data, and Tasmota's answer to this request.
-
I'm also planning create real geiger tube IOT setup, but since my Chinese kit not working with my surplus tube, and I haven't fond time to trace the issue yet the GDK101 is first choice for me, but definitely I will try to setup geiger tube with esp MCU either.
-
I'm also planning create real geiger tube IOT setup, but since my Chinese kit not working with my surplus tube, and I haven't fond time to trace the issue yet the GDK101 is first choice for me, but definitely I will try to setup geiger tube with esp MCU and wifi either.
-
I'm also planning create real geiger tube IOT setup, but since my Chinese kit not working with my surplus tube, and I haven't fond time to trace the issue yet the GDK101 is first choice for me, but definitely I will try to setup geiger tube with esp MCU either.
-
I'm also planning create real geiger tube IOT setup, but since my Chinese kit not working with my surplus tube, and I haven't fond time to trace the issue yet. The GDK101 is first choice for me.
-
This is post is about slightly different setup - no Tasmota but rather Home Assistant automation (a python script) that will recalculate data and send them over MQTT. If this is too close to Tasmota solution and could be handled there sorry for doubling. We can move this discussion there.
-
I'm asking for supporting it over Tasmota. So GDK101 is interfaced by some ESP or other Tasmota supported MCU, and Geigerlog read the data over MQTT. Device like that that put somewhere and geigerlog in container on home automation server.
-
I'm asking for supporting it over Tasmota. So GDK101 is interfaced by some ESP or other Tasmota supported MCU, and Geigerlog read the data over MQTT. Device like that (https://www.printables.com/model/1134246-d1-mini-v4-gdk101-case/collections) put somewhere and geigerlog in container on home automation server.
-
This is post is about slightly different setup - no Tasmota but rather Home Assistant automation (a python script) that will recalculate data and send them over MQTT. If this is too close to Tasmota solution and could be handled there sorry for doubling.
-
I'm asking for supporting it over Tasmota. So GDK101 is interfaced by some ESP or other Tasmota supported MCU, and Geigerlog read the data over MQTT.
-
Why did you double post under different topics? This post does not make it any clearer.
-
Not sure what exactly you are asking for. GDK101 is an I2C based device, and as such it is supported in GeigerLog, and also on a Raspi (in a separate software package, but part of the full GeigerLog package). It works. But in my opinion it is not worth any effort! Sensitivity is way too low. For reviews look into my Article folder (https://sourceforge.net/projects/geigerlog/files/Articles/) for articles about PIN-Diodes: * GeigerLog-Review PIN Diode Geiger Counters-v.1.0.pdf * GeigerLog-Review Smart...
-
I will want to setup my GDK101 esphome sensor with geigerlog. I will probably need to setup something to pass values from Home Assistant to the MQTT broker, or add additional MQTT client to an esphome device. I will dig into that. But I need some guidance for setting it up on geigerlog, and with data preparation. Will someone could help me with this?
-
Since there is a GDK101 in Tasmota it will be great if it will be supported as IOT device out of the box. https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xsns_sensor/xsns_106_gdk101.ino
-
GeigerLog updated /README.md
-
-
-
-
-
Jan posted a comment on ticket #12
By 'I'm running into the same issue' I was referring to trying to contribute by fixing a problem (see other ticket with regards to Linux, RadPro) myself but sourceforge does not allow it.
-
@Jan - Yeah, no pulling on sourceforge :-( To correct either do what @Schuby did, or install the latest Python version. But could you please report the location of this problem?
-
I'm running into the same issue. I would have fixed the error myself with a pull request ullix would only have needed to click on but sourceforge does not seem to allow git versioning at all?
-
Schuby posted a comment on ticket #12
Will do. I generally use GitHub so I wasn't sure how (or if it is possible) to submit a code change to SourceForge. Not sure if you ever thought about using GitHub for this project, but that would allow pull requests and such.
-
Thanks for reporting. The problem was the double-quote use inside double-quotes.; you solved that problem correctly. This was a bug in Python 3.10, and it is corrected in later versions. The trouble for me is that I use Py3.13. So I no longer find the problems, unless I run an older version, AND come across this line :-( If you find more of it, please let me knpw!
-
SyntaxError (gsup_utils.py)
-
RadPro is undetectable in Mac/Linux
-
Jeff posted a comment on discussion General Discussion
Just a cleaned up graphic from my post, 2025-10-10. I decided to just plot rc-110 data as the epoch log records the values - no averaging or data manipulation.
-
1.5 sec - Wow! For comparison data from my current GeigerLog computer. The CPU is modern, but by far not top-of-the-line. I remember similar values from much slower computers: # CPU Model: AMD Ryzen AI 9 HX 370 w/ Radeon 890M, GeigerLog Benchmark (GLBM): 285 # GMC-800Re1.18 GMC_fetchValues: open duration: 16.08 ms GMC_fetchValues: close duration: 0.52 ms # GMC-300Re 4.54 GMC_fetchValues: open duration: 15.81 ms GMC_fetchValues: close duration: 0.53 ms Closing the serial port is well under 1 ms; opening...
-
Bob posted a comment on discussion General Discussion
Yeah, the only thing I remember about neutrons was when I worked at the nuclear power plant they always had a neutron detector in reactor containment, and it would be occasionally make a beeping sound as it detected free neutrons and during our training, they said if it started beeping very fast you would need exit the containment stuucture. Bob
-
Michel posted a comment on discussion General Discussion
Interesting! Thanks for the link. I used the test code provided in the link and it seem Apple has fixed (parts of) the issue in macOS 26 (Tahoe) with opening the port, but not with closing. It seems closing the port takes the long time: % clang -o porttest porttest.c && ./porttest /dev/cu.usbserial-210 opened 0 in 0.011268 closed 0 in 0.506648 opened 1 in 0.014742 closed 1 in 0.507568 opened 2 in 0.014197 closed 2 in 0.507200 opened 3 in 0.013780 closed 3 in 0.507292 opened 4 in 0.014728 closed 4...
-
Oh no! All these years I lived happily, putting all blame about hardware problems on the GMC counters! It was a sure hit every time! And now you are coming and showing to me that the most modern of the Apple computer is even worse than the meager Raspberry Pi ;-)) Apparently this is well known, and Apple gives the middle finger for fixing this! https://discussions.apple.com/thread/255763367?sortBy=rank I now have to put code into GeigerLog for a work around to the poor performing Apple computers....
-
Using GMC_DurAllCalls = 0.7seems to work reliable for both of my GMC counters. The log for the GMC-800 (1 seconds) is attached. (I don't have an alternative computer available)
-
I really have neither experience nor any good knowledge on neutron counters. I believe you need to moderate neutrons to get to "slow" neutrons, which you can then detect via nuclear reactions, which do send out gammas?
-
they’re kind of pricey I actually know the guy that’s selling this on eBay. He reconditions instruments so you can rest assured if you buy something from him and there’s an issue he will make it right. Bob https://ebay.us/m/6l1BS3
-
Simone modified a comment on discussion General Discussion
thank you both for the explanation. not sure I understand it all, but I'll try :) (what do you think about the neutron detectors? probably not much of a use-case at sea level outside off ISM applications. it's interesting how alpha beta and gamma are measured in terms of CPM whilst neutrons are measured using n/cm^2/s. this makes a lot more sense to me because it factors in surface area.)
-
thank you both for the explanation. not sure I understand at all, but I'll try :) (what do you think about the neutron detectors? probably not much of a use-case at sea level outside off ISM applications. it's interesting how alpha beta and gamma are measured in terms of CPM whilst neutrons are measured using n/cm^2/s. this makes a lot more sense to me because it factors in surface area.)
-
GeigerLog takes the values from each device as close to the start of a cycle as possible. Those sluggish devices - which includes all GMC counters - I start calling them earlier, so their data will be ready at cycle start! For GMC counters I currently call them earlier by 500 ms. That had been generous. Now your system shows, it may not suffice? If you want to fiddle with it: in the gdev_gmc.py file search for line GMC_DurAllCalls = 0.5and change the 0.5 sec to a larger value. Then try, and post...
-
GeigerLog takes the values from each device as close to the start of a cycle as possible. Those sluggish devices - which includes all GMC counters - I start calling them earlier, so their data will be ready at cycle start! For GMC counters I currently call them earlier by 500 ms. That had been generous. Now your system shows, it may not suffice? If you want to fiddle with it: in the gdev_gmc.py file search for line GMC_DurAllCalls = 0.5and change the 0.5 sec to a larger value. Then try, and post...
-
;-) - I don't mind either variant of your pancakes! @Bob posted the spec sheet of the LND7314 - and if the naming is unexpected, they themselves call it "Pancake mica window alpha-beta-gamma detector". LND says that the "Window" is made of Mica, and its "AREAL DENSITY" is "1.5 - 2.0 MG/CM²". Assuming a density of Mica of 3 g/cm³, we arrive at a thickness of roughly 10µm (micrometer)! LND does not give a thickness of the bell-part of the detector. Let's assume it is iron (density 7.9 g/cm³), and has...
-
LOL! The LND 7314 is the Pancake GM tube used in the GMC 600+ and the RadEye B20. The window is a thin film of Mica which allows Alpha,Beta and of course ganmma to be detected. Bob
-
not sure i understand what you mean by "hard and thin side are almost invisible" to gamma/xrays. maybe i dont understand how pancakes are contructed and operate. ill research this. (i do know that in the US they are pretty thick and sodden with maple syrup whilst where i grew up they're more like French crepe with a little lemon and a dusting of sugar) oh sure, there are a few; practicality, purchase price, and maintenace/calibration costs, aside...
-
not sure i understand what you mean by "hard and thin side are almost invisible" to gamma/xrays. maybe i dont understand how pancakes are contructed and operate. ill research this. (i do know that in the US they are pretty thick and sodden with maple syrup whilst where i grew up they're more like French crepe with a little lemon and sugar) oh sure, there are a few; practicality, purchase price, and maintenace/calibration costs, aside...
-
not sure i understand what you mean by "hard and thin side are almost invisible" to gamma/xrays. maybe i dont understand how pancakes are contructed and operate. ill research this. (i do know that in the US they are pretty thick and sodden with maple syrup whilst where i grew up they're more like French crepe with a little lemon and sugar) oh sure, there are a few; practicality, purchase price, and maintenace/calibration costs, aside...
-
Hi ullix, thanks! Yes, I don't have a problem with this, but I'll try to get the counter firmware updated. The confusing part is only that (a) I get the same behaviour for all logging cycles I tried (e.g., even with 60 seconds -- see attached), and (b) I don't see this behaviour with version 1.5.0 With 1.5.0 I see of course the same long fetch values of >500ms, but GeigerLog seems to be able to log each 1-second value. Example log file is attached. I observe the same issue with my GMC500+ FW2.53,...
-
@Michel: The reason that your records skip every 2nd recording lies in the GMC device; it takes absurdly long to finish a call, about 10x longer that mine takes! Your proglog shows the calls take some 578 ms: 2025-10-11 09:35:58.200 ...777 THREAD_GMC_fetchValues: 578.31 - - 29.000 0.000 - - - - - - - - while my very same GMC-800 takes some 64 ms: 2025-10-11 10:10:04.093 ...784 THREAD_GMC_fetchValues: 64.03 - - 19.0000 0.0000 - - - - - - - - Even for older GMC counters, some 500+ ms is very unusually...
-
@Michel: The reason that your records skip every 2nd recording lies in the GMC device; it takes absurdly long to finish a call, about 10x longer that mine takes! Your proglog shows the calls take some 578 ms: 2025-10-11 09:35:58.200 ...777 THREAD_GMC_fetchValues: 578.31 - - 29.000 0.000 - - - - - - - - while my very same GMC-800 takes some 64 ms: 2025-10-11 10:10:04.093 ...784 THREAD_GMC_fetchValues: 64.03 - - 19.0000 0.0000 - - - - - - - - Even for older GMC counters, some 500+ ms is very unusually...
-
@Michel: The reason that your records skip every 2nd recording lies in the GMC device; it takes absurdly long to finish a call, about 10x longer that mine takes! Your proglog shows the calls takes some 578 ms: 2025-10-11 09:35:58.200 ...777 THREAD_GMC_fetchValues: 578.31 - - 29.000 0.000 - - - - - - - - while my very same GMC-800 takes some 64 ms: 2025-10-11 10:10:04.093 ...784 THREAD_GMC_fetchValues: 64.03 - - 19.0000 0.0000 - - - - - - - - Even for older GMC counters, some 500+ ms is very unusually...
-
Seems I didn't refresh my browser...just saw your previous message. I don't have a geigerlog.proglog.devel but a geigerlog.proglog, which is attached.
-
Oh my gosh, yet another cause for troubles, ARM vs Intel! Thanks for reporting.
-
I found the problem with "playsound"...The package I had installed was built for Intel (x86_64) (this I installed long time ago with Rosetta since not everything was available for ARM). I'm now running everything on an ARM-based Mac, but seems had forgotten to reinstall this package. You just need to remove the broken sound utils install and reinstall it. Now everything seems working fine! Thanks again.
-
Skipping every 2nd cycle even at 5 sec cycle time? Very strange. Please, do this: * Make sure that the custom.cfg file has nothing in it except the GMC activation. * have the GMC counter connected to your GL computer * Start GL with this command: ./Geigerlog.sh -d * set cycle time to 1 sec * start logging for some dozen cycles * stop logging * exit GL The post here resulting file geigerlog.proglog.devel
-
The pancake detector is like a bell: a hard bowl on one side, and a very thin window "glass" on the other. The hard side is almost unpenetratable for betas, while they can pass through the window much easier than through the glass of glass tube. For gammas, however, both hard and thin side are almost invisible! This is true even for X-rays! If you have no plastic case for the 600, then a regular Paper magazine, hold on the window side, would do. Laying the counter on its small side would reduce the...
-
I'd have thought a gmc600 laid flat w/ the pancake surface parallel w/ the fuselage would register more gamma hits from space (that manage to get through the fuselage and the few tens of thousands of feet of atmosphere above the plane) than when on its side, given the much larger surface area. Thoughts? I'd love to have (and afford) a reliable neutron detector as, compared to gamma/xrays/cosmic rays, they create the most biological damage (especially at altitude). I wonder if pilots/crew (who are...
1 >
