Re: [Discuss-gnuradio] E312 receiver gets stuck

To whom it may concern:

I do not remember the structure of 'benchmark_rx.py', but the PSK/QAM demod blocks of GNU Radio do often fail if you feed in noise for a while. As Mansour suspected, that is mainly due to the synchronization issues. The flowgraph does not stop, but loses synchronizations to the incoming signal and does not recover.

A few things that can be tried (assuming that the problem of 'benchmark_rx.py' is indeed the same blind synch issue):

1. Writing your own synchronization / demod blocks, instead of relying on the blind synchronization of the PSK/QAM demod blocks. (time-consuming, but often worth it).

2. Feed in data to the demod block when and only when the transmitter is actually transmitting. (maybe 'power sqeulch'?)

3. Try fixing the synchronization routine of the demod block. See: http://lists.gnu.org/archive/html/discuss-gnuradio/2017-10/msg00124.html

(I am not sure what is the best way to correct the problem, or if anyone submitted a patch for this.)

Regards,

Kyeong Su Shin

---

보낸 사람: Mojtaba Mansour Abadi <mansourabadi.mojtaba@gmail.com> 대신 Discuss-gnuradio <discuss-gnuradio-bounces+ksshin=postech.ac.kr@gnu.org>
보낸 날짜: 2018년 2월 20일 화요일 오전 4:12:19
받는 사람: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
제목: Re: [Discuss-gnuradio] E312 receiver gets stuck

 

I used Ettus USRP B210.

I had this issue, no matter what modulation schemes I was implementing.

What I noticed was the fact that if the signal power drops below a value, the whole receiver stopped and even the constellation was not updating.

I think the receiver block diagrams couldn't recover after a signal drop.

 

Sent from Mail for Windows 10

 

From: Niloofar Toorchi
Sent: 19 February 2018 15:39
To: mansourabadi.mojtaba@gmail.com
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] E312 receiver gets stuck

 

Thank you Mansour, Which USRP did you use? E312? I know some one who used flowgraph in E310 but did not face any problem. I do not know whether this is related to USRP version or is a software issue.

 

Best,

Niloofar

 

On Mon, Feb 19, 2018 at 8:05 AM, <mansourabadi.mojtaba@gmail.com> wrote:

I had the same problem. Even when I built the flowgraph the problem remained.

I think it's coming from the stages related to signal clock/phase/frequency recovery. Most of these blocks are working as a state machine. For any reason, when the received signal power drops, they probably go to an unknown state.

Unfortunately these blocks have no reset input to initialise them so what you have to do is to re-run the program.

There might be a solution if you use code. But I haven't used coding.

 

Sincerely,

Mansour.

On 18 Feb 2018, at 20:49, Niloofar Toorchi <ntoorchi@crimson.ua.edu> wrote:

Hi All,

 

I am using USRP E312. I used the available examples by Gnuradio, benchmark_{rx,tx}.py to have a simple communication between transmitter and receiver. I noticed that when the transmitter pauses sending, the receiver freezes somehow and when the transmitter resumes packet transmission, the receiver cannot receive anymore. Has any one experienced the same problem? Do you think building flowgarph can solve this issue?

 

Thanks for your help,

Niloofar

_______________________________________________
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