Yes, that is what I am thinking. And try to solve this problem for the non-differential bpsk. Can the known preamble can solve this problem? I am investigate this way.
On Sat, Mar 16, 2013 at 9:18 AM, Tom Rondeau <t...@trondeau.com> wrote: > On Fri, Mar 15, 2013 at 11:33 PM, Alex Zhang <cingular.a...@gmail.com> > wrote: > > Hi Sreeraj and Tom, > > > > For the discontinuous mode, by cutting the freq_bw to below half of the > > default value, I found that for differential_bpsk, the packet loss rate > can > > be improved(from 30% to 70%), but for non-differential bpsk, the > improvement > > is hard to see. Especially, for non-differential bpsk, I found that often > > the whole burst (5 packets) could lost. Maybe, it is due to the Phase > > rotation. I am still trying to investigate. > > Are you handling the phase ambiguity in the receiver somehow? The way > things lock, the phases for BPSK could off by 180 degrees, so all 1's > are 0's and all 0's are 1's. So when you lock with a burst, you have a > 50/50 chance of locking on the wrong phase and so all of your bits are > going to be wrong. You'd have to detect this and flip everything. > > Tom > > > > On Thu, Mar 7, 2013 at 11:08 AM, Sreeraj Rajendran < > srees4sr...@yahoo.co.in> > > wrote: > >> > >> Alex, > >> > >> That one is non data aided(no preamble) frequency syncronization. As Tom > >> mentioned FLL must be the slowest one in the three. > >> > >> Did you try adjusting loop bandwidth?. There is an example_fll example > in > >> gr-digial. Just try that one and check how many symbols/samples it > takes to > >> settle. > >> > >> Just go through the papers I mentioned and that idea is easy to > implement > >> to do coarse synchronization during fast burst transmissions. > >> > >> > >> --- > >> Regards > >> Sreeraj Rajendran > >> http://home.iitb.ac.in/~rsreeraj > >> > >> ________________________________ > >> From: Alex Zhang <cingular.a...@gmail.com> > >> To: Sreeraj Rajendran <srees4sr...@yahoo.co.in> > >> Sent: Thursday, 7 March 2013 10:24 PM > >> > >> Subject: Re: [Discuss-gnuradio] Very low packet loss rate for the > >> discontinuous BPSK communications- the analysis and looking for solution > >> > >> Dear Sreeraj, > >> > >> You mentioned the openloop synch algorithms. Are they refered to the > >> preamble based carrier recovery? > >> > >> Thanks > >> > >> > >> On Mon, Mar 4, 2013 at 8:03 AM, Sreeraj Rajendran > >> <srees4sr...@yahoo.co.in> wrote: > >> > >> Alex, > >> > >> If Adeel's solution is not meeting your burst transmission specs, you > can > >> try implementing some fast openloop synchro algorithms given in > [1],[2]. You > >> could look into some data aided schemes too, though I haven't tried > those > >> yet. > >> > >> > >> [1] Digital Communication Receivers, Heinrich Meyr, Section 8.2.2 > >> [2] Two Frequency Estimation Schemes Operating Independently of Timing > >> Information, Ferdinand Classen and Heinrich Meyr > >> > >> --- > >> Regards > >> Sreeraj Rajendran > >> http://home.iitb.ac.in/~rsreeraj > >> > >> ________________________________ > >> From: Adeel Anwar <adeela...@gmail.com> > >> To: Alex Zhang <cingular.a...@gmail.com> > >> Cc: discuss-gnuradio@gnu.org > >> Sent: Monday, 4 March 2013 5:51 PM > >> Subject: Re: [Discuss-gnuradio] Very low packet loss rate for the > >> discontinuous BPSK communications- the analysis and looking for solution > >> > >> 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 > >> > >> > >> > >> > >> > >> -- > >> > >> 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 > > > -- Alex, *Dreams can come true – just believe.*
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
