2
\$\begingroup\$

I am reading about physical layer of the OSI model. Specifically the different ways in which digital bits can be represented as voltage levels, among the multiple types are:

  • NRZ.
  • Manchester encoding.

My understanding of NRZ encoding, when both tx and rx clock are synchronized, is as follows:

enter image description here

It is stated that tx and rx clocks might go out of sync in which case NRZ encoding will have issues when decoding long strings of 0's (or) 1's, and manchester encoding addresses this problem.

I am having hard time understanding the logic. A picture is worth a thousand words, so can you please help me understand this with a clock /signal diagram that shows.

  • tx clock.
  • rx clock (drifted)
  • tx data (nrz)
  • rx data (nrz)->how drifted clock has affected data.
  • tx data (manchester)
  • rx data (manchester) -> how manchester handles rx clock going out of sync.
\$\endgroup\$
4
\$\begingroup\$

In simple terms, with NRZ encoding and reception, unless you have perfectly synchronous clocks at both ends it won't handle long periods of logic 1 or logic 0 being transmitted. This is because one clock will drift relative to the other and therefore you are limited to how many successive 1's or 0's that can be adequately decoded before the clocks get out of sync and a bit is lost. If the data is changing quite often, then the receiver can re-sync its locally-generated clock on the edges of data changes.

With Manchester encoding (or scrambling), the clock is always embedded with the data and clever logic pulls out the clock signal and hence you can decode data properly. In other words, in the presense of long strings of 1 or 0 Manchester encoding produces a combined data/clock output that toggles quite often so the clock is always decodable and you won't lose sync.

With NRZ decoding, consider the problem that a UART faces in syncing its clock to the transmit clock. The top part of the diagram is when the receiver clock rate is pretty much 16x the transmitter bit rate: -

enter image description here

The bottom part of the picture shows what happens when the receiver clock rate is too slow (for example).

Normally, the UART receiver runs a clock that is close-to 16x higher than the baud rate. In a perfect situation, after receiving the leading edge of a transmission (the start bit is always low), the receiver counts out 8 cycles of its internal clock to estimate the mid bit position. It then "samples" the data and restarts its clock from this point so that it can count another 16 to get the mid-bit position of the 1st bit.

If the data is low all the way through the transmitted UART byte then providing the receiver clock doesn't drift off too much then the last bit (D7) will be sampled mid-bit and all is well.

However if the basic receiver clock is not well matched at 16x the transmit baud rate, then you could miss a bit or count an extra bit. This problem is compounded if the word length is longer than 8 bits (plus start bit and stop bit). Mitigation comes from the fact that data doesn't always remain at 1 or 0 and the receiver can resync its sampling by counting 8 from any data edge.

\$\endgroup\$
  • \$\begingroup\$ Thanks for the answer, your answer is pointing me towards the right direction of understanding. Few questions though (sorray am new to the lower layers of OSI), lets say Tx clock period is 1us, and there is a stream of 4 1's corresponding to 4 clock edges. Does clock drift mean that rx clock may drift away and have 3 clock edges in 4us, and fail to decode one bit is that correct? \$\endgroup\$ – Vivek Maran Feb 17 '18 at 11:13
  • \$\begingroup\$ It’s an extreme example but yes, that is what happens. \$\endgroup\$ – Andy aka Feb 17 '18 at 11:14
  • \$\begingroup\$ Ok thanks, have upvoted the answer. Will see for sometime if someone posts a diagram. If not' ll accept the answer \$\endgroup\$ – Vivek Maran Feb 17 '18 at 11:19
  • \$\begingroup\$ Andy, if you're going to steal someone else's diagram instead of drawing your own, you need to provide attribution. \$\endgroup\$ – Dave Tweed Feb 17 '18 at 15:16
  • \$\begingroup\$ @DaveTweed yes, you are right on both questions. Later today I’ll do it. \$\endgroup\$ – Andy aka Feb 17 '18 at 15:29

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.