Pages

Total Pageviews

Friday, December 16, 2016

This past semester, I worked on an independent study/project where I explored the programming of the PIC32. I've provided the details in the following PDF document. The key takeaway I believe is:

"This document presents sufficient
background information on the project, and implementation specific details. The
most important contribution this makes is adding the experiences and a full implementation
of the project. For even more detail and a thorough understanding, it is
recommended that this report be read along with the reference documents
mentioned in Section 4.1."

I plan on improving this, as well as exploring the option of programming other PICs this summer. A cursory look made me think that the PIC32 programming standard was more complicated than the PIC16's. I'll find out!

Saturday, February 6, 2016

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: http://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:

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: http://www.sbprojects.com/knowledge/ir/nec.php

Fig. 2: Standard NEC IR protocol pulse train

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:

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:

Key

Command

0

9

1

0

2

1

3

2

4

3

5

4

6

5

7

6

8

7

9

8

UP

18

DOWN

19

RIGHT

16

LEFT

17

PREVIOUS CHANNEL

13

-/--

10

POWER

20

MENU

21

MUTE

12

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.

Fig. 5: Schematic of IR remote design

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:

Fig. 6: Final IR remote, top

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!

Recent Posts

Translate this blog

Search This Blog

Follow by Email

About Me

I am Syed Tahmid Mahbub, from Dhaka, Bangladesh, born on August 1, 1994.
Electronics is my passion and from class V, I have been learning electronics. I learnt and worked mostly on SMPS, power electronics, microcontrollers and integration of microcontrollers with SMPS and power electronics. I've used PIC and AVR microcontrollers - PIC 10F, 12F, 16F, 18F, 24F, dsPIC 30F, 33F, PIC32, ATmega and ATtiny, integrating them with various SMPS and power electronics circuits.
I have completed my Bachelor's degree from Cornell University (Class of 2017) in Ithaca, New York, USA, majoring in Electrical and Computer Engineering (ECE).
I am a member of the forum www.edaboard.com, where I am an "Advanced Member Level 5" (the highest level attainable) and also the forum allaboutcircuits.com, where I am a "Senior Member". I post to help solve electronics-related problems of engineers and engineering students from all over the world.
I love watching and playing cricket and football (soccer), and listening to music.
I am now a hardware engineer at Apple in Silicon Valley, California, USA.