After a few tests, both are actually needed :

https://github.com/steve-m/librtlsdr/pull/56 -> Fixes both "r82xx_write: i2c wr failed=-9 reg=17 len=1" & "r82xx_set_freq: failed=-9"

https://github.com/steve-m/librtlsdr/pull/58 -> Fixes "rtlsdr_demod_write_reg failed with -9" by a 2nd try

Regards,

Le mercredi 2 octobre 2019, 10:58:36 CEST Fab Stz a écrit :

Hello,

Actually, relaunching the call of libusb_control_transfer in rtlsdr_demod_write_reg

does the trick for all three messages and sets the frequency correctly without error message. This seems to fix also the gain not being set.

The call of rtlsdr_demod_read_reg is necessary before recalling libusb_control_transfer, if we juste call libusb_control_transfer a 2nd time this doesn't work.

The patch in my initial post is not necessary if this one is applied.

Pull request: https://github.com/steve-m/librtlsdr/pull/58

Regards

Le mercredi 2 octobre 2019, 08:25:54 CEST Fab Stz a écrit :

...

Hello,

When doing a setFrequency I usually have this error afterwards and the frequency is actually not changed

rtlsdr_demod_write_reg failed with -9 r82xx_write: i2c wr failed=-9 reg=17 len=1 r82xx_set_freq: failed=-9

By searching around I found this commit that makes the trick for me. https://github.com/keenerd/rtl-sdr/commit/ 9ed9ffa37e24f3293fa960cfcd74909ac3e9996c

This will actually really set the frequency and remove the last 2 errors related to "r82xx". The only error remaining is then

rtlsdr_demod_write_reg failed with -9

If you can include that upstream that would be nice. I created a pull request here : https://github.com/steve-m/librtlsdr/pull/56

Actually the commit is part of a large PR that you may be interested in ? https://github.com/keenerd/rtl-sdr/pull/8

Regards,

Hello

Le mercredi 2 octobre 2019 22:26:17 CEST, vous avez écrit :

This is weird, I haven't seen this issue before. Which USB host controller are you using, which OS and which version of libusb?

This is with debian buster (=stable) with libusb 1.0 : libusb-1.0-0:amd64 version 2:1.0.22-2

What do you mean by USB Host Controller ? I attached a few files

When connected to rear USB 3.1gen1 : OK rear USB 3.1gen2 : KO front USB 2 : KO front USB 3.1gen1 : KO

according to MB specs (asus PRIME b450M-a: rear USB3.1 gen1 is controlled by CPU : Athlon200GE the 3 other are controlled by chipset B450M

How often does this problem occur?

Quite often. For ex when running welle.io 2.0 beta3 the ferquency gets set once and never changes again. A way to get around it, is to call cancel_async before setting the frenquency.

But I have that error also without reading any data. with the sample test code attached.

Regards

Hi,

On 16.10.19 21:16, Fab Stz wrote:

Any advice ?

I just tried your test program and cannot replicate your issue using Ubuntu 19.04 and libusb 1.0.22 with an Intel host controller. I don't think re-trying USB transactions is the righ way to go, there is either some issue with your hardware or driver support of your system. Have you tried using a more recent Kernel?

Regards, Steve

Hello,

Any idea ?

Le mercredi 16 octobre 2019 21:51:44 CEST, vous avez écrit :

Have you tried using a more recent Kernel?

I just tried with kernel 5.2.17 (libusb also 1.0.22) and still have the issue.

there is either some issue with your hardware or driver support of your system

Do you mean the RTL-SDR key or the motherboard ? I also updated my BIOS to the latest version but that didn't fix it either.

There seems to be an issue when the USB slot I use is one controlled by the chipset (B450) and not when controlled by the CPU (Athlon200GE). Could that be cause ? Does that mean a buggy bios ? Or a buggy kernel ?

Regards, Fab