I would like to use a PicoScope to analyze the signal generated by a silicon photomultiplier, which is basically a sequence of this kind of pulses: http://www.ketek.net/typo3temp/pics/dc39cec061.jpg
(where the slow component time constant can be as short as a few tens of ns, and the rise time can be less than 1 ns) occurring with a frequency of less than 1-2 MHz - so, pulses lasting around 50-200 ns separated by an average dead time of 500-1000 ns. While the time constants do not change, the integral of these pulses will be directly proportional to the number of detected photons.
My goal is to capture all of these pulses, in principle for an indefinite time, and to extract, from each of them, a timestamp and some meaningful information about the number of photons which triggered the pulse - it could be the integral of the pulse for a certain time after the rising edge, or just the values of a few samples taken at a fixed time after the rising edge, provided that this time is very accurate. All of this should be possibly done in real-time.
The best solution that came into my mind would be to have the oscilloscope providing in real time only a fixed number of samples (approx 100) after the trigger, which would be a simple level trigger to detect the rising edge of the pulse. I just would like to know if this should be feasible with the PicoScope 6403C my lab just bought, before start working on it and maybe waste some weeks on something which instead is simply impossible to do
I thought about two possibilities:
1) use streaming mode
2) use rapid block mode
About 1, I didn't understand very well how the trigger in streaming mode works. If the trigger event actually triggers the collection of a fixed number of samples, and the oscilloscope can stream them as soon as possible without dead times, then I think it would be ok.
The problem is that, from what I could understand by looking at the ExampleStreaming LabVIEW VI provided in the SDK, it seems that acquisition starts immediately regardless the trigger, and that the trigger event stops the acquisition rather than starting it (sometimes the trigger event is not even detected). If this is the way it works, I guess the only way I could use streaming mode in my application would be to use no PicoScope trigger, to analyze in real time the streamed data by implementing a software trigger and then storing a few samples after the pulse rising edge.
However, since the samples are taken asynchronously with respect to the pulse rising edges, and since it appears to me that the minimum sampling interval is 7 ns (by trying to reduce as much as possible the sampling interval in the ExampleStreaming VI), there will be a large time uncertainty associated to the trigger event, and therefore the samples value will have a large uncertainty as well. I'm not even sure that the PC will be able to implement a software trigger fast enough to process in real time the samples taken at 7 ns interval.
Solution 2 appears to me to be the best one for time resolution, but I suspect I can only capture a finite amount of pulses until the oscilloscope memory will be filled, and then there will be a dead time of some tens of ms associated to the data transfer to the PC, during which the oscilloscope is not able to capture anything, am I right?
Thank you in advance.