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):
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:
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.
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:
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.
Marca
Reinderien
Marca
Marca
Sam Gibson
Marca
Reinderien
Reinderien
Reinderien
Marca
Sam Gibson
Sam Gibson
Reinderien
Sam Gibson
Reinderien