Arduino IRremote
Support for ESP 3.0 core
A library enabling the sending & receiving of infra-red signals.
Available as Arduino library "IRremote".
? Google Translate
Supported IR Protocols
Features
New features with version 4.x
New features with version 3.x
Converting your 2.x program to the 4.x version
How to convert old MSB first 32 bit IR data codes to new LSB first 32 bit IR data codes
Errors with using the 3.x versions for old tutorials
Staying on 2.x
Why *.hpp instead of *.cpp
Using the new *.hpp files
Tutorials
3 ways to specify an IR code
IRReceiver pinouts
Receiving IR codes
Disclaimer
Other libraries, which may cover these protocols
Protocol=PULSE_DISTANCE
Protocol=UNKNOWN
How to deal with protocols not supported by IRremote
decodedIRData structure
Ambiguous protocols
RAM usage of different protocolsl
Handling unknown Protocols
Sending IR codes
List of public IR code databases
Sending IRDB IR codes
Send pin
Tiny NEC receiver and sender
The FAST protocol
FAQ and hints
Receiving stops after analogWrite() or tone() or after running a motor
Receiving sets overflow flag
Problems with Neopixels, FastLed etc.
Does not work/compile with another library
Multiple IR receiver and sender instances
Increase strength of sent output signal
Minimal CPU clock frequency
Bang & Olufsen protocol
Examples for this library
WOKWI online examples
IR control of a robot car
Issues and discussions
Compile options / macros for this library
Changing include (*.h) files with Arduino IDE
Modifying compile options with Sloeber IDE
Supported Boards
Timer and pin usage
Incompatibilities to other libraries and Arduino commands like tone() and analogWrite()
Hardware-PWM signal generation for sending
Why do we use 30% duty cycle for sending
How we decode signals
NEC encoding diagrams
Quick comparison of 5 Arduino IR receiving libraries
History
Useful links
Contributors
License
Copyright
NEC / Onkyo / Apple Denon / Sharp Panasonic / Kaseikyo
JVC LG RC5 RC6 Samsung Sony
Universal Pulse Distance Universal Pulse Width Universal Pulse Distance 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>
Lots of tutorials and examples.
Actively maintained.
Allows receiving and sending of raw timing data.
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 / Pulse Distance 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().
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().
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.
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) toIrReceiver.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 were renamed to sendNECMSB, sendSamsungMSB(), sendSonyMSB() 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 and therfore was assumed to be never used.
For converting MSB codes to LSB see below.
#include <IRremote.h>#define RECV_PIN 2IRrecv irrecv(RECV_PIN);
decode_results results;void setup()
{
...
Serial.begin(115200); // Establish serial communication
irrecv.enableIRIn(); // Start the receiver}void loop() { if (irrecv.decode(&results)) {
Serial.println(results.value, HEX);
...
irrecv.resume(); // Receive the next value
}
...
}#include <IRremote.hpp>#define IR_RECEIVE_PIN 2void setup()
{
...
Serial.begin(115200); // // Establish serial communication
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
}
...
}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 020x20 10 43 BC after nibble reverse0x40 80 2C D3 after bit reverse of each nibble
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.
Sending old MSB codes without conversion can be done by using sendNECMSB(), sendSonyMSB(), sendSamsungMSB(), sendJVCMSB().
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.
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 4.x is at least trying to be backwards compatible, so your old examples should still work fine.
Only the following decoders are available:NEC Denon Panasonic JVC LGRC5 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.
No decoding to a more meaningful (constant) 8/16 bit address and 8 bit command.
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.
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
A very elaborated introduction to IR remotes and IRremote library from DroneBot Workshop .
There are 3 different ways of specifying a particular IR code.
The timing of each mark/pulse and space/distance_between_pulses is specified in a list or array.
This enables specifying all IR codes, but requires a lot of memory and is not readable at all.
One formal definition of such a timing array, including specification of frequency and repeats is the Pronto format.
Memory can be saved by using a lower time resolution.
For IRremote you can use a 50 µs resolution which halves the memory requirement by using byte values instead of int16 values.
For receiving purposes you can use the hash of the timing provided by the decodeHash() decoder.
There are 3 main encoding schemes which encodes a binary bitstream / hex value:
PULSE_DISTANCE. The distance between pulses determines the bit value. This requires always a stop bit!
Examples are NEC and KASEIKYO protocols. The pulse width is constant for most protocols.
PULSE_WIDTH. The width of a pulse determines the bit value, pulse distance is constant. This requires no stop bit!
The only known example is the SONY protocol.
Phase / Manchester encoding. The time of the pulse/pause transition (phase) relative to the clock determines the bit value. Examples are RC5 and RC6 protocols.
Phase encoding has a constant bit length, PULSE_DISTANCE with constant pulse width and PULSE_WIDTH have no constant bit length!
A well known example for PULSE_DISTANCE with non constant pulse width encoding is the RS232 serial encoding.
Here the non constant pulse width is used to enable a constant bit length.
Most IR signals have a special header to help in setting the automatic gain of the receiver circuit. This header is not part of the encoding, but is often significant for a special protocol and therefore must be reproducible.
Be aware that there are codes using a PULSE_DISTANCE encoding where more than a binary 0/1 is put into a pulse/pause combination.
This requires more than 2 different pulse or pause length combinations.
The HobToHood protocol uses such an encoding.
Using encoding schemes reduces the specification of an IR code to a bitstream / hex value, which is LSB by default and pulse / pause timings of header, 0, and 1. The hex value is quite readable. These schemes can not put any semantics like address, command or checksum on this bitstream.
There are a few common protocols that are implemented directly in IRremote. They specify the frequency, the timings of header, 0, and 1 as well as other values like checksum, repeat distance, repeat coding, bit toggling etc. The semantics of the hex value is also specified, allowing the usage of only 2 parameters address and command to specify an IR code. This saves memory and is highly readable. Often the address is also constant, which further reduces memory requirements.
Adafruit IR Sensor tutorial
In your program you check for a completely 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.
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.};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 | Too many marks and spaces for the specified RAW_BUFFER_LENGTH. To avoid endless flagging of overflow, irparams.rawlen is set to 0 in this case. |
| IRDATA_FLAGS_IS_MSB_FIRST | This value is mainly determined by the (known) protocol. |
auto myRawdata= IrReceiver.decodedIRData.decodedRawData;
The definitions for the IrReceiver.decodedIRData.flags are described here.
IrReceiver.printIRResultShort(&Serial);
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!
IrReceiver.printIRSendUsage(&Serial);
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.
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!
On a long press, the SamsungLG protocol does not repeat its frame, it sends a special short repeat frame.
The RAW_BUFFER_LENGTH determines the length of the byte buffer where the received IR timing data is stored before decoding.
100 is sufficient for standard protocols up to 48 bits, with 1 bit consisting of one mark and space.
We always require additional 4 bytes, 1 byte for initial gap, 2 bytes for header and 1 byte for stop bit.
48 bit protocols are PANASONIC, KASEIKYO, SAMSUNG48, RC6.
32 bit protocols like NEC, SAMSUNG, WHYNTER, SONY(20), LG(28) require a buffer length of 68.
16 bit protocols like BOSEWAVE, DENON, FAST, JVC, LEGO_PF, RC5, SONY(12 or 15) require a buffer length of 36.
MAGIQUEST requires a buffer length of 112.
Air conditioners often send a longer protocol data stream up to 750 bits.
If the record gap determined by RECORD_GAP_MICROS is changed from the default 8 ms to more than 20 ms, the buffer is no longer a byte but a uint16_t buffer, requiring twice as much RAM.
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.
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 due to the time required for printing the information.
If your protocol seems not to be supported by this library, you may try the IRMP library, which especially supports manchester protocols much better.
For air conditioners , you may try the IRremoteESP8266 library, which supports an impressive set of protocols and a lot of air conditioners and works also on ESP32.
Raw-IR-decoder-for-Arduino is not a library, but an arduino example sketch, which provides many methods of decoding especially air conditioner protocols. Sending of these protocols can be done by the Arduino library HeatpumpIR.
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 sendPulseDistanceWidth().
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 PULSE_DISTANCE / PULSE_WIDTH decoder just decodes a timing stream to a bitstream stored as hex values.
These decoders can not put any semantics like address, command or checksum on this bitstream.
But the bitstream is way more readable, than a timing stream. This bitstream is read LSB first by default.
If LSB does not suit for further research, you can change it here.
If RAM is not more than 2k, the decoder only accepts mark or space durations up to 2500 microseconds to save RAM space, otherwise it accepts durations up to 10 ms.
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 + 450,- 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.
If you do not know which protocol your IR transmitter uses, you have several choices.
Just use the hash value to decide which command was received. See the SimpleReceiverForHashCodes example.
Use the IRreceiveDemo example or IRreceiveDump example to dump out the IR timing. You can then reproduce/send this timing with the SendRawDemo example.
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.
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.
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.
Sending old MSB codes without conversion can be done by using sendNECMSB(), sendSonyMSB(), sendSamsungMSB(), sendJVCMSB().
The codes found in the Flipper-IRDB database are quite straightforward to convert, because the also use the address / command scheme.
Protocol matching is NECext -> NECext (or Onkyo), Samsung32 -> Samsung, SIRC20 -> Sony with 20 bits etc.
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.
Any pin can be chosen as send pin, because the PWM signal is generated by default with software bit banging, since SEND_PWM_BY_TIMER is not active.
On ESP32 ledc channel 0 is used for generating the IR PWM.
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.
http://www.harctoolbox.org/IR-resources.html
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> |
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.
Instead of sampling the input every 50 µs as IRremote does, TinyReceiver receiver uses a pin change interrupt for on-the-fly decoding which limits the choice of protocols.
On each level change, the level and the time since the last change are used to incrementally decode the protocol.
With this operating principle, we cannot wait for a timeout and then decode the protocol as IRremote does.
Instead, we need to know which is the last bit (level change) of a protocol to do the final decoding
and the call of the optional user provided callback function handleTinyReceivedIRData().
This means, we need to know the number of bits in a protocol and therefore the protocol (family).
Check out the TinyReceiver and IRDispatcherDemo examples.
Take care to include TinyIRReceiver.hpp or TinyIRSender.hpp instead of IRremote.hpp.
//#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 (TinyReceiverDecode()) { printTinyReceiverResultMinimal(&Serial);
} // No resume() required :-)}#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 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.
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.
#define IR_SEND_PIN 3#include <IRremote.hpp>void setup() { sendFAST(11, 2); // Send command 11 on pin 3 with 2 repeats.}void loop() {}#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.
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().
Especially motor control often uses the analogWrite() function and will therefore stop the receiving if used on the pins indicated here.
On the Uno and other AVR boards the receiver timer ist the same as the tone timer. Thus receiving will stop after a tone() command.
See ReceiveDemo example how to deal with it, i.e. how to use IrReceiver.restartTimer().
The flag IRDATA_FLAGS_WAS_OVERFLOW is set, if RAW_BUFFER_LENGTH is too small for all the marks and spaces of the protocol.
This can happen on long protocol frames like the ones from air conditioner.
It also can happen, if RECORD_GAP_MICROS is smaller than the real gap between a frame and thr repetition frame, thus interpreting both as one consecutive frame.
Best is to dump the timing then, to see which reason holds.
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
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.
This library supports only one IR receiver and one IR sender object (IRrecv and IRsend) per CPU.
However since sending is a serial task, you can use setSendPin() to switch the pin to send, thus emulating multiple sender.
The receiver uses a special timer triggered function, which reads 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 receiver modules internally use an NPN transistor as output device with just a 30k resistor to VCC.
This is basically an "open collector" and allows multiple output pins to be connected to one Arduino input pin.
However, keep in mind that any weak / disturbed signal from one of the receivers will also interfere with a good signal from another receiver.
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 ?.
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 requires 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.
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.
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.
See also DroneBot Workshop SimpleReceiver and SimpleSender.
The SimpleReceiver and SimpleSender examples are a good starting point. A simple example can be tested online with WOKWI.
The SimpleReceiverForHashCodes uses only the hash decoder.
It converts all IR frames longer than 6 to a 32 bit hash code, thus enabling receiving of unknown protocols.
See: http://www.righto.com/2010/01/using-arbitrary-remotes-with-arduino.html
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).
If the protocol is not NEC and code size matters, look at this example.
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.
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.
Sends all available protocols at least once.
Demonstrates receiving while sending.
Record and play back last received IR signal at button press. IR frames of known protocols are sent by the appropriate protocol encoder. UNKNOWN protocol frames are stored as raw data and sent with sendRaw().
Try to decode each IR frame with the universal DistanceWidth decoder, store the data and send it on button press with sendPulseDistanceWidthFromArray().
If RAM is not more than 2k, the decoder only accepts mark or space durations up to 2500 microseconds to save RAM space, otherwise it accepts durations up to 10 ms.
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.
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.
Framework for calling different functions of your program for different IR codes.
Control a relay (connected to an output pin) with your remote.
Example for a user defined class, which itself uses the IRrecv class from IRremote.
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.
Example for receiving and sending AEG / Elektrolux Hob2Hood protocol.
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.
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).
Simple receiver
Simple toggle by IR key 5
TinyReceiver
ReceiverTimingAnalysis
Receiver with LCD output and switch statement
This example of the Arduino PWMMotorControl library controls the basic functions of a robot car using the IRremote library.
It controls 2 PWM motor channels, 2 motors at each channel.
Here you can find the instructable for car assembly and code.
IR_RobotCar with TL1838 IR receiver plugged into expansion board.
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!
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 | 200 | Buffer size of raw input uint16_t buffer. Must be even! If it is too small, overflow flag will be set. 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. A value of 200 requires 200 bytes RAM. |
EXCLUDE_UNIVERSAL_PROTOCOLS | disabled | Excludes the universal decoder for pulse distance width 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. |
DISTANCE_WIDTH_DECODER_DURATION_ARRAY_SIZE | 50 if RAM <= 2k, else 200 | A value of 200 allows to decode mark or space durations up to 10 ms. |
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 cyc
Expand
Additional Information
Related Applications
Recommended for You
Related Information
All
|
