• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register

Interfacing with IR remote controls
For a long time already I own a Marmitek Powermid Wireless Remote Control Extender. It is a set consisting of a transmitter and receiver. The transmitter receives InfraRed (IR) signals from remote controls, and transmit these signals on 433 MHz to the receiver where they are demodulated and emitted using IR diodes. Marmitek still makes these products, for example the Powermid XL.

The connection with the pilight system is of course the 433MHz link. My idea was: can I use the pilight system to transmit remote control signals to the Marmitek receiver, and as a consequence extent the pilight system to IR remote controllers.

So I started to look with my receiver at the 433 MHz signal of the Marmitek transmitter. I saw pulse trains that could be interpreted as control messages. Some further research showed me that what I saw was a control message using the NEC protocol for IR controls. Moreover my remote control was listed in the Lirc repository, and the command codes found there were in agreement with my findings. So, now I could transmit these command codes from pilight to the Marmitek receiver. At least, that was what I thought.

But some preliminary experiments using the pilight raw protocol were a failure. I noticed that the receiver was receiving (leds blinking), but the to be controlled set-top box didn't react to any command. But pilight was transmitting the exact same signal that I received from the Marmitek transmitter (my scope confirmed this). So, what was wrong?

I already knew that IR controls modulate their commands onto a carrier in the 38 kHz range. But I assumed that the Marmitek transmitter would drop this carrier and only transmit the baseband signal. This was what I saw at the output of my receiver. But this proved completely wrong. The Marmitek transmitter modulates the complete IR signal, including the 38 kHz carrier, onto the 433 MHz carrier. The Marmitek receiver receives this 433MHz signal, demodulates it, and emit the pulsed 38 kHz signal. My own 433 MHz receiver simply did not have the bandwidth to show the 38 kHz carrier, and therefore only showed the baseband signal. Problem solved, or not?

It is now clear that in order to use pilight in IR controlled situations, somewhere the control sequence should be modulated onto that 38 kHz carrier. But where? IMHO it would not a good idea to switch the 433 MHz transmitter on and off with a 38 kHz frequency during the high levels (or marks) of the control signal. It is questionable whether the bandwidth of the transmitter is large enough, and if the stability will be good enough. One also could use the GPIO pins of the Raspberry to generate the 38 kHz modulated control signal and drive the IR diodes via an appropriate driver. But then the Raspberry Pi is “promoted” to an IR remote control, and therefore should stay in sight of the apparatus to be controlled. And this is not what I want.

What I really want is a pilight system where the IR remote controls are just some other devices that can be served by sending them a command string from my Raspberry Pi over the 433 MHz link. What I want in fact is a replacement for my Marmitek receiver, that will have its own 38 kHz generator. And this is fairly easy to do. We already have a 433MHz receiver. The only thing we have to do is build a 38 kHz generator that can be switched on/off by the output of the receiver. This can be done in several ways. One could choose for a digital controller solution (e.g. with the ATtiny), or even implement this into the pilight low-pass filter, which would be an elegant solution. But for now I choose an analog solution with an NE555 timer circuit. This is a well known solution and a lot of info can be found on the Internet. The NE555 has a low-active reset input, which is connected directly to the output of the receiver. And the output of the NE555 is able to source enough current to drive IR leds without the need for a separate driver IC. This results in a compact schematic with only a few components.

So, I have build a prototype of this 433MHz-IR transceiver. And I wrote a raw implementation of the NEC protocol for my Sagem IR remote control, controlling a set-top box. Now I am able to control this set-top box using pilight. It works flawless.

The next step is thinking about the GUI. Should it be part of the pilight GUI, or is a separate GUI or even an app better? After all, a remote control is a different thing than a switch or a dimmer. My relatively simple remote control already counts 32 keys, and therewith has 32 different commands. Of course, there are examples of remote controls implemented as web pages or apps. So, still a lot of things to do.

If anyone interested I can post the source of my sagem_raw implementation of the NEC protocol. The device code is hard coded in the source. You have to change this for any other remote control.
I really have no clue what the Marmitek is and does. Can we start there Smile
Sure. First of all Marmitek produces a lot more than only IR remote control extenders. But we talk about the extenders, an example of it is the Powermid XL (see the link). It consists of two identical looking devices, but they are far from identical. One device, the IR receiver, receives IR remote control commands, modulates it on a 433 MHz carrier and transmit the result to the IR transmitter. The IR transmitter receives this 433 MHz signal, demodulates it thereby recovering the original IR remote control command, and will then emit this command using its build in IR leds. So now you can use your IR remote in a different room than where your equipment is. The next picture from the Marmitek site makes it quite clear:
[Image: website_overig1_powermidxl.jpg&action=resize(800x800)]

The connection with pilight is of course the 433 MHz link. In the above picture one could replace the right side by an equivalent Raspberry Pi with pilight and a 433 MHz transmitter. But then the RC command should be modulated on an 38 kHz carrier by the Raspberry Pi. IMHO it would be better (and much cheaper) to also replace the left site of the picture with a standard 433 MHz receiver connected to a 38 kHz modulator/ transmitter. This is exactly what I have done.

(Btw, in my earlier posting I used the old Marmitek naming for the devices. The previous transmitter is now called the IR receiver, and the earlier receiver is now called the IR transmitter. This can lead to some confusion. I'm sorry about that.)
What would be cool is to implement:
- A replacement for the IR receiver. So the device can as you say modulate IR to 433Mhz and send it to the transmitter.
- A replacement for the IR transmitter. So the device can transform the modulated IR to normal IR.
- A replacement of both. Then we don't need 433Mhz at all but we can just use two raspberry pi's and pilight in adhoc mode to repeat the same code on two locations. However, we need to implement a IR hardware module for that so we can drive a e.g. TSOP4838 receiver and an IR transmittor.
(06-26-2014, 11:33 PM)curlymo Wrote: What would be cool is to implement:
- A replacement for the IR receiver. So the device can as you say modulate IR to 433Mhz and send it to the transmitter.
What I mean is that one wants to eliminate the remote control device. So there is no need for receiving IR signals. pilight can generate the necessary command codes, the same way it does for controlling the switches. But there is one problem: if you want to keep/use the Marmitek IR transmitter, then you need to generate the 38 kHz signal in the raspberry.
(06-26-2014, 11:33 PM)curlymo Wrote: - A replacement for the IR transmitter. So the device can transform the modulated IR to normal IR.
Yes, this one is crucial. But then you can generate the 38 kHz signal locally i.e. in the IR transmitter. Then pilight only need to send the commands (as found f.e. in the Lirc repository) without bothering about the 38 kHz carrier needed for the IR signal. In the next post I will give a few examples.
(06-26-2014, 11:33 PM)curlymo Wrote: - A replacement of both. Then we don't need 433Mhz at all but we can just use two raspberry pi's and pilight in adhoc mode to repeat the same code on two locations. However, we need to implement a IR hardware module for that so we can drive a e.g. TSOP4838 receiver and an IR transmittor.
Yes, in fact I replaced both. But I opt for keeping the 433 MHz link because otherwise you do need an extra raspberry, which is much more expensive than a 433 MHz receiver. Moreover the replacement for the IR transmitter can be very small. I only have a prototype now, but I've ordered some components and I plan to build a "production" version the next week. When ready I will publish some photos to show what I mean.

But anyway, if you want to eliminate the 433 MHz link, you don't need a second raspberry. You only need a driver to drive an IR led from the raspberry. And you do use your WiFi to talk to the raspberry. Btw although there are several IR receivers (I use the VS1838B) there are no IR transmitters. A simple IR led is used for that purpose.

It is all about architecture. What I like about the pilight solution is that you have one central (or distributed) control center in the form of a raspberry running pilight, that controls all your switches, dimmers and other equipment. At the moment you can drive your equipment directly using the GPIO pins (eg. the relay protocol) or with a 433MHz link, because switches do use this. In the (near) future, when the internet-of-things will become widely available and affordable, the 433 MHz will be replaced by WiFi. But then still there would be a place for a control center a la the raspberry pi with pilight.
Just my 2 cents.

What i did in fact is building my own IR transmitter, consisting of a standard 433 MHz receiver coupled to an NE555 circuit, used as 38 kHz modulator and IR led driver. Further I implemented a NEC protocol version for my Sagem remote control in pilight. One can find the control codes of this RC in the Lirc repository (link). But since in the NEC protocol the second command byte is the inverse of the first command byte, one only need to specify the first byte. The protocol implementation then calculates the second byte. Also the 16 bit device code (0xE17A for my Sagem) is hard coded in the implementation.
So, using pilight-send I'm now able to control my Sagem set-top box. For example, the onoff code according to the Lirc list is 0x48B7. Only the first byte 0x48 is relevant, which is 72 decimal.
Therefore, the command, entered in the SSH window of my tablet,:
pilight-send -p sagem_raw -c 72
will switch my set-top box on or off. Notice that it is important that the default repeat in the settings.json file should be set to 1. Otherwise the set-top box will be toggled between on and off.
When I want to select channel 1, I will enter:
pilight-send -p sagem_raw -c 128
or increment the program number:
pilight-send -p sagem_raw -c 164
Of course, this is not the most user friendly way. It was only meant to be a proof of concept. It shows that in this way I can reliably control my set-top box using the pilight system.

I am thinking about implementing a protocol version that uses a lookup table for the command codes. The index into this lookup table would then be the code given to pilight-send. That probably would lead tot a somewhat more user friendly system.

Possibly Related Threads...
Thread Author Replies Views Last Post
  11 Key RF Remote, LED controller Jeroenk 24 16,013 02-02-2018, 01:29 AM
Last Post: Silverhawk1986
  [Fully Supported] Remote Control Socket (RC101-U/RC201) Sean 18 14,991 01-04-2018, 06:18 AM
Last Post: ettman8
  Hafele TV-elevator remote wessel_k 1 1,256 09-06-2017, 09:57 PM
Last Post: wessel_k
  mumbi m-FS300 with AB440R Remote / no dips altavista 9 8,610 11-12-2016, 11:04 PM
Last Post: wo_rasp
  [SOLVED] Home Confort - Emulate TEL-010 or TEL-100 remote control xvolte 2 3,091 03-18-2016, 07:21 PM
Last Post: xvolte
  AC114 Remote / Projection Screen redeye86 2 4,574 02-23-2016, 08:54 PM
Last Post: redeye86
  Toom 1919384 Remote Control AlphaWhiskey 5 4,800 11-29-2015, 04:13 PM
Last Post: diman87
  Rolling Code remote control stecker 7 8,947 07-06-2015, 08:27 PM
Last Post: sensorback
  Beamish Remote Switch 4-A4E tyjtyj 30 19,708 06-27-2015, 09:18 AM
Last Post: curlymo

Forum Jump:

Browsing: 1 Guest(s)