osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
910 discussions

Mac osmocom-sdr blocks in gnuradio
by Günther Reimann 19 May '16

19 May '16

Dear list members, I have tried to get osmocom-sdr working on my Mac with an RTL2832U. So far I got running: - gqrx: working fine - librtlsdr: installiert mit “brew install librtlsdr” - rtl_test meldet korrekt 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner - mit rtl_fm und play kann ich FM Radio hören - gnuradio installiert mit brew install gnuradio - lädt, kompiliert - gnuradio_companion funktioniert - gr-osmosdr von git geladen - cmake, make, sudo make install aufgerufen => keine Blöcke in gnuradio Habe gnuradio deinstalliert und neu kompiliert, immer noch nichts. sudo update_dyld_shared_cache hat auch nicht geholfen Wo liegt das Problem? Anbei der Output der Kompilierung von gr-osmosdr: cmake ../ -- Build type not specified: defaulting to release. -- Extracting version information from git describe... -- Configuring Boost C++ Libraries... -- Boost version: 1.60.0 -- Found the following Boost libraries: -- thread -- system -- chrono -- date_time -- atomic Checking for GNU Radio Module: RUNTIME * INCLUDES=/usr/local/Cellar/gnuradio/3.7.9.1/include * LIBS=/usr/local/Cellar/gnuradio/3.7.9.1/lib/libgnuradio-runtime.dylib;/usr/local/Cellar/gnuradio/3.7.9.1/lib/libgnuradio-pmt.dylib GNURADIO_RUNTIME_FOUND = TRUE Checking for GNU Radio Module: BLOCKS * INCLUDES=/usr/local/Cellar/gnuradio/3.7.9.1/include * LIBS=/usr/local/Cellar/gnuradio/3.7.9.1/lib/libgnuradio-blocks.dylib;/usr/local/Cellar/gnuradio/3.7.9.1/lib/libgnuradio-runtime.dylib;/usr/local/Cellar/gnuradio/3.7.9.1/lib/libgnuradio-pmt.dylib GNURADIO_BLOCKS_FOUND = TRUE Checking for GNU Radio Module: PMT * INCLUDES=/usr/local/Cellar/gnuradio/3.7.9.1/include * LIBS=/usr/local/Cellar/gnuradio/3.7.9.1/lib/libgnuradio-runtime.dylib;/usr/local/Cellar/gnuradio/3.7.9.1/lib/libgnuradio-pmt.dylib GNURADIO_PMT_FOUND = TRUE -- Checking for module 'gnuradio-iqbalance' -- No package 'gnuradio-iqbalance' found -- Could NOT find GNURADIO_IQBALANCE (missing: GNURADIO_IQBALANCE_LIBRARIES GNURADIO_IQBALANCE_INCLUDE_DIRS) -- Found gnuradio-uhd: /usr/local/Cellar/gnuradio/3.7.9.1/include, /usr/local/Cellar/gnuradio/3.7.9.1/lib/libgnuradio-uhd.dylib -- Found gnuradio-fcd: /usr/local/Cellar/gnuradio/3.7.9.1/include, /usr/local/Cellar/gnuradio/3.7.9.1/lib/libgnuradio-fcd.dylib -- Checking for module 'gnuradio-fcdproplus' -- No package 'gnuradio-fcdproplus' found -- gnuradio-fcdproplus not found. -- Could NOT find GNURADIO_FCDPP (missing: GNURADIO_FCDPP_LIBRARIES GNURADIO_FCDPP_INCLUDE_DIRS) -- Checking for module 'libosmosdr' -- No package 'libosmosdr' found -- libosmosdr not found. -- Checking for module 'libmirisdr' -- No package 'libmirisdr' found -- libmirisdr not found. -- Checking for module 'libhackrf' -- No package 'libhackrf' found -- Could NOT find LIBHACKRF (missing: LIBHACKRF_LIBRARIES LIBHACKRF_INCLUDE_DIRS) -- Checking for module 'libairspy' -- No package 'libairspy' found -- Could NOT find LIBAIRSPY (missing: LIBAIRSPY_LIBRARIES LIBAIRSPY_INCLUDE_DIRS) -- Checking for module 'libbladeRF' -- No package 'libbladeRF' found -- libbladeRF not found. CMake Warning at CMakeLists.txt:173 (find_package): Could not find a package configuration file provided by "SoapySDR" with any of the following names: SoapySDRConfig.cmake soapysdr-config.cmake Add the installation prefix of "SoapySDR" to CMAKE_PREFIX_PATH or set "SoapySDR_DIR" to a directory containing one of the above files. If "SoapySDR" provides a separate development package or SDK, be sure it has been installed. -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) -- -- Checking for module SWIG -- Disabling SWIG because version check failed. -- -- The build system will automatically enable all components. -- Use -DENABLE_DEFAULT=OFF to disable components by default. -- -- Configuring Python support support... -- Dependency PYTHONLIBS_FOUND = TRUE -- Dependency SWIG_FOUND = FALSE -- Dependency SWIG_VERSION_CHECK = FALSE -- Disabling Python support support. -- Override with -DENABLE_PYTHON=ON/OFF -- -- Configuring high resolution timing... -- High resolution timing supported through mach_absolute_time. -- -- Configuring Osmocom IQ Imbalance Correction support... -- Dependency GNURADIO_IQBALANCE_FOUND = FALSE -- Disabling Osmocom IQ Imbalance Correction support. -- Override with -DENABLE_IQBALANCE=ON/OFF -- -- Configuring sysmocom OsmoSDR support... -- Dependency LIBOSMOSDR_FOUND = FALSE -- Disabling sysmocom OsmoSDR support. -- Override with -DENABLE_OSMOSDR=ON/OFF -- -- Configuring FUNcube Dongle support... -- Dependency GNURADIO_FCD_FOUND = TRUE -- Enabling FUNcube Dongle support. -- Override with -DENABLE_FCD=ON/OFF -- -- Configuring FUNcube Dongle Pro+ support... -- Dependency GNURADIO_FCDPP_FOUND = FALSE -- Disabling FUNcube Dongle Pro+ support. -- Override with -DENABLE_FCDPP=ON/OFF -- -- Configuring IQ File Source & Sink support... -- Dependency GNURADIO_BLOCKS_FOUND = TRUE -- Enabling IQ File Source & Sink support. -- Override with -DENABLE_FILE=ON/OFF -- -- Configuring Osmocom RTLSDR support... -- Dependency LIBRTLSDR_FOUND = TRUE -- Enabling Osmocom RTLSDR support. -- Override with -DENABLE_RTL=ON/OFF -- -- Configuring RTLSDR TCP Client support... -- Dependency GNURADIO_BLOCKS_FOUND = TRUE -- Enabling RTLSDR TCP Client support. -- Override with -DENABLE_RTL_TCP=ON/OFF -- -- Configuring Ettus USRP Devices support... -- Dependency UHD_FOUND = TRUE -- Dependency GNURADIO_UHD_FOUND = TRUE -- Enabling Ettus USRP Devices support. -- Override with -DENABLE_UHD=ON/OFF -- -- Configuring Osmocom MiriSDR support... -- Dependency LIBMIRISDR_FOUND = FALSE -- Disabling Osmocom MiriSDR support. -- Override with -DENABLE_MIRI=ON/OFF -- -- Configuring HackRF & rad1o Badge support... -- Dependency LIBHACKRF_FOUND = FALSE -- Disabling HackRF & rad1o Badge support. -- Override with -DENABLE_HACKRF=ON/OFF -- -- Configuring nuand bladeRF support... -- Dependency LIBBLADERF_FOUND = FALSE -- Disabling nuand bladeRF support. -- Override with -DENABLE_BLADERF=ON/OFF -- -- Configuring RFSPACE Receivers support... -- Enabling RFSPACE Receivers support. -- Override with -DENABLE_RFSPACE=ON/OFF -- -- Configuring AIRSPY Receiver support... -- Dependency LIBAIRSPY_FOUND = FALSE -- Disabling AIRSPY Receiver support. -- Override with -DENABLE_AIRSPY=ON/OFF -- -- Configuring SoapySDR support support... -- Dependency SoapySDR_FOUND = 0 -- Disabling SoapySDR support support. -- Override with -DENABLE_SOAPY=ON/OFF -- -- Configuring Red Pitaya SDR support... -- Enabling Red Pitaya SDR support. -- Override with -DENABLE_REDPITAYA=ON/OFF -- -- ###################################################### -- # Gnuradio enabled components -- ###################################################### -- * FUNcube Dongle -- * IQ File Source & Sink -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- * Ettus USRP Devices -- * RFSPACE Receivers -- * Red Pitaya SDR -- -- ###################################################### -- # Gnuradio disabled components -- ###################################################### -- * Python support -- * Osmocom IQ Imbalance Correction -- * sysmocom OsmoSDR -- * FUNcube Dongle Pro+ -- * Osmocom MiriSDR -- * HackRF & rad1o Badge -- * nuand bladeRF -- * AIRSPY Receiver -- * SoapySDR support -- -- Building for version: v0.1.4-72-g164a09fc / 0.1.5git -- Using install prefix: /usr/local -- Configuring done CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning. MACOSX_RPATH is not specified for the following targets: gnuradio-osmosdr This warning is for project developers. Use -Wno-dev to suppress it. -- Generating done -- Build files have been written to: /Users/greimann/Downloads/gr-osmosdr/build Anschließend make [ 5%] Linking CXX shared library libgnuradio-osmosdr.dylib [100%] Built target gnuradio-osmosdr Dann sudo make install Password: [100%] Built target gnuradio-osmosdr Install the project... -- Install configuration: "Release" -- Up-to-date: /usr/local/lib/pkgconfig/gnuradio-osmosdr.pc -- Up-to-date: /usr/local/include/osmosdr/api.h -- Up-to-date: /usr/local/include/osmosdr/pimpl.h -- Up-to-date: /usr/local/include/osmosdr/ranges.h -- Up-to-date: /usr/local/include/osmosdr/time_spec.h -- Up-to-date: /usr/local/include/osmosdr/device.h -- Up-to-date: /usr/local/include/osmosdr/source.h -- Up-to-date: /usr/local/include/osmosdr/sink.h -- Installing: /usr/local/lib/libgnuradio-osmosdr.0.1.5git.dylib -- Up-to-date: /usr/local/lib/libgnuradio-osmosdr.dylib Gnuradio 3.7.9.1 zeigt kein RTLSDR unter sources :-(

3 4

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

Moderation queue cleanup - 37 messages freed
by Patrick Strasser 12 May '16

12 May '16

Dear list members, noticed a bunch of messages rushing in from this list? I just clean up the moderation queue of osmocom-sdr(a)lists.osmocom.org, deleting some 200 spam messages. Some had really strange proposals or promises... Left over where 37 messages which where not passed through in the last 12 months or so. Some of them where standalone messages or requests, some where parts of ongoing discussions. All of them where sent from people not subscribed at the list, which is unmoderated only for members. Please take your time and review any new messages that you have not yet seen. Maybe it is still interesting what was written in the mails, or the sender would still be happy to get an answer. Please include the sender CC in your message, they are not subscribed. Best regards, Patrick ps: I can check for held messages probably only once per day, so messages could be held for moderation quite long. If someone wants to help moderate the list this could be improved. -- Engineers motto: cheap, good, fast - choose any two One of the lucky 10.000: http://xkcd.com/1053 Use Mail Encryption Today! PGP Key ID: 0xDF8A127E5A120903 Patrick Strasser <patrick at wirklich priv at>

1 0

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

developing driver to use new hardware in GNU Radio
by Card, Stu 09 May '16

09 May '16

(cross-posted to the 3 different sub-communities with relevant driver architectures) I would very much like to use GNU Radio as a real time signal analysis environment with some Altera FPGA based hardware (not a general purpose SDR, more a test probe in a comm system). Searching for information on porting GNU Radio to new hardware, I found https://lists.gnu.org/archive/html/discuss-gnuradio/2012-04/msg00535.html That contains some good pointers, but was 4 years ago, so I wonder if there are any other places I should be looking for information on how to write a driver for my hardware, so I can drop a corresponding source block into GRC and get started with my signal processing? My signal analysis will typically start with a scrolling spectrogram, such as is provided by fosphor (original GPU based gr-fosphor or later FPGA based rfnoc-fosphor). We can do the high rate (FFT, magnitude, log) in the FPGA: this would incline me to start with the rfnoc-fosphor software stack; but my hardware is not Ettus, it does not have a UHD interface, it is not Xilinx. So that pushes me towards writing a driver to go underneath gr-osmosdr: then I think I also would need to extend gr-osmosdr itself to make calls to that library, unless there is some sort of device driver abstraction with a dispatcher to different actual drivers? Searching for a framework that cleanly isolates the hardware specific device driver code from the higher layers, I found SoapySDR: reviewing the description on the web, it looks very nice, and under active development; but as someone new to much of this, I am not yet competent to assist with that development, and am not clear on how complete and usable (by a n00b such as myself) SoapySDR is yet? Thanks for any tips! -- Stu Card <stu.card(a)axenterprize.com>

2 1

gr-fosphor: n00b run-time errors with benchmark tool and sink block on AMD APU
by Card, Stu 09 May '16

09 May '16

Cross-posting an inquiry I sent yesterday to discuss-gnuradio; perhaps osmocom-sdr may be a more appropriate venue. ---------- Forwarded message ---------- From: "Card, Stu" <stu.card(a)axenterprize.com> Date: May 7, 2016 4:08 PM Subject: gr-fosphor: n00b run-time errors with benchmark tool and sink block on AMD APU To: <discuss-gnuradio(a)gnu.org> Cc: My apologies for this n00b question, but I have not found answers in the > usual places. > > I have carefully followed the instructions at > > http://sdr.osmocom.org/trac/wiki/fosphor > > For building the benchmark tool, I replaced the line > > make LDFLAGS=-L/opt/intel/opencl-1.2-4.5.0.8/lib64 > > with > > make LDFLAGS=-L/opt/AMDAPPSDK-3.0/lib/x86_64/sdk > > for my AMD APU (CPU w/on-chip GPU) hardware > > and > > edited the Makefile to remove "-Werror" from the CFLAGS as otherwise the > warning about cl_create_command_queue being deprecated causes Make to give > up. > > After thus building the benchmark tool, running main yields > > libEGL warning: DRI2: failed to authenticate > [+] Selected device: Devastator > libGL error: No matching fbConfigs or visuals found > libGL error: failed to load driver: swrast > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 157 (GLX) > Minor opcode of failed request: 5 (X_GLXMakeCurrent) > Serial number of failed request: 30 > Current serial number in output stream: 30C > > Attempting to use the GRC fosphor sink block in a trivial flowgraph (with > a signal source, noise source and add operation, intended to give me a tone > with a noise floor), I get no output until I manually terminate it, and > then in the GRC message pane I see > > libEGL warning: DRI2: failed to find _glapi_get_proc_address > [+] Selected device: Devastator > [!] CL Error (-34, /home/stu/gr-fosphor/lib/fosphor/cl.c:464): Unable to > share waterfall texture into OpenCL context > > The same flowgraph, with the fosphor sink replaced by a QT GUI waterfall > sink, works as expected. > > Any pointers would be greatly appreciated. > > -- > Stu Card <stu.card(a)axenterprize.com> > >

2 3

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 to build static library (libgnuradio-osmosdr.a)
by Tom Rondeau 30 Apr '16

30 Apr '16

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

1 0

Mailing list moderation/administration
by Harald Welte 18 Apr '16

18 Apr '16

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)

2 1

← Newer
1
...
39
40
41
42
43
44
45
...
91
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr