osmocom-sdr May 2017

osmocom-sdr@lists.osmocom.org

1 participants
3 discussions

gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call

by Raj Bhattacharjea

I'm using the latest fosphor from git (7b6b9961bc2d9b84daeb42a5c8f8aeba293d207c) and am seeing two weird (and I believe related) issues. Firstly, I see the following error: [+] Selected device: TITAN X (Pascal) [!] CL Error (-30, /home/user/gr-fosphor/lib/fosphor/cl.c:409): Unable to queue clear of spectrum buffer This is CL_INVALID_VALUE returning from clEnqueueFillBuffer, so I added some debug fprints to cl.c to see what parameters were being passed into clEnqueueFillBuffer: Edits: fprintf(stderr, "size = %d\n", 2 * 2 * sizeof(cl_float) * FOSPHOR_FFT_LEN); fprintf(stderr, "pattern_size = %d\n", sizeof(float)); fprintf(stderr, "pattern = %p\n", &noise_floor); fprintf(stderr, "offset = %d\n", 0); Output: size = 16384 pattern_size = 4 pattern = 0x7fb66b7fdd2c offset = 0 These parameters look like they shouldn't cause CL_INVALID_VALUE: https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/clEnqueueFil… But there is this one condition that might be met, which is that somehow size (16384) is larger than the underlying buffer (cl->mem_spectrum). The underlying OpenGL buffer being too small brings me to my next (I believe related) issue. The spectrum plot in fosphor is weirdly pixelated, please see the attachment, which shows a screencap from "osmocom_fft -F -f 100e6 -g 20 -s 10e6". Where is the cl->mem_spectrum buffer ultimately declared / initialized? My OpenCL / OpenGL sharing knowledge is nonexistent, any pointers for how I can help debug this issue? Output of clinfo is attached as well, and I'm on Ubuntu 16.04 on x86_64. -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622

6 years, 10 months

RTL-SDR and RTL-TCP drivers

by Krzysztof Halasa

Hello, it's my first mail on this list, so please forgive me if I do something wrong. I'm about to post a couple of patches for RTL drivers: 1. RTL-SDR: convert _lut to float[] to reduce size by a factor of 256. The _lut is being indexed by I + Q (16 bits = 65536 entries), however both samples can be processed independently, resulting in 8-bit LUT. Saves a bit of RAM and CPU cache. lib/rtl/rtl_source_c.cc | 19 ++++++------------- lib/rtl/rtl_source_c.h | 4 ++-- 2 files changed, 8 insertions(+), 15 deletions(-) 2. RTL-TCP: Convert to single class model The existing RTL TCP driver is quite different from its brother RTL_SDR. It's much more complicated, uses gr::blocks::deinterleave and gr::blocks::float_to_complex, and generally doesn't work correctly (e.g. https://github.com/csete/gqrx/issues/99 Spectrum is mirrored when filter or demodulator changes (rtl_tcp) #99) I've converted the RTL TCP driver to the model used by RTL_SDR, simplifying it in the process, and fixing the GQRX issue. lib/rtl_tcp/CMakeLists.txt | 1 - lib/rtl_tcp/rtl_tcp_source_c.cc | 352 ++++++++++++++++++++++++++++++++-------- lib/rtl_tcp/rtl_tcp_source_c.h | 32 +++- lib/rtl_tcp/rtl_tcp_source_f.cc | 327 ------------------------------------- lib/rtl_tcp/rtl_tcp_source_f.h | 125 -------------- 5 files changed, 309 insertions(+), 528 deletions(-) I'm also thinking about merging the code common to RTL-SDR and RTL-TCP, but this it's done yet. Comments? -- Krzysztof Halasa

6 years, 10 months

[PATCH] gr-osmosdr: Avoid crashing if number of connected channels is greater than maximum

by Dominic Chen

This is a workaround for a crash triggered by the following scenario: using gqrx, if the automatically generated device string "addr=1d50:6108,driver=lime,media='USB 3.0',module=STREAM,name=LimeSDR-USB,serial=XXXX,soapy=0" is passed into gr-osmosdr, args_to_io_signature(args) will generate an io_signature with two channels, because the space in 'USB 3.0' causes dev_nchan to be incremented twice. Then, in source_impl::source_impl(), GNU Radio will gneerate an exception of the form "FATAL: destination port 1 out of range for source_impl(47)", which causes the exception-handling null channel code to be executed. But, since output_signature()->max_streams() returns 1, channel is 2, and missing_chans has size_t type, the subtraction will underflow to (unsigned int)(-1), which causes another GNU Radio exception when connect(). Since this is an exception in an exception handler, the program will terminate immediately. Thanks, Dominic --- lib/source_impl.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/source_impl.cc b/lib/source_impl.cc index a28f314..ac7c3af 100644 --- a/lib/source_impl.cc +++ b/lib/source_impl.cc @@ -426,7 +426,7 @@ source_impl::source_impl( const std::string &args ) connect(null_source, 0, throttle, 0); size_t missing_chans = 0; - if ( output_signature()->max_streams() > 0 ) + if ( output_signature()->max_streams() > 0 && ((size_t) output_signature()->max_streams()) > channel) missing_chans = output_signature()->max_streams() - channel; std::cerr << "Trying to fill up " << missing_chans -- 2.7.4

6 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr May 2017