> 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
>> Discuss-gnuradio@gnu.org
>> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment