How does NRZ recover the clock? For example, Manchester coding is a self-time scheme, but we still need to have DLL or PLL for the recovery, it can be done without those CDR circuits? and back to NRZ, can NRZ be used without DLL or PLL for recovery?

  • 1
    \$\begingroup\$ I have only time for a short answer. I've added it. But are you seriously asking for a long discussion on this topic? There are many 100-page theses on this topic! You wrote but just a few sentences and hand-waved in many directions. That leaves me uncomfortable writing more than I have. \$\endgroup\$
    – jonk
    Oct 26, 2021 at 2:53

3 Answers 3

  1. You can attempt to recover the clock (regenerate it) from the signal itself by detecting the waveform transitions. This technique, while theoretically possible under ideal circumstances, is usually not employed because jitter and noise easily corrupt the perceived timing of incoming transitions. And the corruption of even so much as a single case during reception of a data block will cause loss of synchronization and the loss of pretty much the entire rest of the block.

    I don't think anyone does this, in practice.

  2. The alternative is to include a local receiver clock (VCO) and then phase-lock it to the incoming signal using some manner of PLL. (There will be a lock-in range.) This way, there's a very clean, locally generated clock. Even under bad conditions. An error will now likely only affect one bit and this can be corrected using fairly well-understood error correction techniques. This local receiver clock, after lock, is also called a recovered clock

So the short answer is, "Yes". I believe Manchester requires local clock recovery that involves a PLL, a local VCO, and some manner of phase detection (but not sequential phase detection) and clock recovery circuitry leading to a locked local VCO that yields the recovered clock along with retimed data.

The above discussion applies to Manchester (of which there are a variety of techniques... so it's not just one thing.)

Of course, no one is stopped from directly recovering the clock signal from the received signal. It's just that once synch is lost, it stays lost until it can be recovered again. In that case, I suppose you could say that a local VCO and PLL aren't strictly necessary. But this only works well when everything is very clean and losing synch is tolerable.

These problems with NRZ make the above discussion less applicable:

  • Long strings of 0s are easily confused with no signal present

  • Long strings of 1s cause the baseline to wander

  • And both make clock recovery difficult/hard/impossible

NRZI solves one of these (the 1s) but not the other. However, going to 4B/5B (which uses NRZI afterwards) can increase the data rate for a given bandwidth over that which Manchester allows while also solving the issues with NRZ and naked NRZI.


For synchronous channels there are many different protocols that lend themselves for easy SERDES design and clock recovery.

This includes many options;

  1. Using a harmonic method of locking a PLL VCO to harmonics of the smallest transition interval.
  2. Include odd parity to ensure at minimum transition density and also for gain control if necessary for Vpp detection and accurate PW50%.
  3. Use a scrambling method to randomize the data for maximizing transition density.
  4. Use a preamble of of 1010 to enable fast clock sync then a bit pattern for Byte Sync, then a Frame Sync byte pattern for multi-byte packets or continuous frames.
  5. Use tight tolerance on frequency error, so that transition density matters less.
  6. Use a global clock reference (Stratum level clock) that only requires phase control to get in sync.
  7. Use a much faster clock to count phase error rapidly and data clock phase error instantly with low jitter and low frequency error links.
  8. Use Raised Cosine filtering if any is required to minimize ISI that reduces BER from phase or eye pattern margin between clock and data.

My earlier experience was designing a BER Test set for DS1 1.544 Mbps in a custom designed two-way ISDN network trial in 1980 using the Stratum clock sync method.

Then a few years later using PLL with a VCXO for a 4 Mbps link that was broadcast in the unused TV blank lines. I chose a PLL method that could lock in 4 sync transitions , yet stay in for 1000 bits with no NRZ transitions, primarily due to the high SNR for TV and low jitter and dual BW PLL.

I chose a sawtooth S&H of the VCXO and used XOR pulses from data transitions to sample the sawtooth voltage for VCXO phase error correction and lock quickly on 1 byte of 10101010. Then I changed loop BW so as to not drift in phase for the rest of the channel burst of 15.6 ms while correcting any drift with data transitions. The BER spec of < 1e-12 was achieved.


How does NRZ recover the clock?

Simply by detecting edges and synchronizing a data clock to the recovered edges. This does not (necessarily) require a PLL. The classic technique is the standard UART philosophy, which uses a largish multiple of the data frequency to over-sample the data, then reset the data clock at each edge. Of course, this means that both the transmit and receive clocks must be quite accurate, or the data must guarantee some maximum number or data bits without transitions.

In the classic RS232 scheme, a start bit is used for initial synchronization, and the word length must be small enough to guarantee that the recovered clock will not drift more than 1/2 bit during a word. This requires, for an 8-bit word, that the two frequencies are matched to better than 6%. Since it's easy to get much better matching using crystal oscillators, this is not usually an issue, although it also requires a fairly high SNR on the received signal to avoid spurious edges.

CANBUS, another NRZ protocol, employs bit stuffing. When there are 5 bits in a row with the same value, the transmitter inserts a dummy bit of the opposite value, which is detected and ignored by the receiver.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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