Re: [Discuss-gnuradio] PYBOMBs Testing
[ 65%] Building CXX object gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_s_impl.cc.o [ 65%] Building CXX object gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_i_impl.cc.o [ 65%] Building CXX object gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_b_impl.cc.o Linking CXX shared library libgnuradio-blocks-3.7.3git.so [ 65%] Built target gnuradio-blocks make: *** [all] Error 2 ERROR:root:PyBOMBS Make step failed for package (gnuradio) please see bash output above for a reason (hint: look for the word Error) That message is useless ... with a parallell build, the error can be _much_ before the end of the logs so you need to looks for it at any point before the end. That's also why it seems to go a little further each time, it's because the various parallell branch, only one crashes and the other slightly go forward. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fw: packet encoder purpose
On Tue, Jan 07, 2014 at 04:47:44AM -0800, Irfan Ullah wrote: On Tuesday, January 7, 2014 2:54 PM, Irfan Ullah irfancoms...@yahoo.com wrote: Hello everyone, can someone tell me the purpose of packet encoder/decoder? Irfan, the first message came through, there is no need to repeat it. When writing messages like these, it helps to specify what you've tried to figure out the solution. Short answer: These blocks append a bit sequence at the tx side, and find the rx sequence on the rx side to find the first bit of a packet. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] USRP N210 Signal Phase Issue
May it be just some lost packet or smth. like that? It looks very similar when USB does not catch up when using my USRP1 and BladeRF... Missing samples can create funny signals. Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Matt Ettus Sent: Wednesday, January 08, 2014 2:25 AM To: Jonathan Fox Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] [USRP-users] USRP N210 Signal Phase Issue It could be the usrp digitally clipping, not the analyzer. Matt On Tue, Jan 7, 2014 at 5:17 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: On Tue, Jan 7, 2014 at 7:11 PM, Marcus D. Leech mle...@ripnet.com wrote: Try reducing the amplitude to 0.7. Another possibility is that your computer can't keep up. If you are using one of the standard programs, are there U's printing in the terminal? Matt Also, what RF gain are you setting? Does it exceed the maximum input level of the spectrum analyser? Are you connected directly, or with an antenna? On Tue, Jan 7, 2014 at 3:03 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: A colleague and I are sending a simple signal in GNU Radio (sine wave, 1 MHz, amplitude of 1) to the USRP sink and have the center frequency at 500 MHz. The N210 USRP is hooked up to an Agilent spectrum analyzer. On the analyzer we are seeing a weird phenomena every two seconds. At first we see the carrier frequency and two sidebands from the sine wave (see attached normal.gif). Then after two seconds we get two bursts of multiple harmonics (see odd.gif). The question is, why is this happening? Does the phase of the 1 KHz signal become discontinuous before or after being sent to the USRP? Thanks, Jon Fox ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I don't recall seeing any U's but I can recheck tomorrow. The gain on the USRP was set to -2. The USRP was connected directly with an SMA cable. The analyzer is an Agilent E4440A, the Analyzer is rated for at least 1 Watt on average, 100 Watt on a peak pulse (with the built-in attenuator in use). While I am not ruling out the maximum input I thought the N210 tops out at 0.5 Watts due to FCC regulations. Thanks Jon ___ 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] QAM modulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, that could be possible... But why would you do that? For simple QAMs there are decoders available, and for unavailable QAMs you'd simply implement your own constellation class. Please refer to the GNU Radio API reference for further information on constellation mappers. Greetings, Marcus On 08.01.2014 08:10, Irfan Ullah wrote: Hello all, is it possible to design our own block of QAM from small blocks like filters, synchronizers, adders etc. regards, Irfan Ulllah ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSzTogAAoJEAFxB7BbsDrLemgH/jB67dr1wibQEpONNUS4rdCq FjNALnKZeAL5oQ9c+c9cotgwAegJEfmwcvFaNVJBadOJJJrE77dWLeWVth9tq0rd GegM/0Iv9R5MLiFftoHrLOFUNeMhg2vk4383R4dki2/ZS6RLllkSkusrxLJ2aweQ 30hkIPSJ6mQxO7pb5YZTL2dEoqHCceoWW2xfuoPmIS23UuNpv6l1YcYeG9AApbp6 /A9KSpL7/Wm1ASW/MdlPOHqx/lgDObSZS5mZcofgkZ2hVdDmKi0KTQ+/C+nyD3+e Utx0ObKqmz7fxy7FfpJ8vkSYze179KXkriIeKtF+N9GMemBb0RTrdYpbM8q/Axk= =7aaP -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Variable Delay Error
On Wed, Jan 8, 2014 at 7:34 AM, António Gomes agome...@gmail.com wrote: Hi all, I'm trying to make a delay on a signal with a variable delay with a WX GUI Slider. When i run the simulation and try to add a delay on a sinusoidal signal it gives me this error: This is a problem with typing between Python and C++. The delay block wants (demands, really) an integer value, but your slider is passing back a float. In the delay block, cast it as int(delay_slider). Also, you can use the delay block from GNU Radio; it allows variable delays. There's nothing wrong with using the blocks from gr-baz, but I would recommend you use blocks that are directly part of GNU Radio when they are available. Mostly because more of the community will be more familiar with them. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM modulation
On Wed, Jan 8, 2014 at 6:44 AM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, that could be possible... But why would you do that? For simple QAMs there are decoders available, and for unavailable QAMs you'd simply implement your own constellation class. Please refer to the GNU Radio API reference for further information on constellation mappers. Greetings, Marcus Indeed. This is a good place to start: http://gnuradio.org/doc/doxygen/page_digital.html Tom On 08.01.2014 08:10, Irfan Ullah wrote: Hello all, is it possible to design our own block of QAM from small blocks like filters, synchronizers, adders etc. regards, Irfan Ulllah ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] followup: libgnuradio-fcd-3.7.3git.so.0.0.0: undefined reference to `libusb_handle_events_completed'
OK, this error seems to be all fixed now, but as a result I now have a doubt about pybombs . [The background of the problem is in the previous posting (yesterday) about this, but essentially the problem started when I changed the pybombs recipe for libusb in order to force pybombs to build libusb from source rather than to use the libusb-1.0-0-dev (that was originally set in satisfy_deb). ] Once this was changed, pybombs did in fact fetch the libusb source and built that - however, subsequent compiles were still looking in /usr/include for the .h files (and finding the old, bad ones). I bypassed that error. Then the linker also bombed out, again where pybombs should have looked in its own built-from-source copy of libusb. At that point I posted the first message about the linker problem late last night... I offer the following message as 'documentation' of the claim that pybombs is still trying to link against the system copy of libusb and not its own local copy of libusb that it built from source... Note that it prints the library location... make[2]: *** No rule to make target `/usr/lib/x86_64-linux-gnu/libusb-1.0.so', needed by `gr-fcd/lib/libgnuradio-fcd-3.7.3git.so.0.0.0'. Stop. After I fixed that, gnuradio compiled cleanly under pybombs... Best Max___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] followup: libgnuradio-fcd-3.7.3git.so.0.0.0: undefined reference to `libusb_handle_events_completed'
On 01/08/2014 04:19 PM, ikjtel wrote: OK, this error seems to be all fixed now, but as a result I now have a doubt about pybombs . [The background of the problem is in the previous posting (yesterday) about this, but essentially the problem started when I changed the pybombs recipe for libusb in order to force pybombs to build libusb from source rather than to use the libusb-1.0-0-dev (that was originally set in satisfy_deb). ] Once this was changed, pybombs did in fact fetch the libusb source and built that - however, subsequent compiles were still looking in /usr/include for the .h files (and finding the old, bad ones). I bypassed that error. Then the linker also bombed out, again where pybombs should have looked in its own built-from-source copy of libusb. At that point I posted the first message about the linker problem late last night... Same problem with libfaad2, fix recipe, and fix the cmake file that set up where to look for both header files and library. That was your solution also? Btw. I was working with gr-drm in a pybombs environment. regards George I offer the following message as 'documentation' of the claim that pybombs is still trying to link against the system copy of libusb and not its own local copy of libusb that it built from source... Note that it prints the library location... make[2]: *** No rule to make target `/usr/lib/x86_64-linux-gnu/libusb-1.0.so', needed by `gr-fcd/lib/libgnuradio-fcd-3.7.3git.so.0.0.0'. Stop. After I fixed that, gnuradio compiled cleanly under pybombs... Best Max ___ 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] PYBOMBs Testing
Thanks. I'll try single-stringing it or looking further back to catch the actual error. Very Respectfully, Dan CaJacob On Wed, Jan 8, 2014 at 3:07 AM, Sylvain Munaut 246...@gmail.com wrote: [ 65%] Building CXX object gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_s_impl.cc.o [ 65%] Building CXX object gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_i_impl.cc.o [ 65%] Building CXX object gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_b_impl.cc.o Linking CXX shared library libgnuradio-blocks-3.7.3git.so [ 65%] Built target gnuradio-blocks make: *** [all] Error 2 ERROR:root:PyBOMBS Make step failed for package (gnuradio) please see bash output above for a reason (hint: look for the word Error) That message is useless ... with a parallell build, the error can be _much_ before the end of the logs so you need to looks for it at any point before the end. That's also why it seems to go a little further each time, it's because the various parallell branch, only one crashes and the other slightly go forward. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] followup: libgnuradio-fcd-3.7.3git.so.0.0.0: undefined reference to `libusb_handle_events_completed'
On 01/08/2014 04:19 PM, ikjtel wrote: OK, this error seems to be all fixed now, but as a result I now have a doubt about pybombs . [The background of the problem is in the previous posting (yesterday) about this, but essentially the problem started when I changed the pybombs recipe for libusb in order to force pybombs to build libusb from source rather than to use the libusb-1.0-0-dev (that was originally set in satisfy_deb). ] Once this was changed, pybombs did in fact fetch the libusb source and built that - however, subsequent compiles were still looking in /usr/include for the .h files (and finding the old, bad ones). I bypassed that error. Then the linker also bombed out, again where pybombs should have looked in its own built-from-source copy of libusb. At that point I posted the first message about the linker problem late last night... I offer the following message as 'documentation' of the claim that pybombs is still trying to link against the system copy of libusb and not its own local copy of libusb that it built from source... Note that it prints the library location... Same problem with libfaad2, fix recipe, and fix the cmake file that set up where to look for both header files and library. That was your solution also? regards George make[2]: *** No rule to make target `/usr/lib/x86_64-linux-gnu/libusb-1.0.so', needed by `gr-fcd/lib/libgnuradio-fcd-3.7.3git.so.0.0.0'. Stop. After I fixed that, gnuradio compiled cleanly under pybombs... Best Max ___ 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] followup: libgnuradio-fcd-3.7.3git.so.0.0.0: undefined reference to `libusb_handle_events_completed'
On Jan. 8, 2013, George wrote: Same problem with libfaad2, fix recipe, and fix the cmake file that set up where to look for both header files and library. That was your solution also? Hate to admit, was in a hurry so I just nuked the system library copy, and replaced it with the ones that pybombs compiled. That worked, but not anywhere near as cleanly as the solution you've outlined... :-/ Best Max ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] followup: libgnuradio-fcd-3.7.3git.so.0.0.0: undefined reference to `libusb_handle_events_completed'
On 01/08/2014 06:17 PM, ikjtel wrote:
On Jan. 8, 2013, George wrote:
Same problem with libfaad2, fix recipe, and fix the cmake file that
set up where to look for both header files and library.
That was your solution also?
Hate to admit, was in a hurry so I just nuked the system library copy,
and replaced it with the ones that pybombs compiled. That worked, but
not anywhere near as cleanly as the solution you've outlined... :-/
Did not work the way I expected either, had to uninstall the system
variant before cmake found that it could actually use the variant I put
first.
I reran from cmake, but it resolved to the system header files and lib,
and I don't understand why.
The recipe is included below, while the cmake file is here:
https://github.com/rfz-com/gr-drm/commit/0f062bb97b1e742b829260653418c64520c4ee1d
faad2.lwr
---
category: baseline
source: wget://http://downloads.sourceforge.net/faac/faad2-2.7.tar.gz
satisfy_deb: libfaad-dev
#satisfy_rpm: faad2-devel
configure {
. bootstrap
./configure --without-xmms --with-drm --without-mpeg4ip --with-pic
}
install {
make
cp include/faad.h include/neaacdec.h $prefix/include
cp libfaad/.libs/libfaad.a $prefix/lib
cp libfaad/.libs/libfaad.a $prefix/lib64
}
Best
Max
___
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] Top block trash not cleaning up where it used to. File sink not writing in some instances.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Miguel, sorry to hear you have a hard time... :( On 08.01.2014 18:44, Miguel Duarte wrote: Marcus Muller: It.. kind of worked, in relation to the file sink writing. Worked in some cases but not in most (!?), it seemed up to chance really. I don't know what to think of it. :/ Me neither; Martin Braun: That solution didn't work, at least in my case. Thanks for the advice though. I guess GNU Radio needs more SWIG experts, and someone who knows who to coerce python to just do what I tell you... I've tried everything, and I'm feeling really dumb for not managing to make it work. I've switched to a more practical method, using lock() and unlock(). Don't feel dumb. But even destroying all blocks (including the file sink block) and constructing them again, it doesn't work. Also, I've switched order and it always works for the first time. There's something I'm missing. (The only blocks I'm not destroying are the USRP blocks now, but I don't think that could be it, even if the USRP was giving out weird data it would write it to file.) The thing is, since I'm not using any wxgui blocks right now and I never intended to, I don't even know how I'm supposed to debug and check if there's anything reaching the file sink. Ok, I know this is not incredibly helpful if you're dealing with very much samples, but maybe try this: - - replace file_sink by vector_sink_X - - at the end of your flowgraph run, get a numpy.array(vector_sink.data()) - - using the numpy arrays .tofile() method, save it to a file Can I extract and print in python the info going through a certain block, or something like that? Or do I have to delve into C++ territory? Can be done in python. Just write a python block that a) copies the input to the output and b) prints nitems_read() or something of the like. Hope I could alleviate your situation a little, Greetings, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSzZMsAAoJEAFxB7BbsDrLQhQIAJzSOiDJL8GQUIQk5HOKRB6o C+t5IgoBz3mmsszoCT6NQ1MaH+O+NCIJQ8QiWY37NYNSLuLikSWMJ5ioY59gatAv vP8BXRqxGYsQsC6iUvH/jcfDML33ggwAs0ZtVsD6BI0i/PDdVs6dWRq2kE6cqaZD YySH7dnKMV/xdsd2pA+V3J3sX9Z9P/UAgQdFDmI9mfAZD5o4jO3aPs/x4GxeNNZJ sc8+V3ljzMmull4xsdE325tVHstWrRB4lnF8h3wX/TiiLEvZZQhp5rFYKJkZxwwr Lk/Rq6oqaLQzUonkE3nNNXKh6RggVnZittOe7DBzb46q9XKJJWKhpFHgflMlhtc= =T0FS -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
Clayton and I worked on the FM RDS project over the last weeks. I think that the receiving side is in a pretty good state now. It works well with the RTL SDR. This is really cool! Worked right out of the box. It's decoding and displaying the local NPR station without any problems. Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC Hier block with vector IO not working as expected
Hi list, I'm currently in the process of porting my gr-drm project to the 3.7 API and now I'm a little bit stuck and hope that someone here can help me. I want to create a hier block (in GRC) that accepts vectors as input and output. Their size is controlled by parameters like vlen_in and vlen_out. Unfortunately, the IO size of the generated hier block always stays 1, no matter what I use as parameter. I attached a minimal (pure GNU Radio) example flow graph and hier block that reproduces my problem. Maybe I overlooked something obvious, but I don't get why this is not working. If someone had the time to try this and could report if it works (it does not for me), I would be very grateful. I'm on Ubuntu 12.10 and have GNU Radio v3.7.2.1-116-ge751e54a installed. Regards, Felix Wunsch example_hier_block.grc Description: application/gnuradio-grc example_fg.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] USRP N210 Signal Phase Issue
It works now, although with some U's on the console, they were there before anyways. I forgot to run systctl -w net.core.rmem_max=5000 and net.corewmem_max=1048576. As soon as I ran it the harmonics went away. On Wed, Jan 8, 2014 at 4:26 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxxwrote: May it be just some lost packet or smth. like that? It looks very similar when USB does not catch up when using my USRP1 and BladeRF... Missing samples can create funny signals. Ralph. *From:* discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto: discuss-gnuradio-bounces+ralph=schmid@gnu.org] *On Behalf Of *Matt Ettus *Sent:* Wednesday, January 08, 2014 2:25 AM *To:* Jonathan Fox *Cc:* GNURadio Discussion List *Subject:* Re: [Discuss-gnuradio] [USRP-users] USRP N210 Signal Phase Issue It could be the usrp digitally clipping, not the analyzer. Matt On Tue, Jan 7, 2014 at 5:17 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: On Tue, Jan 7, 2014 at 7:11 PM, Marcus D. Leech mle...@ripnet.com wrote: Try reducing the amplitude to 0.7. Another possibility is that your computer can't keep up. If you are using one of the standard programs, are there U's printing in the terminal? Matt Also, what RF gain are you setting? Does it exceed the maximum input level of the spectrum analyser? Are you connected directly, or with an antenna? On Tue, Jan 7, 2014 at 3:03 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: A colleague and I are sending a simple signal in GNU Radio (sine wave, 1 MHz, amplitude of 1) to the USRP sink and have the center frequency at 500 MHz. The N210 USRP is hooked up to an Agilent spectrum analyzer. On the analyzer we are seeing a weird phenomena every two seconds. At first we see the carrier frequency and two sidebands from the sine wave (see attached normal.gif). Then after two seconds we get two bursts of multiple harmonics (see odd.gif). The question is, why is this happening? Does the phase of the 1 KHz signal become discontinuous before or after being sent to the USRP? Thanks, Jon Fox ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I don't recall seeing any U's but I can recheck tomorrow. The gain on the USRP was set to -2. The USRP was connected directly with an SMA cable. The analyzer is an Agilent E4440A, the Analyzer is rated for at least 1 Watt on average, 100 Watt on a peak pulse (with the built-in attenuator in use). While I am not ruling out the maximum input I thought the N210 tops out at 0.5 Watts due to FCC regulations. Thanks Jon ___ 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] GRC Hier block with vector IO not working as expected
Hi Felix, I can reproduce it. Problem is that the generated 'xml' file is not generated correctly. The parameter 'vlen' should be written as '$vlen' in the xml files source/sink section but it is written as 'vlen'. Thus 'vlen' is treated as the value. Happens with 'v3.7.2-11-g3b27cc47'. I don't know how to fix it though. Happy hacking Johannes On Wed, Jan 8, 2014 at 12:59 PM, Felix W. wunsch.fe...@googlemail.comwrote: Hi list, I'm currently in the process of porting my gr-drm project to the 3.7 API and now I'm a little bit stuck and hope that someone here can help me. I want to create a hier block (in GRC) that accepts vectors as input and output. Their size is controlled by parameters like vlen_in and vlen_out. Unfortunately, the IO size of the generated hier block always stays 1, no matter what I use as parameter. I attached a minimal (pure GNU Radio) example flow graph and hier block that reproduces my problem. Maybe I overlooked something obvious, but I don't get why this is not working. If someone had the time to try this and could report if it works (it does not for me), I would be very grateful. I'm on Ubuntu 12.10 and have GNU Radio v3.7.2.1-116-ge751e54a installed. Regards, Felix Wunsch ___ 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] PYBOMBs Testing
OK, Here's a specific error. Seems like it's related to ICE, which compiled successfully as a dependency. Scanning dependencies of target gr_runtime_test [ 13%] Building CXX object gnuradio-runtime/lib/CMakeFiles/gr_runtime_test.dir/test_runtime.cc.o Linking CXX executable gr_runtime_test libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceInternal::IncomingBase::__endWriteParams(bool)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceInternal::BasicStream::readEnum(int)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `Ice::upCast(Ice::ObjectFactory*)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceDelegateD::Ice::Object::ice_invoke(std::string const, Ice::OperationMode, std::pairunsigned char const*, unsigned char const* const, std::vectorunsigned char, std::allocatorunsigned char , std::mapstd::string, std::string, std::lessstd::string, std::allocatorstd::pairstd::string const, std::string const*, IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `Ice::upCast(Ice::ServantLocator*)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `Ice::upCast(Ice::Logger*)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceProxy::Ice::Object::__handleExceptionWrapper(IceInternal::HandleIceDelegate::Ice::Object const, IceInternal::LocalExceptionWrapper const, IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceInternal::Ex::throwMarshalException(char const*, int, std::string const)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `virtual thunk to IceDelegateD::Ice::Object::ice_id(std::mapstd::string, std::string, std::lessstd::string, std::allocatorstd::pairstd::string const, std::string const*, IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceDelegateD::Ice::Object::ice_id(std::mapstd::string, std::string, std::lessstd::string, std::allocatorstd::pairstd::string const, std::string const*, IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `Ice::upCast(Ice::AsyncResult*)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceDelegateM::Ice::Object::ice_ids(std::mapstd::string, std::string, std::lessstd::string, std::allocatorstd::pairstd::string const, std::string const*, IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceDelegateD::Ice::Object::ice_flushBatchRequests(IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `virtual thunk to IceDelegateD::Ice::Object::ice_ids(std::mapstd::string, std::string, std::lessstd::string, std::allocatorstd::pairstd::string const, std::string const*, IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `Ice::upCast(Ice::Object*)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceDelegateD::Ice::Object::ice_ids(std::mapstd::string, std::string, std::lessstd::string, std::allocatorstd::pairstd::string const, std::string const*, IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `virtual thunk to IceDelegateM::Ice::Object::ice_ids(std::mapstd::string, std::string, std::lessstd::string, std::allocatorstd::pairstd::string const, std::string const*, IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceInternal::IncomingBase::__startWriteParams(Ice::FormatType)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceDelegateM::Ice::Object::ice_ping(std::mapstd::string, std::string, std::lessstd::string, std::allocatorstd::pairstd::string const, std::string const*, IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceInternal::Ex::throwUOE(std::string const, IceInternal::HandleIce::Object const)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceInternal::BasicStream::initReadEncaps()' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceInternal::BasicStream::read(std::vectorunsigned char, std::allocatorunsigned char )' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `virtual thunk to IceDelegateM::Ice::Object::ice_flushBatchRequests(IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `IceInternal::Outgoing::Outgoing(IceInternal::RequestHandler*, std::string const, Ice::OperationMode, std::mapstd::string, std::string, std::lessstd::string, std::allocatorstd::pairstd::string const, std::string const*, IceInternal::InvocationObserver)' libgnuradio-runtime-3.7.3git.so.0.0.0: undefined reference to `virtual thunk to IceDelegateM::Ice::Object::ice_isA(std::string const, std::mapstd::string, std::string, std::lessstd::string, std::allocatorstd::pairstd::string const, std::string const*,
[Discuss-gnuradio] a pybombs bug, plus a question
I found this bug to be very humorous ;-) In the case of a source download where the source file to be unpacked is one of tar.gz or tgz or tar.bz2 or tbz2, you had better not make the name of the recipe the same as the name of the top-level directory in the archive. If you make them the same name, guess what happens in this code in mod_pybombs/fetch.py: rmrf(self.recipe.name); os.rename(dirname, self.recipe.name); The rmrf nukes the unpacked source in its entirety ! On to the question - noticed that when pybombs builds boost it doesn't seem to be using more than one CPU - i.e., it's like make -j1 - is there a quick fix for this ? Best Max ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC Hier block with vector IO not working as expected
Hi, thanks for confirming that and pointing me to the right spot in the code. For now, I'll just fix it in the xml as I include them in the repo anyway. Is this a known bug or should I file a bug report for this? Regards, Felix 2014/1/8 Johannes Demel johannes.de...@ettus.com Hi Felix, I can reproduce it. Problem is that the generated 'xml' file is not generated correctly. The parameter 'vlen' should be written as '$vlen' in the xml files source/sink section but it is written as 'vlen'. Thus 'vlen' is treated as the value. Happens with 'v3.7.2-11-g3b27cc47'. I don't know how to fix it though. Happy hacking Johannes On Wed, Jan 8, 2014 at 12:59 PM, Felix W. wunsch.fe...@googlemail.comwrote: Hi list, I'm currently in the process of porting my gr-drm project to the 3.7 API and now I'm a little bit stuck and hope that someone here can help me. I want to create a hier block (in GRC) that accepts vectors as input and output. Their size is controlled by parameters like vlen_in and vlen_out. Unfortunately, the IO size of the generated hier block always stays 1, no matter what I use as parameter. I attached a minimal (pure GNU Radio) example flow graph and hier block that reproduces my problem. Maybe I overlooked something obvious, but I don't get why this is not working. If someone had the time to try this and could report if it works (it does not for me), I would be very grateful. I'm on Ubuntu 12.10 and have GNU Radio v3.7.2.1-116-ge751e54a installed. Regards, Felix Wunsch ___ 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
