Re: [Discuss-gnuradio] Trellis in generic_mod_demod

[Achilleas Anastasopoulos]

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
beforehand,
whereas now we can extract this info from the header.

It would also require someone to code it        :-)

Achilleas