Your Universal Remote Control Center
RemoteCentral.com
Philips Pronto Professional Forum - View Post
Previous section Next section Previous page Next page Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Page 1 of 2
Topic:
Ip Connection Woes
This thread has 17 replies. Displaying posts 1 through 15.
Post 1 made on Wednesday February 8, 2012 at 01:00
ClubChapin
Long Time Member
Joined:
Posts:
September 2008
14
I've got both a TSU9600 and TSU9400 that I recently set up to use a RFX9600.

This works well sort of.

The issue that I am having is that when they are set down for even a short length of time (2 mins maybe?) they lose the wifi connection and are not able to send commands over wifi, resulting in a command failed message. This is pretty unacceptable; basically the prontos are not usable for the first 15 or so seconds after being picked up.

I've got the network timeout set to one hour. I would expect that the wifi connection would be maintained for this duration, but tneither the 9600 or the 9400 are able to stay connected.

Is there a setting that I am missing that will enable these things to be usable upon being picked up? Why doesn't the wifi stay connected for the hour that it is set to?

I've got it set to roaming strategy "Single Access Point" and WiFi channel Automatic. Is there a preferred setting for the wifi advanced settings? My WAP is an Apple Airport.

Thanks, Pete
Post 2 made on Wednesday February 8, 2012 at 01:05
gopronto
Senior Member
Joined:
Posts:
April 2008
1,385
Dont use the air port buy your self an access point and use that instead , you will have far less issues.
Pronto still one of the best Wi-Fi Remotes,
www.ikonavs.co.nz and [Link: prontoprojects.com] Axium Control catching up fast :)
OP | Post 3 made on Wednesday February 8, 2012 at 11:16
ClubChapin
Long Time Member
Joined:
Posts:
September 2008
14
What about the Airport is not good? It replaced a Linksys wap and in all ways performs better, both for my IOS devices and my Win machines. It is operating in WAP only mode, not as a router. The Linksys had connection issues with my wireless devices, the airport does not. I've got to believe that this would be true with the Pronto as well. I do not see where the Airport is less ocnfigurable or powerful than a stand alone wap.
Post 4 made on Wednesday February 8, 2012 at 13:27
gopronto
Senior Member
Joined:
Posts:
April 2008
1,385
there has been a number of reported issues using Airports with non apple devices.. so the cure has been to fit a WAP.
Pronto still one of the best Wi-Fi Remotes,
www.ikonavs.co.nz and [Link: prontoprojects.com] Axium Control catching up fast :)
Post 5 made on Wednesday February 8, 2012 at 16:41
joZ
Long Time Member
Joined:
Posts:
September 2008
33
I'm just shooting from the hip here, never had to deal with an airport, but I guess it has some kind of encryption method just like a router?
If you're use WPA or stronger:
Last time I tried (a few firmwares ago) the remotes got so sluggish that I changed back to WEP, maybe not an option for you, but it could be worth a test just to see if it works better on WEP.



/joZ
Post 6 made on Wednesday February 8, 2012 at 18:31
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
11,899
The RFX9600 utilizes the UDP protocol and there are known issues with UDP on Airports. I've seen this documented by other control vendors as well.

There is a secondary issue regarding security and the scheme you are using. WPA requires longer negotiation period for connection. So, the fact that you are using WPA coupled with Airport could be cause of many of your issues. Drop in a Linksys/Cisco/PakEdge WAP and run as WEP. That will likely correct many of your issues.

Lyndel
Lyndel McGee
Philips Pronto Addict/Beta Tester
OP | Post 7 made on Wednesday February 8, 2012 at 20:52
ClubChapin
Long Time Member
Joined:
Posts:
September 2008
14
Thanks. I have read about WEP vs WPA. I prefer to stick with WPA.

The issue doesn't seem like a UDP from the RFX. It does seem to be all in the speed of the TSU connecting to the wap.

What I don't understand is that when I set the timeout for 1 hour, why doesn't it stay connected for 1 hour? I get how WEP negotiates faster than WPA, but it shouldn't have to negotiate before the timeout.
Post 8 made on Thursday February 9, 2012 at 08:44
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
11,899
That "Command Failed" message you are getting is because TSU cannot communicate with RFX. Could be due to TCP not ready or due to the fact that you have dropped packets in Airport.

If the unit is left on a table, screen goes dark and it goes to sleep. About every 55 seconds, it wakes up to keep the wifi connection alive. I can attest to this for WEP however, I cannot answer for WPA. I suspect that the WPA negotiation sequence is a bit longer.

One solution you have is to return the unit to the dock (or buy an extra dock and power supply from www.servicewidetech.com) such that the screen will go dark but wifi will stay connected.
Lyndel McGee
Philips Pronto Addict/Beta Tester
OP | Post 9 made on Thursday February 9, 2012 at 21:25
ClubChapin
Long Time Member
Joined:
Posts:
September 2008
14
Thanks. It seems that when I pick it up with a dark screen that is when it can't connect. And, when I can't connect, the wifi indicator has a red "x" on it, indicating no connection. It re-establishes one 10 or so seconds after being picked up. It would be nice if it could just stay connected.

One thing I will do is set up a constant ping and see how it is behaving from the network side.

It just seems that if I set it to stay connected for 1 hour, it should be able to do this and not drop the connection or need to reconnect every 55 secs. It seems like a poor implementation on Philips part that could be fixed with firmware, but, of course, will not be.

I may just go back to IR. Right now, I am just using Ir anyway. My extenders are in place. Just one of them is not well situated.

Thanks, Pete
Post 10 made on Thursday February 9, 2012 at 21:35
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
11,899
To conserve the battery, when the unit is not docked and goes to sleep, the entire CPU shuts down and gets awakened every 50-60 seconds if wifi keepalive is required.

If you leave the unit docked, when screen goes off, wifi stays connected and is always ready to go as the CPU does not go to sleep when there is constant power.
Lyndel McGee
Philips Pronto Addict/Beta Tester
OP | Post 11 made on Thursday February 9, 2012 at 22:05
ClubChapin
Long Time Member
Joined:
Posts:
September 2008
14
Thanks. That's not how I'd like it to perform, but I will figure out how to live with it. Other than this, this is a fantastic device.

I'd expect it to stay connected and pingable for an hour if that is how it is set. Seems like it's behavior is how it should act after the "Stay Connected" duration has passed.

I did find that there is a direct correlation to it being pingable and the back light being on. Also, a direct correlation to it being pingable and commands succeeding.

One idea I came up with is to let the screen turn off after 20 secs and keep the key backlight on for it's longest duration (240 secs). I set this in PEP and it did not take on the panel. I then tried to set it on the panel and it will not set. It forces me to have the key backight timeout be <= screen timeout. Why is this? I have the latest firmware. Not sure why it lets me set this in PEP when apparently the device doesn't support this.

Minor annoyances at this point really.

Are there any preferred settings for advanced wifi setting? Roaming and scan strategies?

If I choose to operate IR only, without the RFX, should I delete the RFX from my CCF, or can it stay.

Thanks again, Pete
Post 12 made on Friday February 10, 2012 at 00:08
Guy Palmer
Active Member
Joined:
Posts:
June 2008
647
I agree with both Joz and Lyndel: your basic problem is that you are using WPA rather than WEP - as per lots of other threads, WPA and the Prontos don't really go well together (and, until recently, didn't go at all together)
Post 13 made on Friday February 10, 2012 at 08:53
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
11,899
If the RFX is selected in a project, the remote may send a discover via UDP to find the extenders, even though they are not needed.
Lyndel McGee
Philips Pronto Addict/Beta Tester
OP | Post 14 made on Saturday February 11, 2012 at 15:12
ClubChapin
Long Time Member
Joined:
Posts:
September 2008
14
Thanks. It's too bad the WPA doesn't work better. I'm not going to set my network to wep.

I presume there is 0% chance of Philips ever fixing this.

One of my rooms I've reverted to IR and have removed the RFX from this remote.

I'll need to decide how to handle 232 and more complex operations. This may get outsourced to homeseer.
Post 15 made on Saturday February 11, 2012 at 20:12
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
11,899
you can setup a WEP and do MAC address filtering. this has been discussed here before.
Lyndel McGee
Philips Pronto Addict/Beta Tester
Page 1 of 2


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse