Re: [Discuss-gnuradio] Trellis in generic_mod_demod

[Ben Reynwar]

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 <address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>