Photon Counter

Status
Not open for further replies.

jofre

Member
Dear all,

I am considering the Teensy3.6 (the fastest Arduino like board that I know of) to develop a photon counter (I am physicist).

I am looking to reproduce the "Buffered Edge Counting" mode found in many National Instruments boards. I attached a figure from the National Instruments manual.

Buffered_Edge_Counting.png

The idea is to fill a buffer with the number of clock ticks since a trigger signal happens (SOURCE in the figure) each time that a rising edge occurs ("Sample Clock" in the figure, this is coming from the photon multiplier). Because a clock tick is associated to a time, it is possible to convert to time if needed.

The closest I found to my problem is the code found here: https://github.com/tni/teensy-samples/blob/master/input_capture_dma.ino

But the code is a bit above my current level: I have to admit I am not in position to modify that code to do what I need. I can put time and effort if it is worthy...

I am not asking to do the work for me, but I was hoping that some of the experts around here could answer the questions: Can the above be done? If yes, which performance can be realistically be achieved? By performance, I mean, what will be the time resolution that can be achieved, including sending the data to a PC (python serial?). I need to achieve, at least, 20ns resolution. (the National Instruments X-Series boards provides 10ns, but cost 40 times what a teensy3.6 board cost!)

If you read until here: thanks a lot!

PS: I know that FPGA are probably better for this, but I have some experience with Arduino boards and zero with FPGAs technologies...
 
Don't know if will work, but I'd look into using the input capture capability of a T3.6 Flexible Timer Module (FTM).

First though, your "Requirements Document" needs to be fleshed out quite a bit:

* Does it need to detect photons and transmit data to the PC continuously and simultaneously? Or, can you have an acquire mode to gather samples followed by a data transmission mode to send the data?

* If you can have two modes as described above, how much data do you need to acquire before switching over and sending it to the PC? Is it based on time or number of "hits" detected?

* How deep do the buffers need to be?

* Is there a lower bound on the time between rising edges of your "Sample Clock"?

* What is the minimum "High" time of your "Sample Clock"? Minimum "Low" time?


Those are the questions I can think of right now.
 
I was going to say it... (I was not sure that somebody was going to answer a 2 years old thread...)
Should I delete this thread?
 
Status
Not open for further replies.
Back
Top