Mathematics of pulse processing

[sgt_johnny]

Hello,

Not sure if this is the right sub category, but my idea would be carried out by a Microcontroller (STM32Fxxx). In Nuclear Science, there is a thing called "pulse height analysis", from a given pulse, the height is calculated and then logged to somewhere. Out of all the pulse heights you get a spectrum. Here is an idea what the pulse looks like:
http://physicsopenlab.org/wp-content/uploads/2016/01/pulse-e1452009804601.png = yellow trace

Now my question here is, lets imagine i have sampled the pulse by my ADC of choice, i will have an array of adc values which, on what mathematical formula i do calculate the Pulse height?


Any help appreciated!

[ataradov]

You would need to be more specific. In general you just go over the array and find local maximums (or minimums in this case) over a certain threshold. It is pretty trivial.

But in the case of this picture, the width of the pulse is 40 ns. There is no way you will capture this using an MCU as is. You will need to add pulse extender, and the actual design depends on A LOT of factors.

[sgt_johnny]

If its that trivial, just finding the highest value, why even bother with sample the whole pulse?
If they only need the max value, a old fashion high-speed peak detector would do the same, then you can just shoot one adc measure at the detected peak and you have the  height, but theres gotta be more to it that they sample the analog signal??

[ataradov]

If its that trivial, just finding the highest value, why even bother with sample the whole pulse?

Because you are going to be finding the maximum value of the sampled data. You have to sample before you can find the maximum.

If they only need the max value, a old fashion high-speed peak detector would do the same,

Correct. But I assume you need this signal in some sort of a digital form. Given the peak shown here you would need to have a peak detector before STM32 can have a fighting chance of capturing anything.

So STM32 here does not replace the analog peak detector, it extends its functionality by transferring the data into a digital domain, where it can be processed.

then you can just shoot one adc measure at the detected peak and you have the  height, but theres gotta be more to it that they sample the analog signal??

If your peak detector gives an output when the peak is detected, then yes, you can use that and do just one measurement. 

Also, who are "they" here?

[sgt_johnny]

I refered "they" as the companies that actually produce the commercial products like Amptek with the DP5

http://experimentationlab.berkeley.edu/sites/default/files/images/DP5_User_Manual_A1.pdf

See page 5, the light blue trace is the one that is fed to the adc, still a analog pulse.

[Mechatrommer]

i will have an array of adc values which, on what mathematical formula i do calculate the Pulse height?

Interpolation... and the one that is well known to be highly coupled with sampled / digitized data following Nyquist–Shannon sampling theorem is Whittaker–Shannon interpolation. using that you need to ensure to certain degree your sampling system is following the rule. my eyeball telling me you need at least 50 - 300 MSa/s ADC (minimum) and equivalent circuitry / mcu processing to capture at that rate. but then, peak detect circuit could be cheaper.

[ataradov]

See page 5, the light blue trace is the one that is fed to the adc, still a analog pulse.

Well, the width of the raw pulse there is 10 us, which can be reasonably sampled by the MCU. So depending on further requirements, direct sampling is just a way to have more flexibility and same some external parts on the peak detector.

That's why it is important to specify the actual pulse parameters.

Although even there MCU is only used for communications and control. The main thing appears to be an ASIC  with "ADC Clock Rate 20 or 80 MHz, 12 bit ADC". So far beyond what MCUs can do.

And to capture your pulse directly will indeed require development of a decent scope front end. Not impossible, but impractical if you can get away with a peak detector and a slow ADC.

[sgt_johnny]

Although even there MCU is only used for communications and control. The main thing appears to be an ASIC  with "ADC Clock Rate 20 or 80 MHz, 12 bit ADC". So far beyond what MCUs can do.

And to capture your pulse directly will indeed require development of a decent scope front end. Not impossible, but impractical if you can get away with a peak detector and a slow ADC.

The Processor on the Amptek dp 5 is a  Silicon Labs 8051F340 with 48MIPS, 64k Memory and 4k of RAM,

For example an STM32H7 can deliver up to 800MIPS with over 1Mb Memory, 1Mb of RAM so i guess sampling a 80MHz should be possible. Also STM has DMA which can reduce CPU load..

[iMo]

So you want to detect and measure the amplitude of a random pulse train coming from a detector (a diode detector I assume). In such case you most probably needs:

diode_detector(with_shaper)--->pulse_detector-->ADC--->MCU--->data

Pulse detector: You may use a traditional "peak detector" with 2 opamps + 2 diodes + capacitor and a mosfet transistor for the peak detector's capacitor (the capacitor memorizes the amplitude of the pulse peak) reset (reset to 0Volt).

You would also need a fast comparator (1-5ns) set to say 5mV trigger level, to tell the MCU "the pulse has been detected and its amplitude has been memorized in the peak detector's capacitor" such the MCU may start to measure its amplitude (the MCU uses its build-in ADC).

After the ADC finishes the conversion (it usually takes hundreds of nanoseconds best case), the MCU reads the ADC value, the MCU writes the value into an Array[sample_num], and then the MCU resets the memory capacitor in the peak detector such it prepares itself for the next pulse processing.

Unless you work inside a nuke reactor the number of the pulses will not be more than a few thousands per minute. That is easy to manage with almost any decent MCU.

The speed of an MCU ( ie. in MIPS) has nothing to do with your ability to sample the pulse directly with the build-in ADC. There are no such MCUs with built-in ADC which can sample a 40ns long pulse directly.

[sgt_johnny]

So you want to detect and measure the amplitude of a random pulse train coming from a detector (a diode detector I assume). In such case you most probably needs:

detector--->pulse_detector-->ADC--->MCU--->data

Pulse detector: You may use a traditional "peak detector" with 2 opamps + 2 diodes + capacitor and a mosfet for the peak detector's capacitor (it memorize the amplitude of the pulse peak) reset.

You would also need a fast comparator (1-5ns) set to say 5mV trigger level, to tell the MCU the "the pulse has been detected and its amplitude has been memorised in the peak detector's capacitor" such the MCU may start to measure its amplitude (MCU uses its build-in ADC). After the ADC finishes the conversion (it usually takes hundreds of nanoseconds best case), the MCU resets the memory capacitor in the peak detector and prepares itself for the next pulse processing.

Unless you work inside a nuke reactor the number of the pulses will not be more than a few thousands per minute. That is easy to manage with almost any decent MCU.

The speed of an MCU ( ie. in MIPS) has nothing to do with your ability to sample the pulse directly with the build-in ADC. There are no such MCUs with built-in ADC which can sample a 40ns long pulse directly.

The detector is a PMT which creates a "short" in the supply voltage of 600-1000V which causes the supply voltage to fall. This is coupled via a capacitor to create a negative amplitude of about 5V.

The pulses can arrive around 60k/s for reference. With my 10uCi Calibration Source i get around 8000 imp/s. Depending on Detector size, so 1k imp/s should be the upper limit for my circuit.

I'm thinking about using a peak detector, but i just was wondered why most commecrcial applications rather sample the pulse, instead of using a old fashion peak detector

[iMo]

..
The pulses can arrive around 60k/s for reference. With my 10uCi Calibration Source i get around 8000 imp/s. Depending on Detector size, so 1k imp/s should be the upper limit for my circuit.

I'm thinking about using a peak detector, but i just was wondered why most commecrcial applications rather sample the pulse, instead of using a old fashion peak detector

The 60k/s is still feasible with an 100MIPS++ MCU I guess. The question is how many energy bins (==memory size) you expect. Mind there always will be a "dead time" unless you run more peak detectors in parallel.

The commercial apps may use an FPGA in front of the MCU, where the FPGA directly samples via a fast external ADC and pushes the data to an external memory chip. The data are then read out by the MCU for further processing. Something a "normal" oscilloscopes do.

[rstofer]

According to the reference manual linked above, the sample rate is either 20 MHz of 80 MHz.  This makes sense if we need to accurately represent a narrow pulse that happens every once in awhile.

The manual also gives a complete discussion of the commercial version including block diagrams, schematics and discussion.

[iMo]

According to the reference manual linked above, the sample rate is either 20 MHz of 80 MHz.

Hmm, the 8051F340 includes a 200ksps 10bit adc based on the datasheet. I've done my best but I've been not successful with identifying other components/chips there in the manual.. (except a MAX7328 i2c expander and an Analog Devices chip, it might be it is the fast ADC).

PS: while looking into the stm32H7 datasheet the max ADC speed is 6MSPS with 8bits res.

[mark03]

This has been done with simple hardware; see https://www.theremino.com/en/blog/gamma-spectrometry

The sampling theory for pulse-height analysis is very interesting.  It falls into a class of problems known as "finite rate of innovation" (google search term).  The usual thought experiment goes something like this:  You are monitoring a stream of dirac impulses with random amplitudes and arrival times.  By passing this signal through a filter which meets certain criteria and sampling the output, it can be shown that perfect reconstruction is possible at a low sampling rate which covers the "rate of innovation" in the signal.  The reconstruction algorithm is [so far] quite processor-intensive, so to the best of my knowledge this exact/perfect solution has not yet been applied in gamma spectroscopy.  But the thermino people seem to get nice spectra for amateur setups.

Disclaimer:  I haven't tried any of this myself yet, I just have a couple of nice medical-grade PMTs in the junkbox waiting to be used "when I have the time".

[ataradov]

The Processor on the Amptek dp 5 is a  Silicon Labs 8051F340 with 48MIPS, 64k Memory and 4k of RAM,

But it is not doing the main work. That big 144-TQFP chip in the middle of the board does. And this is some sort of proprietary chip or an FPGA.

For example an STM32H7 can deliver up to 800MIPS with over 1Mb Memory, 1Mb of RAM so i guess sampling a 80MHz should be possible. Also STM has DMA which can reduce CPU load..

It does not matter. To get those parameters, STM32H7 alone is not sufficient, and it is way overkill for the comms.

[iMo]

As I wrote above the "dp5 manual" is pretty funny document. There is literary no information how the stuff works The main components which do the trick (the FPGA/Asic and the ADC) are the "blackboxes" only. Or, it might be, my pdf reader is a crap
PS: they mention (at about 4 places) the FPGA is there:

A demonstration program written in Visual Basic is provided. Amptek also provides an “Upload Manager”, permitting new releases of the DP5s firmware and FPGA code to be programmed into the DP5 in the field, using the RS232 interface.

[ataradov]

Why would they disclose internal workings of the device? To me it looked like there is more information provided than needed for normal use. The device has inputs and outputs. Both are documented.

[iMo]

Yea, but we cannot make an SDR out of it then 

[jmelson]

The pulses can arrive around 60k/s for reference. With my 10uCi Calibration Source i get around 8000 imp/s. Depending on Detector size, so 1k imp/s should be the upper limit for my circuit.

Well, using a micro at 60K pulses/second is going to be tricky.  That is only 16 us between pulses, so if you need to get just about all of the pulses, you would at least need a very fast micro.  The processing per pulse is pretty easy, though, you just get the digitized sample, look up one location in a table and increment it.  If you don't want a live display, that is pretty easy.  If you DO want a live display as the spectrum is accumulating, then you have to time share between the acquisition function and the display update function.  Most commercial PHAs have the acquisition part entirely in hardware, to a dual-port memory, and then the display is formatted and updated by the micro.

Jon

[langwadt]

The Processor on the Amptek dp 5 is a  Silicon Labs 8051F340 with 48MIPS, 64k Memory and 4k of RAM,

But it is not doing the main work. That big 144-TQFP chip in the middle of the board does. And this is some sort of proprietary chip or an FPGA.

yep, afair it is a Xilinx FPGA

many years ago I did a pulse processor for the amptek pa-230 with an FPGA and a 50MHz ADC

[rstofer]

Why would they disclose internal workings of the device? To me it looked like there is more information provided than needed for normal use. The device has inputs and outputs. Both are documented.

I don't have a clue about what is being done, it's not my line of work.  OTOH, I thought there was enough information in the manual to reverse engineer the system without too much difficulty.  Yes, there are some complex bits and they would require some thought but you basically have the entire hardware block diagram given plus a description of all the blocks.

Figure 2-1 gives the big picture and the description of the analog prefilter in section 2-2 seems pretty complete.  I don't intend to build a system like this but it sure seems like a lot of information is provided.

OTOH, I don't want to minimize the software and firmware.  Knowing what the blocks are supposed to do and actually implementing them are two entirely different things.  I suspect it will involve quite a bit of engineering stuff plus a lot of fine tuning.

I would think that an FPGA will be required to keep up with the 80 MHz sample rate.  That's the way the manufacturer did it and it may be the best way to go.  Still, an Analog Devices Blackfin might be just the CPU for this if a one chip design was desired.  Running at 600 MHz with internal DSP might provide just the resources needed.  Or the Sharc...  I have not checked the datasheet to see how fast the DMA will run.

[MasterT]

IMHO, math itself is could be simple as FIR filtering, they mention trapezoidal - quite possible. 
The trade between hardware solution (peak detector) and software (fast sampling + FIR integration) is the ratio performance vs cost. I think, that physics of the sensor (XR-100 or whatever) apply certain limitation on the resolution, since detector has an intrinsic capacitance, and RC constant limits fast rising edge of the pulse, making it more "rounded" and consequently hardware ( peak detector) could not precisely measure magnitude. Sharp peak is distorted. Same with first stage of the amplifier, due limitation of the GBW it doesn't make pulse any better, rather worse, smoothing fast edges even more. Though, to get better  accuracy the DSP processing seems right way.

[rhb]

Take a look at the LPC4370.  It's used in the LPC Link-2 programmer which can be reprogrammed with another Link-2.  The LPC4370 has an 80 MSa/S 12 bit ADC.  The Link-2 is $20  from Digikey.

You might also want to look into "compressive sensing".  The math is seriously painful, but it's easy to use and apply.  It trades a lot of CPU cycles for fast ADC.

[dmills]

Didn't AOE 1st edition have a design for a PHA using a 68k CPU as one of the examples?
Painfully old school by todays standards, but it may give you some ideas.

Regards, Dan.

[iMo]

..and RC constant limits fast rising edge of the pulse, making it more "rounded" and consequently hardware ( peak detector) could not precisely measure magnitude. Sharp peak is distorted..

Not sure.. It depends on the peak detector's construction. It must be fast enough, in case the OP uses opamps they must be with large BW (xxx MHz). No problem with measuring the 40ns pulse amplitude then.

Interestingly it could be a problem with ADC+FPGA - with ie. 80MHz sampling rate you have got 12.5ns sampling period, therefore you can miss the max amplitude of a 40ns wide pulse pretty easily..