help calculating word hex code from OBC value of IR signal

[longpole001]

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

[Charlie]

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.

[longpole001]

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

[longpole001]

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.


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

[longpole001]

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.

[longpole001]

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

[longpole001]

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

[Jerson]

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

[longpole001]

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 ) ,