Forum: GNU Radio Re: Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking fo

Hello,

I am getting the same problem you described here i.e very high packet 
loss
in discontinuous mode (first and last packet received with ok=False).

Could you please elaborate on how to adjust the synchronisation loops
bandwidth?
I have tried adjusting the --timing-bw and --phase-bw parameters on the
benchmark-rx example, but I don't know if that is what you were talking
about.


*From:* Adeel Anwar <address@hidden>

I don't believe this problem can be solved by adjusting the loop 
bandwidth.
Applying faster tracking algorithm may solve this problem, but I think 
it
takes long time to develop for a new guy.


On Wed, Mar 6, 2013 at 3:44 AM, Jawad Seddar <jawad.seddar@gmail.com> 
wrote:

>
>> 1: U can try adjusting the synchronization loops bandwidth (Phase/Timing
>>
>>
>>
>> discontinuous mode where every 5 packets are in a burst. But in continuous
>> I have tried  to add very long preamble for each packet to ensure the
>>
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


--

Alex,
*Dreams can come true  just believe.*

Ok, well thank you for the fast answer.
I'll keep looking around but this is a serious issue for me, it means I
can't use my two USRP to send and receive any useful traffic.


2013/3/6 Alex Zhang <cingular.alex@gmail.com>

>>I don't believe this problem can be solved by adjusting the loop bandwidth.

Acquisition time is roughly inversely proportional to loop_bw and error 
variance is proportional to loop_bw. So there is always a tradeoff 
between acquisition time and tracking performance. You should try 
adjusting loop_bw 
(http://www.trondeau.com/blog/2011/8/13/control-loo...).


>>Applying faster tracking algorithm may solve this problem, but I think it takes 
long time to develop for a new guy.

If you have a good understanding of the algorithm, its really easy to 
prototype the alogorithm in GRC or by using gnuradio python-block coding 
support. "gr_modtool" is always there to make block coding easier.

-Sreeraj

On Wed, Mar 6, 2013 at 6:42 AM, Sreeraj Rajendran
<srees4srees@yahoo.co.in> wrote:
>>> takes long time to develop for a new guy.
>
> If you have a good understanding of the algorithm, its really easy to
> prototype the alogorithm in GRC or  by using gnuradio python-block coding
> support. "gr_modtool" is always there to make block coding easier.
>
> -Sreeraj


Also hand tune to make sure the frequencies of the transmitter and
receiver are as close as you can get them. The slowest loop in this
chain is the frequency lock loop, so overcome that by hand and see
what happens.

Tom

Thanks you all.
I will try to adjust th loop_bw in the fll firstly to see what happened.

And I am not understanding the function advance_loop(error) well:

void
gri_control_loop::advance_loop(float error)
{
  d_freq = d_freq + d_beta * error;
  d_phase = d_phase + d_freq + d_alpha * error;
}

I am not clear why d_freq and d_phase are updated in this way. Is the
d_freq the frequency offset estimate every step?

According to the
http://www.trondeau.com/blog/2011/8/13/control-loo... , i
have a rough picture on this, but still confused why d_freq is only
dependent on d_beta.

The other question is: Is it possible to turn off the loop when there is 
no
input signal (only noise) and turn on the loop when signal is detected?
If possible, how to update hte d_freq and d_phase?




On Wed, Mar 6, 2013 at 7:08 AM, Tom Rondeau <tom@trondeau.com> wrote:

> loop_bw
> > -Sreeraj
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



--

Alex,
*Dreams can come true  just believe.*

In my case I am inclined to think that the problem might come from the
emitter, here is why :

First, I am mostly getting errors on the last packet of the burst rather
than the first (95% of the time).

I have tweaked the benchmark_tx file a bit so that I could adjust the
length of the burst and the sleeping time between two bursts : when 
using
large bursts, the receiver receives all packets as if it were a 
continuous
transmission and therefore no errors occur on the last packet of the 
burst.

So the transmitter stops adding packets to the queue but still is 
sending
packets inside the queue through the antenna.

It seems to me that this could actually be a weird effect from the
transmitter that cuts power (or something along those lines) before the
last packet is completely transmitted.

Thank you for the tips, and if you want me to create my own topic for 
this
issue, just say the word.

Besides the tips mentioned in the previous mails, I am wondering if the
carrier recovery can performed by adding proper preamble fore the burst
mode bpsk communication.
Several books mentioned that but did not provide more details;

for example:

Radio System Design for Telecommunication  By Roger L. Freeman
page 417.

Satellite Communication
 By Dharma Raj Cheruku
page 138

Especially the latter book, a preamble with 352 bits are used as carrier
recovery, which is much faster than the my current FLL.
I am wondering if any guy who have similar implementation.


On Wed, Mar 6, 2013 at 7:08 AM, Tom Rondeau <tom@trondeau.com> wrote:

> loop_bw
> > -Sreeraj
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



--

Alex,
*Dreams can come true  just believe.*