Measuring time between pulse edges (in 20 nanoseconds resolution or less)

Hello Arope99

20 ns resolution or less is something TM4C129x would not be able to do. Even though the timer resolution is 8.33ns, doing a capture of a fast signal would typically mean that even if a single pulse is captured, a continuous set of pulses will overwhelm the device. You must look for a FPGA based solution.

Regards
Amit

Hi Amit,

Thanks for the reply.

Do you have any idea what would be the fastest continuous set of pulses that the TM4C can handle without overwhelming the device? I mean what would be the shortest time between pulses?

Regards,
Arope

Hello Arope,

Typically I would consider that the pulse train duration be enough for the CPU to go to the interrupt handler, read the timer register for time stamp, exit from the loop and perform the task/computation that needs to be done. Typically this would be in the order of 40-50 clock cycles, but an accurate testing can only be done based on the actual code.

Regards
Amit

I faintly remember there are microcontrollers with sub-nanosecond timer resolution, which use PLLs or other "tricks" to pace counters beyond the core clock. One name (i.e. talk with sales representatives) I remember,  - and this is not a recommendation - is Microchip.

However, the hardware design for that frequency range is not trivial, even for a digital signal. To retain a rectangular shape at the MCU/counter input, the signal path should have a bandwidth about two orders of magnitude higher than the signal (optimally). That would put you in the GHz range, where strip wires and waveguides rule.

I would find a FPGA based solution, like Amit suggested, rather appealing ...

Hello f.m.

C2000 class device have the sub-nanosecond tricks. But information is very sketchy for me.

Regards
Amit

Hi Amit,

Coming back again to the TM4C with 120MHz (timer resolution 8.3333ns). The pulse width that I'll be working with is ~50ns and there will be at least 1000ns between pulses. I need to measure the time between 2 continuous pulses (will be > 1000ns).

Do you think the TM4C would be able to do this? 

Assuming that it need 50 clock cycles (416ns) for the CPU to go to interrupt handler, read the timer register for time stamp, exit the loop etc, the TM4C would still have enough time to capture the next pulse and not be overwhelmed. Is this theoretically correct? 

Thanks in advance.

arope99 said:

If no, which Launchpad (or any other COTS board) that would be suitable for my use?

There are some time-of-flight measurement devices which are designed with a sub-nanosecond resolution and and be connected by SPI to a MCU. e.g. see TDC7200EVM.

Not sure if such a device will meet all your timing requirements, but provides a way to off-load the timing measurement from the MCU.

Assuming that it need 50 clock cycles (416ns) for the CPU to go to interrupt handler, ...

Where did you get this from ?

This is an incorrect assumption, the Cortex M4 needs 12 clock cycles to get into the interrupt handler (if you don't use the FPU in both main and interrupt code, which you most probably don't).

Still, 1000ns means about / up to 1MHz interrupt frequency, which is, in my discretion, too much. The core can retrieve pulse length data, but there is barely time to process it in a useful way. The usual recommendation is to use DMA to collect data at such high rates. Never done this for TM4C timers, so I don't know if this would be possible. For sub-microsecond times, those internal timers would have a resolution problem anyway.

Hello f.m.

The number of 50 clocks came from me, with the condition of why it was 50 clocks also mentioned

Regards
Amit

I think we are speaking of different things.

I meant/understood cycles --into-- the interrupt (latency), and you meant, I guess, available core cycles --in-- the interrupt handler. That figure might be about correct, and indicate unfortunate suppositions for this kind of solution ...

Hi f.m,

The MCU won't really need to do much processing. I just need to get the time stamps of each pulse (or time separation between 2 pulses) and send it off to another machines via Ethernet. The other machines will do all the processing.

Will it worth trying with the Tiva C Series Connected Launchpad?

Thanks.

I just need to get the time stamps of each pulse (or time separation between 2 pulses) and send it off to another machines via Ethernet. The other machines will do all the processing.

I might be wrong, but that sounds a bit naive. Have you investigated what that "sending via Ethernet" involves ? Hardly in just 50 cycles.

Perhaps you can explain your use case (project) in more detail, but sustaining concurrent and interdependent data streams in the Mbps range seems to max out most Cortex M4 devices (not only TM4C) ...

f. m. said:

Perhaps you can explain your use case (project) in more detail

Ya think?   "More" detail is too kind - "some" detail better specifies.   Are we not 13 posts into this thread - and (only) now - key/critical data arrives?   (which - as you sense - may invalidate much/most of "helpers" earlier work...)

Highly demanding applications must be very well bounded & detailed - that's yet to occur - and the piecemeal introduction of needed/necessary facts provides (slight) comfort...