Failed to apply antenna bias voltage state: 0 (-1000) Pipe error

klaute commented 4 months ago

What type of issue is this?

permanent - occurring repeatedly

What issue are you facing?

Facing the following error using gqrx and gnuradio companion with a CCC rad1o SDR (rev5 hackrf firmware):

Failed to apply antenna bias voltage state: 0 (-1000) Pipe error

What are the steps to reproduce this?

Start gqrx or GRC. Try to send data with osmocom sink. Sending signals is not possible with these tools.

No issues with hackrf commandline tools. One exception: hackrf_transfer is used with the -p1 option. That causes the same error.

Adding "bias=0" or "bias_tx=0" to the device string does not affect the behavior. Not in gqrx and also not in GRC. Also tried the values 1/trie/false.

Can you provide any logs? (output, errors, etc.)

Failed to apply antenna bias voltage state: 0 (-1000) Pipe error

Tested with the following tools on latest MacOS and Debian gnu Linux.

Mac gqrx: gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.5.0 built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf spyserver rfspace airspy airspyhf soapy redpitaya [INFO] [UHD] Mac OS; Clang version 15.0.0 (clang-1500.1.0.2.5); Boost_107100; UHD_3.15.0.0-MacPorts-Release PortAudio V19.7.0-devel, revision unknown (version 1246976)

Linux 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 airspyhf soapy redpitaya freesrp xtrx [INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-5

Mac GRC: 3.8.5.0 (Python 3.9.18)

Linux GRC: 3.10.5.1 (Python 3.11.2)

Mac hackrf: hackrf_info hackrf_info version: 2021.03.1 libhackrf version: 2021.03.1 (0.6) Found HackRF Index: 0 Serial number: 000000000……… Board ID Number: 3 (rad1o) Firmware Version: git-b6acd66c (API:1.06) Part ID Number: 0xa0000a30 0x0059434e Operacake found, address: 0xff

Linux hackrf: hackrf_info hackrf_info version: 2022.09.1 libhackrf version: 2022.09.1 (0.7) …

klaute commented 3 months ago

More logs from Gqrx on a mac:

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.5.0 built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf spyserver rfspace airspy airspyhf soapy redpitaya [INFO] [UHD] Mac OS; Clang version 15.0.0 (clang-1500.1.0.2.5); Boost_107100; UHD_3.15.0.0-MacPorts-Release PortAudio V19.7.0-devel, revision unknown (version 1246976)

log: portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::stop(): Error stopping audio stream: Invalid stream pointer portaudio_sink::stop(): Error closing audio stream: Invalid stream pointer ||PaMacCore (AUHAL)|| Warning on line 520: err=''!obj'', msg=Unknown Error ||PaMacCore (AUHAL)|| Warning on line 436: err=''!obj'', msg=Unknown Error ||PaMacCore (AUHAL)|| Error on line 1334: err='-10851', msg=Audio Unit: Invalid Property Value portaudio_sink::start(): Failed to open audio stream: Unanticipated host error Failed to apply antenna bias voltage state: 0 (-1000) Pipe error Playing audio from /Users/klaute/gqrx_20240308_175312_117019100.wav portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::work(): Error writing to audio device: Invalid stream pointer portaudio_sink::stop(): Error stopping audio stream: Invalid stream pointer portaudio_sink::stop(): Error closing audio stream: Invalid stream pointer

martinling commented 3 months ago

The rad1o board does not have an antenna bias tee, so the firmware does not support the USB request to change this setting. The device therefore returns a STALL response to the USB request, which shows up as a "Pipe error".

This needs to be fixed on the osmosdr side. Either the osmosdr block needs to check the board ID and not try to expose or set the bias tee option for the rad1o board in the first place, or it needs to handle this error and continue rather than simply giving up.

dos1 commented 1 month ago

A quick firmware-level workaround:

diff --git a/firmware/hackrf_usb/hackrf_usb.c b/firmware/hackrf_usb/hackrf_usb.c
index e6536795e409..8c72239d6beb 100644
--- a/firmware/hackrf_usb/hackrf_usb.c
+++ b/firmware/hackrf_usb/hackrf_usb.c
@@ -92,7 +92,7 @@ static usb_request_handler_fn vendor_request_handler[] = {
        usb_vendor_request_set_vga_gain,
        usb_vendor_request_set_txvga_gain,
        NULL, // was set_if_freq
-#ifdef HACKRF_ONE
+#if (defined HACKRF_ONE || defined RAD1O)
        usb_vendor_request_set_antenna_enable,
 #else
        NULL,
diff --git a/firmware/hackrf_usb/usb_api_transceiver.c b/firmware/hackrf_usb/usb_api_transceiver.c
index c639a11c4fc1..b72b0cbc26fa 100644
--- a/firmware/hackrf_usb/usb_api_transceiver.c
+++ b/firmware/hackrf_usb/usb_api_transceiver.c
@@ -233,6 +233,12 @@ usb_request_status_t usb_vendor_request_set_antenna_enable(
        usb_endpoint_t* const endpoint,
        const usb_transfer_stage_t stage)
 {
+#ifdef RAD1O
+       if (stage == USB_TRANSFER_STAGE_SETUP) {
+               usb_transfer_schedule_ack(endpoint->in);
+       }
+       return USB_REQUEST_STATUS_OK;
+#endif
        if (stage == USB_TRANSFER_STAGE_SETUP) {
                switch (endpoint->setup.value) {
                case 0:

miek commented 1 week ago

I tried reproducing this and, while I get the same error when using a rad1o, it doesn't prevent it from running the flowgraph and transmitting correctly.

Can you describe a bit more about what goes wrong? Does the flowgraph stop immediately or, if not, how are you testing to see if transmit is working?

Also, one thing I notice from the logs is that its going through extra layers of abstraction (via UHD & soapysdr) because of some unfortunate defaults in the third-party libs, which can cause some issues. You can tell the osmosdr blocks to use the hackrf driver directly by setting the device arguments to "hackrf".

greatscottgadgets / hackrf