osmocom-sdr March 2016

osmocom-sdr@lists.osmocom.org

16 participants
12 discussions

by Holger Freyther

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 years, 7 months

post a new release

by Joseph Poirier

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

7 years, 10 months

Sampling at 250 kHz without aliasing

by Syed Karim

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…

8 years

Heatmap with unwanted vertical lines

by John

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

8 years

Fixing gr-fosphor compilation

by Elliot Saba

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

8 years

sdrangelove build issues on mipsel

by Arturo Borrero Gonzalez

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

8 years

Segfault bug and solution

by Eric Jesse

Hey all, I've been looking into a seg fault bug appearing after asynchronous reads, and I wanted to put forward my thoughts, and a potential solution, perhaps for the official release. I looked into the C source code and have ultimately determined that problem lies in the rtlsdr_read_async function in librtlsdr.c, which usually (if not always) returns a -5. I've traced this error back to the libusb_cancel_transfer function. My proposed solution is to change the following condition, "if (r < 0)" to "if (r < 0 && r != LIBUSB_ERROR_NOT_FOUND)". Why? It's been noted that the new transfer status from the libusb_cancel_transfer function does not propagate immediately (and to be honest, I'm not sure when exactly it propagates). As it is now, if the function returns successfully (r=0), the function runs through the while loop again, and checks all the functions to see if they are cancelled. If not, (i.e. the status hasn't propagated) the libusb_cancel_transfer function is called again, but this time it returns LIBUSB_ERROR_NOT_FOUND, which according to the function description in the libusb documentation means "the transfer is not in progress, already complete, or already cancelled" and is treated as an error. This does not sound to me like an error, but something that can be ignored to give time for the already "cancelled" signal to obtain the "CANCELED" status. I've implemented the change personally, and everything seems to work fine. I don't know if others have seen the same seg fault problem I have, but this seems to be a working, minimal solution. Let me know if I'm interpreting the "transfer is not in progress, already complete, or already cancelled" wrong, since I don't want to ignore any actual problems. Thanks, Eric Jesse AMDG

8 years, 1 month

DC spike remove ???

by a c

Hi, I just started experimenting with rtl-fm with a DVB-T stick and a raspberry pi 2. It's really very simple to use but I currently have a problem by setting a frequency in NBFM mode. When I slightly shifts the frequency of the true frequency , it appears intermodulation with DC spike even with the dc -E parameters and offset -E ??? The problem does not exist with automatic gain. IQ balance dont work with a fixed gain (ex -g 30) or i made mistake in my command line ??? Have you ever encountered this problem? Thanks, Arnaud F6GNJ

8 years, 1 month

[PATCH] drop option -a and be independent from interface ip-address

by Hannes Petermaier

From: Hannes Schmelzer <oe5hpm(a)oevsv.at> It is very inconvenient to have some RTL-stick on a machine with multiple network interfaces if it is bound to a specific one. So we break up this and make this dynamically. The -a option therefore is not needed any longer. Signed-off-by: Hannes Schmelzer <oe5hpm(a)oevsv.at> --- src/rtl_tcp.c | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c index 317e0f3..39d7c3e 100644 --- a/src/rtl_tcp.c +++ b/src/rtl_tcp.c @@ -31,6 +31,7 @@ #include <sys/socket.h> #include <sys/time.h> #include <netinet/in.h> +#include <netdb.h> #include <fcntl.h> #else #include <winsock2.h> @@ -365,10 +366,10 @@ static void *command_worker(void *arg) int main(int argc, char **argv) { int r, opt, i; - char* addr = "127.0.0.1"; - int port = 1234; + char* port = "1234"; uint32_t frequency = 100000000, samp_rate = 2048000; - struct sockaddr_in local, remote; + struct addrinfo hints, *res; + struct sockaddr_in remote; uint32_t buf_num = 0; int dev_index = 0; int dev_given = 0; @@ -391,7 +392,7 @@ int main(int argc, char **argv) struct sigaction sigact, sigign; #endif - while ((opt = getopt(argc, argv, "a:p:f:g:s:b:n:d:P:")) != -1) { + while ((opt = getopt(argc, argv, "p:f:g:s:b:n:d:P:")) != -1) { switch (opt) { case 'd': dev_index = verbose_device_search(optarg); @@ -406,11 +407,8 @@ int main(int argc, char **argv) case 's': samp_rate = (uint32_t)atofs(optarg); break; - case 'a': - addr = optarg; - break; case 'p': - port = atoi(optarg); + port = optarg; break; case 'b': buf_num = atoi(optarg); @@ -502,16 +500,20 @@ int main(int argc, char **argv) pthread_cond_init(&cond, NULL); pthread_cond_init(&exit_cond, NULL); - memset(&local,0,sizeof(local)); - local.sin_family = AF_INET; - local.sin_port = htons(port); - local.sin_addr.s_addr = inet_addr(addr); + memset(&hints, 0, sizeof(hints)); + hints.ai_family = AF_INET; + hints.ai_socktype = SOCK_STREAM; + hints.ai_flags = AI_PASSIVE; /* fill in my IP for me */ + hints.ai_protocol = IPPROTO_TCP; + getaddrinfo(NULL, port, &hints, &res); + + listensocket = socket(res->ai_family, + res->ai_socktype, res->ai_protocol); - listensocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); r = 1; setsockopt(listensocket, SOL_SOCKET, SO_REUSEADDR, (char *)&r, sizeof(int)); setsockopt(listensocket, SOL_SOCKET, SO_LINGER, (char *)&ling, sizeof(ling)); - bind(listensocket,(struct sockaddr *)&local,sizeof(local)); + bind(listensocket, res->ai_addr, res->ai_addrlen); #ifdef _WIN32 ioctlsocket(listensocket, FIONBIO, &blockmode); @@ -522,11 +524,11 @@ int main(int argc, char **argv) while(1) { printf("listening...\n"); - printf("Use the device argument 'rtl_tcp=%s:%d' in OsmoSDR " + printf("Use the device argument 'rtl_tcp=%s:%s' in OsmoSDR " "(gr-osmosdr) source\n" "to receive samples in GRC and control " "rtl_tcp parameters (frequency, gain, ...).\n", - addr, port); + "yourip", port); listen(listensocket,1); while(1) { -- 1.9.1

8 years, 1 month

[notifications@github.com: [rtl-sdr] drop option -a and be independent from interface ip-address (#2)]

by Harald Welte

somebody sending pull requests to a mirror of the official repository... -- - 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)

8 years, 1 month

Time to rename projects.osmocom.org to osmocom.org

by Holger Freyther

Hi, I think we all liked tnt's proposal to just call it osmocom.org. Are we ready to make the redmine available as osmocom.org (and redirect www.osmocom.org, projects.osmocom.org to it)? As first step of redirects I propose: http://bb.osmocom.org/ -> http://osmocom.org/projects/baseband http://openbsc.osmocom.org/ -> http://osmocom.org/projects/openbsc http://tetra.osmocom.org/ -> http://osmocom.org/projects/tetra http://simtrace.osmocom.org/ -> http://osmocom.org/projects/simtrace http://security.osmocom.org/ -> http://osmocom.org/projects/security http://gmr.osmocom.org/ -> http://osmocom.org/projects/gmr http://sdr.osmocom.org/ -> http://osmocom.org/projects/sdr any objections or corrections to that? kind regards holger

8 years, 2 months

AirSpy & sdr tools ?

by Jean-Paul Le Fèvre

Hi, After having played with a DX-Patrol device for a while using the sdr tools (sdr_tcp, sdr_fm, etc.) I've purchased an AirSpy and I would like to experiment with it. However reading the GrOsmoSDR page I see that AirSpy is supposed to be supported by the gr-osmosdr library but on the other hand the wiki page rtl-sdr does not mention it. I've recompiled the file librtlsdr.c after having added the id product and vendor of the AirSpy in the code. But I figure out that it is not sufficient and even maybe that it does not make sense. Is there a way to make the sdr tool set (sdr_*) compatible with the AirSpy ? -- Jean-Paul Le Fèvre - CEA Saclay Irfu Svom Scientific Ground Segment project manager

8 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr March 2016