osmocom-sdr February 2016

osmocom-sdr@lists.osmocom.org

12 participants
12 discussions

Moving from trac to a single redmine
by Holger Freyther 25 Sep '16

25 Sep '16

Hi guys, I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now. Tickets: Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either: * not import tickets * only import from one project * deal with changing ticket numbers In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number? Wiki: We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this? kind regards holger

7 14

post a new release
by Joseph Poirier 23 Jul '16

23 Jul '16

If would be nice to have a newer official release available; installation using the package manager on many Linux distros gets a two year old librtlsdr that's missing the rtlsdr_set_tuner_bandwidth function (added about nine months ago), as well as, other nice updates and fixes. cheers, joe

6 12

Sampling at 250 kHz without aliasing
by Syed Karim 13 May '16

13 May '16

We have a need for a small sample rate on the rtl-sdr. We have been able to select a bandwidth of 250 kHz, but there is significant aliasing at that setting. At higher sample rates the aliasing no longer exists. We are using the dongle that is sold by the RTL-SDR.com blog: http://www.rtl-sdr.com/new-products-rtl-sdr-with-1ppm-tcxo-sma-f-connector-… Since a reduced sample rate would allow for a much less resource consumption by the CPU, we would gladly sponsor an open source bounty or pay for open source development work to address this problem. Our use case is reception of a 5 kHz channel from a geostationary L-band operator. We have found that the dongle gets very hot at 1550 MHz, so we will use an LNB to downconvert to ~400 MHz. The rest of the RF chain consists of a patch antenna with 8 dBi of gain and 17 dBW EIRP from the spacecraft. The demodulator will be running on a derivative of the Beagle Bone Black. The designs for this board are available here: https://github.com/outernet-project/lantern-compute-pcb You can learn more about Outernet through the following links. http://gizmodo.com/what-is-the-outernet-and-is-it-the-future-of-the-intern-… http://www.wired.com/2015/07/plan-beam-web-3-billion-unconnected-humans/ http://www.technologyreview.com/news/537411/startup-beams-the-webs-most-imp…

2 1

Heatmap with unwanted vertical lines
by John 12 May '16

12 May '16

Hello, When I use heatmap.py with output from rtl_power I get regularly spaced vertical lines that do not appear to be related to any signal. They look they like repeat at the dongle bandwidth (2048000Hz in this case). The crop option for rtl_power reduces the presence but I am not sure f that is intended by that option. Even at -c of 70% they are still there (see attachment). Is this because of small bin width? If I use a larger bin (32k) they are still there. In this case there is no frequency legend along top so can't compare if they happen more often. Are these lines to be expected? John

2 1

Fixing gr-fosphor compilation
by Elliot Saba 12 May '16

12 May '16

After pulling gr-fosphor `master` today and compiling against the latest GNURadio, I noticed that it failed when attempting to link against libgnuradio, due to missing pmt symbols. The attached one-line patch fixes the issue, but I imagine would break compilation against older GNURadio releases. If there is a better way for me to submit this patch, please let me know. I had previously emailed one of the gr-fosphor developers with a separate issue regarding libpng issues out of ignorance of this mailing list. I don't want to disturb you developers any more than need be, so if there is a better forum than this for patches/pull requests, I am more than happy to use it. -E

2 1

sdrangelove build issues on mipsel
by Arturo Borrero Gonzalez 04 May '16

04 May '16

Hi there, In debian, sdrangelove is having some build issues on mipsel [0]. At first, there was an issue regarding the '-msse2' switch. If I delete the switch, then another build error happens: ======== 8< ======== [...] [ 21%] Building CXX object CMakeFiles/sdrbase.dir/sdrbase/dsp/interpolator.cpp.o /usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DUSE_FFTW -Dsdrangelove_EXPORTS -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -fPIC -isystem /usr/include/mipsel-linux-gnu/qt5 -isystem /usr/include/mipsel-linux-gnu/qt5/QtCore -isystem /usr/lib/mipsel-linux-gnu/qt5/mkspecs/linux-g++ -isystem /usr/include/mipsel-linux-gnu/qt5/QtWidgets -isystem /usr/include/mipsel-linux-gnu/qt5/QtGui -isystem /usr/include/mipsel-linux-gnu/qt5/QtOpenGL -isystem /usr/include/mipsel-linux-gnu/qt5/QtMultimedia -isystem /usr/include/mipsel-linux-gnu/qt5/QtNetwork -I/tmp/buildd/sdrangelove-0.0.1.20140824/obj-mipsel-linux-gnu -I/tmp/buildd/sdrangelove-0.0.1.20140824/include -I/tmp/buildd/sdrangelove-0.0.1.20140824/include-gpl -fPIC -o CMakeFiles/sdrbase.dir/sdrbase/dsp/interpolator.cpp.o -c /tmp/buildd/sdrangelove-0.0.1.20140824/sdrbase/dsp/interpolator.cpp In file included from /tmp/buildd/sdrangelove-0.0.1.20140824/sdrbase/dsp/interpolator.cpp:4:0: /tmp/buildd/sdrangelove-0.0.1.20140824/include-gpl/dsp/interpolator.h:4:23: fatal error: immintrin.h: No such file or directory #include <immintrin.h> ^ compilation terminated. [...] ======== 8< ======== Do you have any hint for this? Thanks, best regards. PS: Please keep me in CC, i'm not subscribed. [0] https://buildd.debian.org/status/fetch.php?pkg=sdrangelove&arch=mipsel&ver=… -- Arturo Borrero González

4 3

[PATCH] allow both >=3.7.4 and git version of GnuRadio
by P 29 Feb '16

29 Feb '16

This patch make GnuRadion version less strict and allows build with GnuRadio 3.8 (current git version). It makes live more bearable for those of us who live on bleeding edge. P

2 1

Airspy patch to enable USB bit packing
by Martin Smith 29 Feb '16

29 Feb '16

Last July there were several changes made to the Airspy firmware and libairspy that added support for a new bit packing mode where 4 sets of 12 bit samples are packed into 3 sets of 16 bits for the transfer across the USB bus ( https://i.imgur.com/qXnWoEK.png?1 ). 25% less data is transferred across the bus and this is good for some computers with cheap USB chipsets. There is an overhead of extra memory bandwidth required on the host side to unpack the data into a useful format, so for optimal performance bit packing is disabled by default. The data is automatically unpacked within libairspy before being passed along, so no changes are required anywhere else if packing is enabled (or not enabled). Airspy firmware older than v1.0.0-rc6 does not have the function, but that is detected and handled by libairspy. I wrote the attached patch to enable packing in gr-osmosdr, which I tested and it works. It is basically a clone of the bias=0|1 lines as pack=0|1 and calls the needed libairspy function. ref: https://github.com/airspy/firmware/commit/7e1806b https://github.com/airspy/firmware/commit/5b7dcab https://github.com/airspy/host/commit/a51eccb --- Do some Baseline test with Airspy command line tools to have something to compare USB throughput results -------------------------------------------------------------------------------------------------------- $ sudo mount -t debugfs none /sys/kernel/debug $ sudo modprobe usbmon $ wireshark -i usbmod3 & $ airspy_info ; sleep 120 ; \ airspy_rx -t 4 -r /dev/null -n 2400000000 ; sleep 120 ; \ airspy_rx -t 4 -r /dev/null -p 1 -n 2400000000 ; sleep 120 ; \ airspy_info Wireshark->Statistics->IO Graph The Bytes/Tick are double the actual data rate because of way wireshark collects the USB packets, I could have added a filter to fix this. But the relationship is valid 25% less with packing enabled. The data rate in the IO Grahp drops from 80MB/sec (in+out) [really 40MB/sec] to 60MB/second (in+out) [really 30MB/sec] from unpacked to packed. 10MSPS no packing, packing https://i.imgur.com/pA9LPdE.png?1 2.5MSPS no packing, packing https://i.imgur.com/lA8q5aq.png?1 Verification test with my patched gr-osmosdr -------------------------------------------- $ sudo mount -t debugfs none /sys/kernel/debug $ sudo modprobe usbmon $ wireshark -i usbmod3 & $ osmocom_fft -a "airspy=0" -s 10000000 --fft-rate=1 $ osmocom_fft -a "airspy=0,pack=1" -s 10000000 --fft-rate=1 $ osmocom_fft -a "airspy=0" -s 2500000 --fft-rate=1 $ osmocom_fft -a "airspy=0,pack=1" -s 2500000 --fft-rate=1 $ osmocom_fft -a "airspy=0" -s 2500000 --fft-rate=1 $ osmocom_fft -a "airspy=0,pack=0" -s 2500000 --fft-rate=1 I ran all of the above tests and the wireshark USB throughput graphs showed exactly what was expected. 40MB/sec(10MSPS+normal),30MB/sec(10MSPS+packing),10MB/sec(2.5MSPS+normal),7.5MB/sec(2.5MSPS+packing),10MB/sec(2.5MSPS+normal),10MB/sec(2.5MSPS+normal). 25% less when packing was enabled and if you did not specify the "pack=1", then no bit packing is performed by libairspy. All the magnitudes within the FFT windows looked exactly the same as they do without bit packing.

2 1

rtl_test
by Ashish Kurian 25 Feb '16

25 Feb '16

Hi, When I run the command rtl_test I get the message like Reading samples in async mode and then there is no output. But when I give commands like rtl_test -p I get the expected output. Please help me in fixing this issue. Best Regards, Ashish Kurian

1 0

Building rtl-sdr under mingw64
by Momchil Ivanov 22 Feb '16

22 Feb '16

Hi, I was trying to build rtl-sdr on windows using mingw64 and stumbled upon the error described here [1] [ 40%] Building C object src/CMakeFiles/rtl_adsb.dir/rtl_adsb.c.o Linking C executable rtl_adsb.exe libconvenience_static.a(convenience.c.o):convenience.c:(.text+0x1e5): undefined reference to `rtlsdr_set_tuner_gain_mode' libconvenience_static.a(convenience.c.o):convenience.c:(.text+0x1e5): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `rtlsdr_set_tuner_gain_mode' libconvenience_static.a(convenience.c.o):convenience.c:(.text+0x1fb): undefined reference to `rtlsdr_get_tuner_gains' libconvenience_static.a(convenience.c.o):convenience.c:(.text+0x1fb): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `rtlsdr_get_tuner_gains' and so on.... I was able to build rtl-sdr using the attached patch. I exchange the order of linking libraries. 1: http://lists.osmocom.org/pipermail/osmocom-sdr/2015-April/000048.html Greetings, Momchil

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr February 2016