Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
Bookmark this on Delicious
Recommend to StumbleUpon
Where's the remote control for the TV? If you can find it, wouldn't it be cool if it could be used to send commands to your Arduino? Read on....
You buy a TSOP1838 unit... I got mine from nuelectronics.com for about $3, plus modest p&p, 7/10. It needs three connections: 5v, gnd and a digital input. As I had a nuelectronics datalogging shield, I simply plugged it in to one of the shield's connectors. If you don't have the shield, plugging in will still be no hassle unless you are very new to Arduinos. Even then, if you can't do it easily, you need to learn those skills! (You can take the 5v from the Arduino.)
ARGH!!! Complications on complications!
Here's as much as I can get to the bottom of this morning...
Once Upon A Time, things just worked.
Then various people changed things, and there were unintended consequences.
Just now, 15 Mar 15, I got the following "working" again. I'm using Arduino 1.0.6 on a Windows 7 PC, and define "working" only as far as "will compile". (I haven't dug out the hardware to test that it really works. I'd be grateful to anyone who can do that who would write and tell me.
I downloaded and installed the current "best" "IRremote" library from Shirriff... version 1.0, according to "Readme.md", which can be opened by an ordinary text editor, who knows why he didn't call it Readme.txt. Bah.
When I tried to compile my code, there was an error involving 'TKD2'.
A bit of digging leads to....
... but you don't have to read that, if you want to take my word for the following.
If you "break" something else, you "fix" IRremote. My code compiles without errors. The examples I've tried, from those supplied with IRremote, compile. (Which they didn't... TKD2 errors... before the following...)
(Shut down any open Ardiuno sessions you may have open at this point.)
In your Arduino Libraries folder, I think you will find one called RobotIRremote. Rename it. I simply stuck my initials, "TKB", onto the end of it, as they don't seem to crop up from outside sources on my computer. (If I were named Michael Smith, I might have to use a different approach.)
By doing that, you "break" the RobotIRremote library, to a degree, but in a easy spotted way. Happily, in my case, I don't think I am using this library. If the day comes that I want to, I can "undo" my breaking easily, and as the "damaged" RobotIRremote library is still more or less where it was before, I might even be able to find the bit I broke. Sigh.
So. Imperfect. Unsatisfactory. But should, up to a point, "work". And maybe, in due course, the problems caused by others will be resolved, and we can move forward to a world where we can use BOTH IRremote and RobotIRremote... withouth all this hassle.
*** * * * ...End of Stop Press
You install the IRremote library into your Arduino development system. That comes from Ken Shirriff's blog, "arcfn" link below , and I've done a tutorial on software libraries if you don't already know about them. (If you do know about libraries, skip my tutorial. Ken's library is "well behaved", no special "features" (hassles).)
For IRremote from Ken Shirriff: http://www.arcfn.com/2009/08/multi-protocol-infrared-remote-library.html
aka...
After the library is installed, you enter the following into your Arduino...
/*
* IRremote: IRrecvDemo - demonstrates receiving
* IR codes with IRrecv
* An IR detector/demodulator must be connected
* to the input RECV_PIN.
* Version 0.1 July, 2009
* Copyright 2009 Ken Shirriff
* http://arcfn.com
*/
#include <IRremote.h>
int RECV_PIN = 14;//SEE NOTE in Sheepdogguides text
//Must be set to the Arduino pin your sensor is on.
//http://sheepdogguides.com/arduino/ar3ne1ir.htm
IRrecv irrecv(RECV_PIN);
decode_results results;
void setup()
{
Serial.begin(9600);
irrecv.enableIRIn(); // Start the receiver
}
void loop() {
if (irrecv.decode(&results)) {
Serial.println(results.value, HEX);
irrecv.resume(); // Receive the next value
}
}
(Confession: That code hasn't been DIRECTLY tested... it is a copy from where I got the code I DID test... let me know if you have any problems... after you've dealt with the RECV_PIN= line)
You may need to change the number in....
int RECV_PIN = 14;
The "right" number depends on where you plugged your sensor into your Arduino. If you are using the nuelectronics shield, 14 is right for P4. (See Naming of Parts if you don't know which connector is P4. It is marked... in tiny writing... on the shield.) Never heard of a digital line with such a high number? It is just another name for the analog I/O line "0". You can use one of the "ordinary" digital I/O lines if you are more comfortable with that.
Run the program. Once it has uploaded to your Arduino, run the serial monitor. Point a remote control at the sensor, being careful that whatever it normally controls can't "see" it, if you want to stay sane, and press a button. You should see some characters appear on the serial monitor!
That little program, by the way, uses 6150 bytes of memory, because of the things pulled in by the #include. I added a tiny bit of code which would cause the altered program to do what it did before and send signals out with an IR LED, and the program size only grew to 6726 bytes. While elements of the "receive IR signals" and the "send IR signals" code will be shared, you do seem to be "paying for" the "send IR" code, even when you aren't using it. Small price, for this elegant library. Do not underestimate the work that you are being saved. Different companies use different ways of encoding their data, for one thing.
I've successfully used the system above with....
If I press the "1" on my Sony radio remote, I get "26" from the system above. If I press "2" on the same controller, I get "4026"
In the first instance, a single byte has been sent. In the second, a two byte message was sent.
When I use a different controller, I get different... but consistent... results.
I wouldn't encourage you to try to see the method (if any) in the madness of the encoding systems used. I would simply use matching to "see" commands of interest. Here's how you do that...
First run the simple demo above to find out what your remote sends. For a simple demo of responding to a specific code, you can add the following two lines just after the " Serial.println(results.value, HEX); " line....
if (results.value==0x26){Serial.println("Sony Radio 1");};
if (results.value==0x4026){Serial.println("Sony Radio 2");};
(Again... I haven't tested that... copied it, by hand(!), from the screen of an adjacent computer. Apologies for any typos... PLEASE WRITE ME with any corrections!) (In fact an "it worked" email would be welcome, or a StumbleUpon vote? (See link at top of page.))
N.B. Unless you are also using a controller that emits "26" and "4026" when you press the "1" and "2" buttons, you will need to change the code you are trying to match.
The code will always have a "0x" (that's "zero ex") in front of it to say that it is expressed in hex. As hex, the codes can contain the letters A-F as well as the digits 0-9, by the way.
Bad news? It could be that the library is "messing with" the timers and/ or interrupts in your Arduino... but that may be NECESSARY for any decent IR reader. I haven't studied Ken Shirriff's page carefully... I bet he explains any such "messing" there. It isn't likely to be a problem for people getting started with using IR controllers as "keyboards" for Arduinos... but it is a possible cloud on the horizon for advanced users. But, as I said, probably a necessary "cloud"... and one that you will be able to manage, if you are advanced enough to be doing things to the default timer and interrupt settings.
Good news! While the focus of this page is reading signals from IR controllers, as I sort of mentioned a while back, the library has other capabilities. In particular, it makes it easy for you to send the codes sent by IR controllers. You only need an IR LED (and the current limiting resistor used with all LEDs)
I have in mind to build a "challenge/ response" access controller using two Arduinos, and Ken's library gives me what I need. In simplified essence: An Arduino inside my house, by a window by the front door will look for a burst of IR from a portable "key" Arduino with an IR transmitter (and receiver). The inside Arduino will then send a random number to the outside Arduino. The outside Arduino will then double the number it was sent, and send that back. If the inside Arduino sees that doubled number coming back, it opens the door. (Obviously(?) the rules of what will be sent, and what will constitute a correct reply will be more arcane.)
By all means work that up yourself if you have time before I do. If I inspired or helped you (the idea isn't ground-breaking!) I'd welcome a link to my pages from your pages... and I'd be pleased to hear of your project's completion!
I remember "broken light beam" burglar, etc, detectors from "the days of my youth" (don't ask... before integrated circuits for hobbyists, anyway, although transistors had made it out of the research labs!)... so why use an Arduino for something so pedestrian?
That little TSOP1838 unit is far more clever than you may have realized. It doesn't just look for some IR light. It looks for IR light "blinking" at a specific frequency... a very high frequency.
If you constantly "wink" an IR LED at the right frequency, and have it shine on a TSOP1838, then the (digital... i.e. robust) output of the TSOP1838 will change if the light from the LED is blocked.
Same idea as the "break the beam" sensors of my youth, but a more reliable system in which the detector is harder to confuse with stray other sources of infra red light... including things like the muffler of a car. Ken has more on this in a page on his site.
Which brings me to another Arduino project for you: A clever camera trap.
Basic idea: When light beam is broken, picture is taken.
Clever bit: Use TWO light beams, making an "X" in a horizontal plane. Take picture ONLY when BOTH beams are broken. Now you get the picture of the passing BigFoot when it is in an optimal spot, and your camera isn't tripped when the subject is at inconvenient spots along a single beam. (Not my idea, and, sorry, I forget where I saw it first.)
Of course, while not so much fun, not so "clever", a simple Sharp reflective proximity detector might be just as effective, and a lot less fussy to set up. "Break the beam" detectors are better than the Sharp for monitoring many points on a long line... more or less the opposite of what you want in the "camera trap" trigger sensor. Sigh. If you decide to play with camera traps, remember you will have to over-ride your camera's sleep- and- save- the- battery function.
So? What are you waiting for? If you have read this far, you obviously liked the page. While I'd really like it if you tried my Windows freeware and sent feedback, I know you're not likely to do that, but could you at least click the "StumbleUpon" button at the top of the page??? And maybe work up a project using the IR sensor/ LED information here, one of "my" projects, even, and post a "how to" for others? (With a link back to my page??) The Arduino playground makes publishing easy! And the Arduino forum is worth supporting too... please, though: search for old posts before asking, for instance, how to control a motor?
-------------------
Further to the Arduino ideas the page you are reading now will take you to, I have posted a series of essays which try to help you become a better Arduino programmer and engineer... but, for the best result, you will have to buckle down and work your way through them in sequence. The "How To's" here can be accessed in whatever order you like.
Feel free to use this information in programming courses, etc, but a credit of the source would be appreciated. If you simply copy the pages to other web pages you will do your readers a disservice: Your copies won't stay current. Far better to link to these pages, and then your readers see up-to-date versions. For those who care- thank you- I have posted a page with more information on what copyright waivers I extend, and suggestions for those who wish to put this material on CDs, etc.
See the discussion near the bottom of the "top level" page covering the bulk of my Arduino contributions. There is information there, too, about things like "May I copy your material?", and the system of file names I am trying to work to.
If you visit 1&1's site from here, it helps me. They host my website, and I wouldn't put this link up for them if I wasn't happy with their service... although I was less than pleased the other day to have what I was doing interrupted by a telephone call from their sales team, trying to get me to extend my involvement. Sigh. Hardly a rare event, but I'd thought 1&1 were a bit classier that some of the people who have my telephone number.
Click here to visit editor's Sheepdog Software (tm) freeware, shareware pages.
Click here to visit the homepage of my biggest site.
Click here to visit the homepage of Sheepdogsoftware.co.uk. Apologies if the "?Frmar3ne1ir" I added to that link causes your browser problems. Please let me know, if so?
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
....... P a g e . . . E n d s .....