GammaMCA app stops after 74.7M counts. Time or counts limit?

[jbeale1]

First; great project, and I don't know if this is an issue or simply working as intended.

I built OpenGammaDetector PCB Rev 4.0, changing the layout to remove the two inner ground-plane layers, and cut off the mechanical-support-only part of the PCB to reduce cost. Even on a 2-layer PCB, the circuit seems to work, testing with one SiPM at Vbias = 29.1 V using a random chunk of plastic scintillator. I adjusted the threshold pot R8 for what looked reasonable on the scope. I dragged and dropped the code file https://github.com/OpenGammaProject/Open-Gamma-Detector/blob/main/software/ogd_pico-4.0.3.uf2 onto the Pico.

I do not yet have a I2C display attached to the board, but at first impression the hardware and Pico code works perfectly. It is connected via USB to a Mint Linux box running Gamma MCA Version 2023-12-30 with all controls in the "Settings" tab left at default; I did not enable a time limit to acquisition. I did not do any calibration. I put a chunk of ore on the scintillator and saw a count rate near 2800 cps, sometimes exceeding 3000. I left it to run 9 hours overnight. In the morning I could see from the activity LED on the board that it was still counting, but the app reported count rate was 0 cps, showing Spectrum: 74781924 cts 09:22:27 so I wonder, did it stop accumulating due to some memory limit in the app? I don't even know what to expect from a plastic scintillator material, I'm told it is not useful for spectroscopy, but I suppose the spectrum looks plausible. Also shown is a short run with 547 cps count rate, using a 0.25 uCi Cs-137 source. I was able to save the data, clear the spectrum, click "Record" and the app works OK again, showing the expected count rate.

[NuclearPhoenixx]

Hi there! Very interesting issue you've encountered here.

I don't even know what to expect from a plastic scintillator material, I'm told it is not useful for spectroscopy, but I suppose the spectrum looks plausible.

Yeah plastic isn't very useful, because the energy resolution is practically non-existant. Meaning you'll get an extremely smeared out "spectrum" with which you can't really do anything because you can't see any peaks. That's probably also what you're seeing in your "spectrum". It's also possible that you can lower the threshold even more, but that's not really the point of your issue.

Now, to your actual problem. I am not aware of any number size limitations and there certainly isn't any artificial limit to time or pulse count in the app if you're using the default settings. Also, because the app is technically still recording (you can pause or stop the recording and the red dot is still flashing), my best guess is that something behind the scenes broke. Possibly something related to the serial connection.

Do you still have the app open? Can you open the developer console (STRG+SHIFT+J) by any chance and post a screenshot here?

[jbeale1]

Thanks. After this report I had already closed and started a different acquisition, but if I can recreate the problem I will go to the dev console as suggested and report my findings.

[jbeale1]

I moved the SiPM to a CsI(Tl) crystal and tried the test again. The count rate was a bit lower, but the problem occurred within the first two hours. Screenshot attached. I don't know what ERR_BLOCKED_BY_CLIENT means.

[NuclearPhoenixx]

Okay that's weird, there's no explicit error. Does the serial console still work as expected when this problem occurs?

Can you please maybe also post the settings of your detector board just for completeness?

[jbeale1]

I did not check the serial console, I will next time. I have not changed any settings on the board yet, so they remain at defaults. It ran overnight (9 hours) at background rate Avg: 16.6 ± 4.8 cps (Δ 29%) without stopping this time. So in the still-working state, the console reports:

read info
[#] =========================
[#] -- Open Gamma Detector --
[#] By NuclearPhoenix, Open Gamma Project
[#] 2023. https://github.com/OpenGammaProject
[#] Firmware Version: 4.0.3
[#] =========================
[#] Runtime: 46213.97 s
[#] Average Dead Time: 36 µs
[#] Total Dead Time: 1.39 %
[#] Total Number Of Impulses: 18034683
[#] CPU Frequency: 133.00 MHz
[#] Used Heap Memory: 3.32 kB
[#] Free Heap Memory: 108.95 kB
[#] Total Heap Size: 112.27 kB
[#] Temperature: 24.8 °C
[#] USB Connection: 1
[#] Supply Voltage: 4.7 V
[#] Power Cycle Count: 3
[#] Power-on hours: 32

[NuclearPhoenixx]

That's so weird, I've never encountered a similar issue once. Do you have access to a more powerful computer so that you could check if it's something to do with the memory or just general speed of your device?

[jbeale1]

Yes, I agree my slow miniPC I am using for this now is suspect when attempting real-time acquisition and control, especially with higher data rates (possible rate limitation on USB packets)? I do have more modern laptops, so tomorrow I will move the system and try it elsewhere.

[jbeale1]

after running the Gamma MCA PWA for 85 hours on my slower Linux MiniPC, and also a normal Windows laptop, I have not experienced this issue again. Even on the MiniPC, the time plot looks OK out to 300,000 readings on the X axis, so the issue appears to be addressed.

[NuclearPhoenixx]

Awesome! Thanks for re-testing 👍🏻