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

GNU Radio
1

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 A. address@hidden

2

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 S. [email protected]
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
[email protected]
Discuss-gnuradio Info Page

–

Alex,
Dreams can come true just believe.

3

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 Z. [email protected]

4

On Wed, Mar 6, 2013 at 6:42 AM, Sreeraj Rajendran
[email protected] 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

5

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
(Control Loop Gain Values — Rondeau Research).

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

6

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
Control Loop Gain Values — Rondeau Research , 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 R. [email protected] wrote:

loop_bw

-Sreeraj
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–

Alex,
Dreams can come true just believe.

7

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 R. [email protected] wrote:

loop_bw

-Sreeraj
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–

Alex,
Dreams can come true just believe.

8

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.