There is no logic at the moment to make the trellis encoder and decoder sync their blocks with the packets. I would have thought that if you don't specify the starting and ending states, and the blocks are reasonably long, then it would still work adequately but I could be wrong.
If you want to sync the blocks with the packets then you could add a stream tag to the start of each packet, and detect that with the encoder and decoder. Ben On Thu, Feb 28, 2013 at 9:47 PM, Manu T S <manu.t.s...@gmail.com> wrote: > I want to use convolution code to transmit packet over USRP. So I ended up > modifying the generic_mod_demod in digital. > > The original flow graph was > > Tx > packed_to_unpacked(bits_per_symbol) ---> gray_encoder ---> > differential_encoder ---> chunks_to_symbol(constellation) > ---> rrc_filter ---> USRP > > Rx > USRP ---> fll_band_edge ---> pfb_clock_sync ---> (constellation_receiver, 0) > ---> demod_pkts > > Now I have modified it to the following. > > Tx > packed_to_unpacked(bits_per_trellis_input) ---> trellis_encoder(fsm) ---> > chunnks_to_symbol(constellatin) ---> rrc_filter ---> USRP > > Rx > USRP ---> fll_band_edge ---> pfb_clock_sync ---> (constelllation_receiver, > 4)(symbol) ---> viterbi_combined ---> demod_pkts > > I find this structure ends up in more errors than before. ( almost all > errors ) > > 1. Does the packet size at the output of pkt.py has anything to do with the > block_length in viterbi_combined? > > 2. Will it make any difference if I specify the starting and ending states?? > > > -- > Manu T S > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
