Web-App: Gamma MCA

[NuclearPhoenix]

Im Zuge meiner "DIY-Detektor" Eskapaden bin ich an einem Punkt angekommen, an dem ich eine gescheite Software brauchte, um über den serial port die Daten auszulesen und gleich live in einem Plot anzuzeigen.
Das ganze sollte man natürlich auch wieder mittels Dateien exportieren und importieren können. Außerdem sind die wichtigsten Einstellungen und Möglichkeiten zur Datenbearbeitung auch ein Muss.
Da ich aber speziell im Zusammenhang mit einer seriellen Schnittstelle nichts brauchbares gefunden habe, habe ich mir das einfach selbst programmiert.

Ich stelle vor: Gamma MCA, eine Web App zur einfachen Gamma-Spektroskopie.
https://spectrum.nuclearphoenix.xyz/

Das ganze ist letztendlich eine Website geworden... Damit hat jeder gleich die aktuellste Version, es muss nichts installiert werden - ist somit kompatibel mit jedem Betriebssystem und ich erspare mir viel Arbeit im Zusammenhang mit Installern, Kompatibilität, etc.

Zum jetzigen Zeitpunkt kann man verschiedene Dateiformate importieren und auch wieder exportieren, Verbindungen über den serial port aufbauen, eine lineare Energiekalibration durchführen und die Daten mit einer Liste an typischen Gamma-Energien vergleichen. Einstellungen wie simple-moving average, log-log Achsen und so weiter gibts klarerweise auch.

Und jetzt kommt ihr ins Spiel: Ich brauche im Idealfall ein paar Leute die mir da beim Testen helfen und Feedback geben
Das ganze ist natürlich open-source, somit kann jeder den Code einsehen und daran arbeiten.
Ich hoste das auf GitHub, dort seid ihr herzlich eingeladen issues oder pull requests zu schreiben. Außerdem gibt es dort noch einen Tab für Diskussionen, oder ihr schreibt mir einfach hier drunter.

https://github.com/Open-Gamma-Project/Gamma-MCA

Dort stehen auch noch ein paar letzte Hinweise zur Benutzung, es sollte aber gerade für Leute die sich sonst mit der Materie befassen recht selbsterklärend sein (falls nicht - wie gesagt - bitte schreiben  )

Im Anhang habe ich euch noch eine ZIP angehängt, darin sind verschiedene Dateien von drei separaten Messungen.
Dann seht ihr mal wie die Dateien so aufgebaut sein sollten und welche verschiedenen Formate schon genommen werden:

• Die beiden "pico" CSVs sind Spektrum und Hintergrund eines ~5g schweren LYSO Szintillators (gemessen mit einem NaI Szinti, Selbstbau-Detektor).
  Dazu gibt es noch die calibration.json für die passende Energiekalibration des Detektors. Dann sieht man auch die schönen beiden Lu-176 Peaks und den ~50 keV Röntgenpeak.
• Die TKA file ist eine Messung von Uranglas, gemacht mit einem professionellen Halbleiterdetektor.
• Die letzte Datei ist ein Spektrum eines Walzenglases mit dem RadiaCode gemacht.

Zum Schluss habe ich euch auch noch das fertige Lu-176 Spektrum als png verlinkt. So sollte das dann mit den Daten aus der ZIP aussehen

[rhelectronics]

Very nice!
Just imported a random CSV file from Nuclear Pioneer and it opened without any issue.

is the serial dump example can be used form this sketch?
https://github.com/Open-Gamma-Project/Open-Scintillation-Counter/tree/main/arduino/opensc_pico

[NuclearPhoenix]

Yes exactly, that's the one. I'm using a Raspberry Pi Pico - hence the name. Though the repo that you found is pretty outdated, I'm working on finishing the project by end of February. I'll be posting here again once it's finished.

[rhelectronics]

Thank you.
If I understand your sketch correctly, you are sending each pulse amplitude ADC value by serial once the pulse is detected? And after that wait for the next pulse.
Is it possible to send out the whole data array for example every second? It would be more useful, I think, instead working for a single count event.

[wrdmstr inc.]

coole sache, das csv vom raysid ging zu importieren,backround, 2 kalibrierpunkte gesetzt usw ohne fehler

[NuclearPhoenix]

If I understand your sketch correctly, you are sending each pulse amplitude ADC value by serial once the pulse is detected? And after that wait for the next pulse.
Is it possible to send out the whole data array for example every second? It would be more useful, I think, instead working for a single count event.

Sure that is entirely possible, although you would lose some time information like the deltaT between events.

Maybe sending an array of data every second or so improves the detector deadtime a little bit, though. Might be worth looking into.

[rhelectronics]

Is it possible to add the protocol that will allow to send the data like: channel, counts?
Because the spectrum array in hardware contain accumulated counts in whole array and I would like to send it in the complete array every second.

[NuclearPhoenix]

Don't know if this would be easy to implement without sacrificing a whole lot of cpu time. Printing 4096 channels to the serial interface every second takes a long time compared to the ~100 µs it takes for a single event.

[rhelectronics]

Maybe it depend on the serial port speed? I use 12MBit port.

Big scint like 63x63 can produce thousands of pulses per second from a radiation test source like 1uCi. I'll try your current method to see how it will work with high load CPS and 12MBit interface.

[rhelectronics]

What is serial port baud rate do you use? What is the maximum baud rate supported?

[NuclearPhoenix]

What is serial port baud rate do you use? What is the maximum baud rate supported?

The baud rate cannot be set since I am using the USB serial.

https://arduino-pico.readthedocs.io/en/latest/serial.html

[rhelectronics]

I also use USB serial, but with CPS>200 the browser seems to sum all received pulses values and add it to histogram above 4096 bins
My code in hardware is:
if (isXYZ == true){Serial.flush(); Serial.println(analogVal); delayMicroseconds(25);}}

analogVal is 0-4095 int value

[rhelectronics]

here is the example attached,
the spectrum received high values with every update and looks like zoomed out to the bins that never exist in the data. The data is integer 0-4096

the higher CPS cause it happen faster.

Is something wrong that I do here? Thanks for your help.

[NuclearPhoenix]

Huh, that's pretty interesting. I tested ~300 cps with Am-241 just today and had a similar issue.

I don't know why this happens, but my best guess would be that there is a newline missing somewhere in the serial transmission and that way e.g. 80 and 300 get cropped to 80300 which would explain the very high numbers here. Does it change in any way if you put the Serial.flush() after the Serial.println()?

I don't know if this is actually a problem of the detector sending too much serial data at once or actually an issue with the serial processing of the app.

[rhelectronics]

I test now with a constant number sending like Serial.flush(); Serial.println(2000); delayMicroseconds(25);
and it gives me the solid 2000 line at the spectrum without summing the counts on histogram