ullix

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!

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

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

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?

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

@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...