9 Replies Latest reply on Aug 21, 2014 1:12 PM by awadood7

    Time Stamping on a NanoSecond Scale

    awadood7

      Hello BeagleBone Experts!

      I'm making a coincidence counter for an optics experiment.

       

      So currently the problem is this:

      An event of interest occurs at a frequency of 6-7KHz. This is in the form of 50ns pulses. I need to 'time-stamp' these events i.e. at what time they occured. (based on the rising edge)

       

      The simple approach I'm trying here is to run a timer with a fast clock and whenever the event occurs, save the timer value.So the external clock needs to be of time period 1,2 or 5ns. BBB datasheet mentions 32-bit timers.

       

      So do the BBB timers run on the 1GHz processor clock? Or do they run on a slower clock?

       

      Another problem would be the time taken to latch the value of the timer to a storage register. Does it take many clock cycles(and which clock) or does the latching occur in an analog fashion(on order of picoseconds)?

       

      People have also recommended Enhanced Capture Module and PRU. Will these work?

       

      Any timer+capture module running above 200MHz would be fine.

       

      This is my first ever experience with BeagleBones. I'm also not an expert on FPGAs and have just worked on Micro-controllers previously.

       

      Is this project beyond BBB capability? Faster FPGA would suit better? Any suggestions for the task at hand would be welcome.

        • Re: Time Stamping on a NanoSecond Scale
          DAB

          Hi Wadood,

           

          You might want to try a fast running clock and a fast memory chip.

          You clock the memory at the 6-7K rate and then clock a faster memory chip when you detect the burst of pulses.

          If you do not need to time stamp each 50-nsec pulse, then you can do this easily with a static memory chip.

           

          DAB

          • Re: Time Stamping on a NanoSecond Scale
            Kilohercas

            simple FPGA or CPLD can do this for you, simple counter , PLL, and other logic

            • Re: Time Stamping on a NanoSecond Scale
              shabaz

              Hi Wadood,

               

              The BBB timers don't run at 1GHz as far as I'm aware; they may run at 100MHz or lower (I'm only 75% certain - I only quickly scanned the documentation), and would require you to write a driver for Linux. The PRU that you mention is an option, and there is existing code that can capture sustained at 100MHz for a near-indefinite period to capture your events (I'm assuming they are not repetitive) - there is a 100Msps logic analyzer project, see here for some information.

              However, that gets you 10nsec resolution; if you need higher resolution then you probably need to create some hardware, I don't think an off-the-shelf SBC alone will do it. DABs suggestion is pretty good, since if you only need to timestamp events at a rate of every 6-7kHz, then a fast counter could be captured in a register that can be read when latched, by any SBC (or stored away in memory as DAB mentions). It may need something like a 16-bit counter though. It may need programmable logic, e.g. a fast CPLD. Another option could be an oscilloscope if you have access to one for the duration of your experiment.

                • Re: Time Stamping on a NanoSecond Scale
                  awadood7

                  I need to timestamp on a nano-second scale. Yes the event frequency is 6KHz but there are multiple events and I want to compare the time axes.

                   

                  Where can I look in the Datasheet for the Timer clock? It just isn't clear to me after reading the article on Timers.

                   

                  And how fast is the eCAP module? I also could not decipher it from the datasheet.

                    • Re: Time Stamping on a NanoSecond Scale
                      shabaz

                      Hi Wadood,

                       

                      The mentioned solution would timestamp on a nanosecond scale; the point is that if each event occurs at a rate of 6-7kHz, then that gives you time to transfer the nanosecond-scale timestamp to memory (e.g. onto an SBC).

                      The detailed document is 4700 pages document called spruh73j.pdf that you need to look at. From a brief look, the timebase is clocked from SYSCLK which can be up to 200MHz. So 5ns granularity may be possible.

                        • Re: Time Stamping on a NanoSecond Scale
                          awadood7

                          So you're saying that a fast CPLD or FPGA could implement such a counter, right?

                          An oscilloscope is out of question. So I guess it's either this timer on BBB, or FPGA, or a TDC chip I'd have to use. I'm going through the spruh73j.pdf, thanks for telling me about it.

                            • Re: Time Stamping on a NanoSecond Scale
                              shabaz

                              There's actually another option too. That's the open bench logic sniffer (can be found by google), that can capture at 200Msps apparently. It doesn't have a lot of memory for sustained arbitrary capture, but does have run length encoding which would greatly extend the capture time.

                              It is low cost so possibly worth a shot.

                                • Re: Time Stamping on a NanoSecond Scale
                                  antber

                                  Hi Wadood,

                                   

                                  Regarding the PRU usage:

                                  The PRU is clocked at 200Mhz so it can poll a GPI every 5ns. When the edge is detected on the GPI the PRU can on the next instructions read an timer that is internal to the PRU-ICSS module. Once you have save the time stamps in internal RAM the PRU can jump back to the polling routing.

                                   

                                  I don't know how many inputs you need to manage but may be you can split the jobs between the 2 PRUs.

                                   

                                  Keep in mind that when the PRU access the timer and save time stamp to RAM it does not poll the GPI pins. So you will need to see how long this takes and if the delay to come back to polling is acceptable for you.

                                   

                                  A.