Ir remote with Pic16series microcontroller {Need help}
Moderator: Moderators
Ir remote with Pic16series microcontroller {Need help}
Hi!
i want to make a infrared remote, what shut downs and power up (go to standby/sleep and wake up, like TV;VCR etc..) all devices that are in its way. I'm using PIC16 series Microchip.
Does somebody know microcircuit and code for that?
i want to make a infrared remote, what shut downs and power up (go to standby/sleep and wake up, like TV;VCR etc..) all devices that are in its way. I'm using PIC16 series Microchip.
Does somebody know microcircuit and code for that?
Last edited by kingshark on Mon Nov 28, 2005 8:48 am, edited 1 time in total.
I moved this thread to the correct forum (hopefully I did so correctly, since I haven't tried many moderator tasks before).
If you want useful help, you need to give a clearer description of what you're trying to do.
My guess is that you want a device that on one butten press sends out the power toggle commands for hundreds of different models of TV and VCR.
I know a device is sold for turning off TV's in public places. I've never seen one in action and I don't know how (or how well) it works. I can't think of a way to do that other than sending out a lot of different power toggle and discrete off commands. I doubt you could send more than four per second, on average (most are shorter than 1/4 second but enough are enough longer to wreck the average). My wild guess is that about 50 different commands would cover 50% of the TV's in public places in the US. But I think the next 45% of the TV's would take more than another 50 commands and the last 5% would be a lot harder.
If you want useful help, you need to give a clearer description of what you're trying to do.
My guess is that you want a device that on one butten press sends out the power toggle commands for hundreds of different models of TV and VCR.
I know a device is sold for turning off TV's in public places. I've never seen one in action and I don't know how (or how well) it works. I can't think of a way to do that other than sending out a lot of different power toggle and discrete off commands. I doubt you could send more than four per second, on average (most are shorter than 1/4 second but enough are enough longer to wreck the average). My wild guess is that about 50 different commands would cover 50% of the TV's in public places in the US. But I think the next 45% of the TV's would take more than another 50 commands and the last 5% would be a lot harder.
Only a few devices have discrete On/Off commands. Most devices just have power toggle commands. So if you had an On button and an Off button there wouldn't be much difference between what they would be able to send, and they would frequently do the opposite of what you intended.kingshark wrote:i'm in Europa. and yes, i want to make a device with one or two buttons, to turn on and off.
RC-5, the most common Philips protocol, is more common in Europe than in the USA. I expect more European TV's use the standard RC-5 TV power toggle command than any single power toggle command used in the US. So you get a better start toward your 50% in Europe than in the US.kingshark wrote: I think, even 50% of common devices are good...
doesn't in Europe and Asia have some more standarts like: Philips RC-5 Protocol???
But Philips has a bunch of other protocols (varients of RECS80 etc.) that are used inconsistently by a lot of different European brands. Plus many brands manufactured in Turkey are sold primarily in Europe with strange and unique IR signals. So I wouldn't guess you could get to 50% with fewer different signals in Europe than in the US.
For the actual project of making software to send a wide variety of different IR protocols, I suggest you find and read a few threads discussing IRP notation. A generic routine to translate from IRP notation to a time series would be a lot easier to write than a bunch of seperate protocol generation routines (one per protocol). Maybe you can ask for a copy of the Java source code for the new MakeLearned program. That is likely to be better sample code for translating from IRP to time series than the C++ source code for older IRP notation in MakeHex.
i found a website http://www.xs4all.nl/%7Esbp/knowledge/ir/ir.htm
There are some protocols, but different address for different device http://www.xs4all.nl/%7Esbp/knowledge/ir/rc5.htm
But how i can use them and all other protocols together? or is't to hard and complicated? And ai should focust example RC5 protocol
There are some protocols, but different address for different device http://www.xs4all.nl/%7Esbp/knowledge/ir/rc5.htm
But how i can use them and all other protocols together? or is't to hard and complicated? And ai should focust example RC5 protocol
That site has some nice pictures and introductory explanation, so it's worth reading if you lack basic concepts about how IR signals work. But its list of protocols is quite limited and it doesn't have any unified way of presenting even that limited list.kingshark wrote:i found a website :http://www.xs4all.nl/%7Esbp/knowledge/ir/ir.htm
The best set of IR protocol descriptions I know is the one I made myself, consisting of all the IRP format lines mixed into the DecodeIr documentation at
http://www.hifi-remote.com/johnsfine/DecodeIr.html
It's far from perfect. The IRP notation is presented without explanation (see other threads here) and is missing from several of the protocols (I'm fixing that as I find time). But meanwhile, I think it is already ahead of any other single source.
That's the point of IRP notation: A concise, unambiguous specification for an IR protocol in a format a program could understand.kingshark wrote: But how i can use them and all other protocols together?
I advise against that. Doing one protocol would be a lot easier than doing an IRP based general IR engine. But when you add the second protocol you won't have much in common with the first, so the effort will nearly double. Once you've done even the ten most common protocols you would find you've done far more work than doing a general IRP engine that covers almost all protocols.kingshark wrote:And ai should focust example RC5 protocol
-
underquark
- Expert
- Posts: 874
- Joined: Mon Jun 20, 2005 4:58 am
- Location: UK
-
The Robman
- Site Owner
- Posts: 21889
- Joined: Fri Aug 01, 2003 9:37 am
- Location: Chicago, IL
- Contact:
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
-
underquark
- Expert
- Posts: 874
- Joined: Mon Jun 20, 2005 4:58 am
- Location: UK
I thought my answers in this thread already were helping.kingshark wrote:I want to make a device like "The Robman" shows, on PIC microcontroller. can anyone help?
I find the project interesting, but I don't have time to do any significant chunk of the work for you.
If you have more specific questions, I probably can provide the answers.
If you have a semi-detailed design, I probably can warn you about whatever pitfalls it would lead to before you invest too much effort into any wrong design choice.
This idea is very interesting to me. When I did the IR to IR translator, with your help, I was "lucky" that both the received protocol and the transmitted protocol were NEC1.I advise against that. Doing one protocol would be a lot easier than doing an IRP based general IR engine. But when you add the second protocol you won't have much in common with the first, so the effort will nearly double. Once you've done even the ten most common protocols you would find you've done far more work than doing a general IRP engine that covers almost all protocols.
My next project, which is just in the ( half-baked ) planning stage, is to be able to control more of my home theater system with a picmicro. Due to an earlier project involving the ethernet, I can see the possibilty of selecting programs to be recorded in the future, via a web browser, and automatically setting up the equipment to do the actual recording. Other ideas include muting the audio when the phone rings, etc.
I am already able to control all of the units from my '6131 JP1 remote, so obviously your IRP notation will be a terrific help in my understanding each one, but I had not considered trying to unify or generalize the program. I was just going to slowly work thru each device that needs controlling and implement a specific subroutine to handle that device.
My equipment includes a Sony TV, a Sony audio system, a Panasonic "PVR", a Humax HDTV tuner, and an old VCR. I guess I need to sit down with my JP1 file and make a list of all of the protocols involved, and see if something jumps out at me, in the way of a general approach.
Thank you for your help in the past and your insights into IR programming.
-
classicsat
- Posts: 279
- Joined: Fri Feb 20, 2004 2:24 pm
