Re: Trellis in generic_mod_demod

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
    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 :slight_smile: