Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

License

NotificationsYou must be signed in to change notification settings

Arduino-IRremote/Arduino-IRremote

Repository files navigation

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

Badge License: MIT   Badge Version   Badge Commits since latest   Badge LibraryBuild

Stand With Ukraine

Available asArduino library "IRremote".

Button Install   Button API   Button Changelog   Button Contribute

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

🌎Google Translate

Table of content


Supported IR Protocols

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> likehere:

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

Common problem with IRremote

Or"I build a gadged with 2 motors controlled by IR and theIR stops after the first motor command".
This is due to the fact, that the motor control by AnalogWrite() uses the same timer as IR receiving.
Seethis table for the list of timers and pins.

Using the new library version for old examples

This library has been refactored, breaking backward compatibility with the old version, on which many examples on the Internet are based.

New features of version 4.x

  • Since 4.3IrSender.begin(DISABLE_LED_FEEDBACK) will no longer work, useIrSender.begin(DISABLE_LED_FEEDBACK, 0) instead.
  • New universalPulse Distance / Pulse Width / Pulse Distance Width decoder added, which covers many previous unknown protocols.
  • Printout of code how to send received command byIrReceiver.printIRSendUsage(&Serial).
  • RawData type is now 64 bit for 32 bit platforms and thereforedecodedIRData.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 ofPULSE_DISTANCE +PULSE_WIDTH protocols.
  • New FAST protocol.
  • Automatic printout of thecorresponding send function withprintIRSendUsage().

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 parameterbool hasStopBit is not longer required and removed e.g. for functionsendPulseDistanceWidth().

New features of version 3.x

  • Any pin can be used for receiving and ifSEND_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 bitaddress and a protocol number is provided for decoding (instead of the old 32 bit value).
  • Protocol values comply toprotocol standards.
    NEC, Panasonic, Sony, Samsung and JVC decode & send LSB first.
  • SupportsUniversal Distance protocol, which covers a lot of previous unknown protocols.
  • Compatible withtone() library. See theReceiveDemo example.
  • Simultaneous sending and receiving. See theSendAndReceive example.
  • Supportsmore platforms.
  • Allows for the generation of non PWM signal to justsimulate an active low receiver signal for direct connect to existent receiving devices without using IR.
  • Easy protocol configuration,directly in yoursource code.
    Reduces memory footprint and decreases decoding time.
  • Contains avery small NEC only decoder, whichdoes 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 andenabling 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 andIRsender object have been added and can be used without defining them, like the well known ArduinoSerial object.

  • Just remove the lineIRrecv IrReceiver(IR_RECEIVE_PIN); and/orIRsend IrSender; in your program and replace all occurrences ofIRrecv. orirrecv. withIrReceiver and replace allIRsend orirsend withIrSender.

  • Since the decoded values are now inIrReceiver.decodedIRData and not inresults any more, remove the linedecode_results results or similar.

  • Like for the Serial object, callIrReceiver.begin(IR_RECEIVE_PIN, ENABLE_LED_FEEDBACK)orIrReceiver.begin(IR_RECEIVE_PIN, DISABLE_LED_FEEDBACK) instead of theIrReceiver.enableIRIn() orirrecv.enableIRIn() in setup().
    For sending, callIrSender.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);

  • Olddecode(decode_results *aResults) function is replaced by simpledecode(). So if you have a statementif(irrecv.decode(&results)) replace it withif (IrReceiver.decode()).

  • The decoded result is now in inIrReceiver.decodedIRData and not inresults any more, therefore replace any occurrences ofresults.value andresults.decode_type (and similar) toIrReceiver.decodedIRData.decodedRawData andIrReceiver.decodedIRData.protocol.

  • Overflow, Repeat and other flags are now inIrReceiver.receivedIRData.flags.

  • Seldom used:results.rawbuf andresults.rawlen must be replaced byIrReceiver.decodedIRData.rawDataPtr->rawbuf andIrReceiver.decodedIRData.rawDataPtr->rawlen.

  • The 5 protocolsNEC, Panasonic, Sony, Samsung and JVC have been converted to LSB first. Send functions for sending old MSB data were renamed tosendNECMSB,sendSamsungMSB(),sendSonyMSB() andsendJVCMSB().The oldsendSAMSUNG() andsendSony() MSB functions are still available.The old MSB version ofsendPanasonic() function was deleted, since it had bugs nobody recognized and therefore was assumed to be never used.
    For converting MSB codes to LSB seebelow.

Example

Old 2.x program:

#include<IRremote.h>#defineRECV_PIN2IRrecvirrecv(RECV_PIN);decode_results results;voidsetup(){...  Serial.begin(115200);// Establish serial communication  irrecv.enableIRIn();// Start the receiver}voidloop() {if (irrecv.decode(&results)) {      Serial.println(results.value, HEX);      ...      irrecv.resume();// Receive the next value  }  ...}

New 4.x program:

#include<IRremote.hpp>#defineIR_RECEIVE_PIN2voidsetup(){...  Serial.begin(115200);// // Establish serial communication  IrReceiver.begin(IR_RECEIVE_PIN, ENABLE_LED_FEEDBACK);// Start the receiver}voidloop() {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  }  ...}

Sample output

For more, see theUnitTest log.

Protocol=NEC Address=0xF1 Command=0x76 Raw-Data=0x89760EF1 32 bits LSB firstSend with: IrSender.sendNEC(0xF1, 0x76, <numberOfRepeats>);Protocol=Kaseikyo_Denon Address=0xFF1 Command=0x76 Raw-Data=0x9976FF10 48 bits LSB firstSend with: IrSender.sendKaseikyo_Denon(0xFF1, 0x76, <numberOfRepeats>);

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

For the new decoders forNEC, Panasonic, Sony, Samsung and JVC, the resultIrReceiver.decodedIRData.decodedRawData is nowLSB-first, as the definition of these protocols suggests!

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

Nibble reverse

0xCB 34 01 02 MSB value
0x20 10 43 BC after nibble reverse
0x40 80 2C D3 LSB value 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

Binary string reverse

If youread the first binary sequence backwards (right to left), you get the second sequence.
0xCB340102 is binary1100 1011 0011 0100 0000 0001 0000 0010.
0x40802CD3 is binary0100 0000 1000 0000 0010 1100 1101 0011.

IRremote functions

UsebitreverseOneByte() orbitreverse32Bit() for reversing.

Online tool which reverses every byte, but not the order of the bytes

Use thistool provided by analysir.

Send MSB directly

Sending old MSB codes without conversion can be done by usingsendNECMSB(),sendSonyMSB(),sendSamsungMSB(),sendJVCMSB().


Errors when using the 4.x versions for old tutorials

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


Staying on 2.x

Consider using theoriginal 2.4 release form 2017or the last backwards compatible2.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.

Drawbacks of using 2.x

  • Only the following decoders are available:
    NEC    Denon    Panasonic    JVC    LG
    RC5    RC6    Samsung    Sony
  • The call ofirrecv.decode(&results) uses the old MSB first decoders like in 2.x and sets the 32 bit codes inresults.value.
  • No decoding to a more meaningful (constant) 8/16 bit address and 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 onVerify orUpload.

And now our problem with Arduino is:
How to setcompile options for all *.cpp files, especially for libraries used?
IDE's likeSloeber orPlatformIO 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 theworkaround 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 extensioncpp is not longer possible, and one solution is to usehpp as extension, to show that it is an included *.cpp file.
Every other extension e.g.cinclude would do, buthpp seems to be common sense.

Using the new *.hpp files

In order to supportcompile 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()).

Inall other files you must use the following, topreventmultiple definitions linker errors:

#defineUSE_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

Tutorials

  • A very elaborated introduction to IR remotes and IRremote library fromDroneBot Workshop.

3 ways to specify an IR code

There are 3 different ways of specifying a particular IR code.

1. Timing

The timing of each mark/pulse and space/distance_between_pulses is specified in a list or array.This enables specifyingall IR codes, but requires a lot of memory and isnot readable at all.One formal definition of such a timing array, includingspecification of frequency and repeats is thePronto 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 thehash of the timing provided by thedecodeHash() decoder.

2. Encoding schemes

There are 3 main encoding schemes which encodes a binary bitstream / hex value:

  1. 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.
  2. 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.
  3. 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 aconstant bit length,PULSE_DISTANCE with constant pulse width andPULSE_WIDTH haveno constant bit length!

A well known example forPULSE_DISTANCE with non constant pulse width encoding is theRS232 serial encoding.Here the non constant pulse width is used to enable aconstant bit length.

Most IR signals have aspecial 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 aPULSE_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.TheHobToHood 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 isquite readable.These schemes can not put any semantics like address, command or checksum on this bitstream.

3. Protocols

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 parametersaddress andcommand to specify an IR code.This saves memory and ishighly readable.Often the address is also constant, which further reduces memory requirements.

IRReceiver pinouts

IRReceiver Pinout

Adafruit IR Sensor tutorial

Receiving IR codes

In your program you check for acompletely 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 asIrReceiver.decodedIRData.

decodedIRData structure

structIRData {decode_type_t protocol;// UNKNOWN, NEC, SONY, RC5, PULSE_DISTANCE, ...uint16_t address;// Decoded addressuint16_t command;// Decoded commanduint16_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 thelist of flags contained in the flags field.
Check it with e.g.if(IrReceiver.decodedIRData.flags & IRDATA_FLAGS_IS_REPEAT).

Flag nameDescription
IRDATA_FLAGS_IS_REPEATThe 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_REPEATThe 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_FAILEDThe current (autorepeat) frame violated parity check.
IRDATA_FLAGS_TOGGLE_BITIs set if RC5 or RC6 toggle bit is set.
IRDATA_FLAGS_EXTRA_INFOThere is extra info not contained in address and data (e.g. Kaseikyo unknown vendor ID, or in decodedRawDataArray).
IRDATA_FLAGS_WAS_OVERFLOWToo many marks and spaces for the specifiedRAW_BUFFER_LENGTH. To avoid endless flagging of overflow, irparams.rawlen is set to 0 in this case.
IRDATA_FLAGS_IS_MSB_FIRSTThis value is mainly determined by the (known) protocol.

To access theRAW data, use:

auto myRawdata= IrReceiver.decodedIRData.decodedRawData;

The definitions for theIrReceiver.decodedIRData.flags are describedhere.

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

TheNEC 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.
Theextended NEC protocol uses the additional 8 parity bit of address for a 16 bit address, thus disabling the parity check for address.
TheONKYO 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. the16 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 toalways use the ONKYO protocol interpretation by using#define DECODE_ONKYO.Another way is to check ifIrReceiver.decodedIRData.protocol is NEC and not ONKYO and to revert the parity reducing manually.

NEC, NEC2

On a long press, theNEC 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 theNEC2 protocol and it is sent withsendNEC2().
But be careful, the NEC2 protocol can only be detected by the NEC library decoderafter the first frame and if you do a long press!

Samsung, SamsungLG

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

RAM usage of different protocols

TheRAW_BUFFER_LENGTH determines the length of thebyte buffer where the received IR timing data is stored before decoding.
100 is sufficient for standard protocolsup 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 abuffer length of 68.
  • 16 bit protocols like BOSEWAVE, DENON, FAST, JVC, LEGO_PF, RC5, SONY(12 or 15) require abuffer length of 36.
  • MAGIQUEST requires a buffer length of112.
  • Air conditioners often send a longer protocol data streamup to 750 bits.

If the record gap determined byRECORD_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.

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.

Use theReceiveDemo example to print out all informations about your IR protocol.
TheReceiveDump example gives you more information but has bad repeat detection due to the time required for printing the information.

Other libraries, which may cover these protocols

IRMP

If your protocol seems not to be supported by this library, you may try theIRMP library, which especially supports manchester protocols much better.

IRremoteESP8266

Forair conditioners , you may try theIRremoteESP8266 library, which supports an impressive set of protocols and a lot of air conditioners and works also on ESP32.

rawirdecode and HeatpumpIR

Raw-IR-decoder-for-Arduino is not a library, but an arduino example sketch, which provides many methods of decoding especiallyair conditioner protocols. Sending of these protocols can be done by the Arduino libraryHeatpumpIR.

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 of56 bits, which is probably from an air conditioner remote.
You can send it withsendPulseDistanceWidth().

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 callingsendPulseDistanceWidthData() twice, once for the first 32 bit and next for the remaining 24 bits.
ThePULSE_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 readLSB first by default.If LSB does not suit for further research, you can change ithere.

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.

Protocol=UNKNOWN

If you see something likeProtocol=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 anodd 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 thereforeMARK_EXCESS_MICROS (specified in your ino file) should benegative to compensate for this at decoding.
  • If you seeProtocol=UNKNOWN Hash=0x0 1 bits received it may be that the space after the initial mark is longer thanRECORD_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.


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 theReceiveDemo 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 firstSend with: IrSender.sendLG(0x2, 0x3434, <numberOfRepeats>);

You will discover thatthe 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 enabledDECODE_DISTANCE_WIDTH, the code printed byprintIRSendUsage()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, thatthere 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.

Sendingold MSB codes without conversion can be done by usingsendNECMSB(),sendSonyMSB(),sendSamsungMSB(),sendJVCMSB()or byconverting them manually to LSB.

Sending IRDB IR codes

The codes found in theFlipper-IRDB database are quite straightforward to convert, because the also use the address / command scheme.
Protocol matching is NECext -> Onkyo, Samsung32 -> Samsung, SIRC20 -> Sony with 20 bits etc.

The codes found in theirdb database specify adevice, asubdevice and afunction.Most of the times,device andsubdevice can be taken as upper and lower byte of theaddress parameter andfunctionis thecommand parameter for thenew structured functions with address, command and repeat-count parameterslike e.g.IrSender.sendNEC((device << 8) | subdevice, 0x19, 2).
Anexact mapping can be found in theIRP definition files for IR protocols."D" and "S" denotes device and subdevice and "F" denotes the function.

Send pin

Any pin can be chosen as send pin as long asIR_SEND_PIN isnot defined.This is because the PWM signal is generated by default with software bit banging, sinceSEND_PWM_BY_TIMER is not active.
OnESP32 ledc channel 0 is used for generating the IR PWM.
IfIR_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. withsetSendPin(uint8_t aSendPinNumber), you must disable thisIR_SEND_PIN macro e.g. with#undef IR_SEND_PIN.Then you can change send pin at any time before sending an IR frame.See alsoCompile options / macros for this library.

Polarity of send pin

By default the polarity is HIGH for active and LOW for inactive or pause.This corresponds to the connection schema: Pin -> Resistor-> IR-LED -> Ground.
If you want to use the connection schema: VCC -> IR-LED -> Resistor -> Pin, you must specifyUSE_ACTIVE_LOW_OUTPUT_FOR_SEND_PIN.

List of public IR code databases

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

Flipper Zero

Flipper IRDB Database

Flipper decodingIRremote decoding
Samsung32Samsung
NECNEC
NECextONKYO
<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 verysmall code size of 500 bytes and does NOT require any timer.

Principle of operation

Instead of sampling the input every 50 µs as IRremote does, TinyReceiver receiver uses apin 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, wecannot 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 decodingand the call of the optionaluser provided callback functionhandleReceivedTinyIRData().
This means,we need to know the number of bits in a protocol and therefore the protocol (family).

Check out theTinyReceiver andIRDispatcherDemo examples.
Take care to includeTinyIRReceiver.hpp orTinyIRSender.hpp instead ofIRremote.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"voidsetup() {initPCIInterruptForTinyReceiver();// Enables the interrupt generation on change of IR input signal}voidloop() {if (TinyReceiverDecode()) {printTinyReceiverResultMinimal(&Serial);    }// No resume() required :-)}

TinyIRSender usage

#include"TinyIRSender.hpp"voidsetup() {sendNEC(3,0,11,2);// Send address 0 and command 11 on pin 3 with 2 repeats.}voidloop() {}

Another tiny receiver and sendersupporting more protocols can be foundhere.

The FAST protocol

The FAST protocol is a proprietary modified JVC protocolwithout 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 takes21 ms for sending and is sent at a50 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

#defineIR_SEND_PIN3#include<IRremote.hpp>voidsetup() {sendFAST(11,2);// Send command 11 on pin 3 with 2 repeats.}voidloop() {}

Sending FAST protocol with TinyIRSender

#defineUSE_FAST_PROTOCOL// Use FAST protocol. No address and 16 bit data, interpreted as 8 bit command and 8 bit inverted command#include"TinyIRSender.hpp"voidsetup() {sendFAST(3,11,2);// Send command 11 on pin 3 with 2 repeats.}voidloop() {}

The FAST protocol can be received by IRremote and TinyIRReceiver.

FAQ and hints

Receiving stops after analogWrite() or tone() or after running a motor.

The receiver sample interval of 50 µs is generated by a timer. On many boards this must be ahardware 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 foranalogWrite().
Especiallymotor control often uses theanalogWrite() function and will therefore stop the receiving if used on the pins indicatedhere.
On the Uno and other AVR boards the receiver timer ist the same as the tone timer. Thus receiving will stop after atone() command.SeeReceiveDemo example how to deal with it, i.e. how to useIrReceiver.restartTimer().

Receiving sets overflow flag.

The flagIRDATA_FLAGS_WAS_OVERFLOW is set, ifRAW_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, ifRECORD_GAP_MICROS is smaller than the real gap between a frame and the repetition frame, thus interpreting both as one consecutive frame.Best is to dump the timing then, to see which reason holds.

Problems with Neopixels, FastLed etc.

IRremote will not work right when you useNeopixels (aka WS2811/WS2812/WS2812B) or other libraries blocking interrupts for a longer time (> 50 µs).
Whether you use the Adafruit Neopixel library, 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 thisvideo.

Oneworkaround is to wait for the IR receiver to be idle before you send the Neopixel data withif (IrReceiver.isIdle()) { strip.show();}.
Thisprevents 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 lineIrReceiver.begin(IR_RECEIVE_PIN, ENABLE_LED_FEEDBACK);.
This is often due totimer resource conflicts with the other library. Please seebelow.

Multiple IR receiver and sender instances

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 usesetSendPin() to switch the pin to send, thus emulating multiple sender.
The receiver uses a specialtimer triggered function, which reads the digital IR signal value from one pin every 50 µs.
Somultiple 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.

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 power2 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 Ω.
For3 diodes it requires 1.4 V / 20 mA =70 Ω.
The actual current might be lower since ofloss 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, theminimal 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, thedefault 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 #defineDECODE_<XYZ>. It must always be enabled explicitly by#define DECODE_BEO.This is because it has anIR transmit frequency of 455 kHz and therefore requires a different receiver hardware (TSOP7000).
And becausegenerating a 455 kHz PWM signal is currently only implemented forSEND_PWM_BY_TIMER, sending only works ifSEND_PWM_BY_TIMER orUSE_NO_SEND_PWM is defined.
For more info, seeir_BangOlufsen.hpp.

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, theArduino library ATtinySerialOut is required for this CPU's.
See alsoDroneBot Workshop SimpleReceiver andSimpleSender.

SimpleReceiver + SimpleSender

TheSimpleReceiverandSimpleSender examples are a good starting point.A simple example can be tested online withWOKWI.

SimpleReceiverForHashCodes

TheSimpleReceiverForHashCodes 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

TinyReceiver + TinySender

Ifcode size ortimer usage matters, look at these examples.
TheTinyReceiver example uses theTinyIRReceiver librarywhich canonly 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 withWOKWI.

TheTinySender example uses theTinyIRSender library which canonly 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 thisexample.

ReceiveDemo + AllProtocolsOnLCD

ReceiveDemo receives all protocols andgenerates 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 additionallydisplays 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 anexample how to use IRremote and tone() together.

ReceiveDump

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

SendDemo

Sends all available protocols at least once.

MultipleSendPins

Demonstrates sending IR codes toggling between 2different send pins.

SendAndReceive

Demonstratesreceiving while sending.

ReceiveAndSend

Record andplay 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 withsendRaw().

ReceiveAndSendDistanceWidth

Try to decode each IR frame with theuniversalDistanceWidth decoder, store the data and send it on button press withsendPulseDistanceWidthFromArray().
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.

ReceiveOneAndSendMultiple

Serves as a IRremote 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 aNetflix-key emulation for my old Samsung H5273 TV.

IRDispatcherDemo

Framework forcalling 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 functionbool Aircondition_LG::sendCommandAndParameter(char aCommand, int aParameter) you can control the air conditioner by any other command source.
The fileacLG.h contains the command documentation of the LG air conditioner IR protocol. Based on reverse engineering of the LG AKB73315611 remote.LG AKB73315611 remote
IReceiverTimingAnalysis can be tested online withWOKWIClick on the receiver while simulation is running to specify individual IR codes.

ReceiveAndSendHob2Hood

Example for receiving and sending AEG / Elektrolux Hob2Hood protocol.

ReceiverTimingAnalysis

Thisexample 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 theMARK_EXCESS_MICROS value, which is the extension of the mark (pulse) duration introduced by the IR receiver module.
It can be tested online withWOKWI.Click on the receiver while simulation is running to specify individual NEC IR codes.

UnitTest

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

WOKWI online examples

IR control of a robot car

Thisexample of theArduino 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.
IR_RobotCar


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 programbefore the line#include <IRremote.hpp> to take effect.
Modify them by enabling / disabling them, or change the values if applicable.

NameDefault valueDescription
RAW_BUFFER_LENGTH200Buffer size of raw input uint16_t buffer. Must be even! If it is too small, overflow flag will be set. 100 is sufficient forregular 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_PROTOCOLSdisabledExcludes the universal decoder for pulse distance width protocols and decodeHash (special decoder for all protocols) fromdecode(). Saves up to 1000 bytes program memory.
EXCLUDE_EXOTIC_PROTOCOLSdisabledExcludes BANG_OLUFSEN, BOSEWAVE, WHYNTER, FAST and LEGO_PF fromdecode() and from sending withIrSender.write(). Saves up to 650 bytes program memory.
DECODE_<Protocol name>allSelection of individual protocol(s) to be decoded. You can specify multiple protocols. Seehere
DECODE_STRICT_CHECKSdisabledCheck 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_CALLBACKdisabledSaves up to 60 bytes of program memory and 2 bytes RAM.
MARK_EXCESS_MICROS20MARK_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_MICROS5000Minimum 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_SIZE50 if RAM <= 2k, else 200A value of 200 allows to decode mark or space durations up to 10 ms.
IR_INPUT_IS_ACTIVE_HIGHdisabledEnable it if you use a RF receiver, which has an active HIGH output signal.
IR_SEND_PINdisabledIf specified, it reduces program size and improves send timing for AVR. If you want to use a variable to specify send pin e.g. withsetSendPin(uint8_t aSendPinNumber), you must not use / disable this macro in your source.
SEND_PWM_BY_TIMERdisabledDisables carrier PWM generation in software and use hardware PWM (by timer). Has theadvantage of more exact PWM generation, especially the duty cycle (which is not very relevant for most IR receiver circuits), and thedisadvantage 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 thededicated timer output pin(s). Is enabled for ESP32 and RP2040 in all examples, since they support PWM generation for each pin without using a shared resource (timer).
IR_SEND_DUTY_CYCLE_PERCENT30Duty cycle of IR send signal.
USE_ACTIVE_LOW_OUTPUT_FOR_SEND_PINdisabledReverses the polarity at the send pin. Can be used to connect IR LED between VCC and the send pin. It is like open drain but with electrical active high in its logical inactive state.
USE_OPEN_DRAIN_OUTPUT_FOR_SEND_PINdisabledUses 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!
USE_NO_SEND_PWMdisabledUses no carrier PWM, just simulate anactive low receiver signal. Used for transferring signal by cable instead of IR. OverridesSEND_PWM_BY_TIMER definition.
USE_ACTIVE_HIGH_OUTPUT_FOR_NO_SEND_PWMdisabledOnly ifUSE_NO_SEND_PWM is enabled. Simulate anactive high receiver signal instead of an active low signal.
DISABLE_CODE_FOR_RECEIVERdisabledDisables 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.
FEEDBACK_LED_IS_ACTIVE_LOWdisabledRequired on some boards (like my BluePill and my ESP8266 board), where the feedback LED is active low.
NO_LED_FEEDBACK_CODEdisabledDisables 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.
NO_LED_RECEIVE_FEEDBACK_CODEdisabledDisables the LED feedback code for receive. Saves around 100 bytes program memory for receiving and halving the receiver ISR (Interrupt Service Routine) processing time.
NO_LED_SEND_FEEDBACK_CODEdisabledDisables the LED feedback code for send. Saves around 500 bytes for sending.
MICROS_PER_TICK50Resolution 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_PERCENT25Relative tolerance for matchTicks(), matchMark() and matchSpace() functions used for protocol decoding.
DEBUGdisabledEnables lots of lovely debug output.
IR_USE_AVR_TIMER*Selection of timer to be used for generating IR receiving sample interval.

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

NameDefault valueDescription
IR_RECEIVE_PIN2The pin number for TinyIRReceiver IR input, which gets compiled in. Not used in IRremote.
IR_FEEDBACK_LED_PINLED_BUILTINThe pin number for TinyIRReceiver feedback LED, which gets compiled in.
NO_LED_FEEDBACK_CODEdisabledDisables the feedback LED code for send and receive. Saves 14 bytes program memory.
NO_LED_RECEIVE_FEEDBACK_CODEdisabledDisables the LED feedback code for receive.
NO_LED_SEND_FEEDBACK_CODEdisabledDisables the LED feedback code for send.
DISABLE_PARITY_CHECKSdisabledDisables the address and command parity checks. Saves 48 bytes program memory.
USE_EXTENDED_NEC_PROTOCOLdisabledLike 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_PROTOCOLdisabledLike 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_PROTOCOLdisabledUse FAST protocol (no address and 16 bit data, interpreted as 8 bit command and 8 bit inverted command) instead of NEC.
ENABLE_NEC2_REPEATSdisabledInstead of sending / receiving the NEC special repeat code, send / receive the original frame for repeat.
USE_CALLBACK_FOR_TINY_RECEIVERdisabledCall the user provided functionvoid handleReceivedTinyIRData() each time a frame or repeat is received.

The next macro forIRCommandDispatcher must be defined in your program before the line#include <IRCommandDispatcher.hpp> to take effect.|USE_TINY_IR_RECEIVER | disabled | UseTinyReceiver 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 | | IfUSE_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, useSketch > 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 parallellibraries folder and select the library you want to access.
In both cases the library source and include files are located in the librariessrc 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 theplatformio.ini file withbuild_flags = -D MACRO_NAME orbuild_flags = -D MACRO_NAME=macroValue.

Modifying compile options / macros with Sloeber IDE

If you are usingSloeber as your IDE, you can easily define global symbols withProperties > Arduino > CompileOptions.
Sloeber settings


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.
ForESP8266/ESP32,the IRremoteESP8266 library supports animpressive set of protocols and a lot of air conditioners
ATtiny CPU's are tested with theArduino library ATtinySerialOut library.

Digispark boards are only tested withATTinyCore usingNew Style pin mapping for the Digispark Pro board.
ATtiny boards are tested withATTinyCore ormegaTinyCore only.

  • 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 thearduino:renesas_uno:unor4wifi.
  • Teensy 1.0 / 1.0++ / 2.0 / 2++ / 3.0 / 3.1 / 3.2 / Teensy-LC - butlimited 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)
  • SAMD (Zero, MKR*,but not DUE, the latter is SAM architecture)
  • ESP8266
  • ESP32 (ESP32-C3 since board package 2.0.2 from Espressif). New CPUs (as of January 2025) are not guaranteed to work!
  • 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.)

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 provideexamples 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

Thereceiver 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.
OnESP8266timer1 is used for receive interrupts, which makes it incompatible to the Servo and other libraries.
OnESP32hw_timer_t is used for receive interrupts.

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 theTinyReceiver library, which canonly receive NEC codes, but does not require any timer and runs even on a 1 MHz ATtiny85.

The code for the timer and thetimer selection is located inprivate/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/CPUReceive
& send PWM Timer
Default timer isbold
Hardware-Send-PWM PinanalogWrite()
pins occupied by timer
ATtiny8416
ATtiny85 > 4 MHz0, 10, 40, 1 & 4
ATtiny88 > 4 MHz1PB1 / 8PB1 / 8 & PB2 / 9
ATtiny167 > 4 MHz19, 8 - 158 - 15
ATtiny1604TCB0PA05
ATtiny1614, ATtiny816TCA0PA3
ATtiny3217TCA0, TCD%
ATmega819
ATmega12841,2, 313, 14, 6
ATmega164, ATmega324, ATmega6441,213,14
ATmega8535 ATmega16, ATmega32113
ATmega64, ATmega128, ATmega1281, ATmega2561113
ATmega8515, ATmega162113
ATmega168,ATmega3281,29,39 & 10,3 & 11
ATmega1280,ATmega25601,2, 3, 4, 55, 6,9, 11, 465, 6,9, 11, 46
ATmega4809TCB0A4
Leonardo (Atmega32u4)1, 3,4_HS5,9, 135,9, 13
Zero (SAMD)TC3*,9
ESP8266timer1%
ESP32hw_timer_t
Ledc channel 0
All pins
Sparkfun Pro Micro1,35, 9
Teensy 1.011715, 18
Teensy 2.01, 3,4_HS9,10, 1412
Teensy++ 1.0 / 2.01,2, 31, 16, 250
Teensy-LCTPM11617
Teensy 3.0 - 3.6CMT5
Teensy 4.0 - 4.1FlexPWM1.387, 25
BluePill / STM32F103C8T63%PA6 & PA7 & PB0 & PB1
BluePill / STM32F103C8T6TIM4%PB6 & PB7 & PB8 & PB9
RP2040 / Pi Picodefault alarm poolAll pinsNo pin
RP2040 / Mbed basedMbed TickerAll pinsNo pin

No timer required for sending

Thesend 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 usingdelayMicroseconds().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 formerSerial.print() statement to be finished bySerial.flush().Since the Arduinomicros() 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 coremicros() function for an ATmega328Detail (ATmega328 generated) showing 30% duty cycle
Software PWMSoftware PWM detail

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, sincethe timer resource cannot be shared simultaneously by both libraries.

Use NEC protocol and TinyReceiver

TinyReceiver does not require a timer, it relies on interrupts, thus avoiding any timer resource problems.

Change timer

The best approach is tochange 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 inprivate/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#defineIR_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 areIR_USE_AVR_TIMER[1,2,3,4,5].
Youjust 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 again incompatible with other libraries or Arduino functions.
For non AVR 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 timersequentially if their functionality is used only for a short period of time like for theArduino tone() command.An example can be seenhere, where the IR timer is restarted after the tone has stopped.

IrReceiver.stopTimer();// Stop timer consistently before calling tone() or other functions using the timer resource.tone(TONE_PIN,2200,8);delay(8);IrReceiver.restartTimer();// Restart IR timer after timer resource is no longer blocked.

This works on AVR boards like Uno because each call to tone() completely initializes the timer 2 used by thetone() command.

Hardware-PWM signal generation for sending

If you defineSEND_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. Seeprivate/IRTimer.hpp
Exceptions are currentlyESP32, ARDUINO_ARCH_RP2040, PARTICLE and ARDUINO_ARCH_MBED,wherePWM generation does not require a timer.

Why do we use 30% duty cycle for sending

Wedo it according to the statement in theVishay 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.16The 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 a50 µ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!
Thereforewe decode by default with a +/- 25% margin using the formulashere.
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 theMARK_EXCESS_MICROS macroto compensate for this receiver (and signal strength as well as ambient light dependent 😞 ) specific deviation.
Welcome to the world ofreal world signal processing.


NEC encoding diagrams

Created with sigrok PulseView with IR_NEC decoder by DjordjeMandic.
8 bit address NEC code8 bit address NEC code16 bit address NEC code16 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 formyself in order to choose a small IR library for my project and to have a quick overview, when to choose which library.
It is dated from24.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 anESP8266/ESP32 version of IRremote with animpressive list of supported protocols.

SubjectIRMPIRLremoteIRLib2
mostly unmaintained
IRremoteTinyIRIRsmallDecoder
Number of protocols50Nec + Panasonic + Hash *12 + Hash *17 + PulseDistance + Hash *NEC + FASTNEC + RC5 + Sony + Samsung
Timing method receiveTimer2 or interrupt for pin 2 or 3InterruptTimer2 or interrupt for pin 2 or 3Timer2InterruptInterrupt
Timing method sendPWM and timing with Timer2 interruptsTimer2 interruptsTimer2 and blocking waitPWM with Timer2 and/or blocking wait with delay
Microseconds()
blocking wait with delay
Microseconds()
%
Send pinsAllAllAll ?Timer dependentAll%
Decode methodOnTheFlyOnTheFlyRAMRAMOnTheFlyOnTheFly
Encode methodOnTheFlyOnTheFlyOnTheFlyOnTheFly or RAMOnTheFly%
Callback supportx%%xx%
Repeat handlingReceive + Send (partially)%?Receive + SendReceive + SendReceive
LED feedbackx%xxReceive%
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)
48301770900?1100?
RAM usage52
(73 / 100 for 15 (main) / 40 protocols)
623342271929
Supported platformsavr, megaavr, attiny, Digispark (Pro), esp8266, ESP32, STM32, SAMD 21, Apollo3
(plus arm and pic for non Arduino IDE)
avr, esp8266avr, SAMD 21, SAMD 51avr, attiny,esp8266, esp32, SAM, SAMDAll platforms with attach
Interrupt()
All platforms with attach
Interrupt()
Last library update5/20234/201811/20229/20235/20232/2022
RemarksDecodes 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.
SupportsPronto 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 Shirriffhttp://www.righto.com
Copyright (c) 2016-2017 Rafi Khanhttps://rafikhan.io
Copyright (c) 2020-2025Armin Joachimsmeyer


[8]ページ先頭

©2009-2025 Movatter.jp