6 Replies Latest reply on Jul 31, 2015 10:02 AM by userc_41119

    Timestamp Generation

      How can can I get a 100ns-increment counter in PSoC 4 BLE for the purpose of time-stamping data samples?


      Using a UDB counter, the system complains about clocks and such.


      Accelerometer data is acquired via I2C with an interval of about 3.8 ms between data sets. (this is now working)


      The "time" is to be read out of the counter and applied to the current data set as it begins to come in.


      The data sets are to be shipped to a cell phone via BLE. (this is not working yet)


      A data collection run will be a few (maybe 10 or so) minutes long, during which the time stamp generator needs to run without glitches.


      How can I make the 100ns counter?  It is mainly a question about sources for "count" (10 MHz) and "clock" inputs.


      I've used this time stamping plan on other micro controllers, including PSoC 5 (FirstTouch in 2011).  Creator 3.2 messes up the TopDesign picture, so I can't view the design info there due to missing obsolete components.



        • 1. Re: Timestamp Generation

          100 nS ? The data rate is 10 Mhz ? or you just want that time resolution ?


          BLE will not support a continuous stream of 10 Mhz data.








          Regards, Dana.

          • 2. Re: Timestamp Generation

            thanks for your reply


            100 ns is the time resolution, which is what I used in version 1 of my project.


            Version 2 is to be wireless, which is why I am considering BLE.


            The time resolution doesn't have to be exactly 100 ns, as whatever it turns out to be can be scaled to match the rest of the system.


            The data rate is about 25 bytes every 3.8 ms -> ~7 bytes per millisecond -> 56 bits per millisecond


            That is as fast as the pair of accelerometers can provide data.  Can BLE handle that?


            The data is filtered and integrated, so a time stamp is essential.

            • 3. Re: Timestamp Generation

              The average data rate you pointed out can be easily supported by BLE, but I would like to point out that the minimum connection interval that can be set for a BLE connection is 7.5 ms. This implies that the minimum difference between any two data transfer cannot be less than 7.5 ms.


              So when you say that you need to send 25-bytes every 3.8 ms, it will be more like send 50 (25+25) bytes every 7.6 (3.8+3.8) ms. This implies, in your case, one set of data will se received by the device 3.8 ms later than its original intended time.

              • 4. Re: Timestamp Generation

                Thanks for pointing out the minimum connection interval.  That is not an issue, however, as each data set is to be time stamped at the time of acquisition.  When the data set is actually sent is not important.  I am considering storing the data in F-RAM and sending it later.


                What I need help with is in setting up PSoC 4 BLE so that "time", with a resolution around 100 ns, can be read and applied to each data set as it is grabbed from the accelerometers via I2C polling.


                Any ideas?


                From Document Number: 001-96201 Rev. *A  page 11


                For PSoC 3/PSoC 5LP, you can connect any digital signal from any source to the count/clock
                input. The frequency of that signal is limited to the frequency range defined in the DC and AC
                Electrical Characteristics (UDB Implementation) section in this datasheet. The count input must,
                at most, be half the frequency as that of the clock input in any of the Counter Clock modes.


                For PSoC 4, you cannot connect a clock signal to the count input.


                What can be used for a 100 ns input to "count"?




                Dick C.

                • 5. Re: Timestamp Generation

                  Use a Timer and feed its clock with 10 Mhz.




                  Regards, Dana.

                  1 of 1 people found this helpful
                  • 6. Re: Timestamp Generation



                    Why didn't I think of that!