Needing more than a spark test?

[graham-xrf]

Raspberry Pi supply is getting kinda dire, and this is worldwide!

Since I saw the entire PyMCA software suite up and running on my Pi, I definitely want a Pi in there. While there have been huge efforts to ramp up supply, the demand has stayed ahead of it. There is no point in "shopping around" yet. One fine fellow has automated the task with a Raspberry Pi supplier stock tracker app.

--> HERE --> https://rpilocator.com/

It's not all that useful as it is. What we need is a product select, then "sort by supplier" to discover if there is any stock.

 

[WobblyHand]

Raspberry Pi supply is getting kinda dire, and this is worldwide!

Since I saw the entire PyMCA software suite up and running on my Pi, I definitely want a Pi in there. While there have been huge efforts to ramp up supply, the demand has stayed ahead of it. There is no point in "shopping around" yet. One fine fellow has automated the task with a Raspberry Pi supplier stock tracker app.

--> HERE --> https://rpilocator.com/

It's not all that useful as it is. What we need is a product select, then "sort by supplier" to discover if there is any stock.

Seems that I'm lucky, or silly, to have a few of most of the versions. Still have a 2, a 3b, and 2GB, 4GB, & 8GB RPI4 spares. I try to use them for little tasks around the house. One is a print server, another an advert filter, known as pi-hole, and one as an irrigation controller (Open Sprinkler Pi).

The RPI 4 is light years ahead of all the rest. It's satisfactory as a home computer, albeit a little slow, and runs two monitors. I used one that way when my laptop motherboard failed and was waiting for a new laptop to ship. It's not bad, as long as you boot from disk. Running from SD is still quite slow. You can buy an inexpensive SSD and boot from USB. At the time I bought the disk it was only $24. Huge improvement.

I'm in the same quandary with trying to source a microcontroller board to make an electronic lead screw. Delivery time is now over a year. I've been trying to source the board for 4 months now. No luck so far.

 

[homebrewed]

Hardkernel has some RPi equivalents, although the one closest to the RPI4 is currently out of stock. It's claimed to be available again "by early May". I have three of them, of two different generations. I'm using one as a networked front end for a 4K TV (to bypass its built-in but hard to use browser), one as a print server and one as a smart call blocker.

The one being used for the TV is an 8-core job (IIRC, 4 A15's and four A7's) running at 2GHz and has a built-in graphics coprocessor so it can upconvert video streams to 4K. It can use either SD cards or EMMC. The latter are much faster, pretty much like an SSD. It's claimed to run about 7x faster than an RPI3.

 

[homebrewed]

I've been working on the S/W side of my version of an XRF spectrometer and have a few suggestions for other folks who may be doing the same thing. To make it easier to exchange information regarding things like trigger levels (to start the pulse processing stuff) and goodness of fit values (as a way to reject ill-formed pulses), it would be best to use values that are an accurate representation of the pulse amplitude coming out of the detetor front end. That's the approach I'm taking at present, because those values can easily be adjusted if you know the gain of the analog front end. And if it becomes clear that a different kind of detector like a scintillator is needed, the S/W wouldn't need much editing to adapt to that.

A fully user-friendly system would encapsulate the specific hardware parameters in an easily edited configuration file. Something to consider down the line.

Since the A/D front end needs to run upwards of 400KSPS this pretty much eliminates low-end Arduinos. The Teensy4 I'm writing code for has an FPU and hardware support for other DSP functions like FFT's so using floating point is not that big a deal. With all that you can do a lot with a 600MHz microprocessor in a short period of time. And it costs a bit under $20 so there's not much of a downside.

 

[graham-xrf]

Hi Mark
To this same end, I did think that in my build, there could be included circuit for a (accurate) peak-detect-hold, or at least, to provide tracking for it, even if no components are fitted for that feature if one wished to leave it out. This is something which can also be implemented in software, though it takes up processor time.

A similar reasoning applies for a settable trigger, if possible meaning software settable. I still have no clear idea what would be a nice level that occurs with certainty, but it can be near the noise, and might tip on less than 50,000 carriers released. This stuff happening below 1nA might be just silly, but I would try for it. Such a trigger might also provide a "it's all over" signal. Again, none of the components for such a feature need be fitted, but the tracking can be there.

The same approach applies to the front end gain, allowing some choices of circuit variants. I choose LTC6268IS8 or LTC6268HS8 as the transimpedance op-amp. These have only one op-amp in the package, but it is SO8 size, and so has space between pins for a guard ring.

There are three circuit variants..
One is using just the op-amp by itself with transimpedance gain resistor split as two in series, and positions for oscillation stabilizing capacitors. We add ground plane track going under them to minimize strays across the top. The remaining two circuit choices add the discrete FET front-end, for the transimpedance implementations researched by Glen Brisebos. I am still a bit unsure of how to maintain the guard ring arrangements for this. If I have to, I will simply build for one circuit, but so far, the variants can be made by using a zero-ohms resistor in places, and choosing which links to have, and which components to leave out.

The pin-out for single op-amp packages is very standard, and I think a whole lot of other op-amps could be used in there if one had something to hand. They might be lower cost, or slower, but never mind. The only place where I can't let it be messy is with the ADC.

Oh yes - I have included the 50Hz/60Hz notch filter that we simulated before. As with the rest, it goes away if you leave out the components, though in this case, I hoped to hijack driver stages that have to be there anyway, so it becomes just omitting the capacitors and resistors associated with the notch(s). Getting along with KiCAD has , so far, been slow going. I admit I have been getting much diverted by other stuff in my home life. This includes what was (for me) a spectacular adventure in a sailplane a couple of weeks ago, and my first trip to London in more than a decade. My shop is filling up with crates of new machines to be unpacked, and I am steadily knocking off the remaining tasks of the house build.

 

[homebrewed]

I've been working on the front end portion of my XRF system, basically the A/D-centric stuff (including a circular-buffer based rolling averager for noise-free triggering) and the pulse-qualification code. The latter is based on a fast least-squares polynomial fitting routine optimized for a second-order polynomial. The main purpose for that is to identify "good" pulses by their relatively low RMS error. It also is easy to calculate the estimated peak value using the polynomial coefficients.

I was curious regarding the overall accuracy of the least-squares fitting routine compared to a simple pulse integration scheme, so I included that in my standalone test program. While the numbers are different (peak values vs. integrated values), the percentage error is pretty much the same. If nothing else, that means my code is working right.

That's when integrating over the same data set used by the fitting procedure. I think the integration approach can actually do better than that (see below).

So if we come up with a less computationally intensive approach for identifying "good" pulses we can be sure that the simple integration approach is about as good as we can hope for. Also, since the 2nd degree polynomial really is only valid right around the pulse's peak value, the integration approach is more correct in terms of the actual pulse shape. Finally, since we don't care WHAT the pulse shape is, as long as it's consistent with the ideal single-pulse shape is, we can integrate over a larger data set than the polynomial fit can use -- which should further improve its SNR.

One possible pulse qualification scheme could be to compare a sequence of integrated values for the pulse to what we'd get with an ideal pulse. As soon as they differ by some TBD amount, the pulse would be rejected. No curve fitting required. However, the downside is that we'd need to somehow come up with that ideal pulse shape -- implying a very good simulation model. A more laborious approach would be to characterize a real-world system using a known elemental reference and fine-tune the discriminator for the best accuracy. I'd start with values based on a SPICE simulation and tweak them as needed.

 

[graham-xrf]

Hi Mark
Good to hear from you.
One can, of course, successfully discriminate between some peaks using only the relative recovered amplitude of a peak, even if it be grossly distorted, slow, delayed, very low-pass filtered remnant of the original (few) carriers that made it into the first amplifier. The true knowledge of what was the relative energy in the event, and separating it from other event energies requires we do do better than that. Integrating a single pulse does it! Especially if we can throw out the overlapped, noise intrusion, and other pulse artifacts that sullied it in various ways.

A good, fast check is having a reliable peak, knowing the remainder of the waveform is of a known characteristic type. The area under the pulse, representing an analogue of the photon energy is related to the peak value by a (almost) constant factor, so the percentage error in working from only a reliably discovered peak is quite small. This is only so if the there are waveform shapes other than the ideal. Note that one pretends the waveform was an artificial perfect triangle, the peak value would be enough to know all one needs.

In my scheme, I do admit that I have a hardball approach to discovering the energy. I reasoned that since we need the ADC there anyway, and the software can easily persuade it to do it's thing many times during a pulse, then collecting a number for the peak is just as easy as collecting a whole bunch of them to add up the area. As I looked closer, especially at results of peaks the PyMCA program has to pick through, I got to thinking about how it has to relate little ups and downs on a line riding generally high enough to mask lower peaks. Basically, if there is not enough accurate resolution in figuring the area under that peak, then adjacent buckets are going to have counts that run into each other. Do it well, and you get separated narrow(er) peaks.

Then I looked at the document (attached). The huge mess of energies in all sorts of combinations that actually comes out of materials that have been hit by Am241 gamma was a new realization for me. Your approach would seem to be effective as a way of cutting down the amount of computation.

I have included a fast peak detector option in my circuit. One can leave out the components if going for a pure software approach.

Also, a hardware 2-level trigger, which provides the computer a way of working with the circular buffer (ie. how far back was the start). and a "it's all over" pulse, to aid in rejecting overlaps. If the second pulse has not arrived in a certain time, the pulse is a mess, and gets rejected. As with the peak detector, one can leave it out.

Staying with the "Swiss Army Knife" set of options, the transconductance amplifier can also be built in various flavours, depending on which components are put in, and which links be set. First is using low noise op-amps only. Second and third are the versions with a FET front-end. The interface to whatever computing board there is general purpose. The board is a kind of experimenter's handy thing. Keep in mind, I am trying to have it be OK for my scintillator PMT tube also. One can choose alternative op-amps so long as they have the "standard" pinout. About the only hard set choice was that I plan to use 3 x Lithium 3.3V button cells as the fixed 10V low noise DC bias for the photo-diode.

The PCB will be a step-and-repeat of as many as I can cram onto a 12" square board. I will only be needing a couple, of spares so the remainder can be gratis to any HM folk wanting to play XRF. Maybe a single postage to someone in USA would make sense. One could cut off the bits wanted, and send the rest on like pass the parcel

The computer
The lack of supply of Raspberry Pi's is temporary problem, but everything the Pi can do in this context is also done by the 1GHz Beaglebone Black, including running PyMCA under Debian or Ubuntu. Its £25 in UK (about $30). Probably about $45 with PSU and options.

I think the PyMCA software might have some damn clever false pulse discriminators built in. It is a big load of code, and so far, all I have done with it is install it, and run it, and marvel at it!

--> https://beagleboard.org/black/

I can only visit my pet project occasionally, but I will get to play more quite soon. My order for IC's and stuff from Mouser on Friday was £70+ though it was not all for XRF, and I rarely order only one of any IC unless it happens to be darn expensive.

_

I could not make any of the available symbols for the ADC simply drop in to my KiCAD in a way that suited me, so I had to "roll my own". Here is a fragment of what it looks like. I will be posting the whole circuit soon.

 

[homebrewed]

While writing the Teensyduino code for my front end ADC system, it occurred to me that implementing a simple "geiger" mode would be handy for troubleshooting the hardware and also for getting a rough idea of what the trigger level should be for a particular design. Just a suggestion for anyone else who is interested in this thing.

 

[graham-xrf]

I kind of guessed that you might be getting into code I am a bit envious that you already explored getting real pulses from your experimental setup.

I do agree about the usefulness of a "geiger" type operation available, even if not ever to be used as a geiger counter. As I mentioned in my last post, a 2-level trigger is one of the "optional to include" bits of circuit I have in mind. Looking back at the original pocket geiger, it was all about using LM393 comparator trigger circuit to make a pulse to be counted, and a "noise pulse", which I think was about rejecting the count. I had thought to use a dual high grade op-amps as comparators monitoring a resistor chain circuit, and even add in some positive feedback to make Schmitt type. Motive here was just to keep it all as rail-to-rail stuff with one end at 0V, and (lazy) using the op-amp output as a logic signal.

Following on getting some idea of what the trigger level(s) should be, I would ask if you think there is value in having some means by which the trigger levels could be adjusted by the computer, or perhaps from pot adjuster(s) not mounted on the little board. Having to make alterations by changing out resistors is awkward. Just possibly, we might like the ability to alter the trigger setting in software anyway, especially if we include gain range settings. Does the Teensyduino maybe have a DAC capability?

 

[homebrewed]

Arduinos in general have a DAC function that's based on low-pass filtering a PWM signal. Depending on the processor, some also have a "real" DAC but the processor used in the Teensy 4.X series does not. Looking at the processor data sheet, all I found was a 6-bit DAC that only is used internally as an input to some comparators. I believe there are some in the 3.X series that are better in this regard. The Teensy 3.6 actually has better analog functions than the T4, but like a lot of electronics right now it is out of stock, with no indication of when it will be available again.

I agree that the ability to make adjustments remotely would be very handy, at least during the initial testing. The question is if it's useful enough to justify the additional complexity if you go with things like DACs, digital pots etc. All those are available with I2C and SPI serial interfaces, which are pretty well supported by any Arduino you have lying around.