Re: [Discuss-gnuradio] Installing Channel coding toolbox problem
On Wed, Jan 23, 2013 at 10:28:56AM -0800, Ghulam Rasool Begh wrote: ImportError: libgnuradio-chancoding.so.0: cannot open shared object file: No such file or directory Did you 'sudo ldconfig'? 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 pgpeOJgx_Mb4e.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio bloc design tutorial
Salut JM, thanks for posting this here. Would you mind adding a link to the GNU Radio wiki? http://gnuradio.org/redmine/projects/gnuradio/wiki/ExternalDocumentation If you do, include a link to the French version also; it's a great thing we're getting more and more docs in other languages. MB On Wed, Jan 23, 2013 at 09:00:05PM +0100, jmfriedt wrote: For what it is worth, some might (or might not) be interested in the tutorial document I wrote concerning the implementation of some decoding blocs for GNURadio, from signal processing prototyping using GNU/Octave on recorded signals to the actual bloc http://jmfriedt.free.fr/en_sdr.pdf For the French speaking audience, this document is a translation to English of the article in French published in GNU/Linux Magazine France available at http://jmfriedt.free.fr/lm_sdr.pdf, translation performed following some requests received after the Physics for Development Conference (http://www.epsphysicsfordevelopment.org/) held last October in Brussels (Belgium). As an extension of this document, I am currently completing an extension towards the implementation of some time and frequency analysis algorithms targetted at using GNURadio and the sound card interface as signal generator and acquisition (network analyzer application, frequency counter, phase measurement) for teaching and hobby applications. Any comment or correction is welcome, these documents are not aimed at being static but to evolve depending on the feedback I might receive. JM -- JM Friedt, FEMTO-ST Time Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpiBRn1YPxrj.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installing Channel coding toolbox problem
Thanks it worked now. --- On Thu, 1/24/13, Martin Braun (CEL) martin.br...@kit.edu wrote: From: Martin Braun (CEL) martin.br...@kit.edu Subject: Re: [Discuss-gnuradio] Installing Channel coding toolbox problem To: discuss-gnuradio@gnu.org Date: Thursday, January 24, 2013, 1:33 PM On Wed, Jan 23, 2013 at 10:28:56AM -0800, Ghulam Rasool Begh wrote: ImportError: libgnuradio-chancoding.so.0: cannot open shared object file: No such file or directory Did you 'sudo ldconfig'? 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 -Inline Attachment Follows- ___ 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] Tests fail building with boost1.52
On 23/01/13 15:05, Tom Rondeau wrote: On Wed, Jan 23, 2013 at 9:58 AM, Philip Balister phi...@balister.org mailto:phi...@balister.org wrote: On 01/23/2013 09:45 AM, Tom Rondeau wrote: On Wed, Jan 23, 2013 at 5:42 AM, Barry Jackson zen25...@zen.co.uk mailto:zen25...@zen.co.uk wrote: I package gnuradio for Mageia and we are having problems with test failures with 3.6.3 in our beta2 distro release. (from git tag v3.6.3 since release tarball was from 3.6.4git) We have boost-1.52 and the package builds, but fails 143 tests. Full build system log is here:- http://pkgsubmit.mageia.org/**uploads/failure/cauldron/core/** release/20130123090056.barjac.**valstar.22658/log/botcmd.** 1358931665.ecosse.loghttp://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130123090056.barjac.valstar.22658/log/botcmd.1358931665.ecosse.log As a test I set up a local system using boost-1.53 beta1. (with uhd also built on the same system) This fails only 3 tests. log is here: http://mtf.no-ip.co.uk/pub/**linux/barjac/soft/log.gnuradiohttp://mtf.no-ip.co.uk/pub/linux/barjac/soft/log.gnuradio Switching to boost-1.53 beta1 for us is not an option for a stable release, plus we are now in version freeze. Unless there is a fix for this using boost-1.52 then our only option may be to drop gnuradio from the distro. Any help will be appreciated. Barry Barry, I'm afraid we can't use Boost 1.52 with GNU Radio. See: https://svn.boost.org/trac/boost/ticket/7669 The thread join_all is very important for clean operation of a flowgraph. There's a similar bug in 1.47 that we can't use, either. In fact, you shouldn't have been able to compile against 1.52 since we've explicitly disabled it in GrBoost.cmake. Has this been reported to the boost people? There is a boost 1.53 beta, I wonder if the problem is fixed there. The link that I posted is to the Boost issue tracking system, so yes, it has been reported :) The ticket is closed as fixed, so it looks like 1.53 will work. Are the test failures related to the thread join_all problem? Philip The test failures probably aren't related to this. This bug shows up by locking the entire program on exit, so the test would never complete. The failures are probably due to some mismatch in library versions or pre-built code. As I said, we don't allow GNU Radio to build with 1.52, so my guess it that cmake actually failed, but the Makefiles were still there from previous build attempts. Tom I really don't know why the 1.52 build did not fail (without the tests). Our build system uses a clean minimal installation in chroot with only buildrequires installed, so nothing from previous builds can be left around. It was only a chance comment on irc that drew my attention to a possible problem. Using boost 1.53b1 (with or without the gruel/thread.h patch posted earlier) in a local build I see: 1 - qa_volk_test_all (Failed) 115 - qa_ctcss_squelch (Failed) 152 - qa_qtgui (Failed) Any clues as to the cause of these? Barry ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release 3.6.3 available for download
Hi, Tom and Michael, Here is part of the message when I configure to use gcc 4.7 without orc support(and the build was failed) -- ORC support not found, Overruled arch orc -- Check size of void*[8] -- Check size of void*[8] - done -- CPU width is 64 bits, Overruled arch 32 -- Available architectures: generic;64;3dnow;abm;popcount;mmx;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx -- Available machines: generic;sse2_64_mmx;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64_mmx -- Did not find liborc and orcc, disabling orc support... For volk_profile output, I'll put it on my public folder of Dropbox since it's lengthy. volk_profile output with ORC support: https://dl.dropbox.com/u/31960195/volk_profile_output.txt volk_profile output without ORC support: https://dl.dropbox.com/u/31960195/volk_profile_output_no_orc.txt Before MacPorts has GNU Radio packages, I always need to build gnuradio by myself. I remember that I need to modify some files in VOLK in order to support optimization for AVX. I don't remember the exact reason, but it's related to Apple assembler and probably xgetbv(?) instruction set. Here is the version of Apple assembler: Apple Inc version cctools-836, GNU assembler version 1.38 I wonder if I can use the latest GNU assembler with VOLK? Thank you very much! Albert Michael Dickens m...@alum.mit.edu writes: Albert - Tom (as a VOLK developer) has some good advice: (1) Try installing GNU Radio without the +orc variant, and seeing what the configure output is; combined with: (2) Run volk_profile after you've installed GNU Radio. It will test all of the kernels and create a $HOME/.volk/volk_config file. If you look in that file, it will tell you what architectures are to be used for each kernel. Tom - I'm wondering what volk_profile is doing? It looks like it's running through (all?) available kernels for a given algorithm and finding the best (fastest?) one. Is this correct? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tests fail building with boost1.52
On Thu, Jan 24, 2013 at 7:42 AM, Barry Jackson zen25...@zen.co.uk wrote: On 23/01/13 15:05, Tom Rondeau wrote: On Wed, Jan 23, 2013 at 9:58 AM, Philip Balister phi...@balister.org mailto:phi...@balister.org wrote: On 01/23/2013 09:45 AM, Tom Rondeau wrote: On Wed, Jan 23, 2013 at 5:42 AM, Barry Jackson zen25...@zen.co.uk mailto:zen25...@zen.co.uk wrote: I package gnuradio for Mageia and we are having problems with test failures with 3.6.3 in our beta2 distro release. (from git tag v3.6.3 since release tarball was from 3.6.4git) We have boost-1.52 and the package builds, but fails 143 tests. Full build system log is here:- http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/** ** http://pkgsubmit.mageia.org/**uploads/failure/cauldron/core/** release/20130123090056.barjac.valstar.22658/log/botcmd.** 1358931665.ecosse.loghttp://**pkgsubmit.mageia.org/uploads/** failure/cauldron/core/release/**20130123090056.barjac.valstar.** 22658/log/botcmd.1358931665.**ecosse.loghttp://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130123090056.barjac.valstar.22658/log/botcmd.1358931665.ecosse.log As a test I set up a local system using boost-1.53 beta1. (with uhd also built on the same system) This fails only 3 tests. log is here: http://mtf.no-ip.co.uk/pub/linux/barjac/soft/log.gnuradiohttp://mtf.no-ip.co.uk/pub/**linux/barjac/soft/log.gnuradio **http://mtf.no-ip.co.uk/pub/**linux/barjac/soft/log.gnuradiohttp://mtf.no-ip.co.uk/pub/linux/barjac/soft/log.gnuradio ** Switching to boost-1.53 beta1 for us is not an option for a stable release, plus we are now in version freeze. Unless there is a fix for this using boost-1.52 then our only option may be to drop gnuradio from the distro. Any help will be appreciated. Barry Barry, I'm afraid we can't use Boost 1.52 with GNU Radio. See: https://svn.boost.org/trac/**boost/ticket/7669https://svn.boost.org/trac/boost/ticket/7669 The thread join_all is very important for clean operation of a flowgraph. There's a similar bug in 1.47 that we can't use, either. In fact, you shouldn't have been able to compile against 1.52 since we've explicitly disabled it in GrBoost.cmake. Has this been reported to the boost people? There is a boost 1.53 beta, I wonder if the problem is fixed there. The link that I posted is to the Boost issue tracking system, so yes, it has been reported :) The ticket is closed as fixed, so it looks like 1.53 will work. Are the test failures related to the thread join_all problem? Philip The test failures probably aren't related to this. This bug shows up by locking the entire program on exit, so the test would never complete. The failures are probably due to some mismatch in library versions or pre-built code. As I said, we don't allow GNU Radio to build with 1.52, so my guess it that cmake actually failed, but the Makefiles were still there from previous build attempts. Tom I really don't know why the 1.52 build did not fail (without the tests). Our build system uses a clean minimal installation in chroot with only buildrequires installed, so nothing from previous builds can be left around. Strange. Cmake should fail with Boost not found. It was only a chance comment on irc that drew my attention to a possible problem. Using boost 1.53b1 (with or without the gruel/thread.h patch posted earlier) in a local build I see: 1 - qa_volk_test_all (Failed) 115 - qa_ctcss_squelch (Failed) 152 - qa_qtgui (Failed) Any clues as to the cause of these? Barry Could you run 'ctest -V -R test name' for these tests to see what they are? I wouldn't worry too much about the ctcss and qtgui failures. My OSX box has a problem with ctcss, too, though I've not gone to track it down since it's not a heavily used blocks. The qtgui is probably failing due to an issue with X. This will fail for me over ssh if I don't set things up correctly. The volk test is the most troubling, though. We definitely want that to pass. What's your processor? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Volk build error using MacPorts GCC 4.7
[New subject line]
Albert sent me the build log for:
{{{
sudo port install gnuradio +full configure.compiler=macports-gcc-4.7
}}}
and I can replicate the error on my computer; so, this must be a GCC 4.7 (or,
MacPorts's GCC 4.7) issue. The error is:
{{{
build/volk/lib/volk_cpu.c:54:no such instruction: `xgetbv'
}}}
VOLK folks: what other info do you need from me/us to address this issue? - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Hier signal processing block in Python
Hi all, Can somebody explain me a bit the difference between blocks written in python in the way presented on the website and blocks like packet decoder, packet encoder, gfsk modulator, etc. The latter blocks are written also in Python, but they are different than the previous. Particularly I don't understand why there are also thread classes stick to the blocks from the second group. And the most important thing is I would like to know how to make such block out of tree. Many thanks -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] installing gr-my-basic files
Hi all,While following instructions given at http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorialsfor adding a new block I faced following problem.sudo ./bootstrap executed well.But sudo ./configure gave following error: checking for GNURADIO_CORE... configure: error: Package requirements (gnuradio-core = 3) were not met: No package 'gnuradio-core' found Consider adjusting the PKG_CONFIG_PATH environment variable if youinstalled software in a non-standard prefix. Alternatively, you may set the environment variables GNURADIO_CORE_CFLAGSand GNURADIO_CORE_LIBS to avoid the need to call pkg-config.See the pkg-config man page for more details. I used following command export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH and then sudo ./configurebut it again gives the same error. Please suggest what should do now. RegardsGRB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk build error using MacPorts GCC 4.7
On 01/24/2013 07:37 AM, Michael Dickens wrote:
[New subject line]
Albert sent me the build log for:
{{{
sudo port install gnuradio +full configure.compiler=macports-gcc-4.7
}}}
and I can replicate the error on my computer; so, this must be a GCC 4.7 (or,
MacPorts's GCC 4.7) issue. The error is:
{{{
build/volk/lib/volk_cpu.c:54:no such instruction: `xgetbv'
}}}
VOLK folks: what other info do you need from me/us to address this issue? - MLD
This is a compiler problem. xgetbv was added to vanilla GCC in 4.4.
Apparently MacPorts' mutant GCC hasn't added it as of 4.7. The relevant
check is line 128 of volk/lib/CMakeLists.txt. We could just disable AVX
support on GCC 4.7, but since 4.7 is basically the latest GCC out
there it seems a little aggressive to disable AVX for everyone. I'd
rather disable AVX on Mac. I haven't done Mac-specific platform
detection in CMake; can anyone else suggest a Mac test to use here to
disable AVX on Mac?
--n
___
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] Hier signal processing block in Python
On 01/24/2013 10:20 AM, Nemanja Savic wrote: Hi all, Can somebody explain me a bit the difference between blocks written in python in the way presented on the website and blocks like packet decoder, packet encoder, gfsk modulator, etc. The latter blocks are written also in Python, but they are different than the previous. Particularly I don't understand why there are also thread classes stick to the blocks from the second group. Those old blocks are just hier blocks with some processing blocks from gnuradio, where the python interface part is outside of the scheduler, really just a python thread polling a message queue. The interface is a python function call or something. So, there are APIs to create blocks in python that actually use the scheduler. For example, here is one that does the pkt framer/correlate but presents a message interface. This block has inputs and outputs that can be connected in a gnuradio flow graph. https://github.com/guruofquality/grextras/blob/master/python/packet_framer.py Then you can do cool things like this: https://github.com/jmalsbury/pre-cog/wiki And the most important thing is I would like to know how to make such block out of tree. Most of the feature above is in gnuradio master branch, but I dont think there is a doc, so you will have to interpolate from this: https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Uninstalling Gnu Radio
HI, I want to uninstall gnu radio which i installed from the wget http://www.sbrac.org/files/build-gnuradio chmod a+x ./build-gnuradio ./build-gnuradio Can anybody tell me how to uninstall it. I used the command make uninstall but it does not work. Best Regards, SAJJAD SAFDAR___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Uninstalling Gnu Radio
Sajjad - What do you mean you used it and it didn't work. Can you provide console output detailing what happened? How do you know it didn't work? We need more details if to help you! Cheers, Ben On Thu, Jan 24, 2013 at 11:07 AM, Sajjad Safdar engrsajjadsaf...@yahoo.comwrote: HI, I want to uninstall gnu radio which i installed from the wget http://www.sbrac.org/files/build-gnuradio chmod a+x ./build-gnuradio ./build-gnuradio Can anybody tell me how to uninstall it. I used the command make uninstall but it does not work. Best Regards, SAJJAD SAFDAR ___ 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] installing gr-my-basic files
Ghulam - What instructions are you referring to? Those build commands refer to the autotools toolchain, which GNU Radio no longer uses. You should be using CMake, as detailed on this page: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules Cheers, Ben On Thu, Jan 24, 2013 at 8:41 AM, Ghulam Rasool Begh grbegh...@yahoo.comwrote: Hi all, While following instructions given at http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials for adding a new block I faced following problem. sudo ./bootstrap executed well. But sudo ./configure gave following error: *checking for GNURADIO_CORE... configure: error: Package requirements (gnuradio-core = 3) were not met:* *No package 'gnuradio-core' found* * * *Consider adjusting the PKG_CONFIG_PATH environment variable if you* *installed software in a non-standard prefix.* * * *Alternatively, you may set the environment variables GNURADIO_CORE_CFLAGS * *and GNURADIO_CORE_LIBS to avoid the need to call pkg-config.* *See the pkg-config man page for more details.* I used following command export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH and then *sudo ./configure* but it again gives the same error. Please suggest what should do now. Regards GRB ___ 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] Unknown cause of Latency with USRP
Thank you Matt and Josh for the suggestions. When I look at the output of the RF connector with an oscilloscope, when there are underruns the signal is randomly broken up with gaps even though I am flushing out data packet by packet to GNURadio. Is adding an SOB and EOB tag to the burstthe only way to fix the breaking up of the signal? The underrun messages themselves do not bother me. I thought the underruns from the USRP would happen only between sending packets so there would only be random gaps in the signal between the packets not inside the packet itself. What I'm seeing is random gaps inside of the data blocks of a packet causing detection issues on the receiver side. Without the underruns I don't see this. I will look into the SOB and EOB tags as suggested but thought I would ask if the behavior I saw was expected. Thank you, Tom From: Josh Blum j...@ettus.com To: Tom Hendrick sdtom...@yahoo.com Cc: Matt Ettus m...@ettus.com; discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Wednesday, January 23, 2013 1:52 PM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP On 01/23/2013 02:29 PM, Tom Hendrick wrote: Hello Matt, I went back and tried your suggestion of setting the transmitter at 50kbps and keeping the ffmpeg stream at 45 kbps. This actually gets rid of almost all the latency buildup however the problem is that the transmit GRC script running the USRP is now consistently giving underruns errors. This is causing the received video signal to have a lot of distortions. It seems like the video stream rate has to be lower than the transmit/receive rate like you suggested but then this causes a problem because the USRP seems to not get the samples fast enough to avoid underruns. I'm not sure if there even is a solution to this that I could easily implement with GRC. In this case you are sending finite bursts of samples. A burst should end with an of burst tag when its known that there are no more samples available (for example). This tell the USRP TX machinery not to expect more samples, otherwise, it generates an underflow message. Technically GRC is agnostic to this because its just connections. The block feeding the gnuradio stream should probably be generating this. There is an example of this in the pre-cog link I sent you (does it in python). Also, c++ example: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/examples/c++/ -josh Thanks again, Tom From: Tom Hendrick sdtom...@yahoo.com To: Matt Ettus m...@ettus.com Cc: discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org; j...@ettus.com j...@ettus.com Sent: Wednesday, January 23, 2013 10:40 AM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP Hello Matt, The ffmpeg encoder is set to 45 kbps bitrate and the transmitter/receiver is set to about 45 kbps as well. The ffmpeg encoder doesn't converge at 45 kbps exactly, but it comes close. The signals are sampled at a pretty high rate of 500 kHz and the GRC scripts resample at 1 MHz so the USRP is run at 1MS/s rates. Thank you, Tom From: Matt Ettus m...@ettus.com To: Tom Hendrick sdtom...@yahoo.com Cc: j...@ettus.com j...@ettus.com; discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Wednesday, January 23, 2013 10:34 AM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP What is the bit rate of the source and what is the bit rate of the data transmission? Matt On Wed, Jan 23, 2013 at 10:32 AM, Tom Hendrick sdtom...@yahoo.com wrote: Hello Josh, The transmitter sends data when there is enough to fill a packet. The packets are flushed about every 200msec consistently. The ffmpeg encoder seems to have a continuous output that is pretty steady since it is encoding webcam images at a pretty reasonably constant bitrate with the settings I applied. When I look on the oscilloscope output of the USRP tx board, the stream shows no gaps or pauses at all and the packets look spaced properly in time as if I had written the transmitter output directly to a file. Are the solutions you recommended something I can try implementing with GRC (for instance throttle or the gr_block api)? Making the external modulator/demodulator work in a burst type mode is something I probably don't know how to do. I know how to run the modulator/demodulator code but I didn't develop it. The only thing I can think of adjusting is the amount of data blocks inside a packet. I can increase or reduce that number and that would increase/decrease the time duration between flushing of packets. Thanks very much for your help, Tom From: Josh Blum j...@ettus.com To: discuss-gnuradio@gnu.org Sent: Tuesday, January 22, 2013 10:54 PM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP
Re: [Discuss-gnuradio] Hier signal processing block in Python
Thank you Josh, I hope your answer will help. The problem particularly with packet decoder block which could be found in packet.py is that I can't figure out how messages goes from framer sink to the message source. Namely, framer sink sends message to the queue. There is a thread responsible for reading message from the queue and for calculating crc. After that, callback function is called and if message was OK, it will post message again to the queue (Isn't there only one queue between two blocks and both read from and write to that queue?). By the way, do you think that message source sounds like block which produces messages (that's what i was thinking at first glance, but maybe cause I am not native speaker)? Cheers On Thu, Jan 24, 2013 at 7:25 PM, Josh Blum j...@ettus.com wrote: On 01/24/2013 10:20 AM, Nemanja Savic wrote: Hi all, Can somebody explain me a bit the difference between blocks written in python in the way presented on the website and blocks like packet decoder, packet encoder, gfsk modulator, etc. The latter blocks are written also in Python, but they are different than the previous. Particularly I don't understand why there are also thread classes stick to the blocks from the second group. Those old blocks are just hier blocks with some processing blocks from gnuradio, where the python interface part is outside of the scheduler, really just a python thread polling a message queue. The interface is a python function call or something. So, there are APIs to create blocks in python that actually use the scheduler. For example, here is one that does the pkt framer/correlate but presents a message interface. This block has inputs and outputs that can be connected in a gnuradio flow graph. https://github.com/guruofquality/grextras/blob/master/python/packet_framer.py Then you can do cool things like this: https://github.com/jmalsbury/pre-cog/wiki And the most important thing is I would like to know how to make such block out of tree. Most of the feature above is in gnuradio master branch, but I dont think there is a doc, so you will have to interpolate from this: https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unknown cause of Latency with USRP
On 01/24/2013 04:07 PM, Tom Hendrick wrote: Thank you Matt and Josh for the suggestions. When I look at the output of the RF connector with an oscilloscope, when there are underruns the signal is randomly broken up with gaps even though I am flushing out data packet by packet to GNURadio. Is adding an SOB and EOB tag to the burstthe only way to fix the breaking up of the signal? The underrun messages themselves do not bother me. In a bursty transmission like this, underflow messages can only be fixed by setting EOB. When an underflow happens, the USRP remains in transmit state for some time window rather that switching at the EOB. If you are relying on some sort of antenna switching, then this could be an issue if you are receiving from the same device. I thought the underruns from the USRP would happen only between sending packets so there would only be random gaps in the signal between the packets not inside the packet itself. What I'm seeing is random gaps inside of the data blocks of a packet causing detection issues on the receiver side. Without the underruns I don't see this. I will look into the SOB and EOB tags as suggested but thought I would ask if the behavior I saw was expected. The underflows should only happen in places where the device is starved. So probably in between packets of data from your source. So I wouldnt expect random gaps in the middle of useful data. -josh Thank you, Tom From: Josh Blum j...@ettus.com To: Tom Hendrick sdtom...@yahoo.com Cc: Matt Ettus m...@ettus.com; discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Wednesday, January 23, 2013 1:52 PM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP On 01/23/2013 02:29 PM, Tom Hendrick wrote: Hello Matt, I went back and tried your suggestion of setting the transmitter at 50kbps and keeping the ffmpeg stream at 45 kbps. This actually gets rid of almost all the latency buildup however the problem is that the transmit GRC script running the USRP is now consistently giving underruns errors. This is causing the received video signal to have a lot of distortions. It seems like the video stream rate has to be lower than the transmit/receive rate like you suggested but then this causes a problem because the USRP seems to not get the samples fast enough to avoid underruns. I'm not sure if there even is a solution to this that I could easily implement with GRC. In this case you are sending finite bursts of samples. A burst should end with an of burst tag when its known that there are no more samples available (for example). This tell the USRP TX machinery not to expect more samples, otherwise, it generates an underflow message. Technically GRC is agnostic to this because its just connections. The block feeding the gnuradio stream should probably be generating this. There is an example of this in the pre-cog link I sent you (does it in python). Also, c++ example: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/examples/c++/ -josh Thanks again, Tom From: Tom Hendrick sdtom...@yahoo.com To: Matt Ettus m...@ettus.com Cc: discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org; j...@ettus.com j...@ettus.com Sent: Wednesday, January 23, 2013 10:40 AM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP Hello Matt, The ffmpeg encoder is set to 45 kbps bitrate and the transmitter/receiver is set to about 45 kbps as well. The ffmpeg encoder doesn't converge at 45 kbps exactly, but it comes close. The signals are sampled at a pretty high rate of 500 kHz and the GRC scripts resample at 1 MHz so the USRP is run at 1MS/s rates. Thank you, Tom From: Matt Ettus m...@ettus.com To: Tom Hendrick sdtom...@yahoo.com Cc: j...@ettus.com j...@ettus.com; discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Wednesday, January 23, 2013 10:34 AM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP What is the bit rate of the source and what is the bit rate of the data transmission? Matt On Wed, Jan 23, 2013 at 10:32 AM, Tom Hendrick sdtom...@yahoo.com wrote: Hello Josh, The transmitter sends data when there is enough to fill a packet. The packets are flushed about every 200msec consistently. The ffmpeg encoder seems to have a continuous output that is pretty steady since it is encoding webcam images at a pretty reasonably constant bitrate with the settings I applied. When I look on the oscilloscope output of the USRP tx board, the stream shows no gaps or pauses at all and the packets look spaced properly in time as if I had written the transmitter output directly to a file. Are the solutions you recommended something I can try implementing with GRC (for instance throttle or the gr_block api)? Making the external modulator/demodulator
Re: [Discuss-gnuradio] Unknown cause of Latency with USRP
Hello Josh, Thanks again I don't need to do any tx switching. I have a dedicated USRP for the transmitter and a dedicated USRP for the receiver for a 1 way transmission for now. I'm guessing I won't need to worry about the SOB and EOB unless I want to see the underruns go away. This isn't an issue except for the fact the signal is broken up with gaps inside of each packet. I don't know why that is happening. I'm pretty sure the data is flushed packet by packet. Is there anything else you can think of that could cause this? I can go back and double check to make sure the transmitter is indeed flushing out data only once a packet is made. Thank you, Tom From: Josh Blum j...@ettus.com To: Tom Hendrick sdtom...@yahoo.com Cc: discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Thursday, January 24, 2013 2:36 PM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP On 01/24/2013 04:07 PM, Tom Hendrick wrote: Thank you Matt and Josh for the suggestions. When I look at the output of the RF connector with an oscilloscope, when there are underruns the signal is randomly broken up with gaps even though I am flushing out data packet by packet to GNURadio. Is adding an SOB and EOB tag to the burstthe only way to fix the breaking up of the signal? The underrun messages themselves do not bother me. In a bursty transmission like this, underflow messages can only be fixed by setting EOB. When an underflow happens, the USRP remains in transmit state for some time window rather that switching at the EOB. If you are relying on some sort of antenna switching, then this could be an issue if you are receiving from the same device. I thought the underruns from the USRP would happen only between sending packets so there would only be random gaps in the signal between the packets not inside the packet itself. What I'm seeing is random gaps inside of the data blocks of a packet causing detection issues on the receiver side. Without the underruns I don't see this. I will look into the SOB and EOB tags as suggested but thought I would ask if the behavior I saw was expected. The underflows should only happen in places where the device is starved. So probably in between packets of data from your source. So I wouldnt expect random gaps in the middle of useful data. -josh Thank you, Tom From: Josh Blum j...@ettus.com To: Tom Hendrick sdtom...@yahoo.com Cc: Matt Ettus m...@ettus.com; discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Wednesday, January 23, 2013 1:52 PM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP On 01/23/2013 02:29 PM, Tom Hendrick wrote: Hello Matt, I went back and tried your suggestion of setting the transmitter at 50kbps and keeping the ffmpeg stream at 45 kbps. This actually gets rid of almost all the latency buildup however the problem is that the transmit GRC script running the USRP is now consistently giving underruns errors. This is causing the received video signal to have a lot of distortions. It seems like the video stream rate has to be lower than the transmit/receive rate like you suggested but then this causes a problem because the USRP seems to not get the samples fast enough to avoid underruns. I'm not sure if there even is a solution to this that I could easily implement with GRC. In this case you are sending finite bursts of samples. A burst should end with an of burst tag when its known that there are no more samples available (for example). This tell the USRP TX machinery not to expect more samples, otherwise, it generates an underflow message. Technically GRC is agnostic to this because its just connections. The block feeding the gnuradio stream should probably be generating this. There is an example of this in the pre-cog link I sent you (does it in python). Also, c++ example: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/examples/c++/ -josh Thanks again, Tom From: Tom Hendrick sdtom...@yahoo.com To: Matt Ettus m...@ettus.com Cc: discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org; j...@ettus.com j...@ettus.com Sent: Wednesday, January 23, 2013 10:40 AM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP Hello Matt, The ffmpeg encoder is set to 45 kbps bitrate and the transmitter/receiver is set to about 45 kbps as well. The ffmpeg encoder doesn't converge at 45 kbps exactly, but it comes close. The signals are sampled at a pretty high rate of 500 kHz and the GRC scripts resample at 1 MHz so the USRP is run at 1MS/s rates. Thank you, Tom From: Matt Ettus m...@ettus.com To: Tom Hendrick sdtom...@yahoo.com Cc: j...@ettus.com j...@ettus.com; discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Wednesday, January 23, 2013 10:34 AM Subject: Re:
Re: [Discuss-gnuradio] Volk build error using MacPorts GCC 4.7
Hi Nick - I'll also query the MacPorts developers with respect to this issue, to see if they can address it instead of GR folks trying to work around some Mac-specific idiosyncrasy. Can you point me to a changelog or something equivalent which shows that AVX support is in the mainline GCC as of 4.4? And, also, what exactly is AVX support in the first place? I assume it's some variant on SIMD related to SSE1/2/3/4 or the like? - MLD On Jan 24, 2013, at 1:13 PM, Nick Foster n...@ettus.com wrote: This is a compiler problem. xgetbv was added to vanilla GCC in 4.4. Apparently MacPorts' mutant GCC hasn't added it as of 4.7. The relevant check is line 128 of volk/lib/CMakeLists.txt. We could just disable AVX support on GCC 4.7, but since 4.7 is basically the latest GCC out there it seems a little aggressive to disable AVX for everyone. I'd rather disable AVX on Mac. I haven't done Mac-specific platform detection in CMake; can anyone else suggest a Mac test to use here to disable AVX on Mac? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] installing gr_modtool
Hi all,In my system when i use commandgr_modtoolit shows command not found.How can I install it. RegardsGRB___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk build error using MacPorts GCC 4.7
Nick Foster n...@ettus.com writes:
On 01/24/2013 07:37 AM, Michael Dickens wrote:
[New subject line]
Albert sent me the build log for:
{{{
sudo port install gnuradio +full configure.compiler=macports-gcc-4.7
}}}
and I can replicate the error on my computer; so, this must be a GCC 4.7
(or, MacPorts's GCC 4.7) issue. The error is:
{{{
build/volk/lib/volk_cpu.c:54:no such instruction: `xgetbv'
}}}
VOLK folks: what other info do you need from me/us to address this issue? -
MLD
This is a compiler problem. xgetbv was added to vanilla GCC in
4.4. Apparently MacPorts' mutant GCC hasn't added it as of 4.7. The
relevant check is line 128 of volk/lib/CMakeLists.txt. We could just
disable AVX support on GCC 4.7, but since 4.7 is basically the
latest GCC out there it seems a little aggressive to disable AVX for
everyone. I'd rather disable AVX on Mac. I haven't done Mac-specific
platform detection in CMake; can anyone else suggest a Mac test to use
here to disable AVX on Mac?
Hi, Nick and Michael,
After digging into this issue, I found an answer on MacPorts list, and
it's related to Apple's ancient assembler(version 1.38). In this post,
they try to replace Apple /usr/bin/as by clang's assembler.
http://lists.macosforge.org/pipermail/macports-dev/2011-October/016335.html
I tried this approach to compile gnuradio with gcc 4.7, it's still not
successful. But it seems to be an interesting and possible way -- to use
clang's assembler to optimize for AVX on MacOSX. GNU binutil on MacOSX
does not come with GNU assembler, so gcc 4.7 on MacOSX uses the built-in
GNU assembler, which is very old and does not support AVX. Only clang's
assembler on MacOSX provides support to AVX instruction set.
Albert
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
