Real time processing of ns pulses

Post general discussions on using our drivers to write your own software here
Post Reply
m.asiatici
Newbie
Posts: 0
Joined: Fri Mar 14, 2014 12:37 pm

Real time processing of ns pulses

Post by m.asiatici »

Hi,

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.

Best regards,

Mikhail

Karunen
Advanced User
Advanced User
Posts: 194
Joined: Thu Nov 21, 2013 9:22 am

Re: Real time processing of ns pulses

Post by Karunen »

Hi Mikhail,

You are correct in how the streaming trigger work and the rapid block capture works.

Streaming mode is unlikely to return values every 7ns as this would put a heavy load onto your PC.

What it does instead is fill a buffer that you registered with the driver (the overview buffer) and then that section of data is copied over in the streaming callback.
So you should be able to process the data as it is retrieved into your application.


Unfortunately the only way to get real time processing would be by using streaming mode capture,
as with the others you simply catch a block or a lot of blocks and then retrieve it from the device.

Thanks,
Karunen

Technical Specialist
Pico Technology

m.asiatici
Newbie
Posts: 0
Joined: Fri Mar 14, 2014 12:37 pm

Re: Real time processing of ns pulses

Post by m.asiatici »

Hi Karunen,

thank you for your reply.

What happens if the overview buffer gets completely filled before the data is retrieved? The acquisition is stopped or the old data is overwritten? Does the driver tell me if such buffer overflow condition happen?

Thank you.

Best regards,

Mikhail

Karunen
Advanced User
Advanced User
Posts: 194
Joined: Thu Nov 21, 2013 9:22 am

Re: Real time processing of ns pulses

Post by Karunen »

Hi Mikhail,

Every timeGetStreamingValues.vi is called it will fill the overview buffer depending on the samples stored in the driver buffer.

The driver buffer will fill the overview buffer from where the last last value was copied over.

Since you will require a fast streaming the overview buffer will most likely overwritten each time,
in the Lab View example the previous values are stored within the plotting history,
while in the C example we output each overview buffer to file.

Please note if the GetStreamingValues.vi is not called fast the driver buffer will fill up and then stop collecting,
this will introduce some latency.

If this occurs you will get corrupted data,
the driver will not warn you if this happens.

The StartStreaming should allow you to output the actual sample interval,
this will tell you what the device is setting the sample interval at.

You can use this to test and find the fastest sampling rate that you can use while processing the data.

Thanks,
Karunen

Technical Specialist
Pico Technology

m.asiatici
Newbie
Posts: 0
Joined: Fri Mar 14, 2014 12:37 pm

Re: Real time processing of ns pulses

Post by m.asiatici »

Hi Karunen,

thank you very much.

I would have just one more question, this time about rapid block mode, since I am exploring also this possibility.

From what I understood, it seems to me that the ps6000GetValuesTriggerTimeOffsetBulk64 function could be the best way to extract the timestamp of each pulse. In the Programmer's Guide I read:
This function retrieves the 64-bit time offsets for waveforms captured in rapid block mode.
but I could not understand exactly what these times offsets are referred to. Is it the time difference between the occurrence of the trigger event of the current waveform with respect to the previous waveform? Or is it somehow referred to the beginning or end of each captured waveform?

What confuses me even more is that I am trying to capture some known pulses obtained from a function generator, but I do not manage to relate in any way the times I obtain with the properties of the waveform I am acquiring. For instance, if I acquire a sequence of 0 V/1 V pulses 20 us wide with a 1 ms period, with trigger on rising edge at 500 mV, 20 pre-trigger samples, 50 post-trigger samples, 50 waveforms, timebase 160 corresponding to about 1 us of sampling period, I obtain:

- always 0 (so PS6000_FS) in the timeUnits array
- either 242639049 or 245638101 in the times array

which would lead to about 240 ns, which I cannot relate to any of the waveform parameters. These values do not depend on the number of pre/post trigger samples and surprisingly not even on the pulses period, but seem to be proportional to the sampling period, since if I move to timebase 360 (corresponding to approx 2 us of sampling period) I get three discrete values in the times array corresponding to approx 479 to 495 ns.

Briefly, how do I interpret the values returned by the ps6000GetValuesTriggerTimeOffsetBulk64 function? Is this the function to be called to obtain the timestamp of the waveforms in rapid block mode, or is there any function which can do this job better?

Thank you.

Regards,

Mikhail

Karunen
Advanced User
Advanced User
Posts: 194
Joined: Thu Nov 21, 2013 9:22 am

Re: Real time processing of ns pulses

Post by Karunen »

Hi Mikeal,

The time offset is the time from when the trigger event occurs to when the first sample is taken.

Please could you email to support@picotech.com,
where we can discuss your application further.

Thanks,
Karunen

Technical Specialist
Pico Technology

m.asiatici
Newbie
Posts: 0
Joined: Fri Mar 14, 2014 12:37 pm

Re: Real time processing of ns pulses

Post by m.asiatici »

Hi Karunen,

thank you very much for your help. I just wrote you.

Regards,

Mikhail

Post Reply