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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
