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

[DG0MG]

Thank you for sharing the files. There is no aop on Android phones. Is there any sharing? Thank you

This works for you?

https://apkgk.com/de/com.almacode.radiacode/download

[JoergK]

    Danke!

[pangeiger]

Ich habe heute mal auf die Schnelle zwei unterschiedliche Messungen
a) mit dem FH 40 F2 und
b) dem RadiaCode-101 durchgeführt.

Messobjekt 1 - kleiner Uraninit: Werte bei a) signifikant höher
Messobjekt 2 - Glüchstrumpf: b) zeigt doppelt so viel an wie a)

Schönen Restabend
Peter

[SAL-87]

Vorweg möchte ich kurz erwähnen, dass ich von dem RadiaCode sehr begeistert bin. Gute Verarbeitung, sehr angenehme Größe, Tracking, tolle Android App, sehr gut programmierte und für den 1 cm³ Kristall super umgesetzte Spektrometriefuntion.
Über den Preis für dieses tolle Gesamtpaket braucht man wohl kein Wort zu verlieren. 

Allerdings irritieren mich die wirklich sehr großen Unterschiede bei der Dosisleistungsanzeige gegenüber dem Automess.
772 µSv/h bei einem Gerät, das wirklich nur die reine Gammadosisleistung anzeigt gegenüber 329 µSv/h bei dem Radiacode, welcher auch deutlich auf Betastrahlung reagiert passen einfach nicht zusammen.
Aufgrund der Tatsache, dass bei Pechblende wegen den niedrigen Energien ohne Energiekompensation und der zusätzlich registrierten Betastrahlung deutlich mehr als beim Automess angezeigt werden sollte, muss doch irgendwo noch der Wurm drinnen sein.
Falls ich diesbezüglich einem Denkfehler unterliegen sollte, bitte korrigiert mich.
Interessant wäre wenn jemand ähnliche Messungen mit seinem Radiacode und einem Gerät aus dem profesionellen Bereich nachstellen könnte.
Vielleicht hat ja mein Radiacode einen weg  Davon gehe ich aber nicht aus.




Und nun ein kleines Update zu den Messungen:

Diesmal wurden drei verschiedene Strahler verwendet. Bei einem alten Flugzeuginstrument mit Radiumfarbe waren die Messergebnisse weitestgehend identisch.
Bei den WT-20 Elektroden und einem kleinen Stückchen Pechblende traten jedoch wieder große Unterschiede auf.
Da alle drei Kandidaten keine möglichst kleinen Punktsrahler sind und die Aktivitäten sowie die daraus resultierenden Abstände zum Objekt eher gering ausfallen, lassen wir das Abstandsquadratgesetz mal außen vor.


WT-20 Elektroden

Automess
Abstand / DL
32 cm  -  0,13 µSv/h
16 cm  -  0,22 µSv/h
8  cm  -  0,48 µSv/h
4  cm  -  1,17 µSv/h
2  cm  -  1,72 µSv/h
0  cm  -  3,45 µSv/h

Radiacode
Abstand / DL
32 cm  -  0,17 µSv/h
16 cm  -  0,21 µSv/h
8  cm  -  0,35 µSv/h
4  cm  -  0,51 µSv/h
2  cm  -  0,72 µSv/h
0  cm  -  1,39 µSv/h


Radiumfarbe

Automess
Abstand / DL
32 cm  -  0,25 µSv/h
16 cm  -  0,46 µSv/h
8  cm  -  1,67 µSv/h
4  cm  -  4,25 µSv/h
2  cm  -  9,57 µSv/h
0  cm  -  22,1 µSv/h

Radiacode
Abstand / DL
32 cm  -  0,28 µSv/h
16 cm  -  0,55 µSv/h
8  cm  -  1,45 µSv/h
4  cm  -  3,73 µSv/h
2  cm  -  8,17 µSv/h
0  cm  -  19,3 µSv/h


kleine Pechblende
Automess
Abstand / DL
32 cm  -  0,42 µSv/h
16 cm  -  1,22 µSv/h
8  cm  -  3,17 µSv/h
4  cm  -  6,00 µSv/h
2  cm  -  9,81 µSv/h
0  cm  -  16,9 µSv/h

Radiacode
Abstand / DL
32 cm  -  0,38 µSv/h
16 cm  -  0,78 µSv/h
8  cm  -  1,72 µSv/h
4  cm  -  3,44 µSv/h
2  cm  -  5,39 µSv/h
0  cm  -  8,97 µSv/h


Auf den Fotos im Anhang wird deutlich, dass der Radiacode zwar nicht extrem aber doch deutlich auf Betastrahlung reagiert.
Das Spektrum der Perlen wurde dementsprechend mit einer 3mm starken Aluplatte zur Abschirmung aufgenommen und gefällt mir sehr gut ( nicht in der Bleiburg, einfach an der frischen Luft im Garten. Praktisch  ).


Grüße
Marcel

[Henri]

Zu den Unterschieden zwische RadiaCode und Automess:

ich weiß nun nicht, wie der Radiacode konstruiert ist. Er muss ja die Peakhöhen messen. Normalerweise hat man dafür zwei Wege: einmal direkt, wie z.B. im Oszilloskop, das dann aber eine sehr hohe Abtastrate braucht, denn man will ja die genaue Peakhöhe sehen, und nicht die Stelle kurz davor oder danach. Sonst bekommt man keine gute Auflösung. Das ist von der Elektronik her sehr teuer und voluminös, aber natürlich auch sehr schnell. Die AD-Wandler in normalen Microcontrollern arbeiten viel zu langsam, um so was leisten zu können.

Der "klassische" Weg ist eine Sample-Hold-Schaltung. Der Impuls wird in einem Kondensator zwischengespeichert, indem er ihn auflädt. Wurde ein Impuls registriert, erhält der Microcontroller einen Interrupt und macht eine AD-Wandlung der Spannung im Kondensator. Diese ist meist nicht so genau, das heißt man macht die mehrfach hintereinander und mittelt dann, wenn man ein präziseres Ergebnis haben möchte. Auch braucht der AD-Wandler für seine Arbeit etwas Zeit. Sobald er fertig ist, schaltet der Controller einen Ausgang, und der Kondensator wird entladen und ist bereit für den nächsten Impuls.

Das heißt, bei hohen Zählraten kann man aufgrund des langsamen Vorgangs nicht jeden Impuls erfassen. Bzw. man erfasst ihn zwar, denn der Zähl-Interrupt geht ja ein, aber man kann keine AD-Wandlung durchführen. Das ist jetzt nicht sonderlich schlimm, denn statistisch mittelt sich das raus, und wenn man diese "Totzeit" kennt, kann man das auch rechnerisch kompensieren.

Nun ist die Frage, aus welchem Wert (Anzahl eingehender Interrupts, oder Anzahl gemessener Pulshöhen) der RC seine Dosisleistungswerte ermittelt.

Jedenfalls hat der Controller aber jede Menge zu tun, und so ein Szintillator erzeugt ja immense Pulsraten bei hohen Dosisleistungen. So ein Interrupt braucht aber eine gewisse Länge, um überhaupt registriert werden zu können. Wenn man keinen analogen Vorteiler benutzt, kommt man ziemlich schnell an seine Grenzen. Professionelle Geräte, die einen weiten Messbereich abdecken möchten, haben für hohe Dosisleistungen deshalb z.B. noch ein kleines Geigerzählrohr verbaut, das dann einspringt, wenn der Szintillator überlastet ist.


Dass der RC mehr als die 300µSv/h messen können soll, kann ich mir ehrlich gesagt nicht vorstellen. Zumindest wenn keine analoge Vorverarbeitung erfolgt, die dann aber die Pulshöhendetektierung ausschließen dürfte.


Der RC macht ja ca. 5 cps pro 100 nSv/h, also 15.000 cps bei 300 µSv/h. CsI(Tl) ist ein langsamer Szintillator, mit ca. 4 µs Pulsanstiegszeit und 1 µS Zerfallskonstante.

https://www.crystals.saint-gobain.com/products/csitl-cesium-iodide-thallium

Also kann man vielleicht jede 10 µs einen Impuls registrieren. Das sind pro Sekunde also 100.000. Das heißt, hier ist rechnerisch schon mal bei 2 mSv/h Schluss, allein durch das Szintillatormaterial. Und diese Impulse sind ja nicht gleich weit auseinander, sondern statistisch "zufällig" verteilt. Sehr kurz hintereinander kommende Impulse verschmelzen dann zu einem längeren. Dieser Effekt dürfte sich schon sehr deutlich bei einiges weniger als den 100.000 cps auswirken. Also müsste man hier auch noch für jeden Einzelimpuls die Pulslänge bestimmen, oder zumindest ein statistisches Modell haben, um das rechnerisch zu kompensieren. Das wird bei hohen Zählraten dann aber sehr ungenau, weil sich ja beliebig viele Impulse in einem Intervall einer bestimmten Länge überlagern können.

Als CPU dient ein ARM Cortex-M3, der ja ein schnelles Interrupt-Handling hat, aber um genauer herauszufinden, was der abarbeiten kann, müsste man den genauen Typ und Taktung wissen.


Viele Grüße!

Henri

[Samarskit]

Professionelle Antwort eines Elektronikkenners!

Da kann ich nicht mithalten - aber was die Statistik betrifft, unterstütze ich das Argument mit der Nichterreichbarkeit der rechnerisch möglichen Maximalzahl von 100000 cps. Genaue Funktionen habe ich da
auch nicht, aber aus Erfahrung mit meinem Theremino-System, bei dem die Totzeit der Audiokarte bis zu
100 µs beträgt, was zu einer rechnerisch möglichen maximalen Rate von 10000 cps führt, ist bereits bei
ca. 3000 cps Schluss mit lustig. Alle noch höheren Zählraten führen überwiegend zu Doppel-, Dreifach- oder sogar Mehrfachpeaks, die als Artefakt mit auf dem Spektrum erscheinen. Wenn man dann noch die Prüfroutine für
die Gültigkeit eines Impulses einschaltet, kommt man im Endeffekt auf nicht mehr als ca. 800 cps, also
weniger als 10% der Maximalrate.

Das muss sich bei CsI und der RC-Software natürlich nicht so extrem auswirken, aber es ist mal ein Wert, mit
dem verglichen werden kann.

[Samarskit]

Prost auf ein neues großes Update

Hier ist keine kurze Liste dessen, was sich geändert hat

1 Komplett neu gestalteter Hauptbildschirm der Anwendung, Grafiken können jetzt bequem gescrollt werden, die Grafiken selbst sind viel informativer geworden und in den ersten 10 Minuten der Grafik können Rohdaten oder auf Wunsch mit unterschiedlichem Mittelwert angezeigt werden. Wir haben auch einen Modus zur Darstellung des Graphen in einer Quadratwurzel hinzugefügt, der in vielen Szenarien die logarithmische und lineare Darstellung übertrifft.
Durch Doppeltippen auf das Diagramm ändert sich nun die Anzeige, Linear - Logarithm - Root.
Die Dicke der beiden Graphenlinien und die Schriftgröße sind nun einstellbar und der Messfehler wird angezeigt.

2 Der Alarmalgorithmus des Geräts wurde neu gestaltet, wodurch fast vollständig zufällige Trigger und Einbrüche auf dem Chart eliminiert wurden!

3 Der Gerätespeicher ist nun nichtflüchtig, das Spektrum verschwindet nach dem Ausschalten oder Flashen nicht!

4 Beim Erfassen des Spektrums werden die Werte im CPS (und in der Spektrumbibliothek) angezeigt
Dies hilft dabei, genaue Messungen durchzuführen, während kein * Messung *-Modus vorhanden ist, und macht den Hintergrund beim Wählen des Spektrums deutlich.

5 Erneut haben wir die Arbeit von Bluetooth verbessert, Problemgeräte, Lg / Honor sollten funktionieren.

6 Beim Mapping wird der Kilometerstand der Strecke angezeigt (und in der Streckenbibliothek)

7 Option "Beim Mapping wird sofort ein Punkt (Marker) gesetzt, wenn ein Alarm ausgelöst wird" hinzugefügt

8 Das Mapping ist viel weniger batteriehungrig geworden, insbesondere für große Strecken.
(Vor allem in Verbindung mit den mitgelieferten Mapping-Optionen "Marker ausdünnen" und "Marker nicht außerhalb der Grenzen hinzufügen...")

9 Wir haben die Log-Bugs entfernt, und der neue Algorithmus hatte einen guten Einfluss auf die Log-Lesungen, da sie eng miteinander verbunden sind.

10 Optimiert für die strengen Anforderungen von Android 11, funktioniert in der neuen Umgebung alles wie es soll.

11 Sie haben gefragt, Option, * den Smartphone-Bildschirm nicht ausschalten, wenn die Anwendung aktiv ist *

12 In der neuen Version werden die Spektren beim Senden mit dem Namen gespeichert, den Sie ihnen in der Bibliothek gegeben haben

13 Die Position der Statusanzeigen des Geräts wurde geändert, jetzt sind sie in allen Modi verfügbar

14 Viele Fehler behoben, vergessen Sie nicht, Fehlerberichte zu senden, sobald Sie einen Fehler feststellen, es hilft sehr.

15 Möglichkeit hinzugefügt, die Kalibrierungskoeffizienten gespeicherter Spektren in der Bibliothek zu bearbeiten.

Die lange Liste der Änderungen gibt leider nicht an, was davon für die Androidsoftware gedacht ist, was für
die Windowssoftware, und was für beide Softwarebereiche gilt.

Nach Installation der neuen Versionen habe ich einen Skalierungsfehler in der Windows-Software entdeckt, den
ich nicht durch irgendwelche "Klicks" auf Maus oder Buttons ändern kann:

Die Schwankungen für die Zählraten- und DL-Graphen sind viel zu hoch im Vergleich zu der logarithmischen Skalierung der vertikalen Achse. Bis zur vorletzten Funktion waren die Verläufe noch sehr glatt und stimmten
mit den Maßzahlen der Achse überein.

Ist da was übersehen worden? Ich füge zwei Bilder ein.

[Samarskit]

Ich war neugierig herauszufinden, wie lange es der Akku schafft, in einem Non-Stop-Lauf
bis zum automatischen Abschalten durchzuhalten.

Dazu habe ich ihn in meine Bleiburg gelegt und nur das notwendige interne Display laufen gelassen (in der Stellung "Zählrate"). Ton und LED waren deaktiviert.

Bei einer Zählrate von ca. 0,25 cps betrug die Laufzeit satte 540 Stunden (exakt: 539,5 +/- 0,5 Stunden)!!

Das ist nicht von schlechten Eltern, will ich meinen. Es zeigt aber auch, wie energiehungrig all die
anderen zuschaltfähigen Hilfen und Anwendungen sind.

Interessant wäre jetzt vielleicht noch ein zweiter Lauf außerhalb der Burg mit normaler Umgebungsaktivität,
also bei Zählraten von ca. 6 cps bis 15 cps, je nach Wohnort und individueller Umgebung.

Durch Vergleich mit der ersten Laufzeit könnte man dann den Einfluss der Zählrate auf den Energieverbrauch ermitteln.

[Samarskit]

Zum Schluss für heute noch eine Antwort auf die Anregung von opengeiger, einen Vergleichstest durchzuführen
mit H3-Bremsstrahlung. Er wollte wissen, ob sein Ergebnis real ist oder ein Artefakt.

Antwort: Es ist real!

Zwar habe ich bei meinem Test es nicht geschafft, die Emission auf einen einzigen Kanal zu konzentrieren, sondern habe die beiden ersten Kanäle fast gleich hoch erhalten. Das muss aber kein Widerspruch sein.
Der Peak der H3-Bremsstrahlung überstreicht aus theoretischen und physikalischen Gründen nur einen ganz engen Energiebereich so etwa zwischen 8keV und 18keV. Alles unterhalb von 8keV wird bereits innerhalb durch den ZnS-Leuchtstoff und das Glas absorbiert, alles oberhalb von gut 18keV wird durch das Emissionsmaximum der Betas begrenzt. Die (leider immer noch nur) 256 Kanäle des Spektrums führen zu einer Kanalbreite von über 11keV. Ist die Kalibrierung nun derart, dass das Maximum des Peaks genau in die Mitte des Balkens fällt,
dann reicht ein Balken zur Darstellung der gesamten Emission aus. Liegt es aber genau an der Grenze zwischen
zwei  Balken, dann werden beide Kanäle relativ gleich hoch gefüllt. Möglicherweise liegen bei opengeiger und mir beide Fälle in fast idealer Weise vor.

Im Anhang mein Spektrum. Der linke Rand des ersten Balkens zeigt bei mir ca. 10keV, die Mitte zwischen den beiden hohen Balken ca. 22keV. Das bedeutet, dass mein RC schlecht kalibriert ist (an dieser Stelle ca. 10keV zu hoch). Die Nettozählrate betrug ca. 1,27 cps.

Den dritten Balken/Kanal würde ich nicht mehr zu H3 rechnen. Allenfalls liegen hier Sonderemissionen vor durch Überlagerung.

[opengeiger.de]

Die AD-Wandler in normalen Microcontrollern arbeiten viel zu langsam, um so was leisten zu können.

Irgendjemand im Forum hat geschrieben im RC101 ist ein STM32L475 verbaut. Und ich meine, im Video "von dem mit den blauen Handschuhen" auch einen STM32 Baustein gesehen zu haben. Der STM32L475 hat drei 12bit ADCs, die im interleaved mode mit 5 Megasamples pro Sekunde laufen können. Die Prozessor Taktrate der L4 Serie ist 80MHz. Das war also einmal, dass MCU ADCs langsam waren. Es ist ja auch so, dass man nach dem TIA hinterm SiPM erst mal eine Pulsformung macht, was letzten Endes dann die maximale Pulsrate bestimmt. Also nehmen wir mal an, die Zeitkonstante des Pulse Shapers ist ne Mikrosekunde (wenn der Kristall, der SiPM und der TIA schnell genug wären), und man würde mit dem ADC die Impulsantwort des Pulse Shapers mit einem Oversamplingfaktor von 5 abtasten, dann könnte man immer noch eine Impulsrate von 200k Pulse pro Sekunde erreichen. Und der Code, der da auf dem STM32 läuft und die Pulshöhenklassifizierung macht, läuft ja nicht unter MS Windows, man kann sowas auch in Assembler schreiben, wenn es schnell sein soll. Der Sample&Hold ist heute bei jedem ADC ein Teil des Wandlers selbst und sitzt am Eingang auf dem Chip damit die Kapazität so klein wie möglich wird. Er definiert die Aperturzeit des Wandles (18.75ns beim ST32L475), und damit die analoge Bandbreite. Die ist bei jedem vernünftigen Wandler wenigstens doppelt so hoch wie die Abtastrate, sonst tut ja so ein Wandler nicht recht (Aliasing-Problem). Von daher würde ich zumindest der RC101 Hardware das schon zutrauen. Aber ja, mit einer entsprechenden SW bekommt man natürlich jede HW-Performance kaputt.

Beim Vergleich von Instrumenten nach einer ordentlichen Kalibrierung sollte man doch vor allem die Strahlungsgeometrie beachten. Von meinem Gefühl her wäre schon ein Abstand von wenigstens 1m nötig, vor allem, wenn das Vergleichsinstrument ein etliche Zentimeter langes energiekompensiertes Zählrohr verwendet oder gar einen großen Plastik-Szintillator wie beim 6150AD von Automess.  Wie sah denn die Mess-Geometrie genau aus und welches Vergleichsinstrument von Automess wurde verwendet? War das Vergleichsinstrument geeicht? Oder war es kalibriert, und wenn ja wie? Ein Vergleichsinstrument (selbst ein eichfähiges von Automess) kann ja auch beliebig falsch messen. Ich denke das müsste noch erklärt werden, bevor man Zweifel säht, oder nicht?

[Henri]

Die AD-Wandler in normalen Microcontrollern arbeiten viel zu langsam, um so was leisten zu können.

Irgendjemand im Forum hat geschrieben im RC101 ist ein STM32L475 verbaut. Und ich meine, im Video "von dem mit den blauen Handschuhen" auch einen STM32 Baustein gesehen zu haben. Der STM32L475 hat drei 12bit ADCs, die im interleaved mode mit 5 Megasamples pro Sekunde laufen können. Die Prozessor Taktrate der L4 Serie ist 80MHz. Das war also einmal, dass MCU ADCs langsam waren. Es ist ja auch so, dass man nach dem TIA hinterm SiPM erst mal eine Pulsformung macht, was letzten Endes dann die maximale Pulsrate bestimmt. Also nehmen wir mal an, die Zeitkonstante des Pulse Shapers ist ne Mikrosekunde (wenn der Kristall, der SiPM und der TIA schnell genug wären), und man würde mit dem ADC die Impulsantwort des Pulse Shapers mit einem Oversamplingfaktor von 5 abtasten, dann könnte man immer noch eine Impulsrate von 200k Pulse pro Sekunde erreichen. Und der Code, der da auf dem STM32 läuft und die Pulshöhenklassifizierung macht, läuft ja nicht unter MS Windows, man kann sowas auch in Assembler schreiben, wenn es schnell sein soll. Der Sample&Hold ist heute bei jedem ADC ein Teil des Wandlers selbst und sitzt am Eingang auf dem Chip damit die Kapazität so klein wie möglich wird. Er definiert die Aperturzeit des Wandles (18.75ns beim ST32L475), und damit die analoge Bandbreite. Die ist bei jedem vernünftigen Wandler wenigstens doppelt so hoch wie die Abtastrate, sonst tut ja so ein Wandler nicht recht (Aliasing-Problem). Von daher würde ich zumindest der RC101 Hardware das schon zutrauen. Aber ja, mit einer entsprechenden SW bekommt man natürlich jede HW-Performance kaputt.

Da war ich wohl nicht mehr ganz auf dem Stand der Technik...    Erstaunlich, was mittlerweile (noch dazu für sehr wenig Geld) geht, und Danke für die Richtigstellung!

Viele Grüße!

Henri

[SAL-87]

Ich denke das müsste noch erklärt werden, bevor man Zweifel säht, oder nicht?

Hört sich ein bisschen an wie ein eingeschnappter Produktmanager    aber das ist ja nicht der Fall 

Es geht nicht darum Zweifel an der Tauglichkeit des RadiaCode zu sähen sondern um einen konstruktiven Austausch darüber, wie die großen Unterschiede zu erklären sind.
Die Messgeometrie kann den vorherigen Beiträgen entnommen werden. Wenn du diesbezüglich Anregungen oder eine Idee zur Verbesserung des Versuchsaufbaus hast, bin ich für jeden Vorschlag offen und dankbar. 
Eine Strahlenquelle um den Versuch im Abstand von 100 cm aufwärts sinnvoll wiederholen zu können steht mir jedoch leider nicht zu Verfügung. Schade eigentlich. 

Von einem Hobbygerät erwarte ich auch gewiss nicht, dass es bei einer hohen Dosisleistung, wie sie bei der großen Pechblende gemessen werden kann, mit einem 7 mal teureren Gerät aus dem professionellen Sektor mithalten muss. Aber solch große Unterschiede, zumal der RadiaCode laut Hersteller mit einer maximalen Dosisleistung von einem Millisievert/h angegeben ist, verwundern mich dann schon.

Das ist aber auch gewiss nicht die Stärke des RadiaCode und die Vorzüge dieses kompakten Gerätes mit Szintillator liegen natürlich darin, kleinere Veränderungen gegenüber der Hintergrundstrahlung schnell feststellen zu können. Und das macht der RadiaCode. Sehr gut sogar.

Wie sah denn die Mess-Geometrie genau aus und welches Vergleichsinstrument von Automess wurde verwendet?

Siehe die vorherigen Beiträge. Aber gerne nochmal. Es war ein Automess 6150 AD6/E. Ohne externe Sonde, wie man auf den Fotos auch sehen kann.

War das Vergleichsinstrument geeicht? Oder war es kalibriert, und wenn ja wie?

Geeicht nicht.
Kalibriert selbstverständlich. Wie standardmäßig  jedes 6150AD welches das Hause Automess verlässt.
Eine Eichung sagt auch nicht aus, dass das geeichte gerät genauer wäre. Jedes Gerät, egal ob es danach zum Eichamt geht oder nicht, wird gleich sorgfältig kalibriert.

vor allem, wenn das Vergleichsinstrument ein etliche Zentimeter langes energiekompensiertes Zählrohr verwendet

Das ist genau der Punkt. Ist es möglich, dass die großen Unterschiede daher kommen? Bei einem sehr kleinen Abstand zum Messobjekt kann ich mir das gut vorstellen. Aber auch im Abstand von 35 cm zu der großen Pechblende wurde eine ca. doppelt so hohe Dosisleistung mit dem Automess gemessen. Auch bei einem kleinen Stückchen Pechblende und wesentlich geringerer Dosisleistung sahen die Ergebnisse genau so aus.

Bei einem alten Flugzeuginstrument mit Radiumfarbe lagen die Messwerte zwischen dem Automess und dem RadiaCode über alle Entfernungen jedoch wieder sehr dicht beieinander. Was meines Erachtens nach eher gegen die Theorie spricht, die unterschiedliche Geometrie Zählrohr/Kristall wäre für die Abweichungen verantwortlich.


Grüße und ein schönes restliches Wochenende 
Marcel

[Chinaboy]

Thank you for sharing the files. There is no aop on Android phones. Is there any sharing? Thank you

This works for you?

https://apkgk.com/de/com.almacode.radiacode/download

You can open it and download four installation files. After installing the files with radiation icons, it can't run normally on the mobile phone, and the display is only blank. My mobile phone is Xiaomi Hongmi note8 and Android 11 system. I don't know why. I plan to install ROM with Google play in the next step and try again. Thank you for your help

[Na-22]

Ich habe eine Vergleichsmessung zwischen dem Automess 6150AD6/E und dem RadiaCode auf einem Platz mit Kupferschlackesteinen durchgeführt.
Beide Geräte befanden sich ca. 1 Meter über den Steinen. Zu allen Seiten waren noch mehr als 1 Meter Kupferschlackesteine vorhanden.

Automess: 0,45 µSv/h
RC: 0,72 µSv/h

Das entspricht dem, was man erwarten würde: Der RC zeigt mehr an.

[opengeiger.de]

Hört sich ein bisschen an wie ein eingeschnappter Produktmanager

Ja, weiß nicht so recht, ob ich bei Scan-Electronics in Moskau Produktmanager sein wollte, wär aber bestimmt mal was anderes 

Entschuldige aber, ich hab die Bilder zu den Messdaten nicht gesehen (kommt davon wenn man sich beim lesen der Posts nicht einloggt). Worauf ich nur hinweisen wollte: Man kann auch mit dem teuersten Profimessgerät Mist messen. Auch der Name des Herstellers oder der Ruhm eines Geräts schützt da nicht davor. Es ist auch bekannt, dass eine werksseitige Kalibration bei der Auslieferung nicht notwendigerweise bedeutet, dass man einige Zeit später noch richtig liegt, auch bei einem mega-teuren Gerät nicht.

Ich glaube schon auch, dass es wichtig ist, den Erkenntnissen der Diskrepanz nachzugehen. Aber welches der beiden Geräte nun in einer gewissen Situation wie viel daneben liegt, würde ich vorerst aber doch besser mal offen lassen.

Ich denke z.B. im Fall eines Flächenstrahlers wie bei einem Schlackesteinpflaster könnte eine Richtungsabhängigkeit sichtbar werden. Einmal ist der SiPM ja fast so groß wie eine Fläche des Kristalls. Und unten im Gehäuse liegt ein EMV-Schutzgitter drin. Wenn ich den RC101 nun waagrecht halte, liegt das Schutzgitter zwischen dem Strahler und dem Kristall und der SiPM steht rechtwinklig dazu. Das ist möglicherweise doch eine andere Sitution wie bei einer Kalibration auf einen Punktstrahler, der sich frontal in Richtung der Geräteachse befindet. Das sollte man ausprobieren. Ich habe mich auch schon gefragt aus welchem Material das EMV-Gitter wohl besteht (vernickeltes Kupfer?), möglicherweise kann es zu einer Röntgenfluoreszenz angeregt werden. Wie die Situation beim Automess aussieht, weiß ich nicht. Aber ich vermute mal nicht vergleichbar. Ich denke wir sollten noch mehr Hinweise von verschiedenen Situationen sammeln, bevor man eine Aussage zur Genauigkeit der Messwerte macht. Dennoch halte ich es schon auch für nicht ganz ausgeschlossen, dass es z.B. ein Problem beim RC101 bei hohen Pulsraten gibt, genauso könnte auch die Energiekompesation auch fehlerhaft sein, die er doch mindestens mal bis 1000keV zu machen scheint. Das kann man sicher beim Hersteller anfragen. Vielleicht verrät Scan-Electronics uns auch wie die Kalibrierung gemacht wird. Das wäre sicher spannend zu hören.