Can see the Funcube Dongle is detected from CubicSDR devices list. When I try to s

OK, I've found the change in libhidapi-libusb0: <a class="commit-link" href="https

Not just remote, doesn't work locally with rtl_433 either: <div class="snippet-cli

<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clip

Thank you! This seems to be where the problem is: <code class="notra

Righto - my fork now contains a fix that works for me: <a href="https://github.com/phl

Yes, that's looking better, locally: <div class="snippet-clipboard-content notrans

"Error opening PCM device not found" when used remotely about soapyfcdpp HOT 12 CLOSED

pothosware commented on September 23, 2024

"Error opening PCM device not found" when used remotely

from soapyfcdpp.

Comments (12)

troffasky commented on September 23, 2024 1

Package: libhidapi-libusb0
Version: 0.11.0-1
Package: linux-image-5.14.0-2-amd64
Version: 5.14.9-2

from Debian SID.

from soapyfcdpp.

phlash commented on September 23, 2024 1

OK, I've found the change in libhidapi-libusb0:
libusb/hidapi@03998f4#diff-516ed9d234e81614e6fa65cfc81a50b8b119e8a0769b2e66a1c89166bac437f7
which changes the device path from mine (Debian bulllseye/stable -> 0.10.1) to yours (Debian SID -> 0.11.0).

I'll grab the SID build of libhidapi-libusb0 and work on a fix 😄

from soapyfcdpp.

troffasky commented on September 23, 2024 1

Yes, that's the fix. The period field in CubicSDR is unlabelled and defaults to 24000. Tried 1024 and it's absolutely fine.

from soapyfcdpp.

troffasky commented on September 23, 2024

Not just remote, doesn't work locally with rtl_433 either:

# rtl_433 -d ""
rtl_433 version 21.05 (2020-05-09) inputs file rtl_tcp RTL-SDR SoapySDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/alex/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 157 out of 186 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-186 ]
[ERROR] avahi_service_browser_new() failed: Bad state
[INFO] makeFCDPP
[INFO] setup stream
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM not found
Error opening PCM device not found

libasound2 version is 1.2.5.1, FWIW.

from soapyfcdpp.

troffasky commented on September 23, 2024

I think my problem here is that this driver is for the Funcube Dongle Pro Plus, and I merely have a Pro [I wish the names were a bit more distinct!].
I will close this issue on that basis, but I am sure someone can reopen this if my assumption is wrong.

from soapyfcdpp.

phlash commented on September 23, 2024

Hi, sorry I missed this earlier - it's definitely a problem somewhere as the driver supports all versions of FCD (and I apologise for the names, those are 'marketing' choices, you can use the version numbers, 1.0, 1,1 [Pro, 96k] or 2.0 (Pro+, 192k).

From your logs, it seems the driver is unable to find the appropriate sound device in the kernel that relates to the HID device it has found (for your FCD v1.x): Error opening PCM device not found

Please re-run a test on the local machine where the device is, with Soapy logging turned up to TRACE:

% SOAPY_SDR_LOG_LEVEL=TRACE SoapySDRUtil --make=driver=fcdpp

This will provide more detail on the HID device identity, and may determine if we have a bug in the parsing of that to detect the Alsa device name, here's what I get:

phlash@bruce:~$ SOAPY_SDR_LOG_LEVEL=TRACE SoapySDRUtil --make=driver=fcdpp
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Make device driver=fcdpp
[TRACE] findFCDPP
[TRACE] Found device: 0001:0006:02, hw:1,0
[TRACE] findFCDPP=1 devices
[INFO] makeFCDPP
[DEBUG] SoapyFCDPP('0001:0006:02','hw:1,0',0,0)
  driver=FCDPP
  hardware=FCD

Please also check that your device is registering as an Alsa sound card by looking at the content of:

% cat /proc/asound/cards

this should contain an entry for the FCD similar to mine:

phlash@bruce:~$ cat /proc/asound/cards
 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xa1518000 irq 146
 1 [V10            ]: USB-Audio - FUNcube Dongle V1.0
                      Hanlincrest Ltd. FUNcube Dongle V1.0 at usb-0000:00:14.0-4, full speed

if so, please look at the content of the following (USB path) file:

% cat /proc/asound/card<n>/usbbus     <--- replace <n> with the entry number from above, in my case '1'

this should contain a pair of numbers that locate the FCD on the USB bus, again, here's mine:

phlash@bruce:~$ cat /proc/asound/card1/usbbus 
001/006

finally, check that these numbers match with the output of lsusb, here's mine:

phlash@bruce:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 06cb:00a2 Synaptics, Inc. Metallica MOH Touch Fingerprint Reader
Bus 001 Device 003: ID 13d3:56a6 IMC Networks Integrated Camera
Bus 001 Device 002: ID 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
Bus 001 Device 006: ID 04d8:fb56 Microchip Technology, Inc. FUNcube Dongle V1.0  <----- here it is@001/006
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Hope this helps...

from soapyfcdpp.

troffasky commented on September 23, 2024

# SOAPY_SDR_LOG_LEVEL=TRACE SoapySDRUtil --make=driver=fcdpp
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Make device driver=fcdpp
[TRACE] findFCDPP
[TRACE] Found device: 1-1.4:1.2, not found
[TRACE] findFCDPP=1 devices
[INFO] makeFCDPP
[DEBUG] SoapyFCDPP('1-1.4:1.2','not found',0,0)
  driver=FCDPP
  hardware=FCD

At this point I'm wondering if the above is telling me that it can't find the FCD at all, so I unplugged it and re-ran:

# SOAPY_SDR_LOG_LEVEL=TRACE SoapySDRUtil --make=driver=fcdpp
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Make device driver=fcdpp
[TRACE] findFCDPP
[TRACE] findFCDPP=0 devices
[INFO] makeFCDPP
Segmentation fault

So being plugged in does make a difference, thankfully :)

# cat /proc/asound/cards
 1 [V10            ]: USB-Audio - FUNcube Dongle V1.0
                      Hanlincrest Ltd. FUNcube Dongle V1.0 at usb-0000:00:1a.0-1.4, full speed
# cat /proc/asound/card1/usbbus
001/004
# lsusb | grep cube
Bus 001 Device 004: ID 04d8:fb56 Microchip Technology, Inc. FUNcube Dongle V1.0

qthid-2.2 does find the device and can toggle it from bootloader to application mode [confirmed by watching USB events with journalctl -f], although the display is a bit garbled.

from soapyfcdpp.

phlash commented on September 23, 2024

Thank you! This seems to be where the problem is:

[TRACE] Found device: 1-1.4:1.2, not found

that shows me that your HID device path 1-1.4:1.2 is completely different to mine and thus fails to parse. Yours appears to be a full USB device/port path, whereas mine is only bus/device ID. What versions of the following are you building/running with?

kernel
libhidapi-libusb0

then we should be able to reproduce and fix (after reading some manuals!)

from soapyfcdpp.

phlash commented on September 23, 2024

Righto - my fork now contains a fix that works for me: https://github.com/phlash/SoapyFCDPP.git

Please give it a try - I'll open a PR back to here.

from soapyfcdpp.

troffasky commented on September 23, 2024

Yes, that's looking better, locally:

# SOAPY_SDR_LOG_LEVEL=TRACE SoapySDRUtil --make=driver=fcdpp
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Make device driver=fcdpp
[TRACE] findFCDPP
[TRACE] Found device: 1-1.4:1.2, hw:1,0
[TRACE] findFCDPP=1 devices
[INFO] makeFCDPP
[DEBUG] SoapyFCDPP('1-1.4:1.2','hw:1,0',0,0)
  driver=FCDPP
  hardware=FCD

I've not had much luck remotely, however.
sdrpp segfaults as soon as you start streaming. CubicSDR works but is really choppy and logs a lot of this:

SDRThread::readStream(): 2. SoapySDR read failed with code: -1
SDRThread::readStream(): 3.1 iqDataOutQueue output queue is full, discard processing of the batch...
SSDRThread::readStream(): 2. SoapySDR read failed with code: -1
SDRThread::readStream(): 2. SoapySDR read failed with code: -1
SDRThread::readStream(): 3.1 iqDataOutQueue output queue is full, discard processing of the batch...
SSDRThread::readStream(): 2. SoapySDR read failed with code: -1

Pretty sure it's not a network issue as it's a whole 2Mbps and I have a 1G link to the server. This might be nothing to do with SoapyFCPP of course.

from soapyfcdpp.

phlash commented on September 23, 2024

Ah good - I'll let @guruofquality have time to look at the PR, I usually miss something like tagging...

By default the SoapyFCDPP driver batches up data into 250msec chunks, which can look quite lumpy as most drivers are nearer 50msec. It does this to avoid thread thrashing on small remote heads (ie: my OrangePi Zero!). You can change the batch size with a driver argument period=<n> where <n> is the number of samples in each batch. On my x64 it's happy down to 1024 (~5msec/batch at 192kHz), have a play..

from soapyfcdpp.

phlash commented on September 23, 2024

Change merged in #15

from soapyfcdpp.

"Error opening PCM device not found" when used remotely about soapyfcdpp HOT 12 CLOSED

Comments (12)

Related Issues (9)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent