Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Creating my own TV Tuner IR remote with a PIC16F684

  • Author Tahmid
  • Create date
  • Updated
  • Blog entry read time 3 min read
attachment.php

While I was home this winter, I saw that the remote for our TV tuner was damaged physically, causing the buttons to not function responsively. Some of them just didn't work. I saw this as an opportunity for a fun couple days' project to build a new remote controller for the tuner.

The TV tuner was manufactured by a brand name RealView and, as expected, I couldn't find much detail about it. Thus, I had to reverse engineer the remote. From my previous experience in working with IR remotes, I had a hunch that the IR was most likely modulated at ~38kHz or ~56kHz. For those of you who don't know how this works, I highly recommend going through this website: https://www.sbprojects.com/knowledge/ir/

Thus, I connected a 38kHz IR receiver I had at home (TSOP1738) to an oscilloscope in order to figure out what IR protocol is used by the remote. Upon pressing the 4 key on the remote, I saw the following waveform:

attachment.php

Fig. 1: Oscilloscope waveform capture of the received IR signal​

Note that I inverted the signal on the oscilloscope since the IR receiver output is active-low.

I then compared the waveform to some of the common IR protocols, paying particular attention to the initial first high and low states. After going through SIRC, RC5, RC6 among others, I noticed that this matched the NEC protocol: https://www.sbprojects.com/knowledge/ir/nec.php

attachment.php

Fig. 2: Standard NEC IR protocol pulse train

attachment.php

Fig. 3: NEC IR protocol logic high and logic low signals​

Using the waveform shown above, I found that ~address was not being sent, meaning that the extended NEC protocol was being used:

attachment.php

Fig. 4: Extended NEC IR protocol pulse train​

From the waveform, I found that the address was 0xBD02. I then proceeded to make a simple decoder with a PIC16F877A since I had a development board with an IR sensor mounted on it. Using this, I found all the required commands for the different keys of the remote. I decided to exclude some of the keys that were never used (eg play, pause, stop, fast forward, rewind).
You can find this part of the project here:
https://drive.google.com/file/d/0B4SoPFPRNziHZjk2N3pNLVE5V1E/view?usp=sharing

This left me with the following keys and commands:

KeyCommand
09
10
21
32
43
54
65
76
87
98
UP18
DOWN19
RIGHT16
LEFT17
PREVIOUS CHANNEL13
-/--10
POWER20
MENU21
MUTE12


I then proceeded to write an IR transmitter using the PIC16F684 (using the MPLAB X IDE and XC8 compiler), following the timing information from the extended NEC protocol. In order to connect all the keys, I connected them in matrix keypad form.

In order to power the remote off 2xAA batteries, it is necessary to use sleep mode - otherwise the battery will be drained extremely quickly. So, in order to detect when a button is pressed, an interrupt is used. After the IR command is sent, the microcontroller goes to sleep. The interrupt wakes up the microcontroller when a button is pressed. Debouncing is achieved using simple software delays. When a button is held down, the NEC command repeat sequence is not sent. Instead, the remote relies on releasing the button and pressing it again.

To minimize leakage current through the input capacitor, I decided not to use an electrolytic capacitor. A red LED illuminates to confirm that a button has been pressed.

attachment.php

Fig. 5: Schematic of IR remote design​
For larger image: https://www.edaboard.com/attachment.php?attachmentid=125949&d=1454981510

Everything was put together, a PCB was designed and when tested with the TV tuner, everything worked as expected! I measured the sleep current with a portable DMM and it was read as 1.6μA! I'm not sure how accurate the DMM is at such low currents, so I wouldn't entirely trust this number - however, it does seem to be within spec for the PIC16F684.

Due to a lack of time, I had to put the remote together with electric tape! Here you can see pictures of the final design:

attachment.php

Fig. 6: Final IR remote, top

attachment.php

Fig. 7: Final IR remote, bottom​

I am back at college now, but I have been told that the same set of batteries are still working on the remote, and it is working perfectly fine!

You can find the MPLABX project, source code, schematic and pcb files all here:
https://drive.google.com/file/d/0B4SoPFPRNziHV2I1U1Bldm1OYUE/view?usp=sharing

Let me know what you think! If you have any questions, let me know in the comments section!

Comments

I have heard that there are 'universal' remotes that will work with many equipment- you have some idea about how they work? Why one remote does not work for another?
 
c_mitra;bt2565 said:
I have heard that there are 'universal' remotes that will work with many equipment- you have some idea about how they work? Why one remote does not work for another?
Because the standard infrared protocols use on remote do have device address setting and others. So check and combine all possible settings to creat a multifunction remote.
 
Hi Tahmid. have you try to use 3volt battery to power this chip before? To do that I'm sure the internal clock frequency should be reduce. Most remote uses low frequency clock to save power consumption. Please let me know your opinion on these.
 

Part and Inventory Search

Blog entry information

Author
Tahmid
Read time
3 min read
Views
1,636
Comments
3
Last update

More entries in Uncategorized

More entries from Tahmid

Share this entry

Back
Top