Does NRZ-I have a synchronization problem?

I'm new to EE, just have a question on synchronization.

I was reading a book which says:

NRZ-I has no problem with sequences of 1s, but has problem with sequences of 0s.

It certainly has a synchronization problem with sequences of 0s. But for sequences of 1s, it is still possible to have a synchronization problem.

For example, if a sender sends 1111 and the receiver's clock is twice as fast as the sender's clock, the receiver will interpret the pattern as 101010.

Isn't that a synchronization problem?

• If every '1' causes a toggle (low to high or high to low), won't the receiver be able to count that there are 4 toggles instead of 8 toggles? How would it detect 8 changes when there are only 4? – Justin May 23 at 12:49
• Do you understand that a sequence of 0s means that the voltage stays constant, and a sequence of 1s means that the signal is toggling every bit? – Justin May 23 at 12:51
• @Justin sorry Justin, I was thinking too fast, I mean the receiver will interpret 1111 as 101010 – secondimage May 23 at 13:39

For example, if a sender sends 1111 and the receiver's clock is twice as fast as the sender's clock, the receiver will interpret the pattern as 101010.

Isn't that a synchronization problem?

Not in this context, no. When you design a synchronous communications link like this you assume that the uncorrected receiver clock is pretty close to the transmitter clock. "Pretty close" can vary (and you design the communications protocol with an allowable mismatch in mind), but $$\\pm 10\%\$$ is easy to achieve with RC circuits, and $$\0.1\%\$$ is easy with crystal-controlled circuits.

Part of a system designer's task would be to assess the tradeoff between protocols that allow quicker synchronization at the expense of a closer initial match between receiver and transmitter (and hence more expensive receivers and transmitters) vs. the opposite.

No, because NRZI is not the same as NRZ.

Each '1' in NRZI is a toggle regardless of rate. So "1111" cannot be confused with "11111111" because you cannot confuse 4 toggles with 8 toggles.

But that's not the whole story : in your example (receiver at double rate) "1111" (sent 4 toggles) would be received as "10101010" (4 toggles, 4 spaces between toggles). (OK you edited the question to reflect this)

But this isn't a synchronisation error per se : synchronisation doesn't guarantee the ability to decode arbitrary signals : some a-priori knowledge of the approximate data rate can be assumed (or specified in the coding scheme) and 2:1 variation prohibited.

Then "1111" is self synchronising (the first toggle tells you when the first bit appears) and subsequent toggles keep you aligned to track clock errors, but "0000" is patently not because nothing happens.

"00001111" is still not self synchronising; so there must be something else like a preamble or idle pattern to provide framing (i.e. identify the start of a message or packet)

• Thanks for your answer. I'm still a little bit confused, the synchronization problem is a problem that receiver cannot tell when does a signal element end, that why we come up with return zero to assist us. Since the receiver can't tell when does a signal ends in the pattern, how come it is not a synchronization problem?e.g. the first toggle might be a '1', but it might also be '10', the receiver couldn't tell – secondimage May 23 at 14:30
• Because some a-priori knowledge of the approximate data rate can be assumed. What knowledge? Depends on the comms scheme; 100ppm, or 0.1% or 10% as Tim says, but for NRZI it is obviously less than 2:1 for the reason you state. – Brian Drummond May 23 at 15:02