Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: Teensy 4.0 - Speed of Light (RF) using ToF with nanosecond precision

Hybrid View

  1. #1
    Junior Member
    Join Date
    Sep 2017

    Teensy 4.0 - Speed of Light (RF) using ToF with nanosecond precision

    Measuring RF Time of Flight:

    I would like to create a Time of Flight system with two RF log ICs that each output a pulse when an RF input is detected (5ns response time from each ICs)

    I have a dream that a 600Mhz Teensy 4.0 might be able to resolve or measure time intervals down to 1/600,000,000, or 1.7ns per clock cycle.

    I pray that there is some way to query the clock cycles elapsed between two rising or falling edge logic or analog inputs on a Teensy 4.0 and calculate the time of difference between a pulsed input on a first pin versus pulsed input on a second pin in nanoseconds, hopefully without stopping the counter. This is essentially a poor man's Time Interval Counter (TIC).

    A few questions for the PJRC crew:
    1) Is there an easy way to implement something like nanos() that is similar to millis() with nanosecond precision?
    2) Does a timer exist in the ARM M7 that counts each clock cycle and which can be read out or buffered and later read out?
    3) For the fastest measurements speed on an input pin, are interrupts the way to go or just use DigitalReadFast in a very short loop()?
    4) In the Teensy 3.5 forum, Frank B mentioned using " cyclecounter, DWT_CYCCNT" to count clock cycles, is this more efficient?
    5) To know the absolute time or arrival, is there an easy way to synch or reset the internal Teensy 4.0 clock to an external one pulse per second (PPS) input from a GPS?



  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Hi Jerry - #4 has much of the information.

    on Teensy 4 at start the free running cycle counter is started and can be read quickly with :: uint32_t cyclesStart = ARM_DWT_CYCCNT;

    Searching for that on the forum will find various instances of usage. I have a couple in the Beta T4 thread where the millis() clock counter is used to get micros() the needed resolution with ARM_DWT_CYCCNT. That micros() code is in the Teensy4 source tree so you can look at adapting it.

    With nothing else to do polling is faster than interrupts perhaps - but still limited to some couple of cycles per loop and the time to read the I/O at hand - and then do something about it.

    An _isr() will work well but have some number of cycles overhead - IIRC it might get near 50-100 cycles until you do something about it - I posted sample code on threads for somebody wanting to watch photon (?) emissions some weeks back and compared _isr and Polling.

    The other day on T4 Beta thread I posted delayCycles() and a function call min was 7 cycles to return and picked up to usable value about 15-20 cycles and over that is was hitting +/- 2 cycles on time consumed before return based on how the loop and test synchromized with the desired # of cycles.

    Also posted some longer time ago was an interrupt trigged when the UART Serial Stop bit was changed to record the time of the start of a GPS incoming message. That code may be findable - that was on T_3.6/3.5.

    Like that the GPS PPS signal cam be set to a value and then tracked - I did that on the same project with GPS and 9DOF sensors.

  3. #3
    Senior Member
    Join Date
    Oct 2012
    Portland OR
    There are many different clocks used on the Teensy. Yes it has a 600 MHz instruction clock internally, but for interfacing with the outside world, input signals have to be synchronized to prevent glitches and indeterminate behavior, so the hardware timers that you would use to measure edge timing for a GPIO pin, for example, are clocked at most 1/4 of the main clock, or 150 MHz. As far as I know, 1/150 MHz or 6.667 nsec is the best timing resolution available directly from the T4 (which is still pretty good for a microcontroller!) To get better resolution than that, you need some different approach.

    Are you aware of the TI TDC7200 chip which is designed for exactly the application you have in mind? It claims 55 picosecond resolution. You may also be interested in with a project using that chip, they found it to be around 57+ ps in practice.

    In case you're wondering how the TI chip manages that feat- it uses two clocks internally; a 10 MHz clock (100 nsec period) plus a crazy-fast ~ 17 GHz or 57 ps period ring oscillator, which is always drifting in frequency, but is self-calibrated by counting how many of its cycles went by in one period of the stable 10 MHz clock. How that chip handles the unsynchronized-clock-domains metastable problem, I don't know.
    Last edited by JBeale; 08-22-2019 at 03:15 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts