SN65176 Contención RS485

Estoy transmitiendo RS485 a través de:

Aplicación mono -> Dispositivo Linux USBTTY -> Adaptador RS485 con un terminador 100R agregado -> ~1m CATV -> SN65176 con un terminador 100R agregado -> PIC.

A través de la depuración, puedo ver que la transmisión desde la aplicación al PIC es exitosa, y la transmisión del PIC desde su puerto serie también está bien. Sin embargo, cuando el SN65176 se cambia del modo de recepción al modo de manejo, el nivel bajo de salida es muy ruidoso (ver captura de alcance):

Imagen de alcance de las señales RS482

En esta captura de alcance, el canal 1 (azul) es el lado de datos (R/D) del SN65176, y el canal 2 (amarillo) está en el terminal RS485 cerca de la PC.

En este caso particular, el primer byte era de la PC (00001101) y el segundo byte era del PIC. Se suponía que era 00011101 pero se recibió como 00000100.

Aquí está el código de puerto Mono/C# relevante:

        port = new SerialPort(
            portName: portName,
            baudRate: 115200,
            parity: Parity.None,
            dataBits: 8,
            stopBits: StopBits.One)
        {
            Encoding = ASCIIEncoding.ASCII,
            Handshake = Handshake.RequestToSend,
            DtrEnable = false,
            RtsEnable = false,
            WriteTimeout = 1000 // ms
        };
        port.Open();
// ...
        Port.ReadByte()

El adaptador RS232 a 485 es un XS201A . Afirma tener un sesgo a prueba de fallas; sin embargo, la medición directa no respalda esta afirmación. Tal vez eso se deba a que el sesgo solo está habilitado cuando la unidad está encendida, pero no lo considero particularmente a prueba de fallas. No proporciona un esquema y es una unidad sellada, por lo que es más difícil aplicar ingeniería inversa a la cosa; sin embargo, cuando se conduce en presencia de una terminación externa de 100 ohmios en ambos extremos, veo los siguientes voltajes:

Va-Vb = 44mV
Va-gnd = 311mV
Vb-gnd = 267mV

El XS201A también afirma usar "Control automático de envío de datos", para ser alimentado por puerto desde RTS/DTR/TXD, y abreviar RTS+CTS y DTR+DSR+CT.

Con el SN65176 desconectado y una polarización ligeramente diferente, parece que el XS201A tiene una unidad de línea de 4 bits no documentada, después de lo cual el controlador se desactiva:

tiempo de espera de la unidad

Esto muestra dos 0x33 consecutivos desde la PC. Hay un bit de parada y de inicio que rodea a ambos bytes, más el tiempo de espera de la unidad final.

Me parece una contienda. ¿Está seguro de que el transmisor del lado de la PC está desactivado antes de que el PIC comience a transmitir? ¿Cómo se controla la señal de activación del transmisor de la PC? ¿Ha mirado los lados + y - del autobús y ambos muestran el problema?
Estoy bastante seguro de que los estados Z del lado PIC se implementan correctamente, pero no tanto del lado de la PC. Es un adaptador USB a UART y luego un adaptador UART a RS485. Voy a publicar mi código.
Parece una velocidad de transmisión de alrededor de 125k, pero no veo el bit de parada de la transmisión de la PC. Parece que el PIC está transmitiendo antes de que la PC termine. A partir de su código, parece que la habilitación de transmisión de la PC está controlada por RTS, pero tengo entendido que puede haber latencia antes de que caiga RTS, especialmente a través de USB.
Una cosa que podría ayudar: generalmente coloco resistencias de polarización en el bus, de modo que un bus de tres estados tenga un voltaje de aproximadamente 300 milivoltios por debajo de la línea central (alrededor de 2.2v con un bus de 5v). De esa manera, es obvio en un alcance cuando el autobús no está en marcha. Parece que su autobús siempre está en marcha, por lo que sospecho que los dos transmisores están superpuestos.
@Reinderien: estoy de acuerdo con Mark (+1), de esas formas de onda, su problema es la contención. Hay varios adaptadores RS-485 que se ajustan a la descripción que escribió, pero no todos funcionan de la misma manera, por ejemplo, algunos afirman tener "habilitación automática" del lado RS-485. Esos requieren tiempo después de que terminan de transmitir, para dejar de conducir el bus RS-485. Sugiero concentrarse solo en la transmisión de la PC (tx 1 byte, luego pausa de 5 segundos, repetición) y monitorear el bus durante esas pausas. Sospecho que encontrará que el bus RS-485 se activa activamente durante un tiempo de carácter adicional más largo que el byte transmitido en sí.
Sam tiene un buen punto: algunos RS-232->RS-485 esperan a que el transmisor esté inactivo antes de desactivar el controlador. Lleva algún tiempo detectar inactividad. ¿Cuál es el adaptador RS-485 que está utilizando? (@SamGibson)
El convertidor que estoy usando es este. usconverters.com/rs232-rs485-converter-xs201a
@Mark the biasing network es una buena idea, pero difícil en la práctica. Es un par diferencial que requiere una impedancia de terminación específica, por lo que la topología de polarización no sería solo una resistencia de terminación única.
Tal vez el sesgo de thevenin que se muestra en goo.gl/images/yY5BjW
Para ver un ejemplo de cómo termino, observe la figura 10 en la última página de este documento: usconverters.com/downloads/support/10waysrs485.pdf
@Reinderien: Mark ya ha dado muchos buenos consejos. Solo agregaré mi $ 0.02 re: "la red de polarización es [...] difícil en la práctica. Es un par diferencial que requiere una impedancia de terminación específica [...]" en mi humilde opinión para propósitos de prueba temporales, no le importa sobre la terminación tanto. Solo necesita sesgar las líneas +/- para que pueda ver en el osciloscopio cuando la PC las está impulsando activamente, o solo el voltaje de polarización de las resistencias. Luego ejecute la prueba solo para PC que sugerí para ver qué tan rápido la PC deja de conducir activamente el autobús, para confirmar el enfoque en el hardware de la PC.
Mirando su enlace al convertidor RS232-RS485, se destacan dos puntos (aunque no se proporciona un esquema para un análisis más detallado). Dicen que tiene "resistencias de polarización a prueba de fallas", por lo que eso puede afectar las decisiones sobre el voltaje de polarización y hacerlo obvio en el osciloscopio. Más importante aún, confirman mi sospecha: tiene "Control automático de envío de datos" - ¡bingo! La hoja de datos muestra que la señal RTS no se usa para el control de dirección, solo para la energía parásita del puerto RS232. Agregue un retraso de 1 s después de Tx desde la PC antes de que el PIC intente Tx, repita su prueba original e informe.
@Mark, ese artículo de "10 puntos" es realmente genial. A su vez, se refiere a AN-847 específicamente sobre polarización diferencial, que estoy leyendo ahora.
@Reinderien: gracias por los resultados de las pruebas en sus actualizaciones recientes. Eso confirma la disputa no intencional en el autobús. Escribí una respuesta para resumir mis puntos de vista y la vinculé a otro tema de EE.SE que es muy relevante. Felicitaciones a Mark por sus comentarios anteriores :-)
Mis nuevos problemas de RS485 están aquí: electronics.stackexchange.com/questions/246097/…

Respuestas (1)

Para resumir la discusión y responder a los resultados de su prueba:

parece que el XS201A tiene una unidad de línea de 4 bits no documentada, después de lo cual el controlador se desactiva

De acuerdo, ese comportamiento encaja con lo que he visto antes en algunos convertidores, y gracias por realizar la prueba.

Es probable que el convertidor RS232-RS485 controle activamente la línea después de la transmisión durante un tiempo relativamente fijo, en lugar de un número constante de bits, independientemente de la tasa de bits. Puede cambiar significativamente la velocidad de bits y volver a realizar la prueba para confirmar que el "tiempo de transmisión de la línea después del envío" sigue siendo similar a los ~35 us actuales. También puede encontrar que hay una variación en ese "tiempo controlado por línea después del envío" según el byte de datos que se envía, por lo que sugiero más pruebas con diferentes bytes para verificar eso.

Este fue otro tema reciente aquí en EE.SE (¿Cómo funciona este módulo RS485?) , donde un esquema parcial muestra el tipo de circuito que se puede usar para proporcionar el cambio "automático" entre enviar y recibir en RS-485. Sin embargo, esos no cambian inmediatamente cuando finaliza una transmisión, lo que lleva al tipo de comportamiento que ha observado.

Como yo lo veo, algunas opciones incluyen:

  • Agregue retrasos donde sea necesario en su código, para tener en cuenta el comportamiento de este convertidor (pero primero debe probar e intentar encontrar el "tiempo de conducción de línea después del envío" máximo), o;
  • Use un convertidor RS232-RS485 diferente que use la línea RTS para cambiar realmente entre Tx y Rx. Sin embargo, debe verificar que la señal RTS cambie en el momento correcto y no antes (lo que podría truncar el envío). Es posible que aún se necesite un pequeño "retraso de respuesta", especialmente si la distancia (es decir, la capacitancia del cable) entre los dispositivos es grande.

Es posible que desee buscar términos como "Retardo de respuesta RS-485" o "Retorno automático RS-485" para obtener más información y experiencias al multiplexar en el tiempo varios transmisores en buses RS-485 semidúplex.

Ya había comenzado a codificar el retraso antes de que lo sugiriera y, de hecho, eso resolvió la disputa que parecía ruido. Las señales entrantes y salientes ahora se ven bastante limpias... desafortunadamente, los datos entrantes todavía son completamente erróneos, por alguna razón. Voy a empezar una nueva pregunta para eso.
SN65176 Contención RS485
RespuestasAquíPolítica de privacidad1y, 0v