> What on earth are you talking about ?
>
> The data transmission is Asynchronous. No clock required. The data is
> sent
> at a fixed Baud rate. The Uart synchronizes at the frame level using
> START
> and STOP bits.

You had originally said this was a manchester encoded bit stream.  Such a
bit stream does not have start and stop bits.  There is no hardware module
on a PIC that will interpret native manchester data directly.  You finally
explained you weren't doing real manchester in a post after mine you are
replying to.

So, I think we finally understand what you are really doing.  You are
sending bytes over RS-232, except that the transmission medium is RF
instead of a wire.  Because of that, you need the average DC level to be
about 1/2 way between the 1 and 0 bit states so that the receiver AGC and
descriminator can be most effective.  Is this correct?  (If it is, you
could have saved a lot of trouble by saying so in the first place).

Assuming the above is correct, you then decided to use manchester encoding
on the 8 data bits because this is known to produce an equal number of 1s
and 0s over short intervals.  This is the part that doesn't make sense.
There are lots of ways to encode 4 bits into 8 so that there are always 4
0s and 4 1s.  I doubt the RF receiver will have a problem if the signal
averages to 1/2 over an 8 bit interval instead of a 2 bit interval.  Why
not just send the 4 bits in the low nibble and the complement of the bits
in the high nibble?  This makes both encoding and decoding trivial.  I
have done exactly this with RF communication, and it worked fine.

> Reread my orgininal question,

I've got things to do, and that's not one of them.

> it relates to finding a "faster" way of
> decoding
> the received data, the problem is not in decoding data. The current
> algorithm
> does this fine, I want to speed up the decode process to enable more
> idle time between
> each incoming byte to perform other processes.

As is often the case, the wrong question was asked in the first place or
the explanation was inconsistant.  You seem frustrated that someone didn't
just plunk down a solution for the question you asked.  It doesn't work
that way, get over it.  There were inconsistancies and things that didn't
make sense in your problem statement, which is why most people were trying
to drill down to what is really happening rather than giving the solution
to the wrong problem.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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