PicoScope 7 Software
Available on Windows, Mac and Linux
Scope 2208A as counting module
-
PhotonCoder
- Newbie
- Posts: 0
- Joined: Thu Apr 23, 2020 9:00 am
Scope 2208A as counting module
Hi all,
I am currently working on an application using an avalanche photodiode as a photon counter, which generates pulses that I want to sample with a Picoscope 2208A and count them, getting a value of pulses/second.
The pulses have a width of 10 ns and can occur every 20 ns (~50 MHz) so according to the specs of 1GS/s sampling rate the device should be totally fine. In principle I also do not need the form of the pulse, just if it's there
Here's what I want to do: Along with the SDK and Labview implementation I want to use the Picoscope in triggered rapid block mode as to catch as many pulses as possible before memory overflows. However I am a bit unsure if this is actually a feasible way to do this as even with millisecond integration time it will be already 50k pulses and thus over twice the limit for the buffer memory (which is a bit less than 25k) and I think the streaming to the PC takes longer than one ms. What would generally be enough however is measuring as many pulses with as few samples as possible (as I am interested in only the count per second) and then extrapolating this, but then I would need very accurate information on the time segment (e.g. the scope measured for 100 µs, and with the trigger 50 waveforms were captured -> 500k waveforms/pulses per second).
Do you think this sort of application and coding it in this way is feasible or is there a smarter way of solving the problem? Help and comments would be greatly appreciated.
Cheers,
PhotonCoder
I am currently working on an application using an avalanche photodiode as a photon counter, which generates pulses that I want to sample with a Picoscope 2208A and count them, getting a value of pulses/second.
The pulses have a width of 10 ns and can occur every 20 ns (~50 MHz) so according to the specs of 1GS/s sampling rate the device should be totally fine. In principle I also do not need the form of the pulse, just if it's there
Here's what I want to do: Along with the SDK and Labview implementation I want to use the Picoscope in triggered rapid block mode as to catch as many pulses as possible before memory overflows. However I am a bit unsure if this is actually a feasible way to do this as even with millisecond integration time it will be already 50k pulses and thus over twice the limit for the buffer memory (which is a bit less than 25k) and I think the streaming to the PC takes longer than one ms. What would generally be enough however is measuring as many pulses with as few samples as possible (as I am interested in only the count per second) and then extrapolating this, but then I would need very accurate information on the time segment (e.g. the scope measured for 100 µs, and with the trigger 50 waveforms were captured -> 500k waveforms/pulses per second).
Do you think this sort of application and coding it in this way is feasible or is there a smarter way of solving the problem? Help and comments would be greatly appreciated.
Cheers,
PhotonCoder
Re: Scope 2208A as counting module
Hi PhotonCoder,
don't know if your question is still active. If yes: I am doing a similar application in python. I count pulses in order to get the rate. However, our rate is smaller.
So I think in your situation 2 options are available:
1) rapid block mode with short recorded pulses, taking as many pulses as possible. Take the CPU time of your computer needed for taking one block of pulses. Repeat for at least an hour (20min at the beginning are waste due to warm-up time). Then take the mean of your rates (pulses / CPU time).
Before calibrate your module and find out what your deadtime/setup time between pulses is. It is probably around 2us [1]. To some degree up to some rates, you can simply correct your rate. CPU time is probably accurate to around 1us. But if you are unsure you should also calibrate that. See link [2]
2) Second approach: more accurate at high rates, but very slow:
You can set your record length as long as possible. Transfer this readout to your PC and do offline triggering on this waveform. Count the pulses and divide them by the duration of your recorded trace. Then repeat many times (see 1). This works for high rates but the transfer of data and offline triggering/counting takes long time.
With method 1) you measure >> 50% of the time and with method 2) you measure << 50% of your time. If possible, take method 1).
Best wishes,
Anna
[1] see links in this post topic42433.html
[2] https://stackoverflow.com/questions/113 ... time-sleep
don't know if your question is still active. If yes: I am doing a similar application in python. I count pulses in order to get the rate. However, our rate is smaller.
So I think in your situation 2 options are available:
1) rapid block mode with short recorded pulses, taking as many pulses as possible. Take the CPU time of your computer needed for taking one block of pulses. Repeat for at least an hour (20min at the beginning are waste due to warm-up time). Then take the mean of your rates (pulses / CPU time).
Before calibrate your module and find out what your deadtime/setup time between pulses is. It is probably around 2us [1]. To some degree up to some rates, you can simply correct your rate. CPU time is probably accurate to around 1us. But if you are unsure you should also calibrate that. See link [2]
2) Second approach: more accurate at high rates, but very slow:
You can set your record length as long as possible. Transfer this readout to your PC and do offline triggering on this waveform. Count the pulses and divide them by the duration of your recorded trace. Then repeat many times (see 1). This works for high rates but the transfer of data and offline triggering/counting takes long time.
With method 1) you measure >> 50% of the time and with method 2) you measure << 50% of your time. If possible, take method 1).
Best wishes,
Anna
[1] see links in this post topic42433.html
[2] https://stackoverflow.com/questions/113 ... time-sleep