# Reconstructing Clock for Serial Signal

Suppose that I have a serial signal (example below), which is transmitted without an accompanying clock signal, I would like find a circuit (using discrete components / ICs, possibly an FPGA, but not a microcontroller) to reconstruct the clock for this signal.

The main challenge is that the frequency of this serial signal varies over time. The signal is received from a wireless ASIC. When the ASIC transmitter is on, the receiver produces a signal, like what is shown below.

Additionally, the ASIC may intermittently (and asynchronously) cut out after a few seconds, and a different transmitter will come online. Any given transmitter's nominal frequency can be anywhere from 35 to 65 KHz due to design issues.

Depending on how much power the transmitter has, I have seen a single ASICs clock drift by as much as 2 KHz from a nominal 50 khz during continuous operation. I have never measured a noticeable frequency shift within less than 20 frames of data, but I don't have an actual figure for rate of change in the clock frequency....

There is one start bit per frame, and a parity bit and stop bit at the end. There can be as many as 13 consecutive zeros in the frame. There are always 4 zero cycles between frames coming from a single ASICs transmitter. Consecutive frames come from a single transmitter, but as I mentioned, the transmitter can periodically cut out, and another one can come online at a different clock frequency.

What I am looking for is a circuit to recover the clock, using a combination of digital logic, and discrete analog components (not a microcontroller!) which is very robust, that can adapt to a drifting clock, and can lock on to frequencies in that wide range. Also I would like to find a design which scales well to higher frequencies, because future ASICs will have a transmitter clock which is much faster (I have heard as much as 20 times faster).

An FPGA will be utilized to decode the data stream (and use the recovered clock, in fact this has already been implemented before assuming the availability of the clock), and as such can be used as part of the clock recovery circuit if that helps.

Very sorry for the confusion, I hope everything has been clarified.

• Sounds like the real issue is the flaky power the ASIC is subjected to. Actually, it's surprising that the only result would be different speed. If some oscillator is changing that much, then lot's of other stuff should be going wrong too. In any case, show plot of your signal over time. Without that it's too hard to tell what you really have. Apr 22, 2014 at 19:51
• I don't have any control over the output from the ASIC, that is a job for someone else. I will however, work on getting a data sample to post. Apr 22, 2014 at 19:57
• I've written down some ideas but I have a question for you, apart from what Olin said: do you really need to recover the clock to decode RZ signal? Apr 22, 2014 at 19:59
• I've been using a microcontroller's timer peripheral to decode the signal using a state machine in software, however there is a new version of the ASIC being fabbed which will have a faster signal that needs to be processed using custom digital logic, so I would like to get an idea of how to recover the clock using a circuit rather than an algorithm. Apr 22, 2014 at 20:02
• I will add all of the additional clarification requested once I clarify with the people I'm working with. I apologize for the confusion in this question, I'm fairly new to this field (undergrad EE). Apr 23, 2014 at 20:14

Recovering a clock from an intermittent stream of pulses is a non-trivial design exercise. I generally try to center the edge of the clock on the pulses, then the clock edge can be used to capture the presence/absence of the pulse in a flip-flop. A hybrid digital/analog circuit demonstrates the concept more clearly:

simulate this circuit – Schematic created using CircuitLab

The general idea is to use a pair of gates to generate a "pump up" pulse and a "pump down" pulse for every input pulse. As long as these two pulses are the same length (the clock edge occurred exactly in the middle of the input pulse), there will be no net change of the VCO frequency. But if the pulse comes a little early with respect to the clock (which means the clock is slow), the "pump up" pulse will be wider than the "pump down" pulse, increasing the VCO control voltage. The opposite occurs if the input pulse is late, decreasing the control voltage. The VCO should be configured so that the range of frequencies that it can produce over the range of the control voltage matches the the expected range of data rates.

Since you're working with an FPGA, a very similar thing can be done purely in the digital domain. We'll assume you have a high-speed clock (e.g., 10 - 50 MHz) available. We replace the charge pump with a binary up/down counter, replace the VCO with a DDS, and instead of relying on analog pulse widths, we sample the phase of the DDS at the rising and falling edges of the input pulses.

In the following diagram, all of the "dangling" clock inputs are connected to the FPGA's high-speed internal clock. Any pins with [] at the ends of their names represent multi-wire buses.

simulate this circuit

The asynchronous RZ input is passed through a 2-stage synchronizer and then an edge detector. Registers U3 and U4 capture the upper phase bits of the DDS (U2) on the rising and falling edges of the RZ pulse, respectively. If we treat the phase value as a signed binary number, the rising edge will capture a negative value, while the falling edge will capture a positive number. We add these two numbers together, and if we're perfectly in sync, they'll cancel and the result will be zero. However if the clock is late, the negative number will be greater and the sum will be negative. We therefore just take the sign bit at the output of the adder (U5), and use gates to either increment or decrement the value in our counter (U1) to speed up or slow down the clock. Note that you'll want to configure this counter so that it only covers the frequency range of interest. In other words, it'll have both a minimum value and a maximum value that it won't count beyond.

The "carry out" from the DDS is a one-clock-wide (system clock) pulse that occurs at the rate of the RZ data, aligned to the centers of the bits.

• Thank you very much. This is the level of explanation I was hoping to find, because it seemed to be as you said "a non-trivial" design issue. I appreciate that you demonstrate two different methods as well. Apr 23, 2014 at 21:29
• You're welcome. I have a lot of experience generating precision clocks and timebases in FPGAs from various kinds of references. Apr 23, 2014 at 22:04

If the clock can vary, and you need to recover it, you should definitely build a clock recovery circuit.

With the RZ signal that can be quite easy since as you say the clock is present in the signal all the time. If you are receiving all ones you actually are receiving the clock signal... But when a zero is received you are receiving the negated clock. First of all I suggest an edge detector, that is a cirtuit that outputs a pulse each time the input signal changes polarity. A trivial example is an high pass filter, that is a series capacitor with a resistor to ground. Your pulses still are of mixed polarity, but you can just use a full wave rectifier so that you get a positive pulse each time your signal makes a transition. Now that's nearly a clock, you just need to divide it by two with a couple of flip flops and you are done.

To detect all the edges you can also use a XOR gate: one input to the RZ signal, the other to the same signal delayed "a bit". When and only when the inputs are different, that happens when you are having a transition, the output will be high. You still need to divide by two.

I know I haven't proposed a practical solution but I hope my inputs can help you.

• It sounds like this answer was written before the picture was added to the question. It needs to be revised to match the OP's situation. Apr 23, 2014 at 13:08
• @DaveTweed I know, it seems to me that the OP still has not clarified what he is asking, especially about clock variability. I'll revise my answer (or delete it) when the question will be final. Apr 23, 2014 at 13:11

Given the frequencies you're looking at, I would suggest trying to solve the problem in the digital domain. If there's some "nice" way to identify two pulses that are supposed to be some number of time slots apart (e.g. the inter-frame gap is supposed to be longer than any gap within a frame, and the time from the start of one frame to the start of the next is always supposed to be exactly twenty time slots) then if you sample your incoming data with a clock that's at least twice as fast as the data rate, you should be able to figure out where the frame boundaries are. From that, you should be able to figure out the location of individual time slots within a frame.

A major advantage of moving this sort of thing to the digital domain is that data can be analyzed retrospectively. For example, if each frame is twenty time slots, the first and sixteenth always have pulses, and there's no gap of four or more time slots without a pulse, then you could use hardware to record every 15us whether there was a pulse or not, watch for a time without pulses that's long enough to be an inter-frame gap, and keep track of the last such time that's been observed. When an inter-frame gap (other than the first) is observed, latch the number of clocks between it and the previous one, and then grab data from suitably-spaced spots in the buffer.

It might be possible to use a microcontroller to do much of the analysis; 50khz is a little fast, but perhaps workable if the controller has some hardware assistance for capturing the data or doesn't have to do anything else. A microcontroller's odds of success could be especially good if e.g. there are always nine pulses per frame (if hardware stores a byte per pulse with its approximate length, then if the current gap and the one nine previous are longer than any of the intervening ones, then the intervening eight probably form a data frame, and the clock rate should be 1/20 of their sum). Selection of the best approach would require a bit more knowledge of what the incoming data stream represents, what parts of it are fixed or variable, how clean or jittery it's apt to be, etc.

Try this. Assuming the data has amplitude +/- Vl. Use two comparators, one set to trigger at Vl / 2, the other at -Vl / 2. Invert the second, and then OR the two signals. You can do it with half a quad comparator, and half a quad NOR gate. (This assumes that the period of the data is a good deal greater than the propagation time of the logic, and that the signal to noise ratio of the data is reasonably high.)

• Thanks for your help, please see the edit. A zero bit is just represented as 0 volts, not a negative voltage which returns to zero. Apr 22, 2014 at 22:13
• OK. As Vladimir pointed out, that's not RZ. For what you're doing, given the wide frequency excursions, I would not recommend a PLL. Rather, use the capabilities of the FPGA to synthesise a new clock. Something like this: Using a high frequency clock, measure the period between rising edges. Since you know the approximate boundaries of the data frequency, put upper and lower limits on what can be acquired. Use the measured period to set the period of a counter chain which produces the new clock. Whenever you get a valid data cell, you'll update the clock frequency. Apr 23, 2014 at 0:38
• Okay that sounds like a good approach. Any idea how much variance in the clock frequency could be tolerated by a PLL approach? Apr 23, 2014 at 1:05
• The problem with doing it via a PLL is the VCO. You can actually get a very wide frequency swing (like several orders of magnitude), but as you do so the jitter on the recovered clock goes up. Also, you need to modify the charge pump into the integrator as the frequency changes in order to keep the loop damping the same. Not actually a problem in your case, though. The big reason I suggested the FPGA approach, though is that you already have an FPGA, so no extra circuitry is required. Apr 23, 2014 at 1:35
• In your case, you could probably get adequate performance out of a 74HC4046 with an AD537 VFC. Much would depend on the longest stretch of all zeroes or all ones you encounter. Apr 23, 2014 at 3:04