PDA

View Full Version : remote code learning



Bruce
- 25th January 2010, 20:41
This is a simple example for using the 18F2431 motion feedback modules capture hardware
to learn IR codes, and codes from RF encoders.



'************************************************* ***************
'* Name : CODE_LEARN.BAS *
'* Author : B. Reynolds *
'* Notice : Copyright (c) 2008 B. Reynolds *
'* : All Rights Reserved *
'* Date : 8/22/2008 *
'* Version : 1.0 *
'* Notes : Using the 18F2431 Motion Feedback Module capture *
'* : to learn encoder or IR transmitter codes. *
'************************************************* ***************

' Connections;
' IR detector output to PORTA.2 CAP1 input
' PORTB.0 ------/\/\/\/----|>|----GND LED on RB0 (for press/release indicator)
' PORTC.6 --MAX232---PC serial port RX (to print results)
DEFINE NO_CLRWDT 1 ' it's disabled in config
DEFINE LOADER_USED 1
DEFINE OSC 4
DEFINE DEBUG_REG PORTC
DEFINE DEBUG_BIT 6
DEFINE DEBUG_BAUD 9600
DEFINE DEBUG_MODE 0 ' 1 = inverted, 0 = true

NumPulses CON 26 ' total signal states to learn (26 for Sony)

T1 VAR WORD[NumPulses]
INDEX VAR BYTE
KeyNum VAR BYTE

SYMBOL Capture = PIR3.1

CLEAR

ANSEL0 = 0 ' all digital
TRISA.2 = 1 ' cap1 input pin (Capture input)
INTCON = 0 ' interrupts off
TMR5H = 0 ' clear high byte of TMR5 count
TMR5L = 0 ' clear low byte
T5CON = %00000001 ' prescale=1:1, int clock, TMR5=on

Main:
CAP1CON = %01001000 ' auto time base reset, capture on every state change
Capture = 0

FOR KeyNum = 0 TO 14 ' learn 15 total button codes
CAP1CON = %01001000 '
HIGH 0 ' indicate start (user press button)
Capture = 0 ' clear capture flag before starting

' Wait for 1st capture on state-change. Note: We don't care what the 1st capture
' value is since it's the beginning high-to-low edge (for IR), and of no significance.
' We only want the length of each high & low signal after the falling edge.
WHILE Capture = 0 : WEND
Capture = 0

FOR INDEX = 0 TO NumPulses-1 ' captures IR signal in 1uS increments
WHILE Capture = 0 : WEND ' wait for capture event
Capture = 0 ' clear int flag after each capture
T1[INDEX] = ((CAP1BUFH<<8) + CAP1BUFL) ' store capture values
Next INDEX
CAP1CON = 0 ' disable capture immediately after to avoid unwanted captures
Capture = 0
' if user holds transmitter button down too long.
LOW 0 ' indicates user should release transmitter button
PAUSE 1000

' print button codes
FOR INDEX = 0 TO NumPulses-1 STEP 2
DEBUG "low = ", DEC T1[INDEX],"uS",13,10 ' print low signal period
DEBUG "high = ",DEC T1[INDEX+1],"uS",13,10 ' print high signal period
NEXT INDEX
DEBUG 10,13
NEXT KeyNum

Finished: ' indicate finished
TOGGLE 0
PAUSE 200
GOTO Finished

END
This capture module can capture the value of TMR5 on every state change, making
it really simple to capture & recreate timing signals for remote control encoders.

It's really handy if you don't have an O-scope, and want to create code for a custom IR or
RF encoder IC.

anonymouse
- 26th January 2010, 15:59
many thanks for this and the others posted bruce,and also to the other peoples code examples.

amgen
- 27th January 2010, 00:04
Bruce,
That is a neat function. You introduced the PIC with the motion feedback module which makes many functions much easier.

Don
American Generator

Bruce
- 27th January 2010, 00:43
Hi Don,

I wish Microchip had a boat-load more of PICs' with this hardware peripheral. It can
measure low pulse widths, high pulse widths, frequency, and low/high signals from a
remote control encoder all in hardware.

It saves a TON of code, and it's spot-on with values returned for each signal
period.

This really is the ultimate controller for measuring any type of logic signal in hardware,
and excellent for robotics applications.

Note: If you're using this to record IR signals, use it in the dark, or use an IR module
that's very stable. It picks up on even very short signal transitions.

If you want to read a signal from an RF encoder IC, connect the encoder ICs' data output
pin directly to the pin.

It's rock-solid, and really beats recording each signal transition timing on a scope.

circuitpro
- 23rd March 2010, 01:05
Bruce,

I was searching for just this type of thing! I want to be able to memorize particular IR commands from many different types of remote controls (TV models). I am going to build this up, and give it a try. I see you have a constant of 26 (for Sony). Maybe this will make sense as I get into it, but how did you know that, and will I know how many pulses I will need when I see the repetitive pattern for other models?

Thanks very much for this great post!

Len

Bruce
- 23rd March 2010, 01:47
Hi Len,

I knew Sony had this many bits since I have played with it for years. But it will vary like the wind from one IR transmitter & mfg to the next.

If you're not sure just set it to read in 50-60 (or more) pulse times, then look for the BIG pulse between data packets. There's normally a large break time between packets so you'll know where it starts, what's in between, and the end timing.

Then you will find a few that only transmit a few bits and stop. Those are really a bear to figure out. It's not as nice as a good logic analyzer, but it works with the majority of IR transmitters.

flotulopex
- 10th May 2011, 14:19
...T1[INDEX] = ((CAP1BUFH<<8) + CAP1BUFL)...
I did something very similar and was very concerned about code space so I wrote the same kind of code this way which makes it, in my case, 17 words less:
...
Temp.Highbyte = CAP1BUFH
Temp.Lowbyte = CAP1BUFL
T1[INDEX] = Temp
...

dhouston
- 10th May 2011, 15:20
Bruce,

I wrote a PC application 6-7 years ago that scanned IR & RF codes (recorded using a soundcard (http://davehouston.org/learn.htm)), identified them by manufacturer's type, and allowed converting them to Pronto and other formats.

A couple of tips: Accuracy is not critical as most remotes, being battery powered, allow a fairly wide range on pulse/space durations. 20% will work with most.

And, as you noted, most codes have a lengthy space between copies and/or have an initial pulse that is significantly wider than subsequent pulses. You can look for these to determine the end(s) of a code rather than having to predefine the number of bits.

Bruce
- 10th May 2011, 16:36
Hey Dave,

I'm not sure I follow you on this! Could you elaborate?

I have found individual bit timing to not be that critical, but if you're off by a certain margin on each data bit & the space between each data bit, you're potentially off by a mile by the end of the complete data packet, and this really did make a huge difference.

For example - if you're off by say 20% on each data bit, and the space between each bit, you're way off by the end of the packet.

And this may/may not be impacted by your measurement technique. I.E. measureing bits directly from the encoder output or the output of an RF receiver or IR module with a relatively slow rise/fall time, so it's best to be as close as possible in my experience.

dhouston
- 10th May 2011, 20:38
Bruce,

Many of the IR protocols go back 40 years or more when both remotes and receivers were less refined. The overall length of the code is not as important as the bit times. For both PPM (e.g. NEC) and PWM (e.g. Sony) the difference between a 1-bit and 0-bit depends solely on the time between rising edges and the duration of a 1-bit is usually twice the duration of a 0-bit so differentiating them is very easy. The NEC protocol is detailed in the datasheet for their µPD6121 (http://davehouston.org/Nec6121.pdf).

I haven't tested every protocol but have tested several using either a Pronto or a device I designed a few years back (when early PDAs had a CF slot) that sent IR codes. I found the receivers were very tolerant. I've done similar tests with various RF devices (X10, ceiling fans, garage door openers, etc.) with similar results. And, while not much of a factor for this discussion, most consumer IR receivers also have a fairly wide bandwidth (±5kHz) and this does come into play as many protocols are defined using cycles of carrier rather than time.

Even biphase protocols like Philips RC5, etc. are forgiving as their timing is contained within the code..

That said, when designing transmitters, I tried to keep them within ±10%.

Ioannis
- 10th May 2011, 20:46
How about re-calibrating on every header to the possible slip?

If header is x% off then probably all the bits will be too.

Ioannis

dhouston
- 10th May 2011, 21:02
How about re-calibrating on every header to the possible slip?Again, it really isn't necessary as the codes need not be precise. For example, NEC defines a 1-bit as ~2.2mSec between rising edges and a 0-bit as ~1.1mSec between rising edges. It's child's play to differentiate even if overall timing varies widely.

The only codes that require you to capture both pulses and spaces are the biphase protocols like Philips RC5, RC6, etc. where you need to recover the timing before you can decide between 1 and 0.

Ooops - I forgot about one protocol. I don't recall who uses it (it's a high-end RF home automation system used mostly in Europe). It uses 5 different pulse widths and 5 different space widths which allows for an enormous code base. If you assign ADCDE to pulses and abcde to spaces, you can see there are lots of possible 10 letter words (10^5 or 100,000)

Bruce
- 10th May 2011, 21:54
Thanks Dave. I agree. I have one version that simply spits out up to 100 pulse periods to a serial port. Then it's easy to see everything at a glance. The period between packets is easy to locate, etc,,.

Even fiddled with one version that actually printed out working PBP code to reproduce the data packets, adjust for various carrier frequency, etc. Was fun. Just cut & paste and viola...;o)

That sounds like a pretty nifty PC app you wrote a while back.

cesar35
- 18th February 2021, 14:31
Hello about mister Bruce code
Can i use another photo as pic16f876a
I appreciate it:eek:

Ioannis
- 18th February 2021, 18:40
Photo? What Photo?

Ioannis

cesar35
- 18th February 2021, 21:40
Excuse me
Hello about mister Bruce code
Can i use another o pic16f876
I appreciate it

Ioannis
- 19th February 2021, 00:36
You need a PIC with the motion feedback module. An there are not many.

Sorry...

Ioannis

Ioannis
- 19th February 2021, 07:34
Or you can write more code to emulate the motion feedback module.

Tedious I think.

Ioannis

cesar35
- 19th February 2021, 11:06
Thanks for the answer.
Do you know if there is another example for my pic16f876
I thank

Ioannis
- 19th February 2021, 12:09
Example to do the same thing as motion feedback module? I am not sure. Guess not.

Ioannis

cesar35
- 21st February 2021, 15:38
I thank
By the answer
A hug