Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

[Landsman, Arik]

Hi Andy, 

So the issue is with the modulate vector block like you suggested. Disabling it 
alone is not enough, had to be removed altogether and GRC restarted. Only then 
the flowgraph runs ok. 

how did you menage to run it on your setup?.. different Thrift config? To this 
end, how would I go about setting "GR_CONF_THRIFT_PORT" to have a separate port 
for modulate_vector?  Even having that block on a *blank* flowgraph returns the 
error. 

if this is a no go, I was going to try modulating a vector manually in a 
separate flowgraph (without modulate_vector), storing as txt, and later reading 
the content into corr_est in the main flowgraph. 

Best Regards,
Arik 
________________________________________
From: Landsman, Arik
Sent: Sunday, April 03, 2016 10:15 AM
To: Andy Walls; Tom Rondeau
Cc: address@hidden
Subject: RE: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] 
costas ambiguity and correlate-and-sync block in qpsk)

error still there in Rx_syncd_3.grc.

Feels like a version or dependencies issue on the GRC side..

With the .py running, going to use Rx_syncd_2.grc for now as a reference  to 
copy essential blocks to a working (earlier) version of Rx_syncd.grc. if this 
works I'll continue off of the other thread to keep the two topics somewhat 
separate. certainly will have a question or two on how you fine-tuned the 
modulated symbols to corr against.  going to try the "octave method" next..

also will try disabling the added blocks.



________________________________________
From: Landsman, Arik
Sent: Sunday, April 03, 2016 9:47 AM
To: Andy Walls; Tom Rondeau
Cc: address@hidden
Subject: RE: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] 
costas ambiguity and correlate-and-sync block in qpsk)

Hi Andy,

Looks like the issue is connected to the .grc like you mentioned - without 
opening Rx_syncd_2.grc, the Rx_syncd.py you attached earlier runs fine.

Just opening the Rx_syncd_2.grc, w/o ever running or generating a new .py, 
while attempting to run any other .grc gives the same error.

So I suppose with the .py running ok a race condition with modulate_vector is 
unlikely.. do our GRC's match version? I have 3.7.9.

not sure how to check the Apache Thrift version, but it was running ok so far.

worth noting that I did have to get the .grc off of the gnuradio-list archives 
as a .bin (original was blocked by the tufts mail server for some reason). Just 
in case anything besides the name could change once archived.

But let me try Rx_syncd_3.grc

Thanks,
Arik


________________________________________
From: Andy Walls address@hidden
Sent: Sunday, April 03, 2016 8:49 AM
To: Landsman, Arik; Tom Rondeau
Cc: address@hidden
Subject: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] costas 
ambiguity and correlate-and-sync block in qpsk)

Hi Arik:

First off, try the attached Rx_syncd_3.grc.  I disabled the modulate
vector block and hard-coded in a vector of 150 preamble samples.

On Sat, 2016-04-02 at 20:11 -0400, Andy Walls wrote:
> Hi Arik:
>
> On Sat, Apr 2, 2016 at 7:41 PM, Landsman, Arik
> <address@hidden> wrote:
>         Hi Andy,
>
>         Still looking it over, but one thing jumps out right away -
>         for some reason I couldn't execute either Rx_syncd_2.grc or
>         the Rx_syncd.py. getting the same error in both cases:
>
>         ""
>         Generating:
>         '/home/ubuntu/Desktop/MSProject/alternateVersions/Rx_syncd_2.py'
>
>         Executing: '/usr/bin/python2Andy, certainly will have a question or 
> two on how you fine-tuned the modulated symbols to corr against.
>         -u /home/ubuntu/Desktop/MSProject/alternateVersions/Rx_syncd_2.py'
>
>         Using Volk machine: sse4_1_64
>         Thrift: Sat Apr  2 19:05:54 2016 TServerSocket::listen() BIND
>         9090
>         terminate called after throwing an instance of
>         'apache::thrift::transport::TTransportException'
>           what():  Could not bind: Transport endpoint is not connected
>         ""
>
>         does this look familiar by any chance?
>do our GRC's match versions? I have 3.7.9.
>
> It looks like a GNURadio ControlPort / Apache Thrift error.
>
>
> I took your flowgraph and modified it slightly, only adding a few
> blocks:
>
> -modulate_vector
> -skip_headmodulate_vector
> -keep_1_in_n
> -qt_time_sink
> -feedforward_agc
> -multiply const
> -qt gui range
>
> One of those might be doing it.  Disable skip_head, keep_1_in_n, and
> the constellation sink they connect to.  Hopefully it's one of them.
>
> Otherwise, you didn't drop a control port related block on the
> flowgraph did you?


Here is some good info on how GRNURadio's control port works at a high
level:
https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
https://gnuradio.org/doc/doxygen/page_ctrlport.html

>From that second page, it appears that running two flowgraphs on the
same machine has a problem caused by Apache Thrift and GNURadio's
configuration of the Control Port network port (default of 9090).
https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues

So please only run on flowgraph at a time, at first, to troubleshoot
this issue.

Second, you may want to try setting the GR_CONF_THRIFT_PORT environment
variable to something other than 9090, a port that you know is open on
your machine, for each separate flowgraph that you run.

FYI, the modulate_vector block runs a "mini"-flowgraph, before the main
flowgraph actually runs:

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59

Hopefully, there isn't some sort of weird race condition with the Thrift
port being open for the modulate_vector block's mini-flowgraph and the
main flowgraph.


Hi Tom,

Do you have any comments or insights on Arik's Thrift error message
and/or the possibility of modulate_vector's mini-flowgraph causing
problems with Thrift's network port and the main flowgraph?

Regards,
Andy

> Regards,
>
> Andy