The usrp / gr-usrp hacking continues...
If you're tracking CVS, please update usrp and gr-usrp.
Prior to building usrp, you'll probably want to do a
"rm -fr PREFIX/share/usrp" to avoid possible confusion down the road.
I've added provisions that allow code to specify the
firmware and fpga files
On Sat, Feb 18, 2006 at 06:10:41PM -0500, Clark Pope wrote:
> In rx_buffer.v I see the 8-bit transfer mode but it only seems to me that
> it allows doubling the number of channels transferred not doubling the rate
> on the two channels? I want to get 16 MHz bandwidth into my PC. I am able
> to r
In rx_buffer.v I see the 8-bit transfer mode but it only seems to me that it
allows doubling the number of channels transferred not doubling the rate on
the two channels? I want to get 16 MHz bandwidth into my PC. I am able to
run 8 MHz, 16-bit I/Q fine in usrp_fft.py so I figured I should be ab
On 2/18/06, Jovan Mostanovski <[EMAIL PROTECTED]> wrote:
> Michael, thanks for the link. I've checked that out, and I think it's a
> good idea that I get an amateur radio licence, as the frequencies that I
> require for long distance communications (~2 - 30Mhz)
Sounds good.
> that I need the main
Hi folks,
I've been hacking away in usrp and gr-usrp.
I've removed a bunch of old cruft that was left over from rev 0 and
rev 1 boards. Don't worry, none of you have any of these.
I've also added support for serial numbers on the usrp motherboards.
By default, all existing boards now look they
On Fri, Feb 17, 2006 at 11:35:25AM +0100, Stephane Fillod wrote:
> On Thu, Feb 16, 2006 at 07:17:08PM -0800, Eric Blossom wrote:
> > Hi Martin,
> >
> > I added gr_int64 and gr_uint64 to gr_types.h.
> > I continued the "unsafe practice" pending a proper config fix.
>
> Tedious is the word for the
