RadiaCode-101 (радиакод-101, RadiaCode-102, RadiaCode-103)

[Samarskit]

Ui, das freut mich!
Ich hatte bereits gehört, dass jemand anderes seinen RadiaCode ohne Zollformalitäten erhalten hat, wusste aber nicht warum. Weil (vermutlich Tatiana) - wie versprochen - wieder einen Versand aus Zypern durchführt.

Nein, dieser "jemand andere" bin ich! Ich hatte mich bisher nur noch nicht gemeldet, weil ich einige Tage energietechnisch vom Karlsruher Syndrom absorbiert war (siehe dort!)

Ja, mein Gerät kam auch völlig problemlos zollfrei an, von DHL an der Haustür in Empfang genommen.
Ich hatte direkt auf der Internetseite der Vertriebsfirma bestellt für 179€ und über PAYPAL bezahlt (versendet am 12. Mai, angekommen kurz vor Pfingsten).

Allerdings lief der Versandweg nicht über Zypern, sondern direkt von Russland nach Deutschland (Trackingnummer EE054141125RU) via FRA-Flughafen. Dort erhielt das soft verpackte Expresspaket den geliebten grünen Post-Aufkleber "von zollamtlicher Behandlung befreit" und fand alsbald seinen Weg zu mir.

Ja, und ich habe eben vorhin alle 20 Seiten der regen Diskussion im Zusammenhang mit dem Gerät verfolgt. Schon spannend und oft hilfreich, was ausgetauscht wurde. Einiges habe ich selbst auch schon festgestellt (z.B. die unkontrollierten Farbwechsel des Displays, die zu hohen ODL-Werte) und einige Spektren aufgezeichnet, darunter auch Langzeitmessungen der Hirschgraben-Erde und des Quantum Amuletts (siehe Bilder).
Beim Amulett ist bei diesem kleinen Kristall schon erstaunlich, wie gut die hochenergetische Emission von Tl208 bei 2615keV abgebilder wird (natürlich nur in der logarithmischen Einstellung).

Insgesamt halte ich dieses handliche Gerät für einen echten Knüller - insbesondere im Zusammenhang mit den qualitativ hervorragenden Kommentaren und Hilfestellungen von Arsenji - ganz herzlichen Dank für diese Kundenbetreuung!!

Noch eine Frage: was bedeutet eigentlich der meist recht hohe Balken ganz am Ende des 3MeV-Spektrums?
Ist das ein Artefakt? oder sammelt der alle Lichtblitze im Kristall jenseits der magischen Grenze auf?
Bei sehr niedriger Zählrate ist er sehr dominant und "drückt" das Hauptspektrum unnötig nach unten, insbesondere bei der Einstellung "linear". Könnte man den irgendwie ausblenden (ich arbeite nur mit der Windows-Software)?

[DL3HRT]

Im Prinzip ist der Akku ja weit weg, allerdings wenn das Gehäuse nicht belüftet ist und der Ladestrom recht hoch gewählt ist, dann könnt der Kristall ja schon auch warm werden. Ist vom draufgucken wohl schwer zu beurteilen. Allerdings hat zumindest die Android SW ja ne Temperaturanzeige (rechts neben dem Ladestand). Da könnte man ja schon mal mal schauen wie die sich ändert, wenn man zu Laden beginnt. Das wird auch im Log Display geloggt.

Genau das passiert, siehe hier: https://www.geigerzaehlerforum.de/index.php/topic,647.msg7806.html#msg7806

Wenn das Laden beendet ist, so sinkt die angezeigte Temperatur relativ schnell wieder ab. Ich glaube nicht, dass sich der Kristall so schnell erwärmt hat. Möglicherweise wird zur Messung nur der interne Temperatursensor des STM32L475 verwendet. Wir wissen es nicht.

Ein möglichst exaktes Spektrum basiert auf folgenden Voraussetzungen:

   
• temperaturunabhängige Vorspannung des Detektors (wird in den technischen Daten so beworben)
• temperaturunabhängige Spannungsmessung
• Kompensation der Temperaturabhängigkeit der Lichtausbeute des CsI-Scintillators

Der letzte Punkt scheint bei CsI und üblichen Umgebungsbedingungen nicht allzu kritisch zu sein. Zwischen 15°C und 45°C ändert sich die relative Lichtausbeute nur wenig (siehe hier: https://www.crystals.saint-gobain.com/sites/imdf.crystals.com/files/documents/csitl-and-na-material-data-sheet.pdf).

Dann komt es auch noch darauf an, wie die Temperaturkompensation realisiert wird.

Variante #1:
Der Messwert des Lichtimpulses wird dem der gemessenen Spannung entsprechenden Kanal im Spektrum zugeordnet. Die Temperaturkompensation erfolgt, indem am Ende das gesamte Spektrum entsprechend verschoben angezeigt wird. Diese Variante ist nur dann brauchbar, wenn sich die Temperatur während der Messzeit nicht oder nur wenig ändert.

Variante #2:
Für jeden Messwert wird in Abhängigkeit von der Temperatur entschieden, welchem Kanal er zugeordnet wird. Damit könnte man auch Langzeitmessungen gut kompensieren. Das setzt allerdings voraus, dass die gemessene Temperatur auch der realen entspricht.

Arsenij konnte mir nicht sagen, auf welcher Variante die Temperaturkompensation beruht. Ich vermute, dass man Variante #1 umgesetzt hat, da das am einfachsten ist. Das funktioniert sicher gut, wenn man im "flachen" Bereich des Temperaturgangs  des Szintillators liegt.

Davon einmal abgesehen: Die Theremino-Software bietet auch keine Möglichkeit zur Temperaturkompensation. Da muss man sich darauf verlassen, dass die HV-Erzeugung eine stabile Spannung liefert, die Soundkarte nur einen geringen Temperaturgang hat, etc. Daher lasse ich mein Gammaspektrometer mit dem großen NaI(Tl)-Kristall nach dem Einschalten mindestens eine halbe Stunde laufen, bevor ich mit Messungen beginne. Bei Langzeitmessungen achte ich auf eine möglichst gleichbleibende Raumtemperatur.

[DL3HRT]

Noch eine Frage: was bedeutet eigentlich der meist recht hohe Balken ganz am Ende des 3MeV-Spektrums?
Ist das ein Artefakt? oder sammelt der alle Lichtblitze im Kristall jenseits der magischen Grenze auf?

Die letzte Vermutung dürfte stimmen. Es gibt auch noch einen Summationseffekt. Wenn im Szintillator mehrere Lichtblitze (nahezu) zeitgleich erzeugt werden, so wird deren Energie im Detektor summiert und ergibt dann eine hohe Spannung.

[Na-22]

...
Könnte man den irgendwie ausblenden (ich arbeite nur mit der Windows-Software)?

In der Windowssoftware, zumindest bei der z.Z. aktuellen Version 1.00.08 ist das nicht möglich. Vielleicht kommt das später noch.

In der Androidversion gibt es in den Optionen fürs Spektrum den Punkt "Show last channel", der deaktiviert werden kann. Der letzte Kanal wird dann ausgeblendet.

[Samarskit]

Es gibt auch noch einen Summationseffekt. Wenn im Szintillator mehrere Lichtblitze (nahezu) zeitgleich erzeugt werden, so wird deren Energie im Detektor summiert und ergibt dann eine hohe Spannung.

Ich weiss nicht.... das kann ich mir bei dem beigefügten Spektrum (Langzeitaufnahme Hintergrund in der Burg) eigentlich nicht vorstellen. Bei einer durchschnittlichen (geschätzten, da keine Akkumulationsdaten erfasst werden) Zählrate von 0,2 cps werden in den 98000 Sekunden etwa 19600 Impulse erfasst, von denen dann ca. 1660 Impulse in den letzten Kanal geschoben werden und die anderen 17940 Impulse auf die restlichen 255 Kanäle verteilt werden (im Schnitt ca. 70 pro Kanal). Jeder 12. Impuls wäre also dann ein solcher Summationseffekt? Das ist bei dieser sehr geringen Impulsrate statistisch ausgeschlossen, zumal für die Überschreitung der 3MeV-Schranke ja auch nur Summanden mit (seltenen!) hohen Energien in Frage kommen. Es muss also einen anderen Effekt geben, der (vermutlich sogar ausschließlich) für diesen Extrembalken verantwortlich ist. Ein Indiz hierfür ist auch die Beobachtung, dass der Balken bei hoher Zählrate relativ niedrig bleibt und bei kleiner Zählrate in die Höhe steigt. Aber was ist das für ein Effekt? Ich kann mir darauf im Moment keinen Reim machen.

[Samarskit]

In der Windowssoftware, zumindest bei der z.Z. aktuellen Version 1.00.08 ist das nicht möglich. Vielleicht kommt das später noch.

Ich würde es sehr begrüßen, wenn aus dem "vielleicht" ein "gewiss" wird, denn dieser Balken stört teilweise sehr und beeinträchtigt vor allem Spektren mit geringer Zählrate (siehe Bilder in obigem Post).

Ich kann an dieser Stelle auch nicht verstehen, weshalb die Windows-Software doch irgendwie etwas stiefmütterlich behandelt zu werden scheint gegenüber der Android-Software für die mobilen Geräte.
Deren Vorteil ist zur Zeit natürlich die Anbindung an das GPS-System für das Aufnehmen von ODL-Profilen in der Landschaft, und das werden die meisten Nutzer ja auch umsetzen.

Es kann aber doch keine großen Probleme bereiten, die allgemeinen Features für die Darstellung der Spektren für beide Softwaresysteme gleichzeitig zu implementieren (hier z.B. das Ausblenden eines möglicherweise unerwünschten, weil störenden Kanals)!? Oder sind die Schnittstellen zur Steuerung der Grafik in Windows so viel schwieriger als in Android? 

[Samarskit]

Aber was ist das für ein Effekt? Ich kann mir darauf im Moment keinen Reim machen.

Ich zitiere mich eben selbst....

Ich könnte mir vorstellen, dass der Grund die energiereiche Höhenstrahlung ist. Für die sind ja selbst dicke Bleiburgen kein Hindernis, und gelegentlich werden die Quanten auch von einem winzigen CsI-Kristall eingefangen. Der Auswertungsalgorithmus scheint diese Impulse dann alle in einen einzigen Kanal, den höchsten, zusammenzustauchen. Da die Impulsrate dieser Strahlung einigermaßen konstant und damit unabhängig von den schwankenden Messraten bei unterschiedlichen Objekten ist, erklärt sich daraus auch die Tatsache, dass relativ betrachtet der Balken bei niedrigen Impulsraten höher ist und bei hohen niedriger.

[Henri]

Es gibt auch noch einen Summationseffekt. Wenn im Szintillator mehrere Lichtblitze (nahezu) zeitgleich erzeugt werden, so wird deren Energie im Detektor summiert und ergibt dann eine hohe Spannung.

Ich weiss nicht.... das kann ich mir bei dem beigefügten Spektrum (Langzeitaufnahme Hintergrund in der Burg) eigentlich nicht vorstellen. Bei einer durchschnittlichen (geschätzten, da keine Akkumulationsdaten erfasst werden) Zählrate von 0,2 cps werden in den 98000 Sekunden etwa 19600 Impulse erfasst, von denen dann ca. 1660 Impulse in den letzten Kanal geschoben werden und die anderen 17940 Impulse auf die restlichen 255 Kanäle verteilt werden (im Schnitt ca. 70 pro Kanal). Jeder 12. Impuls wäre also dann ein solcher Summationseffekt? Das ist bei dieser sehr geringen Impulsrate statistisch ausgeschlossen, zumal für die Überschreitung der 3MeV-Schranke ja auch nur Summanden mit (seltenen!) hohen Energien in Frage kommen. Es muss also einen anderen Effekt geben, der (vermutlich sogar ausschließlich) für diesen Extrembalken verantwortlich ist. Ein Indiz hierfür ist auch die Beobachtung, dass der Balken bei hoher Zählrate relativ niedrig bleibt und bei kleiner Zählrate in die Höhe steigt. Aber was ist das für ein Effekt? Ich kann mir darauf im Moment keinen Reim machen.

Vielleicht sind das ja EMV-Störungen? Die üblichen Impulse sind ja sehr niedrig. Wenn dann mal was "dazwischenstört", landet es im letzten Kanal. Oder es ist doch ein Summenpeak, der dann (logarithmische Achse?) entsprechend hochgerechnet wird. Zwischen 1,5 und 3 MeV sollte ja kaum was registriert werden. Da reichen dann eigene ganz wenige Impulse oberhalb 3 MeV, durch den "Verstärkungsalgorithmus" gedreht, um einen hohen Peak zu erzeugen - es sind ja keine echten Impulse, die da angezeigt werden, sondern sie wurden mit einem Faktor multipliziert, damit man sehen kann, dass in dem Kanal was passiert ist.

Oder es ist ein Artefakt des Analog-Digital-Wandlers.

Oder es sind kosmische Teilchen. Die haben ja eine sehr hohe Energie. Wäre allerdings ein Wunder, wenn das Kriställchen die sehen könnte.

Dass 2615 keV noch abgebildet wird, ist mir ehrlich gesagt etwas suspekt. Die sieht nicht mal mein knapp 3" NaI(Tl) wirklich gut. Bei riesigen Kristallen von einem halben Meter Länge kommt man da auf einige wenige Impulse pro Minute. Der Gammaquant muss ja seine gesamte Energie im Kristall abladen können, damit man den realen Energiewert messen kann. Wie soll das gehen, auf günstigstenfalls nicht mal 1,5 cm Strecke? Vielleicht schafft das noch BGO, aber CsI(Tl)?

Vielleicht ist das in etwa so wie mit dem Interpolieren von digitalen Bildaufnahmen. Man kann 640x480 problemlos auf Full-HD hochrechnen, aber der Informationsgehalt steigt dadurch nicht an, auch wenn es erst mal so scheint...

Viele Grüße!

Henri


PS:
hier https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2008JB006226  ist ein etwas unsortierter Artikel - wenn ich es beim schnellen Überfliegen richtig verstanden habe, wurde dort mit einem 3" x 3" NaI(Tl) und Bleikollimator die Umgebungsstrahlung aus Bodenrichtung gemessen. Bei 1460 keV hatte man eine Countrate von ca. 0,55 cps, bei 2615 keV waren es noch 0,15 cps. Mit einem 345 Mal so großem Volumen wie beim RadiaCode... Wenn man das überschlägig aufs Volumen umrechnet, dürfte der RadiaCode unter 2 counts pro Stunde (!) bei 2,6 MeV registrieren. (OK, mit einem Th-Präparat natürlich mehr).

PS PS:
Hier ist noch ein Artikel: https://ludlums.com/images/data_sheets/Geo%20Explorer%20Article.pdf 
Verwendet wird ein 5 x 10 x 40cm NaI(Tl), also 2000 cm³. Dieser hat im 2615 keV Kanal eine Zählrate von 1-2 cps... runtergebrochen auf das Volumen des RadiaCode-Kristalls wären hiernach bei diesem ca. 2,7 counts pro Stunde zu erwarten.
Das heißt, wenn man 20-30 Minuten mit dem RadiaCode misst, sollte schon ein einziger Count dabei sein. Und der wird dann durch die exponentielle Skalierung als Peak angezeigt.

[DL3HRT]

Angehängt findet ihr einen Screenshot des Hintergrundspektrums über mehr als 2 Tage. Exakt sind es 235447 Sekunden.  Die Y-Achse zeigt die absoluten Ereignisse pro Kanal logarithmisch skaliert an. Der Marker zeigt, dass bei 2,486 MeV insgesamt 34 Ereignisse registriert wurden was 0,00014 cps entspricht. Das ist im Mittel ein Ereignis alle (gerundet) 2 Stunden.  Bei 2,6 MeV wurden 48 Ereignisse registriert. Das sind dann 0,000203 cps oder ein Ereignis alle 1,37 Stunden. Das liegt etwas unterhalb der Abschätzung aus dem letzten Post und sieht realistisch aus.

Die Messwerte heben sich nur aufgrund der logarithmischen Skalierung von der Nulllinie ab.

Was den letzten Kanal betrifft, so tippe ich auf eine Mischung aus AD-Wandler Artefakte und Störimpulse (EMV). Es gibt in der Android-App ja nicht ohne Grund die Option, den letzten Kanal nicht anzuzeigen.

[Samarskit]

Angehängt findet ihr einen Screenshot des Hintergrundspektrums über mehr als 2 Tage. Exakt sind es 235447 Sekunden.  Die Y-Achse zeigt die absoluten Ereignisse pro Kanal logarithmisch skaliert an. Der Marker zeigt, dass bei 2,486 MeV insgesamt 34 Ereignisse registriert wurden was 0,00014 cps entspricht. Das ist im Mittel ein Ereignis alle (gerundet) 2 Stunden.  Bei 2,6 MeV wurden 48 Ereignisse registriert. Das sind dann 0,000203 cps oder ein Ereignis alle 1,37 Stunden.

Danke für das Bild und die Zahlen! Bei meinem Gerät läuft ebenfalls ein Hintergrundtest in der Burg (siehe drei Screenshots). Die Laufzeit ist um gut 7 Stunden (ca. 11%) kürzer. Bei der Energie von 2,486 MeV erhalte ich 21 Impulse oder 0,000100 cps (1 Impuls alle 2,67 Stunden), bei 2,6 MeV 28 Impulse oder 0,000134 cps (1 Impuls alle gut 2 Stunden) - also vergleichbare, wenn auch etwas niedrigere Werte. Die maximale Impulszahl in den untersten Kanälen beträgt fast exakt 1000. Der höchste Kanal zeigt 3860 Impulse an. Der Maßstab ist ebenfalls logarithmisch. Der Unterschied ist, dass ich die Windowssoftware benutze. Vor einigen Stunden betrug die mittlere Zählrate (manuell bestimmt mangels automatischer Erfassung) ca. 0,23 cps über alle 256 Kanäle.

Beide Spektren zeigen übrigens einen Knick bei ca. 2,3 MeV: links davon befindet sich eine fallende Linie, rechts davon eine schwach ansteigende.

Was mich jedoch sehr irritiert, sind die Maßzahlen der Skalierung im Smartphone. 100000 Impulse in Kanälen bei 100 keV?? Ich habe da gerade mal 1% davon!? An der logarithmischen Einstellung kann es nicht liegen, die muss die Zahlen dennoch korrekt wiedergeben. Wo liegt der Fehler? Meine Zahlen habe ich durch manuelle Addition ermittelt und bestätigt.

[Samarskit]

PS PS:
Hier ist noch ein Artikel: https://ludlums.com/images/data_sheets/Geo%20Explorer%20Article.pdf 
Verwendet wird ein 5 x 10 x 40cm NaI(Tl), also 2000 cm³. Dieser hat im 2615 keV Kanal eine Zählrate von 1-2 cps... runtergebrochen auf das Volumen des RadiaCode-Kristalls wären hiernach bei diesem ca. 2,7 counts pro Stunde zu erwarten.
Das heißt, wenn man 20-30 Minuten mit dem RadiaCode misst, sollte schon ein einziger Count dabei sein. Und der wird dann durch die exponentielle Skalierung als Peak angezeigt.

Die Zahlen der beiden HG-Spektren zeigen, dass man ganz so proportional nicht rechnen kann. Selbst wenn ich davon ausgehe, dass der Ludlum ebenfalls die normale HG-Strahlung misst, so ist er durch seine Größe doch im Vorteil gegenüber dem Winzling im RadiaCode. Das hast du ja bereits vermutet. Der "Verlustfaktor" in Höhe von ca. 5 hält sich aber erstaunlich in Grenzen, finde ich. Das hängt vermutlich damit zusammen, dass der punktuell in einem einzigen Atomkern ablaufende Photopeak doch relativ häufig erfolgt (bei diesen Geometrieverhältnissen wären es über den Daumen gepeilt so etwa 20%). Die restlichen 80% schafft dann der Riesenkristall durch Addition fast gleichzeitig ablaufender Teilenergieabsorptionen. Die entgehen dem Winzling, weil das Photon den Würfel zu früh verlässt.

[DL3HRT]

Was mich jedoch sehr irritiert, sind die Maßzahlen der Skalierung im Smartphone. 100000 Impulse in Kanälen bei 100 keV?? Ich habe da gerade mal 1% davon!? An der logarithmischen Einstellung kann es nicht liegen, die muss die Zahlen dennoch korrekt wiedergeben. Wo liegt der Fehler? Meine Zahlen habe ich durch manuelle Addition ermittelt und bestätigt.

Die Integrationszeit war mit ca. 235000 Sekunden sehr lang. Der RadiaCode lag nicht in der Bleiburg und brachte zwischen 6 und 8 cps. Multipliziert mit der Messzeit ergibt das eine Gesamtzahl im Bereich von 1,5  .. 1,8 Millionen Impulsen. Das passt schon, da sich das Maximum auf einen schmalen Bereich konzentriert.

[Samarskit]

Die Integrationszeit war mit ca. 235000 Sekunden sehr lang. Der RadiaCode lag nicht in der Bleiburg und brachte zwischen 6 und 8 cps. Multipliziert mit der Messzeit ergibt das eine Gesamtzahl im Bereich von 1,5  .. 1,8 Millionen Impulsen. Das passt schon, da sich das Maximum auf einen schmalen Bereich konzentriert.

Alles klar. Das ist dann ein Verhältnis von ca. 30 : 1 für die Zählraten in cps. Dann wundert es mich auch nicht mehr, dass dein Spektrum viel  geglätteter erscheint als meines - sowie die Tatsache, dass bei dir der K40-Peak ebenfalls viel deutlicher herauskommt. Dennoch interessant, dass der "Knick" bei 2300 keV bei beiden Spektren fast identisch aussieht.

Ich habe mal vorhin nachgeschlagen: Oberhalb von 2300 keV kommen als natürliche Nuklide eigentlich nur noch Tl208 (2615 keV) und Bi214 (sehr viele verstreute Emissionen bis knapp 3300 keV, der intensivste mit 1,57% bei 2448 keV) in Frage. Ob die aber an dem Anstieg wesentlich beteiligt sind, da habe ich meine Zweifel.

[Samarskit]

Dieser hat im 2615 keV Kanal eine Zählrate von 1-2 cps... runtergebrochen auf das Volumen des RadiaCode-Kristalls wären hiernach bei diesem ca. 2,7 counts pro Stunde zu erwarten.
Das heißt, wenn man 20-30 Minuten mit dem RadiaCode misst, sollte schon ein einziger Count dabei sein. Und der wird dann durch die exponentielle Skalierung als Peak angezeigt.

Mir fiel dazu noch ein, dass die Raten ja auch von der Gesamtzahl der Kanäle abhängen bzw. von der Breite jedes Kanals. Bei 256 Kanälen wie z.Zt. im RadiaCode beträgt die Kanalbreite knapp 12 keV. Bei 1024 Kanälen wären es nur noch 4 keV, was die Zählrate auf etwa den vierten Teil reduzieren würde. Mit wie vielen Kanälen arbeitet das Ludlumsystem denn? Davon hängt ja jede Vergleichsrechnung ab, wenn man von einzelkanalbezogenen Zählraten ausgeht, wie du sie oben beschreibst.

[Henri]

Mit wie vielen Kanälen arbeitet das Ludlumsystem denn? Davon hängt ja jede Vergleichsrechnung ab, wenn man von einzelkanalbezogenen Zählraten ausgeht, wie du sie oben beschreibst.

Mit 4

Das Ludlum-System hat keinen MCA, sondern diskriminiert Fenster raus. Da ist dann alles drin, was zur zu überwachenden Energie gehört.

Beim RadiaCode bin ich in meinem Beispiel davon ausgegangen, dass nach einer Stunde mal ein Impuls  da oben aufschlägt und rechts und links gähnende Leere herrscht. Dann ist der Peak sozusagen in dem einen Impuls. Es war ja nur eine rechnerische Abschätzung, ich habe (mangels RadiaCode, der immer noch im Zoll hängt) keine eigene Messung hierzu machen können.

Prinzipiell ist das aber natürlich eine wichtige Aussage: hat mein MCA mehr Kanäle bei gleichbleibender Energieauflösung, muss ich auch mehr Kanäle aufsummieren, um alles zu erfassen, was zum Peak dazugehört. Es zählt ja nicht die Impulssumme im höchsten Peak (außer vielleicht bei einem Germaniumdetektor ), sondern die Fläche unter dem Peak.

Viele Grüße!

Henri