5
\$\begingroup\$

I want to make a counter that can count the time between pulses in nanoseconds. The counter starts to count when a pulse enters a pin (at the start of the pulse) then stops when a second pulse comes. Then the timer sends a signal to either a display or LED and starts the counting again.

Diagram showing example image of pulses


The time between each pulse is anything from 100 ns to 1 s and the pulse width is 100 ns to 1 µs. The counter needs to be as cheap as possible and does not need to give me a 100 % accurate time. For example, if the time is 100 ns and the counter says its 200 ns it is acceptable (basically ±100 ns).

  • Resolution: There is no need for it to read in 0.1 ns but rather 10 ns steps.
  • Display: Either a simple LCD, CRT or anything really.
  • Noise: The pulse will be from 0.5 V to something higher.
\$\endgroup\$
17
  • 2
    \$\begingroup\$ What is the time between pulses? If it is log enough vernier techniques can be used to avoid the necessity for clocking at very high frequencies. \$\endgroup\$ – Kevin White Feb 20 at 18:56
  • 8
    \$\begingroup\$ Counters like this cost over $500 to buy with 1GHz stable clocks and PECL counter chips cascaded with 74ALC variable decade clock dividers for X digits of resolution over 7 decades of time interval . Define your resolution (digits) , sensitivity and accuracy specs first then decide/define what you can buy. \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Feb 20 at 19:32
  • 5
    \$\begingroup\$ SInce this is a 1-shot measurement, do you really need 10 ns resolution for a 1 second interval? Your specs are insufficient for any suggestions to be valid. Can you anticipate the duration ahead of time to vary the clock resolution? Otherwise you need a 8 digit display \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Feb 20 at 20:11
  • 12
    \$\begingroup\$ Aha, you've relaxed the requirements by two orders of magnitude... That of course basically invalidates all answers you've already gotten. \$\endgroup\$ – Marcus Müller Feb 21 at 11:34
  • 2
    \$\begingroup\$ There's still a contradiction in your requirements. First you say ±100 ns is acceptable, but then you mention "10 ns steps" under Resolution. That's again a huge difference. \$\endgroup\$ – TooTea Feb 21 at 22:07
25
\$\begingroup\$

You've changed the requirements by a lot! Measuring something in nanoseconds is hard. Measuring something with a +-100 ns accuracy really isn't. A 10 MHz counter works perfectly fine for that, do 20 MHz if you want to be sure.

Any modern 32 bit microcontroller (read: 2€ investment...) has timer/capture units that can do that for you.

You've went from a problem that requires own hardware design to something that even the cheapest STM32 eval board can do out of the box: That's an excellent illustration of the importance of requirements engineering.

\$\endgroup\$
13
\$\begingroup\$

Luxury option:

Time to digital converter chip, available from several manufacturers. Accuracy: picoseconds.

AS6500 TDC7200

Easy option:

Microcontroller timer in capture mode to measure pulse width, or time between two pulses. Pretty much any microcontroller will do the job, but accuracy will be at best one clock cycle, so you must choose a microcontroller with suitable clock frequency. And you must also check the timer clock frequency, which is not always the same as the CPU clock frequency. If you want 10ns accuracy that's 100MHz, so there are a lot of options, STM32, LPC, etc. If you want a LCD, just get a module with one on it.

ESP32 is an example of why you should check carefully: the CPU runs at 240 MHz but the timers run at 80MHz.

Next, check the microcontroller datasheet and check if the timer can measure the delay between two pulse edges. If it cannot, then you can use two timers running on the same internal counter to capture the start pulse and the stop pulse counter values, and just substract.

Since you're interested in edges, make sure it can be triggered on the leading edge.

the pulse will be from 0.5V to something higher.

0.5V is too low for a CMOS logic input so you will need a fast comparator to set a suitable threshold, search the category on mouser, digikey etc. It's important to select a comparator with a response time that is low enough. If your minimum pulse width is 100ns, then a <50ns comparator should be adequate. You can also use a highspeed opamp to amplify the signal, but in any case, a CMOS 3V3 logic input will not work directly with a 0.5V signal.

\$\endgroup\$
6
  • 2
    \$\begingroup\$ use an analog integrator to measure the time between counter clock pulses. The measured pulse stops the integrator and counter. Measure the voltage on the integrator with an adc and along with the count value gives you a high resolution timing measurement. Eg: a 10 bit adc and 10MHz counter will achieve ~1ns resolution. 50MHz count would give 200ps resolution and so on. \$\endgroup\$ – Kartman Feb 20 at 23:49
  • \$\begingroup\$ @jms nice find! So the high resolution also applies to capture mode? \$\endgroup\$ – bobflux Feb 21 at 8:43
  • \$\begingroup\$ Sorry, I remembered wrong - The input capture is limited to the input frequency of the high resolution timer, which maxes out at 144MHz (on the STM32F334) \$\endgroup\$ – jms Feb 21 at 13:30
  • \$\begingroup\$ Still good enough for 7ns accuracy, excellent deal at 4€/piece qty one and probably available on cheap ST dev board too, that would be an excellent choice for OP! \$\endgroup\$ – bobflux Feb 21 at 14:31
  • \$\begingroup\$ @jms actually, one could use the HRTIMER to generate a multiphase clock, say 6 outputs with each having its edge delayed by 1/6 period, or 1.15 ns. Using these as data inputs for a bunch of fast flops like 74LVC, with the pulse to be detected as clock input, then looking at the flop outputs, one can tell the pulse edge timing relative to each and divide the period in slices for up to 1ns accuracy, not bad for a 4€ micro and a bunch of 20c flops... \$\endgroup\$ – bobflux Feb 21 at 14:34
9
\$\begingroup\$

Your cheapest solution is going to be determined by the cost of your time , components and circuit board with debug time.

In this case your best solution is a used 100 MHz counter off EBAY for $150

https://www.ebay.ca/itm/AGILENT-HP-5316B-HIGH-PERFORMANCE-FREQUENCY-COUNTER-100-MHz-LOOK-REF-330G/193032320482?hash=item2cf19f75e2:g:O8UAAOSws3ldSDHf

\$\endgroup\$
8
\$\begingroup\$

(basically +/- 100ns).

Well then, a cheap 8-bit microncontroller like ATTINY2313 can be clocked at 20Mhz, then you can just use its timers in input capture mode and that will get you +/- 25ns precision at each end of the pulse for over-all +/- 50ns precision (modulo clock jitter and innacuracy so use a good crystal for the clock) 75ns accuracy should be possible.

\$\endgroup\$
3
  • \$\begingroup\$ if you use a "better" microcontroller that comes with a 32 bit timer/counter, then you don't have to do any interrupt trickery to count up to 4 billion intervals, making the whole system easier. \$\endgroup\$ – Marcus Müller Feb 21 at 13:42
  • 1
    \$\begingroup\$ yeah. mainly I was trying to contrast against the other answers. \$\endgroup\$ – Jasen Feb 21 at 19:30
  • \$\begingroup\$ Agreed, and much appreciated. \$\endgroup\$ – Marcus Müller Feb 21 at 23:12
7
\$\begingroup\$

I think the most realistic approach here is probably still a bit tricky:

First of all, you'll have to realize that your signal has a pretty high bandwidth, assuming that the rise time of your pulses needs to be pretty steep to even get the required timing accuracy (e.g. if your rise time is 40 ns, then in 1 ns of an edge not that much voltage difference happens, and the tiniest bit of noise and component temperature variation can skew your measurement beyond your target accuracy).

That means your board design needs to be wideband-aware, which basically means you need to design this as a high-speed logic or RF board, with appropriate buffers/amplifiers, matched traces, matched in- and outputs and so on.

Assuming you get the analog side sorted out, most logic is still too slow to count that fast, and most discrete logic is also too small to count up to a billion nanoseconds!

So, what I think this will boil down to is "abusing" fast inputs on an FPGA to reduce the rate at which you can work.

Two approaches:

  1. Use an FPGA with a high-speed SERDES. The ECP5 series by lattice might work. Get one with a 2.5 Gb/s or higher SERDES, and use it to sample your signal at a Gigabit per second, convert it to to 10bit units, so that your counting can happen at a much easier 100 MHz, and do the counting in-FPGA. For the 10 bit symbol where the signal changes, you just need to find the first changed bit in these 10 to figure out things with nanosecond precision.
  2. Use an FPGA with wide parallel buses (say, N bit wide) where you can program artificially added skew between different inputs in N steps up to N-1 nanoseconds. Feed (matched length!) the same signal to all N inputs, and sample every N nanoseconds.

I think the first alternative is easier. In both cases, you'd buy an FPGA evaluation board to get across the initial hardware design hurdle.

\$\endgroup\$
4
  • \$\begingroup\$ To extent your list of FPGA solutions: 1 ns precision can easily be reached with a clocked sampling of the signal, using 2 or 4 clocks shifted using a PLL. A cheap 5€ MachXO3 FPGA or a 25€ evaluation board will do. \$\endgroup\$ – asdfex Feb 21 at 11:17
  • \$\begingroup\$ @asdfex that's an interleaved ADC you're building there :D Never worked with the Mach serieses, do they have sufficiently many PLLs that you can also relate in phase built-in or is that something you'd need to construct externally? \$\endgroup\$ – Marcus Müller Feb 21 at 11:32
  • \$\begingroup\$ @asdfex I just read the edit that OP went through... we're now from "count nanoseconds" to "+- 100 ns accuracy". Of course, implementing a 10 or even 20 MHz counter can be done with about anything, including bog-normal microcontrollers. \$\endgroup\$ – Marcus Müller Feb 21 at 11:39
  • 1
    \$\begingroup\$ MachXO3 has 1 or 2 PLL per device, but each PLL has 4 outputs that can be shifted with respect to each other. Like ECP5. 100 ns, 10ns or even 5ns are another story.... \$\endgroup\$ – asdfex Feb 21 at 11:40
4
\$\begingroup\$

Counting pulses with 1ns precision is a tall order. That rate rules out all the commonly used logic families like 74XX, CD4XXX, etc. Even the "high speed" varieties are nowhere near fast enough.

That leaves you with ECL (Emitter Coupled Logic) as the next step up. These are fairly expensive and use a lot of power but when that's what you need, you use them.

For example there is the ON Semiconductor MC100EP016AFAG which is an ECL 8-bit up/down counter. It's datasheet is here:

ON Semiconductor ECL 8-bit Counter

You can see from the timing that is can be clocked at 1.3GHz at 70C:

MC100EP016AFAG Timing

Of course you don't just drop one of these into a breadboard and expect it to work at this speed. You will need to follow RF design rules very carefully.

Good luck as this will certainly be a challenging project but I am sure you'll learn a lot in the process.

\$\endgroup\$
6
  • \$\begingroup\$ 8 bits of resolution only gives you 2.5 digits of resolution. \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Feb 20 at 19:30
  • \$\begingroup\$ Are you sure? The last time I checked 8 bits of resolution gives 8 bits of resolution. \$\endgroup\$ – jwh20 Feb 20 at 20:56
  • \$\begingroup\$ It takes 10 bits to get a 3 digit counter in decades. \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Feb 20 at 21:04
  • 2
    \$\begingroup\$ follow the expwensive fast counter with a cheaper slow counter on the carry output. \$\endgroup\$ – Jasen Feb 20 at 23:44
  • \$\begingroup\$ It turns out that 0.1 microsecond precision is all that's needed, but this is still a good treatment if more precision is needed. \$\endgroup\$ – Jasen Feb 20 at 23:54
4
\$\begingroup\$

Since you imply that 10 ns resolution is acceptable, a 50 OR 100 MHz timer can be built with either 10K or 100K ECL, or Schottky TTL (74Sxx or 74ASxx).

You will need an accurate 50-100 MHz oscillator to clock the counters, and this is not a simple thing to design.

Note that at your frequencies, the display will be updating far more rapidly that the eye can perceive.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.