Envío de I2C de forma fiable a través de cables Cat5

Tratar de hacerlo 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 bajar una línea 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 instalan cables sin blindaje en las paredes, posiblemente justo al lado de los cables de alimentación de CA.

Yo usaría CAN para esto. CAN usa un solo par trenzado unido con solo 60 Ω en cualquier punto, y la señal es diferencial. Eso significa que los receptores pueden cancelar la mayor parte del inevitable ruido de modo común que se captará debido al acoplamiento capacitivo. CAN corriendo a 500 kbits/s puede cubrir algo del tamaño de una casa ordinaria.

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

No se deje engañar por RS-485. Esa es una reliquia de una época pasada. También utiliza una señal diferencial única como CAN, por lo que también tiene una buena inmunidad al ruido. Sin embargo, la gente suele enamorarse de RS-485 porque parece "más simple". Esto es solo porque no miran todo el sistema. Primero, no es realmente menos complejo eléctricamente. Aún necesitará algún tipo de transceptor para conducir y recibir la señal diferencial. Ya sea que tenga un transceptor RS-485 conectado al UART del microcontrolador o un MCP2551 conectado al periférico CAN es bastante irrelevante en términos de costo y complejidad del hardware. La gran diferencia es que RS-485 lo deja en el nivel de byte sin procesar (a través de UART). Esto significa que para implementar cualquier sistema significativo y robusto, debe inventar su propio protocolo para manejar la detección de colisiones, decida cómo manejar los reintentos, la paquetización, la generación y verificación de la suma de verificación, el control de flujo, etc. Puede usar una única arquitectura maestra, pero obtener los detalles correctos es mucho más complicado de lo que la gente piensa que no los ha analizado todos cuidadosamente. Con CAN, solo envía y recibe paquetes, y el hardware se encarga de los detalles.

I2C no es el camino a seguir. Los transceptores CAN cuestan un dólar cada uno, y puede usarlos como transceptores uart y escribir su propio protocolo para que no necesite un micro compatible con latas si no desea usar la pila completa de latas.

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

La forma segura de hacerlo es tener un polifusible en ambos rieles de alimentación y unir las tierras en el suministro, y conectar cada dispositivo a un solo 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 que una línea se vea obligada a transportar la energía de dos.

A mucha gente le gusta poner energía y tierra en ambos pares trenzados por razones de EMI en lugar de tener un par de energía y un par de tierra. Si tiene dos pares de alimentación/tierra, la línea de alimentación estará más cerca de tierra y los campos se cancelarán, lo que reducirá las ondas de radio transmitidas o recibidas de las líneas de alimentación. Innecesario, pero agradable si hay mucho ruido eléctrico zumbando.

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

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

• Mantener todos los "cerebros" en un solo lugar. Use expansores de E/S I2C si es necesario, pero manténgalos todos con la frambuesa pi. También necesitará el hardware apropiado para asegurarse de que no está tratando de obtener demasiada corriente de los pines GPIO de la pi.
• Use los cables de ethernet para simplemente controlar los relés. Puede construir su propia placa u obtener relés de estado sólido de 120/240 V montables en panel que se montarán en una caja eléctrica. Los hilos de los cables Ethernet Cat5 pueden manejar hasta 50 V a 320 mA cada uno, lo que es más que suficiente para controlar un relé. De hecho, podría controlar 7 relés desde un solo cable (más un cable para conexión a tierra). O deje un cable para una salida de 12 V sin interruptor, para que también pueda instalar un interruptor manual. Si son carreras realmente largas, 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 caída de voltaje.
• También querrá consultar los códigos de construcción locales para obtener consejos sobre cómo mezclar cables de alto y bajo voltaje en la misma caja.
• Los interruptores simples también se pueden hacer a través de los cables de ethernet, nuevamente hasta 7 por cable, y simplemente se conectan a las entradas de la pi. La caída de voltaje puede ser una preocupación para cables realmente largos.
• También es posible que desee utilizar 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 gran gasto si no hay muchos de estos dispositivos. Podrían ser otro pi o un microcontrolador con ethernet.

^{simular este circuito : esquema creado con CircuitLab}

¡EUREKA! ¡Lo averigué! (no probado, lo probaré este fin de semana)

Los chips de interfaz son el búfer/divisor NXP P82B96 I2C y 2 chips de interfaz de bus CAN TI SN65HVD251P. 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 se pueden unir. 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 será muy difícil. El problema es el arbitraje de autobuses. Aunque se pueden conectar en paralelo varias unidades usando, por ejemplo, RS485, la gran pregunta será:

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

En IIC, con líneas de señal de drenaje abierto, la transferencia bidireccional es fácil, pero con los buses tri-state 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 enviar datos, y que solo envíen datos si el maestro lo solicita, pero esto requerirá un esfuerzo considerable de su parte en el diseño del tarjetas de interfaz para el maestro y los esclavos.

En cuanto a los controladores/receptores físicos, RS485 le irá bien y hay muchos chips de interfaz disponibles. Solo Google.

No sé si está interesado en una solución prefabricada en lugar de construir su propio circuito, pero pensé en señalar que Pololu vende estas placas extensoras diferenciales de larga distancia I²C fabricadas por SJTbits, que parecen hacer casi exactamente Que estas buscando. (Divulgación completa: trabajo para Pololu).

Incluso si no desea usarlo directamente, tal vez mirar el circuito que usa podría darle algunas ideas. Puede 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 parece que se ha encontrado una solución en algún lugar entre las respuestas, pero tenía esta sugerencia para ofrecer. Hay dispositivos como el PCA9614/5/6 de NXP que estoy considerando en este momento como una solución para un bus I2C de larga distancia más sólido (búfer de bus I2C diferencial PCA9614 de 2 canales multipunto de modo rápido Plus) . Esencialmente, es cierto que se está convirtiendo en algo más que el verdadero I2C, 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, como ya se mencionó en los comentarios, que se traducen en 4 pares diferenciales unidireccionales. Traducir a solo 2 pares le permite usar un cable CAT y aún tener 2 pares para alimentación/tierra.

¡Pulgares hacia arriba! Actualmente estoy tratando de resolver más o menos 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 I2C sean al menos 5 veces más baratos que incluso attiny13 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 conexión directa SCL y SDA! Uso PCF8574 y 2 relés para activar 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 va a permitir un par de relés más o 10 metros extra... Una caída de tensión es significativa (de 5,5 a 4,7). Entonces, para el problema de la caída de voltaje, voy a poner 12 V en una línea y agregar reguladores de voltaje de 5 V en las placas para mantener un voltaje fino en todas partes, independientemente de la caída de toda la línea. Pondré fuentes de alimentación adicionales durante las líneas futuras de todos modos.

3) La señal en sí se puede mejorar usando P82B96 o P82B715 barato sin dividirse en líneas diferenciales. Un NXP en sí usa 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 ejemplo, un par es GND+SDA y el otro es VCC+SCL.

4) Otro punto interesante: estos amortiguadores pueden simplemente elevar una amplitud hasta 12 V para aumentar la resistencia al ruido. Entonces, probablemente intentaré poner 12V en las líneas de señal también y eso debería permitir poner pullups directamente desde un cable de 12V... Pero eso me obligará a poner algo como P82B96 en cada dispositivo.

Como habrás notado, también uso una línea de interrupción separada... El maestro está actualmente en una placa arduino conectada a la PC. El software maestro principal estará en una PC 24x7 de todos modos, por lo que arduino solo traduce la señal y maneja la interrupción. Puedo enviar una configuración específica para el manejo de interrupciones a bordo, por ejemplo, para manejar el cambio de interruptor conveniente a través de la interrupción... Eso me permite olvidarme de cualquier retraso al cambiar la luz manualmente. El manejo de interrupciones es una ventaja adicional de i2c.

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

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