Your new topic does not fit any of the above??? Check first. Then post here. Thanks.

Moderator: igrr

User avatar
By Sev D
#29157 Hello. Running Arduino IDE.

I'm trying to decode IR Signals I receive from an IR Diod. IRremote.h doesn't work. There are custom versions from IRremote.h for the ESP8266, but those can only send, receiving isn't programmed yet and as it looks it won't happen soon.

I tried:
Libraries:
Standard <IRremote.h>
https://github.com/markszabo/IRremoteESP8266
https://github.com/valkuc/esp8266-ir-remote

The furthest I got is with probonopd's sketch posted in this thread:
https://github.com/markszabo/IRremoteESP8266/issues/2

But what I'm receiving doesn't look like a distinct IR code or atleast I don't know what to do with it:

Code: Select all+4384 -630 +491 -629 +491 -629 +494 -626 +491 -628 +493 -629 +491 -628 +493 -627 +492 -628 +1610 -627 +1610 -627 +1606 -628 +1611 -627 +1607 -629 +1607 -628 +1610 -627 +1609 -626 +495 -626 +492 -627 +1609 -628 +1608 -628 +492 -628 +496 -623 +496 -624 +494 -628 +1610 -626 +1610 -626 +492 -628 +493 -627 +1611 -624 +1612 -626 +1608 -629 +1610 -625 +38854
-9044 +2152 -629 -99999
User avatar
By Phil Price
#29617 Hi Sev,
Looks like the code is giving you the raw timing for the IR modulated signal.
Carrier on for 4384uS
Carrier off for 630uS
Carrier on for 491uS
..etc...

Looking at the numbers it seems that the 1s and 0s are encoded by varying the length of the carrier on state.
The first on/off pair (+4384, -630) is usually there to wake up the receiver and set the gain in the decoder chip, so you can safely ignore it in your decoder sketch.

If we assume that a long pulse (>1000uS for example) is a 1 and a short pulse (<1000uS) is a 0 (it might be, or it might be inverted) we get:
00000000 11111111 00110010 11001111 <big pulse> <potentially 1>

The part before the big pulse translates into hex as
0x00 0xFF 0x32 0xCF (small endian)

The 1 after the big pulse could be a checksum. There are an odd number of 1s in the 4 bytes so a basic check might be related to that - it is hard to know without more samples but I suspect it is not part of the actual data so you could ignore it if you wanted to.

Without knowing what you're trying to decode I can't offer much more insight, but hopefully this will help get you in the right direction. Decode some more signals using the method I described above and see how it changes.