Skip to content

ma-laforge/ArduinoCIR

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

8 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

ArduinoCIR: Consumer IR Control

Description

ArduinoCIR provides the ir_messaging library, a ready-to-use solution for sending/receiving consumer IR (remote-control) signals on Arduino platforms.

Supported Hardware

ArduinoCIR was designed to support multiple Atmel platforms. At the moment, only a few are supported:

  • Atmel ATmega328/328P
    • Arduino Uno
    • Arduino Redboard (Tested)
    • Arduino Pro
    • Arduino Fio
    • Arduino Mini
    • Arduino Nano
    • Arduino LilyPad
    • Arduino BT
    • Arduino Ethernet
  • Atmel ATmega1280
    • Arduino Mega
  • Atmel ATmega2560
    • Arduino Mega 2560 (Tested)
    • Arduino Mega ADK (Tested)

Supported Protocols

The list of supported protocols is listed below. Note that certain protocols might only be implemented for either transmit (tx) or receive (rx).

  • NEC: (tx/rx).
  • RC-MM: (tx only).
  • RC-5: (untested tx/untested rx).
  • Sony SIRC: (untested tx/rx).

New protocols can be added to libraries/ir_messaging/ir_protocol.cpp/.h.

Purpose (Is there not IRremote already?)

Indeed, the IRremote library already exists to interface Arduino platforms with consumer IR products. The main differating factor of the ir_messaging library is that it does not hardcode the allocation of hadware timers.

Here are a few advantages of ir_messaging:

  • Designed to simultaneously transmit & receive IR messages.
    • Last version of IRremote I checked used the same timer hardware for both transmit & receive (contention). Moreover, the trival time-interleaved (tx ⇔ rx) solution is not very robust.
  • Easier to select which timers & I/O pins to use for transmit/receive function.
    • No need to read/modify core library files.
    • Hardware select can be easily deduced from sample sketches (+ minimal knowldege of hardware timers).
  • Uses IRMsg class to simplify API (protocol, data & message length stay together).
  • More modular approach to supporting different chipsets.
  • Seems to be a slightly more robust solution (but cannot remember exact reason why that is).

Untested advantages:

  • Could easily support asynchronous (non-blocking) transmit (not yet made available).
    • Uses ISR to modulate transmit carrier.
  • Build solutions supporting 2+ receivers or 2+ transmitters (Speed & hardware permitting).

Any reason to use IRremote instead?

Definitely. There are a few reasons to use IRremote instead of the ir_messaging library. Some that come to mind are listed below:

  • At the moment, IRremote supports more IR protocols.
    • Only an advantage if your project must communicate with a given (un-supported) protocol.
    • NOTE: Possible to add support for other protocols in ir_messaging.
  • At the moment, IRremote supports more Arduino platforms.
  • Might not be as comfortable making customizations to the ir_messaging library.
    • Implementation makes heavy use of C++ constructs (ex: objects).
    • Code is divided into more files (This might not fit the way you work).
    • Object/module hierarchy is more elaborate than IRremote.
  • Currently generates smaller binaries.
  • Larger community for support.

Sample Sketches

ir_messaging provides 3 sample sketches under the libraries/ir_messaging/samples sub-directory:

  • ir_tx_onbutton: Simple sketch that transmits a hard-coded IR message when a button is pressed.
  • ir_rx_sniff: Simple sketch that dumps recieved signal to serial output.
  • ir_repeater: Simple sketch that re-transmits valid incomming IR messages.
    • Note that this sketch only supports the Arduino Mega platforms. Due to interrupt priorities, platforms that use the system clock (Timer0) for modulating the IR output will not successfully receive all incomming signals. This task requires a bit more synchronization of the IR traffic.

Usage Tips

Atmel Timer0: Time & Delays

On what appears to be all Atmel chipsets, the Arduino software uses timer0 to measure time & implement delays (delay(), delayMicroseconds(), millis(), micros()). Better not appropriate this timer for anything else.

Atmel: Timer Priorities

Interrupt priority on on Atmel timers appear to match their number (highest priority for timer0, then timer1, ...). To avoid potential signal jitter issues, select the lowest available timer (ex: timer1) to modulate the transmitter output (TxHw::tmrMod).

Register Writes

To guarantee proper initialization of the Arduino platforms, it appears hardware register writes must be executed after construction of static objects. Thus, register writes performed during the construction phase of static global objects simply do not persist. I believe the intent was for users to perform these register writes within Arduino's "setup()" function.

Interference on "ir_repeater"

The biggest issue with the ir_repeater sample project is its inherent succeptibility to interference between the originating IR remote and the repeated signal. Most IR controller diodes are designed to drive significant power over a broad range of angles. Without proper isolation, the repeated signal might leak back into the arduino's IR receiver... and if that does not cause an interference problem, the originating signal from the consumer IR remote will then likely collide with the repeated signal - confusing the IR receiver of the end-user equipment.

To solve this problem, the originating signal from the consumer IR remote should be physically isolated from the repeated signal.

I found that boxes to store ESD-sensitive devices, like the 37054 Protektive Pak are ideal for the task. Simply place the receiver module (possibly with the arduino itself) in the box, and solder the transmit diode to the end of a ~1m+, 18AWG speaker wire. The speaker wire will make it easy to effectively direct the repeated signal to the end-user equipment. If the consumer IR remote is pointed away from this direction and shrouded sufficiently by the ESD box (where the arduino reciever module is listening), interference should no longer be a problem.

Circuit Topology

Very little external circuitry is required for IR communication. Ken Shirriff provides a good reference circuit for use with his own IRremote library. The only major caveat to using his topology is with regards to the default choice of I/O pins (see section Hardware/Pinout Selection). Given all this good work, please visit Ken's IRremote page for the wiring diagram.

Similarly, a wiring diagram for the push button signal required by the ir_tx_onbutton sketch can be found on Ken's record/playback project page (again, see section Hardware/Pinout Selection for default pinout):

Hardware/Pinout Selection

The ir_messaging library is relatively flexible. The IR receiver software can be configured to listen on any available pin. However, the transmitter output pin is controlled by whatever timer generates the output carrier:

  • ATmega328/328P
    • Timer2: Pin 3.
  • ATmega1280/2560
    • Timer1: Pin 11.
    • Timer2: Pin 9.
    • Timer3: Pin 5.
    • Timer4: Pin 6.

Please refer to the appropriate datasheet for more details regarding the capabilities of your particular Arduino platform.

Libraries (Dependencies)

NOTE: All libraries listed below are included as part of the ir_messaging project.

  • arduino_tools: Defines types/functions/macros that extend the Arduino base tools.
  • arduino_timers: Defines tools/abstractions to simplify control of Arduino timers. Needs to be extended to support different chipsets.
  • ir_messaging: Provides consumer IR (remote-control) communication for Arduino platforms.

Class Hierarchy

The following lists a few key classes:

  • IRCtrl::IRMsg class: High-level description of a consumer IR (remote-control) message.
  • IRCtrl::TxHw virtual class: Implementations allocate timers, I/O pins, & control low-level IR transmit.
  • IRCtrl::RxHw virtual class: Implementations allocate timers, I/O pins, & control low-level IR receive.
  • IRCtrl::PktInfo class: Describes low-level signalling of consumer IR packets.
  • IRCtrl::IRProtocol::pktInfo[]: Details how each consumer IR protocol transmits/receives IR messages.

And some low-level classes that might be useful for supporting more hardware:

  • ArduinoHW::Timer16b::Timer class: Facilitates the control of 16-bit timers (hopefully works for most arduino platforms).

Compiling

The ir_messaging library was tested on the version 1.0.5+dfsg2-2 (Linux) of the Arduino IDE.

Known Limitations

  • IR receiver currently only works using a 16-bit timer (IRCtrl::Timer16b::RxHw).
  • IR transmitter currently supports two resource allocations:
    • System clock (Timer0) + an 8-bit timer (IRCtrl::Timer8b::TxHw),
    • or two 16-bit timers (IRCtrl::Timer16b::TxHw).
  • ...

Resources/Acknowledgments

Ken Shirriff (et al.)

Ken Shirriff's IRremote library provides an interesting solution to consumer IR (remote-control) communication. Ken's library is very inspiring:

A few more interesting blogs from Ken's site:

SB-Projects

The SB-Projects website contains useful information on selected consumer IR (remote-control) protocols:

Datasheets

The following lists a few datasheets might be of use.

Disclaimer

This software is provided "as is", with no guarantee of correctness. Use at own risk.

About

Communication with consumer IR "remote" signals

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published