Why do radio link care about the average DC of the encoded data ? Does
this apply to all forms of radio modulation ?

Thanks,

Tal

> -----Original Message-----
> From: pic microcontroller discussion list
> [mailto:PICLIST@MITVMA.MIT.EDU] On Behalf Of Olin Lathrop
> Sent: Friday, September 12, 2003 4:17 AM
> 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#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body