I think I was wrong; it looks like "bitrate" is used in the expected way - to
indicate the transmission bit rate. However the code doesn't take
bits-per-symbol into account in uhd_interface.py (line 70):
asked_samp_rate = bitrate * req_sps
Shouldn't this be, "asked_samp_rate = bitrate * req_sps
Top on. Fire up the fastest card you have (widest band signal you can
process) and put your finger on the FPGA. It is cool.
If the oscillator in the USRP1 were most stable and accurate, it might make
some sense but it just doesn't in my opinion make sense so I disconnected
them all in my USRP 1
Hi, all,
I have updated the kernel modules to 3.0.0 for my USRP E100.
UHD is successfully built and benchmark_rx_rate in
uhd/host/build/examples works.
I further installed the gnuradio according to the
usrpe1xx-FAQhttp://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ
$ git clone git://gn
I believe usrp is the old driver for USRP1, which you don't need since you're
running UHD. Also, the OFDM example (and the other examples) don't run on UHD
yet. You can try the "next" branch from git, in which some of the examples have
been ported to use UHD.
Sean
From: discuss-gnuradio-bounce
Hi, Marcus and Sean,
I'm a little bit confused by the relationship between UHD and gnuradio.
I thought we can use either UHD or gnuradio, just UHD provides some unique
interfaces for the products from Ettus.
Do you mean that our old ofdm codes that work on USRP1 cannot be used
anymore?
We are work
On 10/19/2011 09:41 AM, xi yang wrote:
> Hi, Marcus and Sean,
>
> I'm a little bit confused by the relationship between UHD and gnuradio.
> I thought we can use either UHD or gnuradio, just UHD provides some unique
> interfaces for the products from Ettus.
uhd is the hardware driver for ettus p
On 19/10/2011 12:41 PM, xi yang wrote:
Hi, Marcus and Sean,
I'm a little bit confused by the relationship between UHD and gnuradio.
I thought we can use either UHD or gnuradio, just UHD provides some
unique interfaces for the products from Ettus.
Do you mean that our old ofdm codes that work on
On 19/10/2011 12:53 PM, Josh Blum wrote:
You will have to change the block that is instantiated to be a uhd usrp
source or sink. There is no reason that rest of your
modulation/demodulation chain or mac layer would have to change.
Cheers,
-Josh
A further consideration for porting applications/e
Hi, Marcus,
Thanks a lot, got it.
I may have to have a look at the examples in gr-uhd, see how the codes are
changed.
And curious, what do you mean by plugging a USRP1 to USRP E100?
I only understand that we can change daughterboards for a motherboard.
Thanks,
Yooxi
2011/10/19 Marcus D. Leech
Hi Marcus,
Could you point a commit diff of a grc example and a python example where
such port (USRP1 input converted to UHD input) is done?
Best regards,
Rafael Diniz
> On 19/10/2011 12:53 PM, Josh Blum wrote:
>
>> You will have to change the block that is instantiated to be a uhd usrp
>> source
On Wed, Oct 19, 2011 at 6:39 AM, Nowlan, Sean
wrote:
> I think I was wrong; it looks like “bitrate” is used in the expected way
> – to indicate the transmission bit rate. However the code doesn’t take
> bits-per-symbol into account in uhd_interface.py (line 70):
>
> ** **
>
> asked_samp_rate
Right.. that's what I meant :)
From: Tom Rondeau [mailto:trondeau1...@gmail.com]
Sent: Wednesday, October 19, 2011 2:45 PM
To: Nowlan, Sean
Cc: j...@ettus.com; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch
On Wed, Oct 19, 2011 at 6:39 AM
We are REMOVING the USRP and USRP2 components from GNU Radio!
It's been mentioned in the past, but the change on the next branch
is imminent. As of GNU Radio 3.5, we will no longer support libusrp,
libusrp2 or the GNU Radio interfaces, gr-usrp and gr-usrp2. Everything is
moving to using UHD.
If y
Another big change is happening today! Josh Blum has make GNU Radio build
using cmake, and we are hoping to switch over to it completely. The 'next'
branch has just pulled in his changes, and we now have parallel build
systems, cmake and autofoo. We are trying to make cmake the default build
system
Hi,
I'm experiencing problems with volk when building on an amd64 Debian
"testing". It started when volk was first introduced to the git tree and is
also my experience with the 3.4 release. When I build I get the following:
make[4]: Entering directory `/home/stevie/SourceCode/gnuradio/volk/lib'
/
On 10/19/2011 09:43 PM, Tom Rondeau wrote:
... we need people to start using it and testing as much as possible.
Build went smoothly with cmake on Ubuntu 11.10 x64 Unfortunately, it
built as 32 bit, but it works. I usually build with Marcus Leech's
script which handles the architecture automa
On 10/19/2011 08:42 PM, Dan CaJacob wrote:
> On 10/19/2011 09:43 PM, Tom Rondeau wrote:
>> ... we need people to start using it and testing as much as possible.
> Build went smoothly with cmake on Ubuntu 11.10 x64 Unfortunately, it
> built as 32 bit, but it works. I usually build with Marcus Le
It worked for me on Ubuntu 11.10 x64
On Oct 17, 2011, at 1:31 PM, "Marcus D. Leech" wrote:
> Could somebody try build-gnuradio under Ubuntu 11.10 and give me feedback
> about work/not-work. There's currently
> a pre-reqs paragraph for "11.*", which may or may not work under 11.10.
>
>
>
Hello,
I am working on the effect of adaptive modulation in packet loss. I am
running my codes in USRP2 with XCVR2450 daughter-board and I am using
UHD_003_001_002 image. I am using benchmark_tx and benchmark_rx codes in the
gnuradio-examples/python/digital folder to find packet loss for different
19 matches
Mail list logo
