Gammaspektroskopie Dateiformate

NuclearPhoenix · 07. Januar 2023, 14:34

Im Zuge meiner Bastelei mit den XML Dateien für die Gamma MCA App, habe ich mich gefragt, ob es denn nicht andere Dateiformate gibt, die in der Gammaspektroskopie so üblich sind.

Einerseits gibt es natürlich die ganzen CSV-Typen, bzw. jene die anders heißen, aber trotzdem CSV sind (z.B. TKA). Das ist sicher die weitverbreitetste Methode Spektren zu speichern.

Aber was, wenn man andere Daten mitspeichern möchte? Zum Beispiel Spektrumname, Aufnahmezeit, Gerät, irgendeine Beschreibung, o.Ä.? Dann fällt mir nur mehr der XML Typ ein, der teilweise in der RadiaCode Software implementiert ist und auch im BecqMoni ganz integraler Bestandteil ist. Die XMLs sind natürlich eine gute Sache, aber das Dateiformat ist ziemlich sperrig und die Dateigröße wird sehr schnell sehr groß, je nachdem wie viel man speichern möchte. Beispiel: Meine 4096 Kanal Spektren haben 200 KB, großteils nur wegen den ganzen XML Tags.

Gibt es da sonst noch irgendwas? Wie sieht es da bei Theremino aus? Soweit ich weiß ist das auch nur eine CSV, mit einem kleinem Header oben drauf.

Wie schön die Welt doch wäre, wenn es so ein Dateiformat gäbe, worin man alles speichern kann und welches in den meisten offenen/freien Gammaspektroskopie-Programmen gelesen werden kann. Gibt es sowas? Habe ich das komplett übersehen? Falls ja, lasst es mich bitte wissen!

NuclearPhoenix · 08. März 2023, 15:22

Habe ganz auf dieses Thema vergessen, ups. Hier nur ein kleines Update, damit der Anfangsbeitrag nicht unkommentiert stehen bleibt.

Ich hab mich vor einiger Zeit hingesetzt und mit den BecqMoni XMLs als Vorbild ein neues Format erstellt. Zusammengefasst hat es eine viel kleinere Dateigröße, die Datenstruktur ist genau festgelegt und kann jederzeit geprüft werden. Habe das alles auf GitHub gestellt, das findet man hier:

https://github.com/OpenGammaProject/NPES-JSON

Gamma MCA verwendet dieses Datenformat jetzt schon länger als Standard und die neue "impulse" Software von GammaSpectacular ebenfalls.

Zugpferd · 05. April 2023, 23:45

Hatte ich hier nicht drauf geantwortet oder wollte ich nur?
.spe Mirion HDS101G/N 100G
.cnf Canberra Genie2000

Kermit · 06. April 2023, 12:09

Ich habe mal auf das Programm von Canberra geschaut,

Genie 2000, V3.4 von 2015

CAM Dateien .CNT
Toolkit Dateien .TKA
IEC14ST Dateien .IEC

bei der .TKA Datei habe ich das "Gefühl", genau weiß ich es aber nicht, das die ersten zwei Einträge die Messzeit betreffen (Lifetime und Realtime) und nicht den Kanalinhalten zugeordnet werden. Zumindest beim Import in Excel sieht das so aus.

Peter-1 · 19. November 2023, 11:52

Log-file Daten ?

Ich suche sicher mal wieder an falschen Stellen. Ganz einfache Frage:
Wie komme ich an die gespeicherten Log-Daten ran?
Unter Android - data - com.almacode.radiacode - files
finde ich ein Datensatz .log , aber gibt es eine SW welche daraus Uhrzeit und µSv/h extrahieren kann?
Bisher bin ich keinen Schritt weitergekommen.

Peter

NuclearPhoenix · 19. November 2023, 20:15

Ich bin gerade ein wenig verwirrt über den Beitrag. Bist du sicher, dass das das richtige Thema ist? Eigentlich geht es hier mehr um Dateien in denen die eigentlichen Spektren gespeichert sind. Also die Pulshöhendiagramme, etc., weniger sowas wie programminternen (debug) logs.

Aber du kannst ja mal eine .log Datei hier reinstellen, dann kann man sich anschauen, welche Struktur das hat und welche Daten drin gespeichert sind.

NuclearPhoenix · 03. Dezember 2023, 20:07

In der Zwischenzeit habe ich eine neue Version von meinem kleinen Datei"standard"/format veröffentlicht, die es möglich macht, komplett unabhängig voneinander mehrere Spektren in einer Datei zu speichern. Also ähnlich wie bei den BecqMoni XML-Dateien, nur wirklich 100% isoliert voneinander. Meiner Meinung nach ist das nochmal deutlich weniger fehleranfällig.

Ich habe ein wenig mit Steven von Gammaspectacular und Am6er von BecqMoni hin- und hergeschrieben und beide klangen relativ überzeugt davon soweit ich das beurteilen kann. Mit ein wenig Glück unterstützt BecqMoni vielleicht bald schon das neue Format...

Ich sammle aktuell noch Feedback, mal sehen ob noch was dazukommt. Die genauen Spezifikationen finden sich auf GitHub: https://github.com/OpenGammaProject/NPES-JSON/tree/draft
Ich habe auch schon alles in Gamma MCA umgesetzt. Mit dem neuen Update heute, werden alle JSON Dateien schon in dem Format abgespeichert.

NuclearPhoenix · 27. Januar 2025, 13:53

Nochmal eine Frage in die Runde: Welche Programme nutzt ihr so in Bezug auf die verschiedensten Dateiformate und Geräte? Vor allem an Mitglieder, die mehrere Geräte und Programme von verschiedenen Herstellern nutzen oder selber Bastler sind:

Bleibt ihr eher bei der Software des Herstellers/der Hersteller, weil euch das einfach reicht und/oder ihr das Dateiformat nur dort öffnen könnt?
Oder nutzt ihr hauptsächlich Open-Source Software wie Interspec und BecqMoni, die die verschiedensten Spektren laden können und dadurch einen einheitlichen Workflow ermöglichen?
Oder konvertiert ihr Spektren manuell mit einem Skript oder anderen Programm, um es in bestimmter Software laden zu können? Wenn ja, um welche Dateien und Programme geht es da meistens?

Beispiel: Man hat einen RadiaCode, einen KC761CN und ein selbstgebautes Spektrometer, und damit potentiell 3 verschiedene Dateiformate und Programme. Wie würdet ihr vorgehen?

Weiß leider nicht, ob und wie man eine Umfrage in einem existierenden Thread erstellen kann. Deshalb mal so die offene Frage in den Raum

ullix · 13. März 2025, 12:35

Zitat von: Kermit am 06. April 2023, 12:09Ich habe mal auf das Programm von Canberra geschaut,

Genie 2000, V3.4 von 2015

CAM Dateien .CNT
Toolkit Dateien .TKA
IEC14ST Dateien .IEC

bei der .TKA Datei habe ich das "Gefühl", genau weiß ich es aber nicht, das die ersten zwei Einträge die Messzeit betreffen (Lifetime und Realtime) und nicht den Kanalinhalten zugeordnet werden. Zumindest beim Import in Excel sieht das so aus.

Ich hab sogar das "Gefühl", die ersten 5 Werte in .TKA files passen nicht? Ich lasse die jetzt mal weg.

Aber ich finde da ausserdem die .CNF Dateien. Das scheinen reine Binärdateien zu sein. Kann jemand dazu irgenwelche Info geben?

silfox · 13. März 2025, 13:54

Es gibt das Konversionstool:

https://github.com/sandialabs/cambio

Ich selbst habe es nie genutzt.
Letztendlich enthält jeder Spektrum-File die folgende Information:
acquisition-parameter, energy, shape, efficiency calibration, spectrum data
Eventuelll noch Information zur Peak-Analyse

Ich schreibe mir für jedes Datenformat einen eigenen Konverter und schreibe die Daten in die Datenbank.

ullix · 13. März 2025, 14:38

Zitat von: silfox am 13. März 2025, 13:54Es gibt das Konversionstool: cambio

Seufz - es gibt einfachere Software :-(

Für die eigentliche Konversion scheint das Programm SpecUtils zuständig zu sein. Das hat auch support für .TKA und .CNF Dateien. Wenigstens für TKA findet sich ein befriedigender Comment in Datei 'SpecFile_tka.cpp':

Zitat/*
Simple file with one number on each line with format:
Live time
Real time
counts first channel
.
.
.
counts last channel
*/

Danach wären doch nur die ersten beiden Zeilen Nicht-Counts, wie Kermit "gefühlt" hat. (Aber die nächsten drei Werte bleiben merkwürdig ...).

Der CNF Code ist erheblich komplexer. Darin wird großen Wert gelegt auf das Lesen von PDF-11 files. Wann war PDF-11 nochmal? Im Jahre des Herren AD....

Schaun mer mal.

ullix · 13. März 2025, 15:25

Die SpecUtils sind doch zu komplex. Aber ich habe daraufhin etwas anderes gefunden:
https://github.com/pbellino/CNFreader/blob/master/read_cnf.py

Kommt gleich in Python; wesentlich leichter verdaulich. Ein Cs-137 .CNF File kommt damit so raus:

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

plus diesem Text ins Terminal:

Code Auswählen

==================================================
File Cs-137-5min-4fach-BEGE-07032025.CNF succesfully read!          
==================================================
Sample id: 
Measurement mode: PHA
Number of channels used: 8192
At channel 250:
	 Counts: 40
	 Energy: 57.338159918785095

Damit könnte es gehen. Dank für die Hilfe!

silfox · 14. März 2025, 10:36

Anmerkung zum Datenformat für Spektren:

Am anschaulichsten ist das phd-Datenformat, dass von CTBTO verwendet wird.
CTBTO verwendet Hochvolumensammler.
Es wird einen Tag lang das Filter beaufschlagt, also gemessen (#Collection).
Dann klingt das Filter für einen Tag ab.
Dann wird das Filter zum Detektor geführt und mit einem HPGe-Detektor analysiert (#Acquisition).
Hier findet man dann auch die Angaben zu Realtime und Livetime in Sekunden.
Die Differenz in Sekunden ist die deadtime (Totzeit).
Die Totzeit ist das entscheidende Element im Umgang mit Gamma-Spektren.
Ein guter MCA hat einen schnellen Kanal, der Auskunft gibt, wie viele Photonen den Detektor erreicht haben. Am langsamen Kanal liegt der ADC. Ein ADC benötigt Zeit für die Konversion von Ladung (oder Spannung) in einen digitalen Wert. Je höher die Anzahl an Photonen, die den Detektor erreichen, umso weiter driften schneller und langsamer Kanal auseinander. Ist die Totzeit unbekannt, kann man also nicht aussagen, welche Photonenzahl tatsächlich den Detektor erreicht hat. Man kann also z.B. keine Gamma-Ortsdosisleistung aus dem Spektrum berechnen – das Spektrum ist wertlos.

Die Kalibrierdaten sind in den Blöcken #g_Energy, #g_Resolution, #g_Efficiency enthalten.
Die Kalibrierinformation ist jeweils in Datenpaaren (Energie/keV, Wert, Unsicherheit) abgelegt.
Das hat als Vorteil, dass man für die Weiterverarbeitung eine beliebige Interpolationsfunktion verwenden kann.

#Collection
2011/12/17 06:25:25 2011/12/18 06:25:25 23721.82
#Acquisition realtime livetime
2011/12/19 06:25:30 84872.66 84849.14
#Calibration
2008/09/05 10:27:00
#g_Energy
59.52 165.42 0.1000
122.07 338.79 0.1000
391.70 1085.23 0.1000
661.65 1832.00 0.1000
898.04 2485.85 0.1000
1173.24 3247.12 0.1000
1332.51 3687.81 0.1000
1836.02 5081.04 0.1000
#g_Resolution
59.52 1.0200 0.100000
122.07 1.0700 0.100000
391.70 1.3000 0.100000
661.65 1.5000 0.100000
898.04 1.6700 0.100000
1173.24 1.8600 0.100000
1332.51 1.9600 0.100000
1836.02 2.2800 0.100000
#g_Efficiency
59.52 0.0069600000 0.000050000000
122.07 0.0527400000 0.001090000000
391.70 0.0453200000 0.000600000000
661.65 0.0341300000 0.000300000000
898.04 0.0261900000 0.000200000000
1173.24 0.0218700000 0.000270000000
1332.51 0.0203000000 0.000260000000
1836.02 0.0166600000 0.000210000000
#g_Spectrum
8192 3100
1 0 0 0 0 0
6 0 0 0 0 0
11 0 0 0 0 0
16 0 0 0 0 0
21 0 0 0 0 0
...
8176 8 10 5 12 14
8181 11 6 5 6 8
8186 5 4 4 7 10

Das Datenformat kann man z.B. auch für den Radiacode-Detektor verwenden.
In dem Fall dauert eine Messung z.B. 10 Minuten und es wird gleichzeitig gesammelt und analysiert.
Die Angaben in den Blöcken #Collection und #Acquisition sind also identisch.

Alle anderen Spektren-Datenformate enthalten die gleiche Information.
Sie sind nur anders strukturiert.
Der Umgang mit den vielen unterschiedlichen Datenformaten ist folglich kein inhaltliches Problem.
Man muss sich ansehen, wie die Formatierung aussieht.
Anschließend extrahiert man die relevante Information und dass ist:
#Collection
#Acquisition, realtime, livetime
#Calibration
    #g_Energy
    #g_Resolution
   #g_Efficiency
#g_Spectrum

Und: wenn keine Angabe zur Totzeit enthalten ist, ist das Spektrum für eine inhaltliche Nutzung wertlos!

ullix · 15. März 2025, 09:17

Ich liebe Standards, vor allem bei Dateiformaten! Das beste daran: es gibt so viele !

Zu den times eine Frage. Hier echte Daten aus einem CNF File:

Code Auswählen

GeigerLog Spectro Generator CANBERRA-CNF
Real time:               319.67
Live time:               300.00
Number of channels used: 8192
Counts Total:            568,563

319.67 sec sind auf meiner Stoppuhr abgelaufen, also gab es im Mittel 1 Count pro 562µs. Aber mit Messen beschäftigt war mein System nur die Differenz zwischen Real und Live time, also 19.67 sec. Mithin dauert 1 Messung 35µs? Ganz schön fix!

Deine Sorge ist also, dass Du diese Zeiten kennen musst, um die Dosisrate um diese 6% zu korrigieren?

silfox · **Gestern** um 09:56

Bei allen zählenden Messgeräten, die zur Radioaktivitätsmessung verwendet werden, ist die Totzeit zu berücksichtigen. Das gilt z.B. auch für Geiger-Müller-Detektoren. Bei der (vom Hersteller mitgeteilten) Kennlinie zur Umrechnung von Zählrate in H*(10) wird (soll) dem aber in der Regel bereits Rechnung getragen.

Bei Präzisionsmessungen im Labor (Spurenanalyse, Lebensmittelüberwachung) sollte die Totzeit 1 bis 2 Prozent nicht übersteigen. Es kommt auf die Analyse-Software an, ob der Totzeit Rechnung getragen wird und in welcher Form. Auf jeden Fall ist die Totzeit bei der Berechnung des Messfehlers zu berücksichtigen. In Labors werden ohnehin Maßnahmen getroffen, dass keine ,,heißen" Proben in das Labor gelangen und ggf. die teure Messapparatur kontaminieren.

Bei einer einfachen Klassifizierung kann eine höhere Totzeit akzeptiert werden, wenn es also nur darum geht zu sagen, in der Probe befinden sich künstliche Radionuklide und wie viele. Wenn man aber qualitative Aussagen machen will, muss man die Totzeit in die Berechnung mit einbeziehen.

Noch einmal zurück zum Datenformat.

In den Blöcken #Resolution und #Effiziency sind Werte eingetragen, die charakteristisch für den Detektor bzw. die Messgeometrie sind.

Die Detektorauflösung bestimmt man in der Regel bei Einkauf und dann wiederkehrend nach mehreren Jahren, um eine Alterung des Detektors festzustellen. Man kann das z.B. mit dem WT20 Thorium-Stab machen und dann die Breite der Gauss-Peaks bestimmen und die Koeffizienten in den Datenblock eintragen.

Bei der Effizienz oder Detektor-Response-Funktion ist die Messgeometrie ausschlaggebend. Im Labor ist die Messgeometrie fest vorgegeben. Z.B. presst man das Luftfilter eines Hochvolumensammlers in eine Tablette mit fester Geometrie. Man kann nun ein reines Filter in dieser Geometrie mit Radionukliden bekannter Aktivität (möglichst homogen) verunreinigen, auf den Detektor legen, messen und dann die Detektor-Effizienz bestimmen. Das gilt auch für Lebensmittelproben und Bodenproben, die man in einen Marinelli-Becher auf den Detektor legt (nass, trocken, verascht ...). Alternativ werden inzwischen häufig Monte-Carlo-Simulationen verwendet. Auch bei Insitu-Messungen im Freien (HPGE-Detektor auf dem Kopf auf ein Dreibein gestellt) gibt es feste Regeln, wie man zunächst mit Hilfe einer Punktquelle die Detektoreffizienz bestimmt. Dann multipliziert man diese Funktion mit dem sogenannten Geometriefaktor (analytische Funktion), der abhängig ist von der Annahme, wie tief die Radionuklide in den Boden eingedrungen sind. Anders sieht es aus bei Handmessgeräten. Die Hersteller halten sich oft bedeckt, welche Funktion sie für die Detektoreffizienz verwenden. Meiner Meinung nach sollte/könnte man bei den portablen Geräten die Werte verwenden, die man mit einer Punktquelle erhält (beim RC-103 z.B. die Kennlinie, die von Sandia-Labs bestimmt wurde und in InterSpec verwendet wird).

Da die Blöcke #Resolution und #Effiziency statisch sind, werden sie oftmals bei der Datenweitergabe vernachlässigt bzw. sind optional. Ein einfaches Datenformat, dass auch von InterSpec untersützt wird ist das SPE-Datenformat file:///home/kpc/Downloads/32042415.pdf).

Nun werden inzwischen spektroskopische Detektoren (Spektro-Dosimeter) z.B. im Notfallschutz als stationäre Systeme verwendet. Hier ist die Absicht, neben der ODL, nuklidspezifische Daten zu gewinnen. Letzten Herbst wurde eine Vergleichsmessung unterschiedlicher (auch kommerzieller) Spektro-Dosimeter durchgeführt. Eine erste Analyse hat gezeigt, dass bei einigen Geräten bei der Bestimmung der ODL aus dem Spektrum der Referenzwert um bis zu einen Faktor 2 über-, bzw. unterschätzt wurde und zwar abhängig von der jeweiligen Quelle (also dem jeweiligen Radionuklid). Andere Systeme lieferten recht gute Übereinstimmung. Es wurde ja hier im Forum bereits diskutiert, wie man aus einem Spektrum die ODL berechnen kann. Tatsächlich liefert die inverse Detektoreffizienz keine guten Werte. Bei der PTB wurde ein CeBr3-Detektor als Sekundärstandard für die ODL-Messung empfohlen (https://www.sciencedirect.com/science/article/pii/S0265931X19300633). Dabei wurde nicht zuletzt genau der Frage nachgegangen, wie man aus dem Spektrum die ODL bestimmen kann. Man hat mit recht hohem experimentellem Aufwand Koeffizienten der sogenannten Bandmethode (oder auch Koeffizientenmethode) ermittelt und mit Monte-Carlo-Rechnungen abgesichert. Tatsächlich ähnelt diese Funktion der inversen Detektoreffizienzfunktion: es handelt sich um eine Reihe an Koeffizienten, die man analog des #Effiziency Blocks als weiteren Block (z. B. #Band) dem Datenformat hinzufügen sollte. Die Bestimmung der Koeffizienten ist allerdings ein gesondertes Kapitel. Wegen des hohen experimentellen Aufwands, ist es vermutlich nur mit Hilfe von Monte-Carlo-Rechnungen möglich, diese Koeffizienten in guter Näherung zu bestimmen. Es ist sicher notwendig, dies in Zukunft genauer zu untersuchen, um eine Lösung vorschlagen zu können.