Das ist im Diagramm der ODL-Sonde eingezeichnet: Regen, der radioaktive Partikel auswäscht.

Das ist aber ein gutes Zeichen, dass Du das feststellst. Das zeigt, dass Dein Aufbau ausreichend empfindlich reagiert.

Zitat von: DL3HRT am 18. November 2022, 14:27Das ist im Diagramm der ODL-Sonde eingezeichnet: Regen, der radioaktive Partikel auswäscht.

Und wieder etwas dazugelernt

Zitat von: DG0MG am 18. November 2022, 14:35Das ist aber ein gutes Zeichen, dass Du das feststellst. Das zeigt, dass Dein Aufbau ausreichend empfindlich reagiert.

Das freut mich, dann lohnt es sich ja doch die Hardware und Software noch zu optimieren und danach eine Leiterplatte fertigen zu lassen.

Super, tolle Ergebnisse schon mal.

Zitat von: Xodor am 18. November 2022, 14:50Das freut mich, dann lohnt es sich ja doch die Hardware und Software noch zu optimieren und danach eine Leiterplatte fertigen zu lassen.

Wird es dann auch was zum Nachbasteln geben?   

Zitat von: NuclearPhoenix am 18. November 2022, 16:12Wird es dann auch was zum Nachbasteln geben?   

Wenn die zweite Version fertig ist und einwandfrei funktioniert, werde ich die Gerber-Dateien, Schaltplan, Teileliste und die Firmware auf GitHub veröffentlichen.

Hier mal zwei Beispiele, wie kommerzielle, infrastrukturunabhängige ODL-Sonden aussehen:

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

Soetwas kann man sich ja als Vorbild  für die mechanische Gestaltung nehmen.

@Xodor Siehst Du eine Möglichkeit, die Daten in die Karte, die der Multigeiger benutzt, zu bekommen?

Kann man also dem TTN sagen: Wenn Daten von Sensor xx über ein (beliebiges) LORA-Gateway einlaufen, dann multipliziere mit yy, teile durch zz und mache dann einen POST (oder GET oder so) mit der sich ergebenden Dosisleistung bei sensor.community (wo man aber auch noch einen Account bräuchte)?

Zitat von: DG0MG am 19. November 2022, 00:09@Xodor Siehst Du eine Möglichkeit, die Daten in die Karte, die der Multigeiger benutzt, zu bekommen?

Kann man also dem TTN sagen: Wenn Daten von Sensor xx über ein (beliebiges) LORA-Gateway einlaufen, dann multipliziere mit yy, teile durch zz und mache dann einen POST (oder GET oder so) mit der sich ergebenden Dosisleistung bei sensor.community (wo man aber auch noch einen Account bräuchte)?

Das ist gar nicht mal so schwierig 

Der Quelltext vom Multigeiger ist ja vorhanden und somit auch das Protokoll. Der Kartenserver rechnet nun damit, dass man eines der drei hinterlegten Zählrohre verwendet, und hat für diese Kalibrierfaktoren hinterlegt. An die kommt man natürlich nicht ran. Man kann aber ohne weiteres eine Funktion einfügen, die vorher einen eigenen Kalibrierfaktor drüberlaufen lässt, und zwar auf dem Multigeiger-Gerät direkt, bevor man die Daten sendet. So dass man dann ein SBM-20 o.ä. "simuliert".
Der Quelltext ist allerdings etwas umfangreich, mich hat es ein Wochenende gekostet.

Ich hatte das mal als Geschenk für einen Freund gemacht, weil ich eine Verwendung für ein altes Robotron-Zählrohr gesucht habe, das einfach nur jahrelang bei mir rumlag. Nur das Notwendigste auf Lochraster zusammengebraten, funktioniert bis jetzt prima   

Okay, das ist prima, aber die Situation bei @Xodor s LORAWAN ist ja etwas anders. Bei Dir , Henri, macht doch sicher ein ESP32 die verarbeitung und der spricht direkt IP und "redet" selbst mit dem Server bei Sensor.community . Bei LORAWAN läuft doch - so wie ich das verstanden habe - zwischen Sensor und erster Instanz (dem TTN) kein IP. D.h. die Kontaktaufnahme mit dem Datenserver macht im Gegensatz zum Multigeiger nicht der Sensor selbst.
@Henri Benutzt denn Deine Lösung am Sensor WLAN oder wirklich ebenfalls LORA?

Zitat von: DG0MG am 19. November 2022, 17:31Okay, das ist prima, aber die Situation bei @Xodor s LORAWAN ist ja etwas anders. Bei Dir , Henri, macht doch sicher ein ESP32 die verarbeitung und der spricht direkt IP und "redet" selbst mit dem Server bei Sensor.community . Bei LORAWAN läuft doch - so wie ich das verstanden habe - zwischen Sensor und erster Instanz (dem TTN) kein IP. D.h. die Kontaktaufnahme mit dem Datenserver macht im Gegensatz zum Multigeiger nicht der Sensor selbst.
@Henri Benutzt denn Deine Lösung am Sensor WLAN oder wirklich ebenfalls LORA?

Aber das ist doch eigentlich egal? Der Multigeiger stellt ein Datagramm zur Verfügung, und dessen Inhalt bestimmt man selber. Wie es transportiert wird, dürfte nebensächlich sein? Ich erinnere mich nur, dass ein paar Informationen wie z.B. Zählrohrspannungs-Nachladefrequenz weggelassen wurden, weil man ja nur alle paar Minuten senden darf und dann auch nur ein paar bytes.

Bei meiner Bastelei hatte ich auf WLAN gesetzt, genau, mit ESP32 und kleinem billigen OLED statt dem Heltec-Board, das damals auch gerade nicht zu kaufen war. Mit LoRa habe ich das noch gar nicht ausprobiert, weil bei mir die nächsten Netzzugangspunkte zu weit weg sind.

Man kann sehr einfach die Daten wenn sie bei TTN ankommen per JavaScript entsprechend aufarbeiten und in ein beliebiges Format konvertieren. Danach bindet man einen WebHook ein, der per GET oder POST die Daten an einen beliebigen Server versendet.
Somit dürfte es keine große Anstrengung sein die Daten dort einzubinden wo du sie benötigst.

Ich bin gerade dabei die 2. Version zu bauen, da die erste eher fliegende Verdrahtung als was Fertiges darstellte. Jetzt ist das Ganze auf einer Leiterplatte untergebracht und auf den ATTiny wurde auch verzichtet.
Beim Zusammenbau habe ich festgestellt, dass es in der Leiterplatte einen Fehler gibt, den ich vorher in Ki-Cad nicht gesehen habe. Das konnte allerdings mit einem Messer und einer kurzen Drahtbrücke einfach korrigiert werden.
Jetzt muss nur noch die Firmware angepasst und optimiert werden.

Seit nun ca. 4 Wochen verrichtet die 3. Version im Garten ihren Dienst. Im HV-Teil verrichtet ein Theremino GA500 Board an dem ein J305 Zählrohr angeschlossen ist seinen Dienst. Das GA500 habe ich aufgrund der extrem niedrigen Stromaufnahme ausgewählt.
Am GA500 Board habe ich die Klinkenbuchse entfernt und gebe das Ausgangssignal direkt auf einen ATTiny202 der nichts anderes macht, als die Impulse zu zählen und sich zwischen den Impulsen schlafen zu legen.
Ein CubeCell Board welches per I2C an den ATTiny angebunden ist, liest alle 30 Minuten den Zähler aus und setzt ihn auf null zurück.
Der Zählerstand, Batteriespannung, Meßzeit (30Minuten) und der Typ des Zählrohres werden dann per LoraWAN an TTN übertragen. Nach der Übertragung geht das CubeCell Board wieder für 30 Minuten in den Deep-Sleep Mode.
Aufgrund der extrem niedrigen Stomaufnahme von ca. 13 Mikroampere in dem Zeitraum in dem die Pulse gezählt werden, konnte ich auf eine Solarzelle und einen LiIon Akku verzichten. Stattdessen kommt ein LiFePO4 Akku mit 6000mA zum Einsatz. Bei der derzeitigen Konfiguration dürfte eine Laufzeit von mehr als zwei Jahren zu erwarten sein.
Für den Fall dass der Akku gewechselt werden muss (irgendwann nach zwei Jahren) ist noch ein GoldCap mit verbaut, welcher die gesamte Schaltung für mindestens 8 Stunden weiter versorgt.

Das ganze ist wieder in einem HT-Rohr eingebaut worden und wurde in den Garten gestellt.
Meine Meßergebnisse decken sich ziemlich mit denen der benachbarten ODL-Sonde.

Interessantes Projekt!
Glückwunsch dazu.

Zitat von: Xodor am 19. Dezember 2023, 15:00Für den Fall dass der Akku gewechselt werden muss (irgendwann nach zwei Jahren)

Läuft denn das Projekt noch?