Details of my environment are in "==Firmware/Network details==" further below.

Problem: About 20% of the IR Commands that my TSU9400 sends were result in "Command Failed". The diagnostic screen says "0450 Extender 2 didn't reply". It seems that the "Command Failed" result mainly from IR commands, and much less so (or not at all) with RS-232 commands. It was strange that Nvidia Shield IR commands resulted in more Command Failed than Apple TV IR commands. EDIT: I checked the hex codes. The Nvidia Shield IR commands (uses Flirc) are maybe 10x longer than the Apple TV hex codes, which could explain why "Command Failed" was much more prevalent with Shield than Apple TV.

I have 3 RFX9600's, but I only need 1. I tried using the other 2 RFX9600's, but I was still getting "Command Failed" with them. So, I didn't bother trying to reload the firmware (doubt I have a need-to-reload-firmware issue given that all 3 get "Command Failed" errors).

Anyway, I remembered that a long time ago, I had changed the Cisco switch's port that my RFX9600 is plugged into from Auto-negotiate to be manually configured to 10Mb full duplex. I thought there was an auto-negotiation problem, since I didn't believe that the RFX9600 would be a half duplex device. But I found @Sogliphy's old post above that said that the RFX9600 is actually a half duplex device. I couldn't confirm this since none of the RFX9600 documentation says whether it's half or full duplex.

So, I changed my switch's port back to Auto-negotiate, and rebooted the RFX9600. It auto-negotiated to 10 Mbps, half duplex. But, I was still getting Command Failed. I left it as auto-negotiate. Then, I went to the Pronto software's "Configure Extenders" page, and explicitly checked "Use fixed IP address" and entered the RFX9600's address. I read in some other thread that explicitly specifying the IP address prevents the need to rely on multicast.

Anyway, after the two changes (auto-negotiate, and explicitly specifying the RFX9600's IP address), performance is much better. Now, only about 1% to 2% of IR commands sent result in "Command Failed" (down from 20% before I made these two changes).

So, I'll keep testing to see if "Command Failed" continues to be a relatively rare occurrence. I had rebooted the RFX9600, my Wi-Fi access point, and RFX9600, so I'll have to see as time goes on whether "Command Failed" will continue to be relatively rare.

I'm wondering if it's worth trying to other things to see if I can further decrease the possibility of "Command Failed" (although if it stays at or below 2% failure, it's still a big improvement from before):

1. Have my access point broadcast the SSID. Currently, the SSID is hidden. I hid it years ago as a false sense of security (only Pronto remotes use this SSID). I read in some other thread that hiding the SSID may increase problems when the Pronto first wakes up.

2. I still use RS-232 for a couple of my devices. Interestingly, it seems that I get Command Failed mostly (or maybe all the time?) with IR commands. RS-232 commands don't fail. So, I'm wondering if maybe I can get better performance if I continue to use my RFX9600 for RS-232, but use an RFX9400 (which I have in storage) for IR commands. There was another thread where someone was also getting Command Failed issues, and decided to use an RFX9400 for IR and IIRC they kept the RFX9600 for non-IR commands.


==== Firmware/Networking details =====

Network access point: 2.4 GHz, WEP, hidden SSID, b + g + n, Channel 11

RFX9600: Uses DHCP reservation

Pronto TSU9400 Network settings:
Wireless Timeout: Two Hours,
Channel 11, use DHCP reservation,
Encryption: WEP128 (using WPA too slow)

Pronto TSU Application version: 7.3.3
Pronto TSU IR firmware: 4.0.29

RFX9600 firmware: 1.4.8 (EDIT: I checked my old notes, and I did update to 1.4.8 beta. I also found my old posting from 2011: [Link: remotecentral.com] .