Scenario 3 - An arbitrary number of USRP2 systems, no MIMO cables,
no HUB
Some means of providing the same 10 MHz reference to all USRP2 systems
must be set up. Typically this would be the 10 MHz output of some lab
reference like a GPS-locked reference. That reference would be put
through some s
Oh, I forgot to mention that both the attached plots in my previous mail
were from an over-the-air test at 2.412 GHz using two USRP Rev 4.5
boards with RFX2400 Rev 30 and the new antennas.
Thanks for the pointer to the literature!
Kyle
Dominik Auras wrote:
Hi Kylie,
This has also been propo
I believe it would result in spurious
peak detections, which might hurt performance in the face of multiple
transmitters and receivers. The issue is harder to see when the
transmitter sends continuously, since the normalization factor never has
a chance to fall.
Comments/feedback? Thanks,
acket reception rate), switching the hardware roles of transmitter
and receiver results in 0% packet reception rate.
Any idea why? In my own toy PHY implementations in the past, I've
noticed very different carrier frequency offsets between different
pairs of daughterboard, so that's my guess
Tom,
Thanks for your reply. I've tried the following, doubling the
interpolation and decimation rates to their maximum, twice the
defaults:
./benchmark_ofdm_tx.py -v -T A -f 2.45e9 --tx-amplitude=3000 -i 512
./benchmark_ofdm_rx.py -v -R A -f 2.45e9 -d 256
and no packets received. I simultaneou
Thanks for responding so quickly.
I cvs updated this afternoon just before trying it. Have you moved to
a different (svn) repository? I'm using
[EMAIL PROTECTED]:/cvs/adroitgrdevel.
On 11/7/06, Greg Troxel <[EMAIL PROTECTED]> wrote:
I am indeed reading the list :-)
desired freq = 24370
I'm hoping one of the BBN people is reading this list... I checked
out the CVS code from acert.ir.bbn.com:/cvs/adroitgrdevel, and try
running bbn_80211b_rx.py like so:
$ /opt/gnuradio/bin/bbn_80211b_rx.py -f 2.437G -v -b
Bits Per Encoded Sample = 8
adc frequency = 6400
decimation frequency
A fresh checkout now builds and installs cleanly on FC6 -- thanks.
I've added a configure check for the header and made the include
dependent on that. IIRC there was some distribution way back when,
that required this file.
Please update trunk and test.
Eric
__
After upgrading to FC6, usrp/host/lib/fusb_linux.cc fails to compile
(can't find linux/compiler.h). Turns out for me, that include file
isn't needed at all (trivial patch attached). I wonder if I've broken
something by removing it, or if other systems need it?
fusb-fc6.patch.gz
Description: G
"How to write a signal processing block" suggests subclassing from
gr_sync_block for the case of a sink. However, gr_sync_block's work
function arranges to call consume_each for the user, consuming the
same number of elements on all inputs. What if my sink doesn't
consume at the same rate on eac
Right, depending on the version of swig you're using, you'll get
either a lot or a whole lot of warnings, and then it'll take a minute
or so to compile.
On 6/14/06, Eric Blossom <[EMAIL PROTECTED]> wrote:
On Tue, Jun 13, 2006 at 10:52:33PM -0700, John E. Don Carlos wrote:
> I applied the patch b
ling FC5 but didn't have
the time or skill to solve it. Exactly how do i apply the patch? and to
what?
Thanks,
John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf
Of Kyle Jamieson
Sent: Tuesday, June 13, 2006 1:52 PM
To: discuss-gnuradio@gnu.org
Subjec
Well, I've resolved this issue for myself. I'd be interested in why
this isn't bugging everyone else, and if I made a mistake. It just
involved an apparently bad header prototype; patch follows.
Index: src/lib/general/gr_binary_slicer_fb.h
===
I'm using FC5, compiling gnuradio-core from cvs. With both the
current Fedora version of swig (1.3.24) and swig 1.3.29 from
Sourceforge, I have problems compiling
src/lib/swig/gnuradio_swig_python.cc. Let me know if I can provide
any other relevant info; below is part of the compile transcript.
14 matches
Mail list logo
