Hi all,
Two related questions:
1) In the datasheet for the N210, the specifications state 50Mhz
instantaneous bandwidth in 8-bit mode. I was looking at
otw_type.width in the UHD and I can't see an 8 bit mode there. Is
8-bit mode implemented in the fpga/firmware/driver for N210? If not,
roughly
On Wed, Dec 01, 2010 at 08:05:51PM -0800, madengr wrote:
>
> Sorry if I can't provide any more debug info, I'm new and ignorant, but I
> updated from both the GnuRadio, UHD, and gr-air-mode repos today, and now
> I'm getting two programs with duplicate failure in gr_fir_fff. They just
> dump back
Nick Foster-4 wrote:
>
> On Mon, 2010-11-29 at 20:16 -0800, madengr wrote:
>> Nick,
>>
>> Got it working on my USRP2 by changing to line 57 to:
>> self.u = uhd.single_usrp_source("addr=192.168.1.15",
>> uhd.io_type_t.COMPLEX_FLOAT32)
>>
>> and line 119 to:
>> result = self.u.set_center_freq(f
Sorry if I can't provide any more debug info, I'm new and ignorant, but I
updated from both the GnuRadio, UHD, and gr-air-mode repos today, and now
I'm getting two programs with duplicate failure in gr_fir_fff. They just
dump back to the shell after 2 seconds with no debug info.
Only thing I did
Hi,
I am trying to build the OFDM decoder on GRC based on the FTW 802.11a/g
encoder.
At the USRP2 receiver, after CFO compensation, I want to see the QPSK
constellation.
Basically, the process is:
bit stream ofdm mod usrp2 sink
usrp2 source -- timing offset comp --- CFO comp ofdm
On 12/01/2010 09:20 PM, madengr wrote:
>
> Is this the proper procedure to update and re-build the GnuRadio source? I'm
> using the next branch:
>
> sudo make uninstall
> make clean
if you want it super clean you can do
git clean -dfx
./bootstrap && ./configure
> git pull
> ./configure
> ma
Is this the proper procedure to update and re-build the GnuRadio source? I'm
using the next branch:
sudo make uninstall
make clean
git pull
./configure
make
make check
sudo make install
I'd rather not uninstall before I have a successful build; maybe I don't
have to. I tried make current, but
Hi Marcus,
Actually we are doing all our processing on the GPU. We use GNURADIO to
bring in the data and then run everything on the GPU and only copy back
the results.
As you wrote in your mail CPU-GPU resp. GPU-CPU copies can be
bottlenecks and should be avoided or reduced whenever possible.
On Wed, Dec 01, 2010 at 04:57:11PM -0600, John Andrews wrote:
> Hi,
> Can we change the DDC value to 0 in usrp_fft.py? Why is this not 0 as one
> would expect to input the center frequency same as the baseband frequency;
> i.e. if I know that my signal is on a carrier at 2.4G then I would use
> usr
Hi,
Can we change the DDC value to 0 in usrp_fft.py? Why is this not 0 as one
would expect to input the center frequency same as the baseband frequency;
i.e. if I know that my signal is on a carrier at 2.4G then I would use
usrp_fft.py to display the spectrum by having the center frequency as 2.4G
On Wed, Dec 01, 2010 at 01:40:03AM -0500, Marcus D. Leech wrote:
>
> On a related note, has anyone looked at enabling the multi-threaded FFTW
> stuff? The cross-over
> points there (between FFTW in a single-thread and FFTW in
> multiple-threads) seem to be lower-down
> on the FFT-size curve.
Thunder87 wrote:
>
> I'm still trying to get gr-ais going on Beagleboard (Lucid). When I tried
> to run ais_decode.py, I've got "uOuOuO" output. On PC everything works
> fine. My guess - BB simply can't process that much data.
>
> So I ran usrp_benchmark on BB to see if this was the problem. 2M
On Wed, 2010-12-01 at 13:53 -0800, Vladutzzz wrote:
> The problem is that I am in the middle of a project, time is of the essence
> and I don't have time to start stumbling around with UHD, right now I have
> to use Simulink, hence UDP. GnuRadio Companion still doesn't work with UHD,
> right (I am
Per,
At the moment we don't have a MIMO cable, so we're looking for alternative
solutions until one makes its way to our lab :)
Thank you for your suggestion though, it is much appreciated.
All the best,
Vlad.
Per Zetterberg-2 wrote:
>
> On Tue, 2010-11-30 at 08:27 -0800, Vladutzzz wrote:
>
The CPFSK block expects digitally encoded data as bits. The file sink
will give you raw demodulated samples. You need to determine what format
your handheld radio expects to see before you can re-encode your saved
data appropriately. FSK describes a digital modulation scheme but says
nothing about
The problem is that I am in the middle of a project, time is of the essence
and I don't have time to start stumbling around with UHD, right now I have
to use Simulink, hence UDP. GnuRadio Companion still doesn't work with UHD,
right (I am very new to python)?
So no chance of UDP working with 2 USR
Hello all,
I am having the following trouble with data types:
I have the following flowgraph working to record FM broadcasts:
{USRP2 source -> LPF -> FM Demod -> File Sink}
Next, I am making another program to transmit the stored FM broadcast audio to
my handheld radio which expects FSK modula
On Wed, 2010-12-01 at 16:16 -0500, William Cox wrote:
> Whenever I run the userp_fft.py script (USRP1, Ubuntu 10.04 and
> 10.10), there's almost always a large spike (10-20 db above the noise
> floor) at the center frequency. This is the same for all the daughter
> boards I've tried (WBX, LFRX, and
Whenever I run the userp_fft.py script (USRP1, Ubuntu 10.04 and 10.10),
there's almost always a large spike (10-20 db above the noise floor) at the
center frequency. This is the same for all the daughter boards I've tried
(WBX, LFRX, and BasicRX).
Why is this? What am I missing?
Thanks.
-William
__
I do have the Refresh tab set to time-based refresh periodically and 5
second timeout. I seem to make one capture with no following renewals.
- Original Message -
From: "Nick Foster"
To: "Allen Vinegar"
Cc:
Sent: Wednesday, December 01, 2010 3:21 PM
Subject: Re: [Discuss-gnuradio] g
On Wed, 2010-12-01 at 13:55 -0500, Allen Vinegar wrote:
> I am getting output like the following:
> (-35) Type 11 (all call reply) from ac85cc in reply to interrogator 4
> (-34) Type 11 (all call reply) from ac85cc in reply to interrogator 4
> (-35) Type 11 (all call reply) from ac85cc in reply
On Mon, 2010-11-29 at 20:16 -0800, madengr wrote:
> Nick,
>
> Got it working on my USRP2 by changing to line 57 to:
> self.u = uhd.single_usrp_source("addr=192.168.1.15",
> uhd.io_type_t.COMPLEX_FLOAT32)
>
> and line 119 to:
> result = self.u.set_center_freq(freq,0)
That's correct. The Github re
Congratulations!
On 01/12/2010 12:31, Tom Rondeau wrote:
Last night, Ettus Research, LLC won the Wireless Innovation Forum's
SDR Technology of the Year for the USRP family of products. I'm very
pleased that Matt's contributions to the SDR community have been so
well received and recognized.
Tom
Hi,
I've noticed that with the aforementioned configuration that when I set the
gain between 0-40 dB that the actual gain out is 0-70 dB. I've seen this across
multiple units. Is there a fix for this?
Thanks,
David
___
Discuss-gnuradio mailing l
Just what I was looking for. In this case, it sounds like MinGW is the
way to go, especially since we may end up with multiple developers,
and a consistent environment would be best.
The script looks to be amazing. Thanks so much
Kevin
On Wed, Dec 1, 2010 at 7:46 AM, Don Ward wrote:
> Kevin Dixo
I'm still trying to get gr-ais going on Beagleboard (Lucid). When I tried to
run ais_decode.py, I've got "uOuOuO" output. On PC everything works fine. My
guess - BB simply can't process that much data.
So I ran usrp_benchmark on BB to see if this was the problem. 2MB/s and
4MB/s went fine, but wi
>-Original Message-
>From: Thomas Hobiger [mailto:hobi...@nict.go.jp]
>Sent: Tuesday, November 30, 2010 01:04 AM
>To: b...@sigmatix.com
>Cc: j...@joshknows.com, discuss-gnuradio@gnu.org
>Subject: Re: [Discuss-gnuradio] GRC with two URSP2+DBSRX andUHD
>
>Hi Bob,
>>This is pretty eas
On 12/01/2010 05:49 AM, Vladutzzz wrote:
> Thank you Marcus, for the very prompt and exhaustive reply!
> Mostly it's what I expected, but I am a wee bit worried about the IP
> addressing process:
> I need to change the IP of one of the USRP2 modules, how do I do that,
> considering I use an UDP FPG
It appears that the server went down yesterday. I don't know if anyone
recieved these messages. I apologize for any Deja vu this causes. Please see
the following:
-- Forwarded message --
From: Justin Bracken
Date: Tue, Nov 30, 2010 at 11:35 AM
Subject: USRP2 Lo Frequency Change
To
It appears that the server went down yesterday. I don't know if anyone
recieved these messages. I apologize for any Deja vu this causes. Please see
the following:
-- Forwarded message --
From: Justin Bracken
Date: Tue, Nov 30, 2010 at 12:17 PM
Subject: Discrete Lo Frequency Change
Kevin Dixon wrote:
I'd like to get started building GNURadio for Windows, using the USRP
1, with the goal of writing some custom blocks. Do people prefer
Cygwin or MinGW style installations? Off the cuff, Cygwin looks more
straightforward. Any opinions?
I use GNU Radio (with USRP1) on both, bu
> and line 119 to:
> result = self.u.set_center_freq(freq,0)
>
I intended the channel parameters to default to 0 for the single usrp*
blocks. It looks like i missed that. Will fix, thanks. -Josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.o
Nick,
Got it working on my USRP2 by changing to line 57 to:
self.u = uhd.single_usrp_source("addr=192.168.1.15",
uhd.io_type_t.COMPLEX_FLOAT32)
and line 119 to:
result = self.u.set_center_freq(freq,0)
I'm getting 0 aircraft locations in the KML file but the stdout is as
follows:
(-40) Type 11
Hi Bob,
This is pretty easy to do (but, I can only tell you how to do it in C++)...
set_clock_config() in UHD
Do you have some code snippet to share? Does the C++ version support
streaming data from a slave device through a host URSP2 before sending
all data via a single ethernet cab
Congratulations!
On Wed, Dec 1, 2010 at 1:31 PM, Tom Rondeau wrote:
> Last night, Ettus Research, LLC won the Wireless Innovation Forum's
> SDR Technology of the Year for the USRP family of products. I'm very
> pleased that Matt's contributions to the SDR community have been so
> well received a
Eric Blossom adapted MIT student Vanu Bose's "pspectra" (parallelized
"spectra") software into the first GNU Radio software. That software
used a PCI digitizer board, I believe from National Instruments, but
it was expensive and not very flexible. We knew of much better
digitizer chips, but there
Many many congratulations from me and all other community members, usrp is mile
stone in SDR technology
Sent on my BlackBerry® from Vodafone
-Original Message-
From: Tom Rondeau
Sender: discuss-gnuradio-bounces+smzerocool=gmail@gnu.org
Date: Wed, 1 Dec 2010 07:31:06
To: GNURadio Dis
On Tue, 2010-11-30 at 08:27 -0800, Vladutzzz wrote:
> I am interested in this 2 USRPs approach since I don't have the experience
> and the knowledge to start messing about inside the FPGA firmware code and
> have an extra USRP2.
> How would this go?
> I tried looking up some info about this topic b
Last night, Ettus Research, LLC won the Wireless Innovation Forum's
SDR Technology of the Year for the USRP family of products. I'm very
pleased that Matt's contributions to the SDR community have been so
well received and recognized.
Tom
___
Discuss-gn
Hi!
I'm trying to compile the BBN 802.11 component into the Gnuradio
3.2.2.1 framework on i686 Linux,
using GCC 4.3.3.
mar...@gnuradio012 ~/gnuradio/sw/bbn_80211
% make
make all-recursive
make[1]: Entering directory `/home/marius/gnuradio/sw/bbn_80211'
Making all in config
make[2]: Entering dire
Thank you Marcus, for the very prompt and exhaustive reply!
Mostly it's what I expected, but I am a wee bit worried about the IP
addressing process:
I need to change the IP of one of the USRP2 modules, how do I do that,
considering I use an UDP FPGA image and not UHD?
Also, what IPs should I use i
Is anyone out there taking another look at CUDA + Gnu Radio?
Some of the couple-of-years-old charts I've looked at suggest that
speedups for some of the
most important transforms we use vary between modest and disappointing.
Cross-over points for things like FFTs are usually up in the atmospher
Hello all,
I am writing a report on gnuradio and wanted to include a small portion about
the history of the USRP. The only info that I have found is from wikipedia,
"The GNU Radio project created the Universal Software Radio Peripheral (USRP)
... the USRP was
developed by Matt Ettus." I was sl
Hello All,
As always thanks for the help.
I was doing some timing measurements the other day and was wondering if this
seemed reasonable to you all. I did a simple setup in GRC where I had a
toggle switch that changed the frequency the usrp used as an LO. I input a
constant of 1 into the USRP2 bl
Hello all,
Another question. I need to have essentially a counter that will control
what frequency I transmit out of the USRP2. I need to control the rate at
which it changes. Currently I use a ramp function to do this. I see there is
a vector source that is also possible solution. Im wondering if
On 11/30/2010 10:06 PM, Miok Wah wrote:
Hi all,
We hope to do some experiments with the LP0410 antenna. Before that, we
hope to know more about its characteristics:
1. Is it a directional antenna?
2. If so, is there statistics about its directionality (e.g., beamwidth)?
We did not find releva
How did you resolve your problem? I have the same problem and reading your
post I cannot understand the solution of your one.
Thanks in advance
blwfsoj wrote:
>
> Hi all,
> Before i start telling about my problem, i want to mention that i have
> already read the post named "help: cannot send a
Tom,
You are right, it doesn't make any sense, I was thinking about the reverse
method, taking for example just 10 MHz out of a total band of 12.5 by filtering
or resampling, but that is totally different since you have extra band and you
just eliminate the extra part, but here you can't just ma
48 matches
Mail list logo