Page 2 of 2

Posted: Mon Feb 28, 2005 10:25 am
by The Robman
wbrells wrote:I've just uploaded my IR file named

"8810w_ir_file_with_LKP_DKP_DSM_problem.ir"
When you post a file that you'd like people to look at, please post a link to it so they don't have to go searching for it.

Remember, the best way to get people to help you is to make it as easy as possible for them to do so.

Posted: Mon Feb 28, 2005 11:25 am
by wbrells
Sorry, still doesn't work. Under the Devices tab of IR I now have TV:1053 and TV:1106 and under the Spcl Prot Fns tab I have

Device button: TV
Key: Power
Type: LKP(4) (TV[1106])
Function: (Short):L1 (Long):L2
HexCmd: $41 $25 $26

Under the Key Moves tab, I still have the two (unchanged) entries for L1 and L2 referencing TN 1053. Is that correct?

Wayne

Posted: Mon Feb 28, 2005 11:26 am
by wbrells
Whoops! In the last message there was a 'typo': TN 1053 should have been TV 1053.

Posted: Mon Feb 28, 2005 11:50 am
by johnsfine
The problem is that L1 and L2 aren't macros.

In the extender version of LKP, you can put any keystrokes inside the LKP. I'm pretty sure the non extender version only works with macros. (Nils, please correct me if I'm wrong.)

If you want to get the effect you seem to be aiming at, define a macro on shift-L1 that contains just the key L1, and similarly for L2. Then edit the LKP so that it uses shift-L1 and shift-L2.

(I was telling the truth when I said special protocols are simpler in the extender version).

Posted: Mon Feb 28, 2005 12:05 pm
by wbrells
That WAS the problem! With Shift-L1 & Shift-L2 defined as macros, everything works fine. Just one question: Is Nils upgrade

----------------------------------------
Try deleting the 1106 device upgrade and add this one and change your keymove to this one

Upgrade code 0 = 0c 52 (TV/1106)
F9 00 01
End
------------------------------------------

really required, or was that a "red herring"? (Actually, I can test it myself and see if this upgrade was really needed...)

Thanks very much,

Wayne

Posted: Mon Feb 28, 2005 12:25 pm
by johnsfine
It looks like IR.EXE is smarter than I expected about dealing with the device type (for special protocols), so the device type changes that I earlier thought were the problem probably never were. It looks like it will work with any device type (though changing the device type after defining the entry on the special protocols tab may well confuse it).

Notice the advantage of posting .ir files when you have problems. Something we probably never would have guessed in the usual game of 20 questions becomes obvious when we open your .ir file in our copy of IR.

Posted: Mon Feb 28, 2005 12:39 pm
by wbrells
Yes, I verified that a device type of "audio" works just as well as "TV". Also, I switched to using "Shift-Phantom1"/"Phantom1" and "Shift Phantom2"/"Phantom2", and those seem to work fine also.

Now that I know the "macro secret" I should be able to configure my 8810w so the Power key in DVD mode will turn on the receiver AND the TV and set the TV input to video, etc.

Thanks very much for everyone's help!

Wayne

Posted: Mon Feb 28, 2005 12:58 pm
by wbrells
One new concern. It appears that I'll need to add a delay after the "Power ON" before giving additional commands. I found a very simple Special Protocol that can be used to add such a delay to S3C8 based remotes. Can someone tell me if my 8810w is, indeed, such a remote?

Thanks,

Wayne

Posted: Mon Feb 28, 2005 1:01 pm
by gfb107
The entries in the RDFs for special protocols use protocol ids, so it makes sense that IR would do everything based on the protocol and not on the setup code.

Posted: Mon Feb 28, 2005 1:09 pm
by johnsfine
wbrells wrote: S3C8 based remotes. Can someone tell me if my 8810w is, indeed, such a remote?
Yes it is.

Posted: Mon Feb 28, 2005 1:28 pm
by Nils_Ekberg
Well, as usual you guys were busy thinking while I was busy testing. I was just getting on to mention the macro issue. I have not used the unextended protocols in so long I forgot about that issue until I started testing it.

So, you have confirmed that my test was correct.

I am going to add to my todo list a minor change to the standalone LDKP for this remote(s) to change it to TV to eliminate that minor confusion in the future.

There is still a problem with using the SP tab for the unextended version since it builds the first hex value backwards. So effectively, the duration will always be 1 if LKP is selected. If DKP is selected it won't work at all.

Posted: Mon Feb 28, 2005 1:30 pm
by Nils_Ekberg
gfb107 wrote:The entries in the RDFs for special protocols use protocol ids, so it makes sense that IR would do everything based on the protocol and not on the setup code.
I agree Greg. I just think it is worthwhile though to atleast have a device and setup code the remote recognizes.

Posted: Tue Mar 01, 2005 6:43 am
by wbrells
Folks,

I recently noticed that the DSM "Special Protocol" is greyed-out while I'm using the "6_806_80 (URC-881x_801x_601x).rdf" file in conjunction with the "LKPDKP-8810w.txt" LKP/DKP/DSM" combo protocol file. The documentation for this combo protocol shows support for LKP/DKP/DSM, all (apparently) with an ID of $01F9. HOWEVER, the above rdf file contains the entries:

[SpecialProtocols]
LDKP=01F9
DSM=01FC

I don't have a $01FC protocol, so that is probably why I'm getting a greyed-out DSM in IR.

I tried changing the DSM=01FC to DSM=01F9, but that caused IR to generate a "duplicate ID" error message.

Is there different change that I can make in my rdf file to "activate" the DSM protocol in $01F9?

Thanks again,
Wayne

Posted: Tue Mar 01, 2005 8:10 am
by Nils_Ekberg
That was kind of the point I was making above. IR is not working correctly with standalone protocols and there is nothing you can change. The LDKP protocol does include DSM so you can create it as a keymove per the documentation and not use the SP tab until it is fixed.

In addition, the are also standalone DSM protocols somewhere in the file section that is the 01FC protocol

Posted: Tue Mar 01, 2005 8:21 am
by wbrells
Nils,

I expected that this was the situation, but I just wanted to confirm that there was no other "workaround".

Thanks for the info,
Wayne