Hey everyone:

Once again, I need some expert advice regarding a problem I am having with a TSU/RFX9600. There are two:

1. Occasionally, the RFX does not receive the signal from the Pronto. I am using WIFI, which obviously is the problem. Now, the WAP/Router is located with the equipment under the TV in the entertainment center. My theory is that the WAP is too close or not positioned correctly. My question: Is there some sort of standard regarding location for the WAP in respective to the TSU. I can relocate the WAP in the ceiling if anyone thinks this might help.

2. Occasionally, the WAP receives signal, sends it to the RFX and the RFX reports busy for almost 10-15 seconds. Now, all of my durations are standard .10 seconds, and macros are not being uses in these instances. A simple channel up for the Cable box is causing the RFX to hold for this time frame. Is this the RFX or the WIFI again?

FYI: I have updated both the TSU and RFX with the latest firmware. Also, everything worked fine for me upon initial install. However, I did notice that if I tried to use the remote within 2-3 feet from the equipment area that nothing would happen. Again, leading me to believe that there is a dead spot between the WAP and the TSU.

One more theory is that it could also be possible that my customer is using the remote too quickly, causing it to jam. He tried rebooting and that did nothing.

Finally, will turning the WAP 90 degrees make any difference, or should I just concentrate on relocating it.

One final note: There is another Wireless Network in the house for their computers. Could I be receiving interference from that network? There is no internet access for the Pronto's network.

Thanks again.

Joe

It sounds as though you are using two seperate wi-fi networks; one for PC and the other for Pronto to RFX9600. If this is the case it is important to select two wi-fi channels that do not interfere with each other. The best channels to try are 1, 6 or 11.

Thanks. As of right now, I believe they are both set to auto which could be the problem. I will try it out on Monday.

Joe

Depending on the brand of WIFI Router and the protocol (802.11b/g/n) that you are using, it is very possible to end up with 'dark spots'. Adjusting the antenna position will usually cure the problem if it is a simple signal problem (vertical / horizontal positions). Also if you want to dump out some extra bucks, you could also change the antenna on the router for a high gain antenna. D-Link makes one for about $35.00. PS... although I have seen some WAP conflicts when channel is on auto scan, this is usually pretty rare: In general it's a first to the post for channel selection, and if the second place finisher tries to use the channel allocated to the first place finisher, it should detect the other WIFI device's info and choose another channel. Also on conflict the WIFI access point should re-scan for an available channel. If both WIFI networks have the same SSID, that might cause a seriously weird result!

Is your router's wireless protocol 802.11b or g. I sincerely hope it's not an 'n' class wifi device as I don't believe the Pronto TSU's support 'n'. If it is a 'b' class wifi device it will be running rather slowly as 802.11b has a tiny transfer rate. 802.11g rips along at 54mbps (although that's its 'rated' speed).

Thanks again for the help. The Router is an N, but I don't think it is set to just N. Probably mixed. The only device on the router/WAP is the Pronto. I will try configuring it so it is just N.

The SSID are not the same. I will also try fixing the channel.

One more note: The signal jumps from full strength to almost nothing. My pronto I use as a demo does not do that. I am running a Linksys at the house. Would interference be the cause for the weird behavior? Just a thought.

I am also going to bring my demo TSU/RFX 9600 to make sure it is not equipment related.

Thanks again for the insight.

Joe

I have installed 94/9600's in large homes with multiple access points. I set all of the access points to the same SSID and tinker with the channel assignments to avoid overlapping coverage areas on the same channel as much as possible.

Computers travel seamlessly throughout the house. The Pronto's have more limited range and hang on to their access point longer than they should. While there are no dead areas for the computers, the Prontos have dead spots and they are slow at releasing the former access point and picking up a better signal.

Also, the Pronto's are slow at connecting after waking from a sleep. I find that technology shy customers who press buttons slowly have less trouble than the savvy, quick ones. I encourage the quick ones to wait till the connection is completed before issuing commands. If they issue commands too soon, they'll run into "command failed", which causes a delay, but they'll follow up with another command too soon, the follow-on command may not work either, and the frustration level builds. After they learn to pace their button pressing, everything is fine.

With RS-232 based components I use ProntoScript and a command stack. On these units, once the WiFi connection is established, it is not possible for the user to press buttons fast enough to overrun the program. It is an interesting interaction because several seconds might elapse before the device catches up with the command stack. One could use a similar approach for IR based commands, but this requires more effort than I can justify for the rather limited benefits.

Ok. Fixed it this morning. I set the D-Link Router/WAP to G only, I activated the range booster and as a result the router automatically set the channel to 6. I left the Linksys alone that runs his computers. All seems well. The indicator still jumps around a little, but the remote seems to be working just fine.

Thanks for the help.

Joe

Buzz, because of the button press issues you describe all my Pronto applications handle the buttons (soft and hard) in the same manner.

They make a Queue entry in a FIFO stack. I can then control the execution of the associated command (IR, TCPIP, RS232, etc.) based upon system state.

All my applications run a page loop (the same loop for every page with the loop code at the activity level). The page loop looks at the user queue only when approriate, but the user never looses a keyin and if things get too busy I can put up a wait/busy message util I bring the queue down to a manageble size..

Well, my customer called. It's not fixed. I spoke with Philips and they told me to switch out the RFX first. If that doesn't work, then try the TSU. I am also going to change the settings on the Linksys to Channel 1, if it lets me, to see if that fixes my problem.

I'll keep you guys informed.

Thanks.

Joe

I got another call. Even with the new extender the system is locking up. Sometimes for just a few seconds, sometimes up to 20-30 seconds. Could it be the router/WAP? The remote seems to be fine and although the WIFI meter moves up and down, it does not show no WIFI signal.

My next step would be to change out the remote and maybe the router/WAP. I guess it could still be interference with the Linksys, but I checked the settings and the Linksys is running on a different channel then the D-Link.

Any information would be great.

Thanks.

Joe

New update. The problem seems to be resolved. I think it was that D-Link Router/WAP. I exchanged it out with a new Linksys and the problem seems to be gone. It still might have also been the extender, but most likely not.

Thanks.

Joe

I am having the same issue, the only difference is that the extender seems to be receiving the commands but it doesn't pass them on to the IR ports. The only way to resolve the issue is having to reset the RFX9600 by pulling out the power.

Any thoughts on what might be causing this issue?

By the way, it happens only after using the remote for while and especially watching recorded shows and having to scan forward or reverse to skip commercials, etc...

I appreciate any thoughts on this.

Thanks!

I too have the exact same problem as Kypros with my RFX9600. On a random basis the IR ports lock up and are only cleared by a power cycle to the extender. It appears to be triggered when frequent, closely spaced IR commands are sent such as paging through the cable TV menu pages. The command is received at the RFX9600 but not passed on to the IR ports.

Firmware is 1.1.36, have switched IR ports with same result.

Anyone else experience this problem?

Any thoughts on a fix?

Thanks,
Jerry

This is complete pie in the sky on my part: Kypros / Jerry are either of you doing any RS232 comms over the RFX9600? If you are doing some two way comms, I'm wondering if your Pronto is not clearing the buffer on the RFX with a receive() command or variant thereof. Basically it sounds like you're getting a buffer overrun.

Thanks for the response GuerillaBuild. I am controlling a TV via RS232 for PWR on and off; and a Denon AV processor which does a PWR on, and INPUT on start up and VOLUME UP/DWN. When the IR locks the RS232 does still work. If it is a buffer overrun, sounds like a firmware issue that I would expect more people to experience.

Does anyone know of a way to issue a command (pronto script?) to flush the buffer to test this theory?

Thanks again to all...
Jerry