[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Lost packet problem
From: |
abbasi9999 |
Subject: |
Re: [Discuss-gnuradio] Lost packet problem |
Date: |
Thu, 18 Feb 2010 21:50:57 -0800 (PST) |
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.
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,
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,
--
View this message in context:
http://old.nabble.com/Lost-packet-problem-tp27637608p27649992.html
Sent from the GnuRadio mailing list archive at Nabble.com.