[Discuss-gnuradio] How to use a single-threaded scheduler
Dear list, Is there any way to use the single-threaded scheduler over the thread-per-block scheduler without rebuilding Gnu Radio? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to use a single-threaded scheduler
The reason why I bring this up, is because I think I may have found an error in the scheduler; or at least a shortcoming in the way that it schedules different ‘scheduling domains’. I have several sub-flowgraphs in my flow graph. What I mean by this is that my program (with a single top block) has several disjoint flow graphs with separate sources and sinks. I say that each of these sub-flowgraphs are in separate 'scheduling domains' because they _should_ be scheduled independently by the same scheduler. Is this an incorrect understanding of mine? I have a test system that streams floats from a file through a throttle, into a series of FFTs, through a custom throughput block (which tells me the throughput of the data flowing through it) , and into a file sink. A necessary component of my system is a queue that temporarily holds ‘windows’ to be computed via the FFT, and then another queue after the FFTs that holds the resulting windows. Because this queue ties two sub-flowgraphs together, they should work in tandem. I ran the system without queues, with a single queue, and with two queues to get throughput values. My results were not as I had predicted: Queue_sink: is a Flowgraph sink that grabs the data from input buffer, populates ‘window’ vectors, and pushes a reference to the vectors into a boost lock free queue. Queue_source: is a Flowgraph source that grabs ‘window’ references from the lock free queue, and populates the output buffer. If my system has two queues: [file source] - [throttle] - [input queue sink] ||INPUT QUEUE|| - [input queue source] - FFTs - [output queue sink] - ||INPUT QUEUE|| - [output queue source] - [throughput] - [file sink] With this configuration, I get an average throughput of : 0.235 MS/S (which is ~ 80% less than the queue-free system) Here’s where it gets weird! If my system has ONE queue, placed before the FFTs: [file source] - [throttle] - [input queue sink] ||INPUT QUEUE|| - [input queue source] - FFTs - [throughput] - [file sink] With this configuration, I get an average throughput of : 0.208 MS/S! (not significantly less than the 2-queue system, but still less!) If my system has ONE queue, placed after the FFTs: [file source] - [throttle] - FFTs - [output queue sink] - ||INPUT QUEUE|| - [output queue source] - [throughput] - [file sink] With this configuration, I get an average throughput of : 0.409 MS/S! (which is ONLY 6% less than the queue-free system) This leads me to believe that there may be a flaw in the scheduler. Do I have an incorrect understanding of how it should work? Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 31, 2014, at 12:49 PM, Bogdan Diaconescu b_diacone...@yahoo.com wrote: On older gnuradio releases there was an environment variable to set so that it will switch to single threaded scheduler. Cannot remember the name, though. Bogdan On Monday, March 31, 2014 7:35 PM, Tommy Tracy II tj...@virginia.edu wrote: Dear list, Is there any way to use the single-threaded scheduler over the thread-per-block scheduler without rebuilding Gnu Radio? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Finding error: thread[thread-per-block[357]: block queue_sink (4)]: std::bad_alloc
Dear Marcus, Thank you. I will explain my setup and system below I am running Ubuntu 13.04, kernel: 3.8.0-35-generic in a VM. I am using a pybombs-installed GR version v3.7.2.1-195-g19d111e2. The description below is a small component of my overall system design; what I’m seeking to do is include a multiple-producer, multiple-consumer queue into the flow graph. The c++ code for this test program is here: Source: https://github.com/tjt7a/GR-Router/blob/master/apps/transparent.cc The flow graph: [WAVFILE SOURCE] - [THROTTLE] - several[FFT/IFFT]s - [THROUGHPUT] - [OUTPUT QUEUE SINK] —|QUEUE|— [OUTPUT QUEUE SOURCE] - [FILE SINK] It may seem unnecessary to include a QUEUE in the case about, but I am benchmarking having a QUEUE vs. not using one. Explaining the different blocks: [FFT/IFFT] block is a hierarchical dummy load. It accepts a stream of floats, vectorizes the stream, does a forward FFT, then a reverse FFT, and de-vectorizes. Source: https://github.com/tjt7a/GR-Router/blob/master/apps/fft_ifft.cc [THROUGHPUT] block is a transparent block that returns the running average throughput; it’s basically the compliment of the [THROTTLE BLOCK] (existing gnu radio::blocks) Source: https://github.com/tjt7a/GR-Router/blob/master/lib/throughput_impl.cc **This is where I’m getting the error message** [OUTPUT QUEUE SINK] block accepts a stream of floats, packages them into a series of 1024-float vectors, tacks on a message type, message index, and message size, and pushes the address of these messages onto the lock free queue. Source: https://github.com/tjt7a/GR-Router/blob/master/lib/queue_sink_impl.cc (I would ignore the if(preserve) for now) |QUEUE|: This is a boost::lockfree::queue. This queue supports multiple producers and consumers. It dynamically grows in size. (unless I were to constrain the size) Source: http://www.boost.org/doc/libs/1_53_0/doc/html/boost/lockfree/queue.html [OUTPUT QUEUE SOURCE] block is basically the compliment of the [OUTPUT QUEUE SINK] block. It pops message addresses off of the queue, reads headers, and dumps the data on the output. Source: https://github.com/tjt7a/GR-Router/blob/master/lib/queue_source_impl.cc ( I would ignore the if(preserve) and if(order) cases for now … I plan to use a heap in the future for ordering) Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 27, 2014, at 4:41 AM, Marcus Müller mar...@hostalia.de wrote: Signed PGP part Hi Tommy, as this, I haven't seen it. However, this is really guessing - could you supply a little more information (Platform, GR version, OS version etc) and try to do a backtrace? Since you have problems with low-level and scheduler-related code (and if I remember correctly, not the first time), a little information on your application as whole and in detail how you use that block would obviously be of help ;) Greetings, Marcus On 27.03.2014 06:09, Tommy Tracy II wrote: Dear Gnuradio Community, I ran my GNURADIO program and got the following error message: thread[thread-per-block[357]: block queue_sink (4)]: std::bad_alloc This looks like a memory allocation problem with the scheduler. Has anyone seen this before? What would cause this? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Finding error: thread[thread-per-block[357]: block queue_sink (4)]: std::bad_alloc
Solved my problem; I wasn’t deleting the float arrays in the sink. Silly mistake. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 27, 2014, at 10:27 AM, Tommy Tracy II tj...@virginia.edu wrote: Dear Marcus, Thank you. I will explain my setup and system below I am running Ubuntu 13.04, kernel: 3.8.0-35-generic in a VM. I am using a pybombs-installed GR version v3.7.2.1-195-g19d111e2. The description below is a small component of my overall system design; what I’m seeking to do is include a multiple-producer, multiple-consumer queue into the flow graph. The c++ code for this test program is here: Source: https://github.com/tjt7a/GR-Router/blob/master/apps/transparent.cc The flow graph: [WAVFILE SOURCE] - [THROTTLE] - several[FFT/IFFT]s - [THROUGHPUT] - [OUTPUT QUEUE SINK] —|QUEUE|— [OUTPUT QUEUE SOURCE] - [FILE SINK] It may seem unnecessary to include a QUEUE in the case about, but I am benchmarking having a QUEUE vs. not using one. Explaining the different blocks: [FFT/IFFT] block is a hierarchical dummy load. It accepts a stream of floats, vectorizes the stream, does a forward FFT, then a reverse FFT, and de-vectorizes. Source: https://github.com/tjt7a/GR-Router/blob/master/apps/fft_ifft.cc [THROUGHPUT] block is a transparent block that returns the running average throughput; it’s basically the compliment of the [THROTTLE BLOCK] (existing gnu radio::blocks) Source: https://github.com/tjt7a/GR-Router/blob/master/lib/throughput_impl.cc **This is where I’m getting the error message** [OUTPUT QUEUE SINK] block accepts a stream of floats, packages them into a series of 1024-float vectors, tacks on a message type, message index, and message size, and pushes the address of these messages onto the lock free queue. Source: https://github.com/tjt7a/GR-Router/blob/master/lib/queue_sink_impl.cc (I would ignore the if(preserve) for now) |QUEUE|: This is a boost::lockfree::queue. This queue supports multiple producers and consumers. It dynamically grows in size. (unless I were to constrain the size) Source: http://www.boost.org/doc/libs/1_53_0/doc/html/boost/lockfree/queue.html [OUTPUT QUEUE SOURCE] block is basically the compliment of the [OUTPUT QUEUE SINK] block. It pops message addresses off of the queue, reads headers, and dumps the data on the output. Source: https://github.com/tjt7a/GR-Router/blob/master/lib/queue_source_impl.cc ( I would ignore the if(preserve) and if(order) cases for now … I plan to use a heap in the future for ordering) Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 27, 2014, at 4:41 AM, Marcus Müller mar...@hostalia.de wrote: Signed PGP part Hi Tommy, as this, I haven't seen it. However, this is really guessing - could you supply a little more information (Platform, GR version, OS version etc) and try to do a backtrace? Since you have problems with low-level and scheduler-related code (and if I remember correctly, not the first time), a little information on your application as whole and in detail how you use that block would obviously be of help ;) Greetings, Marcus On 27.03.2014 06:09, Tommy Tracy II wrote: Dear Gnuradio Community, I ran my GNURADIO program and got the following error message: thread[thread-per-block[357]: block queue_sink (4)]: std::bad_alloc This looks like a memory allocation problem with the scheduler. Has anyone seen this before? What would cause this? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Finding error: thread[thread-per-block[357]: block queue_sink (4)]: std::bad_alloc
Dear Gnuradio Community, I ran my GNURADIO program and got the following error message: thread[thread-per-block[357]: block queue_sink (4)]: std::bad_alloc This looks like a memory allocation problem with the scheduler. Has anyone seen this before? What would cause this? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with TCP Source module in the client mode
Dear Martin, Sorry for the delayed response. My code is all written in C++; I am not using the GRC. These canvasses; are they separate top blocks? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 4, 2014, at 3:03 AM, Martin Braun martin.br...@ettus.com wrote: On 03.03.2014 17:57, Igor Volodin wrote: Hi all! I am trying to build following simple scheme: Signal source -- TCP Sink (server mode) TCP Source (client mode) -- GUI Scope Sink It's strange but this simple scheme isn't working. Are you running both sub-flowgraphs in the same GRC canvas? I just tried this in 2 canvases and it works. It *should* work from one, but I'm not sure GRC is setting things up right. In any case, try 2 canvases. M sockstat shows me: USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS igor python2.7 56206 11 tcp4 10.21.32.6:21950 10.21.32.6:12000 Looks like communication between tcp sink and tcp source blocks has been established, but tcpdump doesn't show any packets I decided to check first part of my scheme (Signal source + TCP Sink), and connected using netcat utility to the tcp sink port. All looks OK, the values come as expected. Can anybody explain, why this simple scheme doesn't work? Best regards, Igor ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr::buffer::index_add Assertion failure
Dear community, Every now and then, when I execute my GNU Radio program, I get the following error. Has someone seen this before? It looks like a buffer access problem, but I’m not sure why it happens on and off /home/tjt7a/src/pybombs/src/gnuradio/gnuradio-runtime/include/gnuradio/buffer.h:170: unsigned int gr::buffer::index_add(unsigned int, unsigned int): Assertion `s d_bufsize' failed. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How does a C++ custom block kill the FlowGraph
Thank you.
I have another question.
I have a strange situation where I have two sub-flowgraphs. The two
sub-flowgraphs are connected by a message queue. The 1st Sink can talk to the
2nd Source through this queue.
TOP BLOCK{
1st subgraph [1st Source]——[…]——[1st Sink]
2nd subgraph [2nd Source] ——[…]——[2nd Sink]
}
Both sub-flowgraphs use the same top block (you can’t have two top blocks in
one application). Unfortunately, because they are disjoint, if the 1st Source
returns WORK_DONE, it won’t call the other blocks’ destructors as I would
expect. It appears that 2nd Source needs to return WORK_DONE as well to kill
it’s subgraph, and thus the entire flow graph.
My problem is that 2nd Source depends on 1st Sink. My original plan was for 1st
Sink to send a message ‘stop’ to 2nd Source, which would then return WORK_DONE
and effectively kill the entire flow graph. Unfortunately, my plan was to do
this in the destructor of 1st Sink, because at that point the 1st’s sink know’s
it’s done processing. This destructor isn’t called until all blocks are done,
so I’ve got a cyclic dependency.
Is it possible for blocks to know if other blocks are done? I could have some
code in my 1st Sink's work function send that ‘stop’ message outside of the
destructor as originally intended.
Sincerely,
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
On Feb 10, 2014, at 12:33 PM, Martin Braun martin.br...@ettus.com wrote:
On 10.02.2014 09:18, Tommy Tracy II wrote:
Dear Gnuradio Community,
I have some custom gnu radio blocks that make up my flow graph. I want
one of my blocks to kill this flow graph (cause all blocks to call their
destructors). When the source is computing its last set of inputs, I
want it to let all the other blocks know it’s time to stop. Ideally,
this source would finish its computation, and allow the sink block to
sink the data before stopping. How would I go about doing this?
Have your block return WORK_DONE (or -1) in the work function.
Note this doesn't call the destructors, though! They get called when your
blocks go out of scope. It makes blocks call their stop(), though.
MB
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How does a C++ custom block kill the FlowGraph
Dear Gnuradio Community, I have some custom gnu radio blocks that make up my flow graph. I want one of my blocks to kill this flow graph (cause all blocks to call their destructors). When the source is computing its last set of inputs, I want it to let all the other blocks know it’s time to stop. Ideally, this source would finish its computation, and allow the sink block to sink the data before stopping. How would I go about doing this? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Getting pybombs to work with GR-LDPC
Dear Gnuradio community,
I’m trying to install gr-ldpc using pybombs, but I get the following error. I
expect it has something to do with conflicting versions of pybombs and that
someone has seen this before. Does anyone know how to set the swig path? I know
where the required ‘gnuradio.i’ file is located:
~/src/pybombs/src/gnuradio/gnuradio-runtime/swig/gnuradio.i
but I’m not sure how to add that location to the path that pybombs is searching.
--
tjt7a@ubuntu:~/src/pybombs$ ./pybombs install gr-ldpc
Settled on prefix: /home/tjt7a/src/target
Initializing environmental variables...
/home/tjt7a/src/target/python/:/home/tjt7a/src/target/lib/python2.6/site-packages/:/home/tjt7a/src/target/lib64/python2.6/site-packages/:/home/tjt7a/src/target/lib/python2.6/dist-packages/:/home/tjt7a/src/target/lib64/python2.6/dist-packages/:/home/tjt7a/src/target/lib/python2.7/site-packages/:/home/tjt7a/src/target/lib64/python2.7/site-packages/:/home/tjt7a/src/target/lib/python2.7/dist-packages/:/home/tjt7a/src/target/lib64/python2.7/dist-packages/:/home/tjt7a/src/target/python/:/home/tjt7a/src/target/lib/python2.6/site-packages/:/home/tjt7a/src/target/lib64/python2.6/site-packages/:/home/tjt7a/src/target/lib/python2.6/dist-packages/:/home/tjt7a/src/target/lib64/python2.6/dist-packages/:/home/tjt7a/src/target/lib/python2.7/site-packages/:/home/tjt7a/src/target/lib64/python2.7/site-packages/:/home/tjt7a/src/target/lib/python2.7/dist-packages/:/home/tjt7a/src/target/lib64/python2.7/dist-packages/
-- loading recipes ---
Loading recipes ...
Loading recipes ... done
-- loading recipes finished --
checking for gr-ldpc
False
/home/tjt7a/src/pybombs/mod_pybombs/sysutils.py:598: RuntimeWarning: tempnam is
a potential security risk to your program
tmpfile = os.tempnam(d);
TMPFILE = /home/tjt7a/src/target/fileC2snMh
WRITE PERMS OK /home/tjt7a/src/target/fileC2snMh
installing gr-ldpc
gr-ldpc dep [['gnuradio', 'git', 'cmake']]
gnuradio dep [['make', 'boost', 'fftw', 'cppunit', 'swig', 'gsl', 'uhd', 'git',
'python', 'cheetah', 'wxpython', 'numpy', 'lxml', 'pygtk', 'pycairo', 'cmake',
'pyqt4', 'pyqwt5', 'gcc', 'ice', 'git', 'cmake']]
git dep [['wget', 'curl']]
cmake dep [['wget']]
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed version
of cmake (2.8.10) is = than 2.8.3
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed version
of cmake-data (2.8.10) is = than 2.8.3
packages to install: ['gr-ldpc']
install called (gr-ldpc)
install type priority: ['deb', 'src']
install deb called (gr-ldpc)
no deb satisfiers available
install src called (gr-ldpc)
state = configure
Current step: (gr-ldpc :: make)
make
('\nmake -j4\n', '\nmake -j4\n')
bash exec (/home/tjt7a/src/pybombs/src/gr-ldpc/build)::
make -j4
[ 3%] Built target _ldpc_swig_doc_tag
[ 46%] [ 53%] Built target gnuradio-ldpc
[ 56%] Built target pygen_python_5aba1
Built target _ldpc_swig_swig_tag
[ 60%] [ 60%] Swig source
Built target pygen_apps_9a6dd
[ 66%] [ 70%] Built target test-ldpc
Swig source
/home/tjt7a/src/pybombs/src/gr-ldpc/swig/ldpc_swig.i:5: Error: Unable to find
'gnuradio.i'
make[2]: *** [swig/ldpc_swigPYTHON_wrap.cxx] Error 1
make[1]: *** [swig/CMakeFiles/_ldpc_swig.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
/home/tjt7a/src/pybombs/src/gr-ldpc/swig/ldpc_swig.i:5: Error: Unable to find
'gnuradio.i'
make[2]: *** [swig/ldpc_swigPYTHON_wrap.cxx] Error 1
make[1]: *** [swig/CMakeFiles/pygen_swig_7c327.dir/all] Error 2
make: *** [all] Error 2
ERROR:root:PyBOMBS Make step failed for package (gr-ldpc) please see bash
output above for a reason (hint: look for the word Error)
--
Sincerely,
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting pybombs to work with GR-LDPCree
had the problem, and I had to manually change the
CMake files to get to the error I submitted in the previous message.
Information about my system:
OS
Distributor ID: Ubuntu
Description:Ubuntu 13.04
Release:13.04
Codename: raring
GNURADIO
tjt7a@ubuntu:~/src/pybombs$ gnuradio-config-info -v
v3.7.2.1-195-g19d111e2
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
On Feb 10, 2014, at 3:42 PM, Marc Hölscher marc.hoelsc...@posteo.de wrote:
Hi,
could you provide some details on your system/OS/relevant packages
installed ?
I assume you did not alter the gnuradio recipe for an older version or
an obscure fork.
In Debian 7.4.0 on a 32 bit system it compiles flawless (tested right
now).
Greetings,
Marc Hölscher
On 10/02/14 17:57, Tommy Tracy II wrote:
Dear Gnuradio community,
I?m trying to install gr-ldpc using pybombs, but I get the
following error. I expect it has something to do with conflicting
versions of pybombs and that someone has seen this before. Does
anyone know how to set the swig path? I know where the required
?gnuradio.i? file is located:
~/src/pybombs/src/gnuradio/gnuradio-runtime/swig/gnuradio.i but I?m
not sure how to add that location to the path that pybombs is
searching. --
tjt7a@ubuntu:~/src/pybombs$ ./pybombs install gr-ldpc Settled on
prefix: /home/tjt7a/src/target Initializing environmental
variables...
/home/tjt7a/src/target/python/:/home/tjt7a/src/target/lib/python2.6/site-packages/:/home/tjt7a/src/target/lib64/python2.6/site-packages/:/home/tjt7a/src/target/lib/python2.6/dist-packages/:/home/tjt7a/src/target/lib64/python2.6/dist-packages/:/home/tjt7a/src/target/lib/python2.7/site-packages/:/home/tjt7a/src/target/lib64/python2.7/site-packages/:/home/tjt7a/src/target/lib/python2.7/dist-packages/:/home/tjt7a/src/target/lib64/python2.7/dist-packages/:/home/tjt7a/src/target/python/:/home/tjt7a/src/target/lib/python2.6/site-packages/:/home/tjt7a/src/target/lib64/python2.6/site-packages/:/home/tjt7a/src/target/lib/python2.6/dist-packages/:/home/tjt7a/src/target/lib64/python2.6/dist-packages/:/home/tjt7a/src/target/lib/python2.7/site-packages/:/home/tjt7a/src/target/lib64/python2.7/site-packages/:/home/tjt7a/src/target/lib/python2.7/dist-packages/:/home/tjt7a/src/target/lib64/python2.7/dist-packages/
-- loading recipes ---
Loading recipes ... Loading recipes ... done -- loading
recipes finished --
checking for gr-ldpc False
/home/tjt7a/src/pybombs/mod_pybombs/sysutils.py:598:
RuntimeWarning: tempnam is a potential security risk to your
program tmpfile = os.tempnam(d); TMPFILE =
/home/tjt7a/src/target/fileC2snMh WRITE PERMS OK
/home/tjt7a/src/target/fileC2snMh installing gr-ldpc gr-ldpc dep
[['gnuradio', 'git', 'cmake']] gnuradio dep [['make', 'boost',
'fftw', 'cppunit', 'swig', 'gsl', 'uhd', 'git', 'python',
'cheetah', 'wxpython', 'numpy', 'lxml', 'pygtk', 'pycairo',
'cmake', 'pyqt4', 'pyqwt5', 'gcc', 'ice', 'git', 'cmake']] git dep
[['wget', 'curl']] cmake dep [['wget']] PyBombs.sysutils - INFO -
have_deb: Satisfies requirement...installed version of cmake
(2.8.10) is = than 2.8.3 PyBombs.sysutils - INFO - have_deb:
Satisfies requirement...installed version of cmake-data (2.8.10)
is
= than 2.8.3 packages to install: ['gr-ldpc'] install called
(gr-ldpc) install type priority: ['deb', 'src'] install deb called
(gr-ldpc) no deb satisfiers available install src called
(gr-ldpc) state = configure Current step: (gr-ldpc :: make) make
('\n make -j4\n', '\nmake -j4\n') bash exec
(/home/tjt7a/src/pybombs/src/gr-ldpc/build):: make -j4
[ 3%] Built target _ldpc_swig_doc_tag [ 46%] [ 53%] Built target
gnuradio-ldpc [ 56%] Built target pygen_python_5aba1 Built target
_ldpc_swig_swig_tag [ 60%] [ 60%] Swig source Built target
pygen_apps_9a6dd [ 66%] [ 70%] Built target test-ldpc Swig source
/home/tjt7a/src/pybombs/src/gr-ldpc/swig/ldpc_swig.i:5: Error:
Unable to find 'gnuradio.i' make[2]: ***
[swig/ldpc_swigPYTHON_wrap.cxx] Error 1 make[1]: ***
[swig/CMakeFiles/_ldpc_swig.dir/all] Error 2 make[1]: *** Waiting
for unfinished jobs
/home/tjt7a/src/pybombs/src/gr-ldpc/swig/ldpc_swig.i:5: Error:
Unable to find 'gnuradio.i' make[2]: ***
[swig/ldpc_swigPYTHON_wrap.cxx] Error 1 make[1]: ***
[swig/CMakeFiles/pygen_swig_7c327.dir/all] Error 2 make: *** [all]
Error 2 ERROR:root:PyBOMBS Make step failed for package (gr-ldpc)
please see bash output above for a reason (hint: look for the word
Error)
--
Sincerely, Tommy James Tracy II Ph.D Student High Performance Low
Power Lab University of Virginia Phone: 913-775-2241
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against
[Discuss-gnuradio] Question about working with multiples of input values
Dear GNU Radio, I am writing a GNU Radio block that processes the input in blocks of 1024. Is there a way for me to tell the scheduler that I can only accept inputs in multiples of 1024, or do I need to block the input, and save the left-overs for the next work() call? If the latter, how do I know if the work() call is called for the last time? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to make an FFT block in c++
You’re right; the following syntax is the least ambiguous for creating Blackmanharris windows in c++: const std::vector float fft_window = gr::filter::firdes::window(gr::filter::firdes::WIN_BLACKMAN_HARRIS, 1024, NULL); Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Nov 1, 2013, at 6:04 AM, Alexandru Csete oz9...@gmail.com wrote: On Fri, Nov 1, 2013 at 6:16 AM, Tommy Tracy II tj...@virginia.edu wrote: Thanks a lot. I do have a question about the 6.67 that you pass to the gr::firdes::window(gr::filter::firdes::WIN_BLACKMAN_HARRIS, SIZE, 6.67); What is the importance of this value? Is this the default BETA? I found that when creating a BLACKMANHARRIS window in python and c++, I got two different results. If I recall correctly that parameter is only used for the Kaiser window and not for the others. Alex signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to make an FFT block in c++
Thanks a lot. I do have a question about the 6.67 that you pass to the gr::firdes::window(gr::filter::firdes::WIN_BLACKMAN_HARRIS, SIZE, 6.67); What is the importance of this value? Is this the default BETA? I found that when creating a BLACKMANHARRIS window in python and c++, I got two different results. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Oct 18, 2013, at 5:20 PM, Alexandru Csete oz9...@gmail.com wrote: On Fri, Oct 18, 2013 at 10:05 PM, Tommy Tracy II tj...@virginia.edu wrote: Hello, I'm trying to make an FFT block in my hierarchical block, but I cannot seem to find the correct syntax. I'm trying to make it with a BLACKMAN_HARRIS windowing function, and it's easy in a python program: fft_forward = fft.fft_vfc(window_size, True, (fft.blackmanharris(window_size)), 1) fft_backward = fft.fft_vcc(window_size, False, (fft.blackmanharris(window_size)), False, 1) But in a c++ program it gets hairy. Does anyone have any experience with this? gr::fft::fft_vfc::sptr fft_forward = gr::fft::fft_vfc::make(SIZE, true, gr::filter::firdes::WIN_BLACKMAN_HARRIS, num_threads); gr::fft::fft:vcc::sptr fft_reverse = gr::fft::fft_vcc::make(SIZE, false, gr::filter::firdes::WIN_BLACKMAN_HARRIS, false, num_threads); I believe what I have wrong is the Windowing, which is of the form: const std::vector float window I have only used gr::fft::fft_complex in C++ but I think it uses the same window type. If that's true you can create the window using: window = gr::filter::firdes::window(gr::filter::firdes::WIN_BLACKMAN_HARRIS, SIZE, 6.76); Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Debugging New Gnuradio blocks
Dear List, I’m finding it particularly challenging to debug new gnu radio blocks. If I have a printf() in my work() function, the output is not written to std out; is it redirected elsewhere? What other methods are you using for debugging gnu radio blocks? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Cycle Detection in GNU Radio
What about passing Tommy James Tracy IIPh.D StudentHigh Performance Low Power LabUniversity of VirginiaPhone: 913-775-2241 On Jul 9, 2013, at 5:46 PM, Josh Blum j...@joshknows.com wrote:On 07/09/2013 08:25 PM, Johnathan Corgan wrote:On 07/09/2013 05:06 PM, Tommy Tracy II wrote:I am working on a GNU Radio Router block that will serve as a communication block between multiple flow graphs. My router willreceive information via TCP, and then send it to several otherblocks to be processed. After those blocks have completed theirprocessing, my original idea was to take that data and return itto the router to be sent back to a different node. This wouldintroduce a cycle in the flow graph. Is there any way to disablecycle prevention?There is no way to disable cycle prevention; the GNU Radioscheduler algorithm requires streaming ports to be a directedacyclic graph.However, this applies to streaming ports only. It's possible(though probably lower in performance) for you to encapsulate datainto async messages and use message ports connected in an arbitrarytopology.Checkout the advanced scheduler. There is no problem with feedbackloops, and there is no penalty for passing buffers as messages insteadof streams: https://github.com/guruofquality/gras/wiki-josh___ Discuss-gnuradiomailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] How to make an FFT block in c++
Hello, I'm trying to make an FFT block in my hierarchical block, but I cannot seem to find the correct syntax. I'm trying to make it with a BLACKMAN_HARRIS windowing function, and it's easy in a python program: fft_forward = fft.fft_vfc(window_size, True, (fft.blackmanharris(window_size)), 1) fft_backward = fft.fft_vcc(window_size, False, (fft.blackmanharris(window_size)), False, 1) But in a c++ program it gets hairy. Does anyone have any experience with this? gr::fft::fft_vfc::sptr fft_forward = gr::fft::fft_vfc::make(SIZE, true, gr::filter::firdes::WIN_BLACKMAN_HARRIS, num_threads); gr::fft::fft:vcc::sptr fft_reverse = gr::fft::fft_vcc::make(SIZE, false, gr::filter::firdes::WIN_BLACKMAN_HARRIS, false, num_threads); I believe what I have wrong is the Windowing, which is of the form: const std::vector float window Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNURADIO.org down???
It appears that gnuradio.org is down. There's a domain name advertisement up instead. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO.org down???
Hm. I suspect a DNS problem. I get the domain advertisement page using Chrome, and get to the GNURADIO webpage using Firefox. I cleared both caches; same results. Weird. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Oct 3, 2013, at 4:28 PM, Aditya Dhananjay adi...@cs.nyu.edu wrote: It's still working for me. http://www.downforeveryoneorjustme.com/gnuradio.org Down for me. I see the advert for domains priced right. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about adding your own classes
Perfect,
Thank you everyone. What I did was include the header files in my block source
files; I needed to add them to the CMakeLists.txt in /lib under:
list(APPEND router_sources
to get everything to build and link correctly.
I was then able to import the module and use it without error in python. From
now on I will use 'no block'.
-
The next question I have is... is there any documentation on creating GNU Radio
programs in c++ including the build instructions? I want to test my code in a
c++ program as well. I saw the example dial_tone, but I'm not sure what else I
need to include to build it. dial_tone also doesn't seem to work in my virtual
machine with the following error:
tjt7a@ubuntu:~/Src/pybombs/src/gnuradio$
./build/gr-audio/examples/c++/dial_tone
audio_oss_sink: /dev/dsp: No such file or directory
terminate called after throwing an instance of 'std::runtime_error'
what(): audio_oss_sink
Aborted (core dumped)
Sincerely,
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
On Sep 21, 2013, at 11:21 AM, Tom Rondeau t...@trondeau.com wrote:
On Fri, Sep 20, 2013 at 7:13 PM, Martin Braun (CEL)
martin.br...@kit.edu wrote:
Hi Tommy,
is this a visibility issue? Did you use modtool to add the additional
classes? If not, do you have a FOO_API macro in your class def?
MB
Tommy,
Yes, make sure that the FOO_API is declared for the classes. Also, you
have to make sure they are being imported into the swig module
correctly in gr-foo/swig/foo_swig.i.
You can use gr_modtool with the class type noblock to create classes
that are not gr::blocks for this purpose, which will set up the cmake
and swig files correctly.
On Fri, Sep 20, 2013 at 01:58:16PM -0400, Tommy Tracy II wrote:
Dear List,
I am using gr_modtool to create new modules and blocks, and I have a
question
about adding additional .cc/.h files that are not included by gr_modtool to
the
cmake file or otherwise importing them by hand.
My new blocks are dependent on two new classes called
NetworkInterface.{cc,h}
and EthernetConnector.{cc,h}. During the make process, if there is a syntax
error in either of these files, the compiler will alert me. I was able to
fix
all problems and get the cmake, make, and make install completed. The
problem
manifested itself when I attempted to import the module:
--
import router
Traceback (most recent call last):
File stdin, line 1, in module
File
/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/__init__.py,
line 45, in module
from router_swig import *
File /home/tjt7a/Src/target/lib/python2.7/dist-packages/router/
router_swig.py, line 26, in module
_router_swig = swig_import_helper()
File /home/tjt7a/Src/target/lib/python2.7/dist-packages/router/
router_swig.py, line 22, in swig_import_helper
_mod = imp.load_module('_router_swig', fp, pathname, description)
ImportError: /home/tjt7a/Src/target/lib/libgnuradio-router.so: undefined
symbol: _ZN16NetworkInterface7connectEPc
--
To investigate the definition of this symbol, I ran c++filt
--
$c++filt _ZN16NetworkInterface7connectEPc
NetworkInterface::connect(char*)
--
This indicates, that my libgnuradio-router module cannot access the
NetworkInterface object file, even though it was part of the compilation
step.
My thought process was to create the two shared object (.so) files by hand,
and
move them to my python path location. So I did that:
--
cc -shared -o libEthernetConnector.so -fPIC EthernetConnector.cc
cc -shared -o libNetworkInterface.so -fPIC NetworkInterface.cc
I then copied them to the location of my gnuradio .so files
--
Unfortunately, this still hasn't solved the problem. Does anyone know a
solution to this problem?
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
___
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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
signature.asc
[Discuss-gnuradio] Question about adding your own classes
Dear List,
I am using gr_modtool to create new modules and blocks, and I have a question
about adding additional .cc/.h files that are not included by gr_modtool to the
cmake file or otherwise importing them by hand.
My new blocks are dependent on two new classes called NetworkInterface.{cc,h}
and EthernetConnector.{cc,h}. During the make process, if there is a syntax
error in either of these files, the compiler will alert me. I was able to fix
all problems and get the cmake, make, and make install completed. The problem
manifested itself when I attempted to import the module:
--
import router
Traceback (most recent call last):
File stdin, line 1, in module
File /home/tjt7a/Src/target/lib/python2.7/dist-packages/router/__init__.py,
line 45, in module
from router_swig import *
File
/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/router_swig.py,
line 26, in module
_router_swig = swig_import_helper()
File
/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/router_swig.py,
line 22, in swig_import_helper
_mod = imp.load_module('_router_swig', fp, pathname, description)
ImportError: /home/tjt7a/Src/target/lib/libgnuradio-router.so: undefined
symbol: _ZN16NetworkInterface7connectEPc
--
To investigate the definition of this symbol, I ran c++filt
--
$c++filt _ZN16NetworkInterface7connectEPc
NetworkInterface::connect(char*)
--
This indicates, that my libgnuradio-router module cannot access the
NetworkInterface object file, even though it was part of the compilation step.
My thought process was to create the two shared object (.so) files by hand, and
move them to my python path location. So I did that:
--
cc -shared -o libEthernetConnector.so -fPIC EthernetConnector.cc
cc -shared -o libNetworkInterface.so -fPIC NetworkInterface.cc
I then copied them to the location of my gnuradio .so files
--
Unfortunately, this still hasn't solved the problem. Does anyone know a
solution to this problem?
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Runtime issue with gr_modtool block
Just for future reference,
Problem:
If moving a module from one version of gnu radio to another, the shared object
(DLL) links may break.
Solution:
Use the gr_modtool script on the destination machine to create a new module and
add the blocks in your old module. Copy over the source, and everything should
work.
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
On Sep 16, 2013, at 12:00 AM, Tommy Tracy II tj...@virginia.edu wrote:
Dear List,
I recently moved a custom block to a new virtual machine, built and
compiled, and tried to import. I get the following error:
import router
Traceback (most recent call last):
File stdin, line 1, in module
File
/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/__init__.py, line
45, in module
from router_swig import *
File
/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/router_swig.py,
line 26, in module
_router_swig = swig_import_helper()
File
/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/router_swig.py,
line 22, in swig_import_helper
_mod = imp.load_module('_router_swig', fp, pathname, description)
ImportError: /home/tjt7a/Src/target/lib/libgnuradio-router.so: undefined
symbol: _ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_
Investigating this line, I get:
tjt7a@ubuntu:~/Src$ c++filt
_ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_
gr::msg_accepter::post(boost::intrusive_ptrpmt::pmt_base,
boost::intrusive_ptrpmt::pmt_base)
I'm running the new pybombs version:
tjt7a@ubuntu:~/Src$ gnuradio-config-info -v
3.7.2git-0-gd19aa281
Has anyone seen this?
Sincerely,
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Runtime issue with gr_modtool block
Dear List,
I recently moved a custom block to a new virtual machine, built and
compiled, and tried to import. I get the following error:
import router
Traceback (most recent call last):
File stdin, line 1, in module
File /home/tjt7a/Src/target/lib/python2.7/dist-packages/router/__init__.py,
line 45, in module
from router_swig import *
File
/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/router_swig.py,
line 26, in module
_router_swig = swig_import_helper()
File
/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/router_swig.py,
line 22, in swig_import_helper
_mod = imp.load_module('_router_swig', fp, pathname, description)
ImportError: /home/tjt7a/Src/target/lib/libgnuradio-router.so: undefined
symbol: _ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_
Investigating this line, I get:
tjt7a@ubuntu:~/Src$ c++filt
_ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_
gr::msg_accepter::post(boost::intrusive_ptrpmt::pmt_base,
boost::intrusive_ptrpmt::pmt_base)
I'm running the new pybombs version:
tjt7a@ubuntu:~/Src$ gnuradio-config-info -v
3.7.2git-0-gd19aa281
Has anyone seen this?
Sincerely,
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Cycle Detection in GNU Radio
What I'm trying to do is this: 1. The Root Router receives data from an input flow graph, packages it and sends it to its children in a balanced manner. 2. The Child Routers receive data, and, as a Source block, streams the data to the Child's flow graph. The resulting output needs to be returned to the Root, so the Child Router serves as a sink as well! (here's a cycle) 3. The Child Router sends the data back to the Root Router, which re-orders it and streams the result to it's sink. ROOT SOURCE--ROUTERROOT SINK (no cycle) ...---CHILD ROUTER--CHILD FLOWGRAPH-… (cycle) - This won't work with the existing gnu radio framework because of that cycle. One alternative is the following: 1. The Root flow graph dumps data into a shared input_queue via an input queue sink block. The Router has a shared_ptr to the input_queue, reads the data, and distributes it to its children. 2. The children receive the data and dump it into their input_queue via shared ptr. 3. The child also has a queue source block that also has a shared_ptr to the input_queue, and it reads the data to stream through its flow graph. 4. The child then uses an output queue sink block to dump data into a shared output_queue. 5. The child router reads from the output_queue (via shared_ptr), and sends data to the Root. 6. The Root receives the data, reorders it, and dumps it into its output queue. 7. A queue source reads from the Root's output_queue, and writes it to the Root's sink. ROOT SOURCEINPUT_QUEUE SINK[shared_ptr] [shared_ptr]ROUTER[shared_ptr] OUTPUT_QUEUE SOURCE---ROOT SINK [shared_ptr]INPUT QUEUE SOURCE--CHILD FLOWGRAPH---OUTPUT QUEUE SINK[shared_ptr] [shared_ptr]ROUTER[shared_ptr] This all seems a bit convoluted. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Jul 10, 2013, at 1:44 AM, Tom Rondeau t...@trondeau.com wrote: On Wed, Jul 10, 2013 at 1:25 AM, Johnathan Corgan johnat...@corganlabs.com wrote: On 07/09/2013 05:06 PM, Tommy Tracy II wrote: I am working on a GNU Radio Router block that will serve as a communication block between multiple flow graphs. My router will receive information via TCP, and then send it to several other blocks to be processed. After those blocks have completed their processing, my original idea was to take that data and return it to the router to be sent back to a different node. This would introduce a cycle in the flow graph. Is there any way to disable cycle prevention? There is no way to disable cycle prevention; the GNU Radio scheduler algorithm requires streaming ports to be a directed acyclic graph. However, this applies to streaming ports only. It's possible (though probably lower in performance) for you to encapsulate data into async messages and use message ports connected in an arbitrary topology. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com The thing is, you don't want your streaming ports to have cycles. It's not a fundamental limitation of GNU Radio; it's just not the right thing to do. The streaming ports are for streams of data, which tend to have strong temporal relationships with each other. Cycles in data streams are (generally; I'm sure there are a few exceptions) usually very time-specific. Think of a PLL: if you have more than 1 sample delay in your loop, it falls apart as an algorithm (I have a paper on this somewhere that shows the math behind how delay effects the locking performance). We don't do cycles because we transfer large (ideally) chunks of data between blocks. If you're processing 8191 items in one work function and try to feed that back, you're now that many samples delayed in time. Then next call could be a different number. So not only do you have this delay, you have a varying time delay. Doesn't make sense for these kinds of streams. And if we set N=1 for all calls to work, you're going to maximize the scheduler overhead, which is also bad. What you're talking about sounds like a job for the message passing interface, as Johnathan recommended. You're not time dependent from what I gather from your email, so the async message interface will work well. That's basically what it's meant for. You would post messages when ready. The blocks that are receiving blocks would simply block until a message is posted to them and then wake up and process it. 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
[Discuss-gnuradio] Question about Cycle Detection in GNU Radio
Dear GNU Radio I am working on a GNU Radio Router block that will serve as a communication block between multiple flow graphs. My router will receive information via TCP, and then send it to several other blocks to be processed. After those blocks have completed their processing, my original idea was to take that data and return it to the router to be sent back to a different node. This would introduce a cycle in the flow graph. Is there any way to disable cycle prevention? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Cycle Detection in GNU Radio
Perfect; thank you! Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Jul 9, 2013, at 5:46 PM, Josh Blum j...@joshknows.com wrote: On 07/09/2013 08:25 PM, Johnathan Corgan wrote: On 07/09/2013 05:06 PM, Tommy Tracy II wrote: I am working on a GNU Radio Router block that will serve as a communication block between multiple flow graphs. My router will receive information via TCP, and then send it to several other blocks to be processed. After those blocks have completed their processing, my original idea was to take that data and return it to the router to be sent back to a different node. This would introduce a cycle in the flow graph. Is there any way to disable cycle prevention? There is no way to disable cycle prevention; the GNU Radio scheduler algorithm requires streaming ports to be a directed acyclic graph. However, this applies to streaming ports only. It's possible (though probably lower in performance) for you to encapsulate data into async messages and use message ports connected in an arbitrary topology. Checkout the advanced scheduler. There is no problem with feedback loops, and there is no penalty for passing buffers as messages instead of streams: https://github.com/guruofquality/gras/wiki -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Cycle Detection in GNU Radio
Another alternative would be to pass around shared pointers to a queue. Does that seem like a reasonable, albeit hack-ee, approach? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Jul 9, 2013, at 5:46 PM, Josh Blum j...@joshknows.com wrote: On 07/09/2013 08:25 PM, Johnathan Corgan wrote: On 07/09/2013 05:06 PM, Tommy Tracy II wrote: I am working on a GNU Radio Router block that will serve as a communication block between multiple flow graphs. My router will receive information via TCP, and then send it to several other blocks to be processed. After those blocks have completed their processing, my original idea was to take that data and return it to the router to be sent back to a different node. This would introduce a cycle in the flow graph. Is there any way to disable cycle prevention? There is no way to disable cycle prevention; the GNU Radio scheduler algorithm requires streaming ports to be a directed acyclic graph. However, this applies to streaming ports only. It's possible (though probably lower in performance) for you to encapsulate data into async messages and use message ports connected in an arbitrary topology. Checkout the advanced scheduler. There is no problem with feedback loops, and there is no penalty for passing buffers as messages instead of streams: https://github.com/guruofquality/gras/wiki -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code: We're in!
I created a mentor account, but I'm not sure how to link to GNU Radio. Could someone add me or provide a link? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Apr 9, 2013, at 1:16 PM, M. Ranganathan mra...@gmail.com wrote: What are the deadlines for applying as a mentor/participant for a Gnu Radio GSOC sub-project? How does one go about getting involved? Thanks, Ranga On Tue, Apr 9, 2013 at 1:06 PM, Carles Fernandez carles.fernan...@gmail.com wrote: Thanks Martin, those were my guesses as well. I just wanted to make sure that I didn't miss something. I don't understand, either, the reason why there is not a MASSIVE number of applications. Could it be lack of advertisement? Fear of not being good enough? Students having a life? Lets try to improve the figures this year! Best regards, Carles On Tue, Apr 9, 2013 at 5:30 PM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Tue, Apr 09, 2013 at 04:44:50PM +0200, Carles Fernandez wrote: do you know how the slot allocation works? Is there a fixed number of slots per organization or it depends on the number of received proposals? Any clue would be welcome. Different orgs did get different # of slots in the past. However, there's no official description re. the slot allocation; I assume Google takes all the available info (# of mentors, # of ideas, amount of $$$, random other facts) and then decides somehow. It's not that easy to fill lots of slots, though, despite GSoC probably being the best thing a student can do over summer. Orgs will probably have to earn the right to get lots of slots, having to prove they can handle it. All of this is guesswork, though! 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 -- M. Ranganathan ___ 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] Using the GRUEL msg_queue
Dear GNU Radio, I am looking to use the GRUEL msg_queue for passing messages (of PMT type) from block to block in python. I can use the old gr.msg_queue as shown below: from gnuradio import gr message_queue = gr.msg_queue(max size) How would I use a GRUEL message queue? Anyone have any documentation on this? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the GRUEL msg_queue
More information on this. I checked the build directory to see if the gruel/msg_queue had built. cd ~/src/gnuradio/build/gruel/src/lib/msg ls **nothing** I then GREPd my python/gruel directory and couldn't find any msg_queue either. This leads me to believe that gruel/msg_queue wasnt installed. I tried to build gruel: cd ~/src/gnuradio/gruel/build cmake ../ -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at CMakeLists.txt:23 (include): include could not find load file: GrBoost CMake Error at CMakeLists.txt:25 (include): include could not find load file: GrPython CMake Error at CMakeLists.txt:30 (include): include could not find load file: GrComponent CMake Error at CMakeLists.txt:31 (GR_REGISTER_COMPONENT): Unknown CMake command GR_REGISTER_COMPONENT. CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 2.8) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run cmake --help-policy CMP. This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring incomplete, errors occurred! Is there something missing from my build, or is this a bug? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Apr 23, 2013, at 6:48 PM, Tommy Tracy II tj...@virginia.edu wrote: Dear GNU Radio, I am looking to use the GRUEL msg_queue for passing messages (of PMT type) from block to block in python. I can use the old gr.msg_queue as shown below: from gnuradio import gr message_queue = gr.msg_queue(max size) How would I use a GRUEL message queue? Anyone have any documentation on this? Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio Paper Submissions
Dear GNU Radio, Below is a link to a conference on Software Defined Radios. GlobalSIP 2013 Symposium on: Software Defined and Cognitive Radios http://www.ieeeglobalsip.org/sym/13/SDCR Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio/Parallella project for GSoC 2013
Ideally, an architecture-aware scheduler could capitalize on all available accelerators / heterogenous processors, and could maximize performance for that system. Unfortunately right now we're limited to porting a subset of blocks to these accelerators. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Apr 18, 2013, at 9:58 PM, Robert McGwier rwmcgw...@gmail.com wrote: Or possibly more interesting and significant for the future, heterogeneous processors in a system. We're seeing lots of this with ARM's on FPGA's, GPU on ARM based SoC, ... In addition to homogeneous multicore processors with interesting network fabrics On Thursday, April 18, 2013, Tom Rondeau wrote: On Thu, Apr 18, 2013 at 4:16 AM, Andrew Back and...@carrierdetect.com wrote: Hi Sylvain, On 18 April 2013 08:56, Sylvain Munaut 246...@gmail.com wrote: Hi, Hello, I'm starting this thread to discuss ideas about support for many-core floating-points accelerators. As it was said in wiki it could be for example: -further development of Performance Counters and Block Core Affinity Shouldn't we work on actually _running_ any of the blocks on the accelerator before trying to benchmark them ? Of course, but the suggestion was that a GSoC project involving Parallella should do more than just port blocks — this could be part of the project but not all. I believe Tommy Tracy II has started working on porting, but I am not sure how far he will get before a student would need to start their project. Cheers, Andrew Yes. We certainly need to get blocks ported over to the chip to do anything. From a GNU Radio standpoint as a GSoC project, that's not particularly interesting to us, just work that has to be done. What we're interested in as a project is improving our understanding of both many-core processors as well as the use of coprocessors for signal processing/SDR work. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Owner and Technical Director, Allied Communication, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ 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] GNU Radio signal transmitting
Dear Karimkhan, What did you want to demo? You will need some sort of DAC or USRP to transmit data. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Apr 17, 2013, at 3:30 AM, karimkhan khan_karim2...@yahoo.com wrote: Can any one please give me link to example which show signal transmission using grc? I dont have usrp. I want to show demo for transmitting signal in multiple channel as per selection. Please someone help! ___ 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] Build failures on Ubuntu 12.04 32-bit
I just tried the build on my 32-bit Ubuntu 10.04 VM and got the following error: [ 70%] Building CXX object gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc: In member function ‘bool gr::digital::packet_header_default::header_formatter(long int, unsigned char*, const std::vectorgr_tag_t, std::allocatorgr_tag_t )’: /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc:71: error: ‘memset’ was not declared in this scope make[2]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o] Error 1 make[1]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/all] Error 2 make: *** [all] Error 2 I added #include string.h to the top of the file, and it seems to have completed the build for that file. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 29, 2013, at 1:53 PM, Tom Rondeau t...@trondeau.com wrote: Ralph, Marcus, et al., I've pushed a fix just now for the 32-bit OS problem. See issue #529 for the problem/solution. Tom On Thu, Mar 28, 2013 at 5:02 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 28, 2013 at 3:56 PM, Marcus D. Leech mle...@ripnet.com wrote: Just tried to do a build now, from latest GIT. Attached is the make.log file. This Ubuntu 12.04 system is up-to-date as of today. Boost is 1.48 GCC is 4.6.3 Swig is 2.0.4 -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org Working off-list with Ralph, we found the problem. Seems specific to 32-bit machines, though. I have to figure out what the right fix is, but I'll get to that soon. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failures on Ubuntu 12.04 32-bit
That was successful. Build complete. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 29, 2013, at 2:26 PM, Tom Rondeau t...@trondeau.com wrote: On Fri, Mar 29, 2013 at 2:23 PM, Tommy Tracy II tj...@virginia.edu wrote: I just tried the build on my 32-bit Ubuntu 10.04 VM and got the following error: [ 70%] Building CXX object gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc: In member function ‘bool gr::digital::packet_header_default::header_formatter(long int, unsigned char*, const std::vectorgr_tag_t, std::allocatorgr_tag_t )’: /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc:71: error: ‘memset’ was not declared in this scope make[2]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o] Error 1 make[1]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/all] Error 2 make: *** [all] Error 2 I added #include string.h to the top of the file, and it seems to have completed the build for that file. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 Tommy, Try adding: #include string.h Into packet_header_default.h and let me know how that works. Tom On Mar 29, 2013, at 1:53 PM, Tom Rondeau t...@trondeau.com wrote: Ralph, Marcus, et al., I've pushed a fix just now for the 32-bit OS problem. See issue #529 for the problem/solution. Tom On Thu, Mar 28, 2013 at 5:02 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 28, 2013 at 3:56 PM, Marcus D. Leech mle...@ripnet.com wrote: Just tried to do a build now, from latest GIT. Attached is the make.log file. This Ubuntu 12.04 system is up-to-date as of today. Boost is 1.48 GCC is 4.6.3 Swig is 2.0.4 -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org Working off-list with Ralph, we found the problem. Seems specific to 32-bit machines, though. I have to figure out what the right fix is, but I'll get to that soon. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio on Zedboard
4GB of swap on an SD card? I'm worried that that may wear out the SD card, but I'll give it a shot. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 26, 2013, at 3:36 AM, Sid Boyce g3...@blueyonder.co.uk wrote: This is like the error I encountered and got past by having swap. The kernel used then was built without swap. A new kernel got way past that but I have run into another error near the end which seems to suggest I need greater than 2GB of swap so I'm adding another 2GB of swap. [100%] Built target pygen_gnuradio_core_src_lib_swig_2dc10 Segmentation fault make[2]: *** [gr-digital/swig/CMakeFiles/_digital_swig.dir/digital_swigPYTHON_wrap.cxx.o] Error 139 make[1]: *** [gr-digital/swig/CMakeFiles/_digital_swig.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs Linking CXX shared module _gnuradio_core_gengen.so [100%] Built target _gnuradio_core_gengen Linking CXX shared module _blocks_swig.so [100%] Built target _blocks_swig make: *** [all] Error 2 73 ... Sid. On 26/03/13 07:04, Tommy Tracy II wrote: Dear All, Lately there have been several emails about installing GNU Radio on Raspberry Pi and other ARM platforms. I tried to get it installed on the Zedboard *ARMv7*, but I was unsuccessful, with the following error message: [ 39%] Built target test_runtime Scanning dependencies of target test_vmcircbuf [ 39%] Building CXX object gnuradio-core/src/tests/CMakeFiles/test_vmcircbuf.dir/test_vmcircbuf.cc.o Linking CXX executable test_vmcircbuf [ 39%] Built target test_vmcircbuf [ 39%] Built target gnuradio_core_general_swig_doc [ 39%] Built target gnuradio_core_gengen_swig_doc [ 39%] Built target pmt_swig [ 39%] Built target gnuradio_core_filter_swig_doc [ 39%] Built target general_generated [ 39%] Built target filter_generated [ 43%] Built target gengen_generated [ 43%] Built target gnuradio_core_runtime_swig_doc [ 43%] Built target _gnuradio_core_filter_swig_tag [ 43%] Building CXX object gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/gnuradio_core_filterPYTHON_wrap.cxx.o /mnt/gnuradio/build/gnuradio-core/src/lib/swig/gnuradio_core_filterPYTHON_wrap.cxx: In function ‘void init_gnuradio_core_filter()’: /mnt/gnuradio/build/gnuradio-core/src/lib/swig/gnuradio_core_filterPYTHON_wrap.cxx:82736:21: warning: variable ‘md’ set but not used [-Wunused-but-set-variable] /mnt/gnuradio/build/gnuradio-core/src/lib/swig/gnuradio_core_filterPYTHON_wrap.cxx: In function ‘PyObject* _wrap_gr_freq_xlating_fir_filter_fcc_sptr_set_max_noutput_items(PyObject*, PyObject*, PyObject*)’: /mnt/gnuradio/build/gnuradio-core/src/lib/swig/gnuradio_core_filterPYTHON_wrap.cxx:53877:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Has anyone seen this before? I did the build using the following flags: cmake -Dhave_mfpu_neon=0 -DCMAKE_CXX_FLAGS:STRING=-march=armv7 -mfpu=vfp -mfloat-abi=hard -DCMAKE_C_FLAGS:STRING=-march=armv7 -mfpu=vfp -mfloat-abi=hard ../ Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ___ 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] GNU Radio on Zedboard
Dear Sylvain, Thank you! I wasn't aware of the soft eabi. I'm going to try compiling with the flags you have listed and maybe later come back to integrate Java support if needed. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 26, 2013, at 3:51 AM, Sylvain Munaut 246...@gmail.com wrote: Hi, Lately there have been several emails about installing GNU Radio on Raspberry Pi and other ARM platforms. I tried to get it installed on the Zedboard *ARMv7*, but I was unsuccessful, with the following error message: Just from you nick, I would think that the zedboard in question is a paralella prototype ? Do you use the linaro image ? I compiled it a couple of day ago for that platform. cmake -Dhave_mfpu_neon=0 -DCMAKE_CXX_FLAGS:STRING=-march=armv7 -mfpu=vfp -mfloat-abi=hard -DCMAKE_C_FLAGS:STRING=-march=armv7 -mfpu=vfp -mfloat-abi=hard ../ The linaro image is not a hardfp image AFAIK, it's a softfp eabi. Also, why would you disable neon ??? the ARM core in the zynq has a neon unit so you should use it. I compiled it using those flags : -DCMAKE_CXX_FLAGS:STRING=-mfpu=neon -DCMAKE_C_FLAGS:STRING=-mfpu=neon I also disabled python support because compiling the SWIG generated files requires multi-Go of RAM and trying to use swap for it made each SWIG file take hours to compile ... Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Osmocom supporting Rafael R820T SDR?
Dear List, I just received the NooElec R820T SDR USB dongle with antenna to test some of my GNU Radio code. This particular dongle uses the R820T SDR. Does anyone know if osmocom supports it, or if it works at all? I see that osmocom supports http://sdr.osmocom.org/trac/wiki/rtl-sdr#SupportedHardware The code below shows that the rtl_test program detected the tuner, but failed because it =! E4000. Is that the only tuner currently supported, or is there a command-line flag I can use to toggle tuners? -- tjt7a@bt:~/sdr$ sudo rtl_test -t Found 1 device(s): 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 No E4000 tuner found, aborting. -- Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Osmocom supporting Rafael R820T SDR?
Excellent! Thank you. It seems to work. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 18, 2013, at 12:21 PM, Alexandru Csete oz9...@gmail.com wrote: On Mon, Mar 18, 2013 at 4:56 PM, Tommy Tracy II tj...@virginia.edu wrote: Dear List, I just received the NooElec R820T SDR USB dongle with antenna to test some of my GNU Radio code. This particular dongle uses the R820T SDR. Does anyone know if osmocom supports it, or if it works at all? I see that osmocom supports http://sdr.osmocom.org/trac/wiki/rtl-sdr#SupportedHardware The code below shows that the rtl_test program detected the tuner, but failed because it =! E4000. Is that the only tuner currently supported, or is there a command-line flag I can use to toggle tuners? Try rtl_test without any options. The -t option is for benchmarking the E4000 tuner. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to know the number of bits/packets transmitted
You have your input on repeat, so it'll keep transmitting as long as the program is running. Are you looking for the rate, or the total bit count? Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 8, 2013, at 7:11 PM, manjusha yandamuri.ma...@gmail.com wrote: or do i have to go through the entire .py code ,find the variables and print it?? Please help!! Thanks. - Manjusha -- View this message in context: http://gnuradio.4.n7.nabble.com/How-to-know-the-number-of-bits-packets-transmitted-tp40083p40084.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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] qa_rational_resampler Test is non-deterministic
Dear Gnuradio, I was running the build test script, and got my usual 18 failed tests, but one failed some of the time, and passed other times. I'm investigating what could cause this, but wanted to ask if anyone else had seen this before. To reproduce, run 'ctest -R qa_rational_resampler' several times. - # ctest -R qa_rational_resampler Test project /src/old_gnuradio/gnuradio/build Start 73: qa_rational_resampler 1/2 Test #73: qa_rational_resampler Passed0.57 sec Start 99: qa_rational_resampler 2/2 Test #99: qa_rational_resampler ***Failed0.59 sec 50% tests passed, 1 tests failed out of 2 Total Test time (real) = 1.27 sec The following tests FAILED: 99 - qa_rational_resampler (Failed) Errors while running CTest # ctest -R qa_rational_resampler Test project /src/old_gnuradio/gnuradio/build Start 73: qa_rational_resampler 1/2 Test #73: qa_rational_resampler Passed0.57 sec Start 99: qa_rational_resampler 2/2 Test #99: qa_rational_resampler Passed0.67 sec 100% tests passed, 0 tests failed out of 2 Total Test time (real) = 1.35 sec - I wanted to get more information, so I ran 'ctest -VV -R qa_rational_resampler', but it always fails with the very verbose flag. # ctest -VV -R qa_rational_resampler UpdateCTestConfiguration from :/src/old_gnuradio/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/src/old_gnuradio/gnuradio/build/DartConfiguration.tcl Test project /src/old_gnuradio/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 73 Start 73: qa_rational_resampler 73: Test command: /bin/sh /src/old_gnuradio/gnuradio/build/gnuradio-core/src/python/gnuradio/gr/qa_rational_resampler_test.sh 73: Test timeout computed to be: 9.99988e+06 1/2 Test #73: qa_rational_resampler Passed0.85 sec test 99 Start 99: qa_rational_resampler 99: Test command: /bin/sh /src/old_gnuradio/gnuradio/build/gr-filter/python/qa_rational_resampler_test.sh 99: Test timeout computed to be: 9.99988e+06 99: /src/old_gnuradio/gnuradio/build/gr-filter/python/qa_rational_resampler_test.sh: line 7: 11953 Segmentation fault /usr/bin/python -B /src/old_gnuradio/gnuradio/gr-filter/python/qa_rational_resampler.py 2/2 Test #99: qa_rational_resampler ***Failed0.61 sec The following tests passed: qa_rational_resampler 50% tests passed, 1 tests failed out of 2 Total Test time (real) = 1.81 sec The following tests FAILED: 99 - qa_rational_resampler (Failed) Errors while running CTest Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] qa_constellation_receiver test's constellation fails
The qa_constellation_receiver test tests a series of test constellations, by iterating through them and asserting that the 'correct' variable is always REQ_CORRECT. for constellation, differential in tested_constellations(): ... self.assertTrue(correct REQ_CORRECT) Which is not the case for at least one of the constellations: correct: 0.633012820513 REQ_CORRECT: 0.7 Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] qa_constellation_receiver test's constellation fails
This is Gentoo Base System release 2.1. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Feb 15, 2013, at 4:22 PM, Tom Rondeau t...@trondeau.com wrote: On Fri, Feb 15, 2013 at 3:31 PM, Tommy Tracy II tj...@virginia.edu wrote: The qa_constellation_receiver test tests a series of test constellations, by iterating through them and asserting that the 'correct' variable is always REQ_CORRECT. for constellation, differential in tested_constellations(): ... self.assertTrue(correct REQ_CORRECT) Which is not the case for at least one of the constellations: correct: 0.633012820513 REQ_CORRECT: 0.7 Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia Remind us what OS you're using? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issues with running volk_profile in GENTOO
Thank you. I think this may be the problem: # grep Available architectures cmake.out -- Available architectures: generic;32;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx # grep Available machines cmake.out -- Available machines: generic_orc;sse2_32_mmx_orc;sse3_32_orc;ssse3_32_orc;sse4_a_32_orc;sse4_1_32_orc;sse4_2_32_orc;avx_32_mmx_orc /proc/cpuinfo flags: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm arat dts tpr_shadow vnmi flexpriority ept void It looks like my processor does not support avx, but Gnuradio assumes it does. Is there a way to disable avx? Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Feb 12, 2013, at 10:27 AM, Johnathan Corgan johnat...@corganlabs.com wrote: Available architectures: generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issues with running volk_profile in GENTOO
The problem is that during the build, AVX support was enabled, even though my processor doesn't support it. -- Python checking for Cheetah = 2.0.0 -- Python checking for Cheetah = 2.0.0 - found -- Compiler name: GNU -- x86* CPU detected -- CPU width is 32 bits, Overruled arch 64 -- Available architectures: generic;32;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx -- Available machines: generic_orc;sse2_32_mmx_orc;sse3_32_orc;ssse3_32_orc;sse4_a_32_orc;sse4_1_32_orc;sse4_2_32_orc;avx_32_mmx_orc Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Feb 13, 2013, at 2:48 PM, Josh Blum j...@joshknows.com wrote: On 02/13/2013 01:44 PM, Johnathan Corgan wrote: On Wed, Feb 13, 2013 at 8:25 AM, Tommy Tracy II tj...@virginia.edu wrote: # grep Available architectures cmake.out -- Available architectures: generic;32;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx # grep Available machines cmake.out -- Available machines: generic_orc;sse2_32_mmx_orc;sse3_32_orc;ssse3_32_orc;sse4_a_32_orc;sse4_1_32_orc;sse4_2_32_orc;avx_32_mmx_orc /proc/cpuinfo flags: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi *mmx* fxsr *sse* *sse2* ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 *ssse3 *cx16 xtpr pdcm *sse4_1* *sse4_2* popcnt aes lahf_lm arat dts tpr_shadow vnmi flexpriority ept void It looks like my processor does not support avx, but Gnuradio assumes it does. Is there a way to disable avx? It would be best to find out why libvolk is detecting avx during cmake. It determines that AVX is supported by the compiler via flags. So, support for AVX will be built into the library. From the output of the volk profile, it doesnt seem that AVX was detected. So, all seems well so far... -josh Can you post the rest of the lines from your cmake.out related to volk (should be near the beginning)? Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issues with running volk_profile in GENTOO
Nick, thank you. I was wondering why AVX showed up in the list if the processor didn't support it. Does anyone have any ideas why rotatorpupper would take so long? Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Feb 13, 2013, at 2:57 PM, Nick Foster n...@ettus.com wrote: On 02/13/2013 08:25 AM, Tommy Tracy II wrote: Thank you. I think this may be the problem: # grep Available architectures cmake.out -- Available architectures: generic;32;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx # grep Available machines cmake.out -- Available machines: generic_orc;sse2_32_mmx_orc;sse3_32_orc;ssse3_32_orc;sse4_a_32_orc;sse4_1_32_orc;sse4_2_32_orc;avx_32_mmx_orc /proc/cpuinfo flags: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm arat dts tpr_shadow vnmi flexpriority ept void It looks like my processor does not support avx, but Gnuradio assumes it does. Is there a way to disable avx? No, your processor doesn't support AVX. Your compiler, however, does. Volk looks once at compile time to build all architectures your compiler supports, and then looks again at runtime to enable only instructions your CPU can support. If you look at volk_profile's output again, you'll see that it's not trying to use a volk_machine with AVX support: Using Volk machine: sse4_2_32_orc I haven't tried using volk_profile on a 32-bit OS but I suspect that has something to do with your incredibly long rotatorpuppet test. =) --n Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Feb 12, 2013, at 10:27 AM, Johnathan Corgan johnat...@corganlabs.com wrote: Available architectures: generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx ___ 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] Issues with running volk_profile in GENTOO
What I got from GDB: Is there any way to get more information using backtrace? Program received signal SIGSEGV, Segmentation fault. 0xf7f77098 in volk_32fc_32f_multiply_32fc_a_generic () from /usr/lib/libvolk.so.0.0.0 … Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Feb 13, 2013, at 3:20 PM, Josh Blum j...@joshknows.com wrote: On 02/13/2013 01:59 PM, Tommy Tracy II wrote: The problem is that during the build, AVX support was enabled, even though my processor doesn't support it. Thats intended because AVX is supported by the compiler. You should notice however, that VOLK detected at runtime that AVX was not actually available on your CPU. Back to the original issue, I thought there was a segfault in one of the profile tests. I think a gdb backtrace would be helpful to see which one is failing. -josh -- Python checking for Cheetah = 2.0.0 -- Python checking for Cheetah = 2.0.0 - found -- Compiler name: GNU -- x86* CPU detected -- CPU width is 32 bits, Overruled arch 64 -- Available architectures: generic;32;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx -- Available machines: generic_orc;sse2_32_mmx_orc;sse3_32_orc;ssse3_32_orc;sse4_a_32_orc;sse4_1_32_orc;sse4_2_32_orc;avx_32_mmx_orc Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Feb 13, 2013, at 2:48 PM, Josh Blum j...@joshknows.com wrote: On 02/13/2013 01:44 PM, Johnathan Corgan wrote: On Wed, Feb 13, 2013 at 8:25 AM, Tommy Tracy II tj...@virginia.edu wrote: # grep Available architectures cmake.out -- Available architectures: generic;32;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx # grep Available machines cmake.out -- Available machines: generic_orc;sse2_32_mmx_orc;sse3_32_orc;ssse3_32_orc;sse4_a_32_orc;sse4_1_32_orc;sse4_2_32_orc;avx_32_mmx_orc /proc/cpuinfo flags: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi *mmx* fxsr *sse* *sse2* ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 *ssse3 *cx16 xtpr pdcm *sse4_1* *sse4_2* popcnt aes lahf_lm arat dts tpr_shadow vnmi flexpriority ept void It looks like my processor does not support avx, but Gnuradio assumes it does. Is there a way to disable avx? It would be best to find out why libvolk is detecting avx during cmake. It determines that AVX is supported by the compiler via flags. So, support for AVX will be built into the library. From the output of the volk profile, it doesnt seem that AVX was detected. So, all seems well so far... -josh Can you post the rest of the lines from your cmake.out related to volk (should be near the beginning)? Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Issues with running volk_profile in GENTOO
I tried running volk_profile in Gentoo and got the following: # volk_profile Using Volk machine: sse4_2_32_orc RUN_VOLK_TESTS: volk_32fc_s32fc_rotatorpuppet_32fc_a generic completed in 361.04s sse4_1 completed in 0.49s Best arch: sse4_1 RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a sse4_1 completed in 1.14s sse completed in 6.16s generic completed in 1.19s Best arch: sse4_1 RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i_a ssse3 completed in 0.6s generic completed in 0.6s orc completed in 0.92s Best arch: ssse3 RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2_a ssse3 completed in 1.3s sse2 completed in 1.28s generic completed in 1.13s orc completed in 1.33s Best arch: generic RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2_a sse completed in 0.8s generic completed in 0.37s orc completed in 0.3s Best arch: orc RUN_VOLK_TESTS: volk_16ic_deinterleave_real_16i_a ssse3 completed in 0.69s sse2 completed in 0.81s generic completed in 0.72s Best arch: ssse3 RUN_VOLK_TESTS: volk_16ic_magnitude_16i_a sse3 completed in 1.83s sse completed in 1.84s generic completed in 2.19s Best arch: sse3 RUN_VOLK_TESTS: volk_16ic_s32f_magnitude_32f_a sse3 completed in 1.21s sse completed in 1.22s generic completed in 3.15s Best arch: sse3 RUN_VOLK_TESTS: volk_16i_s32f_convert_32f_a sse4_1 completed in 0.85s sse completed in 2.36s generic completed in 1.55s Best arch: sse4_1 RUN_VOLK_TESTS: volk_16i_s32f_convert_32f_u sse4_1 completed in 0.85s sse completed in 2.36s generic completed in 1.55s Best arch: sse4_1 RUN_VOLK_TESTS: volk_16i_convert_8i_a sse2 completed in 0.35s generic completed in 0.38s Best arch: sse2 RUN_VOLK_TESTS: volk_16i_convert_8i_u sse2 completed in 0.35s generic completed in 0.38s Best arch: sse2 RUN_VOLK_TESTS: volk_16u_byteswap_a sse2 completed in 0.42s generic completed in 0.62s orc completed in 0.32s Best arch: orc RUN_VOLK_TESTS: volk_16u_byteswap_u sse2 completed in 0.42s generic completed in 0.62s Best arch: sse2 RUN_VOLK_TESTS: volk_16i_32fc_dot_prod_32fc_a generic completed in 3.25s sse completed in 7.63s Best arch: generic RUN_VOLK_TESTS: volk_32f_accumulator_s32f_a sse completed in 0.61s generic completed in 2.43s Best arch: sse RUN_VOLK_TESTS: volk_32f_x2_add_32f_a sse completed in 1.4s generic completed in 1.65s orc completed in 1.26s Best arch: orc RUN_VOLK_TESTS: volk_32f_x2_add_32f_u sse completed in 1.35s generic completed in 1.64s Best arch: sse RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a sse completed in 0.37s Segmentation fault You'll notice that the first test took 5 minutes to complete! Finally, it failed running volk_32fc_32f_multiply_32fc_a. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grmodtool
What did you try? Did you pull the source from 'https://github.com/mbant/gr-modtool.git'? Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Jan 18, 2013, at 1:28 PM, srhtbynkln serhatboynuka...@gmail.com wrote: Is there any body to help? -- View this message in context: http://gnuradio.4.n7.nabble.com/grmodtool-tp39026p39064.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grmodtool
OK. You pulled the source. Next, put the source directory on your PATH. To do that.. export PATH=location of gr-modtool:$PATH where location of gr-modtool is the directory location. Once you've done that, change directory to the gnu radio source directory, for me thats in: /home/tjt7a/src/gnuradio-3.6.3 From there, you can create a new module by running: gr_modtool newmod Let me know if that doesn't work for you. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Jan 18, 2013, at 2:01 PM, srhtbynkln serhatboynuka...@gmail.com wrote: yes i pull the source but i couldnt make it worked.. 2013/1/18 Tommy Tracy II [via GnuRadio] [hidden email] What did you try? Did you pull the source from 'https://github.com/mbant/gr-modtool.git'? Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Jan 18, 2013, at 1:28 PM, srhtbynkln [hidden email] wrote: Is there any body to help? -- View this message in context: http://gnuradio.4.n7.nabble.com/grmodtool-tp39026p39064.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio If you reply to this email, your message will be added to the discussion below: http://gnuradio.4.n7.nabble.com/grmodtool-tp39026p39065.html To unsubscribe from grmodtool, click here. NAML View this message in context: Re: grmodtool 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Randomness Introduced in Gnuradio WAV Source Block?
On Tue, Jan 15, 2013 at 01:48:47AM -0500, Tommy Tracy II wrote: I eventually determined, that the randomness was added somewhere in the WAV Source block. Has anyone seen this? Tommy, Martin, can you please post more details: - Which GR version? $gnuradio-config-info -v Ubuntu: v3.6.2-265-gb15b38df Gentoo: v3.6.x-xxx-xunknown The version of gnu radio installed on the Gentoo box was installed from source from the latest stable release of gnuradio-3.6.3. As per some prior posts, I get failed 'make test' results, but the install completes. - What format are your WAV files? (8/16 Bit, Mono/Stereo) This is an 8 Bit/Sample, 11025Hz, Mono WAV file. - Does that matter? I don't think it should. There is an 8-bit to float (32-bit) conversion somewhere in that block, but it should be deterministic. It appears to be deterministic on the Ubuntu machine. - How large is the WAV file? The WAV file is 10.9 MBytes - To be clear, this works on Ubuntu, but not on Gentoo? (works on my Ubuntu …) Yes. This is how I determined it 'worked'. for i in 1 2 3 4 5; do ./WAV_TEST.py ../sources/source.wav $i; done for i in 1 2 3 4 5; do md5sum $i; done Ubuntu: They are the same 143a5b3be71e8476ff2f5edd1086e79f 1 143a5b3be71e8476ff2f5edd1086e79f 2 143a5b3be71e8476ff2f5edd1086e79f 3 143a5b3be71e8476ff2f5edd1086e79f 4 143a5b3be71e8476ff2f5edd1086e79f 5 Gentoo: They are not 6f328ef003b3a60cf4b9675a5453d142 1 c544a257aef0a2f95c9cda82f92acbd6 2 c544a257aef0a2f95c9cda82f92acbd6 3 6f328ef003b3a60cf4b9675a5453d142 4 cf9dc9f7d0c80a3c205c47c60c6c7ac9 5 Interesting note though; all 10 files have the same size. - Do you know how the output is corrupted? This is where it gets weird. for i in 1 2 3 4 5; do hexdump $i $i.hex; done To compare, I looked at a few lines of 1.hex, 2.hex, and 5.hex (they are all different) 1.hex 000 a27e a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 010 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 * 170 a1a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 180 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 * … 0019710 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a3 0019720 a1a1 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 0019730 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 * 001a1d0 a2a3 a1a1 a3a3 a1a2 a2a2 a2a2 a2a2 a2a2 001a1e0 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 a2a2 … 04f09a0 a1a1 a3a3 a1a2 a3a2 a1a2 a2a1 a2a3 a2a1 04f09b0 a3a3 a1a1 a3a2 a1a2 a3a1 a2a3 a2a1 a2a3 04f09c0 a1a1 a3a2 a1a2 a3a2 a1a3 a2a1 a2a3 a1a1 04f09d0 a3a3 a1a2 a3a2 a2a2 a2a1 a2a3 a2a1 a3a3 2.hex 000 421e 4242 4242 4242 4242 4242 4242 4242 010 4242 4242 4242 4242 4242 4242 4242 4242 * 170 4142 4242 4242 4242 4242 4242 4242 4242 180 4242 4242 4242 4242 4242 4242 4242 4242 * … 0019710 4242 4242 4242 4242 4242 4242 4242 4243 0019720 4141 4242 4242 4242 4242 4242 4242 4242 0019730 4242 4242 4242 4242 4242 4242 4242 4242 * 001a1d0 4243 4141 4343 4142 4242 4242 4242 4242 001a1e0 4242 4242 4242 4242 4242 4242 4242 4242 * … 04f09a0 4141 4343 4142 4342 4142 4241 4243 4241 04f09b0 4343 4141 4342 4142 4341 4243 4241 4243 04f09c0 4141 4342 4142 4342 4143 4241 4243 4141 5.hex 000 c29e c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 010 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 * 170 c1c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 180 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 * … 0019710 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c3 0019720 c1c1 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 0019730 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 * 001a1d0 c2c3 c1c1 c3c3 c1c2 c2c2 c2c2 c2c2 c2c2 001a1e0 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 c2c2 * … 04f09a0 c1c1 c3c3 c1c2 c3c2 c1c2 c2c1 c2c3 c2c1 04f09b0 c3c3 c1c1 c3c2 c1c2 c3c1 c2c3 c2c1 c2c3 04f09c0 c1c1 c3c2 c1c2 c3c2 c1c3 c2c1 c2c3 c1c1 Other than the first 2-byte entry (which seems to take the form of random2randome, all other bytes seem to be identical with a simple substitution. This little program shows where the problem may be. The input is a WAV file. The float stream is converted to chars, and then dumped to a file. This should be completely reproducible, but it doesn't seem to be in the case of my Gentoo machine. Are the Ubuntu Gentoo machine different hardware? Yes. They are very different. The Ubuntu machine is a core i5, 2GB desktop. The gentoo machine is a storage-less single-board computer, with NFS filesystem. [code] if __name__ == '__main__': tb = top_block() tb.run(True) Hm, I'm not even sure what the 'True' does here.. normally you limit the FG to a number of items with the run() argument. I'm
[Discuss-gnuradio] Randomness Introduced in Gnuradio WAV Source Block?
Dear Gnuradio, I wrote a program that uses a WAV source block. I found that my program ran as expected on my CENTOS and UBUNTU machines (producing the same output for a given input), but I noticed something unusual on my Gentoo machine. If I run the decoder against the same input WAV file, I get different output every time! My program is an APT decoder, so the resulting output is an image. The images look similar, but they have different intensities. (some are darker, some lighter) I eventually determined, that the randomness was added somewhere in the WAV Source block. Has anyone seen this? This little program shows where the problem may be. The input is a WAV file. The float stream is converted to chars, and then dumped to a file. This should be completely reproducible, but it doesn't seem to be in the case of my Gentoo machine. - class top_block(gr.top_block): def __init__(self): gr.top_block.__init__(self, WAV TEST) inputFileName = str(sys.argv[1]) outputFileName = str(sys.argv[2]) self.gr_wavfile_source_0 = gr.wavfile_source(inputFileName, False) self.gr_float_to_uchar_0 = gr.float_to_uchar() self.gr_file_sink_0 = gr.file_sink(gr.sizeof_char*1, outputFileName) self.gr_file_sink_0.set_unbuffered(False) self.connect((self.gr_wavfile_source_0,0), (self.gr_float_to_uchar_0, 0)) self.connect((self.gr_float_to_uchar_0, 0), (self.gr_file_sink_0, 0)) if __name__ == '__main__': tb = top_block() tb.run(True) - I used the same WAV file input 4 times, and got 4 different outputs. This is the same problem-computer that gives me the make test errors, so that may be related. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Updated of Make Test fail with Gnuradio Gentoo Installation
I did not use the '-j #' flag to parallelize the build. It is possible that I had an old version installed though, so I'm removing that now and trying again. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Jan 13, 2013, at 10:40 AM, Tom Rondeau t...@trondeau.com wrote: On Fri, Jan 11, 2013 at 4:31 PM, Tommy Tracy II tj...@virginia.edu wrote: Thank you; I tried that, and that was also unsuccessful. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia Tommy, First, you don't need to worry about running ldconfig for the tests since they testing suite only uses binaries in the build tree, not the installed versions. The problem with the filter_swig might come from a parallel build issue that we thought we licked recently. When you run make, do you do a parallel build? Tom On Jan 11, 2013, at 3:18 PM, Alexandru Csete oz9...@gmail.com wrote: I don't know if it has anything to do with it but I recommend that you try to run cmake, make and make test as a regular user, not as root. ldconfig should have no effect on the make test step. Alex On Fri, Jan 11, 2013 at 8:40 PM, Tommy Tracy II tj...@virginia.edu wrote: Dear Gnuradio, I tried 'sudo ldconfig' before 'make test' but that didn't work either. Below I will go through all of the failed test cases, and if anyone has any suggestions, thank you in advance! Here is a summary: *Two failed VOLK tests *gr_block_executor policy error *Segmentation fault: /root/src/gnuradio-3.6.3/build/gr-filter/lib/test-gr-filter *Missing module name: filter_swig *Rounding error 1 - qa_volk_test_all (Failed) 1: /root/src/gnuradio-3.6.3/volk/lib/testqa.cc(28): error in volk_32fc_32f_multiply_32fc_a_test: check run_volk_tests(volk_32fc_32f_multiply_32fc_a_get_func_desc(), (void (*)())volk_32fc_32f_multiply_32fc_a_manual, std::string(volk_32fc_32f_multiply_32fc_a), 1e-4, 0, 20460, 1, 0, NULL) == 0 failed [true != 0] ... ___ 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] Updated of Make Test fail with Gnuradio Gentoo Installation
Scanning dependencies of target filter_swig_swig_doc [ 53%] Built target filter_swig_swig_doc Scanning dependencies of target _filter_swig_swig_tag [ 53%] Building CXX object gr-filter/swig/CMakeFiles/_filter_swig_swig_tag.dir/_filter_swig_swig_tag.cpp.o Linking CXX executable _filter_swig_swig_tag [ 53%] Built target _filter_swig_swig_tag [ 53%] Generating filter_swig.tag [ 53%] Swig source Scanning dependencies of target _filter_swig [ 53%] Building CXX object gr-filter/swig/CMakeFiles/_filter_swig.dir/filter_swigPYTHON_wrap.cxx.o In file included from /usr/include/boost-1_46/boost/thread/condition_variable.hpp:16:0, from /usr/include/boost-1_46/boost/thread/pthread/shared_mutex.hpp:13, from /usr/include/boost-1_46/boost/thread/shared_mutex.hpp:16, from /usr/include/boost-1_46/boost/thread/detail/thread_group.hpp:9, from /usr/include/boost-1_46/boost/thread/thread.hpp:24, from /home/tjt7a/src/gnuradio-3.6.3/gruel/src/include/gruel/thread.h:25, from /home/tjt7a/src/gnuradio-3.6.3/gnuradio-core/src/lib/runtime/gr_basic_block.h:36, from /home/tjt7a/src/gnuradio-3.6.3/gnuradio-core/src/lib/runtime/gr_block.h:27, from /home/tjt7a/src/gnuradio-3.6.3/gnuradio-core/src/lib/runtime/gr_sync_block.h:27, from /home/tjt7a/src/gnuradio-3.6.3/gnuradio-core/src/lib/runtime/gr_sync_decimator.h:27, from /home/tjt7a/src/gnuradio-3.6.3/gr-filter/include/filter/adaptive_fir_ccc.h:27, from /home/tjt7a/src/gnuradio-3.6.3/build/gr-filter/swig/filter_swigPYTHON_wrap.cxx:4462: /usr/include/boost-1_46/boost/thread/pthread/condition_variable.hpp: In member function 'void boost::condition_variable::wait(boost::unique_lockboost::mutex)': /usr/include/boost-1_46/boost/thread/pthread/condition_variable.hpp:53:19: warning: unused variable 'res' Linking CXX shared module _filter_swig.so [ 53%] Built target _filter_swig Scanning dependencies of target pygen_gr_filter_swig_496e6 [ 53%] Generating filter_swig.pyc [ 53%] Generating filter_swig.pyo What's weird, is that test 96 (qa_rational_resampler) did not fail this time: The following tests FAILED: 1 - qa_volk_test_all (Failed) 5 - gr-core-test-all (Failed) 81 - test_gr_filter (Failed) 84 - qa_fft_filter (Failed) 88 - qa_adaptive_fir_filter (Failed) 90 - qa_hilbert (Failed) 97 - qa_filter_delay_fc (Failed) 98 - qa_pfb_arb_resampler (Failed) 99 - qa_fir_filter (Failed) 100 - qa_channel_model (Failed) 101 - qa_freq_xlating_fir_filter (Failed) 110 - qa_ctcss_squelch (Failed) Errors while running CTest make: *** [test] Error 8 Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Jan 13, 2013, at 5:18 PM, Tom Rondeau t...@trondeau.com wrote: On Sun, Jan 13, 2013 at 4:03 PM, Tommy Tracy II tj...@virginia.edu wrote: I did not use the '-j #' flag to parallelize the build. It is possible that I had an old version installed though, so I'm removing that now and trying again. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia Oh, good. That was going to be my next suggestion. Tom On Jan 13, 2013, at 10:40 AM, Tom Rondeau t...@trondeau.com wrote: On Fri, Jan 11, 2013 at 4:31 PM, Tommy Tracy II tj...@virginia.edu wrote: Thank you; I tried that, and that was also unsuccessful. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia Tommy, First, you don't need to worry about running ldconfig for the tests since they testing suite only uses binaries in the build tree, not the installed versions. The problem with the filter_swig might come from a parallel build issue that we thought we licked recently. When you run make, do you do a parallel build? Tom On Jan 11, 2013, at 3:18 PM, Alexandru Csete oz9...@gmail.com wrote: I don't know if it has anything to do with it but I recommend that you try to run cmake, make and make test as a regular user, not as root. ldconfig should have no effect on the make test step. Alex On Fri, Jan 11, 2013 at 8:40 PM, Tommy Tracy II tj...@virginia.edu wrote: Dear Gnuradio, I tried 'sudo ldconfig' before 'make test' but that didn't work either. Below I will go through all of the failed test cases, and if anyone has any suggestions, thank you in advance! Here is a summary: *Two failed VOLK tests *gr_block_executor policy error *Segmentation fault: /root/src/gnuradio-3.6.3/build/gr-filter/lib/test-gr-filter *Missing module name: filter_swig *Rounding error 1
Re: [Discuss-gnuradio] Updated of Make Test fail with Gnuradio Gentoo Installation
Thank you; I tried that, and that was also unsuccessful. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Jan 11, 2013, at 3:18 PM, Alexandru Csete oz9...@gmail.com wrote: I don't know if it has anything to do with it but I recommend that you try to run cmake, make and make test as a regular user, not as root. ldconfig should have no effect on the make test step. Alex On Fri, Jan 11, 2013 at 8:40 PM, Tommy Tracy II tj...@virginia.edu wrote: Dear Gnuradio, I tried 'sudo ldconfig' before 'make test' but that didn't work either. Below I will go through all of the failed test cases, and if anyone has any suggestions, thank you in advance! Here is a summary: *Two failed VOLK tests *gr_block_executor policy error *Segmentation fault: /root/src/gnuradio-3.6.3/build/gr-filter/lib/test-gr-filter *Missing module name: filter_swig *Rounding error 1 - qa_volk_test_all (Failed) 1: /root/src/gnuradio-3.6.3/volk/lib/testqa.cc(28): error in volk_32fc_32f_multiply_32fc_a_test: check run_volk_tests(volk_32fc_32f_multiply_32fc_a_get_func_desc(), (void (*)())volk_32fc_32f_multiply_32fc_a_manual, std::string(volk_32fc_32f_multiply_32fc_a), 1e-4, 0, 20460, 1, 0, NULL) == 0 failed [true != 0] ... ___ 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] Issues moving gr-modtool blocks between OSs
Dear Gnuradio Mailing List,
I created a gr-modtool block on my Ubuntu machine; it works well, but I
want to run it on my Gentoo machine. At first, I thought I could just copy over
the module in dist-packages, but that doesn't seem to work:
I copied my custom module from: /usr/local/lib/python2.7/dist-packages/tom
to (on my gentoo machine): /usr/lib/python2.7/site-packages/
I then tried an import and got the following error:
import tom
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/site-packages/tom/__init__.py, line 45, in module
from tom_swig import *
File /usr/lib/python2.7/site-packages/tom/tom_swig.py, line 26, in module
_tom_swig = swig_import_helper()
File /usr/lib/python2.7/site-packages/tom/tom_swig.py, line 22, in
swig_import_helper
_mod = imp.load_module('_tom_swig', fp, pathname, description)
ImportError: /usr/lib/python2.7/site-packages/tom/_tom_swig.so: wrong ELF
class: ELFCLASS64
This indicates that I need to rebuild my module. Is there a way to build a
32-bit version of the module on a 64 bit machine?
Sincerely,
Tommy James Tracy II
PhD Student
High Performance Low Power Lab
University of Virginia
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issues moving gr-modtool blocks between OSs
):
add_subdirectory given source gr-noaa which is not an existing directory.
CMake Error at CMakeLists.txt:257 (add_subdirectory):
add_subdirectory given source gr-pager which is not an existing
directory.
CMake Error at CMakeLists.txt:258 (add_subdirectory):
add_subdirectory given source gr-qtgui which is not an existing
directory.
CMake Error at CMakeLists.txt:259 (add_subdirectory):
add_subdirectory given source gr-trellis which is not an existing
directory.
CMake Error at CMakeLists.txt:260 (add_subdirectory):
add_subdirectory given source gr-uhd which is not an existing directory.
CMake Error at CMakeLists.txt:261 (add_subdirectory):
add_subdirectory given source gr-shd which is not an existing directory.
CMake Error at CMakeLists.txt:262 (add_subdirectory):
add_subdirectory given source gr-utils which is not an existing
directory.
CMake Error at CMakeLists.txt:263 (add_subdirectory):
add_subdirectory given source gr-video-sdl which is not an existing
directory.
CMake Error at CMakeLists.txt:264 (add_subdirectory):
add_subdirectory given source gr-vocoder which is not an existing
directory.
CMake Error at CMakeLists.txt:265 (add_subdirectory):
add_subdirectory given source gr-fcd which is not an existing directory.
CMake Error at CMakeLists.txt:266 (add_subdirectory):
add_subdirectory given source gr-wavelet which is not an existing
directory.
CMake Error at CMakeLists.txt:267 (add_subdirectory):
add_subdirectory given source gr-wxgui which is not an existing
directory.
CMake Error at CMakeLists.txt:268 (add_subdirectory):
add_subdirectory given source gr-blocks which is not an existing
directory.
--
-- ##
-- # Gnuradio enabled components
-- ##
-- * python-support
-- * testing-support
-- * volk
--
-- ##
-- # Gnuradio disabled components
-- ##
-- * doxygen
-- * sphinx
-- * gnuradio-core
--
-- Using install prefix: /usr
-- Building for version: 3.6.1git-576-g3abf4a11 / 3.6.4git
-- Configuring incomplete, errors occurred!
I do want the gnuradio-core enabled though. Does the current installer work
with Gentoo?
Sincerely,
Tommy James Tracy II
PhD Student
High Performance Low Power Lab
University of Virginia
On Jan 10, 2013, at 12:51 PM, tzopik tzo...@gmail.com wrote:
Tommy
You need to re-compile the source of the module in the gentoo computer
because the libs and so many things is diferent in Gentoo vs Ubuntu
copy all project created by gr-modtool from ubuntu to gentoo and run in
gentoo:
cd /path/your_blocks
rm build/ -rf
mkdir build
cd build
cmake ../
make
sudo make install
2013/1/10 Tommy Tracy II tj...@virginia.edu
Dear Gnuradio Mailing List,
I created a gr-modtool block on my Ubuntu machine; it works well, but I
want to run it on my Gentoo machine. At first, I thought I could just copy
over the module in dist-packages, but that doesn't seem to work:
I copied my custom module from: /usr/local/lib/python2.7/dist-packages/tom
to (on my gentoo machine): /usr/lib/python2.7/site-packages/
I then tried an import and got the following error:
import tom
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/site-packages/tom/__init__.py, line 45, in
module
from tom_swig import *
File /usr/lib/python2.7/site-packages/tom/tom_swig.py, line 26, in
module
_tom_swig = swig_import_helper()
File /usr/lib/python2.7/site-packages/tom/tom_swig.py, line 22, in
swig_import_helper
_mod = imp.load_module('_tom_swig', fp, pathname, description)
ImportError: /usr/lib/python2.7/site-packages/tom/_tom_swig.so: wrong ELF
class: ELFCLASS64
This indicates that I need to rebuild my module. Is there a way to build a
32-bit version of the module on a 64 bit machine?
Sincerely,
Tommy James Tracy II
PhD Student
High Performance Low Power Lab
University of Virginia
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Cumprimentos,
José Quaresma
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Make successful; Make Test fail with Gnuradio Gentoo Installation
I tried installing using http://gnuradio.org/releases/gnuradio/gnuradio-3.6.3.tar.gz There were a few packages missing that I needed to download: cheetah PyQt4 I then ran cmake: cmake -DCMAKE_INSTALL_PREFIX=/usr -DQWT_INCLUDE_DIRS=/usr/include/qwt5 ../ The build completed, but several of the build tests fail. The following tests FAILED: 1 - qa_volk_test_all (Failed) 5 - gr-core-test-all (Failed) 81 - test_gr_filter (Failed) 84 - qa_fft_filter (Failed) 88 - qa_adaptive_fir_filter (Failed) 90 - qa_hilbert (Failed) 96 - qa_rational_resampler (Failed) 97 - qa_filter_delay_fc (Failed) 98 - qa_pfb_arb_resampler (Failed) 99 - qa_fir_filter (Failed) 100 - qa_channel_model (Failed) 101 - qa_freq_xlating_fir_filter (Failed) 110 - qa_ctcss_squelch (Failed) 131 - qa_constellation_receiver (Failed) Errors while running CTest make: *** [test] Error 8 I tried using cTest and got the following errors: XPedite7370 build # ctest -V -R qa_volk_test_all UpdateCTestConfiguration from :/root/src/gnuradio-3.6.3/build/DartConfiguration.tcl UpdateCTestConfiguration from :/root/src/gnuradio-3.6.3/build/DartConfiguration.tcl Test project /root/src/gnuradio-3.6.3/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 1 Start 1: qa_volk_test_all 1: Test command: /root/src/gnuradio-3.6.3/build/volk/lib/test_all 1: Test timeout computed to be: 9.99988e+06 1: Running 92 test cases... 1: Using Volk machine: sse4_2_32_orc 1: RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a 1: sse4_1 completed in 0s 1: sse completed in 0s 1: generic completed in 0s 1: Best arch: sse4_1 1: RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i_a 1: ssse3 completed in 0s 1: generic completed in 0s 1: orc completed in 0s 1: Best arch: ssse3 1: RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2_a 1: ssse3 completed in 0s 1: sse2 completed in 0s 1: generic completed in 0s 1: orc completed in 0s 1: Best arch: ssse3 1: RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2_a 1: sse completed in 0s 1: generic completed in 0s 1: orc completed in 0s 1: Best arch: sse 1: RUN_VOLK_TESTS: volk_16ic_deinterleave_real_16i_a 1: ssse3 completed in 0s 1: sse2 completed in 0s 1: generic completed in 0s 1: Best arch: ssse3 1: RUN_VOLK_TESTS: volk_16ic_magnitude_16i_a 1: sse3 completed in 0s 1: sse completed in 0s 1: generic completed in 0s 1: Best arch: sse3 1: RUN_VOLK_TESTS: volk_16ic_s32f_magnitude_32f_a 1: sse3 completed in 0s 1: sse completed in 0s 1: generic completed in 0s 1: Best arch: sse3 1: RUN_VOLK_TESTS: volk_16i_s32f_convert_32f_a 1: sse4_1 completed in 0s 1: sse completed in 0s 1: generic completed in 0s 1: Best arch: sse4_1 1: RUN_VOLK_TESTS: volk_16i_s32f_convert_32f_u 1: sse4_1 completed in 0s 1: sse completed in 0s 1: generic completed in 0s 1: Best arch: sse4_1 1: RUN_VOLK_TESTS: volk_16i_convert_8i_a 1: sse2 completed in 0s 1: generic completed in 0s 1: Best arch: sse2 1: RUN_VOLK_TESTS: volk_16i_convert_8i_u 1: sse2 completed in 0s 1: generic completed in 0s 1: Best arch: sse2 1: RUN_VOLK_TESTS: volk_16u_byteswap_a 1: sse2 completed in 0s 1: generic completed in 0s 1: orc completed in 0s 1: Best arch: sse2 1: RUN_VOLK_TESTS: volk_16u_byteswap_u 1: sse2 completed in 0s 1: generic completed in 0s 1: Best arch: sse2 1: RUN_VOLK_TESTS: volk_32f_accumulator_s32f_a 1: sse completed in 0s 1: generic completed in 0s 1: Best arch: sse 1: RUN_VOLK_TESTS: volk_32f_x2_add_32f_a 1: sse completed in 0s 1: generic completed in 0s 1: orc completed in 0s 1: Best arch: sse 1: RUN_VOLK_TESTS: volk_32f_x2_add_32f_u 1: sse completed in 0s 1: generic completed in 0s 1: Best arch: sse 1: RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a 1: sse completed in 0s 1: generic completed in 0s 1: orc completed in 0s 1: offset 2 in1: 0.0993798 in2: -0.0764461 1: offset 3 in1: 0.0125911 in2: -0.00968545 1: offset 7 in1: 0.186311 in2: 0.684512 1: offset 10 in1: 0.603073 in2: 0.54498 1: offset 12 in1: 0.156199 in2: -0.0389959 1: offset 15 in1: 0.0559507 in2: -0.0278312 1: offset 17 in1: 0.46997 in2: 0.662043 1: offset 19 in1: 0.498347 in2: -0.521947 1: offset 21 in1: 0.392071 in2: 0.794964 1: offset 25 in1: 0.34799 in2: -0.70742 1: volk_32fc_32f_multiply_32fc_a: fail on arch sse 1: offset 2 in1: 0.0993798 in2: -0.0764461 1: offset 3 in1: 0.0125911 in2: -0.00968545 1: offset 7 in1: 0.186311 in2: 0.684512 1: offset 10 in1: 0.603073 in2: 0.54498 1: offset 12 in1: 0.156199 in2: -0.0389959 1: offset 15 in1: 0.0559507 in2: -0.0278312 1: offset 17 in1: 0.46997 in2: 0.662043 1: offset 19 in1: 0.498347 in2: -0.521947 1: offset 21 in1: 0.392071 in2: 0.794964 1: offset 25 in1: 0.34799 in2: -0.70742 1: volk_32fc_32f_multiply_32fc_a: fail on arch orc 1: Best arch: sse 1: /root/src/gnuradio-3.6.3/volk/lib/testqa.cc(28): error in volk_32fc_32f_multiply_32fc_a_test: check
Re: [Discuss-gnuradio] gr-howto-write-a-block build fails
On Dec 18, 2012, at 3:52 AM, Martin Braun (CEL) martin.br...@kit.edu wrote:
On Tue, Dec 18, 2012 at 01:27:16AM -0500, Tommy Tracy II wrote:
I'm looking to write c++ gnuradio blocks using the gr-howto-write-a-block
code
that comes with gnuradio. Unfortunately, when I do the build with the
existing
code, the tests fail. Has anyone else seen this?
I haven't (and it shouldn't fail). Comments:
1) Don't use 'sudo' for cmake and make test, unless really necessary.
2) You can build gr-howto-... for educational purposes, but I strongly
recommend using gr-modtool instead.
3) In general, if a test fails, use 'ctest -V -R +REGEX+' to obtain
the output of the failed test.
Provide that in any email here.
MB
1. Thank you for your advice. I went through and changed ownership to my user
name, and I will only use sudo for installation.
2. I still want to figure out why gr-howto-… is failing, but I have installed
gr-modtool and will be using it.
Does anyone know of a good tutorial for this package? I wrote my work
function, but I'm not sure how to write a test.
3. I tried using ctest and got the following error:
--
ttracy@ubuntu:~/Documents/src/gnuradio/gr-howto-write-a-block/build$ ctest -V
-R qa_howto
UpdateCTestConfiguration from
:/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build/DartConfiguration.tcl
UpdateCTestConfiguration from
:/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build/DartConfiguration.tcl
Test project /home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: qa_howto_square_ff
1: Test command: /bin/sh
/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build/lib/qa_howto_square_ff_test.sh
1: Test timeout computed to be: 9.99988e+06
1: Running 2 test cases...
1:
1: *** No errors detected
1/3 Test #1: qa_howto_square_ff ... Passed0.00 sec
test 2
Start 2: qa_howto_square2_ff
2: Test command: /bin/sh
/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build/lib/qa_howto_square2_ff_test.sh
2: Test timeout computed to be: 9.99988e+06
2: Running 2 test cases...
2:
2: *** No errors detected
2/3 Test #2: qa_howto_square2_ff .. Passed0.00 sec
test 3
Start 3: qa_howto
3: Test command: /bin/sh
/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build/python/qa_howto_test.sh
3: Test timeout computed to be: 9.99988e+06
3: Traceback (most recent call last):
3: File
/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/python/qa_howto.py,
line 23, in module
3: from gnuradio import gr, gr_unittest
3: File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/__init__.py,
line 27, in module
3: from gnuradio_core import *
3: File
/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core.py, line 23,
in module
3: from gnuradio_core_runtime import *
3: File
/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 26, in module
3: _gnuradio_core_runtime = swig_import_helper()
3: File
/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 22, in swig_import_helper
3: _mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
description)
3: ImportError: libgnuradio-core-3.6.3git.so.0.0.0: cannot open shared object
file: No such file or directory
3/3 Test #3: qa_howto .***Failed0.05 sec
The following tests passed:
qa_howto_square_ff
qa_howto_square2_ff
67% tests passed, 1 tests failed out of 3
Total Test time (real) = 0.06 sec
The following tests FAILED:
3 - qa_howto (Failed)
Errors while running CTest
--
It appears that qa_howto failed because of a missing module.
I'm running Ubuntu 12.10.
--
ttracy@ubuntu:~/Documents/src/gnuradio/gr-howto-write-a-block/build$ sudo
cmake
../
-- The CXX compiler identification is GNU 4.7.2
-- The C compiler identification is GNU 4.7.2
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.49.0
-- Found PkgConfig: /usr/bin/pkg-config (found version 0.26)
-- checking for module 'gruel'
-- found gruel, version 3.6.3git
-- Found GRUEL: /usr/local/lib/libgruel.so
-- checking for module 'gnuradio-core'
-- found gnuradio-core, version 3.6.3git
-- Found GNURADIO_CORE: /usr/local/lib/libgnuradio-core.so
-- Boost version: 1.49.0
-- Found the following Boost
Re: [Discuss-gnuradio] gr-howto-write-a-block build fails
On Dec 18, 2012, at 4:57 PM, Tom Rondeau t...@trondeau.com wrote:
On Tue, Dec 18, 2012 at 4:54 PM, Tommy Tracy II tj...@virginia.edu wrote:
On Dec 18, 2012, at 3:52 AM, Martin Braun (CEL) martin.br...@kit.edu wrote:
On Tue, Dec 18, 2012 at 01:27:16AM -0500, Tommy Tracy II wrote:
I'm looking to write c++ gnuradio blocks using the gr-howto-write-a-block
code
that comes with gnuradio. Unfortunately, when I do the build with the
existing
code, the tests fail. Has anyone else seen this?
I haven't (and it shouldn't fail). Comments:
1) Don't use 'sudo' for cmake and make test, unless really necessary.
2) You can build gr-howto-... for educational purposes, but I strongly
recommend using gr-modtool instead.
3) In general, if a test fails, use 'ctest -V -R +REGEX+' to obtain
the output of the failed test.
Provide that in any email here.
MB
1. Thank you for your advice. I went through and changed ownership to my user
name, and I will only use sudo for installation.
2. I still want to figure out why gr-howto-… is failing, but I have installed
gr-modtool and will be using it.
Does anyone know of a good tutorial for this package? I wrote my work
function, but I'm not sure how to write a test.
3. I tried using ctest and got the following error:
--
ttracy@ubuntu:~/Documents/src/gnuradio/gr-howto-write-a-block/build$ ctest -V
-R qa_howto
UpdateCTestConfiguration from
:/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build/DartConfiguration.tcl
UpdateCTestConfiguration from
:/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build/DartConfiguration.tcl
Test project /home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: qa_howto_square_ff
1: Test command: /bin/sh
/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build/lib/qa_howto_square_ff_test.sh
1: Test timeout computed to be: 9.99988e+06
1: Running 2 test cases...
1:
1: *** No errors detected
1/3 Test #1: qa_howto_square_ff ... Passed0.00 sec
test 2
Start 2: qa_howto_square2_ff
2: Test command: /bin/sh
/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build/lib/qa_howto_square2_ff_test.sh
2: Test timeout computed to be: 9.99988e+06
2: Running 2 test cases...
2:
2: *** No errors detected
2/3 Test #2: qa_howto_square2_ff .. Passed0.00 sec
test 3
Start 3: qa_howto
3: Test command: /bin/sh
/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build/python/qa_howto_test.sh
3: Test timeout computed to be: 9.99988e+06
3: Traceback (most recent call last):
3: File
/home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/python/qa_howto.py,
line 23, in module
3: from gnuradio import gr, gr_unittest
3: File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/__init__.py,
line 27, in module
3: from gnuradio_core import *
3: File
/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core.py, line
23, in module
3: from gnuradio_core_runtime import *
3: File
/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 26, in module
3: _gnuradio_core_runtime = swig_import_helper()
3: File
/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 22, in swig_import_helper
3: _mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
description)
3: ImportError: libgnuradio-core-3.6.3git.so.0.0.0: cannot open shared object
file: No such file or directory
3/3 Test #3: qa_howto .***Failed0.05 sec
The following tests passed:
qa_howto_square_ff
qa_howto_square2_ff
67% tests passed, 1 tests failed out of 3
Total Test time (real) = 0.06 sec
The following tests FAILED:
3 - qa_howto (Failed)
Errors while running CTest
--
It appears that qa_howto failed because of a missing module.
It looks like you're just missing where libgnuradio-core is installed. Make
sure you installed GNU Radio, and then set LD_LIBRARY_PATH to point to the
location of the installed libraries (/usr/local/lib by default unless you've
changed the install prefix).
Tom
Perfect, thank you!
Sincerely,
Tommy James Tracy II
PhD Student
High Performance Low Power Lab
University of Virginia
I'm running Ubuntu 12.10.
--
ttracy@ubuntu:~/Documents/src/gnuradio/gr-howto-write-a-block/build$ sudo
cmake
../
-- The CXX compiler identification is GNU 4.7.2
-- The C compiler identification is GNU 4.7.2
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
[Discuss-gnuradio] gr-howto-write-a-block build fails
Dear List, I'm looking to write c++ gnuradio blocks using the gr-howto-write-a-block code that comes with gnuradio. Unfortunately, when I do the build with the existing code, the tests fail. Has anyone else seen this? I'm running Ubuntu 12.10. -- ttracy@ubuntu:~/Documents/src/gnuradio/gr-howto-write-a-block/build$ sudo cmake ../ -- The CXX compiler identification is GNU 4.7.2 -- The C compiler identification is GNU 4.7.2 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Build type not specified: defaulting to release. -- Boost version: 1.49.0 -- Found PkgConfig: /usr/bin/pkg-config (found version 0.26) -- checking for module 'gruel' -- found gruel, version 3.6.3git -- Found GRUEL: /usr/local/lib/libgruel.so -- checking for module 'gnuradio-core' -- found gnuradio-core, version 3.6.3git -- Found GNURADIO_CORE: /usr/local/lib/libgnuradio-core.so -- Boost version: 1.49.0 -- Found the following Boost libraries: -- unit_test_framework -- Found SWIG: /usr/bin/swig2.0 (found version 2.0.7) -- Found PythonLibs: /usr/lib/python3.2/config/libpython3.2.so (found version 2.7.3) -- Found PythonInterp: /usr/bin/python (found version 2.7.3) -- Found Doxygen: /usr/bin/doxygen (found version 1.8.1.2) -- Configuring done -- Generating done -- Build files have been written to: /home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build ttracy@ubuntu:~/Documents/src/gnuradio/gr-howto-write-a-block/build$ sudo make Scanning dependencies of target gnuradio-howto [ 5%] Building CXX object lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o [ 10%] Building CXX object lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o Linking CXX shared library libgnuradio-howto.so [ 10%] Built target gnuradio-howto Scanning dependencies of target qa_howto_square2_ff [ 15%] Building CXX object lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o Linking CXX executable qa_howto_square2_ff [ 15%] Built target qa_howto_square2_ff Scanning dependencies of target qa_howto_square_ff [ 20%] Building CXX object lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o Linking CXX executable qa_howto_square_ff [ 20%] Built target qa_howto_square_ff Scanning dependencies of target _howto_swig_swig_tag [ 25%] Building CXX object swig/CMakeFiles/_howto_swig_swig_tag.dir/_howto_swig_swig_tag.cpp.o Linking CXX executable _howto_swig_swig_tag [ 25%] Built target _howto_swig_swig_tag Scanning dependencies of target _howto_swig_doc_tag [ 30%] Building CXX object swig/CMakeFiles/_howto_swig_doc_tag.dir/_howto_swig_doc_tag.cpp.o Linking CXX executable _howto_swig_doc_tag [ 30%] Built target _howto_swig_doc_tag [ 35%] Generating doxygen xml for howto_swig_doc docs [ 40%] Generating howto_swig_doc.i [ 45%] Generating howto_swig.tag [ 50%] Swig source Scanning dependencies of target _howto_swig [ 55%] Building CXX object swig/CMakeFiles/_howto_swig.dir/howto_swigPYTHON_wrap.cxx.o Linking CXX shared module _howto_swig.so [ 55%] Built target _howto_swig Scanning dependencies of target pygen_swig_cc723 [ 60%] Generating howto_swig.pyc [ 65%] Generating howto_swig.pyo [ 85%] Built target pygen_swig_cc723 Scanning dependencies of target pygen_python_257bc [ 90%] Generating __init__.pyc [ 95%] Generating __init__.pyo [ 95%] Built target pygen_python_257bc Scanning dependencies of target pygen_apps_58acf [100%] Shebangin howto_square.py [100%] Built target pygen_apps_58acf ttracy@ubuntu:~/Documents/src/gnuradio/gr-howto-write-a-block/build$ sudo make test Running tests... Test project /home/ttracy/Documents/src/gnuradio/gr-howto-write-a-block/build Start 1: qa_howto_square_ff 1/3 Test #1: qa_howto_square_ff ... Passed0.01 sec Start 2: qa_howto_square2_ff 2/3 Test #2: qa_howto_square2_ff .. Passed0.01 sec Start 3: qa_howto 3/3 Test #3: qa_howto .***Failed0.14 sec 67% tests passed, 1 tests failed out of 3 Total Test time (real) = 0.15 sec The following tests FAILED: 3 - qa_howto (Failed) Errors while running CTest make: *** [test] Error 8 -- Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Making a transparent block for throughput measurement
Thank you. It worked! Unfortunately, it slowed down my flowgraph from ~6 seconds to 145 seconds. The only difference between the two programs is in the connections: -- self.connect((self.gr_wavfile_source_0, 0), (emptyBlock0,0)) self.connect((emptyBlock0,0), (self.band_pass_filter_0, 0)) -- which was originally: -- self.connect((self.gr_wavfile_source_0,0), (self.band_pass_filter_0,0)) -- Below is the emptyBlock code: -- class emptyBlock(gr.block): def __init__(self, args): gr.block.__init__(self, name=empty, in_sig=[float32], out_sig=[float32]) def work(self, input_items, output_items): output_items[0][:]=input_items[0] return len(output_items[0]) -- Thanks again! Tom Tracy II UVA On Dec 12, 2012, at 2:54 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Tue, Dec 11, 2012 at 07:00:42PM -0500, Tommy Tracy II wrote: I'm trying to measure the throughput of my flow graph. In order to accomplish this, I'm creating a transparent float block and then measuring the btyes/second that is going through the block. Unfortunately, my block is not acting transparently. I'm getting strange distortion when doing AM demodulation. Try without self.consume(); grextras using auto_consuming in sync blocks, although I don't know what happens if you do call it (my hypothesis is that if I'm right, your audio should sound choppy). MB PS: Or is this the omninous Bugsquatch people have been talking about? Below is my grextras code: Is there something that I am missing? -- class emptyBlock(gr.block): def __init__(self, args): gr.block.__init__(self, name=empty, in_sig=[float32], out_sig=[float32]) def work(self, input_items, output_items): in0 = input_items[0] out = output_items[0] out[:]=in0 self.consume(0, len(in0)) return len(out) -- Sincerely, Tom Tracy II UVA ___ 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 ___ 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] Making a transparent block for throughput measurement
I'm trying to measure the throughput of my flow graph. In order to accomplish this, I'm creating a transparent float block and then measuring the btyes/second that is going through the block. Unfortunately, my block is not acting transparently. I'm getting strange distortion when doing AM demodulation. Below is my grextras code: Is there something that I am missing? -- class emptyBlock(gr.block): def __init__(self, args): gr.block.__init__(self, name=empty, in_sig=[float32], out_sig=[float32]) def work(self, input_items, output_items): in0 = input_items[0] out = output_items[0] out[:]=in0 self.consume(0, len(in0)) return len(out) -- Sincerely, Tom Tracy II UVA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Synchronizing Schedulers across network
Dear Gnuradio, I want to split my gnuradio program into two flow graphs that will run on separate machines. I can do this by using the TCP or UDP gnuradio blocks. The problem is that these separate flow graphs have different schedulers that I believe are not synchronized. My understanding is that If the first flow graph is faster than the second, the first will quickly compute and send packets to the second, which will then queue and execute those packets. This is not scalable, and ideally I'm looking to get both of the flowgraph schedulers synchronized. Is there an existing way to do this? Could I use a separate block to send tags over? SIncerely, Tommy Tracy II UVA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Loading file into memory
Dear Gnuradio List, I'm doing some benchmarking involving read a WAV file into my gnuradio program, executing a APT Decoder, and writing out the result to a file. I'm finding that my results are all I/O bound. I want to be able to load the entire file into memory (load the WAV file into a vector or other datatype) and then execute it, but still preserve the sampling rate. Is there a way of doing that? Sincerely, Tommy Tracy II UVA Grad Student ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Parallelizing GnuRadio
Thank you for everyone on the listserv for all of your help so far. I have a question about parallelizing gnuradio. I want to implement gnuradio on several computers networked over a PCIe bus. Does anyone know of any prior work in: 1. Gnuradio PCIe gateway 2. Taking a gnuradio flow-graph and splitting it into smaller flowgraphs to be executed on different machines based on the 'cost' of networked between flowgraphs and the execution cost of each individual flowgraph. Again, thank you. Tommy J. Tracy II Computer Engineering University of Virginia signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Distributed GnuRadio
I'm starting some research on running Gnuradio on a network of small computers (over potentially a PCIe bus). The idea being that the network of smaller computers handle the blocks separately. Does anyone know if there has been any work done in this field, or maybe some related research? Tommy J. Tracy II Computer Engineering University of Virginia signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about inter-block communications
Dear Discussion List, I'm just starting with GnuRadio and I would like to understand how the GnuRadio block threads communicate with each other and use shared memory. Does anyone have any insight and/or resources around this subject? Sincerely, Tommy J. Tracy II Computer Engineering University of Virginia signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
