April 2017 - osmocom-sdr - lists.osmocom.org

gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call
by Raj Bhattacharjea 20 Jun '17

20 Jun '17

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

2 7

RTL-SDR and RTL-TCP drivers
by Krzysztof Halasa 12 Jun '17

12 Jun '17

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

2 3

[PATCH] remove -I/usr/include in pkg-config
by Martin Kelly 22 Apr '17

22 Apr '17

This shouldn't be necessary as it's part of the default compiler include paths anyway. Morever, it can cause GCC 6 C++ build failures in downstream packages when combined with QMake (such as qtmultimedia-rtlfm-radio-plugin). Fix these issues by removing it. Signed-off-by: Martin Kelly <mkelly(a)xevo.com> --- librtlsdr.pc.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/librtlsdr.pc.in b/librtlsdr.pc.in index 5e55049..84b6d0c 100644 --- a/librtlsdr.pc.in +++ b/librtlsdr.pc.in @@ -6,6 +6,6 @@ includedir=@includedir@ Name: RTL-SDR Library Description: C Utility Library Version: @VERSION@ -Cflags: -I${includedir}/ @RTLSDR_PC_CFLAGS@ +Cflags: @RTLSDR_PC_CFLAGS@ Libs: -L${libdir} -lrtlsdr -lusb-1.0 Libs.private: @RTLSDR_PC_LIBS@ -- 2.1.4

2 5

R820T I2C
by Chris Miller 14 Apr '17

14 Apr '17

Hi, To teach myself Swift, I’m writing my own version of librtlsdr (in Swift on MacOS). I’m confused about the I2C interface between the RTL2832U and the R820T. It seems the first 16 registers of the R820T can be read but not any after that. I get a pipe stall when trying to read more than 16 bytes. Is this true or am I missing something? Is this why the shadow registers are used to maintain the state of the R820T’s registers? Thanks Chris

1 0

Astrum TV 100 USB TV device dongle. Does this support SDR? I use it to tune TV, seems it doesn't have radio or I don't know how to find it setup.
by Luke Jentile 09 Apr '17

09 Apr '17

1 0

rtl_test -t results in failed to open rtlsdr device #0.
by pantos＠pantokratoren.de 07 Apr '17

07 Apr '17

Hello, a few days ago I tried to install rtl-sdr on my raspberry pi. I'm using a dvb-t usb stick with Realtek, RTL2838UHIDIR chipset. I build the software following the guide in the wiki. I used two additional switches: cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON After installing the software I created a blacklist in cd /etc/modprobe.d: blacklist dvb_usb_rtl28xxu blacklist rtl2832 blacklist rtl2830 blacklist rtl2838 After rebooting the device I tried to test rtl-sdr with rtl_test -t and got this result: Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM usb_claim_interface error -6 Failed to open rtlsdr device #0. I don't know how to fix this error. I tried many suggestions found via google but it doesn't work. Can someone help me to fix this? Thanks for your help!! Joachim

2 4

No 64-bit librtlsdr for windows.
by Bill Gaylord 07 Apr '17

07 Apr '17

Hello. So I have ran into a small problem. I used a python library called pyrtlsdr which uses ctypes to interact with librtlsdr. But when I upgraded my python form 32 bit to 64 bit the library no longer works because the librtlsdr.dll is 32 bit not 64. So has anyone had luck compiling a 64 bit version of librtlsdr? Or knows how to?

1 0