Hi Piotr, I was facing the same issue, and the issue is caused by Schmidl-Cox sometimes detecting the packet boundaries a little late. This cannot really be helped, as channel noise may force the correlator to detect a peak/plateau later than it should. I have found a couple of ways to overcome this problem:
a) After every packet, send a stream of maybe 10 "0"s. This ensures that even if one packet is detected a symbol late, the subsequent packet has enough room to be detected. The way to implement this is by having another tagged stream of "0"s, the tag being packet_length. At the transmitter side, pass the symbols from the TX block into one input of a tagged-stream-mux, and the tagged stream of "0"s into the other input of the tagged stream mux. b) In the header-payload demux, 'consume' a few symbols lesser than you need to. That way, you won't accidentally eat up the peak trigger from the next packet. As was discussed in a different thread, this is an unclean solution -- a hack! Hope that helps, and happy hacking! Best regards, Aditya On Wed, Jan 29, 2014 at 8:24 AM, Piotr Potocki <piotr.l.poto...@gmail.com>wrote: > Hi all, > > I am trying to create OFDM transmission on USRP 2. I am using two URSP's > (XVCR 2450) which are close to each other. To do that I am using Gnu radio > 3.7.2 with slightly modify OFDM_benchmark_receiver (see img 1) and > transmitter. > But the problem is that I am still receiving packet lost around 1.73 - 2.2 > %. Even when I am using direct cable between USRP's the packet lost is the > same (around 1.73 - 2.0 % newer below). I don't think it can be frequency > offset (I checked exactly what offset i have and corrected it manually). > 1) So my first question is how to improve packet lost (my guess is the > timing synchronization) and is this packet lost a normal thing in this > scenario (without FEC) ? > 2) Second question is what methods of timing synchronization (auto > correlation function, ?) are used in this OFDM example and where to find > them ? > > My specs of system: > FFT length = 64 > Sample rate = 2M > Packet length = 40 ( i tried with different packet length and 40 gave the > best results) > Modulation = BPSK > Carrier frequency = 2.4 Ghz > Occupied carriers = 52 > > Best regards, > Piotr Potocki > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
