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

RC700 infrared remote control

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
rudy



Joined: 27 Apr 2008
Posts: 167

View user's profile Send private message Send e-mail MSN Messenger

RC700 infrared remote control
PostPosted: Mon May 11, 2009 5:12 pm     Reply with quote

Hi,

I need to know about infrared control, I have one here RC700 one, and I don´t know how to implement a routine to receive commands from it. Should I use RX pin with RS232 or RB0 interrupt routine?
Guest








PostPosted: Thu May 14, 2009 10:31 am     Reply with quote

Hi,

Do you know anything about the data transmission protocol being used? Can you provide a link to this device?

I doubt the data is being sent in a traditional serial format, so the PIC Rx pin and the internal UART is not going to help you out. A better choice would be the RB0 pin and an External Interrupt solution.

The code library has some IR routines. That might be a good place to start!

Charlie
rudy



Joined: 27 Apr 2008
Posts: 167

View user's profile Send private message Send e-mail MSN Messenger

PostPosted: Sat May 16, 2009 11:00 am     Reply with quote

Thanks Guest.

In fact I don´t know well the protocol, and i tried to get the datasheet from the CI in the remote, didn’t find any ware, it´s BU2483-3J.
I made some tests using RS232 with 1200 baud and recording the values on eeprom, than I analyzed and it’s working not very well, sometimes it does some times does not.
Here are two pictures I take from my scope, from the two buttons I want to deal with.

and


What should I do?

Regards.
Guest








PostPosted: Sat May 16, 2009 10:50 pm     Reply with quote

Well - here is a quick and dirty way to do it.

1) In your big loop wait for the falling edge.
2) Sample at intervals of 1/2 the bit period (which looks to be slightly less than 1 mSec from your scope display)
3) At each sample read whether the pulse is high or low for a 1 or 0 bit read.
4) Continue for the entire command length.
5) Process your received command.
6) Enter the big loop again waiting for the next start of a command (go to step 1).

So I would decode the two commands that you show as:
0101010 and 010010.

This is a common way that UARTs work and a way that I have used to decode things like WWVB time code. Some sample code is here...

http://www.geocities.com/hagtronics/wwvb.c

HTH - Steve H.
rudy



Joined: 27 Apr 2008
Posts: 167

View user's profile Send private message Send e-mail MSN Messenger

PostPosted: Sun May 17, 2009 6:26 am     Reply with quote

Nice.

I will try but I am afraid that so many dalay_ms() may couse some problems with the rest of my routine, I use 20kHz PWM that must be as much stable as possible.

Regards.

Manoel.
Guest








PostPosted: Sun May 17, 2009 1:38 pm     Reply with quote

Rudy: The example was just that -- an example not a solution for your exact problem. You could also use a timer interrupt to signal when you should sample. In between interrupts you can be doing other things.

You get the idea though, right? Somehow you need to sense the start of the sequence, then at the proper point in the middle of each bit you need to sample if you have a one or a zero.

From this there are an infinite number of ways to accomplish this task - some better than others depending on other system constraints.

HTH - Steve H.
Ttelmah
Guest







PostPosted: Sun May 17, 2009 2:20 pm     Reply with quote

However, the UART really should do the sampling you need.
Move the trigger point left, so we can see the rest of the data byte. The most likely thing is that you have the character length, stop bits etc. wrong, and this is why it doesn't work.
Also, display a character sent at 1200bps, on the same scope, which will then give a comparative calibration of the actual speeds being generated by the PIC.

Best Wishes
rudy



Joined: 27 Apr 2008
Posts: 167

View user's profile Send private message Send e-mail MSN Messenger

PostPosted: Sun May 17, 2009 3:53 pm     Reply with quote

Thanks Guest, and for sure I got the idea. Ttelmah, the data showed is the total information I have, I mean, I made this test with a lots of buttons of the remote, from all of them I got C8 in the beginning, it seems to be the synchronization they use.

I took a look at the routine I did, and I am quite so sure that I know where is the problem that sometimes it works sometimes it not. I think that if I do something like I did in one routine build in the past used to sync RF signal will do the job. When I found 0xC8 I do one step, then wait for other character that I already know, and jump to another step. If the character sent is not what I expect, the code returns to initial point.

Regards.

Manoel.
rudy



Joined: 27 Apr 2008
Posts: 167

View user's profile Send private message Send e-mail MSN Messenger

PostPosted: Mon May 25, 2009 1:15 pm     Reply with quote

I did a routine for reading the pulses, 8 bits, in 4 bytes using for command. In the beginning, I just read the signal emitted by the remote, and then stored the values in EEPROM, just to check what I looking for. The major problem, I think, is that this remote don’t send nothing to synchronize the pulses. I start to think that I will have to use CCP to do something with the signal, for example, how many counts of TIMER1 while the pin is hi or something like that.

I am using a 16f628, and its become to be a little bit busy, while doing PWM at RB3 pin and a RTCC interrupt for two 7 segments displays, may be, the best way is using a bigger processor, with two CCP modules, one to generate PWM and another one just to check IR signal.

The routine I did stay 400us in each bit, the total length of the eight bits sent by remote is 12,8ms .

Really need help.

Regards;

Manoel.
rudy



Joined: 27 Apr 2008
Posts: 167

View user's profile Send private message Send e-mail MSN Messenger

PostPosted: Sun May 31, 2009 2:56 am     Reply with quote

Hum,
Based on your tip I made a routine that’s working great, the only problem is that when I turn on the light, for example, the routine detects and do something that it should not do. How will be the best way to filter this erroneous reading?
Code:
void receive_ir()
{
int i=0, byte_ir=0;
lock_ir=1;
for (i=0; i<8; i++)
{
if(!i)delay_us(711);
else delay_us(1580);
shift_right(&byte_ir,1,input(pin_b0));
}
byte_ir=~byte_ir;
transfer_0=byte_ir;
aux_0++;
if(aux_0==0x01)
{
verify_channel();
ds2=transfer_0;
trans_channel=1;
ds1=12;
}
if(aux_0==0x02)
{
verify_channel();
ds1=ds2;
ds2=transfer_0;
trans_channel=0;
aux_0=0;
}
byte_ir=0;
unlock_ir=1;
}

Another thing is that, according my scope, the rising time shall be 1520us and the falling time is 1720us.
I’m trying to make samples inside the bit, just to be sure that there is a rising or falling edge, what do you think?

Regards.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
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