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: Ben Reynwar
Subject: Re: [Discuss-gnuradio] Trellis in generic_mod_demod
Date: Fri, 1 Mar 2013 12:33:30 -0700

Manu,

At the moment when you feed into your viterbi decoder you still have
phase ambiguity i.e. you don't know if the constellation is orientated
correctly.  I imagine this would place a constraint on the code you
could use.

If you go with Achilleas' suggestion then the differential decoding
would already have happened so you wouldn't need to worry about it.

Ben

On Fri, Mar 1, 2013 at 11:05 AM, Achilleas Anastasopoulos
<address@hidden> wrote:
> 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]