Hi --
I've recently been trying to install the Gnu Radio system on a new
machine using the build-gnuradio script. The script is failing with an
error in the gr-osmocom build phase, and I've been able to verify this
with a separate attempt to build.
In rtl_source_c.cc, line 224, the build fails with:
error: 'rtlsdr_set_bias_tee' was not declared in this scope
ret = rtlsdr_set_bias_tee(_dev, bias_tee);
It appears that changes were merged into the tree on about June 11 to
add bias tee support, and that this error results from that change set.
I'm able to get a successful build if I comment out those few lines of
code, but when I try to run an application (e.g., osmocom_fft), upon
exit there is a bunch of traceback output and a lengthy memory map
printed. I'm no debugging expert, but I can tell that the exact error
and address change on different runs, but always appear to be related to
a memory map or corrupted list.
I don't know if anyone else has seen either the build issue, or the
traceback issue, so thought I should report it here.
FWIW, I'm building on a fresh install of Linux Mint 18.1 using the
latest version of the build-gnuradio script on a Lenovo M900 i7-6700T
system. I've used the build-gnuradio script on several other systems in
the past without encountering this issue. If you need any further info,
I'm happy to provide it.
Thanks,
John N8UR
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
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
How to choose nfm mode?
According to rtl_fm help, there is no nfm among available mode: fm, wbfm, raw, am, usb, lsb
rtl-sdr-git 1:v0.5.3.r13.ge3e6ee2-1
--
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
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
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
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