Il mio GEIGERINO

Ciao a tutti.
Vorrei condividere con voi il mio progetto di contatore Geiger con Arduino, iniziato nell'Ottobre 2016 e, forse, giunto a una versione definitiva con la reintegrazione della misura anche in mR/h per avere misure direttamente confrontabili con contatori classici.

Il progetto era nato in una versione molto semplice, poiché pensavo che bastasse contare gli impulsi e fare la media in un tempo predeterminato, come se ci fosse un integratore RC (resistenza e condensatore). A questo scopo iniziai dichiarando un array composto da tanti elementi quanti erano i secondi, scrivendo a rotazione in tali n elementi e poi facendo la media. In questo modo ottengo la media negli ultimi n secondi.

Mi è stato fatto notare che apparecchi commerciali raffinati calcolano anche l'errore stimato in base alla distribuzione di Poisson. Così, con l'aiuto di qualche persona esperta che mi ha spiegato molto pazientemente come svolgere il calcolo statistico, ho aggiunto anche quello.

Tutto il funzionamento è spiegato nel manuale, presente in github con tutto il software:
https://github.com/Gatware/Geigerino/tree/...O_1.9aUX_031217


14/2/2019
N.B.: Sarebbe meglio collegare il partitore R1-R2 non direttamente al pin A1, ma tra la resistenza e il LED. In questo modo l'uscita del 328 non dovrebbe caricare o scaricare brutalmente il condensatore da 100nF ogni volta che accende o spegne il primo LED verde. La stessa cosa sarebbe opportuna sul pin A2 se anche lì venisse messo un condensatore.

Edited by Datman - 18/9/2022, 09:32

4. 110 dovrebbe essere il fondo proprio della sonda, ma è, evidentemente, sbagliato
Mi piacerebbe trovare una tabella comparativa fra le varie sonde, con unità di misura omogenee e coerenti...

Edited by Datman - 20/5/2022, 11:18

So bene che le sonde Geiger non sono strumenti di precisione e che rispondono in maniera molto diversa alle varie particelle e alle varie lunghezze d'onda dei raggi gamma, ma io ho costruito un apparecchio sperimentale, non uno strumento di misura da mettere in commercio! Avendo delle indicazioni in uSv/h e in mR/h posso provare a fare un confronto con apparecchi commerciali e campioni.

Nel Geigerino, dove ho usato decimali e ho fatto calcoli precisi è stato per evitare, poi, errori macroscopici, oppure per far vedere che il valore sta cambiando, mentre con solo l'intero sembrerebbe fisso.

>> Non fare mai misure a meno di 1 metro dalle superfici degli oggetti
Uhm... Questo sarebbe plausibile se avessi da misurare qualcosa di più "sostanzioso" delle maioliche del bagno, del bidet e del davanzale di mia suocera...

Mi è dispiaciuto che ti sei impegnato tanto per dirmi parecchie cose che avevo già considerato

Comunque, se ci capiterà di incontrarci, mi farà piacere avere un tuo parere dopo averlo provato di persona.

Vedi... L'ho fatto per fare esperienza, ma i miei interessi sono numerosi e il tempo non mi basta mai. Con quasi cinquant'anni, alla pensione ne mancano ancora un bel po'...

Sul collettore c'è un TP che si chiama TEST F IN...
Sì, avevo provato, ma non ricordo bene... Aspetta...

Edited by Datman - 7/12/2017, 10:51

Grrr... Il frequenzimetro Victor è impazzito!!!
Facciamo con il frequenzimetro dell'oscilloscopio:
1000Hz: 60000cpm
2000Hz:120000cpm
4000Hz:240000cpm
5000Hz:300000cpm

Ho fatto qualche approssimazione, ad esempio adesso leggo 5,002kHz sull'oscilloscopio e 299927cpm su Geigerino. Funziona fino a 5,3kHz, con 318500cpm, poi rallenta tutto fino a bloccarsi anche lo scorrere del tempo (ogni secondo deve incrementare il contatore di 1) a 5,67kHz.

h.13.15
Ho aggiustato Victor! Era solo il connettore del potenziometro della base dei tempi che non faceva contatto! Evviva!

Edited by Datman - 7/12/2017, 13:16

Mi ero ripromesso di fare un video, prima poi...

Beh... C'è il tempo impiegato da tutto il ciclo. Se l'interrupt sta sempre a chiamare (ne so qualcosa in casa ), il povero processore non riesce a fare altro!
Avevo avuto il timore che il Tic software potesse rallentare significativamente il ciclo, ma poi ho visto che tutto funzionava bene ben oltre valori ragionevolmente misurabili. Spero di non doverlo usare mai per andare a cercare al buio il nucleo di una centrale nucleare

Eh... Questa è la differenza fra chi usa Arduino e chi usa i PIC!
Purtroppo il mondo di Arduino è stato inventato per far giocare i bambini! Appena uno cerca di fare qualcosa di più o di farla meglio, deve andare a cercare informazioni col lanternino e avventurarsi in un altro mondo che non è diffuso come Arduino.

Ho fatto qualche aggiustamento e ho caricato la nuova versione:
https://github.com/Gatware/Geigerino/tree/...O_1.9aUX_171217

1.9a 17/12/17 Semplifico il numero della versione che appare all'accensione in 1.9a.
Nell'impostazione della sensibilità delle sonde A e B aggiungo 6 spazi dopo "Sensibilità?" per cancellare qualcosa che rimane se era selezionata una sonda memorizzata.
Ho abbassato il background di 2xSBM-20 da 47 a 22cpm in base a prove nelle gallerie della A24 dove, con background=0 (sonda Variabile), leggevo 22cpm.
Ho portato a 16 quello della singola SBM-20 (non poteva essere superiore!).
In BattIco() ho portato il delay a 200mS per cercare di risolvere il problema della lettura diversa tra quella ogni 10s nel loop e quella in Autonomia ma non è cambiato nulla, quindi ho rimesso come prima.
In Autonomia ho aggiunto BattIco() per far apparire il simbolo della batteria. Essendo continuo è sempre stabilissimo, contrariamente a quando leggo nel loop anche se sta su Sonda B senza sonda! Per risolvere il problema nel loop, in BattIco() ho aggiunto un semplice analogRead() pleonastico prima di leggere Vb: OK!!!
Nel loop, nella pressione breve dell'encode (riga 23) ho ridotto il delay da 200 a 100mS (mi sembrava eccessivo e inutile).

E' strana la cosa che, per ottenere una lettura analogica stabile, ho dovuto per forza fare una pre-lettura pleonastica. A nulla è servito un delay(10) o più fra pinMode(X, INPUT) e analogRead()! Nel datasheet del 328 si parla di 13 o 25 cicli di clock necessari secondo i casi... Il problema è sapere la condizione in cui ci troviamo... Mah...

P.s.: il mio Geigerino è anche un progetto base da cui estraggo blocchi interi ormai collaudati con cui posso realizzare molto velocemente qualcosa di anche molto diverso. Ci sono la struttura del menu, la lettura della tensione della batteria con l'icona e tutti i valori già calcolati, la routine di lettura dell'encoder, la regolazione di un valore numerico da menu, la selezione di voci da menu, la formattazione numerica...

Edited by Datman - 18/12/2017, 11:01

zoomx: >> è possibile che nel primo ciclo il tempo per caricare il condensatore sia troppo breve.

Il problema c'è nonostante un condensatore elettrolitico sull'ingresso, quindi con corrente disponibile a volontà per caricare la capacità d'ingresso. Temo che il problema sia intrinseco nel ciclo di lettura del uC, quindi non è nemmeno possibile inserire un ritardo. E' possibile solo fare due letture successive.

zoomx: >> Con Arduino è possibile usare i contatori, ma esempi di utilizzo dei contatori in questo modo sono pochi mentre esempi di utilizzo dell'interrupt tantissimi. Il limite è che se ho un registro a 16 bit, quindi un contatore fino a 65535, e una media di 32 impulsi al minuto, ci vogliono poco meno di 2048 minuti prima che scatti l'interrupt di overflow.

Ho in cantiere (a lungo termine) un frequenzimetro basato su un contatore SN74LV8154: è un doppio contatore a 16 bit (collegabili per avere 32 bit) con uscita a 8 bit (non è seriale, purtroppo). La base dei tempi temporizza la lettura del contatore e il uC visualizza la frequenza. Allo stesso modo, si potrebbe usare il contatore di Arduino nel Geiger leggendo il valore periodicamente e azzerandolo.