@exicator vielen Dank für die Mühe. Das Ergebnis deckt sich mit den Erkenntnissen aus einem anderen "HPGe"-Spektrum, welches mir jemand freundlicherweise angefertigt hat. Dort fehlt der 1001 keV Peak ebenfalls komplett und der 186 keV Peak ist schmal und ohne seitliche Schulter, was für ausschließlich Ra-226 spricht.

Zitat von: ullix am 04. Juli 2026, 15:20ist ab pre08 auf GeigerLog's devel site zu finden:
https://sourceforge.net/p/geigerlog/discussion/devel2/

Wie ich sehe, hast du auch die Setup-Routine überarbeitet, es werden die aktuellen Module installiert (& Playsound <=1.2.2 wegen Python 3.14), der playsound3-Fork wird stattdessen standardmäßig verwendet. Die Installation läuft jetzt unter Ubuntu 26.04 LTS Pro, Python 3.14.4 fehlerfrei durch, Sound funktioniert. 

Hallo,

... noch einen Nachtrag zum "fehlenden" Peak des Pa-234m in der Jachymov #7 Bodenprobe.
Dies ist ein Spektrum von ca. 70mg Pechblende (als Mausauge). Es kann mit hoher Wahrscheinlichkeit von einem Gleichgewicht der Töchter ausgegangen werden. In diesem Spektrum ist der Peak des Pa-234m bei 1001 keV deutlich ausgebildet.

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

... der Peak bei 186 keV setzt sich in diesem Fall aus dem Ra-226 und U-235 zusammen, wobei gut 70% (72,4%) auf das Ra-226 und knapp 30% (27,6%) aus das U-235 entfallen.

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

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

... die senkrechten grünen Linien im unteren Spektrum zeigen die anderen "wichtigen" Linien des U-235, in der Tabelle sind auch die Emissionswahrscheinlichkeiten der Linien aufgeführt.
Gerne Hinweise, Fragen oder was auch immer ...
Grüsse an ALLE und besondere Grüsse an die HPGe-Fraktion (;-).
Ralf



 

Zitat von: ullix am 04. Juli 2026, 15:20Kurios, an diversen Stellen im GeigerLog Code musste ich für diesen Counter Delays(!) einfügen, weil der nagelneue Microchip nicht schnell genug war.

Bei den alten Controllern gab es eine Stelle, an der die Daten real seriell übertragen werden - nämlich vom Ch390 zum µController. Das bremst die Datenrate dort zwingend ein (zwischen ca. 100µs und 1ms pro Zeichen, je nach Baudrate).
Diese Bremse hat der Treiber durchgereicht. (Unvermeidlich zwingend .. naja fast, damals (als W95 neu war) gabe es auch immer mal wieder Chip/Treiber Kombinationen (AFAIR die ersten Prolific Konverter), die das nicht machten und damit weitgehend unbrauchbar waren. Schlichtweg weil sämtliche "serielle" Software damit rechnet das der Treiber (wenig) puffert und ansonsten wartet, bis alles raus ist.)

Hier sitzt aber auf beiden Seiten nur Software, die lediglich das "seriell über USB"-Protokoll nutzt. Damit ist die Rohdatenrate deutlich höher (vermutlich ca. 5µs pro Zeichen), und es gibt auf einmal ganz andere "Fallen" wo man Zeichen verlieren kann.
=> Effektiv muss das nicht langsamer geworden sein, um jetzt plötzlich Zeichenüberläufe zu bekommen - es ist schlichtweg ein Bug im USB-Code auf dem STM-Controller. 

Die haben auch nicht nach DIN gebaut, sondern nach GOST.

Zitat von: DL8BCN am 04. Juli 2026, 15:44Auch muss man auf die Maße aufpassen. Wenn das Batteriefach sehr knapp bemessen ist, passt der Akku nicht rein
Gerade erlebt mit meinem Radiation Alert Inspector +
Der Poover Lithium Akku ist ca. 2 mm breiter als handelsübliche Primärzellen.
Dann geht der Deckel nicht zu

Auch manche ältere russische Dosisleistungsmessgeräte haben schon Probleme mit Alkali-9V-Batterien (meistens zu dick) renomierter Marken-Hersteller.

Norbert

Zitat von: DL8BCN am 04. Juli 2026, 15:44Dann geht der Deckel nicht zu

Hab dich mal nicht so, Du bist doch ein großer , kräftiger Kerl

Viele Grüße
Bernd

Zitat von: DL8BCN am 04. Juli 2026, 15:44Der Poover Lithium Akku ist ca. 2 mm breiter als handelsübliche Primärzellen.

2 mm sind krass. Wenigstens an die Standardmaße hätten sie sich halten können...

Auch muss man auf die Maße aufpassen. Wenn das Batteriefach sehr knapp bemessen ist, passt der Akku nicht rein
Gerade erlebt mit meinem Radiation Alert Inspector +
Der Poover Lithium Akku ist ca. 2 mm breiter als handelsübliche Primärzellen.
Dann geht der Deckel nicht zu

Ein updated GeigerLog, das auch mit dem neuen GMC-800Re2.00 umgehen kann, ist ab pre08 auf GeigerLog's devel site zu finden:
https://sourceforge.net/p/geigerlog/discussion/devel2/

Kurios, an diversen Stellen im GeigerLog Code musste ich für diesen Counter Delays(!) einfügen, weil der nagelneue Microchip nicht schnell genug war. Selbst die Altgeräte GMC-300 et al brauchten das nicht