IR Code issue w/KM v9.09a w/URC-9960B01 and Shift-Functions

fastcat_777 · Post by **fastcat_777** » Mon Sep 03, 2007 12:52 pm

The 3-digit EFC code generated using KM v 9.09a for URC-9960B01 (OFA Kameleon) using the shift function in Buttons (Key move) worksheet for a Sony TV is incorrect using the following parameters

Remote: URC-9960B01 (OFA Kameleon)
Signature code: KASAKAS0
Device Type: TV
Setup Code: 1000 (Upgraded 0000 code)
Extender: No
Protocol Name: Sony12/15
Device1: 1
Device2: 164
Protocol ID: 00 CA
Fixed Data: 80 25 40

When transposed in IR703 it shows as a 5-DIGIT invalid code. For example Button "VOL+" has a code of 080 as a regular button and a 5 digits 52268 as a Key move button (Shift Key). When edited back to 080 in IR703 the code shows up as 00080 (5 digits)

Any idea? Thanks for the help...

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sun Sep 09, 2007 9:41 am

KM is set to generate the newer-style JP1.x keymoves for the URC-9960B01. IR, in interpreting the RDF file, is using a different keymove format. I'm not sure which is correct.

The RDF has an entry for AdvCodeBindFormat=LONG, with no AdvCodeFormat entry. (Therefore, IR will default to AdvCodeFormat=HEX.) If this is correct, then this remote uses a unique keymove style that KM does not yet support. Can anyone verify that this is correct?

Do the keymoves you create in IR actually operate the TV?

fastcat_777 · Post by **fastcat_777** » Fri Sep 21, 2007 6:33 pm

Thanks for the help...
The basic buttons (3 digit code) operates the TV properly but the Key moves (Shift/preset Key) codes(5 digit code) have unpredictable results that do not correspond to the function programmed in and in most cases the TV does not respond.
I checked the RDF file for the URC-9960 B01 it has the following parameters:
AdvCodeFormat=EFC
AdvCodeBindFormat=LONG

unclemiltie · Post by **unclemiltie** » Fri Sep 21, 2007 7:42 pm

The 9960B01 does use the LONG format for Advance Codes. The header on these is one byte longer than that of the previous (non-long) formats in most of the older UEI remotes

I haven't used KM for a long time and can't comment if it does or does not generate the right codes. RM, I know, does.

-bill

fastcat_777 · Post by **fastcat_777** » Fri Sep 21, 2007 8:31 pm

I suspect you might be correct... will learn try RM

Surprisingly in KM, the "Key MAP" worksheet shows the correct 3 digit code for all the Shift-function!!! .... The basic buttons and the shifted one have the same 3 digit code and not 3 and 5 respectively for the same function...

mr_d_p_gumby · Post by **mr_d_p_gumby** » Fri Sep 21, 2007 10:26 pm

fastcat_777 wrote:Surprisingly in KM, the "Key MAP" worksheet shows the correct 3 digit code for all the Shift-function!!! .... The basic buttons and the shifted one have the same 3 digit code and not 3 and 5 respectively for the same function...

The Key Map sheet is displaying EFC codes, either 3-digit or 5-digit, as selected by the user. This has nothing to do with the format of keymoves within the remote.

fastcat_777 · Post by **fastcat_777** » Sat Sep 22, 2007 9:21 am

Thanks for the info...

Maybe lack of consistency since the keymoves are coded with a 5 digits on one worksheet (Setup) and the same keymoves are shown with a different 3 digits code on a different worksheet - Key Maps.

Even though it's a key Map wksheet, since there are separate code (EFC, OBC and Hex) columns for "Functions" and "shift-Functions" and the code are different, you would expect this wksheet to reflect it.

Matter of interpretation....

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sat Sep 22, 2007 10:35 am

Unfortunately, it's not as simple as a "lack of consistency". Even though KM is fully aware of the correct OBC, EFC and HEX values, KM must create the keymove data in such a way that the remote itself will understand it. The remote does not care if you understand the data.

I am aware of the problem here, and will try to have it resolved for the next release of KM.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sat Nov 24, 2007 12:07 pm

KM v9.12 released. This problem should be fixed now.