- osmocom-sdr - lists.osmocom.org

[PATCH] rtl_tcp: keep serving after a client that disconnects at once
by Rodrigo Gressler 23 Oct '26

23 Oct '26

Hi, I hit this running rtl_tcp on Windows with an RTL-SDR Blog V4: a client that connects and drops right away (port probe, quick reconnect) leaves rtl_tcp accepting TCP connections but never sending the dongle header again until it is restarted. When the client goes away before rtlsdr_read_async() has started, the worker's rtlsdr_cancel_async() is a no-op, read_async then runs forever with do_exit set and the server never gets back to accept(). The attached patch: - rtlsdr_callback(): once do_exit is set, cancel from there and return - command_worker(): recv() == 0 (client closed) ends the session - tcp_worker(): a select() error ends the session; bytesleft/index only move when send() sent something It applies to master (v2.0.3) and builds without warnings. With it the server goes back to accept() after each such client; tested on the same setup. The same fix is in rtlsdrblog/rtl-sdr-blog PR #85. For transparency: I tracked this down and wrote the fix with help from an LLM. I reviewed the change, tested it and am happy to answer questions about it. Regards, Rodrigo Gressler

1 0

Re: osmocom-sdr Digest, Vol 114, Issue 1
by Carl 23 Oct '26

23 Oct '26

Hi Oliver, SDR++ is one popular project that pulls from these binaries. The issue only came up just now because Blog V4L (Lite) support wasn't working after they updated to the latest build from the ftp. It must have been working back in 2023, because that's when Blog V4 support was added, and the binaries have picked up that change. So probably only 2-3 years that it has been failing. Regards, Carl On Sat, Oct 24, 2026 at 1:01 AM <osmocom-sdr-request(a)lists.osmocom.org> wrote: > Send osmocom-sdr mailing list submissions to > osmocom-sdr(a)lists.osmocom.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > osmocom-sdr-request(a)lists.osmocom.org > > You can reach the person managing the list at > osmocom-sdr-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of osmocom-sdr digest..." > > Today's Topics: > > 1. Osmocom Windows binaries not built on up to date code? > (Carl Laufer) > 2. Re: Osmocom Windows binaries not built on up to date code? > (Oliver Smith) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 23 Oct 2026 18:19:05 +1300 > From: Carl Laufer <admin(a)rtl-sdr.com> > Subject: Osmocom Windows binaries not built on up to date code? > To: osmocom-sdr(a)lists.osmocom.org > Message-ID: > < > CAP8SZq1LJkOkuvRNdycOdce3-3L1sExHv-PWBnjc5ByqHRfXOw(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="000000000000b6b60a065e7b204c" > > Hi, > > I've just been testing out the latest Windows builds at > https://ftp.osmocom.org/binaries/windows/rtl-sdr/, but they do not seem to > be up to date. > > I tested the latest October 18 2026 zip file, and found that rtl_test does > not detect the RTL-SDR Blog V4L. > > But if I compile from source from the Osmocom rtl-sdr GitHub, I get working > V4L support for Windows and Linux, so the source is working fine. > > So it seems that the automatic builds are not working correctly and are > using old code to build librtlsdr.dll and possibly everything else? > > Regards, > Carl Laufer > RTL-SDR.com <http://rtl-sdr.com/> & krakenrf.com >

1 0

Osmocom Windows binaries not built on up to date code?
by Carl Laufer 23 Oct '26

23 Oct '26

Hi, I've just been testing out the latest Windows builds at https://ftp.osmocom.org/binaries/windows/rtl-sdr/, but they do not seem to be up to date. I tested the latest October 18 2026 zip file, and found that rtl_test does not detect the RTL-SDR Blog V4L. But if I compile from source from the Osmocom rtl-sdr GitHub, I get working V4L support for Windows and Linux, so the source is working fine. So it seems that the automatic builds are not working correctly and are using old code to build librtlsdr.dll and possibly everything else? Regards, Carl Laufer RTL-SDR.com <http://rtl-sdr.com/> & krakenrf.com

2 1

(Very Minor) Correction to Gain Values in librtlsdr.c
by Gary Schafer 03 Oct '26

03 Oct '26

I've been trying to understand how the RTL-SDR drivers adjust gain values for R82xx/R860 chips based on user input. I saw that a user input is set to one of 29 possible values using the "nearest_gain" function in "convenience.c". These values are listed in "librtlsdr.c" in the "r82xx_gains", with the last two gain values being 480 and 496. As I was going through the code, I looked up the gain values for the LNA and mixers in "tuner_r82xx.c", and then created a spreadsheet to understand the method of how these are used together to set the overall gain. The method is to add gain to the LNA and mixer in alternating fashion (LNA-mixer-LNA-mixer), as listed in the function "r82xx_set_gain", using the gain values for each amp listed in "tuner_r82xx.c". And I think that there's a value missing in "r82xx_gains". According to my spreadsheet, there should also be a value of 483 between these last, two values. That means the last three values of this array would be "..., 480, 483, 496]". Mind you, this is a minor 0.3 dB of gain. This is also my OCD kicking in. I'm not a programmer, so I don't know if I'm understanding this correctly. If I am, I don't know if the correction is to just add this value to the array. Regards, Gary

1 0

[PATCH] Add RTL-SDR Blog V4L Support
by Carl Laufer 12 Aug '26

12 Aug '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

2 2

fl2k ARM patch
by Kiss Ádám 01 Aug '26

01 Aug '26

Dear Osmocom, I encountered instability using libfl2k on ARM architecture. Along optimizing my specific application; I added the necessary memory barrier logic to the lib to get it work. If the changes meet your standards, please consider merging them into the main repository. I am open for discussions. Kind regards, Ádám Kiss

1 0

[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