Michael Watterson wrote:
>>> no, Manchester encoding is a frequency shift x2. It doesn't change
>>> the bandwidth at all.
>>
>> Of course it does, you have to transmit twice as many transitions per
>> bit compared to an NRZ signal!
>
> You are confusing bandwidth and clock rate.
> Manchester encoded has double clock  rate minimum of un-encoded data,
> which has a minimum bandwidth from 0Hz to Data_Clock_Rate
> The Manchester encoding doubles the Data_Clock_Rate but the 0Hz is now
> Data_Clock_Rate, so bandwidth is the same.

The highest frequency signal a NRZ system can generate is when each bit
differs from the previous, 101010101...  That results in a square wave at a
frequency of half the bit rate.  The highest frequency signal a manchester
system can generate is when the stream of bits is all the same.  That
results in a square wave with a frequency of the bit rate.

Therefore, the upper frequency the channel must be capable of (worst case
must be assumed) has to be twice as high for manchester as compared to NRZ
at the same bit rate.  Note that in both cases these worst case signals are
square waves, so you can't just use the frequency as the bandwidth
requirement.  However both manchester and NRZ are the same in this regard
(50% duty cycle square wave), so the 2:1 comparison is still valid.

You could say that manchester does not include low frequencies whereas NRZ
can go down to 0, and that therefore the band width requirement of the
channel is the same, as apposed to the upper frequency requirement.
However, unless you have the ability to do some pretty fancy filtering and
modulation, the lack of low frequencies doesn't do any good in a practical
sense.

If a simple on/off keying radio module is rated for 10Kbits/second, then you
can transfer 5Kbits/second over it with manchester and theoretically
transfer 10Kbits/second over it with NRZ.  Of course you have to provide for
some means of synchronizing the ends of the NRZ stream, but with accurate
clocks on both ends this extra embedded clock information need only use up a
small fraction of the bandwidth.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist