Accurate pulse width measurement

[AccountRemovedPerUsersRequest]

I have been searching for a chip to measure pulse width accurately. Maybe something that can be triggered and the width can be read via SPI or something. Looks like there is not such a chip available. I can do this using MCU, but more accurate (and dedicated) chip is preferred.
As an alternative option I am also thinking of building something using discrete components or FPGA (CPLD more likely, but anyway).
Any ideas? Out-of-the-box ideas especially appreciated :-)

A

(100MHz sampling level is close to the target level of accuracy)

[jmelson]

Implementing a 100 MHz counter in an FPGA would be fairly simple.  Start counter on rising edge, stop counter on falling edge, transfer count to holding register and then zero counter.  You could likely go well over 100 MHz for finer resolution.

Jon

[2N3055]

And most important thing was not said: what time interval (shortest and longest, in sec) and what accuracy and resolution you need that (in seconds)....

There are, for instance, direct time to digital chips that do just that, but they have range they work in.

Term for device that measures just that is TIC (time interval counter), and there are several designs floating around the Internet.

[Cerebus]

What kind of pulse width, and to what accuracy?

Without those two bits of information people can't tell whether you need to use a small boy with a pencil and a wristwatch (minutes long pulses to seconds accuracy), or something like SiGe triggered phase locked oscillators as part of a vernier measurement scheme (sub to several nanosecond pulses to picosecond accuracy).

[AccountRemovedPerUsersRequest]

Hello. And thanks! I just opened the datasheet of the first candidate (TDC7200) and this is EXACTLY what I was looking for.
And yes, this is fairly simple to do using FPGA. Actually, I have done that, but in this case, a stock chip for $1-2... check please.

For the record: the time of flight is about 500uS

A

[xani]

Depending on CPU you're using a builtin timer *might* be just enough, most of micros have timers functional enough to do what you want purely in hardware (hardware start/stop so no extra jitter)

[David Hess]

PIC has an analog CTMU (charge/time measurement unit) which can be used for pulse width measurement.

[viperidae]

I don't see why this can't be done accurately with a capture/compare capable timer on a micro.
A 16mhz clock would give you a 0.0625us resolution with a 16bit timer capable of measuring up to 4ms, I assume that's plenty for a 500us signal.

[AccountRemovedPerUsersRequest]

Please check the first message. Resolution of 100MHz  is needed. Otherwise I would already done this using just CPU. The fastest CPU I can use is not even close to that.

[viperidae]

An stm32f407 should be able to do 168mhz 32bit capture

[Cerebus]

Please check the first message. Resolution of 100MHz  is needed. Otherwise I would already done this using just CPU. The fastest CPU I can use is not even close to that.

I think you mean that you need a resolution of 10ns in the time domain, not quite the same thing. A resolution of 100 MHz is in the frequency domain, suggesting that you need to be able to resolve  frequency to within 100 MHz (i.e. be able to just tell the difference between 100 MHz and 200 MHz,). It might seem pedantic (you can blame a morning spent looking at Z transforms), but there is a world of difference.

The STM32F4 series will run their timers with at least 10ns resolution (with the one exception of the STM32F401) and have input capture modes that are designed to do exactly this kind of timing of an external signal. I can personally attest to that because the breadboard I have in front of me is using an STM32F411 to do exactly that. The range starts at around the £2 level in quantity, £3 one off pricing. An official, fully populated, ST Nucleo64 development board for the STMF410  is under £12.

Now, whether one can find anybody with stock of any STM32 microcontrollers at the moment is another question, but that's down to the current Chipagedon situation.

[bson]

For very short pulses you can discharge a capacitor during the pulse and measure the voltage before and after, then with a little calibration data convert the voltage drop to a pulse width.  This though will put limits on the period and width of the pulse.  But it's easy to implement with any garden variety low-power microcontroller and a decent ADC.

[David Hess]

For very short pulses you can discharge a capacitor during the pulse and measure the voltage before and after, then with a little calibration data convert the voltage drop to a pulse width.  This though will put limits on the period and width of the pulse.  But it's easy to implement with any garden variety low-power microcontroller and a decent ADC.

The lower limit on pulse width is removed by using separate switches to turn on the capacitor charging (or discharging, same thing) and turning it off, so each transistor only switches once instead of one transistor switching twice.

[Cerebus]

For very short pulses you can discharge a capacitor during the pulse and measure the voltage before and after, then with a little calibration data convert the voltage drop to a pulse width.  This though will put limits on the period and width of the pulse.  But it's easy to implement with any garden variety low-power microcontroller and a decent ADC.

The tried and tested method of doing that sort of analogue time interpolation is to use a dual slope integrator, a comparator and a counter. Charge the capacitor to an arbitrary clamping voltage, discharge it through a constant current source connected via a current switch, recharge it with a much lower constant current source (always left on, hence the clamp), and count the number of clocks that it takes to recharge. The time is the number of clocks taken to recharge divided by the ratio of the two current sources (1000:1 is easily achieved in practice, 3000:1 is achievable with care). It's easy to calibrate the thing on the fly by feeding it two known width pulses. A 100ns counter clock (10 MHz) with a 1000:1 cc source ratio will give you 100 ps resolution.

That kind of setup is typically used with a convention counter running at a moderate clock rate and used to time the difference between the leading and trailing edges of the pulse you're measuring and the clock edges of the conventional counter. Measurement repetition rate is limited by running the auto-zero calibration pulses through the interpolator and minimum measurable pulse duration by whether you're reusing the same interpolator for stop and start timing. Put together an interpolator running at 10 MHz, a conventional 32bit counter (which could be an MPU timer) running at 10 MHz and you get the ability to measure pulses between about a millisecond and ~430 seconds with 100 ps resolution. Use two interpolators (one each for start and stop timing) and the minimum measurable time falls to the close order of a nanosecond with a repetition rate of something like 3 us.

Using the classic dual slope method takes out temperature dependence of the capacitor automatically. A pair of calibration pulses will take out any drift in the current source ratios. All you have left is comparator threshold uncertainty and that's minimised by crossing the threshold in only one direction. There's some non-linearity for very short pulses, but that's easily eliminated by switching on at the leading edge of the pulse to be measured and using a simple synchronous one-shot to stretch the trailing edge of that pulse by a fixed known time (i.e. to the next counter clock edge +1) giving you a minimum pulse width applied to the interpolator of (original pulse distance from clock edge + one clock). That trick obviously only works if you have the full synchronous counter and stop/start interpolation thing going on as above because you're mullering the trailing edge of the pulse. You'd do the same thing at the trailing edge but detecting a rising edge rather than a falling edge and stretching it out to the next counter clock edge + 1.