RC5 code for infrared receiver

[Dennis]

Hi All

I am using a TSOP 1736 connected to a 12F629 and that in turn connected to a MAX232 which connected to a PC serial port.

The idea is to capture the keypress data from infrared remotes.

Digging through the forumas I found and tried Dave Houston's code which worked for NEC based remotes. (Thanks Dave!)

I am now searching for some very simple code suited to the RC5 protocol. The one requirement is that hopefully it is purely PICBASIC without any assembler.

I would like to receive the button press from the RC5 infrared transmitter, and store it in a variable , then I could do something like

IF ButtonCode = xxx then
do_something

Any help or pointers would really be appreciated.

Kind regards

Dennis

[dhouston]

You should be able to adapt my code. All you need is the details for each protocol of interest. See...

• http://www.sbprojects.com/knowledge/ir/ir.htm

[Dennis]

That definitely is a start ...
Did you check the PM I sent you by the way ?

As much as I have read the info on the PULSIN command, it still leaves me somewhat confused.

I have seen many references to your code on the forum but I just can't seem to 'catch on' to the method

My blurred pseudo understanding of it is :

1.Wait for a certain pulse of specified duration (discard all other pulses we are not interested in)
2. Once the correct pulse is received then start counting pulses of a certain duration
3. Store each pulse as a bit. 8 pulses = a byte , 32 pulses = 4 bytes
4. Decipher the received/stored bits/bytes into a SYSTEM ID and a DEVICE ID.


So with reference to the diagram and the following quote:

http://www.sbprojects.com/knowledge/ir/rc5train.gif

The first two pulses are the start pulses, and are both logical "1". Please note that half a bit time is elapsed before the receiver will notice the real start of the message.
Extended RC-5 uses only one start bit. Bit S2 is transformed to command bit 6, providing for a total of 7 command bits. The value of S2 must be inverted to get the 7th command bit though!

The 3rd bit is a toggle bit. This bit is inverted every time a key is released and pressed again. This way the receiver can distinguish between a key that remains down, or is pressed repeatedly.
The next 5 bits represent the IR device address, which is sent with MSB first. The address is followed by a 6 bit command, again sent with MSB first.
A message consists of a total of 14 bits, which adds up to a total duration of 25 ms. Sometimes a message may appear to be shorter because the first half of the start bit S1 remains idle. And if the last bit of the message is a logic "0" the last half bit of the message is idle too.

As long as a key remains down the message will be repeated every 114ms. The toggle bit will retain the same logical level during all of these repeated messages. It is up to the receiver software to interpret this auto repeat feature.

PS: I had rather a big error on this page for quite some time. For some mysterious reason the LSB and MSB of the address and command were reversed. I can recall correcting this error before, but somehow an old version of the description must have sneaked its way up to the internet again.

And with reference to your code

If (stx<760) Then init

As soon as a pulse is received greater than 760 then INIT but what is the 760 ?
and

While GPIO.1=1:Wend			'wait space

This line is the same as

While GPIO.1=1
Wend			'wait space

So in other words keep looping while GPIO.1 is 1
and as soon as it goes to a 0 then continue to the next line(s)
On the next section of code (the pulse count/bit catcher) you REPEAT the same thing until i is > 31 (since 0 to 31 is 32 pulses(1 or 0 bits) right ?

Repeat
          PulsIn GPIO.1, 1, pulse
          If (pulse>100) Then
            IR.0(i)=1				'set bit
          EndIf
          i=i+1 
        Until (i>31)

OK for me there is a little confusion in the above stub of the code

If (pulse>100) Then

So do we disregard any pulse less than 100 here ?

and this line
[/code] IR.0(i)=1 [/code]

So the above begins to build the the array IR[4] (it's 4 since we need to catch 4 bytes (32 pulses/bits) not so ?)
The value "i" is the counter which is incremented evertime we loop through this section of code until the UNTIL condition is met (Ie. we have 32 bits or 4 bytes namely IR.0,IR.1IR.2and IR.3)
And finally to send what we have so far (the value of the 4 IR bytes to the PC serial port

For i = 0 To 3
          Debug IHEX2 IR[i] 
          
        Next

I notice you display the HEX value here, is that because if it were decimal you might overflow the WORD var ?

I also saw in another posting that there might be a reverse bit order sent through ... is that correct ?

In the meantime I will go through the link you sent and carefully examine the RC5 info and post what I have come up with albeit wrong.

Kind regards

Dennis





I hope you don't mind me asking a tally of questions to get a clearer understanding of the functions.

[Dennis]

I have to catch 14 bits as opposed to 32 right ?

would this mean something like

Until (i>13)

If that's the case then what about the pulse sizing ?
I am specifically referring to these lines

If (stx<760) Then init

and

pulse>100

I am correct so far then the above part is where the confusion starts and it has to do with the PULSIN command.

As i understand it the PULSIN command...
As per the manual

Measures pulse width on Pin.
If State is zero, the width of a low pulse is measured.
If State is one, the width of a high pulse is measured.
The measured width is placed in Var.
If the pulse edge never happens or the width of the pulse is too great to measure, Var is set to zero

Fantastic , that explains the following (I think!)

While GPIO.1=1
Wend

Now here's the cruncher for me

The resolution of PULSIN is dependent upon the oscillator frequency. If a 4MHz oscillator is used, the pulse width is returned in 10us increments.
If a 20MHz oscillator is used, the pulse width will have a 2us resolution.

This is a tad confusing, what about other values of oscillator ?
I am using a 4MHZ internal clock so therefore I would be looking at 10uS increments, but what does this mean exactly ? Does it mean the pulse is returned rounded off to the nearest 10uS ?

Another thing ...

Defining an OSC value has no effect on PULSIN.
The resolution always changes with the actual oscillator speed.

So PULSIN reads ONLY the ACTUAL oscillator (crystal, R/C) so what happens if we were using this on an 18F4520 for example where you could use PLL , something like 8MHz x 4 to total up to 32MHz ..?
Is there some trick involved in that instance or do we then need to start looking at HPWM ?

Apologies for the what may appear as "dumb questions" but I am trying to keep them simple in order to explain my confusion.
And looking at the forums and various posts it seems you have so many asking similar thnigs about your code.

Kind regards
Dennis

[dhouston]

Dennis,

I am not going to write your code for you. And I've already answered many of your questiions 2 or 3 times either here or in the many PMs you sent before I stopped responding. Here's a thread which includes code for capturing durations of both edges which you will likely need for RC5...

• http://www.picbasic.co.uk/forum/showthread.php?t=12444

[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

[garryp]

You should be able to adapt my code. All you need is the details for each protocol of interest. See...

• http://www.sbprojects.com/knowledge/ir/ir.htm

Hello, dhouston
I tried to look for the link but 404 error is coming
Can you another link so that I can adapt your code
thanx

[keithdoxey]

Try http://www.sbprojects.com/knowledge/ir/index.php and follow the instructions on "How to Navigate", there is a dropdown on the menu bar that lists all the different protocols.