RC5 code for infrared receiver

[Dennis]

Dave thanks for the link as always.

For the record I have never wanted anyone, nor asked anyone to write code for me! I am not using PIC's nor electronics for any commercial gain ..it is merely a hobby !
I have asked only for code snippets to gain more of an understanding of certain aspects of a particular technology or to move past a struggling block.
So THANK YOU to you and to all the others who still reply no matter how many times they have heard and answered the same questions.

It's fantastic that so many here are happy to share code and experiences with others but please understand that as simple as it may seem for some to read and understand, it may take others lifetimes and that's where a few lines in a reply to a question will advance the learning process.
To err is human ... not so ?

So off I went
Forums,sites,articles, google,the manual, late nights, Dave's suggestions, Bruce's site, and Les Johnson's article oh yes and dome app note from microchip, and many cups of coffee.... I am slowly moving closer to some sort of understanding (or more confusion)....
See, the big problem was trying to grasp the PULSIN command and the resolutions @ given oscillator rates which LES JOHNSON does extremely well in the article "Controlling the world from your armchair" , in the article Les says

I hope that I’ve succeeded in illustrating
that both, infrared decoding and
PICmicro programming need not be the
exclusive property of the whizz kids or
rocket scientists among us.

Well that certainly did start clearing up the a lot confusion I have had with the PULSIN command for so long, it is still a little confusing for me I must admit ..stupid human that I am !

Anyway , with enough bashing away and peeking and poking I finally came up with something that seems to work , but only with a certain remote code typed into a universal remote. At the moment there must be at least 12 different remote controls scattered around the workbench.

Here is the code :

' Philips RC5 IR decoder for 12F629 @ 4MHZ
'set for samsung TV on universal rae-1000 (or similar??) remote - TV1 -code 189 most buttons work
        
        define OSC 4 '4MHz
        DEFINE OSCCAL_1K 1          ' Set OSCCAL for 1k -HELPS tuning the crystal for more accurate timing
        CMCON = 7
        'TRISIO = %76543210          ' port GPIO 0=output and 1=input
        TRISIO = %00000010          ' GPIO.1 is an input all the rest are outputs
        'OPTION_REG.7 = 0 ' Internal pull-ups = on
        
    'debug defines
    DEFINE DEBUG_MODE  0    ' Debug sending INVERTED serial data
    DEFINE DEBUG_REG GPIO   ' Debug Port = GPIO
    DEFINE DEBUG_BIT 2      ' Debug.bit = GPIO.2
    DEFINE DEBUG_BAUD 2400  ' Default baud rate = 2400
    'end of debug defines
    
    'Variables begin here
    RC5CODE VAR WORD ' Holds 12-bit RC5 code
    CYCLEX VAR BYTE ' used to hold the loop count for bit collection 
    IRPIN VAR GPIO.1 ' GPIO.1 input pin reading data
    'end of variables



main:
'check for a valid header
IF IRPIN = 1 THEN main 'Only start when PULSE is a LOW 
    PAUSEUS 100 'Pause for 0.1mS
IF IRPIN = 1 THEN main 'Could be junk so try again
    PAUSEUS 1350 'Pause for 1.350mS
'header check is good so now continue

rc5code.0[13] = IRPIN 'Setup array to read each pulse into Bits 
    FOR CYCLEX = 12 to 0 STEP - 1 'read 13 Pulses/bits in reverse order
        RC5CODE.0[cyclex] = IRPIN 'build the array 
    PAUSEUS 1800 ' PAUSE 1.8mS then start reading next BIT/pulse
    NEXT cyclex  'go back and do it again

IF RC5CODE.LOWBYTE = $FF THEN main 'Check to see if it's junk we received $FF aka 255

'OK now dow some AND-ing/bit-masking to get the codes right

RC5CODE = ~RC5CODE & $003F ' Mask upper 10-bits to return 6-bit data
' in lower 6-bits of word result
'Send it to the MAX232 or serial port for display
debug "Key Pressed = ",DEC rc5code ' send the code to serial port/MAX @ 2400bps TRUE
'for LCDOUT ALTER THE NEXT LINE
'LCDOUT "kepress is", DEC RC5CODE

RC5CODE=0 ' Clear the variable for next keypress
PAUSE 500 ' a short DEBOUNCE -If you leave this out then expect duplicates -- !

GOTO main 'start again from main
  end

The code behaves differently for most remotes and I'm sure only very well for those sending RC5 codes.

Will post the circuit later on ..really simple but it works.

I am busy playing around with Les Johnson's code (what I could make out in the article) and will post that later on too.

Dave .. I will keep bashing away and post progress.

Keep well

Kind regards
Dennis

[Dennis]

Here's a schematic as promised !

[Dennis]

Hi all

The code in earlier posts works but produces some strange results and I'm sure it has to do with timing and the bit tests I'm doing.
I have been reading up on the RC5 code at this sitehttp://www.sbprojects.com/knowledge/ir/rc5.htm

I'm still not just not getting it right and would really appreciate some guidance from some kind soul here.

Here's how I understand it so far (I have put comments in the code too):
1.RC5 consists of 1.778ms pulses representing a bit
2.Each bit consists of two halves and either half of the time may be filled with a 36Khz burst.
If the burst occurs in the first half then a ZERO is represented.
If the burst occurs in the second half then a ONE is represented.
3.There are TWO(2) Start bits
4.The third bit is a "toggle" bit - which tells us the button is pressed.
Apparently it is up to the receiving device to 'sense' that the button is down/pressed.

So in order to get the received pulses checked and decoded the first step is decide on the method of capture right ?
I have chose to use a 12F629 and TSOP1736 IR receiver is on GPIO.2 for receiving the IR input (IRpin in the code)
The methods I have been seeing in the forums and on the web seem to use either PULSIN or a PIN state test.
I have chose the PIN state test because I still don't understand the PULSIN command (you can only read the manual and examples all over so many times) - the thing I don't get is the timing/numbers. the rising ,falling and duty cycle do make sense.
So I chose to use the state of the PIN method.

The pseudo code is as follows:
1.Monitor a PIN (GPIO.2) and wait for it to go LOW - this means the start of a pulse/bit.
2.We know that if the first half of the pulse/bit is LOW (889uS) then the next half should be HIGH (assuming this is indeed a start bit)
3.So a quick check would help --- the idea is to delay/wait for a duration of under 889uS and then check to see if the pulse/bit is still low)
If it is high then start over and keep waiting and checking for a pulse.
If it is low then wait for a short time and check the next half time already spent +889uS/2
4.if the next half is HIGH then we have the first start bit and it's time to check the second incoming start bit.
So back to square one and do it again for the second start bit.
5.After I have the 2 start bits , it's time to start collecting the rest of the bits into a word variable.
6.Once we have collected the bits, they need to be separated/masked/divided into the a DEVICE/ADDRESS and COMMAND portion
BITS 4 to 8 =ADDRESS code MSB first
BITS 9 to 14 = COMMAND code MSB first.

Well that's the order of things as I have it figured out so far.



Please find my code below (It's not complete yet as I first need to understand the filtering correctly and then will begin (and finally post) the bit grabbing section.

I have it running but the problem is my initial bit tests don't seem to work because when I press a button on any remote (RC5 and others) it activates a message on my screen.I only want to filter RC5 code.

What am I doing wrong ? :-(
Should I rather attempt to use PULSIN (If so, what figures should I be using)

Kind regards

Dennis

' Philips RC5 IR decoder for 12F629 @ 4MHZ
'set for samsung TV on universal rae-1000 (or similar??) remote - TV1 -code 189 most buttons work
        
        define OSC 4 '4MHz
        DEFINE OSCCAL_1K 1          ' Set OSCCAL for 1k -HELPS tuning the crystal for more accurate timing
        CMCON = 7
        'TRISIO = %76543210          ' port GPIO 0=output and 1=input
        TRISIO = %00000100          ' GPIO.2 is an input all the rest are outputs
        'OPTION_REG.7 = 0 ' Internal pull-ups = on
        
    'debug defines
    DEFINE DEBUG_MODE  0    ' Debug sending INVERTED serial data
    DEFINE DEBUG_REG GPIO   ' Debug Port = GPIO
    DEFINE DEBUG_BIT 0      ' Debug.bit = GPIO.0
    DEFINE DEBUG_BAUD 2400  ' Default baud rate = 2400
    'end of debug defines
    
RC5 VAR WORD ' Holds 12-bit RC5 code
Loopy VAR BYTE ' Loop variable
IRpin VAR GPIO.2 ' RB.0 input pin reading data
Startbit2 var  bit 'holds first synch bits
Startbit1 var  bit 'holds synch bits
Home: 
 

IF IRpin = 1 THEN Home ' Wait for low going pulse
'
'
'if not then continue to read the pulse
'
'RC5 has equal length pulses each ot 1.788ms
'first two bits are START BITS for RC5 one bit = 889uS X2half bits = 17880ms/bit 
'0 = burst in first half of bit time,1=burst in 'second half of bit time
' half    half    half    half   half   half   half    half
'________|||||||________||||||||_______|||||||________|||||||
'  889     889     889    889
'STARTbit1       Startbit2      Togglebit      First data MSB
'--------------|---------------|-------------|---------------| ...12 others
'                                             Bits 4to8 Addr Bits 8to12 Command
'           |
'.......testfor|........testfor|
'         HIGH            HIGH
'
'send a message to serial port
debug "got something YAY ",DEC Y,13,10
'
PAUSEUS 200 ' Short delay to waste some time and test if pulse is still low
'
'Some conditions

IF IRpin = 1 and startbit1=0 THEN Home ' Must be noise so test again
IF IRpin = 1 and startbit1=1 THEN getbits 'is startbit1=1 
PAUSEUS 1350 ' Pause to read 2nd half of 1st bit period is it 1 or 0 ?
'
'
'send message to serial port

Debug "looks like RC5 S1 bit..checking next bit"
Startbit1=1 'set startbit to flag we got first start bit
if IRpin = 1 and Startbit1 =0 then Startbit1 =1
' test conditions I may use
'if IRpin=1 and Startbit1=1 and Startbit2=0 then Startbit2=1
'if startbit1=1 and startbit2=1 then goto getbits
'
'
While IRpin=1:Wend ' go home when pin goes low again
goto home

[Dennis]

@ Dave Houston and @ Bruce

Hi Guys

I think I finally got it !!

I decided to measure the incoming pulses with PULSIN and debug :-), next step is a scope :-)

So for the PULSIN command
@ 4 Mhz PULSIN returns a value with a 10uS resolution/increments.
So for the SONY protocol header the returned PULSIN value should be around 240 not so ?

So if testing a SONY remote I should be testing for an incoming PULSIN value of between say 190 and 290 not so ?
Those figures are based on the debug tests I have done with ..get this..a Phillips remote.

One question here:
What tolerance value should I be using ? Is 20% ok or should I use 30% just to be safe ?

So i figure the header test would be something like

IRpulse_length var word(13)
IRpin var GPIO.0

getheader:

PULSIN IRpin,0,IRpulse_length(0)

if IRpulse_length <190 then getheader

if IRpulse_length >290 then getheader

goto getheader

If the IR pulse passes the test , the next step is to collect the bits and then to possibly use an AND to mask the received data to split into device and commands .. not so ?

Another question :
How do I test the second pulse as in the case for the RC5 protocol ?
Should I just grab all 13 bits following the initial header and then check the second bit once I have captured them all ?
This would probably be the best idea since the second bit determines whether or not the code is RC5-X which only uses one start pulse.


I would really appreciate your comments here. it's not a problem if you don't/can't reply since I'm sure you have been asked this a million times on these forums. I will still continue to experiment until I have it working though and will post back results along the way as always.

Kind regards
Dennis

[Byte_Butcher]

@ 4 Mhz PULSIN returns a value with a 10uS resolution/increments.
So for the SONY protocol header the returned PULSIN value should be around 240 not so ?

Yes. About 240.

So if testing a SONY remote I should be testing for an incoming PULSIN value of between say 190 and 290 not so ?

I have some lighting devices here that "speak Sony" and use a 16F684 running @ 8MHz, and I have my "limits" set at 450 and 520.
That seems to work reliably with all 3 remotes I use... RCA, Universal, and Phillips.

One question here:
What tolerance value should I be using ? Is 20% ok or should I use 30% just to be safe ?

Mine are more like 10% and that works fine with all 3 remotes I use.

So i figure the header test would be something like

IRpulse_length var word(13)
IRpin var GPIO.0

getheader:

PULSIN IRpin,0,IRpulse_length(0)

if IRpulse_length <190 then getheader

if IRpulse_length >290 then getheader

goto getheader

If the IR pulse passes the test , the next step is to collect the bits and then to possibly use an AND to mask the received data to split into device and commands .. not so ?

Yeah. I use this:

IRIN:     
    IR_Dev=255:IR_But=255 ' Preset the Return variables
    Pulsin IRinput,0,Header ' Measure the header length.
    If Header < 450 then Return' If the result is less than 450 toss it out
    If Header > 520 then Return' If the result is greater than 520 toss it out  
' Receive the 12 data bits and convert them into a packet
    For Bitcnt=0 to 11 ' Create a loop of 12
    Pulsin IRinput,0,P_Val ' Receive the IR pulses
    If P_Val >= 190 then ' If >= 190 then we've received a 1
        Packet.0[Bitcnt]=1 ' So set the appropriate bit
        Else
        Packet.0[Bitcnt]=0 '...or clear the appropriate bit
        Endif
    Next     
    IR_But=Packet & %01111111 'Extract the 7 BUTTON bits
    IR_Dev=(Packet >>7) & %00011111 'Right shift and extract the 5 DEVICE bits     
    return

Another question :
How do I test the second pulse as in the case for the RC5 protocol

I haven't fooled with RC5 yet, only Sony.
I'm hoping you'll become an expert soon.

steve

[Dennis]

@Steve ...Seems like I am finally making some headway ..YAY

Hey I recognize that code ... it's from 'Controlling the world from your armchair' aka article.pdf by Les Johnson :-)

I tried it and it didn't work at the time .. I'm sure it's 'cos I had the wrong pulsin resolution and timing.

Now if you look carefully at the previous posts you'll see mention of the RC5 protocol and here for a more detailed tech dive [HTML]http://www.sbprojects.com/knowledge/ir/rc5.htm[/HTML]

Expert ...pffft..there are so many remote controllers out there :-) and so many different codes :-)

Thanks for the extra info regarding PULSIN header checks by the way :-)

Kind regards

Dennis

[Byte_Butcher]

Hey I recognize that code ... it's from 'Controlling the world from your armchair' aka article.pdf by Les Johnson :-)

Yep. Works great too.

Now if you look carefully at the previous posts you'll see mention of the RC5 protocol and here for a more detailed tech dive [HTML]http://www.sbprojects.com/knowledge/ir/rc5.htm[/HTML]

Thanks. I've read a bit about RC5... I just haven't used it for anything yet.

Say, the other thing I'll mention is that if you use DT_interrupts (or probably any interrupts for that matter) you may want to turn them off just before the PULSIN command and turn 'em back on afterward. It took me an embarrassingly long amount of time to troubleshoot THAT problem...


steve