View previous topic :: View next topic |
Author |
Message |
sahu77
Joined: 08 Sep 2011 Posts: 202
|
|
Posted: Sun Oct 16, 2011 1:55 am |
|
|
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
|
|
Posted: Wed Oct 19, 2011 12:25 pm |
|
|
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
|
|
Posted: Wed Oct 19, 2011 1:35 pm |
|
|
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
|
|
Posted: Mon Jan 09, 2012 1:20 pm |
|
|
Anything is wrong ? as my sch ?
Where I wrong? pl guide me. _________________ sahu |
|
|
rikkitikki
Joined: 30 Jan 2012 Posts: 1
|
alternative way to read RC5 using automatic synchronizing |
Posted: Mon Jan 30, 2012 4:44 pm |
|
|
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 ('')
'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.
Last edited by rikkitikki on Mon Jan 30, 2012 5:10 pm; edited 2 times in total |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19408
|
|
Posted: Mon Jan 30, 2012 5:00 pm |
|
|
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
|
|
Posted: Sun Sep 16, 2012 9:50 am |
|
|
not yet reply any body ! _________________ sahu |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1333
|
|
Posted: Sun Sep 16, 2012 4:47 pm |
|
|
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
|
Re: alternative way to read RC5 using automatic synchronizi |
Posted: Mon Sep 17, 2012 12:23 am |
|
|
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... |
|
|
|