Universal Remote Reciever

[PICMICRO]

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.

 

[Ian Rogers]

Have a word with Jason (atomsoft) he's made one...
He has posted it on the forum somewhere..

 

[sahu]

PIC RC5 Code code u can find here...

https://www.ccsinfo.com/forum/viewtopic.php?p=152585#152585

&&

**broken link removed**
hope help some u & also me

 

[sahu]

PIC RC5 Code code u can find here...

https://www.ccsinfo.com/forum/viewtopic.php?p=152585#152585

&&

**broken link removed**

&&

https://www.ccsinfo.com/forum/viewtopic.php?t=26226&postdays=0&postorder=asc&start=0
hope help some u & also me

 

[AtomSoft]

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

 

[OlPhart]

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 <<<)))

 

[PICMICRO]

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

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)

 

[AtomSoft]

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

 

[Nigel Goodwin]

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.

 

[PICMICRO]

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.

 

[3v0]

At least one protocol has a bit that it toggles after each command. A system that recorded times would have to account for this.

 

[AtomSoft]

Hey Nigel and to all. Some remotes have a custom protocol like: https://www.electro-tech-online.com/threads/decoding-ir-control.123976/
I have never seen a protocol like that before and its not in https://www.sbprojects.com/knowledge/ir/index.php

But i think manually decoding and learning it is better than wasting RAM/ROM for recording it.. Imagine if i had just tried to clone my remote by recording .. it would have taking up so much space

 

[hexreader]

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.

 

[Gayan Soyza]

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….

 

[PICMICRO]

Umm! I didn't actually built a universal remote receiver, but anyways, here is what I built