Needing more than a spark test?

[WobblyHand]

Saw this recently on the PJRC Forum. Might be of interest. MCA Gamma Spectrometer, powered by a Teensy and a PMT.

 

[graham-xrf]

@WobblyHand :
Thanks for the link
76mm PMT's are like ... expensive! This gadget is, of course, one he is promoting for sale.

It seems to be a nicely put together gamma range thing. I had a quick look through the spectrum images. All start at 0KeV, and end at between about 1.4MeV and 2.1MeV. I don't know how often one would be after identifying Eu-152 (Europium), or Ca-137 (Caesium). I do like that it's driven by a Teensy and that it has it's own little 3.5" screen in the plastic case

Of course, our needs are different! We do start with a gamma source, but we want to see X-rays, not gamma. We want it to see energy ranges from as low as possible, up to about 60KeV, or 90KeV, sampled at the highest resolution possible. We try for as ultra low noise as possible. We want it to be as low cost as possible, and within the abilities of most any member interested to get one together. This attempt could be more demanding than seeing higher energy gamma hitting a PMT. For our design goals, I think the challenge is greater. I am hoping we have not bitten off more than we can chew!

I have had a easy, cruddy lash-up (sort of) working, and I have somewhat explored PyMCA on a Raspberry Pi. Mark has done rather better, with a first run shielding mount experiment, looked at real signals, and he has done good stuff with the software. (He can write actual software from scratch)! For me, playing with radioactive stuff, and electronics has to fit in between other things. Good Lord, I can't believe I am STILL doing stuff to my house!

I will have you in mind as I progress, but (I think) I recall you are one of those with considerable electronics assembly ability already, and would not have a problem putting something together. When we do get something really figured out, there may be several HM members interested, but not really into soldering surface mount IC's. We may have to find some way to help them.

You posted his link, so it should be OK to show some of the plots here ..

 

[WobblyHand]

@graham-xrf just wanted to show there's activity in this area. This thread's focus has been different than in the URL above, but the idea is similar.

As for Teensy, I have been writing my own ELS software, using a similar, but cheaper, 3.5" touch panel display and a Teensy 4.1. I have a project thread on it. Teensy is good for general stuff and DSP, but it lacks an OS. RPI is good for lot's of stuff, I'm embarrassed as to how many I have. They are great for automation. Before the great shortage I managed to get an RPI4B-8GB. This is amazing for what it costs. Had some serious Linux kernel issues on my main computer and transferred my files to the RPI4 and a ssd and was able to carry on with life, albeit a bit more slowly. Even was able to run FreeCAD on the RPI4 using the 64 bit OS.

Guess this was just a virtual poke to this thread - trying to keep it alive. If either of you publish any code, or schematics, (can't remember if schematics we're ever "released",) I'd be happy to look at it. Writing C or C++ isn't my forte, but can get by. I'm a bit better at Python, having used it as a replacement for Matlab, for commercial automotive radar simulation.

 

[homebrewed]

If either of you publish any code, or schematics, (can't remember if schematics we're ever "released",) I'd be happy to look at it. Writing C or C++ isn't my forte, but can get by. I'm a bit better at Python, having used it as a replacement for Matlab, for commercial automotive radar simulation.

I'll take that as a broad hint . Here's what I've got so far: Teensy H-M XRF Warning: although it compiles for me, that doesn't mean it doesn't produce garbage!

The Teensy code is meant to be a front end pulse acquisition/qualification system. It sends out pulse data via the USB acting as a TTY so when plugged into my linux box it shows up as /dev/ttyACM0. I haven't even gotten close to the MCA part, but it should be possible to use the Arduino's serial monitor to change acquisition parameters and examine the pulse data coming out.

Reading other folks' code can be difficult so feel free to ask questions. Anyhow, it's likely I have overlooked something....

 

[WobblyHand]

I'll take that as a broad hint . Here's what I've got so far: Teensy H-M XRF Warning: although it compiles for me, that doesn't mean it doesn't produce garbage!

The Teensy code is meant to be a front end pulse acquisition/qualification system. It sends out pulse data via the USB acting as a TTY so when plugged into my linux box it shows up as /dev/ttyACM0. I haven't even gotten close to the MCA part, but it should be possible to use the Arduino's serial monitor to change acquisition parameters and examine the pulse data coming out.

Reading other folks' code can be difficult so feel free to ask questions. Anyhow, it's likely I have overlooked something....

Wasn't directed exactly towards you, but thanks. Haven't looked at it yet, but how are you timing the sampling? Via some sort of timing interrupt or DMA? I've done DMA on an M4, but have to say I had help. Not so good to debug, but very nice to offload the processor.

I also run Linux as my main platform.

Remind me, is there any consensus on the front end? There was quite the lively discussion MANY pages ago. You still doing a version of pulse stretching, vs Graham's super high fidelity mode? So still running two schools of thought? I have no dog in the race so far, but have to say if simple works, then go with it.

 

[graham-xrf]

I also run Linux as my main platform.

Me too. I did try several times to live with Windows, but I found myself hardly ever turning it on. The last marginally effective Windows was W7, after being stripped of it's most egregious intrusions. W8 thru W10 Truly turned me off. I think part of it's problem was that there was this little Raspberry Pi right next to it that kept showing it up. Running FreeCAD on a Pi is impressive, but not really what we want to have the Pi doing. (So says he who is not beyond making it play smooth jazz From YouTube as a "background task"

Re: Mark's Teensy H-M XRF link. Um.. it's on Google Drive - so not something I would be able to open for the moment.

Remind me, is there any consensus on the front end? There was quite the lively discussion MANY pages ago. You still doing a version of pulse stretching, vs Graham's super high fidelity mode? So still running two schools of thought? I have no dog in the race so far, but have to say if simple works, then go with it.

You are right, though we don't actually need complete consensus. It's OK to have variety. Mark has shown that, up to a point, a low-pass filtered (distorted) pulse can still be representative of the energy, provided that the general wave-shape is much the same for most pulses, and is roughly triangular. Just the peak amplitude only, retains sufficient correlation to the full energy integral area under the pulse.

I simply do not want to slow the pulse up when I happen to have an ADC and Raspberry Pi that can go fast enough to do the integration without compromise. In previous posts, I have mentioned my notions to use 3 x button cell fixed bias, 50/60 Hz notch filters, a choice of amplifier front-end configurations, a trigger, switched gain ranges, guard rings, separate ADC 2.5V ultra-low noise reference, etc. I will try and get more going on posting the whole circuit. We can then decide on what might be "gilding the lily", and alter it according to the advice folk give.

 

[WobblyHand]

As you well know, a LPF (low pass filter) is a very good approximation to a matched filter, which is optimal. So Mark's approach is not giving up much SNR, but may be susceptible to errant pulses. It is unclear to me, in practice, how much of an issue it is. I have no instrumentation of this nature, so at the moment, I can offer no insight. I think both circuits have merit, but both have some issues with overlapping pulses. Gated integrators are effectively the best one can do, (a matched filter) but the devil is in the implementation details which can be tricky for those less skilled in the analog arts. Lots of pitfalls, as you well know. And a gated integrator can get clobbered by pulse pile up, because random pulses do not respect our proper sense of timing. Guess the best one can do is to reject that pulse (or pulses) and carry on after that.

If one has moderately fast sampling then the pulse processing (integration) could be done digitally, with optional single pulse or pulse block rejection. This can be done in something like a Teensy or equivalent relatively easily.

I guess, for anyone else to play along, we need to have something to make, with enough details to actually make it. No, it won't be perfect, and might not work straight away, but in a way this is good, because it may highlight design issues. In the end, we would like something "easy enough" that others could make something and contribute to the effort. If there are tricky parts, we need to have methods to make them easier to set up, or calibrate. If I can get Mark @homebrewed to temporarily enable a download from his google docs, I can at least take a look at his approach. Not to critique anything, but to get a better idea of the issues.

 

[homebrewed]

@WobblyHand, sampling is done by an ISR triggered by one of the Teensy timers. The default in my code (although it can be changed by sending out a command on the USB) is 360Ksps, about the max possible for the built-in ADC's.

I've been thinking more and more strongly about a faster sampling rate, even for heavily-filtered pulses. Mostly because that will permit more samples around the peak and consequently a more substantial improvement in the SNR. The whole-pulse integration scheme would benefit from that, too. That's one of the reasons I investigated some ideas on getting decent data rates using a 16-bit parallel ADC on a Teensy 4.0. I now can get a raw read rate close to 80MBytes/second by getting a lot closer to the hardware. Just to sweeten the deal, TI makes some 16-bit parallel-output ADCs where the upper 8 and lower 8 bits can be multiplexed onto an 8-bit bus, just by changing the state on one of the pins. So no 74XX244's (or their equivalent) needed.

The Teensy4.1 has enough pins to get a full 16 bits in one chunk, but it still is necessary to do a shift and OR to do it because all 16 aren't contiguous in the port's Data Register. It would be VERY handy to be able to separately read the upper 16 and lower 16 data register bits but it doesn't work that way.

If there's any interest in it, I can provide more information regarding the parallel I/O stuff, including putting on google Drive if it's deemed useful for the cause. BTW all the info necessary to do it is in <imxrt.h>

Mark

 

[WobblyHand]

@WobblyHand, sampling is done by an ISR triggered by one of the Teensy timers. The default in my code (although it can be changed by sending out a command on the USB) is 360Ksps, about the max possible for the built-in ADC's.

I've been thinking more and more strongly about a faster sampling rate, even for heavily-filtered pulses. Mostly because that will permit more samples around the peak and consequently a more substantial improvement in the SNR. The whole-pulse integration scheme would benefit from that, too. That's one of the reasons I investigated some ideas on getting decent data rates using a 16-bit parallel ADC on a Teensy 4.0. I now can get a raw read rate close to 80MBytes/second by getting a lot closer to the hardware. Just to sweeten the deal, TI makes some 16-bit parallel-output ADCs where the upper 8 and lower 8 bits can be multiplexed onto an 8-bit bus, just by changing the state on one of the pins. So no 74XX244's (or their equivalent) needed.

The Teensy4.1 has enough pins to get a full 16 bits in one chunk, but it still is necessary to do a shift and OR to do it because all 16 aren't contiguous in the port's Data Register. It would be VERY handy to be able to separately read the upper 16 and lower 16 data register bits but it doesn't work that way.

If there's any interest in it, I can provide more information regarding the parallel I/O stuff, including putting on google Drive if it's deemed useful for the cause. BTW all the info necessary to do it is in <imxrt.h>

Mark

I have interest in the parallel I/O. Think you need to enable access to your google drive. I put in a request to access. As of a few minutes ago, I had no access. I have 3 Teensy 4.1's. One for an ELS, one for an ELS encoder simulator, and a 3rd to play around with. So #3 can have XRF.

 

[homebrewed]

As you well know, a LPF (low pass filter) is a very good approximation to a matched filter, which is optimal. So Mark's approach is not giving up much SNR, but may be susceptible to errant pulses. It is unclear to me, in practice, how much of an issue it is. I have no instrumentation of this nature, so at the moment, I can offer no insight. I think both circuits have merit, but both have some issues with overlapping pulses. Gated integrators are effectively the best one can do, (a matched filter) but the devil is in the implementation details which can be tricky for those less skilled in the analog arts. Lots of pitfalls, as you well know. And a gated integrator can get clobbered by pulse pile up, because random pulses do not respect our proper sense of timing. Guess the best one can do is to reject that pulse (or pulses) and carry on after that.

If one has moderately fast sampling then the pulse processing (integration) could be done digitally, with optional single pulse or pulse block rejection. This can be done in something like a Teensy or equivalent relatively easily.

I guess, for anyone else to play along, we need to have something to make, with enough details to actually make it. No, it won't be perfect, and might not work straight away, but in a way this is good, because it may highlight design issues. In the end, we would like something "easy enough" that others could make something and contribute to the effort. If there are tricky parts, we need to have methods to make them easier to set up, or calibrate. If I can get Mark @homebrewed to temporarily enable a download from his google docs, I can at least take a look at his approach. Not to critique anything, but to get a better idea of the issues.

The heavily-filtered approach is predicated on a fairly slow count rate. But due to the random nature of radioactive decay there still is a finite chance of pulse overlap. So some kind of pulse-qualification scheme is needed. My code actually uses three criteria that have to be satisfied: 1. The pulse amplitude needs to exceed a user-set trigger level. This is like the simplest kind of oscilloscope trigger scheme. 2. The pulse width has to be close to the pulse width expected for a single pulse. I think this will eliminate most kinds of pileup. And finally 3. The FastPeak function returns the RMS error between the polynomial fit and the pulse data, centered around the peak. Another user-set value (called F_level in the code) sets what differentiates a "good" pulse from a mal-formed one. This will hopefully address shorter noise pulses that might originate in the detector electronics.

Regarding being able to examine the code, I probably didn't get the permission stuff done correctly. It was supposed to work for anyone with the link. I also don't know if the link changes depending on the permission, so after changing it, here you go.