Let's analyze in detail the signal generated by the Mitsubishi RKS502A502A remote control to switch on the air conditioner by pressing the ON button with all the other default parameters (FAN SPEED=AUTO, MODE=AUTO, AIR FLOW=AUTO, TEMP=0)
Here we don't use the timer settings because our purpose is to switch on and off the air conditioner with an external tool. By the way the complete signal description including timer management will be soon provided here.
The RKS502A502A uses a slight variation of the NEC protocol that you find described in the network (e.g. here).
It's transmitted with a carrier frequency of 38 kHz (26.3 μs wavelength). Somewhere it's written that it best behaves with a carrier frequency os 38220 Hz.
In my tests I noticed no different behaviour. Maybe with some professional test equipment someone could note some differences.
The logical bits are transmitted as follows:
'0' → a burst having a duration of 490 μs followed by a space of 1450 μs
'1' → a burst having a duration of 490 μs followed by a space of 3455 μs
The following sequence is transmitted:
- an initial pulse of about 6 ms
- a space of about 7.5 ms
- 8 bits of data
- 8 bits that are the logical inverse of the previous 8
- 8 bits of data
- 8 bits that are the logical inverse of the previous 8
- the 8-bit fixed sequence "01010100"
- 8 bits that are the logical inverse of the previous 8 ("10101011")
- a final pulse of about 7.5 ms indicating the end of the signal
When bytes are transmitted, the least significant bit is sent first.
In the following picture we see how the signal detected on IRToy's IRRX pin appears in xoscope:
In absence of signal the output on the IRRX pin is 1 (carrier signal missing). When a pulse is detected, the logic value on IRRX is 0 (carrier signal present).
In the following image, we see the signal as showed in OpenBench Logic Sniffer client that should work with IRToy. I did not succeed in running my IRToy with this client but, with the values derived from the IRToy's Perl scripts, I generated a data file in OLS format to get the image below. I can now import it into OLS for a more convenient signal analysis. I will provide all the script I used asap in this blog.
Then, pressing all the combinations of the remote control (always excluding the timer) and analyzing the bits that change, I got the following tables.
In red there are the bits changing pressing the related button in left columns.
BYTE 0
| |||||||||
---|---|---|---|---|---|---|---|---|---|
bit 0
|
bit 1
|
bit 2
|
bit 3
|
bit 4
|
bit 5
|
bit 6
|
bit 7
| ||
1
|
1
|
1
|
0
|
0
|
0
|
0
|
1
| ||
FAN
|
LOW
|
x
|
x
|
x
|
x
|
x
|
0
|
0
|
x
|
HI
|
x
|
x
|
x
|
x
|
x
|
0
|
1
|
x
| |
MED
|
x
|
x
|
x
|
x
|
x
|
1
|
0
|
x
| |
AUTO
|
x
|
x
|
x
|
x
|
x
|
1
|
1
|
x
| |
SWING
|
SWING
|
x
|
x
|
x
|
0
|
1
|
x
|
x
|
x
|
STOPPED
|
x
|
x
|
x
|
1
|
0
|
x
|
x
|
x
| |
AUTO
|
x
|
x
|
x
|
1
|
1
|
x
|
x
|
x
|
BYTE 2
| |||||||||
---|---|---|---|---|---|---|---|---|---|
bit 0
|
bit 1
|
bit 2
|
bit 3
|
bit 4
|
bit 5
|
bit 6
|
bit 7
| ||
0
|
0
|
1
|
0
|
0
|
0
|
0
|
0
| ||
STATUS
|
ON
|
x
|
x
|
x
|
0
|
x
|
x
|
x
|
x
|
OFF
|
x
|
x
|
x
|
1
|
x
|
x
|
x
|
x
| |
MODE
|
FAN
|
0
|
0
|
x
|
x
|
x
|
x
|
x
|
x
|
COOL
|
0
|
1
|
x
|
x
|
x
|
x
|
x
|
x
| |
DRY
|
1
|
0
|
x
|
x
|
x
|
x
|
x
|
x
| |
AUTO
|
1
|
1
|
x
|
x
|
x
|
x
|
x
|
x
| |
TEMP (AUTO)
|
-6
|
x
|
x
|
x
|
x
|
0
|
1
|
1
|
1
|
-5
|
x
|
x
|
x
|
x
|
1
|
0
|
1
|
1
| |
-4
|
x
|
x
|
x
|
x
|
0
|
0
|
1
|
1
| |
-3
|
x
|
x
|
x
|
x
|
1
|
1
|
0
|
1
| |
-2
|
x
|
x
|
x
|
x
|
0
|
1
|
0
|
1
| |
-1
|
x
|
x
|
x
|
x
|
1
|
0
|
0
|
1
| |
0
|
x
|
x
|
x
|
x
|
0
|
0
|
0
|
1
| |
1
|
x
|
x
|
x
|
x
|
1
|
1
|
1
|
0
| |
2
|
x
|
x
|
x
|
x
|
0
|
1
|
1
|
0
| |
3
|
x
|
x
|
x
|
x
|
1
|
0
|
1
|
0
| |
4
|
x
|
x
|
x
|
x
|
0
|
0
|
1
|
0
| |
5
|
x
|
x
|
x
|
x
|
1
|
1
|
0
|
0
| |
6
|
x
|
x
|
x
|
x
|
0
|
1
|
0
|
0
| |
TEMP (other)
|
18
|
x
|
x
|
x
|
x
|
0
|
1
|
1
|
1
|
19
|
x
|
x
|
x
|
x
|
1
|
0
|
1
|
1
| |
20
|
x
|
x
|
x
|
x
|
0
|
0
|
1
|
1
| |
21
|
x
|
x
|
x
|
x
|
1
|
1
|
0
|
1
| |
22
|
x
|
x
|
x
|
x
|
0
|
1
|
0
|
1
| |
23
|
x
|
x
|
x
|
x
|
1
|
0
|
0
|
1
| |
24
|
x
|
x
|
x
|
x
|
0
|
0
|
0
|
1
| |
25
|
x
|
x
|
x
|
x
|
1
|
1
|
1
|
0
| |
26
|
x
|
x
|
x
|
x
|
0
|
1
|
1
|
0
| |
27
|
x
|
x
|
x
|
x
|
1
|
0
|
1
|
0
| |
28
|
x
|
x
|
x
|
x
|
0
|
0
|
1
|
0
| |
29
|
x
|
x
|
x
|
x
|
1
|
1
|
0
|
0
| |
30
|
x
|
x
|
x
|
x
|
0
|
1
|
0
|
0
| |
CONT
|
x
|
x
|
x
|
x
|
1
|
1
|
1
|
1
|
For example, the bit indicating that the air conditioner is switched on or off is bit#3 of byte#2: it is 0 if ON is pressed, it is 1 if OFF is pressed.
By subtracting the obtained value from 8, we get the value of the matched temperature.
Then e.g. we get the temperature value corresponding to the sequence "1011" by reversing the 4 bits (1101) and subtracting from 8 the corresponding decimal value 13 thus obtaining the value -5
TEMP
|
bit7
|
bit 6
|
bit5
|
bit 4
|
value
|
-6
|
1
|
1
|
1
|
0
|
14
|
-5
|
1
|
1
|
0
|
1
|
13
|
-4
|
1
|
1
|
0
|
0
|
12
|
-3
|
1
|
0
|
1
|
1
|
11
|
-2
|
1
|
0
|
1
|
0
|
10
|
-1
|
1
|
0
|
0
|
1
|
9
|
0
|
1
|
0
|
0
|
0
|
8
|
1
|
0
|
1
|
1
|
1
|
7
|
2
|
0
|
1
|
1
|
0
|
6
|
3
|
0
|
1
|
0
|
1
|
5
|
4
|
0
|
1
|
0
|
0
|
4
|
5
|
0
|
0
|
1
|
1
|
3
|
6
|
0
|
0
|
1
|
0
|
2
|
The same logic is present in the encoding temperature if MODE is not AUTO: in these other cases we must subtract the value from 32 (and not from 8).
Obviously, given the temperature, it's easy to find the corresponding bits sequence: e.g. to find the 4 bits corresponding to temperature +5, let's subtract +5 from 8. We get 3, "0011" in binary format: let's write it inverted and it becomes "1100" that we find in the table of BYTE#2 as the encoded value.
let's see how to send signals.
Obviously, given the temperature, it's easy to find the corresponding bits sequence: e.g. to find the 4 bits corresponding to temperature +5, let's subtract +5 from 8. We get 3, "0011" in binary format: let's write it inverted and it becomes "1100" that we find in the table of BYTE#2 as the encoded value.
let's see how to send signals.
Nessun commento:
Posta un commento