| Author |
 Topic  |
|
|
n8xyn
USA
66 Posts |
 Posted - 05/23/2018 : 14:48:24
|
| I finally got a piece of hot ore, 10100 CPM 6.7 msv/h. I tried to get the low sensitivity tube to read something but not sure if it saw any of it because the other tube of course stayed involved. At what level would the low sensitivity come into use? |
Jim Whitaker |
|
| Reply #1
ZLM
1261 Posts |
Posted - 05/24/2018 : 10:51:16
|
Both tubes alway be involved in the real time reading. The firmware algorithm takes care the calculation.
If you want to know the low sensitivity tube count, you can try to use internal testing command : <GETCPMH>> |
 |
|
| Reply #2
ullix
Germany
1171 Posts |
Posted - 05/25/2018 : 00:12:00
|
Oh, wonderful, yet another command not found in the "open" document, downloadable under GMC-500+.
So, it is <GETCPMH>> with an 'H' like high for the low sensitivity tube. And what is the command for the high sensitivity tube? And what about CPS commands? |
|
|
| Reply #3
EmfDev
2250 Posts |
Posted - 05/25/2018 : 08:42:12
|
Those commands are only for testing and not supposed to be used by public, hence, not in the document.
<GETCPML>> for the high sensitivity tube. And there's no CPS for individual tubes. |
|
|
| Reply #4
ullix
Germany
1171 Posts |
Posted - 05/26/2018 : 04:09:42
|
quote:
I finally got a piece of hot ore, 10100 CPM 6.7 msv/h. I tried to get the low sensitivity tube to read something but not sure if it saw any of it because the other tube of course stayed involved. At what level would the low sensitivity come into use?
Jim, something seems wrong with your numbers:
At 10100 CPM and a calibration factor of 0.0065 µSv/h/CPM I arrive at 10100 * 0.0065 = 65.65 µSv/h
That is MICRO Sievert per hour, you gave 6.7 MILLI Sievert/h, which is 6700 µSv/h. That can't be right; could you please check?
|
|
|
| Reply #5
jjm386
USA
6 Posts |
Posted - 05/26/2018 : 16:19:41
|
Similar to you, I've encountered issues at high doses on the GMC-500+. Unfortunately, I was the 'calibrated' source after receiving radio-iodine treatment and would saturate it when I got within a meter or two. Even though it is advertised as having two tubes that go up to ~ 4 REM/hr (which is why I got this unit), the actual limit seems to be ~10 mRem/hr because the blending of the calibration curves does not seem to work. I suspect the software is using the 3rd calibration point for both tubes which is clearly erroneous if that's the case. The blending then does some weird thing I don't understand based on this.
The default for the third calibration point (labeled as tube #2), came as 25 CPM/9.75 uSv/hr. At high doses the unit would cause it to sometimes spontaneously switch and eventually rail to a 0 mR/h reading. I got it to work at higher doses, with what seemed to be about the value I'd expect, by setting cal point #3 to 20000 CPM and 13000 uSv/hr. However, this was shaky and would cause issues at intermediate values.
You might be able to calibrate it to work in any range, though I think it really requires a firmware update to adjust how it is handling the blending.
Does anyone know if there are any planned updates that fix this?
Thanks,
Jim
quote:
Originally posted by n8xyn
I finally got a piece of hot ore, 10100 CPM 6.7 msv/h. I tried to get the low sensitivity tube to read something but not sure if it saw any of it because the other tube of course stayed involved. At what level would the low sensitivity come into use?
|
|
|
| Reply #6
n8xyn
USA
66 Posts |
Posted - 05/26/2018 : 17:59:28
|
| I'm sure I was wrong about the uSv/h rate. Thanks for the terminal command I'mm give it a try. I'm a newbie and just interested in how the two tubes operate. Looks to me like that by the time the high level tube comes into any real value you might be dead? |
Jim Whitaker |
|
|
| Reply #7
ullix
Germany
1171 Posts |
Posted - 05/27/2018 : 01:39:02
|
With jjm386's comments the mystery of the second tube becomes even more mysterious.
But nothing that we can't unravel with some software and an experiment. I have just uploaded 'geigerlog_simple_500plus-v0.1' to https://sourceforge.net/projects/geigerlog/files/
As the name says, it is a simple program. It is run from the command-line, running on both Python2 and Python3, and is used to measure both tubes of the GMC-500plus, as combined and separate count sources. The result is a log file like this:
# DateTime, CPS, CPM, CPM1st, CPM2nd
2018-05-25 10:52:37, 14, 601, 530, 71
It shows the standard CPS and CPM, as well as CPM from 1st and 2nd tube, resp..
You may have to set USB-Port and Baudrate in the code; a Quickstart help file tells you howto setup and run it.
The data can be handled and plotted in any spreadsheet program, but I have also included a generic plotting program (needing Python3) in the package. This can be configured to create graphs like this:
Image Insert:
146194 bytes
So far it looks like a GMC-3xx counter will have CPM=CPM1st=CPM2nd, while a GMC-500 (non-plus, i.e. no 2nd tube) will have CPM=CPM1st, and CPM2nd always zero.
@n6xyn:
Now we need the experiment.
If you can, try to run your counter in the 3x-design: measure at close to CPM 10000, 3000, 1000, 300, 100, 30 (the factor of ~3 means approx equal distance on a log scale), and note the reported dose rate in µSv/h for each setting.
Something beyond 10000 would be really helpful, like 30000, 100000, ...
This will give us some clues on the algorithm used in the GMc-500 series.
|
|
|
| Reply #8
EmfDev
2250 Posts |
Posted - 05/29/2018 : 10:04:46
|
| @jjm386, Thanks for the input, we need more data to support your findings. |
|
|
| Reply #9
jjm386
USA
6 Posts |
Posted - 06/02/2018 : 17:59:28
|
I've attached some of the relevant data for the period when I tried to measure the radiation at different ranges from 129 mCi of I-131. The GQ 500+ would freak out whenever I got closer than about ~3ft which corresponded to > 10 mRem/hr. The values between 10-20 mRem/hr were suspect and everything above that caused the output to rail to 0 mRem/hr which you can see on the second plot.
Unfortunately I don't have precise data showing the known dose versus output for > 10 mRem/hr. However,you can see from the output that I was never able to measure any of the higher radiation levels even though it was exposed to 500-1000 mRem/hr and the unit is specified to go up to almost 5000 mRem/hr.
Hope this helps. Although I hope to never be in a position to measure the levels again, it would still be great to get a fix so the unit can operate properly. In some cases is provides artificially low measurements by orders of magnitude which can be deceiving.
Thanks,
J
quote:
Originally posted by EmfDev
@jjm386, Thanks for the input, we need more data to support your findings.
Download Attachment: 
54549
Download Attachment:
87368 |
|
|
| Reply #10
ullix
Germany
1171 Posts |
Posted - 06/03/2018 : 22:20:08
|
Both attachments cannot be downloaded; I get a 404 error
|
Edited by - EmfDev on 06/04/2018 10:45:25 |
|
|
| Reply #11
EmfDev
2250 Posts |
Posted - 06/04/2018 : 10:46:01
|
| Did you check if it had 0 cpm? because it could just be calibration issues. |
Edited by - EmfDev on 06/04/2018 11:00:25 |
|
|
| Reply #12
ZLM
1261 Posts |
Posted - 06/04/2018 : 10:56:59
|
| Please try to upload the image files again, there was a software bug and now be fixed. |
|
|
| Reply #13
jjm386
USA
6 Posts |
Posted - 06/04/2018 : 17:11:58
|
I've attached the image files again.
The counts all went to 0 CPM. The sound clicks and LED light also stopped flashing.
J
Image Insert:
54549 bytes
Image Insert:
87368 bytes
quote:
Originally posted by ZLM
Please try to upload the image files again, there was a software bug and now be fixed.
|
|
|
| Reply #14
ullix
Germany
1171 Posts |
Posted - 06/06/2018 : 11:49:46
|
The GMC Geiger counters and Software have different counting problems, e.g. in CPM mode see my post "Counting Max is more limited than thought"
http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4613
Using the DV Viewer there is an additional problem posted as "Severe counting bug in GQ GMC Data Viewer"
http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4615
The point in both cases is that you see the problem only when you note the counts, either CPM or CPS. Using mRem/h or µSv/h just disguises the problem.
Do you know what "calibration" factor is used in your counter to convert from counts to the units you reported? That might help to figure out the issue.
Also, I suggest to ignore the mR or mREM or µSv or whatever units the counter is offering in future measurements, and use pure counts only. You can always calculate those units after the runs with a simple multiplication.
Specifically, in your case I would recommend to measure CPS, not CPM, as there seems to be a bit more leeway towards high counts. I estimated your low counts of around 1 mRem/hr should amount to CPS=25; I think everything beyond CPS>10 justifies this unit for the low end, since you will go much higher anyway.
I-131 decays in several pathways, but >95% of the times a decay emits both beta and gamma. While beta will not pass your tissue, the gammas of 0.4 and 0.6 MeV have quite some penetration power, as you noticed.
I would really love to see what my 'geigerlog_simple_500plus-v0.1' program says about the counts of the two tubes?
|
|
|
| Reply #15
jjm386
USA
6 Posts |
Posted - 06/16/2018 : 18:31:47
|
I downloaded the raw data using the GQ app and then converted from CPM to mR/hr by multiplying by 6.5E-4. The scale factor was derived by comparing the values on the display and assuming it was linear throughout the range. This probably isn't accurate when the 2nd tube kicks in, though the results seem to be bogus at these higher dose rates anyway. For example, when I was hot, the output would drop to 0 CPM if I held the unit in my hand. Things have now decayed so I can't really test anything at the higher levels.
FYI - I was using the default 3 point calibration which I believe is:
Calibration Point 1: 60 CPM = 0.39 µSv/h (0.0065 µSv/h / CPM)
Calibration Point 2: 10000 CPM = 65.00 µSv/h (0.0065 µSv/h / CPM)
Calibration Point 3: 25 CPM = 9.75 µSv/h (0.3900 µSv/h / CPM)
J
quote:
Originally posted by ullix
The GMC Geiger counters and Software have different counting problems, e.g. in CPM mode see my post "Counting Max is more limited than thought"
http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4613
Using the DV Viewer there is an additional problem posted as "Severe counting bug in GQ GMC Data Viewer"
http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4615
The point in both cases is that you see the problem only when you note the counts, either CPM or CPS. Using mRem/h or µSv/h just disguises the problem.
Do you know what "calibration" factor is used in your counter to convert from counts to the units you reported? That might help to figure out the issue.
Also, I suggest to ignore the mR or mREM or µSv or whatever units the counter is offering in future measurements, and use pure counts only. You can always calculate those units after the runs with a simple multiplication.
Specifically, in your case I would recommend to measure CPS, not CPM, as there seems to be a bit more leeway towards high counts. I estimated your low counts of around 1 mRem/hr should amount to CPS=25; I think everything beyond CPS>10 justifies this unit for the low end, since you will go much higher anyway.
I-131 decays in several pathways, but >95% of the times a decay emits both beta and gamma. While beta will not pass your tissue, the gammas of 0.4 and 0.6 MeV have quite some penetration power, as you noticed.
I would really love to see what my 'geigerlog_simple_500plus-v0.1' program says about the counts of the two tubes?
|
|
|
| Reply #16
ullix
Germany
1171 Posts |
Posted - 06/19/2018 : 03:55:14
|
Too bad we can't unravel the two tubes ...
If I understood right, then the highest reading shown in the second figure at distance ~3ft was 14.4 mRem/hr, which, divided by 0.00065, gives CPM=22153. Going closer to 2ft - your data points marked "Unit @ 2ft" - makes the counts disappear completely (these data points were all numerical zeros?).
Going from 3ft to 2 ft towards a point source should increase the count rate by (3/2)^2 = ~2.3 fold to CPM=50000. Given the uncertainties about source and distances, this might well have been >65535, which suggest a numeric overflow in the counter.
If it were a 300E counter, it should have now given the overflow counts, i.e. the true count rate modulo 65536 as shown here http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4613. However, it is unknown if the 500 counter behaves the same way!
But even with an overflow on the first tube, the second tube should have kicked in and reported counts. Which it didn't.
My conclusion: either the second tube is dead, or the firmware has a huge bug!
Try to test the second tube for count rate. If you don't want to use my 'geigerlog_simple_500plus-v0.1' the use the GQ with the commands described in Reply #1 and #3 of this thread (<GETCPMH>> and <GETCPML>>).
|
|
|
| Reply #17
jjm386
USA
6 Posts |
Posted - 06/23/2018 : 11:57:14
|
I have definitely noticed cases where it looks like there is a counter-overflow based on what you said. However, at higher rates it goes to 0 exactly. The speaker and LED flasher also stop working at high dose rates.
I don't have a way to get to higher dose rates now, but just ran GETCPML and GETCPMH and got 00 41 and 00 02. These seem consistent with the ~65 CPM on the display panel. It looks like the second tube is working at low dose rates at least. I'm not sure what it is doing at higher levels.
J
quote:
Originally posted by ullix
Too bad we can't unravel the two tubes ...
If I understood right, then the highest reading shown in the second figure at distance ~3ft was 14.4 mRem/hr, which, divided by 0.00065, gives CPM=22153. Going closer to 2ft - your data points marked "Unit @ 2ft" - makes the counts disappear completely (these data points were all numerical zeros?).
Going from 3ft to 2 ft towards a point source should increase the count rate by (3/2)^2 = ~2.3 fold to CPM=50000. Given the uncertainties about source and distances, this might well have been >65535, which suggest a numeric overflow in the counter.
If it were a 300E counter, it should have now given the overflow counts, i.e. the true count rate modulo 65536 as shown here http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4613. However, it is unknown if the 500 counter behaves the same way!
But even with an overflow on the first tube, the second tube should have kicked in and reported counts. Which it didn't.
My conclusion: either the second tube is dead, or the firmware has a huge bug!
Try to test the second tube for count rate. If you don't want to use my 'geigerlog_simple_500plus-v0.1' the use the GQ with the commands described in Reply #1 and #3 of this thread (<GETCPMH>> and <GETCPML>>).
|
|
|
| Reply #18
ullix
Germany
1171 Posts |
Posted - 06/25/2018 : 02:02:38
|
It very much looks like what I had discovered using a signal generator, and had reported here:
http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4613.
I used a signal generator with a count rate of equiv CPS=2000, which worked. But:
quote:
The next step up of the pulse generator is 5kHz, and when this was set - irrespective of CPS or CPM mode - the counter would crash and not show anything (see far right edge in picture). The counter could only be set back to normal by cycling power.
So, somewhere between CPS=2000 and 5000 the counter reaches its technical limits, perhaps due to the limiting computing power of the microcontroller. This limit may coincide or come even earlier than the tube limit.
This far right edge mentioned above is shown enlarged here:
Image Insert:
15359 bytes
Once the counter had collapsed, only exact zeros were returned, just as you observed.
So, even assuming the counter crashed at the max of CPS=5000, this is CPM=300000, or 1950 µSv/h. Yet the GMC-500+ specs say it can handle up to 42500 µSv/h or CPM~1 million.
Image Insert:
12292 bytes
@ZLM: you seem to be way off with your specs. Do you have proof that it actually does work as advertised?
@jjm386: You have gotten some might big dose! I don't want want to step in your privacy, but would it be possible for you to provide the dose and isotope(s) of what you actually got? Maybe one could do some back-calculation.
|
|
|
| Reply #19
ZLM
1261 Posts |
Posted - 06/25/2018 : 22:29:12
|
@ullix, thanks for the testing and all information.
Indeed, the unit should not crash no matter what CPS is. This software unstable issue in high CPS will be investigated.
For the 1950 uSv/h question. In fact, the GMC-520+ used two tubes to determine the reading. In such high CPS case, the low sensitivity tube will play an important role. The low sensitivity tube uses conversion rate 0.194.
|
|
|
| Reply #20
ullix
Germany
1171 Posts |
Posted - 06/26/2018 : 00:10:46
|
Wow, GMC-520+ -- Yet another counter variant?
I guess what you named conversion rate is 0.194 µSv/h/CPM ?
So, this 2nd tube is 0.194 / 0.0065 = 30 times less sensitive than the 1st tube M4011 ? |
|
|
| Reply #21
ZLM
1261 Posts |
Posted - 06/26/2018 : 06:40:54
|
Sorry. I mean GMC-500+. The GMC-500+ low sensitivity tube conversion rate is 0.194 uSv/h per CPM. It is about 30 times less than M4011.
Yes. There are other variant models from GMC-500, see:
http://www.gqelectronicsllc.com/support/GMC_Selection_Guide.htm
Bye the way, I would like to put your GergerLog download link on our download page. So that to let more users know it. Please let me know if this is OK. |
|
|
| Reply #22
ullix
Germany
1171 Posts |
Posted - 06/30/2018 : 02:21:57
|
Double-Wow to the new models with Temperature, Pressure and Humidity sensors (though I don't see them listed in the store?). A good move in the right direction, I think. And guess what, GeigerLog will support T, P, H in the next release!
I suppose the new models will use the Bosch BME280 sensor? I experimented with it, it works really well, and I have released software to use such I2C based sensors as I2Cpytools. It is also Open Source, available here: https://sourceforge.net/projects/i2cpytools/
However, GeigerLog is being readied to support the RadMon+ Kit ( https://sites.google.com/site/diygeigercounter/gk-radmon ), which handles a Geiger tube and the BME280 sensor for CPM, T, P, H, though it comes as a kit and needs soldering. So, not for everyone.
What is the meaning of the CO2 (?) sensor with a precision of +/- 150ppm? Good thing is that with this precision you will never be wrong, because CO2 for the last 1000 years has been WELL within that range of this uncertainty. :-/
The change of CO2 is currently about 2.2ppm per YEAR. So, in order to measure something relevant, you need to have a precision better than 1ppm, not 150 times worse at 150ppm! Such a sensor is completely pointless. Something seems wrong.
|
|
|
| Reply #23
ullix
Germany
1171 Posts |
Posted - 06/30/2018 : 02:23:44
|
quote:
Bye the way, I would like to put your GergerLog download link on our download page. So that to let more users know it. Please let me know if this is OK.
OK, of course; GeigerLog is Open Source.
|
|
|
| Reply #24
ZLM
1261 Posts |
Posted - 06/30/2018 : 11:38:09
|
Yes. BME280 installed.
Main improvement are GPS and GPRS.
The CO2 is for generic monitoring for home air quality, not for scientific monitoring.
Sure the 1ppm we can do. It is just the matter of cost. But the 1ppm accuracy sensor may increase the cost about 10 times more. |
|
|
| Reply #25
ullix
Germany
1171 Posts |
Posted - 07/01/2018 : 00:20:37
|
quote:
The CO2 is for generic monitoring for home air quality, not for scientific monitoring.
Even elevated levels of CO2 (carbon dioxide) as they may occur at home or at workplaces/classrooms don't do harm. But CO (carbon monoxide) can kill you. Anybody with a furnace or fireplace at home should be interested in a CO sensor.
|
|
|
| Reply #26
ZLM
1261 Posts |
Posted - 07/01/2018 : 09:02:02
|
That true. But too high CO2 in bedroom will let people feel bad and sick.
Do you have any good CO (carbon monoxide) sensor information?
|
|
|
| Reply #27
jjm386
USA
6 Posts |
Posted - 07/02/2018 : 18:03:54
|
The plots I showed were from 129 mCi of I-131. Hope this helps...
quote:
@jjm386: You have gotten some might big dose! I don't want want to step in your privacy, but would it be possible for you to provide the dose and isotope(s) of what you actually got? Maybe one could do some back-calculation.
|
|
|
| Reply #28
ullix
Germany
1171 Posts |
Posted - 07/03/2018 : 00:09:20
|
quote:
Do you have any good CO (carbon monoxide) sensor information?
Go to Top of Page
Probably not more than what you have. I did a cursory review and what seemed the most promising is found here: https://euro-gasman.com/carbonmonoxide-co-ss-gas-sensor-micro-version-804.html
They have sensors ranging from 0...100ppm up to 0...10000ppm, and claim to also offer I2C ready devices. I have not tested any of them.
Upper level 100 would suffice, as danger limits are roughly 0...10ppm: all ok, 30ppm: begin to become concerned, 100ppm: use the GPRS-feature of the counters to call the fire fighters directly ;-)
|
|
|
| Reply #29
ZLM
1261 Posts |
Posted - 07/05/2018 : 14:15:13
|
| Thank you for your information. I will take a look on this. |
|
|
| Reply #30
EmfDev
2250 Posts |
Posted - 07/11/2018 : 14:10:04
|
For 500+, we tested both tube terminals with a signal generator and tried to go up till the CPM becomes non sense.
Resulted max CPM = 3.9M for each terminal(total of ~7.8M CPM) with a signal of 65KHz from the signal generator.
The GETCPS or Heartbit1 still is not 0.
|
|
|
| Reply #31
ullix
Germany
1171 Posts |
Posted - 07/12/2018 : 02:38:25
|
How exactly are you reporting a value of 3 900 000 as a CPM, which is a 16 bit number, that can hold a max of 65 000?
And what is the value of a 65kHz signal, which gives pulses 15µs apart, when the pulse length of the counter pulses is currently 200µs, perhaps with some tricky optimization 150µs? Even then the pulses will still be 10 times longer?
|
|
|
| Reply #32
EmfDev
2250 Posts |
Posted - 07/12/2018 : 08:51:02
|
It's displayed on the device, the 500+ range is 98kCPM and I think the CPM in this processor is 4 bytes.
This is just to simulate if the hardware counter works and doesn't just die with a pulse of 2KHz. And tested without a tube.
The tube generates counts that are much slower than the hardware can handle. |
Edited by - EmfDev on 07/12/2018 10:45:03 |
|
|
| Reply #33
ullix
Germany
1171 Posts |
Posted - 07/12/2018 : 23:49:14
|
Does this mean that the <GETCPM>> et al commands now return 4 bytes?
|
|
|
| Reply #34
EmfDev
2250 Posts |
Posted - 07/13/2018 : 08:24:49
|
| Just checked still 2 bytes. |
Edited by - EmfDev on 07/13/2018 08:57:37 |
|
|
| |
Topic |
|
Low sensitivity tube in GQ 500+
