Alex, 1: U can try adjusting the synchronization loops bandwidth (Phase/Timing etc) see PFB_Timing documentation 2: Try reducing the receiver gain (for a constant tx-amplitude/gain) or reduce transmission amplitude/gain (for constant rx gain)
-Adeel On Sat, Mar 2, 2013 at 10:21 AM, Alex Zhang <cingular.a...@gmail.com> wrote: > I think you may rarely get the correct packet with pktno = 0, in > continuous mode, as my guess. Your received correct packet starts from > pktno = 1. > Could you also try the discontinuous mode for the BPSK communications? > > My question is actually a problem that how to implement a more reliable > BPSK mod/demod in burst mode. The current bpsk example in GNURadio does not > work well in burst mode. > > > On Fri, Mar 1, 2013 at 11:12 PM, Manu T S <manu.t.s...@gmail.com> wrote: > >> Alex, >> >> If it was about loosing sync, we would mostly loose the first packet even >> if we are sending in continuous mode. I personally face no such issues. >> >> >> On Sat, Mar 2, 2013 at 3:25 AM, Alex Zhang <cingular.a...@gmail.com>wrote: >> >>> Seems no one can shed a light on this topic? >>> >>> >>> On Thu, Feb 28, 2013 at 10:25 PM, Alex Zhang <cingular.a...@gmail.com>wrote: >>> >>>> Hello, >>>> >>>> In the current gr-digital/narrowband, I am using the benchmark_tx.py >>>> and rx.py to test the bpsk communications. >>>> It is found that the packet loss rate is very high (70% loss) in >>>> discontinuous mode where every 5 packets are in a burst. But in continuous >>>> mode, the paket loss rate is less than 10% for the same point to point >>>> link. >>>> >>>> I captured the waveform data. From the observed result, it seems that >>>> for each burst (5 packet), the bpsk receiver needs to re-do the >>>> frequency/time sync. This will directly causes that the first packet of >>>> each burst will definitely be crashed. Also, some burst can not be >>>> demodulated correctly at all. For the same reason, even in the continuous >>>> mode, the very first packet is also crashed at the receiver. >>>> >>>> I have tried to add very long preamble for each packet to ensure the >>>> data part of the packet can be received in well sync status. But the result >>>> is not very good. >>>> >>>> Before I get further investigation on the solutions, just wondering if >>>> any ideas or existing work within this community. >>>> >>>> -- >>>> >>>> Alex, >>>> *Dreams can come true – just believe.* >>>> >>> >>> >>> >>> -- >>> >>> Alex, >>> *Dreams can come true – just believe.* >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> -- >> Manu T S >> > > > > -- > > Alex, > *Dreams can come true – just believe.* > > _______________________________________________ > 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