I was playing around last night trying to see if my new TV would respond to codes other than those gleaned from the ones I obtained from the RS phone ugrade and those which were learned from the original remote.
Typing in EFC starting form 000 in RM resulted in seemingly strange hex values:
EFC HEX
000 46
001 66
010 01
100 D5
I am assuming that the EFC is a decimal representation of a transmografied hex value or vise versa and was just curious what the corrolation between EFC, OBC, and HEX was.
Thanks,
whats the corrolation between EFC, OBC, HEX?
Moderator: Moderators
The Hex command is the data the protocol executor uses to transmit the signal.
The OBC is the command number encoded within that signal. The Hex command usually differs from the direct hex representation of the OBC for various reasons, including:
1) Hex command is always MSB, but OBC is LSB or MSB depending on which protocol it is. When OBC is LSB the OBC<->HexCmd tanslation must reverse bit sequence.
2) Many protocol executors use definitions of One and Zero that are reversed, in which case OBC<->HexCmd tanslation must reverse bit polarity.
3) Hex commads are always one or more 8 bit bytes, but OBCs are often less than 8 bits or not a multiple of 8 bits. Other info, such as mini-combiner selection may be mixed in.
4) Some protocols, such as RC5, encode one of the OBC bits strangely and noncontiguous to the rest of the OBC. This is handled in various strange ways by various executors.
The EFC is a (rather stupidly) encripted form of one byte (except for some newer models) of HexCmd. That encription was broken by at least two people independently (I'm one of them) long before Rob and friends discovered/invented JP1. EFC formulas and tables have been published on the internet in many places for many years. I'm sure a few are in the JP1 file areas, but I forget where.
The OBC is the command number encoded within that signal. The Hex command usually differs from the direct hex representation of the OBC for various reasons, including:
1) Hex command is always MSB, but OBC is LSB or MSB depending on which protocol it is. When OBC is LSB the OBC<->HexCmd tanslation must reverse bit sequence.
2) Many protocol executors use definitions of One and Zero that are reversed, in which case OBC<->HexCmd tanslation must reverse bit polarity.
3) Hex commads are always one or more 8 bit bytes, but OBCs are often less than 8 bits or not a multiple of 8 bits. Other info, such as mini-combiner selection may be mixed in.
4) Some protocols, such as RC5, encode one of the OBC bits strangely and noncontiguous to the rest of the OBC. This is handled in various strange ways by various executors.
The EFC is a (rather stupidly) encripted form of one byte (except for some newer models) of HexCmd. That encription was broken by at least two people independently (I'm one of them) long before Rob and friends discovered/invented JP1. EFC formulas and tables have been published on the internet in many places for many years. I'm sure a few are in the JP1 file areas, but I forget where.
Thanks John.
I found this page: http://www.hifi-remote.com/wasser/MakeEFCTable.shtml with such a table.
I found this page: http://www.hifi-remote.com/wasser/MakeEFCTable.shtml with such a table.
Jeff Birt
I think John Wasser (author of that page) was first to publish OBC <-> EFC translation. I had the translation earlier but didn't publish it.
That page is what he wrote after we exchanged results. At that time we still didn't have direct knowledge of the HexCmd piece (that needed JP1). We infered the existence of an intermediate piece but didn't describe it that way (because without JP1 that description just adds confusion).
So we described OBC <-> EFC
instead of OBC <-> HexCmd <-> EFC
That page included my formula
#define OBCtoEFC(OBC) (((((unsigned char)(OBC))>>5)+(((unsigned char)(OBC))<<3)) ^ 0x51) + 100
which (IIRC) combines the LSB Comp version OBC <-> HexCmd with the then only version of HexCmd <-> EFC. So it is only valid for protocols using LSB comp.
I think you should use later sources that deal with HexCmd <-> EFC without assuming a specific OBC <-> HExCmd.
That page is what he wrote after we exchanged results. At that time we still didn't have direct knowledge of the HexCmd piece (that needed JP1). We infered the existence of an intermediate piece but didn't describe it that way (because without JP1 that description just adds confusion).
So we described OBC <-> EFC
instead of OBC <-> HexCmd <-> EFC
That page included my formula
#define OBCtoEFC(OBC) (((((unsigned char)(OBC))>>5)+(((unsigned char)(OBC))<<3)) ^ 0x51) + 100
which (IIRC) combines the LSB Comp version OBC <-> HexCmd with the then only version of HexCmd <-> EFC. So it is only valid for protocols using LSB comp.
I think you should use later sources that deal with HexCmd <-> EFC without assuming a specific OBC <-> HExCmd.