One of the little things that really annoy me when using tsu9200 is what seems to be extra delay between sending IR codes. Sure, in the component configuration you can set it to 0.1 seconds, but the reality is that the actual delay is longer than that. As a result, if you do multiple button presses in a quick succession, some codes will simply be swallowed by the remote and never be sent.

I was hoping that it was just a shortcoming of the tsu9200 hardware/software and with the 9300 I would have better control over it. However, to my disappointment, 9300 has exactly the same behavior. Ultimately, it makes it impractical, say, to program the wheel to send skip/replay when watching recorded TV. In my particular case, the DVR device (Media Center PC) has plenty of bandwidth to process the skip/replay commands considerably faster - which is apparent when using the original remote, let alone the kbd/mouse - however, the much more sophisticated panel is nowhere near.

Is there another configuration option (in addition to the delay in the device configuration) that I am missing to reduce the system delay between the key pressed?

Thanks!

How about posting the IR code data of one of the codes you are having issues with or is it all brands?

If you understand the format of the IR code (See Barry Gordon's Pronto Hex IR Format doc in the User Documentation subsection of Classic Pronto Files Forum) you might be able to "tweak" the code to cut down on the time the IR is sent.

As far as I can tell, it's device independent: at least the TV (a recent Panasonic Plasma), the receivers (Denon 2809, Marantz NR1601, Panasonic SA-XR700) and the Media Center (the standard Microsoft Vista IR receiver/blaster) that I tried all behave similarly when controlled from 9300 - the said delay is quite noticeable. And since the delay can easily be observed with the standard Pronto database codes, I am assuming that the codes are fine - after all most of the actual Pronto devices do use the same IR database.

BTW, is there a simple way to extract the hex codes from the standard database without re-learning them? The component function editor simply shows 'DATABASE' instead of the actual hex sequence.

If it says "DATABASE" then it is an encrypted code that cannot easily be translated into Pronto Hex.

There are tools in the files section to extract things from the database but in this case, I don't think these will help.

I've managed to find a workaround - in the component database for each particular command there is another timing parameter: duration. By default it says, no surprise here, - 'Default'. However, it is possible to use a specific numeric value. I set the value to 0.1 sec for some commands and - voilà! – the annoying delay for those was gone.

I find it weird, that no one else is annoyed by this. I can hardly believe that it somehow is specific to my particular panel nor do I think that my expectations of the responsiveness of the remote are unreasonable.

Anyway, in the PEP2 help there is only one article with the ‘duration’, which is exactly about the component function editor form. However, I could not find in the help how to change the default value for it. An obvious guess – the delay in the component properties, did not actually work as expected.

The Philips database codes, although they have been around for a while were provided to them by a 3rd party and on certain occasions, I have found them to be unreliable or just plain "clunky", esepcially the Denon or Escient codes.

If you are going to use database codes and you are using someone else's codes, I strongly recommend using the Only One Remote (O1R) database as these codes are "clean" and tested and work very well. I have provided codes for them on various occasions and have also used their codesets on occasion.

Typically, I use MakeHex to gen my own codes as early on, I found Philips DB to be unreliable. With the advent of PEPv2, I simply migrated my learned/generated clean codes into My Database as I knew they worked quite well.

I understand that this does not work for all users but if you already have codes in a CCF, PCF. or XCF and they are "clean" (see the Classic Pronto FAQ for what is a clean code), I'd recommend using those or the O1R database over the Philips DB.

OK, understood. Although somewhat unexpected: one patricular component that misbehaved - Panasonic Plasma - is exactly from Only One Remote. Or, at least, so it says the 'Owner' in the component properties.

Thanks!

Interesting... You might let Dave and Stan know.