Reverse engineering Sanyo AC rcs-3pss4e remote

[kvthie0]

Hi everybody,

I try to reverse engineer the Sanyo AC rcs-3pss4e remote.
This is a 152-bit protocol (sanyo 152AC). I was able to figure out the meaning of all bits except the last byte and bit 57 (bit 1 of byte 8).

I suppose the last byte is the checksum. Unfortunately, I cannot find the key to calculate the checksum. The checksum calculator of AnalysIR could not help me. I’ve tried several other calculations in MSB and LSB8, without any luck.

Perhaps bit 57 has something to do with the checksum ?

On the website of AnalysIR, there is a testimonial of someone who was able to figure out the checksum of a Sanyo rcs-ar1 remote, a remote that looks almost the same as mine. I think (hope !) it should be possible to find the solution.

Any help will be greatly appreciated !

PS : Hereafter the links to a session file from AnalysIR and an excel file. Sheet “decode” shows the meaning of every bit, sheets MSB en LSB8 show the signals both in HEX and BIN format with my calculations for the checksum.

https://drive.google.com/file/d/11L6OEN ... sp=sharing

https://drive.google.com/file/d/1xQc7qb ... sp=sharing

[AnalysIR]

I had a look at it using the reverse engineering tools & the checksum calculator....with the LSB8 fix for the bug you reported.

The checksum is definately using a SUM function...most likely the sum of nibbles.

I went thru a few of them and (excluding the checksum byte - the last byte/last 2 nibles) it is out by a count of 4 on some and a count of 8 on others.

It is not immediately obvious what the distinguishing rule is....so it needs a little more work, to solve.

We will issue the next 'dev' update in the next few days & then you should be able to make some more progress using the tool.


UPDATE: I think we have it

exclude the first 2 bytes and the last 5 bytes.
The checsum is the last byte.
The rule is to SUM the remaining nibbles and add 0x4. (remember to exclude the first 2 bytes and the last 5 bytes)

Please verify & report back.

[kvthie0]

Thanks for your help and time in finding the solution to this problem !

I’ve tried to verify your logic but I can’t reconstruct the checksum.

What I did :

I made the sum of the nibbles of bytes 3->14 (in LSB8) = 24 nibbles and added 0x04 (or 4 in decimals) but the result of this sum is never equal to the checksum.(byte 19 is the checksum byte for me)

I also tried the sum with the nibbles of bytes 6->16, 22 nibbles (which seems to be more logical because bytes 1->5, 17 and 18 never changes) but also without luck.

Could you tell me where I’m wrong ?

Thanks !

[AnalysIR]

Are you using the LSB8 format? (I have includedsome generated with the updated software fix below, for you to check against.

Also, it seems to work better with
Ignore first 2 bytes (always 40 00 in Hex)....so in theory could just ignore the first byte.(40)
Ignore last byte (=chacksum)
The checksum = sum of all other nibbles. (or'ed with 0x00FF)

Here are some decoded signals to test with.

400014806E9018AE2308300018010000000061
400014806E9218ED2308300018010000000066
400014806E8018ED2300300000010001000053 - QUIET ON
400014806E801AE12300300000010000000048 - T- 17
400014806E8022E02300300000010000000040 - T+ 21
400014806E8218DE2300300000010000000054 - ON

[AnalysIR]

The updated 'dev' version of AnalysIR is now available. You should have received a download link via email.

Hopefully, you can make more progress now.

[war3333]

I just registered to thank you for this forum.

I'm trying to reverse engineer the Sanyo AC RCS-3HPSS4E remote.
With only a Broadlink RM4 Mini, that output a raw signal that is like this

Code: Select all

2600 3601 6e37 0f0d 0e0e 0f0e 0e0e 0e0f 0b0f 0f2a 0f0d 0e0e 0e0e 0f0d 0f0f 0d0f 0a10 0f10 0d0d 0e0e 0c10 0f29 0f0f 0d29 0e0e 0f0d 0f0d 0f0d 0e0e 0e0f 0e10 0c10 0a10 0f0d 0f29 0f0d 0e2a 0f29 0f29 0f0d 0c2c 0f29 0f0d 0f0d 0c10 0f2a 0e0e 0e0e 0c0f 1029 0f29 0e0e 0c10 0f0d 0f29 0f29 0d0f 0f0e 0e0d 0f0d 0e2a 0f2a 0e29 0f29 0e2a 0f2a 0e29 0f29 0e2a 0f0e 0e0e 0e10 0a2b 100d 0f0d 0f0f 0c0e 0f0e 0e0f 0d0f 0a10 0f10 0d0d 0e0e 0e0e 0f0d 0f0d 0f0f 0a10 0f0e 0f0f 0c29 0f29 0f2a 0e0e 0e29 0f29 100d 0f29 0e2a 0d2a 100d 0f0f 0d0d 0e0e 0e0f 0e0d 0f0f 0b0f 0f2a 0e0e 0e0f 0d0e 0f0d 0f0d 0f0f 0a10 0f0f 0d10 0c0e 0c0f 100d 0f0d 0f0f 0c0e 0e0f 0e0f 0d0f 0b0f 100d 0f0f 0c0f 0d0e 0f0d 0f0f 0d0f 0a10 0f0f 0e0d 0e0e 0e0e 0f0d 0f0d 0f0f 0a10 0f0e 0e0d 0f29 0e0e 0f0e 0f0f 0c29 0f29 1029 0f0d 0f00 0d05

Those are the frequencies in hex, every couple is a byte (had to learn the hard way until 5 days ago I had never tried to learn how a remote works )

For what i'm seeing is the same signal.
There are some differences but it's because i think the remote of the first post is not a Heat Pump so it lacks some features.
Like bit 48 is 1 for the heat pump enabled.
bit 56 is for the automatic mode that shift from AC to Heat pump as needed.
bit 71 is 1 when the automatic ON turn on the AC
bit 72 is 1 when the automatic OFF turn off the AC

I also have some worry on the bit 57 it seem bind to be 1 when there is a change in the temperature sensor but i wouldn't bet on it for know, i have an hairdryer and some test to do tomorrow.

I will surely buy this software I will need it for some other AC that i have to make "smart" and for the CRC calculation.

I'm only feel a bit bad to have found this forum only at almost the end of my research.

THANK YOU BOTH.

[AnalysIR]

I can confirm that this 'Broadlink' formatted signal decodes as SANYO152AC in AnalysIR & can be imported in this format. (152 data bits)

e.g.
Row: 1
Hex: 020028017623187FC40000EDC020000000008E
Binary:
00000010 00000000 00101000 00000001
01110110 00100011 00011000 01111111
11000100 00000000 00000000 11101101
11000000 00100000 00000000 00000000
00000000 00000000 10001110

As a comparison, the same signal in our own (compressed lossless) LIR format:
LIR: 26 0D16 068A 01B8 01AA 0142 01D6 01BA 04EC 0130 051E 0F 15 23 F1 62 F1 43 13 F1 82 13 13 33 13 31 11 31 11 33 11 13 3F 14 F3 91 11 4F 17 2F 17 21 13 33 13 31 33 3F 17 23 F1 62 F1 EF 15 2F 17 21 13 11 13 33 11