Universal Remote Reciever

Status
Not open for further replies.
P

PICMICRO

New Member
I am trying to build a remote controlled device (one that will activate a relay when you point your regular TV/VCD remote at it and press a button)
I want to activate relay 1 when I press button 1 and relay 2 when I press button 2 and so on.
I tried a little research and came across all those things about protocols.
Instead of trying to follow the protocols, is it possible to do this?
Activate a Learning mode. And when you press a button, the uC will record the times for Low and High of the pulses.
And in the normal modes, compare the received signal with the recorded signal. Allow for as much tolerances as required.
In short, will recording and comparing work?
Thanks.
 
Have a word with Jason (atomsoft) he's made one...
He has posted it on the forum somewhere..
 
I think recording and comparing will work. BUT... here is the catch.. you have to either setup a appropriate timeout time or know the protocol so you can know how long is a signal. Because if you try to just record the data you wont know when it ends since a remote sends HIGH and LOW pulses...

So something like:

TIMER2 = 20ms TIMEOUT
TIMER1 = 10uS time base

You have to start and reset the timer1 for each low and high point.

Make a 2 dimension array like:
HL[2][100];
char count = 0;
#define LOW 0
#define HIGH 1

This will allow you to keep track of HIGHs and LOWs easy...

The main code could be something like

LOOP UNTIL TIMER2 says we hit 20ms
{
reset timer1 and count HIGH portion
HL[LOW][count] = TIMER1 VALUE;
reset timer1 and count HIGH portion
HL[HIGH][count++] = TIMER1 VALUE
}

Well you can see what i mean. This isnt exactly what i would do but its how i would think then refine the final

Its easier to learn the protocol and make a receiver... also will require less RAM and ROM/EEPROM... since you will most likely use ROM or EEPROM to store saved codes..

BTW... Im Jason
 
Last edited:
timing edges

I've built DOS and Windows based universal IR controllers by demodulating the carrier and logging/learning the times between edges. Start by waiting for the 1st transition to active, count to next edge, log the count, repeat until the counter overflows.

For input only, the trick is picking the counter frequency.

I built one of these to control an AV switch deck I harvested out of an Onkyo AV receiver that was in a flood. The amplifier stages were fine, as was the I/O selection boards, but the front panel & microcontroller were rusted toast. The owner didn't know you Must pop all the panels and rinse, literally with clean water, the entire chassis. Good Hunting <<<)))
 

Thanks, Jason.
I checked a remote I had with a Logic Analyzer, and it used NEC protocol. So, there were some 35 high pulse and 35 low pulse to be recorded. Using Timer1 means, integer value for each pulse. that required around 70 integers = 140 bytes to record 1 button.
HTC compiler complained that it couldn't find enough memory for this variable
unsigned int store[141];
So, that was end of story. I didn't have enough memory to even record 1 button. (I saw that RC5 and sonys are shorter, but then, I want to record some 10s of buttons)
So, Recording looks just too memory hungry.
So, I abandoned this recording concept, and am now decoding NEC protocol. Finally done that successfully.
(Instead of trying to decode all protocols, I think I am better off using Universal Remotes and configuring them to use NEC protocol. I hope it works tthat way)
 
Yeah, I would have chosen sony just because its simpler and most universal remotes have the same for for it... 0000 or 0001 or 001 or 000 you get the picture heh.. no need to look at remote manual for it... But heh im lazy

Glad you got something up and running and while i dont have much experience with NEC im sure if you asked for help ill try to figure it out
What TV systems use NEC? so i can see it for myself? I get bored
 

I reverse engineered a Media Player remote a few months ago, in order to create a simple wired control with a few buttons for controlling it (actually for various uses in a local small theme park), I found out later it was NEC protocol. As well as being quite long, it also repeats differently after the initial code is sent.
 
The remote was from a TV card (which converts your monitor into TV). (Brand name: Gadmei) . Another Remote I had of a VCD player from china, also used the same protocol.
I hope the Universal remotes widely available can be configured to use this NEC protocol, otherwise I would have to write code for decoding another protocol too, because in the final project I would be using this Universal Remotes. And, like Jason, I'm lazy too.
 
At least one protocol has a bit that it toggles after each command. A system that recorded times would have to account for this.
 
I have messed with domestic IR remotes quite a bit.

Not sure if it helps, but if you have a PIC18F45K22 or PIC18F4620 (or 4520) then I have put some ready solutions here:

http://www.libstock.com/projects/view/43/infrared-tx-rx-easypic7-nec-sony-rc5-rc6-toshiba

Timing print is one of the receive options if you connect a terminal at 9600 8,n,1.

You will not be able to compile the receive code unless you have MikroC licence, but you can program the HEX file into your PIC.

Transmit version is probably small enough to fit trial MikroC compiler, but I have not checked.

NEC (or similar) protocol makes up a high proportion of my remote control collection.
It seems to be favourite for cheap domestic devices.

NEC seems to be compatible with other similar protocols, it is just the way that the 4 data bytes are used that varies a little.
 
Last edited:
I setup couple of techniques but never had a chance to do in real life.

Most remotes follow IR rules.So it must have at least 200uS burst time either high or low to identify at receivers end otherwise AGC in the receiver will reduce its gain & omit the incoming pulse.

basic method
*set up a timer which has a pre-scaller, ex 1:16.If timer = 20 then it will present a 320uS pulse time.

*Measure each mark & space times in the incoming stream & save them in an array or use indirect addressing to store timer values.

*But when to know the end pulse or end of the packet!!most protocols uses a bigger space time than any other mark/space timing in end of the packet before beginning the next packet.

*setup an offset factor to each stored registers & check comparing with the incoming pulse.

Ex: if the incoming high pulse is 1200uS just check the pulse is between 1000uS & 1400uS.

For what 3V0 has mentioned I’d bypass the first 3 or 4 pulses.start bit,toggle bit & some space times….
 
Last edited:
Umm! I didn't actually built a universal remote receiver, but anyways, here is what I built
 
Last edited by a moderator:
Status
Not open for further replies.

Similar threads

  • Question
Remote Control By Location Part 2--CONTROL SECTION
Replies
3
Views
3K
camerart
Remote Control By Location Part 2
2 3
Replies
45
Views
27K
camerart
V
IR Remote Control Fun
Replies
19
Views
6K
gophert
44-Key IR Remote NEC 'Command' Codes
Replies
0
Views
3K
Mike - K8LH
a remote control using a pic
2 3 4
Replies
69
Views
11K
MrDEB
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…