From vvvelichkov at gmail.com  Thu Oct  5 15:54:01 2017
From: vvvelichkov at gmail.com (Vasil Velichkov)
Date: Thu,  5 Oct 2017 18:54:01 +0300
Subject: [PATCH] Fix a segfault in soapy_source_c
Message-ID: <20171005155401.30083-1-vvvelichkov@gmail.com>

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



From laforge at gnumonks.org  Sat Oct 14 06:01:40 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 14 Oct 2017 08:01:40 +0200
Subject: Planning for OsmoCon + OsmoDevCon
Message-ID: <20171014060140.khxczgit4pe2icuq@nataraja>

[cross-post to many lists, please follow-up-to openbsc at 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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From martin.m at suddenlink.net  Thu Oct 19 00:20:44 2017
From: martin.m at suddenlink.net (Martin McCormick)
Date: Wed, 18 Oct 2017 19:20:44 -0500
Subject: build-gnuradio
Message-ID: <E1e4yZo-00024T-RE@localhost>

	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


From cinaed.simson at gmail.com  Thu Oct 19 02:12:03 2017
From: cinaed.simson at gmail.com (Cinaed Simson)
Date: Wed, 18 Oct 2017 19:12:03 -0700
Subject: build-gnuradio
In-Reply-To: <E1e4yZo-00024T-RE@localhost>
References: <E1e4yZo-00024T-RE@localhost>
Message-ID: <190f5618-48f2-7c41-711a-0f3c7e3b4b6a@GMail.COM>

On 10/18/2017 05:20 PM, Martin McCormick wrote:
> 	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.

You're the wrong mailing list. You want

  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

I recommend using pybombs - I've never heard of build-gnuradio script.

Also, make sure there's only one installation of gnuradio - otherwise
you're going to have trouble.

Check to make sure the system doesn't already have a version of gnuradio
installed

  apt list --installed | grep gnuradio

I've built gnuradio under wheezy and jessie from source on a BeaglBone
Black, Odroid-C2, Odroid-XU4 and an i7 laptop. But I didn't use pybombs
- I used my own scripts.

-- Cinaed



> 
> 	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
> 



From zvpunry at zvpunry.de  Thu Oct 19 20:06:52 2017
From: zvpunry at zvpunry.de (Michael Loeffler)
Date: Thu, 19 Oct 2017 22:06:52 +0200
Subject: gr-osmosdr: add clock_source= parameter
Message-ID: <d35a97b9-ced2-465b-3933-0e7f86673027@zvpunry.de>

Hello,

the attached patch allows to set the clock_source on uhd devices in
programs like gqrx.

Bye
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-uhd-add-clock_source-parameter.patch
Type: text/x-patch
Size: 2033 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20171019/52072429/attachment.bin>

From martin.m at suddenlink.net  Fri Oct 20 00:22:09 2017
From: martin.m at suddenlink.net (Martin McCormick)
Date: Thu, 19 Oct 2017 19:22:09 -0500
Subject: build-gnuradio
In-Reply-To: <190f5618-48f2-7c41-711a-0f3c7e3b4b6a@GMail.COM>
References: <E1e4yZo-00024T-RE@localhost>
 <190f5618-48f2-7c41-711a-0f3c7e3b4b6a@GMail.COM>
Message-ID: <E1e5L4k-00037w-0W@localhost>

Cinaed Simson <cinaed.simson at gmail.com> writes:
> You're the wrong mailing list. You want
> 
>   https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> I recommend using pybombs - I've never heard of build-gnuradio script.
> 
> Also, make sure there's only one installation of gnuradio - otherwise
> you're going to have trouble.
> 
> Check to make sure the system doesn't already have a version of gnuradio
> installed
> 
>   apt list --installed | grep gnuradio
> 
> I've built gnuradio under wheezy and jessie from source on a BeaglBone
> Black, Odroid-C2, Odroid-XU4 and an i7 laptop. But I didn't use pybombs
> - I used my own scripts.

	Thank you.  This is all very useful.

Martin  WB5AGZ


From subs at qcontinuum.plus.com  Sat Oct 21 16:08:08 2017
From: subs at qcontinuum.plus.com (John)
Date: Sat, 21 Oct 2017 17:08:08 +0100
Subject: New SDR dongle received but cannot get it to work
Message-ID: <59EB70E8.7000407@qcontinuum.plus.com>

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


From marcus.mueller at ettus.com  Sat Oct 21 17:06:13 2017
From: marcus.mueller at ettus.com (=?UTF-8?Q?Marcus_M=c3=bcller?=)
Date: Sat, 21 Oct 2017 19:06:13 +0200
Subject: New SDR dongle received but cannot get it to work
In-Reply-To: <59EB70E8.7000407@qcontinuum.plus.com>
References: <59EB70E8.7000407@qcontinuum.plus.com>
Message-ID: <6533c67a-87a3-f89e-b5b7-fd194dce4794@ettus.com>

Hi John,

so, the R820T tuner IC is very well-supported in my experience, as you
can see from the fact that librtlsdr *tries* to talk to it.

I've seen similarly catastrophic behaviour on a USB port that simply
couldn't supply enough power to keep the RTL Dongle operational.

Maybe it's also a different tuner chip that has compatible ID register
(compare: librtlsdr.c, current git master, l. 1553); but I've personally
not encountered such before. You might want to look inside your device
and identify the tuner IC (there will be only two or three "large" ICs
on that PCB; one with a crab, that's the RTL2838, and one very close to
the antenna connector, that's the tuner IC).

Other than that, your stick might also be damaged. There might be other
reasons for this behaviour, too, but "power problems" sounds like it's
the most likely explanation; can you try on a different USB port?

Best regards,
Marcus


On 21.10.2017 18:08, 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
> 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
>
>
>



From cinaed.simson at gmail.com  Sun Oct 22 02:53:57 2017
From: cinaed.simson at gmail.com (Cinaed Simson)
Date: Sat, 21 Oct 2017 19:53:57 -0700
Subject: New SDR dongle received but cannot get it to work
In-Reply-To: <59EB70E8.7000407@qcontinuum.plus.com>
References: <59EB70E8.7000407@qcontinuum.plus.com>
Message-ID: <b3fc04e1-e8fb-c77b-8d07-313057c16249@GMail.COM>

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
> 
> 
> 

-------------- next part --------------
#
# Copyright 2012-2013 Osmocom rtl-sdr project
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.
#

# original RTL2832U vid/pid (hama nano, for example)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2832", MODE:="0666"

# RTL2832U OEM vid/pid, e.g. ezcap EzTV668 (E4000), Newsky TV28T (E4000/R820T) etc.
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", MODE:="0666"

# DigitalNow Quad DVB-T PCI-E card (4x FC0012?)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0413", ATTRS{idProduct}=="6680", MODE:="0666"

# Leadtek WinFast DTV Dongle mini D (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0413", ATTRS{idProduct}=="6f0f", MODE:="0666"

# Genius TVGo DVB-T03 USB dongle (Ver. B)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0458", ATTRS{idProduct}=="707f", MODE:="0666"

# Terratec Cinergy T Stick Black (rev 1) (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00a9", MODE:="0666"

# Terratec NOXON rev 1 (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00b3", MODE:="0666"

# Terratec Deutschlandradio DAB Stick (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00b4", MODE:="0666"

# Terratec NOXON DAB Stick - Radio Energy (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00b5", MODE:="0666"

# Terratec Media Broadcast DAB Stick (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00b7", MODE:="0666"

# Terratec BR DAB Stick (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00b8", MODE:="0666"

# Terratec WDR DAB Stick (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00b9", MODE:="0666"

# Terratec MuellerVerlag DAB Stick (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00c0", MODE:="0666"

# Terratec Fraunhofer DAB Stick (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00c6", MODE:="0666"

# Terratec Cinergy T Stick RC (Rev.3) (E4000)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00d3", MODE:="0666"

# Terratec T Stick PLUS (E4000)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00d7", MODE:="0666"

# Terratec NOXON rev 2 (E4000)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0ccd", ATTRS{idProduct}=="00e0", MODE:="0666"

# PixelView PV-DT235U(RN) (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1554", ATTRS{idProduct}=="5020", MODE:="0666"

# Astrometa DVB-T/DVB-T2 (R828D)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="15f4", ATTRS{idProduct}=="0131", MODE:="0666"

# Compro Videomate U620F (E4000)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="185b", ATTRS{idProduct}=="0620", MODE:="0666"

# Compro Videomate U650F (E4000)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="185b", ATTRS{idProduct}=="0650", MODE:="0666"

# Compro Videomate U680F (E4000)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="185b", ATTRS{idProduct}=="0680", MODE:="0666"

# GIGABYTE GT-U7300 (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d393", MODE:="0666"

# DIKOM USB-DVBT HD
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d394", MODE:="0666"

# Peak 102569AGPK (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d395", MODE:="0666"

# KWorld KW-UB450-T USB DVB-T Pico TV (TUA9001)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d397", MODE:="0666"

# Zaapa ZT-MINDVBZP (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d398", MODE:="0666"

# SVEON STV20 DVB-T USB & FM (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d39d", MODE:="0666"

# Twintech UT-40 (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d3a4", MODE:="0666"

# ASUS U3100MINI_PLUS_V2 (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d3a8", MODE:="0666"

# SVEON STV27 DVB-T USB & FM (FC0013)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d3af", MODE:="0666"

# SVEON STV21 DVB-T USB & FM
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d3b0", MODE:="0666"

# Dexatek DK DVB-T Dongle (Logilink VG0002A) (FC2580)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1d19", ATTRS{idProduct}=="1101", MODE:="0666"

# Dexatek DK DVB-T Dongle (MSI DigiVox mini II V3.0)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1d19", ATTRS{idProduct}=="1102", MODE:="0666"

# Dexatek DK 5217 DVB-T Dongle (FC2580)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1d19", ATTRS{idProduct}=="1103", MODE:="0666"

# MSI DigiVox Micro HD (FC2580)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1d19", ATTRS{idProduct}=="1104", MODE:="0666"

# Sweex DVB-T USB (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="a803", MODE:="0666"

# GTek T803 (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="b803", MODE:="0666"

# Lifeview LV5TDeluxe (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="c803", MODE:="0666"

# MyGica TD312 (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="d286", MODE:="0666"

# PROlectrix DV107669 (FC0012)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="d803", MODE:="0666"

From subs at qcontinuum.plus.com  Mon Oct 23 22:30:45 2017
From: subs at qcontinuum.plus.com (John)
Date: Mon, 23 Oct 2017 23:30:45 +0100
Subject: New SDR dongle received but cannot get it to work
In-Reply-To: <e91938e4-bf6d-9466-9f59-68a6a53e255a@GMail.COM>
References: <59EB70E8.7000407@qcontinuum.plus.com>
 <b3fc04e1-e8fb-c77b-8d07-313057c16249@GMail.COM>
 <59ECC124.4020200@qcontinuum.plus.com>
 <e91938e4-bf6d-9466-9f59-68a6a53e255a@GMail.COM>
Message-ID: <59EE6D95.7000908@qcontinuum.plus.com>

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 at 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 at 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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20171023/50139e5d/attachment.htm>

From cinaed.simson at gmail.com  Tue Oct 24 03:12:04 2017
From: cinaed.simson at gmail.com (Cinaed Simson)
Date: Mon, 23 Oct 2017 20:12:04 -0700
Subject: New SDR dongle received but cannot get it to work
In-Reply-To: <59EE6D95.7000908@qcontinuum.plus.com>
References: <59EB70E8.7000407@qcontinuum.plus.com>
 <b3fc04e1-e8fb-c77b-8d07-313057c16249@GMail.COM>
 <59ECC124.4020200@qcontinuum.plus.com>
 <e91938e4-bf6d-9466-9f59-68a6a53e255a@GMail.COM>
 <59EE6D95.7000908@qcontinuum.plus.com>
Message-ID: <df4fa1fd-16da-4ac5-751d-41e9d22778bf@GMail.COM>

On 10/23/2017 03:30 PM, John wrote:
> 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 at 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.

That's IO error.

> 
> 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.

You shouldn't have seen it - it should have been blacklisted.

Try

  lsmod | grep rt

-- Cinaed

> 
>> 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 at 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 at 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 at 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 at 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 at 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



From marcus.mueller at ettus.com  Wed Oct 25 07:00:23 2017
From: marcus.mueller at ettus.com (=?UTF-8?Q?Marcus_M=c3=bcller?=)
Date: Wed, 25 Oct 2017 09:00:23 +0200
Subject: rtl-sdr: gba64a74 breaks _my_ FC0012-based dongle
Message-ID: <1c2055b9-226f-5e52-0b66-bdd61b2a07b2@ettus.com>

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

-------------- next part --------------
git bisect start
# good: [af1e2d29e80ce31e54cad771b47d31bdb846b695] bump version to 0.5.0
git bisect good af1e2d29e80ce31e54cad771b47d31bdb846b695
# good: [af1e2d29e80ce31e54cad771b47d31bdb846b695] bump version to 0.5.0
git bisect good af1e2d29e80ce31e54cad771b47d31bdb846b695
# bad: [b04c2f9f035c5aede43d731e5d58e4725d2f8bb4] fix for msvc14
git bisect bad b04c2f9f035c5aede43d731e5d58e4725d2f8bb4
# good: [7855c7c8768c91fd47425136bb4c151d0abdc224] rtl_tcp: clean up error handling
git bisect good 7855c7c8768c91fd47425136bb4c151d0abdc224
# good: [0a90c7d4177a61b2272098e7c89553726401f836] rtl_test: update copyright header
git bisect good 0a90c7d4177a61b2272098e7c89553726401f836
# good: [c5dc459fc51d4b6721a7c0457ac0cddbb3213b2c] Correct return code of e4k_reg_write().
git bisect good c5dc459fc51d4b6721a7c0457ac0cddbb3213b2c
# good: [e3c03f738f5aef4dc51e2b741fbdb542b9cc1bb1] lib: check for libusb init failure
git bisect good e3c03f738f5aef4dc51e2b741fbdb542b9cc1bb1
# bad: [2be1612e604f950ba21ef6ff12488eab62e66ad5] lib: Use GPIO P0 to toggle an (optional) bias-t
git bisect bad 2be1612e604f950ba21ef6ff12488eab62e66ad5
# bad: [ba64a7459a43652354990855176a7d8dad5b9d54] lib: fix direction bit in GPIO code
git bisect bad ba64a7459a43652354990855176a7d8dad5b9d54
# good: [e3e6ee23b7f052327bf64c6908f5c09b75029edc] lib: add new HanfTek dongle
git bisect good e3e6ee23b7f052327bf64c6908f5c09b75029edc
# first bad commit: [ba64a7459a43652354990855176a7d8dad5b9d54] lib: fix direction bit in GPIO code
-------------- next part --------------
#!/usr/bin/zsh

pushd build
rm -r *
cmake -DCMAKE_INSTALL_PREFIX=~/.usrlocal -DCMAKE_C_COMPILER=clang -GNinja ..
ninja
./src/rtl_eeprom |& grep "Found Fitipower"
return_code=$rc
[[ $rc -ne 0 ]] && echo "$(git describe): Nope" && exit -1

From vsrksiva at gmail.com  Wed Oct 25 09:37:06 2017
From: vsrksiva at gmail.com (vempati Sarma)
Date: Wed, 25 Oct 2017 15:07:06 +0530
Subject: searching osmocom-sdr archives
Message-ID: <CAGeYVNA7rrmFYbf0t-KLCsKqYsGV_7_Y7fFX3iaRgoyWFa6-mg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20171025/62c4f692/attachment.htm>

From mueller at kit.edu  Fri Oct 27 15:03:00 2017
From: mueller at kit.edu (=?UTF-8?q?Marcus=20M=C3=BCller?=)
Date: Fri, 27 Oct 2017 17:03:00 +0200
Subject: [PATCH] Revert "lib: fix direction bit in GPIO code"
Message-ID: <20171027150300.20176-1-mueller@kit.edu>

This reverts commit ba64a7459a43652354990855176a7d8dad5b9d54.

The mentioned commit leads to nonfunctionality of Fitipower FC0012
dongles (tested by a small horde of students) and doesn't increase
functionality on my "RTL-SDR.com" branded R820T-based dongle.
---
 src/librtlsdr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index b369a5d..6c079a5 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -570,7 +570,7 @@ void rtlsdr_set_gpio_output(rtlsdr_dev_t *dev, uint8_t gpio)
 	gpio = 1 << gpio;
 
 	r = rtlsdr_read_reg(dev, SYSB, GPD, 1);
-	rtlsdr_write_reg(dev, SYSB, GPD, r & ~gpio, 1);
+	rtlsdr_write_reg(dev, SYSB, GPO, r & ~gpio, 1);
 	r = rtlsdr_read_reg(dev, SYSB, GPOE, 1);
 	rtlsdr_write_reg(dev, SYSB, GPOE, r | gpio, 1);
 }
-- 
2.13.6



From 246tnt at gmail.com  Fri Oct 27 16:09:18 2017
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 27 Oct 2017 18:09:18 +0200
Subject: [PATCH] Revert "lib: fix direction bit in GPIO code"
In-Reply-To: <20171027150300.20176-1-mueller@kit.edu>
References: <20171027150300.20176-1-mueller@kit.edu>
Message-ID: <CAHL+j0-_T0cHGhu+9xyTHS22Mfo+BbwQacrEmnBsr1yxO0Cg-A@mail.gmail.com>

That commit might break something but it still looks like the right thing to do.
This is just a symptom of another underlying problem. Find that
problem and fix it.


On Fri, Oct 27, 2017 at 5:03 PM, Marcus M?ller <mueller at kit.edu> wrote:
> This reverts commit ba64a7459a43652354990855176a7d8dad5b9d54.
>
> The mentioned commit leads to nonfunctionality of Fitipower FC0012
> dongles (tested by a small horde of students) and doesn't increase
> functionality on my "RTL-SDR.com" branded R820T-based dongle.
> ---
>  src/librtlsdr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/librtlsdr.c b/src/librtlsdr.c
> index b369a5d..6c079a5 100644
> --- a/src/librtlsdr.c
> +++ b/src/librtlsdr.c
> @@ -570,7 +570,7 @@ void rtlsdr_set_gpio_output(rtlsdr_dev_t *dev, uint8_t gpio)
>         gpio = 1 << gpio;
>
>         r = rtlsdr_read_reg(dev, SYSB, GPD, 1);
> -       rtlsdr_write_reg(dev, SYSB, GPD, r & ~gpio, 1);
> +       rtlsdr_write_reg(dev, SYSB, GPO, r & ~gpio, 1);
>         r = rtlsdr_read_reg(dev, SYSB, GPOE, 1);
>         rtlsdr_write_reg(dev, SYSB, GPOE, r | gpio, 1);
>  }
> --
> 2.13.6
>


From mueller at kit.edu  Fri Oct 27 17:13:04 2017
From: mueller at kit.edu (=?ISO-8859-1?Q?Marcus_M=FCller?=)
Date: Fri, 27 Oct 2017 19:13:04 +0200
Subject: [PATCH] Revert "lib: fix direction bit in GPIO code"
In-Reply-To: <CAHL+j0-_T0cHGhu+9xyTHS22Mfo+BbwQacrEmnBsr1yxO0Cg-A@mail.gmail.com>
References: <20171027150300.20176-1-mueller@kit.edu>
 <CAHL+j0-_T0cHGhu+9xyTHS22Mfo+BbwQacrEmnBsr1yxO0Cg-A@mail.gmail.com>
Message-ID: <EF67758C-53A5-4CE6-A662-330F0E6F6D3B@kit.edu>

Hi Sylvain,

I'd love to, but I honestly don't even have the symptom (whatever that is) of what this commit fixes. Admittedly, I'd assume myself that maybe I just haven't looked hard enough for a symptom, but if you'd have insight on what the fact that the register was wrong effects, then I'd be thankful!

I really just observe that this commit breaks something, and that I haven't been able to find out what out fixes :(

Cheers
Marcus

On 27 October 2017 6:09:18 PM GMT+02:00, Sylvain Munaut <246tnt at gmail.com> wrote:
>That commit might break something but it still looks like the right
>thing to do.
>This is just a symptom of another underlying problem. Find that
>problem and fix it.
>
>
>On Fri, Oct 27, 2017 at 5:03 PM, Marcus M?ller <mueller at kit.edu> wrote:
>> This reverts commit ba64a7459a43652354990855176a7d8dad5b9d54.
>>
>> The mentioned commit leads to nonfunctionality of Fitipower FC0012
>> dongles (tested by a small horde of students) and doesn't increase
>> functionality on my "RTL-SDR.com" branded R820T-based dongle.
>> ---
>>  src/librtlsdr.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/librtlsdr.c b/src/librtlsdr.c
>> index b369a5d..6c079a5 100644
>> --- a/src/librtlsdr.c
>> +++ b/src/librtlsdr.c
>> @@ -570,7 +570,7 @@ void rtlsdr_set_gpio_output(rtlsdr_dev_t *dev,
>uint8_t gpio)
>>         gpio = 1 << gpio;
>>
>>         r = rtlsdr_read_reg(dev, SYSB, GPD, 1);
>> -       rtlsdr_write_reg(dev, SYSB, GPD, r & ~gpio, 1);
>> +       rtlsdr_write_reg(dev, SYSB, GPO, r & ~gpio, 1);
>>         r = rtlsdr_read_reg(dev, SYSB, GPOE, 1);
>>         rtlsdr_write_reg(dev, SYSB, GPOE, r | gpio, 1);
>>  }
>> --
>> 2.13.6
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20171027/fcaeba20/attachment.htm>

From oliver.jowett at gmail.com  Fri Oct 27 17:44:45 2017
From: oliver.jowett at gmail.com (Oliver Jowett)
Date: Fri, 27 Oct 2017 18:44:45 +0100
Subject: [PATCH] Revert "lib: fix direction bit in GPIO code"
In-Reply-To: <EF67758C-53A5-4CE6-A662-330F0E6F6D3B@kit.edu>
References: <20171027150300.20176-1-mueller@kit.edu>
 <CAHL+j0-_T0cHGhu+9xyTHS22Mfo+BbwQacrEmnBsr1yxO0Cg-A@mail.gmail.com>
 <EF67758C-53A5-4CE6-A662-330F0E6F6D3B@kit.edu>
Message-ID: <CAAjXfu9QGP68cDnyWO-BE7Z6x=sihA6jeZYek_-TD5kuM3TohQ@mail.gmail.com>

The original commit fixes configuring the direction of the GPIO pins on the
2832 so it actually works. The FC0012 failure is probably a side-effect of
the direction bits now really being set.

The tuner initialization does this:

rtlsdr_set_gpio_output(dev, 5); /* should set GPIO 5 to output mode, but
actually does not touch the direction bits and instead turns on GPIO output
5 */
rtlsdr_set_gpio_bit(dev, 5, 1);   /* turns on GPIO 5 output */
rtlsdr_set_gpio_bit(dev, 5, 0);   /* turns off GPIO 5 output */

I don't know the reset state of the 2832 offhand but assuming GPIO 5 is not
set as an output on reset, then that tuner reset was doing nothing much
before the GPIO fix.
Maybe the FC0012 takes a while to settle after a reset, so when it really
gets reset the detection immediately afterwards fails. You could try
commenting out those three lines and see if anything changes.

Oliver


On 27 October 2017 at 18:13, Marcus M?ller <mueller at kit.edu> wrote:

> Hi Sylvain,
>
> I'd love to, but I honestly don't even have the symptom (whatever that is)
> of what this commit fixes. Admittedly, I'd assume myself that maybe I just
> haven't looked hard enough for a symptom, but if you'd have insight on what
> the fact that the register was wrong effects, then I'd be thankful!
>
> I really just observe that this commit breaks something, and that I
> haven't been able to find out what out fixes :(
>
> Cheers
> Marcus
>
>
> On 27 October 2017 6:09:18 PM GMT+02:00, Sylvain Munaut <246tnt at gmail.com>
> wrote:
>>
>> That commit might break something but it still looks like the right thing to do.
>> This is just a symptom of another underlying problem. Find that
>> problem and fix it.
>>
>>
>> On Fri, Oct 27, 2017 at 5:03 PM, Marcus M?ller <mueller at kit.edu> wrote:
>>
>>>  This reverts commit ba64a7459a43652354990855176a7d8dad5b9d54.
>>>
>>>  The mentioned commit leads to nonfunctionality of Fitipower FC0012
>>>  dongles (tested by a small horde of students) and doesn't increase
>>>  functionality on my "RTL-SDR.com" branded R820T-based dongle.
>>>  ---
>>>   src/librtlsdr.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>>  diff --git a/src/librtlsdr.c b/src/librtlsdr.c
>>>  index b369a5d..6c079a5 100644
>>>  --- a/src/librtlsdr.c
>>>  +++ b/src/librtlsdr.c
>>>  @@ -570,7 +570,7 @@ void rtlsdr_set_gpio_output(rtlsdr_dev_t *dev, uint8_t gpio)
>>>          gpio = 1 << gpio;
>>>
>>>          r = rtlsdr_read_reg(dev, SYSB, GPD, 1);
>>>  -       rtlsdr_write_reg(dev, SYSB, GPD, r & ~gpio, 1);
>>>  +       rtlsdr_write_reg(dev, SYSB, GPO, r & ~gpio, 1);
>>>          r = rtlsdr_read_reg(dev, SYSB, GPOE, 1);
>>>          rtlsdr_write_reg(dev, SYSB, GPOE, r | gpio, 1);
>>>   }
>>>  --
>>>  2.13.6
>>
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20171027/9af7e5fe/attachment.htm>

From marcus.mueller at ettus.com  Fri Oct 27 17:48:40 2017
From: marcus.mueller at ettus.com (=?ISO-8859-1?Q?Marcus_M=FCller?=)
Date: Fri, 27 Oct 2017 19:48:40 +0200
Subject: [PATCH] Revert "lib: fix direction bit in GPIO code"
In-Reply-To: <CAAjXfu9QGP68cDnyWO-BE7Z6x=sihA6jeZYek_-TD5kuM3TohQ@mail.gmail.com>
References: <20171027150300.20176-1-mueller@kit.edu>
 <CAHL+j0-_T0cHGhu+9xyTHS22Mfo+BbwQacrEmnBsr1yxO0Cg-A@mail.gmail.com>
 <EF67758C-53A5-4CE6-A662-330F0E6F6D3B@kit.edu>
 <CAAjXfu9QGP68cDnyWO-BE7Z6x=sihA6jeZYek_-TD5kuM3TohQ@mail.gmail.com>
Message-ID: <35F059CA-D6DE-44E5-9B44-2EEC30874AB1@ettus.com>

Cool, thanks, will do!

On 27 October 2017 7:44:45 PM GMT+02:00, Oliver Jowett <oliver.jowett at gmail.com> wrote:
>The original commit fixes configuring the direction of the GPIO pins on
>the
>2832 so it actually works. The FC0012 failure is probably a side-effect
>of
>the direction bits now really being set.
>
>The tuner initialization does this:
>
>rtlsdr_set_gpio_output(dev, 5); /* should set GPIO 5 to output mode,
>but
>actually does not touch the direction bits and instead turns on GPIO
>output
>5 */
>rtlsdr_set_gpio_bit(dev, 5, 1);   /* turns on GPIO 5 output */
>rtlsdr_set_gpio_bit(dev, 5, 0);   /* turns off GPIO 5 output */
>
>I don't know the reset state of the 2832 offhand but assuming GPIO 5 is
>not
>set as an output on reset, then that tuner reset was doing nothing much
>before the GPIO fix.
>Maybe the FC0012 takes a while to settle after a reset, so when it
>really
>gets reset the detection immediately afterwards fails. You could try
>commenting out those three lines and see if anything changes.
>
>Oliver
>
>
>On 27 October 2017 at 18:13, Marcus M?ller <mueller at kit.edu> wrote:
>
>> Hi Sylvain,
>>
>> I'd love to, but I honestly don't even have the symptom (whatever
>that is)
>> of what this commit fixes. Admittedly, I'd assume myself that maybe I
>just
>> haven't looked hard enough for a symptom, but if you'd have insight
>on what
>> the fact that the register was wrong effects, then I'd be thankful!
>>
>> I really just observe that this commit breaks something, and that I
>> haven't been able to find out what out fixes :(
>>
>> Cheers
>> Marcus
>>
>>
>> On 27 October 2017 6:09:18 PM GMT+02:00, Sylvain Munaut
><246tnt at gmail.com>
>> wrote:
>>>
>>> That commit might break something but it still looks like the right
>thing to do.
>>> This is just a symptom of another underlying problem. Find that
>>> problem and fix it.
>>>
>>>
>>> On Fri, Oct 27, 2017 at 5:03 PM, Marcus M?ller <mueller at kit.edu>
>wrote:
>>>
>>>>  This reverts commit ba64a7459a43652354990855176a7d8dad5b9d54.
>>>>
>>>>  The mentioned commit leads to nonfunctionality of Fitipower FC0012
>>>>  dongles (tested by a small horde of students) and doesn't increase
>>>>  functionality on my "RTL-SDR.com" branded R820T-based dongle.
>>>>  ---
>>>>   src/librtlsdr.c | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>>  diff --git a/src/librtlsdr.c b/src/librtlsdr.c
>>>>  index b369a5d..6c079a5 100644
>>>>  --- a/src/librtlsdr.c
>>>>  +++ b/src/librtlsdr.c
>>>>  @@ -570,7 +570,7 @@ void rtlsdr_set_gpio_output(rtlsdr_dev_t *dev,
>uint8_t gpio)
>>>>          gpio = 1 << gpio;
>>>>
>>>>          r = rtlsdr_read_reg(dev, SYSB, GPD, 1);
>>>>  -       rtlsdr_write_reg(dev, SYSB, GPD, r & ~gpio, 1);
>>>>  +       rtlsdr_write_reg(dev, SYSB, GPO, r & ~gpio, 1);
>>>>          r = rtlsdr_read_reg(dev, SYSB, GPOE, 1);
>>>>          rtlsdr_write_reg(dev, SYSB, GPOE, r | gpio, 1);
>>>>   }
>>>>  --
>>>>  2.13.6
>>>
>>>
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20171027/29e5b02c/attachment.htm>

From cinaed.simson at gmail.com  Mon Oct 30 22:36:28 2017
From: cinaed.simson at gmail.com (Cinaed Simson)
Date: Mon, 30 Oct 2017 15:36:28 -0700
Subject: gr-osmosdr and the compile flag -std=gnu++11
Message-ID: <8af9c187-d9a9-a3b5-15ba-3e55bd3f34e6@GMail.COM>

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 at web.de>
    Date:   Sun Jun 11 00:18:53 2017 +0200

  gr-osmosdr:
    commit c653754dde5e2cf682965e939cc016fbddbd45e4
    Merge: b7aab45 cf95494
    Author: Dimitri Stolnikov <horiz0n at 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




From hwelte at sysmocom.de  Tue Oct 31 18:56:00 2017
From: hwelte at sysmocom.de (Harald Welte)
Date: Tue, 31 Oct 2017 19:56:00 +0100
Subject: Want to do paid work on Osmocom? sysmocom is hiring
Message-ID: <20171031185600.ca6izqakkcvg43nu@nataraja>

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 at 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 at 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