JP1 Remotes

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...

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?

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

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

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...

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.

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....

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.

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