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