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
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
Hi guys,
new member here, but been playing with rtl dongles and sdr generally for a
while now.
I run four rtl dongles covering 50, 70, 144 and 432MHz with websdr running
on Ubuntu Mate
Works quite well but I have trouble with the device indexing changing for
rtl_tcp. ie sometimes a dongle gets allocated to a different band.
To try and fix the issue I've given each dongle a unique serial number and
created some udev rules which create symlinks for each dongle. That all
works nicely.
Problem is that rtl_tcp uses device indexing starting at D0 and expects D1,
D2 D3 etc. whereas my symlinks are called 6mtrs, 4mtrs, 2mtrs and 70cms
Not sure how to make rtl_tcp work with symlink's rather than device index.
Any ideas ?
Regards Tim G4WIM
I have these RTL dongles:
http://www.amazon.com/dp/B00SXZDUAQ
I've always noticed that when I start up osmocom_fft at 250kSamp/s with
those RTL dongles plugged in, the spectrum looks like a bunch of samples
are FFT'd, and then the application waits for another batch of samples and
the FFT GUI doesn't update, then some more samples come in and get FFT'd,
and this process goes on. I up the rate to something like 1M or higher and
go about my business.
I've been working with an application that can use lower sample rates, and
in my investigations, sample rates below 901kSamp/s exhibit this "burst of
samples, then nothing" repeating pattern. It seems to me that samples are
being dropped, i.e., the sampling is not continuous. With osmocom_fft -F
(fosphor) running, if I set the sampling rate to 901k vs. 900k, I see a
marked difference in the spectrum, and how often it is updated in the
drawing. My suspicions about the samples not arriving / being dropped comes
from doing a simple FM radio demod, which sounds great at 901kSamp/s, but
plays continuous, stops and underflows, and repeats that again and again
when things are run at 900kSamp/s (GNURadio flowgraph attached). I've also
seen other really weird stuff, like if you ask for 215k sampling rate.
Has anyone else seen these issues? Can anyone replicate? Anyone have
solutions or information about what sample rates are properly supported by
the hardware? Any documentation to the RTL2832u that might explain this
behavior?
Here is my setup:
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.8.1
Ubuntu 14.04, gnuradio built from tagged release, osmosdr / fosphor built
from git master some day in the past
--
Raj Bhattacharjea, PhD
Georgia Tech Research Institute
Information and Communications Laboratory
http://www.prism.gatech.edu/~rb288/
404.407.6622
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
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 :-(
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
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>
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
(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>
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>
>
>
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
