| |
A thought, a photo and a handful of curiosity
 
Title: Project Alpha - PC Remote Control (IR)
Start: 29/12/03
End: 03/03/04
Objective: Goal is to have a PIC (a fully functional microprocessor architecture on a chip) decode IR signals from a remote control and send the decoded signals to the PC probably using the serial interface (COM port). A program on the PC will receive the signal and make other progams act accordingly.
By Jason [- 04/04/04 (00:00:13) -]
So at this moment, I can easily control media player with my remote. It works pretty flawless, as long as the IR signal can reach it's goal, just as with your tv remote. One sweet thing is that I don't have to switch to media player to control it, which normally would cause some extensive swapping of my HD (not that much memory). Even when I'm playing old school doom (SkullTag windows version) I can control media player. Doing this without remote, I would have to switch to windows, which would take too much time and wreck my colours. Yet my remote control signal is processed in the background very efficiently :-)
I know, I got lotsa buttons unused and stuff is still on a testing-board with many unused wires hanging all over the place. And there are other programs to control, play-lists to select, fast-forward tp control, I could remote control relais so I could turn of lamps and stuff. But it worx, and I'm pretty proud on it, because, as you will know when you're read all this, it wasn't easy. In my life, it's not often that I stay persistent and finally succeed. And so I think I should close this project. Maybe make a new thread for more progress, or add something later on anywayz, but for now, I'm remote-controlling :-)
-= closed =- [popup]
By Jason [- 04/04/04 (00:00:12) -]
Getting back to the pc-part, I could strip the code and just wait for some bytes on the com-port. I had to init it and stuff so that cost me some web-surfing. It finally runs at 9600bps I believe, it could be faster I think, when I edit the IC code too, but why do that? It's just about sending a few bytes a second at max (when repeat codes come in). Maybe I want to do more later since the pic is not used at it's full potential now in many ways and I have more ideas like two-way communication and stuff. Anywayz, talking to media player was already working, but I needed some extra scan-codes. Which I finally managed to obtain using a program similar to Spy++. No in this code play, pause, next track, previous track, volume up and down is working. I could do more but I got lazy (and I was busy controlling media player from all over my room :). Source (don’t mind the names of the files) [popup]
Step 11 - Holding a key down
By Jason [- 04/04/04 (00:00:11) -]
When you hold a key on the remote, a repeat-signal is emitted. Detecting this is do-able, and usefull for fast-forward and volume-changes. The problem is that when the first burst does not come through (because someone is standing in front of you or whatever) and the repeat-code DOES, the pc just thinks the PREVIOUS code is repeated. Get it? So I set up a timer in the pic as soon as a code came in, for less than a second, but long enough to run only when the repeat wouldn't come. When it went off, some variable would be reset and no repeat signal would be transmitted to the pc. Nice :-) Assembler code at this point in the project you will find here (warning: it may be dirty and not well commented!).
[popup]
By Jason [- 04/04/04 (00:00:10) -]
Finally I could turn to coding (in MP-LAB, burning it to the chip with IC-PROG). First tried some simple led-blinx. Then I could hook up the IR-Receiver. After getting that to work I could start decoding the signal in assembler. However I am really fond of debugging and programming bit by bit, cause it is easier to find your mistakes.
So I decided first to get the serial connection running. The pc part could wait, I used some COM-port inspector for that. The pic-part wasn't easy, I read through the PDF and searched the www. Finally I realised that the PIC uses 0 and 5v and the pc expects -12 and +12. Yet because the PC is really easy going it accepts 0 and 5v as different signals too BUT you heve to invert the signal (cause -12 is digital '1'). Luckily I had a 7473N I used before which helds 4 inverters. I build all stuff on a test-board and because I had this IC already hooked up with coloured dreads it was easy to insert it between PIC and PC. And yes, it worked finally.
[popup]
By Jason [- 04/04/04 (00:00:09) -]
After more time-outs (other thinks like university demanded attention…again :-) I got some build circuit from a friend of mine to work with a external AC-adapter. It was actually a project he did for school, which included a in-circuit programmer. So my computer was OK. Then I started to do some deduction, using LVP, using a smallest part of the circuit as possible and finally had only a small 5V-generator and some resistors / diodes left. Before I went to the store to buy thes components I tried something on my own, reducing the circuit even more by using 5V from my gameport. And it worked and has worked ever since! The final circuitry consisted of only 2 resistors! And I'm not sure if they were actually necessary! It is really weird and probably violates the chip's specs (like voltage input and stuff) and also the COM-port specs (which actually runs on +12 and -12 signals and now gets input in 0v and 5v signals). But whatever, it WORX! And I can continue towards my goal! [popup]
By Jason [- 04/04/04 (00:00:08) -]
Yes well, *sigh*, I soldered some wires to a new rs232 9 pins SUB-D plug and we (a friend doing a similar project and I work together on the PIC-programmer) build the circuit on a breadbord, compiled some simple program with MPLAB and tried to burn it with IC-PROG but no luck. Turns out Remco (my friend) forgot to ground some parts. But still no luck after that problem was fixed. Actually, it is some weeks later and we tried different computers, different operatingsystem (win95, win98, winXP with and without different drivers), different tools (ic-prog, ponyprog, winpic, fpp) and different circuit-designs ( jdm-lookalike) (for serial and parallel connections). We also did extensive checking, tracing and volt-metering but the programming just wouldn't work.
Oh yes, that is so annoying, we must be doing something wrong but it could be so many things and ofcourse it is possible we made different mistakes during the many try-outs. You can't really see what's wrong, it's the same error all the time and it is frustrating. We read a lot of stuff on-line, traced message bords and other peoples problems (yes it seems to be able to work, these simple programmers but many others seem to have or have had problems with it).
Right now, I think I'll just buy a package from Voti and try a more sohisticated - yet more expensive - design…to be continued. [popup]
Step 7 - Talking to Media Player
By Jason [- 04/04/04 (00:00:07) -]
Some more hours where spent trying to find out how my application could talk to Windows Media Player. Like, sending it commands to play or stop and so on. Finally I found some important clues and instructions how to repeat the proces for other applications at The Code Project. Putting it all together, I could put Windows Media Player on play and pause using my remote (I just did again just now, I still can't get enough of this :). Source
[popup]
By Jason [- 04/04/04 (00:00:06) -]
 Now I had a stream of 0's and 1's coming in and I had to decode this further. There are many protocols remote controls talk in to their receivers. I had an old VCR remote laying around doing nothing and here I found out exactly what protocol the NEC chip inside it used. To get the signal right, I had the program wait for a '1' with a special API function called 'WaitCommEvent'. Then I took as many samples of the CTS status I could using 'GetCommModemStatus'. These where interpreted according to NEC's protocol. Yet, since the protocol uses pulse width modulation (PWM) and windows might switch processes during the sampling, some samples might appear short while they aren't. The solution for this problem was to let the process run at high priority (when no IR comes in, it's doing nothing so won't use any CPU time, when a signal comes in, it takes it all for a some milliseconds). Later on, the PIC will do the sampling and this problem will not be relevant anymore. To prevent the program to appear to 'hang' while waiting for the waitcommevent I placed this code into a separate thread. ScreenShot [popup]  
Step 5 - IR detection without PIC
By Jason [- 04/04/04 (00:00:05) -]
First I wanted to connect the receiver module directly to the computer with a simple schematics. Using Borland C++ Builder and the internet I finally found some code that could communicate with the COM-port (e.g. setting the RTS and reading the CTS). In de DOS days you could directly talk to the port's adresses, but in windows (actually the 386 protected mode it's running in) only system processes and device drivers are allowed to do this. Sadly enough, the program didn't respond to signals from the receiver, eventhough a led between ground and IR-receiver output would and the PC also responded to a direct '1' signal by applying 5 or 12 volts to the CTS line. Weird shit. It took me like a day to figure out how to get this stuff to work, but I finally got it to work by putting a inverter (actually a NEN-port with combined inputs) from the 74 chip series between the IR-receiver output and the CTS line. I still haven't figured out why the 7437 chip could handle the signal and the computer input could not. Maybe it has something to do with the CMOS values the computer wants (-12 and +12 volts) and the TTL outputs the IR-receiver should give (0 and +5 volts). But on the other hand, COM ports are said to be accepting TTL values also because they see everything above 1 volts as '1'. Anywayz, it worked :) [popup]
By Jason [- 04/04/04 (00:00:04) -]
I ordered needed parts at Conrad Electronics. These came in about a week later. So some patients was required and time spent on other stuff. Sadly enough, the circuitboards were left out :( [popup]
By Jason [- 04/04/04 (00:00:03) -]
Now, to receive the IR signal from the remote, I needed a receiver module. These things first filter all but infrared light out, make the signal stronger and tune in on a specific carrier frequency. With a small dos-program sampling really fast on a standard phototransistor I decided the remote I'm using has a carrier frequency of 38Khz. So I needed an IR-receiver module for that frequency. Vishay makes them and I decided to go for a TSOP1738 (I bought a TSOP1740 and TSOP1838 too just in case). These things are hardly supported anymore at Vishay's yet the 17xx and 18xx series were the only ones listed in the catalogue of the electronics supplier in Holland.
[popup]
Step 2 - Choosing a programmer
By Jason [- 04/04/04 (00:00:02) -]
These PIC series can be programmed in two ways. Like older PIC's they can be programmed by supplying them with +/- 13 volts. Yet the newer ones should also work with Low Voltage Programming (LVP), by supplying 5v to the PGM pin. So I took a design from here (Dutch site, choose Electronica and then "pic in-circuit programmer"). [popup]
By Jason [- 04/04/04 (00:00:01) -]
To achieve this, many things had to be done and learned. First, electronics - choosing a controller. I decided to use a MicroChip PIC and ordered 5 (free) samples from the PIC16F87x series (PIC16F870-I/SP, 2 x PIC16LF877A-I/P and 2 x PIC16F877A-I/P) based on experiences of a friend with these series. The F stands for flash, so programming and reprogramming would be relatively easy. [popup]
| |