Forum: GNU Radio Re: Trellis in generic_mod_demod

Posted by Achilleas Anastasopoulos (Guest)
on 2013-03-01 19:19
(Received via mailing list)
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
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.