From john at tonebridge.com Wed Dec 7 01:12:50 2016
From: john at tonebridge.com (john)
Date: Tue, 6 Dec 2016 19:12:50 -0600
Subject: Example of Setting Auto Gain
Message-ID: <58476212.5000509@tonebridge.com>
Hello,
I am not sure how to set auto gain on a RTL dongle. I ran across this
which I think should be what I need:
http://cgit.osmocom.org/gr-osmosdr/tree/grc/gen_osmosdr_blocks.py
From that page:
| Ch$(n): Gain Modegain_mode$(n)Falsebool\#if \$nchan() > $n then
'none' else 'all'#
|
However it is not clear what I need to pass to make auto gain happen.
Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From horiz0n at gmx.net Wed Dec 7 23:07:07 2016
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Thu, 08 Dec 2016 00:07:07 +0100
Subject: Example of Setting Auto Gain
In-Reply-To: <58476212.5000509@tonebridge.com>
References: <58476212.5000509@tonebridge.com>
Message-ID:
Hi John,
you're on the right track - you give it one the values listed in
..., True or False here. It might take integers 0 or 1 as well.
Best regards,
Dimitri
On Wed, 07 Dec 2016 02:12:50 +0100, john wrote:
> Hello,
>
> I am not sure how to set auto gain on a RTL dongle. I ran across this
> which I think should be what I need:
>
> http://cgit.osmocom.org/gr-osmosdr/tree/grc/gen_osmosdr_blocks.py
>
> From that page:
>
> | Ch$(n): Gain Modegain_mode$(n)
> Falsebool\#if \$nchan() > $n then
> 'none' else 'all'#
> |
>
> However it is not clear what I need to pass to make auto gain happen.
>
> Thanks,
>
> John
From john at tonebridge.com Fri Dec 9 19:53:09 2016
From: john at tonebridge.com (John)
Date: Fri, 9 Dec 2016 13:53:09 -0600
Subject: Example of Setting Auto Gain
In-Reply-To:
References: <58476212.5000509@tonebridge.com>
Message-ID:
Thanks. I will work down that path and report back when I have something
working.
On Dec 7, 2016 5:07 PM, "Dimitri Stolnikov" wrote:
> Hi John,
>
> you're on the right track - you give it one the values listed in
> ..., True or False here. It might take integers 0 or 1 as well.
>
> Best regards,
> Dimitri
>
> On Wed, 07 Dec 2016 02:12:50 +0100, john wrote:
>
> Hello,
>>
>> I am not sure how to set auto gain on a RTL dongle. I ran across this
>> which I think should be what I need:
>>
>> http://cgit.osmocom.org/gr-osmosdr/tree/grc/gen_osmosdr_blocks.py
>>
>> From that page:
>>
>> | Ch$(n): Gain Modegain_mode$(n)
>> Falsebool\#if \$nchan() > $n then
>> 'none' else 'all'#
>> |
>>
>> However it is not clear what I need to pass to make auto gain happen.
>>
>> Thanks,
>>
>> John
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From laforge at gnumonks.org Sat Dec 10 19:11:39 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 10 Dec 2016 20:11:39 +0100
Subject: RFC: OsmoDevCon 2017 planning
Message-ID: <20161210191139.rxtzqrdmsifwgi4s@nataraja>
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc at lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
>From 2012 to 2016 we were running a series of small, invitation-only
Osmocom Developer Conferences. Access was intentionally restricted
to those community members who have demonstrated an existing track
record of contribution to any of the projects under the Osmocom
umbrella.
This format of a small, tightly knit group of about 20 people has been
successful over the years, and I have received a lot of positive
feedback from past participants.
On the other hand, the Osmocom project has grown in scope and diversity,
and some of those projects don't have all that much relationship to each
other - except being started by people from within the same group.
There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at
some point LTE) protocols which is attracting a lot of professional
users. And then there's pure community projects like rtl-sdr,
OsmocomBB, OsmocomGMR and many other efforts.
Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU,
OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow
"standing out" of the othe projects in the context of having a wider
user bsae, and in that user base also primarily commercial users.
So I'd like to start a discussion on how to possibly change the event
format to accomodate the various interests and parties. I definitely
don't want to loose the "annual meeting of old friends" atmosphere,
while at the same time also opening up to other interested parties.
One idea would be to keep OsmoDevCon as-is and have a separate event
where non-contributing/developing users / sysadmins / system integrators
could also be attending.
Another idea would be to split into a 'user day' and 'developer days'
format. This is something the netfilter developer workshops have been
using for many years, and from my limited insight quite successfully so.
The "user day" is more like a traditional tech conference, with a large
auditorium and talks oriented towards users / sysadmins / integrators of
the software. The "developer days" are the invitation-only part, for
known contributing developers only, similar to what we have at
OsmoDevCon.
Having both events (or both parts of an event) back-to-back has the
advantage that a large number of potential speakers for the 'user day'
are already present, and they don't have to travel yet another time.
One could even structure it further and say we have one user day, one
public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon
classic', maybe reduced from 4 days to 3 or even 2 days only?
What is the general opinion about this?
Are there people lurking on this list who would be interested in
attending a public 'user day' or even 'developer day' about the Osmocom
cellular projects, with presentations and workshops around topics such
as running Osmocom based cellular networks?
In terms of when/where, I would suggest to keep the tradition of April
in Berlin/Germany. But I'm of course very happy if somebody wants to
host it some place else...
Regards, and looking forward to meeting you [again] in 2017,
Harald
--
- Harald Welte http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
From luigi.tarenga at gmail.com Fri Dec 16 12:18:58 2016
From: luigi.tarenga at gmail.com (Luigi Tarenga)
Date: Fri, 16 Dec 2016 13:18:58 +0100
Subject: compiling rtl-sdr on win10 with qtcreator
Message-ID:
hello,
I'm trying to build rtl-sdr on win10. I choosed to use mingw and qtcreator.
I installed:
cmake 3.7.1
qtcreate 4.2.0
mingw32 (to build libusb)
I compiled libusb with mingw32 and automake and installed in Desktop\libusb\.
Now I'm trying to find out how to generate make files for rtl-sdr passing
the folder where I installed libusb (library and header) in qtcreator.
I don't understand if I have to modify CMakeLists.txt or there is some
gui to enter
the correct parameter. I have even to find out if I have to explicit the
variable LIBUSB_PKG_INCLUDE_DIRS or what...
running cmake (from qtcreator) returns with error that I'm missing
libusb and libpthread.
I think that once I can solve the problem for libusb I will be able to
solve even the one of
libpthread. can someone help me in this phase?
thanks
Luigi
From h_ayguen at web.de Fri Dec 16 13:52:43 2016
From: h_ayguen at web.de (Hayati Ayguen)
Date: Fri, 16 Dec 2016 14:52:43 +0100
Subject: compiling rtl-sdr on win10 with qtcreator
In-Reply-To:
References:
Message-ID: <45A7D229-51FC-4ECE-8538-F9AE731992DB@web.de>
Hi Luigi,
i modified the pathes in the CMakeLists.txt for mingw/qtcreator for compilation. Think, i commented it in the head of the file.
Kind Regards,
Hayati
---
Hayati Ayg?n
Am 16. Dezember 2016 13:18:58 MEZ, schrieb Luigi Tarenga :
>hello,
>I'm trying to build rtl-sdr on win10. I choosed to use mingw and
>qtcreator.
>I installed:
>cmake 3.7.1
>qtcreate 4.2.0
>mingw32 (to build libusb)
>
>I compiled libusb with mingw32 and automake and installed in
>Desktop\libusb\.
>
>Now I'm trying to find out how to generate make files for rtl-sdr
>passing
>the folder where I installed libusb (library and header) in qtcreator.
>I don't understand if I have to modify CMakeLists.txt or there is some
>gui to enter
>the correct parameter. I have even to find out if I have to explicit
>the
>variable LIBUSB_PKG_INCLUDE_DIRS or what...
>
>running cmake (from qtcreator) returns with error that I'm missing
>libusb and libpthread.
>I think that once I can solve the problem for libusb I will be able to
>solve even the one of
>libpthread. can someone help me in this phase?
>
>thanks
>Luigi
From luigi.tarenga at gmail.com Fri Dec 16 15:33:00 2016
From: luigi.tarenga at gmail.com (Luigi Tarenga)
Date: Fri, 16 Dec 2016 16:33:00 +0100
Subject: compiling rtl-sdr on win10 with qtcreator
In-Reply-To: <45A7D229-51FC-4ECE-8538-F9AE731992DB@web.de>
References:
<45A7D229-51FC-4ECE-8538-F9AE731992DB@web.de>
Message-ID:
hello Hayati,
thanks for the feedback. unfortunately I cannot find the commended
lines you mention.
just to be clear, I cloned rtl-sdr git and I'm at commit
e3e6ee23b7f052327bf64c6908f5c09b75029edc
I solved the problem editing cmake/Modules/FindLibUSB.cmake
I addeded c:/..blablabla../libusb/include/libusb-1.0 and
c:/..blablabla../libusb/lib
in the find_path() and find_library() blocks respectively.
I'm now trying to figure out how add pthread-win32 to the qt mingw (I
have installed libpthread in
the mingw directory used for compiling libusb but qtcreator seems to
have its own mingw environment
and the latter one is missing pthread-win32 ... )
regards
Luigi
On Fri, Dec 16, 2016 at 2:52 PM, Hayati Ayguen wrote:
> Hi Luigi,
> i modified the pathes in the CMakeLists.txt for mingw/qtcreator for compilation. Think, i commented it in the head of the file.
> Kind Regards,
> Hayati
> ---
> Hayati Ayg?n
>
>
> Am 16. Dezember 2016 13:18:58 MEZ, schrieb Luigi Tarenga :
>>hello,
>>I'm trying to build rtl-sdr on win10. I choosed to use mingw and
>>qtcreator.
>>I installed:
>>cmake 3.7.1
>>qtcreate 4.2.0
>>mingw32 (to build libusb)
>>
>>I compiled libusb with mingw32 and automake and installed in
>>Desktop\libusb\.
>>
>>Now I'm trying to find out how to generate make files for rtl-sdr
>>passing
>>the folder where I installed libusb (library and header) in qtcreator.
>>I don't understand if I have to modify CMakeLists.txt or there is some
>>gui to enter
>>the correct parameter. I have even to find out if I have to explicit
>>the
>>variable LIBUSB_PKG_INCLUDE_DIRS or what...
>>
>>running cmake (from qtcreator) returns with error that I'm missing
>>libusb and libpthread.
>>I think that once I can solve the problem for libusb I will be able to
>>solve even the one of
>>libpthread. can someone help me in this phase?
>>
>>thanks
>>Luigi
>
From h_ayguen at web.de Fri Dec 16 21:04:50 2016
From: h_ayguen at web.de (Hayati Ayguen)
Date: Fri, 16 Dec 2016 22:04:50 +0100
Subject: compiling rtl-sdr on win10 with qtcreator
In-Reply-To:
References:
<45A7D229-51FC-4ECE-8538-F9AE731992DB@web.de>
Message-ID: <0E4123F0-C6DC-4BFD-BA7B-C7CFD3810B88@web.de>
Hi Luigi,
i had created the CMakelist below the librtlsdr/tree/master/win32-qtcreator
subdirectory. You should directly open the CMakelist from here in qtcreator.
I just needed the first non commented line setting LIBUSBBASE:
# edit this path
SET( LIBUSBBASE C:/src/_foreign/libusb-1.0.20 )
Everything else comes from/with the qt/creator installation including mingw.
For me quite important is the FULL_STATIC Build option, that the result does not need any gcc/libusb or pthread dlls.
Kind Regards,
Hayati
---
Hayati Ayg?n
Am 16. Dezember 2016 16:33:00 MEZ, schrieb Luigi Tarenga :
>hello Hayati,
>thanks for the feedback. unfortunately I cannot find the commended
>lines you mention.
>just to be clear, I cloned rtl-sdr git and I'm at commit
>e3e6ee23b7f052327bf64c6908f5c09b75029edc
>
>I solved the problem editing cmake/Modules/FindLibUSB.cmake
>I addeded c:/..blablabla../libusb/include/libusb-1.0 and
>c:/..blablabla../libusb/lib
>in the find_path() and find_library() blocks respectively.
>
>I'm now trying to figure out how add pthread-win32 to the qt mingw (I
>have installed libpthread in
>the mingw directory used for compiling libusb but qtcreator seems to
>have its own mingw environment
>and the latter one is missing pthread-win32 ... )
>
>regards
>Luigi
>
>On Fri, Dec 16, 2016 at 2:52 PM, Hayati Ayguen wrote:
>> Hi Luigi,
>> i modified the pathes in the CMakeLists.txt for mingw/qtcreator for
>compilation. Think, i commented it in the head of the file.
>> Kind Regards,
>> Hayati
>> ---
>> Hayati Ayg?n
>>
>>
>> Am 16. Dezember 2016 13:18:58 MEZ, schrieb Luigi Tarenga
>:
>>>hello,
>>>I'm trying to build rtl-sdr on win10. I choosed to use mingw and
>>>qtcreator.
>>>I installed:
>>>cmake 3.7.1
>>>qtcreate 4.2.0
>>>mingw32 (to build libusb)
>>>
>>>I compiled libusb with mingw32 and automake and installed in
>>>Desktop\libusb\.
>>>
>>>Now I'm trying to find out how to generate make files for rtl-sdr
>>>passing
>>>the folder where I installed libusb (library and header) in
>qtcreator.
>>>I don't understand if I have to modify CMakeLists.txt or there is
>some
>>>gui to enter
>>>the correct parameter. I have even to find out if I have to explicit
>>>the
>>>variable LIBUSB_PKG_INCLUDE_DIRS or what...
>>>
>>>running cmake (from qtcreator) returns with error that I'm missing
>>>libusb and libpthread.
>>>I think that once I can solve the problem for libusb I will be able
>to
>>>solve even the one of
>>>libpthread. can someone help me in this phase?
>>>
>>>thanks
>>>Luigi
>>
From luigi.tarenga at gmail.com Sat Dec 17 10:15:32 2016
From: luigi.tarenga at gmail.com (Luigi Tarenga)
Date: Sat, 17 Dec 2016 11:15:32 +0100
Subject: compiling rtl-sdr on win10 with qtcreator
In-Reply-To: <0E4123F0-C6DC-4BFD-BA7B-C7CFD3810B88@web.de>
References:
<45A7D229-51FC-4ECE-8538-F9AE731992DB@web.de>
<0E4123F0-C6DC-4BFD-BA7B-C7CFD3810B88@web.de>
Message-ID:
Hi Hayati,
actually I'm working with a clone of git://git.osmocom.org/rtl-sdr
I remember the file you mention is on the librtlsdr fork on github...
( https://github.com/librtlsdr/librtlsdr/blob/master/win32-qtcreator/CMakeLists.txt
)
I'm missing something?
My objective now is to build the original rtl-sdr and try to apply some patches
on that tree. I will try out your cmake file in win32-qtcreator in the future
as I see it's simpler to use and the static library is a good idea.
As to yesterday I manager to build rtl-sdr. the summary is:
I tried to build with the mingw installed by qtcreator but this fail as it miss
libpthread and I can't figure out own to install additional library
into this mingw.
I then configured qtcreator to build using my mingw installed apart and in this
mingw I have libpthread installed. Initially it failed and I find out that
the in the file FindThread.cmake there is a reference to an different
library (older?)
I change the line:
SET (_Threads_pthreads_libname
pthreadG${THREADS_PTHREADS_WIN32_EXCEPTION_SCHEME}2)
with
SET (_Threads_pthreads_libname
libpthreadG${THREADS_PTHREADS_WIN32_EXCEPTION_SCHEME}-3)
does anyone know if I'm using a too recent pthread library or the
FindThread.cmake needs a patch?
anyway this solved my make generation problem. no problem during compilation.
Luigi
On Fri, Dec 16, 2016 at 10:04 PM, Hayati Ayguen wrote:
> Hi Luigi,
> i had created the CMakelist below the librtlsdr/tree/master/win32-qtcreator
> subdirectory. You should directly open the CMakelist from here in qtcreator.
>
> I just needed the first non commented line setting LIBUSBBASE:
>
> # edit this path
> SET( LIBUSBBASE C:/src/_foreign/libusb-1.0.20 )
>
> Everything else comes from/with the qt/creator installation including mingw.
>
> For me quite important is the FULL_STATIC Build option, that the result does not need any gcc/libusb or pthread dlls.
>
> Kind Regards,
> Hayati
>
>
> ---
> Hayati Ayg?n
>
>
> Am 16. Dezember 2016 16:33:00 MEZ, schrieb Luigi Tarenga :
>>hello Hayati,
>>thanks for the feedback. unfortunately I cannot find the commended
>>lines you mention.
>>just to be clear, I cloned rtl-sdr git and I'm at commit
>>e3e6ee23b7f052327bf64c6908f5c09b75029edc
>>
>>I solved the problem editing cmake/Modules/FindLibUSB.cmake
>>I addeded c:/..blablabla../libusb/include/libusb-1.0 and
>>c:/..blablabla../libusb/lib
>>in the find_path() and find_library() blocks respectively.
>>
>>I'm now trying to figure out how add pthread-win32 to the qt mingw (I
>>have installed libpthread in
>>the mingw directory used for compiling libusb but qtcreator seems to
>>have its own mingw environment
>>and the latter one is missing pthread-win32 ... )
>>
>>regards
>>Luigi
>>
>>On Fri, Dec 16, 2016 at 2:52 PM, Hayati Ayguen wrote:
>>> Hi Luigi,
>>> i modified the pathes in the CMakeLists.txt for mingw/qtcreator for
>>compilation. Think, i commented it in the head of the file.
>>> Kind Regards,
>>> Hayati
>>> ---
>>> Hayati Ayg?n
>>>
>>>
>>> Am 16. Dezember 2016 13:18:58 MEZ, schrieb Luigi Tarenga
>>:
>>>>hello,
>>>>I'm trying to build rtl-sdr on win10. I choosed to use mingw and
>>>>qtcreator.
>>>>I installed:
>>>>cmake 3.7.1
>>>>qtcreate 4.2.0
>>>>mingw32 (to build libusb)
>>>>
>>>>I compiled libusb with mingw32 and automake and installed in
>>>>Desktop\libusb\.
>>>>
>>>>Now I'm trying to find out how to generate make files for rtl-sdr
>>>>passing
>>>>the folder where I installed libusb (library and header) in
>>qtcreator.
>>>>I don't understand if I have to modify CMakeLists.txt or there is
>>some
>>>>gui to enter
>>>>the correct parameter. I have even to find out if I have to explicit
>>>>the
>>>>variable LIBUSB_PKG_INCLUDE_DIRS or what...
>>>>
>>>>running cmake (from qtcreator) returns with error that I'm missing
>>>>libusb and libpthread.
>>>>I think that once I can solve the problem for libusb I will be able
>>to
>>>>solve even the one of
>>>>libpthread. can someone help me in this phase?
>>>>
>>>>thanks
>>>>Luigi
>>>
>
From cinaed.simson at gmail.com Mon Dec 26 20:21:45 2016
From: cinaed.simson at gmail.com (Cinaed Simson)
Date: Mon, 26 Dec 2016 12:21:45 -0800
Subject: minor bug in gr-osmosdr's gnuradio-osmosdr.pc.in?
Message-ID: <105fd995-66fb-728a-4a85-a77c0f3e3e37@GMail.COM>
The include directory in gnuradio-osmosdr.pc.in
includedir=${prefix}/@GR_INCLUDE_DIR@
ends up pointing to
includedir=${prefix}/include
when the file gnuradio-osmosdr.pc is installed in $prefix/lib/pkgconfig.
But it appears the include files for gnuradio-osmosdr.pc are installed in
includedir=${prefix}/include/osmosdr
When I attempted to build software using gr-osmosdr outside of the
gnuradio tree, I had to add the subdirectory ./osmosdr to the include
path in gnuradio-osmosdr.pc otherwise cmake complained it couldn't find
the gnuradio-osmosdr includes.
Since it appears to build
gr-osmosdr
without the subdirectory osmosdr added to the include path, I'm not
really sure what's going on.
-- Cinaed
From 246tnt at gmail.com Mon Dec 26 20:37:38 2016
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 26 Dec 2016 21:37:38 +0100
Subject: minor bug in gr-osmosdr's gnuradio-osmosdr.pc.in?
In-Reply-To: <105fd995-66fb-728a-4a85-a77c0f3e3e37@GMail.COM>
References: <105fd995-66fb-728a-4a85-a77c0f3e3e37@GMail.COM>
Message-ID:
> When I attempted to build software using gr-osmosdr outside of the
> gnuradio tree, I had to add the subdirectory ./osmosdr to the include
> path in gnuradio-osmosdr.pc otherwise cmake complained it couldn't find
> the gnuradio-osmosdr includes.
The bug is in the software you're trying to build.
Software is supposed to use #include and not
source.h directly ( or more generally osmocom/XXX.h instead of XXX.h
directly)
Cheers,
Sylvain
From luigi.tarenga at gmail.com Wed Dec 28 11:52:51 2016
From: luigi.tarenga at gmail.com (Luigi Tarenga)
Date: Wed, 28 Dec 2016 12:52:51 +0100
Subject: [PATCH] gr-osmosdr: add set_bandwidth and independent gains via
extended_mode
Message-ID:
Hello list,
the following patch rely on librtlsdr fork on github. I would like to
receive feedback on what
is the best option to backport the commit:
https://github.com/librtlsdr/librtlsdr/commit/25d0e8e6737b93b3564ad04d0fd2cd5e91cefa8b
or alternatively put a preprocessor switch in this patch in order to
enable build against 2
different rtlsdr driver.
regards
Luigi
--- a/lib/rtl/rtl_source_c.cc
+++ b/lib/rtl/rtl_source_c.cc
@@ -88,7 +88,11 @@ rtl_source_c::rtl_source_c (const std::string &args)
_no_tuner(false),
_auto_gain(false),
_if_gain(0),
- _skipped(0)
+ _lna_gain(0),
+ _mix_gain(0),
+ _vga_gain(0),
+ _skipped(0),
+ _extended_mode(0)
{
int ret;
int index;
@@ -150,6 +154,9 @@ rtl_source_c::rtl_source_c (const std::string &args)
if (dict.count("offset_tune"))
offset_tune = boost::lexical_cast< unsigned int >(
dict["offset_tune"] );
+ if (dict.count("extended_mode"))
+ _extended_mode = boost::lexical_cast< bool >( dict["extended_mode"] );
+
_buf_num = _buf_len = _buf_head = _buf_used = _buf_offset = 0;
if (dict.count("buffers"))
@@ -528,6 +535,13 @@ std::vector
rtl_source_c::get_gain_names( size_t chan )
if ( rtlsdr_get_tuner_type(_dev) == RTLSDR_TUNER_E4000 ) {
names += "IF";
}
+
+ if ( rtlsdr_get_tuner_type(_dev) == RTLSDR_TUNER_R820T ) {
+ if ( _extended_mode ) {
+ names += "MIX";
+ names += "IF";
+ }
+ }
}
return names;
@@ -553,14 +567,31 @@ osmosdr::gain_range_t
rtl_source_c::get_gain_range( size_t chan )
osmosdr::gain_range_t rtl_source_c::get_gain_range( const std::string
& name, size_t chan )
{
- if ( "IF" == name ) {
- if ( _dev ) {
- if ( rtlsdr_get_tuner_type(_dev) == RTLSDR_TUNER_E4000 ) {
- return osmosdr::gain_range_t(3, 56, 1);
- } else {
+
+ if ( _dev ) {
+ if ( rtlsdr_get_tuner_type(_dev) == RTLSDR_TUNER_R820T ) {
+ if ( _extended_mode ) {
+ if ( "LNA" == name ) {
+ return osmosdr::gain_range_t( 0, 15, 1 );
+ }
+
+ if ( "MIX" == name ) {
+ return osmosdr::gain_range_t( 0, 15, 1 );
+ }
+
+ if ( "IF" == name ) {
+ return osmosdr::gain_range_t( 0, 15, 1 );
+ }
+
return osmosdr::gain_range_t();
}
}
+
+ if ( rtlsdr_get_tuner_type(_dev) == RTLSDR_TUNER_E4000 ) {
+ if ( "IF" == name ) {
+ return osmosdr::gain_range_t(3, 56, 1);
+ }
+ }
}
return get_gain_range( chan );
@@ -584,21 +615,86 @@ bool rtl_source_c::get_gain_mode( size_t chan )
return _auto_gain;
}
+double rtl_source_c::set_bandwidth( double bandwidth, size_t chan )
+{
+ if (_dev) {
+ return (double)rtlsdr_set_tuner_bandwidth( _dev, (uint32_t)bandwidth);
+ }
+
+ return 0;
+}
+
double rtl_source_c::set_gain( double gain, size_t chan )
{
osmosdr::gain_range_t rf_gains = rtl_source_c::get_gain_range( chan );
- if (_dev) {
+ if ( _dev ) {
rtlsdr_set_tuner_gain( _dev, int(rf_gains.clip(gain) * 10.0) );
}
return get_gain( chan );
}
+double rtl_source_c::set_lna_gain( double gain, size_t chan )
+{
+ osmosdr::gain_range_t gains = rtl_source_c::get_gain_range( "LNA",
chan );
+
+ if ( _dev ) {
+ _lna_gain = gains.clip( gain );
+ return rtlsdr_set_tuner_gain_ext( _dev, int(_lna_gain),
int(_mix_gain), int(_vga_gain) );
+ }
+
+ return _lna_gain;
+}
+
+double rtl_source_c::set_mix_gain( double gain, size_t chan )
+{
+ osmosdr::gain_range_t gains = rtl_source_c::get_gain_range( "MIX",
chan );
+
+ if ( _dev ) {
+ _mix_gain = gains.clip( gain );
+ return rtlsdr_set_tuner_gain_ext( _dev, int(_lna_gain),
int(_mix_gain), int(_vga_gain) );
+ }
+
+ return _mix_gain;
+}
+
+double rtl_source_c::set_vga_gain( double gain, size_t chan )
+{
+ osmosdr::gain_range_t gains = rtl_source_c::get_gain_range( "IF", chan );
+
+ if ( _dev ) {
+ _vga_gain = gains.clip( gain );
+ return rtlsdr_set_tuner_gain_ext( _dev, int(_lna_gain),
int(_mix_gain), int(_vga_gain) );
+ }
+
+ return _vga_gain;
+}
+
double rtl_source_c::set_gain( double gain, const std::string & name,
size_t chan)
{
- if ( "IF" == name ) {
- return set_if_gain( gain, chan );
+ if ( _dev ) {
+ if ( rtlsdr_get_tuner_type(_dev) == RTLSDR_TUNER_R820T ) {
+ if ( _extended_mode ) {
+ if ( "LNA" == name ) {
+ return set_lna_gain( gain, chan );
+ }
+
+ if ( "MIX" == name ) {
+ return set_mix_gain( gain, chan );
+ }
+
+ if ( "IF" == name ) {
+ return set_vga_gain( gain, chan );
+ }
+ }
+ }
+
+ if ( rtlsdr_get_tuner_type(_dev) == RTLSDR_TUNER_E4000 ) {
+ if ( "IF" == name ) {
+ return set_if_gain( gain, chan );
+ }
+ }
}
return set_gain( gain, chan );
@@ -614,6 +710,20 @@ double rtl_source_c::get_gain( size_t chan )
double rtl_source_c::get_gain( const std::string & name, size_t chan )
{
+ if ( _extended_mode ) {
+ if ( "LNA" == name ) {
+ return _lna_gain;
+ }
+
+ if ( "MIX" == name ) {
+ return _mix_gain;
+ }
+
+ if ( "IF" == name ) {
+ return _vga_gain;
+ }
+ }
+
if ( "IF" == name ) {
return _if_gain;
}
diff --git a/lib/rtl/rtl_source_c.h b/lib/rtl/rtl_source_c.h
index 76de400..bb20e5c 100644
--- a/lib/rtl/rtl_source_c.h
+++ b/lib/rtl/rtl_source_c.h
@@ -101,12 +101,16 @@ public:
osmosdr::gain_range_t get_gain_range( const std::string & name,
size_t chan = 0 );
bool set_gain_mode( bool automatic, size_t chan = 0 );
bool get_gain_mode( size_t chan = 0 );
+ double set_bandwidth( double bandwidth, size_t chan = 0 );
double set_gain( double gain, size_t chan = 0 );
double set_gain( double gain, const std::string & name, size_t chan
= 0 );
double get_gain( size_t chan = 0 );
double get_gain( const std::string & name, size_t chan = 0 );
double set_if_gain( double gain, size_t chan = 0 );
+ double set_lna_gain( double gain, size_t chan = 0 );
+ double set_mix_gain( double gain, size_t chan = 0 );
+ double set_vga_gain( double gain, size_t chan = 0 );
std::vector< std::string > get_antennas( size_t chan = 0 );
std::string set_antenna( const std::string & antenna, size_t chan = 0 );
@@ -141,7 +145,12 @@ private:
bool _no_tuner;
bool _auto_gain;
double _if_gain;
+ double _lna_gain;
+ double _mix_gain;
+ double _vga_gain;
unsigned int _skipped;
+
+ bool _extended_mode;
};
#endif /* INCLUDED_RTLSDR_SOURCE_C_H */
From 246tnt at gmail.com Wed Dec 28 12:09:36 2016
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 28 Dec 2016 13:09:36 +0100
Subject: [PATCH] gr-osmosdr: add set_bandwidth and independent gains via
extended_mode
In-Reply-To:
References:
Message-ID:
Hi,
> the following patch rely on librtlsdr fork on github. I would like to
> receive feedback on what
> is the best option to backport the commit:
> https://github.com/librtlsdr/librtlsdr/commit/25d0e8e6737b93b3564ad04d0fd2cd5e91cefa8b
There is so many things wrong with this patch that I don't even know
where to start :
- Rename a function to _old and then not use it ... wtf ... if it's
not used, remove it, don't leave it there for posterity's sake, that's
why we have source revision control !
- r82xx_set_gain now has 3 completely distinct operating modes for no
good reasons ... just make 3 distinct functions and call the right
one. Everywhere that function is called the "mode" params are
fixed/hardcoded ...
- Introduces a new API rtlsdr_set_tuner_gain_ext which has hard coded
calls to R820T functions without the appropriate tuner type
indirections and without appropriate fallbacks or error code if the
dongle uses a tuner not supporting the 'ext' mode.
Seriously people wonder why those don't get upstream, but I apply this
and my E4k dongle might just not work or plain crash with any app
using that new API ...
Cheers,
Sylvain
From 246tnt at gmail.com Wed Dec 28 12:24:59 2016
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 28 Dec 2016 13:24:59 +0100
Subject: [PATCH] gr-osmosdr: add set_bandwidth and independent gains via
extended_mode
In-Reply-To:
References:
Message-ID:
In my haste, I also forgot some other things wrong :
- TAB vs SPACE / indentation / code style errors
- Gratuitous whitespace changes
- Change the .gitignore completely unrelated to the commit but still
present in it...
From luigi.tarenga at gmail.com Thu Dec 29 12:27:29 2016
From: luigi.tarenga at gmail.com (Luigi Tarenga)
Date: Thu, 29 Dec 2016 13:27:29 +0100
Subject: [RFC PATCH] rtl-sdr: add support for independent gain settings
Message-ID:
hello list,
with this patch I try to start adding support for independent gain
setting to rtl-sdr.
If this will go on (after review of course) I will be able to send a
patch for gr-osmosdr
to expose those controls to end user applications like gqrx.
I see some users wish to experiment with manual tuning like it's
possible to do on SDR#
with airspy dongle that use R820T tuner. I see some users started their
own tree to add this.
There will be some complexity added but I think this can be masked with
a proper
patching of gr-osmosdr to no break compatibility with existing software
and let users
get the old control layout.
In a future patch I wish to add:
- single automatic gain control. I ask if it's ok to expose a
function like
rtlsdr_set_tuner_gain_mode() and internally recycle the function
added by
this patch but with a new *mode* parameter.
- optimized gain for *max sensitivity* and *max linearity* like those
found in airspy code.
here I ask if is fine to expose gains as just integers instead of
tenth of dB.
best regards
Luigi
Signed-off-by: Luigi Tarenga
---
include/rtl-sdr.h | 62 ++++++++++++++++++++++++++
include/tuner_r82xx.h | 3 ++
src/librtlsdr.c | 120
+++++++++++++++++++++++++++++++++++++++++++++++---
src/tuner_r82xx.c | 53 +++++++++++++++++++++-
4 files changed, 230 insertions(+), 8 deletions(-)
diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h
index fe64bea..2eec99c 100644
--- a/include/rtl-sdr.h
+++ b/include/rtl-sdr.h
@@ -216,6 +216,41 @@ RTLSDR_API int rtlsdr_get_tuner_gains(rtlsdr_dev_t
*dev, int *gains);
RTLSDR_API int rtlsdr_set_tuner_gain(rtlsdr_dev_t *dev, int gain);
/*!
+ * Set the LNA gain for the device.
+ *
+ * Valid gain values for the R820T tuner are from 0 to 15.
+ *
+ * \param dev the device handle given by rtlsdr_open()
+ * \param gain between 0 and 15.
+ * \return 0 on success
+ */
+RTLSDR_API int rtlsdr_set_tuner_lna_gain(rtlsdr_dev_t *dev, int gain);
+
+/*!
+ * Set the Mixer gain for the device.
+ * Manual gain mode must be enabled for this to work.
+ *
+ * Valid gain values for the R820T tuner are from 0 to 15.
+ *
+ * \param dev the device handle given by rtlsdr_open()
+ * \param gain between 0 and 15.
+ * \return 0 on success
+ */
+RTLSDR_API int rtlsdr_set_tuner_mix_gain(rtlsdr_dev_t *dev, int gain);
+
+/*!
+ * Set the VGA gain for the device.
+ * Manual gain mode must be enabled for this to work.
+ *
+ * Valid gain values for the R820T tuner are from 0 to 15.
+ *
+ * \param dev the device handle given by rtlsdr_open()
+ * \param gain between 0 and 15.
+ * \return 0 on success
+ */
+RTLSDR_API int rtlsdr_set_tuner_vga_gain(rtlsdr_dev_t *dev, int gain);
+
+/*!
* Set the bandwidth for the device.
*
* \param dev the device handle given by rtlsdr_open()
@@ -233,6 +268,33 @@ RTLSDR_API int
rtlsdr_set_tuner_bandwidth(rtlsdr_dev_t *dev, uint32_t bw);
RTLSDR_API int rtlsdr_get_tuner_gain(rtlsdr_dev_t *dev);
/*!
+ * Get actual LNA gain the device is configured to.
+ * The LNA gain must have been set with \ref rtlsdr_set_tuner_lna_gain
function.
+ *
+ * \param dev the device handle given by rtlsdr_open()
+ * \return -1 on error, LNA gain register value (0 to 15 for R820T).
+ */
+RTLSDR_API int rtlsdr_get_tuner_lna_gain(rtlsdr_dev_t *dev);
+
+/*!
+ * Get actual Mixer gain the device is configured to.
+ * The Mixer gain must have been set with \ref
rtlsdr_set_tuner_mix_gain function.
+ *
+ * \param dev the device handle given by rtlsdr_open()
+ * \return -1 on error, Mixer gain register value (0 to 15 for R820T).
+ */
+RTLSDR_API int rtlsdr_get_tuner_mix_gain(rtlsdr_dev_t *dev);
+
+/*!
+ * Get actual VGA gain the device is configured to.
+ * The VGA gain must have been set with \ref rtlsdr_set_tuner_vga_gain
function.
+ *
+ * \param dev the device handle given by rtlsdr_open()
+ * \return -1 on error, VGA gain register value (0 to 15 for R820T).
+ */
+RTLSDR_API int rtlsdr_get_tuner_vga_gain(rtlsdr_dev_t *dev);
+
+/*!
* Set the intermediate frequency gain for the device.
*
* \param dev the device handle given by rtlsdr_open()
diff --git a/include/tuner_r82xx.h b/include/tuner_r82xx.h
index f6c206a..3ddb9c6 100644
--- a/include/tuner_r82xx.h
+++ b/include/tuner_r82xx.h
@@ -115,6 +115,9 @@ int r82xx_standby(struct r82xx_priv *priv);
int r82xx_init(struct r82xx_priv *priv);
int r82xx_set_freq(struct r82xx_priv *priv, uint32_t freq);
int r82xx_set_gain(struct r82xx_priv *priv, int set_manual_gain, int
gain);
+int r82xx_set_lna_gain(struct r82xx_priv *priv, int gain);
+int r82xx_set_mix_gain(struct r82xx_priv *priv, int gain);
+int r82xx_set_vga_gain(struct r82xx_priv *priv, int gain);
int r82xx_set_bandwidth(struct r82xx_priv *priv, int bandwidth,
uint32_t rate);
#endif
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 9b7ba52..10556a8 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -62,6 +62,9 @@ typedef struct rtlsdr_tuner_iface {
int (*set_freq)(void *, uint32_t freq /* Hz */);
int (*set_bw)(void *, int bw /* Hz */);
int (*set_gain)(void *, int gain /* tenth dB */);
+ int (*set_lna_gain)(void *, int gain /* register value */);
+ int (*set_mix_gain)(void *, int gain /* register value */);
+ int (*set_vga_gain)(void *, int gain /* register value */);
int (*set_if_gain)(void *, int stage, int gain /* tenth dB */);
int (*set_gain_mode)(void *, int manual);
} rtlsdr_tuner_iface_t;
@@ -117,6 +120,9 @@ struct rtlsdr_dev {
uint32_t offs_freq; /* Hz */
int corr; /* ppm */
int gain; /* tenth dB */
+ int lna_gain; /* register value */
+ int mix_gain; /* register value */
+ int vga_gain; /* register value */
struct e4k_state e4k_s;
struct r82xx_config r82xx_c;
struct r82xx_priv r82xx_p;
@@ -258,6 +264,18 @@ int r820t_set_gain(void *dev, int gain) {
rtlsdr_dev_t* devt = (rtlsdr_dev_t*)dev;
return r82xx_set_gain(&devt->r82xx_p, 1, gain);
}
+int r820t_set_lna_gain(void *dev, int gain) {
+ rtlsdr_dev_t* devt = (rtlsdr_dev_t*)dev;
+ return r82xx_set_lna_gain(&devt->r82xx_p, gain);
+}
+int r820t_set_mix_gain(void *dev, int gain) {
+ rtlsdr_dev_t* devt = (rtlsdr_dev_t*)dev;
+ return r82xx_set_mix_gain(&devt->r82xx_p, gain);
+}
+int r820t_set_vga_gain(void *dev, int gain) {
+ rtlsdr_dev_t* devt = (rtlsdr_dev_t*)dev;
+ return r82xx_set_vga_gain(&devt->r82xx_p, gain);
+}
int r820t_set_gain_mode(void *dev, int manual) {
rtlsdr_dev_t* devt = (rtlsdr_dev_t*)dev;
return r82xx_set_gain(&devt->r82xx_p, manual, 0);
@@ -266,36 +284,37 @@ int r820t_set_gain_mode(void *dev, int manual) {
/* definition order must match enum rtlsdr_tuner */
static rtlsdr_tuner_iface_t tuners[] = {
{
- NULL, NULL, NULL, NULL, NULL, NULL, NULL /* dummy for unknown
tuners */
+ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL /*
dummy for unknown tuners */
},
{
e4000_init, e4000_exit,
- e4000_set_freq, e4000_set_bw, e4000_set_gain, e4000_set_if_gain,
+ e4000_set_freq, e4000_set_bw, e4000_set_gain, NULL, NULL, NULL,
e4000_set_if_gain,
e4000_set_gain_mode
},
{
_fc0012_init, fc0012_exit,
- fc0012_set_freq, fc0012_set_bw, _fc0012_set_gain, NULL,
+ fc0012_set_freq, fc0012_set_bw, _fc0012_set_gain, NULL, NULL,
NULL, NULL,
fc0012_set_gain_mode
},
{
_fc0013_init, fc0013_exit,
- fc0013_set_freq, fc0013_set_bw, _fc0013_set_gain, NULL,
+ fc0013_set_freq, fc0013_set_bw, _fc0013_set_gain, NULL, NULL,
NULL, NULL,
fc0013_set_gain_mode
},
{
fc2580_init, fc2580_exit,
- _fc2580_set_freq, fc2580_set_bw, fc2580_set_gain, NULL,
+ _fc2580_set_freq, fc2580_set_bw, fc2580_set_gain, NULL, NULL,
NULL, NULL,
fc2580_set_gain_mode
},
{
r820t_init, r820t_exit,
- r820t_set_freq, r820t_set_bw, r820t_set_gain, NULL,
+ r820t_set_freq, r820t_set_bw, r820t_set_gain,
+ r820t_set_lna_gain, r820t_set_mix_gain, r820t_set_vga_gain, NULL,
r820t_set_gain_mode
},
{
r820t_init, r820t_exit,
- r820t_set_freq, r820t_set_bw, r820t_set_gain, NULL,
+ r820t_set_freq, r820t_set_bw, r820t_set_gain, NULL, NULL, NULL,
NULL,
r820t_set_gain_mode
},
};
@@ -1049,6 +1068,69 @@ int rtlsdr_set_tuner_gain(rtlsdr_dev_t *dev, int
gain)
return r;
}
+int rtlsdr_set_tuner_lna_gain(rtlsdr_dev_t *dev, int gain)
+{
+ int r = 0;
+
+ if (!dev || !dev->tuner)
+ return -1;
+
+ if (dev->tuner->set_lna_gain) {
+ rtlsdr_set_i2c_repeater(dev, 1);
+ r = dev->tuner->set_lna_gain((void *)dev, gain);
+ rtlsdr_set_i2c_repeater(dev, 0);
+ }
+
+ if (!r)
+ dev->lna_gain = gain;
+ else
+ dev->lna_gain = 0;
+
+ return r;
+}
+
+int rtlsdr_set_tuner_mix_gain(rtlsdr_dev_t *dev, int gain)
+{
+ int r = 0;
+
+ if (!dev || !dev->tuner)
+ return -1;
+
+ if (dev->tuner->set_mix_gain) {
+ rtlsdr_set_i2c_repeater(dev, 1);
+ r = dev->tuner->set_mix_gain((void *)dev, gain);
+ rtlsdr_set_i2c_repeater(dev, 0);
+ }
+
+ if (!r)
+ dev->mix_gain = gain;
+ else
+ dev->mix_gain = 0;
+
+ return r;
+}
+
+int rtlsdr_set_tuner_vga_gain(rtlsdr_dev_t *dev, int gain)
+{
+ int r = 0;
+
+ if (!dev || !dev->tuner)
+ return -1;
+
+ if (dev->tuner->set_vga_gain) {
+ rtlsdr_set_i2c_repeater(dev, 1);
+ r = dev->tuner->set_vga_gain((void *)dev, gain);
+ rtlsdr_set_i2c_repeater(dev, 0);
+ }
+
+ if (!r)
+ dev->vga_gain = gain;
+ else
+ dev->vga_gain = 0;
+
+ return r;
+}
+
int rtlsdr_get_tuner_gain(rtlsdr_dev_t *dev)
{
if (!dev)
@@ -1057,6 +1139,30 @@ int rtlsdr_get_tuner_gain(rtlsdr_dev_t *dev)
return dev->gain;
}
+int rtlsdr_get_tuner_lna_gain(rtlsdr_dev_t *dev)
+{
+ if (!dev)
+ return -1;
+
+ return dev->lna_gain;
+}
+
+int rtlsdr_get_tuner_mix_gain(rtlsdr_dev_t *dev)
+{
+ if (!dev)
+ return -1;
+
+ return dev->mix_gain;
+}
+
+int rtlsdr_get_tuner_vga_gain(rtlsdr_dev_t *dev)
+{
+ if (!dev)
+ return -1;
+
+ return dev->vga_gain;
+}
+
int rtlsdr_set_tuner_if_gain(rtlsdr_dev_t *dev, int stage, int gain)
{
int r = 0;
diff --git a/src/tuner_r82xx.c b/src/tuner_r82xx.c
index f620238..64d412b 100644
--- a/src/tuner_r82xx.c
+++ b/src/tuner_r82xx.c
@@ -1018,7 +1018,7 @@ int r82xx_set_gain(struct r82xx_priv *priv, int
set_manual_gain, int gain)
if (rc < 0)
return rc;
- /* Mixer auto off */
+ /* Mixer auto off */
rc = r82xx_write_reg_mask(priv, 0x07, 0, 0x10);
if (rc < 0)
return rc;
@@ -1073,6 +1073,57 @@ int r82xx_set_gain(struct r82xx_priv *priv, int
set_manual_gain, int gain)
return 0;
}
+int r82xx_set_lna_gain(struct r82xx_priv *priv, int gain)
+{
+ int rc;
+
+ /* LNA auto off */
+ rc = r82xx_write_reg_mask(priv, 0x05, 0x10, 0x10);
+ if (rc < 0)
+ return rc;
+
+ /* set LNA gain */
+ rc = r82xx_write_reg_mask(priv, 0x05, (uint8_t) gain, 0x0f);
+ if (rc < 0)
+ return rc;
+
+ return 0;
+}
+
+int r82xx_set_mix_gain(struct r82xx_priv *priv, int gain)
+{
+ int rc;
+
+ /* Mixer auto off */
+ rc = r82xx_write_reg_mask(priv, 0x07, 0, 0x10);
+ if (rc < 0)
+ return rc;
+
+ /* set Mixer gain */
+ rc = r82xx_write_reg_mask(priv, 0x07, (uint8_t) gain, 0x0f);
+ if (rc < 0)
+ return rc;
+
+ return 0;
+}
+
+int r82xx_set_vga_gain(struct r82xx_priv *priv, int gain)
+{
+ int rc;
+
+ /* VGA auto off */
+ rc = r82xx_write_reg_mask(priv, 0x0c, 0, 0x10);
+ if (rc < 0)
+ return rc;
+
+ /* set VGA gain */
+ rc = r82xx_write_reg_mask(priv, 0x0c, (uint8_t) gain, 0x0f);
+ if (rc < 0)
+ return rc;
+
+ return 0;
+}
+
/* Bandwidth contribution by low-pass filter. */
static const int r82xx_if_low_pass_bw_table[] = {
1700000, 1600000, 1550000, 1450000, 1200000, 900000, 700000,
550000, 450000, 350000
--
2.11.0
From 246tnt at gmail.com Thu Dec 29 15:45:12 2016
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 29 Dec 2016 16:45:12 +0100
Subject: [RFC PATCH] rtl-sdr: add support for independent gain settings
In-Reply-To:
References:
Message-ID:
Hi,
First off, thanks for trying to clean this up into a mergeable state !
I can't actually try the patch, it doesn't apply. How did you generate
and send the patch to the list ? Make sure to use git-send-email as
mail-software will usually mangle the patch and prevent it from being
used ...
Comments on the patch itself :
* Doc and API for the top-level functions (exposed one) should be
tuner independent, so you can't reference R820T directly in there, nor
can you expect the user to know register values ... that's why API use
tenth of dB there and do the mapping in a tuner specific way in the
actual tuner driver.
* I'm not a big fan of adding 3 methods to the API ... what happens
when the R820T3 comes out with one more gain stage ? ...
And yes, I know there is a "IF" one in there that pretty much
matches E4k only, but IMHO that's a mistage. We can't change the past
but we can certainly learn from it and avoid repeating it.
So from the API standpoint, I would use the concept of "named" gain stages.
You get :
- one function to query the available gain stages
- one function to query for a given gain stages what gain values
are possible / valid
- one function to set the curent gain value
- one function to get the current gain value
This way :
1) We could actually cleanup the E4k impl as well and also properly
expose its various gain stages
2) In gr-osmosdr you can also query / register named gain stages at
runtime depending on what's really available
3) That API should be fairly future proof.
I didn't really understand the linearity / gain question but IIUC that
should be doable without new functions :
The meaning of the set_gain_mode existing API could be extended to be
a bitfield / flags. ( With the existing defined 0|1 value staying what
they are but allowing new ones to be defined).
And so you'd have the 0|2 flag to select the preferred gain setting
algorithm. then the tuner can store that in its internal state and act
appropriately on the next gain setting call.
CC to steve and dimitri, please chime in if you disagree with my view on this :)
Cheers,
Sylvain
From luigi.tarenga at gmail.com Thu Dec 29 16:05:05 2016
From: luigi.tarenga at gmail.com (Luigi Tarenga)
Date: Thu, 29 Dec 2016 17:05:05 +0100
Subject: [RFC PATCH] rtl-sdr: add support for independent gain settings
In-Reply-To:
References:
Message-ID: <871d53ed-0434-23f9-0ad7-e285be8804a7@gmail.com>
Hi Sylvain,
many thanks for the feedback. I apologie for the inconvenient about
patch format.
I used git format-email but seems I did something wrong in the cut&paste.
If nobody ask for, I will avoid repost the patch at the current state.
I agree with you on all point but one. I would like to have a way to get
gains values
as an array of int and expose integers if wanted (maybe by just using an
index?) .
I can copy values from those measured by Steve of course but there can
be a case
where a device diverge from those (not linear, bad batch, overtemp
etc..)? Since usually we work
with dbFS that have nothing to do with dBm or dbuV I think using simple
integer
is still ok. Still I will try to put things in a way where you can query
the gains value choosing
between integers and tenth of dB.
I will try to put the new patch down asap but I will be on vacation next
week so I'm not sure
to be able to finish very soon.
best regards and happy new year
Luigi
On 29/12/16 16:45, Sylvain Munaut wrote:
> Hi,
>
>
> First off, thanks for trying to clean this up into a mergeable state !
>
> I can't actually try the patch, it doesn't apply. How did you generate
> and send the patch to the list ? Make sure to use git-send-email as
> mail-software will usually mangle the patch and prevent it from being
> used ...
>
> Comments on the patch itself :
>
> * Doc and API for the top-level functions (exposed one) should be
> tuner independent, so you can't reference R820T directly in there, nor
> can you expect the user to know register values ... that's why API use
> tenth of dB there and do the mapping in a tuner specific way in the
> actual tuner driver.
>
> * I'm not a big fan of adding 3 methods to the API ... what happens
> when the R820T3 comes out with one more gain stage ? ...
> And yes, I know there is a "IF" one in there that pretty much
> matches E4k only, but IMHO that's a mistage. We can't change the past
> but we can certainly learn from it and avoid repeating it.
>
> So from the API standpoint, I would use the concept of "named" gain stages.
> You get :
> - one function to query the available gain stages
> - one function to query for a given gain stages what gain values
> are possible / valid
> - one function to set the curent gain value
> - one function to get the current gain value
>
> This way :
> 1) We could actually cleanup the E4k impl as well and also properly
> expose its various gain stages
> 2) In gr-osmosdr you can also query / register named gain stages at
> runtime depending on what's really available
> 3) That API should be fairly future proof.
>
> I didn't really understand the linearity / gain question but IIUC that
> should be doable without new functions :
> The meaning of the set_gain_mode existing API could be extended to be
> a bitfield / flags. ( With the existing defined 0|1 value staying what
> they are but allowing new ones to be defined).
> And so you'd have the 0|2 flag to select the preferred gain setting
> algorithm. then the tuner can store that in its internal state and act
> appropriately on the next gain setting call.
>
>
> CC to steve and dimitri, please chime in if you disagree with my view on this :)
>
> Cheers,
>
> Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From luigi.tarenga at gmail.com Thu Dec 29 16:31:54 2016
From: luigi.tarenga at gmail.com (Luigi Tarenga)
Date: Thu, 29 Dec 2016 17:31:54 +0100
Subject: [RFC PATCH] rtl-sdr: add support to change FIR coefficients
Message-ID:
Hello list,
these days I was experimenting with the FIR filters. If my reasoning are
correct
there is rooms for improvement with some trade-off between bandwidth
flatness
and image aliasing. I'm not saying the default FIR is to trash but I
think there can
be specialized application that will benefit from a custom FIR.
Even to just let more people test my theory I need support for FIR
coefficient loading
so even who can't program the driver but have lab test equipment can
give me a
feedback. I have prepared a patch for rtl-sdr and gr-osmosdr to load FIR
coefficients
with a device string like
"rtl=0,fir=50:54:57:60:63:65:68:70:72:74:75:77:78:78:79:79"
for a little discussion see here with some screenshot:
https://www.reddit.com/r/RTLSDR/comments/5jqk5h/playing_with_rtl2832u_fir_filter/
I'm looking for feedback and once this patch get accepted (I hope so :) )
I will push the one for gr-osmosdr.
best regards
Luigi
PS: I hope to not send another garbage patch....
Signed-off-by: Luigi Tarenga
---
include/rtl-sdr.h | 9 +++++++++
src/librtlsdr.c | 6 ++++++
2 files changed, 15 insertions(+)
diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h
index fe64bea..74cd765 100644
--- a/include/rtl-sdr.h
+++ b/include/rtl-sdr.h
@@ -169,6 +169,15 @@ RTLSDR_API int
rtlsdr_set_freq_correction(rtlsdr_dev_t *dev, int ppm);
*/
RTLSDR_API int rtlsdr_get_freq_correction(rtlsdr_dev_t *dev);
+/*!
+ * Load and set FIR filter coefficients.
+ *
+ * \param dev the device handle given by rtlsdr_open()
+ * \param new_fir the vector of 16 integer FIR coefficients
+ * \return 0 on success
+ */
+RTLSDR_API int rtlsdr_load_fir_coefficients(rtlsdr_dev_t *dev, int
*new_fir);
+
enum rtlsdr_tuner {
RTLSDR_TUNER_UNKNOWN = 0,
RTLSDR_TUNER_E4000,
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 9b7ba52..4b7855f 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -613,6 +613,12 @@ int rtlsdr_set_fir(rtlsdr_dev_t *dev)
return 0;
}
+int rtlsdr_load_fir_coefficients(rtlsdr_dev_t *dev, int *new_fir)
+{
+ memcpy(dev->fir, new_fir, sizeof(fir_default));
+ return rtlsdr_set_fir(dev);
+}
+
void rtlsdr_init_baseband(rtlsdr_dev_t *dev)
{
unsigned int i;
--
2.11.0
From martin.m at suddenlink.net Fri Dec 30 18:20:01 2016
From: martin.m at suddenlink.net (Martin McCormick)
Date: Fri, 30 Dec 2016 12:20:01 -0600
Subject: Just Getting Started with the SDR Dongles.
Message-ID:
Here are some real beginner questions that I would like
to have a better understanding of concerning SDR in general and
the rtl dongles:
I understand that the I and Q signals are both 8-bit
numbers so each one can have 2^8 possible levels. Is the in-phase
value related to the amplitude of the signal such that frequency
variations within the pass band don't change it much?
Is the Q or Quadrature value something that varies with
whether or not the frequency is higher or lower than the center
frequency set in to the device?
I could imagine that if the Q value responds to changes
in frequency that one could get the effect of a discriminator
circuit.
I bought a couple of the rtl dongles and tried out the
rtl-fm program to receive local FM signals and it worked quite
well.
Finally, what determines the pass-band? It did seem to
get smaller if I tried a 12,000 HZ sample rate. I also was
surprised at how accurate the frequency is.
Other than the fact that I am at the low end of the
learning curve, I see all kinds of possibilities.
Martin McCormick WB5AGZ
From marcus.mueller at ettus.com Fri Dec 30 23:00:01 2016
From: marcus.mueller at ettus.com (=?UTF-8?Q?Marcus_M=c3=bcller?=)
Date: Sat, 31 Dec 2016 00:00:01 +0100
Subject: Just Getting Started with the SDR Dongles.
In-Reply-To:
References:
Message-ID: <9c473dbc-1966-5110-bcc8-da90f5c7cb0c@ettus.com>
Hi Martin,
let me quickly address this in-text
On 12/30/2016 07:20 PM, Martin McCormick wrote:
> Here are some real beginner questions that I would like
> to have a better understanding of concerning SDR in general and
> the rtl dongles:
>
> I understand that the I and Q signals are both 8-bit
> numbers so each one can have 2^8 possible levels. Is the in-phase
> value related to the amplitude of the signal such that frequency
> variations within the pass band don't change it much?
Short answer: Yep.
Long answer: analog filters are never perfectly flat; in fact, the
flatter they are, the more expensive. But: if you use a bandwidth of
multiple MHz, and your signal of interest shifts within that by a
couple 100 kHz, you can basically assume flatness.
>
> Is the Q or Quadrature value something that varies with
> whether or not the frequency is higher or lower than the center
> frequency set in to the device?
You should not consider I and Q to be independent things. I and Q are
*two* physical analog signals, but IQ **together** is the baseband
signal that represents the passband (==RF) signal that you want to observe.
If there is a gain difference, we call that /IQ imbalance/, and it's
detrimental to any phase-sensitive modulation; therefore, receivers are
designed to minimize that effect. I and Q analog signal chains are
always designed to be as identical as possible! In fact, the only
difference is that the I signal is the RF signal mixed with a *cosine*
of the RF center frequency (and then low-pass filtered), and the Q
signal is the RF signal mixed with a *sine* of the same frequency ? the
two oscillators used for mixing are 90? out-of-phase, which is why the
first one is called *I*nphase, and the second *Q*uadrature (if you draw
a constellation diagram, the Q axis is orthogonal to the I axis).
>
> I could imagine that if the Q value responds to changes
> in frequency that one could get the effect of a discriminator
> circuit.
No, sorry. As explained, I and Q are exactly the same, but for a 90?
oscillator phase shift. That's how you convert a *real-valued passband*
to a *complex baseband* signal (just to give you two terms to look out for).
> I bought a couple of the rtl dongles and tried out the
> rtl-fm program to receive local FM signals and it worked quite
> well.
>
> Finally, what determines the pass-band? It did seem to
> get smaller if I tried a 12,000 HZ sample rate. I also was
> surprised at how accurate the frequency is.
So: The passband that you can observe is from -f_sample/2 to +f_sample/2
around the frequency you tune to. Filtering is adjusted to give you a
perfect-as-feasible part of the spectrum that fits into that.
>
> Other than the fact that I am at the low end of the
> learning curve, I see all kinds of possibilities.
:) Don't worry, you seem to be doing fine so far.
I don't really know from which background you're coming from, but if
you're rather curious and want to learn about *why* we use SDR, and how
that actually works, I'd recommend something like [1] (which also
explains in detail what I and Q are). Beware: It's pretty math-y !
That's why I like SDR: It's really just doing math, but that math
actually does something to a signal that converts an intangible RF wave
to something very /practical/ (e.g. audible, if audio) and
/understandable, rather than just observable/ (as math concepts).
If you're not *that* curious (which I really couldn't blame you for), a
simple explanation for I and Q is that if you simply mix something with
a tone of its center frequency, than half of the signal (the upper
sideband) ends up on low, positive frequencies, whereas the other half
ends up on the negative frequencies, theoretically: mixing with a tone
shifts by the tone's frequency, and if you mix with the center
frequency, what was originally right and left of that center frequency
in spectrum ends up around 0Hz. Since with "normal" real signals, you
can't tell positive from negative frequencies (I can look at a cosine of
frequency f or -f for as long as I want, cos(f t) == cos (-f t)), you
need a way to tell positive from negative frequencies. The combination
of the two mixing products of sine and cosine of the same frequency does
that.
Best regards,
Marcus
[1] Free PDF:
http://www.afidc.ethz.ch/A_Foundation_in_Digital_Communication/Getting_The_Book.html