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
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 A.:
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 S.:
On 9/16/2010 2:41 AM, Tobias S. wrote:
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
that’s exactly what I thought abaout as well. Because the part I
problem of burst errors.
Am 10.09.2010 20:47, schrieb Achilleas A.:
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–