Hi all, Just to update you all, I've updated gr-ais to the GR 3.7 API this morning. I still have a mile's worth of updates to take care of, but it compiles and runs OK. Be sure to use a 162MHz bandpass filter as in many places nearby FM and broadcast TV RFI will saturate even the most linear front end.
Best, --n On Sun, Sep 8, 2013 at 3:04 PM, Marcus Müller <[email protected]> wrote: > Hi Fokko, > > you have a misconception of what flowgraphs are. > You call connect twice, connecting all the blocks twice; this can't be > done, since every block only has one set of input ports. > Please consider flowgraphs as mathematical digraphs: Just a set of > vertices (blocks) and directed edges; if you connect the two same blocks > with the exact same connect(...) call, you end up with double edges and > blocks that have more incoming edges than they can accept, since you try to > add the same vertices and edges to a graph that it already has. > You even made the mistake of overwriting self.filter with the second call > to ais_rx - are you sure you know what you're coding here? > Try with only one ais_rx; I don't see why that should not work. When you > want to construct the second branch of your flowgraph, you need to > duplicate all the vertices (blocks) first, so that they can function on > their own. > > > On 09/08/2013 11:47 PM, Driesprong, Fokko wrote: > > Hello Marcus, > > I am sorry for the scare information. Please let me elaborate. > > The most recent version is pushed in my fork of the repository of gr-ais: > https://github.com/Fokko/gr-ais/blob/master/apps/ais_rx.py > > I have digged in the generated python swig code, but the type of the > osmosdr_source_c_impl > and freq_xlating_fir_filter_ccf blocks seem the be gr_block, which should > be accepted. It doesn't reach the ais.demod block, it crashes right away. > > Kind regards > , > ing. Fokko Driesprong > > > 2013/9/8 Marcus Müller <[email protected]> > >> Hi Fokko, >> The information you're offering is a little sparse. >> Do you have the source code (at leas ais_rx.py in your current version) >> somewhere? >> >> >> >> On 09/08/2013 09:25 PM, Driesprong, Fokko wrote: >> >> He guys, >> >> I have managed to fix all the swig error's, but now I have some issue's >> with python. Maybe you guys have run into it earlier? >> >> All the SWIG objects and Python classes are available. But something >> might have changed in the connect method of the top_block. >> >> Traceback (most recent call last): >> File "/usr/local/bin/ais_rx.py", line 216, in <module> >> main() >> File "/usr/local/bin/ais_rx.py", line 169, in main >> tb = my_top_block(options, queue) >> File "/usr/local/bin/ais_rx.py", line 79, in __init__ >> self.ais_rx(self.u, 161.975e6 - 162.0e6, "A", options, queue); >> File "/usr/local/bin/ais_rx.py", line 121, in ais_rx >> self.connect(self.u, self.filter, self.demod, self.unstuff, >> self.start_correlator, self.stop_correlator, self.parse) >> File >> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line >> 131, in connect >> self._connect(points[i-1], points[i]) >> File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", >> line 143, in _connect >> dst_block.to_basic_block(), dst_port) >> File >> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line >> 4130, in primitive_connect >> return _runtime_swig.top_block_sptr_primitive_connect(self, *args) >> NotImplementedError: Wrong number or type of arguments for overloaded >> function 'top_block_sptr_primitive_connect'. >> Possible C/C++ prototypes are: >> gr::hier_block2::connect(gr::basic_block_sptr) >> >> gr::hier_block2::connect(gr::basic_block_sptr,int,gr::basic_block_sptr,int) >> >> Some blocks are getting chained by the connect method. It crashes on >> the following blocks: >> <gr_block osmosdr_source_c_impl (0)> -> <gr_block >> freq_xlating_fir_filter_ccf (1)> >> These two blocks should pass complex numbers. >> >> Anyone any idea? I am confused because the osmosdr and freq_xlanting >> objects shipped with osmosdr/gnuradio. >> >> Kind regards, >> ing. Fokko Driesprong >> >> >> 2013/9/5 Martin Braun (CEL) <[email protected]> >> >>> On Thu, Sep 05, 2013 at 12:20:17AM +0200, Driesprong, Fokko wrote: >>> > He Guys, >>> > >>> > Thank you for the prompt replies, in special Nick Foster for the >>> reply, I am >>> > very thankful for the gr-ais package! :) >>> > >>> > Currently I am working with the modtool. I didn't know it's existence. >>> A very >>> > helpful tool. >>> >>> Fokko, >>> >>> You really should read the tutorials on how to work with out-of-tree >>> modules if you want to work with out-of-tree modules: >>> http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules >>> >>> MB >>> >>> -- >>> Karlsruhe Institute of Technology (KIT) >>> Communications Engineering Lab (CEL) >>> >>> Dipl.-Ing. Martin Braun >>> Research Associate >>> >>> Kaiserstraße 12 >>> Building 05.01 >>> 76131 Karlsruhe >>> >>> Phone: +49 721 608-43790 <%2B49%20721%20608-43790> >>> Fax: +49 721 608-46071 <%2B49%20721%20608-46071> >>> www.cel.kit.edu >>> >>> KIT -- University of the State of Baden-Württemberg and >>> National Laboratory of the Helmholtz Association >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing >> [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
