Hello
I am installing a satgate on the raspberry pi with an rtl dongle
I use the rtl_fm from the sources and I get an error about bias tee
I have had to use another source
Here is my install script
#!/bin/sh
clear
echo "VK4TEC SATGATE install"
echo " "
#sudo apt-get update
#sudo apt-get install cmake build-essential libusb-1.0-0-dev
git clone https://github.com/niofis/rtl-sdr.git
cd rtl-sdr/
mkdir build
cd build
cmake ../
make
sudo make install
sudo ldconfig
git clone https://www.github.com/wb2osz/direwolf
cd ~/direwolf
make
sudo make install
make install-rpi
make install-conf
cd ~
sudo mv sdr.old sdr.confcd ~
sudo cp sdr.conf sdr.old
cd ~
sudo apt-get uninstall rtl-sdr
sudo apt-get install rtl-sdr
sudo apt-get install librtlsdr-dev
/usr/bin/rtl_fm -f 145.825M - | direwolf -t 0 -dii -c sdr.conf -r 24000 -D 1
-
Andrew Rich Nov 2017
The commit ba64a745 fixed rtlsdr_set_gpio_output() but also caused librtlsdr
to stop working with (at least some) dongles with the FC0012 tuner. It seems
that the FC0012 is connected to GPIO 4 while rtlsdr_open() assumes it's
connected to GPIO 5. Before ba64a745 the bug in rtlsdr_set_gpio_output()
caused GPIOs 3 and 4 to be set low and so everything worked.
This changes the GPIO used in rtlsdr_open() from 5 to 4. At least on my
dongle this fixes the regression.
---
src/librtlsdr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index b369a5d..4fb2128 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1565,11 +1565,11 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
}
/* initialise GPIOs */
- rtlsdr_set_gpio_output(dev, 5);
+ rtlsdr_set_gpio_output(dev, 4);
/* reset tuner before probing */
- rtlsdr_set_gpio_bit(dev, 5, 1);
- rtlsdr_set_gpio_bit(dev, 5, 0);
+ rtlsdr_set_gpio_bit(dev, 4, 1);
+ rtlsdr_set_gpio_bit(dev, 4, 0);
reg = rtlsdr_i2c_read_reg(dev, FC2580_I2C_ADDR, FC2580_CHECK_ADDR);
if ((reg & 0x7f) == FC2580_CHECK_VAL) {
--
2.14.2
Dear Osmocom community,
I would like to point out that at sysmocom, we're currently (again)
hiring [1]. If you happen to have an interest in open source cellular
communications and are fluent in C language development, we would
love to hear from you.
sysmocom probably doesn't need any introduction here, but just in case:
The company was founded by Holger Freyther and Harald Welte, two of the
leading OpenBSC and Osmocom developers from the very early days of the
project. Today we are responsible for by far the largest number of commits
to the Osmocom GSM/3G infrastructure related git repositories.
Among our current priorities are automatic testing for the GPRS PCU,
generalization of the OsmoMGW media gateway, support for load-based hand-over,
inter-BSC hand-over as well as various improvements on the lower layers
of the GPRS protocol stack.
We're very dedicated to the cause in furthering the capabilities of
open source cellular infrastructure from 2G to 4G. We believe in
working upstream, no open core or dual licensing.
If you have an interest working with an enthusiastic, strong technical
and dedicated team of Osmocom hackers, please don't hesitate to let me know,
best by e-mail to jobs(a)sysmocom.de
Thanks,
Harald
p.s.: I hope this kind of message is not disturbing to anyone. I think
it is important to the Osmocom project to have more paid people working
on the stack, so it is justified. The positions we are seeking to fill
will work [almost exclusively] on Osmocom, so it's not a random job ad
but in the very interest of Osmocom, and hence on-topic for this list.
[1] https://www.sysmocom.de/jobs/
--
- Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi - I presume since I'm receiving a number of these types of errors
while compiling
/opt/gnuradio/src/gr-oot/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:307:7: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11
cmd = { 0x0a, htonl(offset_tune) };
i.e., complaining about -std=gnu++11, that I should probably be
compiling gr-osmosdr with the -std=gnu++11 flag.
Typically, I fall asleep at the wheel during the build - so I don't know
which version these warning started. If it wasn't for my dog's wet nose
pressing against my elbow, I'd still be sleeping.
I'm using the following git pulls for
rtl-sdr:
commit 18bf26989c926a5db4fca29e7d859af42af1437c
Author: hayati ayguen <h_ayguen(a)web.de>
Date: Sun Jun 11 00:18:53 2017 +0200
gr-osmosdr:
commit c653754dde5e2cf682965e939cc016fbddbd45e4
Merge: b7aab45 cf95494
Author: Dimitri Stolnikov <horiz0n(a)gmx.net>
Date: Mon Jun 12 00:04:36 2017 +0200
and I have somewhat recent git pulls for libosmocore and libosmo-dsp.
Should I be compiling the programs rtl-sdr and gr-osmosdr with
-std=gnu++11?
How about libosmocore and libosmo-dsp?
-- Cinaed
I am having difficulty in searching archives as the search page does not
have search window. How do I specific topic or problem?
I am trying to use DAB+FM+DVB-T dongle in gnuradio-companion installed with
latest pre-built package on Windows 10 OS. But, it is throwing error as
follows:
QUOTE
Generating: 'C:\\Users\\vsrks_000\\Documents\\top_block.py'
Executing: C:\GNURadio-3.7\gr-python27\python.exe -u
C:\Users\vsrks_000\Documents\top_block.py
Win32; Microsoft Visual C++ version 14.0; Boost_106000;
UHD_003.010.001.001-0-unknown
gr-osmosdr ae686c46 (0.1.5git) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
airspy redpitaya
Using device #0 Generic RTL2832U OEM
usb_open error -12
FATAL: Failed to open rtlsdr device.
Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.
gr::pagesize: no info; setting pagesize = 4096
UNQUOTE
Can you please suggest a solution.
--
Best Regards,
vsrk sarma
Hi folks,
something wasn't quite right with current git master of rtl-sdr, since
it wouldn't detect the Fitipower FC0012 tuner on a couple (dozen) of my
dongles.
So, I had a quick git-bisect session that basically went:
git checkout master
git bisect start
[build]
[connect dongle]
build/src/rtl_eeprom | grep "Found Fitipower"
then git bisect good
else git bisect bad
[disconnect dongle]
jump back to build, rinse, repeat
turns out, when you _initialize_ the dongle with an older version, it
works, even with the newer revisions (hence my un- and replugging
exercises).
The (reproducibly) offending commit is the GPO/GPD register swap in
ba64a74 : librtlsdr.c, l. 570,
- rtlsdr_write_reg(dev, SYSB, GPO, r & ~gpio, 1);
+ rtlsdr_write_reg(dev, SYSB, GPD, r & ~gpio, 1);
Now, that commit's msg mentions
http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html
and I don't want to break their application, but I can't get my dongles
to run :(
How to proceed from here? I'm not quite sure what I'd break if I just
reverted that commit; _my_ R820T dongle continues to work if I revert,
but I'm sure this commit didn't come out of thin air.
Best regards,
Marcus
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
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
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
