Needing more than a spark test?

Apologies for the omission. Here's the link: DIY multichannel analyzer.

Any of the Pi's would be a good candidate. Lots of free S/W development stuff, just pick your favorite language. I like SciPy because it has nice graphing utilities. I used it for a homebrew visible-light spectrometer using a webcam (and a real diffraction grating, not a DVD).
 
Last edited:
I did a quick analysis of the hardware design for the Arduino-based implementation of that DIY MCA. While I believe it's unlikely anyone here will take this exact approach, the analysis may be helpful when it comes to writing a S/W-based version. So my analysis is attached. I'm an old-school analog electronics guy so I may well have glossed over some things that are obvious to me, so feel free to ask questions.
 

Attachments

  • Circuit description.txt
    2.8 KB · Views: 12
So this has already been done?!
R
 
So this has already been done?!
R
So it would seem :). However, I haven't seen any results that might suggest this kind of DIY approach is actually useful. I have to think it's possible because there are lots of XRF vendors using very similar technology. Here's the thing, though. In the world of X-ray spectroscopy, it's not just a matter of finding the energy peaks, parsing out the relative intensities for the percentage of content and calling it good. An element emitting higher-energy X-rays will, in turn, excite X-rays from other materials present. So there are complex interactions. A lot of this has been modelled based on the analysis of EDX/WDX data, but, just to make things even more complicated, each element can have a number of different energy levels that, in a number of cases, produce energy peaks that overlap.

I know this may seem an unlikely coincidence, but the mousepad I'm currently using is one I got from ThermoScientific as a freebie: and it's a periodic table that has information about EDX/WDX elemental analysis. A cool thing about this chart shows the "overlaps", where the emission from one element can overlap the other -- making it more difficult to distinguish the two. Case in point: the K-alpha line for iron at 6.4KeV is close to manganese at 5.89Kev. Definitely problematic, because manganese is used in many alloys. The L-alpha lines are .636 and .704Kev for Mn/Fe respectively so no joy there. Vanadium's K-alpha is close to Chromium, and Manganese is close to Chromium. Ugh! To resolve this, commercial tools use sophisticated data-extraction programs to produce a least-errors fit to all the data (not just the peaks). The situation for iron and manganese is problematic, but cobalt isn't much better because it is on the other side of iron in the periodic table. Nickel is better (some) because its K-alpha line is about 1Kev higher than iron.

A work-around might be a kind of fingerprint analysis, where different alloys are characterized and then used as a comparison to the unknown alloy. That would be my best-case approach. It's limited by the "dictionary" of alloys you have characterized but that could rapidly grow in the context of an open-source effort. Of course, a reliable open-source approach would include a rigorous method of calibrating the tools so DIY'er A can depend on the results produced by DIY'er B...and so on.

On a slightly different note, I am thinking that the "5V switch" control line in the Arduino MCA circuit is likely being used to implement a type of sample-and-hold circuit. Once a pulse enters the measurement system, it sends a signal to the Arduino which then turns the peak-hold detector off so a particular photon event can be accurately captured. If not, suppose in the meantime an even-higher-energy photon strikes the scintillator. The higher pulse peak is captured by the peak detector. This will result in a skew of the data, favoring higher-energy x-rays.
 
I did a quick analysis of the hardware design for the Arduino-based implementation of that DIY MCA. While I believe it's unlikely anyone here will take this exact approach, the analysis may be helpful when it comes to writing a S/W-based version. So my analysis is attached. I'm an old-school analog electronics guy so I may well have glossed over some things that are obvious to me, so feel free to ask questions.
This is OK. For a retriggerable multivibrator, it is a sad thing that I can still remember exploiting 74LS123 for all manner of pulse-making.
 
Regarding analysis of the outputs. It could be digitally filtered somewhat.
Imagine a photon hits the iron, and provokes a clear single response. The same photon does not hit the manganese. That is the job of a new photon. Suppose it generates it's own clear pulse, at a different time. Now suppose they do their thing so that the response duration somewhat overlaps. We get a summing of the intensity, with two very small hikes at the top. If the pulses overlap enough, they will smear each other to the point you don't know which is which.

You do know that the height of the sum pulse is high enough that there must be response from more than one.
If the FIFO or boxcar storage of the intensity waveform is long enough, say a whole minute, then there will be some lower pulses that can be captured as having a higher probability of being a valid one, especially if they repeat.
If a sample finds (say) 10, or 200, whatever, all the same height, it is an indicator.

When you have 5 or 8 alloy elements in there, it will get to be a noisy mess, with some peaks here and there. This is where the only recourse is to characterize the noisy mess as a signature mess corresponding to a stored profile of that alloy. Once we get to display the output, we may be able to get smarter about how to analyze it.
This is the sort of thing where a human could look at a display, or mix the waveform with a tone and listen, and be able to tell differences.

There is also what might be revealed if the waveform were given the FFT (Fast Fourier Transform" treatment.

I know some will want a weekend project style little board with a USB connection, and a probe they can point. I am not sure. If it was that easy, we would be able to get them from eBay ready made. The world is full of "detectors", many totally bogus, but with "circuitry" in them. We are exploring this to discover if something truthful and usable can be made to work. Sure - we can trawl other projects to progress things if they are useful, but in the end, we verify.
Given the lack of (affordable) kit, we must be prepared that we discover it might take lots of money to do it well.
 
My pack of thorium-loaded gas lamp mantles has arrived.
I take it one should not stash them in the same little plastic box as the Americium buttons from the smoke detectors.
 
I have examined the Arduino code that was written for the MCA. It's interesting that, while the project web page is in Italian, all the comments in the Arduino code are in German. Thank goodness there are some good online translation sites! The code actually is fairly simple, although it has a lot of commented-out code that most likely was put in for debugging purposes.

The main reason I wanted to examine the code was to verify my hypothesis that the "5V in switch" is used to implement a track-hold circuit; and I was correct. An overview of the code shows that the program waits for a pulse to come in from the 1-shot. It waits a short time to make sure that the voltage on the sampling capacitor rises to its peak value, then shuts the transistor buffer (the BC327 PNP transistor) off. The circuit now is in its "hold" state. The voltage is then digitized and the value is used to create an index into an array. The array contents at that address are incremented by 1. Then there's some code to update the display, which appears to be a realtime plot of the spectrum as it's acquired. Finally, the storage capacitor is reset, re-enabled (after a short delay so the cap can fully discharge), and the "5V in switch" signal is set HIGH, which turns the buffer transistor back on. This loop is repeated until the reset button is pushed (not shown on the schematic, by the way). The reset clears the spectrum array and the whole thing starts over again. The reset command also causes the program to output the spectrum data to a host computer, if one is connected to the Arduino.

While the display routine includes an "auto-scaling" function so no data clipping occurs, the code doesn't seem to take care of overflow in the integer array that stores the raw spectrum data. This might be a moot point though -- there are 128 slots for the data so it might take a long time for one of them to overflow. OTOH it wouldn't take much more code to check for that and stop the acquisition at that point.....or run a scaling operation on the data.

By using the Arduino's interrupt capabilities, it might be possible to get rid of the 1-shot. If you want a visual or audible indication of pulse activity, you could use an Arduino output pin to generate a short tone or light up an LED. It may not be possible to move the track-hold circuit into S/W, but a faster controller like a Teensy might be able to do it in S/W -- continuously digitize the input and look for a pulse event to occur.

I don't see anything really special about the MOS transistors used in the track-hold circuit. They all are fairly high-current devices, but the IRL510 is the only one that needs to be that hefty (due to the discharge current of the 4.7nF capacitor). I get the feeling these particular devices were used because they happened to be in the developer's parts drawer.
 
There are high speed op-amp circuits that can ride up a pulse, and stay stuck at it's peak until discharged. I will agree the scheme has the merit of low cost simplicity. It has been a while since I used LTC6244. They are now part of Analog Devices.
--> PEAK DETECTION

I think the nature of the pulse - how sharp, or broad is it, or is it two pulses partly overlapping, is better to know than to just seek it's peak. We now have low cost high bandwidth A/D conversion chips available that can capture a pulse with enough samples through it's duration to get it's shape, including it's peak. Should we consider a pulse trigger circuit which starts a sampling, capturing (say) a gated 1second's worth at some sample rate like 250KHz?

If the pulse is faster, we increase the sample rate, and maybe reduce the sample interval.
 
Last edited:
Back
Top