DIY Gammaspektrometer mit SiPM

[dekagon]

Das ist zwar schön, aber ich habe die Spannungsreferenz auf die Unterseite gelötet... Also nix für mich, da du ja per default den im Code nicht aktiviert hast.
Oder hab ich was verpasst?

[NuclearPhoenix]

Das ist zwar schön, aber ich habe die Spannungsreferenz auf die Unterseite gelötet... Also nix für mich, da du ja per default den im Code nicht aktiviert hast.
Oder hab ich was verpasst?

Danke für den Hinweis, hab noch eine zweite Version für die Referenz hochgeladen.

[NuclearPhoenix]

Ich habe mir heute mal die Leistung vom Raspberry Pi Pico in Zusammenhang mit CPU Frequenz und Compiler-Optimierung in der Arduino IDE angesehen. Hier die Ergebnisse (der Einfachheit halber Screenshot von der Tabelle auf Hackaday):

Sie dürfen in diesem Board keine Dateianhänge sehen.
Ich bin schon sehr verwundert wie viel man da wirklich noch rausholen kann! In meinem Fall habe ich den Pico auf 250 MHz noch stabil bekommen und da habe ich fast nur mehr die halbe Totzeit! Das ist doch eigentlich genial, dass man einen Mikrocontroller der auf 133 MHz (Standard) getaktet ist, so eben mal auf 250 MHz übertakten kann.

Natürlich muss es nicht so sein, dass man jeden Pico auf 250 MHz bekommen kann. Und vielleicht schaffen es manche sogar auch auf mehr. Jedenfalls ist es wirklich einfach damit herumzuprobieren.
Ich bin sehr gespannt ob sich das irgendwie auf die Langzeit-Stabilität auswirkt. Falls ich da nochmal Probleme bekomme, werde ich sicher davon berichten

[NuclearPhoenix]

Danke an @nukulus für das 3D gedruckte Box-Design! Die Druckqualität ist in diesem Fall noch nicht die beste, weil es mehr ein Probedruck war.

Das ganze Detektor-Board kann man innen anschrauben mitsamt dem darauf installiertem Szintillator. Nach oben und auf die Seite ist Platz genug, damit man theoretisch einen 5 x 5 cm Kristall montieren kann. Einziger Haken dabei ist, dass dieser ebenfalls nicht länger als 5 cm sein darf, sonst kommt man mit der Elektronik in Berührung.

Die micro-USB Buchse vom Pi Pico wird nach außen am Gehäuse mit einem USB Panel-Mount verbunden, in diesem Fall ist am Ausgang eine robuste USB Typ B Buchse.

Die ganzen 3D-Druck Files wird es sehr bald auf GitHub geben. Dazu dann auch die Schraubengrößen, Kabelbuchsen und verschiedene Deckel-Entwürfe.

[NuclearPhoenix]

Die letzten Posts von @Raddet haben mich motiviert in die FW des Geräts auch mal einen TRNG einzubauen

Output können die typischen Datentypen sein (uint8_t, uint18_t, uint32_t), standardmäßig ist es ein uint8_t - also Zahlen von 0 bis 255. Verglichen werden die Zeiten zwischen den letzten beiden Pulsen mit den vorletzten beiden. Ist der Abstand zwischen den letzten beiden größer als der der vorigen, wird eine 0 als Bit geschrieben, andersrum eine 1. Hat man 8 Bits gesammelt, wird die Zahl ausgegeben.

Ich habe das auch mal über Nacht als Test laufen lassen und leider ist die Null als einzige Zahl noch deutlich überrepräsentiert...

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

[NuclearPhoenix]

@dekagon und andere die das Board mit PMTs testen wollen und hier mitlesen:

Das ist mir grade, leider ein bisschen spät aufgefallen, aber ihr müsste den Wert von

Code Auswählen Erweitern

delayMicroseconds(1);
 von 1 mindestens auf eure höchste zu erwartende Pulsdauer/2 ändern. Also bei z.B. 20 µs Pulsen stellt hier am besten

Code Auswählen Erweitern

delayMicroseconds(10);
 oder mehr ein. Sonst triggert der ADC zu früh und ihr bekommt falsche Werte ausgelesen!

Hier ist der Code in dem aktuellsten Arduino Sketch markiert:
https://github.com/Open-Gamma-Project/Open-Gamma-Detector/blob/c48d7cded6a02ae83dea506a05235e752aa821a6/software/opengamma_pico/opengamma_pico.ino#L542

Ich weiß zwar nicht, ob das alle eure Probleme löst, aber anders funktioniert es oft erst gar nicht.

Falls ihr SiPMs mit Szintillatoren benutzt, die ebenfalls eine längere Pulsdauer als vielleicht 1 oder 2 µs haben (also nicht NaI oder schneller), solltet ihr das auf jeden Fall auch ändern!
Ich werde dazu bald noch ein FW Update raushauen, damit man das über die serielle Schnittstelle on-the-go ändern kann, auch um zu sehen wie sich das Spektrum ändert.

[NuclearPhoenix]

Ich werde dazu bald noch ein FW Update raushauen, damit man das über die serielle Schnittstelle on-the-go ändern kann, auch um zu sehen wie sich das Spektrum ändert.

Ist mit FW 2.5.0 erledigt.

[NuclearPhoenix]

Lang ist's her, dass ich hier etwas geschrieben habe. Vielleicht eine kurze Zusammenfassung, was seit dem letzten Mal alles passiert ist. Für die ohnehin gut Informierten unter euch, ist hier wahrscheinlich nichts neues dabei

In der FW 2.5.0 und danach 2.5.1 habe ich nicht nur die letzten hier vorher erwähnten Änderungen implementiert, sondern auch (vor allem) die serielle Schnittstelle ein wenig überarbeitet.

• Für den bereits erwähnten "TRNG" habe ich im Moment leider (noch immer) keine Lösung. Für Vorschläge bin ich immer sehr dankbar!
• Für die serielle Schnittstelle habe ich die Terminalbedienung ein wenig schöner und einfacher gemacht, das sind die "neuen" Befehle:

Code Auswählen Erweitern

> help
Usage:
    <command> [options]
Commands:
    read spectrum    : Read the spectrum histogram collected since the last reset.
    read settings    : Read the current settings (file).
    read info        : Read misc info about the firmware and state of the device.
    read fs          : Read misc info about the used filesystem.
    set trng         : <toggle> Either 'enable' or 'disable' to enable/disable the true random number generator output.
    set display      : <toggle> Either 'enable' or 'disable' to enable or force disable OLED support.
    set mode         : <mode> Either 'geiger' or 'energy' to disable or enable energy measurements. Geiger mode only counts cps, but has ~3x higher saturation.
    set int          : <mode> Either 'events', 'spectrum' or 'disable'. 'events' prints events as they arrive, 'spectrum' prints the accumulated histogram.
    set reset        : <toggle> Either 'enable' or 'disable' for periodic resets of the P&H circuit. Helps with mains interference to the cap, but adds ~4 ms dead time.
    set averaging    : <number> Number of ADC averages for each energy measurement. Takes ints, minimum is 1.
    set delay        : <number> Delay between trigger and ADC readout of pulses in µs. Set this to ~1/2 of the maximum pulse duration you are expecting. Minimum is 1.
    clear spectrum   : Clear the on-board spectrum hist.
    clear settings   : Clear all the settings and revert them back to default values.
    reboot           : Reboot the device.
>
^ Das ist der neue Output, wenn man "help" in die Kommandozeile eingibt. Damit hat man auch gleich überall eine Beschreibung der Funktion dabei und muss nicht extra auf GitHub oder so nachschauen.

Außerdem habe ich die "read info" Informations-Seite überarbeitet. Hier wird jetzt auch die absolute Totzeit pro Puls und die gesamte Totzeit relativ bezogen auf die eingeschaltete Zeit angezeigt. Das ist, finde ich, ein tolles Feature, an dem man schön die Auswirkungen der einzelnen Einstellungen sieht.

Code Auswählen Erweitern

> read info
=========================
-- Open Gamma Detector --
By NuclearPhoenix, Open Gamma Project
2022. https://github.com/Open-Gamma-Project
Firmware Version: 2.5.1
=========================
Runtime: 338.84 s
Avg. dead time: 52.63 µs
Total dead time: 0.13 %
CPU Frequency: 250.00 MHz
Used Heap Memory: 2.02 kB
Total Heap Size: 132.90 kB
Temperature: 24.00 °C
USB Connection: 1
Supply Voltage: 4.80 V
Und zu guter Letzt habe ich die ganze Hardware auch "offiziell" von der Open Source Hardware Association (OSHWA) zertifizieren lassen. Ich kann den Service nur echt jedem empfehlen, der in dieser Richtung entwickelt. Damit ist für den Benutzer und Interessierte eindeutig zu erkennen, dass die gesamte Hardware und dazugehörige Software einem bestimmten Standard der "Offenheit" unterliegt. (Bild ist ein Link)

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

Falls hier jemand hier mitliest und das ganze interessant findet, kann ich euch nur diese Seite ans Herz legen, das ist recht unkompliziert und kostenlos, vorausgesetzt natürlich ihr wollt alles offenlegen

https://application.oshwa.org/

Im Moment bin ich außerdem schon ein wenig am Weiterentwickeln, was die Hardware angeht. Ich bekomme demnächst ein paar neue Teile, um eine neue Detektor-Revision zu testen. Ich halte euch natürlich am Laufenden!

[NuclearPhoenix]

Die letzten Posts von @Raddet haben mich motiviert in die FW des Geräts auch mal einen TRNG einzubauen

Output können die typischen Datentypen sein (uint8_t, uint18_t, uint32_t), standardmäßig ist es ein uint8_t - also Zahlen von 0 bis 255. Verglichen werden die Zeiten zwischen den letzten beiden Pulsen mit den vorletzten beiden. Ist der Abstand zwischen den letzten beiden größer als der der vorigen, wird eine 0 als Bit geschrieben, andersrum eine 1. Hat man 8 Bits gesammelt, wird die Zahl ausgegeben.

Ich habe das auch mal über Nacht als Test laufen lassen und leider ist die Null als einzige Zahl noch deutlich überrepräsentiert...

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

Ich habe heute die Verteilung der Zufallszahlen nocheinmal mit der aktuellen FW aufgenommen (keine Änderung an der TRNG-Programmierung) und diesmal scheint alles in Ordnung zu sein. Diesmal habe ich auch nicht Excel dafür benutzt, sondern die Daten gleich im Gamma MCA Histogramm über die serielle Schnittstelle aufgenommen. Würde hier irgendwie ein systematischer Fehler bestehen, dann sollte der ja eigentlich wieder auftauchen. Da aber hier nix passiert ist, würde ich fast auf einen Fehler bei der 1. Auswertung schließen.

Durchschnitt bei ganz normaler Hintergrundstrahlung ~25 cps, bekomme ich ziemlich genau 1 Zufallszahl pro Sekunde. Aufgenommen wurden 13 Stunden lang, hier ist das Ergebnis:

[nukulus]

cool! erhöhen sich die rate bei stärkerer aktivität?

[NuclearPhoenix]

Ja natürlich. Die aktuelle Implementation braucht 3 Pulse pro Bit und standardmäßig werden ganze 8-Bit Zahlen ausgegeben, also insgesamt 24 Pulse pro Zufallszahl. Du könntest ohne weiteres zum Beispiel auch nur Zahlen zwischen 0 und 7 ausgeben, und würdest mehr als doppelt so viele Zufallszahlen bei der gleichen Rate bekommen.

[RD-Gamma]

Ansonsten werde ich demnächst noch ein paar kleine Verbesserungen machen und auf GH hochladen.

Ich habe die Platine noch nicht lang, und war noch nicht allzu erfolgreich bei der Aufnahme von Spektren, aber zwei Sachen würden mir direkt einfallen.

a) könntest du den Display Header so machen, dass man die kleinen SSD1306 Displays direkt ohne Crossover Kabel einstecken könnte. Sprich GND 3V3 SDA SCL wie es auch am Display ist.

b) wenn ich das Display im Code auf true setze stürzt der Pico bei Zählraten ab circa 30 1/s ab. Dabei blinkt die LED und er wird am PC neu erkannt. Das wiederholt sich im Takt von einigen Sekunden.

[NuclearPhoenix]

Falsches Thema? Glaube du meinst das hier, oder? https://www.geigerzaehlerforum.de/index.php/topic,974.0.html

Ich habe die Platine noch nicht lang, und war noch nicht allzu erfolgreich bei der Aufnahme von Spektren, aber zwei Sachen würden mir direkt einfallen.

Falls gar nichts geht, kann ich dir pauschal empfehlen R4 zu verlöten (falls du das noch nicht gemacht hast) und den Gain möglichst hoch einzustellen.

a) könntest du den Display Header so machen, dass man die kleinen SSD1306 Displays direkt ohne Crossover Kabel einstecken könnte. Sprich GND 3V3 SDA SCL wie es auch am Display ist.

Habe ich schon geändert für die nächste Revision.

b) wenn ich das Display im Code auf true setze stürzt der Pico bei Zählraten ab circa 30 1/s ab. Dabei blinkt die LED und er wird am PC neu erkannt. Das wiederholt sich im Takt von einigen Sekunden.

Danke für den Hinweis, ich benutze das selbst eigentlich nie, deshalb ist mir das noch nicht aufgefallen. Werde mir das mal anschaun und ein FW Update machen.

[NuclearPhoenix]

Hier mal wieder ein kleines Statusupdate. Diesmal mitten in der Entwicklung der Rev 3 Hardware.

Nach ein paar Denkanstößen und einiges an Tests habe ich die Verstärkerschaltung mal vereinfacht und siehe da, die Ergebnisse sind deutlich besser. Win-Win würde ich sagen

Genaueres zur Schaltung und Hardware, wenn ich alles fertig habe, bis dahin kann sich noch was ändern. Anbei wieder einmal ein Spektrum meiner 2 kleinen (4g) LYSO Szintillatoren. Aufgenommen über 30 Minuten und siehe da - Energieauflösung bei 310 keV bei ca. 14%. Muss es nochmal mit ein paar höheren Energien testen, aber das ist schonmal viiiel besser.

Stromverbrauch liegt jetzt bei ca 15 mA ohne OLED (das braucht aber kaum zusätzlich), damit die Leistungsaufnahme also insgesamt bei unter 100 mW. Wahrscheinlich grob die Hälfte davon entfällt noch auf den Pico, da habe ich kaum noch die Software in diese Richtung optimiert.

Und das OLED kann man jetzt auch ganz einfach draufstecken, wie es sich @RD-Gamma gewünscht hat

Muss noch ein paar kleine Änderungen an der Schaltung und Platine machen, aber das geht schon sehr in die richtige Richtung.

Zwei kleine Kompromisse, die ich dafür eingehen musste:

• Die Pulse vom SiPM werden nicht mehr manuell nachverstärkt. Das heißt einerseits, dass es nochmal deutlich einfacher zu handhaben und zu benutzen ist. Andererseits bedeutet das aber natürlich auch, dass der Energiebereich den man erreichen kann und die Auflösung (begrenzt durch den ADC) stärker vom verwendeten Szintillator abhängen. Das sollte aber absolut kein Problem sein, wenn der Szintillator nicht zu klein ist. Ich verwende einen älteren 18 x 30mm NaI. Das ist jetzt nicht wirklich klein, aber auch nicht besonders groß. Sogar die $60, 1" x 1" Szintillatoren aus China haben schon ein größeres Volumen.
• Die SiPM Pulse haben jetzt eine Dauer von ca. 10 µs. Das ungefähr eine Größenordnung langsamer als vorher, dementsprechend auch mehr Totzeit. Ist aber meiner Meinung nach immer noch mehr als vertretbar, v.A. für die anderen Verbesserungen.

Im Anhang ein paar Bilder.

[NuclearPhoenix]

Ich habe heute nochmal eine schöne Vergleichsmessung mit einem alten Rev. 2 Detektor und meinem Rev. 3 Prototypen gemacht. Natürlich wieder mit meinem obligatorischen Lu-176

Gain und SiPM Spannung sind hier identisch, wie man gut anhand der unkalibrierten Aufnahme sehen kann. Beide Detektoren haben auch einen gleichen SiPM (MicroFC 6 mm) und Szinti (russischer 18 x 30 mm NaI(Tl)). Aufgenommen habe ich jeweils 1 Stunde Hintergrund und 1 Stunde mit Lu.

Die beiden Hintergründe sehen prinzipiell sehr ähnlich aus. Man sieht aber, dass das neue Spektrum weiter links beginnt, ein längeres "Plateau" vor der eigentlichen Kurve hat und auch deutlich weiter rechts erst endet (nahe 4096 vs ~3800).

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

Dasselbe Schema sieht man dann auch für das unkalibrierte Lu-176 Spektrum, nur das hier auch der unangenehme Spike des alten Boards am Anfang des Messbereichs wegfällt. Da hätte man auch den Diskriminator höher stellen können, dann wäre der Bereich aber noch mehr eingeschränkt.

Hier sieht man auch die von mir schon angesprochene und deutliche Verbesserung der Energieauflösung. Die Spektren sind jetzt natürlich generell noch ein wenig rau, das liegt einfach an der kurzen Messzeit.

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

Und letztlich das kalibrierte Spektrum; das habe ich gemacht um nochmal den neuen Messbereich hervorzuheben. Das ist sicher nicht die genaueste Kalibrierung (habe nur die 202 und 307 keV Peaks genommen), aber man sieht so auch schon einen deutlichen Unterschied.

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