[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Trellis in generic_mod_demod

From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] Trellis in generic_mod_demod
Date: Fri, 1 Mar 2013 13:18:15 -0500

Incidentally this brings forward a drawback (in my opinion) in the
design of the physical
layers in gnuradio, ie, that the physical layer is designed
essentially with continuous transmission in mind.

For instance, the
fll_band_edge ---> pfb_clock_sync ---> (constellation_receiver,0) --->
chain has no concept of a "packet" or "block" of data.
This is done afterwards when we try to find a header in the hard
decisions using the correlator,
and then read the packet length and extract the payload.

I believe a  redesigned scheme would be something like:

1) correlator_searching_for _training_sequence in the actual receiver samples
which will also implement initial timing/coarse freq sync
2) followed by a standard demod chain as above, ie,
 (constellation_receiver,0) ---> soft_decision_decoder

In understand that this would require knowledge of the packet length
whereas now we can extract this info from the header.

It would also require someone to code it        :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]