Scott Dattalo wrote:

>> This is very similar to Microchip's KEELOQ PWM protocol. Your preamble
>> is a bit different, and I don't think they take different delays for
>> hi>lo and lo>hi transitions into account like you do. (They use duty
>> cycles of 1/3 and 2/3 and three samples per bit for decoding: one in
>> the part that should always be hi, one in the variable part, and one in
>> the part that should always be lo.) But in essence, it's the same
>> thing. I'm also currently researching what protocol to use over a radio
>> link, and just today thought that I'd found it with this PWM scheme.
> 
> When designing an RF link based on PWM, be sure to compare it against
> Manchester encoding for the following cases:
> 
>    -- varying pulse timing
>    -- multiple transmitters
>    -- distance between transmitter and receiver
> 
> If PWM works for you then use it. However, there are many reasons people
> have been using Manchester encoding for decades!

I'm sure there are :)

One is that Manchester guarantees an average; with PWM, it may be anything
between the two limits (all 0, all 1). Another is, as you say, that PWM
requires more bandwidth, which may affect maximum distance. I didn't think
the latter was very noticeable, but maybe it is.


> You may wonder how Manchester encoding may be more robust against
> multiple transmitters or how it can allow the distance between the
> transmitter and receiver be increased. Well first, a Manchester encoded
> data stream has state information. For example, if you look at a
> Manchester stream there are narrow pulses and wide pulses. Only certain
> combinations of these pulses are allowed. So if interference damages a
> particular pulse then there's a significant probability that the
> Manchester state decoder will encounter an illegal state. 

Same for PWM. If you sample 3 times per bit, the first sample must be 1,
the second is the bit state, the third must be 0. Anything that's not 1x0
is noise. 

The difference is, again, that for this you need 3 samples per bit, with
Manchester you need (at least) 2 for something similar. But the noise
rejection of PWM doesn't seem to be worse.

> Second, the narrow pulses in a Manchester encoded stream are wider than
> the narrow pulses in a PWM encoded stream (assuming the two streams have
> the same bit time). This means that the frequency spectrum of the data
> stream has a greater proportion of its energy in the lower harmonics.
> This further means that the RF transmitter hardware has more time to
> transmit the narrow pulses. And finally, this means that the narrow
> Manchester pulses have a greater probability reaching there receiver
> than the narrow PWM pulses as the distance between the receiver and
> transmitter increases.

To me, it seems that this is the main difference.


>> The simpleness to synchronize to the bit rate is really convincing, as
>> is the fact that you have a good noise retention at the bit level by
>> very simple checks before even looking at the data.
> 
> I think the Manchester encoding is only more complicated if you don't
> understand it. 

This may well be true :)

> The synchronization and decoding of Manchester and PWM are comparable in
> code size. My Manchester receiver takes about 100 instructions to
> receive a 32 bit stream, although any given path through the receiver
> takes fewer than 50 cycles. 

Thanks for insisting... I'll definitely have a closer look at Manchester
decoding. I just liked the simpleness (in terms of firmware implementation)
of a guaranteed rising edge at the beginning of each bit time.


OTOH... Why would Microchip use this as basis for their KEELOQ products if
decoding Manchester is as easy as decoding PWM and results in better
performance?

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist