Este artigo estende o artigo introdutório sobre modulação banda-base onde o código Manchester foi devidamente explanado, e (assim espero) entendido e aceito pelo leitor como um código funcional.
O código Manchester e em particular a sua variante diferencial são bons, mas conforme mencionado no artigo introdutório eles são relativamente exigentes em termos de banda. Manchester foi a escolha da Ethernet 10Mbit, porém não mais em 100Mbit, pois aqueles cabos azuis Categoria 5 não dariam conta de transmitir 100Mbit nessa modulação.
Bem, sucede que é possível transmitir uma seqüência de bits "crua" (denominada código NRZ) assim como está. E na verdade o NRZ é largamente empregado. Ele precisa de apenas metade da banda que a modulação Manchester. Mas como superar os problemas apontados no artigo introdutório, como a recuperação de clock no caso da mensagem ser composta de longas seqüências de 000000... ou 11111111...? E como evitar o DC Bias?
Há uma solução simples para isto: garantir que não haja longas seqüências monótonas. Isto dá ao RX oportunidade de recalibrar o clock.
Há diversos métodos de implementar esta garantia. O método mais simples é denominado bit stuffing ("recheio de bits"). No exemplo abaixo, um bit invertido é inserido depois de 5 bits iguais consecutivos:
0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 1 |
0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 1 |
O lado RX sabe que o TX pratica o bit stuffing, então ele simplesmente remove o sexto bit da mensagem recebida, depois de cinco bits iguais consecutivos. Note que o sexto bit da mensagem original não entra nessa conta; o bit de recheio é adicionado independente do valor do bit seguinte.
A recuperação de clock RX (que vai ser alguma implementação de PLL) também sabe quantos bits consecutivos são permitidos pelo protocolo. Assim sendo, o PLL não tentará reajustar o clock rápido demais; ele precisa "ouvir" uma seqüência longa de bits codificados antes de tomar uma decisão.
Uma desvantagem do bit stuffing é que ele desperdiça banda. Mensagens "problemáticas" com longas seqüências de 0's ou 1's podem consumir até 20% mais banda do que o originalmente previsto, e o meio físico precisa ter 20% de capacidade de sobra para lidar com esta possibilidade.
Há técnicas mais avançadas que o bit stuffing, que não exigem banda extra, mas não vamos considerá-las neste artigo. Por ora, vamos nos restringir a mencionar uma técnica denominada alvejamento de bits ou bit whitening. (É "alvejar" no sentido de "branquear", não no sentido de "disparar contra".)
Alvejamento de bits é uma transformação da mensagem que faz a mesma parecer mais aleatória. A maioria das mensagens (como textos, e-mails, etc.) são extremamente monótonas, e cheias de longas seqüências repetitivas, com muito mais bits 1 que 0 ou vice-versa. Depois do "alvejamento", elas geralmente serão muito mais balanceadas, com um número igual de bits 0 e 1, e sem monotonia. Obviamente, essa transformação tem de ser desfeita no lado RX para recuperar a mensagem original.
Esse tratamento reduz e uniformiza as ocorrências de "recheio de bits" - em vez de precisar 20% a mais de banda de forma intermitente, a mensagem "alvejada" vai precisar, digamos, 5% a mais de banda de forma contínua. Isto permite usar um canal um pouco mais barato.
Alvejamento de dados é uma técnica que confia em probabilidades. É perfeitamente possível que uma mensagem fique mais monótona que a original depois do alvejamento. Mas a chance disso acontecer é muito baixa.