Needing more than a spark test?

[graham-xrf]

Good thoughts on checking the detector. Back to first principles, block the radiation with lead, what is the background. Then 1 source only. Think I'll make a square aperture in lead, shielding the detector board as well.

A thought - won't we also be seeing the source carrier? That speck of Americium is sitting on some material, what is it? Won't we always see it's signature? It's getting bombarded. I'd expect that material spectrum would be present with source only.

Of course I'd be happy to see any pulses at all! Still a ways from that.

It's way worse than that! There is a mad shower of secondary photons scattering everywhere when one of these decays into Neptunium.
Fortunately, the main type of decay is in near 100% of the stuff.

A secondary type of spontaneous fission has a minuscule fraction, only 3.6 trillionths at 1.2 per second per gram. We can ignore it!
The rarest kind is decay into Tellurium(81), and on into Silicon(14). At 7.4e-16, I am surprised anybody ever discovered it! Ignore it.

As you know, I am getting hardball in trying to figure how much we can expect to count. This is about more than the obvious things, like the solid angle we can manage aimed at the test stuff, compared to the sphere area around the source. We have to get as close as possible, and shield as little as possible consistent with denying a path to the detector.

There is another solid angle we have to consider, because the fluorescence is not obliging enough to head straight up a cone heading toward the PIN photodiode. Also, there may be more re-emitted photons (I think) of part expended incoming.

Maybe here, you don't want to go down the murky route with me into nuclear physics!

We have ..

I am not sure if all of this happens simultaneously.
Apparently α-decay energies 5.486 megaelectronvolts (0.8790 picojoules) for 85% of the time
Another 5.433 MeV (0.8705 pJ) for 13% of the time
5.388 MeV (0.8633 pJ) for the remaining 2%

The energies on all the decays is near the same. I am sure some physicist can account for all the other minor little bits that happen. When a decay happens, it can be any one of those, mostly alpha. When a gamma happens, it is much higher energy, just not as often.
2% of the decays have a γ-ray energy 59.5409 keV (9.53950 fJ) happening. I take it that then only 2% of the 33300 decays can be expected to be gamma, which is why I applied the percentage later.

About the source, and the other stuff in it and around it.
It starts with AmO2, the oxide, mixed thoroughly with gold, fused 800C into a little briquette.
Then a backing of plated silver, and a front covering of gold or palladium, hot forged on.

Then, like all gold leaf, (this one with Am241 oxide contaminants), it can be rolled out very thin, into 0.2mm, or maybe 0.008" foil.
The top cover of gold, there to stop corrosion I guess, is about 2 microns thick
It comes as a 20mm wide strip, and the sources are punched out of the strip. I have to take a look to see the actual size of the punching.

This is then mounted into the little circular metal carrier, about 1/4" diameter, which itself is held in on a approx 10mm metal disc with a terminal tag, which we take off. My sources are not handy right now, but have a try with a magnet. Am241 is a metal, but there is so little there (fractional micrograms), you won't discover from a magnet, if it was ever magnetic in the first place. If the surround is plated steel, you get to find out.

How many per second?
I don't know yet
0.9uCi decays means 0.9e-6 x 3.7e+10 decays per second. That is about 33,300 decays per second.
We lose the ones heading in the wrong directions, getting only the ellipse that lands. It is some fraction of the sphere about 20mm radius.
Loosely, that's about 1250mm2 out of 4*π*20*20 sphere = 5026 mm2. or near 24% , maybe 25%.

Then again from everywhere that got hit, multiply again by a fraction heading towards the detector, but this time starting from a wider region, rather than a point-like source. Loosely, we end up with around 2000/second.
But we have 8 sources, so let's make that 16000 per second.

Then we have the probability curve. If aluminium, think about 1% or 2%
If iron, then pretty much 100% probability of detecting it, if its result came our way, toward the diode.

I left one out. That is the probability of incoming photon hitting an atom in the test material cross section and yielding a fluorescence. That is not 100%, but the x-rays can travel out of the material so long as it's not lead.

Again, loosely, and conservatively, reduce the 16000 to (say) 5% . That is still 800Hz !
OK then, make it 1%, that is still 160 Hz. That more than accounts for the 2% yield from the source.
We would accumulate a 10,000 count in about a minute!
Even if it were only 20 detections per second, we could get a 10,000 count in about 8 minutes.

What do I think?
I think I don't know what I am doing!
Either a whole lot of counts went missing because of construction inefficiencies, or lack of our ability to discover them electronically, or there is something about my expectation of how much should be happening is totally wrong!

 

[WobblyHand]

I think I don't know what I am doing!

You are not the only one. I'm in this because it is intellectually stimulating. It would be a bonus if this worked. Clearly the basic concept works - there are XRF machines that work. Sort of wondering about this low power Xray source.

Based on what you stated about the source, the background only due to the source - if I ignore counts and whatnot, should have signatures of gold and silver and maybe steel (and whatever is in the steel). Seems like a lot of "pollution". (That's what one gets in the real world - clutter we don't want.) And in the midst of this clutter is stuff from our instrument, and finally the signal we are trying to detect. Perhaps this is analogous to radar problems in the presence of clutter, but I'm not sure what ways are at our disposal to reduce the clutter power. Perhaps lead, but it generates its own signature? In radar, many times the clutter has a strong discriminant, so it can be separated.

 

[WobblyHand]

@homebrewed Mark, I have your program running on my Teensy and display on my ELS PCB. I populated a blank PCB with a Teensy and an ILI9341 display (and a couple of capacitors).

Of course, it's not doing much because I have no front end hooked up, and I don't fully understand how to run your program. From what I can tell, it is alive and at least responding to serial input commands. That's all it does right now - the display has nothing on it. If I query it, it has 0 pulses detected, which is sensible at least. A small victory of sorts... I have nothing connected to A2, so I am reading near 0.050 mV RMS noise. I am assuming that A2 on Teensy 4.0 gets mapped to A2 on Teensy 4.1.

 

[homebrewed]

You have been thinking it may help if it was made out of plastic.
Again, you could be right, but here, I think there might be surprises.

There's one main why plastic shouldn't cause problems. Carbon's K-alpha line is well below the detector's sensitivity range @0.282 Kev. Its absorptivity @ 60Kev is about half that of aluminum, but its density is much lower so the product of (u/p) * p is about 1/4 that of aluminum. But the low energy photon isn't going to wake up our detector anyway.

I think, at some stage, you should try to make it quit. Cut a small square of lead, and stick it over the photodiode. Do we get low or zero counts at all energies?

At one point I just removed the sources and observed that the count rate went to a very low level. That was done when I was getting all kinds of leakage from my sources and troubleshooting the problem.

A thought - won't we also be seeing the source carrier? That speck of Americium is sitting on some material, what is it? Won't we always see it's signature? It's getting bombarded. I'd expect that material spectrum would be present with source only.

Yes. My current setup appears to be showing a bit of a steel peak even with no sample in the chamber & that could be from the source carriers. The chamber is lead-lined so that eliminates the screws used to assemble the enclosure.

 

[homebrewed]

@homebrewed Mark, I have your program running on my Teensy and display on my ELS PCB. I populated a blank PCB with a Teensy and an ILI9341 display (and a couple of capacitors).

Of course, it's not doing much because I have no front end hooked up, and I don't fully understand how to run your program. From what I can tell, it is alive and at least responding to serial input commands. That's all it does right now - the display has nothing on it. If I query it, it has 0 pulses detected, which is sensible at least. A small victory of sorts... I have nothing connected to A2, so I am reading near 0.050 mV RMS noise. I am assuming that A2 on Teensy 4.0 gets mapped to A2 on Teensy 4.1.

Congratulations on getting the program up & running! I find that fairly encouraging. Hopefully you didn't find it necessary to edit a whole lot of stuff. Maybe you could summarize in a separate post so I can fix things up on my end?

The commands the program understands can be found early on in loop(). But to summarize:

v -- print the version number to the serial monitor

i -- print some system information

c -- perform a calibration. setup() does this so not required unless the setup has been running awhile. Prints some info when done.

nN -- N is an integer. Sets the total number of valid pulses to acquire a spectrum. I typically use N = 3000. Default: 65536 (!)

tF --F is a floating point value and sets the trigger point. Right now I'm using .65V to trigger pulse processing. Default: .3V. The ISR for the ADC converts values to floating point, using the Aref voltage I measured for my particular Teensy, so you probably want to do that, too. The system variable is called "vRef", on or near line 153

fF -- F is floating point. It sets the "fit" parameter for pulse qualification and is based on the RMS error between the data
and 2nd order polynomial fit, performed around the pulse peak. I typically use "f5". Default: 50. The value is scaled relative to the
fitted peak value so it should be equally stringent for large pulses as small ones. Smaller values for f will really drop the count rate of
qualified pulses.

uN -- N is an integer. It determines the refresh rate of the MCA plot. I typically use u10 so the display refreshes after every 10 pulses are
acquired. Default: 20.

mF -- F is a floating point value. Sets the maximum pulse level to be displayed. Basically a scale factor. For displaying integrated pulse values
I'm using m75. Default is 3.28 -- it was defined for peak pulse values, not area, so failing to set this parameter won't plot anything but noise.

 

[WobblyHand]

There's one main why plastic shouldn't cause problems. Carbon's K-alpha line is well below the detector's sensitivity range @0.282 Kev. Its absorptivity @ 60Kev is about half that of aluminum, but its density is much lower so the product of (u/p) * p is about 1/4 that of aluminum. But the low energy photon isn't going to wake up our detector anyway.



At one point I just removed the sources and observed that the count rate went to a very low level. That was done when I was getting all kinds of leakage from my sources and troubleshooting the problem.


Yes. My current setup appears to be showing a bit of a steel peak even with no sample in the chamber & that could be from the source carriers. The chamber is lead-lined so that eliminates the screws used to assemble the enclosure.

Have you tried literally putting a small piece of lead on the PIN diode and checked the background level? Is it low, or is there scatter with stuff coming in from the edges or from behind? Trying to figure out the nature of the problem...

 

[WobblyHand]

Congratulations on getting the program up & running! I find that fairly encouraging. Hopefully you didn't find it necessary to edit a whole lot of stuff. Maybe you could summarize in a separate post so I can fix things up on my end?

The commands the program understands can be found early on in loop(). But to summarize:

v -- print the version number to the serial monitor

i -- print some system information

c -- perform a calibration. setup() does this so not required unless the setup has been running awhile. Prints some info when done.

nN -- N is an integer. Sets the total number of valid pulses to acquire a spectrum. I typically use N = 3000. Default: 65536 (!)

tF --F is a floating point value and sets the trigger point. Right now I'm using .65V to trigger pulse processing. Default: .3V. The ISR for the ADC converts values to floating point, using the Aref voltage I measured for my particular Teensy, so you probably want to do that, too. The system variable is called "vRef", on or near line 153

fF -- F is floating point. It sets the "fit" parameter for pulse qualification and is based on the RMS error between the data
and 2nd order polynomial fit, performed around the pulse peak. I typically use "f5". Default: 50. The value is scaled relative to the
fitted peak value so it should be equally stringent for large pulses as small ones. Smaller values for f will really drop the count rate of
qualified pulses.

uN -- N is an integer. It determines the refresh rate of the MCA plot. I typically use u10 so the display refreshes after every 10 pulses are
acquired. Default: 20.

mF -- F is a floating point value. Sets the maximum pulse level to be displayed. Basically a scale factor. For displaying integrated pulse values
I'm using m75. Default is 3.28 -- it was defined for peak pulse values, not area, so failing to set this parameter won't plot anything but noise.

Really didn't fix much. Had to change paths. Also fixed some of the indentation, which made it easier for me to follow. I was hoping to eliminate the pflag warning by doing this, but it didn't help. Got rid of some declarations that were unused by commenting them out. I can send you a zip of the whole folder if you want it.

Ah, now I understand the case 't and 'f'. Multiple character parsing, makes more sense now.

As a general comment, might want to set defaults that work, as opposed to having to set parameters. Not sure how to approach that, but at least maybe it would get people in the ball park quicker.

As a recent author of an ELS controller, I have found it is hard to let others use and evaluate your work. I have a brave soul who is using my controller. They are finding many details that should be addressed, that simply weren't very important to me as a sole user. Been eye opening to experience that. A lot of work too... I'm not complaining, it has made my SW better, but it has been more work than I expected.

 

[WobblyHand]

@homebrewed how does one measure vRef? There's no pin. It's an internal node.

 

[graham-xrf]

You are not the only one. I'm in this because it is intellectually stimulating. It would be a bonus if this worked. Clearly the basic concept works - there are XRF machines that work. Sort of wondering about this low power Xray source.

Based on what you stated about the source, the background only due to the source - if I ignore counts and whatnot, should have signatures of gold and silver and maybe steel (and whatever is in the steel). Seems like a lot of "pollution". (That's what one gets in the real world - clutter we don't want.) And in the midst of this clutter is stuff from our instrument, and finally the signal we are trying to detect. Perhaps this is analogous to radar problems in the presence of clutter, but I'm not sure what ways are at our disposal to reduce the clutter power. Perhaps lead, but it generates its own signature? In radar, many times the clutter has a strong discriminant, so it can be separated.

Actually not. All the "rubbish" unwanted photons emanating from the material around the source source cannot get back to the detector.
The best that may happen is that some of them have enough energy to "help" the 59.5KeV big guns gamma.

For example, X-rays coming from the gold might be 9.7KeV and 11.4KeV. They will never arrive at the detector, but they have enough energy to get λ-shell responses from antimony and tin and cadmium. They can also provoke K-shell responses from, zinc, and copper , and nickel, and cobalt and iron, and manganese and titanium. We should be grateful for all the secondary X-rays coming from the source contaminants.

The more that hits the stuff under test, the better, even if it is second hand. That said, it can skew the proportions when trying to identify the alloy, if there is stuff there that they simply have not got the energy to expose. They load the odds in favor of the lighter metals.

Not so much problem with lead. Only λ-shell can respond at 10.8KeV and 12.6KeV, but these have to fight their way out of the lead, and with shadow shielding, their edge scatter has small chance. What does escape, can only help in the same way that gold did.

 

[graham-xrf]

There's one main why plastic shouldn't cause problems. Carbon's K-alpha line is well below the detector's sensitivity range @0.282 Kev. Its absorptivity @ 60Kev is about half that of aluminum, but its density is much lower so the product of (u/p) * p is about 1/4 that of aluminum. But the low energy photon isn't going to wake up our detector anyway.

I am hoping @RJSakowski may be able to help us with what might happen with plastic.
I get it that the energies from carbon, hydrogen, oxygen, etc are so low, we cannot detect them.

The problem is, what ever low energy got subtracted when the plastic got hit, should also release the non-expended energy as photons, still quite high level x-rays, able to go on and hit more stuff, with entirely new random directions.

It is that - or we don't understand what happens to the exit energy.