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
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
