Hello list,
---
-- Tagged a 3.4.0 release
---
A 3.4.0 release has been tagged. Its been a long time coming since the
last release. 3.4.0 contains the new features
Hello list,
A bunch of great work has been merged into the master. For those
following the work on the master branch, and not a release, you will
need to update your firmware and FPGA images:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Binary-downloads
http://files.ettus.com/uhd_release
Hello list,
Recall from my previous announcements that addition of correction
registers and API for DC offset and IQ balance. Well, now you can use
special calibration utilities that come with UHD to improve RF
performance for WBX and SBX better than the out of the box specs.
So, I just merged th
Hello list,
A bunch of great work has been merged into the master. For those
following the work on the master branch, and not a release, you will
need to update your firmware and FPGA images:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Binary-downloads
http://files.ettus.com/uhd_release
On Thu, Jul 28, 2011 at 21:34, Josh Blum wrote:
> Due to FPGA bug fixes, users following the work on the master branch,
> will need to upgrade firmware and FPGA images for USRP2 and N-Series
> products. Install the latest host code and follow the instructions to
> load images: http://www.ettus.c
Hello list,
A release 3.2.0 has been tagged. This release is the combined work from
last weeks merge announcement + some fixes.
http://code.ettus.com/redmine/ettus/projects/uhd/repository/show?rev=release_003_002_000
This change log entry details the changes between this and the last
release:
htt
On Sat, 2011-07-23 at 18:55 +0100, Nemanja Trecakov wrote:
> There are two more things I am not clear with.
>
> > >
> > > I understand that the FPGA and firmware images have to be updated,
> i.e. the newest images downloaded and "flashed" on the SD card in case
> of USRP2.
> > > However, since th
There are two more things I am not clear with.
> >
> > I understand that the FPGA and firmware images have to be updated, i.e. the
> > newest images downloaded and "flashed" on the SD card in case of USRP2.
> > However, since the source code is new too, should I rebuild and reinstall
> > the U
>
> I understand that the FPGA and firmware images have to be updated, i.e. the
> newest images downloaded and "flashed" on the SD card in case of USRP2.
> However, since the source code is new too, should I rebuild and reinstall the
> UHD from the new source?
>
The host code and images must
Hi Josh,
I am a newbie and have some questions regarding the UHD announcement.
> Date: Tue, 19 Jul 2011 22:43:13 -0700
> From: j...@ettus.com
> To: usrp-us...@lists.ettus.com; Discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] UHD Announcement - July 19th 2011
>
> Hello
Hello list,
I have pulled work from the next branch into the master. If you are
working from the code in the master branch, you will need to update your
FPGA images. In the case of E100 users, this will also require a kernel
uImage and kernel modules update.
FPGA and firmware images for the maste
Hello list,
---
-- Tagged releases and binary installers
---
For the past month or so we have been tagging uhd releases and providing
binary installers for those
Hello list,
As promised, we have official releases for UHD and binary installers.
http://code.ettus.com/redmine/ettus/projects/uhd/wiki
---
-- Binary installers
---
Hello list,
New code has been pushed to master and new images have been uploaded.
This effects USRP2, USRP-N210, and USRP-E100.
http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/
E100 Users: expect a follow-up announcement for an updated kernel and
instructions.
--
Hello list,
In preparation for the coming gnuradio release, and the cut-over from
next to master, changes have been pushed to both the uhd.git master
branch and the gnuradio.git next branch.
http://code.ettus.com/redmine/ettus/projects/uhd/wiki
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/20/2011 09:05 AM, Josh Blum wrote:
> [...] UHD will build and run under the clang compiler.
Cool stuff! Thanks Josh :-)
Cheers,
Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJNN/UPAAoJEOjnDXL6I0uZRqcP/1
Hello list,
The UHD work in the next branch has been merged into the master. These
changes include new FPGA and firmware images, changes uhd host code, and
changes to gnuradio gr-uhd.
-
-- FPGA and firmware images
-
N
Hey Josh,
thanks a lot. Now it works.
I'll try to implement algorithms soon.
But this should be a first step.
Am 14.12.2010 01:34, schrieb Josh Blum:
Hello list,
I would like to announce support for the MIMO cable with UHD. The
support is experimental, so its not in the mainline yet, and is on
On 12/13/2010 05:28 PM, Josh Blum wrote:
>
>
> On 12/13/2010 05:04 PM, b...@sigmatix.com wrote:
>> Josh,
>>
>> This is great!
>>
>> Although it goes without saying, I'm assuming users should also need
>> to keep in mind that there's no magic going on here w.r.t. gigE
>> bandwidth (i.e., one U2
On 12/13/2010 05:04 PM, b...@sigmatix.com wrote:
> Josh,
>
> This is great!
>
> Although it goes without saying, I'm assuming users should also need
> to keep in mind that there's no magic going on here w.r.t. gigE
> bandwidth (i.e., one U2 running "wide open" can pretty much consume
> an entir
t 2 U2's sharing a single connection each one (on average) should be
run at no more than 1/2 max bandwidth). right?
--Bob
>-Original Message-
>From: Josh Blum [mailto:j...@joshknows.com]
>Sent: Monday, December 13, 2010 07:34 PM
>To: Discuss-gnuradio@gnu.org, usrp-us...@l
Hello list,
I would like to announce support for the MIMO cable with UHD. The
support is experimental, so its not in the mainline yet, and is only
available for USRP2 at the moment.
The source for the FPGA code has not yet been pushed but you can get the
pre-built images here:
http://www.ettus.co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/24/2010 07:11 PM, Josh Blum wrote:
> I believe that that UHD was missing a case for the the revision number
> in your usrp2 (possibly 3.1) and was falling through to a register map
> intended for the USRP-N210. Can you pull the latest host code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/24/2010 05:45 PM, Matt Ettus wrote:
The working one is revision 3.0 // serial number 149. The one that's not
responding is a revision 3.01 // serial number 186.
Sorry for not including this information ;-) Looking back now I feel
kind of stupid
I believe that that UHD was missing a case for the the revision number
in your usrp2 (possibly 3.1) and was falling through to a register map
intended for the USRP-N210. Can you pull the latest host code (just
updated) and try again?
Thanks,
-Josh
On 11/24/2010 08:23 AM, Moritz Fischer wrote:
On 11/24/2010 08:23 AM, Moritz Fischer wrote:
When putting the current images on the first one, it works just fine!
Now if I use the *same* SD-card in the *other* USRP2 I get an odd response:
What are the serial numbers of the two USRP2s?
Matt
___
D
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/24/2010 04:24 AM, Josh Blum wrote:
> -- Feedback is welcome!
Hi list,
first of all thanks Josh for the great work. Now for the feedback part:
While playing around with our USRP2s I noticed some odd behavior with
the new fw/fpga images.
My se
On Tue, Nov 23, 2010 at 10:24 PM, Josh Blum wrote:
> Hello list,
>
> Much code has been pushed and new images uploaded.
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki
>
> ---
> -- Support for new devices
> ---
Hello list,
Much code has been pushed and new images uploaded.
http://code.ettus.com/redmine/ettus/projects/uhd/wiki
---
-- Support for new devices
---
Host cod
Hello list,
This is the flow-control announcement :-)
http://code.ettus.com/redmine/ettus/projects/uhd/wiki
---
USRP2 flow-control
---
Its not yet in the master
> Hello list,
>
> I would like to announce additional daughterboard support and API
> changes in regards to the UHD. As of this announcement, all Ettus
> hardware is supported under UHD.
>
> ---
> Daughter board features and suppor
Hello list,
I would like to announce additional daughterboard support and API
changes in regards to the UHD. As of this announcement, all Ettus
hardware is supported under UHD.
---
Daughter board features and support
On Sun, Sep 26, 2010 at 09:40:58AM -0400, Tom Rondeau wrote:
> On Sat, Sep 25, 2010 at 6:23 PM, Josh Blum wrote:
> >
> >>
> >> I agree with you it's not exactly right.
> >>
> >> I'm not sure about the right action.
> >>
> >> This issue should probably go onto the list of things to be considered
>
On Sat, Sep 25, 2010 at 6:23 PM, Josh Blum wrote:
>
>>
>> I agree with you it's not exactly right.
>>
>> I'm not sure about the right action.
>>
>> This issue should probably go onto the list of things to be considered
>> in the grand build restructuring that was discussed by some of us a
>> coupl
I agree with you it's not exactly right.
I'm not sure about the right action.
This issue should probably go onto the list of things to be considered
in the grand build restructuring that was discussed by some of us a
couple of weeks ago.
Autotools is trying to be helpful by setting the "un
On Sat, Sep 25, 2010 at 12:32:36PM -0700, Josh Blum wrote:
>
> >Fair enough, Eric. So do you suggest another approach that allows
> >boostrap/configure/make to "just work", or simply more notes
> > about this in the build instructions when you're using UHD?
> >
> >
>
> The issue being that all
On Sat, Sep 25, 2010 at 12:23:19PM -0700, Josh Blum wrote:
>
>
> On 09/25/2010 12:01 PM, Eric Blossom wrote:
> >On Sat, Sep 25, 2010 at 10:24:18AM -0700, Josh Blum wrote:
> >>This turns out to be a bug in gnuradio configure - when --prefix is
> >>not specified with ./configure, the ${prefix} var
Fair enough, Eric. So do you suggest another approach that allows
boostrap/configure/make to "just work", or simply more notes
about this in the build instructions when you're using UHD?
The issue being that all the gnuradio dependencies are distribution
installable (on linux) so you do
On 09/25/2010 12:01 PM, Eric Blossom wrote:
On Sat, Sep 25, 2010 at 10:24:18AM -0700, Josh Blum wrote:
This turns out to be a bug in gnuradio configure - when --prefix is
not specified with ./configure, the ${prefix} variable is set to
NONE
Listen guys, you may not like this behavior, but i
On Sat, Sep 25, 2010 at 03:09:47PM -0400, Marcus D. Leech wrote:
> >
> > There definitely shouldn't be any PKG_CONFIG_PATH special case
> > handling for anything in grc_.m4.
> >
> > A ton of effort was put into making the building system work reliably
> > and consistently (mostly by Michael Dickens
>
> There definitely shouldn't be any PKG_CONFIG_PATH special case
> handling for anything in grc_.m4.
>
> A ton of effort was put into making the building system work reliably
> and consistently (mostly by Michael Dickens). A lot of the details
> are quite subtle, and the effort took a long time
On Sat, Sep 25, 2010 at 10:24:18AM -0700, Josh Blum wrote:
> This turns out to be a bug in gnuradio configure - when --prefix is
> not specified with ./configure, the ${prefix} variable is set to
> NONE
Listen guys, you may not like this behavior, but it's not a bug.
If you read the makefile stan
This turns out to be a bug in gnuradio configure - when --prefix is not
specified with ./configure, the ${prefix} variable is set to NONE
http://www.mail-archive.com/autoc...@gnu.org/msg15772.html
The following code with yeild a PKG_CONFIG_PATH of NONE/lib/pkgconfig
dnl add ${prefix}/lib${gr
>
>
>
> The problem being that /usr/local/lib/pkgconfig isnt honoring the
> users prefix and possibly libdir. Perhaps we can still make this
> right... Does this patch work for you?
>
> -Josh
>
Still no worky. Must set PKG_CONFIG_PATH manually. I confirmed that
the patch had been applied to the
On 09/24/2010 10:18 PM, Marcus D. Leech wrote:
http://gnuradio.org/cgit/gnuradio.git/commit/?h=next&id=71c193ad5380829e20af533ed89903d8d7abcd2c
-Josh
Ok, so all Eric's fault :-)
The problem being that /usr/local/lib/pkgconfig isnt honoring the users
prefix and possibly libdir. Perhaps
On 09/24/2010 10:18 PM, Marcus D. Leech wrote:
http://gnuradio.org/cgit/gnuradio.git/commit/?h=next&id=71c193ad5380829e20af533ed89903d8d7abcd2c
-Josh
Ok, so all Eric's fault :-)
So, since the "let's be nice and add /usr/local/lib to PKG_CONFIG_PATH"
code got removed from the .m4 file, so
>
>
> http://gnuradio.org/cgit/gnuradio.git/commit/?h=next&id=71c193ad5380829e20af533ed89903d8d7abcd2c
>
>
> -Josh
>
Ok, so all Eric's fault :-)
So, since the "let's be nice and add /usr/local/lib to PKG_CONFIG_PATH"
code got removed from the .m4 file, so perhaps a note
needs to be added to the
OK, so I just updated a two-weeks-old gnuradio and uhd via GIT, and
while UHD builds properly and installs correctly, gnuradio
can't find "uhd" when it goes to do a configure, because pkg-config
can't find "uhd"--and therefore doesn't build "gr-uhd".
This is a change from circa two weeks a
> Hello List,
>
> I have pushed a bunch of code to the uhd repo and gnuradio next branch.
> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
>
> -
> USRP1 multi-channel support has been completed. Multiple chann
Hello List,
I have pushed a bunch of code to the uhd repo and gnuradio next branch.
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
-
USRP1 multi-channel support has been completed. Multiple channels can be
On 08/31/2010 07:08 PM, Marcus D. Leech wrote:
On 08/31/2010 10:01 PM, Josh Blum wrote:
Hello list,
USRP1 support is now part of the UHD. Fetch the latest host code and
images: http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
I take it then, that USRP1 under UHD doesn't requir
On 08/31/2010 10:01 PM, Josh Blum wrote:
Hello list,
USRP1 support is now part of the UHD. Fetch the latest host code and
images: http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
I take it then, that USRP1 under UHD doesn't require new firmware on the
USRP1?
--
Marcus Leec
Hello list,
USRP1 support is now part of the UHD. Fetch the latest host code and
images: http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
---
Firmware and FPGA images:
You can get the most recent pre-compiled
Hello list,
I have pushed up new host code to the repo, and uploaded new images. So
what new since the last announcement?
---
1) Subdev specification:
A daughterboard may have more than one rf pathway on it. These pathways,
Hi Josh,
Just a quick note. I don't use ctrl+c to kill the graph. Instead I use the
kill button ( or F7).. Thanks again for the info provided.
Regards,
Zohair
Josh Blum-2 wrote:
>
>
>> It's working now! I changed it to 50ms instead of 10 and added the lines
>> in
>> the synchronisation for l
It's working now! I changed it to 50ms instead of 10 and added the lines in
the synchronisation for loop in mimo_usrp.cpp to see the amount of deviation
between usrps if they are synchronised:
float diff=(time_i.get_real_secs() - time_0.get_real_secs())*1000;
std::cerr<< boost::format("Time wa
sue
>>>>> with the configuration. In the following example, I disconnected the
>>>>> PPS
>>>>> on one of the boards. This is the result:
>>>>>
>>>>> Set time with unknown pps edge:
>>>>>1) set times ne
the MIMO block and
got
it working/not working.
Best regards,
zohair
Date: Fri, 9 Jul 2010 09:18:24 -0700
From: j...@joshknows.com
To: zohair...@hotmail.com
CC: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010
3) set times next pps (synchronously)
g
ext pps (synchronously)
>>>> Error: time deviation between board 1 and board 0.
>>>> Board 0 time is 0.008782 seconds.
>>>> Board 1 time is 65.009945 seconds.
>>>>
>>>> gr_block_executor: source produced no
>>>> outp
;>>
>>>>
>>>> Dear Josh,
>>>>
>>>> Thanks for the info provided and the help.
>>>>
>>>> I
>>>> have 4 USRP2 boards, 2 separate function generators and 2 splitters to
>>>> supply PPS and REF clock with specs as in the FAQ
: Fri, 9 Jul 2010 09:18:24 -0700
From: j...@joshknows.com
To: zohair...@hotmail.com
CC: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010
3) set times next pps (synchronously)
gr_block_executor: source produced no
output. We're marking it DONE.
T
n't
>> lucky enough to get something working.
>>
>> I am also interested to know if anybody has tried the MIMO block and got
>> it working/not working.
>>
>> Best regards,
>> zohair
>>
>>
>>
>>
>>> Date: Fri, 9 Jul 2010 09:18:24
ubject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010
3) set times next pps (synchronously)
gr_block_executor: source produced no
output. We're marking it DONE.
This tells me that the alignment buffer is not finding a common
timestamp among the 4 channels or one or more channels i
gards,
zohair
> Date: Fri, 9 Jul 2010 09:18:24 -0700
> From: j...@joshknows.com
> To: zohair...@hotmail.com
> CC: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010
>
>
> > 3) set times next pps (synchronously)
> >
3) set times next pps (synchronously)
gr_block_executor: source produced no
output. We're marking it DONE.
This tells me that the alignment buffer is not finding a common
timestamp among the 4 channels or one or more channels is not streaming
(perhaps a timestamp/setup issue). What does yo
e/uhd/host/lib/usrp/usrp2/io_impl.cpp:97
Waiting for reply. By the way, thank you for modifying the online manual :)
Best regards,
Zohair
Date: Thu, 8 Jul 2010 10:13:52 -0700
From: j...@joshknows.com
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 20
rsday, July 08, 2010 12:16 PM
To: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010
Dear Josh,
I have successfully installed the UHD branch from jblum.git repo and have
tried out using the MIMO sources available. I have a few points to raise
here regarding thi
Zohair,
1- I am using a PC with four Ethernet ports. I burned the firmware and the
fpga images created on 6-7-2010. Also, I tried assigning IP addresses from
the same subnetwork: 192.168.10.X/24. However, Only a single USRP2 is
discovered at a time while others are unreachable. (USRP2s IPs are
Regarding my post below, I have traced back the error and came to a result
that the error is occurring in device.cpp file. This line in the catch block
throws an error:
device::sptr dev = maker(dev_addr);
I beleive there is something wrong in : Arg: addr=192.168.10.11
192.168.20.11 192.168
ubject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010
Dear Josh,
I have successfully installed the UHD branch from jblum.git repo and have
tried out using the MIMO sources available. I have a few points to raise
here regarding this release and block:
1- I am using a PC with four Ethernet
Dear Josh,
I have successfully installed the UHD branch from jblum.git repo and have
tried out using the MIMO sources available. I have a few points to raise
here regarding this release and block:
1- I am using a PC with four Ethernet ports. I burned the firmware and the
fpga images created on 6-
Excellent - I look forward to trying this out. In particular I'm very
happy to see the get_time_now() functionality, which it looks like
made it into the simple_usrp class as well. That is a very nice
addition since it enables exactly the sort of thing you've already
done with set_time_unknown_pps:
Hello all,
MIMO capabilities have just been added to the UHD. With N gigE ports and
N USRP2s, one can perform synchronous aligned receives.
A usrp_mimo class has been added to the UHD for construction of a mimo
enabled device configuration. And I have added the corresponding
gnuradio blocks:
There have been many changes to the uhd since the last announcement.
* Support for all daughter boards except dbsrx and txrx. The dbsrx
support is coming soon.
* Send and recv modes to control how the driver deals with packets and
buffers: http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1
On Tue, Apr 27, 2010 at 01:55:55PM -0700, Sam Bretheim wrote:
> Marcus D. Leech wrote:
> >On 04/26/2010 05:16 PM, Josh Blum wrote:
> >> The rx and tx data packets are samples encapsulated in vrt headers for
> >> IF data: http://www.digitalif.org/
> >Gosh. Too bad they want for a copy of the s
Marcus D. Leech wrote:
On 04/26/2010 05:16 PM, Josh Blum wrote:
> The rx and tx data packets are samples encapsulated in vrt headers for
> IF data: http://www.digitalif.org/
Gosh. Too bad they want for a copy of the standard. Bleerg.
As long as you don't mind using a draft version of
Current rx socket buffer size: 42080
Adjust max rx socket buffer size (linux only):
sysctl -w net.core.rmem_max=VALUE
Using: XCVR2450 RX (0x0061)
Using: XCVR2450 TX (0x0060)
I tried some different values in
set_recv_buff_size(size_t(xxx)); //some big number!,
3.7e6 still works as the "big"
Am 27.04.2010 um 18:03 schrieb Josh Blum:
>
>>
>> I would really like to use the USRP2 with my MacBook. My first test with the
>> driver yields the following result:
>>
>>> $ uhd_find_devices
>>> --
>>> -- UHD Device 0
>>> --
I would really like to use the USRP2 with my MacBook. My first test with the
driver yields the following result:
$ uhd_find_devices
--
-- UHD Device 0
--
name: USRP2
addr: 192.168.10.2
Error: No
Am 24.04.2010 um 01:31 schrieb Josh Blum:
> XCVR2450 and RFX series boards are now supported in the UHD.
>
> Here is the link to the wiki and manual that I have been working on:
> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
>
> The microblaze firmware has changed since the p
On 04/26/2010 05:16 PM, Josh Blum wrote:
> The rx and tx data packets are samples encapsulated in vrt headers for
> IF data: http://www.digitalif.org/
Gosh. Too bad they want for a copy of the standard. Bleerg.
>
> The control protocol is just a bunch of enums and structs in a header
> shar
The rx and tx data packets are samples encapsulated in vrt headers for
IF data: http://www.digitalif.org/
The control protocol is just a bunch of enums and structs in a header
shared by firmware and host:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/master/e
On Mon, Apr 26, 2010 at 4:44 PM, Josh Blum wrote:
> When no address is specified, the find devices will send a broadcast udp
> packet to each interface. I experienced identical behavior on a fedora 11
> box because the firewall was interfering with broadcast packets. After
> turning off the firewa
On Mon, Apr 26, 2010 at 4:47 PM, Marcus D. Leech wrote:
> I can confirm that after a couple of bits of finger-trouble on my part,
> I built both UHD, and GR-UHD, and
> was able to install 'em both. I don't have a USRP2 to do tests, but at
> least the build went well.
>
> If there's a succinct pr
I can confirm that after a couple of bits of finger-trouble on my part,
I built both UHD, and GR-UHD, and
was able to install 'em both. I don't have a USRP2 to do tests, but at
least the build went well.
If there's a succinct protocol description out there for UHD-over-UDP
I'd start work on a W
When no address is specified, the find devices will send a broadcast udp
packet to each interface. I experienced identical behavior on a fedora
11 box because the firewall was interfering with broadcast packets.
After turning off the firewall with system-config-firewall, the find
devices worked
On Mon, Apr 26, 2010 at 3:57 PM, Josh Blum wrote:
> That seems odd, it shouldnt be able to make a device without finding it
> first. That is if nothing comes up for ::find, then the ::make will yell at
> you.
>
> Is this problem repeatable, if you repeatedly call uhd_find_devices, will it
> contin
That seems odd, it shouldnt be able to make a device without finding it
first. That is if nothing comes up for ::find, then the ::make will yell
at you.
Is this problem repeatable, if you repeatedly call uhd_find_devices,
will it continue to come up blank?
-Josh
To follow up: it appears th
That does look a bit suspicious. I have two suggestions:
1) if its a firewall issue, make sure that the linux firewall is off
2) if its a timeout issue edit the udp_simple.cpp and change
milliseconds(100) to something larger, say 1000
-Josh
On 04/26/2010 12:13 PM, Douglas Geiger wrote:
O
On Mon, Apr 26, 2010 at 3:13 PM, Douglas Geiger
wrote:
> Josh,
> Trying it out on one of my USRP2's here, with an RFX2400. The build
> went well: libuhd, firmware and fpga images all built fine. And
> building the gr-uhd branch of gnuradio had no problems either,
> although I haven't gotten to t
On Fri, Apr 23, 2010 at 7:31 PM, Josh Blum wrote:
> XCVR2450 and RFX series boards are now supported in the UHD.
>
> Here is the link to the wiki and manual that I have been working on:
> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
>
> The microblaze firmware has changed since
XCVR2450 and RFX series boards are now supported in the UHD.
Here is the link to the wiki and manual that I have been working on:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
The microblaze firmware has changed since the previous announcement.
Download the most recent builds
Very exciting! Thanks Josh!
I'm off to build and test. Couple quick questions:
* Are you still basing the fpga build around Xilinx 10.1? If so - any
plans to move to/test with later versions?
We have no immediate plans because 10.1 is stable and working. Perhaps
the next ISE service pack wi
On Thu, Apr 15, 2010 at 5:11 PM, Josh Blum wrote:
> Hello List,
>
> I said that we would release some uhd code on the 15th of April (2010). So
> here it is...
> git clone git://ettus.sourcerepo.com/ettus/uhd.git
> The UHD source tree comes with firmware, fpga, and host code.
Very exciting! Thanks
Hello List,
I said that we would release some uhd code on the 15th of April (2010).
So here it is...
git clone git://ettus.sourcerepo.com/ettus/uhd.git
The UHD source tree comes with firmware, fpga, and host code.
For those of you who are not familiar. The UHD is the universal hardware
driver
95 matches
Mail list logo
