On XLR2 is anyone seeing that RTS output deasserts when CTS deasserts

[Mahendra Tailor]

On the XLR2 chipset I am seeing that if the RTS output follows the state of the CTS input. When I load the same firmware in a XLR then RTS does not follow CTS

[RK]

This reminds me of this question devzone.nordicsemi.com/.../ from earlier this year which I didn't understand the answer to and didn't make sense to me.

That question was the other way around and was about the nrf raising the RTS line when the other side raised its RTS (connected to the nrf's CTS), but it seems like the same effect, one line follows the other.

As I said I didn't understand that answer at the time, the two signals should be entirely independent. it's quite possible to have one side ready to receive (thus holding its RTS line low) while the other side is not ready to receive (holding its RTS line high) and data could continue to flow in one direction forever. Just because the thing I'm connected to says it doesn't want to receive any more data, I don't see why that would mean I raise my RTS line and stop it sending.

Does this look like the same issue or am I just even more confused than I was in January?

[Mahendra Tailor]

Hi RK From your description, it is the same issue given RTS is connected to other's CTS and vice versa. Basically you are saying "about the nrf raising the RTS line when the other side raised its RTS (connected to the nrf's CTS)"

[MartinBL]

Hi. For future readers who might be interested in this case the conclusive, although vague, answer to this is: yes, the hardware guys confirm that in XLR2 the RTS output does follow the state of CTS. This behaviour is different from both XLR and XLR3, but is to be expected. The behaviour is not documented anywhere and sadly no one seems to remember the reason for the inconsistencies.

[Mahendra Tailor]

Thank you for the confirmation. We will be advising our customers that they should try to refrain deaserting their RTS as much as possible and expect that if they deassert RTS to stop the peer sending them data, then the XLR2 is also going to do the same and thus prevent you from sending data as well and thus reach a no-traffic either way scenario.

Important to understand the behaviour is fixed for XLR3.