Hi Brent,

Here is the code that I came up with (it should go into your application
pretty easily):

//  Variables
int DataIn; // Data Input

char DataInCount = 0; // Number of Characters to Read In

char DataReady = 0; // Data to be Read in

int SaveRTC; // Saved RTC/TMR0 for Interrupt Pins

int CurrentRTC;

char Message[4] = "-> "; // Header of Incoming Bits


// Interrupt Handler

void interrupt tmr0_int(void) // TMR0 Interrupt Handler

{

    if (T0IF) {

        T0IF = 0; // Reset Interrupt Flag

        RTC++; // Increment the Clock

        CurrentRTC = (RTC & 0x0FF) - ((SaveRTC >> 8) & 0x0FF);

        if (CurrentRTC < 0) // Calculate Time Since Save

            CurrentRTC = 0 - CurrentRTC;

        if ((DataInCount != 0) && (CurrentRTC > 9))

        DataInCount = 0; // Reset and Wait for the Next Character

    } // endif

    if (INTF) { // RB0/INT Pin Interrupt

        if (DataReady) // Waiting to Process Previous Packet

            ; // Ignore

        else if (DataInCount == 0) { // New Message Coming In

            DataInCount = 12; // 12 Bits to Come in

            SaveRTC = ((RTC & 0x0FF) << 8) + TMR0; // Save the Current Time

        } else { // Bit to Process

            CurrentRTC = ((RTC & 0x0FF) << 8) + TMR0; // Get the Current
Time

            if ((SaveRTC = CurrentRTC - SaveRTC) < 0)

                SaveRTC = 0 - SaveRTC;

            if ((SaveRTC > 250) && (SaveRTC < 350)) {

                DataIn = (DataIn << 1) + 1; // "1" Received

                if (--DataInCount == 0)

                    DataReady = 1;

            } else if ((SaveRTC > 390) && (SaveRTC < 490)) {

                DataIn = DataIn << 1; // "0" Received

                if (--DataInCount == 0)

                    DataReady = 1;

            } else // Invalid - Delete

                DataInCount = 0;

            SaveRTC = CurrentRTC; // Save the Execution Time

        } // endif

        INTF = 0; // Reset Interrupt

    } // endif

} // End Interrupt Handler



// Mainline

void main(void) // Template Mainline

{

int i;

    OPTION = 0x0D1; // Assign Prescaler to TMR0

// Prescaler is /4

    TMR0 = 0; // Reset the Timer for Start

    T0IE = 1; // Enable Timer Interrupts

    INTEDG = 1; // Interrupt on Rising Edge of RB0/IR TX'r

    INTE = 1; // Enable RBO/INT Pin Interrupts

    GIE = 1; // Enable Interrupts

    while (1 == 1) { // Loop forever

        if (DataReady) {

//  Put in Packet output/handler routine

        } // endif

    } // endwhile

} // End of Mainline



Let me know if you have any questions,



myke

----- Original Message -----
From: "Brent Brown" <brent.brown@clear.net.nz>
To: <myke@PASSPORT.CA>
Sent: Monday, September 02, 2002 5:00 PM
Subject: Re: [PIC]: RF remote control decoding


> Hi Myke,
>
> Thanks, it would be cool to look at, off-list if you prefer. There must be
some
> similarities between RF and IR decoding and I hadn't though of looking at
> that. I am also using Hi-Tech PIC C, running my chip at 4MHz, and TMR0 is
> free. The part I most need ideas about is "filtering" in the time domain
to
> allow some tolerance of noise.
>
> On 1 Sep 2002 at 21:40, myke predko wrote:
>
> > Hi Brent,
> >
> > I have some IR Remote control code that I could share with you that
> > would probably do the job.
> >
> > The code is written in PICC Lite ("C"), runs at 4 MHz with TMR0
> > overflowing every 1,024 usecs.  The I/R receiver input is passed to
> > RB0/INT and on every rising edge, the TMR0 value is saved to determine
> > the length of the High/Low signal that just passed.
> >
> > myke
> > ----- Original Message -----
> > From: "Brent Brown" <brent.brown@CLEAR.NET.NZ>
> > To: <PICLIST@MITVMA.MIT.EDU>
> > Sent: Sunday, September 01, 2002 9:14 PM
> > Subject: [PIC]: RF remote control decoding
> >
> >
> > > Hi all,
> > >
> > > I'm interested in talking to anyone who has done decoding of data from
> > > an RF 2 button remote control. I'll skip most of the details and get
> > > down to the problem.
> > >
> > > The data is sent as a combination of short and long pulses. I
> > > receive the pulses OK, and have developed some code that
> > > discriminates between short and long pulses, (approx 500us &
> > > 1500us), and succesfully recognises each button press. It works
> > > well, but not well enough. There is zero tolerance for pulses that are
> > > "broken up" during less than perfect reception. This results in a
> > > relatively poor range of operation. My assumption is that there is
> > > still enough of the pulse getting through that it should still be
> > > possible to identify short and long data pulses.
> > >
> > > I'm using a PIC16F877 with the data from the receiver module coming
> > > into RB0/INT. Presently I interrupt on a rising edge, start a timer,
> > > switch to falling edge and on that interrupt read the timer value
> > > which is the pulse width.
> > >
> > > I have been thinking of all kinds of averaging and integrating
> > > schemes but my brain hurts and I haven't found a workable solution
> > > yet. I would appreciate any helpful suggestions, especially from
> > > anyone that has already been there and done that.
> > >
> > > Thanks, Brent.
> > >
> > > --
> > > Brent Brown, Electronic Design Solutions
> > > 16 English Street, Hamilton, New Zealand
> > > Ph/fax: +64 7 849 0069
> > > Mobile/txt: 025 334 069
> > > eMail:  brent.brown@clear.net.nz
> > >
> > > --
> > > http://www.piclist.com hint: The PICList is archived three different
> > > ways.  See http://www.piclist.com/#archives for details.
> > >
> > >
> > >
> > >
> >
> > --
> > http://www.piclist.com hint: The PICList is archived three different
> > ways.  See http://www.piclist.com/#archives for details.
> >
> >
> >
>
>
>
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body