On Nov 22, 2009, at 10:11 AM, George Nychis wrote:
> Has anyone here had any success with receiving 16-bit samples from the USRP2
> @ 20MHz to the host without an onslaught of overruns? I did some searching
> on the list and some people suggested a RAID configuration, but this is my
> poor lit
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 driver)
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 w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 17, 2008, at 10:44 AM, Peter O'Doherty wrote:
This is my first post to this list.
I'm a sound artist and I've just started to explore the world of
software radio and have been eavesdropping on this list for a while
and have a few question
-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/ . Th
-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
bo
-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 a
-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 atte
-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 ) ->
binary_slicer
-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 recei
-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 CEAN
-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 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 9, 2008, at 10:04 AM, Rana Basheer wrote:
How do I go about bypassing this filter?
Check out this thread:
http://www.nabble.com/FSK-with-RFX2400-td18587205.html#a18587205
which I found via a simple search: http://www.nabble.com/GnuRadio-f
-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 = math.atan2(x_hyd_filt
-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 conditional
-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 18, 2008, at 9:10 AM, Wireless Monster wrote:
Is any modification needed to the USRP board to use an external
clock generator instead of the on board 64MHz one?
A trivial search of the Wiki, or the mailing list, should be executed
before
-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 le
-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 Rx
-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 packe
-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 FPG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
From Matt's recent announcement email:
""
2 Upcoming Daughterboard Status
The WBX0510, a transceiver which will cover 50 MHz to 1 GHz, has been
delayed a bit,
but we hope to have it ready for purchase some time in July.
The WBX0822, a transcei
-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 l
-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
-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 correctl
-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 wi
-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 /sys/proc/
-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
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 byt
-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
At hat point can I send the samples (for example from a file with
> gr.file_source) and guarantee they will be treated as a 270.8333Ks/
s stream?
> (assuming there will be enough samples to process)
No. They will be treated like a 2Msps stream w
-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 - http://enigmail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phaysal Khan wrote:
> I get the msg
> Using RX d'board A:
> 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
Opti
-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 t
-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 file
-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 a
-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
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.
-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
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 t
nd receive 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-powe
ple frequencies.
- -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, th
-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 an
-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 interesti
-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
-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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
sri ram wrote:
> P.S. I am attaching the output of the rx side.
uOok = True pktno = 47 n_rcvd = 48 n_right = 48
ok = True pktno = 48 n_rcvd = 49 n_right = 49
ok = True pktno = 49 n_rcvd = 50 n_right = 50
ok = True pktno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brook Lin wrote:
> plughw:0,0 to record the FM radio to my computer. It gives me almost the
> same error: audio_alsa_sink[plughw:0,0]: Device or resource busy. Can you
Is some other application locking the sound card? An IM client, a media
player, eve
-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 e
-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 --se
-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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eugene Grayver wrote:
> Please see answers in-line.
> Which blocks are causing you the biggest problem?
>
> I got a 2x improvement on all the filtering blocks. About a 40%
> improvement for sine/cosine generation blocks. This includes gr_expj,
>
-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
> f
-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 i
-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 t
-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 cod
-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 N
-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.
>
>
-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 US
-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 pro
-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 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
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
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 demons
-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 ha
-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'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lisa Creer wrote:
> On 8/20/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
>> On Mon, Aug 20, 2007 at 11:15:36PM -0400, Lisa Creer wrote:
>>> I'm testing the -8 option in various example programs, and haven't been
>>> successful in receiving valid data.
-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:
> http://www.andrew.cmu.edu/user/gnychis/SDR
-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 (B
-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 po
-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 fre
-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.
S
-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 -> f
-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
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 directo
-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 co
-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 th
-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
-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 gr_compl
-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 P
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 th
-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
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 pa
-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
> "http://g
-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 m&m 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
Eric Blossom wrote:
> Dan, are you running under Debian or Ubuntu?
>
> If so, all of this is probably a result of the broken version of
> libtool that Debian/Ubuntu ships.
>
> See the section on "Broken libtool" in the Ubuntu install guide
> http://g
-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
-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 som
-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
-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 somethin
-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 block
1 - 100 of 177 matches
Mail list logo
