Olin,

Very simple. If you don't understand the question or don't have the
time or interest to ask further questions then why bother to reply ??

I am grateful to all those who replied.=20

If you are involved in commercial enterprise, how do you deal with
customers (in the real world) who invariably do not supply all relevant=20
information from the beginning ?=20

As much as I appreciate your desire to help develop my communication
skills, I would appreciate it even more if you took the time to ask
if you needed more information in order to offer constructive advice.

Some people are more intuative than others (as shown by others on the =
list
who did understand the context of my question from the beginning).

As for frustration, my only frustration (mild), is those who have time =
to
find a point of argument but not the time to find out the real issue
and help.

Kind Regards

David Huisman


-----Original Message-----
From: Olin Lathrop [mailto:olin_piclist@EMBEDINC.COM]
Sent: Friday, 12 September 2003 9:17 PM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]:Manchester Lookup table


> 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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads