I'm currently reading a lot about different encoding techniques for data transmission, in particular ethernet, fiber (and usb). 10Base Tx ethernet uses Manchester encoding for data transmission. But it is not used for 100Base Tx or 100Base Fx. Instead MLT3 or NRZI encoding is used. I read that this has something to do with the speed (frequency?) limitations of the techniques. But where does this limitation come from? Is it dependent on the media (fiber, copper), the distance between the transmit and the receive side or is it somehow inherent to the applied technique? Could I maybe use Manchester encoding for a high speed (100 mbps) optical data link over air or for a cable link if the distance between both sides is only some centimeters? Related to this question: Is there a way to convert encoded data from e.g. MLT3 to Manchester or NRZI encoding? Most ethernet chips for 100 mbps use MLT3 encoding but for my application I probably need Manchester encoded data as input.
1 Answer
Multi-level codings allow you to send more bits in a given frequency, with the trade-off of needing more complexity to generate and detect the multiple levels.
At the time the 100mbps Ethernet copper standard was being developed, this obviously felt like the right compromise of interface complexity vs demands for cabling of a particular quality.
Standards like Ethernet are an immensely complex balancing act of backwards compatibility, politics, vested interests and attempts to predict future demand. You can't really pick one of umpteen overlapping engineering decisions and say 'why did they do that?', because the answer is always at least in part 'because they did all the other stuff'.
In answer to your specific question about recoding stuff, then yes, you can always do that, because if you can decode one format and generate another, then you can put those circuits back-to-back.
-
\$\begingroup\$ "with the trade-off of needing more complexity to generate and detect the multiple levels" -- and also needing a better signal to noise ratio to correctly decode. \$\endgroup\$ Commented Jan 20, 2016 at 14:18