Re: [Discuss-gnuradio] Lost packet problem

[abbasi9999]

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 Rondeau wrote:
> 
> 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
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> 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.