[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] UHD issues on Mac
From: |
Matthias Wilhelm |
Subject: |
Re: [Discuss-gnuradio] UHD issues on Mac |
Date: |
Wed, 19 May 2010 12:22:52 +0200 |
Am 19.05.2010 um 02:51 schrieb Josh Blum:
> I had misconfigured the clocks, which would explain the problem. Can you pull
> in the latest uhd code and gnuradio gr-uhd branch. And try again?
>
> I hope that fixes it. I will be looking at daughter board code tomorrow so I
> will see what i can duplicate the problem.
>
> Thanks,
> -Josh
>
> On 05/18/2010 11:55 AM, Matthias Wilhelm wrote:
>>
>> Am 15.05.2010 um 00:02 schrieb Josh Blum:
>>
>>> I believe that i have got a few success emails with mac os. The errors dont
>>> really make sense because its just userspace udp, which clearly works
>>> because of the find devices. It may be an fpga timing issue.
>>>
>>> I just pushed a bunch of new host code, and posted images .
>>>
>>> Can you give it a try:
>>> http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries#UHD-Firmware-and-FPGA-Images
>>>
>>> Let me know, thanks!
>>> -Josh
>>>
>>> On 05/14/2010 09:54 AM, Matthias Wilhelm wrote:
>>>> 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
>>>>
>>
>>
>> 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
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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