Problem learning some IR codes
bob
Posts: 296
Hi there
I am facing a real problem when trying to learn some of the IR codes from a particular remote.
I am using a pronto and prontoedit to learn the IR codes from the original remote and then cut-and-paste these codes as Discrete IR Hex Codes straight into IREdit. Particular I can not learn the left/right/down/up arrow keys. When learned they do not go one item up or down but several which drives me nutts. I have tried SEND_COMMAND SP with CTON 1, also setting SEND_PULSE_TIME(1) and TO or PULSE without luck. Each time a short press on the viewpoint on the learned UP key produces SEVERAL UP jumps on the TV screen.
The original remote works just fine (this is for a Sigma Designs REALmagic card from inside a dvd/video server computer) and also some other buttons like PLAY or STOP are fine. But other like PREV or NEXT CHAPTER skip several chapters.
Any ideas as to what I may try else?
Many thanks in advance,
Bob.
I am facing a real problem when trying to learn some of the IR codes from a particular remote.
I am using a pronto and prontoedit to learn the IR codes from the original remote and then cut-and-paste these codes as Discrete IR Hex Codes straight into IREdit. Particular I can not learn the left/right/down/up arrow keys. When learned they do not go one item up or down but several which drives me nutts. I have tried SEND_COMMAND SP with CTON 1, also setting SEND_PULSE_TIME(1) and TO or PULSE without luck. Each time a short press on the viewpoint on the learned UP key produces SEVERAL UP jumps on the TV screen.
The original remote works just fine (this is for a Sigma Designs REALmagic card from inside a dvd/video server computer) and also some other buttons like PLAY or STOP are fine. But other like PREV or NEXT CHAPTER skip several chapters.
Any ideas as to what I may try else?
Many thanks in advance,
Bob.
0
Comments
I know about the SP and the CTON, CTOF commands. I already used them in the past with other remotes to correct this problem. However they doesn't help with this one particular remote!! I am already using
SEND_COMMAND XCARD, "'CTON',1"
SEND_COMMAND XCARD, "'CTOF',1"
...
SEND_COMMAND XCARD, "'SP', PUSH_CHANNEL"
... or, also tried:
SET_PULSE_TIME(1)
PULSE [XCARD, PUSH_CHANNEL] (* also tried the TO command here *)
SET_PULSE_TIME(5)
with the same result! I think that the pulse time can not be shorter than 1. I have never tried different values for CTOF though?!
What also makes me wonder is the fact that most of the time I learn the one particular IR code the hex values for it are different, also the length is from time to time different! But the original remote just works fine!
Thanks again,
Bob.
PUSH[PANEL,1]
{
ON[dvIR,4]
OFF[dvIR,4]
}
It can also be done in a BUTTON_EVENT.
THis is the shortest "pulse" I could create ever... but as I told above, I only get a rate of about 95% ....
Arrow keys (and often volume and channel) send a repeating IR pulse for as long as the button is held (some types of remotes do this with every function). The actual pulse for control is very small, and it is extremely easy to learn several pulse in the place of one if you are simply pressing the button. The shutter method allows for better control of the size of the pulse you are capturing. As a rule of thumb, I try to make my capture as short as possible while still being able to verify it.
Some remotes with a big nav button that you can press the edge for your arrows have the capacity to send a mixed signal to simulate diagonal movement. These I take apart and use a jumper wire to short out the button contact to insure I'm not getting a combination of up-and-right, or whatever.
Thanks, Marc! And also thanks to Dave and Thomas!
Greetings,
Bob.
Bob wrote that he is capturing IR functions with a Pronto and then copies a hex code to IREdit. Unfortunatelly sometimes if you use the method I described, the hex code generated by ProntoEdit has wrong format and it can not be used in IREdit.
I've also noticed that something that works in Pronto doesn't necessarily work in AMX if it's transferred to IREdit as a hex code (even if IREdit accepts that hex code), but same thing can work correctly if it has been captured with Iris. Strange...
Marc's code sample looks very interesting, I'll have to keep that in mind.
-Kari-
OP
Greetings,
Bob.
OP
Has anyone experience with the non-P0 modes on the IRIS? According to the manual they are:
SP Special Function. Special mode to capture unusual HC functions.
P3 Sends HC functions to a PC running IRLIB automatically
after the VERIFY operation.
P4 Disables the VERIFY operation to capture HC functions.
Default mode requires the VERIFY operation.
P5 Loose-timing mode to capture JVC (PQ10956) HC functions.
P6 Glitch-detection mode to capture Kinderman and some
Mitsubishi HC functions.
P7 Disables glitch-detection mode to capture non-carrier HC functions.
P8 Strict-timing mode
About your actual problem with the prev/next buttons: after you have captured them super-short, try to use the CTON command in your code. I've never had any device which doesn't work correctly after "super-short capturing" and then shortening the pulse with the CTON command, actually I've never had to define the pulse length below 2 (which is equal to 0.2 seconds).
-Kari-
this behaves differently for some products i have to deal with here in Australia, notably Fox Digital TV.
also, since i describe each IR device in a text file for when the system boots, i tend to specify a CTON/CTOF setting for any device that may give me trouble. (as far as i know, all the IR files have been captured with IRIS at full length).
one unreliable TV (sharp aquos over IRS4) has been set to CTON=4, CTOF=1.
and the Fox Digital TV (not over IRS4, wont ever run reliably) is set as CTON=1, CTOF=3.
yes, i could fiddle with shortening IR codes and recapturing short pulses, but i only have so much time in a day. the system i've mentioned, and being cautious around an IRS4, has worked fine so far.
i think there are basically two button types, single press (power, pause, play etc) and repeat buttons (numbers, cursors etc), with the latter group causing the trouble.