Analysis of the protocols of the remote controls

When creating an HTPC, one of the questions is how to control the shell. I think you should not talk about the fact that traditional input devices - keyboard and mouse are not suitable for this task. It is much more convenient to control the HTPC as well as other consumer electronics - using the remote control. The most commonly used remote controls are from DVD players and similar equipment in conjunction with LIRC / WinLIRC, or Windows MCE-compatible consoles with USB receivers, which are full in Chinese online stores. Such remote controls emulate a usb-hid keyboard (and sometimes a mouse). These consoles have a significant drawback - if the motherboard and BIOS do not support power-up and wake-up from usb devices, then using such a remote control device can be controlled, turned off, but will not turn on. I decided to fight this shortcoming.



For my HTPC, I chose an Intel D2700MUD motherboard. As it turned out later - recklessly, since the integrated GMA 3650 video controller, based on PowerVR, is fully supported only in 32-bit Windows, and in Linux the support is very limited - hardware video decoding does not work. But I am satisfied with the work of HTPC running Windows 7 Home Basic. Also, this board does not know how to wake up by a signal from a USB keyboard.



I also had a remote control (Philips 2422 549 01930), which seemed appropriate to me. But WinLIRC worked with him extremely unstable. Apparently, some unusual protocol was used.





')

The first thought was to connect the IR receiver to the Arduino, take the power from the 5VSB bus of the HTPC power supply, and turn on the power (and turn off) by simulating the pin closure on the motherboard to which the power button is connected, and transmit the remaining commands via RS-232. But the Arduino is too expensive and takes up a lot of space in an already small building. So I decided to get by with a cheap ATMega8 microcontroller, in which you can stitch the Arduino bootloader and program it as Arduino NG.

Parsing protocol

For Arduino, there is a good library for working with infrared remote controls - IRRemote, but it does not work with Arduino NG - not enough memory. In addition, I could not get this library to understand my console, even on the Arduino UNO. As I wrote above, LIRC (and WinLIRC) did not work very well with this remote control - they often missed pressing buttons, sometimes they pressed the wrong key. The remote control itself was working properly - there were no problems with the “native” DVD player. The search for information about the protocol for this remote did not give anything, so I decided to deal with it myself.



For this I needed an oscilloscope, but I didn’t have it at hand, and there was no place to take it. But in the case of signals from the remote control, the line input of the sound card is quite suitable. I connected the TSOP 31236 infrared receiver to it.







Further, using any audio editor, you can record the input signal and analyze:







First comes the long parcel needed to set the level of automatic gain control in the receiver. Then follow pulses of different lengths. I wrote an intermediate sketch for Arduino, which determined the time between the pulse fronts in microseconds and output them to the terminal via RS232. The data I downloaded to Excel:







When I began to study the protocol, my main mistake was that I considered the duration of the pulses themselves, but ignored the duration of the intervals between them. After I began to count the intervals between the fronts, everything fell into place. As can be seen, most of the pulse intervals between the fronts have a duration in the range of 350-550 μs and 700-1000 μs. This means that the values ​​of the transmitted bits are denoted as “0” and “1”. The remote control protocol uses toggle bits. This means that with several successive clicks of the same key on the remote, one bit (sometimes several) will change in the code. In my case, the toggle bit has an unusual duration - 1200-1400 μs. In addition, the number of fronts in the "even" and "odd" premises is different. Later I came to the conclusion that the interval of 1200-1400 μs is the sum of two bits with the same level, but of different duration (400 + 800). In the code, I designated such a parcel as a sequence of two bits - “01”. Then the number of bits on the output has become constant.

Sketch for Arduino

Then I wrote a sketch that counted the time between changes in the input level and output the resulting number in uart. Using simple debugging, I achieved the stability of the definition of codes, added addition with a mask to ignore the toggle-bits (I had no functions in which it would be useful). Then I hardcoded the function so that when I received the code for the “Power” button, the microcontroller pressed one of the “digital” Arduino pins to the ground (12 in my case).

//      .          , //       ,       . byte a = 0; //     byte b = 0; //     byte bc = 0; //   const boolean dbg=false; //   =) boolean start=false; //     unsigned int usecs = 0; //  1 -    unsigned int usecs2 = 0; //  2 -     unsigned int plen = 0; //     unsigned int plen2 = 0; //     String bits; //       ,   unsigned int buffer; // . ,      void setup() { // Initialize the digital pin as an output. // Pin 13 has an LED connected on most Arduino boards pinMode(13, OUTPUT); // ,     . pinMode(12, OUTPUT); //   12        .. digitalWrite(13,HIGH); //  . digitalWrite(12,HIGH); //     ,      . pinMode(7, INPUT); //     - TSOP. Serial.begin(115200); Serial.println("READY"); usecs = micros(); //    usecs2 = micros(); } void loop() { a = digitalRead(7); //      if(a != b) { //  !  . start=true; //    . b = a; //    plen = micros() - usecs; //         usecs = micros(); //   usecs2 = micros(); if (plen<2000) { //        if (plen>200 && plen < 620) { //  bits += "0"; buffer = buffer << 1; buffer = buffer | 0; bc++; } if (plen>620 && plen < 1150) { //  bits += "1"; buffer = buffer << 1; buffer = buffer | 1; bc++; } if (plen>1150 && plen < 1600) { // - bits += "01"; buffer = buffer << 2; //     ! buffer = buffer | 1; bc++; bc++; } if(dbg==true){ Serial.print(plen); //    -    Serial.print(";"); } } } else { //           plen2 = micros() - usecs2; //    if(plen2 > 5000 ) { //    5 ,          usecs2 = micros(); //   2 if(start==true){ //       ,          . usecs = micros(); //   1 while(bc<40){ //  .  ,       ,    -   . bits += "0"; buffer = buffer << 1; bc++; } buffer = buffer & 1048575; //  magic-numbers    .    toggle-. Serial.println(buffer); //  ! if (dbg){ //    Serial.print("bits="); //        Serial.println(bc); //    } digitalWrite(13,LOW); //     , delay(100); //      digitalWrite(13,HIGH); //   . switch(buffer){ //      . case 8448: //  Power   . Serial.println("POWER"); //   POWER   .     EventGhost. digitalWrite(12,LOW); //        . delay(300); //  300 digitalWrite(12,HIGH); //   default: break; } buffer=0; //   bits=""; //      start=false; //    bc=0; //    } } } } 

What's next?

And then the EventGhost application reads the codes from the RS-232 port and “pulls the strings” for the well-known XBMC shell. Setting up both is individual and at the same time simple, and therefore not worthy of attention.

Result

The device has been working for several months. It is mainly my father, who is far from technology, who uses it, so the minimum required number of buttons on the remote control is quite a convenient circumstance. The power turns on and off, there are no false positives.