Electronic – RS485 multidrop to UART

rs485uart

I'm trying to do a multi-drop setup where I have two RS485 devices(with MAX13430) daisy chained without termination resistors(for now) as they're pretty close(few cm apart) and at pretty low speed (9600 baud). I bought a generic RS485 to UART converter off of Amazon and I'm trying to talk to each of these devices from my PC.

I send a polling command consisting of an 'address' (similar to modbus) and some payload, then wait for some time to get a response and then cycle to the next 'address'. Each of the two devices respond to a different 'address', so they do not respond to the same command.

Now, things are working fine when I talk to each device independently, but when I try to talk to both, I see communication errors. So, my question is:

Whether the RS485-UART interface is a valid approach to test multi-drop connections or is a potential source of trouble?
Or is this just software going wrong?
Schematic of uart to rs485 chip on the slave devices –
enter image description here

I send a two byte header followed by a unique address that only one slave responds to. Not entirely sure what is going wrong but it looks like only one device is able to respond even when both are connected, the other device receives the poll packet intermittently

Best Answer

If both devices respond at approximately the same time then you’ll have a collision and can expect data errors. For RS485 you should make sure that only one device is transmitting at a time, so either poll the devices individually or add delays so that each device responds in its own ‘time slot’. At 9600 baud the data rate is about 1000 bytes per second, so if your acknowledgement is a few bytes long you might be ok with time slots of a few tens of milliseconds. Of course, you’ll need some way to ensure that each device has a different delay before sending its acknowledgement. Also with RS485 be aware (and you may well have identified this already) that the transmitter needs to be left active until the stop bit has been sent at the end of the last byte in the packet - many UARTs don’t have a way to determine this and you may have to resort to using a seperate timer.