Re: [Discuss-gnuradio] Lost packet problem

[Tom Rondeau]

On Fri, Feb 19, 2010 at 12:50 AM, abbasi9999 <address@hidden> wrote:
>
> Thanks a lot for your reply,
> sorry for my bad english...
>
>
> Tom Rondeau 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.

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.

> Tom Rondeau 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,

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.

> Tom Rondeau 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,

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