Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution

[Nathan West]

On Sat, Mar 16, 2013 at 2:19 PM, Alex Zhang <address@hidden> wrote:
> 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.

I think that's what the "access code" in the packet encoder is for.
But that's actually something I've been looking to use for my
application, so I'm also interested in someone more experienced
chiming in with a nay or yay. If you have any luck with access codes
I'd be interested in hearing it.

>
>
> On Sat, Mar 16, 2013 at 9:18 AM, Tom Rondeau <address@hidden> wrote:
>>
>> On Fri, Mar 15, 2013 at 11:33 PM, Alex Zhang <address@hidden>
>> 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
>> > <address@hidden>
>> > 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 <address@hidden>
>> >> To: Sreeraj Rajendran <address@hidden>
>> >> 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
>> >> <address@hidden> 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 <address@hidden>
>> >> To: Alex Zhang <address@hidden>
>> >> Cc: address@hidden
>> >> 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 <address@hidden>
>> >> 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 <address@hidden>
>> >> 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 <address@hidden>
>> >> wrote:
>> >>
>> >> Seems no one can shed a light on this topic?
>> >>
>> >>
>> >> On Thu, Feb 28, 2013 at 10:25 PM, Alex Zhang <address@hidden>
>> >> 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
>> >> address@hidden
>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Manu T S
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Alex,
>> >> Dreams can come true – just believe.
>> >>
>> >> _______________________________________________
>> >> Discuss-gnuradio mailing list
>> >> address@hidden
>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Discuss-gnuradio mailing list
>> >> address@hidden
>> >> 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
>> > address@hidden
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>
>
>
>
> --
>
> Alex,
> Dreams can come true – just believe.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>