Comprender las tasas de transmisión de datos a través del cable de cobre

He estado investigando las diferentes formas de conectar sensores a un Arduino, y i2c parece ser un método popular. He leído que solo es confiable a distancias cortas (unos pocos metros, como máximo), con una velocidad de datos de 400 o 100 kbps. Me cuesta entender por qué los límites de este protocolo son tan bajos en comparación con otras transmisiones de datos a través del cobre, como el gigabit Ethernet. He visto razones como la capacitancia, la caída de voltaje y la resistencia, pero ¿no está Ethernet sobre cat5 / 6 sujeta a todos esos mismos problemas? Básicamente, quiero saber por qué pulsar un poco de voltaje en un cable de cobre no produce resultados más consistentes (ancho de banda, distancia) al comparar estas diferentes metodologías.

El teorema de Shannon establece el límite máximo del ancho de banda de información en un cable. Aquí hay más información sobre eso: https://www.gaussianwaves.com/2008/04/channel-capacity/

tl; Versión dr: la ecuación de Shannon-Hartley:

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

Donde es el ancho de banda en Hz, es la relación señal-ruido.$B$$\frac{S}{N}$

I2C obviamente no está cerca del límite de Shannon para un cable. En cambio, es un protocolo liviano con temporización intencionalmente lenta (100/400 kbit / s) que utiliza un bus de colector abierto para que sea fácil de implementar para una red de dispositivos pequeños con E / S moderadas y necesidades de control. La operación lenta especificada por I2C evita la mayoría de los problemas de integridad de la señal.

Hay variantes más rápidas de I2C que usan velocidades de 1 Mbit y 3.2 Mbit / s. Estos requieren más atención al diseño y terminación que el I2C normal y, por supuesto, tienen un tiempo más estricto y exigente.

Ascendiendo en la cadena alimenticia de Shannon, Gbit Ethernet utiliza múltiples técnicas para lograr su rendimiento:

• Señalización diferencial
• Múltiples pares (4)
• Señalización multinivel, llamada PAM-5
• Preemphasis / Deemphasis
• Ecualización adaptativa

Estas técnicas requieren una gran cantidad de silicio, incluido un bloque ADC / DAC de señal mixta rápido y grande para comunicarse con el cable y un procesamiento de señal bastante pesado para administrarlo. Agregue a esto, la pila de software mucho más compleja para manejarlo. Esto hace que Ethernet como un bloque en el chip sea demasiado para un microcontrolador de gama baja (algunos de los cuales optan por usar un PHY externo). Sin embargo, su madurez lo coloca al alcance de los sistemas en chip más grandes.

¿Qué tan cerca estamos llegando al límite de Shannon, de todos modos? Más aquí: https://pdfs.semanticscholar.org/482f/5afbf88a06d192f7cb052f543625c4b66290.pdf

Hay más en la transmisión que solo el cable de cobre. ¿Has visto el hardware detrás de Ethernet? Probablemente no, porque es extremadamente difícil encontrar cualquier circuito de nivel base para lo que realmente está sucediendo, ya que las tripas siempre están ocultas en un CI. Lo más cercano que he encontrado es el magnetismo requerido para Ethernet, que aparentemente no es opcional. Eso es solo una pista de lo que sucede físicamente con el hardware de Ethernet.

Piénselo de esta manera: el aire es un medio. ¿Por qué el tipo de información que se puede transmitir cuando los perros se hablan entre ellos es mucho menos que cuando los humanos se hablan entre sí? ¿Por qué enviar algunas ondas de presión a través del aire no produce resultados más consistentes en la comunicación entre estos dos tipos de animales?

Algunos de los factores limitantes para I2C (y muchos otros protocolos) son:

1. unidad de colector abierto
2. sin coincidencia de impedancia
3. sin transmisión equilibrada
4. sin comprobación de errores
5. esquema de codificación simple
6. niveles de voltaje relativamente altos (si su paso de voltaje no tiene que ser tan grande, puede transmitir más rápido porque su dV / dT no tiene que ser tan alto para velocidades más altas)
7. sin aislamiento
8. voltajes unipolares (Ethernet transmite a +/- 2.5V que probablemente ayuda de alguna manera)
9. La transmisión del esclavo es sincronizada por el maestro, por lo que básicamente el reloj tiene que hacer un viaje de ida y vuelta más rápido que la señal de datos

Todos estos son buenos para simplificar las cosas. No es tan bueno para altas velocidades de transmisión de datos o larga distancia.

Probablemente también haya otro vudú en el hardware que no conozco.

Algunas reglas básicas simples: no existe el terreno. Todos los cables son antenas. Todos los cables son líneas de transmisión. Siempre hay ruido.

Si un cable es corto en comparación con el tiempo de subida de la señal, puede ignorar los desajustes y reflexiones de impedancia de la línea de transmisión (a diferencia de Ethernet, que requiere terminaciones complejas y conformación de pulso). Si el cable es largo, es más probable que los voltajes inducidos en el cable y los diferenciales de tierra hagan que sus niveles de señal digital sean indeterminados o incorrectos en el otro extremo. Pero Ethernet utiliza señalización diferencial de par trenzado, lo que reduce en gran medida el ruido inducido y los problemas de referencia a tierra. El receptor Ethernet también utiliza entradas analógicas más sensibles en lugar de entradas digitales típicas, lo que permite una mayor pérdida de línea. Agregue a esa codificación de Ethernet y corrección de errores para superar las estadísticas de ruido, y podrá ir más rápido y más lejos de manera más confiable.

I2C es un bus de drenaje abierto , se baja activamente, pero el pull up (al menos para las variantes normales de 100kHz, 400kHz) son resistencias pasivas.

Debido a esto, hay un límite sobre la rapidez con que la cosa puede funcionar en función de la rapidez con que las resistencias pull-up pueden cargar la capacitancia del bus, a veces puede obtener más velocidad al reducir los valores pull-up, pero eso significa que los nodos deben hundirse más corriente para obtener un nivel lógico bajo ... O puede ir hacia el otro lado, reducir la velocidad del bus para permitir el uso de resistencias pull-up de mayor valor para una menor disipación de potencia (ver, por ejemplo, bus PM).

Es instructivo disparar un osciloscopio y observar que el flanco descendente en I2C es MUCHO más agudo que el ascendente.

Para el uso previsto, básicamente sensores de temperatura y dispositivos de configuración pequeños dentro de una sola placa (o como máximo un solo chasis), esto resulta ser el punto óptimo entre la complejidad de la implementación, el bajo recuento de clavijas y el hardware simple. La intención del diseño no era "Enlaces de datos rápidos y de larga distancia", y por todo lo que considero que SPI es generalmente más fácil de manejar, I2C se ajusta muy bien a su caso de uso previsto.

Una vez que las distancias aumentan, algo más se adapta mejor, pero en una placa con modestas interfaces de configuración eeprom / temperatura / dispositivo, funciona razonablemente bien (Vale la pena señalar que la interfaz de administración PHY se parece MUCHO a I2C).

Los diferentes resultados se deben a que el circuito del controlador es diferente para cada tecnología.

100kHz I2C generalmente usa una resistencia pullup para poner la señal en un nivel alto y controladores de drenaje abierto para poner la señal en un nivel bajo.

Las resistencias pullup son típicamente varios kilo-ohmios. Cuanto más tiempo tenga un cable, más capacitancia tendrá. El tiempo que le toma a la línea pasar de 0 a 1 será proporcional a la capacitancia total en la línea y al valor de la resistencia pullup. En algún lugar en el rango de aproximadamente T = 2 * R * C sería aproximadamente correcto.

Por ejemplo, si tenía un cable de 10 pies que tenía 20pF por pie de capacitancia y usaba una resistencia pullup de 10K, entonces tomaría T = 2 * 20pF / ft * 10 ft * 10K = 3.6us para pasar de bajo a alto.

En este caso, obviamente, no podría tener ningún bit después de un bit cero que tuviera menos de 3.6us de ancho, por lo que su velocidad de transmisión se limitaría a 277kHz.

En un sistema I2C real, la especificación I2C exige aún más la configuración y los tiempos de espera alrededor de las transiciones de datos y reloj. Esos tiempos son cientos de nanosegundos o microsegundos. El tiempo se hizo muy lento a propósito para que los dispositivos pudieran implementarse a bajo costo (centavos) y consumir muy poca energía (milivatios).

Ethernet, por otro lado, puede funcionar más rápido a pesar de la capacitancia del cable porque no usa una resistencia pullup. Conduce activamente ya sea alto o bajo en el cable. El controlador es de baja impedancia y puede cargar cualquier capacitancia de línea muy rápidamente. Por supuesto que todo tiene un precio. Ethernet generalmente consume cientos de mW de potencia y su implementación cuesta al menos unos pocos dólares por puerto.

Si una configuración similar a I2C se ejecuta más rápido, solo cambie el pullup de 10K a 100 ohmios y ahora su tiempo de subida a 10 pies de cable cae de 3.6us a 36ns. Entonces, probablemente podría correr a alrededor de 10MHz sin demasiados problemas (aparte del hecho de que los chips I2C normales no pueden hablar tan rápido).