# Very high speed counter (around 1.5 GHz to 2 GHz)

I am thinking of a device that can measure the distance of an object from a sensor using a radio transmitter and receiver pair.

I'm thinking of using a counter at the sensor side, with a fixed-frequency transmitter and receiver on the sensor.

There will also be a transmitter and receiver on the object whose distance with respect to the sensor I want to measure.

When the transmitter on the sensor transmits a pulse at the previously agreed radio frequency, the counter on the sensor will start counting.

When this pulse is detected by the receiver on the object, the transmitter on the object will transmit a pulse to be received by the receiver on the sensor at which moment the counter will stop and the distance will be measured according to the time lag.

The problem is that I can not find a counter and a clock source compatible with each other in the 1.5 GHz to 2 GHz range. Any suggestions as to what I can use?

The measurement error that is calculated is 33 cm/s at 1.4 GHz and 13 cm/s at 2.2 GHz. So basically, the faster the counter is, the less error.

Can anyone tell me what counter to use together with the clock source for the counter?

I looked at MC100EP016A counter IC but can not find a clock source for this IC.

I require a clock signal with the following characteristics:

• Input high voltage = 2075 to 2420 mV
• Input low voltage = 1355 to 1675 mV
• You want a counter to work at 2GHz but you are thinking of using one that works at 1.4GHz then you want a clock IC? Commented Jul 26, 2014 at 16:08
• You want to measure the time delay between two signals. Are they the same frequency? I'm not sure how a counter helps you. As @Whatroughtbeast answers, you may want to measure the phase difference. Maybe a mixer? Commented Jul 26, 2014 at 16:41
• @Andyaka Seems, he/she want to make a device like radar. also there is many approach in the internet that you can measure the delay between the two radio wave (even by an oscilloscope).
– Roh
Commented Jul 26, 2014 at 16:48
• @Roh did you actually mean to direct your comment to me? Commented Jul 26, 2014 at 16:50
• It's very bad form to repost your question. If you have changes to your original question, please edit edit the original. Commented Jul 26, 2014 at 21:37

Other answers have focused on why you might be approaching this the wrong way. Although I agree with those answers, what you're asking for does exist, so I'll go ahead and give you a straight answer. You'll likely find that this approach is more expensive than alternatives though.

What you want is a 2 GHz voltage-controlled oscillator (VCO) with 3.3-V LVPECL outputs. There are many vendors out there who make such parts.

If you don't find one with LVPECL output, since this is a clock signal, it's relatively easy to adjust the levels to something compatible with LVPECL by ac coupling and rebiasing. Any rf level between -3 and +2 dBm should be usable with a LVPECL input.

LVPECL parts like your 100EP016A can also accept single-ended inputs if you bias the complementary input to the midpoint between the normal logic levels (often there's even a pin called VBB that outputs this level for your convenience, but I didn't check if the 'EP016A has it).

You will then need to build a phase-locked loop to maintain the VCO output frequency accurately by comparing it with a low-drift reference oscillator, which could be anywhere from 10 to 100 MHz.

One part that provides both the VCO and PLL in one chip is Analog Devices' ADF4360-2

A couple more notes:

I noticed that the maximum guaranteed switching frequency of the MC100EP016A is only 1.2 GHz, so if you really want to do this at 2 GHz, you might want to look for another part. Maybe MC100E137, but then you'll need to have a 5 V supply and you'll also need to deal with the unequal timing of the different outputs for a ripple counter.

Finally, you'll need to deal with latching in all the bits of the count at exactly the same instant, so you don't capture some bits before a transition and some bits after. One solution to this is to use a gray-coded counter instead of a binary counter --- then only one bit changes for any transition, and the maximum error from latching delay variation is only a single count.

• can i implement a gray coded counter using this binary counter ??? if yes than how ?? if no then what can i do ??? Commented Jul 27, 2014 at 8:49

A possible alternative is to use one of the newer FPGAs with high speed transceivers (5 to 10Gb/s). These are intended for fast Ethernet, SATA and other high speed serial interfaces. They are relatively cheap, common, faster than the aforementioned ECL device, and internally deserialise (presenting a serial stream of bits as a parallel word).

I understand there may be ways to use them for other purposes such as precise high speed timing measurements. I can't advise on the details but it might be worth some background reading.

Alternatively, this paper does it differently, using multiple phases of a clock running at only 550 MHz. It talks about time resolutions of around 80ps in a now relatively elderly Virtex-5 FPGA.

• I think in many-channel systems, using built-in serdes lanes becomes more expensive compared to a dedicated ripple counter per channel. Number of transceivers is fairly limited on the sub-\$1000 FPGAs. Thoughts? Commented Mar 6, 2016 at 3:33

Just as a starting point, you may want to consider looking at "time-of-flight" range finder circuits using LASER. Considering RF and light travel at the ~same speeds, I would suspect that the time counting sections would be a good comparative match.

A quick google search for "laser range finder circuits" shows a schematic on Parallax.com as the first result. Replacing the laser driver and detector sections with your RF driver and detector circuit could prove to be a valuable resource. This schematic is Distributed under a 'Creative Commons Attribution 3.0 US license'.

Welcome to the forum.

To begin with, I hope you know what you're doing. Messing around at GHz speeds is not for the faint of heart, or those with shallow pockets.

The most obvious way to get a clock is to start with a 1.4 GHz sine wave oscillator, and use the circuit here to convert it to ECLinPS.

Once that is done, you will need to look at other chips in the family to create your gating circuitry.

If you are trying to measure the phase difference between to CW RF signals, you are better advised to look into analog phase detectors followed by an ADC.

• what do you mean by gating circuitry ??? Commented Jul 27, 2014 at 8:50
• So you have an outgoing pulse and a return pulse, and a high-speed clock to count during the interval. How will the clock know when to start counting and when to stop? There are basically two ways to do this, either by enabling/disabling the counter while the clock is running, or by gating the clock so that it is only active during the send/receive interval. In either case you need to perform logic to provide a gate signal, and it must be done with the same high-speed logic as the counter. Commented Jul 27, 2014 at 14:56
• Or i could use a latch and keep the counter counting ??? Commented Jul 28, 2014 at 18:09
• Yup. Of course, this means that you need some way to reset the counter just before you send the outgoing pulse. Either that, or use the outgoing pulse to latch the start count, and the return pulse to latch the stop count, and subtract the two (being careful about rollover). At any rate, you also need to study up on metastability. Commented Jul 28, 2014 at 19:29
• Commented Jul 30, 2014 at 19:26

I think there is a possibility of real latency of signalling through the transmitter and through the receiver detector circuit. These latencies would need to be considered, and unless calibrated out, will limit the shortest distances that can be measured.

Also if the latencies are temperature, voltage and RF signal strength dependent then appropriate calibration becomes more difficult.

• i could measure the transmitter and receiver time delays and then calibrate my device accordingly . Commented Jul 27, 2014 at 8:51

Hmm? If you're hoping to measure go-return delay to s nanosecond accuracy, you need 1 to 2GHz bandwidth. So what would the radio carrier frequency have to be? I would guess at least 20GHz giving 5 to 10% bandwidth that your antennas need. I would not attempt that unless you have a lab full of equipment. You will also need to adhere to FCC rules.

Suggestion: See if you can buy an automotive "driver assistance radar" as a spare part