GC-20 Geigerzähler

[Xodor]

Ich möchte euch gerne mal ein Projekt vorstellen, welches ich im Netz gefunden und nachgebaut habe.

GC-20 Geigerzähler https://github.com/pra22/GC-20

• ESP8266
• SBM-20U Zählrohr
• Touch TFT Display
• WiFi
• aufladbar über USB
• eingebauter LiPo Akku (2000 mAh)
• Gehäuse zum selbst drucken
• Logging Funktion (ThingSpeak)

In dem Git-Repo sind alle benötigten Infos zum erfolgreichen Nachbau inklusive Teilelisten und Gerber-Dateien für das Platinenlayout enthalten. Quellcode und STL-Dateien um das Gehäuse zu drucken, natürlich auch.
Die Software ist Open Source und kann direkt mit Visual-Studio Code und Platform-IO bearbeitet und kompiliert werden. Zu beachten ist jedoch, dass aufgrund eines Fehlers in der Interrupt-Library des ESP8266 die Interrupt-Routine (Zählimpuls vom Rohr) immer zweimal ganz schnell hintereinander aufgerufen wird, was natürlich zu Ungenauigkeiten im Zählvorgang führt. Hier habe ich die ISR-Routine entsprechend angepasst, so dass die Impulse nun korrekt gezählt werden. Bein Interesse kann ich die Änderungen hier posten.
Ich finde, dass es ein kleines und handliches Gerät ist. Wie genau und gut es funktioniert, kann ich noch nicht sagen. Aber es sieht schon ganz ordentlich aus und macht schon was her.

Ich habe die Sonde extern angeschlossen, da ich kein SBM-20U sondern nur ein SBM-20 hatte, welches etwas zu lang ist und daher nicht in das Gehäuse passt - wird aber nachgeholt.

Anbei noch ein paar Bilder.

[Henri]

Der ist ja hübsch, der kleine

Bei der Akkuladeschaltung und beim Controller hat der Designer einfach auf fertige China-Module gesetzt, was Aufwand und Kosten noch mal reduziert. Jetzt müsste man nur noch seine Leiterplatten selber drucken... Mit Touchscreen, das ist schon edel...

Das SBM-20 wird mittels Lötkolben zum SBM-20U. Die beiden Endkontakte sind nur aufgelötet und können recht einfach entfernt werden. Falls Du's riskieren möchtest. Lötstelle flüssig machen, Zinn absaugen und dann die Kappe sehr vorsichtig abpulen.

Anscheinend hat das Gerät vorgegebene, fest einstellbare Integrationsintervalle von minimal 5 Sekunden Integrationszeit. Das ist natürlich für eine Suchfunktion zu langsam, aber der Quelltext liegt ja vor und man könnte sich das beliebig ändern, idealerweise adaptiv. 120 mA Stromaufnahme ist zwar reichlich, aber für großes Touch-Display und Wifi nun auch wieder nicht. Und man kann den Akku ja so groß machen wie man will (wenn man den Ladewiderstand auf dem Lademodul anpasst, was eine üble SMD-frickelei ist).

Danke für das Vorstellen des Projekts hier!

Viele Grüße!

Henri

[Xodor]

Hallo Henri,

das Projekt ist echt ausbaufähig und die Verwendung der China-Module finde ich echt gut.

Ein paar kleine Dinge sind mir allerdings aufgefallen:

• WiFi Name max. 20 Zeichen
• WiFi Passwort max. 20 Zeichen
• 1s Integrationszeit fehlt
• kein OTA-Update
• kein Akustischer-Alarm
• LED Hintergrundbeleuchtung nicht dimmbar/abschaltbar

Ich werde mal mit Punkt 4 anfangen und von da aus an alle weiteren Punkte angehen. Die Steuerung des LED-Beleuchtung wird wohl nicht ohne Änderung an der Hardware funktionieren (Wemos D1 gegen ESP-12 oder NodeMCU tauschen). Daher wird das der letzte Punkt auf meiner Liste.

[DG0MG]

Wenn man ein portables Gerät baut/hat und "in der Landschaft" benutzt, kommt ganz schnell der Wunsch nach einer Georeferenzierung der Messwerte auf.

Ist noch gar nicht so lange her, da hat man das mit einem Messwertspeicher im Strahlungsmessgerät gemacht, der in regelmäßigen Zeitabständen mit dem Messwert beschrieben wurde. Parallel dazu hat man mit einem GPS-Empfänger einen Track mitgeschrieben. Die beiden Datenströme wurden dann erst zuhause anhand der Uhrzeit kombiniert, so dass man erst dann wusste, *WO* *WELCHE* Dosisleistung gemessen wurde und daraus eventuell eine bunte Karte zeichnen konnte.

Seit ATOM FAST und RadiaCode-101 ist dieses Problem erheblich kleiner geworden, da der Ansatz, das Smartphone in die Messwerterstellung einzubeziehen, es ermöglicht, Dosisleistung und Position gleichzeitig zu loggen. Für ein eigenständiges Gerät ist das aber weiterhin eine Geschichte, die man brauchen kann, abseits vom Logging in Cloud mit ThingSpeak und Co.

Deshalb: Falls noch Platz im Gehäuse ist: MicroSD-Kartenslot und GPS-Modul nachrüsten! 

[Xodor]

Micro-SD und GPS ist machbar. Allerdings nur mit NodeMCU, ESP-12 oder ESP32. Der D1 mini hat zu wenige IOs, und das Display und den Kartenslot über das gleiche SPI-Interface laufen lassen, möchte ich nicht.
Das läuft ja schon fast auf eine komplett neue Hardware (PCB) hinaus. Auch die Software müsste gründlich aufgeräumt und optimiert werden.

[DG0MG]

Wir hatten das damals beim AS622 mit OpenLog gemacht: Eine kleine Platine, die per UART ankommende Daten auf die SD-Karte schreibt. Allerdings muss man trotzdem an die Original-Software ran, denn irgendeine Instanz muss ja Messwert und GPS-Daten zusammen in eine Zeile packen.

https://www.geigerzaehlerforum.de/index.php/topic,5.msg2329.html#msg2329

[Henri]

Die Steuerung des LED-Beleuchtung wird wohl nicht ohne Änderung an der Hardware funktionieren (Wemos D1 gegen ESP-12 oder NodeMCU tauschen). Daher wird das der letzte Punkt auf meiner Liste.

Ist die nicht an einem PWM-Pin? Sonst könnte man auch ganz old-school einfach ein Poti dazwischenschleifen... muss ja nicht alles digital sein.

Die anderen Sachen (Alarm mal ausgenommen) finde ich gar nicht so schlimm, bei diesen ganzen IoT-Dingen darf man eh keine hohe Sicherheit erwarten und tut besser daran, dies auf der Accesspoint-Seite irgendwie zu regeln. OTA ist praktisch, aber will man das? Kommt ja nicht so häufig vor, da kann man das auch einfach über USB machen. Und das Gerät ist ja nicht dafür gedacht, irgendwo auf dem Dach vor sich hinzuwerkeln, wo man nur schwer wieder rankommt.

NMEA parsen geht ganz schön auf die CPU, weil ja ständig an RX auf evtl. ankommende Daten gelauscht werden muss. Aber man könnte auch einen Arduino pro mini nehmen, der das ausschließlich macht und dann die Standortdaten z.B. per SPI bereitstellt, oder was gerade noch für Pins auf dem D1 mini verfügbar sind. Die Standortdaten abrufen und auf die SD-Karte schreiben muss ja nicht gleichzeitig geschehen.

Viele Grüße!


Henri

[Xodor]

OTA war nur für mich gedacht, da der USB-Port vom D1 nicht im Gehäuse herausgeführt ist. Zur Not tut es auch ein Schlitz an der richtigen Stelle im Gehäuse.
Die LED-Hintergrundbeleuchtung liegt fest auf VDD (zumindest so wie es der Author dieses Projektes vorgesehen hat). Es fehlt leider ein Pin am D1 der dafür frei wäre.

NMEA würde ich gar nicht nehmen. Eher das UBX-Protokoll von uBlox, welches relativ einfach gelesen werden kann. Um die Interrupt-Last zu senken, kann man ja auch alle nicht benötigten Messages vom GPS-Empfänger deaktivieren.

[DL3HRT]

NMEA parsen geht ganz schön auf die CPU, weil ja ständig an RX auf evtl. ankommende Daten gelauscht werden muss.

Das ist aber wirklich kein Problem, man muss es nur effizient implementieren. Der PIC im AS622-Geigerzähler wird nur mit 2 MHz getaktet und macht das nebenbei.

[Henri]

NMEA parsen geht ganz schön auf die CPU, weil ja ständig an RX auf evtl. ankommende Daten gelauscht werden muss.

Das ist aber wirklich kein Problem, man muss es nur effizient implementieren. Der PIC im AS622-Geigerzähler wird nur mit 2 MHz getaktet und macht das nebenbei.

Echt? Ich hatte das mal mit dem Arduino (8 Mhz) probiert. Aber Display + GPS + SD-Karte + Impulse zählen war wirklich eine Herausforderung. Ich brauchte ja 2x SPI, für Display und SD-Karte getrennt, also 1x Soft-SPI... Am Ende habe ich dann eine Library gefunden, die irgendwelchen wilden Voodoo-Zauber angewendet hat, und dann ging es. Der Prozessor kann ja kein Multitasking. Während er von der seriellen Schnittstelle liest, muss alles andere warten. Ich habe im GPS-Empfänger entsprechend auch alle bis auf ein Datagramm deaktivieren müssen. Das ging nur über die ublox-Software. Im Auslieferungszustand senden die Module ja Unmengen Daten, und das noch mit 9600b...

Und jetzt bitte nicht sagen, "Arduino ist keine Programmierung"! 

Viele Grüße!

Henri

[Lordcyber]

Der steht auch noch auf meiner Bauliste.
Da mein GMC320 langsam spinnt

[ts55]

Hallo Leute,
bin neu hier und hätte mal ne Frage zu diesen GZ.
Ich habe mir nach Anleitung einen aufgebaut, kann aber keine Hochspannung am Zählrohr messen.
Display funktioniert u. die Stromaufnahme liegt bei 93mA.
Versuchsweise habe ich noch eine Platine nur mit den Hochspannungsteil aufgebaut.
Also ohne Spannungsversorgung, Microcontroller u. Display. Auch da keine Hochspannung.
Gibt es Messpunkte zum kontrollieren wo eine bestimmte Spannung anliegen muss?
Hat jemand eine Idee warum ich keine Hochspannung kriege?

Grüße Bernd

[DG0MG]

Hier der komplette Schaltplan: https://github.com/pra22/GC-20/blob/master/GC-20%20Schematic.pdf

Nur die HV-Erzeugung:

Sie dürfen in diesem Board keine Dateianhänge sehen.

Mach mal ein Foto deines "HV-Only" Aufbaues, vielleicht fällt etwas auf.
Was nimmt denn nur die HV an Strom auf?

[ts55]

Also die HV , sowie auf dem Foto , nimmt nur 1 mA auf.
Scheint bissel wenig, oder. Den 100 Ohm Regler hab ich erstmal extern
angelötet, weil die Platine beide Fußpunkte auf Minus legt.
Sie dürfen in diesem Board keine Dateianhänge sehen.

[DG0MG]

Wo hast Du die Spule her?
Bist Du sicher, dass eine mit "100" beschriftete Induktivität 10 mH hat?

Man sieht leider die Wicklung nicht, um anhand der Drahtstärke und Wicklungszahl etwas abschätzen zu können, aber der Beschriftung nach müsste deine Spule 10 * 10⁰ = 10 µH haben, das sind drei Zehnerpotenzen zu wenig.