View Full Version : help calculating word hex code from OBC value of IR signal
longpole001
- 26th May 2012, 11:13
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
- 26th May 2012, 12:31
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
- 26th May 2012, 13:46
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
- 26th May 2012, 14:45
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
- 27th May 2012, 02:20
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
- 27th May 2012, 04:08
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
- 29th May 2012, 07:51
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
- 29th May 2012, 14:02
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
- 31st May 2012, 13:14
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 ) ,
Powered by vBulletin® Version 4.1.7 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.