3 Replies Latest reply on Apr 22, 2015 11:03 AM by intel_jassowski

    Pulse detection on the order of nanoseconds?

    Pawnbrake

      Question: How do I detect the time between a train of pulses that are on the order of nanoseconds with my Intel Edison?

       

      I want to see if it is possible to detect a set of pulses with my Intel Edison.  I do not have much experience with electronics, so this project is intended to be a big learning experience for me. 

       

      About the pulse train: I have a photon detector that emits a pulse when it receives a photon.  This pulse will remain in a high voltage for 30ns, and there is a minimum of 50ns of dead time between pulses.  Pulse dead/low voltage is 0-0.8V; pulse high voltage is 3.5-5.25V.  The important data to measure is the **time between each pulse**.

       

      I have done some research on time-to-digital converters and I think I want to build something on the Edison that has a similar structure to the wikipedia page.     I think that the idea I have is standard for these types of devices:

       

      First, convert the pulse train with a schmitt trigger to voltages that the later components can use.  Then, have a counter count clock cycles until a pulse arrives.  When a pulse arrives, capture the counter in an output register and send this data serially to the Edison.  Then, reset the counter.

       

      I have several hurdles that I am trying to overcome to build said device:

       

      1. 30ns + 50ns = 80ns.  With cycles at a minimum of 80ns, we will need some kind of fast clock resolution in order to process this data.  I know that the Intel Edison has a fast clock, but from my understanding the GPIO pins can only detect pulses that are five clock cycles long.  As well, the Edison can only output a clock at a rate of 19.2 MHz.  This means that it has a resolution of 260 ns, which is far too slow to process said data.  I think my understanding of the best way for the Edison to receive the data is wrong since I am new to this.  Is my understanding correct that I cannot use this, or is there a way that I can?

       

      2. When the counter is captured and sent through the output register, does it need any type of encoding (UART for example)?

       

      3. What kind of mechanism can I use to stop & reset the counter and shift the data to an output register?

       

      Two possible answers to my question:

       

      1. Help me to overcome my hurdles

       

      2. Make a different suggestion that also works.

       

      If anyone can help me overcome these hurdles then I would be very happy.  Or, if there is a better/more efficient way to measure the time between each pulse, I am all ears.  Is it possible to program the counter into the Edison?  That would remove several parts, however, I have done research to no avail.

        • 1. Re: Pulse detection on the order of nanoseconds?
          Slugskickass

          HI, it sounds like you want to build a photon counter, I don't think the Edison will do this on its own, the reason I say this is normally a photon counter is built on a dedicated clock / counter chip.  The Edison will be running linux or controlling an Arduino neither of these have the capability of latching a time in to a counter on the receipt of a signal. There are some I2C counters you may be able to use.

          • 2. Re: Pulse detection on the order of nanoseconds?
            CMata_Intel

            Hi Pawnbrake

             

            About the hurdles you were talking about:

            1. Yes, in the Hardware Guide for the Edison Compute Module, you can see that the pulse should be five clock cycles long to be detected, so yo will have "100 ns for a 50 MHz clock when SoC is in S0 state"

            2. Are you using a shift register?

            3. Have you tried to use a pin like a trigger and use it as enable or reset in the other components?

             

            Another way to do it could be creating a code that calculates and saves the time that the pulse stays as HIGH or LOW.

             

            Regards;

            CMata

            • 3. Re: Pulse detection on the order of nanoseconds?
              intel_jassowski

              I think you'll find that -- as defined -- this task could be challenging for many microcontrollers.

              Not only do you need to worry about the minimum delay between pulses (80ns), but you also need to think about what resolution (accuracy) you want to measure that period with.  Are you trying to distinguish between 80ns and 81ns, or between 80ns and 100ns, or between 80ns and 1000ns?

              Do you care about the individual pulse readings, or are will you be averaging the pulses over some period?

               

              For example, detecting the difference between 80ns and 81ns requires a clock frequency on the order of 1Ghz, well beyond what you can reasonably achieve with standard prototyping components.  And that only measures your dead time (50ns) with an accuracy of +/- 2%.  If +/-10% is acceptable, then you'd still be working with a 200MHz timebase -- which still requires careful design (any wire over ~6" at this frequency is an antenna).

               

              If, however, you can count the number of events in a period of time, you can determine the average pulse period for that time.  Since the pulses are arriving at no faster than 80ns, then you only need a 20Mhz counter to accumulate the pulses.  This counter can then be read and reset at a much more reasonable rate for a microcontroller.

               

              Something like this: http://www.lsicsi.com/pdfs/Data_Sheets/LS7366R.pdf might work well.

              32 bits would give you 200 seconds of counting at the maximum expected pulse rate.  You can count much shorter periods, limited by the speed at which you can read and reset the counter with Edison (or other controller), and the accuracy you need (the fewer pulses you count, the lower your timing accuracy).

               

              If, however, you are looking for the minimum dead-time (rather than the average), and need to know the delay accurately, this task will be much harder.