Re: [Discuss-gnuradio] Manchester/L encoding-decoding?

[Achilleas Anastasopoulos]

There IS a Gnu-Radio ready made block for Manchester encoding decoding.
Once you realize that this encoding is nothing but a finite automaton 
(finte state machine) followed by memoryless modulation, all components 
for encoding/decoding are there.
See gr-trellis.

Achilleas


-------------






> > I'm new to GNU Radio and would like encode and decode 
manchester...I looked
> > through the documentation for manchester or L encoding but did not 
see any
> > thing.   I was wondering if someone could point me in the right 
direction?

There  isn't a ready-made GNU Radio block for either encoding or
decoding Manchester-coded signals; you'll need to write your own.
This is done using C++ and is exemplified by the
gr-howto-write-a-block subdirectory in the tree.

Since you are new to GNU Radio, I highly recommend that you first
familiarize yourself with existing flowgraph concepts by studying the
examples provided, and achieve an understanding of overall GNU Radio
operation with existing blocks.  Then, study the C++ code for existing
blocks to see examples of how various DSP techniques are implemented
within.  While Manchester coding itself is a fairly simple algorithm,
the GNU Radio runtime environment will add a degree of complexity to
your implementation.

A common pitfall for beginning GNU Radio users is to dive right into
custom blocks, or worse, into GUI programming with custom blocks, and
struggle to learn five different things at once instead of one at a
time.  Save yourself some grief  :)

Things to keep in mind:

* If you're operating at passband using FSK, there *will* be a
time-varying frequency offset between your transmitter and receiver.
This will show up as a wandering DC level after FM demodulation and
you'll need to track this out before slicing to bits.

* Even at baseband, there will be timing differences between what your
transmitter and receiver consider one bit period.  Since
Manchester-coded signals are self-clocking, in an analog world this
would not be an issue.  In an SDR implementation, you'll need to
oversample and implement a digital PLL to keep the transitions
centered within the bit period.

Have fun...

-Johnathan