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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
