crankyoldgit
commented
5 years ago 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 E4CD1208breaking 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: 36A 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
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)