osmocom-sdr April 2016

osmocom-sdr@lists.osmocom.org

6 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

MSVC Patch

by Geof Nieboer

Please find attached patch for osmocom-sdr 1- Allows compilation on MSVC by conditionally adding __attribute(format tags based on the compiler 2- Allows builders to use Glew when required, making a GlewInit call when USING_GLEW is defined. If that is not defined, there are no changes. Geof

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

Patch to build static library (libgnuradio-osmosdr.a)

by Tom Rondeau

I have attached a patch for gr-osmosdr to build it as a static library (libgnuradio-osmosdr.a) as well as the normal shared lib. This is the same method we use in GNU Radio. The main difference here, is that the patch means that the static lib will always be built. In GNU Radio, we added a -DENABLE_STATIC_LIBS option to cmake to turn this on/off. Let me know if that's preferably and if you have specific styles for adding these options (if you can just point me to the right line if you have other flags of this nature). The static libs are used in Android and other embedded systems. It's not entirely necessary, but it sure makes some things a heck of a lot simpler. Tom

8 years

Mailing list moderation/administration

by Harald Welte

Dear Osmocom SDR community, as one of the Osmocom.org admins, it has come to my attention that nobody seems to be handling the moderator queue ofr the osmocom-sdr mailing list. There's currently 267 held postings, most are spam, but there are also quite some legitimate posts held in the queue. Is there anyone involved in related projects interested in checking the mailman moderation queue regularly and approving good postings while rejecting the bad ones? Explanation: All mails from non-members are moderated to keep the list mostly spam free. Regards, 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)

8 years, 1 month

fosphor benchmark result

by Geof Nieboer

All, >From the wiki, I understand you are looking for some additional benchmarks for fosphor, here's what I received: Intel i7-5930X CPU (6-core w/ HT, 3.5 GHz OC to ~4.4 GHz) 2 x Radeon 270 3GB GDDR5 video cards Intel 750 SSD, 400GB NVMe Windows 10 64-bit Compiled using MSVC + AMD App SDK Average: 325 MSps I've also submitted two pull requests to the Github repo with the patches I needed to use to get it compile in MSVC 2015. Pretty minor stuff. Cheers, Geof

8 years, 1 month

patch for supporting multiple airspy by serial number in gr-osmosdr

by Lawrence Glaister

Hello all, I have completed additions to airspy_source_c.cc to support using multiple airspy devices. This is done by specifying the serial number for the device (i.e. airspy=0x644064DC317C1FCD). The current behaviour of opening the first device when no serial number is specified is still maintained. Specifying airspy=0 will also open the first device found. The serial number format is a 64bit hex number with or without a leading "0x". I have attached a patch file based on the current git source, a copy of the whole CC file as patched ( see lines 93 to 112 and 122 to 129), and a screen shot of the grc block for selecting by s/n. This patch has been tested with gnuradio 3.7.9 and 0, 1 and 2 airspy devices connected. I hope this can be placed into the current sources as I know of several requests for this have shown up on various discussion boards. I place no copyright restrictions on the code... please release it however you desire. This is my first attempt at contributing to gnu radio, so please excuse any blunders in protocol I may have made. Thank you for your fine work Lawrence Glaister VE7IT Nanoose Bay BC Canada

8 years, 1 month

patch for supporting multiple airspy by serial number in gr-osmosdr

by Lawrence Glaister

Hello all, I have completed additions to airspy_source_c.cc to support using multiple airspy devices. This is done by specifying the serial number for the device (ie airspy=0x644064DC317C1FCD). The current behaviour of opening the first device when no serial number is specified is still maintained. Specifying airspy=0 will also open the first device found. The serial number format is a 64bit hex number with or without a leading "0x". I have attached a patch file based on the current git source, a copy of the whole CC file as patched ( see lines 93 to 112 and 122 to 129), and a screen shot of the grc block for selecting by s/n. This patch has been tested with gnuradio 3.7.9 and 0, 1 and 2 airspy devices connected. I hope this can be placed into the current sources as I know of several requests for this have shown up on various discussion boards. I place no copyright restrictions on the code... please release it however you desire. This is my first attempt at contributing to gnu radio, so please excuse any blunders in protocol I may have made. Thankyou for your fine work Lawrence Glaister VE7IT Nanoose Bay BC Canada

8 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr April 2016