Can't get FUNCube working just with gqrx on RP3

SatNOGS Hardware
1

Using bookworm on a Raspberry Pi 3 and was using an airspy successfully but
was getting many overflows and very poor RF performance, so replaced the
unit with a FunCube Pro.

Tested the FunCube on a laptop with bookworm and an Intel Atom processor and
it was very zippy.

Plugged it in to the rpi without restarting gqrx and just went to the I/O device manu
and changed it to fcd=1,bias=1 and everything looked fine… I was getting
reception… but then, once gqrx was restarted, I got the message
“audio_alsa_source: please select another device” and I get no signal
displayed.

Startup looks like:

$ gqrx
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.5.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy ai
rspyhf soapy redpitaya freesrp xtrx
Resampling audio 96000 → 48000
BandPlanFile is /home/pi/.config/gqrx/bandplan.csv
BookmarksFile is /home/pi/.config/gqrx/bookmarks.csv
[INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-5
libusb: warning [libusb_exit] device 1.8 still referenced
libusb: warning [libusb_exit] device 1.7 still referenced
libusb: warning [libusb_exit] device 1.6 still referenced
libusb: warning [libusb_exit] device 1.4 still referenced
libusb: warning [libusb_exit] device 1.5 still referenced
libusb: warning [libusb_exit] device 1.3 still referenced
libusb: warning [libusb_exit] device 1.2 still referenced
libusb: warning [libusb_exit] device 1.1 still referenced
[ERROR] avahi_service_browser_new() failed: Bad state
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.5.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy ai
rspyhf soapy redpitaya freesrp xtrx
Using FUNcube Dongle V2.0 (hw:1)
Funcube Pro+ :info: Start init fcdpp
Funcube Pro+ :info: Audio device hw:1 opened
fcdpp_control :info: FunCube Dongle V2.0 initialized.
cdpp_control :info: Dongle: FCDAPP 20.03
fcdpp_control :info: LNA gain enabled
fcdpp_control :info: Mixer gain enabled
fcdpp_control :info: IF gain set to: 15
fcdpp_control :info: Set Frequency to: 150000 Hz
fcdpp_control :info: Set Frequency to: 106912000 Hz
qt.qpa.xcb: QXcbConnection: XCB error: 148 (Unknown), sequence: 191, resource id
: 0, major code: 140 (Unknown), minor code: 20

And that’s it… no other initialization stuff.

The dmesg shows me:

[ 15.619236] usb 1-1.5.3: FTDI USB Serial Device converter now attached to tty
USB1
[ 15.804784] usb 1-1.2: 1:1: cannot get freq at ep 0x81
[ 15.813401] usbcore: registered new interface driver snd-usb-audio
[ 28.019032] usb 1-1.2: 1:1: cannot get freq at ep 0x81
[ 28.329409] usb 1-1.2: 1:1: cannot get freq at ep 0x81
[ 50.397911] systemd-journald[299]: Time jumped backwards, rotating.
[ 52.272413] i2c-bcm2835 3f805000.i2c: Got unexpected interrupt (from firmware

but I don’t get any messages about not enough bandwidth.

removing the .config/gqrx directory and the .gnuradio directories and having
them recreated does nothing.

The I/O settings I have are:

set I/Q input to
FUNcube Dongle V2.0
device string fcd=0
input rate 192000
decimation none
sample rate 192 ksps
bandwidth 0
lnb lo 0
audio device default
sample rate 48 khz

Any suggestions here? My assumption is that this is an alsa issue and I
really don’t know anything about alsa… but that may also be a red herring.

What is disturbing is that this worked briefly until gqrx was restarted and
that makes me think it’s got to be some initialization setting somehow.

Help!

2

Do you want to use the FUNcube Pro with a SatNOGS setup ?

And running a Airspy Mini and or R2 should run fine and great RF performance, this needs further investigation

Jan | PE0SAT

3

The Airspy Mini, now that it’s been taken down, is showing the same issues on the Linux laptop that it was showing on the raspberry pi up above. Lots of overloads, no signals. I know the gqrx install on the laptop is good since it worked fine with the Funcube. So I am prepared to say that the Airspy itself is bad, but that’s not the issue I am concerned about.

What I am concerned about is that the Funcube, which is known to be good since it works on the laptop, is not working with the gqrx installation on the raspberry pi.

I had previously stated that I was seeing signals when it was first installed but this is probably in error… I may have been using the alternate configuration with “soapy=0” and getting junk signal.

Yes, I would ultimately like to get this on SatNOGS but if I can’t even get local signals I don’t want to make that big step. I’d like to just get it running locally first and assure myself that I can hear reasonable signals.
–scott

4

So issues with two SDR devices, my guess something with your USB setup and without any further hardware details (all hardware) difficult to point in the right direction.

5

I think you are correct. Actually listening to audio on a somewhat sluggish Intel Atom machine, both the SDR devices work, although the Funcube gives continuous audio and the audio on the Airspy breaks up because there isn’t enough CPU… reducing the downsampling helps but does not fix things.

For some reason I don’t seem to be able to turn the bias on with the Funcube however… bias=1 and bias=0 don’t seem to do anything. But that’s a smaller issue. Bias works fine with the Airspy.

The machine I’d like to be running everything on is a Revolution Pi Connect Plus, which is an embedded raspberry pi system. It reports itself as being a “Raspberry Pi Compute Module 3 Plus Rev 1.0” and on this machine the airspy produces constant overflows and no coherent signal (probably also running out of CPU) while the Funcube is recognized by gqrx but produces no signal at all and does not seem to get completely initialized when it’s on this machine (as mentioned above… and it is fine on the Atom machine).

lsusb does show the host as having a USB hub although I don’t know if the SDR is downstream of the USB hub. It’s difficult for me to get physical access to this system since it’s on a rooftop that can’t be easily accessed during the government shutdown which is not helping any matters.

Will have more information soon with any luck as I am going to try and get the box with the processor down off the roof.

You may be right about it being a USB issue at the base, but it’s clear that the airspy is not working because of a lack of CPU horsepower and the Funcube is not working for some other reason which may or may not be USB-related.