| T O P I C R E V I E W |
| ullix |
Posted - 04/29/2017 : 04:15:12
GeigerLog - just renamed for consistency from old name Geiger - has been uploaded to SourceForge: https://sourceforge.net/projects/geigerlog/ as version 0.9.03.
As a major change there is now also a "bundle" available, which brings its own Python environment; no further installation needed. However, current bundle can be used only on Linux.
In addition there is now a GeigerLog-Manual, giving overview, quick intro and details. In particular, the appendices may give insight to some of the problems handling the Geiger counter, in particular the hurdles reading the history from the counter, and the solution used in GeigerLog.
Bundling and Manual have "encouraged" some minor clean-up modifications.
Image Insert:
176568 bytes |
| 9 L A T E S T R E P L I E S (Newest First) |
| ullix |
Posted - 05/08/2017 : 04:11:15
quote:
But showing the history, it shows the date "in the future" (June instead of Mai, Date/Time on the 500 are correct) ..!?
That is probably a consequence of the firmware's storage format, in particular the interplay of the Date&Time tag and the ambivalent use of the value 255 byte.
GeigerLog in version 0.9.03 treats this in a different way, which avoids certain errors of this type. For discussion see Manual, Appendix E, "The 255 value".
I'll discuss the other stuff directly with you. |
| the_mike |
Posted - 05/07/2017 : 10:34:35
Had to do a full batterie-cycle to resolve the problem... No idea what caused this problem...
I could compare yesterdays data; issue:
both show similar CPM, though the 500 has either higher, or lower counts while the 320 keeps a steady measurment.
both show somewhat-similar nSv/h, while the 500 has a higher "normal rate" (140nSv/h instead of the 320's 90nSv/h), and has several peaks to both higher and lower values; the 500 even showed 190nSv/h and 10nSv/h; the 320 keeps closer to local background-radiationlevel of about 95nSv/h
Unfortunatly, I don't have a sample to check with higher readings...
Here the Device-Info:
Selected device: GMC-320
Device Firmware Version: GMC-320Re 4.19
Baudrate read from device: 115200
Baudrate set by program: 115200
Date and Time from device: 2017-05-07 19:32:23
Date and Time from computer: 2017-05-07 20:26:39
Device is slower than computer by 3256 sec
Device Battery Voltage: 4.2 V
Device Temperature: 85.0 DEG C
(only GMC-320 Re.3.01 and later)
Device Gyro data (x,y,z): (5, 2, 65282)
(only GMC-320 Re.3.01 and later)
Device Power State: ON
Device Save Mode: CPM, save every minute
Device Calibration:
Calibration Point 1: 60 CPM = 0.39 uSv/h (0.0065 uSv/h / CPM)
Calibration Point 2: 240 CPM = 1.56 uSv/h (0.0065 uSv/h / CPM)
Calibration Point 3: 1000 CPM = 6.50 uSv/h (0.0065 uSv/h / CPM)
Unfortunatly, for the 500, I can't get the Device-Info; Geigerlog just does "nothing" when connected to the 500; but I can download the history... But showing the history, it shows the date "in the future" (June instead of Mai, Date/Time on the 500 are correct) ..!?
Edit:
...and I just realised I forgot to set the 320 to MEST (verdammte Zeitumstellung, könnte man abschaffen den Quatsch) |
| ullix |
Posted - 05/06/2017 : 23:50:44
I have no idea what "unsynched communication" might be; can't imagine it has to do with GeigerLog. Though I observed an occasional choking of my 300E+ when things went too fast, which made me put some breaks into the code. Such problems were overcome by reconnecting. At the latest, cycling the Geiger counter power should settle it. If this happens again you could start GeigerLog with the debug option ('geigerlog -d') and inspect the geigerlog.proglog file.
There is always a history, although perhaps a short one, which can be downloaded. Alternatively, do logging.
The CPM should be the first thing to differ between units, depending on tube, electronics, case, thickness of case walls, and perhaps other things. It is the µSv/h that should be the same due to the calibration. However, I think it is unknown on what basis this calibration was made. It does depend on the hardware and on the source of radiation, and is not just a point calibration but a line calibration, like seen here for far more expensive Geiger counters: h**p://services.ludlums.com/component/virtuemart/radiation-detector-185-detail?activetab=specifications&Itemid=0
Therefore even dose differences are acceptable, though within limits. An elevated radiation, well above background, would be good for a comparison.
It also would be helpful if you could post the output of GeigerLog menu Device--> Show Device Info for both devices |
| the_mike |
Posted - 05/06/2017 : 12:04:13
Yes, I have a 500 (not a plus) and a 320...
Both have the same tube installed (my STS5 i have here from a raspberry-project remains unused, they are just too big), that's why I keep wondering about the differences in measuring (even the CPM differ)...
Currently, I'm running a second "comparing-test" as for some reason, dataviewer (2.35) couldn't read any data from my 320...
But I gave the 500 a short try with GeigerLog, and the connection worked, but as there was no history to load, i couldn't give it a full try...
(q: i had some issues with the 320 in dataviewer saying "There are some unsynched communication, you may need to reconnect the unit and download again" - does the geigerlog do something on the 320 that may cause this problem?) |
| ullix |
Posted - 05/06/2017 : 02:07:29
Are you saying you already have a 500+ and a 320? Then can't you just try out whether GeigerLog works with both AND gives meaningful readings?
I missed one issue, which I find even more confusing. The calibration of the 320 is (65535CPM)/(328µSv/h) = 200CPM/(µSv/h), while that of the 500+ is 23CPM/(µSv/h), meaning the 500+ is about 10 times LESS sensitive.
I surely would expect a HIGHER sensitivity, the 2 tubes won't necessarily make it 2 fold higher, but surely not lower, and surely not by an order of magnitude. What gives?
Do you have some higher radioactive source available to compare CPM and µSv/h readings of the two devices? Background measurements won't cut it, you need a bit elevated level to be surely above electronic background.
|
| the_mike |
Posted - 05/05/2017 : 07:10:17
well, at least the GMC-500+ uses two tubes...
but you're right, the numbers ... lead to some questions... ;)
comparing the measurements (background-radiation - i set 'em on and let 'em count) from the 500 and the 320, i also found some different results (the 500 measures less, while the 320 is close to the numbers the NAZ is publishing, while the 500 ...make me wish i'd have a rad-source for calibration-purposes as there's something wrong) |
| ullix |
Posted - 05/05/2017 : 03:13:49
Mike, most likely the communication between computer and device will work, but the data interpretation needs adjustments.
Relying on the user guide https://www.gqelectronicsllc.com/GMC-500UserGuide.pdf the 500s have the same USB-2-Serial connection, with the same type of USB-Mini plug (i.e. not the more modern USB-micro as found on Smartphones), and GQ refers to them same communication protocol from Jan-2015 (https://www.gqelectronicsllc.com/download/GQ-RFC1201.txt )
Which, however, can't be quite correct, as they also claim http://www.gqelectronicsllc.com/support/GMC_Selection_Guide.htm to have a 10 fold higher "upper limit detection range".
Image Insert:
15995 bytes
That is strange on several levels, as the old firmware stores the counts in 2-byte words, which don't hold more than 65535 (=2^16 - 1) counts. And if you were taking more bits for storage, the range should increase by binary 2x steps, not by decimal 10x steps! Are they simply rounding the lowest digit to the next 10, such that a reading with GeigerLog of CPM=12 might then actually be CPM=120?
They still state in the manual "Instrument Background < 0,2 pulses/s" or <12 CPM, i.e. the first 10 counts are electronic noise anyway, having nothing to do with radiation. But many users are mapping their counts http://www.gmcmap.com/ and those are mostly below 20 CPM. Would look strange if in the future most are exact 0, 10, 20 CPM.
And why the extension of the upper limit up to 42500 µSv/h? Apart from the just mentioned fact that many users deal with background radiation only (and an occasional air flight) - you don't want to be where such high limits are reached. German radiation laws limit max occupational exposure to 20000 µSv per year - 42500µSv/h is thus almost twenty-thousand times higher! You'd better take a robot to bring your counter to that location!
The upper CPM level of the 500+ is 982980 (see image), or 16383 counts per second (= 2^14 -1). Well, that is the same max CPS as in the current GMc-3xx Geigers. But then, why is the dose range now >10 or even >100fold higher?
But at 16383 CPS the counts on average are only 1sec/16383 = 61 microseconds apart (ignoring Poisson distribution, which brings many even closer). The best Geiger tubes resolve counts 50µsec apart, most need 100µsec and more. In other words, once you reached that radiation level, the tube + electronics couldn't discriminate between counts, and you wouldn't measure any counts at all!
Once you get close to that level - my guess without trying: CPS=8000 - you'll need calibration to account for the missed counts from them coming too close together. From the above table divide µSv/h by CPM and you get the overall calibration. It is given as 0.005 for the 3xx series. Strange, because my GMC300E+ has factory default 0.0065. Which is the exact same value you get for the GMc-500. But for the 500+ you get 0.043. As nothing else is mentioned, I guess it is all linear calibration - which is inadequate for the claimed higher upper limit.
Looks to me like a marketing driven initiative; the 300E+ is still good value for your money.
@ZLM: can you bring light into this confusion? What is now different and hence needs to be adjusted in GeigerLog to also accomodate the 500 series?
|
| the_mike |
Posted - 05/04/2017 : 02:54:20
Hi Ullix,
thanks for the new package... :-)
q: do you know if your log works for the new GMC-500(+), too? |
| flukeguy |
Posted - 05/01/2017 : 06:23:15
Thanks Ullix, learned much from your manual about how the GC operates. Nice work!
--Terry |
|
|
