arduino-irremote / arduino-irremote Goto Github PK

View Code? Open in Web Editor NEW

4.3K 222.0 1.7K 9.13 MB

Infrared remote library for Arduino: send and receive infrared signals with multiple protocols

License: Other

C++ 91.32% C 8.68%

arduino library infrared arduino-library remote

arduino-irremote's Introduction

Arduino IRremote

A library enabling the sending & receiving of infra-red signals.

Available as Arduino library "IRremote".

If you find this program useful, please give it a star.

🌎 Google Translate

Table of content

Staying on 2.x

Supported IR Protocols

NEC / Onkyo / Apple Denon / Sharp Panasonic / Kaseikyo

JVC LG RC5 RC6 Samsung Sony

Universal Pulse Distance Universal Pulse Width Hash Pronto

BoseWave Bang & Olufsen Lego FAST Whynter MagiQuest

Protocols can be switched off and on by defining macros before the line #include <IRremote.hpp> like here:

#define DECODE_NEC
//#define DECODE_DENON
#include <IRremote.hpp>

Features

Lots of tutorials and examples.
Actively maintained.
Allows receiving and sending of raw timing data.

New features with version 4.x

Since 4.3 IrSender.begin(DISABLE_LED_FEEDBACK) will no longer work, use IrSender.begin(DISABLE_LED_FEEDBACK, 0) instead.
New universal Pulse Distance / Pulse Width decoder added, which covers many previous unknown protocols.
Printout of code how to send received command by IrReceiver.printIRSendUsage(&Serial).
RawData type is now 64 bit for 32 bit platforms and therefore decodedIRData.decodedRawData can contain complete frame information for more protocols than with 32 bit as before.
Callback after receiving a command - It calls your code as soon as a message was received.
Improved handling of PULSE_DISTANCE + PULSE_WIDTH protocols.
New FAST protocol.
Automatic printout of the corresponding send function with printIRSendUsage().

Converting your 3.x program to the 4.x version

You must replace #define DECODE_DISTANCE by #define DECODE_DISTANCE_WIDTH (only if you explicitly enabled this decoder).
The parameter bool hasStopBit is not longer required and removed e.g. for function sendPulseDistanceWidth().

New features with version 3.x

Any pin can be used for receiving and if SEND_PWM_BY_TIMER is not defined also for sending.
Feedback LED can be activated for sending / receiving.
An 8/16 bit **command value as well as an 16 bit address and a protocol number is provided for decoding (instead of the old 32 bit value).
Protocol values comply to protocol standards.
NEC, Panasonic, Sony, Samsung and JVC decode & send LSB first.
Supports Universal Distance protocol, which covers a lot of previous unknown protocols.
Compatible with tone() library. See the ReceiveDemo example.
Simultaneous sending and receiving. See the SendAndReceive example.
Supports more platforms.
Allows for the generation of non PWM signal to just simulate an active low receiver signal for direct connect to existent receiving devices without using IR.
Easy protocol configuration, directly in your source code.
Reduces memory footprint and decreases decoding time.
Contains a very small NEC only decoder, which does not require any timer resource.

-> Feature comparison of 5 Arduino IR libraries.

Converting your 2.x program to the 4.x version

Starting with the 3.1 version, the generation of PWM for sending is done by software, thus saving the hardware timer and enabling arbitrary output pins for sending.
If you use an (old) Arduino core that does not use the -flto flag for compile, you can activate the line #define SUPPRESS_ERROR_MESSAGE_FOR_BEGIN in IRRemote.h, if you get false error messages regarding begin() during compilation.

IRreceiver and IRsender object have been added and can be used without defining them, like the well known Arduino Serial object.
Just remove the line IRrecv IrReceiver(IR_RECEIVE_PIN); and/or IRsend IrSender; in your program, and replace all occurrences of IRrecv. or irrecv. with IrReceiver and replace all IRsend or irsend with IrSender.
Since the decoded values are now in IrReceiver.decodedIRData and not in results any more, remove the line decode_results results or similar.
Like for the Serial object, call IrReceiver.begin(IR_RECEIVE_PIN, ENABLE_LED_FEEDBACK) or IrReceiver.begin(IR_RECEIVE_PIN, DISABLE_LED_FEEDBACK) instead of the IrReceiver.enableIRIn() or irrecv.enableIRIn() in setup().
For sending, call IrSender.begin(); in setup().
If IR_SEND_PIN is not defined (before the line #include <IRremote.hpp>) you must use e.g. IrSender.begin(3, ENABLE_LED_FEEDBACK, USE_DEFAULT_FEEDBACK_LED_PIN);
Old decode(decode_results *aResults) function is replaced by simple decode(). So if you have a statement if(irrecv.decode(&results)) replace it with if (IrReceiver.decode()).
The decoded result is now in in IrReceiver.decodedIRData and not in results any more, therefore replace any occurrences of results.value and results.decode_type (and similar) to IrReceiver.decodedIRData.decodedRawData and IrReceiver.decodedIRData.protocol.
Overflow, Repeat and other flags are now in IrReceiver.receivedIRData.flags.
Seldom used: results.rawbuf and results.rawlen must be replaced by IrReceiver.decodedIRData.rawDataPtr->rawbuf and IrReceiver.decodedIRData.rawDataPtr->rawlen.
The 5 protocols NEC, Panasonic, Sony, Samsung and JVC have been converted to LSB first. Send functions for sending old MSB data for NEC and JVC were renamed to sendNECMSB, and sendJVCMSB(). The old sendSAMSUNG() and sendSony() MSB functions are still available. The old MSB version of sendPanasonic() function was deleted, since it had bugs nobody recognized.
For converting MSB codes to LSB see below.

Example

Old 2.x program:

#include <IRremote.h>
#define RECV_PIN 2

IRrecv irrecv(RECV_PIN);
decode_results results;

void setup()
{
...
  irrecv.enableIRIn(); // Start the receiver
}

void loop() {
  if (irrecv.decode(&results)) {
      Serial.println(results.value, HEX);
      ...
      irrecv.resume(); // Receive the next value
  }
  ...
}

New 4.x program:

#include <IRremote.hpp>
#define IR_RECEIVE_PIN 2

void setup()
{
...
  IrReceiver.begin(IR_RECEIVE_PIN, ENABLE_LED_FEEDBACK); // Start the receiver
}

void loop() {
  if (IrReceiver.decode()) {
      Serial.println(IrReceiver.decodedIRData.decodedRawData, HEX); // Print "old" raw data
      IrReceiver.printIRResultShort(&Serial); // Print complete received data in one line
      IrReceiver.printIRSendUsage(&Serial);   // Print the statement required to send this data
      ...
      IrReceiver.resume(); // Enable receiving of the next value
  }
  ...
}

How to convert old MSB first 32 bit IR data codes to new LSB first 32 bit IR data codes

For the new decoders for NEC, Panasonic, Sony, Samsung and JVC, the result IrReceiver.decodedIRData.decodedRawData is now LSB-first, as the definition of these protocols suggests!

To convert one into the other, you must reverse the byte/nibble positions and then reverse all bit positions of each byte/nibble or write it as one binary string and reverse/mirror it.

Example: 0xCB 34 01 02
0x20 10 43 BC after nibble reverse
0x40 80 2C D3 after bit reverse of each nibble

Nibble reverse map:

 0->0   1->8   2->4   3->C
 4->2   5->A   6->6   7->E
 8->1   9->9   A->5   B->D
 C->3   D->B   E->7   F->F

0xCB340102 is binary 1100 1011 0011 0100 0000 0001 0000 0010.
0x40802CD3 is binary 0100 0000 1000 0000 0010 1100 1101 0011.
If you read the first binary sequence backwards (right to left), you get the second sequence. You may use bitreverseOneByte() or bitreverse32Bit() for this.

Errors with using the 4.x versions for old tutorials

If you suffer from errors with old tutorial code including IRremote.h instead of IRremote.hpp, just try to rollback to Version 2.4.0.
Most likely your code will run and you will not miss the new features.

Staying on 2.x

Consider using the original 2.4 release form 2017 or the last backwards compatible 2.8 version for you project.
It may be sufficient and deals flawlessly with 32 bit IR codes.
If this doesn't fit your case, be assured that 3.x is at least trying to be backwards compatible, so your old examples should still work fine.

Drawbacks

Only the following decoders are available:
NEC Denon Panasonic JVC LG
RC5 RC6 Samsung Sony
The call of irrecv.decode(&results) uses the old MSB first decoders like in 2.x and sets the 32 bit codes in results.value.
The old functions sendNEC() and sendJVC() are renamed to sendNECMSB() and sendJVCMSB().
Use them to send your old MSB-first 32 bit IR data codes.
No decoding by a (constant) 8/16 bit address and an 8 bit command.

Why .hpp instead of .cpp?

Every *.cpp file is compiled separately by a call of the compiler exclusively for this cpp file. These calls are managed by the IDE / make system. In the Arduino IDE the calls are executed when you click on Verify or Upload.

And now our problem with Arduino is:
How to set compile options for all *.cpp files, especially for libraries used?
IDE's like Sloeber or PlatformIO support this by allowing to specify a set of options per project. They add these options at each compiler call e.g. -DTRACE.

But Arduino lacks this feature. So the workaround is not to compile all sources separately, but to concatenate them to one huge source file by including them in your source.
This is done by e.g. #include "IRremote.hpp".

But why not #include "IRremote.cpp"?
Try it and you will see tons of errors, because each function of the *.cpp file is now compiled twice, first by compiling the huge file and second by compiling the *.cpp file separately, like described above.
So using the extension cpp is not longer possible, and one solution is to use hpp as extension, to show that it is an included *.cpp file.
Every other extension e.g. cinclude would do, but hpp seems to be common sense.

Using the new *.hpp files

In order to support compile options more easily, you must use the statement #include <IRremote.hpp> instead of #include <IRremote.h> in your main program (aka *.ino file with setup() and loop()).

In all other files you must use the following, to prevent multiple definitions linker errors:

#define USE_IRREMOTE_HPP_AS_PLAIN_INCLUDE
#include <IRremote.hpp>

Ensure that all macros in your main program are defined before any #include <IRremote.hpp>.
The following macros will definitely be overridden with default values otherwise:

RAW_BUFFER_LENGTH
IR_SEND_PIN
SEND_PWM_BY_TIMER

IRReceiver pinouts

Receiving IR codes

In your program you check for a completly received IR frame with:
if (IrReceiver.decode()) {}
This also decodes the received data.
After successful decoding, the IR data is contained in the IRData structure, available as IrReceiver.decodedIRData.

decodedIRData structure

struct IRData {
    decode_type_t protocol;     // UNKNOWN, NEC, SONY, RC5, PULSE_DISTANCE, ...
    uint16_t address;           // Decoded address
    uint16_t command;           // Decoded command
    uint16_t extra;             // Used for Kaseikyo unknown vendor ID. Ticks used for decoding Distance protocol.
    uint16_t numberOfBits;      // Number of bits received for data (address + command + parity) - to determine protocol length if different length are possible.
    uint8_t flags;              // IRDATA_FLAGS_IS_REPEAT, IRDATA_FLAGS_WAS_OVERFLOW etc. See IRDATA_FLAGS_* definitions
    IRRawDataType decodedRawData;    // Up to 32 (64 bit for 32 bit CPU architectures) bit decoded raw data, used for sendRaw functions.
    uint32_t decodedRawDataArray[RAW_DATA_ARRAY_SIZE]; // 32 bit decoded raw data, to be used for send function.
    irparams_struct *rawDataPtr; // Pointer of the raw timing data to be decoded. Mainly the data buffer filled by receiving ISR.
};

Flags

This is the list of flags contained in the flags field.
Check it with e.g. if(IrReceiver.decodedIRData.flags & IRDATA_FLAGS_IS_REPEAT).

Flag name	Description
IRDATA_FLAGS_IS_REPEAT	The gap between the preceding frame is as smaller than the maximum gap expected for a repeat. !!!We do not check for changed command or address, because it is almost not possible to press 2 different buttons on the remote within around 100 ms!!!
IRDATA_FLAGS_IS_AUTO_REPEAT	The current repeat frame is a repeat, that is always sent after a regular frame and cannot be avoided. Only specified for protocols DENON, and LEGO.
IRDATA_FLAGS_PARITY_FAILED	The current (autorepeat) frame violated parity check.
IRDATA_FLAGS_TOGGLE_BIT	Is set if RC5 or RC6 toggle bit is set.
IRDATA_FLAGS_EXTRA_INFO	There is extra info not contained in address and data (e.g. Kaseikyo unknown vendor ID, or in decodedRawDataArray).
IRDATA_FLAGS_WAS_OVERFLOW	irparams.rawlen is set to 0 in this case to avoid endless OverflowFlag.
IRDATA_FLAGS_IS_MSB_FIRST	This value is mainly determined by the (known) protocol.

To access the RAW data, use:

auto myRawdata= IrReceiver.decodedIRData.decodedRawData;

The definitions for the IrReceiver.decodedIRData.flags are described here.

Print all fields:

IrReceiver.printIRResultShort(&Serial);

Print the raw timing data received:

IrReceiver.printIRResultRawFormatted(&Serial, true);`

The raw data depends on the internal state of the Arduino timer in relation to the received signal and might therefore be slightly different each time. (resolution problem). The decoded values are the interpreted ones which are tolerant to such slight differences!

Print how to send the received data:

IrReceiver.printIRSendUsage(&Serial);

Ambiguous protocols

NEC, Extended NEC, ONKYO

The NEC protocol is defined as 8 bit address and 8 bit command. But the physical address and data fields are each 16 bit wide. The additional 8 bits are used to send the inverted address or command for parity checking.
The extended NEC protocol uses the additional 8 parity bit of address for a 16 bit address, thus disabling the parity check for address.
The ONKYO protocol in turn uses the additional 8 parity bit of address and command for a 16 bit address and command.

The decoder reduces the 16 bit values to 8 bit ones if the parity is correct. If the parity is not correct, it assumes no parity error, but takes the values as 16 bit values without parity assuming extended NEC or extended NEC protocol protocol.

But now we have a problem when we want to receive e.g. the 16 bit address 0x00FF or 0x32CD! The decoder interprets this as a NEC 8 bit address 0x00 / 0x32 with correct parity of 0xFF / 0xCD and reduces it to 0x00 / 0x32.

One way to handle this, is to force the library to always use the ONKYO protocol interpretation by using #define DECODE_ONKYO. Another way is to check if IrReceiver.decodedIRData.protocol is NEC and not ONKYO and to revert the parity reducing manually.

NEC, NEC2

On a long press, the NEC protocol does not repeat its frame, it sends a special short repeat frame. This enables an easy distinction between long presses and repeated presses and saves a bit of battery energy. This behavior is quite unique for NEC and its derived protocols like LG and Samsung.

But of course there are also remote control systems, that uses the NEC protocol but only repeat the first frame when a long press is made instead of sending the special short repeat frame. We named this the NEC2 protocol and it is sent with sendNEC2().
But be careful, the NEC2 protocol can only be detected by the NEC library decoder after the first frame and if you do a long press!

Samsung, SamsungLG

On a long press, the SamsungLG protocol does not repeat its frame, it sends a special short repeat frame.

Unknown protocol

Use the ReceiveDemo example to print out all informations about your IR protocol.
The ReceiveDump example gives you more information but has bad repeat detection.

If your protocol seems not to be supported by this library, you may try the IRMP library.

Sending IR codes

If you have a device at hand which can generate the IR codes you want to work with (aka IR remote), it is recommended to receive the codes with the ReceiveDemo example, which will tell you on the serial output how to send them.

Protocol=LG Address=0x2 Command=0x3434 Raw-Data=0x23434E 28 bits MSB first
Send with: IrSender.sendLG(0x2, 0x3434, <numberOfRepeats>);

You will discover that the address is a constant and the commands sometimes are sensibly grouped.
If you are uncertain about the numbers of repeats to use for sending, 3 is a good starting point. If this works, you can check lower values afterwards.

If you have enabled DECODE_DISTANCE_WIDTH, the code printed by printIRSendUsage() differs between 8 and 32 bit platforms, so it is best to run the receiving program on the same platform as the sending program.

The codes found in the irdb database specify a device, a subdevice and a function. Most of the times, device and subdevice can be taken as upper and lower byte of the address parameter and function is the command parameter for the new structured functions with address, command and repeat-count parameters like e.g. IrSender.sendNEC((device << 8) | subdevice, 0x19, 2).
An exact mapping can be found in the IRP definition files for IR protocols. "D" and "S" denotes device and subdevice and "F" denotes the function.

All sending functions support the sending of repeats if sensible. Repeat frames are sent at a fixed period determined by the protocol. e.g. 110 ms from start to start for NEC.
Keep in mind, that there is no delay after the last sent mark. If you handle the sending of repeat frames by your own, you must insert sensible delays before the repeat frames to enable correct decoding.

The old send*Raw() functions for sending like e.g. IrSender.sendNECRaw(0xE61957A8,2) are kept for backward compatibility to (old) tutorials and unsupported as well as error prone.

Send pin

Any pin can be choosen as send pin, because the PWM signal is generated by default with software bit banging, since SEND_PWM_BY_TIMER is not active. If IR_SEND_PIN is specified (as c macro), it reduces program size and improves send timing for AVR. If you want to use a variable to specify send pin e.g. with setSendPin(uint8_t aSendPinNumber), you must disable this IR_SEND_PIN macro. Then you can change send pin at any time before sending an IR frame. See also Compile options / macros for this library.

List of public IR code databases

http://www.harctoolbox.org/IR-resources.html

Flipper Zero

Flipper IRDB Database

Flipper decoding	IRremote decoding
Samsung32	Samsung
NEC	NEC
NECext	ONKYO
<start bit><VendorID:16><VendorID parity:4><Genre1:4><Genre2:4><Command:10><ID:2><Parity:8><stop bit> and ID is MSB of address. address: 8A 02 20 00 command: 56 03 00 00 -> IRremote: Address 0x6A8, sendPanasonic (for 02 20) and Command 0x35	<start bit><VendorID:16><VendorID parity:4><Address:12><Command:8><Parity of VendorID parity, Address and Command:8><stop bit>

Tiny NEC receiver and sender

For applications only requiring NEC, NEC variants or FAST -see below- protocol, there is a special receiver / sender included,
which has very small code size of 500 bytes and does NOT require any timer.

Check out the TinyReceiver and IRDispatcherDemo examples.
Take care to include TinyIRReceiver.hpp or TinyIRSender.hpp instead of IRremote.hpp.

TinyIRReceiver usage

//#define USE_ONKYO_PROTOCOL    // Like NEC, but take the 16 bit address and command each as one 16 bit value and not as 8 bit normal and 8 bit inverted value.
//#define USE_FAST_PROTOCOL     // Use FAST protocol instead of NEC / ONKYO
#include "TinyIRReceiver.hpp"

void setup() {
  initPCIInterruptForTinyReceiver(); // Enables the interrupt generation on change of IR input signal
}

void loop() {
    if (TinyIRReceiverData.justWritten) {
        TinyIRReceiverData.justWritten = false;
        printTinyReceiverResultMinimal(&Serial);
    }
}

TinyIRSender usage

#include "TinyIRSender.hpp"

void setup() {
  sendNEC(3, 0, 11, 2); // Send address 0 and command 11 on pin 3 with 2 repeats.
}

void loop() {}

Another tiny receiver and sender supporting more protocols can be found here.

The FAST protocol

The FAST protocol is a proprietary modified JVC protocol without address, with parity and with a shorter header. It is meant to have a quick response to the event which sent the protocol frame on another board. FAST takes 21 ms for sending and is sent at a 50 ms period. It has full 8 bit parity for error detection.

FAST protocol characteristics:

Bit timing is like JVC
The header is shorter, 3156 µs vs. 12500 µs
No address and 16 bit data, interpreted as 8 bit command and 8 bit inverted command, leading to a fixed protocol length of (6 + (16 * 3) + 1) * 526 = 55 * 526 = 28930 microseconds or 29 ms.
Repeats are sent as complete frames but in a 50 ms period / with a 21 ms distance.

Sending FAST protocol with IRremote

#define IR_SEND_PIN 3
#include <IRremote.hpp>

void setup() {
  sendFAST(11, 2); // Send command 11 on pin 3 with 2 repeats.
}

void loop() {}

Sending FAST protocol with TinyIRSender

#define USE_FAST_PROTOCOL // Use FAST protocol. No address and 16 bit data, interpreted as 8 bit command and 8 bit inverted command
#include "TinyIRSender.hpp"

void setup() {
  sendFAST(3, 11, 2); // Send command 11 on pin 3 with 2 repeats.
}

void loop() {}

The FAST protocol can be received by IRremote and TinyIRReceiver.

FAQ and hints

Receiving does not run if analogWrite() or tone() is used.

The receiver sample interval of 50 µs is generated by a timer. On many boards this must be a hardware timer. On some boards where a software timer is available, the software timer is used.
Be aware that the hardware timer used for receiving should not be used for analogWrite().
On the Uno and other AVR boards the receiver timer ist the same as the tone timer, so receiving will stop after a tone() command. See ReceiveDemo example how to deal with it.

Problems with Neopixels, FastLed etc.

IRremote will not work right when you use Neopixels (aka WS2811/WS2812/WS2812B) or other libraries blocking interrupts for a longer time (> 50 µs).
Whether you use the Adafruit Neopixel lib, or FastLED, interrupts get disabled on many lower end CPUs like the basic Arduinos for longer than 50 µs. In turn, this stops the IR interrupt handler from running when it needs to. See also this video.

One workaround is to wait for the IR receiver to be idle before you send the Neopixel data with if (IrReceiver.isIdle()) { strip.show();}.
This prevents at least breaking a running IR transmission and -depending of the update rate of the Neopixel- may work quite well.
There are some other solutions to this on more powerful processors, see this page from Marc MERLIN

Does not work/compile with another library

Another library is only working/compiling if you deactivate the line IrReceiver.begin(IR_RECEIVE_PIN, ENABLE_LED_FEEDBACK);.
This is often due to timer resource conflicts with the other library. Please see below.

Multiple IR receivers

IRreceiver consists of one timer triggered function reading the digital IR signal value from one pin every 50 µs.
So multiple IR receivers can only be used by connecting the output pins of several IR receivers together. The IR receivers use an NPN transistor as output device with just a 30k resistor to VCC. This is almost "open collector" and allows connecting of several output pins to one Arduino input pin.
But keep in mind, that any weak / disturbed signal from one of the receivers will in turn also disturb a good signal from another one.

Increase strength of sent output signal

The best way to increase the IR power for free is to use 2 or 3 IR diodes in series. One diode requires 1.2 volt at 20 mA or 1.5 volt at 100 mA so you can supply up to 3 diodes with a 5 volt output.
To power 2 diodes with 1.2 V and 20 mA and a 5 V supply, set the resistor to: (5 V - 2.4 V) -> 2.6 V / 20 mA = 130 Ω.
For 3 diodes it requires 1.4 V / 20 mA = 70 Ω.
The actual current might be lower since of loss at the AVR pin. E.g. 0.3 V at 20 mA.
If you do not require more current than 20 mA, there is no need to use an external transistor (at least for AVR chips).

On my Arduino Nanos, I always use a 100 Ω series resistor and one IR LED 😀.

Minimal CPU clock frequency

For receiving, the minimal CPU clock frequency is 4 MHz, since the 50 µs timer ISR (Interrupt Service Routine) takes around 12 µs on a 16 MHz ATmega.
The TinyReceiver, which reqires no polling, runs with 1 MHz.
For sending, the default software generated PWM has problems on AVR running with 8 MHz. The PWM frequency is around 30 instead of 38 kHz and RC6 is not reliable. You can switch to timer PWM generation by #define SEND_PWM_BY_TIMER.

Bang & Olufsen protocol

The Bang & Olufsen protocol decoder is not enabled by default, i.e if no protocol is enabled explicitly by #define DECODE_<XYZ>. It must always be enabled explicitly by #define DECODE_BEO. This is because it has an IR transmit frequency of 455 kHz and therefore requires a different receiver hardware (TSOP7000).
And because generating a 455 kHz PWM signal is currently only implemented for SEND_PWM_BY_TIMER, sending only works if SEND_PWM_BY_TIMER or USE_NO_SEND_PWM is defined.
For more info, see ir_BangOlufsen.hpp.

Handling unknown Protocols

Disclaimer

This library was designed to fit inside MCUs with relatively low levels of resources and was intended to work as a library together with other applications which also require some resources of the MCU to operate.

For air conditioners see this fork, which supports an impressive set of protocols and a lot of air conditioners.

For long signals see the blog entry: "Recording long Infrared Remote control signals with Arduino".

Protocol=PULSE_DISTANCE

If you get something like this:

PULSE_DISTANCE: HeaderMarkMicros=8900 HeaderSpaceMicros=4450 MarkMicros=550 OneSpaceMicros=1700 ZeroSpaceMicros=600  NumberOfBits=56 0x43D8613C 0x3BC3BC

then you have a code consisting of 56 bits, which is probably from an air conditioner remote.
You can send it with sendPulseDistance().

uint32_t tRawData[] = { 0xB02002, 0xA010 };
IrSender.sendPulseDistance(38, 3450, 1700, 450, 1250, 450, 400, &tRawData[0], 48, false, 0, 0);

You can send it with calling sendPulseDistanceWidthData() twice, once for the first 32 bit and next for the remaining 24 bits.
The PulseDistance or PulseWidth decoders just decode a timing steam to a bit stream. They can not put any semantics like address, command or checksum on this bitstream, since it is no known protocol. But the bitstream is way more readable, than a timing stream. This bitstream is read LSB first by default. If this does not suit you for further research, you can change it here.

Protocol=UNKNOWN

If you see something like Protocol=UNKNOWN Hash=0x13BD886C 35 bits received as output of e.g. the ReceiveDemo example, you either have a problem with decoding a protocol, or an unsupported protocol.

If you have an odd number of bits received, your receiver circuit probably has problems. Maybe because the IR signal is too weak.
If you see timings like + 600,- 600 + 550,- 150 + 200,- 100 + 750,- 550 then one 450 µs space was split into two 150 and 100 µs spaces with a spike / error signal of 200 µs between. Maybe because of a defective receiver or a weak signal in conjunction with another light emitting source nearby.
If you see timings like + 500,- 550 + 450,- 550 + 500,- 500 + 500,-1550, then marks are generally shorter than spaces and therefore MARK_EXCESS_MICROS (specified in your ino file) should be negative to compensate for this at decoding.
If you see Protocol=UNKNOWN Hash=0x0 1 bits received it may be that the space after the initial mark is longer than RECORD_GAP_MICROS. This was observed for some LG air conditioner protocols. Try again with a line e.g. #define RECORD_GAP_MICROS 12000 before the line #include <IRremote.hpp> in your .ino file.
To see more info supporting you to find the reason for your UNKNOWN protocol, you must enable the line //#define DEBUG in IRremoteInt.h.

How to deal with protocols not supported by IRremote

If you do not know which protocol your IR transmitter uses, you have several choices.

Use the IRreceiveDump example to dump out the IR timing. You can then reproduce/send this timing with the SendRawDemo example. For long codes with more than 48 bits like from air conditioners, you can change the length of the input buffer in IRremote.h.
The IRMP AllProtocol example prints the protocol and data for one of the 40 supported protocols. The same library can be used to send this codes.
If you have a bigger Arduino board at hand (> 100 kByte program memory) you can try the IRremoteDecode example of the Arduino library DecodeIR.
Use IrScrutinizer. It can automatically generate a send sketch for your protocol by exporting as "Arduino Raw". It supports IRremote, the old IRLib and Infrared4Arduino.

Examples for this library

The examples are available at File > Examples > Examples from Custom Libraries / IRremote.
In order to fit the examples to the 8K flash of ATtiny85 and ATtiny88, the Arduino library ATtinySerialOut is required for this CPU's.

SimpleReceiver + SimpleSender

The SimpleReceiver and SimpleSender examples are a good starting point. A simple example can be tested online with WOKWI.

TinyReceiver + TinySender

If code size or timer usage matters, look at these examples.
The TinyReceiver example uses the TinyIRReceiver library which can only receive NEC, Extended NEC, ONKYO and FAST protocols, but does not require any timer. They use pin change interrupt for on the fly decoding, which is the reason for the restricted protocol choice.
TinyReceiver can be tested online with WOKWI.

The TinySender example uses the TinyIRSender library which can only send NEC, ONKYO and FAST protocols.
It sends NEC protocol codes in standard format with 8 bit address and 8 bit command as in SimpleSender example. It has options to send using Extended NEC, ONKYO and FAST protocols. Saves 780 bytes program memory and 26 bytes RAM compared to SimpleSender, which does the same, but uses the IRRemote library (and is therefore much more flexible).

SmallReceiver

If the protocol is not NEC and code size matters, look at this example.

ReceiveDemo + AllProtocolsOnLCD

ReceiveDemo receives all protocols and generates a beep with the Arduino tone() function on each packet received.
Long press of one IR button (receiving of multiple repeats for one command) is detected.
AllProtocolsOnLCD additionally displays the short result on a 1602 LCD. The LCD can be connected parallel or serial (I2C).
By connecting debug pin to ground, you can force printing of the raw values for each frame. The pin number of the debug pin is printed during setup, because it depends on board and LCD connection type.
This example also serves as an example how to use IRremote and tone() together.

ReceiveDump

Receives all protocols and dumps the received signal in different flavors including Pronto format. Since the printing takes much time, repeat signals may be skipped or interpreted as UNKNOWN.

SendDemo

Sends all available protocols at least once.

SendAndReceive

Demonstrates receiving while sending.

ReceiveAndSend

Record and play back last received IR signal at button press. IR frames of known protocols are sent by the approriate protocol encoder. UNKNOWN protocol frames are stored as raw data and sent with sendRaw().

ReceiveAndSendDistanceWidth

Try to decode each IR frame with the universal DistanceWidth decoder, store the data and send it on button press with sendPulseDistanceWidthFromArray().
Storing data for distance width protocol requires 17 bytes. The ReceiveAndSend example requires 16 bytes for known protocol data and 37 bytes for raw data of e.g.NEC protocol.

ReceiveOneAndSendMultiple

Serves as a IR remote macro expander. Receives Samsung32 protocol and on receiving a specified input frame, it sends multiple Samsung32 frames with appropriate delays in between. This serves as a Netflix-key emulation for my old Samsung H5273 TV.

IRDispatcherDemo

Framework for calling different functions of your program for different IR codes.

IRrelay

Control a relay (connected to an output pin) with your remote.

IRremoteExtensionTest

Example for a user defined class, which itself uses the IRrecv class from IRremote.

SendLGAirConditionerDemo

Example for sending LG air conditioner IR codes controlled by Serial input.
By just using the function bool Aircondition_LG::sendCommandAndParameter(char aCommand, int aParameter) you can control the air conditioner by any other command source.
The file acLG.h contains the command documentation of the LG air conditioner IR protocol. Based on reverse engineering of the LG AKB73315611 remote.
IReceiverTimingAnalysis can be tested online with WOKWI Click on the receiver while simulation is running to specify individual IR codes.

ReceiveAndSendHob2Hood

Example for receiving and sending AEG / Elektrolux Hob2Hood protocol.

ReceiverTimingAnalysis

This example analyzes the signal delivered by your IR receiver module. Values can be used to determine the stability of the received signal as well as a hint for determining the protocol.
It also computes the MARK_EXCESS_MICROS value, which is the extension of the mark (pulse) duration introduced by the IR receiver module.
It can be tested online with WOKWI. Click on the receiver while simulation is running to specify individual NEC IR codes.

UnitTest

ReceiveDemo + SendDemo in one program. Demonstrates receiving while sending. Here you see the delay of the receiver output (blue) from the IR diode input (yellow).

WOKWI online examples

Issues and discussions

Do not open an issue without first testing some of the examples!
If you have a problem, please post the MCVE (Minimal Complete Verifiable Example) showing this problem. My experience is, that most of the times you will find the problem while creating this MCVE 😄.
Use code blocks; it helps us to help you when we can read your code!

Compile options / macros for this library

To customize the library to different requirements, there are some compile options / macros available.
These macros must be defined in your program before the line #include <IRremote.hpp> to take effect.
Modify them by enabling / disabling them, or change the values if applicable.

Name	Default value	Description
`RAW_BUFFER_LENGTH`	100	Buffer size of raw input buffer. Must be even! 100 is sufficient for regular protocols of up to 48 bits, but for most air conditioner protocols a value of up to 750 is required. Use the ReceiveDump example to find smallest value for your requirements.
`EXCLUDE_UNIVERSAL_PROTOCOLS`	disabled	Excludes the universal decoder for pulse distance protocols and decodeHash (special decoder for all protocols) from `decode()`. Saves up to 1000 bytes program memory.
`DECODE_<Protocol name>`	all	Selection of individual protocol(s) to be decoded. You can specify multiple protocols. See here
`DECODE_STRICT_CHECKS`	disabled	Check for additional required characteristics of protocol timing like length of mark for a constant mark protocol, where space length determines the bit value. Requires up to 194 additional bytes of program memory.
`IR_REMOTE_DISABLE_RECEIVE_COMPLETE_CALLBACK`	disabled	Saves up to 60 bytes of program memory and 2 bytes RAM.
`MARK_EXCESS_MICROS`	20	MARK_EXCESS_MICROS is subtracted from all marks and added to all spaces before decoding, to compensate for the signal forming of different IR receiver modules.
`RECORD_GAP_MICROS`	5000	Minimum gap between IR transmissions, to detect the end of a protocol. Must be greater than any space of a protocol e.g. the NEC header space of 4500 µs. Must be smaller than any gap between a command and a repeat; e.g. the retransmission gap for Sony is around 24 ms. Keep in mind, that this is the delay between the end of the received command and the start of decoding.
`IR_INPUT_IS_ACTIVE_HIGH`	disabled	Enable it if you use a RF receiver, which has an active HIGH output signal.
`IR_SEND_PIN`	disabled	If specified, it reduces program size and improves send timing for AVR. If you want to use a variable to specify send pin e.g. with `setSendPin(uint8_t aSendPinNumber)`, you must not use / disable this macro in your source.
`SEND_PWM_BY_TIMER`	disabled	Disables carrier PWM generation in software and use hardware PWM (by timer). Has the advantage of more exact PWM generation, especially the duty cycle (which is not very relevant for most IR receiver circuits), and the disadvantage of using a hardware timer, which in turn is not available for other libraries and to fix the send pin (but not the receive pin) at the dedicated timer output pin(s). Is enabled for ESP32 and RP2040 in all examples, since they support PWM gereration for each pin without using a shared resource (timer).
`USE_NO_SEND_PWM`	disabled	Uses no carrier PWM, just simulate an active low receiver signal. Used for transferring signal by cable instead of IR. Overrides `SEND_PWM_BY_TIMER` definition.
`IR_SEND_DUTY_CYCLE_PERCENT`	30	Duty cycle of IR send signal.
`USE_OPEN_DRAIN_OUTPUT_FOR_SEND_PIN`	disabled	Uses or simulates open drain output mode at send pin. Attention, active state of open drain is LOW, so connect the send LED between positive supply and send pin!
`DISABLE_CODE_FOR_RECEIVER`	disabled	Disables static receiver code like receive timer ISR handler and static IRReceiver and irparams data. Saves 450 bytes program memory and 269 bytes RAM if receiving functions are not required.
`EXCLUDE_EXOTIC_PROTOCOLS`	disabled	Excludes BANG_OLUFSEN, BOSEWAVE, WHYNTER, FAST and LEGO_PF from `decode()` and from sending with `IrSender.write()`. Saves up to 650 bytes program memory.
`FEEDBACK_LED_IS_ACTIVE_LOW`	disabled	Required on some boards (like my BluePill and my ESP8266 board), where the feedback LED is active low.
`NO_LED_FEEDBACK_CODE`	disabled	Disables the LED feedback code for send and receive. Saves around 100 bytes program memory for receiving, around 500 bytes for sending and halving the receiver ISR (Interrupt Service Routine) processing time.
`MICROS_PER_TICK`	50	Resolution of the raw input buffer data. Corresponds to 2 pulses of each 26.3 µs at 38 kHz.
`TOLERANCE_FOR_DECODERS_MARK_OR_SPACE_MATCHING`	25	Relative tolerance (in percent) for matchTicks(), matchMark() and matchSpace() functions used for protocol decoding.
`DEBUG`	disabled	Enables lots of lovely debug output.
`IR_USE_AVR_TIMER*`		Selection of timer to be used for generating IR receiving sample interval.

These next macros for TinyIRReceiver must be defined in your program before the line #include <TinyIRReceiver.hpp> to take effect.

Name	Default value	Description
`IR_RECEIVE_PIN`	2	The pin number for TinyIRReceiver IR input, which gets compiled in.
`IR_FEEDBACK_LED_PIN`	`LED_BUILTIN`	The pin number for TinyIRReceiver feedback LED, which gets compiled in.
`NO_LED_FEEDBACK_CODE`	disabled	Disables the feedback LED function. Saves 14 bytes program memory.
`DISABLE_PARITY_CHECKS`	disabled	Disables the addres and command parity checks. Saves 48 bytes program memory.
`USE_EXTENDED_NEC_PROTOCOL`	disabled	Like NEC, but take the 16 bit address as one 16 bit value and not as 8 bit normal and 8 bit inverted value.
`USE_ONKYO_PROTOCOL`	disabled	Like NEC, but take the 16 bit address and command each as one 16 bit value and not as 8 bit normal and 8 bit inverted value.
`USE_FAST_PROTOCOL`	disabled	Use FAST protocol (no address and 16 bit data, interpreted as 8 bit command and 8 bit inverted command) instead of NEC.
`ENABLE_NEC2_REPEATS`	disabled	Instead of sending / receiving the NEC special repeat code, send / receive the original frame for repeat.
`USE_CALLBACK_FOR_TINY_RECEIVER`	disabled	Call the fixed function `void handleReceivedTinyIRData()` each time a frame or repeat is received.

The next macro for IRCommandDispatcher must be defined in your program before the line #include <IRCommandDispatcher.hpp> to take effect. | USE_TINY_IR_RECEIVER | disabled | Use TinyReceiver for receiving IR codes. | | IR_COMMAND_HAS_MORE_THAN_8_BIT | disabled | Enables mapping and dispatching of IR commands consisting of more than 8 bits. Saves up to 160 bytes program memory and 4 bytes RAM + 1 byte RAM per mapping entry. | | BUZZER_PIN | | If USE_TINY_IR_RECEIVER is enabled, the pin to be used for the optional 50 ms buzzer feedback before executing a command. Other IR libraries than Tiny are not compatible with tone() command. |

Changing include (*.h) files with Arduino IDE

First, use Sketch > Show Sketch Folder (Ctrl+K).
If you have not yet saved the example as your own sketch, then you are instantly in the right library folder.
Otherwise you have to navigate to the parallel libraries folder and select the library you want to access.
In both cases the library source and include files are located in the libraries src directory.
The modification must be renewed for each new library version!

Modifying compile options / macros with PlatformIO

If you are using PlatformIO, you can define the macros in the platformio.ini file with build_flags = -D MACRO_NAME or build_flags = -D MACRO_NAME=macroValue.

Modifying compile options / macros with Sloeber IDE

If you are using Sloeber as your IDE, you can easily define global symbols with Properties > Arduino > CompileOptions.

Supported Boards

Issues and discussions with the content "Is it possible to use this library with the ATTinyXYZ? / board XYZ" without any reasonable explanations will be immediately closed without further notice.

Digispark boards are only tested with ATTinyCore using New Style pin mapping for the Digispark Pro board.
ATtiny boards are only tested with ATTinyCore or megaTinyCore.

Arduino Uno / Mega / Leonardo / Duemilanove / Diecimila / LilyPad / Mini / Fio / Nano etc.
Arduino Uno R4, but not yet tested, because of lack of a R4 board. Sending does not work on the arduino:renesas_uno:unor4wifi.
Teensy 1.0 / 1.0++ / 2.0 / 2++ / 3.0 / 3.1 / 3.2 / Teensy-LC - but limited support; Credits: PaulStoffregen (Teensy Team)
Sanguino
ATmega8, 48, 88, 168, 328
ATmega8535, 16, 32, 164, 324, 644, 1284,
ATmega64, 128
ATmega4809 (Nano every)
ATtiny3217 (Tiny Core 32 Dev Board)
ATtiny84, 85, 167 (Digispark + Digispark Pro)
SAMD21 (Zero, MKR*, but not SAMD51 and not DUE, the latter is SAM architecture)
ESP8266
ESP32 (ESP32-C3 since board package 2.0.2 from Espressif) not for ESP32 core version > 3.0.0
Sparkfun Pro Micro
Nano Every, Uno WiFi Rev2, nRF5 BBC MicroBit, Nano33_BLE
BluePill with STM32
RP2040 based boards (Raspberry Pi Pico, Nano RP2040 Connect etc.)

For ESP8266/ESP32, this library supports an impressive set of protocols and a lot of air conditioners

We are open to suggestions for adding support to new boards, however we highly recommend you contact your supplier first and ask them to provide support from their side.
If you can provide examples of using a periodic timer for interrupts for the new board, and the board name for selection in the Arduino IDE, then you have way better chances to get your board supported by IRremote.

Timer and pin usage

The receiver sample interval of 50 µs is generated by a timer. On many boards this must be a hardware timer. On some boards where a software timer is available, the software timer is used.

Every pin can be used for receiving.
If software PWM is selected, which is default, every pin can also be used for sending. Sending with software PWM does not require a timer!

The TinyReceiver example uses the TinyReceiver library, which can only receive NEC codes, but does not require any timer and runs even on a 1 MHz ATtiny85.

The code for the timer and the timer selection is located in private/IRTimer.hpp. The selected timer can be adjusted here.

Be aware that the hardware timer used for receiving should not be used for analogWrite()!.

Board/CPU	Receive & send PWM Timer Default timer is bold	Hardware-Send-PWM Pin	analogWrite() pins occupied by timer
ATtiny84	1	6
ATtiny85 > 4 MHz	0, 1	0, 4	0, 1 & 4
ATtiny88 > 4 MHz	1	PB1 / 8	PB1 / 8 & PB2 / 9
ATtiny167 > 4 MHz	1	9, 8 - 15	8 - 15
ATtiny1604	TCB0	PA05
ATtiny1614, ATtiny816	TCA0	PA3
ATtiny3217	TCA0, TCD	%
ATmega8	1	9
ATmega1284	1, 2, 3	13, 14, 6
ATmega164, ATmega324, ATmega644	1, 2	13, 14
ATmega8535 ATmega16, ATmega32	1	13
ATmega64, ATmega128, ATmega1281, ATmega2561	1	13
ATmega8515, ATmega162	1	13
ATmega168, ATmega328	1, 2	9, 3	9 & 10, 3 & 11
ATmega1280, ATmega2560	1, 2, 3, 4, 5	5, 6, 9, 11, 46	5, 6, 9, 11, 46
ATmega4809	TCB0	A4
Leonardo (Atmega32u4)	1, 3, 4_HS	5, 9, 13	5, 9, 13
Zero (SAMD)	TC3	*, 9
ESP32	Ledc chan. 0	All pins
Sparkfun Pro Micro	1, 3	5, 9
Teensy 1.0	1	17	15, 18
Teensy 2.0	1, 3, 4_HS	9, 10, 14	12
Teensy++ 1.0 / 2.0	1, 2, 3	1, 16, 25	0
Teensy-LC	TPM1	16	17
Teensy 3.0 - 3.6	CMT	5
Teensy 4.0 - 4.1	FlexPWM1.3	8	7, 25
BluePill / STM32F103C8T6	3	%	PA6 & PA7 & PB0 & PB1
BluePill / STM32F103C8T6	TIM4	%	PB6 & PB7 & PB8 & PB9
RP2040 / Pi Pico	default alarm pool	All pins	No pin
RP2040 / Mbed based	Mbed Ticker	All pins	No pin

No timer required for sending

The send PWM signal is by default generated by software. Therefore every pin can be used for sending. The PWM pulse length is guaranteed to be constant by using delayMicroseconds(). Take care not to generate interrupts during sending with software generated PWM, otherwise you will get jitter in the generated PWM. E.g. wait for a former Serial.print() statement to be finished by Serial.flush(). Since the Arduino micros() function has a resolution of 4 µs at 16 MHz, we always see a small jitter in the signal, which seems to be OK for the receivers.

Software generated PWM showing small jitter because of the limited resolution of 4 µs of the Arduino core `micros()` function for an ATmega328	Detail (ATmega328 generated) showing 30% duty cycle

Incompatibilities to other libraries and Arduino commands like tone() and analogWrite()

If you use a library which requires the same timer as IRremote, you have a problem, since the timer resource cannot be shared simultaneously by both libraries.

Change timer

The best approach is to change the timer used for IRremote, which can be accomplished by specifying the timer before #include <IRremote.hpp>.
The timer specifications available for your board can be found in private/IRTimer.hpp.

// Arduino Mega
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
#  if !defined(IR_USE_AVR_TIMER1) && !defined(IR_USE_AVR_TIMER2) && !defined(IR_USE_AVR_TIMER3) && !defined(IR_USE_AVR_TIMER4) && !defined(IR_USE_AVR_TIMER5)
//#define IR_USE_AVR_TIMER1   // send pin = pin 11
#define IR_USE_AVR_TIMER2     // send pin = pin 9
//#define IR_USE_AVR_TIMER3   // send pin = pin 5
//#define IR_USE_AVR_TIMER4   // send pin = pin 6
//#define IR_USE_AVR_TIMER5   // send pin = pin 46
#  endif

Here you see the Arduino Mega board and the available specifications are IR_USE_AVR_TIMER[1,2,3,4,5].
You just have to include a line e.g. #define IR_USE_AVR_TIMER3 before #include <IRremote.hpp> to enable timer 3.

But be aware that the new timer in turn might be incompatible with other libraries or commands.
For other boards/platforms you must look for the appropriate section guarded by e.g. #elif defined(ESP32).

Stop and start timer

Another approach can be to share the timer sequentially if their functionality is used only for a short period of time like for the Arduino tone() command. An example can be seen here, where the timer settings for IR receive are restored after the tone has stopped. For this we must call IrReceiver.restartTimer() or better IrReceiver.restartTimer(microsecondsOfToneDuration).
This only works since each call to tone() completely initializes the timer 2 used by the tone() command.

Hardware-PWM signal generation for sending

If you define SEND_PWM_BY_TIMER, the send PWM signal is forced to be generated by a hardware timer on most platforms.
By default, the same timer as for the receiver is used.
Since each hardware timer has its dedicated output pin(s), you must change timer or timer sub-specifications to change PWM output pin. See private/IRTimer.hpp
Exeptions are currently ESP32, ARDUINO_ARCH_RP2040, PARTICLE and ARDUINO_ARCH_MBED, where PWM generation does not require a timer.

Why do we use 30% duty cycle for sending

We do it according to the statement in the Vishay datasheet:

Carrier duty cycle 50 %, peak current of emitter IF = 200 mA, the resulting transmission distance is 25 m.
Carrier duty cycle 10 %, peak current of emitter IF = 800 mA, the resulting transmission distance is 29 m. - Factor 1.16 The reason is, that it is not the pure energy of the fundamental which is responsible for the receiver to detect a signal. Due to automatic gain control and other bias effects, high intensity of the 38 kHz pulse counts more than medium intensity (e.g. 50% duty cycle) at the same total energy.

How we decode signals

The IR signal is sampled at a 50 µs interval. For a constant 525 µs pulse or pause we therefore get 10 or 11 samples, each with 50% probability.
And believe me, if you send a 525 µs signal, your receiver will output something between around 400 and 700 µs!
Therefore we decode by default with a +/- 25% margin using the formulas here.
E.g. for the NEC protocol with its 560 µs unit length, we have TICKS_LOW = 8.358 and TICKS_HIGH = 15.0. This means, we accept any value between 8 ticks / 400 µs and 15 ticks / 750 µs (inclusive) as a mark or as a zero space. For a one space we have TICKS_LOW = 25.07 and TICKS_HIGH = 45.0.
And since the receivers generated marks are longer or shorter than the spaces, we have introduced the MARK_EXCESS_MICROS macro to compensate for this receiver (and signal strength as well as ambient light dependent 😞 ) specific deviation.
Welcome to the world of real world signal processing.

NEC encoding diagrams

Created with sigrok PulseView with IR_NEC decoder by DjordjeMandic.
8 bit address NEC code 16 bit address NEC code

Quick comparison of 5 Arduino IR receiving libraries

This is a short comparison and may not be complete or correct.

I created this comparison matrix for myself in order to choose a small IR lib for my project and to have a quick overview, when to choose which library.
It is dated from 24.06.2022 and updated 10/2023. If you have complains about the data or request for extensions, please send a PM or open a discussion.

Here you find an ESP8266/ESP32 version of IRremote with an impressive list of supported protocols.

Subject	IRMP	IRLremote	IRLib2 mostly unmaintained	IRremote	TinyIR	IRsmallDecoder
Number of protocols	50	Nec + Panasonic + Hash *	12 + Hash *	17 + PulseDistance + Hash *	NEC + FAST	NEC + RC5 + Sony + Samsung
Timing method receive	Timer2 or interrupt for pin 2 or 3	Interrupt	Timer2 or interrupt for pin 2 or 3	Timer2	Interrupt	Interrupt
Timing method send	PWM and timing with Timer2 interrupts	Timer2 interrupts	Timer2 and blocking wait	PWM with Timer2 and/or blocking wait with delay Microseconds()	blocking wait with delay Microseconds()	%
Send pins	All	All	All ?	Timer dependent	All	%
Decode method	OnTheFly	OnTheFly	RAM	RAM	OnTheFly	OnTheFly
Encode method	OnTheFly	OnTheFly	OnTheFly	OnTheFly or RAM	OnTheFly	%
Callback support	x	%	%	x	x	%
Repeat handling	Receive + Send (partially)	%	?	Receive + Send	Receive + Send	Receive
LED feedback	x	%	x	x	Receive	%
FLASH usage (simple NEC example with 5 prints)	1820 (4300 for 15 main / 8000 for all 40 protocols) (+200 for callback) (+80 for interrupt at pin 2+3)	1270 (1400 for pin 2+3)	4830	1770	900	?1100?
RAM usage	52 (73 / 100 for 15 (main) / 40 protocols)	62	334	227	19	29
Supported platforms	avr, megaavr, attiny, Digispark (Pro), esp8266, ESP32, STM32, SAMD 21, Apollo3 (plus arm and pic for non Arduino IDE)	avr, esp8266	avr, SAMD 21, SAMD 51	avr, attiny, esp8266, esp32, SAM, SAMD	All platforms with attach Interrupt()	All platforms with attach Interrupt()
Last library update	5/2023	4/2018	11/2022	9/2023	5/2023	2/2022
Remarks	Decodes 40 protocols concurrently. 39 Protocols to send. Work in progress.	Only one protocol at a time.	Consists of 5 libraries. *Project containing bugs - 63 issues, 10 pull requests.	Universal decoder and encoder. Supports Pronto codes and sending of raw timing values.	Requires no timer.	Requires no timer.

* The Hash protocol gives you a hash as code, which may be sufficient to distinguish your keys on the remote, but may not work with some protocols like Mitsubishi

Useful links

License

Up to the version 2.7.0, the License is GPLv2. From the version 2.8.0, the license is the MIT license.

Copyright

Initially coded 2009 Ken Shirriff http://www.righto.com
Copyright (c) 2016-2017 Rafi Khan
Copyright (c) 2020-2024 Armin Joachimsmeyer

arduino-irremote's People

Contributors

Stargazers

Watchers

Forkers

paul-sh toddtreece zenwheel edtler ashishmody homecontrol sept0r chicagozer coopermaa mrscotty neopunisher thorsten-sick fpo hansgit alexbain ktorn soojinhan microtherion shineangelic hholzgra supersidor alberanid tomovwgti ronaldpatino sudar marco-jardim mharizanov eduardoa xenomachina nusid-c0de garthoff mocy rusgon thailsantunes rbigelow matthewaj g1pete erix elpsk chlopakrzeznika itoutline netconstructor remotecontrol brightmaan jufow vocalfolds alex96t eugenevlasyuk vinny1948 rickyrounds toshsan buildcircuit dbeckx rondoggie paulstoffregen cj7jeep1983 pietro66 alfredfahrenholz raghumulukutla lgroeb dometec blaines-dupes kukulski mpflaga chelland tomeu99 anujjamwal davidpitkin ehcabarete vovazubko kasbert marco-loche fabinho8877 arachnid olivierwong noxcionum nuwud peter52 rickfranchi vikkykiller shengyu7697 robodon4000 aguegu carloseulalio70 arnhat gassig robertorossi335501 gorlinker exidyboy rafaalves steveroot roiles asifrizwanubx cibernetician santilucas szilagyi-raul smarttextile ahmetalpat sharnett rougelong

arduino-irremote's Issues

DisableIRIn() command doesn't work Attiny85

Board: Attiny85
Protocol: Not Sure

Code Block:

#include < IRremote.h >

const int RECV_PIN = PB2; // Recving pin for IR light
volatile IRrecv irrecv(RECV_PIN); // Setting up the IR decoding
volatile decode_results results; // More set up

void setup() {
	// put your setup code here, to run once:
	pinMode(PB3, OUTPUT);
	irrecv.enableIRIn();
	irrecv.disableIRIn();
}

void loop() {

	unsigned long i = millis();

	delay(100);

	if (millis() > i) {
		digitalWrite(PB3, HIGH);
	}
}

I wrote this simple code to test if millis() worked properly with IRremote.h. I soon discovered that it doesn't work if I do enableIRIn(). I bellieve this is because the receiving software uses the same clock as millis(). I was wondering if I could use the disableIRIn() command so that I could only have the receiver on when I need it so that I could use millis() the rest of the time. I ran the test above to see if the disable command allowed me to use millis(). It doesn't let me use millis(). I belleive this is a bug because I can use millis() if I never enable, so disabling it should bring me back to the state I was in before enabling and I should be able to use it like before. That does not happen leading me to think this is a bug. Please let me know if I am just doing something wrong.

BTW, when millis() didn't work the if statement condition returned false and the led did not light.

Removing ASCII "art"?

I am not really a fan of art in plain text, especially not in source code. I would like to remove the large headings in files (see screenshot) if no one is opposed.

Suggested alternative....

Possible bug in AIWA send() function

I cannot for the life of me work out how to add the "write code" tag - help!

See inline comment:

//-v- THIS CODE LOOKS LIKE IT MIGHT BE WRONG
//    it only sends 15bits and ignores the top bit
//    then uses TOPBIT which is bit-31 to check the bit code
//    ...because of how codes are built by the receiver
//    I suspect "TOPBIT" should be changed for "0x00008000"
//    Of course, if this code is known to work, then I am clearly wrong
//    but I have nothing with which to test it :/
  // Skip firts code bit     
  code <<= 1;
  // Send code
  for (i = 0;  i < 15;  i++) {
    mark(AIWA_RC_T501_BIT_MARK);
    if (code & TOPBIT)  space(AIWA_RC_T501_ONE_SPACE) ;
    else                space(AIWA_RC_T501_ZERO_SPACE) ;
    code <<= 1;
  }         
//-^- THIS CODE LOOKS LIKE IT MIGHT BE WRONG

Support for Nano 33 IoT and other SAMD based boards

Just tested this library with a Nano 33 IoT board, it works like a charm!

Can you please add details (ex. PIN) in the README?

Library Goals Statement

Need to create some sort of goal statement so that it is clear what the intent of this library is. This is mainly to distinguish between what is and is not within the scope of this library/

#386 @z3t0

Unexpected codeType 5 and 11 on Hisense AC remote

Hi,
I am using example IRrecord.ino
When I press the button on the remote, it shows:

Sometimes it shows:

 m3350 s1750 m350 s450 m400 s450 m400 s450 m350 s500 m350 s500 m350 s500 m350 s1350 m300 s500 m350 s500 m350 s500 m350 s500 m350 s500 m350 s500 m350 s450 m400 s450 m400 s450 m350 s500 m350 s500 m350 s1350 m350 s450 m350 s1350 m350 s500 m350 s500 m350 s450 m400 s450 m350 s500 m350 s500 m350 s500 m350 s500 m350 s500 m350 s500 m350 s1300 m350 s1300 m400 s1300 m350 s500 m350 s500 m350 s500 m350 s450 m400 s1300 m350 s500 m350 s500 m350 s1300 m350 s500 m350 s500 m350 s500 m350 s500 m350 s1300 m350 s500 m350 s500

but most time it shows Unexpected codeType 5 and 11

Using IRrecvDumpV2
IR code too long. Edit IRremoteInt.h and increase RAWLEN

     +3450, -1650     + 450, - 400     + 450, - 400     + 450, - 400
     + 450, - 350     + 500, - 350     + 450, - 400     + 450, -1250
     + 450, - 350     + 500, - 350     + 500, - 350     + 450, - 400
     + 450, - 400     + 450, - 400     + 450, - 400     + 450, - 400
     + 450, - 400     + 450, - 350     + 500, - 350     + 450, -1250
     + 450, - 400     + 450, -1200     + 450, - 400     + 450, - 400
     + 450, - 400     + 450, - 400     + 450, - 350     + 500, - 350
     + 500, - 350     + 450, - 400     + 450, - 400     + 450, - 400
     + 450, -1250     + 450, -1200     + 450, -1200     + 500, - 350
     + 450, - 400     + 450, - 400     + 450, - 400     + 450, -1250
     + 400, - 400     + 450, - 400     + 450, -1250     + 450, - 350
     + 500, - 350     + 450, - 400     + 450, - 400     + 450, -1250
     + 450, - 350     + 450, - 400
unsigned int  rawData[100] = {3450,1650, 450,400, 450,400, 450,400, 450,350, 500,350, 450,400, 450,1250, 450,350, 500,350, 500,350, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,350, 500,350, 450,1250, 450,400, 450,1200, 450,400, 450,400, 450,400, 450,400, 450,350, 500,350, 500,350, 450,400, 450,400, 450,400, 450,1250, 450,1200, 450,1200, 500,350, 450,400, 450,400, 450,400, 450,1250, 400,400, 450,400, 450,1250, 450,350, 500,350, 450,400, 450,400, 450,1250, 450,350, 450,400 };  // UNKNOWN DABAE293

Encoding  : UNKNOWN
Code      : FCABFFBF (32 bits)
Timing[5]: 
     + 550, - 350     +1200, - 750     + 250
unsigned int  rawData[5] = {550,350, 1200,750, 250};  // UNKNOWN FCABFFBF

Transmit timing is sensitive to other library ISR

The mark() and space() functions use delayMicroseconds(), which is only accurate when no other libraries are consuming much CPU time in their interrupts.

Someday, I'm going to redesign the transmission code to use the timer ISR to enable/disable the PWM output, for reliably transmit timing even when other libraries consume significant CPU time.

This issue is mainly just a reminder to myself to work on this someday....

JVC commands need to be sent three times

This is just to let others know that some JVC devices (in my case, a 2007 JVC TFT TV) apparently ignore commands if they are not sent three times with appropriate timing in between. To me this was not clear from reading the JVC spec at http://support.jvc.com/consumer/support/documents/RemoteCodes.pdf so I spent a lot of time and in the end found the solution by comparing what the original remote sends to what the sketch sends using a USB sound card "oscilloscope" and Audacity.

Here is code that works for me:

// Mute = 0xC038 (command needs to be sent three times!) - works
unsigned int jvc[104] =  {
8400, 4220,                               // Header
527, 1583, 527, 1583, 527, 527, 527, 527, // 1100 =, 0xC
527, 527, 527, 527, 527, 527, 527, 527,   // 0000 =, 0x0
527, 527, 527, 527, 527, 1583, 527, 1583, // 0011 =, 0x3
527, 1583, 527, 527, 527, 527, 527, 527,  // 1000 =, 0x8
527, 75000,                               // Pause
527, 1583, 527, 1583, 527, 527, 527, 527, // 1100 =, 0xC
527, 527, 527, 527, 527, 527, 527, 527,   // 0000 =, 0x0
527, 527, 527, 527, 527, 1583, 527, 1583, // 0011 =, 0x3
527, 1583, 527, 527, 527, 527, 527, 527,  // 1000 =, 0x8
527, 75000,                               // Pause
527, 1583, 527, 1583, 527, 527, 527, 527, // 1100 =, 0xC
527, 527, 527, 527, 527, 527, 527, 527,   // 0000 =, 0x0
527, 527, 527, 527, 527, 1583, 527, 1583, // 0011 =, 0x3
527, 1583, 527, 527, 527, 527, 527, 527,  // 1000 =, 0x8
527, 75000                                // Footer
};

Or, using the built-in function:

void sendJVC(long command)
{
  // JVC commands need to be sent three times with 75 ms pause in between
  irsend.sendJVC(command, 16, 0); // 0 = with lead-in
  delayMicroseconds(75); 
  irsend.sendJVC(command, 16, 1); // 1 = without lead-in
  delayMicroseconds(75); 
  irsend.sendJVC(command, 16, 1); 
}

Interruptdriven signal reception

@marcmerlin wrote in #437 (which was unfortunately OT there)

I was wondering why it was based on a timer that fires no matter what, vs a pin interrupt that would only fire each time the IR signal toggles from low to high or high to low. Is it because on some AVR chips it's just difficult to do this on any pin while on newer chips per pin interrupts are trivial?
If so, I can see that having 2 versions of the IR receive code, one that is designed to work on pin level change and counting time between each interrupt, vs the one that fires on interval and samples the pin, would probably not be very desirable since it would be 2 different code bases.

(The correct term for "no matter what" is "equidistant sampling".)

IMHO, there is no fundamental problems implementing interrupt driven signal reception. IIRC, it is already done in Chris Young's IRLib. The main drawback is that you introduce new hardware dependencies, a timer and corresponding hardware pin. (OK, the Due is different in that it allows "arbitrary" allocations, are there others?)

Having said that, the architecture of IRremote makes it very problematic with alternative implementations, have to work with ugly conditional compilation. This is in comparison with an object-oriented approach like in my Infrared4Arduino; you can, at least in principle, add a class as "sibling" to the sampling implementation, cf. this picture. The user can then decide which one of the concrete classes to instantiate.

Simplified API

Discussion on a proposed API

IRSend irsend(pin); // Create send object on pin, need to figure out the pin part though...
irsend.start(); // enable sending
irsend.mark(uint us, uint khz);
irsend.space(uint us, uint khz);
irsend.stop() // clean up use of timer, other applications can do what they want here.
irsend.sendRaw(uint[] data, uint len, uint khz); // data is an array with the data
IRrecv irrecv(pin); // Create recv object
IRrecv.start(&uint[] recv_data); // pass a pointer to the place to save it
IRrecv.stop();

Coding standards

use platform independent types C99

Features

There should be a function for just getting the raw microsecond data, without the decoding attempts (presentyl possibly only by fiddling with the preprocessor symbols).
Presently, the [0] entry is junk (yes, I know what it means physically, still it is junk).
The amount of time waited until the signal was considered ended should be the last entry.
The timeouts at the beginning and at the end (see previous item) should be (runtime) configurable.
Preferrable also the length of the received data (RAWBUF).
User-level method of getting the durations in microseconds (presently must multiply by USECPERTICK)

All "protocol" implementations will be separate from the implementation of the library itself, this still needs to be discussed but one possible solution is to simply provide them all as example sketches. This might also be the best option consider end user ease of use.

One of the main goals here is to support multiple receivers and senders from the same device

Speed of receiver does not match speed of transmitter

Board

IDE

Protocol

Code Block:


<script `src="https://gist.github.com/MTRobin/38f45c1352e9ca6857294524b732aa71.js"></script>`

.....

Use a gist if the code exceeds 30 lines

checklist:

I have read the README.md file thoroughly
I have searched existing issues to see if there is anything I have missed.
The latest repo version is used
Any code referenced is provided and if over 30 lines a gist is linked INSTEAD of it being pasted in here
The title of the issue is helpful and relevant

**I have one Arduino Uno sending a hex value every 30 milliseconds via NEC over IR. I have another Arduino Uno receiving those values and then changing the color of an RGB LED based on what hex value is sent. This is all working fine, except the receiving unit doesn't look like it is changing the LED every 30 milliseconds. It is slower. Is it possible to speed up the turnaround time between receiving the IR command and telling the LED what color to be?

On a similar note, I would like to send faster than 30 milliseconds, but if I go below 25 milliseconds the receiver doesn't show the right values and the protocol becomes unknown.

Thank you,
Maxwell**

999 Stars

Just wanted to make a quick issue to celebrate the fact that we have 999 stars!

All thanks go to the contributors!

@shirriff @Informatic @fmeschia @PaulStoffregen @crash7 @zenwheel @Neco777 @Lauszus @csBlueChip @joshuajnoble @sstefanov @levsa

AND EVERYONE ELSE I MISSED... feel free to comment and let me know.

IR receiver board inverts output

I purchased a RobotDyne IR receiver mini-board which has an external output driver/inverter transistor. Schematic available from Addicore: https://www.addicore.com/RobotDyn-Digital-IR-Receiver-p/ad504.htm After much futzing, I finally figured out your code expects a MARK=0 and SPACE=1 output. The RobotDyn board is inverted from that: MARK=1 and SPACE=0 output. Perhaps mention this somewhere obvious? Maybe make the following changes?

In the examples add:
// #define IR_REC_INVERTED // uncomment this line if your receiver has an external output driver transistor / inverted ouput

In IRremoteInt.h change lines 111 - 115 from

//------------------------------------------------------------------------------
// IR detector output is active low
//
#define MARK   0 ///< Sensor output for a mark ("flash")
#define SPACE  1 ///< Sensor output for a space ("gap")

// IR receivers on a board with an external output transistor may have inverted output
#ifdef IR_REC_INVERTED
// IR detector output is active high 
#define MARK   1 ///< Sensor output for a mark ("flash")
#define SPACE  0 ///< Sensor output for a space ("gap")
#else
// IR detector output is active low
#define MARK   0 ///< Sensor output for a mark ("flash")
#define SPACE  1 ///< Sensor output for a space ("gap")
#endif
```
Thank you for supplying this great code!

Discussion: Open Source Alternative to Analysir

@zenwheel @DaAwesomeP @sEpt0r @joshuajnoble @sstefanov @levsa @pcoughlin @csBlueChip @crash7 @mariocarta @cyborg5

Open Source Alternative to Analysir

NOTE: This initial post will continue to be updated as I further iron out my ideas and gather other ideas from everyone else.

First of all let me just make it clear that I do not mean to offend @AnalysIR as they work on an amazing project which, I am CERTAIN, is useful to many people. However, I have come to realize that there are likely to be many people out there who would be interested in an open source alternative which has support.

I was thinking it would be an interesting project to work on and would allow the community to add their own contributions. Also this project would mainly be community driven and of course it would be free, although donations would probably be welcome (I am not sure of this yet).

If you are interested or have any ideas I would love to hear them.

Features

Open Source Code and Hardware Designs(Either MIT or GPLv3)
Official Support from Arduino IRremote (this name may change as I am considering merging efforts with @cyborg5)
Cross Platform Support: I know that one of the many shortcomings of Analysir is the fact that it only works on windows. I have reached out to them offering to help support other operating systems, but they have responded claiming that the cost would be too much. This is completely understandable. However, this open source project would have Cross-Platform support at the forefront.

Cons

Community Driven: This is not exactly a con but rather here to point out that the project will only stay alive so long as there are others out there supporting it, whereas Analysir is maintained by a group of developers who are dedicated to delivering the best service/product for their customers.

UPDATE: I thought I would go head and have a shot and starting the project, my efforts can be followed here. Until other people show interest, this will mostly be a pet project.
Thank you for reading!

Commodore Amiga CD-TV Protocol

Hi, first of all many thanks for this great library! I am looking for someone that is willing to implement the IR-based "Commodore CDTV Remote Control Protocol". It is a proprietary protocol. I don't have an oscilloscope for analysis and I would not be capable of doing the job even if I would have one. But I could provide a CDTV controller for testing.

I have tested the remote control with this library's the NEC protocol. Button presses are recognized quite well, but there's a problem with the repeat signal, it's somehow not reliably detected by the library (I get the repeat signal only from time to time when holding a button pressed).

Resources I have found so far:

Someone that is willing to implement the CDTV protocol :-) ?

WiFi broken on ESP32 if IRremote used

Board: ESP32
Library Version: 2.3.3
Protocol: Sony (if any)

Code Block:

#include <WiFi.h>
#include <IRremote.h>

IRrecv irrecv(16);

const char * ssid = "network";
const char * password = "password";

void setup(){
   Serial.begin(115200);
   Serial.println("----------Program Start ------------");
   
   delay(10);
   irrecv.enableIRIn();

   Serial.print("Connecting to ");
   Serial.println(ssid);

   WiFi.begin(ssid, password);

   while (WiFi.status() != WL_CONNECTED) {
       delay(500);
       Serial.print(".");
   }
   Serial.println("Success");
 }
 
 void loop() {}

Produces this output:

Executing task: platformio device monitor <

--- Miniterm on /dev/cu.SLAB_USBtoUART 115200,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0008,len:8
load:0x3fff0010,len:160
load:0x40078000,len:10632
load:0x40080000,len:252
entry 0x40080034
----------Program Start ------------
Connecting to network
Guru Meditation Error: Core 1 panic'ed (Cache disabled but cached memory region accessed)
Register dump:
PC : 0x400dc5dc PS : 0x00060034 A0 : 0x40081c69 A1 : 0x3ffc0be0
A2 : 0x00000001 A3 : 0x00000002 A4 : 0x000000ff A5 : 0x40085f48
A6 : 0x00000001 A7 : 0x3ffcccb0 A8 : 0x800832ac A9 : 0xe00a1400
A10 : 0x00000000 A11 : 0x3ffc1480 A12 : 0x20000000 A13 : 0x00000001
A14 : 0x00000400 A15 : 0x00060523 SAR : 0x00000017 EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000 LBEG : 0x40001609 LEND : 0x4000160d LCOUNT : 0x00000000

Backtrace: 0x400dc5dc:0x3ffc0be0 0x40081c69:0x3ffc0c00

CPU halted.

Lasetag Manchester protocol: UNKNOWN Command, each time different raw data

Dear community, first of all THANKS A LOT for this great library!! It helped me a lot with various projects. For the last weeks I tried to figure out how to decode an unknown IR signal, hope you can help. (I don't need to resend it, just recognize different signals.) Every time the data seems to be different although it is the same button/device.

Attached you find the raw data of a few attempts. Thanks in advance!!!

`Encoding : UNKNOWN
Code : 74074BF7 (32 bits)
Timing[23]:
+ 350, - 200 + 450, - 400 + 300, - 250 + 400, - 200
+ 500, - 300 + 300, - 350 + 400, - 150 + 450, - 400
+ 250, - 350 + 400, - 150 + 450, - 650 + 750
unsigned int rawData[23] = {350,200, 450,400, 300,250, 400,200, 500,300, 300,350, 400,150, 450,400, 250,350, 400,150, 450,650, 750}; // UNKNOWN 74074BF7

Encoding : UNKNOWN
Code : 7FE2F6FE (32 bits)
Timing[23]:
+ 250, - 400 + 400, - 200 + 400, - 350 + 350, - 250
+ 400, - 200 + 450, - 400 + 250, - 350 + 350, - 200
+ 400, - 450 + 250, - 350 + 400, - 600 + 650
unsigned int rawData[23] = {250,400, 400,200, 400,350, 350,250, 400,200, 450,400, 250,350, 350,200, 400,450, 250,350, 400,600, 650}; // UNKNOWN 7FE2F6FE

Encoding : UNKNOWN
Code : DAC7D8ED (32 bits)
Timing[23]:
+ 400, - 200 + 350, - 450 + 300, - 250 + 400, - 250
+ 400, - 400 + 300, - 300 + 400, - 200 + 400, - 400
+ 300, - 300 + 400, - 200 + 350, - 750 + 600
unsigned int rawData[23] = {400,200, 350,450, 300,250, 400,250, 400,400, 300,300, 400,200, 400,400, 300,300, 400,200, 350,750, 600}; // UNKNOWN DAC7D8ED

Encoding : UNKNOWN
Code : 12C2E8A1 (32 bits)
Timing[23]:
+ 400, - 250 + 350, - 450 + 300, - 200 + 450, - 250
+ 400, - 350 + 300, - 300 + 400, - 200 + 400, - 450
+ 300, - 250 + 400, - 200 + 350, - 750 + 700
unsigned int rawData[23] = {400,250, 350,450, 300,200, 450,250, 400,350, 300,300, 400,200, 400,450, 300,250, 400,200, 350,750, 700}; // UNKNOWN 12C2E8A1

Encoding : UNKNOWN
Code : CC6DE2E9 (32 bits)
Timing[23]:
+ 400, - 200 + 350, - 500 + 250, - 300 + 400, - 200
+ 350, - 450 + 250, - 350 + 300, - 350 + 350, - 400
+ 250, - 350 + 400, - 200 + 400, - 700 + 750
unsigned int rawData[23] = {400,200, 350,500, 250,300, 400,200, 350,450, 250,350, 300,350, 350,400, 250,350, 400,200, 400,700, 750}; // UNKNOWN CC6DE2E9

Encoding : UNKNOWN
Code : BD36B682 (32 bits)
Timing[23]:
+ 300, - 300 + 400, - 300 + 350, - 400 + 300, - 200
+ 450, - 300 + 350, - 400 + 250, - 350 + 350, - 300
+ 350, - 400 + 250, - 350 + 400, - 650 + 650
unsigned int rawData[23] = {300,300, 400,300, 350,400, 300,200, 450,300, 350,400, 250,350, 350,300, 350,400, 250,350, 400,650, 650}; // UNKNOWN BD36B682`

What is the purpose of the Pronto protocol?

I am trying to determine what Pronto is and whether it should be removed, or better documented

ESP32 - BLE callback

Board

Protocol

Code Block:

gist

checklist:

I have read the README.md file thoroughly
I have searched existing issues to see if there is anything I have missed.
The latest release is used
Any code referenced is provided and if over 30 lines a gist is linked INSTEAD of it being pasted in here
The title of the issue is helpful and relevant

Hi all,

I'm struggling with my implementation of a bluetooth controlled esp32 remote control.

Everything seems to work as far as I expect it to work but something strange is happening if I try to send the IR commands from the BLE callback in line 43 or 58.

If I send the power command from the "loop" function (line 25), it works as expected. If I call the same function from the callback class, it outputs the expected output in the serial console but does not send the ir command.

Send Logitech Command 128 0    // loop: works
Send Logitech Command 128 0    // loop: works
onRead POWER UUID
Send Logitech Command 128 0    // callback line 43: not working
new value: 10
DETECTED POWER UUID
Send Logitech Command 128 0    // callback line 58: not working

Did someone had any similar problem or knows how to call it from within a callback/ class properly?

Ethernet.h does not work well when IRremote.h is added

Hi,

I am trying to write a software that uses Ethernet shield with (Ethernet.h library) and infrared emitter

The network part works fine but it seems memory gets corrupted as soon as I just add IRremote.h

Am I missing something?

Thanks you

How do the codes read here relate to HEX codes found on the internet?

Hi, I want to use your library to read codes I need to translate later to an on/off pattern. The HEX codes given on the internet, e.g. https://www.remotecentral.com/cgi-bin/codes/ have that information. I wonder how the codes you produce relate either to the HEX codes, or to on/off cycles. Can you shed some light onto it? Thanks, K.

Documenting Protocol Implementations

This issue documents the need to create a wiki/document explaining the technical specifications of all support. There are a few options for this, we can write the documentation in the existing wiki provided by GitHub for this repository, we could write it using a service such as readthedocs, or we could simply write it in a folder in the existing repository.

Obtaining sendNEC remote codes from an LIRC file

Board: ARDUINO UNO
Library Version: 2.1.0
Protocol: NEC (if any)

I'm trying (and failing) to send codes using irsend.sendNEC. I'm fairly sure the issue is with the codes I'm using. I've got the codes for my remote from this:
LIRC FILE

I'm attempting to send the codes using:
irsend.sendNEC(code, 16);

where code is one of the hex codes in the 'begin codes' section of the LIRC file.
After a bit of digging around, I found this:
Blog Article

Which makes me think that I need to something with the numbers in the header field, but I can't quite work out how I combine that with the hex code and convert it all into a code that sendNEC can use.

If anyone can help steer me down the right path it'd be much appreciated.

Many thanks.

FastLED and IR

This will not work with the adafruit neopixel lib because it disables interrupts altogether

If you use FastLED instead, and that one has more platform specific code. Specifically for teensy 3.1, due, and other ARM (not AVR) 32bit CPUs, it re-enables interrupts in the middle of updating pixels. Those CPUs are fast enough that they are waiting before sending the next signal to the neopixel line, and during that time, there is just enough time for the infrared ISR to run
I have tested with a teensy 3.1, and IR + neopixel, and it works fine.
My code: https://github.com/marcmerlin/Neopixel-IR

I also got it to work on ESP2866, but I'm not exactly sure how/why it works. however, one needs to use this fork of IRRemote: https://github.com/markszabo/IRremoteESP8266

ESP32 will also work because it can talk to neopixels using the RMT hardware support which works independently from the CPU and therefore does not require interrupts to be ever stopped.
On ESP32, you should use https://github.com/MartyMacGyver/ESP32-Digital-RGB-LED-Drivers for neopixels since they're not supported in fastLED. This works fine at the same time than IRRemote

Significant updates coming along

Information

This issue is to note that I will be spending a significant amount of time over the next three weeks to add features, documentation and guides/tutorials to this library.

If anyone has any requests then I would love to add it to my list below. I will also be looking through past issues/tasks that have been requested, though repeating anything important will bring it to the front of my mind.

Below are some ideas and at the bottom of the issue is going to be a list of tasks I will continue to update.

Ideas

These are some ideas for features that I would like to incorporate. They are up for discussion and may not be very realistic.

Protocol code generator: I would like to use a single file as a database of protocol implementations in a format such as IRP notation. Then we could write a script / program to parse this information and generate the protocol specific code for this library. This means there will be an extra build step when releasing the library, but the end user will receive a fully working copy of the library with the protocol files as generated source code.

Tasks

The following are tasks that will be completed, roughly in the order presented. As I begin each task, or extensive discussion is required I will be creating new issues and provided the links in the relevant parts of this document.

Mentioning important contributors for their thoughts @bengtmartensson @AnalysIR @MCUdude @crankyoldgit @AbelHu @electronicdrops

Adding more authorized contributors

Hi all!

I greatly appreciate all the effort put into this project by members at all levels, including programmers, testers and users who provide valuable feedback. Clearly, I have fallen behind quite a bit in the development and PR merging phases. However, this is just how open source projects tend to go as everyone here is a volunteer working on their own time and for free.

I would like to open up the floor to promote some of the core contributors to being authorized to directly accept PRs and add commits to the repository. This way the project can continue to grow at a faster pace and will have more than just one contributor involved in the final release process.

The only requirement is that you have spent a reasonable amount of time being visible in this project. Either by supporting other users, submitting PRs, or testing the library.

sonySend() format and how to convert it from Pronto IR codes

Protocol: Sony 12
Hello, I am currently sending the example code to my Sony tv succesfully.
"sendSony(0xa90, 12)". it turns on and of my TV. But when looking for ir codes online they are in pronto hex format.
this is supposedly the code to turn on and off sony tv's: "0000 0068 0000 000D 0060 0018 0030 0018 0018 0018 0030 0018 0018 0018 0030 0018 0018 0018 0018 0018 0030 0018 0018 0018 0018 0018 0018 0018 0018 0408",

which looks nothing like "0xa90".
I searched through here and online and the irdb converter does not produce anything that looks like what i'm supposed to send.
I have downloaded irScrutinizer as suggested in a different thread and do not see how it can get me any closer to the "0xa90" piece I need
Can anyone help me in understanding how to convert these codes?

Project Transfer

Hi,

As you may have realized I have become very busy lately and so will be unable to maintain this project in the foreseeable future, would anyone be interested in maintaining this project? Thanks and I apologize for the inconvenience.

Please email me [email protected] if interested

Add Support Vivo/GVT IR - unsolved

I am trying to implement support for Vivo IR.

What I got from IRrecvDumpV2, from pressing the same button "1".

Encoding  : UNKNOWN
Code      : 95ABCFC5 (32 bits)
Timing[35]: 
     + 500, - 250     + 200, - 200     + 200, - 550     + 250, - 400
     + 200, - 200     + 250, - 500     + 250, - 200     + 250, - 200
     + 250, - 200     + 200, - 550     + 250, - 550     + 200, - 400
     + 200, - 550     + 200, - 250     + 200, - 250     + 200, - 250
     + 200, - 350     + 250
unsigned int  rawData[35] = {500,250, 200,200, 200,550, 250,400, 200,200, 250,500, 250,200, 250,200, 250,200, 200,550, 250,550, 200,400, 200,550, 200,250, 200,250, 200,250, 200,350, 250};  // UNKNOWN 95ABCFC5

Encoding  : UNKNOWN
Code      : D7135515 (32 bits)
Timing[35]: 
     + 500, - 200     + 250, - 200     + 200, - 600     + 200, - 400
     + 200, - 200     + 250, - 500     + 250, - 250     + 200, - 200
     + 200, - 250     + 200, - 250     + 200, - 550     + 200, - 400
     + 200, - 550     + 250, - 200     + 250, - 200     + 200, - 250
     + 200, - 400     + 250
unsigned int  rawData[35] = {500,200, 250,200, 200,600, 200,400, 200,200, 250,500, 250,250, 200,200, 200,250, 200,250, 200,550, 200,400, 200,550, 250,200, 250,200, 200,250, 200,400, 250};  // UNKNOWN D7135515

What I get from AnalysIR:

Code for the button "1", same code if you press twice.

Raw: (107) 428, 268, 172, 268, 176, 624, 152, 436, 176, 264, 180, 596, 176, 268, 176, 288, 152, 268, 176, 624, 152, 600, 176, 436, 176, 600, 176, 268, 172, 268, 176, 268, 176, 432, 176, 24480, 428, 264, 180, 264, 180, 616, 156, 432, 176, 268, 176, 600, 176, 288, 156, 264, 180, 264, 176, 600, 176, 600, 176, 432, 180, 596, 180, 264, 176, 264, 180, 264, 180, 428, 180, 24472, 428, 288, 156, 288, 156, 620, 156, 432, 176, 288, 156, 596, 180, 284, 156, 288, 156, 288, 156, 596, 180, 596, 180, 452, 156, 600, 176, 264, 180, 284, 156, 288, 156, 452, 156

It doesnt work if you sendRaw with those codes.
The code seems to be RC6 but with a properly header.

A forum thread used this code to work with ESP8266:

void ICACHE_FLASH_ATTR IRsend::sendRC6gvt(unsigned long data, int nbits) {
  // Set IR carrier frequency
  enableIROut(36);
  // Header
  mark(RC6_HDR_MARK); //header
  space(RC6_HDR_SPACE);
  mark(RC6_T1);  
  space(RC6_T1);
  mark(RC6_T1);  
  space(RC6_T1);
  mark(RC6_T1);  
  space(RC6_T1);  
  space(RC6_T1);      
  mark(RC6_T1);  
  space(2*RC6_T1); //trailer bits     
  mark(2*RC6_T1);   
 
  int t;
  // Data
  for (unsigned long i = 0, mask = 1UL << (nbits - 1); mask; i++, mask >>= 1) {
    // The fourth bit we send is a "double width trailer bit".
    t = RC6_T1;
   
    if (data & mask) {  // 1
      mark(t);
      space(t);
    } else {  // 0
      space(t);
      mark(t);
    }
  }
  // Footer
  ledOff();
}

How to receive at multiple pins ?

If I want to receive at both pin11 & pin10, what shall I do ?

Panasonic Decode output offset by two spaces using IRreceiveDumpV2

Board

Arduino ATmega328* board (UNO, Nano)

Protocol

Panasonic

When using the included IRreceiveDumpV2 program, decoding Panasonic IR was resulting in incorrect data values via the Serial Monitor. For example, "OK" was returning:

uint16_t address = 0x4004;
uint16_t data = 0x4010092;

I noticed all were starting with '40' and missing the last two HEX values. It appeared as the offset was two places to the left (grabbing the last 4 in the address and the leading 0). The correct output should be:

uint16_t address = 0x4004;
uint16_t data = 0x1009293;

I was able to trace this back to the ir_Panasonic.cpp file in decodePanasonic. I made the following change to produce the proper data output:

//    if (!decodePulseDistanceData(PANASONIC_DATA_BITS, offset + PANASONIC_ADDRESS_BITS, PANASONIC_BIT_MARK,
//    PANASONIC_ONE_SPACE, PANASONIC_ZERO_SPACE)) {
//        return false;
//    }
	
	// added + 8 to PANASONIC_DATA_BITS to show correct value
    if (!decodePulseDistanceData(PANASONIC_DATA_BITS + 8, offset + PANASONIC_ADDRESS_BITS, PANASONIC_BIT_MARK,
    PANASONIC_ONE_SPACE, PANASONIC_ZERO_SPACE)) {
        return false;
    }

I noticed that the ir_Panasonic.cpp file is no longer in this github, so I was unable to suggest any changes (or have someone familiar with CPP suggest proper code). I am not sure the reason behind the removal of the file, but this change helped with decoding Panasonic IR for my Viera Plasma TV.

Attempted a Sanyo Send without success

Board: ARDUINO NANO
Library Version: 2.2.3
Protocol: Sanyo

I have a Cisco brand cable box, and when the codes get decoded, they are identified as Sanyo codes. I've written a rather large sketch that holds almost every button code from two different remotes, so I stored the codes in an array in PROGMEM.

The problem is, I had to go with RAW on the Cisco device because I can't get the library to send the hex encoded commands... here is how I created the Sanyo send routine in ir_Sanyo.cpp:

Code Block:

#define SANYO_BITS                   12
#define SANYO_HDR_MARK	           3500  // seen range 3500
#define SANYO_HDR_SPACE	            950  // seen 950
#define SANYO_ONE_MARK	           2400  // seen 2400
#define SANYO_ZERO_MARK             700  // seen 700
#define SANYO_DOUBLE_SPACE_USECS    800  // usually ssee 713 - not using ticks as get number wrapround
#define SANYO_RPT_LENGTH          45000

#if SEND_SANYO
void  IRsend::sendSanyo (const unsigned long data,  int nbits)
    {
        enableIROut(38);

        mark(SANYO_HDR_MARK);
        space(SANYO_HDR_SPACE);

        for (unsigned long  mask = 1UL << (nbits - 1);  mask;  mask >>= 1) {
            if (data & mask) {
                mark(SANYO_ONE_MARK);
                space(SANYO_HDR_SPACE);
            } else {
                mark(SANYO_ZERO_MARK);
                space(SANYO_HDR_SPACE);
            }
        }
    }

#endif

When I send any of the hex codes that I decoded I can see the infrared LED lighting up when I look at it through my cell camera, so I know its doing SOMETHING ... it just has no effect on the receiver.

If I use the RAW codes, it works fine, but they consume a lot of memory which puts me into the warning range when I compile my sketch, so I would really like to use the hex codes instead.

Is there any way of really breaking down the protocol of this Cisco remote somehow so that all of the timing parameters can be properly incorporated into a send command? I understand how IR works CONCEPTUALLY but I'm a little lost with the marks and spaces and the timing of them and how that all works to create an intelligible signal ... but if there was some way to decode the commands from the remote and get all of the specifics of the remote so that I can make a send command that will work ... that would be awesome, I just wouldn't know where to start.

Thank you,

Mike Sims

atmega 328 frequency problem/question

Hello,

I wrote remote control (receiver) sketch on arduino UNO all works fine, then decided to move whole thing on just an atmega 328p processor using his internal clock , on 8MHz nothing works, on 1MHz few buttons are recognized.
My question is does processor frequency affect stability of irreceiver? If yes, I can use an external escilator, what frequency is considered stable?

PSA: Changing the License to MIT

Is anyone opposed to switching the license for all new versions of the library from LGPL to MIT? Just to be clear, all previous versions will remain LGPL.

Update

I thought it might be wise to just mention briefly why I would like to change the Licensing. Without getting into a holy war, I personally prefer permissive licenses and not restrictive ones. I respect that GPL advocates for software "freedom" but unfortunately that means different things to different people. To me GPL simply means a new set of restrictions whereas MIT allows you to practically do anything.

Decode Velux WLR 100 50 02

Board: ARDUINO UNO
Library Version: 2.1.0
Protocol: Unknown

Hey, I am trying to replicate the protocol of a Velux WLR 100 50 02, is there any preexisting stuff that I could use ?
Or how could I go about this ?
It is supposed to be sent by an esp 8266 in the end.

I didn't find anything helpful on the internet, therefore I am asking here.
Thanks in advance.

IRSend NEC Argument/syntax?

Board

[ X] Arduino ATmega328* board (UNO, Nano)
Arduino ATmega2560 board (Mega)
Arduino ATmega32U4 board (Leonardo)
ATtiny85 board (ATTinyCore by Spence Conde)
Digispark board
Arduino SAM board (Due)
Arduino SAMD board (Zero, MKR*)
ESP32 board - first check https://github.com/crankyoldgit/IRremoteESP8266
Teensy board
Other - please specify

Protocol

checklist:

I have read the README.md file thoroughly
I have searched existing issues to see if there is anything I have missed.
The latest repo version is used
Any code referenced is provided and if over 30 lines a gist is linked INSTEAD of it being pasted in here
The title of the issue is helpful and relevant

Here's the data that I've captured:

Protocol=NEC Address=0x0 Command=0x58 Raw-Data=0xA758FF00 (32 bits)

Here's how I'm trying to send it through an IR led --- I have confirmed with my cell phone that the LED is lighting, but my device is not responding?

    IrSender.sendNEC(0xA758FF00, 32);

Updated Library in previousl;y working sketch; error verify/compiling for NANO. Help?

HI - I m very new to this. Had a sketch working well with previous version.
Updated to latest. Noted many more include lines
failed "verify compile" step for NANO/328
I dont understand the note below about if more than 30 lines code do "

Board

[X ] Arduino ATmega328* board (UNO, Nano)
Arduino ATmega2560 board (Mega)
Arduino ATmega32U4 board (Leonardo)
ATtiny85 board (ATTinyCore by Spence Conde)
Digispark board
Arduino SAM board (Due)
Arduino SAMD board (Zero, MKR*)
ESP32 board - first check https://github.com/crankyoldgit/IRremoteESP8266
Teensy board
Other - please specify

Protocol

Code Block:
Here is the error text from the compile log window, truncated to the area where the com[pile appeared to fail.

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\eightanaloginputs" "-IC:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src" "C:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src\ir_Whynter.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\eightanaloginputs" "-IC:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src" "C:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src\nRF5.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\eightanaloginputs" "-IC:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src" "C:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src\sam.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE
Generating function prototypes...
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\eightanaloginputs" "-IC:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src" "C:\Users\glena\AppData\Local\Temp\arduino_build_339388\sketch\GFL_remote_0.6A.ino.cpp" -o "C:\Users\glena\AppData\Local\Temp\arduino_build_339388\preproc\ctags_target_for_gcc_minus_e.cpp" -DARDUINO_LIB_DISCOVERY_PHASE
"C:\Program Files (x86)\Arduino\tools-builder\ctags\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "C:\Users\glena\AppData\Local\Temp\arduino_build_339388\preproc\ctags_target_for_gcc_minus_e.cpp"
Compiling sketch...
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\eightanaloginputs" "-IC:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src" "C:\Users\glena\AppData\Local\Temp\arduino_build_339388\sketch\GFL_remote_0.6A.ino.cpp" -o "C:\Users\glena\AppData\Local\Temp\arduino_build_339388\sketch\GFL_remote_0.6A.ino.cpp.o"
In file included from C:\Users\glena\Dropbox (Personal)\Arduino_Sketches\GFL_remote_0.6A\GFL_remote_0.6A.ino:5:0:
C:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src/TinyIRReceiver.h:87:8: error: redefinition of 'struct TinyIRReceiverStruct'
struct TinyIRReceiverStruct {
^~~~~~~~~~~~~~~~~~~~
In file included from C:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src/TinyIRReceiver.cpp.h:37:0,
from C:\Users\glena\Dropbox (Personal)\Arduino_Sketches\GFL_remote_0.6A\GFL_remote_0.6A.ino:4:
C:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866\src/TinyIRReceiver.h:87:8: note: previous definition of 'struct TinyIRReceiverStruct'
struct TinyIRReceiverStruct {
^~~~~~~~~~~~~~~~~~~~
Using library arduino_189866 at version 2.8.1 in folder: C:\Users\glena\Dropbox (Personal)\Arduino_Sketches\libraries\arduino_189866
exit status 1
Error compiling for board Arduino Nano.

#include <IRremote.h>

.....


Use [a gist](gist.github.com) if the code exceeds 30 lines

**checklist:**
- [x] I have **read** the README.md file thoroughly
- [x] I have searched existing issues to see if there is anything I have missed.
- [x] The latest [repo version](https://github.com/Arduino-IRremote/Arduino-IRremote/archive/master.zip) is used
- [] Any code referenced is provided and if over 30 lines a gist is linked INSTEAD of it being pasted in here
- [x] The title of the issue is helpful and relevant 

** We will start to close issues that do not follow these guidelines as it doesn't help the contributors who spend time trying to solve issues if the community ignores guidelines!**

The above is a short template allowing you to make detailed issues!

Proposed rename of the library

@shirriff @AnalysIR @bengtmartensson @marcmerlin

Hi all I am thinking of renaming this library to something like InfraredRemote or anything very similar. The intention being to change the file IRremote.h into something else... far too many distributions of arduino (including platformio) ship with RobotIRremote.

Thoughts?

This is a good time for this discussion as I am doing a lot of refactoring in v3 and many new changes are coming in with #437 and alike.

Gitter Room

Hi All,

I just created a room in Gitter.
Feel free to pop up there so we can talk more about the library.

Help supporting YORK AC remote

Hello all,

I'm glad to see new version of this library. :)

I know that it is difficult to add fully functional AC protocol but I just need to save current state of my AC so I can turn it on, off and make some presets. But strange thing is that this remote produce two codes for one button press. IRrecvDump detects two 32bit NEC codes (74 length) for each button press.

Here are some examples:

Turn ON (Fan:auto, temp:24, mode: cooling):

9015260A
Decoded NEC: 9015260A (32 bits)
Raw (74): -7524 9000 -4450 650 -1650 650 -600 650 -550 650 -1600 700 -500 700 -550 650 -550 650 -550 650 -550 650 -550 650 -600 600 -1650 650 -600 650 -1600 700 -550 650 -1600 700 -550 650 -550 650 -1650 650 -550 650 -550 650 -1650 650 -1650 700 -550 650 -550 650 -550 650 -550 650 -550 650 -1650 650 -550 650 -1650 650 -600 600 -600 650 -1600 700 -550 650 
90152606
Decoded NEC: 90152606 (32 bits)
Raw (74): 25536 9000 -4450 650 -1650 650 -600 600 -600 600 -1650 700 -550 650 -550 650 -550 650 -550 650 -550 650 -550 650 -550 650 -1650 650 -550 650 -1650 700 -550 650 -1600 700 -550 650 -550 650 -1650 650 -550 650 -550 650 -1650 650 -1650 650 -550 700 -550 650 -550 650 -550 650 -550 650 -550 650 -1650 650 -1650 650 -550 650 -600 600 -1650 700 -550 650

Turn OFF:

Decoded NEC: 8015240A (32 bits)
Raw (74): 2128 9000 -4450 700 -1600 700 -550 650 -550 650 -550 650 -550 650 -600 600 -600 650 -550 650 -550 650 -550 650 -550 650 -1650 650 -550 650 -1650 650 -550 650 -1650 650 -600 650 -550 650 -1600 700 -550 650 -550 650 -1650 650 -550 650 -550 650 -550 650 -550 650 -600 650 -550 650 -1600 700 -550 650 -1600 700 -550 650 -550 650 -1650 650 -550 650 
80152406
Decoded NEC: 80152406 (32 bits)
Raw (74): 25586 9000 -4450 700 -1600 700 -550 650 -550 650 -550 650 -550 650 -600 600 -600 600 -600 650 -550 650 -550 650 -550 650 -1650 650 -550 650 -1650 650 -550 650 -1650 650 -600 600 -600 650 -1600 700 -550 650 -550 650 -1650 650 -550 650 -550 650 -550 650 -550 650 -550 650 -550 650 -550 700 -1600 700 -1600 700 -550 650 -550 650 -1650 650 -550 650

Change temperature from 24C to 25C:

Decoded NEC: 9095260A (32 bits)
Raw (74): 17628 9000 -4450 650 -1650 700 -550 600 -600 650 -1600 700 -550 650 -550 650 -550 650 -550 650 -1650 650 -550 650 -600 600 -1650 650 -600 650 -1600 700 -550 650 -1600 700 -550 650 -550 650 -1650 650 -550 650 -550 650 -1650 650 -1650 700 -550 650 -550 650 -550 650 -550 650 -550 650 -1650 650 -550 650 -1650 650 -600 600 -600 650 -1600 700 -550 650 
90952606
Decoded NEC: 90952606 (32 bits)
Raw (74): 25536 8950 -4500 650 -1650 650 -600 600 -600 650 -1600 700 -550 650 -550 650 -550 650 -550 650 -1650 650 -550 650 -550 650 -1650 650 -600 600 -1650 650 -600 650 -1600 700 -550 650 -550 650 -1650 650 -550 650 -550 650 -1650 650 -1650 650 -600 600 -600 650 -550 650 -550 650 -550 650 -550 650 -1650 650 -1650 650 -550 650 -550 650 -1650 650 -600 650 ```


Maybe second code is used just for checksum. Any idea how to support this protocol?

Why 33% duty cycle

With IR signals & batteries the key thing is to always run the IR carrier @ 33.3% duty cycle (which IRremote does by default). There is interesting maths behind this for anyone who wants to research further.

Originally posted by @AnalysIR in https://github.com/z3t0/Arduino-IRremote/issues/674#issuecomment-586267368

@AnalysIR Where can I find the math behind it?
AFAIK the volume of fundamental is most at 50%, with other duty cycles you generate more harmonics.

Re-factoring Code

Hi All,

@zenwheel @levsa @Lauszus @PaulStoffregen @shirriff @joshuajnoble

I am working on re-factoring the library since the community is growing and the library with it. We need to develop a new system for managing features and new additions, especially adding protocols. This is to ensure that the library remains efficient and minimal.

We could use #defines within the library that would specify the protocol to be used (e.g. SONY). I do not particularly like this idea because with the help of @khair-eddine and @Neco7 I am working on adding multi receiver/sender support.
We could have TWO releases of the library, one being minimized for people who know what they are doing, this will still support multi receiver support but will be a little bit different. This has the advantage of keeping the library minimal for those who know how to use it and need the space for other things or their board does not have enough space. The other release being the standard one which will be number 3
We will have a standard library that will allow you to choose your protocol when creating a new irrecv and/or irsend. The focus is once again on establishing multi-receiver/sender support

The main concern here is to think ahead and make sure nothing breaks for multi-support.

I would like to hear your ideas and suggestions. Thanks!

Issues on IRremote 2.8.1 @ 4MHz ?

Board

[ X] Arduino ATmega328* board (UNO, Nano)

Protocol

[X ] NEC

The latest release is used

I have a system that can be configured to run at 16Mhz, 8Mhz & 4Mhz depending on whether powered from USB or battery.

with the latest 2.8.1 release I have noticed some issues @ 4mHz (F_CPU)

Specifically, the signals sent are not valid & on first look seem much shorter and incomplete.

I don't have time to look into it further at the moment & will revert to 2.6.1 for now. Do you have any idea what might be the cause? There was nothing obvious to me after some investigation. The carrier freq seems fine - the issue is just with the pulse durations.

It doesn't appear (???) to be related to SYSCLOCK or F_CPU based on initial check - but I haven't kept track of all the changes in 2.8.x.

UART is working fine @4Mhz etc.

When I compile on 2.6.1 everything is fine @4Mhz.

The only thing I can think of is all of the additional loops/function_call overhead related to decodePulseDistanceData and similar changes etc. This overhead might be material @4Mhz vs previous versions.

The other candidates could include any new/updated delay functions (if any).

Happy to test out any Suggestions :)

Tutorials and Documentation [REVAMPED]

I am working on totally re-doing the whole wiki because there are many things that have not been documented and also many new features have been added. Also we now have a GitHub page so we might as well use it.

If anyone can help in any way just post here. Mainly what I need is:

Writers who can re-write parts of the wiki that need rewriting
HTML Programmers (Any Level, Beginners too) that can do simple things like make lists or create paragraphs
Organizers who can work on deciding what needs to be added to the wiki.

EDIT: I changed my mind and realized that it would be better to keep the wiki on the repo, but write some tutorials that will be included in the GitHub Page.

irrecv not work after irsend

Board

[x ] Arduino ATmega328* board (UNO, Nano)
Arduino ATmega2560 board (Mega)
Arduino ATmega32U4 board (Leonardo)
ATtiny85 board (ATTinyCore by Spence Conde)
Digispark board
Arduino SAM board (Due)
Arduino SAMD board (Zero, MKR*)
ESP32 board - first check https://github.com/crankyoldgit/IRremoteESP8266
Teensy board
Other - please specify

Protocol

Code Block:


#include <IRremote.h> 



Use [a gist](gist.github.com) if the code exceeds 30 lines

**checklist:**
- [x] I have **read** the README.md file thoroughly
- [x] I have searched existing issues to see if there is anything I have missed.
- [] The latest [release](https://github.com/z3t0/Arduino-IRremote/releases/latest) is used
- [] Any code referenced is provided and if over 30 lines a gist is linked INSTEAD of it being pasted in here
- [] The title of the issue is helpful and relevant 

** We will start to close issues that do not follow these guidelines as it doesn't help the contributors who spend time trying to solve issues if the community ignores guidelines!**

The above is a short template allowing you to make detailed issues!


Hallo,


I try use irsend & irrec.

irrec works until i use irsend.
after i use irsend, irrec  no longer works.
arduino works generally.

what do I do wrong?

regards Andre
BTU-C-S

tested Arduino-IRremote-master 2.7.0,2.8.0


Code:


IRrecv irrecv(IR_RECV_PIN);
IRsend IrSender;
...
void loop() {
  unsigned long tData = 0xE0E0E02F;
  tnows=(millis()/1000);
  if (irrecv.decode(&results)) {
   Serial.println(results.value, HEX);
   if (results.value == 0xE0E0E01F) {   //Wenn der Infrarotempfänger die Zahl 
    anstoss=1;
   }
  irrecv.resume();
  }
 if (anstoss==1){
  anstoss=0;
  delay(5000);
  IrSender.sendSAMSUNG(tData, 4);
  Serial.print(F("sendSAMSUNG(0x")); Serial.print(tData,HEX);  Serial.println(F(
", 4)"));
  //irrecv.resume();
  }
 if (tmemread<=tnows) {
  tmemread=(tnows+tintread);
  Serial.println(String("heartbeat ")+tnows);
 }
 delay(250);
} // loop

monitor:
- send voldown
- send volup
- send voldown
irfb v04 201128
heartbeat 0
E0E0D02F
E0E0D02F
E0E0D02F
E0E0E01F
sendSAMSUNG(0xE0E0E02F, 4)
heartbeat 30
heartbeat 60

function: IRsend::mark exsit unnecessary delay

https://github.com/z3t0/Arduino-IRremote/blob/0dd763c886ccb1c47a665d681a6f22b7c79992fc/src/irSend.cpp#L164

Help adding Lutron protocol

I've been trying to add the Lutron Dimmer protocol to the library but am struggling with how to convert the protocol timings supplied by Lutron to the #DEFINE entries needed in the ir_Template.cpp.

This is the protocol definition provided by Lutron:

IR Carrier Frequency: 40.0 kHz
Duty Cycle: 40%
Single Bit Time: 2.288 milliseconds
Baud Rate: 437 bps
Command Length: 36 bits
Command Duration: 82.368 milliseconds
Logic One: Presence of IR modulated at 40.0 kHz
Logic Zero: Absence of IR
Transmit Order: Transmit the most significant bit first
General Function: IR code is transmitted while a button is held down
Timeout Function: Timeouts may not occur until at least seven-seconds of continuous IR transmission has taken place.

I know there's an issue with >32 bits but all of the Lutron codes begin with 1111 so I guess this could be hardcoded and sent as a header in the protocol.

The full protocol definition is in the attached pdf. Can anyone shed some light to help me move forward?

Lutron.pdf

Protocols Implementation

@adamlhumphreys @Gustavomurta

It has come to the attention of many users that many of the protocol implementations are questionable and possibly incorrect. This issue will be used to document the effort to find "reputable" sources for the specifications of the different IR protocols so that they can then be referenced and so the library has a way to explain what arbitrary names such as "LG" really mean.
#331

esp32 core - M5stickC support

Vendor: https://m5stack.com/collections/m5-core/products/stick-c?variant=17203451265114

Board

Arduino ATmega328* board (UNO, Nano)
Arduino ATmega2560 board (Mega)
Arduino ATmega32U4 board (Leonardo)
Arduino SAM board (Due)
Arduino SAMD board (Zero, MKR*)
[x ] ESP32 board - M5stickC unit
Teensy board
Other - please specify

Protocol

[x ] TBD

Code Block:

https://github.com/m5stack/M5StickC/blob/master/examples/Unit/IR/IR.ino

checklist:

I have read the README.md file thoroughly
I have searched existing issues to see if there is anything I have missed.
The latest release is used
Any code referenced is provided and if over 30 lines a gist is linked INSTEAD of it being pasted in here
The title of the issue is helpful and relevant

Recommended IR Modules

@AnalysIR

Hi All,

I am working a new project and am looking for a good pair of SMD IR Receiver and Emitter modules. I want to solder these onto a PCB, which will also contain an AVR chip and RS232 Chip.

Any recommendations for which IR receiver or emitter?

Thanks!

arduino-irremote / arduino-irremote Goto Github PK

arduino-irremote's Introduction

Arduino IRremote

If you find this program useful, please give it a star.

Table of content

Supported IR Protocols

Features

New features with version 4.x

Converting your 3.x program to the 4.x version

New features with version 3.x

Converting your 2.x program to the 4.x version

Example

Old 2.x program:

New 4.x program:

How to convert old MSB first 32 bit IR data codes to new LSB first 32 bit IR data codes

Nibble reverse map:

Errors with using the 4.x versions for old tutorials

Staying on 2.x

Drawbacks

Why *.hpp instead of *.cpp?

Using the new *.hpp files

IRReceiver pinouts

Receiving IR codes

decodedIRData structure

Flags

To access the RAW data, use:

Print all fields:

Print the raw timing data received:

Print how to send the received data:

Ambiguous protocols

NEC, Extended NEC, ONKYO

NEC, NEC2

Samsung, SamsungLG

Unknown protocol

Sending IR codes

Send pin

List of public IR code databases

Flipper Zero

Tiny NEC receiver and sender

TinyIRReceiver usage

TinyIRSender usage

The FAST protocol

FAST protocol characteristics:

Sending FAST protocol with IRremote

Sending FAST protocol with TinyIRSender

FAQ and hints

Receiving does not run if analogWrite() or tone() is used.

Problems with Neopixels, FastLed etc.

Does not work/compile with another library

Multiple IR receivers

Increase strength of sent output signal

Minimal CPU clock frequency

Bang & Olufsen protocol

Handling unknown Protocols

Disclaimer

Protocol=PULSE_DISTANCE

Protocol=UNKNOWN

How to deal with protocols not supported by IRremote

Examples for this library

SimpleReceiver + SimpleSender

TinyReceiver + TinySender

SmallReceiver

ReceiveDemo + AllProtocolsOnLCD

ReceiveDump

SendDemo

SendAndReceive

ReceiveAndSend

ReceiveAndSendDistanceWidth

ReceiveOneAndSendMultiple

IRDispatcherDemo

IRrelay

IRremoteExtensionTest

SendLGAirConditionerDemo

ReceiveAndSendHob2Hood

ReceiverTimingAnalysis

UnitTest

WOKWI online examples

Issues and discussions

Compile options / macros for this library

Changing include (*.h) files with Arduino IDE

Why .hpp instead of .cpp?