help calculating word hex code from OBC value of IR signal

Hi guys ,

i need help to be able to store the OBC value of the IR code and generate via formula the word value in hex it represents from it to send.

reason is that the obc value is able to be stored as a 1 byte ( FF) and the represented hex is of OBC ( FF FF ) saves a lot of stored space and i can generate a value for OBC when knowing what key it represents and then the next without using a table on all occasions for sequencing of IR codes

I know that it seems to be a compliment value of but NOT CLEAR how it comes about and how i may calculate it from stored OBC value



eg OBC 0 = 00 FF ( 0000 0000 1111 1111)
OBC1 = 80 7F ( 1000 0000 0111 1111) ( + 80 - 40) when looking at each byte
OBC2 = 40 BF ( 0100 0000 1011 1111) ( - 40 + 40)
OBC3 = C0 3F ( 1011 0000 0100 1111) ( +80 - 80)
OBC4 = 20 DF ( 0010 0000 1101 1111) ( -A0 + A0)
obc5 = A0 5F ( 1010 0000 0101 1111) ( +80 - 80)

any help pointing me how i can do this would be great


Cheers

Sheldon

I know nothing about the code - only what I see from your example, so this reply might be totally bogus.

In the example, the lowest nibble is always F and the third nibble is always 0. If this is always true, you can simply use shift to strip them off and put them back. In the first case (OBC1), shift 7F >> 4, to get 7. Then add it to 80, and store 87. To recover, use logical AND to recover the low nibble. Subtract that from the stored value to get the high byte, then shift it << 4 and add F to get the low byte back.

unforntuanty is not that simple a from this example

OBC92 = 3A C5
OBC93 = BA 45
OBC65 = 82 7D
OBC64 = 02 FD

a lot of the codes follow x2 xD at point but then change to xA x5 etc and not what seems the same point offset of 16 OBC values

looking again at your example , how would a shift be done in the basic code , i have included a summery sheet of the codes for ref , it seem each OBC 0 - 15 . 16 - 31, etc code x0 xF changes on each 16 OBC codes group

since each OBC code is different for each remote using the same function , yes i have to allow for 3 remotes that look similar , do the same function over all , but are sending different codes for the same function , i thought that having only the OBC for each remote key would save a lot of storage space on the prom.

Quote:

---

NEC1 - IR Remote Code table Reference

SigKey #	Button key FUNCTION Reference	Red to White 16 or 20 steps	Remote 1			Remote 2			Remote 3
			OBC	HEX	Full Hex Code	OBC	HEX	Full Hex Code	OBC	HEX	Full Hex Code
1	Brightness UP		5	5F	00 FF A0 5F	0	FF	00 F7 00 FF	92	C5	00 FF 3A C5
2	Brightness DWN		4	DF	00 FF 20 DF	1	7F	00 F7 80 7F	93	45	00 FF BA 45
3	PWR Off		6	9F	00 FF 60 9F	2	BF	00 F7 40 BF	65	7D	00 FF 82 7D
4	PWR On		7	1F	00 FF E0 1F	3	3F	00 F7 C0 3F	64	FD	00 FF 02 FD
5	RED	1	9	6F	00 FF 90 6F	4	DF	00 F7 20 DF	88	E5	00 FF 1A E5
6	GREEN	6	8	EF	00 FF 10 EF	5	5F	00 F7 A0 5F	89	65	00 FF 9A 65
7	BLUE	11	10	AF	00 FF 50 AF	6	9F	00 F7 60 9F	69	5D	00 FF A2 5D
8	WHITE	16 (20)	11	2F	00 FF D0 2F	7	1F	00 F7 E0 1F	68	DD	00 FF 22 DD
9	Button 1	2	13	4F	00 FF B0 4F	8	EF	00 F7 10 EF	84	D5	00 FF 2A D5
10	Button 2	7	12	CF	00 FF 30 CF	9	6F	00 F7 90 6F	85	55	00 FF AA 55
11	Button 3	12	14	8F	00 FF 70 8F	10	AF	00 F7 50 AF	73	6D	00 FF 92 6D
12	Button 4	Flash(19)	15	0F	00 FF F0 0F	11	2F	00 F7 D0 2F	72	ED	00 FF 12 ED
13	Button 5	3	21	57	00 FF A8 57	12	CF	00 F7 30 CF	80	F5	00 FF 0A F5
14	Button 6	8	20	D7	00 FF 28 D7	13	4F	00 F7 B0 4F	81	75	00 FF 8A 75
15	Button 7	13	22	97	00 FF 68 97	14	8F	00 F7 70 8F	77	4D	00 FF B2 4D
16	Button 8	Strobe (18)	23	17	00 FF E8 17	15	0F	00 F7 F0 0F	76	CD	00 FF 32 CD
17	Button 9	4	25	67	00 FF 98 67	16	F7	00 F7 08 F7	28	C7	00 FF 38 C7
18	Button 10	9	24	E7	00 FF 18 E7	17	77	00 F7 88 77	29	47	00 FF B8 47
19	Button 11	14	26	A7	00 FF 58 A7	18	B7	00 F7 48 B7	30	87	00 FF 78 87
20	Button 12	Fade (17)	27	27	00 FF D8 27	19	37	00 F7 C8 37	31	07	00 FF F8 07
21	Button 13	5	17	77	00 FF 88 77	20	D7	00 F7 28 D7	24	E7	00 FF 18 E7
22	Button 14	10	16	F7	00 FF 08 F7	21	57	00 F7 A8 57	25	67	00 FF 98 67
23	Button 15	15	18	B7	00 FF 48 B7	22	97	00 F7 68 97	26	A7	00 FF 58 A7
24	Button 16	Smooth (16)	19	37	00 FF C8 37	23	17	00 F7 E8 17	27	27	00 FF D8 27
25	Button 17	Red Up							20	D7	00 FF 28 D7
26	Button 18	Green Up							21	57	00 FF A8 57
27	Button 19	Blue up							22	97	00 FF 68 97
28	Button 20	Quick							23	17	00 FF E8 17
29	Button 21	Red Dwn							16	F7	00 FF 08 F7
30	Button 22	Green Dwn							17	77	00 FF 88 77
31	Button 23	Blue Dwn							18	B7	00 FF 48 B7
32	Button 24	Slow							19	37	00 FF C8 37
33	Button 25	DIY1							12	CF	00 FF 30 CF
34	Button 26	DIY2							13	4F	00 FF B0 4F
35	Button 27	DIY3							14	8F	00 FF 70 8F
36	Button 28	Auto							15	0F	00 FF F0 0F
37	Button 29	DIY4							8	EF	00 FF 10 EF
38	Button 30	DIY5							9	6F	00 FF 90 6F
39	Button 31	DIY6							10	AF	00 FF 50 AF
40	Button 32	Flash							11	2F	00 FF D0 2F
41	Button 33	Jump 3							4	DF	00 FF 20 DF
42	Button 34	Jump 7							5	5F	00 FF A0 5F
43	Button 35	Fade3							6	9F	00 FF 60 9F
44	Button 36	Fade7							7	1F	00 FF E0 1F

---

Hi , yes i do see where your going , with the shift statement and then getting only the nibbles1 and 3 that are changed and store those for reference , but all 4 nibbles change as per attached sheet , the only thing that ties them consistently is the OBC code reference.
so a generate formula using the OBC Ref is the answer or else i store each 2 bytes per code.

some time the obvious is hard to grasp but if you look at the table and you take the last byte of each code and inverse it , it is the value for the 3rd byte or visa vera if you inverse 3rd byte u get 4byte

eg full hex code 00 FF 20 DF = OBC 4

Ok 00 FF are the device code and i just need to know these for each remote type

20 is the inverse of DF , which is referred to as OBC 4 , why i am not sure perhaps becuase it the 4th change from FF when taking $40 from FF

if i store the value of DF for this key and do bitwise not ( inverse) on this value the result will be 20 byte 3

The following code does this


Byte4 = $DF

Byte3 = (~ byte4)

more fun ahead

for those wondering how the OBC in a IR code comes about here is how it works

OBC value is based on the 3rd byte then if
obc0 = 00
obc1 = 80
obc2 = 40
obc3 = c0
obc4 = 20
obc5 = A0

The bit order is reversed.

OBC0 = 00h 00000000b reversed = 00000000b 00h
OBC1 = 01h 00000001b reversed = 10000000b 80h
OBC2 = 02h 00000010b reversed = 01000000b 40h
...
OBC5 = 05h 00000101b reversed = 10100000b A0h
...
OBC32 = 20h 00100000b reversed = 00000100b 04h
etc.

regards

Quote:

---

34	Button 26	DIY2							13	4F	00 FF B0 4F
35	Button 27	DIY3							14	8F	00 FF 70 8F

---

First of all, I don't know what is OBC. Please expand abbreviations the first time around.

Taking just these 2 examples, it seems pretty intuitive to me.

Let us take the case of Sigkey#34 button 26. The code you see is 00 FF B0 4F
The first byte 00 must be some kind of device ID or something.
The second byte is just the binary inverse (NOT operation) of the first byte
The third byte is the function code
and the 4th byte is the inverted function code. Just like the second byte.

The easiest way to do this is to have a lookup table having the codes for bytes 1 and 3 and you generate the bytes 2 and 4 before sending them out.

It's that easy

yes as i worked through it i found i only needed to store 1 byte , for BUTTON code and 1 byte for the remote type ( DEVICE ) ,