ESPIRP project.

Forum about hardware/software for the Philips Pronto TSU9600 and other remotes.
Post Reply
hvxl
Senior Member
Senior Member
Posts: 1699
Joined: Sat Jun 05, 2010 11:59 am
Contact:

ESPIRP project.

Post by hvxl »

After my OTGW project attracted a lot more interest than I ever expected, I decided to publish another device I made for my own use, which may also be useful for other people. It's an IR transmitter/receiver that interacts via MQTT, so it can be used by a home automation system for controlling equipment with an IR remote control.

The main difference with other IR transmitters currently available is the fact that new IR protocols can easily be added by providing their IRP specification. The IRP specification was created by John S. Fine. It provides a very compact way to exactly specify pretty much any IR signal ever invented.

While the device is built around commonly available components, it may be hard for an individual to have a circuit board made and obtain a front panel that allows IR signals to pass through. I have therefor once again found the Nodo shop willing to offer the device as a kit (Wemos D1 sold separately) that includes the PCB and enclosure.

Details can be found at https://espirp.tclcode.com/
Schelte
hvxl
Senior Member
Senior Member
Posts: 1699
Joined: Sat Jun 05, 2010 11:59 am
Contact:

Re: ESPIRP project.

Post by hvxl »

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.
Schelte
Post Reply

Return to “Philips Pronto (TSU9600), IRtrans and other remotes”