gqrx not detecting Funcube Dongle Pro +

[Calum]

Hello all,

I've just received my Funcube Dongle Pro + (yay!), and I'm trying to get it to work with gqrx.
gqrx runs fine, but only offers me the following device choices:
 RFSPACE SDR-IQ Receiver
 RFSPACE SDR-IP Receiver
 RFSPACE NetSDR Receiver
 RTL-SDR Spectrum Server
 Complex Sampled (ID) File
 Other

I'm running CentOS 6.6.
I compiled and installed (in order):

gnuradio
gr-fcdproplus
gr-osmosdr
and finally gqrx.

gqrx is linked with libgnuradio-fcdproplus

$ ldd /usr/local/bin/gqrx | grep fcd
    libgnuradio-fcdproplus.so.0 => /usr/local/lib64/libgnuradio-fcdproplus.so.0 (0x00007f8a9084a000)

/usr/local/lib64/libgnuradio-fcdproplus.so.0 is linked with correct-looking libraries - gnuradio, volk, boost, etc.

Inserting the dongle causes:

Aug 13 11:08:44 host kernel: usb 6-1: new full speed USB device number 4 using uhci_hcd
Aug 13 11:08:44 host kernel: usb 6-1: New USB device found, idVendor=04d8, idProduct=fb31
Aug 13 11:08:44 host kernel: usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Aug 13 11:08:44 host kernel: usb 6-1: Product: FUNcube Dongle V2.0 
Aug 13 11:08:44 host kernel: usb 6-1: Manufacturer: Hanlincrest Ltd.        
Aug 13 11:08:44 host kernel: usb 6-1: configuration #1 chosen from 1 choice
Aug 13 11:08:44 host kernel: 4:1:1: cannot get freq at ep 0x81
Aug 13 11:08:44 host kernel: generic-usb 0003:04D8:FB31.0003: hiddev96,hidraw0: USB HID v1.11 Device [Hanlincrest Ltd.          FUNcube Dongle V2.0  ] on usb-0000:00:1d.0-1/input2
Aug 13 11:08:44 host kernel: 4:1:1: cannot get freq at ep 0x81
Aug 13 11:08:44 host kernel: 4:1:1: cannot get freq at ep 0x81
Aug 13 11:08:44 host kernel: 4:1:1: cannot get freq at ep 0x81
Aug 13 11:08:44 host kernel: 4:1:1: cannot get freq at ep 0x81
Aug 13 11:08:44 host rtkit-daemon[2907]: Sucessfully made thread 5147 of process 3045 (/usr/bin/pulseaudio) owned by '500' RT at priority 5.

$ cat /etc/udev/rules.d/99-funcube.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="048d", ATTRS{idProduct}=="fb56", MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="048d", ATTRS{idProduct}=="fb31", MODE:="0666"
KERNEL=="hidraw*",ATTRS{busnum}=="1",ATTRS{idVendor}=="048d",ATTRS{idProduct}=="fb56",MODE:="0666"
KERNEL=="hidraw*",ATTRS{busnum}=="1",ATTRS{idVendor}=="048d",ATTRS{idProduct}=="fb31",MODE:="0666"


I have tried running it as root (erk!) as well, just in case there was some permission problem but that hasn't helped.


Any ideas what else I can try to see what's going on here?

Calum

[Calum]

And on the gqrx console, I see:
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7
built-in source types: file rtl_tcp rfspace
Using Volk machine: sse4_1_64
INFO: Audio sink arch: alsa
BookmarksFile is .config/gqrx/bookmarks.csv
libGL error: dlopen /usr/lib64/dri/nouveau_dri.so failed (/usr/lib64/dri/nouveau_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: nouveau
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7
built-in source types: file rtl_tcp rfspace

FATAL: No supported devices found to pick from.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.

[David Ranch]

Hello Calum,

It seems your gr-osmosdr module doesn't have support for several SDR devices:

gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7
built-in source types: file rtl_tcp rfspace

Where did you get your copy of GnuRadio?  Considering you're using Centos, I'm assuming you found some RPMs out on the Internet but they aren't going to work for your needs.  You can follow my guide on how to complile GnuRadio + Gqrx on Centos6:

    http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#42b.gnuradio


The process will take a while but I'm happy to lend a hand off list if you need help.

--David
KI6ZHD

[Calum]

Hey David

Thanks for the tip.
Any idea what the correct output should be?

I'm compiling it all from source.
As far as I understand it, gnuradio doesn't have the driver for the fcdp+, which is what gr-fcdproplus provides. Then gr-osmosdr supports whatever drivers it finds.

When I compiled gr-osmosdr, it showed this output (which looks like it should be OK):

<snip>
-- checking for module 'gnuradio-fcdproplus'
--   package 'gnuradio-fcdproplus' not found
-- Found gnuradio-fcdproplus: /usr/local/include, /usr/local/lib64/libgnuradio-fcdproplus.so
<snip>
-- ######################################################
-- # Gnuradio enabled components                        
-- ######################################################
--   * FUNcube Dongle Pro+
--   * IQ File Source
--   * RTLSDR TCP Client
--   * RFSPACE Receivers
--
-- ######################################################
-- # Gnuradio disabled components                       
-- ######################################################
--   * Python support
--   * Osmocom IQ Imbalance Correction
--   * sysmocom OsmoSDR
--   * FUNcube Dongle
--   * Osmocom RTLSDR
--   * Ettus USRP Devices
--   * Osmocom MiriSDR
--   * HackRF Jawbreaker
--   * nuand bladeRF
--   * AIRSPY Receiver
--   * SoapySDR support
--
-- Building for version: v0.1.4-48-g86ad5842 / 0.1.5git

That seems to imply that it should be supported, right?
I can see the IQ File Source, RTLSDR TCP Client and RFSPACE Receivers options, so it seems correct to me.

I'm currently without an internet connection at home (so I'm accessing on a slow mobile link) so I'd rather avoid large downloads of SRPMS, etc.
I've already got the source for gnuradio, gr-fcdproplus, gr-osmosdr and gqrx downloaded, so I'm hoping it's just a compile option or something I'm missing

C

[Alexandru Csete]

Well, I have no clue what's going on here. The result of cmake says
it's building with funcube dongle pro+ support, but at runtime it
gr-osmosdr says it doesn't have funcube dongle pro+ support. The only
way I can imagine this to happen if you have two copies of gr-osmosdr
installed.

Or perhaps you have rebuilt gr-osmosdr but not gqrx? or something like that...

I also find it a bit strange that python and funcube dongle are
disabled... Python I understand, but how come funcube dongle is
disabled? It has no dependencies besides what are also needed by the
pro+ source, so I don't understand why it is disabled.

Alex

> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gqrx/040dc6a3-4060-4429-8e8f-47a988639f64%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Calum]

Hey Alex,

I'm confused too.

I compiled fcdctl (for fcdpp), and I get this:
$ ./fcdctl -l
nr  USB path      firmware  frequency        gain (lna/mixer/if)  bias-t  audio device
0   0008:0002:02  No FCD Detected.

That path is where the FCD is plugged in to:
Bus 008 Device 002: ID 04d8:fb31 Microchip Technology, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x04d8 Microchip Technology, Inc.
  idProduct          0xfb31
  bcdDevice           20.03
  iManufacturer           1 Hanlincrest Ltd.        
  iProduct                2 FUNcube Dongle V2.0 
  iSerial                 0
  bNumConfigurations      1
<plus some more stuff>

What does fdctl check?

I rebuild gqrx every time I rebuild/install gr-osmosdr.
I've tried building gr-osmosdr with everything else disabled, and only the FCDP+ enabled - then the only device option I get in gqrx is "Other".
I've tried removing all references to *osmosdr* in /usr/local and below.

I might try ditching all of /usr/local, and rebuild gnuradio, gr-fcdproplus. gr-osmosdr, and then qgrx, but I don't hold much hope.
I do seem to have two different versions of boost installed, but I don't think that could be causing this specific problem, could it?

I'm sooooo close, I can taste it...

C

[Calum]

The gr-osmosdr page mentions that "prior pulling a new version from git and compiling it, please do a "make uninstall" first to properly remove the previous version."

I wonder if it squirrels some stuff away in an unexpected place?
However, I've used the same version of it the whole time, so maybe it doesn't matter.

[Alexandru Csete]

Did you build with the fcdpp option? My output looks like this:

nr USB path firmware frequency LNA gain audio device
0 0006:000e:02 20.03 97.300000 MHz enabled (not found)

Alex

[Calum]

Hey Alex,

Yes, I ran make fcdpp.

I notice on the github page for gqrx, it says that
"If you don't see your device listed in the drop-down list it could be because:

• The driver has not included in a binary distribution
• The udev rule has not been properly configured"

Could you take a look at my udevd rule, and check it looks right for a fcdpp?

I took the rules from qthid/funcube-dongle.rules and changed the idProduct - I hope I got it right.

$ cat /etc/udev/rules.d/99-funcube.rules
# Udev rule for the Funcube Dongle to be used with libusb
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fb31", GROUP:="users", MODE:="0660", SYMLINK+="FCD"

# Udev rule for the Funcube Dongle to be used with HIDAPI/hidraw
# KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fb56", GROUP:="users", MODE="0660", SYMLINK+="FCD"

[Alexandru Csete]

what can be an issue is if you have different copies installed in
different locations, e.g. /usr/lib and /usr/local/lib

Alex

[Calum]

For the record, I have:

$ find /dev/ | grep -i fcd
/dev/FCD
/dev/.udev/links/FCD
/dev/.udev/links/FCD/c116:9
/dev/.udev/links/FCD/c116:8
/dev/.udev/links/FCD/c249:0
/dev/.udev/links/FCD/c180:96
/dev/.udev/links/FCD/c189:897

$ ls -l /dev/FCD
lrwxrwxrwx. 1 root root 13 Aug 13 21:08 /dev/FCD -> snd/controlC1

[Calum]

Really appreciating the help, by the way.

# find / -iname "*osmosdr*"
/usr/local/lib64/libgnuradio-osmosdr-0.1.5git.so
/usr/local/lib64/libgnuradio-osmosdr-0.1.5git.so.0
/usr/local/lib64/pkgconfig/gnuradio-osmosdr.pc
/usr/local/lib64/libgnuradio-osmosdr-0.1.5git.so.0.0.0
/usr/local/lib64/libgnuradio-osmosdr.so
/usr/local/include/osmosdr
(Snipping the instances in my source dir)

# ls -l /usr/local/lib64/*osmosdr*
lrwxrwxrwx. 1 root root     37 Aug 13 21:42 /usr/local/lib64/libgnuradio-osmosdr-0.1.5git.so -> libgnuradio-osmosdr-0.1.5git.so.0.0.0
lrwxrwxrwx. 1 root root     37 Aug 13 21:42 /usr/local/lib64/libgnuradio-osmosdr-0.1.5git.so.0 -> libgnuradio-osmosdr-0.1.5git.so.0.0.0
-rwxr-xr-x. 1 root root 311792 Aug 13 21:39 /usr/local/lib64/libgnuradio-osmosdr-0.1.5git.so.0.0.0
lrwxrwxrwx. 1 root root     37 Aug 13 21:42 /usr/local/lib64/libgnuradio-osmosdr.so -> libgnuradio-osmosdr-0.1.5git.so.0.0.0
# ldd /usr/local/lib64/libgnuradio-osmosdr-0.1.5git.so.0.0.0 | grep fcd
    libgnuradio-fcdproplus.so.0 => /usr/local/lib64/libgnuradio-fcdproplus.so.0 (0x00007f7d4ee7e000)

[Alexandru Csete]

looks right assuming that you are member of the group users.

> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/gqrx/a1189520-4d8e-44fe-bdb4-1cfc93443156%40googlegroups.com.

[Calum]

Good spot - I wasn't.

Now I can run fcdctl
$ ~/src/fcdctl/fcdctl -l

nr  USB path      firmware  frequency        gain (lna/mixer/if)  bias-t  audio device

0   0008:0003:02  20.03     97.300000 MHz    on / on / 0 dB       off     card1

It hasn't made any difference to gqrx though.
$ gqrx

gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7
built-in source types:

[Alexandru Csete]

On Thu, Aug 13, 2015 at 11:24 PM, Calum <cal...@gmail.com> wrote:
> Good spot - I wasn't.
>
> Now I can run fcdctl
> $ ~/src/fcdctl/fcdctl -l
> nr USB path firmware frequency gain (lna/mixer/if) bias-t
> audio device
> 0 0008:0003:02 20.03 97.300000 MHz on / on / 0 dB off
> card1
>
> It hasn't made any difference to gqrx though.
> $ gqrx
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7
> built-in source types:
>

So now gr-osmosdr doesn't have any built-in source types???

In your previous email it was:

built-in source types: file rtl_tcp rfspace

As David noted, this means that gr-osmosdr does *not* have fcdpp as
built in source type despite the fact that the cmake part said it
would build fcdpp support.

I suspect this could be caused by not having python support in
gnuradio. While gqrx does not require python, there could be errors in
the gnuradio / gr-fcdproplus / gr-osmosdr build files that are broken
if python support is disabled. But this is just a guess.

Alex

[Calum]

Hey Alex,

Originally, I used the osmosdr defaults.

Then I tried recompiling with everything disabled except for FCDPP
(cmake -DENABLE_FCDPP=ON -DENABLE_RTL_TCP=OFF -DENABLE_SOAPY=OFF -DENABLE_FILE=OFF -DENABLE_RFSPACE=OFF ..)
just to see if that would help, but it didn't. (It did at least prove that gqrx was using the version of gr-osmosdr that I was compiling).

I wonder what versions of the various libraries you use personally - maybe there's been a problem introduced by a later commit?
Just for the records, I'm using:
gnuradio: http://gnuradio.org/releases/gnuradio/gnuradio-3.7.7.1.tar.gz
gr-fcdproplus: commit cf5db388e9f2f77b9ad2ff727608d5cf89d8e218
gr-osmosdr: commit 86ad584204762eeb01f07daa683673f1ec3f1df5
gqrx: commit 536b2bef42217830d3428a791c688640fa2933e2

Tomorrow, I'll try enabling python, and see if that helps.
Do you know of a way I can see whether gr-osmosdr has the support without rebuilding gqrx and trying it?

Thanks for all your help - you've been a star.

C

[Alexandru Csete]

On Thu, Aug 13, 2015 at 11:49 PM, Calum <cal...@gmail.com> wrote:
>
> Do you know of a way I can see whether gr-osmosdr has the support without
> rebuilding gqrx and trying it?

Not directly but you can see which libraries libgnuradio-osmosdr has
been linked against using ldd. Otherwise there is the osmocom_fft test
application included with gr-osmosdr but it is a python application.

Alex

[Calum]

Hey Alex,

I install swig (which was the dependency that meant osmosdr wasn't compiled with Python support), and reinstalled the entire chain.
That didn't help, but accepting the defaults for osmosdr cmake (and not trying to restrict it to FCDPP) meant that I've finally got the option for Funcube Dongle V2.0 in gqrx - yay!

However.
If I run gqrx just after inserting the dongle, I get in the console:

$ gqrx
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7

built-in source types: file fcd rtl_tcp rfspace

Using Volk machine: sse4_1_64
INFO: Audio sink arch: alsa

BookmarksFile is /home/calum/.config/gqrx/bookmarks.csv

libGL error: dlopen /usr/lib64/dri/nouveau_dri.so failed (/usr/lib64/dri/nouveau_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: nouveau

<pops up device selection dialog>

gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7

built-in source types: file fcd rtl_tcp rfspace
Using FUNcube Dongle V2.0 (hw:1)
INFO: Audio source arch: alsa
Opened: hw:1
Dongle sucessfully initialized

<hangs for ever, the main GUI doesn't start>


If I run it subsequently, the main GUI opens, and I get:

gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7

built-in source types: file fcd rtl_tcp rfspace
Using FUNcube Dongle V2.0 (hw:1)
INFO: Audio source arch: alsa
Opened: hw:1

FATAL: FunCube Dongle  V2.0 soundcard found but not controlpart.

Any thoughts?

[David Ranch]

Hello Calum,

libGL error: dlopen /usr/lib64/dri/nouveau_dri.so failed (/usr/lib64/dri/nouveau_dri.so: cannot open shared object file: No such file or directory)

This is an Xwindows video card driver for Nvidia video cards.  Are you locally displaying Gqrx or trying to do it remotely?  If local, do you have a Nvidia video card?  Are you using the stock Centos Xf86 driver or the proprietary Nvidia binary drivers?

If I run it subsequently, the main GUI opens, and I get:

gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7
built-in source types: file fcd rtl_tcp rfspace
Using FUNcube Dongle V2.0 (hw:1)
INFO: Audio source arch: alsa
Opened: hw:1

FATAL: FunCube Dongle  V2.0 soundcard found but not controlpart.

This seems that only part of the FCD+ I/O is available to Gqrx and not both.   Did you look at something like this to get some ideas?

   http://www.oz9aec.net/index.php/funcube-dongle/479-the-funcube-dongle-propro-on-the-raspberry-pi

--David

[Alexandru Csete]

On Fri, Aug 14, 2015 at 1:17 PM, Calum <cal...@gmail.com> wrote:
>
> FATAL: FunCube Dongle V2.0 soundcard found but not controlpart.

Did you fix the udev permissions?

The funcube dongle has two device interfaces, and audio interface used
for sending samples to the PC and a USB HID interface used to control
frequency and gain. The error message says that the audio device part
is OK but the control (HID) interface is not found.

So, either there is a faulty hardware or you don't have permission to
access the HID interface or some software is already using that
interface blocking access to it. In the last case you can simply
unplug and reinsert the device.

Alex

[Calum]

Hello David/Alex,

I am running on a laptop with an Nvidia card in, but I don't use the binary NVidia drivers. I don't think this warning is very important - I get it while running other applications too.

Yes, I've fixed the udev permissions - that's what allowed fcdctl to start working.
Do I need the second "hidraw*" line uncommented for the hidraw stuff? I have currently got:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fb31", GROUP:="calum", MODE:="0660", SYMLINK+="FCD"
KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fb56", GROUP:="calum", MODE="0660", SYMLINK+="FCD"

The main problem is the fact that gqrx hangs after

gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7
built-in source types: file fcd rtl_tcp rfspace
Using FUNcube Dongle V2.0 (hw:1)
INFO: Audio source arch: alsa
Opened: hw:1
Dongle sucessfully initialized

If I run gqrx without a dongle in, it opens up fine.
If I plug a dongle in, and run gqrx, it sees the dongle fine, initialises it, and then hangs after printing the "Dongle sucessfully initialized" line.

strace seems to show it hanging waiting for a read (the Broken pipe is me killing strace/gqrx I think)
open("/dev/hidraw0", O_RDWR)            = 15
ioctl(15, HIDIOCGVERSION, 0x7ffdb4b73c7c) = 0
ioctl(15, HIDIOCAPPLICATION, 0x7ffdb4b72ad0) = 0
write(2, "Dongle sucessfully initialized", 30) = 30
write(2, "\n", 1)                       = 1
write(15, "\0\1\0\0\1\0\0\0\0\0\0\0\0\374\2\0\0\0\2\374\0\0\0\0\377\377\377\377\0\0\1|"..., 65) = -1 EPIPE (Broken pipe)
read(15,

Does this shed any light?

[Calum]

Just saw this in the console when I unplugged the dongle:

 Result of Action :+++++
�
Failed to modify lna gain
Result:  , n
Failed to modify mixer gain
Result:  , r
Could not set If gain
Set Frequency failed: 1.445e+08 Khz
Set Frequency failed: 1.4236e+07 Khz

[Alexandru Csete]

On Sat, Aug 15, 2015 at 2:34 PM, Calum <cal...@gmail.com> wrote:
>
> Yes, I've fixed the udev permissions - that's what allowed fcdctl to start
> working.
> Do I need the second "hidraw*" line uncommented for the hidraw stuff?

Why not just try it? It would be faster for you than waiting several
hours for an answer.

Whether you need the libusb or hidraw depends on how the driver is
configured. I don't know how the present gr-fdcdproplus package is
configured but it could be that it is configured to use the system
HIDAPI which may very well be using the hidraw driver.

Historically, we preferred the libusb driver but today it probably
doesn't matter and it doesn't hurt having both rules enabled in the
udev fiule..

> If I run gqrx without a dongle in, it opens up fine.
> If I plug a dongle in, and run gqrx, it sees the dongle fine, initialises
> it, and then hangs after printing the "Dongle sucessfully initialized" line.
>
> strace seems to show it hanging waiting for a read (the Broken pipe is me
> killing strace/gqrx I think)
> open("/dev/hidraw0", O_RDWR) = 15

Well, this suggests that your system does indeed wants to use the
hidraw driver, so please, try it.

PS: fcdctl uses built-in hidapi and may therefore use the other driver.

Alex

[Calum]

Hey Alex,

I tried it before, but it didn't make any difference.

I've also deleted all of /usr/local, and reinstalled everything, just to ensure things were in a known state.

While I was compiling fcdproplus, the cmake output said "Bundled hidapi is used"
Looking at what's linked against libgnuradio-fcdproplus.so.0.0.0 shows libusb-1.0.so.0, but nothing matching "hid"

When I insert the dongle, the following dev nodes are created/updated among others:
/dev/FCDPP -> snd/controlC1 (I renamed the device in udev rules)
/dev/hidraw0
/dev/usb/hiddev0
/dev/snd/controlC1
/dev/snd/pcmC1D0c
/dev/snd/pcmC0D0p

C

[Alexandru Csete]

Ok, well this is strange and I'm running out of ideas.

The only issues we've seen with FCD Pro / Pro+ devices are permissions
and the famous "not enough bandwidth" issue,
https://github.com/csete/gqrx/issues/91, but you don't seems to have
this issue.

I'm not familiar with centos but perhaps there are some additional
security layers preventing proper access to the device. You could try
MODE="0666" in the udev rules ad see if it helps.

Alex

[David Ranch]

Hmmm.. per Alex's last email, let's keep checking the security site of things:

What are the permissions of these files per the output of "ls -la"

> /dev/usb/hiddev0
> /dev/snd/controlC1
> /dev/snd/pcmC1D0c
> /dev/snd/pcmC0D0p

Also.. are you running SE Linux?  Check in /etc/sysconfig/selinux and it should either be set to permissive or disabled.

--David
KI6ZHD

[Calum]

Hello all,

Thanks for your help with this, by the way - really appreciated.

I do run SELinux, but have tried it with setenforce Permissive, which didn't help.
I checked /var/log/audit/audit.log, and there's nothing being logged there.

I changed the perms to 0666, and:
crw-rw-rw-. 1 root calum 180, 96 Aug 16 11:04 /dev/usb/hiddev0
crw-rw----+ 1 root audio 116, 7 Aug 16 10:57 /dev/snd/controlC0
crw-rw-rw-+ 1 root calum 116, 9 Aug 16 11:04 /dev/snd/controlC1
crw-rw----+ 1 root audio 116, 6 Aug 16 10:57 /dev/snd/hwC0D0
crw-rw----+ 1 root audio 116, 5 Aug 16 10:58 /dev/snd/pcmC0D0c
crw-rw----+ 1 root audio 116, 4 Aug 16 11:04 /dev/snd/pcmC0D0p
crw-rw-rw-+ 1 root calum 116, 8 Aug 16 11:04 /dev/snd/pcmC1D0c
crw-rw----+ 1 root audio 116, 3 Aug 16 10:57 /dev/snd/seq
crw-rw----+ 1 root audio 116, 2 Aug 16 10:57 /dev/snd/timer

I'm in the calum and audio groups.

I don't think it's permissions related - it seems like gqrx tries to read something from the hidraw interface, and nothing is there to be read, which means the main GUI never opens.

In the output of making fcdproplus, I see "Bundled hidapi is used" - could it be using a different library than gqrx is? (I have to confess, I'm not familiar with the hid* stuff).

Alex - I'm always loathe to think it could be hardware, but - could it? Is it possible that the dongle could be working correctly in the ways we've seen, but not supplying anything when the hidraw device is read?

C

[Calum]

Just been reading about the hidraw0 interface.
It seems to say that it blocks until there's something to be read.
Could everything be working correctly, and there're simply no reports being produced from the device?

The HIDRAW API
---------------

read()
-------
read() will read a queued report received from the HID device. On USB
devices, the reports read using read() are the reports sent from the device
on the INTERRUPT IN endpoint.  By default, read() will block until there is
a report available to be read.  read() can be made non-blocking, by passing
the O_NONBLOCK flag to open(), or by setting the O_NONBLOCK flag using
fcntl().

[Alexandru Csete]

On Sun, Aug 16, 2015 at 12:12 PM, Calum <cal...@gmail.com> wrote:
> Hello all,
>
> Thanks for your help with this, by the way - really appreciated.
>
> I do run SELinux, but have tried it with setenforce Permissive, which didn't
> help.
> I checked /var/log/audit/audit.log, and there's nothing being logged there.
>
> I changed the perms to 0666, and:
> crw-rw-rw-. 1 root calum 180, 96 Aug 16 11:04 /dev/usb/hiddev0
> crw-rw----+ 1 root audio 116, 7 Aug 16 10:57 /dev/snd/controlC0
> crw-rw-rw-+ 1 root calum 116, 9 Aug 16 11:04 /dev/snd/controlC1
> crw-rw----+ 1 root audio 116, 6 Aug 16 10:57 /dev/snd/hwC0D0
> crw-rw----+ 1 root audio 116, 5 Aug 16 10:58 /dev/snd/pcmC0D0c
> crw-rw----+ 1 root audio 116, 4 Aug 16 11:04 /dev/snd/pcmC0D0p
> crw-rw-rw-+ 1 root calum 116, 8 Aug 16 11:04 /dev/snd/pcmC1D0c
> crw-rw----+ 1 root audio 116, 3 Aug 16 10:57 /dev/snd/seq
> crw-rw----+ 1 root audio 116, 2 Aug 16 10:57 /dev/snd/timer
>
> I'm in the calum and audio groups.

You should be in the group used in the udev rules, which as I recall
was "users".
By the way, the /dev/usb/hiddev0 should have been created for
root/users, so this suggests something with udev is not working as it
should, or as I would expect.

> I don't think it's permissions related - it seems like gqrx tries to read
> something from the hidraw interface, and nothing is there to be read, which
> means the main GUI never opens.

I'm not sure I understand what you are saying here.
When we query the device it must reply. That's how the FCD Pro+ is
made. Otherwise something is broken.

> In the output of making fcdproplus, I see "Bundled hidapi is used" - could
> it be using a different library than gqrx is? (I have to confess, I'm not
> familiar with the hid* stuff).

No, I think you misunderstand. Gqrx does not do any hardware I/O. It's
basicallly just a GUI.

Gqrx uses gr-osmosdr to access many different type of hardware using a
single interface.
Gr-osmosdr uses the gr-fcdproplus library to provide access to FCD Pro+
Gr-fcdproplus uses the hidapi high-level wrapper to access the control
part of the FCD Pro+
Hidapi can provide access to HID devices either through libusb or
direct kernel API.

> Alex - I'm always loathe to think it could be hardware, but - could it?

I suppose it could. Can you test it on a windows PC using e.g. SDRsharp?

> Is
> it possible that the dongle could be working correctly in the ways we've
> seen, but not supplying anything when the hidraw device is read?

If the dongle is not replying to queries then it is not working properly.

Alex

[Calum]

Hello Alex,

You should be in the group used in the udev rules, which as I recall
was "users".
By the way, the /dev/usb/hiddev0 should have been created for
root/users, so this suggests something with udev is not working as it
should, or as I would expect.

I changed the rules to use the group calum which I'm in. I'm also in the audio group, so everything's fine in that regard.

I'm not sure I understand what you are saying here.
When we query the device it must reply. That's how the FCD Pro+ is
made. Otherwise something is broken.

 
Is there some simple way of testing the hidraw device that you know of? Some sort of "hidcat" or similar?
I took a wild stab and tried cat /dev/hidraw0 but nothing was produced.

Gqrx uses gr-osmosdr to access many different type of hardware using a
single interface.
Gr-osmosdr uses the gr-fcdproplus library to provide access to FCD Pro+
Gr-fcdproplus uses the hidapi high-level wrapper to access the control
part of the FCD Pro+
Hidapi can provide access to HID devices either through libusb or
direct kernel API.

I tried firing up gnuradio-companion, and I get the same issue - "Dongle sucessfully initialized", and then hanging.
I didn't realise that line of output came from gr-fcdproplus.
 

Can you test it on a windows PC using e.g. SDRsharp?

I don't have access to one, but I'm thinking that I should try and verify that the dongle is working correctly before going any further.
Not sure when I'll be able to do this though.

Thanks very much for all your help (and David) - I've got very close, but can't quite crack the final step!

Calum

[Alexandru Csete]

On Sun, Aug 16, 2015 at 8:54 PM, Calum <cal...@gmail.com> wrote:
>
> I tried firing up gnuradio-companion, and I get the same issue - "Dongle
> sucessfully initialized",

What is that supposed to mean? I thought you were getting
"FunCube Dongle V2.0 soundcard found but not controlpart."?

If you were really getting "Dongle sucessfully initialized" then the
dongle is working and I have been wasting my time. If it is still
hanging it has probably not detected the correct audio device and can
be corrected by appending device=hw:2 (or similar) to the device
string. Sometimes it is also necessary to add type=2

So a complete device string would be

fcd=0,type=2,device=hw:2

or whatever the audio device is (cat /proc/asound/cards)

Alex