osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
912 discussions

[PATCH] gr-osmosdr: add set_bandwidth and independent gains via extended_mode
by Luigi Tarenga 28 Dec '16

28 Dec '16

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/25d0e8e6737b93b3564ad04d0fd2c… 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<std::string> 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 */

2 2

minor bug in gr-osmosdr's gnuradio-osmosdr.pc.in?
by Cinaed Simson 27 Dec '16

27 Dec '16

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

2 1

compiling rtl-sdr on win10 with qtcreator
by Luigi Tarenga 17 Dec '16

17 Dec '16

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

2 4

RFC: OsmoDevCon 2017 planning
by Harald Welte 11 Dec '16

11 Dec '16

Dear Osmocom Community, [please respect the Reply-To and post all follow-up discussion to this to openbsc(a)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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Example of Setting Auto Gain
by john 10 Dec '16

10 Dec '16

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: |<param> <name>Ch$(n): Gain Mode</name> <key>gain_mode$(n)</key> <value>False</value> <type>bool</type> <hide>\#if \$nchan() > $n then 'none' else 'all'#</hide> <option> <name>Manual</name> <key>False</key> </option> <option> <name>Automatic</name> <key>True</key> </option> </param> | However it is not clear what I need to pass to make auto gain happen. Thanks, John

3 2

Please add this working hardware ID (15f4:0133) to librtlsdr.c of supported devices
by Martin Hochdekker 27 Nov '16

27 Nov '16

Hello, I bought a RTL-SDR dongle from ebay which has a new hardware ID. The dongle *is working* after adding its hardware ID to the list of supported devices in the "/src/librtlsdr.c" file. *Hardware ID:* ID 15f4:0133 HanfTek *Description of the dongle:* Black cover with white text "DAB+FM+DVB-T". Please update the source code, because I can't use gqrx-sdr as this hardware id is currently missing in the library. Although I compiled rtl-sdr with my added hardware id, I dont know how to make gqrx-sdr work with my own compiled rtl-sdr version and not the original library that lacks my hardware id. I'm using Ubuntu. Sincerely, Martin

3 2

Regarding Supported RTL-SDR hardware with GNU Radio
by reen erin 21 Nov '16

21 Nov '16

Hello I'm wondering if the Nooelec R820T SDR & DVB-T NESDR Mini is compatible with the GNU Radio Companion? I've tried using the osmocom and the rtl-sdr as the source but both didn't work. What happen is that i get "aUaUaU.." on the output box. Thank you, Reen

3 2

direct sampling with RTL2832U
by friedtj＠free.fr 15 Nov '16

15 Nov '16

Following my recent inquiry about direct sampling using the newer RTL2832U+R820T(2) DVB-T receivers: 1/ I know from past experience that the E4k based dongles work fine in direct sampling. Since the E4k is zero-IF, I could just get rid of the I+/I- or Q+/Q- capacitors and feed the RTL2832U with the signal I want to sample. This works fine. 2/ The proposed patch I got last week aimed at canceling the IF frequency since R820T(2) receivers are not zero-IF. Here I was failing to get any result. Going back to basics, I realized that using my old E4k in direct sampling mode (rtl=0,direct_samp=1 in Gnuradio-companion osmosdr source) is also not working. This is an unexpected behavior since E4k based dongle configuration should not change whether direct sampling is used or not. Indeed using the same dongle *without* the direct_samp option did generate the right results. I tried yesterday hacking librtlsdr in an ugly way to get raw samples from the 820T(2) based receiver (solving my short term concern of getting data). I could indeed acquire relevant raw samples by getting librtlsdr to believe I was using a E4k dongle by replacing line 1580 of librtlsdr.c (right after the "found:" label) with dev->tuner_type=RTLSDR_TUNER_E4000; now this induces a change in all the init functions with the function pointers just defined afterwards (&tuners[dev->tuner_type];). I have not yet tracked the difference between the init functions, but I think it would be more or less safe to jump to the E4k code in case the direct_samp option is given. JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France

1 0

r820t2 based receiver raw samples ?
by Jean-Michel FRIEDT 12 Nov '16

12 Nov '16

I am attempting to use a RTL2832U based DVB-T dongle as a "fast" ADC for recording baseband signals. gr-osmosdr under GNURadio 3.7 (as provided by Debian GNU/Linux) provides the expected samples when using an E4000 (zero IF) dongle. Being obsolete, such a dongle is no longer relevant, and I want to do the same with the (non-zero IF) R820T(2) dongles. From http://sdr.osmocom.org/trac/wiki/GrOsmoSDR I should be able to use the direct_samp=1|2 option, but that does not work. I kept pins 1 and 2 connected to the R820T output and connected a wire to pin 5 (Q-) while Q+ (pin 4) is short circuited to pin 3 (gnd). A signal generator outputs a periodic signal (150 mV amplitude, 100 kHz) but still no baseband signal, and on the FFT of the osmosdr output I still see the spectrum of the FM band when tuning to 100 MHz rather than the samples from the (initially unconnected) Q input. Any idea if the "Device Arguments" of osmosdr-source is actually parsed and interpreted ? or is there a command line way of acquiring the raw baseband I/Q data ? Thanks, JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

4 3

[PATCH] hackrf: fix buffer underflow
by P 29 Oct '16

29 Oct '16

Hi, lib/hackrf/hackrf_source_c.cc | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) this patch fixes SIGSEG wich happens when buffer from GnuRadio is bigger than buffers used by HackFR. This is due to 'remaining' will become bigger than size of input buffer. More than available bytes might be copied and '_samp_avail' become negative. This soon or latter becomes SIGSEG. With best regards, P

1 0

← Newer
1
...
36
37
38
39
40
41
42
...
92
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr