Lost packet problem

GNU Radio
1

I’m facing a problem, when the packet is lost in the channel.

I’ve tried to create my own program with multiple ACKs between
transmitter
and receiver (both of them works as transceiver) to retransmit the lost
packets. However i faced some problems:

  1. the CRC32 cannot recognize the error packets (missed packets, larger
    packets and smaller packets cannot be recognized).
  2. It seems that the (PN) access code cannot work probably. how can i
    know
    whether it works probably or not (its purpose is for synchronization,
    but
    how can i check it)?

The receiver will send LOST-ACK with the indexes of the lost packets
(which
identified by the CRC32, when there is error in the payload).

did any body tried to solve the lost packet problem before, if yes can
you
give me some tips?

Is it possible in GNU radio to use some lower complexity protocol than
tcp,
for the error packet correction?
what kind of build-in protocol ?

regards,

–
View this message in context:
http://old.nabble.com/Lost-packet-problem-tp27637608p27637608.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

On Thu, Feb 18, 2010 at 8:25 AM, abbasi9999 [email protected]
wrote:

whether it works probably or not (its purpose is for synchronization, but
how can i check it)?

Which modulation are you using? Are you using the
digita/benchmark_*.py files or is this OFDM. I’m not quite getting
what you mean when you’re talking about the PN code (which makes it
sound like the OFDM code we have in the examples).

The receiver will send LOST-ACK with the indexes of the lost packets (which
identified by the CRC32, when there is error in the payload).

Sorry, I’m really not understanding what you’re doing. Are you
checking the CRC and sending an ACK if the CRC doesn’t check out? If
so, that requires that you get enough good bits of the packet through
to first detect that it’s a packet and then be able to parse it. If
you miss the header and length fields, you won’t be able to see the
CRC.

This is usually solved, like in TCP, with a sequence number. You can
tell if you missed a packet because the sequence numbers from two
consecutive packets received will not match up. This way, the receiver
can completely drop a packet and still know it after then next packet
arrives.

Also, in any of the digital mods and OFDM examples we’ve created, we
don’t use any channel coding, so you’re definitely going to lose
packets. A single bit error can cause the loss of the entire packet.
Secondly, if you’re using OFDM, there are still some problems that
Matt and I have identified but have not had a chance to work out. The
problem(s) will cause the receiver to misfire on the preamble and miss
the entire packet.

Tom

3

Thanks a lot for your reply,
sorry for my bad english…

Tom R. wrote:

Which modulation are you using? Are you using the
digita/benchmark_*.py files or is this OFDM. I’m not quite getting
what you mean when you’re talking about the PN code (which makes it
sound like the OFDM code we have in the examples).

I’m using dbpsk, through a file based on tunnel.py.
As far as i know, the receiver is using gr_correlate_access_code_bb to
slide
the given access code (usually an M-sequence) across the demodulated
bits,
and produces two bits of output for each input bit. This is done for
synchronization.

Tom R. wrote:

Sorry, I’m really not understanding what you’re doing. Are you
checking the CRC and sending an ACK if the CRC doesn’t check out? If
so, that requires that you get enough good bits of the packet through
to first detect that it’s a packet and then be able to parse it. If
you miss the header and length fields, you won’t be able to see the
CRC.

i check the CRC, if it returns correct i send ACK, if it is not correct
i
send LOST-ACK,

Tom R. wrote:

This is usually solved, like in TCP, with a sequence number. You can
tell if you missed a packet because the sequence numbers from two
consecutive packets received will not match up. This way, the receiver
can completely drop a packet and still know it after then next packet
arrives.

I understand what are you saying. but the point is there any scheme
(already
implemented in GNURADIO) which solve this problem. or i have to do it
manually?

regards,

–
View this message in context:
http://old.nabble.com/Lost-packet-problem-tp27637608p27649992.html
Sent from the GnuRadio mailing list archive at Nabble.com.

4

I think the problem was the high bit rate.
my bit rate was 100K when i decrease it to 10K the lost packets can be
recovered safely.
I think that there is overflowing in the USRP, which cause the missing
of
access code. therefore i miss the packets.
I’ll try what you have said in the first post.

thanks for your help

Tom R. wrote:

the given access code (usually an M-sequence) across the demodulated

i check the CRC, if it returns correct i send ACK, if it is not correct i

manually?

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–
View this message in context:
http://old.nabble.com/Lost-packet-problem-tp27637608p27672856.html
Sent from the GnuRadio mailing list archive at Nabble.com.

5

On Fri, Feb 19, 2010 at 12:50 AM, abbasi9999 [email protected]
wrote:

what you mean when you’re talking about the PN code (which makes it
sound like the OFDM code we have in the examples).

I’m using dbpsk, through a file based on tunnel.py.
As far as i know, the receiver is using gr_correlate_access_code_bb to slide
the given access code (usually an M-sequence) across the demodulated bits,
and produces two bits of output for each input bit. This is done for
synchronization.

The access code correlator is just there to determine when the packet
start happens by looking for the preamble access code. I’m not sure if
this is what you mean by synchronization. I just always think of
synchronization in the symbol domian; that is, it does the frequency,
phase, and timing synchronization to be able to slice the symbols into
bits.

i check the CRC, if it returns correct i send ACK, if it is not correct i
send LOST-ACK,

Yeah, ok. But like I said, I really don’t think this is a very good
way to determine when a packet is missed since this will only work
when at least most of the packet has been received. If a packet is
corrupted in the header or access code such that it is completely
overlooked by the demodulator, you’ll never know it with just an
ACK/NACK scheme.

implemented in GNURADIO) which solve this problem. or i have to do it
manually?

regards,

There has been some work done on MAC layer implementation in GNU
Radio, but there is nothing in the main repo that will do what you
want.

Tom