discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] UHD Announcement - April 23rd 2010


From: Matthias Wilhelm
Subject: Re: [Discuss-gnuradio] UHD Announcement - April 23rd 2010
Date: Tue, 27 Apr 2010 21:03:20 +0200

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
>>> --------------------------------------------------
>>> 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)?
>> 
> 
> 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
> 

Removing the line gives:
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> name: USRP2
> addr: 192.168.10.2
> 
> 
> 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" 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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]