Irremoteesp8266: Codes for Samsung ak59-00167a

[plin2]

Version/revison of the library used

IRremote ESP8266 Library v2.5.5
Sketch IRrecvDumpV2
Hardware: Wemos D1 mini with IR Shield

Expected behavior

all received codes will be detected as SAMSUNG

Actual behavior

Most received codes are detected as UNKNOWN with 39 bits length
Only the following keys are detected as SAMSUNG:
SAMSUNG E0E040BF
SAMSUNG E0E0807F
SAMSUNG E0E0D02F
SAMSUNG E0E0E01F

Output of raw data from IRrecvDumpV2.ino (if applicable)

Timestamp : 000060.000
Encoding : UNKNOWN
Code : E4CD1208 (39 bits)
Library : v2.5.5

Raw Timing[77]:

• 4542, - 4438, + 568, - 432, + 562, - 436, + 536, - 462,
• 538, - 460, + 538, - 460, + 564, - 1434, + 564, - 434,
• 534, - 464, + 536, - 462, + 562, - 436, + 536, - 464,
• 564, - 432, + 538, - 462, + 536, - 464, + 534, - 464,
• 564, - 420, + 566, - 4414, + 538, - 1462, + 566, - 1432,
• 562, - 1436, + 536, - 462, + 564, - 436, + 562, - 436,
• 560, - 436, + 562, - 436, + 562, - 436, + 560, - 438,
• 536, - 462, + 562, - 436, + 562, - 1436, + 562, - 1434,
• 536, - 1462, + 564, - 1434, + 562, - 1436, + 564, - 1436,
• 534, - 1462, + 534, - 1464, + 536

uint16_t rawData[77] = {4542, 4438, 568, 432, 562, 436, 536, 462, 538, 460, 538, 460, 564, 1434, 564, 434, 534, 464, 536, 462, 562, 436, 536, 464, 564, 432, 538, 462, 536, 464, 534, 464, 564, 420, 566, 4414, 538, 1462, 566, 1432, 562, 1436, 536, 462, 564, 436, 562, 436, 560, 436, 562, 436, 562, 436, 560, 438, 536, 462, 562, 436, 562, 1436, 562, 1434, 536, 1462, 564, 1434, 562, 1436, 564, 1436, 534, 1462, 534, 1464, 536}; // UNKNOWN E4CD1208

Steps to reproduce the behavior

anytime, just use the remote :-)

Example code used

Sketch IRrecvDumpV2.ino from examples

Circuit diagram and hardware used (if applicable)

Wemos D1 mini with [IR Shield](https://wiki.wemos.cc
Codes from Toshiba, Pioneer and Grundig remotes are beeing received/decoded correctly

I have followed the steps in the

No

Has this library/code previously worked as expected for you?

for other remotes -> yes

Other useful information

A complete IRrecvDumpV2-log of all keys ak59-00167a can be provided

[crankyoldgit]

Thanks for the report and the data.
I've taken a quick look at it, and the reason the library isn't matching it is because it's not a protocol the library currently knows.

Looking at the raw data you provided:

uint16_t rawData[77] = {
  4542, 4438,
  568, 432, 562, 436, 536, 462, 538, 460, 538, 460, 564, 1434, 564, 434, 534, 464,
  536, 462, 562, 436, 536, 464, 564, 432, 538, 462, 536, 464, 534, 464, 564, 420,
  566, 4414,  // This value (4414) is basically an unexpected Header Space. 
  538, 1462, 566, 1432, 562, 1436, 536, 462, 564, 436, 562, 436, 560, 436, 562, 436,
  562, 436, 560, 438, 536, 462, 562, 436, 562, 1436, 562, 1434, 536, 1462, 564, 1434,
  562, 1436, 564, 1436, 534, 1462, 534, 1464, 536}; // UNKNOWN E4CD1208

breaking it down another way:

IRremoteESP8266/tools$ ./auto_analyse_raw_data.py -f /tmp/issue621
Found 77 timing entries.
Potential Mark Candidates:
[4542, 568]
Potential Space Candidates:
[4438, 1464, 464]

Guessing encoding type:
Looks like it uses space encoding. Yay!

Guessing key value:
kHdrMark   = 4542
kHdrSpace  = 4426
kBitMark   = 551
kOneSpace  = 1444
kZeroSpace = 447

Decoding protocol based on analysis so far:

kHdrMark+kHdrSpace+0000010000000000
  Bits: 16
  Hex:  0x0400 (MSB first)
        0x0020 (LSB first)
  Dec:  1024 (MSB first)
        32 (LSB first)
  Bin:  0b0000010000000000 (MSB first)
        0b0000000000100000 (LSB first)
UNEXPECTED->kHdrSpace+11100000000011111111
  Bits: 20
  Hex:  0xE00FF (MSB first)
        0xFF007 (LSB first)
  Dec:  917759 (MSB first)
        1044487 (LSB first)
  Bin:  0b11100000000011111111 (MSB first)
        0b11111111000000000111 (LSB first)

Total Nr. of suspected bits: 36

A normal Samsung protocol (per the spec) doesn't have that Header Space in the middle of the message.

There are a couple of possibilities for this. I did a google search of the remote you said it was, and it's a bluray remote. Correct?

it could be:

• A) You've got a learning remote or set some of the buttons to operate some other device maybe? e.g. a Different model TV perhaps?
• B) It could be a new protocol variant that Samsung is using.
• C) It could be a special protocol samsung uses to encode/signal some other device via HDMI etc.
-

If it's B or C, which it may be. It appears to be in two parts. a 16 bit message which is fairly simple, and a 20 bit payload message.

FYI, the Samsung protocol is 32 bits, this message clearly contains 36 bits of data (16 + 20).

Before I start coding up this potentially new protocol, can you confirm if it the buttons that don't behave are potentially for controlling some other device, or if you set the remote to emulate some other device?

[plin2]

Thanks for the first analysis.

It is a BluRay player, model BD-F6500 with 3D, Smart Hub, AllShare.
The remote is not set to control another device. Actually the keys that are decoded as SAMSUNG are those in the upper right corner of the remote marked as 'SAMSUNG TV' (see here).

I uploaded the complete log of all keys to this location, in case you need to get the complete picture.
How did I create the log? I went through all keys row bey row left to right, next row towards the bottom till the bottom row. I pressed each key several times to make sure the code doesn't alternate between each hit.

[crankyoldgit]

Thanks for confirming that. Yeah, this looks like it's probably a new/different protocol.
I'll try to code something up shortly that should support it.

[crankyoldgit]

@plin2 Can you please try out the code in this branch: https://github.com/markszabo/IRremoteESP8266/tree/Samsung36

Let me know how it goes for you please.

[plin2]

Success! All buttons were detected as either SAMSUNG or SAMSUNG36 (log)
Thanks for the fast fix :-)

[crankyoldgit]

Excellent news. Thanks for the confirmation. Have you tried sending with it yet?

[plin2]

Have you tried sending with it yet?

still owe you the answer: yes, I just successfully transmitted commands to my Samsung device.

[plin2]

Thanks again

[crankyoldgit]

Thanks for the confirmation/update.

[crankyoldgit]

FYI, v2.5.6 has just been release which includes the changes/improvements mentioned.