X-Git-Url: https://vault307.fbx.one/gitweb/micorpython_ir.git/blobdiff_plain/e53fbf4b049125934af6b4572a078301401dbed5..3bc46448ddca0bfdf3a98d96c3e9315159bf642b:/README.md?ds=inline diff --git a/README.md b/README.md index 2e31090..c107a78 100644 --- a/README.md +++ b/README.md @@ -4,10 +4,10 @@ This repo provides a driver to receive from IR (infra red) remote controls and a driver for IR "blaster" apps. The device drivers are nonblocking. They do not require `uasyncio` but are compatible with it. -NOTE: The receiver is intended to be cross-platform. In testing it has proved -problematic on ESP8266 and ESP32 with a tendency to crash and reboot, -especially when repeated pulse trains re received. The cause is under -investigation. +The transmitter driver is specific to the Pyboard. The receiver is cross +platform and has been tested on Pyboard, ESP8266 and ESP32. See +[Receiver platforms](./README.md#42-receiver-platforms) for test results and +limitations. # 1. IR communication @@ -18,7 +18,7 @@ least three options for carrier frequency, namely 36KHz, 38KHz and 40KHz. The drivers support NEC and Sony protocols and two Philips protocols, namely RC-5 and RC-6 mode 0. In the case of the transmitter the carrier frequency is a runtime parameter: any value may be specified. The receiver uses a hardware -demodulator which should be specified for the correct frequency. The receiver +demodulator which should be purchased for the correct frequency. The receiver device driver sees the demodulated signal and is hence carrier frequency agnostic. @@ -27,8 +27,7 @@ protocols exist. Some are doubtless proprietary and undocumented. The supported protocols are those for which I managed to locate documentation. My preference is for the NEC version. It has conservative timing and ample scope for error detection. RC-5 has limited error detection, and RC-6 mode 0 has rather fast -timing: I doubt that detection can be accomplished on targets slower than a -Pyboard. +timing. A remote using the NEC protocol is [this one](https://www.adafruit.com/products/389). @@ -49,7 +48,7 @@ microcontroller. The tested chip returns a 0 level on carrier detect, but the driver design ensures operation regardless of sense. In my testing a 38KHz demodulator worked with 36KHz and 40KHz remotes, but this -is obviously not guaranteed or optimal. +is obviously neither guaranteed nor optimal. The pin used to connect the decoder chip to the target is arbitrary. The test program assumes pin X3 on the Pyboard, pin 23 on ESP32 and pin 13 on ESP8266. @@ -77,10 +76,8 @@ Copy the following files to the target filesystem: There are no dependencies. The demo can be used to characterise IR remotes. It displays the codes returned -by each button. This can aid in the design of receiver applications. When the -demo runs, the REPL prompt reappears: this is because it sets up an ISR context -and returns. Press `ctrl-d` to cancel it. A real application would run code -after initialising reception so this behaviour would not occur. +by each button. This can aid in the design of receiver applications. The demo +prints "running" every 5 seconds and reports any data received from the remote. ## 3.2 Transmitter @@ -99,67 +96,71 @@ This implements a class for each supported protocol, namely `NEC_IR`, appropriate class with a callback. The callback will run whenever an IR pulse train is received. -Constructor: -`NEC_IR` args: `pin`, `callback`, `extended=True`, `*args` -`SONY_IR` args: `pin`, `callback`, `bits=20`, `*args` -`RC5_IR` and `RC6_M0`: args `pin`, `callback`, `*args` +#### Common to all classes -Args (all protocols): +Constructor: +Args: 1. `pin` is a `machine.Pin` instance configured as an input, connected to the IR decoder chip. - 2. `callback` is the user supplied callback (see below). - 4. `*args` Any further args will be passed to the callback. - -Protocol specific args: - 1. `extended` is an NEC specific boolean. Remotes using the NEC protocol can - send 8 or 16 bit addresses. If `True` 16 bit addresses are assumed - an 8 bit - address will be correctly received. Set `False` to enable extra error checking - for remotes that return an 8 bit address. - 2. `bits=20` Sony specific. The SIRC protocol comes in 3 variants: 12, 15 and - 20 bits. The default will handle bitstreams from all three types of remote. A - value matching your remote improves the timing and reduces the likelihood of - errors when handling repeats: in 20-bit mode SIRC timing when a button is held - down is tight. A worst-case 20-bit block takes 39ms nominal, yet the repeat - time is 45ms nominal. - The Sony remote tested issues both 12 bit and 15 bit streams. - -The callback takes the following args: - 1. `data` Integer value fom the remote. A negative value indicates an error - except for the value of -1 which signifies an NEC repeat code (see below). - 2. `addr` Address from the remote - 3. `ctrl` 0 in the case of NEC. Philips protocols toggle this bit on repeat - button presses. If the button is held down the bit is not toggled. The - transmitter demo implements this behaviour. - In the case of Sony the value will be 0 unless receiving a 20-bit stream, in - which case it will hold the extended value. + 2. `callback` is the user supplied callback. + 3. `*args` Any further args will be passed to the callback. + +The user callback takes the following args: + 1. `data` (`int`) Value from the remote. Normally in range 0-255. A value < 0 + signifies an NEC repeat code. + 2. `addr` (`int`) Address from the remote. + 3. `ctrl` (`int`) The meaning of this is protocol dependent: + NEC: 0 + Philips: this is toggled 1/0 on repeat button presses. If the button is held + down it is not toggled. The transmitter demo implements this behaviour. + Sony: 0 unless receiving a 20-bit stream, in which case it holds the extended + value. 4. Any args passed to the constructor. -Class variable: +Bound variable: 1. `verbose=False` If `True` emits debug output. +Method: + 1. `error_function` Arg: a function taking a single arg. If this is specified + it will be called if an error occurs. The value corresponds to the error code + (see below). + +#### Properties specific to a class + +`NEC_IR`: +`extended` `bool`. Remotes using the NEC protocol can send 8 or 16 bit +addresses. If `True` 16 bit addresses are assumed. If an 8 bit address is sent +it will be received as a 16 bit value comprising the address and (in bits 8-15) +its ones complement. Set `False` to enable error checking for remotes that +return an 8 bit address: the complement will be checked and the address will be +returned as an 8-bit value. The default is `True`. + +`SONY_IR`: +`bits` `int`. The SIRC protocol comes in 3 variants: 12, 15 and 20 bits. The +default will handle bitstreams from all three types of remote. A value matching +your remote improves the timing reducing the likelihood of errors when handling +repeats: in 20-bit mode SIRC timing when a button is held down is tight. A +worst-case 20-bit block takes 39ms nominal, yet the repeat time is 45ms nominal. +The Sony remote tested issues both 12 bit and 15 bit streams. The default is +20. + # 4.1 Errors IR reception is inevitably subject to errors, notably if the remote is operated near the limit of its range, if it is not pointed at the receiver or if its -batteries are low. So applications must check for, and usually ignore, errors. -These are flagged by data values < `REPEAT` (-1). +batteries are low. The user callback is not called when an error occurs. -On the ESP8266 there is a further source of errors. This results from the large -and variable interrupt latency of the device which can exceed the pulse -duration. This causes pulses to be missed. This tendency is slightly reduced by -running the chip at 160MHz. +On ESP8266 and ESP32 there is a further source of errors. This results from the +large and variable interrupt latency of the device which can exceed the pulse +duration. This causes pulses to be missed or their timing measured incorrectly. +On ESP8266 some improvment may be achieved by running the chip at 160MHz. In general applications should provide user feedback of correct reception. Users tend to press the key again if the expected action is absent. -Data values passed to the callback are zero or positive. Negative values -indicate a repeat code or an error. - -`REPEAT` A repeat code was received. - -Any data value < `REPEAT` denotes an error. In general applications do not -need to decode these, but they may be of use in debugging. For completeness -they are listed below. +In debugging a callback can be specified for reporting errors. The value passed +to the error function are represented by constants indicating the cause of the +error. These are as follows: `BADSTART` A short (<= 4ms) start pulse was received. May occur due to IR interference, e.g. from fluorescent lights. The TSOP4838 is prone to producing @@ -169,14 +170,31 @@ owing to high interrupt latency. `BADREP` A repeat block: an incorrect number of edges were received. `OVERRUN` A normal data block: too many edges received. `BADDATA` Data did not match check byte. -`BADADDR` Where `extended` is `False` the 8-bit address is checked +`BADADDR` (`NEC_IR`) If `extended` is `False` the 8-bit address is checked against the check byte. This code is returned on failure. # 4.2 Receiver platforms -The NEC protocol has been tested against Pyboard, ESP8266 and ESP32 targets. -The Philips protocols - especially RC-6 - have tighter timing constraints. I -have not yet tested these, but I anticipate problems. +Currently the ESP8266 suffers from [this issue](https://github.com/micropython/micropython/issues/5714). +Testing was therefore done without WiFi connectivity. + +Philips protocols (especially RC-6) have tight timing constraints with short +pulses whose length must be determined with reasonable accuracy. The Sony 20 +bit protocol also has a timing issue in that the worst case bit pattern takes +39ms nominal, yet the repeat time is 45ms nominal. These issues can lead to +errors particularly on slower targets. As discussed above, errors are to be +expected. It is up to the user to decide if the error rate is acceptable. + +Reception was tested using Pyboard D SF2W, ESP8266 and ESP32 with signals from +remote controls (where available) and from the tranmitter in this repo. Issues +are listed below. + +NEC: No issues. +Sony 12 and 15 bit: No issues. +Sony 20 bit: On ESP32 some errors occurred when repeats occurred. +Philips RC-5: On ESP32 with one remote control many errors occurred, but paired +with the transmitter in this repo it worked. +Philips RC-6: No issues. Only tested against the transmitter in this repo. # 4.3 Principle of operation @@ -191,7 +209,7 @@ The size of the array and the duration of the timer are protocol dependent and are set by the subclasses. The `.decode` method is provided in the subclass. CPU times used by `.decode` (not including the user callback) were measured on -a Pyboard D SF2W at stock frequency. They were NEC 1ms for normal data, 100μs +a Pyboard D SF2W at stock frequency. They were: NEC 1ms for normal data, 100μs for a repeat code. Philips codes: RC-5 900μs, RC-6 mode 0 5.5ms. # 5 Transmitter