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.mojt...@gmail.com> 대신 
Discuss-gnuradio <discuss-gnuradio-bounces+ksshin=postech.ac...@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<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



From: Niloofar Toorchi<mailto:ntoor...@crimson.ua.edu>
Sent: 19 February 2018 15:39
To: mansourabadi.mojt...@gmail.com<mailto:mansourabadi.mojt...@gmail.com>
Cc: discuss-gnuradio@gnu.org<mailto: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.mojt...@gmail.com<mailto:mansourabadi.mojt...@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 
<ntoor...@crimson.ua.edu<mailto:ntoor...@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<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org<mailto: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

Reply via email to