Re: [Discuss-gnuradio] CMake/SWIG build problems
> It compiles without any errors or warnings, but when I try to import my > module, I get "undefined symbol" errors. I looked at the swig shared > library file using "nm" and noticed that I have lots of undefined > symbols in the part that contains my former drm_init module. The C++ > shared library seems fine, so I guess it's a SWIG problem. > You probably have some class or function thats defined in a header and either missing from the library or not exported. SWIG basically uses all of the functions/classes you feed it. So anything missing, so long as it was defined in a header you fed to swig, is going to be heard about when you import the module. Are you compiling with -fvisibility=hidden? you need to declare any public symbols to be default visibility http://gcc.gnu.org/wiki/Visibility Just a guess, -josh > I would really appreciate it if somebody could give me a hint how I can > configure CMake / SWIG correctly. The current (working) configuration > can be found on github.com/fewu. The custom make file can be found under > misc/, the other in the swig/ folder. > > Best regards, > Felix > > > > > ___ > 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
Re: [Discuss-gnuradio] making a custom block with no specific/fixed relationship between input and output rates
On Tue, Aug 14, 2012 at 08:44:20AM -0700, Zing Yu wrote: > I have a rather open question for you guys this time. I need to make a custom > block with no specific/fixed relationship between input and output rates. More > precisely, the input(s) to my custom block still come in a streaming fashion > but the output is now bursty and aperiodic in nature. In other words, my > custom > block should consume/accept the input(s) at regular rates but should produce > (possibly variable number of) samples at its output(s) only when it pleases. > Therefore, I cannot derive my class from any of the gr_sync_block, gr_block, > gr_sync_decimator, gr_sync_interpolator parent classes. What other options do > I > have in my hand to accomplish this job? Any suggestions? You *can* derive from gr_block. The OFDM detector block does this. 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 pgpqAkwJJ79Ox.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] making a custom block with no specific/fixed relationship between input and output rates
Hello everyone, I have a rather open question for you guys this time. I need to make a custom block with no specific/fixed relationship between input and output rates. More precisely, the input(s) to my custom block still come in a streaming fashion but the output is now bursty and aperiodic in nature. In other words, my custom block should consume/accept the input(s) at regular rates but should produce (possibly variable number of) samples at its output(s) only when it pleases. Therefore, I cannot derive my class from any of the gr_sync_block, gr_block, gr_sync_decimator, gr_sync_interpolator parent classes. What other options do I have in my hand to accomplish this job? Any suggestions? Thanks, Yu.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Creating signal processing blocks in Python on Windows
That was indeed the error. Thanks again for the help! Regards, Tomas On Tue, Aug 14, 2012 at 2:30 AM, Josh Blum wrote: > > > On 08/13/2012 04:40 AM, Tomas Johansson wrote: >> Thank you for your help! It seems that the problem is with my gnuradio >> installation in general rather than with my signal processing block >> implementation. When I add an Extras:divide block to an existing >> example in grc everything works fine, but when I add an >> Extras:packetframer block (which is implemented in Python) to the same >> example it crashes when the python script specifies how the blocks are >> connected, right before the >> >> self.connect((self.gr_null_source_2, 0), (self.extras_packet_framer_0, 0)) > > Its probably an error about matching IO types. The packet framer is > tectonically supposed to input messages and output a byte stream. It > could be fed by a stream_to_blob block for example > > -josh > >> >> line. I get some Traceback written to the wxPython window, but >> unfortunately it closes before I can see what it says. >> >> I have added the gnuradio\lib\site-packages and >> gnuradio\lib\site-packages\gnuradio directories to my PYTHONPATH. >> >> Any further help would be most appreciated. >> >> Regards, >> Tomas >> >> On Fri, Aug 10, 2012 at 7:15 PM, Josh Blum wrote: >>> >>> >>> On 08/10/2012 07:48 AM, Tomas Johansson wrote: Hi all, I have recently installed GNU Radio on Windows according to the instructions at http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows, and have played around with some simple examples in GNU radio companion. No problems there. But I am not sure which steps you should take in order to be able to use blocks you have written yourself in Python (using GrExtras) in radio companion. Modifying/adding xml files in share/gnuradio/grc/blocks seemed to add my new block to the list of available blocks, but when I try to execute I get the message Win32; Microsoft Visual C++ version 10.0; Boost_104700; UHD_003.004.003-release Using Volk machine: sse2 >>> >>> The above 2 are typical prints from libvolk and libuhd, thats good. >>> and nothing else happens. I have not been able to find an answer in the online documentation. I apologize in advance for the basic question. >>> >>> You should really only need to put the block into your PYTHONPATH, you >>> know, so that you can import it using the python interpreter. >>> >>> As far as GrExtras, I havent used it on windows. Just made sure it >>> builds and unit tests pass. Have you built/installed GrExtras from >>> source? Set PATH and PYTHONPATH? Able to use and call into blocks from >>> this project? >>> >>> As far as the error above, is it freezing there? returning to the >>> terminal? It could be a segfault. It would be very helpful to find out >>> what the last line in the python app was before the app got to that >>> state. Was it run()/start()? >>> >>> -Josh >>> >>> ___ >>> 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio PER encoder/decoder
To add my $0.02: I generally agree with Martin on this one. I think the generic question, i.e. should GNURadio entertain things outside traditional 'signal-processing/RF comms/digital comms/etc.' is: absolutely. If someone wants to use the GNURadio flowgraph structure to build a better mousetrap, go for it. If they feel that the structure breaks down at some point and need to pass it off via source/sink to some external process, then they should be free to go that way as well. The bigger issue, which I think Marcus was aiming at, is what blocks belong in the mainline distribution of GNURadio. With the restructuring (gr-digital/etc.) perhaps there could be some structure that allowed higher layer processing blocks (which may/may not include ASN.1-style parsing), but perhaps that sort of thing should be encouraged to exist out-of-tree. But my main point is that I don't think we should limit ourselves to merely being a radio-signal processing engine (or even a generic signal-processing engine: since obviously people are doing signal processing that is not radio-related with the framework). So - my suggestion would be to throw those things over to CGRAN (or Github, if that's your preference), but still to do everything we can to encourage that sort of thing. After all, the important thing here is that although the signal processing flowgraph may be the most interesting piece (at least to most of us here), it is the complete application that people want: not just a piece of a complete solution. Doug On Mon, Aug 13, 2012 at 3:44 AM, Martin Braun (CEL) wrote: > On Sun, Aug 12, 2012 at 01:28:03PM -0400, Marcus D. Leech wrote: >> >> [...] >> Where do we draw the line as to what consitutes a "reasonable" thing >> to be done inside the Gnu Radio framework, and something that >> is best done elsewhere? Modern operating systems, like Linux have >> a rich palette of IPC mechanisms that are specifically designed to >> facilitate functional decomposition, and yet I continue to see >> people wanting to stuff everything into the Gnu Radio framework. >> Gnu Radio >> is developing an increasingly-well-deserved reputation as >> "bloatware", precisely because we tend to entertain the notion that >> "if it starts >> or ends as a radio(-like) signal, then we're your one-stop-shop". >> > > Yay, a rant leading to a discussion! What a fabulous way to return back > to work. > > GNU Radio, as we all know, is really not that specific to baseband > processing. Its main assets are the block structure (which makes it > modular) and the scheduler, as well as the richness of core blocks > (including gr-digital, gr-filter etc.). > > Adding blocks (in particular, to your own module) therefore does not > make it bloated: the core stays lean and mean, and the fringes become > more diverse. > > So, I'm all for it (by 'it' I mean writing whatever you want in GNU > Radio). At some point, a developer will realize that the > block-and-stream structure really won't help, and that's when you > connect something else via IPC. But a packet encoder might suit the GNU > Radio structure just fine. > > 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 > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to simulate a Zoom in FFT display ?
In the Frequency Xlating FIR filter just put a decimation factor and output that to FFT. This will be "zoomed" to the center frequency by the decimation factor. For example if you have a 1M sample rate file, and pass it through a decimation of 4, you will get an FFT "zoomed" to a 250 kHz bandwidth. Is that what you want to achieve? Also the center frequency parameter (in that FIR filter) can be a variable linked to a GUI slider so that you can interactively move the center frequency you are zoomed on. On Sun, Aug 12, 2012 at 1:28 PM, William Pretty Security wrote: > Hello all; > > > > I have a 40KHz carrier that I want to be able to check for modulation. > > The ‘source’ is the audio source in GnuRadio Companion. > > > > I have tried a number of things and nothing seems to work for me. > > I have the source, followed by a 40KHz Bandpass filter and a frequency > translating FIR filter block. > > The output of the BPF and FIR filters go to separate FFT GUI’s so that I can > see what is going on. > > > > What I am trying to implement is the equivalent of the “Span” and “Center > Frequency” functions on a spectrum analyzer. > > The Center Frequency is easy, using the Translating FIR block, but I can’t > figure out how to do the Span/Zoom function. > > > > I Google searched and found a couple of SDR’s with this function, but it > appears to be “hard coded”. > > > > Does anybody know how to this in GnuRadio Companion ?? > > > > Thanks … > > > > Bill > > > ___ > 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] CMake/SWIG build problems
Hi all, I am currently preparing a release of my DRM transmitter blockset. This package shall contain my GNU Radio blocks and a set of classes (no blocks) used for initializing the transmitter parameters before the flow graph is started. At the moment, I have a source tree generated by gr_modtool based on CMake that contains my GNU Radio blocks and creates the python module "drm" and a second folder containing the classes for initializing where I wrote the .i file myself and compile everything by hand. This folder ends up in "drm_init". Everything works fine if I do it like that but it's quite inconvenient. Now I'd like to combine these two build processes in the CMake build and the two modules in one. My first try was to add the source files in the CMakeLists file in lib/, the header files in include/. Then I added everything from my custom swig file in the existing one in swig/. It compiles without any errors or warnings, but when I try to import my module, I get "undefined symbol" errors. I looked at the swig shared library file using "nm" and noticed that I have lots of undefined symbols in the part that contains my former drm_init module. The C++ shared library seems fine, so I guess it's a SWIG problem. I would really appreciate it if somebody could give me a hint how I can configure CMake / SWIG correctly. The current (working) configuration can be found on github.com/fewu. The custom make file can be found under misc/, the other in the swig/ folder. Best regards, Felix ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Limitations of gr_block: max_possible_items_available = 8191
On Tue, Aug 14, 2012 at 12:52:11PM +0200, l...@epsilon-formacion.com wrote: > Hello, > > I created a block with a variable input rate, but when I run the flowgraph I > get the following error: > > sched: is requesting more input > data > than we can provide. > ninput_items_required = 16000 > max_possible_items_available = 8191 > If this is a filter, consider reducing the number of taps. > > If I don't exceed the limit of 8191 items the block works correctly but I need > to exceed this limit for the experiments I'm doing. > > Is this a limitation of gr_block? Is there any way to exceed this limit? I believe this is to do with the buffer limits between blocks (which are set by the Linux kernel). Do you *really* need this many input items per output item? If so, you can also buffer manually, inside the block--here, there are no limits other than the amount of RAM you have. > In the other way I tried to use gr_sync_decimator but does not work because > sometimes I need to consume 16000 ninput_items, sometimes 15999, and so on, > and > gr_sync_decimator seems to have a fixed rate. Yep, it's fixed. Use a gr_block, and use set_relative_rate() to 1.0/16000 or whatever. 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 pgppKi8TECRfh.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Limitations of gr_block: max_possible_items_available = 8191
Hello, I created a block with a variable input rate, but when I run the flowgraph I get the following error: sched: is requesting more input data than we can provide. ninput_items_required = 16000 max_possible_items_available = 8191 If this is a filter, consider reducing the number of taps. If I don't exceed the limit of 8191 items the block works correctly but I need to exceed this limit for the experiments I'm doing. Is this a limitation of gr_block? Is there any way to exceed this limit? In the other way I tried to use gr_sync_decimator but does not work because sometimes I need to consume 16000 ninput_items, sometimes 15999, and so on, and gr_sync_decimator seems to have a fixed rate. Thank you in advance. Best regards. Luis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
