I am proud to announce the release of firmware 3.0 for the espirp. Users can update their devices by going to the status web page of their device, and clicking the "OTA upgrade" button. But before doing so, read the information below for a few incompatibilities with firmware version 2.x.
With firmware 3.0, the IR capabilities of the espirp are now completely driven by the installed IRP definitions. Transmitting IR signals was already based on IRP definitions. This is now also true for receiving IR signals. So the device is no longer limited to receiving only a fixed set of hard-coded IR signal families. This means that adding full support* for a new IR signal family is as simple as entering an IRP string on a built-in web page.
Receiving IR signals is now handled by decoders. Currently there are 8 decoders available. Each decoder can be configured to handle one IR protocol. It is expected that 8 decoders suffices for normal use. The reported signals can be narrowed down further by specifying a value for one or more variables of the IRP definition.
A change from firmware 2.x is that NEC1 and NEC2 signals are no longer reported as just NEC. Depending on which of the protocols has been assigned to one of the decoders, that protocol is reported. Since the first iteration of NEC1 and NEC2 signals are identical, a decoder configured for NEC1 will report a single iteration of a NEC2 signal. The reverse is also true. If it is important to distinguish the two protocols, a subsequent iteration must be checked (using receive full mode). A NEC1 decoder will only report subsequent iterations of a real NEC1 signal. The same is true for a NEC2 signal and a NEC2 decoder. Signals with so-called dittos (for example NEC1) are now reported (in receive full mode) with the full information, not simply with device 0, function 0.
When dealing with a unknown IR protocol, the espirp can be set to capture mode via the Interact web page. The pulse durations of received IR signals will then be reported. Clicking on a list of pulse durations will present a graphical representation of the signal. The signal is also compared against all installed IRP definitions. Any matches are listed.
Finally, some other improvements to the reception of IR signals have been made: Filtering of stray IR noise between repetitions of the signal has been added. This makes it less likely that a long button press will be reported as multiple presses. And the feedback provided by the red LED is more direct when receiving IR. The LED didn't use to light up until after a full iteration of the signal, plus a timeout. It now already lights up after a few pulses have been received that match the IRP definition of any one of the 8 decoders. The slight downside to this early indication of an IR signal is that it may turn out to be wrong in some circumstances. This does not normally turn out to be an issue.
For more information, see the
espirp web site.
* Receiving IR signals still has some limitations. First of all, only IR signals can be received that have a carrier frequency close to the nominal frequency of the installed IR receiver component. Additionally, it is possible to construct an IRP definition that is too complicated to use for decoding an IR signal. This happens mainly when the number of bits or the duration of a signal is specified using a variable or expression. This is very rare in normal IR signals. The only example in the IRP definitions included in the published firmware is the Zenith protocol. That allows the function value to be transmitted as 5 to 8 bits. The number of bits is represented as the device code. It is still possible to receive such signals by configuring the device code on the decoder.