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]

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.