|
|
View previous topic :: View next topic |
Author |
Message |
Ahmed Adel Hosni
Joined: 16 Aug 2010 Posts: 12
|
IR decoder with CCP using PIC16F877 accuracy |
Posted: Thu Jan 09, 2014 4:09 pm |
|
|
I am facing a problem in calculating the real exact value of a Sony Infrared signal from an IR receiver.
The SIRC is known to have 600 us or 1200 regarding the start bit. Well I am using the CCP1 and CCP2 to measure the low time but the readings are not 600 us but rather 660 and the best values i got was 630 when the remote was 10 cm from the receiver.
Another thing that must be noted is that using Proteus ISIS and generating a pulse, the value was 600 us correctly.
SIRC illustration: http://www.sbprojects.com/knowledge/ir/sirc.php
I am using KSM803LM ( the one available in my country ): http://www.ram-e-shop.com/ds/general/KSM803LM.pdf
THe code:
Code: |
#include <16F877A.h>
#fuses HS,NOWDT,NOPROTECT,NOLVP
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
#include <lcd_interface.c> // don't bother urself with this file. It's to interface with the LCD like the one in the library
unsigned long i, count, length;
unsigned long pulse_width[40] = {}; // Declare an array to store values / "the number can be change"
#int_ccp2
void isrl()
{
pulse_width[i] = CCP_2 - CCP_1;
set_timer1(0);
i = i + 1;
}
void main()
{
output_high(PIN_C5);
delay_ms(1000);
output_low(PIN_C5);
lcd_init();
printf(lcd_putc,"Start");
setup_ccp1(CCP_CAPTURE_FE); // Configure CCP1 to capture fall
setup_ccp2(CCP_CAPTURE_RE); // Configure CCP2 to capture rise
setup_timer_1(T1_INTERNAL | T1_DIV_BY_1); // Start timer 1
enable_interrupts(INT_CCP2);
// enable_interrupts(INT_TIMER1);
enable_interrupts(GLOBAL);
set_timer1(0);
while(TRUE)
{
if(input(PIN_B6) == 1)
{
while(input(PIN_B6) == 1);
i = 0;
count = 0;
printf(lcd_putc, "\fcleared");
}
else if(input(PIN_C4) == 1)
{
while(input(PIN_C4) == 1);
lcd_goto(1,1);
printf(lcd_putc, "\f%lu,%lu,%lu", i, count, 1*pulse_width[count]/5); // print low time
count = count + 1;
output_high(PIN_C5); // indicator LED
delay_ms(500);
output_low(PIN_C5);
}
if(i > 80 ) { i = 0; } // just to avoid putting an if condition to stop at 40, in the interrupt routine upward of the CCP2
}
}
|
The schematic: I am connecting the right pin ( Vcc ) of the Receiver directly to the 5v. The same thing for the middle pin which is the Gnd to the zero directly.
The left pic is the signal and is connected directly to the 2 pins of the CCP.
I connected a 10 uf and tried 100 uf between the Vdd and Vss.
I don't know whether the problem is in my coding and whether this technique using CCP consumes some microseconds so that's why my readings are not accurate. but 60 us is a lot and i guess not logic.
or maybe i must connect the output pin to the microcontroller in a better way. may be pulled high for example.
Thank you in advance.
|
|
|
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Thu Jan 09, 2014 6:48 pm |
|
|
Maybe the remote itself does not have a perfect timing.
G. _________________ CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19561
|
|
Posted: Fri Jan 10, 2014 3:06 am |
|
|
Why do you think SIRC, has a 2:1 timing difference between the 1, and 0 timings?.
Reason is that it is designed to work with transmitters that may well use simple RC timings, and commonly have perhaps +/-20% timing errors.
Also as you have found the leading/trailing edges of the tone burst may get degraded at longer/shorter distances, making the timings even worse.
Generally most devices seem to give longer than specified pulses:
<http://ghmicro.com/index.php/77-projects/70-sirc-with-the-lpc-p2148>
A search will find dozens of other similar examples.
Best Wishes |
|
|
Ahmed Adel Hosni
Joined: 16 Aug 2010 Posts: 12
|
|
Posted: Fri Jan 10, 2014 3:13 am |
|
|
Gabriel wrote: | Maybe the remote itself does not have a perfect timing.
G. |
You may be right and i guess i need to test me decoder with a function generator also ti be sure. |
|
|
Ahmed Adel Hosni
Joined: 16 Aug 2010 Posts: 12
|
|
Posted: Fri Jan 10, 2014 3:19 am |
|
|
Ttelmah wrote: | Why do you think SIRC, has a 2:1 timing difference between the 1, and 0 timings?.
Reason is that it is designed to work with transmitters that may well use simple RC timings, and commonly have perhaps +/-20% timing errors.
Also as you have found the leading/trailing edges of the tone burst may get degraded at longer/shorter distances, making the timings even worse.
Generally most devices seem to give longer than specified pulses:
<http://ghmicro.com/index.php/77-projects/70-sirc-with-the-lpc-p2148>
A search will find dozens of other similar examples.
Best Wishes |
but i guess a 20% error with a transmitter will shift the whole train of pulses. i may read a 1 not a zero after a couple of pulses because the error will accumulate.
I will check you link and see what it is talking about.
Thank you all and waiting for other answers that could help |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19561
|
|
Posted: Fri Jan 10, 2014 3:31 am |
|
|
Unlike async protocols like RS232, the bit _time_ does not basically matter.
You decode a '1' or you decode a '0' at each point. You only consider it 'wrong', if the time between the bits is shorter than the 400uSec, or longer than 2400uSec used for the marker bits.
Best Wishes |
|
|
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Fri Jan 10, 2014 7:49 am |
|
|
In addition, i think/remember/read somewhere that many IR protocols have a long start pulse so that the Receiver can adjust for errors on the transmitter... _________________ CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19561
|
|
Posted: Fri Jan 10, 2014 8:39 am |
|
|
Yes, that is the 2400uSec bit on the Sony protocol.
Basically you look for this, then look for 'when' falling edges occur.
If a falling edge is less than 900uSec after the last one, you have a '0', if if is more that 900uSec, but less than 1500uSec, you have a '1'.
The actual spec. says to wait 900uSec after the last edge, then sample the bit.
Best Wishes |
|
|
Ahmed Adel Hosni
Joined: 16 Aug 2010 Posts: 12
|
|
Posted: Fri Jan 10, 2014 3:25 pm |
|
|
That's an an awesome explaination from you and things are more clear now.
Well i have some questions to fully understand how the receivers handles the bits.
I remember when i decoded the sirc that i received the patterns repeated three times after one another. and i read in the link that you gave to me that the third one is the one used. So i just want to make sure that i must send the patterns three times because i just sent the patterns one time and the TV didnt work.
Another thing, does this technique that you explained above applies for other protocols ? To wait for an edge and then capture the bit ?
Sorry for asking too many questions |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19561
|
|
Posted: Sat Jan 11, 2014 2:18 am |
|
|
No, as with all things there are lots of variants.
However a lot of the IR protocols are based upon some 'common ground'.
1) Since remote controls need to be cheap, their timings may well be inaccurate to save cost.
2) Packets may be lost. The SIRC recommendation is that you decode all the packets, and use 'best of two'. Many people doing their own decoder just pull the last. Your TV looks to be implementing the correct rejection of a single packet. Most standards have some protocol for this.
3) Some forms are much more complex with higher data rates and checksums added. |
|
|
Ahmed Adel Hosni
Joined: 16 Aug 2010 Posts: 12
|
|
Posted: Sat Jan 11, 2014 3:13 am |
|
|
Thanks a lot Ttelmah for your fast response and please be patient with my other questions
I'll try to transmit the pulses again within two days and inform you back with the results.
I have another issue that faced me before deciding to decode the SIRC. At the beginning my aim was to decode the pulses of my York air conditioner but i couldn't recognize the accurate number of bits as i found out that i receive 39 counts if i am 10 cms away and sometimes it's 38, 40. So i decided to count from the receiver itself from the AC to the uc and read the values and i found out that they are 36 and also the same problem began again to appear, to count 38, 40, 42, between these ranges.
Do you have any idea why do i face this issue ? |
|
|
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Sat Jan 11, 2014 6:39 am |
|
|
Some protocols send the bit string once and then just send a "repeat" bit or bits if you keep the button pressed.
Also keep in mind you never press the button for the exact amount of time of ONE frame. Maybe the extra bits are the begining of the next frame.
I did a similar project with an LG unit. I just sampled several times the data frame and used excel to sort through the data and get the correct frame length and bit width.
G. _________________ CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ahmed Adel Hosni
Joined: 16 Aug 2010 Posts: 12
|
|
Posted: Sat Jan 11, 2014 7:03 am |
|
|
Gabriel wrote: | Some protocols send the bit string once and then just send a "repeat" bit or bits if you keep the button pressed.
Also keep in mind you never press the button for the exact amount of time of ONE frame. Maybe the extra bits are the begining of the next frame.
I did a similar project with an LG unit. I just sampled several times the data frame and used excel to sort through the data and get the correct frame length and bit width.
G. |
right and i guess from the readings that i get that it's not a reapeted pattern because i don't find a long start bit in the middle of the patterns.
I'll post the signals after a few hours to help in understanding the problem. |
|
|
Ahmed Adel Hosni
Joined: 16 Aug 2010 Posts: 12
|
|
Posted: Sat Jan 11, 2014 10:48 am |
|
|
These are the signals which i read from the AC receiver itself.
This is 38 readings:
Code: |
3400 usec, 1660 usec
520 usec, 1100 usec
500 usec, 1080 usec
520 usec, 480 usec
540 usec, 480 usec
540 usec, 460 usec
540 usec, 1080 usec
520 usec, 480 usec
540 usec, 480 usec
540 usec, 1080 usec
520 usec, 1060 usec
520 usec, 480 usec
540 usec, 1080 usec
540 usec, 460 usec
540 usec, 480 usec
540 usec, 1060 usec
500 usec, 1140 usec
500 usec, 480 usec
540 usec, 1100 usec
480 usec, 1080 usec
520 usec, 500 usec
520 usec, 480 usec
540 usec, 1080 usec
480 usec, 520 usec
520 usec, 500 usec
540 usec, 480 usec
540 usec, 480 usec
500 usec, 500 usec
520 usec, 500 usec
540 usec, 480 usec
540 usec, 1100 usec
460 usec, 1100 usec
520 usec, 480 usec
540 usec, 500 usec
540 usec, 1060 usec
520 usec, 480 usec
520 usec, 1100 usec
520 usec, 480 usec
|
This is increases by one
Code: |
3460 usec, 1620 usec
500 usec, 1120 usec
480 usec, 1120 usec
480 usec, 520 usec
520 usec, 480 usec
540 usec, 480 usec
520 usec, 1080 usec
500 usec, 500 usec
540 usec, 500 usec
500 usec, 1100 usec
500 usec, 1120 usec
480 usec, 520 usec
480 usec, 1120 usec
480 usec, 520 usec
500 usec, 520 usec
500 usec, 1100 usec
500 usec, 1120 usec
480 usec, 520 usec
500 usec, 1100 usec
500 usec, 1080 usec
520 usec, 500 usec
520 usec, 500 usec
520 usec, 1080 usec
500 usec, 500 usec
520 usec, 520 usec
500 usec, 480 usec
500 usec, 520 usec
520 usec, 500 usec
520 usec, 480 usec
500 usec, 520 usec
500 usec, 520 usec
500 usec, 1100 usec
520 usec, 1100 usec
480 usec, 520 usec
500 usec, 500 usec
520 usec, 1080 usec
520 usec, 500 usec
500 usec, 1100 usec
500 usec, 500 usec
|
This is increased by another one with reference from the last reading
Code: |
3520 usec, 1660 usec
480 usec, 1080 usec
540 usec, 1060 usec
500 usec, 520 usec
520 usec, 500 usec
520 usec, 500 usec
520 usec, 1060 usec
540 usec, 480 usec
540 usec, 460 usec
560 usec, 1040 usec
540 usec, 1060 usec
540 usec, 480 usec
540 usec, 1080 usec
520 usec, 500 usec
520 usec, 480 usec
520 usec, 1100 usec
500 usec, 1080 usec
520 usec, 500 usec
520 usec, 1080 usec
520 usec, 1080 usec
520 usec, 500 usec
520 usec, 480 usec
540 usec, 1060 usec
540 usec, 460 usec
560 usec, 460 usec
540 usec, 1060 usec
520 usec, 480 usec
520 usec, 500 usec
500 usec, 520 usec
520 usec, 480 usec
500 usec, 520 usec
500 usec, 520 usec
520 usec, 1060 usec
540 usec, 1080 usec
520 usec, 480 usec
520 usec, 500 usec
540 usec, 1080 usec
520 usec, 480 usec
520 usec, 1080 usec
520 usec, 480 usec
|
What i see is that there is always 2 pulses one after another repeated with the same values.
Btw this code wasn't written using pic but using an arduino code found there: http://learn.adafruit.com/ir-sensor/using-an-ir-sensor , because I didn't have any available pics at this time and just wanted to test how would the readings appear.
So, I thought that 540 usec, 1060 usec would mean 500 and 1000 so i decided to output the same pulses but using 500 and 1000 usecs and tried to read it again with the same code from arduino but i was read like 440 usec, 1020 usec for example. |
|
|
Ahmed Adel Hosni
Joined: 16 Aug 2010 Posts: 12
|
|
Posted: Mon Jan 13, 2014 4:06 am |
|
|
guys, am happy to tell you that i succeeded to re-transmit the SIRC code to turn on and off the TV :D
Thanks a lot for your help and your patient.
I'll be back again if i faced any problems |
|
|
|
|
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
|