info@iliaplatone.com said: > These events are random photon arrivals (converted to 5vTTL pulses), their > rate was measured using the pulse width of the smaller detected, which was > 5~10 uS during an observation in low-light environment. The photon arrival > and pulse width were random with a minimum pulse width of 10uS. What I want > to do is measuring the photon arrival precisely (low to high transition - > interrupt I guess), consider that the maximum rate would be 100Kcps because > the photon events would overlap if higher. If the 3130 controller can > handle such rate it would be great :) I think your 100K samples per second is going to be exciting. You can collect some data by writing some code and connecting up a signal generator. Start with a slow frequency to debug the software than turn it up and see how fast you can go. I assume it's OK if some (but not many) samples are lost. You (or I) may be confusing the data rate. There are two issues. One is the peak rate. That sounds like your 100K above. The other is the average. How many samples do you expect in a typical second? If that is low enough, you can solve the peak problem with enough buffering. My straw man would be a FPGA. The idea is to collect a batch of pulse arrival times and DMA them into memory. When the buffer fills up or a timer expires, it would finish that block and switch to the next one. You could feed a PPS to the FPGA if you want timing linked to the outside world rather than just relative times. -- These are my opinions. I hate spam.

On 10/20/16 22:08, Hal Murray wrote: > info@iliaplatone.com said: >> These events are random photon arrivals (converted to 5vTTL pulses), their >> rate was measured using the pulse width of the smaller detected, which was >> 5~10 uS during an observation in low-light environment. The photon arrival >> and pulse width were random with a minimum pulse width of 10uS. What I want >> to do is measuring the photon arrival precisely (low to high transition - >> interrupt I guess), consider that the maximum rate would be 100Kcps because >> the photon events would overlap if higher. If the 3130 controller can >> handle such rate it would be great :) > I think your 100K samples per second is going to be exciting. > > You can collect some data by writing some code and connecting up a signal > generator. Start with a slow frequency to debug the software than turn it up > and see how fast you can go. > > I assume it's OK if some (but not many) samples are lost. > > You (or I) may be confusing the data rate. There are two issues. One is the > peak rate. That sounds like your 100K above. The other is the average. How > many samples do you expect in a typical second? If that is low enough, you > can solve the peak problem with enough buffering. > > My straw man would be a FPGA. The idea is to collect a batch of pulse > arrival times and DMA them into memory. When the buffer fills up or a timer > expires, it would finish that block and switch to the next one. You could > feed a PPS to the FPGA if you want timing linked to the outside world rather > than just relative times. > This was the very first approach. But.. err.. I'm trying to determine more precisely the pulse width right now, so the maximum event rate. The real problem is my analogue oscilloscope that seems to lose time at peak detection: it shows a ramp at each pulse raise. If this can help, I attach a photo with the reading of my oscilloscope (2uS/div, 1V/div). not all pulses saturate, but can be detected by a CMOS input. It's difficult to sync because of the high entropy of this signal. Let me know if you can give me any hint on how to setup the oscilloscope.. Best Regards, Ilia. -- Ilia Platone via Ferrara 54 47841 Cattolica (RN), Italy Cell +39 349 1075999