Re: [Discuss-gnuradio] Viterbi--OFDM

[Tobias Schmid]

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

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?

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