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;
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
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'
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
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
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
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
On Wed, Feb 13, 2013 at 7:14 AM, Ralph A. Schmid, dk5ras
ra...@schmid.xxxwrote:
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
On 13 Feb 2013 10:19, Johnathan Corgan wrote:
On Wed, Feb 13,
2013 at 7:14 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx [1] 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
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,
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 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
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:
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
I attached an image of the output of the uhd_fft program. Any frequency that
I try give the same output.
http://gnuradio.4.n7.nabble.com/file/n39601/uhd_fft.jpg
--
View this message in context:
http://gnuradio.4.n7.nabble.com/N210-SBX-High-peaks-at-center-frequency-tp39489p39601.html
Sent
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
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
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
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:
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
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
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
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
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
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
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
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, mle...@ripnet.com wrote:
**
On 13 Feb 2013 12:51, John Wilson wrote:
Hi guys,
Another quick (couple of) question(s);
- The DBSRX2 has a programmable
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
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
}
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 zulfi.khan@gmail.comwrote:
Hello,
I am trying to build gnuradio 3.4.1 on ubuntu for usrp1 but it gives me
the following
On Wed, Feb 13, 2013 at 4:10 PM, Eric B bti6...@gmail.com 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
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
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
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
ra...@schmid.xxxwrote:
Hi,
I use an USRP1 together with gnuradio/GRC
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
35 matches
Mail list logo
