MCA front end
Posted: Fri Aug 26, 2011 9: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: 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.
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: 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.