Enviando I2C de forma confiable a través de cables Cat5

Tratar de ver con IIC es una mala idea. IIC está realmente destinado a la comunicación entre chips en una sola placa. Dado que la corriente máxima requerida para tirar de una línea baja es limitada, las líneas tienen una impedancia relativamente alta (unos pocos kΩ). Esto significa que pueden captar el ruido fácilmente, lo cual es un problema grave cuando se ejecuta en un cable sin blindaje en las paredes, posiblemente justo al lado de los cables de alimentación de CA.

Yo usaría CAN para esto. CAN utiliza un solo par trenzado juntado con solo 60 en cualquier punto, y la señal es diferencial. Eso significa que la mayoría del inevitable ruido de modo común que se detectará debido al acoplamiento capacitivo puede ser cancelado por los receptores. PUEDE funcionar a 500 kbits / s puede cubrir algo del tamaño de una casa común.

Muchos microcontroladores están disponibles hoy con CAN incorporado. Por lo general, se necesita un chip de tranceiver físico (como el MCP2551 común), pero las capas más bajas del protocolo se implementan en silicio en el periférico de CAN. El firmware interactúa con el bus CAN en el nivel de envío y recepción de paquetes completos. La detección y el reintento de colisión, la generación de suma de comprobación, los detalles de la señalización de paquetes de bus, la validación de suma de comprobación recibida y el ajuste de la deriva del reloj se manejan por usted.

No caigas en RS-485. Esa es una reliquia de una época pasada. También utiliza una única señal diferencial como CAN, por lo que también tiene buena inmunidad al ruido. Sin embargo, la gente generalmente se enamora de RS-485 porque parece "más simple". Esto es solo porque no miran todo el sistema. En primer lugar, no es menos complejo eléctricamente. Aún necesitará algún tipo de transciever para conducir y recibir la señal diferencial. Si tiene un transceptor RS-485 conectado a la UART del microcontrolador o un MCP2551 conectado al periférico CAN es bastante irrelevante en términos de costo y complejidad de hardware. La gran diferencia es que RS-485 lo deja en el nivel de byte sin procesar (a través del UART). Esto significa que para implementar cualquier sistema significativo y robusto, debe inventar su propio protocolo para manejar la detección de colisiones, decidir cómo manejar los reintentos, la paquetización, la generación y comprobación de la suma de control, el control de flujo, etc. Puede usar una sola arquitectura maestra, pero los detalles correctos son mucho más complicados de lo que la gente cree que no los ha analizado a fondo. Con CAN solo puede enviar y recibir paquetes, y el hardware se ocupa de los detalles.

I2C no es el camino a seguir. Los transexuales CAN pueden costar un dólar cada uno, y puedes usarlos como uart trancieves y escribir tu propio protocolo para que no necesites un micro compatible con lata que no quieras usar con la pila de latas completa.

Siempre me siento un poco incómodo cuando veo que los conductores cat5 se ejecutan en paralelo para obtener más corriente. Me molesta porque si un conductor se rompe, el otro llevará la corriente completa del sistema. Las calificaciones actuales de cat5 son muy conservadoras, por lo que las probabilidades de un incendio son bastante bajas, pero simplemente no me gusta la posibilidad.

La forma segura de hacerlo es tener un polifusible en ambos rieles de alimentación y unir las conexiones a tierra en el suministro, y conectar cada dispositivo a uno y solo a un conjunto de alimentación / tierra. De esa manera, si un cable falla, los dispositivos que usan esa línea pierden energía en lugar de una línea obligada a llevar la energía de dos.

A mucha gente le gusta poner potencia y conexión a tierra en ambos pares trenzados por razones de EMI en lugar de tener un par de potencia y un par de tierra. Si tiene dos pares de potencia / tierra, la línea eléctrica estará más cerca de la tierra y los campos se cancelarán, reduciendo las ondas de radio transmitidas o recibidas de las líneas eléctricas. No es necesario, pero está bien si hay muchos ruidos de zumbido eléctrico.

En mi opinión, 12V es demasiado bajo para la distribución de energía cuando 24v sigue siendo razonablemente seguro y mucho más eficiente.

Si la automatización es simplemente encender y apagar las cosas en la casa, simplificaría esto por:

• Mantener todos los "cerebros" en un solo lugar. Use I2C I / O expansers si es necesario, pero manténgalos todos con la frambuesa pi. También necesitarás el hardware adecuado para asegurarte de que no estás tratando de obtener mucha corriente de los pines GPIO de la pi.
• Use los cables Ethernet para simplemente conducir los relés. Puede construir su propia placa o obtener relés de estado sólido de 120/240 V para montaje en panel que se montarán en una caja eléctrica. Los cables de los cables Ethernet Cat5 pueden manejar hasta 50 V a 320 mA cada uno, lo que es más que suficiente para impulsar un relé. De hecho, podría manejar 7 relés desde un solo cable (más un cable para conexión a tierra). O deje un cable para desconectar la salida de 12 V, para que también pueda instalar un interruptor manual. Si son realmente largos, es posible que deba tener en cuenta la caída de voltaje, pero puede obtener relés que cambiarán a 3-32V. 12V debería ser más que suficiente, incluso con una caída de voltaje.
• También querrá consultar los códigos de construcción locales para obtener consejos sobre la combinación de cableado de alta y baja tensión en la misma caja.
• Los interruptores simples también se pueden hacer a través de los cables Ethernet, de nuevo hasta 7 por cable, y simplemente cableados a las entradas del pi. La caída de voltaje puede ser una preocupación para los cables realmente largos.
• También puede usar optoaisladores para proteger el pi de daños.
• Para los pocos dispositivos que necesitan más que un relé (como un panel de control), use los cables de Ethernet como Ethernet real. No debería ser un gasto enorme si no hay muchos de estos dispositivos. Podrían ser otra pi o un microcontrolador con Ethernet.

^{simular este circuito : esquema creado usando CircuitLab}

EUREKA! ¡Lo averigué! (sin probar, lo probará este fin de semana)

Los chips de interfaz son NXP P82B96 I2C buffer / splitter y 2 chips de interfaz CAN bus SN65HVD251P de TI. Esencialmente, estoy ejecutando I2C en CAN PHY.

P82B96 entiende el protocolo I2C y maneja el arbitraje de bus por mí, y me da pines Tx y Rx separados que pueden unirse entre sí. Los introduzco en el transceptor CAN SN65HVD251P y me da el par diferencial bidireccional para enviar por cables.

Los pines de alimentación vienen directamente, sin búfer del riel de 5V de mi Pi. (No usaré voltaje y potencia de señalización de 12 V por un tiempo)

Independientemente de los méritos de IIC a nivel de chip, su implementación propuesta va a ser muy difícil. El problema es el arbitraje de autobuses. Aunque varias unidades pueden conectarse en paralelo utilizando, por ejemplo, RS485, la gran pregunta será:

¿Cómo sabe una unidad si puede tomar el control del bus para enviar datos?

En IIC, con las líneas de señal de drenaje abiertas, la transferencia bidireccional es fácil, pero con los buses tripulados necesita alguna forma de asegurarse de que solo una unidad intente conducir el bus a la vez. Esto será complicado. Puede hacerlo, especialmente si establece un solo maestro y requiere que todos los esclavos tengan restricciones de tiempo rígidas para el envío de datos, y que solo envíen datos si lo solicita el maestro, pero esto requerirá un esfuerzo considerable de su parte para diseñar el Tableros de interfaz para el maestro y los esclavos.

En cuanto a los controladores / receptores físicos, RS485 lo hará bien, y hay muchos chips de interfaz disponibles. Sólo Google.

No sé si está interesado en una solución prefabricada en lugar de construir su propio circuito, pero pensé que me gustaría señalar que Pololu vende estos I²C Extensor diferencial de larga distancia fabricados por SJTbits, que parecen hacer casi exactamente lo que está buscando. (Revelación completa: trabajo para Pololu).

Incluso si no quieres usarlo directamente, tal vez mirar el circuito que usa podría darte algunas ideas. Puedes ver el esquema en la hoja de datos; utiliza un búfer NXP PCA9600D, un controlador de línea diferencial TI AM26LS31CDR y un receptor de línea diferencial TI AM26LS32ACDR.

Sé que esto es un poco antiguo y una solución parece haberse resuelto en algún punto entre las respuestas, pero tuve esta sugerencia para ofrecer. Hay dispositivos como el PCA9614 / 5/6 de NXP que estoy analizando ahora como una solución para un bus I2C de larga distancia más robusto (PCA9614 búfer I2C-bus diferencial multipunto de modo rápido Plus de 2 canales) . Esencialmente, es cierto que se está convirtiendo en algo distinto de I2C verdadero, pero en los extremos del bus es invisible para los dispositivos. Esta familia en particular traduce las señales en 2 pares diferenciales bidireccionales, y también hay dispositivos similares que ya se han mencionado en los comentarios, que se traducen en 4 pares diferenciales unidireccionales. La conversión a solo 2 pares le permite usar el cable CAT y aún tener 2 pares para alimentación / tierra.

¡Pulgar hacia arriba! Actualmente estoy tratando de resolver casi el mismo problema. También estoy tratando de usar I2C sobre cat5 para la automatización del hogar con mi pinout personalizado. La razón es el costo, quiero que sea muy rentable y que los componentes de I2C aún sean al menos 5 veces más baratos que incluso attY13 uC (se requiere AFAIU uC para CAN y RS485).

1) Actualmente, estoy en un proceso de prueba para la primera parte de un sistema y ahora tengo éxito con un cable de 15 m de largo con 5 V y una conexión directa de SCL y SDA. Utilizo los relés PCF8574 y 2 para encender las luces de mi habitación. Pinout es

1
2 INT
3 +5V
4 SCL
5 SDA
6 GND
7
8

2) Entiendo que no se permitirán un par de relés más o 10 metros adicionales ... Una caída de voltaje es significativa (de 5.5 a 4.7). Así que para el problema de caída de voltaje, voy a poner 12V en una línea y agregaré reguladores de voltaje de 5V en las tarjetas para mantener el voltaje fino en todas partes, independientemente de la caída de toda la línea. Pondré fuentes de alimentación adicionales en las futuras líneas de todos modos.

3) La señal en sí misma puede mejorarse utilizando P82B96 o P82B715 barato sin dividirse en líneas diferenciales. Un NXP utiliza Cat5 en algunas presentaciones, pero no puedo encontrar su pinout. Una parte importante aquí es que claramente usan líneas de señal en diferentes pares ... por ej. un par es GND + SDA el otro es VCC + SCL.

4) Otro punto interesante: estos búferes pueden simplemente aumentar la amplitud hasta 12 V para aumentar la resistencia al ruido. Por lo tanto, probablemente intentaré poner 12V en una línea de señal y eso debería permitir poner un pullup directamente desde el cable de 12V ... Pero eso me obligará a poner algo como P82B96 en cada dispositivo.

Como se habrá dado cuenta, también utilizo una línea de interrupción separada ... Master está actualmente en la placa arduino conectada a la PC. El software principal primario estará en una PC 24x7 de todos modos, por lo que arduino simplemente traduce la señal y maneja la interrupción. Puedo enviar configuraciones específicas para el manejo de interrupciones a bordo, p. Ej. para manejar el interruptor de conmutación conveniente a través de la interrupción ... Eso me permite olvidarme de cualquier retraso al encender la luz manualmente. El manejo de interrupciones es una ventaja adicional de i2c.

Por lo tanto, mi idea es que I2C es lo suficientemente simple como para ser aplicable en el cableado de apartamentos de la ciudad de < = 100 m. En lugar de ir a la señal diferencial, espero poder reducir la frecuencia adicional en su lugar.

Me gusta su idea de poner 5V y 12V, ya que esto reduce la necesidad de los reguladores y reduce el costo ... la idea completa del bus de múltiples cables para reducir el costo de los puntos finales, también consideraré esto para el nuevo pinout: )