5

We all know that there are various encoding schemes to encode data like Manchester Encoding, before sending it. But why is there a need to encode the data to a signal? Why can't we just transmit the waveforms?

  • This isn't a full answer so I'll post it as a comment, in addition to the existing answers; A minor amount of efficiency increase can some from certain encode schemes and symbol "phrases" – jwbensley Sep 11 '13 at 13:15
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 10 '17 at 0:36
6

Electrically speaking, encoding schemes are important to keep the line balanced - even if the data changes state often enough to clock and be distinguishable from a dead line, if it has an uneven number of 1's/0's the receiver develops an unbalanced offset voltage. Encoding ensures both that there are no long strings of 1's or 0's, and that the total number is effectively balanced over time.

  • 1
    +1, however the problem with a line bias voltage is that it can impede clock recovery, as well as potentially making it impossible to distinguish a 1 from a 0 – Mike Pennington Sep 11 '13 at 12:36
4

The systems simply work better with the benefits brought by various encoding schemes.

So your Manchester Encoding example has the benefit of ensuring frequent -- more frequent than would be the case with typical data -- voltage changes on the wires. More frequent voltage changes have the side effect, in this example, of making clock/timing work better. Other encodings have other benefits that befit their transmission mediums.

  • 4
    quite arguably, the primary reason for line encoding is reliable clocking, which isnt possible if you get long strings of the same value directly encoded on the wire. Even when you specify an encoding, you must encode correctly. Early forms of Packet over SONET actually had a secret vulnerability that would make the line protocol drop on certain packet payloads before the industry standardized on a longer scrambler polynomial in RFC 2615. – Mike Pennington Sep 10 '13 at 15:09
  • 1
    Look at the original use of these encoding schemes on the original (read: copper) digital circuits. The electrical characteristics of the media tended to confuse long strings of zeroes with a dead line just as long strings of 1's might actually be a capacitance problem (for example). Nowadays, of course, optical transmission renders a lot of this moot and clocking becomes the primary value. – rnxrx Sep 10 '13 at 16:51
4

Traditional encoding mechanisms were built to deal with certain media characteristics - specifically electrical issues on traditional copper media or high BER carriers in the various wireless domains. With modern transmission systems there has been a push to streamline these mechanisms to simplify protocol stacks and make better use of available bandwidth by removing associated overhead (i.e. removing SONET encoding from the equation for IPoWDM).

In the larger sense the issue with transmitting native waveforms with no encoding is that some kind of system is required to map between the information to be transmitted and the media over which transmission is to occur. In the case of a T1 circuit (for example) this corresponds to a set of voltage thresholds and an expected signalling rate. Without such a system there is no guarantee (or even likely hope) that what one side transmits is what the other side receives.

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.