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

J

Jerry

Member
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?


Thanks,

-Jerry
 
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.
 
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 https://www.febo.com/pages/TICC/ 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:
Hey Jerry,

I just started a project that is going to require me to do the same thing (measure time of flight using clock cycles). I see that this thread is pretty old but I would sure love to chat with you and find out what you learned when you went down this same road.
 
Sorry 89Echo, as I have not done much with this since then.

I like the idea of a dedicated external IC or ICs, so that the Teensy is not turned into a dumb looping device with short code and no other functionality, even if counting clock cycles works.

There is an online email list group of engineers and scientists called TimeNuts who have PIC code that has ns or ps capabilities, specifically for timing and counting of cesium and Hydrogen Maser clocks. Utilizing something like that might offer even higher resolution, continuous sampling, and stability at a cheap price when combined with the Teensy for processing functions. Best of luck and if you find something that works, please post back and share with the community. Thanks
 
Thanks Jerry. I was thinking something similar. Essentially a dedicated triggering circuit that would trigger an interrupt on the Teensy and just use the Teensy to record the timestamp. My concern is that the more links you add to the chain, the more opportunity for error stack up there is.

I'll check out TimeNuts. Sounds like they may have answered a lot of this already
 
You must log in or register to reply here.
Back
Top