He Nick, Thanks for the quick response! One last error in the make install. In the grc/CMakeLists.txt there are multiple xml files that are copied by cmake, but these files don't exists. I commented it out and everything works fine. I think you should correct that in the master too.
Kind regards, Fokko Driesprong 2013/9/12 Nick Foster <bistrom...@gmail.com> > Dangit. Missed one -- had renamed ais_rx.py to ais_rx but forgot to change > apps/CMakeLists.txt to reflect it. Fixed, pushed the fix to master. > > Thanks! > Nick > > > On Thu, Sep 12, 2013 at 7:17 AM, Driesprong, Fokko > <fo...@driesprongen.nl>wrote: > >> H >> e Nick, >> >> Great work on the update of gr-ais. University is starting again, so I am >> running short on time. >> >> I have the following make-problem: >> make[2]: *** No rule to make target `../apps/ais_rx.py', needed by >> `apps/ais_rx.py.exe'. Stop. >> make[1]: *** [apps/CMakeFiles/pygen_apps_8ba3a.dir/all] Error 2 >> make: *** [all] Error 2 >> >> Not sure where it comes from. >> >> Kind regards, >> >> Fokko Driesprong >> >> >> 2013/9/11 Nick Foster <bistrom...@gmail.com> >> >>> 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 <mar...@hostalia.de>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 <mar...@hostalia.de> >>>> >>>>> 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) <martin.br...@kit.edu> >>>>> >>>>>> 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 >>>>>> Discuss-gnuradio@gnu.org >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing >>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> 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 >>>> >>>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
