Entendendo as taxas de transmissão de dados por fio de cobre

Eu tenho pesquisado as diferentes maneiras de conectar sensores a um Arduino, e o i2c parece ser um método popular. Eu li que ele é confiável apenas a curtas distâncias (no máximo alguns metros), com uma taxa de dados de 400 ou 100kbps. Estou tendo dificuldade para entender por que os limites deste protocolo são tão baixos em comparação com outras transmissões de dados sobre cobre, como Ethernet de gigabit. Já vi razões como capacitância, queda de tensão e resistência, mas a Ethernet sobre cat5 / 6 não está sujeita aos mesmos problemas? Basicamente, quero saber por que pulsar alguma tensão em algum fio de cobre não produz resultados mais consistentes (largura de banda, distância) ao comparar essas diferentes metodologias.

O Teorema de Shannon define o limite máximo de largura de banda de informação em um cabo. Aqui estão mais algumas informações sobre isso: https://www.gaussianwaves.com/2008/04/channel-capacity/

tl; versão dr: a equação de Shannon-Hartley:

• $C = B \; log_2 \left( 1 + \frac{S}{N}\right) \;\;\;\;\;\;\;\;\;\; \rightarrow (1)$

Onde é a largura de banda em Hz, é a razão sinal-ruído.$B$$\frac{S}{N}$

O I2C obviamente não está nem perto do limite de Shannon para um cabo. Em vez disso, é um protocolo leve com tempo intencionalmente lento (100/400 kbit / s), usando um barramento de coletor aberto para facilitar a implementação em uma rede de pequenos dispositivos com E / S modestas e necessidades de controle. A operação lenta especificada pelo I2C evita a maioria dos problemas de integridade do sinal.

Existem variantes mais rápidas do I2C que usam taxas de 1 Mbit e 3,2 Mbit / s. Isso requer mais atenção ao layout e terminação do que o I2C normal e, é claro, tem um tempo mais rígido e exigente.

Subindo na cadeia alimentar em termos de Shannon, a Gbit Ethernet usa várias técnicas para alcançar seu rendimento:

• Sinalização diferencial
• Vários pares (4)
• Sinalização multinível, chamada PAM-5
• Pré-ênfase / Deemphasis
• Equalização adaptativa

Essas técnicas exigem muito silício, incluindo um bloco ADC / DAC de sinal misto grande e rápido para conversar com o cabo e algum processamento de sinal bastante pesado para gerenciá-lo. Adicione a isso, a pilha de software muito mais complexa para controlá-lo. Isso torna a Ethernet como um bloco no chip um pouco demais para um microcontrolador low-end (alguns dos quais optam por usar um PHY externo). Sua maturidade, no entanto, a coloca bem ao alcance de sistemas maiores no chip.

Até que ponto estamos chegando ao limite de Shannon? Mais aqui: https://pdfs.semanticscholar.org/482f/5afbf88a06d192f7cb052f543625c4b66290.pdf

Há mais na transmissão do que apenas o cabo de cobre. Você já viu o hardware por trás da Ethernet? Provavelmente não, porque é extremamente difícil encontrar qualquer circuito de nível básico para o que realmente está acontecendo, uma vez que as tripas estão sempre escondidas em um CI. O mais próximo que eu já encontrei é o magnético necessário para a Ethernet, que aparentemente não é opcional. Isso é apenas uma dica do que está acontecendo fisicamente com o hardware Ethernet.

Pense da seguinte maneira: o ar é um meio. Por que o tipo de informação que pode ser transmitida quando os cães conversam muito menos do que quando os humanos conversam? Por que o envio de algumas ondas de pressão pelo ar não produz resultados mais consistentes na comunicação entre esses dois tipos de animais?

Apenas alguns dos fatores limitantes para o I2C (e muitos outros protocolos) são:

1. unidade de coletor aberto
2. sem correspondência de impedância
3. sem transmissão balanceada
4. nenhuma verificação de erro
5. esquema de codificação simples
6. níveis de voltagem relativamente altos (se o seu passo de voltagem não precisar ser tão grande, você poderá transmitir mais rapidamente porque seu dV / dT não precisará ser tão alto para velocidades mais altas)
7. sem isolamento
8. tensões unipolares (a Ethernet transmite a +/- 2,5V, o que provavelmente ajuda de alguma forma)
9. A transmissão do escravo é cronometrada pelo mestre, portanto, basicamente, o relógio precisa fazer uma viagem de ida e volta mais rápido que o sinal de dados

Tudo isso é bom para simplificar as coisas. Não é tão bom para altas taxas de dados ou transmissão de longa distância.

Provavelmente também há outro vodu no hardware que eu não conheço.

Algumas regras simples: Não existe fundamento. Todos os fios são antenas. Todos os fios são linhas de transmissão. Sempre há barulho.

Se um fio for curto em comparação com o tempo de subida do sinal, você poderá ignorar incompatibilidades e reflexos de impedância da linha de transmissão (ao contrário da Ethernet, que requer terminações complexas e modelagem de pulsos). Se o fio for longo, as tensões induzidas nos diferenciais de fio e terra são mais prováveis ​​de tornar os níveis do sinal digital na extremidade oposta indeterminados ou incorretos. Mas a Ethernet usa sinalização diferencial de par trançado, reduzindo bastante os problemas de referência de ruído e terra induzidos. O receptor Ethernet também usa entradas analógicas mais sensíveis, em vez de entradas digitais típicas, permitindo assim mais perda de linha. Adicione à codificação e correção de erros dessa Ethernet para superar as estatísticas de ruído, e você poderá ir com mais segurança e rapidez e mais longe.

O I2C é um barramento de dreno aberto , é ativamente puxado para baixo, mas o pull-up (pelo menos para as variantes normais de 100kHz, 400kHz) são resistores passivos.

Por causa disso, há um limite de velocidade com que a coisa pode funcionar com base na rapidez com que os resistores pull-up podem carregar a capacitância do barramento, às vezes você pode obter mais velocidade diminuindo os valores pull-up, mas isso significa que os nós precisam afundar mais corrente para obter uma lógica baixa .... Ou você pode ir para o outro lado, diminuir a velocidade do barramento para permitir o uso de resistores pull up de maior valor para menor dissipação de energia (veja, por exemplo, barramento PM).

É instrutivo acionar um escopo e observar que a borda descendente do I2C é MUITO mais nítida que a subida.

Para o uso pretendido, basicamente sensores de temperatura e pequenos dispositivos de configuração em uma única placa (ou no máximo um único chassi), isso acaba atingindo o ponto ideal entre a complexidade da implementação, a baixa contagem de pinos e o hardware simples. O objetivo do projeto não era "Links de dados rápidos e de longa distância" e, por tudo que considero mais fácil lidar com o SPI, o I2C se encaixa muito bem no caso de uso pretendido.

Uma vez que as distâncias aumentam, algo mais se adapta melhor, mas em uma placa com interfaces modestas de configuração eeprom / temperatura / dispositivo, o desempenho é razoavelmente bom (vale a pena notar que a interface de gerenciamento PHY se parece muito com I2C).

Os resultados diferentes são porque o circuito do driver é diferente para cada tecnologia.

O I2C de 100kHz normalmente usa um resistor de pullup para colocar o sinal em um nível alto e drivers de dreno aberto para colocar o sinal em um nível baixo.

Os resistores de pullup são tipicamente vários quilo-ohms. Quanto mais tempo um cabo obtiver, mais capacitância terá. O tempo que a linha leva para fazer a transição de 0 para 1 será proporcional à capacitância total na linha e ao valor do resistor de pullup. Em algum lugar na faixa de cerca de T = 2 * R * C estaria quase certo.

Por exemplo, se você tivesse um cabo de 10 pés com 20pF por pé de capacitância e usasse um resistor de tração de 10K, seria necessário T = 2 * 20pF / pés * 10 pés * 10K = 3,6us para passar de baixo para alto.

Nesse caso, obviamente você não poderia ter nenhum bit após um bit zero com menos de 3,6us de largura, portanto sua taxa de transmissão seria limitada a 277kHz.

Em um sistema I2C real, a especificação I2C exige ainda mais a configuração e o tempo de espera nas transições de dados e relógio. Esses tempos são centenas de nanossegundos ou microssegundos. O tempo era muito lento de propósito, para que os dispositivos pudessem ser implementados de forma barata (centavos) e consumir muito pouca energia (miliwatts).

A Ethernet, por outro lado, pode funcionar mais rapidamente, apesar da capacitância do cabo, porque não usa um resistor de pullup. Ele aciona ativamente alto ou baixo no cabo. O driver é de baixa impedância e pode carregar qualquer capacitância de linha muito rapidamente. Claro que tudo tem um preço. A Ethernet normalmente consome centenas de mW de energia e custa pelo menos alguns dólares por porta para implementar.

Poderia uma configuração semelhante ao I2C funcionar mais rápido, com certeza, basta alterar o pull-up de 10K para 100 ohms e agora seu tempo de subida em 10 pés de cabo cai de 3,6us para 36ns. Você provavelmente poderia rodar em torno de 10 MHz sem muitos problemas (além do fato de que chips I2C comuns não conseguem falar tão rápido).