Re: [Discuss-gnuradio] gr_modtool cmake/make problems on OSX
On Mon, Feb 25, 2013 at 08:40:31PM +, Warren, Kevin M wrote: > 1) A minor difficulty is that gr_modtool.py does not appear to be placing the > class definitions and the instantiation of the class object(s) in the proper > order. This was easy enough to remedy by hand. Hi Kevin, I assume you mean in the SWIG files? Or are you talking about something else? The SWIG order bug was fixed in both the standalone and the master branch version of gr-modtool. Also, are you using the pre-3.7 or the post-3.7 module structure (gr_modtool info tells you this if you don't know what this means). In general, stuff that's "easy to remedy by hand" should be easy to get right in modtool. If you're not talking about the swig files, perhaps you can post the faulty code? > 2) A second minor difficulty is that makexml does not appear to work at all. > Again, this is easy enough to remedy by hand. makexml makes a lot of assumptions, and right now there's no code parser for Python blocks. Message ports aren't supported at all right now. Do you have a C++ block? If so, I'd be interested to see the code chunks that makexml stumbles over. However, there's only so much I can do in makexml, and it will never be able to fully understand all blocks (although it should fail gracefully). 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 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgprjhcKPs6jg.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'square_ff'.
It might be that you have some version mismatch, or i don't know how to call that. Check inside of your _swig.i and see whether this MAGIC thig is above include statement. That was problem in my case. Gr_modtool generated something like this: %include "test_pkdt.h" GR_SWIG_BLOCK_MAGIC(test,pkdt); And it should be like this: GR_SWIG_BLOCK_MAGIC(test,pkdt); %include "test_pkdt.h" Best On Mon, Feb 25, 2013 at 9:16 PM, Nathan West wrote: > On Mon, Feb 25, 2013 at 2:05 PM, wrote: > > > > Nathan West wrote: > >> Someone can correct me if I'm wrong, but I think this is the error that > >> happens if you haven't run `ldconfig` (on Ubuntu). > >> > >> Try `sudo ldconfig` There's a gnuradio wiki page that explains what it > does > >> somewhere. > >> > > Im sorry this is probably a super basic question but which directory > should i run the 'sudo ldconfig'? because i am getting a similar error > (running a a different program in GRC, OP25_grc.py) that made me disable > some GUI sliders; but now the program is dies a different way. > > > > It shouldn't matter which directory you run it in. It just updates the > dynamic linker config (see `man ldconfig` for info) and doesn't have > anything to do with the current working directory > > > http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules#Finalizing-your-work-and-installing > > http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#I-get-an-error-when-importing-from-Python-_gnuradio_swig_py_runtimeso-undefined-symbol-what-do-I-do > > You'll have to copy and paste any errors before I (or anyone else) > will have a chance of knowing what the problem is, but the above links > may be useful as well. > I also don't know what OP25_grc.py is. But it sounds like something > you made. Does your module pass make test? > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-modtool and SWIG file line order
This seems to have been confusing everyone, so here's the answer: == >= 3.7 == In the 3.7-style module structure (which uses the include/MODULENAME/ directory and omits the module prefix from the file names), the correct order is: %include "..." GR_SWIG_BLOCK_MAGIC2(...) This format is automatically chosen for new modules. We generally recommend this format. == Older Format == In the pre-3.7 format (without the impl-files, and with the *.h in include/), the correct order is: GR_SWIG_BLOCK_MAGIC(...) %include "..." A major difference between the way modtool handles swigging in this style modules is that no *.i files are generated, but rather the *.h files are included. If this doesn't work, you'll have to generate the *.i file by hand. If you're using a current version of modtool, this *should all work automatically*. 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 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpboGAT5VRw5.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Toggle use of bad versions of Boost
On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau wrote: > GNU Radio: now allowing you to shoot yourself in the foot! > > We've identified a few versions of Boost that don't work well with GNU > Radio, 1.46, 1.47, and 1.52. A little while ago, I updated our cmake build > files to look for these specific versions and disable their use if found. > > Sadly, many distros currently ship with one of these known bad versions. > Looking at Boost's website, 1.47 and 1.52 are by far the most downloaded > Boost versions. So, as recommended by Johnathan, I put in a cmake command > line option that allows you to override the version check so GNU Radio will > build with any current Boost. > > To use it, just specify "-DENABLE_BAD_BOOST=True" on your cmake command > line. By default this is False. That will allow you to build against > anything. If this value is False, all GNU Radio components will be disabled > if it finds one of the bad versions. (VOLK and a couple of others will still > pass and compile since they are not affected by the problem). > > Just be aware that using one of these versions can cause problems. > Specifically, it can lock up your application when shutting down a > flowgraph. Also, many distros that ship with one of these bad versions also > have other, good, versions that you can pretty easily switch to. > Hi, Sorry for the late reply, but I just realized that half of my computers running Mint 13 (based on Ubuntu 12.04) come with Boost 1.46, yet I have had no problem building gnuradio without using "-DENABLE_BAD_BOOST=True" Admittedly, this distro appears to have a horrible mix of 1.46 and 1.48, which may confuse cmake - I really have no idea which one really is installed but I do have runtime issues on these computers. If anybody has ideas for what we can do on Mint 13 / Ubuntu 12.04, please let me know. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test runs twice
Hi GNURADIOers, I wanted to tell you that test for my block runs twice. Namely, I designed block based on tagged_file_sink, which is able to store some additional samples before true tag. I designed also test, but when I run it, it simply executes twice. at the bottom of my qa file you can find this: self.tb.run () print "\nAfter run!\n" result_data = (0, 1, 1, 0, 0, 1, 1) expected_result = (0, 1, 1, 0, 0, 1, 1) self.assertEqual (expected_result, result_data, 6) and I am able to see in terminal twice "After run", and there are also two files produced by the block itself. I discovered that at very end of my qa file, there is: if __name__ == '__main__': gr_unittest.run(qa_file_sink_history, "qa_file_sink_history.xml") but in some older test one can find this: if __name__ == '__main__': gr_unittest.main () When change first one with the second one, test executes once as it should be. Can anybody explain me this behaviour? Best -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Toggle use of bad versions of Boost
On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete wrote: > On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau wrote: >> GNU Radio: now allowing you to shoot yourself in the foot! >> >> We've identified a few versions of Boost that don't work well with GNU >> Radio, 1.46, 1.47, and 1.52. A little while ago, I updated our cmake build >> files to look for these specific versions and disable their use if found. >> >> Sadly, many distros currently ship with one of these known bad versions. >> Looking at Boost's website, 1.47 and 1.52 are by far the most downloaded >> Boost versions. So, as recommended by Johnathan, I put in a cmake command >> line option that allows you to override the version check so GNU Radio will >> build with any current Boost. >> >> To use it, just specify "-DENABLE_BAD_BOOST=True" on your cmake command >> line. By default this is False. That will allow you to build against >> anything. If this value is False, all GNU Radio components will be disabled >> if it finds one of the bad versions. (VOLK and a couple of others will still >> pass and compile since they are not affected by the problem). >> >> Just be aware that using one of these versions can cause problems. >> Specifically, it can lock up your application when shutting down a >> flowgraph. Also, many distros that ship with one of these bad versions also >> have other, good, versions that you can pretty easily switch to. >> > > Hi, > > Sorry for the late reply, but I just realized that half of my > computers running Mint 13 (based on Ubuntu 12.04) come with Boost > 1.46, yet I have had no problem building gnuradio without using > "-DENABLE_BAD_BOOST=True" > Admittedly, this distro appears to have a horrible mix of 1.46 and > 1.48, which may confuse cmake - I really have no idea which one really > is installed but I do have runtime issues on these computers. If > anybody has ideas for what we can do on Mint 13 / Ubuntu 12.04, please > let me know. > > Alex Alex, You can see which Boost version Cmake is finding for you by looking at CMakeCache.txt in the top of the build directory. Check out the "Boost__LIBRARY" and "Boost_INCLUDE_DIR" to see which ones were found and are being used. Hopefully, it's finding the 1.48 version that's installed. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Toggle use of bad versions of Boost
Hi, > You can see which Boost version Cmake is finding for you by looking at > CMakeCache.txt in the top of the build directory. Check out the > "Boost__LIBRARY" and "Boost_INCLUDE_DIR" to see which ones > were found and are being used. Hopefully, it's finding the 1.48 version that's > installed. It seems some older gnuradio versions and other SDR tools do not want the 1.48, they want a 1.46 or maybe a boost lib without any version in its name, who knows. I got into problems when compiling gnuradio 3.4.2 for OpenBTS, but lacking the knowledge how to solve this in a proper way I just fiddled around with uninstalling and installing several parts of the packages until it compiled. Not satisfying, such a workaround... > Tom Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_modtool cmake/make problems on OSX
>>I assume you mean in the SWIG files? Or are you talking about something else? >>The SWIG order bug was fixed in both the standalone and the master branch >>version of gr-modtool. Martin, It's "howto_swig.py" that is generated following the out of tree module tutorial (link in original post) downloaded from github. I see there's been a new version posted within the past few hours. >>Also, are you using the pre-3.7 or the post-3.7 module structure (gr_modtool >>info tells you this if you don't know what this means). Unfortunately I do not see any switches in the parser or hard coded information containing the version information, though there is a reference to self.info['_version'] I don't see the actual assignment. Either way, it was the top version on github as of two days ago. >>In general, stuff that's "easy to remedy by hand" should be easy to get right >>in modtool. If you're not talking about the swig files, perhaps you can post >>the faulty code? I hope this is sufficient. I cut out some of the details of the code to keep it short. square_ff_sptr_swigregister = _howto_swig.square_ff_sptr_swigregister square_ff_sptr_swigregister(square_ff_sptr) square_ff_sptr.__repr__ = lambda self: "" % (self.name(), self.unique_id()) square_ff = square_ff.make; class square_ff(object): """<+description of block+>""" ... return _howto_swig.square_ff_make() def make(): make = staticmethod(make) __swig_destroy__ = _howto_swig.delete_square_ff __del__ = lambda self : None; def square_ff_make(): """ square_ff_make() -> square_ff_sptr Return a shared_ptr to a new instance of howto::square_ff. ...""" return _howto_swig.square_ff_make() square_ff_swigregister = _howto_swig.square_ff_swigregister square_ff_swigregister(square_ff) >>makexml makes a lot of assumptions, and right now there's no code parser for >>Python blocks. Message ports aren't supported at all right now. Do you have a >>C++ block? If so, I'd be interested to see the code chunks that makexml >>stumbles over. It is identical to that posted in the out of tree module tutorial. http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules >>However, there's only so much I can do in makexml, and it will never be able >>to fully understand all blocks (although it should fail gracefully). Understood. As far as I can tell gr_modtool didn't do anything to the original template when I ran it on the example. When I have some time I will poke into the details of the script but someone else's parsing and code generation tools can be challenging to unravel. I can barely follow my own a few days after I've written them. Thanks, Kevin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] test runs twice
On Tue, Feb 26, 2013 at 7:17 AM, Nemanja Savic wrote: > Hi GNURADIOers, > > I wanted to tell you that test for my block runs twice. > Namely, I designed block based on tagged_file_sink, which is able to store > some > additional samples before true tag. > I designed also test, but when I run it, it simply executes twice. > > at the bottom of my qa file you can find this: > > self.tb.run () > print "\nAfter run!\n" > result_data = (0, 1, 1, 0, 0, 1, 1) > expected_result = (0, 1, 1, 0, 0, 1, 1) > self.assertEqual (expected_result, result_data, 6) > > and I am able to see in terminal twice "After run", and there are also two > files produced by the block itself. > > I discovered that at very end of my qa file, there is: > > if __name__ == '__main__': > gr_unittest.run(qa_file_sink_history, "qa_file_sink_history.xml") > > but in some older test one can find this: > > if __name__ == '__main__': > gr_unittest.main () > > When change first one with the second one, test executes once as it should > be. > Can anybody explain me this behaviour? > > Best > > -- > Nemanja Savić It has to do with how we run the test in the gr_unittest.py suite. Specifically, if you give it an XML file to save the results, it has to run the test twice: once to output to the XML file and once to output to the screen for feedback. If you don't provide the XML file to output to, it will only run the test once. Their is actually a FIXME in the gr_unittest.py file about this. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Toggle use of bad versions of Boost
On Tue, Feb 26, 2013 at 9:38 AM, Ralph A. Schmid, dk5ras wrote: > Hi, > >> You can see which Boost version Cmake is finding for you by looking at >> CMakeCache.txt in the top of the build directory. Check out the >> "Boost__LIBRARY" and "Boost_INCLUDE_DIR" to see which ones >> were found and are being used. Hopefully, it's finding the 1.48 version > that's >> installed. > > It seems some older gnuradio versions and other SDR tools do not want the > 1.48, they want a 1.46 or maybe a boost lib without any version in its name, > who knows. I got into problems when compiling gnuradio 3.4.2 for OpenBTS, > but lacking the knowledge how to solve this in a proper way I just fiddled > around with uninstalling and installing several parts of the packages until > it compiled. Not satisfying, such a workaround... > >> Tom > > Ralph. Two things with this. First, the checking and rejecting of bad Boost versions is new since we just started to understand the issue. So older versions do not have this protection. Second, GNU Radio doesn't /prefer/ a version of Boost; it'll likely just picks the first one it finds that is valid. With 3.4.2, the only non-valid Boost versions would be those before the minimum version of 1.35. Most likely, it'll take whichever the sym link to libboost_xxx.so it finds. For instance, my machine has: /usr/lib/libboost_filesystem-mt.so -> libboost_filesystem.so.1.48.0 It'll depend on how to installed, order of install, or OS issues that would determine this if you have multiple versions installed. You can always tell cmake (and configure before it) which Boost libraries and include directories you want to specify. With cmake, you use -DBoost_LIBRARY_DIRS=..., -DBoost_INCLUDE_DIR=..., and even library-specific directives (if multiple Boost libs are installed into the same directory) like -DBoost_FILESYSTEM_LIBRARY=.../libboost_filesystem-mt.so. I don't recall how to set these using configure, though. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Toggle use of bad versions of Boost
On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau wrote: > On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete wrote: >> On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau wrote: >>> GNU Radio: now allowing you to shoot yourself in the foot! >>> >>> We've identified a few versions of Boost that don't work well with GNU >>> Radio, 1.46, 1.47, and 1.52. A little while ago, I updated our cmake build >>> files to look for these specific versions and disable their use if found. >>> >>> Sadly, many distros currently ship with one of these known bad versions. >>> Looking at Boost's website, 1.47 and 1.52 are by far the most downloaded >>> Boost versions. So, as recommended by Johnathan, I put in a cmake command >>> line option that allows you to override the version check so GNU Radio will >>> build with any current Boost. >>> >>> To use it, just specify "-DENABLE_BAD_BOOST=True" on your cmake command >>> line. By default this is False. That will allow you to build against >>> anything. If this value is False, all GNU Radio components will be disabled >>> if it finds one of the bad versions. (VOLK and a couple of others will still >>> pass and compile since they are not affected by the problem). >>> >>> Just be aware that using one of these versions can cause problems. >>> Specifically, it can lock up your application when shutting down a >>> flowgraph. Also, many distros that ship with one of these bad versions also >>> have other, good, versions that you can pretty easily switch to. >>> >> >> Hi, >> >> Sorry for the late reply, but I just realized that half of my >> computers running Mint 13 (based on Ubuntu 12.04) come with Boost >> 1.46, yet I have had no problem building gnuradio without using >> "-DENABLE_BAD_BOOST=True" >> Admittedly, this distro appears to have a horrible mix of 1.46 and >> 1.48, which may confuse cmake - I really have no idea which one really >> is installed but I do have runtime issues on these computers. If >> anybody has ideas for what we can do on Mint 13 / Ubuntu 12.04, please >> let me know. >> >> Alex > > Alex, > > You can see which Boost version Cmake is finding for you by looking at > CMakeCache.txt in the top of the build directory. Check out the > "Boost__LIBRARY" and "Boost_INCLUDE_DIR" to see which ones > were found and are being used. Hopefully, it's finding the 1.48 > version that's installed. Actually, it seems that I only have version 1.46 libraries installed, see the attached file. This is really screwed up: I have libboost-dev installed, which according to synaptic is at version 1.48.0.2. Looking in the package info I see that it depends on libboost1.46-dev, which explain why all my boost libs are version 1.46. The same applies to many other boost packages, e.g. libboost-thread-dev. Cmake didn't complain about bad boost version and I can see no version info in CMakeCache.txt. Gnuradio compiles and install just fine. I can rerun cmake and submit the cmake files on a system with boost 1.46 if needed. I have uninstalled the 1.46 libs manually (except those that are required by some applications) and the installed libboost-xyz1.48-dev libraries. recompiled uhd and gnuradio and it seems the run-time issue I was having before (app freezes) is now gone. Alex boost-libs.xt Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Toggle use of bad versions of Boost
On Tue, Feb 26, 2013 at 11:10 AM, Alexandru Csete wrote: > On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau wrote: >> On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete wrote: >>> On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau wrote: GNU Radio: now allowing you to shoot yourself in the foot! We've identified a few versions of Boost that don't work well with GNU Radio, 1.46, 1.47, and 1.52. A little while ago, I updated our cmake build files to look for these specific versions and disable their use if found. Sadly, many distros currently ship with one of these known bad versions. Looking at Boost's website, 1.47 and 1.52 are by far the most downloaded Boost versions. So, as recommended by Johnathan, I put in a cmake command line option that allows you to override the version check so GNU Radio will build with any current Boost. To use it, just specify "-DENABLE_BAD_BOOST=True" on your cmake command line. By default this is False. That will allow you to build against anything. If this value is False, all GNU Radio components will be disabled if it finds one of the bad versions. (VOLK and a couple of others will still pass and compile since they are not affected by the problem). Just be aware that using one of these versions can cause problems. Specifically, it can lock up your application when shutting down a flowgraph. Also, many distros that ship with one of these bad versions also have other, good, versions that you can pretty easily switch to. >>> >>> Hi, >>> >>> Sorry for the late reply, but I just realized that half of my >>> computers running Mint 13 (based on Ubuntu 12.04) come with Boost >>> 1.46, yet I have had no problem building gnuradio without using >>> "-DENABLE_BAD_BOOST=True" >>> Admittedly, this distro appears to have a horrible mix of 1.46 and >>> 1.48, which may confuse cmake - I really have no idea which one really >>> is installed but I do have runtime issues on these computers. If >>> anybody has ideas for what we can do on Mint 13 / Ubuntu 12.04, please >>> let me know. >>> >>> Alex >> >> Alex, >> >> You can see which Boost version Cmake is finding for you by looking at >> CMakeCache.txt in the top of the build directory. Check out the >> "Boost__LIBRARY" and "Boost_INCLUDE_DIR" to see which ones >> were found and are being used. Hopefully, it's finding the 1.48 >> version that's installed. > > Actually, it seems that I only have version 1.46 libraries installed, > see the attached file. > > This is really screwed up: I have libboost-dev installed, which > according to synaptic is at version 1.48.0.2. Looking in the package > info I see that it depends on libboost1.46-dev, which explain why all > my boost libs are version 1.46. The same applies to many other boost > packages, e.g. libboost-thread-dev. Grep CMakeCache.txt for "Boost_VERSION" and see what that returns. For 1.48, it'll look like 104800, and for 1.46 it should be 104600. Also see what it tells you when you grep for ENABLE_BAD_BOOST. If this is set to True, it will allow any version. > Cmake didn't complain about bad boost version and I can see no version > info in CMakeCache.txt. Gnuradio compiles and install just fine. I can > rerun cmake and submit the cmake files on a system with boost 1.46 if > needed. Maybe delete CMakeCache.txt and rerun cmake to make sure it refreshes everything. > I have uninstalled the 1.46 libs manually (except those that are > required by some applications) and the installed libboost-xyz1.48-dev > libraries. recompiled uhd and gnuradio and it seems the run-time issue > I was having before (app freezes) is now gone. > > Alex Ok, glad you got it working. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_modtool cmake/make problems on OSX
On Tue, Feb 26, 2013 at 02:45:52PM +, Warren, Kevin M wrote: > Martin, > It's "howto_swig.py" that is generated following the out of tree module > tutorial (link in original post) downloaded from github. I see there's been a > new version posted within the past few hours. If the swig file was the problem, you should be fine. > >>Also, are you using the pre-3.7 or the post-3.7 module structure > >>(gr_modtool info tells you this if you don't know what this means). > > Unfortunately I do not see any switches in the parser or hard coded > information containing the version information, though there is a reference > to self.info['_version'] I don't see the actual assignment. Either way, it > was the top version on github as of two days ago. This doesn't have anything to do with the modtool version, but the version of your code structure. If you don't know what this means, you're probably on post-3.7, but 'gr_modtool info' will tell you for sure. > >>In general, stuff that's "easy to remedy by hand" should be easy to get > >>right in modtool. If you're not talking about the swig files, perhaps you > >>can post the faulty code? > > I hope this is sufficient. I cut out some of the details of the code to keep > it short. > [...] Yep, this is the bug that was fixed a while back. > >>makexml makes a lot of assumptions, and right now there's no code parser > >>for Python blocks. Message ports aren't supported at all right now. Do you > >>have a C++ block? If so, I'd be interested to see the code chunks that > >>makexml stumbles over. > > It is identical to that posted in the out of tree module tutorial. > http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules > > >>However, there's only so much I can do in makexml, and it will never be > >>able to fully understand all blocks (although it should fail gracefully). > > Understood. As far as I can tell gr_modtool didn't do anything to the > original template when I ran it on the example. When I have some time I will > poke into the details of the script but someone else's parsing and code > generation tools can be challenging to unravel. I can barely follow my own a > few days after I've written them. I just pushed a fix to the standalone, perhaps that help. Note that I'll only be doing easy bugfixes to the standalone version since modtool was merged. 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 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpgGA5POkFEY.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tunnel.py command not working.
HI,
I am using tunnel.py command to setup a TCP/IP link between two usrp1. When i
try to use the command , i get this error
./tunnel.py
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.001-29-g3cb515f7
Traceback (most recent call last):
File "./tunnel.py", line 295, in
main()
File "./tunnel.py", line 241, in main
(tun_fd, tun_ifname) = open_tun_interface(options.tun_device_filename)
File "./tunnel.py", line 79, in open_tun_interface
ifs = ioctl(tun, TUNSETIFF, struct.pack("16sH", "gr%d", mode))
IOError: [Errno 1] Operation not permitted
ANy suggestions,
BEST REGARDS;
SAJJAD SAFDAR___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Toggle use of bad versions of Boost
On Tue, Feb 26, 2013 at 5:21 PM, Tom Rondeau wrote: > On Tue, Feb 26, 2013 at 11:10 AM, Alexandru Csete wrote: >> On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau wrote: >>> On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete wrote: On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau wrote: > GNU Radio: now allowing you to shoot yourself in the foot! > > We've identified a few versions of Boost that don't work well with GNU > Radio, 1.46, 1.47, and 1.52. A little while ago, I updated our cmake build > files to look for these specific versions and disable their use if found. > > Sadly, many distros currently ship with one of these known bad versions. > Looking at Boost's website, 1.47 and 1.52 are by far the most downloaded > Boost versions. So, as recommended by Johnathan, I put in a cmake command > line option that allows you to override the version check so GNU Radio > will > build with any current Boost. > > To use it, just specify "-DENABLE_BAD_BOOST=True" on your cmake command > line. By default this is False. That will allow you to build against > anything. If this value is False, all GNU Radio components will be > disabled > if it finds one of the bad versions. (VOLK and a couple of others will > still > pass and compile since they are not affected by the problem). > > Just be aware that using one of these versions can cause problems. > Specifically, it can lock up your application when shutting down a > flowgraph. Also, many distros that ship with one of these bad versions > also > have other, good, versions that you can pretty easily switch to. > Hi, Sorry for the late reply, but I just realized that half of my computers running Mint 13 (based on Ubuntu 12.04) come with Boost 1.46, yet I have had no problem building gnuradio without using "-DENABLE_BAD_BOOST=True" Admittedly, this distro appears to have a horrible mix of 1.46 and 1.48, which may confuse cmake - I really have no idea which one really is installed but I do have runtime issues on these computers. If anybody has ideas for what we can do on Mint 13 / Ubuntu 12.04, please let me know. Alex >>> >>> Alex, >>> >>> You can see which Boost version Cmake is finding for you by looking at >>> CMakeCache.txt in the top of the build directory. Check out the >>> "Boost__LIBRARY" and "Boost_INCLUDE_DIR" to see which ones >>> were found and are being used. Hopefully, it's finding the 1.48 >>> version that's installed. >> >> Actually, it seems that I only have version 1.46 libraries installed, >> see the attached file. >> >> This is really screwed up: I have libboost-dev installed, which >> according to synaptic is at version 1.48.0.2. Looking in the package >> info I see that it depends on libboost1.46-dev, which explain why all >> my boost libs are version 1.46. The same applies to many other boost >> packages, e.g. libboost-thread-dev. > > Grep CMakeCache.txt for "Boost_VERSION" and see what that returns. For > 1.48, it'll look like 104800, and for 1.46 it should be 104600. > > Also see what it tells you when you grep for ENABLE_BAD_BOOST. If this > is set to True, it will allow any version. > >> Cmake didn't complain about bad boost version and I can see no version >> info in CMakeCache.txt. Gnuradio compiles and install just fine. I can >> rerun cmake and submit the cmake files on a system with boost 1.46 if >> needed. > > Maybe delete CMakeCache.txt and rerun cmake to make sure it refreshes > everything. Hi Tom, I started with a clean build directory and after cmake finishes without errors I get: oz9aec@romit ~/sdr/gnuradio/v3.6.3-146-ga54dc5ba/build $ cat CMakeCache.txt | grep ENABLE_BAD_BOOST ENABLE_BAD_BOOST:BOOL=OFF oz9aec@romit ~/sdr/gnuradio/v3.6.3-146-ga54dc5ba/build $ cat CMakeCache.txt | grep "Boost_VERSION" Boost_VERSION:INTERNAL=104601 Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Toggle use of bad versions of Boost
On Tue, Feb 26, 2013 at 1:12 PM, Alexandru Csete wrote: > On Tue, Feb 26, 2013 at 5:21 PM, Tom Rondeau wrote: >> On Tue, Feb 26, 2013 at 11:10 AM, Alexandru Csete wrote: >>> On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau wrote: On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete wrote: > On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau wrote: >> GNU Radio: now allowing you to shoot yourself in the foot! >> >> We've identified a few versions of Boost that don't work well with GNU >> Radio, 1.46, 1.47, and 1.52. A little while ago, I updated our cmake >> build >> files to look for these specific versions and disable their use if found. >> >> Sadly, many distros currently ship with one of these known bad versions. >> Looking at Boost's website, 1.47 and 1.52 are by far the most downloaded >> Boost versions. So, as recommended by Johnathan, I put in a cmake command >> line option that allows you to override the version check so GNU Radio >> will >> build with any current Boost. >> >> To use it, just specify "-DENABLE_BAD_BOOST=True" on your cmake command >> line. By default this is False. That will allow you to build against >> anything. If this value is False, all GNU Radio components will be >> disabled >> if it finds one of the bad versions. (VOLK and a couple of others will >> still >> pass and compile since they are not affected by the problem). >> >> Just be aware that using one of these versions can cause problems. >> Specifically, it can lock up your application when shutting down a >> flowgraph. Also, many distros that ship with one of these bad versions >> also >> have other, good, versions that you can pretty easily switch to. >> > > Hi, > > Sorry for the late reply, but I just realized that half of my > computers running Mint 13 (based on Ubuntu 12.04) come with Boost > 1.46, yet I have had no problem building gnuradio without using > "-DENABLE_BAD_BOOST=True" > Admittedly, this distro appears to have a horrible mix of 1.46 and > 1.48, which may confuse cmake - I really have no idea which one really > is installed but I do have runtime issues on these computers. If > anybody has ideas for what we can do on Mint 13 / Ubuntu 12.04, please > let me know. > > Alex Alex, You can see which Boost version Cmake is finding for you by looking at CMakeCache.txt in the top of the build directory. Check out the "Boost__LIBRARY" and "Boost_INCLUDE_DIR" to see which ones were found and are being used. Hopefully, it's finding the 1.48 version that's installed. >>> >>> Actually, it seems that I only have version 1.46 libraries installed, >>> see the attached file. >>> >>> This is really screwed up: I have libboost-dev installed, which >>> according to synaptic is at version 1.48.0.2. Looking in the package >>> info I see that it depends on libboost1.46-dev, which explain why all >>> my boost libs are version 1.46. The same applies to many other boost >>> packages, e.g. libboost-thread-dev. >> >> Grep CMakeCache.txt for "Boost_VERSION" and see what that returns. For >> 1.48, it'll look like 104800, and for 1.46 it should be 104600. >> >> Also see what it tells you when you grep for ENABLE_BAD_BOOST. If this >> is set to True, it will allow any version. >> >>> Cmake didn't complain about bad boost version and I can see no version >>> info in CMakeCache.txt. Gnuradio compiles and install just fine. I can >>> rerun cmake and submit the cmake files on a system with boost 1.46 if >>> needed. >> >> Maybe delete CMakeCache.txt and rerun cmake to make sure it refreshes >> everything. > > Hi Tom, > > I started with a clean build directory and after cmake finishes > without errors I get: > > oz9aec@romit ~/sdr/gnuradio/v3.6.3-146-ga54dc5ba/build $ cat > CMakeCache.txt | grep ENABLE_BAD_BOOST > ENABLE_BAD_BOOST:BOOL=OFF > oz9aec@romit ~/sdr/gnuradio/v3.6.3-146-ga54dc5ba/build $ cat > CMakeCache.txt | grep "Boost_VERSION" > Boost_VERSION:INTERNAL=104601 > > Alex That clears it up, thanks! I read somewhere that the last two digits would always be 00, so that's all I checked for. With yours being 104601, I'll need to be more clever about it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to monitor the output of tx module
Hi, My RFID communication system uses the following blocks. I can monitor the signal output by rx module using self.connect(rx, rx_out). rx_out is a log file generated by rx_out = gr.file_sink(gr.sizeof_gr_complex, "./rx.out"). How could I monitor the output of tx module? Thanks. self.connect(rx, matched_filt) self.connect(matched_filt, command_gate) self.connect(command_gate, agc) self.connect(agc, to_mag) self.connect(to_mag, center, mm, tag_decoder) self.connect(tag_decoder, self.reader, amp, to_complex, tx); Pengyu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Resistance? Capacitance? Inductance?
Dear GNU Radio aficionado's- Whatever happened to resistance, capacitance, and inductance? When I joined this thread I was hoping you would once in a while talk about ways of using the software in the computer to modify the resonant circuit in the hardware radio by making adjustments to the resistors, capacitors, and inductors. Am I just dreaming? Am I on the wrong page? Is there any hope? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio releases 3.6.3.1 and 3.6.4 available for download
GNU Radio releases 3.6.3.1 and 3.6.4 are now available for download. Release 3.6.3.1 is a bug-fix only update to 3.6.3, and has no new features. Release 3.6.4 has both bug fixes and new features. http://gnuradio.org/releases/gnuradio/gnuradio-3.6.3.1.tar.gz http://gnuradio.org/releases/gnuradio/gnuradio-3.6.4.tar.gz MD5 sums: c05a20a380532b7bce45465ba247f2d6 gnuradio-3.6.3.1.tar.gz 320a7f18593ec493e1061141f23c9a86 gnuradio-3.6.4.tar.gz Enjoy! Johnathan Corgan Corgan Labs Contributors: Balint Seeber Ben Reynwar Johnathan Corgan Josh Blum Julien Olivain Martin Braun Mike Jameson Nicholas Corgan Roy Thompson Sylvain Munaut <246...@gmail.com> Tim O'Shea Tom Rondeau Important new features (3.6.4): Ability to set processor affinity for GNU Radio blocks Tom Rondeau has implemented the ability to set processor affinity per block in a flowgraph. This allows the developer to limit the execution of a GNU Radio block thread to a set of one or more cores, helping optimize inter-core resources in a multicore system. See: http://www.trondeau.com/home/2013/2/7/block-core-affinity.html Inclusion of gr_modtool by Martin Braun Previously available as a stand-alone utility, the gr_modtool application for creating out-of-tree GNU Radio blocks has been integrated within the main GNU Radio software distribution. The features and functionality are the same, but it is now no longer necessary to download this separately. See: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules Use of GNU Radio preferences in native C++ applications Tom Rondeau has ported the GNU Radio preferences system to allow its use in GNU Radio applications implemented in C++. Prior to this, it was only possible to access the preferences file from Python. Until the new manual is updated on gnuradio.org, you can see the raw commit here: http://gnuradio.org/cgit/gnuradio.git/commit/?id=3643a858 Addition of GNU Radio block performance counters Tom Rondeau has implemented a new capability to allow monitoring of peformance statistics of blocks inside a running flowgraph. This is an experimental feature that has not received a great deal of usage. For more details, see: http://gnuradio.org/redmine/projects/gnuradio/wiki/PerformanceCounters Minor features/changes (3.6.4): atsc: added single decode Python script (Ben Reynwar) atsc: made equalizer taps accessible in python. (Ben Reynwar) blocks: added 3.7 API versions of count_bits, threshold, strech, throttle (Tom Rondeau) blocks: added 3.7 API versions of peak_detector2, regenerate, transcendental (Tom Rondeau) cmake: added Fedora 18 packaging information (Nicholas Corgan) cmake: allow 64-bit systems to use Boost in non-standard locations (Nicholas Corgan) core: added min_noutput_items to gr_block API (Ben Reynwar) core: added operator == for tags (Martin Braun) core: added remove_tag_item() (Martin Braun) core: enabled msg_connect within python blocks (Roy Thompson) core: added gr_random_pdu message passing block (Tim O'Shea) core: added gr_fastnoise_source, default for gr_channel_model (Tim O'Shea) core: added GRC callback for gr_throttle sample_rate (Tim O'Shea) core: added a mutex to gr_block to sync setters and work function (Tom Rondeau) digital: improved constellation_receiver_cv documentation (Ben Reynwar) digital: made the demod examples clearer (Martin Braun) digital: added simple_correlator (inverse of simple_framer) to gr-digital. gruel: changed scoped_lock mutex to account for Boost deprecation (Johnathan Corgan) grc: pull in documentation for blocks from other GR modules. (Julien Olivain) howto: added example for Python blocks (Martin Braun) pmt: added python converters (Martin Braun) uhd: added click to change freq for uhd_fft (Mike Jameson) wxgui: dead code removal and formatting cleanup (Sylvain Munaut) wxgui: implemented persistence without using glAccum (Sylvain Munaut) Bug fixes (3.6.3.1, 3.6.4): analog: fixed floating point accuracy issue in CTCSS squelch (Tom Rondeau) blocks: fixed use of bare boost::mutex::scoped_lock (Johnathan Corgan) blocks: fixed missing include in file_source_impl (Josh Blum) cmake: fixed chrono as a necessary Boost library under MSVC (Nicholas Corgan) cmake: allow user to override check for bad versions of boost (Tom Rondeau) cmake: disable certain Boost versions we know are buggy to fix Issue #513. (Tom Rondeau) cmake: fixing generated includes, deps, and header installation. core: fixed gr_pdu_to_tagged_stream XML for type (Johnathan Corgan) core: fixed gr_message_debug for
Re: [Discuss-gnuradio] Resistance? Capacitance? Inductance?
http://staff.washington.edu/jon/gr-mrfm/ USRP and GNU Radio controlling micromechanical oscillators for Magnetic Resonance Force Microscopy (MRFM). Does that count? -John On Tue, Feb 26, 2013 at 2:10 PM, Joel Mayer wrote: > ** > Dear GNU Radio aficionado's- > > Whatever happened to resistance, capacitance, and inductance? > When I joined this thread I was hoping you would once in a while > talk about ways of using the software in the computer to modify > the resonant circuit in the hardware radio by making adjustments > to the resistors, capacitors, and inductors. > > Am I just dreaming? Am I on the wrong page? Is there any hope? > > > ___ > 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] Questions about fhss_engine.py
Hi, I have read the fhss_engine.py file.It seems that they send timed information via msg.And it's impossible to recevie any bit unless they use external synchronization.Is it right?Any suggestion would be appreciated. Thanks./ /// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Padding for USRP
In gnuradio/digital/packet_utils, the packets are padded to make it a multiple of 512 bytes to be sent across the USB(As per the comment there). USRP2 and N210 uses ethernet connection. Is it important to have padding for USRP in for these devices? If so is it the same number? ( 512 bytes to be sent across ethernet ) Thank you in advance. -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Padding for USRP
On 02/26/2013 08:03 PM, Manu T S wrote: > In gnuradio/digital/packet_utils, the packets are padded to make it a > multiple of 512 bytes to be sent across the USB(As per the comment there). > > USRP2 and N210 uses ethernet connection. Is it important to have padding > for USRP in for these devices? If so is it the same number? ( 512 bytes to > be sent across ethernet ) > You should not need any padding. All of the devices (except usrp1) send samples encapsulated in a packet format so the boundaries of the samples are known by the device. I dont think you need the padding for USRP1 either, since UHD will flush out the buffer to a 512 byte multiple if it sees the EOB specified. -josh > Thank you in advance. > > > > ___ > 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] Scheduler Question
I've been reading through the code in gnuradio-core/runtime for a few days to understand the internal workings of the gnuradio scheduler. It seems to me that gnuradio was originally based on a synchronous dataflow (sdf) model of computation and the single thread schedule is an SDF sequential runtime schedule, or a periodic admissible sequential schedule (PASS), and the thread per block schedule is a parallel SDF scheduler, or a parallel admissible parallel schedule (PAPS). Does this sound like an accurate description of the schedulers and underlying gnuradio model of computation or am I reading too much into it? thanks -- Almohanad (Al) Fayez ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
