Re: [Discuss-gnuradio] latency time

[Josh Blum]

On 02/13/2013 01:36 AM, Per Zetterberg wrote:
>> http://code.ettus.com/redmine/ettus/projects/public/wiki/Latency
> 
> This was very interesting. A few questions:
> 
> is "Samples per block" = samples per buffer ?
> 
> How is the old:
> dev_addr["recv_buff_size"]=2;   uhd::usrp::multi_usrp::make(dev_addr);
> 
> related to sbp and spp ?

Many of the examples have samples per buffer (spb) which effect the size
of the client app's buffers for samples; its not really a concept in
UHD. Basically, this size is independent of how packets get fragmented
on the wire; because UHD will deal with the fragmentation on both the TX
and RX side to fill or read from the users buffer. For example, the
samples per buffer in gnuradio changes size from work call to work call.

Samples per packet (spp) affects the slicing of the packet framer on the
RX chain. This is by default, set so each packet is MTU sized. So SPP
can be used to shrink the packet size, mostly for latency reasons.

Setting a small recv_frame_size will also work for this purpose; since
this frame size basically sets the MTU by setting the internal buffers
used with the socket. And therefore, when the frame size is decreased,
the spp will automatically be smaller as well to fit into the MTU. You
can think of spp as a more fine grained MTU setting because it can be
set per streamer rather than once at device init time.

The recv_buff_size is unrelated, its just the amount of total buffering
a socket can offer.

I will have to leave the other questions to Balint.

-josh

> 
> If I have a dual-boot machine with two different ubuntu versions. If I tweak 
> the NIC parameters from one boot - will it change the other as well ?
> 
> Where do I find the code for "responder" ?
> What is it doing ? 
> 
> I can't read the results for N210, two many lines, I can't see which is 
> which. Is it reproduced somewhere else?
> 
> Thank you,
> Per Zetterberg
> ___
> 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 errors: Ubuntu 12.04 LTS 32-bit

[Erik Jakobsen]

I tried it again with Ubuntu 32bit.
Got this:

Done building and installing Gnu Radio
GRC freedesktop icons install ...Done
Done function gnuradio_build at: Wed Feb 13 10:08:21 CET 2013
Starting function rtl_build at: Wed Feb 13 10:08:21 CET 2013
you do not appear to have the 'rtl-sdr' directory
you should probably use ./build-gnuradio gitfetch to fetch the appropriate
files using GIT

At the end of the build.

I'm not sure on how to run what stands about gitfetch.

Any help ?.

Erik

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Build errors: Ubuntu 12.04 LTS 32-bit

[Erik Jakobsen]

I tried it again with Ubuntu 32bit.
Got this:

Done building and installing Gnu Radio
GRC freedesktop icons install ...Done
Done function gnuradio_build at: Wed Feb 13 10:08:21 CET 2013
Starting function rtl_build at: Wed Feb 13 10:08:21 CET 2013
you do not appear to have the 'rtl-sdr' directory
you should probably use ./build-gnuradio gitfetch to fetch the 
appropriate

files using GIT

At the end of the build.

I'm not sure on how to run what stands about gitfetch.

Any help ?.

Erik

An rerun solved it
Erik

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-modtool -> master

[Martin Braun (CEL)]

Hi,

those following master may have noticed that gr-modtool is now part of
GNU Radio.

For those who use gr-modtool:

* If you install master or later, you will automatically have modtool on
  your system.
* The standalone version is invoked through gr_modtool.py, the GNU Radio
  version through gr_modtool (same as all our other cl-tools, no .py at
  the end). This also means you can install both without any trouble,
  although right now, they're pretty identical.
* I'll try and supply bug fixes to the standalone version for a while,
  but won't be adding features there, so using the standalone version is
  discouraged.

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


pgpxbzkgXnaLM.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fw: Gnu radio not completely installed on Ubuntu 12.04

[mleech]

 

On 13 Feb 2013 09:32, Sajjad Safdar wrote: 

> Hi, 
> I have found
two possible solutions to install GnuRadio in my case. 
> 
> 1. Run
build script untill the error comes, then just go int gnuradio folder
and delete build folder and install it with 
> 
> $ mkdir build
> $ cd
build
> $ cmake ../
> $ make && make test
> $ sudo make install
> 
> The
problem which i got with this that the version of GNu Radio is not
determined when installed by this way.

Or, you know, just re-run the
build-gnuradio script at some time after Tom committed the fixes to the
repo last night. That works, too. 

 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fw: Gnu radio not completely installed on Ubuntu 12.04

[Ralph A. Schmid, dk5ras]

Hi,

 

for me it did not work, with a different error. As I need gnuradio today I just 
have put back my backup, maybe I will be able to have a closer look this 
evening.

 

Btw., still I could not manage to get the gnuradio 3.4.2 in the reduced 
“OpenBTS version” (to supply libusrp) up and running under 64 bit (it compiles 
without visible trouble, but OpenBTS does not find the USRP package), still 
stuck with 32bit 12.04.


Ralph.

 

 

Or, you know, just re-run the build-gnuradio script at some time after Tom 
committed the fixes to the repo last night.  That works, too.

 

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fw: Gnu radio not completely installed on Ubuntu 12.04

[Karan Talasila]

Hi Sajjad,
  The first solution is fine if you don't know the version it
runs. It might work by maybe running a slightly older compatible version.
But how does the second solution work. The problem according to Tom seems
to be with template issue with swig interface. How does your second
solution address that problem to run correctly. Not that i understand all
technical details, I am a novice, but i was curious reading the mailing
list.

On Wed, Feb 13, 2013 at 10:07 AM,  wrote:

> **
>
> On 13 Feb 2013 09:32, Sajjad Safdar wrote:
>
>  Hi,
> I have found two possible solutions to install GnuRadio in my case.
>
> 1. Run build script untill the error comes, then just go int gnuradio
> folder and delete build folder and install it with
>
> $ mkdir build
> $ cd build
> $ cmake ../
> $ make && make test
> $ sudo make install
>
>  The problem which i got with this that the version of GNu Radio is not
> determined when installed by this way.
>
>
>
>
>
>   Or, you know, just re-run the build-gnuradio script at some time after
> Tom committed the fixes to the repo last night.  That works, too.
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Regards
Karan Talasila
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fw: Gnu radio not completely installed on Ubuntu 12.04

[Johnathan Corgan]

On Wed, Feb 13, 2013 at 7:14 AM, Ralph A. Schmid, dk5ras
wrote:


> for me it did not work, with a different error. As I need gnuradio today I
> just have put back my backup, maybe I will be able to have a closer look
> this evening.
>

I can verify that on a freshly installed Ubuntu 12.04.1 LTS 32-bit desktop
system, the build-gnuradio script completes successfully and all QA now
passes.  Tom verified the same using Ubuntu 12.10 32-bit desktop.

Johnathan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fw: Gnu radio not completely installed on Ubuntu 12.04

[mleech]

 

On 13 Feb 2013 10:19, Johnathan Corgan wrote: 

> On Wed, Feb 13,
2013 at 7:14 AM, Ralph A. Schmid, dk5ras  wrote:
>

>> for me it did not work, with a different error. As I need gnuradio
today I just have put back my backup, maybe I will be able to have a
closer look this evening.
> 
> I can verify that on a freshly installed
Ubuntu 12.04.1 LTS 32-bit desktop system, the build-gnuradio script
completes successfully and all QA now passes. Tom verified the same
using Ubuntu 12.10 32-bit desktop.
> 
> Johnathan

I ran it last night
on an up-to-date 32-bit Ubuntu 12.04 LTS system, and it ran without
issue. 

When reporting "it didn't work", you're best to run with
--verbose, and provide the last page or so of logging output, to help us
determine if you had some kind of transient failure, or there's an
actual problem. 

Since build-gnuradio does a *lot* of different things,
and its default mode is to be quite terse, just getting a "it didn't
work" doesn't really help anybody help you. 

 

Links:
--
[1]
mailto:ra...@schmid.xxx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] FW: Fw: Gnu radio not completely installed on Ubuntu 12.04

[Ralph A. Schmid, dk5ras]

 

 

From: Ralph A. Schmid, dk5ras [mailto:ra...@schmid.xxx] 
Sent: Wednesday, February 13, 2013 4:35 PM
To: 'mle...@ripnet.com'
Subject: RE: [Discuss-gnuradio] Fw: Gnu radio not completely installed on 
Ubuntu 12.04

 

Sure, I always run it verbose, and I will extract the exact error message, 
today I simply did not find the time for this :) I know it very well that the 
message “doe not work” does not tell very much...working on it.

 

Ralph.

When reporting "it didn't work", you're best to run with --verbose, and provide 
the last page or so of logging output, to help us determine if you had some 
kind of transient failure, or there's an actual problem.

Since build-gnuradio does a *lot* of different things, and its default mode is 
to be quite terse, just getting a "it didn't work" doesn't really help anybody 
help you.

 

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FW: Fw: Gnu radio not completely installed on Ubuntu 12.04

[mleech]

 

On 13 Feb 2013 10:35, Ralph A. Schmid, dk5ras wrote: 

> Sure, I
always run it verbose, and I will extract the exact error message, today
I simply did not find the time for this :) I know it very well that the
message "doe not work" does not tell very much...working on it. 
> 
>
Ralph.

Fair enough. 

I usually find that if build-gnuradio fails, it
fails because of a transient network problem, so it can't download the
source it needs at the time that it's run, or the system it finds itself
on is far-enough away from "stock" that its assumptions are violated,
and it falls over. 

For example, I had one person a couple of years
back who'd redefined a few system commands that the script uses, so the
script naturally, failed. 

 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-osmosdr in MacPorts

[Michael Dickens]

I just checked in the gr-osmosdr port into MacPorts for Mac OS X users to use, 
in r103082 < https://trac.macports.org/changeset/103082 >.  I tried to enforce 
the same variant in both this new port and whatever is installed with the 
gnuradio port; not sure if I succeeded.  Meaning: If you select "gr-osmosdr 
+python27", then "gnuradio +python27" must be installed same for +uhd and 
+swig.  I had thought getting this port working might be a bit complicated, but 
it turned out to not take very much time.

NOTES:

* Documentation does not seem to install correctly even if the +docs variant is 
selected.  Or, maybe it is and I just don't know what I'm looking for?

* Some of the cmake/Modules are a bit out of date with respect to what is 
current in the GNU Radio master or next.  Nothing critical, but I did have to 
patch GrPython.cmake to be able to set GR_PYTHON_DIR via the cmake command.

I appreciate any feedback y'all might have.  Enjoy! - MLD


___
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

[Tommy Tracy II]

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  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] FW: Fw: Gnu radio not completely installed on Ubuntu 12.04

[Ralph A. Schmid, dk5ras]

In my case it is an almost fresh Kubuntu 12.04, everything that got installed 
is condensed Gnuradio 3.4.2 (for libusrp), OpenBTS and some related command 
line tools. Nothing redefined, nothing changed, no tweaks, nothing. How should 
I modify something relevant, with my almost non-existant linux knowledge?! :) 
In fact my only personal contribute to this is that I automated the 
installation of this setup with a crude and dumb script, just that I do not 
have to type so much, otherwise the installation follows the gnuradio.org and 
openbts.org websites.  

 

As I have said, I will do further research :)

 

Ralph.

 

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of 
mle...@ripnet.com
Sent: Wednesday, 13 February, 2013 16:46
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] FW: Fw: Gnu radio not completely installed on 
Ubuntu 12.04

 

On 13 Feb 2013 10:35, Ralph A. Schmid, dk5ras wrote:





 

Sure, I always run it verbose, and I will extract the exact error message, 
today I simply did not find the time for this :) I know it very well that the 
message “doe not work” does not tell very much...working on it.

 

Ralph.

 

Fair enough.

I usually find that if build-gnuradio fails, it fails because of a transient 
network problem, so it can't download the source it needs at the time that it's 
run, or the system it finds itself on is far-enough away from "stock" that its 
assumptions are violated, and it falls over.

For example, I had one person a couple of years back who'd redefined a few 
system commands that the script uses, so the script naturally, failed.

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] N210 + SBX High peaks at center frequency.

[maiconkist]

I attached an image of the output of the uhd_fft program. Any frequency that
I try give the same output.

 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/N210-SBX-High-peaks-at-center-frequency-tp39489p39601.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 4x RX chains on USRP1 with DBSRX2

[John Wilson]

Hi guys,

Another quick (couple of) question(s);
 - The DBSRX2 has a programmable channel filter 1-60 MHz. Is the firmware
clever enough to know to increase this bandwidth when I'm reading two
separate frequencies, or is there a chance that it will ruin my day by
centering a too-narrow filter around what I set as rf_freq?
 - Does GNU radio provide an interface to manually change the daughterboard
channel filter?

Cheers,

John

On Wed, Feb 13, 2013 at 8:54 AM, John Wilson wrote:

> Hey yes I had that bit working okay (found that page before), I was just
> wondering how to actually use it, all seems so simple now anyway! It would
> be nice to see some simple instructions on those application notes about
> how the individual RX chains can be used (pretty much what Josh said
> below). Anyway having got back into the lab it all seems to be up and
> working, now I've just got to hope I don't hit the bandwidth limit on the
> USB :)
>
> Thanks again,
>
> John
>
>
>
> On Wed, Feb 13, 2013 at 2:23 AM, Josh Blum  wrote:
>
>>
>>
>> On 02/12/2013 04:03 PM, Marcus D. Leech wrote:
>> >>
>> >> On 02/12/2013 12:10 PM, John Wilson wrote:
>> >>> Hi,
>> >>>
>> >>> I'm wondering whether it's possible/how to use a USRP1 with 2x DBSRX
>> >>> boards
>> >>> to generate 4 separate streams via the 4rx usrp1 firmware. The
>> required
>> >>> channels will be within the front end bandwidth of the DBSRX2.
>> >>>
>> >>> At the moment I'm using a subdev spec of 'A:0 A:0 B:0 B:0' which I
>> >>> assume
>> >>> runs the signal from subdev A through RX chains 0 and 1, and subdev B
>> >>> through 2 and 3. Is this correct?
>> >> That seems correct.
>> >>
>> >>> I am planning to set each daughter board to a frequency between its
>> two
>> >>> frequencies of interest, then I'd like the DDCs to downconvert the
>> data
>> >>> from the ADC independently to sit the two frequencies of interest in
>> the
>> >>> centre of their respective baseband channels out of the USB bus. So
>> >>> can I
>> >>> change the DDC frequencies independently of the centre frequency in
>> the
>> >> You will want a tune_request object where the rf_freq is set to the
>> >> desired center frequency of the DBSRX (something in between that each
>> >> CORDIC can shift away from). And set the rf freq policy to manual.
>> >>
>> >> There are some examples of making the tune request in the grc block for
>> >> usrp source properties dialog box.
>> >>
>> >>> daughterboard? Also what is the resolution of the DDS in the DDC,
>> >>> i.e. can
>> >>> I tune each one independently in ~1Hz steps?
>> >>>
>> >> The CORDIC resolution is pretty much 64e6/(1<<32), so sub Hz.
>> >>
>> >>
>> >> -josh
>> >>
>> > Also, will he need to use the 4rx FPGA image, or will UHD automagically
>> > use the right image?
>> >
>> >
>>
>> Its an args option, exact example here:
>>
>> http://files.ettus.com/uhd_docs/manual/html/usrp1.html#specify-a-non-standard-image
>>
>> -josh
>>
>> >
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 4x RX chains on USRP1 with DBSRX2

[mleech]

 

On 13 Feb 2013 12:51, John Wilson wrote: 

> Hi guys,
> 
> Another
quick (couple of) question(s); 
> - The DBSRX2 has a programmable
channel filter 1-60 MHz. Is the firmware clever enough to know to
increase this bandwidth when I'm reading two separate frequencies, or is
there a chance that it will ruin my day by centering a too-narrow filter
around what I set as rf_freq?
> - Does GNU radio provide an interface to
manually change the daughterboard channel filter?
> 
> Cheers,
> 
>
John

In GRC, if you use the "bandwidth" parameter when creating the
source, it will set the closest settable bandwidth, if the card has
settable bandwidth. 

The DBSRX2 has settable bandwidth, so you should
set it manually to something appropriate based on your channel spacing.


 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Toggle use of bad versions of Boost

[Tom Rondeau]

GNU Radio: now allowing you to shoot yourself in the foot!

We've identified a few versions of Boost that don't work well with GNU
Radio, 1.46, 1.47, and 1.52. A little while ago, I updated our cmake build
files to look for these specific versions and disable their use if found.

Sadly, many distros currently ship with one of these known bad versions.
Looking at Boost's website, 1.47 and 1.52 are by far the most downloaded
Boost versions. So, as recommended by Johnathan, I put in a cmake command
line option that allows you to override the version check so GNU Radio will
build with any current Boost.

To use it, just specify "-DENABLE_BAD_BOOST=True" on your cmake command
line. By default this is False. That will allow you to build against
anything. If this value is False, all GNU Radio components will be disabled
if it finds one of the bad versions. (VOLK and a couple of others will
still pass and compile since they are not affected by the problem).

Just be aware that using one of these versions can cause problems.
Specifically, it can lock up your application when shutting down a
flowgraph. Also, many distros that ship with one of these bad versions also
have other, good, versions that you can pretty easily switch to.

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

[Johnathan Corgan]

On Wed, Feb 13, 2013 at 8:25 AM, Tommy Tracy II  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.
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

Re: [Discuss-gnuradio] Issues with running volk_profile in GENTOO

[Josh Blum]

On 02/13/2013 01:44 PM, Johnathan Corgan wrote:
> On Wed, Feb 13, 2013 at 8:25 AM, Tommy Tracy II  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

Re: [Discuss-gnuradio] Issues with running volk_profile in GENTOO

[Tommy Tracy II]

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  wrote:

> 
> 
> On 02/13/2013 01:44 PM, Johnathan Corgan wrote:
>> On Wed, Feb 13, 2013 at 8:25 AM, Tommy Tracy II  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

[Tommy Tracy II]

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  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  
>> 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

[Josh Blum]

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  wrote:
> 
>>
>>
>> On 02/13/2013 01:44 PM, Johnathan Corgan wrote:
>>> On Wed, Feb 13, 2013 at 8:25 AM, Tommy Tracy II  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] BBN_80211 Receiver on Gunradio 3.6

[Curtis]

To my best knowledge, the newest GNURadio version which can work well with
BBN code is 3.2.2. 

BTW, what machine do you use? USRP1, USRP2 or N210? 

I have implemented the BBN project on USRP2 with GNURadio 3.2.2.

 

Curtis

___
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

[Tommy Tracy II]

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  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  wrote:
>> 
>>> 
>>> 
>>> On 02/13/2013 01:44 PM, Johnathan Corgan wrote:
 On Wed, Feb 13, 2013 at 8:25 AM, Tommy Tracy II  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 Foster]

On 02/13/2013 12:17 PM, Tommy Tracy II wrote:
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?


I don't, but I'm not that worried about it as the generic implementation 
is only there for backup when the hardware doesn't support the more 
effective SIMD version. Generic implementation times can vary hugely 
dependent on which version of GCC you're using, what optimization flags 
were enabled, etc. And sometimes GCC just optimizes really, really terribly.


The segfault is a different story. Like Josh suggests a backtrace would 
be helpful to see exactly what went wrong.


--n


   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 > 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 
mailto: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] 4x RX chains on USRP1 with DBSRX2

[John Wilson]

Cool thanks, I guess that's exposed in the Python scripts by
usrp_source.set_bandwidth then?

John

On Wed, Feb 13, 2013 at 5:53 PM,  wrote:

> **
>
> On 13 Feb 2013 12:51, John Wilson wrote:
>
> Hi guys,
>
> Another quick (couple of) question(s);
>  - The DBSRX2 has a programmable channel filter 1-60 MHz. Is the firmware
> clever enough to know to increase this bandwidth when I'm reading two
> separate frequencies, or is there a chance that it will ruin my day by
> centering a too-narrow filter around what I set as rf_freq?
>  - Does GNU radio provide an interface to manually change the
> daughterboard channel filter?
>
> Cheers,
>
> John
>
>
>
> In GRC, if you use the "bandwidth" parameter when creating the source, it
> will set the closest settable bandwidth, if the card has settable bandwidth.
>
> The DBSRX2 has settable bandwidth, so you should set it manually to
> something appropriate based on your channel spacing.
>
>
>
>
> ___
> 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] 4x RX chains on USRP1 with DBSRX2

[mleech]

 

Yes. 

I often find that it's useful to put together a flow-graph in
GRC to get the parameter settings where I want them, then inspect the
generated python to get some clue... 

On 13 Feb 2013 15:52, John Wilson
wrote: 

> Cool thanks, I guess that's exposed in the Python scripts by
usrp_source.set_bandwidth then?
> 
> John

 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-modtool produces incorrect swig.i

[Eric B]

I'm using the gr-modtool that is now included with gnuradio to add a block
to an existing module that was created with an earlier version of
gr-modtool.py. The swig.i file originally looks like:

%include "gnuradio.i"
%include "testmod_swig_doc.i"

{
#include "testmod_testblock.h"
}

GR_SWIG_BLOCK_MAGIC(testmod,testblock);
%include "testmod_testblock.h"


After adding my new block the swig.i looks like:


%include "gnuradio.i"
%include "testmod_swig_doc.i"

{
#include "testmod_testblock.h"
#include "testmod_testblock2.h"
}

GR_SWIG_BLOCK_MAGIC(testmod,testblock);
%include "testmod_testblock.h"

%include "testmod_testblock2.h"
GR_SWIG_BLOCK_MAGIC(testmod, testblock2);

I can build and install the module just fine but when I got to execute a
flowgraph with testblock2 in it I get these errors:

Traceback (most recent call last):
  File "/home/user/top_block.py", line 52, in 
tb = top_block()
  File "/home/user/top_block.py", line 34, in __init__
self.testmod_testblock2_0 = testmod.testblock2()
AttributeError: 'module' object has no attribute 'testblock2'
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 64,
in apport_excepthook
from apport.fileutils import likely_packaged, get_recent_crashes
  File "/usr/lib/python2.7/dist-packages/apport/__init__.py", line 4, in

from apport.report import Report
  File "/usr/lib/python2.7/dist-packages/apport/report.py", line 28, in

import problem_report
  File "/usr/lib/python2.7/dist-packages/problem_report.py", line 14, in

import zlib, base64, time, sys, gzip, struct, os
  File "/usr/lib/python2.7/gzip.py", line 10, in 
import io
  File "/usr/lib/python2.7/io.py", line 51, in 
import _io
TypeError: type '_io._IOBase' participates in gc and is a base type but has
inappropriate tp_free slot

Original exception was:
Traceback (most recent call last):
  File "/home/user/top_block.py", line 52, in 
tb = top_block()
  File "/home/user/top_block.py", line 34, in __init__
self.testmod_testblock2_0 = testmod.testblock2()
AttributeError: 'module' object has no attribute 'testblock2'


Simply reversing the order of the last two lines (ie. GR_SWIG_BLOCK_MAGIC
comes BEFORE %include) fixes this and allows it to run correctly. This
isn't very intuitive from the error and it would be great if gr-modtool
could be updated to correct this.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio 3.4.1 build error

[John Wilson]

Use a different version of boost for the older Gnuradio builds, I used
boost-1.40 to compile 3.4.0 against which worked.

On Tue, Feb 12, 2013 at 4:31 PM, Zulfiqar Khan wrote:

> Hello,
>
> I am trying to build gnuradio 3.4.1 on ubuntu for usrp1 but it gives me
> the following error when I run the make command. Please help!
>
> /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/
> src/lib/.libs/libgnuradio-core.so: undefined reference to
> `boost::filesystem3::detail::create_directory(boost::filesystem3::path
> const&, boost::system::error_code*)'
> /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/
> src/lib/.libs/libgnuradio-core.so: undefined reference to
> `boost::filesystem3::path::operator/=(boost::filesystem3::path const&)'
> /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/
> src/lib/.libs/libgnuradio-core.so: undefined reference to
> `boost::system::system_category()'
> /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/
> src/lib/.libs/libgnuradio-core.so: undefined reference to
> `boost::filesystem3::detail::status(boost::filesystem3::path const&,
> boost::system::error_code*)'
> /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/
> src/lib/.libs/libgnuradio-core.so: undefined reference to
> `boost::filesystem3::path::wchar_t_codecvt_facet()'
> /home/imran/Desktop/gnuradio/gnuradio-3.4.1/gnuradio-core/
> src/lib/.libs/libgnuradio-core.so: undefined reference to
> `boost::system::generic_category()'
> collect2: ld returned 1 exit status
> make[5]: *** [usrp_rx_cfile] Error 1
> make[5]: Leaving directory `/home/imran/Desktop/gnuradio/
> gnuradio-3.4.1/gr-usrp/apps'
> make[4]: *** [all] Error 2
> make[4]: Leaving directory `/home/imran/Desktop/gnuradio/
> gnuradio-3.4.1/gr-usrp/apps'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/home/imran/Desktop/gnuradio/
> gnuradio-3.4.1/gr-usrp'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/imran/Desktop/gnuradio/
> gnuradio-3.4.1/gr-usrp'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/imran/Desktop/gnuradio/gnuradio-3.4.1'
> make: *** [all] Error 2
>
>
> ___
> 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] gr-modtool produces incorrect swig.i

[Tom Rondeau]

On Wed, Feb 13, 2013 at 4:10 PM, Eric B  wrote:

> I'm using the gr-modtool that is now included with gnuradio to add a block
> to an existing module that was created with an earlier version of
> gr-modtool.py. The swig.i file originally looks like:
>
> %include "gnuradio.i"
> %include "testmod_swig_doc.i"
>
> {
> #include "testmod_testblock.h"
> }
>
> GR_SWIG_BLOCK_MAGIC(testmod,testblock);
> %include "testmod_testblock.h"
>
>
> After adding my new block the swig.i looks like:
>
>
> %include "gnuradio.i"
> %include "testmod_swig_doc.i"
>
> {
> #include "testmod_testblock.h"
> #include "testmod_testblock2.h"
> }
>
> GR_SWIG_BLOCK_MAGIC(testmod,testblock);
> %include "testmod_testblock.h"
>
> %include "testmod_testblock2.h"
> GR_SWIG_BLOCK_MAGIC(testmod, testblock2);
>
> I can build and install the module just fine but when I got to execute a
> flowgraph with testblock2 in it I get these errors:
>
> Traceback (most recent call last):
>   File "/home/user/top_block.py", line 52, in 
> tb = top_block()
>   File "/home/user/top_block.py", line 34, in __init__
> self.testmod_testblock2_0 = testmod.testblock2()
> AttributeError: 'module' object has no attribute 'testblock2'
> Error in sys.excepthook:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 64,
> in apport_excepthook
> from apport.fileutils import likely_packaged, get_recent_crashes
>   File "/usr/lib/python2.7/dist-packages/apport/__init__.py", line 4, in
> 
> from apport.report import Report
>   File "/usr/lib/python2.7/dist-packages/apport/report.py", line 28, in
> 
> import problem_report
>   File "/usr/lib/python2.7/dist-packages/problem_report.py", line 14, in
> 
> import zlib, base64, time, sys, gzip, struct, os
>   File "/usr/lib/python2.7/gzip.py", line 10, in 
> import io
>   File "/usr/lib/python2.7/io.py", line 51, in 
> import _io
> TypeError: type '_io._IOBase' participates in gc and is a base type but
> has inappropriate tp_free slot
>
> Original exception was:
> Traceback (most recent call last):
>   File "/home/user/top_block.py", line 52, in 
> tb = top_block()
>   File "/home/user/top_block.py", line 34, in __init__
> self.testmod_testblock2_0 = testmod.testblock2()
> AttributeError: 'module' object has no attribute 'testblock2'
>
>
> Simply reversing the order of the last two lines (ie. GR_SWIG_BLOCK_MAGIC
> comes BEFORE %include) fixes this and allows it to run correctly. This
> isn't very intuitive from the error and it would be great if gr-modtool
> could be updated to correct this.
>

Is this for the v3.6 or v3.7 API? I'm assuming this is for 3.6 (based off
master). And this might finally clear up some confusion we've been having
regarding this.

In the new 3.7, the ordering should absolutely be:

%import 
GR_SWIG_BLOCK_MAGIC2(thing)

It sounds like this is the opposite for the 3.6 way of doing things (which
we normally don't do this way and instead create a .i file for each block
and handle things that way). But I guess this is why we named it MAGIC...

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ICCPS 2013: Submission Deadline for Poster/Demo/Work-in-Progress extended to February 18, 2013

[Hongwei Zhang]

CALL FOR POSTERS, DEMOS, AND WORK-IN-PROGRESS ABSTRACTS

 ACM/IEEE ICCPS 2013 
Philadelphia, USA
April 8-11, 2013
http://cesg.tamu.edu/iccps2013/WiP.html


Cyber-physical systems (CPS) are physical and engineered systems whose
operations are monitored, coordinated, controlled, and integrated by a
computing and communication core. International Conference on
Cyber-Physical Systems is the flagship conference on cyber-physical
systems. ICCPS is seeking submissions of abstracts for demos, posters,
and Work-in-Progress presentations.

Contributions should emphasize the cross-cutting, system-wide themes.
Sectors of applicability include, but are not limited to, transportation
(automotive, aerospace, marine, rail), SCADA systems (electricity
generation including smart grids and the like, other utilities), smart
physical infrastructure (smart bridges, buildings and highways), energy
efficiency (energy-aware buildings), environmental monitoring, defense
systems, intelligent medical devices, tele-operations and robotics.

Topics of interest include (but are not limited to) the following:
 - Theoretical foundations of CPS
 - Modeling, Analysis and Synthesis Techniques
 - Architectures for Cyber-Physical Systems
 - Building blocks for Cyber-Physical Systems
 - Systems Abstractions, Services and OS Support
 - Evaluation approaches and metrics
 - Novel CPS applications

Submissions will be evaluated based on technical merit and innovation as
well as their potential to stimulate interesting discussions and
exchange of ideas at the conference. Both academic and industrial
submissions are encouraged. The submissions should be a one-page
abstract in PDF format following ICCPS regular-paper formatting
guidelines. All accepted abstracts will be published in the regular
ICCPS Proceedings.


DEMOS

The demo session will provide a forum for researchers to showcase
ongoing work and obtain feedback from the CPS community as a part of the
joint poster/demo session of CPS Week. The title of submissions should
start with "Demo Abstract:". Submissions should be emailed to Demo
Chair with subject: ICCPS demo submission. Demo proposals should clearly
describe what will be demonstrated and how the contributions will be
illustrated interactively. A table, power, and wireless connectivity
will be provided for each demo. If a demonstration requires special
arrangements in addition to the above, please describe them clearly in
the demo submission. If you have any questions, please contact the Demo
Chair: Insik Shin (insik.s...@cs.kaist.ac.kr).


POSTERS

The poster session will provide a forum for researchers to showcase
ongoing work and obtain feedback from the CPS community as a part of the
joint poster/demo session of CPS Week. Poster abstract should be
submitted through the submission site (http://edas.info/N14217). If you
have any questions, please contact the Poster Chair Omprakash Gnawali
(gnaw...@cs.uh.edu) with subject: ICCPS poster submission.


WORK-IN-PROGRESS

The Work-in-Progress session will provide a forum for researchers to
present ongoing work and obtain feedback from the CPS community at
ICCPS. The title of submissions should start with "WiP Abstract:".
Submissions should be emailed to WiP Chair Nalini Venkatasubramanian
(nal...@ics.uci.edu) with subject: ICCPS WiP submission. Authors of
accepted WiP abstracts will give a short oral presentation at the WiP
session.


Important Dates

Submission Deadline:  February 18, 2013 (11:59PM PST)
Acceptance Decisions: February 22, 2013 (11:59PM PST)
Camera-ready Abstracts:   February 25, 2013
Conference:   April 8-11, 2013













___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM - real RF output vs. expected output

[Ralph A. Schmid, dk5ras]

Hi,

I use an USRP1 together with gnuradio/GRC and would like to transmit an OFDM
signal, abt. 1 MHz bandwidth at 433 MHz. The FFT display block within GRC
shows the power mask as expected, a flat line over the bandwidth, and steep
drops at both ends. What a real spectrum analyzer at the output shows is
something totally different, like a Gaussian distribution of the emitted
energy, with highest amplitude in the center, bandwidth as configured, but
the amplitude is dropping continuously towards the ends for about 70 dB or
so. Adjusting the channel bandwidth in the sink block has no influence,
maybe the WBX anyway does not support adjustable filtering?!

Even the simplest possible setup, like random source, OFDM modulator and
URSP, shows this behavior.

What am I doing wrong?

Btw., the spectrum analyzer is a professional device and out of any doubt :)
LTE, DAB and DVB-T is shown as expected.

Ralph.


--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM - real RF output vs. expected output

[Matt Ettus]

You are probably using an odd interpolation ratio.  You need to use an even
rate in order to get a flat passband.

The WBX does not have adjustable filtering.

Matt


On Wed, Feb 13, 2013 at 10:42 PM, Ralph A. Schmid, dk5ras
wrote:

> Hi,
>
> I use an USRP1 together with gnuradio/GRC and would like to transmit an
> OFDM
> signal, abt. 1 MHz bandwidth at 433 MHz. The FFT display block within GRC
> shows the power mask as expected, a flat line over the bandwidth, and steep
> drops at both ends. What a real spectrum analyzer at the output shows is
> something totally different, like a Gaussian distribution of the emitted
> energy, with highest amplitude in the center, bandwidth as configured, but
> the amplitude is dropping continuously towards the ends for about 70 dB or
> so. Adjusting the channel bandwidth in the sink block has no influence,
> maybe the WBX anyway does not support adjustable filtering?!
>
> Even the simplest possible setup, like random source, OFDM modulator and
> URSP, shows this behavior.
>
> What am I doing wrong?
>
> Btw., the spectrum analyzer is a professional device and out of any doubt
> :)
> LTE, DAB and DVB-T is shown as expected.
>
> Ralph.
>
>
> --
>
> Ralph A. Schmid
> Mondstr. 10
> 90762 Fürth
> +49-171-3631223
> ra...@schmid.xxx
> http://www.bclog.de/
>
>
>
> ___
> 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] OFDM - real RF output vs. expected output

[Ralph A. Schmid, dk5ras]

Aah, OK, in fact it is odd. So I will modify my parameters and try again...
Just got confused that theoretical and practical results were so different
:)

 

Meanwhile I had a look into the WBX schematics, fixed filters before/after
ADC/DAC, as expected.

 

Ralph.

 

From: Matt Ettus [mailto:m...@ettus.com] 
Sent: Thursday, February 14, 2013 7:51 AM
To: Ralph A. Schmid, dk5ras
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] OFDM - real RF output vs. expected output

 

 

You are probably using an odd interpolation ratio.  You need to use an even
rate in order to get a flat passband.

 

The WBX does not have adjustable filtering.

 

Matt

 

On Wed, Feb 13, 2013 at 10:42 PM, Ralph A. Schmid, dk5ras 
wrote:

Hi,

I use an USRP1 together with gnuradio/GRC and would like to transmit an OFDM
signal, abt. 1 MHz bandwidth at 433 MHz. The FFT display block within GRC
shows the power mask as expected, a flat line over the bandwidth, and steep
drops at both ends. What a real spectrum analyzer at the output shows is
something totally different, like a Gaussian distribution of the emitted
energy, with highest amplitude in the center, bandwidth as configured, but
the amplitude is dropping continuously towards the ends for about 70 dB or
so. Adjusting the channel bandwidth in the sink block has no influence,
maybe the WBX anyway does not support adjustable filtering?!

Even the simplest possible setup, like random source, OFDM modulator and
URSP, shows this behavior.

What am I doing wrong?

Btw., the spectrum analyzer is a professional device and out of any doubt :)
LTE, DAB and DVB-T is shown as expected.

Ralph.


--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
  +49-171-3631223
  ra...@schmid.xxx
  http://www.bclog.de/



___
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