Wrong decoded IR about irremoteesp8266

[asyncer]

One example of wrong code:
The decoded IR code for SAMSUNG power is:
unsigned int rawData[67] = {4550,4450, 650,1650, 650,1650, 650,1650, 650,500, 650,500, 650,550, 650,550, 650,550, 650,1650, 650,1650, 650,1650, 650,550, 650,550, 650,550, 650,550, 650,500, 650,550, 650,1650, 650,500, 650,550, 650,500, 650,500, 650,550, 650,500, 650,1650, 650,550, 650,1600, 650,1650, 650,1650, 650,1600, 650,1600, 650,1650, 650}; // SAMSUNG E0E040BF

And the one from IRDB is:
unsigned int Samsung_power_toggle[71] = {38000,1,1,170,170,20,63,20,63,20,63,20,20,20,20,20,20,20,20,20,20,20,63,20,63,20,63,20,20,20,20,20,20,20,20,20,20,20,20,20,63,20,20,20,20,20,20,20,20,20,20,20,20,20,63,20,20,20,63,20,63,20,63,20,63,20,63,20,63,20,1798};

Both data and length are different and IRDB code is working fine.

[crankyoldgit]

TL;DR: If you want to send Global Cache (IRDB) format, see https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRGCSendDemo/IRGCSendDemo.ino. The data in both is the same, however the timings are slightly different.

FYI, the rawData and IRDB(Global Cache) formats are different and not directly compatible.
e.g. there are 4 extra fields in the GC format, of freq, send count, repeat point and the amount of trailing space. (71 - 4 = 67)

Converting them to a rough binary format by hand:
rawData = Header + 11100000111000000100000010111111 (0xE0E040BF)
(A pair of [~650, ~1650] == 1, a pair of [~650, ~500] == 0)
irdb = Header + 11100000111000000100000010111111 (0xE0E040BF)
(A pair of [20, 63] == 1, a pair of [20, 20] == 0)

Thus the code values are the same.

Now the question of if the timings are same.
GC format uses the concept of 'period time' in it's format.
The period is calculated at: floor(1000/(38000/1000)) == 26
Converting the GC pairs above, you get
A pair of 20, 63 => 20*26, 63*26 == 520, 1638; and a pair of 20, 20 => 20*26, 20*26 == 520,520.

So it appears our timing for samsung appear to be off.
i.e.
#define SAMSUNG_BIT_MARK 590
#define SAMSUNG_ONE_SPACE 1690
#define SAMSUNG_ZERO_SPACE 590

The 1690 value is close enough to 1638/1650, that it should be fine-ish.
However the value of 590 is a bit off the GC value of 520, and 500/550 & 650 in the rawData.

Before we adjust that values, is the rawData value in your example captured from an actual Samsung remote? i.e. should we be trusting it. I have no idea on the provenance of the IRDB/Global Cache values.
If it is a Samsung remote, can you take multiple rawData samples of it so we can get more confidence what the average times are?

[crankyoldgit]

ping.

[crankyoldgit]

I've confirmed that the library when invoked with sendSamsung(0xE0E040BFUL, 32); works as expected. i.e. It toggles power to a Samsung TV, the library also decodes it as the correct samsung code.
The raw data captured also matches what you reported.

I suspect you have a problem elsewhere with your other code, circuit, or environment.

Marking this closed.