IRLib Updated to Version 1.3

A new version of IRLib is now available on GitHub at
https://github.com/cyborg5/IRLib/

Down three IRLib is a library of code for Arduino-based microcontrollers that facilitates sending, receiving, decoding and analyzing infrared remote signals. Here is an overview of the changes.

  • NEW FILES

    • Added new file IRLibRData.h and moved irparams structure and related items to that file. Allows users to create custom IRrecv classes
  • NEW EXAMPLES
    • Rewrote Samsung36 example to include both send and receive
    • Added new examples for new protocols DirecTV and GIcable
    • Added new example IRanalyze gives more detailed analysis of timing. Useful in analyzing the protocols
    • Added new example IRfreq reports modulation frequency of a signal. Requires TSMP58000 IR learner chip
    • Cleanup of other example routines.
  • NEW CLASSES
    • Created IRrecvBase class to allow custom receiver classes. IRrecv is now a derived class from it.
    • Created IRrecvLoop class which receives IR signals without using any hardware interrupts or timers. Also created IRrecvPCI class which uses Pin Change Interrupts to receive IR signals. These new receivers are more accurate than the 50µs timing of the original IRrecv. However they also have other limitations described in comments.
  • NEW FUNCTIONS, VARIABLES AND METHODS
    • In IRrecvBase added “unsigned char Mark_Excess” with default value 100. Was a define macro but now is user settable.
    • In IRrecvBase added method “unsigned char getPinNum(void);” which retrieves the pin number used from irparams.recvpin. This value not normally accessible to end user.
    • Globally available function “void do_Blink(void);” blinks pin 13 LED. For use by user created extensions of IRrecvBase.
  • INTERNAL CHANGES
    • Data collected by IRrecvBase classes in irparams.rawbuf is now converted to actual microseconds rather than clock ticks of 50 µs each. IRrecvBase::GetResults has a new parameter “Time_per_Ticks” that is used to convert ticks into actual microseconds if needed.
    • Adjustments to mark and space to deal with overreporting and underreporting of intervals is now done once in IRrecvBase::GetResults eliminating the need for MATCH_MARK(d,v) and MATCH_SPACE(d,v). Just use MATCH(d,v) everywhere.
    • Modified IRLibsendBase::mark() and IRLibsendBase::space() to overcome limitations of “delayMicroseconds()”.
    • Changed many int to char or unsigned char to save memory
    • Eliminated DEBUG macro in IRLib.h and its use elsewhere. Macro TRACE is more useful.
    • Changed IRTYPES to unsigned char and a list of #defines rather than an enum (even though I still really like enums, changing it saves memory)
  • MEMORY EFFICIENCY
    • Code changes result in memory savings of approximately 54 bytes in code space and 39 bytes of RAM.

    For more information see my IRLib page.

5 thoughts on “IRLib Updated to Version 1.3

    • I could not have done it without you. You should also know that the new IRrecvPCI which uses the pin change interrupt is based upon/inspired by your code. One thing I would like your input about. Ken Shirriff who wrote the original IRremote library built in a 100 µs bias because he says that the timing on a mark is over reported in the timing on a space is underreported by that amount. I made that bias user settable in the new version of the library. My tests show that 50 µs adjustment on both sides was a little bit more accurate. I’m wondering what your experience is in that regards.

      • Regarding the timings:
        Yes its rarely more than 100 USecs out & 50 uSecs is closer to reality. But we only use Vishay components and lower quality Receivers may have longer distortions.

        Many things will impact it:
        – AGC algorithm used in the IR Receiver
        – different receivers
        – strength of signal & distance
        – ambient light
        – inteference

        So your approach of making it configurable is best.
        Also, I find that the sum of the mark/space generally turns out to be a more accurate/ reliable indictor when decoding new signals, given the distorion of the individual mark or space timings. Using total elaped time will also get you better accuracy vs individual durations of marks & spaces, particularly when decoding unknown signals for the first time.

        Coincidently, we have been working on a new IR device in recent weeks, where we automatically clean up the signal by 30 uSecs on average, but we may adjust this higher towards 50 uSecs before release. So far the results have been excellent.

        Regarding your new IRfreq code example….if you just leave BUF_SIZE at 256 then ‘Count’ will just wrap round to zero after 255. This means that you don’t have to worry about keeping some spare slots for more interrupts. But you would have to use 255 instead of Count in the Report_Freq() function, in case it was updated by the ISR.

  1. Hi,

    Do you have any plans to implement Denon IR protocol?
    Thanks!

    Decoded Unknown: Value:0 (0 bits)
    Raw samples(32): Gap:43950
    Head: m200 s850
    0:m200 s1900 1:m200 s800 2:m200 s850 3:m200 s850
    4:m200 s1900 5:m200 s850 6:m150 s900 7:m200 s850
    8:m150 s1950 9:m150 s1900 10:m200 s1900 11:m150 s1950
    12:m150 s850 13:m200 s900 14:m150
    Extent=22100
    Mark min:150 max:200
    Space min:800 max:1950

    • That protocol is strange because it does not include a header and contains a long gap in the middle. Many learning remotes only process half of signal. I would have to do the math but there’s a possibility that the gap in the middle would be identified as the end of the signal in my library. Can you give me an idea of what type of device uses this protocol. Perhaps I can find such a device on my universal remote and can play with it that way. The IRP notation for that protocol is {38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165,D:5,~F:8,3:2,1,-165)+ if you would like to try to program it yourself. The sample which you sent is only half of the entire signal. I would have to take a long look to see if you sent me the front half or the back half. Either half sufficient to identify the command but that doesn’t necessarily mean that your device would recognize half a sequence if you transmitted to it. Let me know what type of device (TV, DVD, Blu-ray whatever) and the manufacturer (Sony, NEC, Panasonic, whatever) and I will see what I can do.

Leave a Reply

Your email address will not be published. Required fields are marked *