osmosdr: Failure to send samples.

[ghost]

When I run the osmosdr-siggen program it appears to properly configure the FPGA and lime chip for the Carrier requested in the GUI. The TX Gain adjusts seems to be working as well. But I can't seem to get samples into the modulator. my /dev/bladerf0 file is mode 666

running osmosdr-siggen user@host $ ./osmosdr-siggen

In the console I get: Failed to write samples: provided parameters where out of allowable range.

When I change the carrier frequency, the bladeRF responses. On my spectrum analyzer I can see the TX carrier (LO leakage) move.

But can't get any samples though...

Stopping the osmosdr-siggen causes the LO on the lime chip to disappear. Chip deactivate, as expected result.

Sometimes after running it and start osmosdr-siggen up again. I get the dreaded "Bladerf_enable_module has returned with -6"

Which I think means the board got stuck..
Doesn't go away until I power cycle the bladeRF.

I am using the lastest bladeRF GIT (as of 8/2/2013 00:53:00 UTC ) and the latest osmosdr git head. Running ubuntu-13.04 linux-3.8 kernel.

[jsmnsr]

So I am getting a very similar error except on the read side.

jsmnsr@ubuntu:~/erepo/gqrx$ osmocom_fft linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-121-gaa5e5d23

gr-osmosdr v0.1.0-7-g9dfe3a63 (0.1.1git) gnuradio v3.7.0-82-g179a2d78 built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf Using nuand LLC bladeRF #0 SN 0000000000000000 FW v1.0 FPGA v0.0 Failed to read samples: File or device I/O failure Using Volk machine: avx_64_mmx_orc

A power cycle does NOT fix this issue.

I am using the same bladeRF and osmosdr head. I am, however, running the 3.5 kernel

Read through the CLI seems to work fine.

[jsmnsr]

My issue appears to be fixed in the latest commit

[jynik]

jsmnsr - thanks for confirming! :)

biovore - based upon the date you listed, it looks like I pushed a driver change just after your last pull? Could you verify whether or not you're still seeing this as of: 465b96e7999a96d2d845a0e838628b5334c3e6fd

    linux_driver: Increased periperhal access timeout

    This value was previously set to 1 ms, which is currently too
    small for the required window of time (even with 3 retries) to
    receive a response from the FPGA.

If you could kindly let me know your situation, we might be able to mark this closed. If by chance you continue to see issues, could you try sprinkling some dev_err() / prinkt() calls wherever you see -ETIMEDOUT conditions or functions that time out (e.g., usb_bulk_msg()) -- this would hopefully give us another clue or two.

Thanks folks!

[ghost]

Lastest head now just gives connection timeout error=110. Happens for TX and RX with osmocom tools. See forums for system setup and install procedures used.. http://forums.nuand.com/forums/viewtopic.php?f=9&t=2804

I have talk to several other folks on IRC that are experiencing the same problem..

[jynik]

I didn't haven't seem these timeouts since 465b96e. Just tested via rx'ing & tx'ing in the CLI, osmo_fft, and osmo_siggen (with a 5MHz sample rate.)

Confirmed that there's sometimes a conjugate when transmitting. This came and went when closing and restarting osmo_siggen.

FX3 Image: http://www.nuand.com/~bpadalino/bladeRF.img FX3 Image MD5sum: 34c158b08f89f7cec614f2fc603f0e6b FPGA: x40 image from 2012-07-16 (http://nuand.com/fpga/)

[ghost]

Those where the magic spice needed here.. Appears to be working now..

output seems to be dropping some samples still.. But thats probably a hole other problem.