X-Git-Url: https://vault307.fbx.one/gitweb/micorpython_ir.git/blobdiff_plain/a5c58e92f187b72111774f417d82238ec7e3b6eb..2ebf5db498266618fc0f037469309a6ea1906304:/RECEIVER.md?ds=sidebyside

diff --git a/RECEIVER.md b/RECEIVER.md
index ac20e18..cd84c4f 100644
--- a/RECEIVER.md
+++ b/RECEIVER.md
@@ -15,6 +15,10 @@ driver design ensures operation regardless of sense.
 In my testing a 38KHz demodulator worked with 36KHz and 40KHz remotes, but this
 is obviously neither guaranteed nor optimal.
 
+The TSOP4838 can run from 3.3V or 5V supplies. The former should be used on
+non-5V compliant hosts such as ESP32 and Raspberry Pi Pico and is fine on 5V
+compliant hosts too.
+
 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.
 On the WeMos D1 Mini the equivalent pin is D7.
@@ -55,7 +59,8 @@ test()
 This script waits for a single burst from the remote and prints the timing of
 the pulses followed by its best guess at the protocol. It correctly identifies
 supported protocols, but can wrongly identify unsupported protocols. The
-behaviour of the script exposed to an unknown protocol is unpredictable.
+report produced by the script exposed to an unknown protocol is unpredictable.
+The `test()` function returns a list of the mark and space periods (in μs).
 
 # 3. The driver
 
@@ -280,6 +285,12 @@ 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
 for a repeat code. Philips codes: RC-5 900μs, RC-6 mode 0 5.5ms.
 
+# 7. Unsupported protocols
+
+It is possible to capture an IR burst from a remote and to re-create it using
+the transmitter. This has limitations and is discussed in detail in
+[the transmitter doc](./TRANSMITTER.md#5-unsupported-protocols).
+
 # Appendix 1 NEC Protocol description
 
 A normal burst comprises exactly 68 edges, the exception being a repeat code