[Top][All Lists]

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

Re: [Discuss-gnuradio] Viterbi--OFDM

From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] Viterbi--OFDM
Date: Thu, 16 Sep 2010 13:17:26 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100825 Thunderbird/3.1.3

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?


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.


Thanks for your help


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

So thanks for your quick help, I'll try this out, when I'm back a
university on monday.


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
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).


Discuss-gnuradio mailing list

Discuss-gnuradio mailing list


reply via email to

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