discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Trellis in generic_mod_demod


From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] Trellis in generic_mod_demod
Date: Fri, 1 Mar 2013 13:05:04 -0500

Manu,

Start with a simpler version of your design, ie
1) At the Tx the convolutional code is BEFORE the gray_encoder
2) At the Rx the Viterbi decoder operates with hard decisions (there
is an option for that in the viterbi combined) and is AFTER the block
that synchronizes with the encoded demodumated packet and extracts its
payload.

In other words, add coding/decoding to the payload of the original
uncoded system.

Achilleas

=============================================
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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]