osmocom-sdr

osmocom-sdr@lists.osmocom.org

916 discussions

[PATCH] cmake: use GR_INSTALL_LIBRARY to install modules (gr-osmosdr)
by Mario Haustein 08 May '26

08 May '26

Dear gr-osmosdr maintainers, attached you will find a patch which uses the GR_INSTALL_LIBRARY macro to install the module library. Otherwise no library files will be installed. Kind regards Mario Haustein

1 0

[PATCH] cmake: use GR_INSTALL_LIBRARY to install modules (gr-iqbal)
by Mario Haustein 08 May '26

08 May '26

Dear gr-iqbal maintainers, attached you will find a patch which solves https://osmocom.org/issues/4950. Kind regards Mario Haustein

1 0

[PATCH] cmake: fix usage of GR_REGISTER_COMPONENT according to current GNU Radio
by Mario Haustein 08 May '26

08 May '26

Dear gr-osmosdr maintainers, attached you will find a patch which solves https://osmocom.org/issues/6986. Kind regards Mario Haustein

1 0

Question about PLL setting and vco_power_ref in tuner_r82xx.c
by WangRZ 07 May '26

07 May '26

Hi all, In src/tuner_r82xx.c of the rtl-sdr project, I see the following code: uint8_t vco_power_ref = 2; ... if (priv->cfg->rafael_chip == CHIP_R828D) vco_power_ref = 1; vco_fine_tune = (data[4] & 0x30) >> 4; if (vco_fine_tune > vco_power_ref) div_num = div_num - 1; else if (vco_fine_tune < vco_power_ref) div_num = div_num + 1; ... It seems that vco_power_ref is derived from the chip type, and used to determine the VCO's division. However, when I use an R820T2 with a 16MHz crystal, I have to manually set vco_power_ref = 1 to get it working normally. This confuses me. Could someone explain the mechanism of the PLL setting? And why is vco_power_ref determined solely by the chip type in the original code? Thank you. Wang Rz

1 0

[PATCH] Add RTL-SDR Blog V4L Support
by Carl Laufer 01 May '26

01 May '26

Hi all, The RTL-SDR Blog V4 model is based on the R828D chip, which is no longer in production, and the stockpile we were using is now running low. But we found a bunch of stockpiled R828*S *chips, which I intend to use for a "V4 Lite" model that will allow a similar V4-like architecture to continue being sold for at least another year (and hopefully at a slightly lower price, too). To support the R828S chip a driver update is needed. It's a little confusing as the R828S chip presents itself on I2C as an R820T/R860. Like the Blog V4 patch, the code looks for the "RTLSDRBlog" and "V4L" strings in the EEPROM manufacturer/product strings to know what it's dealing with. The R828S also has only two inputs, so there are some switching changes, and hence the 'lite' designation, as it doesn't have the additional VHF/UHF split filtering that we could do with the three inputs on the R828D. I also added a small mod to disable the tracking filter when in HF upconversion mode for both the V4 and V4L, as this seems to help sensitivity a bit. Please consider this patch. And if anyone at Osmocom wants to try a V4L, please let me know. An initial run of the V4L models should be ready in about 1-2 months. Regards, Carl Laufer RTL-SDR Blog

1 0

fl2k Fread 0 path
by Kiss Ádám 01 Apr '26

01 Apr '26

Dear Osmocom, I encountered a bug in fl2k_file where the program would occasionally exit the loop prematurely while playing a file repeatedly. I have developed a fix for this issue, which is included in the attached patch. If the changes meet your standards, please consider merging them into the main repository. Kind regards, Ádám Kiss

2 1

[PATCH] cmake: remove system component from boost
by doron.behar＠gmail.com 29 Mar '26

29 Mar '26

From: Doron Behar <doron.behar(a)gmail.com> boost_system is a header only library in Boost 1.69, so the version constraint is bumped too. --- CMakeLists.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 3a6b0da..eefd442 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -119,7 +119,7 @@ endif() ######################################################################## # Find boost ######################################################################## -find_package(Boost "1.65" REQUIRED chrono thread system) +find_package(Boost "1.69" REQUIRED chrono thread) if(NOT Boost_FOUND) message(FATAL_ERROR "Boost required to compile osmosdr") -- 2.28.0

3 2

[PATCH] Fix application hang on USB transfer errors
by Ramon Smits 26 Jan '26

26 Jan '26

Hello, I'm submitting a patch that fixes a critical issue where applications using rtlsdr_read_async() hang indefinitely when USB transfer errors occur. ## Background I encountered this issue while running long-term monitoring with rtl_fm for FLEX paging signals. When the RTL-SDR dongle would shift slightly in the USB socket (causing USB transfer errors), rtl_fm would hang indefinitely instead of exiting cleanly. ## Root Cause The problem occurs in two parts: 1. The _libusb_callback() function calls rtlsdr_cancel_async() from within the libusb event handler callback. This creates a race condition where dev->async_cancel is modified while libusb_handle_events_timeout_completed() is actively using it as a parameter, leading to unpredictable behavior. 2. Even when the dev->dev_lost flag is set, the async read loop doesn't properly exit, and applications like rtl_fm have no way to detect that the device is lost. ## Solution The attached patch: - Removes the problematic rtlsdr_cancel_async() call from the callback - Adds detection of dev->dev_lost in the main event loop to properly transition to RTLSDR_CANCELING state - Makes rtlsdr_read_async() return -1 when the device is lost - Updates rtl_fm to check the return value and terminate gracefully ## Testing Tested with RTL2832U dongle (FC0012 tuner) by deliberately triggering USB errors through physical movement. The applications now terminate cleanly with an appropriate error message instead of hanging indefinitely. Normal operation (Ctrl+C termination) continues to work correctly. This fix makes rtl-sdr more robust for long-running monitoring applications and deployment scenarios where physical interference might occur (e.g., Raspberry Pi installations). Please review and consider merging. Best regards, Ramon Smits

2 1

Fwd: Raspberry Pi 5 + RTL-SDR Blog V4 – rtl_* CLI tools produce zero output
by Bodó Richárd 03 Jan '26

03 Jan '26

Subject: Raspberry Pi 5 + RTL-SDR Blog V4 – rtl_* CLI tools produce zero output Dear Developers, I would like to report a reproducible issue observed with a Raspberry Pi 5 and an RTL-SDR Blog V4 device. *Hardware setup:* Raspberry Pi 5 (8 GB) RTL-SDR Blog V4 Direct USB connection (no external hub) Adequate power supply (official Raspberry Pi 5 power supply) *Software environment:* Raspberry Pi OS 64-bit (Bookworm) rtl-sdr package (rtl_sdr, rtl_fm, rtl_power) librtlsdr installed via distribution packages Fully updated kernel and system *Issue description:* rtl_test -p runs successfully USB streaming is active and samples are reported PLL lock messages are shown and the device appears stable *However, the following CLI tools produce no output data:* rtl_sdr rtl_fm rtl_power Output files remain at 0 bytes Processes run without errors, but no IQ samples or audio data are produced *Important observation:* The same RTL-SDR Blog V4 device works correctly on Raspberry Pi 3 and Raspberry Pi 4 systems using the same software stack. *Conclusion:* Based on testing, this appears to be an interaction issue between the Raspberry Pi 5 USB subsystem and/or kernel, librtlsdr, and the RTL-SDR Blog V4. Since rtl_test confirms that USB streaming is functional, the problem seems to occur at the level of sample delivery or processing in the CLI tools. I am happy to provide logs, detailed version information, or perform additional tests if required. Thank you for your time and for maintaining these tools. Kind regards, An RTL-SDR user P.S. My original goal was to develop an Airband (voice) scanner application with the help of ChatGPT, capable of scanning and monitoring airband frequencies. Neither the RTL-SDR Blog V3 nor the V4 worked as expected on the Raspberry Pi 5 during this effort. Based on recommendations, I specifically purchased an RTL-SDR Blog V4 because it was expected to be better aligned with the Raspberry Pi 5 USB implementation. This report is the result of several days of systematic testing and comparison across different Raspberry Pi models. The device enumerates correctly on USB and remains stable during operation. rtl_test confirms continuous sample streaming, indicating that bulk USB transfers are functional. No kernel errors, USB resets, or xHCI faults are observed in dmesg during runtime. The issue appears after device initialization, at the stage where librtlsdr-based tools should consume and process the incoming samples. USB-related kernel and firmware boot parameters were reviewed and adjusted via /boot/firmware/cmdline.txt, including settings related to USB behavior and buffering; these changes did not alter the observed issue. This suggests a possible interaction issue between the Raspberry Pi 5 USB/xHCI implementation, kernel behavior, and librtlsdr buffer handling rather than a physical USB or power problem uname -a lsusb lsusb -t dmesg | grep -i usb rtl_test -p rtl_sdr test.iq rtl_fm -f 118M -M am -s 240k - rtl_power -f 118M:137M:25k test.csv I did not purchase the Raspberry Pi 5 and the RTL-SDR Blog V4 as experimental or disposable hardware. This report is submitted in good faith, with the expectation that this platform can be made fully functional through proper investigation and resolution

1 0

rtl_fm Change cb transfer status: X, canceling...
by Ramon Smits 26 Dec '25

26 Dec '25

I occasionally get the error "cb transfer status: 1, canceling...". This usually is because something bumped my pi causing the RTLSDR dongle to move. rtl_fm nicely emits to ERROUT but remains running. I think this is likely an error. I would expect the process to die in this state. Is this reasoning correct? I made a change with claude.ai , it removed invoking `rtlsdr_cancel_async(dev);` === Why this fixes the halt: The callback was calling rtlsdr_cancel_async() while already executing inside the libusb_handle_events_timeout_completed() loop (line 1924), which would modify the dev->async_cancel flag that the event handler was actively monitoring. This created a deadlock/race condition. Now the callback simply sets the dev->dev_lost flag, and the main event loop at line 1961 properly detects this condition and breaks out cleanly, allowing normal termination to occur. The process should now terminate correctly when USB transfer errors occur. === The change is available at https://github.com/osmocom/rtl-sdr/compare/master...ramonsmits:rtl-sdr:rtls… Does this change make any sense? I have not fully tested this as I'm new to this project and somehow need to build this and deploy on my pi4 which I need to figure out. Any help appreciated! -- Ramon

1 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr