JP1 Remotes

Hex and OBC are the same number, just in base 16 or base 10 (decimal). EFC is a decimal number of the OBC, just obfuscated. With the calculator, I wouldn't really worry about the details of hoe EFC are coded from OBCs.
FWIW, in my Qbasic programs I use(d) to read remotes, I just use a lookup table to convert OBC to EFC.

To be more accurate, "HEX" as it is used in this context is not a hexadecimal representation of the OBC, but rather it is a set of parameters expressed in hexadecimal that are passed to the protocol executor that tell it how to recreate the OBC. Therefore, the relationship between the HEX value(s) and the OBC can vary depending on the protocol in use. There are common cases (such as the NEC1 being discussed here) where the translation between HEX and OBC is straightforward, but in all cases the HEX is specific to JP1 remotes, while the OBC is specific to the device being controlled.

The EFC is a deliberately obfuscated value, but it is directly related to the HEX value, not the OBC.

Yeah what ^ he said. Back a few years ago I did some work in the IR code and this funky "hex" relationship made me crazy.

Next question:

I've got the following config file from winLirc as I recorded the remote of the Sony cd-player. Its in rawcode-format:
#
# this config file was automatically generated
# using WinLIRC 0.6.5 (LIRC 0.6.1pre3) on Tue Feb 26 11:05:46 2008
#
# contributed by
#
# brand: RMT-CF15CPAD
# model:
# supported devices:
#

begin remote

name RMT-CF15CPAD
flags RAW_CODES
eps 50
aeps 100

ptrail 0
repeat 0 0
gap 21711


begin raw_codes

name Operate
2515 455 1299 474 701 472
1301 472 701 473 1298 475
702 472 709 470 711 471
706 472 1301 472 707 472
709 473 701 473 1301 474
706

name 5
2522 449 715 471 718 472
1304 470 714 473 719 472
722 470 717 470 715 471
718 471 1314 471 719 471
719 472 1316 471 1310 472
715

name Vol+
2534 447 723 468 1323 471
721 471 721 471 1321 469
723 471 722 471 721 471
716 472 1319 471 724 468
723 472 724 472 1326 467
725

name Vol-
2522 449 1303 472 1310 470
716 471 718 471 1314 472
716 472 721 465 718 471
717 469 1307 471 720 472
720 467 716 471 1309 471
721

name Play
2519 450 714 470 1305 472
721 466 720 473 1303 472
1303 473 713 465 719 472
719 470 1304 470 722 472
719 471 1304 472 1303 473
720

name Pause
2520 450 1302 468 703 473
713 473 1302 473 1300 472
1302 474 711 471 716 472
718 471 1302 473 713 469
712 474 1301 473 1301 473
709

name Stop
2526 449 711 472 716 473
707 472 1304 472 1301 472
1305 472 714 472 716 472
719 471 1306 472 710 470
713 473 1302 471 1302 473
717

end raw_codes

end remote

How can I get the HEXcode of these rawcodes?
I thought for "operate" its A8 and for "play" its 4C; for "stop" its 1C...but as I tested it only "oerate"-button did right, the others not. Is there something wrong?

Nightslon wrote:I've got the following config file from winLirc as I recorded the remote of the Sony cd-player. Its in rawcode-format:

I manually translated the first one of those and it is Sony15 protocol, device 68, function 21, which is the power function listed here:
http://www.hifi-remote.com/sony/Sony_bb.htm
I think the others will match as well and it is easier to use that table than manually decode each raw string.

Information on manually decoding these is given in great detail at
http://www.sbprojects.com/knowledge/ir/sirc.htm

Alright, the links you gave me are great! Thank you very much!

next question: if I use an URC with Learn-Function and record some signals, then download them from remote to IR, will I see in LearnedSignals-Tab all the Info about the signals? (protocol, device, efc, obc , hex etc.)

Yes. But for Sony, EFC and Hex can't be perfectly known from a learned signal, so it gives you two possibilities. Those are usable if you must, but using OBC and ignoring EFC and Hex is easier.