Source block for the funcube pro plus

Just for your information:

In imitation of the gr-fcd source I set up a gnuradio source for the
funcube pro+ ( linux only) . To avoid the crashes depending on libusb I
used the hidraw driver.

The source and an example can be found on

https://github.com/dl1ksv/gr-fcdproplus.git

Comments are welcome.
Enjoy it

Volker

Hi Volker

You Wrote:

In imitation of the gr-fcd source I set up a gnuradio source for the
funcube pro+ ( linux only) . To avoid the crashes depending on libusb I
used the hidraw driver.

The source and an example can be found on

Great, thanks for this, what version of gnuradio is it based off ?

(I’ve had a quick five minute play, and am having issues getting it to
build, but suspect its my hacked up 3.6.x plus cog tree that’s the
problem rather than your code!)

Best Regards

Iain

Hi Ian,

I tested against 3.6.4, gentoo 64 bit.
I’m not very familiar with cmake, so perhaps the cmake code may be
improved. Can you send me the error message ?

Volker

Am 28.03.2013 20:15, schrieb Iain Young, G7III:

On Thu, Mar 28, 2013 at 11:41 AM, Volker S. [email protected] wrote:

Comments are welcome.
Enjoy it

Hi Volker,

Nice work.
I would recommend letting the user specify the device string and only
use auto-detection if string is empty.

Alex

Hi Volker,

You Wrote:

I tested against 3.6.4, gentoo 64 bit.
I’m not very familiar with cmake, so perhaps the cmake code may be
improved. Can you send me the error message ?

I think it was just my set of multiple/semi broken trees of various
3.6.x branches, precog etc that was confusing cmake et al. A pristine
gnuradio build from 3.6.4, and it builds perfectly, and I can see the
new block in grc.

However, when trying to run a flow graph, I get the following:

Set Frequency to: 144700 KHz, corrected to: 144700 Khz
audio_alsa_source[plughw:1,0]: snd_pcm_hw_params failed: Input/output
error
Traceback (most recent call last):
File “/home/iain/FlowGraphs/top_block.py”, line 73, in
tb.Run(True)
File
“/opt/gnuradio-3.6.4/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py”,
line 76, in Run
self.start()
File
“/opt/gnuradio-3.6.4/lib/python2.7/dist-packages/gnuradio/gr/top_block.py”,
line 97, in start
self._tb.start(max_noutput_items)
File
“/opt/gnuradio-3.6.4/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py”,
line 3063, in start
return _gnuradio_core_runtime.gr_top_block_sptr_start(self,
max_noutput_items)
RuntimeError: check topology failed on audio_alsa_source(11) using
ninputs=0, noutputs=2

Curiously, I got similar error when a few months ago I tried to use
the FCDPP just as a raw ALSA device, so I guess the error is truly
within the ALSA subsystem rather than your code, but any ideas ?

73s

Iain

Hi Alex,

thank you for your hint. I added the device_name parameter .
Now if the device name is not empty, I try to open the appropriate alsa
device. If the device string is empty or opening device failed ( perhaps
the device string was misspelled ) I try to autodetect the dongle.

I personally prefer autodetection, as the order of my soundcards may
change from boot to boot. So I attach a small patch for gr-fcd to enable
autodetection, too.

Volker

Am 01.04.2013 00:29, schrieb Alexandru C.:

Hi Ian,

is the funcube dongle block connected to a selector block ? If I
remember well , I saw such a much some years ago when somebody tried to
switch between alsa- sources.

So it would be helpfull to know the connection diagram at this poit.
vy 73, de Volker

Am 01.04.2013 16:42, schrieb Iain Young, G7III:

Hi Ian,

it’s no problem for me to change the code to set the frequency in Hz
instead of Khz because internally I set the frequency in Hz.
But what do you think about introducing an additional unit parameter (
1, 1000, 1000000 ). So it would be up to the users choice and if you
choose 1 you had the same behavior as the FCD.

Volker

Am 01.04.2013 16:48, schrieb Iain Young, G7III:

On 31/03/13 23:29, Alexandru C. wrote:

Comments are welcome.
Enjoy it

Hi Volker,

Nice work.

Agreed, Very appreciated work as well.

I would recommend letting the user specify the device string and only
use auto-detection if string is empty.

I agree here, but would also add one more request. Specify the
frequency in Hz, kHz is a pain to convert in the head, and Hz can be
bad enough by itself!

(You would not believe the number of times my flowgraphs have ended up
on 1.4GHz rather than 144MHz…)

Other similar blocks (eg UHD, FCD) also specify in Hz, and it would be
good to have compatibility, if only to let me switch between inputs
with a selector block, and not needing a /1000 variable in there as
well :slight_smile:

73s

Iain

On Tue, Apr 2, 2013 at 11:39 AM, Volker S. [email protected] wrote:

Hi Alex,

thank you for your hint. I added the device_name parameter .
Now if the device name is not empty, I try to open the appropriate alsa
device. If the device string is empty or opening device failed ( perhaps the
device string was misspelled ) I try to autodetect the dongle.

I personally prefer autodetection, as the order of my soundcards may change
from boot to boot. So I attach a small patch for gr-fcd to enable
autodetection, too.

Thanks for the patch. Unfortunately, it is not sufficient for gr-fcd
because it must also work on BSD, Windows and OS X. As such no ALSA or
linux specific code should be in the gr-fcd block itself.

In my opinion, updates should be made in gr-audio. We need a new API
call that returns a list of available audio devices with their
descriptive names. That way we can implement autodetection in a
platform independent way.

Alex

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs