Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.
On Thu, Sep 19, 2013 at 10:45 AM, Tim wrote: > > Docs can take a long time to build, so when doing multiple builds a day > during testing you really don't want to have this turned on. Likewise if > you are building on slow machine or an older machine without sufficient > doxygen. But obviously they are valuable for users doing their primary > build who want to use the docs. > > I'm thinking it might make sense to just prompt the user when pybombs sets > up its environment and asks for things like the prefix directory - for it to > also ask the user whether they want to build documentation in general for > all the recipes they will be building. > > The main issues with this are, > 1. there are not currently recipes for doxygen and it's dependencies - those > would need to be written and would pull in a bunch of latex, perl, > ghostscript, etc -- > 2. the dependencies for gnuradio need to change based on enabling/disabling > this feature - we don't have a good mechanism yet in pybombs for turning > deps on or off based on recipe "options", but we could add something like > this fairly easily > > At the end of the day we do have a choice now between trying to keep build > configurations fairly static and simple (defined only by their recipe set > and guaranteed for repeatability - which is great for performing repeatable > testing, versioning, and packaging) or allowing it to become a monolithic > thing that has lots of different user prompted states and options. It's > not clear that we can't achieve both - but we would sacrifice a bit of > conciseness and recipe simplicity to get there > > -Tim At the least, we'll want to get a recipe for Doxygen, which is going to entail a large number of dependencies, too, so it might take some time to get all of those recipes right. At that point, it should be easy enough to just edit gnuradio.lwr to turn on Doxygen for those who really want it. Also, remember that we host the documentation online, including many of the past versions, the most recent released version, and the current master updated weekly: http://gnuradio.org/redmine/projects/gnuradio/wiki/Old-docs And one of the GSoC projects going on this year was to make some improvements to GRC, including access to the online manual documentation for given blocks, so requiring them to be built locally might not be as important once we get this work rolled in. Tom > On 09/19/2013 09:59 AM, Tom Rondeau wrote: > > On Wed, Sep 18, 2013 at 3:48 PM, M Dammer wrote: > > May I then suggest to enable the docs in the pybombs recipe by default > as well ? > > You may suggest. > > Sorry for being glib. I also think it's a good idea to enable the > documentation by default. If Tim agrees and there wasn't a technical > reason why it was turned off in the first place, I think we can change > it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Constellations in OOT projects
On Fri, Sep 20, 2013 at 7:55 PM, Michael Berman wrote:
> I am attempting to add a custom constellation class to be used with the
> generic_mod_demod object for digital PSK. I have the code working as a
> simple addition to the gnuradio source with a re-compilation, however I
> would like to set this up similar to an Out Of Tree module (although it
> isn't entirely a standalone module). Would the way I go about approaching
> this be the same as the adding an Out Of Tree module tutorial on the
> gnuradio website? Or would there be a preferred method than the gr_modtool.
> I would like to set this up so that the code I add sits in the gr::digital
> scope and have everything look as though it all sits in the
> constellation.{cc, h, i} files. Does anybody have recommendations for
> attacking this task?
>
>
> Thank you very much,
>
> Michael Berman
Hi Michael,
Please use a proper subject line in the future to help us sort and
keep track of things.
As to your question, that shouldn't be a problem. You should be able
to create a class in your OOT module and inherit from
gr::digital::constellation (or one of it's children). And just putting
it inside the gr::digital namespace. This will obviously now exist in
your own lib.so and not in libgnuradio-digital.so. So I'm
not sure what you mean by "sits inside constellation.{cc,h,i}". If you
are in an OOT project, you wouldn't be able to add this directly to
the gnuradio-digital library or Python module (ok, there's a way to do
the latter by smashing it in during install, but that's seriously ugly
business that you want no part of).
And use gr_modtool. Definitely the best, easiest, and preferred way of
setting things up. When creating your new class, use 'gr_modtool add'
and for the 'code type' use 'noblock.'
--
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multiple asynchronous channels in parallel
On Wed, Sep 18, 2013 at 3:20 AM, alyafawi wrote: > for a single channel (quite stable): > > USRP -- LPF -- Module -- > > for multi channel (exit with segfault) > > -- LPF -- Module -- > USRP -- LPF -- Module -- > ... > -- LPF -- Module -- > > I am using xlating_fir_filter_ccf with the proper frequency offset value. > > > I have attached a draft of my module block, pleased to have a look at it if > I am producing/consuming samples wrongly. > > Yes, I am defining nitems_items_required in the forecast. input/ output size > as follow: >gr_make_io_signature(MIN_IN, MAX_IN, sizeof(gr_complex)), >gr_make_io_signature(MIN_OUT, MAX_OUT, 23)), > whenever I found I message, I convert it to char array, and send it to the > next module. > > I am using gr_block where it accept different ratios of input/output rates. > But with my current implementation, this ratio is not M:N, where M, N are > integers, it can be any ratio (nitems:sample_number as in the attached file) > > From my understanding to the scheduler, the left over samples in the module > (provided = X, consumed = Y, left = X-Y) will be concatenated in the front > of the new stream, regardless how much was left. Yes, that's correct. > could it be I have to keep the provided:consume ratio as an integers ratio? > then I achieve this using local buffers in the module ? The ratio doesn't need to be an integer. > I checked the timestamp of messages captured by two USRPs running single > channel code in parallel, the resolution was within one symbol duration > (1/R). while the multi channel code, showed a difference of more than one > symbol duration (> 1/R) which I thought its due to samples disorder while > splitting the branches. That lead me to the first question about "faster" Unfortunately, there is only so much I can do to help you with these problems. As I said, you seem to have a good grasp on what's supposed to happen. I have a feeling you're just implementing something wrong. My advice again is to not use a USRP for debugging the block. Create a simulation of 2 channels of data and feed that in and keep track of how many you're consuming, how many you're producing, the message sizes, etc. Often, when it comes to these problems, I find it really helpful to draw out the buffers and the boundaries and walk through it step by step to make sure I'm taking care of all items correctly. -- Tom GRCon13 Oct. 1 - 4 http://www.trondeau.com/grcon13 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Regarding Boost message queue
On Wed, Sep 18, 2013 at 3:27 PM, NaceurElOuni wrote: > Hi, > > I am developping some source code using a boost shared pointer > gr_message_sptr > which is retrieving from a queue (gr_msg_queue_sptr), > The issue is that when calling : > > gr_message_sptr mesg = queue->delete_head_nowait(); > > from within a while loop (BTW the queue itself is being passed from a thread > function to a subsequent function which process it), > > I got an error stated as: > > ... /usr/include/boost/smart_ptr/shared_ptr.hpp:424: T* > boost::shared_ptr::operator->() const [with T = gr_message]: Assertion > `px != 0' failed. > Aborted (core dumped), > Even after googling the issue I got no clear explanation of am I doing wrong > or missing. > > All clarifications are welcome, thank you, > > Regards, This is very little information to go on. But it looks like you aren't initializing your messages correctly. It's core dumping. Do a search for how to create a core dump file and read it with gdb; that can give you a lot more information about where and why things are breaking. -- Tom GRCon13 Oct. 1 - 4 http://www.trondeau.com/grcon13 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about adding your own classes
On Fri, Sep 20, 2013 at 7:13 PM, Martin Braun (CEL)
wrote:
> Hi Tommy,
>
> is this a visibility issue? Did you use modtool to add the additional
> classes? If not, do you have a FOO_API macro in your class def?
>
> MB
Tommy,
Yes, make sure that the FOO_API is declared for the classes. Also, you
have to make sure they are being imported into the swig module
correctly in gr-foo/swig/foo_swig.i.
You can use gr_modtool with the class type "noblock" to create classes
that are not gr::blocks for this purpose, which will set up the cmake
and swig files correctly.
> On Fri, Sep 20, 2013 at 01:58:16PM -0400, Tommy Tracy II wrote:
>> Dear List,
>>
>>
>> I am using gr_modtool to create new modules and blocks, and I have a question
>> about adding additional .cc/.h files that are not included by gr_modtool to
>> the
>> cmake file or otherwise importing them by hand.
>>
>>
>> My new blocks are dependent on two new classes called NetworkInterface.{cc,h}
>> and EthernetConnector.{cc,h}. During the make process, if there is a syntax
>> error in either of these files, the compiler will alert me. I was able to fix
>> all problems and get the cmake, make, and make install completed. The problem
>> manifested itself when I attempted to import the module:
>>
>> --
>>
>> >>> import router
>>
>> Traceback (most recent call last):
>>
>> File "", line 1, in
>>
>> File
>> "/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/__init__.py",
>> line 45, in
>>
>> from router_swig import *
>>
>> File "/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/
>> router_swig.py", line 26, in
>>
>> _router_swig = swig_import_helper()
>>
>> File "/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/
>> router_swig.py", line 22, in swig_import_helper
>>
>> _mod = imp.load_module('_router_swig', fp, pathname, description)
>>
>> ImportError: /home/tjt7a/Src/target/lib/libgnuradio-router.so: undefined
>> symbol: _ZN16NetworkInterface7connectEPc
>>
>> --
>>
>> To investigate the definition of this symbol, I ran c++filt
>>
>> --
>>
>> $c++filt _ZN16NetworkInterface7connectEPc
>>
>> NetworkInterface::connect(char*)
>>
>> --
>>
>> This indicates, that my libgnuradio-router module cannot access the
>> NetworkInterface object file, even though it was part of the compilation
>> step.
>>
>>
>> My thought process was to create the two shared object (.so) files by hand,
>> and
>> move them to my python path location. So I did that:
>>
>> --
>>
>> cc -shared -o libEthernetConnector.so -fPIC EthernetConnector.cc
>>
>> cc -shared -o libNetworkInterface.so -fPIC NetworkInterface.cc
>>
>> I then copied them to the location of my gnuradio .so files
>>
>> --
>>
>>
>> Unfortunately, this still hasn't solved the problem. Does anyone know a
>> solution to this problem?
>>
>>
>> Tommy James Tracy II
>>
>> Ph.D Student
>>
>> High Performance Low Power Lab
>>
>> University of Virginia
>>
>> Phone: 913-775-2241
>>
>>
>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> --
> 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
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
--
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error using Packet Decoder block in 3.7
On Sat, Sep 21, 2013 at 12:29 AM, Vanush Vaswani wrote: > The following error is thrown when trying to run dpsk_loopback.py in > gr digital examples. > > File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/blks2/packet.py", > line 243, in recv_pkt > msg = blocks.message_from_string(payload, 0, self._item_size_out, > AttributeError: 'module' object has no attribute 'message_from_string' > > Any advice? Update your GNU Radio version. This was a bug introduced in the renaming of things from 3.6 to 3.7 (my sed was a little to open). This is fixed in 3.7.1. -- Tom GRCon13 Oct. 1 - 4 http://www.trondeau.com/grcon13 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to specify (const char *) type in xml
Hello Everyone. I have made an OOT module gr-ldpc. The ldpc encoder loads the parity check matrix data from a file. The constructor of this class takes as input the file name as parameter of type " const char * ". I used following in param sector in the xml file. - File alist_file const char * I also tried using the following File alist_file str -- To specify the file in the encoder block (in grc) I made a variable block and specified the file name within double quotes "file_name", and used the variable_id in place of the corresponding parameter in the encoder block. In both the cases the block is colored red and I can't run the flow-graph. What could I use to specify the file name? -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to specify (const char *) type in xml
Got fixed when I used file_open type. On Sat, Sep 21, 2013 at 11:50 PM, Manu T S wrote: > Hello Everyone. > > I have made an OOT module gr-ldpc. The ldpc encoder loads the parity check > matrix data from a file. The constructor of this class takes as input the > file name as parameter of type " const char * ". > > I used following in param sector in the xml file. > - > > File > alist_file > const char * > > > > I also tried using the following > > > > File > alist_file > str > > -- > > To specify the file in the encoder block (in grc) I made a variable block > and specified the file name within double quotes "file_name", and used the > variable_id in place of the corresponding parameter in the encoder block. > In both the cases the block is colored red and I can't run the flow-graph. > > What could I use to specify the file name? > > -- > Manu T S > -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Updating gr-specest to 3.7
:-) I gave it a good lube job and it mostly works now... Still in need of the full tune up to change everything over to the new namespace. I'm still seeing some issues, like did the pad_vector function ever work? It seems to be missing some pieces. I slapped a GRC wrapper together, but it doesn't seem to actually pad things. Jared ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
