hi,

i have a tsu 9600 connected to a netgear wireless wg102 ap. the access point is connected to a linux based router, the router connects a rfx9400, all running the latest firmware.

the problem i have is that if i don't use the remote for a longer period - say a few minutes - the first keypress gets lost somwhere in the air. the diagnostics writes something about extender not responding, but i can see the extender responding to the transmission if i tcpdump the according interfaces. after the first keypress everything works fine till i leave the remote untouched for another few minutes.

i tried static and dhcp configuration on the remote as on the extender. the behaviour does not change.

the setup involves different wlan security profiles on the access point which seperate to complete different wlan networks by vlans. i did this to have a strong encryption for my normal wlan while having that weak wep thing for the pronto. the router firewalls the vlan for the pronto completely except for the communication with the extender.

my question is now: how do i get the remote to react on the first keypress. is it a common thing that the first keypress gets lost or is there some proven ground that my setup is just to complicated for the remote to handle. i know about the incompatibility issues around the netgear devices, but i don't see any problem since the communication works, just not at the beginning.

thanks in advance,

frank

I don't fully follow what you are saying but speaking from TCP/IP experience on the Pronto.

You may not be able to get the remote to recognize first keypress without changes to your code, possibly involving the use of ProntoScript. EscientPronto works because I have a command queue that operates independently from the actual communication channel (socket).

Doing something like this in ProntoScript takes lots of work and full understanding of Javascript and ProntoScript extensions.

fen,

From your description, I'm not sure what sort of problem you are having.

If the TSU-9600 has gone into sleep mode, the first key press will wake the unit, but it will not have had enough time to reconnect with the network.

Try shaking the unit to wake it, then wait for the connection to be established before pressing a command key.

buzz,

what you describe is exactly the problem.. is there any solution to it? this is some kind of an internal firmware problem. the remote should wait to send or at least retry to send the command to the extender until the wifi connection is up again after sleepmode.

i'm aware that there's maybe a solution via pronto script, but i don't want to put up the effort to redesign every button to be handled through pronto script instead of the action lists.

i think this is a bug and it should be addressed since it is a little bit anoying to shake the control and wait a little before pressing the buttons.

will this work better if i connect the pronto directly to the wifi of the extender? or may be the problem still persist then.. i didn't try this, because there's that security issue with wep and not having wpa2..

First, assigning a static IP speeds up reconnect times.

Second, you can set a longer time out period at system properties - say one or two hours. Then this "issue" isn't that obvious and doesn't occur that often.

Holding back the transmission until a connection is restored will come up with some undesired effects. If you are not patient enough you will switch on and off your receiver etc.
But as usual, there are always pros and cons. Personally I like it the way it is.

I agree with Chris: static IP
My time out period is 24 hours. So I never loose the connection and I have direct access. The battery power of TSU9600 is working for one day and good enough with this setup.

i already tried several setups and i've been on a static ip before, but tried the dynamic ip to just try something different. the effect was not really notable - regardless of the ip setting. i have the timeout set to one hour i think - no noteable difference. i will assign now the static ip back to the unit and set the timeout to 24 hours. maybe this helps.

the anoying thing is that if you lay the remote on the table and just want to modify the volume with the hard buttons. then it takes a few tries till it works. since i don't pick the remote up it does not wake up. i hope the settings will fix the problem. we'll see.

the other possibility is to solve this through prontoscript, but as i mentioned earlier i'm not happy fixing something which should work by default. well.. if i have to i'll do.

i set the static ip and turned the wifi to 24h and updated to the latest firmware. still no improvement.

From my understanding there is no sleep modus, if the time out period is 24 hours.
This means continous wifi contact, no time delay.
My system is working with this configuration:
TSU 9600 to router (wifi with WEP128)
router to RFX9400 by LAN RJ45

I tried using a fixed IP address for a while, but I did not notice any practical improvement. If there are multiple remotes in the system using fixed IP addresses is a pain because I install the same program in each unit and, with the fixed IP address, I must go to the trouble of individually managing the IP address of each unit.

If you have fixed Ips you have control of your network.
You can easily check with dos command "ping" if your setup is working.
With fixed Ip´s you have higher security because you can eliminate/refuse/reject not used Ips from your network.

If you don´t need security you can following your comfort idea; why not.