MCA front end

Linear and non linear

MCA front end

Postby Doug Coulter » Fri Aug 26, 2011 10:23 am

A project we'll be doing here soon is an affordable MCA system. I've been putting some skull-sweat into the hardware design for that, since it's a fairly non-trivial problem, and have a start here.

I am aware of a number of easy solutions for wide pulses at slow count rates -- everything from using PC audio recording of spread out pulses, to standalone things that use audio-speed opamps, but the uses of those are pretty limited with sensitive detectors that can easily produce very short pulses at very high rates, and I want something more like the expensive commercial products in terms of performance, just at a much better price. The trick mainly is in capturing peaks and holding them long enough for a slower a/d converter to convert, and being able to ignore pulses that come in too fast, or that pile up. Over "shaping" the pulses as is required for the slow stuff makes pileups a lot more common, so I want to avoid that, and just be able to reduce pileups by having the front end fast enough to not need time smearing and integration. At the very least, the idea is to avoid slew-rate limiting in the front end, as that makes errors that are hard to back out in software, or impossible. Here's a sample schematic of more or less what I have in mind:
MCA.gif
tentative front end design

Now lets look at how I think this will work...Not all the parts have been selected yet, but I've found some ghz speed opamps and comparators that seem adequate for this, as long as say, the comparators don't reverse when the common mode range is pushed, or things don't oscillate too easily. The fets and transistors are not yet chosen, but will have to be selected for various important characteristics in each case to get the performance out of such a simple design.

The two opamp stages are just for gain and "shaping". MCAs all seem to have this and need it. In general we need a DC block at the input to keep things in range, and a high pass filter with a few uS time constant gets rid of DC drift and baseline problems. The low pass is just to keep out cel phone signals, and compensate a HF peak these particular opamps seem to have on the data sheet, though a little bit of rolloff might stretch the pulses slightly and improve things (which is why no values are yet shown, this is going to take some bench time with a variety of sensors to tune).

Going down the signal chain, I decided to build a peak detector out of an NPN emitter follower. This gives us the diode but also some current gain to help charge up Ch quicker, so we can use a larger cap (it'll be small anyway or take far too much current with a fast rise signal and won't reach full charge - something in the 10's of pf is my feel here). Now, the NPN input transistor gives a level shift of about 1 Vbe -- more when it's charging a cap. To compensate that DC error (which is also temperature dependent) a PNP emitter follower is hooked to the capacitor to produce an equal and opposite level shift and make zero in be zero out (instead of negative one Vbe). It won't be perfect, but it will be close if the transistors are put on a common temperature block. Now, there will be some leakage in "hold mode" from the NPN BE diode, but mainly from the PNP base, as it's delivering some current into the load resistor (about 100 ohms likely). To keep that from making the thing drift too fast during hold mode, I drew another NPN emitter follower biased so that its base current will cancel the current from the PNP one. The idea will be to adjust that to keep the hold capacitor from going off into the weeds for the couple uS we need for a uP's internal sample/hold to acquire the signal (it will be sitting there in sample mode whenever it's not doing an a/d conversion, so we get some time-overlap free).

Now for the logic required. We only want to catch pulse peaks that are over some threshold or the dark noise of the sensor kills us. So I show a comparator that just compares the signal to a reference voltage we'll adjust to reject the dark noise. There is another comparator that looks at the input vs output of the peak catcher, to detect when a peak is over and the input going back down - this is used to clock the flip flop and put us in "ignore further input" mode. The setting of the flop shorts out the input so further noise won't couple into the hold cap. It will also produce an interrupt to the uP so it knows to start an a/d conversion. Once the uP has started its a/d, we need to discharge the hold cap, and only enable acquisition once a signal breaks threshold again. We don't want to just turn the front end back on =- we could be in the middle of a pulse already after the peak, and get a bogus output if we do that. So the flop reset signal won't happen unless the threshold comparator reports the signal is at the baseline, so we can start up clean. I will probably have to make that or gate a 3 input one, and derive a delayed input off the flop Q, so as to be able to shorten the reset pulse when the time is right -- the uP has little hope of controlling the reset pulse quick enough for that.
In this case, we want the flip-flop to be fast, but the gate to be slow to prevent a race condition...nasty old trick from back in the day I want to use here (cheaper than a delay line).

I'd use a PIC for the uP, mainly because I already have an opsys and tons of other code and tools for them, and the one we're using on the standard counter has USB and an a/d that should do fine for this, so we get to reuse blocks of hardware just like one normally does with software...The idea here is to let the uP do the complex but not so time-critical stuff, like resetting the hold cap, but this fast logic to do the "simple" but very time critical stuff. At 12 mips, the PIC should be able to handle the inter-pulse housekeeping fine. All it's really doing is resetting the front end between pulses, and building a histogram from the a/d results, and once in awhile shipping those off to a PC for display. Not much code is involved in doing those things.

We won't have some of the issues you have with a regular sample hold here. Charge injection from the reset fets should be at worst, constant and just make a DC error we can back out in software -- it won't be large enough to push things out of range if the parts are selected properly. Or that's what I am hoping.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 2943
Joined: Wed Jul 14, 2010 8:05 pm
Location: Floyd county, VA, USA

Re: MCA front end

Postby Doug Coulter » Wed Sep 24, 2014 7:29 pm

Note, I should add that a feature, if the uP supports it, is to wait till it's interrupt signal goes high again after a reset - holding tings off till then. This prevents re-triggering if a peak happens to be happening, and on its downslope, right as we re-enable. We'd catch that "part of a backside" of that peak and it would be utterly spurious data. At least this way, we avoid re-enabling till things are all below the basic noise threshold.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 2943
Joined: Wed Jul 14, 2010 8:05 pm
Location: Floyd county, VA, USA

Re: MCA front end

Postby Doug Coulter » Mon Sep 29, 2014 6:51 pm



Here's one for you, Philipp. This is what the bigger NaI detector output looks like with and without a calibration source on it. It could use a little low-passing, but not much, or the residual energy from the previous pulse would all too often add to the next pulse and give you big inaccuracy. While these pulses could stand a little lowpassing (noise and they're a bit "scratchy" looking at high time rez), not much or you run into the above problem. You might almost be best off with the sample/hold inside the pic all by itself and another way to tell it when to go into hold and convert. Oh, forgot to say on the video - the scope was at 2v/div, no preamp required unless heavy shaping is used, which would cut the peak height down a bunch. But you can get that in the opamp already in the circuit (both gain and shaping). I used an older scope for this as I've fried a really expensive DSO in the recent past, and I really need that thing working for the fusor and software/scope data aq. Once burned (and $2k is quite a burn for me) - twice shy.

I ordered an op42 opamp from digikey today to speed up the one you had in the original design. It won't be as DC accurate, but that's far from the whole story. While the values I picked for the phototube load and coupling cap were somewhat arbitrary, those were laying around, and just happen to match what the imput impedance of the input to the inverting side of your opamp would be...for some reason. No extra preamp will be required, but you might want to make the feedback R bigger and put a cap across it as your "shaping" for this. I'll be trying it all out soon - I figured I'd get the signal good first, then work on getting a power supply right for your boards, (and a computer interface going) and then we'll see what we get.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 2943
Joined: Wed Jul 14, 2010 8:05 pm
Location: Floyd county, VA, USA

Re: MCA front end

Postby Philipp Windischhofer » Tue Sep 30, 2014 8:17 am

Hi Doug,

nice video, thanks!

Yeah, I thought of only using the internal AD's S/H, too. But you would necessarily have some jitter due to interrupt latency (you still need to tell the PIC when to switch to "hold"). I guess it's worth a try to see whether those are acceptable.
Still, the dsPIC I'm using right now does have 2 internal comparators (400ns response time) one could use for this.
The peak detection itself would most likely still need an external circuit, though.
Can't we just use a differentiating op-amp on the input signal and look for the zero-crossings (indicating the "flat" top of the pulse) on its output? This would get rid of that RC-delay network I don't really like (due to its tendency of needing fine-tuning) altogether.

Philipp
Philipp Windischhofer
 
Posts: 21
Joined: Wed Aug 13, 2014 3:12 pm

Re: MCA front end

Postby Doug Coulter » Tue Sep 30, 2014 10:40 am

"Just pick the peaks" is the oft-stated "conceptually trivial" but actually hardest job in EE. I've been doing it for years with a variety of signals, from human speech pitch pulses to stocks in the markets to scientific inputs. It's never trivial.
How would a differentiator (those always increase noise) handle this?
DS0004.PNG
Funny pulse from an NaI head (one you'll soon have)
DS0004.PNG (139.9 KiB) Viewed 2179 times
- You know what it would do, it would make a series of errors only limited in number by the speed of your a/d. I count at least 10 here. On a single pulse.

You would of course have lowpassed this signal some first (which of course, differentiation un-does), but that video was to show the limits you encounter there - you can't do it much or you have pileup problems (you do anyway, it's just a question of which error becomes dominant).
Think of all this as an error-budget issue - it's never going to be perfect, the goal is just to reduce how common and bad the errors are, not eliminate them - you can't.

You will, of course, always require some hysterisis in something somewhere here - a percentage of the detected peak height is usually the best, but also the hardest to implement vs a fixed amount.

Not sure exactly what happened there - gamma scattered out, then back in? Doesn't matter really, things like this happen all the time in real-world signals. You'd still want a re-settable track and hold as a front end, it's just that the design you show is woefully far too slow without so much low-passing upfront that you'll have pulse pileup instead - energy from a previous pulse will still be in the low-pass filter when the next occurs. This is NOT a trivial problem, and each domain has a slightly different best set of tradeoffs, there's no perfection in peak picking I'm aware of in some 40-odd years of doing it with various signals. I'm not saying my gedanken circuit above is the answer for sure either, just a shot at this one.

Unless you happen to be doing something silly in software, like sleep/shutdown, interrupt timing jitter on PICs is generally at most one cycle (latency can be longer of course). The sample/hold on the PIC takes a bit of time to acquire, and of course you still want a peak holder in front of that so it doesn't try to acquire the backside of the pulse and lose the peak value.

You really do also need to ensure that you don't "re-open" the peak detector on the backside of an existing pulse that might have come in while you were busy. You then get utter garbage depending on timing, and the timing on the input is totally random and cannot be controlled, radiation is the most random thing in the known universe. My circuit above does that by making sure that the signal is below the minimum threshold before allowing the peak picker to re-enable (assuming the pic does its part, holding re-enable low till the interrupt signal goes high again, indicating that the signal has gone back below the minimum threshold).

This is why many older MCA's had a broadband analog delay line, so some part of the circuit could "know the future" compared to the rest, back in the day when digital goodness wasn't so great. Analog delay lines were never cheap, and are now hard to find at all - so we work with what we can get.

You will always want some fine tuning. All past and current MCA's provide for that, since no two detectors need the same tuning. It's just a sorry fact of life. Most are much faster than NaI, the only exception being ZnS - which isn't often used for this since the inherent resolution is so bad. BGO is now more common, and has response times in the few nanoseconds, compared to the microsecond shown here. In other words, it only gets worse, unless perhaps HPGE is used, and I have no experience with those - I don't do cryo here since I'm so far from a place to get the stuff.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 2943
Joined: Wed Jul 14, 2010 8:05 pm
Location: Floyd county, VA, USA

Re: MCA front end

Postby Doug Coulter » Tue Sep 30, 2014 12:51 pm

More data. Now that I know I'm not in danger of frying the "good" scope, here are some saved screens. This was with 850v coming out of the supply, about 840 actually seen by the detector head through a 43k resistor (what I happened to have a bag of near 47k), a 1k pf coupling cap, and a 43k resistor to ground for all shots.
DS0002.PNG
Background

DS0003.PNG
background

DS0004.PNG
More background
DS0004.PNG (10.85 KiB) Viewed 2175 times


Now, let's put the source up to the front of the detector (.25 uC, Cs-137 sample embedded in epoxy) Note the change in trigger rates.
DS0005.PNG
With source present

DS0006.PNG
with source

DS0007.PNG
with source

DS0008.PNG
with source


The trigger time is shown by the red triangle at the top of each shot - I pushed it to the left so you could see more signal after the trigger.
Vertical trigger is the triangle on the right side.

This is what you have to deal with, and what a pro MCA will give a fairly decent spectrum on (no shaping here, though - most MCA's have that internal and adjustable via knobs or software command). The smaller detector has more compton scattering, but does a better job with low-energy X rays since the light doesn't bounce around as much in a smaller system.

I should note that my "big jug" detectors get into the several khz range with this same source and trigger levels. They see more of the source signal due to just being bigger and more pi's of the angular output of the source.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 2943
Joined: Wed Jul 14, 2010 8:05 pm
Location: Floyd county, VA, USA

Re: MCA front end

Postby Doug Coulter » Tue Sep 30, 2014 1:49 pm

I added some fairly minimal shaping to stretch the pulses to around 10us, and here are the results.
Note that differentiating this just gets you back to the raw signals above...
There are two sorts of "pileup" or inter-pulse interference shown here - one where one pulse starts before the last finished, and one that happens while the coupling capacitor highpass (that takes out the 850v DC that's on the signal) has gone above ground - it took on some charge during the pulse - and that reduces the size of the next pulse. There's no free in this physics, nor is there much easy. Just sayin.
http://youtu.be/qsxfrk029Xw


Most of the pileup I saw in the individual screen shots (which show several traces each in this mode) was due to overshoot of the basic 1000pf coupling capacitor, which is one of the tuning items. I could make it smaller and the overshoot would be larger but not last as long...it's not easy to win this one.
Here are some of the basic screenshots I took with the exact same setup (at least you can read the scope settings better and examine the cases in more detail). Of course, I selected the ones that had the most problems, because we don't care about the easy 20% we see - we need to get them all right, or as close as we can.
DS00p2.PNG

DS00p4.PNG

DS00p7.PNG

DS00p9.PNG

DS0p12.PNG

DS0p17.PNG

DS0p21.PNG


You'll notice I didn't do all that much selecting - this is 7 of 21, or 1/3 of the random screen captures I got. Most of the issues here appear to be that the input coupling capacitor hasn't recovered ground by the time the next pulse came in, but there are a couple where one pulse added to the one before (this is all going to be happening near the trigger point, either way).

This is why both JohnF and I lament this one-wire always-positive supply stuff. The detectors I can get inside of and rewire, I use a negative supply and a floating phototube anode with - almost a pure current source if the signal voltage isn't allowed to get too big. Solves a lot of this. You might pull off a perfectly matched pulse transformer, but here that didn't work due to it resonating with the small capacity of the coax coming out of the sealed head unit.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 2943
Joined: Wed Jul 14, 2010 8:05 pm
Location: Floyd county, VA, USA

Re: MCA front end

Postby Philipp Windischhofer » Thu Oct 02, 2014 2:40 pm

Wow - those are quite a bunch of images ;)

You're of course right with the differentiator -- I was posting before thinking, sorry.

Hmm, I wasn't aware of the fact that pulse-pileup could cause you much trouble with safe-to-sit-next-to sources anyway.
But since this doesn't seem to be the case, we'll have to avoid the problem as best as we can :roll:

The thing with ignoring the back side of the pulse until it goes back down below the threshold seems to be a good idea. Since you then want to sample the voltage immediately after the time of the peak, you want to have a fairly good knowledge about "when" the S/H switches to "hold" for the last time, so to say. One possible issue could be that there may be several toggles of the S/H line (either due to noise, or that weird pulse shape of yours) and you need to find out the one that actually corresponds to the global maximum without knowing the rest of the peak. (In my current design I sample the "held" value of the pulse only after it went back below the threshold and therefore avoid this issue altogether -- at the price of possible pile-up during the falling edge).

So - I'm thinking aloud now - you will likely need to implement some sort of debouncing (either in hard- or software) with a certain time-constant to get rid of those spurious triggers. Still, it would reduce the time-slot where pileup can happen without being detected to about the time constant (about the same order of magnitude as the pulse's rise-time) of your debouncing circuit (as opposed to the duration of the entire pulse without this protection). So you should be able to gain a factor of about 5-10 in terms of "time in cycle with no pileup protection" without introducing too much additional complexity. Great!

Philipp
Philipp Windischhofer
 
Posts: 21
Joined: Wed Aug 13, 2014 3:12 pm

Re: MCA front end

Postby johnf » Fri Oct 03, 2014 4:38 am

Phillip
Doug

this is why commercial MCA's have a dead time display to warn of how many pulses statistically might be compromised.

shaping allows a mix of energy vs dead time the faster the shaping the more good pulses get through --but lower power to do it with ( integration of the shaped pulse)

we tend to use something between 1 and 10 uS for shaping with pole zero correction with 3-5uS being the norm
Getting rid of low energy continuum with a window is usually the way to get low dead time.
Pole zero correction is used to keep the base line constant

up to my eyeballs in work
I'll elaborate further when I can
johnf
 
Posts: 375
Joined: Sun Aug 08, 2010 4:51 pm
Location: Wellington New Zealand

Re: MCA front end

Postby Peter Schmelcher » Fri Oct 03, 2014 1:40 pm

You might want to also consider a matched filter. A matched filter will achieve the highest signal to noise ratio from additive white Gaussian noise (an important caveat). Basically the filter shape matches the shape of the signal in the frequency domain.

http://en.wikipedia.org/wiki/Matched_filter

-Peter
Peter Schmelcher
 
Posts: 25
Joined: Tue Sep 30, 2014 9:04 pm

Next

Return to Analog

Who is online

Users browsing this forum: No registered users and 1 guest