Activity for ullix
-
ullix posted a comment on discussion General Discussion
Consider looking into the manual.
-
I re-did all the wiring, and checked again: VPP was 3.8V. Vmin=-0.2V, Vmax=+3.6V. This is borderline! I then soldered a wire on the tiny output-pad of the GDK101, and with some sweat on my forehead I made the connection. The ESP32 survived. Phewwww! I got some interesting data. My ESP32 is a plain ESP32-D0WD-V3 v3.0. The TASMOTA is the latest generic code (which does not support a GDK101!). All other stuff is my own Berry code, added to the Tasmota. I can now do Geiger Counter by counting pulses,...
-
Can't hurt. That pulse output is tiny pad! Just checked it with an osci: VPP is 4.1V! The ESP32 will not like this! It wants 3.3V, and no more than 3.6 V!!!
-
Can't hurt. That pulse output is tiny pad!
-
Look into the GeigerLog manual, chapter "Introduction to GeigerLog, Installing, Starting, and Using GeigerLog", and follow instructions.
-
Ok, is done. Watch for the upcoming pre-release 02 here: https://sourceforge.net/p/geigerlog/discussion/devel2/
-
As I said on the GQ forum: Open a command window, and start GeigerLog. Post every outcome into your ticket.
-
Attached a pic from running the GDK101 on my latest GeigerLog. Blue the 1min data, Magenta the 10min data, red the Temperature from an I2C sensor BME280, and black barometric pressure, all run on the very same ESP32 simultaneously. Bad news: I have loaded the GDK101 with a bag of Uranium beads to give it a bit of a workout. It is responding with µSv data. This is physical bullshit! The calibration of counters - if done at all - refers to Gamma radiation. It is undefined when it receives radiation...
-
Attached a pic from running the GDK101 on my latest GeigerLog. Blue the 1min data, Magenta the 10min data, red the Temperature from an I2C sensor BME280, and black barometric pressure, all run on the very same ESP32 simultaneously.
-
Attached a pic from running the GDK101 on my latest GeigerLog. Blue the 1min data, Magenta the 10min data, red the Temperature from a BME280, and black barometric pressure, all run on the very same ESP32 simultaneously.
-
Attached a pic from running the GDK101 on my latest GeigerLog. Blue the 1min data, Magenta the 10min data, red the Temperature from a BME280, and black barometric pressure, all run on the very same ESP32 simultaneously.
-
I checked the log; looks ok so far. The variables in GeigerLog are strictly numeric-only! Thus strings can never be stored in them. However, I think the values from GDK101 status, vibration, measurement are quite irrelevant to a user. Status changes from 0 to 1 to 2 within 10 min and then stays at 3 forever. Vibration seems to be nailed at 0. I tried hard shaking my device to at least once ge a "1", but failed. Measurement goes up from zero to 10min 59 sec, and then goes back to 10mjin 0 sec, and...
-
English, please.
-
Respect for figuring out what changes are needed for dark mode! I tested it, and it seems to work. I am a bit surprised: is that really all there is needed for dark mode? It seems too easy. I find no way for PyQt6 to auto- detect a dark mode versus a light mode. Is there one? However, a mildly smarter hack could be to put this in the configuration, and allow the user to change it. It still won't be automatic, but is easy to do. Would that work for you?
-
Thanks for the bug report. But things are changing quickly here, will let you know. So, can you do a long(er) term recording with the current GTK101 system? A different question should go on a different topic.
-
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...
-
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...
-
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...
-
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.
-
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...
-
@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?
-
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...
-
@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...
-
Oh my gosh, yet another cause for troubles, ARM vs Intel! Thanks for reporting.
-
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...
-
Really too bad you can't download the GPS data! Interpretation of the data is a bit demanding. The low blue curve is the GMC500? Quite a textbook result with near constant CPM. Which makes the Altitude jump about halfway to Texas all the more surprising. Can you look in retrospec at weathermaps ? Any obvious transition from low to high pressure systems? GPS would really be helpful! The black spikes are from RC110? Very odd. No idea, where they come from. Wild guess, the GMC600 increased levels during...
-
I'm a bit overwhelmed with the mix of messages from different users. Let's approach this a step at a time. I believe the crash last reported by @Michel had already been fixed in GL2.0. Apparently not. So I am adding to this post the latest version of the gdev_gmc.py file. Copy this over the existing file, and leave everything as is! This may or may not fix the GMC problem. If not, the I will post a new development release of a full GL.
-
Really too bad you can't download the GPS data! Interpretation of the data is a bit demanding. The low blue curve is the GMC500? Quite a textbook result with near constant CPM. Which makes the Altitude jump about halfway to Texas all the more surprising. Can you look in retrospec at weathermaps ? Any obvious transition from low to high pressure systems? GPS would really be helpful! The black spikes are from RC110? Very odd. No idea, where they come from. Wild guess, the GMC600 increased levels during...
-
Coming soon
-
First: This 'Anonymous' posting is a real nuisance !!! I don't know wether this 1, 2. 3 or even more different persons, or just a single one. Or even the same as one who posted a few days earlier. I'll try to make this impossible using sourceforge tools. If that is not possible, I will just delete any anonymous posts! I don't want to know your real name. Any fake username is perfectly fine with me! Sorry, but I have had it! Second: Do I see this right that your problem has disappeared, and GeigerLog...
-
It looks like you are barking up the wrong tree! Go to GQ and complain. GeigerLog is open source, which means that volunteers are using their own time and money to create software, which they offer the community for free. While I do offer support for users of GeigerLog, that does not mean that I offer training for beginners of computer use. Get some friends who are more knowledgeable to help you for the first steps. Also, I have mistaken your identity, as you never gave any name to identify you,...
-
Sorry, I missed that. Stupid mistake; attached is an update to GLrelay.py. I consider GLrelay.py as important, and want to make sure it works! Remember that you must start it with admin rights!
-
Well shielded, indeed! With respect to Potassium I very much recommend my "Potty Training" article! https://sourceforge.net/projects/geigerlog/files/Articles/ The Granite most likely sends out way more beta than gamma! This results in many clicks in Geiger counters, and ruins spectra in spectrometers :-( Try shielding the betas - see again my Potty Training for guidance. I think a paper magazine should suffice like e.g. an issue of "Playboy" for hot Granite counter tops ;-)). Beta will be gone almost...
-
You leave me puzzled: how were you ever able to run GeigerLog when you are not aware of "Terminal", "working directory", "cd" ? Anyway: google for "Mac Terminal" and learn its use. Then: Download GeigerLog, and put it into a dirctory of your choice. Unzip it. It will have formed a directory "geigerlog" Using the Terminal, change into this directory Still in the Terminal, run "Geigerlog.sh setup"
-
It is not even true, what I said - GeigerLog is more intelligent than I thought ;-(( But the problem is along the lines of an installation issue. GeigerLog needs a "Setup"! Please see the GL manual in chapter "Installing, Starting, and Using GeigerLog", and follow line by line. You need a terminal!!! Make yourself aware on how to use it. P.S. Please, login for posting. I find this need for approval quite annoying :-(
-
GeigerLog wants to be installed in a directory "geigerlog" - nothing else, e.g. not geigerlog2! This directory can be down to the umpteenth dir, so ...glx/gly/anything/geigerlog2/geigerlog is ok! I suggest to delete all dirs geigerlog and reinstall from scratch.
-
with GMC-500 an average CPM=11.5 - Yeah, well shielded! Note that GQ's claim: Instrument Background: < 0,2 pulses/s # = CPM=12 means you are getting less than the electronic noise of the counter should give you! Strangely, for the GMC-600 the very same Instrumental BG is claimed. Anyway, I believe the message is you are getting very little radiation both from above and below. What type of ship/boat was this? Metal or Plastic?
-
Please use the file gdev_gmc.py from post 2025-08-21, overwrite current file of same name, and try again. It should have fixed it.
-
"Noise" is when you can't explain it ;-)) No, I have no other ideas. But keep me posted on anything of interest. Start a new topic when you feel like it!
-
FlightRadar24 keeps the GPS altitude as well but it is only available for gold members and I only have silver. Holy Moly, I did not know that; this is exciting! Unfortunately, I am not even a scrap-metal member :-(, so all hopes rest on you! All I can offer is a free GeigerLog download for life ;-) If I had wish free, it would be a highly turbulent long-distance flight crossing the equator! Gamma spectra can be difficult to interpret, indeed. But Muons? To me they are more in the range from Mega...
-
I looked at spectra my Radiacode 102 had produced. Leftmost is Am-241. It does seem to show both its peaks 59.5keV and 26.3keV; the ratio of the peak height is reasonable, when compared to online data https://www.gammaspectacular.com/blue/gamma-spectra/am241-spectrum Its 17keV peak is not visible. The other spectra show various background and other sources. Of interest here is that all seem to show a cutoff, setting in very near 17keV. The crumbs to the left of it are then "noise" of any kind, electronic...
-
Have you mesured with a Geiger counter while at sea? Kind off, while sailing on the Dutch Ijsselmeer. The Effect was visible, though only 20...30%, see pic. Counter GMC-300E+. The boat was "plastic", some standard 40ft sailing vessel. But spectra were not taken.
-
Have you mesured with a Geiger counter while at sea? Kind off, while sailing on the Dutch Ijsselmeer. The Effect was visible, though only 20...30%, see pic. Counter GMC-300E+. The boat was "plastic", some standard 40ft sailing vessel. But spectra were not taken.
-
I looked at spectra my Radiacode 102 had produced. Leftmost is Am-241. It does seem to show both peaks 59.5keV and 26.3keV; the ratio of the peak height is reasonable, when compared to online data https://www.gammaspectacular.com/blue/gamma-spectra/am241-spectrum The other spectra show various background and other sources. Of interest here is that all seem to show a cutoff, setting in very near 17keV. The crumbs to the left of it are then "noise" of any kind, electronic or software produced. This...
-
Have you mesured with a Geiger counter while at sea? Kind off, while sailing on the Dutch Ijsselmeer. The Effect was visible, though only 20...30%, see pic. Counter GMC-300E+. The boat was "plastic", some regular 40ft sailing vessel. But no spectra.
-
Have you mesured with a Geiger counter while at sea? Kind off, while sailing on the Dutch Ijsselmeer. The Effect was visible, though only 20...30%, see pic. Counter GMC-300E+. The boat was "plastic", some regular 40ft sailing vessel.
-
Have you mesured with a Geiger counter while at sea? Kind off, while sailing on the Dutch Ijsselmeer. The Effect was visible, though only 20...30%, see pic. Counter GMC-300E+.
-
Do you know how to ping a moderator? You mean like sending a message? Click on the blue name on the top of a post. Then click on button "Send Message".
-
I can't help, but anything on the very left of the spectrum is bound to be noise, most likely electronic noise. You need some really powerful evidence to the contrary to claim any true radioactive origin. I don't see that evidence?
-
Then the "lead and copper" experiment leaves only two explanations: 1. the 80keV peak is created in the "lead and copper". Are there any Xray candidates? 2. it is some electronic artifact? Did you raise this issue on other forums, like https://www.geigerzaehlerforum.de/index.php ?
-
FlightRadar24 keeps the GPS altitude as well but it is only available for gold members and I only have silver. Holy Moly, I did not know that; this is exciting! Unfortunately, I am not even a scrap-metal member :-(, so all hopes rest on you! All I can offer is a free GeigerLog download for life ;-) If I had wish free, it would be a highly turbulent long-distance flight crossing the equator! Gamma spectra can be difficult to interpret, indeed. But Muons? To me they are more in the range from Mega...
-
@Jeff, I looked at your GMC-600+ counter calibration data. This it what GeigerLog saw in your files (see pic). Are these the original, default data embedded in the counter's firmware, or have you modified them in any way? These data look a lot like BS. If you had modified them, could you do a "Factory Reset" and post the configuration screenshot again?
-
@Jeff, I looked at your GMC-600+ counter calibration data. This it what GeigerLog saw in your files:
-
Attached is a modified gdev_gmc.py file; it is more talkative for debugging. Please, copy over existing file before running any further tests.
-
Attached is a modified gdev_gmc.py file; it is more talkative for debugging. Please, copy over existing file.
-
There appear to be a Windows problem, plus one or more counter firmware problems. Please, for all this debugging, always start GL with option "-d", then do brief logging, then exit, then post file geigerlog.proglog.devel! If GL crashes, then also post the last lines from the terminal which give crash info. Windows: given these lines: Error 259 for command: play "C:\Users\belue\Documents\!Data\Python\02-DataAnalysis\geigerlog\gres\bip.wav" wait The driver cannot recognize the specified command parameter....
-
Please, direct all complains and comments about Data Viewer to GQ - I have nothing to do with it!
-
@Jeff: both files indicate that GeigerLog is running well with your counter. Neither contains any crash info whatsoever. I notice that your counter has firmware 2.53, a version I had not seen before. It is quite possible that GQ has done a change which made it incompatible with previous versions. They like to do that :-(((! What is the firmware version in your GMC-600 counter? Please post a screenshot of 'Set GMC Configuration' at the last moment before it crashes. And also anything outputted to...
-
@Jeff: both files indicate that GeigerLog is running well with your counter. Neither contains any crash info whatsoever. I notice that your counter has firmware 2.53, a version I had not seen before. It is quite possibkle that GQ has done a change which made it incompatible with previous versions. They like to do that :-(((! Please post a screenshot of 'Set GMC Configuration' at the last moment before it crashes. And also anything outputted to the terminal in this moment.
-
The RadiaCodes are great devices, indeed. The "peak" at ~80keV perplexes me - there is no reason for it! As these are very low energies, I am wondering whether the real feature is not the "peak", but the valley to the left of it? It could be the end of the detection limit, and the increase to the left of the valley is simply electronic noise?
-
As you are ignoring my advice about connecting multiple GMC counters, please connect ONLY A SINGLE GMC COUNTER AT A TIME! An then post file geigerlog.proglog.devel.
-
A good thing is to get flight data from FlightRadar24. They have CSV data of altitude vs time, it is great for seeing changes of CPM due to altitude changes. Yes, HOWEVER: be aware that the "altitude" is basically the barometric pressure converted to an altitude by a conversion formula! It is NOT the geometric altitude that e.g. a GPS would deliver. This is used by all airplanes so all airplanes are flying on the proper "altitude" levels, and traffic is safe. But depending on the barometric air pressure...
-
I am afraid I cannot reproduce any of the things you describe. It helps better when you do the following: * start GeigerLog with GeigerLog.bat -d * start logging, and log for a minute * stop Logging * exit GeigerLog There should be a file geigerlog.proglog.devel in the data directory. Post this file. Some general things: The tube sensitivities given by GQ may often be wrong! Therefore GeigerLog ignores them completely, and uses its own settings. You can change the default settings as you like, even...
-
You tried to open a bin file as a database! This cannot work; bin files are highly device specific. Read the manual for opening History files with your devices. But GeigerLog should not crash. However, I tried to repeat your wrong approach, but my GeigerLog never crashed? Could you please post the file which results in a crash in your system?
-
Welcome Jeff, (btw, it makes it easier for me and others when you register at sourceforge) re 1: do you get the same gaps when you download with GeigerLog? if you post the downloaded bin data, I can take a look re 2: the Sensitivities of the two detectors are roughly 2fold different. Therefor the CPMs should be 2fold different, but the Sv identical. Note: this is strictly valid ONLY for Cs-137 Gamma, and completely invalid if you find a significant contribution of beta re 3: I have no access to balloon...
-
-
On closer review I found the situation is more complex, and needs a different correction. I am attaching a new gdev_gmc.py file. Please, copy over the existing file. Nothing else needed, in particular no new installation. Thanks for pointing me to this issue.
-
On closer review I found the situation is more complex, and needs a different correction. I am attaching a new gdev_gmc.py file. Please, copy over the existing file. Nothing else needed, in particular no new installation. Thanks for pointing me to this issue.
-
Thanks for giving a nicely detailed bug report, and even its solution! I am wondering how generic this is. Looking into Mac port naming I find there are (at least) two variants possible: tty.usb or cu.usb. How can one be sure that only the cu variant is relevant? This whole section is only because of a bug in the GMC firmware resulting in failures with port numbers > 10! In your case the resulting port number would be portNo=120. This would make GeigerLog print out a failure warning. Does this not...
-
test
-
Copyright Code and Link to My Project
-
GeigerLog pre-release 1.5.1pre14 + FNIRSI GC-01 (Geehy)
-
Now that you finally named the version of my code and your license, I could find it. You use an MIT License. And you are still trying to force others to not use your code? Sounds hilarious; may I remind you of what Wiki says on MIT license: The MIT License is a permissive software license originating at the Massachusetts Institute of Technology (MIT)[6] in the late 1980s.[7] As a permissive license, it puts very few restrictions on reuse and therefore has high license compatibility. But not only...
-
We're getting there slowly. Now tell me: * in which version of my projects * where do I see your copyright statement *
-
Folks, I have no problem in removing any copyrighted code. But given that I have always avoided copyrighted code, I doubt that I have some in my project. This impression is furthered by your playground-like bullying in your first post, and your lack of clear indication what it is that you are claiming - there are many versions on this site - in combination with the lack providing evidence that you even have any copyright at all. Present the reqired details, and I will follow suit.
-
Pardon me, but your rude tone, lack of precision, and demand even for Link removal makes this look like spam to me. If you have true legal reasons for copyright, please prove it! Your line references point to irrelevant, trivial code of my own.
-
Thanks, but this was not what I wanted to see. Sorry. if I hadn't been clear enough. I need to see a log where failures do occur. What you sent is underlining that the Raspi4 does actually quite well. So, go for a 1 sec cycle time, and let it run until at least a few failures had occured.
-
Good to hear! On the Raspi4 I am interested in a log file. Start GL with ./GeigerLog.sh -dvw devel, let it log for some 10 min, and stop. Post the complete geigerlog.proglog.devel file, thanks.
1 >
