Mesures automatisées sur compteur GMC-300E

Dimanche 10 June 2018

Bonjour,

Ce site openradiation.org est bien sympathique et il me donne l'occasion de ressortir un compteur Geiger qui doit avoir 5ans : GMC-300E
Ce compteur Geiger est alimenté par une prise USB, il fonctionne ! même si la batterie 6F22-9V doit maintenant être hors service.
Cette prise USB a l'avantage de pouvoir communiquer avec un PC par le protocole série à la vitesse 57600baud. Je mets ci-dessous mon code source et un exemple de mesures.

Ma principale question porte sur la transformation des CPM en µSv/h.
Est-ce que c'est une simple règle de proportionnalité ? Comment trouver ce coefficient qui dépend du tube ? et peut-être aussi de sa tension aux bornes ?
Doit-on prendre en compte un certain temps de latence pour changer cette règle de proportionnalité en k*CPM / (1 - dt*CPM) que j'ai vue parfois appliquée ?
Comment peut-on vérifier que ce compteur fait des mesures valides ?

Ces données, une fois localisée, ont-elles leur place sur la carte openradiation ?
De mémoire les tests effectués il y a quelques années semblaient montrer que le nombre CPM envoyé par l'appareil consiste à mesurer toutes les secondes le nombre de coups du compteur (dans un tableau avec 60 cases), et renvoie la somme sur la minute passée de ces 60 coups. Il est aussi possible de récupérer seconde après seconde les CPS du tube, mais cela demande plus de manipulations.

Quelle précision vise les mesures de openradiation ?
J'imagine éventuellement me promener en vélo (à 15km/h environ) dans les environs avec compteur Geiger, balise gps et portable dans la sacoche.
Une mesure par minute signifie en fait une moyenne sur les 250m parcourus.

Bien cordialement à tous.

F.

Pour information voila donc le programme Python3 mis dans un fichier gmc-300.py que j'utilise sur une machine Linux-Ubuntu pour récupérer les mesures à mon domicile.

import serial, time

ser = serial.Serial("/dev/ttyUSB0", 57600)
ser.write (("<<GETVER>>"+chr(0)).encode(encoding='utf-8'))
time.sleep(1)
print ((str(ser.read_all ()))[2:-1])

while True :
ser.write (("<<GETCPM>>"+chr(0)).encode(encoding='utf-8'))
time.sleep(1)
res = ser.read_all ()
if len (res) == 2 :
print (time.ctime() + " , " + str(res[0]*256+res[1]) + "CPM")
else :
print (time.ctime() + " , ERROR")
time.sleep(59)

J'obtiens alors ces lignes de mesures :

myf@Portable:~/Atelier/GeigerMuller$ python3 gmc-300.py
GMC-300Re 3.01
Sun Jun 10 15:37:44 2018 , 20CPM
Sun Jun 10 15:38:44 2018 , 27CPM
Sun Jun 10 15:39:44 2018 , 36CPM
Sun Jun 10 15:40:44 2018 , 20CPM
Sun Jun 10 15:41:44 2018 , 25CPM
Sun Jun 10 15:42:44 2018 , 26CPM
Sun Jun 10 15:43:44 2018 , 16CPM
Sun Jun 10 15:44:44 2018 , 19CPM
Sun Jun 10 15:45:44 2018 , 23CPM
Sun Jun 10 15:46:44 2018 , 21CPM
Sun Jun 10 15:47:44 2018 , 28CPM
Sun Jun 10 15:48:44 2018 , 25CPM
Sun Jun 10 15:49:45 2018 , 20CPM
Sun Jun 10 15:50:45 2018 , 22CPM
Sun Jun 10 15:51:45 2018 , 24CPM
Sun Jun 10 15:52:45 2018 , 23CPM
Sun Jun 10 15:53:45 2018 , 23CPM
Sun Jun 10 15:54:45 2018 , 14CPM
Sun Jun 10 15:55:45 2018 , 26CPM
Sun Jun 10 15:56:45 2018 , 26CPM
Sun Jun 10 15:57:45 2018 , 26CPM
Sun Jun 10 15:58:45 2018 , 23CPM
Sun Jun 10 15:59:45 2018 , 33CPM
Sun Jun 10 16:00:45 2018 , 22CPM
Sun Jun 10 16:01:45 2018 , 23CPM
Sun Jun 10 16:02:45 2018 , 30CPM
Sun Jun 10 16:03:45 2018 , 22CPM
Sun Jun 10 16:04:45 2018 , 35CPM
Sun Jun 10 16:05:45 2018 , 25CPM
Sun Jun 10 16:06:45 2018 , 21CPM

Niveau 2

Réponses

Niveau 2
Dimanche 10 June 2018 - 16:27

De retour,

...pour remarquer que l'indentation du code Python n'a pas été conservé par la mise en page du site. L'intérieur de la boucle while: et le if:...else: doivent bien être indentés.

Niveau 3
Jeudi 02 August 2018 - 16:27

Salut,
je me permets de t'orienter sur la discussion que j'ai ouverte l'année dernière pile sur le même sujet :
https://www.openradiation.org/fr/forum/facteur-de-conversion-du-tube-sbm-20
Ce n'est pas une conversion linéaire, mais (de mon interprétation), une formule des coefficients partiels d'atténuation. A confirmer...
Cependant, j'ai pointé plusieurs anomalies dans le calcul du projet d'OpenRadiation, notamment une erreur concernant le comptage net et la non-prise en compte du temps mort du tube.

Donc, en gros, il est difficile d'avoir une consistance entre les mesures de différents appareils avec OpenRadiation.
Une méthode qui serait beaucoup plus fiable, vu que beaucoup de monde utilise le SBM-20 ou équivalent, serait de ne garder que les CPM de bruit de fond sur mesure assez longue (au moins plusieurs minutes, pour se retrouver avec assez d'assurance au milieu de la gaussienne).
Si le sujet et l'implémentation t'intéressent, je me permets également de t'orienter vers mon article sur un forum, qui explique en détails tout ça, avec les intervalles de confiance et le fait qu'un compteur te sort n'importe quoi sur les mesures courtes ;)
http://www.le-projet-olduvai.com/t10467-application-geiger-bot-compteur-geiger-mesure-de-sources-de-bruit-de-fond-et-autres-stats

et notamment à la page 2, où l'expérience avec les noix du Brésil produit des mesures assez inattendues et plutôt complexes à interpréter.
http://www.le-projet-olduvai.com/t10467p25-application-geiger-bot-compteur-geiger-mesure-de-sources-de-bruit-de-fond-et-autres-stats#175642

"Comment peut-on vérifier que ce compteur fait des mesures valides ? "
Si tu n'as pas de source d'étalonnage, amha il faudrait plutôt se baser sur le bruit de fond pour distinguer une anomalie... à prise de mesure strictement identique (hauteur, conditions météo, etc.)

"Quelle précision vise les mesures de openradiation ?
J'imagine éventuellement me promener en vélo (à 15km/h environ) dans les environs avec compteur Geiger, balise gps et portable dans la sacoche. "

Théoriquement, il faudrait réaliser toutes les mesures à 1m du sol dans un environnement "stable", c.a.d hors courant d'airs & co. Sinon tu auras un paquet de fluctuations et de bruit implémentés dans tes mesures.