Re: [Discuss-gnuradio] Viterbi--OFDM

[Achilleas Anastasopoulos]

On 9/16/2010 2:41 AM, Tobias Schmid wrote:
> Hello Achilleas,
>
> I tried out your idea and added an interleaver. While doing this, I got
> the error that really caused my trouble. I splited the coded
> sequenceinto 2 packets. And as I changed this, I worked fine, even
> better after adding an interleaver.
> So thanks for your idea.
>
> But that brought up another question. Although my working with gnu
> radio, I'm not really sure if I understud the output of the
> viterbi_combined right.
>
> The input in case is one bit per byte. I'm using the pack_to_unpack
> block. For trellis coding I'm using the trellis_encoder_bs. With the
> awgn1o2_4.fsm fsm. So what exactly is me output. Is it a short with two
> valid bits each?

YES

> So if I use a unpack_to_pack block afterwards, I would get as much
> shorts as the number of chars before entering the pack_to_unpack block.
> Is that right?

You confused me here...
Let's say you have N input (uncoded) bits.
These appear at the input of the trellis_encoder as N bytes (each with 1 
bit info).
The encoder outputs N shorts (each with 2 bits info)
If you want to pack those the most economic way then you can fit
4 output symbols in a single byte.
I think the best way to do this is to use "trellis_encoder_bb"
and then "unpack_to_pack" to pack every 4 symbols into a byte.
Then you can use the block of N/4 bytes as your payload for the OFDM 
modulator.

Does that make sense?

> So after packing the fsmsymbols into shorts, I catch them with am
> message sink to get the whole coded sequence and hand it over as a
> payload for the ofdm_mod.
> So me next question is, while catching the items in that queue, do I
> have to count the incoming bytes or the number of incoming samples?

not sure i understand this question...there are no "samples" in the 
transmission side of things and before the OFDM modulation. Maybe i 
missed something.

Achilleas

> Thanks for your help
>
> Tobias
>
>
>
> Am 11.09.2010 20:18, schrieb Tobias Schmid:
>
> > Hello Achilleas,
> >
> > that's exactly what I thought abaout as well. Because the part I
> > discribed as channel in my last mail is a wireless transmission using
> > usrp2.
> > Not using channel coding, I have packet error rates of 1 to 2 % using
> > bpsk subcarrier constellation and abaout 18 % using qpsk. And if I
> > evaluate the packet error rates not as a mean value, but in smaller
> > periodes, there are periodes where the viterbi correcty almost every
> > error, but there are also periodes in which there are just erroneus
> > packets produced.
> >
> > So as you said, I thought about using an interveaver to reduce the
> > problem of burst errors.
> > If that doesn't work, it's no bigger problem, because I've implemented
> > a selective repeat arq as well, so using this protocol, I'm getting
> > good or even better performances, due to the reduced amount of data to
> > transmit.
> >
> > So thanks for your quick help, I'll try this out, when I'm back a
> > university on monday.
> >
> > Tobias
> >
> > Am 10.09.2010 20:47, schrieb Achilleas Anastasopoulos:
> > > My guess is that the inner channel (ie the combination of OFDM
> > > modulator/channel/OFDM demodulator) is producing big bursts of errors.
> > > Essentially either the packet is correctly received or completely
> > > erroneously received.
> > > In that case the outer Convolutional code cannot do much; on the
> > > contrary it deteriorates performance because of the SNR loss due to
> > > coding.
> > > One way to verify this hypothesis is to measure the error statistics
> > > of the inner channel.
> > >
> > > The way to improve is to interleave before the inner channel with
> > > sufficient depth (multiple OFDM symbols).
> > >
> > > Achilleas
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--