To summarise the discussion and respond to your test results:

it seems that the XS201A has an undocumented 4 bits of line drive after which the driver is disabled

Agreed, that behaviour fits with what I have seen before on some converters, and thanks for running the test.

It is likely to be a relatively fixed time that the line is actively driven after the transmission by that RS232-RS485 converter, rather than a constant number of bit times irrespective of bit rate. You could change the bit rate significantly and re-test to confirm that the "line driven time after sending" still remains similar to the current ~35 us. You might also find that there is a variation in that "line driven time after sending" depending on the data byte being sent, so I suggest more tests with different bytes to check that.

This was another recent topic here on EE.SE (How is this RS485 Module Working?), where a partial schematic shows the type of circuit which can be used to provide the "automatic" switching between send & receive on RS-485. However those do not switch immediately when a transmission finishes, leading to the sort of behaviour you have observed.

As I see it, some options include:

• Add delay(s) where needed in your code, to take account of the behaviour of this converter (but you need to test and try to find the maximum "line driven time after sending" first), or ;
• Use a different RS232-RS485 converter which uses the RTS line to actually switch between Tx and Rx. However you need to check that the RTS signal changes at the correct time and not early (which could truncate the sending). A small "turnaround delay" may still be needed, especially if the distance (i.e. cable capacitance) between devices is large.

You may want to research terms like "RS-485 turnaround delay" or "RS-485 auto-turnaround" for more information and experiences when time-multiplexing multiple transmitters on half-duplex RS-485 buses.

To summarise the discussion and respond to your test results:

it seems that the XS201A has an undocumented 4 bits of line drive after which the driver is disabled

Agreed, that behaviour fits with what I have seen before on some converters, and thanks for running the test.

It is likely to be a relatively fixed time that the line is actively driven after the transmission by that RS232-RS485 converter, rather than a constant number of bit times irrespective of bit rate. You could change the bit rate significantly and re-test to confirm that the "line driven time after sending" still remains similar to the current ~35 us. You might also find that there is a variation in that "line driven time after sending" depending on the data byte being sent, so I suggest more tests with different bytes to check that.

This was another recent topic here on EE.SE (How is this RS485 Module Working?), where a partial schematic shows the type of circuit which can be used to provide the "automatic" switching between send & receive on RS-485. However those do not switch immediately when a transmission finishes, leading to the sort of behaviour you have observed.

As I see it, some options include:

• Add delay(s) where needed in your code, to take account of the behaviour of this converter (but you need to test and try to find the maximum "line driven time after sending" first), or ;
• Use a different RS232-RS485 converter which uses the RTS line to actually switch between Tx and Rx. However you need to check that the RTS signal changes at the correct time and not early (which could truncate the sending). A small "turnaround delay" may still be needed, especially if the distance (i.e. cable capacitance) between devices is large.

You may want to research terms like "RS-485 turnaround delay" or "RS-485 auto-turnaround" for more information and experiences when time-multiplexing multiple transmitters on half-duplex RS-485 buses.