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
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
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)
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
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
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
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
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