error with sink

[bpadalino]

I noticed you have a line that says:

Code: Select all

self.osmosdr_source_0 = osmosdr.source( args="nchan=" + str(1) + " " + "" )

Do you mind passing in the args bladerf=0 to the block instead of leaving it blank?

[on4bhm]

it's the same effect. it doesn't chance the error....

[on4bhm]

more information:
here you can see it claims the interface twice!!
which is not ok!

Generating: "/home/linaro/top_block.py"

Executing: "/home/linaro/top_block.py"

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.005.003-87-g8f4000ff

Using Volk machine: generic
gr-osmosdr v0.1.0-10-g68ed1854 (0.1.1git) gnuradio 3.7.2git-0-gd19aa281
built-in source types: file fcd rtl_tcp uhd bladerf
INFO - Found a bladeRF
INFO - Claimed all inferfaces successfully
INFO - Change to alternate interface 1
INFO - Changed into RF link mode: LIBUSB_SUCCESS
Using nuand LLC bladeRF #0 SN 00cdce40c67b2fcb478847d2c1259d05WARNING - [/home/linaro/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:818] FPGA currently does not have a version number.
FPGA v0.0
Invalid LNA gain requested: 10, setting to LNA_MAX (6dB)
gr-osmosdr v0.1.0-10-g68ed1854 (0.1.1git) gnuradio 3.7.2git-0-gd19aa281
built-in sink types: uhd bladerf
INFO - Instance: 0
INFO - Found a bladeRF
ERROR - [/home/linaro/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:307] Could not claim interface 0 - LIBUSB_ERROR_BUSY

FATAL: bladerf_sink_c failed to open bladeRF device libusb:instance=0

Trying to fill up 0 missing channel(s) with null sink(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.

Traceback (most recent call last):
File "/home/linaro/top_block.py", line 95, in <module>
tb.Start(True)
File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py", line 73, in Start
self.start()
File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 103, in start
top_block_start_unlocked(self._tb, max_noutput_items)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 4402, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: resolve_port: hierarchical block 'sink_impl': input 0 is not connected internally

>>> Done

[bpadalino]

Ah, I see what you're doing now. You have a source and a sink in the same flowgraph. This is currently unsupported. Let me explain why.

It doesn't really make sense for a USB device to be talking to multiple programs at the same time. As such, libusb cannot claim ownership of the same interface twice. When the source block tries to open the interface, it's successful in doing so. When the sink block (or vice versa, depending on timing and threads) tries to do so, the interface is already opened and it can't reclaim the interface. The problem here lies in the fact that both the source and sink try to open the device.

We've known of this limitation, and the way to get around it is to create a thin layer to understand what the open interfaces are, and pass them to the appropriate requesting context handle. This can be done either in the gnuradio layer, or as a separate layer in the library. We're working with the gr-osmosdr folks on getting both source and sink to be able to appear in the same flowgraph, and figuring out which solution is the appropriate one.

Sorry for the confusion regarding your problem, but thanks for posting the other output. I'll post back here when things have been updated and it should work with both a source and a sink in the same graph.

[on4bhm]

ok thanks for the answer.
i can stop testing... and i shall wait.
any timing yet? could it be available by the end of this year?

[bpadalino]

Yes - it will definitely be done by the end of the year.