Recently, two of our users in France (Vincent & Mathieu) collaborated to reverse engineer the Panasonic AC Infrared protocol, one of the more challenging AC Infrared protocols using AnalysIR. Not only did they identify the codes & checksum but also provided some impressive documentation and full source code to help others. Detailed information is available via GitHub which is linked below. This 216 data bit Panasonic AC Infrared protocol is composed of two consecutive frames. The first frame remains constant for every command sent to the AC unit. In common with most AC units the complete configuration is sent with every IR signal (temperature, fan, swing etc…). AnalysIR was used to record and turn the signal into HEX/Binary format from which the reverse engineering of the individual fields was tackled.
First Signal Frame
As mentioned above, the first frame of each signal is fixed and independent of the command that needs to be sent. This is an 8 bytes (64 bit) frame whose value is always 0x4004072000000060. (MSB order. For this Panasonic model at least).
Second Signal Frame
The second frame is 19 bytes (152 bits) long and is where the complete configuration & settings are encoded. Notice that to be able to understand the frame content, it must first be transformed into the correct ‘bit order’. Luckily, AnalysIR has a number of in-built features to re-order the bit values from the incoming bit-stream. For most AC units, selecting the LSB8 option from the power-tools menu orients the bit pattern and resulting HEX/Binary values correctly. After, this adjustment, it is a much simpler process to tackle the reverse engineering of the individual fields.
Mark Space timings
The timings for marks & spaces were calculated as 3500, 1750, 435 & 1300 uSecs. If you are getting poor range or reliability issues with your signals, then correcting the timings with the values above will improve things. Of course this only applies to this Infrared Protocol as the timings will differ for others.
The carrier frequency was measured at 38 kHz, which is the most common for 90%+ of AC signals seen to date.
Next we step through each of the successfully decoded fields in the AC Infrared signal:
The temperature setting is encoded in byte #7 of the second frame. Only 4 bits are used to specify the valid range from 16°C to 30°C. In decimal, the value 0 represents 16°C, 1 17°C and so on until 30° which is represented by the value 14. The temperature field is always the best place to start when reverse engineering AC signals, as it’s easier to identify single changes in values, particularly with a tool like AnalysIR.
|Frame 2 – Byte #7|
Swing and Fan
Swing and Fan are set by byte #9 of frame 2.
|Frame 2 – Byte #9|
Individual bit values for swing & fan are as follows:
The Panasonic AC unit allows 3 profiles: Normal, Boost and Quiet. The choice of the profile to be used is set through byte #14 of frame 2.
|Frame 2 – Byte #14|
Individual bit values for profile are as follows:
Mode and ON/OFF toggle
Byte #6 of frame 2, is the one that is used to both setup the mode of the AC unit and to switch it ON or OFF. However, it should be noted that there is no discrete signal to turn ON or OFF, merely an ON/OFF toggle. Therefore any 3rd party controlling application must keep track of the ON/OFF status. (See below for possible workaround) Setting the SWITCH bit to 1 signals an ON/OFF toggle to the AC Unit.
|Frame 2 – Byte #6|
Individual bit values for mode are as follows:
If bit #3 is set to 0, the command is accepted by the AC unit, but ignored. For example, if the AC unit is OFF and the command (bit #3 = 0) is received by the module – it will remain OFF. Consequently, bit #3 must be set to 1, for these commands to be accepted.
Time and ON/OFF programming
At this stage these fields have not been decoded. However, observant readers will note that this feature could be used to force the state of the AC unit into a known ON or OFF condition. If you decide to add this feature then please post your work here, on the forum or via the GitHub link below.
Byte #19 of frame 2 is the checksum for frame 2. It allows the AC unit to know whether the command sent is valid or not. The checksum is the sum (addition) of the previous 18 bytes modulo 256 (frame 2 only).
If you want to generate your own command then you must also calculate this checksum before sending the IR signal to the AC unit.
Note: It is likely that frame 1 also contains a similar checksum in the last byte. However, because this frame never changes, there is no need to be concerned about it.
Other frame bytes
None of the other frame bytes/bits varied during the reverse engineering process. Thus, we can safely conclude at this stage that they do not need to be changed and can always remain fixed at the same value.
Infrared Remote Control Unit
The Panasonic remote control unit used for this project was model number A75C3006, which can be seen in some of the images above.
Not only have Vincent & Mathieu reverse engineered this AC protocol, they have also published the full source code on GitHub as a modified IRremote sketch. This means that the SRAM limitation, common with replaying recorded AC signals using Arduinos and other MCUs is avoided. You can get full control of your own Panasonic AC unit using their code, with the bonus of precise timings. It should also be a relatively easy project to port this code to other platforms, as needed.
This blog post is based on the work of ‘Vincent & Mathieu’ who can be reached via the Github link above.