CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

PIC RC5 Code
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
sahu77



Joined: 08 Sep 2011
Posts: 202

View user's profile Send private message

PostPosted: Sun Oct 16, 2011 1:55 am     Reply with quote

ckielstra wrote:
To post a schematic here you first have to upload the picture to a specialized picture website like imageshack.us Then on this forum you post the picture using the IMG button with a link to the picture at imageshack.


Thank you for guidances.
_________________
sahu
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Wed Oct 19, 2011 12:25 pm     Reply with quote

Your schematic is simple, so not many problems to be expected here. Just a few notes:
1) There is no external circuitry connected to the PIC reset pin MCLR. To make the PIC start up correctly you should then add the NOMCLR fuse to your code. Perhaps this is the default value, but best to take no risks here.

2) Resistor R2 to your TSOP1738 VCC. What is the value? And why is it here, in other schematics I don't see it.

3) Same for R1. The TSOP1738 already has an internal 80k pull-up, no need for an extra pull-up resistor but it doesn't hurt either.

4) The speaker connected directly to the PIC is tricky. Depending on the type of speaker this can draw to large a current and destroy your PIC.

5) How are you testing?
a) I don't see a LED connected, so how do you know a signal is received?
b) What device are you using for generating the RC-5 code?
Beware that the TSOP1738 has an automatic gain circuit, so sending the data for too long a burst will reduce the receiver sensitivity. Short bursts will give the best results, but for first tests a continuous signal can be used.

For further debugging start looking at the differences between your program and the original project. The original circuit was running at 20MHz and yours at 4MHz, so timing related problems can be expected.
Try to see the project as many small parts connected together. Think for each part of a method to test it working correctly, for example have a LED light up at every received RC-5 code and then expand from here.
sahu77



Joined: 08 Sep 2011
Posts: 202

View user's profile Send private message

PostPosted: Wed Oct 19, 2011 1:35 pm     Reply with quote

ckielstra wrote:
Your schematic is simple, so not many problems to be expected here. Just a few notes:
1) There is no external circuitry connected to the PIC reset pin MCLR. To make the PIC start up correctly you should then add the NOMCLR fuse to your code. Perhaps this is the default value, but best to take no risks here.
.

here to ok
ckielstra wrote:

2) Resistor R2 to your TSOP1738 VCC. What is the value? And why is it here, in other schematics I don't see it.

3) Same for R1. The TSOP1738 already has an internal 80k pull-up, no need for an extra pull-up resistor but it doesn't hurt either.


http://img510.imageshack.us/img510/2843/rx01.png

ckielstra wrote:

4) The speaker connected directly to the PIC is tricky. Depending on the type of speaker this can draw to large a current and destroy your PIC.

5) How are you testing?
a) I don't see a LED connected, so how do you know a signal is received?
b) What device are you using for generating the RC-5 code?
Beware that the TSOP1738 has an automatic gain circuit, so sending the data for too long a burst will reduce the receiver sensitivity. Short bursts will give the best results, but for first tests a continuous signal can be used.


speaker = BZR i use here in place of led
ckielstra wrote:

For further debugging start looking at the differences between your program and the original project. The original circuit was running at 20MHz and yours at 4MHz, so timing related problems can be expected.
Try to see the project as many small parts connected together. Think for each part of a method to test it working correctly, for example have a LED light up at every received RC-5 code and then expand from here.

yes i want to use internal osc @4MHz in place of original circuit was running at 20MHz
_________________
sahu
sahu77



Joined: 08 Sep 2011
Posts: 202

View user's profile Send private message

PostPosted: Mon Jan 09, 2012 1:20 pm     Reply with quote

Anything is wrong ? as my sch ?
Where I wrong? pl guide me.
_________________
sahu
rikkitikki



Joined: 30 Jan 2012
Posts: 1

View user's profile Send private message

alternative way to read RC5 using automatic synchronizing
PostPosted: Mon Jan 30, 2012 4:44 pm     Reply with quote

The way some go about this RC5 decoding is constraining because of the variability in the remote control pulse lengths.

I won't show the complete code simply because it encourages laziness.

Here is the theory for RC5 decoding that automatically synchronizes to the pulse train:

DIM an array of 26 places.
set timer 0 pre-scaler to 128 (20 Mhz oscillator)
IR receiver is connected to portb.0
Portb.0 is setup to trigger an interrupt.
IR receiver changes state as it receives remote control code.
code branches to interrupt subroutine
read value of portb.0 and XOR with 1
stop timer 0 (yes, this can be done on the 18F2420)
clear timer 0
start timer 0
wait until portb.0 changes state (compare continuously with XOR'ed value)
stop timer 0
half-bit_time = timer 0 value
quarter_time= divide half-bit_time by 2

wait this quarter_time.(clue, one tick = 25.6 uS)
it ensures the next read will be in the middle of the next received pulse. (2nd start bit)

do 26 times (misses the 1st start bit, leaving only 13 bits )
read portb.0 into the array buffer
increment the buffer pointer by 1
wait half-bit_time (clue, one tick = 25.6 uS)
loop

array now contains 26 half-bits

read first and second half-bits
derive the bit value from the manchester encoding
ok , i'll help a little...

figure how to loop this 13 times
bitA=buffer(x)
bitB=buffer(x+1)
if (bitA=1) and (bitB=0) then databit = 1
if (bitB=0) and (bitB=1) then databit = 0

(any other combination is illegal under manchester encoding so flag an error)

now drop databit value into bit 0 of word variable

RC5word.0 = databit
rotate RC5word left simple


now there is a variable called RC5word which contains an address and command plus a toggle bit and one start bit

address and command codes are reversed. if you got your program this far then you deserve to have this snippet ('Very Happy')


'now the variable rc5word should contain 13 bits of info. (offset 0)
'extract bits 10 thru 6 to get address
RC5_add=0
RC5_add.4=RC5word.10
RC5_add.3=RC5word.9
RC5_add.2=RC5word.8
RC5_add.1=RC5word.7
RC5_add.0=RC5word.6

'extract bits 5 thru 0 to get command
RC5_comm= RC5word AND 63



if any of you college kids build a working program from this well done.
You earned it.
And I'll know you didn't fake your degree. Very Happy


Last edited by rikkitikki on Mon Jan 30, 2012 5:10 pm; edited 2 times in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Jan 30, 2012 5:00 pm     Reply with quote

sahu77 wrote:
Anything is wrong ? as my sch ?
Where I wrong? pl guide me.


I'd be worried about the Piezo buzzer. You need to check the specs, but a lot of the 5v units draw over 30mA. More than a PIC pin is rated to drive. You need to check for your exact unit what current it draws, worst case at 5v...

Best Wishes
sahu77



Joined: 08 Sep 2011
Posts: 202

View user's profile Send private message

PostPosted: Sun Sep 16, 2012 9:50 am     Reply with quote

not yet reply any body !
_________________
sahu
jeremiah



Joined: 20 Jul 2010
Posts: 1314

View user's profile Send private message

PostPosted: Sun Sep 16, 2012 4:47 pm     Reply with quote

Ttelmah provided some feedback in the post above yours. What is your response to his comments?
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

Re: alternative way to read RC5 using automatic synchronizi
PostPosted: Mon Sep 17, 2012 12:23 am     Reply with quote

rikkitikki wrote:
The way some go about this RC5 decoding is constraining because of the variability in the remote control pulse lengths.
I do agree that timing in communications is always to be considered, but that's why the here used Manchester encoding was introduced! With Manchester encoding you only check for presence or absence of a signal edge and from that you derive the received bit value. Clock pulse and data are mixed and available, but at the cost of halving the data rate.

Your proposed method for sampling the bit levels at each half bit time is very error prone. With 26 samples less than one percent timing error is allowed for sender _and_ receiver combined. Almost unachievable in the real world. Where a proper implementation of Manchester encoding can do time synchronisation on every edge and gives you 50% error margin.

Showing off involves risks...
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group