From fabstz-it at yahoo.fr Wed Oct 2 06:25:54 2019 From: fabstz-it at yahoo.fr (Fab Stz) Date: Wed, 02 Oct 2019 08:25:54 +0200 Subject: [rtl-sdr patch?] lib: retry i2c on failure Message-ID: <1713745.v7S4I1EGtK@debian> 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, From fabstz-it at yahoo.fr Wed Oct 2 08:58:36 2019 From: fabstz-it at yahoo.fr (Fab Stz) Date: Wed, 02 Oct 2019 10:58:36 +0200 Subject: [rtl-sdr patch?] lib: retry i2c on failure In-Reply-To: <1713745.v7S4I1EGtK@debian> References: <1713745.v7S4I1EGtK@debian> Message-ID: <7214638.7fGsGl3kPW@debian> 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, -------------- next part -------------- A non-text attachment was scrubbed... Name: lib rtlsdr_demod_write_reg try a 2nd time.patch.patch Type: text/x-patch Size: 884 bytes Desc: not available URL: From fabstz-it at yahoo.fr Wed Oct 2 09:23:42 2019 From: fabstz-it at yahoo.fr (Fab Stz) Date: Wed, 02 Oct 2019 11:23:42 +0200 Subject: [rtl-sdr patch?] lib: retry i2c on failure In-Reply-To: <7214638.7fGsGl3kPW@debian> References: <1713745.v7S4I1EGtK@debian> <7214638.7fGsGl3kPW@debian> Message-ID: <1790811.x3Zq29GRgE@debian> 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, From mueller at kit.edu Wed Oct 2 11:25:32 2019 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Wed, 2 Oct 2019 11:25:32 +0000 Subject: gr-osmosdr maintainer needed In-Reply-To: <20190928064507.GR15248@nataraja> References: <20190928064507.GR15248@nataraja> Message-ID: <6dfc5d0983d423fb9edc36b7f710d82a9f4848f0.camel@kit.edu> Dear Harald and Dimitri, dear Osmocom SDR community, I was out of commission for a couple of days, but I direly wanted to give my two cents to this: gr-osmosdr has been paramount to GNU Radio for quite a while ? it's been the de-facto standard hardware interface for anyone who didn't start his SDR endeavours by spending relatively big money on Ettus hardware. And, globally, that's probably a majority of users! Thus, whoever wants to take on gr-osmosdr: I can fully assure you that you'll have the GNU Radio community, and me personally, help you with that, especially in practical terms. Best regards, Marcus On Sat, 2019-09-28 at 08:45 +0200, Harald Welte wrote: > Dear Osmocom SDR community, > Dear Dimitri, > > the situation around gr-osmosdr has been deteriorating for years. > Among other things, I notice: > * there has not been a tagged release since 2014 > * patches (e.g. fixing clang support) are not merged > * there is no support for gnuradio 3.8 > > I raised at least some of this both on-list (in June 2018 at > http://lists.osmocom.org/pipermail/osmocom-sdr/2018-June/001766.html) > and off-list in personal discussions, e.g. at CCCamp2019 > > It is clear that technically there are alternatives these days > (mainly SoapySDR, which didn't exist when gr-osmosdr started in 2012). > > However, at the same time I'm seeing plenty of users asking about gr3.8 > support, as there are [probably] lots of existing applications which > are not ported to other input blocks. As the overall Osmocom project > leader, this puts me in a difficult position: I've never been involved > with gr-osmosdr myself, but I get various related e-mail which show that > there are users, and that they are struggling by a lack of maintenance. > > It appears that original author and maintainer Dimitri has lost time > and/or interest in maintaining gr-osmosdr. That's very sad, but it is a > fact that people have a limited amount of time, and priorities change. > I'd like to thank Dimitri and all other gr-osmosdr > developers/contributors for what they have done so far. > > But what has unfortunately been missed here during the last 1-2 years is > passing the project over to a new maintainer or group of maintainers. > Just because the original author is not around anymore, it doesn't mean > the project has to die. So with this message, I'm publicly calling for > some other community member[s] to step up and become maintainer[s] of > gr-osmosdr. > > Who is interested in gr-osmosdr and willing to maintain it, possibly in > a team with other interested folks? > > I would be more than happy to provide the respective accounts/access on > the osmocom.org redmine as well as the official osmocom.org upstream > repository. > > There's a list of open issues at http://osmocom.org/projects/gr-osmosdr/issues > > I know there are also many forks on github, including > > * https://github.com/igorauad/gr-osmosdr/tree/gr3.8 gr3.8 support > * https://github.com/xtrx-sdr/gr-osmosdr/ with xtrx support > * https://github.com/zhovner/gr-osmosdr and https://github.com/Sevyls/gr-osmosdr > with clang/MacOS related fix > * https://github.com/wirstrom/gr-osmosdr with soapy end-of-burst fix > * https://github.com/thegildedturtle/gr-osmosdr hackrf raspi signedness fix? > * https://github.com/ScanOC/gr-osmosdr print AirSpy serial number on connect > * https://github.com/romeojulietthotel/gr-osmosdr cosmetics > * https://github.com/racerxdl/gr-osmosdr spyserver support? > * https://github.com/rascustoms/gr-osmosdr airspy related patches > * https://github.com/newdreamlj/gr-osmosdr bladerf multi stream fix > * https://github.com/Lukeekul/gr-osmosdr bladerf pass source/sink args > * https://github.com/IW0HDV/gr-osmosdr perseus HF support > * https://github.com/dl1ksv/gr-osmosdr rs-hfiq support > * https://github.com/carpikes/gr-osmosdr/ hackRF AVX/SSE performance > * https://github.com/aports-ugly/gr-osmosdr gr3.8 + xtrx support > * https://github.com/amungo/gr-osmosdr ADSDR support > * https://github.com/0pq76r/gr-osmosdr/commits/master expose rtl-sdr gain stages > > So there's no shortage of interesting fixes and features to investigate > and/or merge, even beyond the 'make a release and port to gr3.8'. > > Thanks in advance! > > Regards, > Harald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6582 bytes Desc: not available URL: From steve at steve-m.de Wed Oct 2 20:26:17 2019 From: steve at steve-m.de (Steve Markgraf) Date: Wed, 2 Oct 2019 22:26:17 +0200 Subject: [rtl-sdr patch?] lib: retry i2c on failure In-Reply-To: <1713745.v7S4I1EGtK@debian> References: <1713745.v7S4I1EGtK@debian> Message-ID: Hi, On 02.10.19 08:25, Fab Stz wrote: > 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 This is weird, I haven't seen this issue before. Which USB host controller are you using, which OS and which version of libusb? -9 is LIBUSB_ERROR_PIPE, which means that the device probably sent a STALL, which again is very weird given that this issue never occured before for multiple users in the past. How often does this problem occur? Best Regards, Steve From fabstz-it at yahoo.fr Thu Oct 3 06:26:17 2019 From: fabstz-it at yahoo.fr (Fab Stz) Date: Thu, 03 Oct 2019 08:26:17 +0200 Subject: [rtl-sdr patch?] lib: retry i2c on failure In-Reply-To: References: <1713745.v7S4I1EGtK@debian> Message-ID: <1666826.aD4OdhAyYi@debian> 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 -------------- next part -------------- [36076.696051] usb 1-8: new high-speed USB device number 7 using xhci_hcd [36076.875854] usb 1-8: New USB device found, idVendor=0bda, idProduct=2838, bcdDevice= 1.00 [36076.875858] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [36076.875860] usb 1-8: Product: RTL2838UHIDIR [36076.875861] usb 1-8: Manufacturer: Realtek [36076.875863] usb 1-8: SerialNumber: 00000001 [36076.893843] usb 1-8: dvb_usb_v2: found a 'Realtek RTL2832U reference design' in warm state [36077.003944] usb 1-8: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [36077.003954] dvbdev: DVB: registering new adapter (Realtek RTL2832U reference design) [36077.097576] i2c i2c-8: Added multiplexed i2c bus 9 [36077.097579] rtl2832 8-0010: Realtek RTL2832 successfully attached [36077.097592] usb 1-8: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))... [36077.097674] r820t 9-001a: creating new instance [36077.110893] r820t 9-001a: Rafael Micro r820t successfully identified [36077.113479] rtl2832_sdr rtl2832_sdr.0.auto: Registered as swradio0 [36077.113481] rtl2832_sdr rtl2832_sdr.0.auto: Realtek RTL2832 SDR attached [36077.113483] rtl2832_sdr rtl2832_sdr.0.auto: SDR API is still slightly experimental and functionality changes may follow [36077.137899] Registered IR keymap rc-empty [36077.137949] rc rc0: Realtek RTL2832U reference design as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-8/rc/rc0 [36077.137995] input: Realtek RTL2832U reference design as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-8/rc/rc0/input18 [36077.138108] rc rc0: lirc_dev: driver dvb_usb_rtl28xxu registered at minor = 0, raw IR receiver, no transmitter [36077.138172] usb 1-8: dvb_usb_v2: schedule remote query interval to 200 msecs [36077.157882] usb 1-8: dvb_usb_v2: 'Realtek RTL2832U reference design' successfully initialized and connected -------------- next part -------------- Bus 001 Device 007: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x2838 RTL2838 DVB-T bcdDevice 1.00 iManufacturer 1 Realtek iProduct 2 RTL2838UHIDIR iSerial 3 00000001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0022 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 4 USB2.0-Bulk&Iso bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 5 Bulk-In, Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 5 Bulk-In, Interface Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 2 Device Status: 0x0000 (Bus Powered) can't get debug descriptor: Resource temporarily unavailable -------------- next part -------------- /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 10000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M |__ Port 8: Dev 7, If 0, Class=Vendor Specific Class, Driver=dvb_usb_rtl28xxu, 480M |__ Port 8: Dev 7, If 1, Class=Vendor Specific Class, Driver=, 480M -------------- next part -------------- A non-text attachment was scrubbed... Name: test.cpp Type: text/x-c++src Size: 2767 bytes Desc: not available URL: From 246tnt at gmail.com Wed Oct 16 19:13:27 2019 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 16 Oct 2019 21:13:27 +0200 Subject: [USRP-users] FOSDEM 2020: Free Software Radio Devroom CfP In-Reply-To: References: Message-ID: CC to osmocom sdr ML > Dear friends and fans of software-defined radio and free/open-source radio topics in general, > > FOSDEM 2020 (the free and open-source developer's meeting in Brussels, Europe) will, once again, feature a track on Software Defined Radio, and any other radio-related topics in the (now known as) Free Software Radio devroom. Therefore, we invite developers and users from the free software radio community to join us for this track and present your talks or demos. > > > Software Radio has become an important tool to allow anyone to access the EM spectrum. Using free software radio libraries and applications and cheap hardware, anyone can now start hacking on wireless communications, remote sensing, radar, fun hacks of all sorts, or other applications. At FOSDEM, we hope to network all these projects and improve collaboration, bring new ideas forward and get more people involved. > > > The track's web site resides at the link below. The final schedule will be available through Pentabarf and the official FOSDEM website. > > https://fosdem.org/2020/schedule/track/free_software_radio/ > > > Additional Information will be also available at: https://wiki.gnuradio.org/index.php/FOSDEM_2020 > > > ** Submit your presentations > > To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM20 and follow the instructions (you need an account, but can use your account from last year if you have one). You need to create an 'Event'; make sure it's in the Free Software Radio track! Lengths aren't fixed, but give a realistic estimate and please don't exceed 30 minutes unless you have something special planned (in that case, contact one of us). Also, don't forget to include time for Q&A. > We will typically go for 30-minute slots -- shorter talks, unless they're really short, usually tend to screw up the schedule too much. > > You aren't limited to slide presentations, of course. Be creative. However, FOSDEM is an open-source conference, therefore we ask you to stay clear of marketing presentations and present something relevant to free/open software. We like nitty-gritty technical stuff. > > Topics discussed in this devroom include: > > * SDR Frameworks + Tools > * Cellular/telecoms software > * Free/Open SDR hardware > * Wireless security > * Random fun wireless hacks > * SDR in education > * Satellite/spacecraft communication > * Ham radio related topics > > > ** Important Dates > > FOSDEM is February 1st and 2nd, 2020. The Free Software Radio devroom is happening on Sunday, the 2nd of February. > > The submission deadline is Friday, December 6th. A complete schedule for the presentations in the devroom will be available on the 15th of December. > > > In the last years we were always full to the brim with presentations, so if you want to present, please make sure to submit your abstracts soon! > > ** Steering Committee > The track committee consists of: > > * Phil Balister - "Crofton" > * Sylvain Munaut -"tnt" > * Derek Kozel - "dkozel" > * Nicolas Cuervo - "primercuervo" > * Martin Braun - "mbr0wn" (Emeritus) Cheers, Sylvain From fabstz-it at yahoo.fr Wed Oct 16 19:16:20 2019 From: fabstz-it at yahoo.fr (Fab Stz) Date: Wed, 16 Oct 2019 21:16:20 +0200 Subject: [rtl-sdr patch?] lib: retry i2c on failure In-Reply-To: <1666826.aD4OdhAyYi@debian> References: <1713745.v7S4I1EGtK@debian> <1666826.aD4OdhAyYi@debian> Message-ID: <2432555.e9P9R5kIif@debian> Hello, Any advice ? Thanks Le jeudi 3 octobre 2019, 08:26:17 CEST Fab Stz a ?crit : > 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 From steve at steve-m.de Wed Oct 16 19:51:44 2019 From: steve at steve-m.de (Steve Markgraf) Date: Wed, 16 Oct 2019 21:51:44 +0200 Subject: [rtl-sdr patch?] lib: retry i2c on failure In-Reply-To: <2432555.e9P9R5kIif@debian> References: <1713745.v7S4I1EGtK@debian> <1666826.aD4OdhAyYi@debian> <2432555.e9P9R5kIif@debian> Message-ID: 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 From fabstz-it at yahoo.fr Thu Oct 17 08:11:14 2019 From: fabstz-it at yahoo.fr (Fab Stz) Date: Thu, 17 Oct 2019 10:11:14 +0200 Subject: [rtl-sdr patch?] lib: retry i2c on failure In-Reply-To: References: <1713745.v7S4I1EGtK@debian> <2432555.e9P9R5kIif@debian> Message-ID: <2663614.fX2PbdSyfL@debian> Hello, 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 From fabstz-it at yahoo.fr Sat Oct 26 08:28:56 2019 From: fabstz-it at yahoo.fr (Fab Stz) Date: Sat, 26 Oct 2019 10:28:56 +0200 Subject: [rtl-sdr patch?] lib: retry i2c on failure In-Reply-To: References: <1713745.v7S4I1EGtK@debian> <2432555.e9P9R5kIif@debian> Message-ID: <5782179.HyYFhM7rRI@debian> 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