[Discuss-gnuradio] Problem with GRC after installation with build-gnuradio
Hi, I have installed GR with the build-gnuradio script from Marcus. In the past it worked well on several machines, but now I have a problem with the gnuradio companion after installation. Once I start the grc from the command line I get a segmentation fault: esemannt@gr01-desktop:~/source$ gnuradio-companion Segmentation fault (core dumped) Unfortunately I get no more error information. After "dmesg" I got: [91365.599988] gnuradio-compan[28920]: segfault at 26356 ip 00026356 sp 7fffa6004ca8 error 14 in python2.7[40+271000] In the past (with an older GR version) GRC worked fine on this machine. Does anyone have an idea that might help me? Everything else, i.e uhd_find_devices and other python code, works fine. I've uploaded the logfile from installation with build-gnuradio to: http://www.cosa.fh-luebeck.de/download/gnuradio/ I'm using a: Intel® Core i7 CPU 920 @ 2.67GHz × 8 ubuntu 12.04 LTS (64-bit) Thanks in advance and best regards, Tim Esemann = ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] delete_head_blocking()
Hi, On 06/28/2013 08:57 AM, Martin Braun (CEL) wrote: Synopsis: Don't block in work() => don't use this call. Perhaps it makes sense to register a message handler (think of it as a work function for a specific message). Even if the only input of the block is a message port? Bastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] delete_head_blocking()
On Fri, Jun 28, 2013 at 10:48:09AM +0200, Bastian Bloessl wrote: > Hi, > > On 06/28/2013 08:57 AM, Martin Braun (CEL) wrote: > >Synopsis: Don't block in work() => don't use this call. > >Perhaps it makes sense to register a message handler (think of it as a > >work function for a specific message). > > Even if the only input of the block is a message port? In that case, there is no reason to block anyway. If you have two message ports as input, blocking might even cause a deadlock. 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 pgpn1zzuV4ncw.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Cannot import gnuradio
Dear Helpers, I had downgraded GNU Radio from GNU Radio 3.7 to GNU Radio 3.6.4, but when I run gnuradio-companion in Ubuntu 13.04 Terminal, I received the following message: *Cannot import gnuradio.* *Is the python path environment variable set correctly? * * All OS: PYTHONPATH* * * *Is the library path environment variable set correctly?* * Linux: LD_LIBRARY_PATH* * Windows: PATH* * MacOSX: DYLD_LIBRARY_PATH* * * I had refered to this thread http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00313.html and doone the following: 1. in .bashrc added *export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/dist-packages/* * * *2. *in CMakeLists.txt replace : * **find_package(PythonLibs)* with : * find_package(PythonLibs 2.7.4)* Thank you. Regards, XLoong ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] delete_head_blocking()
On 06/28/2013 11:21 AM, Martin Braun (CEL) wrote: On Fri, Jun 28, 2013 at 10:48:09AM +0200, Bastian Bloessl wrote: Hi, On 06/28/2013 08:57 AM, Martin Braun (CEL) wrote: Synopsis: Don't block in work() => don't use this call. Perhaps it makes sense to register a message handler (think of it as a work function for a specific message). Even if the only input of the block is a message port? In that case, there is no reason to block anyway. If you have two message ports as input, blocking might even cause a deadlock. so it is the intended behavior that the work function is called all over the time (and immediately returns)? I just checked for the pdu to tagged stream block and its called ~500k times per second. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] delete_head_blocking()
OK, I see. Thanks for that detailed explanation! Bastian On 06/28/2013 04:29 PM, Johnathan Corgan wrote: On Fri, Jun 28, 2013 at 6:48 AM, Bastian Bloessl mailto:bastian.bloe...@uibk.ac.at>> wrote: so it is the intended behavior that the work function is called all over the time (and immediately returns)? I just checked for the pdu to tagged stream block and its called ~500k times per second. This is a known issue specific to the design of streaming source blocks that depend on async message input port(s) for their content. It will be addressed after the 3.7.0 release. Basically, we need to provide a mechanism to allow a block to tell the scheduler to add reception of an async port message as one of the conditions to be satisfied before calling work(). In general on this issue, the desired block design is to handle all incoming async message port traffic using registered message handlers. The message handler(s) can then optionally generate futher outgoing async messages on output message ports and/or set block internal state as needed. Once the scheduler has dispatched all pending async messages to the block's message handlers, if the block has a work() function, conditions will be evaluated whether to call it. If called, the work function can then deal with streaming port I/O and any state updates created by the prior message handler execution. Since the GNU Radio scheduler is actually distributed among all the blocks/threads, each block has its own scheduler that wakes up when events occur, evaluates whether to call block message handlers and work() function, sends notifications to other blocks based on the return from work(), and goes back to sleep waiting for another event to occur. Blocking in either a message handler or in the work() function is very strongly discouraged, as this prevents the scheduler for that block from running and may result in deadlocks. In some cases, usually in source blocks, making blocking system calls is unavoidable, and we "get away" with doing so by using a timeout with a small value and returning. This is suboptimal for CPU usage but does allow the scheduler machinery to run. (The pdu_to_tagged_stream block cannot even do this right now.) Longer term, the plan is to add scheduler provided functions to call so block work() functions can ask the scheduler to "call me again when this happens" and the scheduler can handle the blocking/response in a way the gets along with everything else. TL;DR We're working on it :) -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com -- Dipl.-Inform. Bastian Bloessl Institute of Computer Science University of Innsbruck, Austria Phone: +43 512 507-53288 / Fax: -53079 http://ccs.uibk.ac.at/~bloessl/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] delete_head_blocking()
On Fri, Jun 28, 2013 at 6:48 AM, Bastian Bloessl wrote: > so it is the intended behavior that the work function is called all over > the time (and immediately returns)? I just checked for the pdu to tagged > stream block and its called ~500k times per second. > This is a known issue specific to the design of streaming source blocks that depend on async message input port(s) for their content. It will be addressed after the 3.7.0 release. Basically, we need to provide a mechanism to allow a block to tell the scheduler to add reception of an async port message as one of the conditions to be satisfied before calling work(). In general on this issue, the desired block design is to handle all incoming async message port traffic using registered message handlers. The message handler(s) can then optionally generate futher outgoing async messages on output message ports and/or set block internal state as needed. Once the scheduler has dispatched all pending async messages to the block's message handlers, if the block has a work() function, conditions will be evaluated whether to call it. If called, the work function can then deal with streaming port I/O and any state updates created by the prior message handler execution. Since the GNU Radio scheduler is actually distributed among all the blocks/threads, each block has its own scheduler that wakes up when events occur, evaluates whether to call block message handlers and work() function, sends notifications to other blocks based on the return from work(), and goes back to sleep waiting for another event to occur. Blocking in either a message handler or in the work() function is very strongly discouraged, as this prevents the scheduler for that block from running and may result in deadlocks. In some cases, usually in source blocks, making blocking system calls is unavoidable, and we "get away" with doing so by using a timeout with a small value and returning. This is suboptimal for CPU usage but does allow the scheduler machinery to run. (The pdu_to_tagged_stream block cannot even do this right now.) Longer term, the plan is to add scheduler provided functions to call so block work() functions can ask the scheduler to "call me again when this happens" and the scheduler can handle the blocking/response in a way the gets along with everything else. TL;DR We're working on it :) -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD error
I have 4 N210 USRP accessible via switch. Though it use to come sometime but today even uhd_find_devices gives the same error! UHD Error: Control packet attempt 0, sequence number 6: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 11: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 18: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 22: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 25: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 29: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 33: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 36: RuntimeError: no control response, possible packet loss * * *How to handle this?* I checked prior comments in mailing list but did get concrete solution. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test passes, but Linux kernel log says "undefined instruction"
> Gnu Radio v3.6.4.2 on ARM target. > make test : 100% pass. > But this happens each time python does "from gnuradio import gr_unittest": > <6>[ 390.919792] python (1771): undefined instruction: pc=42a9c328 <6>[ > 390.919822] Code: f26ee1fe e12fff1e (ee190f1d) > For example, when qa_add_and_friends is started. > This just showed up when switched from Ubuntu 12.04 LTS to 13.04, and > installed new versions of g++, libboost, etc... I went back and checked my > older 12.04 environment which does not exhibit this. My cmake configuration > was the same (except I took out -DENABLE_BAD_BOOST, as I now have Boost 1.53). > Some version changes: > g++ : 4.6.3-1ubuntu5 to 4.7.3-1ubuntu1 > python: 2.7.3 to 2.7.4 > swig: 2.0.4 to 2.0.8 > If I had not looked at the kernel log, I would not have noticed. > I'll see if I can narrow this down. But any experience appreciated. An update on this. I see the above log several times during a fresh build of gnuradio, during "cmake ../", and it starts right around this point in the cmake output: -- Looking for C++ include sys/resource.h - found -- -- Python checking for python >= 2.5 -- Python checking for python >= 2.5 - found So at least this eliminates the collection of compiler flags I have on the cmake command line I actually am using. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] benchmark_rate issue
I am doing spectrum sensing at 8MHz sampling rate using N210 series. I have 4 USRPs accessible via switch. But on setting sample rate as high as 8 MHz the code runs for few seconds and comes out with UHD Error. I did benchmark test as follows:- *./benchmark_rate --args="addr=10.32.19.159" --rx_rate 3e6 --tx_rate 3e6* * * *Report:-* "OUUOU" Benchmark rate summary: *Num received samples:27897639* * Num dropped samples: 2395800* * Num overflows detected: 660* * Num transmitted samples: 29685777* * Num sequence errors: 0* * Num underflows detected: 74568* note:-There were many "UUU"s than pasted. *./benchmark_rate --args="addr=10.32.19.159" --rx_rate 5e6 --tx_rate 5e6* * * *Report:-* Using Device: Single USRP: Device: USRP2 / N-Series Device Mboard 0: N210r4 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: SBXv3 RX TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: SBXv3 TX UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam Testing receive rate 5.00 Msps OTesting transmit rate 5.00 Msps *t erminate called after throwing an instance of 'uhd::runtime_error'* what(): RuntimeError: fifo ctrl timed out looking for acks Aborted How can I achieve higher sample rate on my system? Is it mainly due to switch in between? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] delete_head_blocking()
> > Longer term, the plan is to add scheduler provided functions to call so > block work() functions can ask the scheduler to "call me again when this > happens" and the scheduler can handle the blocking/response in a way the > gets along with everything else. > > TL;DR We're working on it :) > > This feature is already available in the advanced scheduler. Not happy with your input, just mark the port fail, your work wont get called again until the state of the port changes: https://github.com/guruofquality/gras/wiki/Codeguide#wiki-dynamic-feedback Cheers! -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD error
On 06/28/2013 12:29 PM, Jay Prakash wrote: > I have 4 N210 USRP accessible via switch. > > Though it use to come sometime but today even uhd_find_devices gives the > same error! > Same error different packets. What is your network configuration like? Is this part of the main office network/or dedicated ethernet port w/ the switch and the USRP? Do the devices eventually get found despite the error? What happens if you do uhd_find_devices --args="addr=192.168.1.myaddr" -josh > > UHD Error: > Control packet attempt 0, sequence number 6: > RuntimeError: no control response, possible packet loss > > UHD Error: > Control packet attempt 0, sequence number 11: > RuntimeError: no control response, possible packet loss > > UHD Error: > Control packet attempt 0, sequence number 18: > RuntimeError: no control response, possible packet loss > > UHD Error: > Control packet attempt 0, sequence number 22: > RuntimeError: no control response, possible packet loss > > UHD Error: > Control packet attempt 0, sequence number 25: > RuntimeError: no control response, possible packet loss > > UHD Error: > Control packet attempt 0, sequence number 29: > RuntimeError: no control response, possible packet loss > > UHD Error: > Control packet attempt 0, sequence number 33: > RuntimeError: no control response, possible packet loss > > UHD Error: > Control packet attempt 0, sequence number 36: > RuntimeError: no control response, possible packet loss > * > * > *How to handle this?* > I checked prior comments in mailing list but did get concrete solution. > > > > ___ > 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] Problem in uhd_fft
On 06/27/2013 09:44 AM, Karan Talasila wrote: > Hi, > I am using a basic tx and basic rx daughterboard for transmission and > reception. The spec says basic tx and basic rx run from 0 to 250 MHz. But > when i run transmitter and check the uhd_fft at receiver, after 32 Mhz, > there is no signal. If i set the transmitter frequency in my flowgraph as > 33 MHz, I don't get a signal at 33 Mhz, But when i enter frequency as > -31Mhz in the uhd_fft i get a received signal on my fft. why does this > happen? If it's in the range of daughter board it should be receiving it at > that particular frequency right. > > Can you tell me more about the cabling setup? Which ports of the Basic TX and RX are you using, and how are they connected via SMA cable? -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_rate issue
> > How can I achieve higher sample rate on my system? > Is it mainly due to switch in between? > >From your previous email, it sounded like you may have something "interesting" with your network configuration, or network topology. I recommend first trying with a direct connection to a gigE port on the PC. See if the applications work as expected. See if the strange errors go away. -josh PS. Also this is a real PC, not a virtual machine? Often VMs mean more networking troubles and slowness. -josh > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] digital_ofdm_cyclic_prefixer::work
Hi all, please can someone tell me why that work method ( like others in the digital_odfm_xx ) does not call consume_each (n) or consume ( i,n ) ? many thanks, Stefano ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
