UHD issues on Mac

GNU Radio
1

Hi,

I’m currently trying the UHD driver on my macbook pro, with still very
limited success. I have the newest git version of uhd and gr-uhd,
checked out today.

$ uhd_find_devices

– UHD Device 0

name: USRP2
addr: 192.168.10.2

which is good, but actually using a simple_source crashes in interesting
ways.

When calling
u = uhd.simple_source(“addr=192.168.10.2, recv_buff_size=3.5e6”,
uhd.io_type_t.COMPLEX_FLOAT32)
or
u = uhd.simple_source(“addr=192.168.10.2”,
uhd.io_type_t.COMPLEX_FLOAT32)

I get the following:

terminate called after throwing an instance of ‘std::runtime_error’
what(): No devices found for ----->
addr: 192.168.10.2
recv_buff_size: 3.5e6 ## nothing here with second version

Abort trap

The attached log file is crash-all.log.

Just calling
u = uhd.simple_source("", uhd.io_type_t.COMPLEX_FLOAT32)

Gives:

terminate called after throwing an instance of ‘std::runtime_error’
what(): usrp2 no control response
Abort trap

with log file in crash-none.log.

After each of the crashes, the uhd_find_devices still finds my USRP2, so
the firmware/FPGA is still running strong. Pinging 192.168.10.2 results
in request timeouts for icmp_seq. The firewall is turned off.

Am I getting it wrong here, how should the driver be used? Or are there
some Mac-specific issues?

Thanks,
Matthias

2

Am 15.05.2010 um 00:02 schrieb Josh B.:

Hi,
which is good, but actually using a simple_source crashes in interesting ways.

recv_buff_size: 3.5e6 ## nothing here with second version
terminate called after throwing an instance of ‘std::runtime_error’
Matthias

Hi,

its working on the Mac and Linux with the new firmware and FPGA code, i
can generate a simple_source object now! But the samples I get don’t
seem right.

I’m using the XCRV2450 dboard, it says RX 0x0061 and TX 0x0060. With the
raw ethernet chain, I can receive WLAN signals, but with the UHD driver
I see only noise, something very low in the FFT sink (around -110dB), no
matter what gain or antenna ("", J1 or J2) I set. Its the same issue on
Mac and Linux platforms.

But it seems that its almost working now…
Matthias

3

Am 19.05.2010 um 02:51 schrieb Josh B.:

Hi,
which is good, but actually using a simple_source crashes in interesting ways.

recv_buff_size: 3.5e6 ## nothing here with second version
terminate called after throwing an instance of ‘std::runtime_error’
Matthias
Matthias

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Hello,

it’s working with the new code, I see signals flying around now.

New problem (unfortunately):
The fft sink freezes after some time, depending on the
decimation/sampling rate:
decim 4: after about 12 secs
decim 8: ~30 secs
decim 16: ~60 secs

Killing the python program and restarting it works directly, so maybe
something is not cleaned up properly on the host side. I used
recv_buff_size=50e6 and the Linux default values, both freeze after the
same time.

Matthias