osmocom-sdr

osmocom-sdr@lists.osmocom.org

917 discussions

Re: New SDR dongle received but cannot get it to work
by John 24 Oct '17

24 Oct '17

Cinead, My apologies for this and thanks for your clarification. I have followed thorough with the suggestions made by yourself and Marcus, including installing the provided ruleset and checking the device power usage. I have also tried another USB cable and another computer. However I did miss the point you made about leaving off the '-t' in the detail of your original response. Also, I have been responding to the messages I received from the mailing list thinking that I was responding to the mailing list, but it seems that I have actually been responding directly to individuals. This was unintentional and I apologise, but the e-mail 'From:' header on the messages I have received from the list shows the e-mail address of the individual who sent the message rather than the mailing list address which seems rather unusual. It means I have to manually copy in the 'osmocom-sdr(a)lists.osmocom.org' address into the 'To:' header each time I reply, as I have done in this case. So this is what I get with just rtl_test: $ rtl_test Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM usb_claim_interface error -5 Failed to open rtlsdr device #0. Its the same whether I run it as user or with root privileges. I don't see the dvb_usb_rtl28xxu kernel driver being loaded in the output of lsmod. > > Okay, if you send another email with output of > > rtl_test -t > > I'm going to blacklist your email address. > > Use > > rtl_test > > to run the test for a 2832. > > Use > > rtl_test -t > > to run the test for a 2838. > > Type > > rtl_test --help > > It clearly indicates the -t flag in rtl_test is for the E4000. > > The system claims you have a 2832 - and not a 2838 or E4000 - so get > over it. > > Clear enough? > > >> Found 1 device(s): >> 0: Realtek, RTL2838UHIDIR, SN: 00000001 >> >> Using device 0: Generic RTL2832U OEM >> Found Rafael Micro R820T tuner > > This is your device: > > Using device 0: Generic RTL2832U OEM > Found Rafael Micro R820T tuner > > It clearly states it's a RTL2832 device with a Rafael Micro R820T tuner. > > >> r82xx_write: i2c wr failed=-1 reg=1a len=7 >> r82xx_write: i2c wr failed=-1 reg=0c len=1 >> r82xx_init: failed=-1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 >> 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 >> 43.4 43.9 44.5 48.0 49.6 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> r82xx_write: i2c wr failed=-1 reg=0a len=1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> WARNING: Failed to set sample rate. >> No E4000 tuner found, aborting. > > No E4000 tuner found, aborting. > > This statement clearly indicates your device is NOT a E4000 - or a 2838. > >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_write_reg failed with -1 >> > > Did you remove the your home brewed file from /etc/udev/rules.d? If not > then remove it and reboot. > > Send me a listing of > > /etc/modprobe.d > > and the contents of the file you're using to blacklist the RTL devices. > > Also, update your system listing and install the following > > apt-get update > apt-get install librtlsdr-dev > apt-get install libusb-1.0-0-dev > > What type of computer are you using? If you're using a computer with > more than 1 USB port, try plugging the dongle into another port. > > It's possible the RTL dongle is bad or you have problems with your USB > ports - but you need to eliminate system possible system software issues > first. > > -- Cinaed > > >>> Cinaed Simson<mailto:cinaed.simson@gmail.com> >>> 22 October 2017 03:53 >>> On 10/21/2017 09:08 AM, John wrote: >>>> Hello, >>>> >>>> I am new to this list and to SDR radio. I have purchased an SDR dongle >>>> but am having trougble getting it to work. The dongle was described as >>>> an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and >>>> lsusb detects the device as follows: >>>> >>>> Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T >>>> >>>> Is it an RTL2832U or an RTL2838? I'm not really sure. >>>> >>>> > From research it seems that It seems like the fist order of business is >>>> to blacklist the kernel driver? So I have done this by adding a >>>> backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I >>>> have also added a rules file to /etc/udev/rules.d with the following >>>> content: >>>> >>>> # Realtek Semiconductor Corp. RTL2838 DVB-T >>>> SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", >>>> MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr" >>>> >>>> I can now access the device in user mode without permission errors so I >>>> assume that this is working OK. >>>> >>>> So my next step was to run rtl_test -t. The output I got contained >>>> errors.If I then try to run any sdr software such as rtl_fm or gqrx, the >>>> device is reset and the application fails to run. Subsequentlly running >>>> 'rtl_test -t' gives: >>>> >>>> No supported devices found. >>>> >>>> Even running rtl_test-t sometimes does the same so i'm not sure whether >>>> the device is 'dropping out' of its own accord. >>>> >>>> I am wondering whether the current crop of devices are supported? Or is >>>> this a configuration problem? >>>> >>>> >>>> The output from rtl_test: >>>> >>>> rtl_test -t >>> The output from rtl_test indicates it's a "2832" - but your home brewed >>> rule is probing for a "2838" which is the E4000. >>> >>> I recommend you install the enclosed udev rules. >>> >>> After you copy them to /etc/udev/rules.d, try >>> >>> udevadm control --reload >>> udevadm trigger >>> >>> If that doesn't work, reboot. >>> >>> The correct rules should have been installed when you installed the >>> sofware - so you may have other problems. >>> >>> And use >>> >>> rtl_test >>> >>> The command >>> >>> rtl_test -t >>> >>> is for the E4000 - and your enclosed error message indicates it's not E4000. >>> >>> -- Cinaed >>> >>>> Found 1 device(s): >>>> 0: Realtek, RTL2838UHIDIR, SN: 00000001 >>>> >>>> Using device 0: Generic RTL2832U OEM >>>> Found Rafael Micro R820T tuner >>>> r82xx_write: i2c wr failed=-1 reg=13 len=7 >>>> r82xx_write: i2c wr failed=-1 reg=0c len=1 >>>> r82xx_init: failed=-1 >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 >>>> 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 >>>> 43.4 43.9 44.5 48.0 49.6 >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> r82xx_write: i2c wr failed=-1 reg=0a len=1 >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> WARNING: Failed to set sample rate. >>>> No E4000 tuner found, aborting. >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> rtlsdr_demod_write_reg failed with -1 >>>> rtlsdr_demod_read_reg failed with -1 >>>> rtlsdr_write_reg failed with -1 >>>> >>>> >>>> >>> John<mailto:subs@qcontinuum.plus.com> >>> 21 October 2017 17:08 >>> Hello, >>> >>> I am new to this list and to SDR radio. I have purchased an SDR dongle >>> but am having trougble getting it to work. The dongle was described as >>> an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and >>> lsusb detects the device as follows: >>> >>> Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 >>> DVB-T >>> >>> Is it an RTL2832U or an RTL2838? I'm not really sure. >>> >>> From research it seems that It seems like the fist order of business >>> is to blacklist the kernel driver? So I have done this by adding a >>> backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I >>> have also added a rules file to /etc/udev/rules.d with the following >>> content: >>> >>> # Realtek Semiconductor Corp. RTL2838 DVB-T >>> SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", >>> MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr" >>> >>> I can now access the device in user mode without permission errors so >>> I assume that this is working OK. >>> >>> So my next step was to run rtl_test -t. The output I got contained >>> errors.If I then try to run any sdr software such as rtl_fm or gqrx, >>> the device is reset and the application fails to run. Subsequentlly >>> running 'rtl_test -t' gives: >>> >>> No supported devices found. >>> >>> Even running rtl_test-t sometimes does the same so i'm not sure >>> whether the device is 'dropping out' of its own accord. >>> >>> I am wondering whether the current crop of devices are supported? Or >>> is this a configuration problem? >>> >>> >>> The output from rtl_test: >>> >>> rtl_test -t >>> Found 1 device(s): >>> 0: Realtek, RTL2838UHIDIR, SN: 00000001 >>> >>> Using device 0: Generic RTL2832U OEM >>> Found Rafael Micro R820T tuner >>> r82xx_write: i2c wr failed=-1 reg=13 len=7 >>> r82xx_write: i2c wr failed=-1 reg=0c len=1 >>> r82xx_init: failed=-1 >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 >>> 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 >>> 43.4 43.9 44.5 48.0 49.6 >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> r82xx_write: i2c wr failed=-1 reg=0a len=1 >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> WARNING: Failed to set sample rate. >>> No E4000 tuner found, aborting. >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> rtlsdr_demod_write_reg failed with -1 >>> rtlsdr_demod_read_reg failed with -1 >>> rtlsdr_write_reg failed with -1 >>> >>> >>> >> -- >> John > > John <mailto:subs@qcontinuum.plus.com> > 22 October 2017 17:02 > Cinead, > > Thank you for this information and the ruleset. I have been looking > for an 'official' ruleset to try, but couln't find one. For whatever > reason a ruleset was not automatically installed. However, I installed > the software from the repository via apt-get rtl-sdr rather than > downloading and compiling. > > I have now removed the file I created and installed the one you > provided. Unfortunately it made no difference. I initially used just > the two udev commands to re-initialise udev, but then also rebooted > for good measure. > > You observation is interesting however, as this device identifies > itself as vendorID '0bda' and deviceID '2838' in lsusb: > > Bus 002 Device 012: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T > > and likewise in dmesg: > > [ 622.683133] usb 2-1.6: new high-speed USB device number 12 using > ehci-pci > [ 622.787405] usb 2-1.6: New USB device found, idVendor=0bda, > idProduct=2838 > [ 622.787410] usb 2-1.6: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 622.787413] usb 2-1.6: Product: RTL2838UHIDIR > [ 622.787415] usb 2-1.6: Manufacturer: Realtek > [ 622.787417] usb 2-1.6: SerialNumber: 00000001 > > As you point out however, it has an R820T tuner, which has now been > visually confirmed by the markings on the IC, so if RTL and other > programs are expecting an E4000 then this is probably not going to > work. I expect that the device will always match the second rule in > the ruleset and it seems that it is possible to access the device in > user mode. However I'm not sure how to get around the expectations of > the driver? Curiously the second rule refers to 'Newsky TV28T > (E4000/R820T)' which mentions both radios for the same product ID, so > then one might expect that the driver looks for either and tries to > determine which it is? > > rtl_test seemed to identify it correctly - 'Found Rafael Micro R820T > tuner' but then then also fails to find an E4000 radio 'No E4000 tuner > found, aborting.' so my assumption was that it was trying to determine > which one was present, but then I am not familiar with the code. > > So the question in my mind is whether rtl_test is indeed making a > determination and the errors are due to a problem communicating with > the device, or whether it is looking for E4000 hardware as you say and > failing because it is sending inappropriate commands. If the latter, > then is there a way to fool it, e.g. by temporarily changing the > device ID or forcing the driver to communicate with an RT820T radio? > > I did find the -d flag and tried rtl_test -d0 but this yielded a > similar response, although it did not identify any tuner and simply > returned 'No supported tuner found'. > > The full output is below: > > $ rtl_test -t > Found 1 device(s): > 0: Realtek, RTL2838UHIDIR, SN: 00000001 > > Using device 0: Generic RTL2832U OEM > Found Rafael Micro R820T tuner > r82xx_write: i2c wr failed=-1 reg=1a len=7 > r82xx_write: i2c wr failed=-1 reg=0c len=1 > r82xx_init: failed=-1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 > 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 > 43.4 43.9 44.5 48.0 49.6 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > r82xx_write: i2c wr failed=-1 reg=0a len=1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > WARNING: Failed to set sample rate. > No E4000 tuner found, aborting. > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_write_reg failed with -1 > > > > > > Cinaed Simson <mailto:cinaed.simson@gmail.com> > 22 October 2017 03:53 > On 10/21/2017 09:08 AM, John wrote: >> Hello, >> >> I am new to this list and to SDR radio. I have purchased an SDR dongle >> but am having trougble getting it to work. The dongle was described as >> an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and >> lsusb detects the device as follows: >> >> Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T >> >> Is it an RTL2832U or an RTL2838? I'm not really sure. >> >> From research it seems that It seems like the fist order of business is >> to blacklist the kernel driver? So I have done this by adding a >> backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I >> have also added a rules file to /etc/udev/rules.d with the following >> content: >> >> # Realtek Semiconductor Corp. RTL2838 DVB-T >> SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", >> MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr" >> >> I can now access the device in user mode without permission errors so I >> assume that this is working OK. >> >> So my next step was to run rtl_test -t. The output I got contained >> errors.If I then try to run any sdr software such as rtl_fm or gqrx, the >> device is reset and the application fails to run. Subsequentlly running >> 'rtl_test -t' gives: >> >> No supported devices found. >> >> Even running rtl_test-t sometimes does the same so i'm not sure whether >> the device is 'dropping out' of its own accord. >> >> I am wondering whether the current crop of devices are supported? Or is >> this a configuration problem? >> >> >> The output from rtl_test: >> >> rtl_test -t > > The output from rtl_test indicates it's a "2832" - but your home brewed > rule is probing for a "2838" which is the E4000. > > I recommend you install the enclosed udev rules. > > After you copy them to /etc/udev/rules.d, try > > udevadm control --reload > udevadm trigger > > If that doesn't work, reboot. > > The correct rules should have been installed when you installed the > sofware - so you may have other problems. > > And use > > rtl_test > > The command > > rtl_test -t > > is for the E4000 - and your enclosed error message indicates it's not E4000. > > -- Cinaed > >> Found 1 device(s): >> 0: Realtek, RTL2838UHIDIR, SN: 00000001 >> >> Using device 0: Generic RTL2832U OEM >> Found Rafael Micro R820T tuner >> r82xx_write: i2c wr failed=-1 reg=13 len=7 >> r82xx_write: i2c wr failed=-1 reg=0c len=1 >> r82xx_init: failed=-1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 >> 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 >> 43.4 43.9 44.5 48.0 49.6 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> r82xx_write: i2c wr failed=-1 reg=0a len=1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> WARNING: Failed to set sample rate. >> No E4000 tuner found, aborting. >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_demod_write_reg failed with -1 >> rtlsdr_demod_read_reg failed with -1 >> rtlsdr_write_reg failed with -1 >> >> >> > > John <mailto:subs@qcontinuum.plus.com> > 21 October 2017 17:08 > Hello, > > I am new to this list and to SDR radio. I have purchased an SDR dongle > but am having trougble getting it to work. The dongle was described as > an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and > lsusb detects the device as follows: > > Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 > DVB-T > > Is it an RTL2832U or an RTL2838? I'm not really sure. > > From research it seems that It seems like the fist order of business > is to blacklist the kernel driver? So I have done this by adding a > backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I > have also added a rules file to /etc/udev/rules.d with the following > content: > > # Realtek Semiconductor Corp. RTL2838 DVB-T > SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", > MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr" > > I can now access the device in user mode without permission errors so > I assume that this is working OK. > > So my next step was to run rtl_test -t. The output I got contained > errors.If I then try to run any sdr software such as rtl_fm or gqrx, > the device is reset and the application fails to run. Subsequentlly > running 'rtl_test -t' gives: > > No supported devices found. > > Even running rtl_test-t sometimes does the same so i'm not sure > whether the device is 'dropping out' of its own accord. > > I am wondering whether the current crop of devices are supported? Or > is this a configuration problem? > > > The output from rtl_test: > > rtl_test -t > Found 1 device(s): > 0: Realtek, RTL2838UHIDIR, SN: 00000001 > > Using device 0: Generic RTL2832U OEM > Found Rafael Micro R820T tuner > r82xx_write: i2c wr failed=-1 reg=13 len=7 > r82xx_write: i2c wr failed=-1 reg=0c len=1 > r82xx_init: failed=-1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 > 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 > 43.4 43.9 44.5 48.0 49.6 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > r82xx_write: i2c wr failed=-1 reg=0a len=1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > WARNING: Failed to set sample rate. > No E4000 tuner found, aborting. > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_write_reg failed with -1 > > > -- John

2 1

New SDR dongle received but cannot get it to work
by John 22 Oct '17

22 Oct '17

Hello, I am new to this list and to SDR radio. I have purchased an SDR dongle but am having trougble getting it to work. The dongle was described as an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and lsusb detects the device as follows: Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Is it an RTL2832U or an RTL2838? I'm not really sure. From research it seems that It seems like the fist order of business is to blacklist the kernel driver? So I have done this by adding a backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I have also added a rules file to /etc/udev/rules.d with the following content: # Realtek Semiconductor Corp. RTL2838 DVB-T SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr" I can now access the device in user mode without permission errors so I assume that this is working OK. So my next step was to run rtl_test -t. The output I got contained errors.If I then try to run any sdr software such as rtl_fm or gqrx, the device is reset and the application fails to run. Subsequentlly running 'rtl_test -t' gives: No supported devices found. Even running rtl_test-t sometimes does the same so i'm not sure whether the device is 'dropping out' of its own accord. I am wondering whether the current crop of devices are supported? Or is this a configuration problem? The output from rtl_test: rtl_test -t Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner r82xx_write: i2c wr failed=-1 reg=13 len=7 r82xx_write: i2c wr failed=-1 reg=0c len=1 r82xx_init: failed=-1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 r82xx_write: i2c wr failed=-1 reg=0a len=1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 WARNING: Failed to set sample rate. No E4000 tuner found, aborting. rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_write_reg failed with -1 -- John

3 2

build-gnuradio
by Martin McCormick 20 Oct '17

20 Oct '17

I am running Debian 7 on a system and Debian 8 on two other PC's and a raspberry PI and having no luck on running the build-gnuradio script. All the Debian 8 systems get as far as stating that the version is unsupported and that's it. The Debian 7 system (wheezy) goes through a number of tests before bombing on not being able to execute certain processes but it appears to get farther than any of the Debian 8 (jessie) systems so it appears that Debian 7 is closest. Is there any place in the script to find a version number so as to be sure that this script is the latest version? I would like to try to receive DMR transmissions as well as try some of the other interesting decoding possibilities but so far, nothing but failure to launch. Thanks for any constructive ideas. Martin McCormick

2 2

Planning for OsmoCon + OsmoDevCon
by Harald Welte 14 Oct '17

14 Oct '17

[cross-post to many lists, please follow-up-to openbsc(a)lists.osmocom.org] Dear all, time is flying, and I would like to start early with discussions and planning about OsmoCon and OsmoDevCon in 2018. It helps to start early. Side note: We have some pending issues about the events from last year at http://osmocom.org/projects/osmo-dev-con/issues - I've incorporated them in the text below. == OsmoDevCon == For OsmoDevCon, I think it's easy: We keep it as-is. Same procedure as every year, which means: * same venue, same catering options * same concept of 'anyone contributing to Osmocom can apply for registration until all seats are taken' * same idea of inviting some few speaker[s] doing other FOSS mobile communications work to join us The parts that we need to change, IMHO: * don't reduce from 4 to 3 days like last year. Have full 4 days again * sort topics per day / half-day, i.e. have "GSM/UMTS Cellular Infrastructure" days for BTS/BSC/NITB/MSC/HLR/SGSN/GGSN & Co, but then have other days for other projects. This would enable people not interested in the [continued evolvement] of the cellular projects be able to skip those days, or to simply meet in an adjacent room for parallel hacking sessions/discussions * try to be a bit more structured with the schedule in general. The existing approach works for people who attend all the event all day long, but not so well for people with other plans / limited time Any further change requests or topics to discuss? Please note that Pablo Neira has offered to kindly host an OsmoDevCon in Seville (Spain). I've attended a number of netfilter workshops he organized there, and he's doing a great job! However, given the large number of attendees from Berlin (and Germany in general), I think this would make things more complicated, and more expensive for most attendees. If you disagree with that assessment: I'm open for having the discussion, I just thought it's more practical/economic to do it in Berlin. === 10 year Anniversary Party === Given that 2018 marks the 10 year anniversary of Dieter and me hacking with the Siemens BS-11 in 2008, I think the 2018 incarnation deserves some special celebration of some form. I have no concrete idea yet, but for sure we should so something, and it should be at/around OsmoDevCon. And for sure we should have a BS-11 around :) == OsmoCon == The public OsmoCon was welcomed and was a success. However, let's start this discussion with a review of last years event. === Registration === * Registrations came in way too late. Two weeks ahead of the event, we were considering to cancel it. And then within the last few days, we had to turn people down due to limited seating capacity * To make planning more reliable, we see on other option but to significantly raise the registration fee combined with an equally significant discount for early booking === Duration === * Many people requested multiple days rather than just one, in order to make more out of (long distance) travels. This is obvious, but as we had no idea how many people would attend at all (or if we have to cancel due to lack of attendance), planning multiple days in the first incarnation would have been high risk and a multitude of work * I would suggest to expand to two or even three days this week, possibly one days with tutorials and the other day with tech talks * Slightly less crammed schedule due to multiple days === Venue === We recognize this yearso venue was not the best option, due to * Bad ventilation in the basemenet * Difficult to find * No space next to the conference room where people can meet / hang out in parallel to talks (not everyone attends every talk) I still like the "understatement" of the venue. I'd prefer any hostel / non-profit / hackerspace / university over luxurious hotels any time. Going to an expensive venue means more or less automatically more expensive ticket fees, which again is more likely to exclude pure community members without a commercial activity related to Osmocom. So any future venue would ideally: * be able to hold slightly more people than this year * have a second room or large lobby in which people can meet for extended coffee breaks in parallel to some talks, as needed * be slightly easier to find (and we have to put up some signs outside and in the lobby) * have better WiFi and/or wired connectivity === Programme / Format === * less crammed over multiple days * some more "interactive" formats were requested, for users to provide feedback to developers * there was some discussion about topics / speakers in redmine last year, but not too much participation [until it was too late]. * I'd suggest a more formal CfP process with a submission deadline that allows us to publish a preliminary schedule long ahead of the event === Video Recordings === I think they were a big success, and it was a very big surprise that the CCC Video Operations Center was volunteering to help such a small and niche-interest event like OsmoCon. We should make sure that we can repeat this for 2018. == Dates / Frequency == Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if OsmoCon is 2-3 days and OsmoDevCon is 4 days. Basically we're looking at a full week for those of you who would like to attend both events. But then, I think the number of people attending both events is actually not all that big. Without checking the details, I think not more than half of the OsmoDevCon attendees were attending OsmoCon. I would expect that tendency to remain or even increase. I still think it's good to keep them back-to-back. In terms of frequency, I would actually suggest we move to a 6-month cycle rather than a 12-month cycle. There's a lot of development going on at all time. I understand that not everyone is able to attend two events just on Osmocom, especially if it's a spare time / hobby type activity. That's ok, I think there's no problem with attending either of the two only, and catching up by video recordings and/or mail on the other. The qeustion is: Should that second event be developer-oriented or user-oriented? Or again both? Any comments here? Ok, that was a somewhat lengthy e-mail. Please make sure to provide any feedback you may have as early as possible, to increase the chances of your feedback being reflected in the planning. Happy hacking, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

[PATCH] Fix a segfault in soapy_source_c
by Vasil Velichkov 05 Oct '17

05 Oct '17

When the get_gain_names(chan) returns an empty vector calls set_gain(gain, chan) instead of set_gain(gain, names.front(), chan); (gdb) bt #0 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (__str=..., this=0x7fffffffdb10) at /usr/include/c++/7/bits/basic_string.h:424 #1 soapy_source_c::set_if_gain (this=0x555556b85250, gain=32, chan=0) at ./lib/soapy/soapy_source_c.cc:257 #2 0x00007fffdf0b82a4 in source_impl::set_if_gain (this=0x555555bb6f30, gain=32, chan=<optimized out>) at ./lib/source_impl.cc:708 #3 0x00007fffdf3a860d in _wrap_source_sptr_set_if_gain (args=<optimized out>, kwargs=<optimized out>) at ./obj-x86_64-linux-gnu/swig/osmosdr_swigPYTHON_wrap.cxx:23069 #4 0x000055555564f3ca in call_function (oparg=<optimized out>, pp_stack=0x7fffffffdd10) at ../Python/ceval.c:4352 --- lib/soapy/soapy_source_c.cc | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/lib/soapy/soapy_source_c.cc b/lib/soapy/soapy_source_c.cc index a645361..e9e7377 100644 --- a/lib/soapy/soapy_source_c.cc +++ b/lib/soapy/soapy_source_c.cc @@ -253,16 +253,24 @@ double soapy_source_c::get_gain( const std::string & name, size_t chan ) double soapy_source_c::set_if_gain( double gain, size_t chan ) { - //docs specify RF gain is the first element - const std::string name = this->get_gain_names(chan).front(); - return this->set_gain(gain, name, chan); + std::vector<std::string> names = this->get_gain_names(chan); + if (names.length()) { + //docs specify RF gain is the first element + return this->set_gain(gain, names.front(), chan); + } else { + return this->set_gain(gain, chan); + } } double soapy_source_c::set_bb_gain( double gain, size_t chan ) { - //docs specify baseband gain is the last element - const std::string name = this->get_gain_names(chan).back(); - return this->set_gain(gain, name, chan); + std::vector<std::string> names =this->get_gain_names(chan); + if (names.length()) { + //docs specify baseband gain is the last element + return this->set_gain(gain, names.back(), chan); + } else { + return this->set_gain(gain, chan); + } } std::vector< std::string > soapy_source_c::get_antennas( size_t chan ) -- 2.13.6

1 0

[PATCH] output calculated ppm to stderr
by Андрей Родионов 23 Sep '17

23 Sep '17

Good day, I found an issue, when i call rtl_test from external program with "-p” argument. PPM is written into stdout, which means it will be automatically flushed on interactive shell or when fflush called manually. Neither of this was used. All other output was written to stderr, hence simple patch: diff --git a/src/rtl_test.c b/src/rtl_test.c index 9a6cfda..c7e60c5 100644 --- a/src/rtl_test.c +++ b/src/rtl_test.c @@ -202,7 +202,7 @@ interval += (int64_t)(ppm_now.tv_nsec - ppm_recent.tv_nsec); nsamples_total += nsamples; interval_total += interval; - printf("real sample rate: %i current PPM: %i cumulative PPM: %i\n", + fprintf(stderr, "real sample rate: %i current PPM: %i cumulative PPM: %i\n", (int)((1000000000UL * nsamples) / interval), ppm_report(nsamples, interval), ppm_report(nsamples_total, interval_total)); Best Regards, Andrey

1 0

No supported tuner found
by Gabor Mikes 19 Sep '17

19 Sep '17

Hi All, I recently purchased a couple of DVB-sticks on Amazon, titled: "RTL-SDR, FM+DAB, DVB-T USB Stick Set with RTL2832U & R820T. Great SDR for SDR#, HDSD" I got "No supported tuner found" when running the rtl_test command. I see others have had the same issue, so when I finally figured it out, I thought some of you might be interested. First of all, this stick has a FC0012 tuner despite the title. Secondly this stick is obliviously wired differently than other sticks with FC0012 because it needs different gpio settings. I added a few lines to the rtlsdr_open() function in librtlsdr.c, just before probing for FCxxx: /* initialise GPIOs */ rtlsdr_set_gpio_output(dev, 0); rtlsdr_set_gpio_output(dev, 3); rtlsdr_set_gpio_output(dev, 4); rtlsdr_set_gpio_output(dev, 5); rtlsdr_set_gpio_output(dev, 6); rtlsdr_set_gpio_bit(dev, 3, 1); rtlsdr_set_gpio_bit(dev, 4, 0); rtlsdr_set_gpio_bit(dev, 6, 0); /* reset tuner before probing */ rtlsdr_set_gpio_bit(dev, 5, 1); rtlsdr_set_gpio_bit(dev, 5, 0); With this modification the tuner comes a live and everything works. Kindest regards, Gabor Mikes

1 0

[PATCH] Add ipv6 support to rtl_tcp
by A. Maitland Bottoms 03 Sep '17

03 Sep '17

I've prepared this patch in response to Debian bug #870804 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870804 It passes the text from the -a and -p options through getaddrinfo() and uses the first result that has a valid socket with a successful bind. While not a complete bind to all possible valid names, it does appear to address the use case of the bug submitter without completely changing the program flow. I submit this for inclusion in the osmocom rtl-sdr repo as it may be of use to others. Thanks for your consideration, -Maitland

1 0

redmine e-mails broken from 08/26 through 08/31
by Harald Welte 31 Aug '17

31 Aug '17

Dear Osmocom community, from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org redmine could not send any e-mails. This was due to a configuration file syntax error introduced by me, my apologies. If you rely on redmine e-mail notifications to the issues you have subscribed to, please double-check as related notifications during that interval were unfortunately lost. Best regards, Harald p.s.: The reason for the config change was to enable e-mail notifications from jenkins.osmocom.org (which it now has, if you want to configure e.g. post-build notification actions). -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

vdl mode2 decoder for RTL SDR
by Thierry Leconte 30 Jul '17

30 Jul '17

Hi I just put on github my new project : vdl mode2 decoder for RTL dongle https://github.com/TLeconte/vdlm2dec

1 0

← Newer
1
...
32
33
34
35
36
37
38
...
92
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr