| T O P I C R E V I E W |
| Scutti |
Posted - 07/10/2018 : 23:06:02
Hello,
two days ago i bought a new GMC600 Counter on amazon. Most of the time it showes reasonable values like 30-60cpm, but yesterday evening it raised two times until around 500cpm for about a half a minute or so (the Alarm started and i heard alot of "clicks"). I didn't move the Counter at all. Is it normal?? Should i send it back?
I left it "on" the entire night and all seems normal (max cpm Count was at aroung 90).
Here's the History data: h**p://www.gmcmap.com/historyData.asp?Param_ID=13984953226
Greetings from Italy
Armin |
| 29 L A T E S T R E P L I E S (Newest First) |
| EmfDev |
Posted - 11/14/2018 : 10:10:07
@Scutti,
We are so sorry for this issue. According to support, they replaced the tube from your unit and tested it for several days before shipping and was working properly. It's unfortunate that when you got it, the cpm is 0.
Please contact customer support again for return. Sorry about that. |
| Scutti |
Posted - 11/14/2018 : 04:47:50
Hello,
right in this moment i received the "repaired" Counter. I turned it on and the unit is DEATH. It shows ZERO Counts. See Picture below.
So, now i spent 60 Dollars for the shipping, only to get in return a death unit.
So what do you suggest next?
I am asking for a replacement.
Image Insert:
152351 bytes |
| Scutti |
Posted - 10/03/2018 : 21:48:48
yes i got a reply. i have to send it in for inspection. thank you very much. |
| EmfDev |
Posted - 10/03/2018 : 10:42:30
did you get reply yet? |
| Scutti |
Posted - 10/02/2018 : 19:49:57
Yes i wrote to them yesterday. I hope i get a response, since i wrote to them the first week i got it (for the software issue) and i never got a response from them. |
| EmfDev |
Posted - 10/02/2018 : 12:44:58
Hi Scutti, sorry to say but looks like unit has tube issues. They need to be replaced.
You can email/contact customer support at support@gqelectronicsllc.com for replacing the tube. |
| Scutti |
Posted - 10/02/2018 : 11:04:15
its like the device is getting saturated with minimal radioactivity! |
| Scutti |
Posted - 10/02/2018 : 10:52:19
ok guys i'm back with the same problem i mentioned in my entry post. but now its even worse! the device counts ghost clicks (it shoes 6-7 uSv when there is absolutely nothing!!). When i measure a weak radioactive source, the geiger reacts but suddenly it starts going crazy (up to 6-7uSv) until i turn it off and back on! Sometimes i dont even need a source and it starts going crazy! Whats wrong with this thing?!? I spend alot of money and its completely useless...!! :( sorry for my bad english but i am realy pissed now!! :( i can make a video for proof and better understanding... |
| ikerrg |
Posted - 07/17/2018 : 00:18:35
OK, thanks for the explanation. I'll send you some data of the whole day recording with GLSimple500 on the KCl bag probably later this evening. About editing the python files in windows the best editor is the free Notepad++ (https://notepad-plus-plus.org), and it takes everything into account (Linux line endings, UTF coding, etc).
|
| ullix |
Posted - 07/17/2018 : 00:07:29
quote:
I think I understand the Poisson thing between CPS and CPM, but I do not understand the need to log every minute instead of every second yet. Isn't the CPM calculated by continuously adding the CPS in a window of 60 seconds? If you read the values stored in the memory when logging by CPS, there is also the CPM reading every minute, and it is equal to the sum of all the CPS values during 60 seconds. Therefore, by logging every second the CPS you have both values, the CPM and the CPS detail.
That seems to be the way it is working. Do an easy test: from the counter being at stable count rate at background, put a high(er)-count source close to it. At the next second it will have the higher CPS count, while it takes exactly 1 min to settle to the high CPM count.
But why would you store mostly zeros in CPS, only to need an extra step and integrate them for a more meaningful CPM value?
For a complete picture of the time course - and I discuss it in the manual - you do need a sample every second for CPS, and every 60 sec for CPM. Oversampling may bring other issues, see manual.
Of course, you could also do CPM every second, and derive the CPS from it!
The GLsimple500 has a 1 sec default cycle time to get the complete CPS picture, with the possible saturation of the CPM reading in mind. If that were to happen, then CPS and CPM would no longer be in agreement!
You can easily change this cycle: Open the program file in an editor and look for the section labeled Customization. Modify 'my_cycletime' to your liking, and store the file. Caution on Windows: some editors change the line ending, which Python may not like!
|
| ullix |
Posted - 07/16/2018 : 23:39:58
quote:
Okay Python 2.7.2. seems to work! But when i double click the Python File(s), a command line windows pops up for a split second and then nothing happens. Should i have some knowledge in Python language to run this?
This looks like a configuration issue of Windows.
However, I suggest anyway to start GeigerLog with this command from a command shell (assuming drive C):
python c:/path/to/geigerlog
if that doesn't work, then Python may also not be on your path; start then with:
c:/path/to/python c:/path/to/geigerlog
See also the last chapters of the full GeigerLog manual https://sourceforge.net/projects/geigerlog/files/GeigerLog-Manual-v0.9.07.pdf/download While not specific to the GLsimple500 it covers the relevant questions. |
| ikerrg |
Posted - 07/16/2018 : 13:26:06
quote:
You'll also notice that with CPS at background count rates, you can't derive a lot from the Poisson curve. This is why I strongly recommend to only use CPM in both logging directly with GeigerLog or storing to the internal History; see my Potty Training for more detailed explanation.
I think I understand the Poisson thing between CPS and CPM, but I do not understand the need to log every minute instead of every second yet. Isn't the CPM calculated by continuously adding the CPS in a window of 60 seconds? If you read the values stored in the memory when logging by CPS, there is also the CPM reading every minute, and it is equal to the sum of all the CPS values during 60 seconds. Therefore, by logging every second the CPS you have both values, the CPM and the CPS detail.
2018-07-08 10:36,Every Second,43,1,0,1,0,1,0,1,1,0,1,0,0,3,0,1,2,0,2,0,1,0,0,2,3,2,0,1,1,1,1,0,1,1,1,1,0,0,2,0,1,2,0,0,1,0,1,1,1,0,0,0,0,1,0,1,1,0,0,1,0,
2018-07-08 10:37,Every Second,42,0,1,1,3,2,0,0,0,0,1,2,1,2,1,2,0,0,1,1,1,0,1,0,1,0,1,0,1,0,1,1,0,0,0,0,1,0,0,1,0,0,2,0,1,1,1,0,1,0,0,0,1,0,0,2,2,1,2,0,1,
What am I missing?
|
| Scutti |
Posted - 07/16/2018 : 10:35:07
Okay Python 2.7.2. seems to work! But when i double click the Python File(s), a command line windows pops up for a split second and then nothing happens. Should i have some knowledge in Python language to run this? |
| ullix |
Posted - 07/14/2018 : 02:28:53
Good, a fertilizer effect can clearly be seen! But while "Blaukorn" has a reputation on being rough on plants when overdosing, it is not necessarily high in Kalium, and despite the same name the Kalium concentrations in different Blaukorn products vary from low to very low. 
The highest K concentrations available are in KCl and K2CO3 (both e.g. on Amazon). I tested the two side-by-side and found no statistical difference.
Since 90% of the decay of K40 results in beta, the sensitivity of your counter/tube to beta is important, and I don't know how the GMC-600 with its SBT11 behaves. As it supposedly can detect alpha, it should have enough of an opening to detect beta witout removing the backplate. Try it out.
I am certain that Windows XP can run at least a Python2 version. This is enough to run 'geigerlog_simple_500plus' ( https://sourceforge.net/projects/geigerlog/files/geigerlog_simple_500plus-v0.1.zip/download ), which creates a log file that can be imported or copied into Excel for graphing and analysis.
Suggestion: pick a spot in your home somewhere on the upper(!) floor, at eye level (because floor tiles may have some activity), easily accessible, and where the counter can be left alone for at least 24h, connected to a computer. Run at least 24h in CPM mode (Don't use CPS, see Potty Training).
Then try other spots, like basement (Radon perhaps?), garage, garden. Granite, due to the Uranium decay chain, should also give a good signal, and I believe you have a little bit of that in Tirol. I don't expect higher counts than with fertilizer; be patient with a recording. See discussion of statistics in Potty Training.
But again, as long as you have not calibrated your counter against the official ones, you can't say that you have more or less activity! You could well have less, you just don't know!
|
| ullix |
Posted - 07/14/2018 : 00:49:00
@mib404: I guess I see what you mean, here the select period from 14:41 to 14:58
Image Insert:
60446 bytes
The black line across the right picture seems to separate two different regions with 57 and 44 CPM, resp..Though I'd caution to draw too firm conclusions, since the data are very limited, and such random behavior is not statistically impossible. Keep observing over a longer time.
One thing to at least test for is a potential light sensitivity of the tube, which I had observed once for a M4011, see post here: http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4540 I think your counter is also a GMC-600 with an SBT11 tube? The Mica (?) window is at least light transparent, so a light effect cannot be excluded a priori.
You'll also notice that with CPS at background count rates, you can't derive a lot from the Poisson curve. This is why I strongly recommend to only use CPM in both logging directly with GeigerLog or storing to the internal History; see my Potty Training for more detailed explanation.
And you won't do any harm even with much higher activities by using CPM. I would use CPS only for specific purposes, like following the decay of a radioactive substance with a short half life (<~ 1min). This will be a very rare occasion among the GMC counter users. |
| Scutti |
Posted - 07/13/2018 : 13:19:57
Hahaa, well for all the effort you did, i owe you more than one beer! :)
By the way, i tried your program, i want doing this stuff by myself but i am too newbish and windows xp is way too old for this python version.. (yes xp, shame on me).
I did some short time tests. At least I want be sure if the device is reacting at all and i think it does:
Here's the result of a 10 min scan with the strongest fertilizer i found. "Blaukorn".(Had a plastic bag covering the device):
Image Insert:
20148 bytes
And without the fertilizer:
Image Insert:
21834 bytes
I did the same test with a 5 min intervall, with the same results.
Also i did a view 15 min scans in another location and this was the avg result (0,13-0,14uSv/h):
Image Insert:
21041 bytes
So for now i assume i'm living in an environment, where the background radiation is a little bit higher than the official results.
I'll try to find one of these official stations and see what's the result!
|
| ullix |
Posted - 07/13/2018 : 03:13:27
Re Adjustments:
I do strongly advise against any tuning of the counter to the background for severa reasons.
You measured an average background of 50. But what you ignored is the tube's/counter's own background, i.e. all the counts which happen e.g. to some disturbance that has nothing to do with counts, like electrical effects.
The M4011 tube is specified by GQ as having quote:
Instrument Background: < 0,2 pulses/s
For the SBT11A I found here h**p://www.sovtube.com/x-ray-and-geiger-tubes/610-sbt-11.html quote:
Own Background (Pulses/s) 0,6
So the latter has somewhere from 0 to CPM=36 as background. Which number in this range do you want to subtract? Your measurement thus ranges from 50 minus 0...36 = 50... 14 CPM, or from 0.05 ... 0.17 µSv/h. That surely covers the whole range of the official measurements!
Then you don't know if and how the official stations account for their background. They might or might not do it. You would have to put your counter next to theirs and then compare numbers.
In particular, since you don't know whether your home has a higher background than the official site because of the composition of the stones used in construction, or any Radon escaping from the ground, your own number might be correcter than the official one!
So, don't bother, and just keep in mind that the background value may or may not be proper! But your result is in the ballpark of the official values anyway. |
| ullix |
Posted - 07/13/2018 : 02:47:33
So, here are some news on your last data (tell me again: who owes whom a beer, when I visit you in your new home on the parking lot? Though, admittedly, for that panoramic view I might consider living there  )
https://www.google.de/maps/@46.4127657,11.2436209,3a,60y,285.71h,112.81t/data=!3m6!1e1!3m4!1sLyjeBxnxy7pZade8G0fRrA!2e0!7i13312!8i6656
In short, it doesn't look good, but there is also not enough statistics to say there is a problem. It might be a real problem with the counter/ the tube but might be merely a thing of statistical uncertainty.
Image Insert:
86446 bytes
You see in the time course the 2 horizontal dashed lines? (Coming up when Avg is selected) These represent the upper and lower 2-sigma points, between which you find 95% of all data (while strictly applicable only to Normal distributions, see Potty Training why this is ok here). There are quite a few data points above and below these lines.
A look at the Poisson curve confirms that there are too many of them. Look at the blue columns above the red line at the bottom part of the Poisson curve. At the same time there are counts missing at the top of the curve. r² is reasonable, but average clearly different from variance. However, overall, not enough evidence to say it is wrong. Yesterday's was worse.
To convey some sense on the looks of Poisson distributions, I assembled a Sergio Leone sequence, shown next:
Image Insert:
69851 bytes
The Good is a genuine background recording with a GMC-300E+ - it doesn't get much better than that. The Bad is your GMC-600 background recording from yesterday, and the Ugly is intentionally made ugly by putting too much capacitive load on the tube on an experimental setting. Take your pick.
|
| ullix |
Posted - 07/13/2018 : 00:56:44
@mib404: what do you mean with "way low"?
I see a history download done with GeigerLog, so you will have also seen the result displayed.
There seems to be some background, some period with the counter switched off, and some playing with a 'hotter' source, giving up to about 3000CPM.
Too much variation for any firm conclusion, but what I have seen for background and hotter periods all looked ok; what is your concern or problem?
|
| Scutti |
Posted - 07/12/2018 : 21:51:46
Okay, thank you very much! |
| EmfDev |
Posted - 07/12/2018 : 13:45:03
As for the Swivel Display bug, you can contact the customer support to get a firmware update.
support@gqelectronicsllc.com |
| EmfDev |
Posted - 07/12/2018 : 11:13:44
Looks like your tube is a little bit high, that is normal for this kind of tube that's why there is calibration settings.
You can try to change the calibration 1, 2, and 3 CPM from 300,3000,30000 to 360,3600,36000 respectively.
Then check the readings again. These calibration values assume that
your official reading 0.14 is correct. |
| Scutti |
Posted - 07/12/2018 : 10:51:22
Okay, the 20 hour avg results from today are quite the same as yesterday:
AVG 0,17uSv/h - 51,10CPM - 61.374 Counts
These are the official ones:
Image Insert:
49788 bytes
Maybe should i mention, that i live in a house that was made with stones? I'll try with shorter misure intervalls (hourly) and different environment) |
| EmfDev |
Posted - 07/12/2018 : 10:03:28
Keep watching the average. Might need a little bit more time. What is the average in the "official data"? |
| Scutti |
Posted - 07/12/2018 : 05:17:16
PS: from today 1am till 6pm nobody touched (and will touch) the device. May i ask you if you re-do the Histogram-Poisson Graphic by using the data from today (1am till 6pm)? Thank you in advance!! |
| Scutti |
Posted - 07/12/2018 : 04:23:25
Oh my god thank you so much for the time and effort!!
Haha well..it's a nice neighborhood, isn't it? You are invited! But don't forget to bring some beer (or a Piece of CS137 sample, that would be great) :)
I can assure you, nobody touched the device at least from midnight till 7am and from 8am till 6pm. Same Story for today! Today the only difference is the room, where it is located.
Sorry for my poor english, and i'm not sure if i understood everything. We can PM in German if you want, as it is my native language. Your help and knowledge is much appreciate.
Official values::
h**p://umwelt.provinz.bz.it/strahlung/radioaktivitaet-suedtirol-aktuelle-werte.asp
My town is located between the Blue and the Orange signed town's.
Yesterday i did a 20 hours measurement (without moving it, i only touched it once in the morning to see if everything is still working.
The result is in the image below. The avarage is slightly higher in compare to the official data.
Image Insert:
77388 bytes |
| ullix |
Posted - 07/12/2018 : 01:52:03
Fluctuation is normal for radioactive decay measured by a Geiger counter, and you can actually well determine what the degree of this fluctuation is and MUST be, because it follows a Poisson distribution. Details in my "Potty Training" article on my SourceForge project page https://sourceforge.net/projects/geigerlog/ (Statistics chapter)
I took Scutti's data and read them into my GeigerLog software (also on SourceForge) and analyzed them. There are 2 major outliers, which I removed from the data set (they may be from electrical interference or else, but are clearly not real data). The result is shown in the picture:
Image Insert:
95900 bytes
The right hand side shows the time course, and nothing strange can be seen. The average of CPM=48 translates into ~0.16µSv/h, which is in agreement with official, state-run Austrian and Swiss stations nearby (I don't have a link to Italian stations; I'd appreciate if anyone could provide those).
GeigerLog also allows to create a histogram of the data and compare it with a Poisson distribution, left side.
You can easily see: the red line is NOT a good fit to the data, r² is poor, and the variance is almost twice the average, while on a true Poisson distribution the two must be the same. This result suggests that the counter is NOT working correctly!
However, such a faulty recording could also be the result when something had been changed during the recording, like a relocation to a site even with barely noticeable different counts rates. If that had been the case, please repeat the experiment and make sure that the counter is not touched during the recording!
The power of a Poisson test for quality control of the data cannot be emphasized enough!
By the way: have you realized what precision your are giving with the lat/lon numbers? When you combine Google map and Google Street View, you can see amazing things. Should I be using the upper or lower doorbell, when I visit you?
|
| Scutti |
Posted - 07/11/2018 : 21:59:00
Mine too has this Bug.. it behavs exactly you were describing it (apart the buzz Sound). Also i think mine was a returned Unit. The plastic film on the Display doesn't look original to me...
I left the unit on for two days in a row now. Last night the max misured cpm was around 100. But yes, the readings are not stable. They go from +-25cpm up to 55-60 in minutes and back. Are this bounces normal? You can see the actual misurements (and bounces) by clicking my History data above. |
| EmfDev |
Posted - 07/11/2018 : 10:34:51
Looks like the sudden change of CPM is the tube noise. Some SBT-11 tubes needs longer time to become stable.
You should keep the unit and see if the tube can get stable. |
|
|
