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 Mode gain_mode$(n) False bool \#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 Mode gain_mode$(n) > False bool \#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 Mode gain_mode$(n) >> False bool \#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