README.md

   1 # Device drivers for IR (infra red) remote controls
   2
   3 This repo provides a driver to receive from IR (infra red) remote controls and
   4 a driver for IR "blaster" apps. The device drivers are nonblocking. They do not
   5 require `uasyncio` but are compatible with it, and are designed for standard
   6 firmware builds.
   7
   8 The receiver is cross platform and has been tested on Pyboard, ESP8266, ESP32
   9 and Raspberry Pi Pico.
  10
  11 In a typical use case the receiver is employed at the REPL to sniff the address
  12 and data values associated with buttons on a remote control. The transmitter is
  13 then used in an application to send those codes, emulating the remote control.
  14
  15 Other use cases involve running the receiver in an application. This enables an
  16 IR remote to control a device such as a robot.
  17
  18 ## Raspberry Pi Pico note
  19
  20 Early firmware has [this issue](https://github.com/micropython/micropython/issues/6866)
  21 affecting USB communication with some PC's. It particularly affects code which
  22 issues `print()` only occasionally: the application appears to have failed. The
  23 missing messages appear when you press a key. Hopefully this will be fixed soon
  24 (note dated 8th March 2021).
  25
  26 #### [Receiver docs](./RECEIVER.md)
  27
  28 The transmitter driver is compatible with Pyboard (1.x and D series) and ESP32.
  29 ESP8266 is unsupported; it seems incapable of generating the required signals.
  30
  31 #### [Transmitter docs](./TRANSMITTER.md)
  32
  33 # 1. IR communication
  34
  35 IR communication uses a carrier frequency to pulse the IR source. Modulation
  36 takes the form of OOK (on-off keying). There are multiple protocols and at
  37 least three options for carrier frequency: 36, 38 and 40KHz.
  38
  39 In the case of the transmitter the carrier frequency is a runtime parameter:
  40 any value may be specified. The receiver uses a hardware demodulator which
  41 should be purchased for the correct frequency. The receiver device driver sees
  42 the demodulated signal and is hence carrier frequency agnostic.
  43
  44 Remotes transmit an address and a data byte, plus in some cases an extra value.
  45 The address denotes the physical device being controlled. The data defines the
  46 button on the remote. Provision usually exists for differentiating between a
  47 button repeatedly pressed and one which is held down; the mechanism is protocol
  48 dependent.
  49
  50 # 2. Supported protocols
  51
  52 The drivers support NEC and Sony protocols plus two Philips protocols, namely
  53 RC-5 and RC-6 mode 0. There is also support for the OrtekMCE protocol used on
  54 VRC-1100 remotes. These originally supported Microsoft Media Center but can be
  55 used to control Kodi and (with a suitable receiver) to emulate a PC keyboard.
  56
  57 Examining waveforms from various remote controls it is evident that numerous
  58 protocols exist. Some are doubtless proprietary and undocumented. The supported
  59 protocols are those for which I managed to locate documentation. My preference
  60 is for the NEC version. It has conservative timing and good provision for error
  61 detection. RC-5 has limited error detection, and RC-6 mode 0 has rather fast
  62 timing.
  63
  64 A remote using the NEC protocol is [this one](https://www.adafruit.com/products/389).
  65
  66 # 3. Hardware Requirements
  67
  68 These are discussed in detail in the relevant docs; the following provides an
  69 overview.
  70
  71 The receiver is cross-platform. It requires an IR receiver chip to demodulate
  72 the carrier. The chip must be selected for the frequency in use by the remote.
  73 For 38KHz devices a receiver chip such as the Vishay TSOP4838 or the
  74 [adafruit one](https://www.adafruit.com/products/157) is required. This
  75 demodulates the 38KHz IR pulses and passes the demodulated pulse train to the
  76 microcontroller.
  77
  78 In my testing a 38KHz demodulator worked with 36KHz and 40KHz remotes, but this
  79 is obviously neither guaranteed nor optimal.
  80
  81 The transmitter requires a Pyboard 1.x (not Lite), a Pyboard D or an ESP32.
  82 Output is via an IR LED which will need a transistor to provide sufficient
  83 current. The ESP32 requires an extra transistor to work as a transmitter.
  84
  85 ## 3.1 Carrier frequencies
  86
  87 These are as follows. The Samsung and Panasonic remotes appear to use
  88 proprietary protocols and are not supported by these drivers.
  89
  90 | Protocol  | F KHz | How found     | Support |
  91 |:---------:|:-----:|:-------------:|:-------:|
  92 | NEC       | 38    | Measured      | Y       |
  93 | RC-5 RC-6 | 36    | Spec/measured | Y       |
  94 | Sony      | 40    | Spec/measured | Y       |
  95 | MCE       | 38    | Measured      | Y       |
  96 | Samsung   | 38    | Measured      | N       |
  97 | Panasonic | 36.3  | Measured      | N       |
  98
  99 # 4. References
 100
 101 Sources of information about IR protocols. The `sbprojects.net` site is an
 102 excellent resource.
 103 [General information about IR](https://www.sbprojects.net/knowledge/ir/)
 104
 105 The NEC protocol:
 106 [altium](http://techdocs.altium.com/display/FPGA/NEC+Infrared+Transmission+Protocol)
 107 [circuitvalley](http://www.circuitvalley.com/2013/09/nec-protocol-ir-infrared-remote-control.html)
 108 [sbprojects.net](https://www.sbprojects.net/knowledge/ir/nec.php)
 109
 110 Philips protocols:
 111 [RC5 Wikipedia](https://en.wikipedia.org/wiki/RC-5)
 112 [RC5 sbprojects.net](https://www.sbprojects.net/knowledge/ir/rc5.php)
 113 [RC6 sbprojects.net](https://www.sbprojects.net/knowledge/ir/rc6.php)
 114
 115 Sony protocol:
 116 [SIRC sbprojects.net](https://www.sbprojects.net/knowledge/ir/sirc.php)
 117
 118 MCE protocol:
 119 [OrtekMCE](http://www.hifi-remote.com/johnsfine/DecodeIR.html#OrtekMCE)
 120
 121 IR decoders (C sourcecode):
 122 [in the Linux kernel](https://github.com/torvalds/linux/tree/master/drivers/media/rc)