Re: UHD Announcement - April 23rd 2010

GNU Radio
1

Am 24.04.2010 um 01:31 schrieb Josh B.:

Thank you,
-Josh

Hi,

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 buffer space available

It seems that there is some problem in device::make, but I have no idea
where this error comes from. If this worked (or if it is no problem at
all), what is the easiest way to test things with the new driver
(something like usrp2_fft.py)?

Matthias

2

Error: No buffer space available

It seems that there is some problem in device::make, but I have no idea where this error comes from. If this worked (or if it is no problem at all), what is the easiest way to test things with the new driver (something like usrp2_fft.py)?

Was there more verbose after that? It looks like it crashed or threw,
trying to allocate a large buffer for the udp data socket.

I have not had a chance to test on macos/freebsd type platform. It seems
that I need to rethink that buffer resizing code.

So, the culprit code is on line 130
host/lib/transport/udp_zero_copy_asio.cpp, just remove that chunk of
code that re-sizes the buffer and see if that fixes things for you.

The equivalent of usrp_fft would be to install the gr-uhd and to connect
a UHD source to a fft sink in GRC.

Thanks for testing it, this is the first report of something working
with the hardware on the mac!
-Josh

3

Am 27.04.2010 um 18:03 schrieb Josh B.:

So, the culprit code is on line 130 host/lib/transport/udp_zero_copy_asio.cpp, just remove that chunk of code that re-sizes the buffer and see if that fixes things for you.

The equivalent of usrp_fft would be to install the gr-uhd and to connect a UHD source to a fft sink in GRC.

Thanks for testing it, this is the first report of something working with the hardware on the mac!
-Josh

Removing the line gives:

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” number, 3.75e6 is too much.

I will try some things with the driver when I’m back on friday, I still
have to sort out some wxWidgets/macports 64 bit problem to test it with
a GUI first.

Matthias

4

I will push up some new code later today: the rx buffer size and tx
buffer size will be configurable though the device address args. If not
specified, it defaults to whatever your system defaults to. Much more
sane solution I believe.

I will try some things with the driver when I’m back on friday, I still have to sort out some wxWidgets/macports 64 bit problem to test it with a GUI first.

cool

thanks,
-Josh