Need help building a simple IR learning remote with a PIC

[JackPollack]

Can someone please help me get started with this project:

I need a PIC to be able to learn 6 different IR codes and be able to output them depending on certain conditions. Basically a very small learning remote.

Thanks for any help.

[keithdoxey]

Just 6 IR codes eg 6 buttons or 6 IR code sets eg for 6 devices.

If just 6 buttons do you know in advance what type of IR codes

eg NEC type, Sony, RC5, RC6 These are the common ones and will cover many items but there are still a lot of codes that do not conform to any of the above.

Panasonic and JVC use codes that are similar to NEC but have subtle differences however the decoding is basically the same once you account for differnt headers and number of bytes in the codes.

A bit moe information on exactly what you are trying to achieve would make it easier to answer your question.

Regards

[JackPollack]

Thanks for your reply.

I just need to transmit about 6 different codes.

The codes are from a proprietary remote (to control a piece of medical equipment). Presently, I do have the codes learned in my Pronto learning remote.

I would like to store the codes in the PIC using the DATA statement and transmit any of the codes based on certain external conditions the PIC will detect.

These are my initial thoughts (please feel free to comment on them):

Figure out the carrier frequency
Figure out if the IR code is PWM or simple high & lows

(I think I can get the above from the Pronto editor, I am trying to find my notes on reading the IR data through the PC software ProntoEdit)

Store the data in the PIC eg (HEADER PULSE), 2H,3L ....

AND the output pulses with the original carrier frequency (either produced by an external oscillator, or possibly by the PIC itself (comments please))

The combined data and carrier would drive a transistor that would be connected to an IR LED.


Comments, ideas suggestions please.

Thanks

[dhouston]

If you can supply the codes in Pronto CCF format I can determine whether they use one of the standard protocols and can probably define them in 3-6 bytes (which will make it easier to store them in EEPROM) and suggest code for playback. All the needed details will be in the CCF codes.

[JackPollack]

I was up working on this all night, see what you think.


Assumptions based on ProntoEdit data:

The carrier is 40K

Header code: 4.12ms ON , 3.75ms OFF
Trailer code1: 11.25ms ON, 3.75ms OFF
Trailer code2: 11.25ms ON, 90ms OFF

Data 0 = 1.15ms ON, 6.35ms OFF
Data 1 = 3.55ms ON, 3.75ms OFF

Data Stream:
Header Code - IR data (eg off) 0010 - 0 spacer - Trailer Code1 -
Header Code - Inverse of IR data (eg 1100) - 1 spacer - Trailer Code2

I see that the PICs cant output a frequency greater then 32767Hz so I plan on ANDing a 555 output with the data stream. Haven't had a chance to test any of this yet. I am also not sure that my timing is accurate (ms ON, MS off).




This is the OFF string (from ProntoEdit)
0000 006b 000c 0000 00a5 0096 002e 00fe 002e 00fe 008e 0096 008e 0096 008e 0096 008e 0096 008e 0096 002e 00fe 002e 00fe 002e 00fe 01c2 0e10

This is the ON string:
0000 006b 000c 0000 00a5 0096 002e 00fe 002e 00fe 008e 0096 002e 00fe 008e 0096 008e 0096 008e 0096 002e 00fe 008e 0096 002e 00fe 01c2 0e10

[dhouston]

I was up working on this all night That's a shame. I can analyze any CCF code in a minute or two, including a graph of the code. A graph of the ON code is attached.

What PIC do you plan to use? It's easy to get higher frequencies using hardware PWM. I do it with a PIC12F683 but you'll probably want more pins. There's an example program on the Reynolds Electronics website. Here's some test code that generates ~120kHz.
DEFINE OSC 8
@ DEVICE PIC12F683, INTRC_OSC_NOCLKOUT
@ DEVICE PIC12F683, MCLR_OFF

TRISIO.2 = 0 'GPIO.2=Output
PR2 = 17 'PWM Period 117.7kHz
CCPR1L = 8 'PWM Duty-Cycle
'CCP1CON = %00001100 'PWM Mode
T2CON = %00000100 'Timer2=ON, 1:1 prescale
OSCCON = %01110001 'INT HF OSC 8MHz
WHILE OSCCON.3>0: WEND 'OSC startup timeout
WHILE OSCCON.2=0: WEND 'INT HF OSC stable
'CCP1CON = 0 'PWM module off
WHILE OSCCON.2>0
CCP1CON = %00001100 'PWM ON
PauseUS 1000 'generate 1ms burst
CCP1CON = 0 'PWM OFF
Low GPIO.2
Pause 10 'pause 10ms
WENDI get somewhat different values.Carrier=38740
Lead-in=4.259ms ON, 3.872ms OFF
1-bit=1.187ms ON, 6.557ms OFF
0-bit=3.665ms ON, 3.872ms OFF
Lead-out=11.616ms ON, 92.928ms OFF
If all codes use the same lead-in & lead-out, the binary codes are 1100 0001 11 and 1101 0001 01 for OFF & ON respectively.

[JackPollack]

Thanks to everyone for all their help so far.I was stupid enough to stay up all last night working on this project, and now I am so fried I can barley think!


I threw together a quick circuit & program, but it does not appear to be sending usable IR. At this point I could be missing something really basic and think I need to change gears for a few hours.

dhouston's sample code appears to be for an oscillator. How would I reduce this down to the Hz needed for my carrier? Is this program specific to the PIC12F683, or can I use it on a 12F629, 12F675 or 16F88 (chips I have available now)? Would this PIC just be used to generate the carrier, or could it also generate the complete IR stream including carrier & data pulses?

Thanks - know I will be back in the morning, against my better judgment :)

[dhouston]

dhouston's sample code appears to be for an oscillator. How would I reduce this down to the Hz needed for my carrier? Is this program specific to the PIC12F683, or can I use it on a 12F629, 12F675 or 16F88 (chips I have available now)? Would this PIC just be used to generate the carrier, or could it also generate the complete IR stream including carrier & data pulses?It can generate everything you need, turning the carrier on and off as my demo code does within the loop. It requires a PIC that has hardware PWM. I think the 16F88 is the only one in your inventory with that capability. Get some sleep. This is too simple a project to lose sleep over.

[Melanie]

Now I don't want to get involved in this thread... but I thought a 'Learning Remote' (see title of thread) is one where you point an existing Remote to your Learning Remote, it captures the Data Stream, and assigns it to one of your available Buttons. The Learning Remote doesn't need to know if it's a Sony, JVC or a Zenith, all it needs to do is faithfully capture the incomming data and replicate it on demand. If you go and pre-program your Data into your PIC at burn time, it's then not a 'Learning Remote' is it?

[keithdoxey]

Now I don't want to get involved in this thread.
Too late :D


If you go and pre-program your Data into your PIC at burn time, it's then not a 'Learning Remote' is it?
Good point. I guess I didnt read the original post well enough!!

[dhouston]

How would I reduce this down to the Hz needed for my carrier?That depends on the PIC and its oscillator rate. PR2 sets the period of the carrier and CCPR1L the duty cycle. Read Bruce's article for the details...http://www.rentron.com/Infrared_Communication.htmSince only one pin is needed to output the bursts of IR carrier, you could do this with the 12F683 - the 5 free pins can support 32 buttons. I assume you want this small and battery powered.

[Bruce]

I've done a few learning remotes. I can't give you all of it, but I can share a few little odds & ends you might find useful.

This simple routine allows you to output your carrier bursts on any pin that can be used as an output, and it's easy enough to modify for most any carrier frequency.

Note this assumes a 4MHz osc. Internal or external work equally well.



@ #define IRTX PORTC ; Define port to use for IR out
@ #define PIN 2 ; Define port pin to use for IR out

' Note: Be sure to make the above pin an output
TRISC.2 = 0
PORTC.2 = 0 ' LED off on boot

Cycles VAR BYTE ' Make sure this is always located in bank0

GOTO Main ' Jump over routine to main program entry point

Pulse: ' Generate "Cycles" number of 40kHz pulses
ASM
bsf IRTX,PIN ; 1uS, LED=on
goto $+1 ; + 2uS = 3uS
goto $+1 ; + 2uS = 5uS
goto $+1 ; + 2uS = 7uS
goto $+1 ; + 2uS = 9uS
goto $+1 ; + 2uS = 11uS
goto $+1 ; + 2uS = 13uS
bcf IRTX,PIN ; 1uS, LED=off
goto $+1 ; + 2uS = 3uS
goto $+1 ; + 2uS = 5uS
goto $+1 ; + 2uS = 7uS
goto $+1 ; + 2uS = 9uS
decfsz _Cycles,f ; + 1uS = 10S
goto _Pulse ; + 2uS = 12uS
return ; Return to caller
ENDASM
Using this is very easy. Load the number of carrier cycles into Cycles, then CALL Pulse.

If you need a carrier burst longer than 255, simply call Pulse again immediately after the 1st call. IR detectors are relatively slow in responding, so it's unlikely you'll see a break in the burst on the receiving end. I never have.

Can't share the larger routine with you, but this shows one simple approach to getting the IR output on any pin.

Making a learning remote isn't really all that hard, but it can be memory hungry depending on the width of carrier bursts, data packets, etc, the IR remote you're learning outputs.

Learning a single remote is much easier than a boat load of different brands.

TIP: Use PULSIN to read & store each logic 0 carrier burst width into an array. The first low pulse is normally a synch pulse, then data. Some remotes will include a long carrier burst period between each packet. That will vary from one mfg to another.

Run through a second PULSIN routine waiting for the logic 0 synch pulse, then start recording/storing the logic 1 periods.

These will be the periods where you PAUSEUS between loading Cycles & calling Pulse when recreating the outgoing data.

TIP #2: My first learning remote I made the user press a button until I had sorted all out logic 0 (carrier burst periods), then lit an LED telling the user to release the button. The same button was pressed once again, and it learned the logic 1 periods between carrier bursts by synching up with the initial logic 0 synch burst. Viola! Codes all learned & stored.

You end up with the whole data pattern, and it's pretty simple from there to re-create the same IR signal.

TIP #3: I eventually used a PIC where I could switch oscillator speeds on the fly, read in pulses at higher speeds for better resolution, then switched back down to the lower osc speed to send, and finally to the lowest speed and entered sleep for ultra low power use until a keypress. Worked really nifty.

Hope that helps. If you want a few more IR goodies contact me off-list. I can share a couple more routines with you if it's 100% for personal use.

[Luciano]

Hi,

See these links.

Best regards,

Luciano

===================================

IR Remote Control info:
http://www.xs4all.nl/~sbp/knowledge/ir/ir.htm

===================================
Hacking Remote Control Signals:

http://www.i-hacked.com/content/view/121/94/
(It is difficult to see the pictures on this page. Copy
the pictures and paste them in the Windows Paint).

Where to download the SW DigiTrace:
http://www.xs4all.nl/~jwasys/old/diy2.html

With a driver DigiTrace will run also on W2k and XP.

Be careful using the parallel port of your PC !!!!!!
If possible, install a second parallel port in a PCI slot.

===================================

See also this one:
http://www.hifi-remote.com/forums/viewtopic.php?t=3569

===================================

[JackPollack]

Thanks again to all that helped. After a little sleep I found that the current limiting resistor on my IR LED was 10K. Anyway, lowered it and everything is working.

[keithdoxey]

After a little sleep I found that the current limiting resistor on my IR LED was 10K.

That would definately limit the current :)

Glad you got it sorted.