[Discuss-gnuradio] Strange behaviour in GRC for a simple FFT/IFFT flow-graph
Hi all! When constructing a simple flow graph Signal_source(f)->Throttle(f)->Stream_to_vector(vf)->Forward_FFT(vc)->Reverse_FFT(vc)->Vector_to_stream(c)->WX_GUI_FFT_sink(c), the sink exhibits strange behaviour, showing frequency (and the image frequency) different than the one I'm creating with the signal source, e.g. for f=1kHz, sink shows 15kHz and -15kHz whereas for f=15 kHZ it shows 1kHz and -1kHz. On the other hand, if I create a complex signal using signal source, or use Float_to_complex block before feeding it to Stream_to_vector, the results are as expected. Is this a glitch in GR (I'm using GRC 3.6.4.1.), or is there something I'm missing here? The flow graph and the result for f=1kHz are as follows:http://imageshack.us/photo/my-images/194/xfvr.jpg/http://imageshack.us/photo/my-images/826/dj2p.jpg/ *f=float; vc=vector of complex; c=complex Thanks in advance!___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] libusb error with gnuradio v3.4.2git
Hi, Can someone help me to solve the problem below? I have usrp1 with RFX1800. When running usrp_fft.py I get error "failed to set initial frequency" and see no spectrum. starting usrp_fft.py -R A helps at the beginning, I can see the spectrum, but any attempt to change the frequency freezes the spectrum or causes it to dissapear and says "failed". And as you can see there are some fusb, libusb errors. My usrp was working fine untill I upgraded to ubuntu 12.04 and reinstalled gnuradio. robert-pc:~/gnuradio$ usrp_fft.py fusb::_reap libusb_handle_events() -10 (python:26722): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent. usrp_benchmark_usb.py returns: Testing 2MB/sec... usb_throughput = 2M ntotal = 100 nright = 94 runlength = 94 delta = 6 OK Testing 4MB/sec... fusb::_cancel_lutusb_throughput = 4M ntotal = 200 nright = 1997869 runlength = 1997655 delta = 2345 OK Testing 8MB/sec... fusb::_cancel_lutusb_throughput = 8M ntotal = 400 nright = 3998087 runlength = 3998087 delta = 1913 OK Testing 16MB/sec... fusb::_cancel_lutfusb::_cancel_lutfusb::_cancel_lutusb_throughput = 16M ntotal = 800 nright = 7999035 runlength = 7999035 delta = 965 OK Testing 32MB/sec... fusb::_cancel_lutfusb::_cancel_lutfusb::_cancel_lutusb_throughput = 32M ntotal = 1600 nright = 15999605 runlength = 15999605 delta = 395 OK Max USB/USRP throughput = 32MB/sec I installed dependecies with build gnuradio script, then I did manual installation. I have Ubuntu 12.04 3.2.0-55-generic-pae i386 i686. I configured gnuradio with the following command: PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ ./configure -q --prefix=/home/robert/gr342 --disable-gr-qtgui --with-fusb-tech=libusb1 --enable-usrp --enable-gr-usrp --enable-gnuradio-core --disable-usrp2 --disable-volk my .bashrc is below, I have a symbolic link pointing .sys > /home/robert/gr342 PREFIX=/home/robert/.sys export PATH=$PATH:$PREFIX/bin:/opt/microblaze/bin export LD_LOAD_LIBRARY=$PREFIX/lib export LD_LIBRARY_PATH=$PREFIX/lib export PYTHONPATH=$PREFIX/lib/python2.7/site-packages export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig export PATH=/opt/local/bin:/opt/local/sbin/:$PATH export MANPATH=/opt/local/share/man:$MANPATH ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] libusb error with gnuradio v3.4.2git
What are you intending to do with this installation? Sounds a bit like OpenBTS to me. If this is your aim, what does OpenBTS say? I never tested the installation this way, just fired the stuff up, and usually it worked :) Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Robert Light Sent: Thursday, November 07, 2013 10:49 AM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] libusb error with gnuradio v3.4.2git Hi, Can someone help me to solve the problem below? I have usrp1 with RFX1800. When running usrp_fft.py I get error "failed to set initial frequency" and see no spectrum. starting usrp_fft.py -R A helps at the beginning, I can see the spectrum, but any attempt to change the frequency freezes the spectrum or causes it to dissapear and says "failed". And as you can see there are some fusb, libusb errors. My usrp was working fine untill I upgraded to ubuntu 12.04 and reinstalled gnuradio. robert-pc:~/gnuradio$ usrp_fft.py fusb::_reap libusb_handle_events() -10 (python:26722): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent. usrp_benchmark_usb.py returns: Testing 2MB/sec... usb_throughput = 2M ntotal= 100 nright= 94 runlength = 94 delta = 6 OK Testing 4MB/sec... fusb::_cancel_lutusb_throughput = 4M ntotal= 200 nright= 1997869 runlength = 1997655 delta = 2345 OK Testing 8MB/sec... fusb::_cancel_lutusb_throughput = 8M ntotal= 400 nright= 3998087 runlength = 3998087 delta = 1913 OK Testing 16MB/sec... fusb::_cancel_lutfusb::_cancel_lutfusb::_cancel_lutusb_throughput = 16M ntotal= 800 nright= 7999035 runlength = 7999035 delta = 965 OK Testing 32MB/sec... fusb::_cancel_lutfusb::_cancel_lutfusb::_cancel_lutusb_throughput = 32M ntotal= 1600 nright= 15999605 runlength = 15999605 delta = 395 OK Max USB/USRP throughput = 32MB/sec I installed dependecies with build gnuradio script, then I did manual installation. I have Ubuntu 12.04 3.2.0-55-generic-pae i386 i686. I configured gnuradio with the following command: PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ ./configure -q --prefix=/home/robert/gr342 --disable-gr-qtgui --with-fusb-tech=libusb1 --enable-usrp --enable-gr-usrp --enable-gnuradio-core --disable-usrp2 --disable-volk my .bashrc is below, I have a symbolic link pointing .sys > /home/robert/gr342 PREFIX=/home/robert/.sys export PATH=$PATH:$PREFIX/bin:/opt/microblaze/bin export LD_LOAD_LIBRARY=$PREFIX/lib export LD_LIBRARY_PATH=$PREFIX/lib export PYTHONPATH=$PREFIX/lib/python2.7/site-packages export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig export PATH=/opt/local/bin:/opt/local/sbin/:$PATH export MANPATH=/opt/local/share/man:$MANPATH ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] libusb error with gnuradio v3.4.2git
You are right, my intention is to use it with OpenBTS or rather with OsmoBTS. BTS says something like "failed to tune RX " and transceiver is not working properly. I also installed gnuradio many times and never had a problem with usrp_fft.py and I completly don't know what the problem could be this time. Looks like the usb transfer is working, but every attempt to change the settings of rfx1800 or usrp fails. The same board works fine on another computer. Gesendet: Donnerstag, 07. November 2013 um 11:02 Uhr Von: "Ralph A. Schmid, dk5ras" An: "'Robert Light'" , discuss-gnuradio@gnu.org Betreff: RE: [Discuss-gnuradio] libusb error with gnuradio v3.4.2git What are you intending to do with this installation? Sounds a bit like OpenBTS to me. If this is your aim, what does OpenBTS say? I never tested the installation this way, just fired the stuff up, and usually it worked :) Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Robert Light Sent: Thursday, November 07, 2013 10:49 AM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] libusb error with gnuradio v3.4.2git Hi, Can someone help me to solve the problem below? I have usrp1 with RFX1800. When running usrp_fft.py I get error "failed to set initial frequency" and see no spectrum. starting usrp_fft.py -R A helps at the beginning, I can see the spectrum, but any attempt to change the frequency freezes the spectrum or causes it to dissapear and says "failed". And as you can see there are some fusb, libusb errors. My usrp was working fine untill I upgraded to ubuntu 12.04 and reinstalled gnuradio. robert-pc:~/gnuradio$ usrp_fft.py fusb::_reap libusb_handle_events() -10 (python:26722): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent. usrp_benchmark_usb.py returns: Testing 2MB/sec... usb_throughput = 2M ntotal = 100 nright = 94 runlength = 94 delta = 6 OK Testing 4MB/sec... fusb::_cancel_lutusb_throughput = 4M ntotal = 200 nright = 1997869 runlength = 1997655 delta = 2345 OK Testing 8MB/sec... fusb::_cancel_lutusb_throughput = 8M ntotal = 400 nright = 3998087 runlength = 3998087 delta = 1913 OK Testing 16MB/sec... fusb::_cancel_lutfusb::_cancel_lutfusb::_cancel_lutusb_throughput = 16M ntotal = 800 nright = 7999035 runlength = 7999035 delta = 965 OK Testing 32MB/sec... fusb::_cancel_lutfusb::_cancel_lutfusb::_cancel_lutusb_throughput = 32M ntotal = 1600 nright = 15999605 runlength = 15999605 delta = 395 OK Max USB/USRP throughput = 32MB/sec I installed dependecies with build gnuradio script, then I did manual installation. I have Ubuntu 12.04 3.2.0-55-generic-pae i386 i686. I configured gnuradio with the following command: PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ ./configure -q --prefix=/home/robert/gr342 --disable-gr-qtgui --with-fusb-tech=libusb1 --enable-usrp --enable-gr-usrp --enable-gnuradio-core --disable-usrp2 --disable-volk my .bashrc is below, I have a symbolic link pointing .sys > /home/robert/gr342 PREFIX=/home/robert/.sys export PATH=$PATH:$PREFIX/bin:/opt/microblaze/bin export LD_LOAD_LIBRARY=$PREFIX/lib export LD_LIBRARY_PATH=$PREFIX/lib export PYTHONPATH=$PREFIX/lib/python2.7/site-packages export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig export PATH=/opt/local/bin:/opt/local/sbin/:$PATH export MANPATH=/opt/local/share/man:$MANPATH ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] libusb error with gnuradio v3.4.2git
Well, I installed a similar setup several times with Kubuntu 12.04, without problems. All the libusb stuff is in place? Anyway, my actual installation is a bad example, two much stuff mixed up, so for example I have no idea what libusb version GR 3.4.2 is using, 0 or 1. Ralph. From: Robert Light [mailto:robert.li...@gmx.de] Sent: Thursday, November 07, 2013 11:16 AM To: Ralph A. Schmid, dk5ras Cc: discuss-gnuradio@gnu.org Subject: Aw: RE: [Discuss-gnuradio] libusb error with gnuradio v3.4.2git You are right, my intention is to use it with OpenBTS or rather with OsmoBTS. BTS says something like "failed to tune RX " and transceiver is not working properly. I also installed gnuradio many times and never had a problem with usrp_fft.py and I completly don't know what the problem could be this time. Looks like the usb transfer is working, but every attempt to change the settings of rfx1800 or usrp fails. The same board works fine on another computer. Gesendet: Donnerstag, 07. November 2013 um 11:02 Uhr Von: "Ralph A. Schmid, dk5ras" An: "'Robert Light'" , discuss-gnuradio@gnu.org Betreff: RE: [Discuss-gnuradio] libusb error with gnuradio v3.4.2git What are you intending to do with this installation? Sounds a bit like OpenBTS to me. If this is your aim, what does OpenBTS say? I never tested the installation this way, just fired the stuff up, and usually it worked :) Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Robert Light Sent: Thursday, November 07, 2013 10:49 AM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] libusb error with gnuradio v3.4.2git Hi, Can someone help me to solve the problem below? I have usrp1 with RFX1800. When running usrp_fft.py I get error "failed to set initial frequency" and see no spectrum. starting usrp_fft.py -R A helps at the beginning, I can see the spectrum, but any attempt to change the frequency freezes the spectrum or causes it to dissapear and says "failed". And as you can see there are some fusb, libusb errors. My usrp was working fine untill I upgraded to ubuntu 12.04 and reinstalled gnuradio. robert-pc:~/gnuradio$ usrp_fft.py fusb::_reap libusb_handle_events() -10 (python:26722): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent. usrp_benchmark_usb.py returns: Testing 2MB/sec... usb_throughput = 2M ntotal= 100 nright= 94 runlength = 94 delta = 6 OK Testing 4MB/sec... fusb::_cancel_lutusb_throughput = 4M ntotal= 200 nright= 1997869 runlength = 1997655 delta = 2345 OK Testing 8MB/sec... fusb::_cancel_lutusb_throughput = 8M ntotal= 400 nright= 3998087 runlength = 3998087 delta = 1913 OK Testing 16MB/sec... fusb::_cancel_lutfusb::_cancel_lutfusb::_cancel_lutusb_throughput = 16M ntotal= 800 nright= 7999035 runlength = 7999035 delta = 965 OK Testing 32MB/sec... fusb::_cancel_lutfusb::_cancel_lutfusb::_cancel_lutusb_throughput = 32M ntotal= 1600 nright= 15999605 runlength = 15999605 delta = 395 OK Max USB/USRP throughput = 32MB/sec I installed dependecies with build gnuradio script, then I did manual installation. I have Ubuntu 12.04 3.2.0-55-generic-pae i386 i686. I configured gnuradio with the following command: PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ ./configure -q --prefix=/home/robert/gr342 --disable-gr-qtgui --with-fusb-tech=libusb1 --enable-usrp --enable-gr-usrp --enable-gnuradio-core --disable-usrp2 --disable-volk my .bashrc is below, I have a symbolic link pointing .sys > /home/robert/gr342 PREFIX=/home/robert/.sys export PATH=$PATH:$PREFIX/bin:/opt/microblaze/bin export LD_LOAD_LIBRARY=$PREFIX/lib export LD_LIBRARY_PATH=$PREFIX/lib export PYTHONPATH=$PREFIX/lib/python2.7/site-packages export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig export PATH=/opt/local/bin:/opt/local/sbin/:$PATH export MANPATH=/opt/local/share/man:$MANPATH ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
On Wed, Nov 06, 2013 at 06:27:40PM -0500, Aditya Dhananjay wrote: > I created an OFDM TX/RX flowgraph (mostly copying stuff out from the GNU Radio > reference GRC implementation), where the TX goes out to a USRP UHD sink, and > the RX reads from a USRP UHD source. > > As long as the receive SNR is high enough, the problem does not show up. > However, as I gradually reduce the RX gain, at some point, the entire thing > crashes with the "Buffer too small for min_noutput_items" error. Are you using a current version? This problem was caused by bit errors creating incorrect, but validated headers. In the current header, we have an 8 Bit CRC check, which is pretty unlikely to cause 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 pgprsvZkgRde1.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
i got a new problem.. when i am working with signals, i converted them to vectors using stream to vectors, then the vectors are given as input to my block (since my block has an input as vectors of fixed length) , then processing is done on the vector, output is also a vector .. but the problem is that there is delay in processing the each vector.. and i declared my i/o signature as follows: i/p signature sizeof(float)*vec_len o/p signature sizeof(float)*vec_len when is plot the output, it is not exactly delay because some unwanted plot is occurring and again my ouput is being plotted... i can post my code if u need it... thanks ... -- View this message in context: http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327p44601.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
On Thu, Nov 7, 2013 at 7:57 AM, Martin Braun (CEL) wrote: > On Wed, Nov 06, 2013 at 06:27:40PM -0500, Aditya Dhananjay wrote: > > I created an OFDM TX/RX flowgraph (mostly copying stuff out from the GNU > Radio > > reference GRC implementation), where the TX goes out to a USRP UHD sink, > and > > the RX reads from a USRP UHD source. > > > > As long as the receive SNR is high enough, the problem does not show up. > > However, as I gradually reduce the RX gain, at some point, the entire > thing > > crashes with the "Buffer too small for min_noutput_items" error. > > Are you using a current version? This problem was caused by bit errors > creating incorrect, but validated headers. In the current header, we > have an 8 Bit CRC check, which is pretty unlikely to cause this. > Hi Martin, Thanks for your response. Yes, I am using the current version pulled from the git sources. To clarify, this is not a rare occurrence. With a > 50% probability, when I reduce the TX/RX gain, the problem shows up. The header/payload demux is always the offending block. Also, once this problem shows up, the entire RX path freezes up, and needs to be restarted. Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
Hi all, Martin, Aditya is correct I too am facing this issue with the new rx_ofdm.grc. This error is prominent its only in some gain settings the model works. Moreover in QPSK modulation CRC is rejecting nearly all the packets. Thanks, Ashish On Thursday, 7 November 2013 6:27 PM, Martin Braun (CEL) wrote: On Wed, Nov 06, 2013 at 06:27:40PM -0500, Aditya Dhananjay wrote: > I created an OFDM TX/RX flowgraph (mostly copying stuff out from the GNU Radio > reference GRC implementation), where the TX goes out to a USRP UHD sink, and > the RX reads from a USRP UHD source. > > As long as the receive SNR is high enough, the problem does not show up. > However, as I gradually reduce the RX gain, at some point, the entire thing > crashes with the "Buffer too small for min_noutput_items" error. Are you using a current version? This problem was caused by bit errors creating incorrect, but validated headers. In the current header, we have an 8 Bit CRC check, which is pretty unlikely to cause 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 ___ 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] Status of GNU Radio with OSX 10.9
On Nov 6, 2013, at 8:25 AM, Michael Dickens wrote: > Today I will see if the C++ parts of GNU Radio work on 10.9, without the SWIG > Python interface. I finally got all of the dependencies installed, and have verified that the GNU Radio codebase does indeed work with 10.9's clang and libc++. So, the issue is purely that SWIG is not generating C++11 compliant code. I will next look into whether SWIG can even do that (at all; some special flag) or whether OSX 10.9 users are "out on a limb" for using the GRC and Python interfaces to GNU Radio. - MLD -- Michael Dickens, Mac OS X Programmer Ettus Research Technical Support Email: supp...@ettus.com Web: http://www.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander)
For those of you using Ubuntu 13.10 (Saucy Salamader), we have some issues with the apt-get version of PyQWT. This has been reported on and discussed as issue #604 on gnuradio.org. I plan on submitting a but report to Ubuntu about this, too. Meanwhile, the best solution for those wanting to use QTGUI on this platform, I have provided instructions on how to build and install both PyQT and PyQWT from source (you need the to install PyQT by hand in order to build PyQWT): http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Saucy-Salamander-1310 Note that you do not have to uninstall PyQT from apt-get, but I recommend uninstalling PyQWT just to be sure. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander)
Hi Tom, thanks for your effort. At the step where PyQt 4.10.3 is installed, python configure.py -b /opt/qt/bin -d /opt/qt/lib/python2.7/dist-packages -v /opt/qt/share/sip The command does many steps then errors out with: sh: 1: /usr/bin/sip: not found Error: Unable to create the C++ code. -- Tom From: Tom Rondeau To: GNURadio Discussion List Sent: Thursday, November 7, 2013 11:24 AM Subject: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) For those of you using Ubuntu 13.10 (Saucy Salamader), we have some issues with the apt-get version of PyQWT. This has been reported on and discussed as issue #604 on gnuradio.org. I plan on submitting a but report to Ubuntu about this, too. Meanwhile, the best solution for those wanting to use QTGUI on this platform, I have provided instructions on how to build and install both PyQT and PyQWT from source (you need the to install PyQT by hand in order to build PyQWT): http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Saucy-Salamander-1310 Note that you do not have to uninstall PyQT from apt-get, but I recommend uninstalling PyQWT just to be sure. Tom ___ 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] Ubuntu 13.10 (Saucy Salamander)
On Thu, Nov 7, 2013 at 3:01 PM, Tom McDermott wrote: > Hi Tom, thanks for your effort. > > At the step where PyQt 4.10.3 is installed, > > python configure.py -b /opt/qt/bin -d /opt/qt/lib/python2.7/dist-packages -v > /opt/qt/share/sip > > > The command does many steps then errors out with: > sh: 1: /usr/bin/sip: not found > Error: Unable to create the C++ code. > > -- Tom Ah, kind of a formatting flaw on my part. I snuck this package into the apt-get line above acting like everyone would start from scratch. You have to install the python-sip package: $ sudo apt-get install python-sip I've updated the webpage to make this clear. Tom > > From: Tom Rondeau > To: GNURadio Discussion List > Sent: Thursday, November 7, 2013 11:24 AM > Subject: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) > > For those of you using Ubuntu 13.10 (Saucy Salamader), we have some > issues with the apt-get version of PyQWT. This has been reported on > and discussed as issue #604 on gnuradio.org. I plan on submitting a > but report to Ubuntu about this, too. > > Meanwhile, the best solution for those wanting to use QTGUI on this > platform, I have provided instructions on how to build and install > both PyQT and PyQWT from source (you need the to install PyQT by hand > in order to build PyQWT): > > http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Saucy-Salamander-1310 > > Note that you do not have to uninstall PyQT from apt-get, but I > recommend uninstalling PyQWT just to be sure. > > Tom > > ___ > 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] Ubuntu 13.10 (Saucy Salamander)
On Thu, Nov 7, 2013 at 3:07 PM, Tom Rondeau wrote: > On Thu, Nov 7, 2013 at 3:01 PM, Tom McDermott > wrote: >> Hi Tom, thanks for your effort. >> >> At the step where PyQt 4.10.3 is installed, >> >> python configure.py -b /opt/qt/bin -d /opt/qt/lib/python2.7/dist-packages -v >> /opt/qt/share/sip >> >> >> The command does many steps then errors out with: >> sh: 1: /usr/bin/sip: not found >> Error: Unable to create the C++ code. >> >> -- Tom > > Ah, kind of a formatting flaw on my part. I snuck this package into > the apt-get line above acting like everyone would start from scratch. > > You have to install the python-sip package: > $ sudo apt-get install python-sip > > I've updated the webpage to make this clear. > > Tom Just to be on the safe side, I also added the package "python-sip-dev" which might be the one that actually installs the sip binary. I have both on all of the instances that I tried this on. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander)
Hi Tom - OK, that got PyQt to install... Now install of PyQwt fails: ./configure.py -Q ../qwt-5.2 --module-install-path=/opt/qt/lib/python2.7/dist-packages/PyQt4/Qwt5produces sip: Deprecation warning: ../sip/qwt5qt4/QwtModule.sip:32: %Module version number should be specified using the 'version' argument sip: Unable to find file "QtCore/QtCoremod.sip" SIP failed to generate the C++ code. -- Tpm From: Tom Rondeau To: Tom McDermott Cc: GNURadio Discussion List Sent: Thursday, November 7, 2013 12:11 PM Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) On Thu, Nov 7, 2013 at 3:07 PM, Tom Rondeau wrote: > On Thu, Nov 7, 2013 at 3:01 PM, Tom McDermott > wrote: >> Hi Tom, thanks for your effort. >> >> At the step where PyQt 4.10.3 is installed, >> >> python configure.py -b /opt/qt/bin -d /opt/qt/lib/python2.7/dist-packages -v >> /opt/qt/share/sip >> >> >> The command does many steps then errors out with: >> sh: 1: /usr/bin/sip: not found >> Error: Unable to create the C++ code. >> >> -- Tom > > Ah, kind of a formatting flaw on my part. I snuck this package into > the apt-get line above acting like everyone would start from scratch. > > You have to install the python-sip package: > $ sudo apt-get install python-sip > > I've updated the webpage to make this clear. > > Tom Just to be on the safe side, I also added the package "python-sip-dev" which might be the one that actually installs the sip binary. I have both on all of the instances that I tried this on. Tom___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander)
On Thu, Nov 7, 2013 at 3:31 PM, Tom McDermott wrote: > Hi Tom - OK, that got PyQt to install... > > Now install of PyQwt fails: > > ./configure.py -Q ../qwt-5.2 > --module-install-path=/opt/qt/lib/python2.7/dist-packages/PyQt4/Qwt5 > > produces > > sip: Deprecation warning: ../sip/qwt5qt4/QwtModule.sip:32: %Module version > number should be specified using the 'version' argument > sip: Unable to find file "QtCore/QtCoremod.sip" > SIP failed to generate the C++ code. > > -- Tpm Ah, ok. This is why we have to install PyQT ourselves and can't rely on the Ubuntu-installed code. That QtCoremod.sip file is installed when we install PyQT. My guess is that you have to set up the environmental variables before trying to configure PyQWT. I updated the webpage to do this before anything else, so go and look at the new order of instructions and see if that helps. I think I did this myself and then wrote up the description out of order because I thought it made more logical sense. Hopefully this does it for you. Tom > > From: Tom Rondeau > To: Tom McDermott > Cc: GNURadio Discussion List > Sent: Thursday, November 7, 2013 12:11 PM > Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) > > On Thu, Nov 7, 2013 at 3:07 PM, Tom Rondeau wrote: >> On Thu, Nov 7, 2013 at 3:01 PM, Tom McDermott >> wrote: >>> Hi Tom, thanks for your effort. >>> >>> At the step where PyQt 4.10.3 is installed, >>> >>> python configure.py -b /opt/qt/bin -d /opt/qt/lib/python2.7/dist-packages >>> -v >>> /opt/qt/share/sip >>> >>> >>> The command does many steps then errors out with: >>> sh: 1: /usr/bin/sip: not found >>> Error: Unable to create the C++ code. >>> >>> -- Tom >> >> Ah, kind of a formatting flaw on my part. I snuck this package into >> the apt-get line above acting like everyone would start from scratch. >> >> You have to install the python-sip package: >> $ sudo apt-get install python-sip >> >> I've updated the webpage to make this clear. >> >> Tom > > Just to be on the safe side, I also added the package "python-sip-dev" > which might be the one that actually installs the sip binary. I have > both on all of the instances that I tried this on. > > > Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Installation error with pybombs
Hi, I am trying to install gnuradio 3.6 using pybombs. Suddenly I get an error message : -- Python checking for Cheetah >= 2.0.0 -- Python checking for Cheetah >= 2.0.0 - not found CMake Error at volk/CMakeLists.txt:62 (message): Cheetah templates required to build VOLK -- Configuring incomplete, errors occurred! bash return val = 1 Traceback (most recent call last): File "./pybombs", line 124, in install(p, not opts.force); File "/home/kartik/SDR/pybombs/mod_pybombs/pybombs_ops.py", line 101, in install global_recipes[pkg].install(); File "/home/kartik/SDR/pybombs/mod_pybombs/recipe.py", line 537, in install st = self.install_src(); File "/home/kartik/SDR/pybombs/mod_pybombs/recipe.py", line 602, in install_src self.install_order[step][1](); File "/home/kartik/SDR/pybombs/mod_pybombs/recipe.py", line 643, in configure assert(st == 0); AssertionError python-cheetah is already installed. When I enter ./pybombs search cheetah , the output shows cheetah installed as: Searching for packages matching: cheetah * cheetah I had previously installed gnuradio 3.6(and then uninstalled it) and then installed gnuradio 3.7 on the same machine. I have uninstalled gnuradio 3.7 I have tried almost everything. Does anybody have any idea ? I was expecting to have easy installation of OOT modules with pybombs and most of them have not been upgraded to 3.7 version Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander)
Hi Tom, That fixed PyQwt. Then did a cmake, make, sudo make install of all gnuradio sucessfully. When I try to run a flowgraph, the error in the GRC console window is: Traceback (most recent call last): File "/home/tom/Desktop/top_block.py", line 16, in import PyQt4.Qwt5 as Qwt ImportError: No module named Qwt5 looking at the packages *qwt* $ dpkg -l '*qwt*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii libqwt-dev 6.0.0-1.2 amd64 Qt widgets library for technical rc libqwt5-qt4 5.2.3-1 amd64 Qt4 widgets library for technical un libqwt5-qt4-de (no description available) ii libqwt6 6.0.0-1.2 amd64 Qt widgets library for technical un libqwtplot3d-q (no description available) ii libqwtplot3d-q 0.2.7+svn191 amd64 3D plotting library based on Qt4/ ii libqwtplot3d-q 0.2.7+svn191 amd64 3D plotting library based on Qt4/ un python-qwt3d-q (no description available) un python-qwt5-qt (no description available) -- Tom From: Tom Rondeau To: Tom McDermott Cc: "discuss-gnuradio@gnu.org" Sent: Thursday, November 7, 2013 12:35 PM Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) On Thu, Nov 7, 2013 at 3:31 PM, Tom McDermott wrote: > Hi Tom - OK, that got PyQt to install... > > Now install of PyQwt fails: > > ./configure.py -Q ../qwt-5.2 > --module-install-path=/opt/qt/lib/python2.7/dist-packages/PyQt4/Qwt5 > > produces > > sip: Deprecation warning: ../sip/qwt5qt4/QwtModule.sip:32: %Module version > number should be specified using the 'version' argument > sip: Unable to find file "QtCore/QtCoremod.sip" > SIP failed to generate the C++ code. > > -- Tpm Ah, ok. This is why we have to install PyQT ourselves and can't rely on the Ubuntu-installed code. That QtCoremod.sip file is installed when we install PyQT. My guess is that you have to set up the environmental variables before trying to configure PyQWT. I updated the webpage to do this before anything else, so go and look at the new order of instructions and see if that helps. I think I did this myself and then wrote up the description out of order because I thought it made more logical sense. Hopefully this does it for you. Tom > > From: Tom Rondeau > To: Tom McDermott > Cc: GNURadio Discussion List > Sent: Thursday, November 7, 2013 12:11 PM > Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) > > On Thu, Nov 7, 2013 at 3:07 PM, Tom Rondeau wrote: >> On Thu, Nov 7, 2013 at 3:01 PM, Tom McDermott >> wrote: >>> Hi Tom, thanks for your effort. >>> >>> At the step where PyQt 4.10.3 is installed, >>> >>> python configure.py -b /opt/qt/bin -d /opt/qt/lib/python2.7/dist-packages >>> -v >>> /opt/qt/share/sip >>> >>> >>> The command does many steps then errors out with: >>> sh: 1: /usr/bin/sip: not found >>> Error: Unable to create the C++ code. >>> >>> -- Tom >> >> Ah, kind of a formatting flaw on my part. I snuck this package into >> the apt-get line above acting like everyone would start from scratch. >> >> You have to install the python-sip package: >> $ sudo apt-get install python-sip >> >> I've updated the webpage to make this clear. >> >> Tom > > Just to be on the safe side, I also added the package "python-sip-dev" > which might be the one that actually installs the sip binary. I have > both on all of the instances that I tried this on. > > > Tom > >___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9
Hi Michael, thanks so much for your efforts and for keeping us updated on your progress. I'm some steps behind of you but reproducing the path the best I can. I successfully built GNU Radio runtime, pmt, blocks, fft, filter, uhd, fec, trellis, analog, and volk libraries with 10.9's clang and libc++, which is enough for my C++ application. Any one else would be interested in a 'gnuradio-devel-mavericks' port with the libraries that compile well by now? On Thu, Nov 7, 2013 at 6:58 PM, Michael Dickens wrote: > On Nov 6, 2013, at 8:25 AM, Michael Dickens > wrote: > > Today I will see if the C++ parts of GNU Radio work on 10.9, without the > SWIG Python interface. > > I finally got all of the dependencies installed, and have verified that > the GNU Radio codebase does indeed work with 10.9's clang and libc++. So, > the issue is purely that SWIG is not generating C++11 compliant code. I > will next look into whether SWIG can even do that (at all; some special > flag) or whether OSX 10.9 users are "out on a limb" for using the GRC and > Python interfaces to GNU Radio. - MLD > -- > > Michael Dickens, Mac OS X Programmer > > Ettus Research Technical Support > > Email: supp...@ettus.com > > Web: http://www.ettus.com > > > ___ > 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] Ubuntu 13.10 (Saucy Salamander)
On Thu, Nov 7, 2013 at 4:37 PM, Tom McDermott wrote: > Hi Tom, > > That fixed PyQwt. Then did a cmake, make, sudo make install of all gnuradio > sucessfully. > > When I try to run a flowgraph, the error in the GRC console window is: > > Traceback (most recent call last): > File "/home/tom/Desktop/top_block.py", line 16, in > import PyQt4.Qwt5 as Qwt > ImportError: No module named Qwt5 > > looking at the packages *qwt* > > $ dpkg -l '*qwt*' > Desired=Unknown/Install/Remove/Purge/Hold > | > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==---= > ii libqwt-dev 6.0.0-1.2amd64Qt widgets library for > technical > rc libqwt5-qt45.2.3-1 amd64Qt4 widgets library for > technical > un libqwt5-qt4-de (no description available) > ii libqwt66.0.0-1.2amd64Qt widgets library for > technical > un libqwtplot3d-q (no description available) > ii libqwtplot3d-q 0.2.7+svn191 amd643D plotting library based on > Qt4/ > ii libqwtplot3d-q 0.2.7+svn191 amd643D plotting library based on > Qt4/ > un python-qwt3d-q (no description available) > un python-qwt5-qt (no description available) > > > -- Tom When you installed PyQWT, you should have configured it using: ./configure.py -Q ../qwt-5.2 --module-install-path=/opt/qt/lib/python2.7/dist-packages/PyQt4/Qwt5 That '--module-install-path' is where the Qwt module would be installed in to. So make sure that that directory structure is correct. Then, you have to make sure your PYTHONPATH is set correctly. In my instructions, I install everything into /opt/qt. I then make sure that the PYTHONPATH variable is appended with this directory. That should make sure that Python looks there first for PyQt4.Qwt5. So just verify that the Qwt Python module is installed and that PYTHONPATH is set in your environment. Tom ___ > From: Tom Rondeau > To: Tom McDermott > Cc: "discuss-gnuradio@gnu.org" > Sent: Thursday, November 7, 2013 12:35 PM > > Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) > > On Thu, Nov 7, 2013 at 3:31 PM, Tom McDermott > wrote: >> Hi Tom - OK, that got PyQt to install... >> >> Now install of PyQwt fails: >> >> ./configure.py -Q ../qwt-5.2 >> --module-install-path=/opt/qt/lib/python2.7/dist-packages/PyQt4/Qwt5 >> >> produces >> >> sip: Deprecation warning: ../sip/qwt5qt4/QwtModule.sip:32: %Module version >> number should be specified using the 'version' argument >> sip: Unable to find file "QtCore/QtCoremod.sip" >> SIP failed to generate the C++ code. >> >> -- Tpm > > Ah, ok. This is why we have to install PyQT ourselves and can't rely > on the Ubuntu-installed code. That QtCoremod.sip file is installed > when we install PyQT. My guess is that you have to set up the > environmental variables before trying to configure PyQWT. I updated > the webpage to do this before anything else, so go and look at the new > order of instructions and see if that helps. > > I think I did this myself and then wrote up the description out of > order because I thought it made more logical sense. Hopefully this > does it for you. > > > Tom > > >> >> From: Tom Rondeau >> To: Tom McDermott >> Cc: GNURadio Discussion List >> Sent: Thursday, November 7, 2013 12:11 PM >> Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) >> >> On Thu, Nov 7, 2013 at 3:07 PM, Tom Rondeau wrote: >>> On Thu, Nov 7, 2013 at 3:01 PM, Tom McDermott >>> wrote: Hi Tom, thanks for your effort. At the step where PyQt 4.10.3 is installed, python configure.py -b /opt/qt/bin -d /opt/qt/lib/python2.7/dist-packages -v /opt/qt/share/sip The command does many steps then errors out with: sh: 1: /usr/bin/sip: not found Error: Unable to create the C++ code. -- Tom >>> >>> Ah, kind of a formatting flaw on my part. I snuck this package into >>> the apt-get line above acting like everyone would start from scratch. >>> >>> You have to install the python-sip package: >>> $ sudo apt-get install python-sip >>> >>> I've updated the webpage to make this clear. >>> >>> Tom >> >> Just to be on the safe side, I also added the package "python-sip-dev" >> which might be the one that actually installs the sip binary. I have >> both on all of the instances that I tried this on. >> >> >> Tom >> >> > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander)
Hi Tom, The /opt/qt/lib/python2.7/dist-packages/PyQt4/Qwt5 directory exists, and has the built modules. I think the PYTHONPATH is set per your instructions. $ export -p: ... declare -x MANDATORY_PATH="/usr/share/gconf/ubuntu.mandatory.path" declare -x OLDPWD declare -x PATH="/opt/qt/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" declare -x PKG_CONFIG_PATH="/opt/qt/lib/pkgconfig:" declare -x PWD="/home/tom" declare -x PYTHONPATH="/opt/qt/lib/python2.7/dist-packages:" declare -x QT4_IM_MODULE="xim" declare -x SESSIONTYPE="gnome-session" declare -x SHELL="/bin/bash" ... -- Tom From: Tom Rondeau To: Tom McDermott Cc: "discuss-gnuradio@gnu.org" Sent: Thursday, November 7, 2013 1:53 PM Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) On Thu, Nov 7, 2013 at 4:37 PM, Tom McDermott wrote: > Hi Tom, > > That fixed PyQwt. Then did a cmake, make, sudo make install of all gnuradio > sucessfully. > > When I try to run a flowgraph, the error in the GRC console window is: > > Traceback (most recent call last): > File "/home/tom/Desktop/top_block.py", line 16, in > import PyQt4.Qwt5 as Qwt > ImportError: No module named Qwt5 > > looking at the packages *qwt* > > $ dpkg -l '*qwt*' > Desired=Unknown/Install/Remove/Purge/Hold > | > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==---= > ii libqwt-dev 6.0.0-1.2 amd64 Qt widgets library for > technical > rc libqwt5-qt4 5.2.3-1 amd64 Qt4 widgets library for > technical > un libqwt5-qt4-de (no description available) > ii libqwt6 6.0.0-1.2 amd64 Qt widgets library for > technical > un libqwtplot3d-q (no description available) > ii libqwtplot3d-q 0.2.7+svn191 amd64 3D plotting library based on > Qt4/ > ii libqwtplot3d-q 0.2.7+svn191 amd64 3D plotting library based on > Qt4/ > un python-qwt3d-q (no description available) > un python-qwt5-qt (no description available) > > > -- Tom When you installed PyQWT, you should have configured it using: ./configure.py -Q ../qwt-5.2 --module-install-path=/opt/qt/lib/python2.7/dist-packages/PyQt4/Qwt5 That '--module-install-path' is where the Qwt module would be installed in to. So make sure that that directory structure is correct. Then, you have to make sure your PYTHONPATH is set correctly. In my instructions, I install everything into /opt/qt. I then make sure that the PYTHONPATH variable is appended with this directory. That should make sure that Python looks there first for PyQt4.Qwt5. So just verify that the Qwt Python module is installed and that PYTHONPATH is set in your environment. Tom ___ > From: Tom Rondeau > To: Tom McDermott > Cc: "discuss-gnuradio@gnu.org" > Sent: Thursday, November 7, 2013 12:35 PM > > Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) > > On Thu, Nov 7, 2013 at 3:31 PM, Tom McDermott > wrote: >> Hi Tom - OK, that got PyQt to install... >> >> Now install of PyQwt fails: >> >> ./configure.py -Q ../qwt-5.2 >> --module-install-path=/opt/qt/lib/python2.7/dist-packages/PyQt4/Qwt5 >> >> produces >> >> sip: Deprecation warning: ../sip/qwt5qt4/QwtModule.sip:32: %Module version >> number should be specified using the 'version' argument >> sip: Unable to find file "QtCore/QtCoremod.sip" >> SIP failed to generate the C++ code. >> >> -- Tpm > > Ah, ok. This is why we have to install PyQT ourselves and can't rely > on the Ubuntu-installed code. That QtCoremod.sip file is installed > when we install PyQT. My guess is that you have to set up the > environmental variables before trying to configure PyQWT. I updated > the webpage to do this before anything else, so go and look at the new > order of instructions and see if that helps. > > I think I did this myself and then wrote up the description out of > order because I thought it made more logical sense. Hopefully this > does it for you. > > > Tom > > >> >> From: Tom Rondeau >> To: Tom McDermott >> Cc: GNURadio Discussion List >> Sent: Thursday, November 7, 2013 12:11 PM >> Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) >> >> On Thu, Nov 7, 2013 at 3:07 PM, Tom Rondeau wrote: >>> On Thu, Nov 7, 2013 at 3:01 PM, Tom McDermott >>> wrote: Hi Tom, thanks for your effort. At the step where PyQt 4.10.3 is installed, python configure.py -b /opt/qt/bin -d /opt/qt/lib/python2.7/dist-packages -v /opt/qt/share/sip The command does many steps then errors out with: sh: 1: /usr/bin/sip: not found Error: U
Re: [Discuss-gnuradio] The GSoC project on LDPC codes.
> Now I'm wondering why I didn't get any segmentation faults.
You should be able to reproduce this by loading the alist file from the
reference site
http://www.inference.phy.cam.ac.uk/mackay/codes/alist.html (that example may
not be a good LDPC example, but should at minimum cause a fault in unfixed
alist.cc)
The next question (tl;dr) about LDPC may not be an actual bug, but I don't have
enough
knowledge of this topic to know for sure. All I know about the error correcting
codes has been learned through experimentation and trial and error...
One of the error correcting codes used in P25 has a 4x8 generator matrix and
I've
been able successfully to get numpy to generate code words that match what we've
seen over the air from analysis of actual P25 TDMA traffic. When I tried to
generate
the set of all possible code words using LDPC it produced a very interesting
result
(see below). It appears that the codewords that gr-ldpc generates really are
the same
as the ones used in P25, however the generated parity bits appear before the
user
data bits, instead of as in P25 where the parity bits are appended after the
original
data bits.
dataP25 gr-ldpc
wordcodewordcodeword
0
1 0001011111010001
2 0010111001110010
3 0011100110100011
4 0100101110110100
5 0101110001100101
6 0110010111000110
7 0111001000010111
8 1000110111101000
9 1001101000111001
10 1010001110011010
11 1011010001001011
12 1100011001011100
13 1101000110001101
14 1110100000101110
15
The "problem" is that if we receive say, P25 codeword 01011100 we want it to
decode
to 5 (0101) whereas if gr-ldpc is called upon to decode 01011100 its answer is
12 .
In this small example we could clean up afterwords by adding a lookup table
(4 bits in, 4 bits out) to map the result back to the proper value, but it's
not clear
that would be generalizable.
I've pasted the python code below that's used to generate the second column in
the
table above - the example shown is for dataword='0101' (5)
>>> import numpy as np
>>>
>>> g = np.array(np.mat('1 0 0 0 1 1 0 1; 0 1 0 0 1 0 1 1; 0 0 1 0 1 1 1 0; 0 0
>>> 0 1 0 1 1 1'))
>>>
>>> codeword = np.dot([0,1,0,1], g) % 2
>>>
>>> print codeword
[0 1 0 1 1 1 0 0]
>>>
The question (_if_ I understand things correctly) seems to be : how reasonable
/ unreasonable is it for users of the
library to be picky about the exact ordering of the parity bits in the
generated codewords?
Thx again Manu
Best
Max
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) - runs from terminal, but not GRC
Hi Tom, thanks again for all your help. It runs from a terminal OK. The missing Qwt5 error comes when trying to run it from GRC. -- Tom From: Tom Rondeau To: Tom McDermott Cc: "discuss-gnuradio@gnu.org" Sent: Thursday, November 7, 2013 1:53 PM Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) On Thu, Nov 7, 2013 at 4:37 PM, Tom McDermott wrote: > Hi Tom, > > That fixed PyQwt. Then did a cmake, make, sudo make install of all gnuradio > sucessfully. > > When I try to run a flowgraph, the error in the GRC console window is: > > Traceback (most recent call last): > File "/home/tom/Desktop/top_block.py", line 16, in > import PyQt4.Qwt5 as Qwt > ImportError: No module named Qwt5 > > looking at the packages *qwt* > > $ dpkg -l '*qwt*' > Desired=Unknown/Install/Remove/Purge/Hold > | > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==---= > ii libqwt-dev 6.0.0-1.2 amd64 Qt widgets library for > technical > rc libqwt5-qt4 5.2.3-1 amd64 Qt4 widgets library for > technical > un libqwt5-qt4-de (no description available) > ii libqwt6 6.0.0-1.2 amd64 Qt widgets library for > technical > un libqwtplot3d-q (no description available) > ii libqwtplot3d-q 0.2.7+svn191 amd64 3D plotting library based on > Qt4/ > ii libqwtplot3d-q 0.2.7+svn191 amd64 3D plotting library based on > Qt4/ > un python-qwt3d-q (no description available) > un python-qwt5-qt (no description available) > > > -- Tom When you installed PyQWT, you should have configured it using: ./configure.py -Q ../qwt-5.2 --module-install-path=/opt/qt/lib/python2.7/dist-packages/PyQt4/Qwt5 That '--module-install-path' is where the Qwt module would be installed in to. So make sure that that directory structure is correct. Then, you have to make sure your PYTHONPATH is set correctly. In my instructions, I install everything into /opt/qt. I then make sure that the PYTHONPATH variable is appended with this directory. That should make sure that Python looks there first for PyQt4.Qwt5. So just verify that the Qwt Python module is installed and that PYTHONPATH is set in your environment. Tom ___ > From: Tom Rondeau > To: Tom McDermott > Cc: "discuss-gnuradio@gnu.org" > Sent: Thursday, November 7, 2013 12:35 PM > > Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) > > On Thu, Nov 7, 2013 at 3:31 PM, Tom McDermott > wrote: >> Hi Tom - OK, that got PyQt to install... >> >> Now install of PyQwt fails: >> >> ./configure.py -Q ../qwt-5.2 >> --module-install-path=/opt/qt/lib/python2.7/dist-packages/PyQt4/Qwt5 >> >> produces >> >> sip: Deprecation warning: ../sip/qwt5qt4/QwtModule.sip:32: %Module version >> number should be specified using the 'version' argument >> sip: Unable to find file "QtCore/QtCoremod.sip" >> SIP failed to generate the C++ code. >> >> -- Tpm > > Ah, ok. This is why we have to install PyQT ourselves and can't rely > on the Ubuntu-installed code. That QtCoremod.sip file is installed > when we install PyQT. My guess is that you have to set up the > environmental variables before trying to configure PyQWT. I updated > the webpage to do this before anything else, so go and look at the new > order of instructions and see if that helps. > > I think I did this myself and then wrote up the description out of > order because I thought it made more logical sense. Hopefully this > does it for you. > > > Tom > > >> >> From: Tom Rondeau >> To: Tom McDermott >> Cc: GNURadio Discussion List >> Sent: Thursday, November 7, 2013 12:11 PM >> Subject: Re: [Discuss-gnuradio] Ubuntu 13.10 (Saucy Salamander) >> >> On Thu, Nov 7, 2013 at 3:07 PM, Tom Rondeau wrote: >>> On Thu, Nov 7, 2013 at 3:01 PM, Tom McDermott >>> wrote: Hi Tom, thanks for your effort. At the step where PyQt 4.10.3 is installed, python configure.py -b /opt/qt/bin -d /opt/qt/lib/python2.7/dist-packages -v /opt/qt/share/sip The command does many steps then errors out with: sh: 1: /usr/bin/sip: not found Error: Unable to create the C++ code. -- Tom >>> >>> Ah, kind of a formatting flaw on my part. I snuck this package into >>> the apt-get line above acting like everyone would start from scratch. >>> >>> You have to install the python-sip package: >>> $ sudo apt-get install python-sip >>> >>> I've updated the webpage to make this clear. >>> >>> Tom >> >> Just to be on the safe side, I also added the package "python-sip-dev" >> which might be the one that actually installs the sip binary. I have >> both on all of th
Re: [Discuss-gnuradio] The GSoC project on LDPC codes.
OK here is my next question :-) One of the other parity codes in P25 TDMA known as "ISCH" is a similar "binary code" which the specs decribe as follows: The Information field in the ISCH is 40 bits encoded with a (40, 9,16) binary code.The (40, 9,16) code derived from a (40,10,16) binary code with a generator matrix, g, 1 0 0 0 1 0 0 0 0 0 0 1 0 1 1 0 1 1 0 0 1 1 1 0 0 0 1 1 0 1 1 0 1 1 0 1 0 1 1 1 0 0 1 0 0 0 0 0 0 0 0 1 1 1 0 1 1 1 1 1 1 1 0 1 0 1 0 0 1 1 1 1 0 1 1 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 1 0 1 1 1 0 1 0 1 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1 1 0 1 1 0 1 0 0 0 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 1 1 1 0 1 1 0 1 0 0 0 1 1 1 0 1 0 0 0 0 1 0 1 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 1 0 0 0 1 1 0 0 1 0 1 1 1 0 1 0 1 0 1 0 0 1 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 0 0 1 1 1 1 0 1 1 0 0 0 0 1 0 1 1 0 0 1 0 1 1 1 Looking at this generator matrix it's not clear how to even convert it into the parity check matrix form that is needed by the cldpc module. In particular it does not have an identity matrix on the left hand side (but there is something vaguely resembling a diagonal row of ones in the leftmost 9x11 chunk of the matrix 'g'... So, the question for this time around is whether the above generator matrix is from a type of code that ldpc will work OK with? If so, how would I remap g above into the proper form of parity check matrix? FWIW, the above generator matrix g can be used to form proper P25 codewords by taking the dot product using numpy.dot() as in my previous question [which was about the 4x8 generator matrix]... Thx again Best Max___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The GSoC project on LDPC codes.
Hi,
The difference could be because of the way the encoding is implemented. My
encoding scheme is very naive. And it need ***not*** necessarily be true
that the last K bits are the data bits. Here it happened, but the encoder
does not have anything to make sure of this in general. If the decoder is
able to correct all the errors in the received vector the decoding will
return the data. So even if the codewords does not match one to one with
P25, there are no worries.
One good thing about having the data (as it is) at the end/ beginning is
that once we decode the codeword correctly, then it is trivial to get back
the data. It has as much complexity as in splitting a vector into two.
But since gr-ldpc encoding does not have this feature, (but it knows which
all positions corresponds to data-bits and also the order) it will have as
much complexity as in permuting a vector. It is still linear, and so not
going to be bottleneck.
So I don't see any reason why the user has to be picky about the exact
ordering of the parity bits in the generated codeword, unless he uses some
other decoding schemes to decode the codeword.
On Fri, Nov 8, 2013 at 4:29 AM, ikjtel wrote:
> > Now I'm wondering why I didn't get any segmentation faults.
>
> You should be able to reproduce this by loading the alist file from the
> reference site
> http://www.inference.phy.cam.ac.uk/mackay/codes/alist.html(that
> example may
> not be a good LDPC example, but should at minimum cause a fault in unfixed
> alist.cc)
>
> The next question (tl;dr) about LDPC may not be an actual bug, but I don't
> have enough
> knowledge of this topic to know for sure. All I know about the error
> correcting
> codes has been learned through experimentation and trial and error...
>
> One of the error correcting codes used in P25 has a 4x8 generator matrix
> and I've
> been able successfully to get numpy to generate code words that match what
> we've
> seen over the air from analysis of actual P25 TDMA traffic. When I tried
> to generate
> the set of all possible code words using LDPC it produced a very
> interesting result
> (see below). It appears that the codewords that gr-ldpc generates really
> are the same
> as the ones used in P25, however the generated parity bits appear before
> the user
> data bits, instead of as in P25 where the parity bits are appended after
> the original
> data bits.
>
> dataP25 gr-ldpc
> wordcodewordcodeword
>
> 0
> 1 0001011111010001
> 2 0010111001110010
> 3 0011100110100011
> 4 0100101110110100
> 5 0101110001100101
> 6 0110010111000110
> 7 0111001000010111
> 8 1000110111101000
> 9 1001101000111001
> 10 1010001110011010
> 11 1011010001001011
> 12 1100011001011100
> 13 1101000110001101
> 14 1110100000101110
> 15
>
>
> The "problem" is that if we receive say, P25 codeword 01011100 we want it
> to decode
> to 5 (0101) whereas if gr-ldpc is called upon to decode 01011100 its
> answer is 12 .
> In this small example we could clean up afterwords by adding a lookup table
> (4 bits in, 4 bits out) to map the result back to the proper value, but
> it's not clear
> that would be generalizable.
>
> I've pasted the python code below that's used to generate the second
> column in the
> table above - the example shown is for dataword='0101' (5)
>
> >>> import numpy as np
> >>>
> >>> g = np.array(np.mat('1 0 0 0 1 1 0 1; 0 1 0 0 1 0 1 1; 0 0 1 0 1 1 1 0; 0
> >>> 0 0 1 0 1 1 1'))
> >>>
> >>> codeword = np.dot([0,1,0,1], g) % 2
> >>>
> >>> print codeword
> [0 1 0 1 1 1 0 0]
> >>>
>
>
> The question (_if_ I understand things correctly) seems to be : how
> reasonable / unreasonable is it for users of the
> library to be picky about the exact ordering of the parity bits in the
> generated codewords?
>
> Thx again Manu
>
> Best
>
> Max
>
--
Manu T S
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
