Einbinden der Daten eines Geigerzählers

Begonnen von pattex66, 10 März 2020, 17:37:11

Vorheriges Thema - Nächstes Thema

pattex66

Als Anfänger stelle ich diese Frage am besten hier und hoffe es klingt jetzt nich zu absurd.
Ich möchte gern die Daten meines Strahlungsmessers loggen und hoffe es gibt jemnanden der mir einen gangbaren Weg aufzeigen kann.
Der GM Zähler erzeugt am Ausgang ein TTL Signal im Takt der registrierten Zerfälle im GM Rohr. Diesen Impuls wollte ich nun z.B. mit dem Modul S0Counter am GPUIO 23 abfragen. Das klappt auch soweit und in den Readings wird schön hochgezählt. Wie könnte ich nun diese Daten entsprechend loggen um daraus ein Diagramm mit Counts/Minute erzeugen? Es muss auch nichts weiter ausgerechnet werden. Die Counts reichen mir. Das Diagram kann ich ja dann entsprechend skalieren und ggf. mit einem Umrechnungsfaktor an die tatsächlichen Werte angleichen.
Ich hatte erst die Idee das Modul ElectricityCalculator zu nehmen aber das geht nicht. Irgendwo hier las ich, dass der wohl auf Impulse unter 1 Sekunde nicht reagiert. Auch die kalkurierten Werte dort haben irgendwie keinen richtigen Bezug zu den Impulsen.
Kann mir da jemand helfen?

VG Patrick

JoWiemann

Hallo Patrick,

das Statistik-Modul könnte Dein Freund sein.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

pattex66

Möglicherweise könnte es das.

Ich habe es jetzt mal mit "define Strahlungsmesser statistics S0Counter:Counter:.*" eingebunden. Allerdings kommen keine Readings rein. Auch sonst lassen sich keine Attribute einstellen. Nur "nextPeriodChangeCalc" ist fest drin.

VG Patrick

pattex66

#3
...ich sehe übrigens gerade in der Hilfsdatei, dass dort etwas von stündlichen Readings steht. Mir steht der Sinn eher so nach sekündlichem Update oder am besten nach permanenter Überwachung der GPIO und der Aufzeichnung jedes Counts. Oder interprätiere ich das falsch?

JoWiemann

Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

pattex66

Naja, nur bedingt. Zunächst hatte ich das Device falsch eingebunden. Richtig ist wohl "define Strahlungsmesser statistics S0Counter" ohne den Verweis auf das Reading.
Nur mit den Attributen komme ich nicht zurecht. Ich weiß nicht wie ich das Device mit dem S0_Counter verbinden soll. Auch weiß ich nicht, was dort eigentlich berechnet wird. Beim Versuch ein svg zu erstellen ist im Auswahlmenü auch keine Datenquelle mit Bezug zum Statistikmodul verfügbar.


Beta-User

Falls du in Betracht ziehst, einen Microcontroller einzusetzten, um die Pulse zu zählen, könnte das ganze z.B. mit https://fhem.de/commandref.html#ArduCounter einfacher gehen.

Der wirft - je nach Konfiguration - auch minütliche Werte aus, statstics und plotten mit delta-h sind eher ab stündlichen Werten interessant.

(Vielleicht noch der Hinweis: Pi-GPIO-Nutzung für sowas ist dem Hörensagen nach immer gut für "Überraschungen", das kann auch schon mal längere Hänger von FHEM/dem ganzen OS (?) geben...)

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Prof. Dr. Peter Henning

Die "Hänger" kommen von der softwareseitigen Abarbeitung der GPIO-Ports. Wir haben bei entsprechenden Konfigurationen (z.B. als serielle Schnittstelle) schon Latenzen von 90 Minuten gemessen - siehe hier im Forum, irgendwo in den allerersten Diskussionen über den EBUS-Adapter.

Mein Tipp für das Zählen: Einen 1-Wire-Counter dranhängen und in regelmäßigen Abständen auslesen. So messe ich beispielsweise die Impulse meines Anemometers.

LG

pah

pattex66

Wenn ich den Zähler am Modul S0_Counter betreibe werden meines Erachtens nach alle Impulse erfasst und hochgezählt. Was ich bräuchte wäre ein Modul was die Impulse/Min anzeigt um sie loggen zu können. Und wenn sie an einem GPIO Port abgegriffen werden könnten wäre das optimal.
Ich hatte den Zähler bis vor kurzem über einen USB Adapter an einem alten Notbook und habe dort die Auswertung gemacht. Allerdings ist das energetisch gesehen eher Nonsens. Der Rechner verbrauchte immer so mind. 30 Watt nur um einen simplen Graphen zu schreiben. Der Raspi ist da schon effizienter.

VG Patrick

Prof. Dr. Peter Henning

Welches Modul wird da jetzt benutzt ?

Und warum sollte bei statistics "nichts hereinkommen", wenn das verwendete Modul angeblich "alles erfasst und hochzählt" ?

Und wieso sollte man aus dem Hochzählen schließen können, dass die Latenz gering ist?

Und wieso sollten "sekündliche Updates" sinnvoll sein?

Ich kenne zwar Tomatenmesser und Kochmesser - aber was ein "Strahlungsmesser" ist, kann ich nur raten.

Darüber hinaus ist es absoluter Käse, mit einem Geiger-Müller-Zählroher so etwas wie die individuelle Strahlenbelastung zu erfassen - die wird nämlich wesentlich durch Alphas und Betas verursacht, die paar Gammaquanten spielen kaum eine Rolle (und nur die Gammas werden im normalen GM-Zählrohr erfasst). Und die Gamma-Ortsdosisleistung wiederum kann man sehr gut auf der Web-Seite des Bundesamtes für Strahlenschutz abgreifen, direkt von der nächsten offiziellen Messstelle.

LG

pah

pattex66

Zum Zählen nutze ich den GPIO 23 mit dem S0_Counter. Möglicherweise ist nur meine Syntax zum Verbinden mit Statistics falsch. Das Wiki, oder besser gesagt die meisten Wikis für FHEM sind halt für Leute geschrieben die wissen was sie tun. Als Einsteiger hat man da echt schlechte Karten und kann sich mit viel Glück und Probieren zusammenreimen was gemeint sein könnte.

Warum bei Statistics nicht reinkommt weiß ich nicht, sonst würde ich nicht fragen. Ich will eigentlich jetzt nicht auch noch programmieren lernen nur um mal ein paar Daten zu loggen. Mir gehts nur darum mit dem Raspi etwas Energie bei der Messerei zu sparen. Wenn ich es wirklichgenau wissen wöllte müsste ich meinen Messplatz aufbauen und könnte das auch spektroskopieren. Das geht aber hier zu weit.
Das die Latenz keine Rolle spielt sehe ich beim direkten Vergleich beider Zähler. Wenn der "Strahlungsmesser" und der S0_Counter über 1 Minute das gleiche gezählt haben reicht mir die Genauigkeit.

Das ich GM Zähler schrieb liegt ganz einfach daran das ich vermute, dass den meisten hier ein Szintillationszähler sich nicht geläufig ist. Und das ein Szintillationszähler bei entsprechend ausgewählten Kristallen bzw. Folien nicht nur Gammas mißt sicher auch nicht.
Insgesamt habe ich hier vier verschiedene Röhren im Einsatz und mache das ganz einfach nur weil ich dem Bundesamt im Ernstfall nicht traue.

Vertauen ist gut, Kontrolle ist besser!

VGP

Prof. Dr. Peter Henning

Zitatweil ich dem Bundesamt im Ernstfall nicht traue

Das ist zwar Off-Topic, aber auch Unsinn. Ich bin Kernphysiker und kenne Kollegen im BfS, denen ich in jeder Hinsicht vertraue. Unabhängig davon haben die weder Interesse noch die Möglichkeit, Daten aus dem Messnetz zu manipulieren.

ZitatGPIO 23 mit dem S0_Counter
Noch einmal: Es gibt kein offizielles FHEM-Modul mit Namen S0_Counter. Also wiederhole ich auch die Frage noch einmal: Welches FHEM-Modul wird verwendet? Genaue Hardware-Konfiguration? List des FHEM-Devices?

ZitatIch will eigentlich jetzt nicht auch noch programmieren lernen nur um mal ein paar Daten zu loggen
So lange keine aussagekräftigen Informationen geliefert werden, wird aber niemand helfen können - und damit läuft es genau darauf hinaus.

ZitatDas Wiki, oder besser gesagt die meisten Wikis für FHEM sind halt für Leute geschrieben die wissen was sie tun.
Unsinn. Die gesamte Einsteigerdoku ist sehr wohl für Anfänger geeignet - und das schreibe ich nicht nur, weil eines der Bücher dazu von mir stammt.

LG

pah

pattex66

Na ok, das Modul heißt nicht S0 Counter sondern RPI_GPIO. Ich bin als Anfänger nach dieser Anleitung vorgegangen und das war halt die Rede von S0 Counter. Wie gesagt, es zählt auch so wie es soll.

ZitatWelches FHEM-Modul wird verwendet? Genaue Hardware-Konfiguration? List des FHEM-Devices?
Genau das ist es was ich meine. Stellen wir uns mal einen Moment vor, es findet ein Bürger zufällig bei der Suche im Netz die Software FHEM von der er noch nie gehört hat. Die Videotutorials versprechen durchaus eine leistungsfähige Software und dann geht die Sch... beim installieren schon los. Als Windows- oder ggf. auch Mac User ist man gewohnt seine Sachen einfach zusammenzuklicken. Hier gehts halt nur über Kommandozeile. Wer keine Ahnung von Unix oder Linux und deren Sysntax hat ist entweder erschossen oder guckt hier im Forum oder den Wikis nach. Schnell merkt man aber, dass hier wie da die gleiche Sparche gesprochen wird. Überall Codeschnipsel mit dem Verweis darauf es doch so wie bekannt zu machen und nur dieses und jenes zu ändern. Da ist man schnell frustriert wenn dann etwas nicht geht wie erwartet und neigt dazu das Handtuch zu werfen.

Allein die Rubrik Anfängerfragen hier im Forum hat bis jetzt 1126!!! Seiten. Sollte das nicht Grund genug sein sich zu fragen, ob die Software oder die Wikis wirklich auch für Einsteiger geeignet sind?
Vielleicht wäre "FHEM für Dummys" eine gute Idee.

ZitatUnabhängig davon haben die weder Interesse noch die Möglichkeit, Daten aus dem Messnetz zu manipulieren.
Die "einfachen" Mitarbeiter sicher nicht. Aber allein schon die Bezeichnung "Bundesamt..." impliziert, dass dort nicht die Mitarbeiter das sagen und die Verfügungsgewalt über die Server haben.

Ich wohne hier im Bergbaugebiet ehem. Uran-Bergbaugebiert und die Radonbelastung im Keller oder gesamten Haus bildet die ODL-Messstelle des BfS leider nicht ab.

VGP


Beta-User

Also nochmal: Besser statt Pi-GPIO was anderes nutzen, es gab auch eine Empfehlung.

Da du aber unbedingt diese Lösung haben willst: Nimm ein minütliches "at" mit alignTime.

Was das genau machen soll, bleibt dir überlassen, du kannst: den aktuellen Wert loggen lassen (plot-Abriss vermeiden im Wiki suchen), setreading auf den Zähler ausführen lassen und ein eigenes Reading erstellen (bzw.: für die Differenz OldReadings aktivieren) und das loggen lassen.

Und nein, hier ist vermutlich weder jemand bereit, weitere vollständige mundgerechte Lösungen zu bieten (Arducounter kann das, was du brauchst mehr oder weniger OOTB...), noch die Suche oder eigene Einarbeitung zu ersparen - oder gar zu privaten Videos, über deren Qualität man teils streiten kann, irgendwie ausführlicher Stellung zu nehmen...

Und ja: Es ist nicht einfach, sich zurechtzufinden. Aber es wird nicht besser, wenn du Leute vor den Kopf stößt, die sich dazu bequemen, überhaupt was zu schreiben (z.B., indem du nicht die Infos lieferst, die als "erforderlich" in den angepinnten Beiträgen hier genannt sind! Oder Beiträge ignorierst, nur weil du sie nicht verstehst...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

pattex66

Es geht mir doch nicht darum jemanden vor den Kopf zu stoßen der bereit ist zu helfen. Was ich nicht mag, ist von oben herab als Anfänger ohne Ahnung hingestellt zu werden - auch wenns so ist. Jeder hat sein Spezialgebiet und wenn zu mir eine Kunde kommt von dem ich merke das er keinen Plan hat mache ich ihn auch nicht runter nur um mit Wissen zu glänzen.

...und ja, mir steht der Sinn schon nach fertigen mundgerechten Lösungen. Die Tatsache, dass das Projekt hier open Source ist kann doch nicht bedeuten, dass jeder Interessent daran dazu verpflichtet werden kann sein Modul selber zu programmieren. Ich will es nur nutzen, nicht entwickeln.

Das ich meine Hardware-Konfiguration nicht angegeben habe stimmt ja nun nicht. Raspi mit TTL Signal welches am GPIO gezählt werden soll ist doch ausreichend. Oder was muss ich noch angeben?

...zu den Videos: Hätte ich diese Videos nicht gesehen dabei erfahren, dass es auch anders aussehen kann wäre mir spätestens nach dem Anblick der Startseite von FHEM im Design und Händling der frühen 90er Jahre der Kragen geplatzt und hätte alles wieder gelöscht.

VGP