On Feb 19, 2009, at 9:44 PM, Gregory Maxwell wrote:
Nvidia video is a pretty poor choice for Linux too— you're tied to
their proprietary drivers which often cause weird bugs (usually the #1
cause of kernel panics on the kernelopps data collection project,
right ahead of a proprietary wifi
On Feb 15, 2009, at 12:11 PM, Chris Stankevitz wrote:
Pete,
How did you solve this problem:
While running ./bootstrap, I am getting the following error:
[r...@fodora gnuradio-3.1.3]# ./bootstrap
gr-trellis/doc/Makefile.am:51: `%'-style pattern rules are a GNU
make extension
AFAIK it's not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 20, 2008, at 6:40 PM, George Nychis wrote:
Bill Stevenson wrote:
In door environment; the temperature are the same in these two
experiments; center frequency is 2479MHz because on one hand, I
want to avoid the 2400MHz to 2483MHz band
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 15, 2008, at 8:14 AM, Angie Ll wrote:
I am just starting to learn the GNU radio and bn code.
I want to test some sample bbn code, however, can anybody tell me
where
and how can I run this code?
Look at CGRAN: https://www.cgran.org/ .
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 4, 2008, at 2:31 PM, Bill Stevenson wrote:
I have a rudimentary question about the attenuator. When I was
searching some questions in the archive, I found that some guys
mentioned when testing the transmitter and receiver for daughter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 28, 2008, at 4:10 PM, George Nychis wrote:
C.cc Jay wrote:
Dear andrea
I want to develop ISO 14443-A,
Can you tell me, how to find ASK100% python module. Or I must
rewrite this part of the code.
Do you know if any of the RFID code done
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 10, 2008, at 11:59 AM, Philip Balister wrote:
My data file is 16bit complex shorts in big-endian format. It looks
like the file source block reads data from the file and sends it to
the fm demod which is expecting a complex float data. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 9, 2008, at 8:39 AM, Dan wrote:
Hi, I am working on an OOK receiver but am having some problems with
the squelch.
I wrote a script with the following flow graph:
USRP.source_c - complex_to_mag - add_const_ff( -const ) -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 2, 2008, at 7:34 AM, kaleem ahmad wrote:
Hi,
I want to transmit some data using usrp.sink_c and immediately after
the
data is sent I want to start receiver mode, but my problem is if I
do like
this:
Send using 'usrp.sink_c'
start
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 11, 2008, at 11:26 AM, Mohsen Baratvand wrote:
Guy, all I need to do is changing some parameters such as preamble,
LTF, STF, modulation and etc of the OFDM transmitter and then send a
predefined pattern to the OFDM receiver, then estimate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 11, 2008, at 1:14 PM, George P Nychis wrote:
The slightly longer response:
I think these are all great ideas, and I think they'd be a valuable
contribution to the GNU Radio community. CPAN (The Comprehensive
Perl
Archive Network) and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 9, 2008, at 12:11 PM, Brian Padalino wrote:
On Tue, Sep 9, 2008 at 3:08 PM, isaacgerg [EMAIL PROTECTED]
wrote:
Any ideas in US dollars?
http://www.ettus.com/orderpage.html
List price seems to be $1400, but don't forget the accessories!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 2, 2008, at 8:58 AM, Brian Padalino wrote:
On Tue, Sep 2, 2008 at 11:51 AM, Engin Karabulut [EMAIL PROTECTED]
wrote:
hi all,
I have two signal which is float and I want to use
atan2 fuction like this,
self.arctan =
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 25, 2008, at 10:37 AM, Johnathan Corgan wrote:
On Fri, Aug 22, 2008 at 2:00 AM, Ulf Lindgren A
[EMAIL PROTECTED] wrote:
I have made a fix for the change in comedilib.
Thanks for the update.
We'll have to figure out a way to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 18, 2008, at 10:43 AM, Dan Halperin wrote:
http://gnuradio.org/trac/wiki/UsrpFAQ/Clocking
And there is another way of clocking if you want to solder on an SMA
connector instead, connect an external clock, and disable the onboard
clock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 11, 2008, at 4:58 PM, Daniel O'Connor wrote:
On Mon, 11 Aug 2008, Philip Balister wrote:
New appication for USRP+GNU radio, free subway rides :)
http://www-tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf
Well, at least until people
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 31, 2008, at 12:15 PM, Wireless Monster wrote:
All,
I've been trying to set both Tx and Rx to the same frequency and
sending a sinusoid to try to measure the frequency offset, but it
does not seem to work... it looks like as both Tx and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 29, 2008, at 6:14 PM, yyzhuang wrote:
That's the point. But to unpack a packet, we have to know exactly
its format.
Hope someone can tell what format of the packet is. And what
information can
we get from the packets.
The 802.11
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 28, 2008, at 2:09 PM, isaacgerg wrote:
Eric,
When you talk about the FPGA, do you mean that I can repull and
reinstall
the FPGA code for the USRP? This I have never done since the radio
has been
purchased 2 years ago.
Isaac
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 11, 2008, at 11:24 AM, Chris Stankevitz wrote:
Matt Ettus wrote:
Remember that while the ADCs are 12 bits, we carry 16+ bits of
precision throughout the signal processing.
How do you get 16 bits of precision from a 12 bit ADC? What does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 2, 2008, at 3:20 PM, Matt Ettus wrote:
The RFX400s have PLL chips on them. The PLL chips on the 2 boards
are fed the same reference clock since it comes from the
motherboard. However, they both divide the clock down by the R
Divider
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 25, 2008, at 4:28 PM, Eric Blossom wrote:
2) I have a transmitter USRP and a receiver USRP attached to the
same
machine. I use usrp.serial_number() as suggested by Eric in many
previous mails to distinguish between them. I have a code loop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Two not-that-related questions... but here goes.
1) I notice that multi-antenna.py claims to only work with the BasicRX
boards. Any reason I can't use the 2 RX paths on each of 2 RFX2400s
assuming the d'board is powered up and configured
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 25, 2008, at 3:20 PM, Eric Blossom wrote:
On Wed, Jun 25, 2008 at 02:37:48PM -0700, Dan Halperin wrote:
1) I notice that multi-antenna.py claims to only work with the
BasicRX
boards. Any reason I can't use the 2 RX paths on each of 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- - -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- - - -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 4, 2008, at 10:59 PM, Chris Stankevitz wrote:
USRP's cfile utility cannot write my data
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey,
I know that the buffer allocation uses some memory mapping tricks to
make it efficient; is there some shared resource that this process
uses of which a computer should have a finite amount? I'm running a
process with, oh, say 500 buffers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 9, 2008, at 9:21 AM, Eric Blossom wrote:
You're probably running into a limit on the total number of shared
memory segments in the system (SHMMNI) or the max segs per process
(SHMMSEG). You can check the current values by:
$ cat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I don't know how relevant this is, but I have fixed similar problems
in the past by making sure that the host app sends data that's an even
multiple of 512 bytes. (This is harder than you think :))
I found that if you send a number of sample
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 19, 2008, at 2:24 PM, Eric Blossom wrote:
On Fri, Apr 18, 2008 at 10:25:07AM -0400, Brian Padalino wrote:
On Fri, Apr 18, 2008 at 10:21 AM, Wireless Monster
[EMAIL PROTECTED] wrote:
Thank Martin,
However I was thinking in a way to measure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there an way to disable the (usually good) automatic recognition of
advanced CPU features by the filter libraries, etc?
Thanks!
Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phaysal Khan wrote:
I get the msg
Using RX d'board A:none
USB sample rate 4M
It's using side A, not side B. Try with the -R B option. (see the
usage message shown below)
$ usrp_rx_cfile.py
Usage: usrp_rx_cfile.py: [options] output_filename
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry for the dumb question :).
I've tried to change the global CXXFLAGS by modifying
gnuradio/configure.ac, but the changes are not propagated to the rest of
the tree even after a configure. I've had some success modifying all of
the Makefile.am
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Blossom wrote:
On Mon, Mar 03, 2008 at 12:29:45PM -0800, Dan Halperin wrote:
I've tried to change the global CXXFLAGS by modifying
gnuradio/configure.ac, but the changes are not propagated to the rest of
the tree even after a configure. I've
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Nychis wrote:
it seems to me like you're using antennas, you can try coax to isolate
the problem maybe you're getting interference at 2.4GHz. But answer
Eric's questions too.
With suitable attenuation of course -- I think Matt says at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Suppose I want to build a C++ application to drive GNU Radio, using
captured trace data -- so I don't need the USRP.
With the new top_block stuff we should be ready for this now, correct?
Here's a short program towards going down that path:
#include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Halperin wrote:
Suppose I want to build a C++ application to drive GNU Radio, using
captured trace data -- so I don't need the USRP.
Another observation: It looks like right now there's no
super-header-file like gr.h that does the same thing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Has anyone had success using VTune (or pin, or another linux profiler)
with GNU Radio? I'm experiencing a difficulty in that VTune segfaults
when trying to process libgnuradio-core and pin produces no output at
all, although both programs work on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shravan Rayanchu wrote:
Basically, I seem to completely lose some of the packets in the air.
Of the packets I receive, almost all the packets are received
correctly. Initially, the error rate was too high (The packets were
getting lost and also
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Nychis wrote:
What general_work() would do is use the first ntaps() samples as
history and start producing output at in+ntaps(). I would then
consume ninput_items-ntaps() to then keep those last ntaps() samples in
the input queue as the
at
different frequencies can bring the noise floor back to normal. If I
transmit at 2.48G and receive at 2.485G the noise floor is normal. With
some other RX frequencies, (I think 2.445G) the same problem persists.
- -Dan
Johnathan Corgan wrote:
Dan Halperin wrote:
Just-powered on USRP rev 4.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just-powered on USRP rev 4.2 with RFX2400 rev 2-6-2006. Current SVN.
usrp_rx_cfile.py -f 2.485G -d 8 -s pre.dat
usrp_siggen.py -i 16 -f 2.485G
usrp_rx_cfile.py -f 2.485G -d 8 -s post.dat
In the first set of data, the noise level is what I'd expect
.
- -Dan
Dan Halperin wrote:
Just-powered on USRP rev 4.2 with RFX2400 rev 2-6-2006. Current SVN.
usrp_rx_cfile.py -f 2.485G -d 8 -s pre.dat
usrp_siggen.py -i 16 -f 2.485G
usrp_rx_cfile.py -f 2.485G -d 8 -s post.dat
In the first set of data, the noise level is what I'd expect and
everything
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Nychis wrote:
Was the access code picked randomly, or was there some basic rule of
thumb for generating it? What about the threshold of 12? What about
choosing a 64bit access as opposed to 32bit?
Standards for access codes are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
You want to remove the installed files of GNU radio, you're going to
replace them from source.
- -Dan
Jonas wrote:
Will I not remove the installed files of GNU Radio? Do I just remove its
directory?
=)
On Jan 11, 2008 10:50 AM, Dan Halperin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wee Shinhan wrote:
Hi eric,
Thanks for the reply, i have connected it to the
channel filters, i trying to do an estimate on
wireless channel coefficient. Therefore i'm trying to
capture the complex data received before
de-modulation. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The default decim in the C++ program (which, IIRC, is deprecated) is 8.
What decim (what bitrate?) are you using for GMSK?
- From the graphs, it looks like data from the C++ app is coming in about
4x too fast.
- -Dan
George Nychis wrote:
Hi all,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
By default, oprofile tracks CPU usage of each process/function/whatever.
I'm trying to do some cache analysis now but I can't get it to change
events. My setup command looks like this (trying different events):
sudo opcontrol --setup --no-vmlinux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Nychis wrote:
The decimation should not affect the amplitude of the waves, right?
Which if you look at the graph, the GMSK receiver has ~4x the amplitude.
Actually, it may. Imagine you decimate by a factor of 4, that's sort of
like adding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I suspect this comment:
http://gnuradio.org/trac/browser/gnuradio/branches/features/inband-usb/usrp/fpga/inband_lib/rx_buffer_inband.v#L120
TODO write this genericly
is where the interleaving should be done... maybe :).
- -Dan
George Nychis wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Johnathan Corgan wrote:
On 12/11/07, Johnathan Corgan [EMAIL PROTECTED] wrote:
I see this as well now. It can be attributed to a check-in on the trunk
2 days ago that Martin did to fix an iir bug (r7089). I suspect the iir
QA needs to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wuest Brandon-WTVR47 wrote:
I am having a problems with disk writing not being able to keep up with
the high data rate, so I am trying to do a little manipulation of the IQ
data to get around this. What I am trying to do it get 8-bit samples
from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please don't send attachments to the GNU radio mailing list.
It's a known issue that the USRP sends some spurious large amplitude
samples right after it is enabled. You can safely ignore them.
- -Dan
Aadil Volkwin wrote:
Hi
Attached is code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Padalino wrote:
On 10/29/07, Achilleas Anastasopoulos [EMAIL PROTECTED] wrote:
PS: I have mixed feelings about all this being implemented on the FPGA:
is this a software or a hardware radio?
In terms of GNURadio, I can agree with the mixed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think the answer you want is:
cvs -d [EMAIL PROTECTED]:/cvs/adroitgrdevel co adroitgrdevel
then ./bootstrap ./configure as you wish from the gr-bbn subdirectory.
- -Dan
Mohammad Hamed Firooz wrote:
Hi everyone,
I am going to use BBN code on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My 2c:
I imagine that futuristic uses of the USRP (such as the ones for which
you're explicitly redo-ing the stack) involve dynamically changing the
decimation on the fly. Drive it off the absolute clock to keep some
sense of meaning.
- -Dan
George
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Padalino wrote:
The CIC filter has some bit-growth associated based on your decimation
rate. This growth is deifned for decimations up to 128 in that file.
It basically takes a different slice of the CIC comb section at
the end.
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In my experience the USRP stops performing very well at low bitrates.
This is due to the current code's inability to handle large frequency
offsets when the symbol period is that long.
Try it at 250kbps/500kbps.
- -Dan
Joseph Crowley wrote:
Joseph
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It'll involve hacking the FPGA code, but no, it shouldn't be especially
hard.
- -Dan
Jan Schiefer wrote:
This may be a dumb question, but suppose I changed the USRP ADC clock to
10MHz. Would there be a way to get 12-bit integer data across the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Old documentation on GNU radio says that it would have transparent
SMP/multicore/SMT support for signal processing by version 2.x; on 20
March 2007 Marcus Leech sent an email claiming
Eventually, Gnu Radio will support multi-threading for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The maximum (at 16 bits complex samples) data rate across USB on the
USRP is 16 MHz; hence the minimum decimation rate of 4. My understanding
is that this decimation gives more bits -- since you're combining 4
samples together, you can now extrapolate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Berndt Josef Wulf wrote:
G'day,
building current source results in an error due to missing file gr_runtime.i.
It appears runtime.i was renamed to gr_runtime.i which was missed in the
trunk.
cheerio Berndt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The comment for the filters gr.freq_xlating_fir_filter_XXX says (about
the parameter center_freq):
/*!
* Construct a FIR filter with the given taps and a composite frequency
* translation that shifts center_freq down to zero Hz. The frequency
*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey all,
I'm trying to receive, and send, traffic on a fixed but unknown carrier
frequency within the passband of the USRP. That is, there are many
communication bands, but transmissions happen on only one of k channels.
The trivial approach is to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Johnathan Corgan wrote:
For the receive side, you can use a blks.analysis_filterbank to turn a
wideband signal with N carriers into N baseband channels equally spaced.
Then you can attach demodulators to these output ports.
This is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Note that Matt has claimed in the past (and I've partially verified)
that the Basic boards can go as low as about 100kHz.
- -Dan
Brian Padalino wrote:
On 8/23/07, George Nychis [EMAIL PROTECTED] wrote:
Hey all,
I'm slightly confused. I'm trying
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think Hydra at UT does this.
- -Dan
George Nychis wrote:
A couple students did this for their master's thesis here two years back
I think. Peter had e-mailed me their report, I'm hosting it for you:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bahn William L Civ USAFA/DFCS wrote:
Thanks, that helps some.
I figured that I could put in the literal size of the data, in bytes, but
that only helps if it actually matches how the GR blocks are going to process
those bytes.
When
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The USRP has a maximum bandwidth of about 16 MHz (using 8-bit samples
instead of the usual 16), which is not even enough to cover one
802.11b/g channel (22 MHz Nyquist). Thus you'll have a hard time
decoding b/g packets at faster than 1,2 Mbit rates
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bahn William L Civ USAFA/DFCS wrote:
I have a few questions, but they mostly come down to: What is the data file
format when using a file as a signal source?
These file_sink and file_source are direct wrappers for the C functions
fwrite and fread
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The data is packed binary data. Each complex samples is stored as 8
bytes, 4 bytes I as a float and 4 bytes Q. You need to use a binary
program to read these files. See read_complex_binary.m for MATLAB code
and the exact same syscalls translate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hsin-mu Tsai wrote:
On 7/25/07, Dan Halperin [EMAIL PROTECTED] wrote:
I removed all the USB devices from the computer when I was doing the
experiment. The benchmark script said 32 MB/s throughput can be
achieved.
Sorry I reread your original
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
One interesting thing I noticed is that when I increased fusb_nblock
and fusb_block_size, it shows a lot of buffer overrun ('uO'). When I'm
using the default setting, these uO disappear. Why is this happening?
However, the packet loss ratio are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hsin-mu Tsai wrote:
2. I guess I wasn't very clear in my first e-mail. I tried two
different kinds of setting with file_sink and file_source:
a) TX_blocks - usrp_source - usrp board 1 ---physical_channel---
usrp board 2 - usrp_sink - file_sink
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dong Li wrote:
found four of them can't pass the configuration checks:
gr-audio-jack
gr-audio-osx
gr-audio-portaudio
gr-audio-windows
You only need these modules if you plan to be using your sound card with
signal processing. The specific
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
pratik hetamsaria wrote:
hi..
fg.connect(self.dst,self.chan_filt,self.packet_receiver)
where self.dst refers to the new file which i want to demodulate.
That should work, as long as self.dst is actually a file _source_ not a
file sink. And the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There is a gr_throttle block that you can use to rate-limit your data. I
think the only rate-limiting going on here is CPU time.
- -Dan
John Bratteli wrote:
I'm attempting to write a script, based on
usrp_fft.py, that will read a file of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've asked a similar question before, so please try and bear with me :).
Is there a way to calculate the delay of all blocks after yours in a
chain? It might be as easy as summing up the histories of all of the
blocks...
As an illustration of why we
Has anyone explored inserting a compression algorithm before a file_sink
or a file_source? I made a gzip_file_sink, but it just can't keep up
at low decimation rates. Are there good compression libs that anyone
would recommend instead?
Similarly, has anyone explored writing a MATLAB script
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sander Stepanov wrote:
Hi, I going to buy one THE USRP card but I am not sure
that it is what I am looking for
pls help me if sombody have this one in Toronto
Sandy
You order the USRP from Ettus Research, www.ettus.com.
- -Dan
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Meenaktchi Venkatachalam wrote:
Thanks Tarun, this helped.
Is there anyway to do the opposite? I have 16-bit I and Q data, I would
like
to send this data to USRP and transmit
Thanks
Meenaktchi
To log data from the USRP: usrp.source_c -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Double check that you updated /etc/ld.so.conf and run ldconfig?
- -Dan
John Stralka wrote:
I am running Feisty Fawn Ubuntu. I downloaded, built, and installed the GNU
Radio via the trunk following the build directions for Feisty on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarun Tiwari wrote:
Hi,
I was wondering if we can add the packet number using current packet_utils
python class.
When I look into the code, I see that we introduce the preamble, access
code, length of the packet, payoad with crc, and padding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brett L. Trotter wrote:
I had originally asked Johnathan Corgan about expanding the list called
sbs_to_mm that has the mm mu gain for given samples/symbol to include
higher samples per symbol so that we can use it at very low bitrates. I
don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fresh SVN checkout as of this morning, into a new directory (r5734).
Ubuntu Edgy, everything's upgraded to its newest version, more or less
along the lines of the install guide that mdickens and I put together on
the trac.
1) ./configure spits out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Halperin wrote:
Fresh SVN checkout as of this morning, into a new directory (r5734).
Ubuntu Edgy, everything's upgraded to its newest version, more or less
along the lines of the install guide that mdickens and I put together on
the trac.
2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nothing that modulates data has constant envelope. Plot the amplitude of
a BPSK or GMSK signal (after transmission, not simulation) sometime.
- -Dan
Achilleas Anastasopoulos wrote:
Bob,
this is not correct.
The CPM signal is by definition
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Rader wrote:
Hi
I have GNUradion up and running with the USRP board. I have two daughter
cards installed. One is the DBSRX, the second is the RFX1800, and I have a
3rd dauther board the TVRX that is not installed. I can get the thing to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Johnathan Corgan wrote:
Dominic Spill wrote:
I think I may've mis-phrased the question, if I have a single daughterboard
and I tune to 2.44GHz, what are the highest and lowest frequencies that I
should be able to see when I run something like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Looking at the existing DBPSK detector, it seems that the current
software doesn't do any sort of transmission detection where
demodulation only happens if there's an increase of energy in the air.
It seems you could implement this easily with a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Blossom wrote:
On Wed, May 09, 2007 at 01:02:52PM +0200, Albert Rodriguez wrote:
We're trying to receive two signals from two different RFX2400 in the
same USRP. We've already read everything about setting the rx mux and
snip
These lines:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Halperin wrote:
Eric Blossom wrote:
On Wed, May 09, 2007 at 01:02:52PM +0200, Albert Rodriguez wrote:
We're trying to receive two signals from two different RFX2400 in the
same USRP. We've already read everything about setting the rx mux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eng. Firas wrote:
Hi,
How can I now my USRP REV number (and my daughter boards rev)? where I can
read it on the broad?
Firas,
Upper right corner of the USRP. Daughterboards, at least for the RFX
2400, right below the model name (middle of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey all,
Sorry to bring up painful memories :). I did some calculations to work
out frequency drift of the USRPs, and I wanted to know where I'm going
wrong.
The crystals in the RFX 2400 are spec'ed at 50ppm error, which is to say
that the maximum
Melody S wrote:
Hi,
I already have downloaded all the Usrp codes and Gnuradio code but when I
go to this link http://www.comsec.com/wiki?UsrpInstall for the
Usrp Hardware setup and try to run the %tail -f /var/log/messages
command, it gives me this error No such file or
You can just do it from the gnuradio-core/src/lib directory too, unless
you actually add a new block.
-Dan
pradeepbhat wrote:
I do the same but it seems to be achingly slow. Well I guess I would have
keep doing that if i need to modify something.
Pradeep
Chris Stankevitz wrote:
When I
Davide Anastasia wrote:
Hi List,
I'm using a line link this in a script:
self.pack = gr.unpacked_to_packed_ss(1, gr.GR_LSB_FIRST)
It's give me only a sequence of zero, but I don't mind why!
Any suggestion?
What's the previous block? Is it binary? Are you using the wrong
endianness? For
Dan Halperin wrote:
Is there a howto for how to add a new signal processing block to the GNU
Radio libraries?
Sorry; in case it wasn't clear, I saw and used the how-to-write-a-block
code. But actually adding it to libgnuradio-core and getting SWIG to
process it was the tricky bit that took
Is there a howto for how to add a new signal processing block to the GNU
Radio libraries? I made a gr_xor_bb (in src/lib/general) block, and it
took me about an hour to figure out all the files I had to modify to get
it made (the one I missed was general.i).
Anticipating Eric's response, what's
Eric Blossom wrote:
On Wed, Mar 28, 2007 at 09:39:14PM -0700, Dan Halperin wrote:
Same loopback code I emailed about earlier; this time I attached the
complete file (modulo some cleanup).
Here's my input file (in stupid x86 short ordering..):
$ hexdump input.txt
000 bbaa ddcc
(Eric, sorry I keep failing to reply all)
Eric Blossom wrote:
On Thu, Mar 29, 2007 at 08:01:38AM -0700, Eric Blossom wrote:
On Thu, Mar 29, 2007 at 08:04:22AM -0400, Greg Troxel wrote:
I wonder if there is data somewhere in the flowgraph that's less than
the amount needed for the
1 - 100 of 153 matches
Mail list logo
