osmocom-sdr

osmocom-sdr@lists.osmocom.org

906 discussions

Fixing gr-fosphor compilation
by Elliot Saba 11 May '16

11 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 08 May '16

08 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 03 May '16

03 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 29 Apr '16

29 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 17 Apr '16

17 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

fosphor benchmark result
by Geof Nieboer 14 Apr '16

14 Apr '16

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

1 1

patch for supporting multiple airspy by serial number in gr-osmosdr
by Lawrence Glaister 13 Apr '16

13 Apr '16

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

1 0

patch for supporting multiple airspy by serial number in gr-osmosdr
by Lawrence Glaister 09 Apr '16

09 Apr '16

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

1 0

Segfault bug and solution
by Eric Jesse 29 Mar '16

29 Mar '16

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

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr