After a successful build of the Gnuradio plus extras by modifying the
build-gnuradio script to point to the osmocom git repository for rtlsdr,
I get an error and backtrace/memory map similar to the attached
osmosdr-error-output.txt when I exit from, e.g., osmo_fft (the program
seems to run fine until exit). Fabian suggested that I post this to the
list.
I also installed op25 on this system, and it fails at runtime with a
bunch of errors that I'm attaching as "op25-error-output.txt"; the end
of the sring is:
wx._core.PyAssertionError: C++ assertion "!m_frameStatusBar" failed at
../src/common/framecmn.cpp(381) in CreateStatusBar(): recreating status
bar in wxFrame
I wonder if this error is related, as op25 on a several-month-old
gnuradio installation works fine.
Thanks for any pointers on how to resolve this issue (or these issues).
John
-------- Forwarded Message --------
Subject: Re: Problem with latest version (master) of gr-osmosdr
Date: Sat, 24 Jun 2017 14:35:45 -0400
From: John Ackermann N8UR <jra(a)febo.com>
To: kerel <kerel-fs(a)gmx.de>
Here you go, Fabian. Thanks much for looking into this!
I have noticed this problem each time I've managed to get a successful
build-gnuradio completion on this system (e.g., after I commented out
the changes that made the build fail). I have another machine that was
updated using build-gnuradio perhaps three months ago, and it does not
exhibit this behavior.
One difference is that the other machine is running Linux Mint 18.0,
while the current one is on 18.1 (both "apt-get dist-upgraded" to
current levels at the time of the build).
John
----
On 06/24/2017 02:23 PM, kerel wrote:
> Hi John,
> this seems like an unrelated issue in gr-osmosdr, but I can't tackle it
> with the partial? backtrace you provided and can't reproduce it myself.
> Could you provide the full backtrace?
>
> Sincerely,
> Fabian
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
--