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: [email protected] 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 [[email protected]] Sent: Sunday, April 03, 2016 8:49 AM To: Landsman, Arik; Tom Rondeau Cc: [email protected] 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 > <[email protected]> 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
