|
| From: | Florian Schlembach |
| Subject: | Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450? |
| Date: | Mon, 30 Jan 2012 16:11:05 +0100 |
We have now extended our tests to the tests with two USRP2s with daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is receiving any packets. We checked the spectrum and tuned the gains as well. (OFDM)
Now, we played with the benchmark files and tunnel.py located in the narrowband folder and therefore changed the modulation scheme from BPSK to GMSK and ultimately receiving all the packets!! That's strange.
Does anybody knows what code be the problem that we can't establish any connection using higher order modulation schemes? Could it possibly be our slightly outdated UHD version?
We are totally clueless, so we appreciate any idea/help!
Send Discuss-gnuradio mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: Try to improve E100's performance at high sample rate (ziyang)
2. Re: Try to improve E100's performance at high sample rate
(Nick Foster)
3. Re: Try to improve E100's performance at high sample rate
(Evan Merewether)
4. Re: Try to improve E100's performance at high sample rate
(Almohanad Fayez)
5. Re: Try to improve E100's performance at high sample rate (ziyang)
6. Changing the value of a Python Variable into a block (Andr? Selva)
7. Re: Changing the value of a Python Variable into a block
(Josh Blum)
8. GNURadio and Parrallel Computing (Alex Zhang)
9. Re: GNURadio and Parrallel Computing (Alex Zhang)
10. Re: Try to improve E100's performance at high sample rate
(Philip Balister)
11. Re: GNURadio and Parrallel Computing (Tom Rondeau)
12. Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
(Florian Schlembach)
----------------------------------------------------------------------
Message: 1
Date: Tue, 24 Jan 2012 18:56:09 +0100
From: ziyang <address@hidden>
To: Nick Foster <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
high sample rate
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 01/19/2012 07:13 PM, Nick Foster wrote:
> Optimizing an algorithm is a hard and sometimes counterintuitive
> process. You might benchmark the following:
>
> - Gnuradio's atan2 WITHOUT any Volk multiplications (just comment out
> the volk mults in your block)
> - The Volk multiplications WITHOUT Gnuradio's atan2 (just comment out
> the atan2 in your block)
>
> This will let you determine where the bottleneck is. In addition, try
> running over a MUCH larger dataset. The clock resolution at <1ms is
> not very good and the scheduler will have a correspondingly larger
> effect at smaller timescales.
>
> I think you'll find the atan2 part takes vastly longer than the
> multiplications do, and that will be where you have to look for
> performance improvements.
>
> --n
>
Hi Nick,
I have been doing some tests about the demodulation module. As you said,
the atan2 part takes much longer than the multiplication. So in order to
maximize the performance improvement that volk could bring to the
processing, I took a division and a multiplication out of atan2, and use
volk-ified divider and multiplier instead. Then I run tests using a much
larger dataset.
But from the test results, I did not observe a performance improvement.
In fact, the average processing time even increase a little bit. So I
was wondering if what I did was not a good way to improve the performance?
Another issue is that when I ran Cmake to build Gnuradio on E100, it
reported this:
-- Available arches: generic;neon
-- Available machines: generic;neon
-- Did not find liborc and orcc, disabling orc support...
But from the "opkg list-installed | grep orc" check, both orc and liborc
are installed. Could this lack of orc support be part of the reason why
my implementation did not have a performance improvement?
I will appreciate it if you could give me a hand on this. Thanks.
Best Regards,
Terry
------------------------------
Message: 2
Date: Tue, 24 Jan 2012 10:12:34 -0800
From: Nick Foster <address@hidden>
To: ziyang <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
high sample rate
Message-ID:
<CALALHJUO8FdW8mXsTt7KZ-gPQ-ooBxo=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Jan 24, 2012 at 9:56 AM, ziyang <address@hidden> wrote:
> On 01/19/2012 07:13 PM, Nick Foster wrote:
>
>> Optimizing an algorithm is a hard and sometimes counterintuitive process.
>> You might benchmark the following:
>>
>> - Gnuradio's atan2 WITHOUT any Volk multiplications (just comment out the
>> volk mults in your block)
>> - The Volk multiplications WITHOUT Gnuradio's atan2 (just comment out the
>> atan2 in your block)
>>
>> This will let you determine where the bottleneck is. In addition, try
>> running over a MUCH larger dataset. The clock resolution at <1ms is not
>> very good and the scheduler will have a correspondingly larger effect at
>> smaller timescales.
>>
>> I think you'll find the atan2 part takes vastly longer than the
>> multiplications do, and that will be where you have to look for performance
>> improvements.
>>
>> --n
>>
>>
>
> Hi Nick,
>
> I have been doing some tests about the demodulation module. As you said,
> the atan2 part takes much longer than the multiplication. So in order to
> maximize the performance improvement that volk could bring to the
> processing, I took a division and a multiplication out of atan2, and use
> volk-ified divider and multiplier instead. Then I run tests using a much
> larger dataset.
>
> But from the test results, I did not observe a performance improvement. In
> fact, the average processing time even increase a little bit. So I was
> wondering if what I did was not a good way to improve the performance?
>
> Another issue is that when I ran Cmake to build Gnuradio on E100, it
> reported this:
> -- Available arches: generic;neon
> -- Available machines: generic;neon
> -- Did not find liborc and orcc, disabling orc support...
>
> But from the "opkg list-installed | grep orc" check, both orc and liborc
> are installed. Could this lack of orc support be part of the reason why my
> implementation did not have a performance improvement?
>
Very likely. Make sure that orcc is somewhere that pkgconfig can find it,
and make sure its version is > 0.4.10.
>
> I will appreciate it if you could give me a hand on this. Thanks.
>
>
> Best Regards,
>
> Terry
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/e956f4f9/attachment.html>
------------------------------
Message: 3
Date: Tue, 24 Jan 2012 11:22:20 -0700
From: "Evan Merewether" <address@hidden>
To: <address@hidden>
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
high sample rate
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
Has anybody looked at using the CORDIC approximation for atan2? Depending
on the required accuracy, this may dramatically improve performance in your
C code. Ultimately, you can implement the CORDIC functions in the FPGA
(quasi math-coprocessor style) which would then give you the fastest
possible computation speed.
Evan
-----Original Message-----
From: discuss-gnuradio-bounces+evan=address@hidden
[mailto:discuss-gnuradio-bounces+evan=address@hidden] On Behalf Of
ziyang
Sent: Tuesday, January 24, 2012 10:56 AM
To: Nick Foster
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at high
sample rate
On 01/19/2012 07:13 PM, Nick Foster wrote:
> Optimizing an algorithm is a hard and sometimes counterintuitive
> process. You might benchmark the following:
>
> - Gnuradio's atan2 WITHOUT any Volk multiplications (just comment out
> the volk mults in your block)
> - The Volk multiplications WITHOUT Gnuradio's atan2 (just comment out
> the atan2 in your block)
>
> This will let you determine where the bottleneck is. In addition, try
> running over a MUCH larger dataset. The clock resolution at <1ms is
> not very good and the scheduler will have a correspondingly larger
> effect at smaller timescales.
>
> I think you'll find the atan2 part takes vastly longer than the
> multiplications do, and that will be where you have to look for
> performance improvements.
>
> --n
>
Hi Nick,
I have been doing some tests about the demodulation module. As you said,
the atan2 part takes much longer than the multiplication. So in order to
maximize the performance improvement that volk could bring to the
processing, I took a division and a multiplication out of atan2, and use
volk-ified divider and multiplier instead. Then I run tests using a much
larger dataset.
But from the test results, I did not observe a performance improvement.
In fact, the average processing time even increase a little bit. So I
was wondering if what I did was not a good way to improve the performance?
Another issue is that when I ran Cmake to build Gnuradio on E100, it
reported this:
-- Available arches: generic;neon
-- Available machines: generic;neon
-- Did not find liborc and orcc, disabling orc support...
But from the "opkg list-installed | grep orc" check, both orc and liborc
are installed. Could this lack of orc support be part of the reason why
my implementation did not have a performance improvement?
I will appreciate it if you could give me a hand on this. Thanks.
Best Regards,
Terry
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4763 - Release Date: 01/24/12
------------------------------
Message: 4
Date: Tue, 24 Jan 2012 13:33:33 -0500 (EST)
From: Almohanad Fayez <address@hidden>
To: address@hidden, address@hidden
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
high sample rate
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="us-ascii"
I haven't used VOLK with the OMAP processor but from my experience with the E100 every multiplication and/or division in your flowgraph counts ... When I was working on my C64x+ DSP based FM receiver on the E100 I was moving individual blocks 1-by-1 from the GPP to the DSP and almost every multiplication/division on the GPP caused a buffer overflow my impression at least is if you're going for a pure GPP implementation you need to make used of NEOS vector operations and if you're using a DSP based solution you'll need to find a way to speed up the GPP/DSP buffers, which is something I'm hoping to have more time to look into.
Almohanad Fayez
address@hidden
-----Original Message-----
From: Evan Merewether <address@hidden>
To: discuss-gnuradio <address@hidden>
Sent: Tue, Jan 24, 2012 1:22 pm
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate
Has anybody looked at using the CORDIC approximation for atan2? Depending
on the required accuracy, this may dramatically improve performance in your
C code. Ultimately, you can implement the CORDIC functions in the FPGA
(quasi math-coprocessor style) which would then give you the fastest
possible computation speed.
Evan
-----Original Message-----
From: discuss-gnuradio-bounces+evan=address@hidden
[mailto:discuss-gnuradio-bounces+evan=address@hidden] On Behalf Of
ziyang
Sent: Tuesday, January 24, 2012 10:56 AM
To: Nick Foster
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at high
sample rate
On 01/19/2012 07:13 PM, Nick Foster wrote:
> Optimizing an algorithm is a hard and sometimes counterintuitive
> process. You might benchmark the following:
>
> - Gnuradio's atan2 WITHOUT any Volk multiplications (just comment out
> the volk mults in your block)
> - The Volk multiplications WITHOUT Gnuradio's atan2 (just comment out
> the atan2 in your block)
>
> This will let you determine where the bottleneck is. In addition, try
> running over a MUCH larger dataset. The clock resolution at <1ms is
> not very good and the scheduler will have a correspondingly larger
> effect at smaller timescales.
>
> I think you'll find the atan2 part takes vastly longer than the
> multiplications do, and that will be where you have to look for
> performance improvements.
>
> --n
>
Hi Nick,
I have been doing some tests about the demodulation module. As you said,
the atan2 part takes much longer than the multiplication. So in order to
maximize the performance improvement that volk could bring to the
processing, I took a division and a multiplication out of atan2, and use
volk-ified divider and multiplier instead. Then I run tests using a much
larger dataset.
But from the test results, I did not observe a performance improvement.
In fact, the average processing time even increase a little bit. So I
was wondering if what I did was not a good way to improve the performance?
Another issue is that when I ran Cmake to build Gnuradio on E100, it
reported this:
-- Available arches: generic;neon
-- Available machines: generic;neon
-- Did not find liborc and orcc, disabling orc support...
But from the "opkg list-installed | grep orc" check, both orc and liborc
are installed. Could this lack of orc support be part of the reason why
my implementation did not have a performance improvement?
I will appreciate it if you could give me a hand on this. Thanks.
Best Regards,
Terry
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4763 - Release Date: 01/24/12
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/08c39673/attachment.html>
------------------------------
Message: 5
Date: Tue, 24 Jan 2012 19:43:10 +0100
From: ziyang <address@hidden>
To: Nick Foster <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
high sample rate
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 01/24/2012 07:12 PM, Nick Foster wrote:
> On Tue, Jan 24, 2012 at 9:56 AM, ziyang <address@hidden
> <mailto:address@hidden>> wrote:
>
> On 01/19/2012 07:13 PM, Nick Foster wrote:
>
> Optimizing an algorithm is a hard and sometimes
> counterintuitive process. You might benchmark the following:
>
> - Gnuradio's atan2 WITHOUT any Volk multiplications (just
> comment out the volk mults in your block)
> - The Volk multiplications WITHOUT Gnuradio's atan2 (just
> comment out the atan2 in your block)
>
> This will let you determine where the bottleneck is. In
> addition, try running over a MUCH larger dataset. The clock
> resolution at <1ms is not very good and the scheduler will
> have a correspondingly larger effect at smaller timescales.
>
> I think you'll find the atan2 part takes vastly longer than
> the multiplications do, and that will be where you have to
> look for performance improvements.
>
> --n
>
>
>
> Hi Nick,
>
> I have been doing some tests about the demodulation module. As you
> said, the atan2 part takes much longer than the multiplication. So
> in order to maximize the performance improvement that volk could
> bring to the processing, I took a division and a multiplication
> out of atan2, and use volk-ified divider and multiplier instead.
> Then I run tests using a much larger dataset.
>
> But from the test results, I did not observe a performance
> improvement. In fact, the average processing time even increase a
> little bit. So I was wondering if what I did was not a good way to
> improve the performance?
>
> Another issue is that when I ran Cmake to build Gnuradio on E100,
> it reported this:
> -- Available arches: generic;neon
> -- Available machines: generic;neon
> -- Did not find liborc and orcc, disabling orc support...
>
> But from the "opkg list-installed | grep orc" check, both orc and
> liborc are installed. Could this lack of orc support be part of
> the reason why my implementation did not have a performance
> improvement?
>
>
> Very likely. Make sure that orcc is somewhere that pkgconfig can find
> it, and make sure its version is > 0.4.10.
This is what it shows when I run a "opkg list-installed | grep orc" check:
liborc-0.4-0 - 0.4.16-r1.0.9
liborc-test-0.4-0 - 0.4.16-r1.0.9
orc - 0.4.16-r1.0.9
I don't understand why orc/liborc cannot be detected by CMake. The
options for CMake are:
cmake -DCMAKE_INSTALL_PREFIX=/usr
-DCMAKE_CXX_FLAGS:STRING="-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp
-g" -DCMAKE_C_FLAGS:STRING="-mcpu=cortex-a8 -mfpu=neon
-mfloat-abi=softfp -g" ../
Could you tell me what might be the problem? Thanks.
Terry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/0e9cf2ac/attachment.html>
------------------------------
Message: 6
Date: Tue, 24 Jan 2012 16:42:55 -0200
From: Andr? Selva <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Changing the value of a Python Variable
into a block
Message-ID:
<CALC7W7=_address@hidden>
Content-Type: text/plain; charset="utf-8"
Hello!
I'm developing a TV enconder, and I need to extract information from my
input data, and this will be used to determine the parameters of other
blocks on the flow graph.
How can I change the value of a variable of the python (or grc) environment
from the block general_work() method?
Thanks!
--
Andr? F. B. Selva -
SECOMP - Semana da Computa??o da Unicamp 2012
Coordenador Geral
CACo - Centro Acad?mico da Computa??o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/f1bedf6d/attachment.html>
------------------------------
Message: 7
Date: Tue, 24 Jan 2012 11:31:14 -0800
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Changing the value of a Python
Variable into a block
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 01/24/2012 10:42 AM, Andr? Selva wrote:
> Hello!
>
> I'm developing a TV enconder, and I need to extract information from my
> input data, and this will be used to determine the parameters of other
> blocks on the flow graph.
> How can I change the value of a variable of the python (or grc) environment
> from the block general_work() method?
>
Well, you generally cant call a python function from c++.... but heres a
few ways that may accomplish what you need:
1) Using swig directors is a possibility. Rather than figure out the
intricacies of directors, gnuradio already makes use of them in the
gr.feval_* class, which you can use to call into a python object. Your
general_work() calls the feval object in c++; and then feval object
(from python) directly calls into other variables in the python-domain
of your flow graph.
2) Another possibility is passing messages into a message queue object.
A python thread can pop the messages and act upon them.
3) A related possibility, depending upon how your block operates would
be to have a python thread periodically poll the getter methods of your
custom block and act upon those values. There is already a block in grc
that will poll another block's getter function and update a variable.
4) You could write the general work in python, which means all of the
parameter calculation and setting occurs entirely in python (this
functionality is not yet officially accepted).
http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython
5) And if thats not possible for performance reasons, you might consider
a hybrid approach where you write general work in python, but you call
into a function implemented in c++; where this function processes the
input data and returns the "determined parameters", which you can act on
in python.
-Josh
------------------------------
Message: 8
Date: Tue, 24 Jan 2012 14:55:55 -0600
From: Alex Zhang <address@hidden>
To: gnuradio mailing list <address@hidden>
Subject: [Discuss-gnuradio] GNURadio and Parrallel Computing
Message-ID:
<CA+FEAnfdiDkDUHR2G=UOwHhL+1qM=address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi,
We want to fully utilize the multi-core/GPU archtecture to implement the
GNURadio based signal processing flow.
Are there any official materials summarizing the usage for the so-called
TPB (thread-per-block) mechanism in the GNURadio community? Or related
papers are also appreciated.
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/1f0e3fdc/attachment.html>
------------------------------
Message: 9
Date: Tue, 24 Jan 2012 15:00:38 -0600
From: Alex Zhang <address@hidden>
To: gnuradio mailing list <address@hidden>
Subject: Re: [Discuss-gnuradio] GNURadio and Parrallel Computing
Message-ID:
<CA+FEAndiOSK1FzAOc0kzcj0oRTUza0u9=address@hidden>
Content-Type: text/plain; charset="windows-1252"
And I remember that
Eric Blossom<http://dl.acm.org/author_page.cfm?id=81100473842&coll=DL&dl=ACM&trk=0&cfid=63471391&cftoken=37521642>
has a paper describing the GNURadio scheduler on parallel architecture. But
I don't remember the paper name.
On Tue, Jan 24, 2012 at 2:55 PM, Alex Zhang <address@hidden> wrote:
> Hi,
>
> We want to fully utilize the multi-core/GPU archtecture to implement the
> GNURadio based signal processing flow.
> Are there any official materials summarizing the usage for the so-called
> TPB (thread-per-block) mechanism in the GNURadio community? Or related
> papers are also appreciated.
>
> --
>
> Alex,
> *Dreams can come true ? just believe.*
>
>
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/6d2eaf80/attachment.html>
------------------------------
Message: 10
Date: Tue, 24 Jan 2012 17:00:56 -0500
From: Philip Balister <address@hidden>
To: ziyang <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at
high sample rate
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 01/24/2012 01:43 PM, ziyang wrote:
> On 01/24/2012 07:12 PM, Nick Foster wrote:
>> On Tue, Jan 24, 2012 at 9:56 AM, ziyang <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>> On 01/19/2012 07:13 PM, Nick Foster wrote:
>>
>> Optimizing an algorithm is a hard and sometimes
>> counterintuitive process. You might benchmark the following:
>>
>> - Gnuradio's atan2 WITHOUT any Volk multiplications (just
>> comment out the volk mults in your block)
>> - The Volk multiplications WITHOUT Gnuradio's atan2 (just
>> comment out the atan2 in your block)
>>
>> This will let you determine where the bottleneck is. In
>> addition, try running over a MUCH larger dataset. The clock
>> resolution at <1ms is not very good and the scheduler will
>> have a correspondingly larger effect at smaller timescales.
>>
>> I think you'll find the atan2 part takes vastly longer than
>> the multiplications do, and that will be where you have to
>> look for performance improvements.
>>
>> --n
>>
>>
>>
>> Hi Nick,
>>
>> I have been doing some tests about the demodulation module. As you
>> said, the atan2 part takes much longer than the multiplication. So
>> in order to maximize the performance improvement that volk could
>> bring to the processing, I took a division and a multiplication
>> out of atan2, and use volk-ified divider and multiplier instead.
>> Then I run tests using a much larger dataset.
>>
>> But from the test results, I did not observe a performance
>> improvement. In fact, the average processing time even increase a
>> little bit. So I was wondering if what I did was not a good way to
>> improve the performance?
>>
>> Another issue is that when I ran Cmake to build Gnuradio on E100,
>> it reported this:
>> -- Available arches: generic;neon
>> -- Available machines: generic;neon
>> -- Did not find liborc and orcc, disabling orc support...
>>
>> But from the "opkg list-installed | grep orc" check, both orc and
>> liborc are installed. Could this lack of orc support be part of
>> the reason why my implementation did not have a performance
>> improvement?
>>
>>
>> Very likely. Make sure that orcc is somewhere that pkgconfig can find
>> it, and make sure its version is > 0.4.10.
>
> This is what it shows when I run a "opkg list-installed | grep orc" check:
>
> liborc-0.4-0 - 0.4.16-r1.0.9
> liborc-test-0.4-0 - 0.4.16-r1.0.9
> orc - 0.4.16-r1.0.9
>
> I don't understand why orc/liborc cannot be detected by CMake. The
> options for CMake are:
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr
> -DCMAKE_CXX_FLAGS:STRING="-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp
> -g" -DCMAKE_C_FLAGS:STRING="-mcpu=cortex-a8 -mfpu=neon
> -mfloat-abi=softfp -g" ../
>
> Could you tell me what might be the problem? Thanks.
Add -DENABLE_ORC=ON to the cmake command line.
Philip
>
>
> Terry
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 11
Date: Tue, 24 Jan 2012 17:12:57 -0500
From: Tom Rondeau <address@hidden>
To: Alex Zhang <address@hidden>
Cc: gnuradio mailing list <address@hidden>
Subject: Re: [Discuss-gnuradio] GNURadio and Parrallel Computing
Message-ID:
<CA+SzT6hAsnFrwo5rwuoPL6K=address@hidden>
Content-Type: text/plain; charset="windows-1252"
On Tue, Jan 24, 2012 at 4:00 PM, Alex Zhang <address@hidden> wrote:
> And I remember that
> Eric Blossom<http://dl.acm.org/author_page.cfm?id=81100473842&coll=DL&dl=ACM&trk=0&cfid=63471391&cftoken=37521642>
> has a paper describing the GNURadio scheduler on parallel architecture.
> But I don't remember the paper name.
>
> On Tue, Jan 24, 2012 at 2:55 PM, Alex Zhang <address@hidden>wrote:
>
>> Hi,
>>
>> We want to fully utilize the multi-core/GPU archtecture to implement the
>> GNURadio based signal processing flow.
>> Are there any official materials summarizing the usage for the so-called
>> TPB (thread-per-block) mechanism in the GNURadio community? Or related
>> papers are also appreciated.
>>
>> --
>>
>> Alex,
>> *Dreams can come true ? just believe.*
>>
>> --
>
> Alex,
> *Dreams can come true ? just believe.*
>
Hi Alex,
Good project to work on. I don't know any papers on the TPB scheduler. If
Eric wrote one like you mentioned, I'm not sure where it would be :) If you
or someone else is aware of it, I'd love to get the reference so we can
link to it on our site (
http://gnuradio.org/redmine/projects/gnuradio/wiki/AcademicPapers)
In the meantime, I recommend looking at GRGPU and Will Plishker's work from
Univ. Maryland. He just made a CGRAN project out of it:
https://www.cgran.org/wiki/GRGPU
--
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120124/03d95061/attachment.html>
------------------------------
Message: 12
Date: Wed, 25 Jan 2012 16:18:17 +0100
From: Florian Schlembach <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM)
with XCVR2450?
Message-ID:
<CAMZjtuzj9fiXWFMLhZGX89sGgzpoTYF-bRM1gK7fD=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hey guys,
we are trying to get run the tunnel.py / benchmark_rx.py (OFDM) in order to
measure the datarate between two USRP2 (located with distance of 1 m) with
daughterboards XCVR2450.
We are running the benchmark_tx/rx.py as follows:
benchmark_tx.py -f 2.4G --tx-gain=10 --tx-amplitude=0.8 -v
benchmark_rx.py -f 2.4G --rx-gain=4 -v
We already tried to tune the parameters by analyzing the spectrum by
gnuradio-companion. It looks reasonable and the SNR is round about 20 dB
which should be fine?
Unfortunately, we don't get any packets transmitted. The RX side always
says TIMEOUT.
Our configuration is as follows:
- Ubuntu 10.04
- gnuradio 3.5.1 (installed freshly)
- UHD firmware version 003.003.001
- XCVR2450
Has anybody already got the tunnel.py/benchmark_tx.py run with a similar
configuration? Has anybody an idea what we are doing wrong?
Thanks in advance for your help! Best Regards, Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120125/83b837d9/attachment.html>
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End of Discuss-gnuradio Digest, Vol 110, Issue 25
*************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |