- osmocom-sdr - lists.osmocom.org

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

26 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 10 Dec '16

10 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 09 Dec '16

09 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 20 Nov '16

20 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 14 Nov '16

14 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 28 Oct '16

28 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

Fix for Airspy MIXER gain
by Lucas Teske 26 Oct '16

26 Oct '16

So I was having a problem with my GOES LRIT receiver in GNU Radio. In GQRX the SNR was 7dB and in GNU Radio was 4dB regardless of the setting. Then I noticed that the Mixer (BB Gain) wasn't working at all. Checked over the internet and there was this issue: So I made some changes and here is the working version: https://github.com/osmocom/gr-osmosdr/pull/8 (I know its a mirror, but the patch is also attached) Lucas Teske

2 1