• It works!

    Clayton G. Hobbs2 days ago 0 comments

    My STM32 "blue pill" boards arrived yesterday, and I started hacking away at some firmware.  I combined a couple different examples I found online and made the damned thing actually work.

    The IR receivers I had on hand all required 5 V, so I used two diodes to get a safe level for the microcontroller.  The electrical tape is just to make the power LED less obnoxious.  Soon I'll buy parts specifically for this project and build it in a more permanent way, and I won't need those diodes anymore.

    The last example linked above, the IR reading code, needed some work.  Mr. Guglielmi reverse-engineered the NEC protocol, apparently not bothering to find out exactly what protocol he was reverse-engineering.  As such, some of his timings were wrong, and his code needed a repeat signal to be sent before it sent an event telling the rest of the code that a button press had been seen.

    I fixed those problems last night, and the device works pretty well now.  You can check out the firmware from my Git repository, and the one C source code file says what pins are used.  I might release a more formal hardware design if anyone else is interested in making a device like this.

  • Remote Control Signal Reverse Engineering

    Clayton G. Hobbs5 days ago 0 comments

    The first step for this project was to figure out just what exactly the two remote control codes involved are.  To do this, I built an ugly version of the "silver bullet".

    With this new weapon at hand, I pointed a remote control at it and pressed the power button.  A pretty nice signal appeared, which I recorded on the scope and analyzed.

    After a bit of research, I determined that this is the NEC Infrared Transmission Protocol.  With this knowledge, I easily decoded the address 0x80 and data 0x18.  I'll have to listen for this signal, and transmit the other remote's power button code when it's received.

    Speaking of which, what exactly is the other remote's signal?  Using a similar technique, I found that it was using the RC5 Infrared Transmission Protocol.  The address is 0x00, and the data is 0x0C.  All the signals from this remote control seemed to be at about 106.6% of the normal speed for RC5, which interestingly made the carrier frequency 38 kHz instead of RC5's normal 36 kHz.  Whether this was intentional or not, I don't know.  Since this is the signal I'll be generating, I can try it both ways to see if the TV receives either one significantly more reliably.