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

[Landsman, Arik]

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