Measuring time between pulses to 1ns resolution - Page 1
Forum section: electronics / projects

author: gxti
author_rank: Frequent Contributor
timestamp: June 10, 2012, 11:58:52 pm
content: Some of Microchip's PIC24F line has a peripheral called a "charge time measurement unit" that can be used to measure time between two external, asynchronous pulses down to the sub-nanosecond level. Does anyone know of any good standalone designs of this type? (appnotes, articles, whatever) It charges up a capacitor using a precision current source, switching on with the leading pulse and off with the lagging pulse. The voltage on the capacitor is then proportional to the time between events. The module is totally asynchronous so it's not limited by the period of any clock.Some more details: I'm designing a GPS-disciplined oscillator, which combines the strengths of a "local" ovenized crystal oscillator, with a pulse-per-second from a GPS receiver which is stable over long periods of time. The GPS pulses are compared to the divided-down crystal clock and the crystal is pulled faster or slower until the pulses are in sync. The result is then a very precise, very stable 10MHz (or whatever) reference clock. I'm planning on using a LPC1313 or similar as the processor as it fits all of my needs other than the fine pulse measurement. In particular, it has 32-bit timers that will be perfect for a "coarse" measurement with enough range to work when the pulses are too far apart to be precisely measured by the charge time method. For example, 1ns resolution and a 10-bit ADC yields a max "fine" range of 1.023uS, while the 32-bit timer running at 72MHz can run for well beyond the needed 1 second range. The fine measurement is only needed when the pulses are very close together (nearly locked) so this works out perfectly. But of course the LPC1313 doesn't have a built-in charge time measurement unit, and in any case I think I need two in order to cover both the leading and lagging case. So I'm looking for standalone solutions, and rather than flailing around I figured I'd ask if anyone has seen a similar project.

author: Rufus
author_rank: Super Contributor
timestamp: June 11, 2012, 12:51:46 am
content: Quote from: gxti on June 10, 2012, 11:58:52 pmThe 1 pps signal from a typical GPS isn't stable enough short term to warrant anything like 1ns resolution edge timing.There is a 1 pps synchronized design herehttp://ve2zaz.net/GPS_Std/GPS_Std.htm. The first thing it does is divide the 1 pps signal by 16.

author: krenzo
author_rank: Regular Contributor
timestamp: June 11, 2012, 01:25:50 am
content: This will tell you everything you wanted to know about Time To Digital converters:http://www.ko4bb.com/~bruce/TDC.htmlThese designs are obsolete though. Everyone does it digitally now, and I was able to implement a Time To Digital converter with 200 ps resolution in a Spartan 3 FPGA with no external parts.This company designs standalone TDC chips you can buy:http://www.acam-usa.com/

author: hlavac
author_rank: Frequent Contributor
timestamp: June 11, 2012, 01:32:53 am
content: Quote from: Rufus on June 11, 2012, 12:51:46 amAnd that is helping them how? It's not like dividing by any amount will remove the jitter form the edges is it?You'd have to have some sort of local low jitter PLL locked onto it that tracks slowly enough for the jitter to average out...

author: gxti
author_rank: Frequent Contributor
timestamp: June 11, 2012, 02:40:12 am
content: Quote from: Rufus on June 11, 2012, 12:51:46 amThe receiver I have is designed for timing purposes and is good to +/- 15ns even before correcting for quantization error. It then sends in each packet an estimate of what the quantization error is (whether it's for the next pulse or the previous, I still have to determine). So 1ns is entirely reasonable.There will be a software PI loop smoothing the oscillator control, so the uncorrectable jitter from pulse to pulse will be smoothed out. But it's still possible to correct for the systematic error caused by the receiver quantizing its pulse output, and to do that I need to measure the actual timing precisely.QuoteWhat does the implementation look like? I actually played with using 225MHz counters running at offset phases, but I'm not entirely sure it makes sense. I haven't tested it outside of simulation either. Either way I'd love to avoid the cost of a FPGA -- not just the part but also the board area it takes up, power supply or supplies, power sequencing, etc... The good news is that I could potentially move the MCU onto the FPGA.

author: krenzo
author_rank: Regular Contributor
timestamp: June 11, 2012, 04:38:59 am
content: Quote from: gxti on June 11, 2012, 02:40:12 amIt's a tapped delay line consisting of many carry chain elements in the FPGA. All flip flops are connected to the same carry line and use the same clock. The distance between each flip flop is around 30-100 ps which defines the resolution. See:http://www-ppd.fnal.gov/EEDOffice-W/Projects/ckm/comadc/WaveletTDC_abs08.pdfhttp://www-ppd.fnal.gov/EEDOffice-w/Projects/ckm/comadc/PID765918.pdfThat method took me awhile to reproduce. Here's another way that uses the built-in clock manager's delay. It's much slower but less complicated:http://conferenze.dei.polimi.it/FPL2010/presentations/W3_C_1.pdf