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
> On 18 Mar 2017, at 16:09, Neels Hofmeyr <nhofmeyr(a)sysmocom.de> wrote:
>
>
Hi,
> All in all these are excellent improvements!
> Holger, what's the status of your promise, made one day in a chat, to make
> redmine catch the OS#123s?
lol, I love how we go from a private chat to this CC list. I have not looked at it but maybe this is something for an afternoon at Osmodevcon. It should be fairly simple with redmine.
holger
Dear Mr/Ms,
I meet errors when use osmocom sink and source in GNU Radio, I have tried BladeRF and HackRF, and I use Ubuntu 16.04.
1.When I use BladeRF, I set the parameters as
"bladerf=701c2ce1da297914cb29695ba79fac54,fpga=<'/Users/qiuyuexue/Documents/BladeRF/hostedx115-latest.rbf'>,fpga-reload=1,buffers=32,buflen=4096,transfers=16,stream_timeout_ms=3000,loopback=none,verbosity=silent,xb200.”
and I got error as:
“(top_block.py:4795): IBUS-WARNING **: The owner of /home/ceca_517/.config/ibus/bus is not root!
gr-osmosdr v0.1.4-86-ge9dde9af (0.1.5git) gnuradio 3.7.10
built-in sink types: hackrf bladerf redpitaya file
Opening nuand bladeRF with device identifier string: "*:serial=701c2ce1da297914cb29695ba79fac54"
[bladeRF sink] Loading FPGA bitstream </home/ceca_517/LPWAN/SOAR(a)PKU/LPWAN/BladeRF/hostedx115-latest.rbf>...
[bladeRF sink] bladerf_load_fpga has failed with -11
[bladeRF sink] Warning: 'loopback' has been specified on a bladeRF sink, and will have no effect. This parameter should be specified on the associated bladeRF source."
2.when I use HackRF, I set the parameter as
"hackrf=393b4b,bias=1,bias_tx=1,buffers=32.”
and I got error as:
"(top_block.py:5108): IBUS-WARNING **: The owner of /home/ceca_517/.config/ibus/bus is not root!
gr-osmosdr v0.1.4-86-ge9dde9af (0.1.5git) gnuradio 3.7.10
built-in sink types: hackrf bladerf redpitaya file
FATAL: bad lexical cast: source type value could not be interpreted as target
Trying to fill up 1 missing channel(s) with null sink(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.”
I want to know if I set the parameters wrong? Or anything else? Thanks a lot for your help and your time! Thanks very much!!
Best,
Qiuyue
Hi all,
today I've deployed some cgit improvements on https://git.osmocom.org/,
in the hope that it makes this tool even more useful:
1) syntax highlighting of source code (requested by Hoernchen)
The source code is now highlighted by pygments. I don't really
understand why somebody would want to look at source code a lot in a
browser, but well, it was as easy as to enable the existing pygments
based filter plugin.
2) rendering of "about" page from README.md
As you might have noticed, I've introduced a README.md in a number of
repositoires, and cgit is now rendering an about page for every
repository, e.g. at http://git.osmocom.org/libosmo-abis/about/
3) gerrit change-ID hyperlink generation
All gerrit Change-IDs in commit messages are now automatically converted
to hyperlinks to the respective gerrit change, see e.g. the below
example:
http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44…
Please note that this works for the "Change-Id" line of the actual
change, but also for change-ids in the free text (e.g. "this depends on
change-id ... in libosmocore")
4) Osmocom ticket/issue hyperlink generation
Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is
scanned for occurrences of "OS#(\d+)" which are then amended with
hyperlinks to the respective issue on osmocom.org
Please note the OS# prefix is mandatory, so things like "OS#1614, 1615"
will not work, as can be seen at
http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5…
Please format your commit messages accordingly.
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)
Something I am doing is not quite right. The following
example works almost perfectly but please read on.
rtl_fm -f 88.3e6 -M wbfm -s 215000 -r 44100 - | aplay -r 44.1k -f S16_LE
The audio from the sound card is nearly excellent.
To record this stream, I do the following:
rtl_fm -f 88.3e6 -M wbfm -s 215000 -r 44100 testfile.bin
I get a file so it would appear that the following should sound
just like the stream I am listening to using the pipe in the
first example.
aplay -r 44.1k -f S16_LE testfile.bin
The pitch of the audio is fine but instead of almost dead
silence between words, there is a lot of hiss and
distortion. In theory, I should hear the same mostly noiseless
audio I hear in the first example when playing from the file.
This is really not a DSP issue but maybe I have saved the
audio as unsigned and am trying to play it signed which would
preserve the pitch but be a cause for a lot of distortion.
Besides, it is apparently signed when piped in to aplay.
I am mystified.
Thanks.
Martin McCormick
Hello all, not sure if this will go through or if Ive to subscribe or even if this is the rite place for help like this.
I am on a mac running the latest OSX updates and I am waiting for my new SDR to get to me from amazon, Ive got CubicSDR and also Gqrx on the system, well my question is will I be able to just plug and play or will I have to install macports and all that other stuff that goes over my head.
Do I have to use turminal? Me trying to use that thing is like a fish trying to live out of water for a year, its vary unlikely it will happen effectivly.
Also let me say rite up front please don’t post any photos because I cant see your photos.
I hope this is the rite place to ask this question, thank you in advanced.
May Peace Be With You. Active skywarn severe weather spotter and Community Collaborative Rain, Hail & Snow Network operative.
@HomefrontHugs Volunteer for our Troops and Families
FYI, this was in my personal inbox but is probably better adressed by
the people on this list.
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)
