| Author |
 Topic  |
|
|
DeivF
USA
7 Posts |
 Posted - 11/15/2025 : 15:32:34
|
I recently purchased a new GMC-600 Pro directly from GQ Electronics. I already have a GMC-600+ and a Black Cat Systems GM-45. Just as with both the GMC-600+ and GMC-600 Pro, the GM-45 also uses the LND7317 "pancake" detector.
Soon after acquiring the GMC-600 Pro, I noticed that it seemed to be reading anomalously low. Just to check, I logged all three detectors continuously for three days. I placed all three detectors side-by-side on a table with the LND7317 windows facing up and nothing (except the table) for several feet in any direction from the detectors. Over the three day period, the GMC-600+ recorded an average of 47.2 CPM, the RM-45 recorded an average of 48.2 CPM, while the GMC-600 Pro recorded and average of 34.0 CPM.
In other words, over the three-day period, the GMC-600+ and the RM-45 recorded averages within 2.3% of each other, while the new GMC-600 Pro recorded approximately 28% less (it recorded a three-day average that was only 72% of the other two detectors).
Soon after, I took the GMC-600+ and the GMC-600 Pro on a commercial aircraft flight from California to Chicago and back. I placed both detectors side-by-side in my nylon-sided carry-on bag which I placed in the overhead storage. Both units had the LND7317 windows facing up and had nothing except one thickness of nylon (the top of the bag) over them. The one-hour running average (OHRA) readings from the GMC-600 Pro, both on the ground and at altitude and on both flights, were consistently only 70% to 74% of the OHRA readings from the GMC-600+.
While I don't have any calibration sources, I assume that since the readings from both the GMC-600+ and the RM-45 have historically been similar (within a few percent of each other), the new GMC-600 Pro is giving anomalously low readings.
Can this be corrected? Or do I need to return the GMC-600 Pro to GQ Electronics?
|
Edited by - DeivF on 11/15/2025 15:38:27
|
|
| Reply #1
ullix
Germany
1228 Posts |
Posted - 11/16/2025 : 03:35:06
|
Your question relates to multiple issues.
First, on any GMC counter the first thing you should do is to switch off the dreaded FET option - this may ruin all your data. It is switched off when set to 60!
Second, no two counters give the same CPM values, even when of the very same make! Comparing the uSv/h (micro-Sievert) values is the only valid way for comparison! But note 2 things: first, this not possible unless each counter has been correctly calibrated. And I am almost sure that neither counter was, because it costs quite a few extra bucks to do it in a reputable lab. And second, this calibration is valid only, O N L Y when your radioactive sample is a pure Gamma emitter. When it also emits betas - most samples around hobbyist do - a uSv reading is INVALID and can never be compared between counters!
Third, the radioactive process can be described by a Poisson distribution. Human beings cannot tell whether any of the data scatter has a Poisson property. But software can tell. To my knowledge, the only one useable is my GeigerLog software. You find it here (it is open source): https://sourceforge.net/projects/geigerlog/
Load your data, then click "Poiss" to run a Poisson test. Data are ok when you get such a result, no matter how weird the data may look like;
And lastly, nice flight data! I'am collecting such stuff for hosting on my GeigerLog site. When you are ok with, please post the raw data!
|
 |
|
| Reply #2
DeivF
USA
7 Posts |
Posted - 11/16/2025 : 19:10:35
|
Thank you, ullix, for your quick and very informative response.
The Fast Estimate Time was indeed set to "Dynamic" on the 600 Pro. I have now set it to "60 Seconds."
I have no way to know, but like you, I doubt the counters were ever calibrated. I've converted the CPM values to µSv/hr using the values I back-calculated from each of the counters. The 600+ appears to be using 380 CPM/(µSv/hr), while the 600 Pro appears to be using 355 CPM/(µSv/hr). The Black Cat software for the RM-45 uses a value of 300 CPM/(µSv/hr). Comparing the µSv/hr values for the 3-day run, the 600 Pro still appears record an average value about 23% lower than the 600+.
I ran the Poison test for the 600 Pro and the 600+, but was unable to run it on the RM-45 data. When I attempted to load the .csv file (which I formatted the same as the .csv files saved by GeigerLog), GeigerLog crashed with the error message:
File "gsup_sql.py", line 200, in DB_openDatabase
res = DB_Connection.execute("SELECT count(*) FROM data")
sqlite3.OperationalError: no such table: data
(it created the .hisdb file, but it was length 0)
The Poison graph of the 600 Pro data looks reasonably good, but the graph from the 600+ looks somewhat distorted.
On the flight data: Yes, I would be glad to send you the data files. I have a record of my recent flights from California to Chicago and back, and also 2019 flights from California to Poland and Ukraine and back. |
Edited by - DeivF on 11/16/2025 20:53:32 |
|
|
| Reply #3
ullix
Germany
1228 Posts |
Posted - 11/17/2025 : 06:36:00
|
Thw manufacturer of the lnd7317 claims a sensitivity of 348 CPM/(uSv/h). You'd have to have very good reason to exceed their claim!
Claiming less is always possible, as the case of the counter plays a role with respect to absorption.
And never forget, any Beta radiation will render your data useless with respect to uSv data! What source are you using?
GeigerLog does not like an empty database. Still, it shouldn't crash. Can you please post your raw data? Those that result in a crash. Posting data does not work in this forum. But is easy enough at the GeigerLog site. |
|
|
| Reply #4
DeivF
USA
7 Posts |
Posted - 11/17/2025 : 10:23:18
|
I did not use any source for the 3-day test (I, unfortunately, do not own any calibration sources). The data represent the background radiation in my office. I set the three detectors side-by-side with the LND7317 windows facing upward. There were no objects (except the table) within a meter of the detectors.
I have not altered any of the factory settings on any of the detectors. In other words, the sensitivity values for each of the detectors are the ones set by the detector manufacturer (GQ Electronics for the 600+ and 600 Pro, and Black Cat Systems for the RM-45).
Using the GQ Electronics default sensitivity values, the 600 Pro still records a µSv/hr average that is approximately 23% less than the 600+ in the same location, recording for the same duration. Using the LND7317 manufacturer's sensitivity value, the 600 Pro records an average that is approximately 28% less than the 600+.
I attempted to post the Poison graphs for both logs in my previous post, but apparently the forum did not like the "+" (in "600+") in the file name. Here are the Poison graphs from the 3-day logs (using a re-named image file):
|
Edited by - DeivF on 11/17/2025 10:41:08 |
|
|
| Reply #5
ullix
Germany
1228 Posts |
Posted - 11/18/2025 : 02:01:54
|
Please, the French guy's name is "Poisson" - with double-s! It is "fish" in English; has nothing to do with dangerous chemicals ;-)
Very nice data! Now I am really urging to see the RM-45 Poisson !!!
Background recording as you did is quite ok, and almost guaranteed to be free of betas. Poor man's radioactive sources could be kitchen granite counter tops, because of their Uranium content, or simply kitchen/bathroom tiles because of their potassium content. Read more in my "Potty Training" article (https://sourceforge.net/projects/geigerlog/files/Articles/) Though both emit plenty of beta, i.e. not useable for calibration!
Your histograms highlight the problems that exist with GMC-600 counters since their beginning. They have a defect in construction which creates defects in the counting! The left side histogram (600+) is clearly deficient. This counter is defect! The likely cause is too much capacitive load in the connection of the Geiger tube. I have shown this effect elsewhere, a long time ago.
The surprise to me is the right side Poisson (600Pro). It is kinda, sorta ok, though it still shows a significant deviation. Compare with the Poisson I posted last. That is from a run-of-the-mill counter, and yet, is almost text-book ready.
At least there is an improvement from "+" to "Pro". So, what happened? Can you open the cases, and post photos from the tube's connection to the circuit board?
As you said the RM-45 is using the same tube, you see why I am so interested in its data?
|
|
|
| Reply #6
DeivF
USA
7 Posts |
Posted - 11/19/2025 : 00:32:19
|
Please forgive the "poison" vs. "Poisson." I would like to blame it on my editor's auto correct (which does often deserve the blame), but I fear in this case it was just typing too quickly without proofing my words afterwards.
I have made some progress on loading the RM-45 data into GeigerLog. For some reason, GeigerLog was crashing when I attempted to import a .csv file form my ntwork server. However, when I copied the file to the GeigerLog local data directory, it appeared to be able to read the file. The dates appear to be formatted correctly and I am able to designate the column associations:
After clicking on "OK," however, GeigerLog appears to read only the first line into the (note the "Recs: 1" in the graph window):
Selecting "Show History Data" shows only one line of data:
==== Monitor Server =============================================================
Auto-Started Monitor Server at: 192.168.1.174 Port: 8080
==== Get History from CSV File ==================================================
History database: /home/DeivF/Applications/geigerlog/data/RM-45-3day-cpm.hisdb
Creating from file /home/DeivF/Applications/geigerlog/data/RM-45-3day-cpm.csv
==== Plot Data ==================================================================
from: /home/DeivF/Applications/geigerlog/data/RM-45-3day-cpm.hisdb
==== Show History Data ==========================================================
from: /home/dlfowler/Applications/geigerlog/data/RM-45-3day-cpm.hisdb
# Index, DateTime, CPM, CPM1st, CPM2nd, CPM3rd, Temp, Humid, Xtra
1, 2025-10-26 18:00:35, 48 2, 48 2, nan, nan, nan, nan, nan
# Index, DateTime, CPM, CPM1st, CPM2nd, CPM3rd, Temp, Humid, Xtra
I unfortunately don't have a granite counter top [As a side note, almost all "granite" counter tops I've seen are not granite. Most are gneiss and many are diorite]. I do have some large potassium feldspar crystals from a pegmatite (a single crystal approximately 40 cm in size), which should be interesting to check. I also have some antique uranium glass plates from the early 1900s.
I won't be able to look inside the detectors to get photos of the tube connections until the weekend (my day-job gets in the way - I am a geologist and will be in the field for the next few days). |
|
|
| Reply #7
DeivF
USA
7 Posts |
Posted - 11/19/2025 : 20:00:38
|
Success at last. I changed the end-of-line characters in the file from "carriage return" (<cr> - hex 0D) to "line feed" (<lf> - hex 0A), and the file imported correctly. So it appears that, at least when running GeigerLog on a Linux system, the .csv file must be on the local file system and must have unix-style end-of-line characters.
So, after all that, this is the Poisson graph for the RM-45 recorded over the same 3-day period as the 600+ and 600 Pro:
The data for the RM-45 is somewhat more course than for either the 600+ of 600 Pro because while the 600+ and 600 Pro logged one data point per second, the RM-45 recorded only one data point per minute. |
|
|
| Reply #8
ullix
Germany
1228 Posts |
Posted - 11/20/2025 : 02:13:28
|
Well, look at that: Nothing but random scatter, as the thin-red residual line shows!
A clear proof that the Geiger tube LND7317 is working just fine - if the device is constructed properly! And this is NOT the case with BOTH GQ-600 counters! One of them is bad, the other very bad.
I am showing this for years now, alas ...
Strange thing: Google doesn't know about an RM-45! Can you give links and details?
Would be great if you could run the RM-45 quite bit longer?
|
|
|
| Reply #9
DeivF
USA
7 Posts |
Posted - 11/21/2025 : 02:18:05
|
To my embarrassment I have been perpetuating a typographic error. The Black Cat Systems detector is the GM-45, not RM-45.I called it by its correct name in the first line of my first post in this thread, but then switched (for unknown reasons) to the wrong name. Please forgive my confusion.
Black Cat Systems is, I believe a one-person operation that specializes in armature radio software. In the early 2000s to 2019, they sold a series of rather simple counters. The counters had no on-board firmware and no display, meter, or any other user interface. They used a serial interface to connect to a computer. Any count from the detector is sent as a single byte over the serial line to the computer. The value of the byte is not important. The software on the computer simply counts the number of bytes received over time, ignoring the values.
The last Black Cat Systems web page that lists the GM-45 was from July 2019 (from the internet "Wayback Machine" archives). I would post the link here, but the forum doesn't like embedded urls within a url and won't allow it to be posted.
Here is an image of the archive url:
I've had the GM-45 attached to my server where it has been continuously recording (with some gaps) the background radiation in my home office since about 2009. The software provided by Black Cat Systems has always been a bit buggy and crashes every few weeks of continuous operation. The crashes generally result in a few hours to a few days of missed data (the time it takes me to notice the crash and restart the software).
Here is the Poisson graph for the period from 6 January through 24 February of this year (a period between software crashes, one data point per minute).
 |
Edited by - DeivF on 11/21/2025 02:59:46 |
|
|
| |
Topic |
|
|
|
600 Pro reading anomalously low
