osmocom-sdr March 2017

osmocom-sdr@lists.osmocom.org

7 participants
9 discussions

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

Re: git.osmocom.org cgit improvements
by Holger Freyther 19 Mar '17

19 Mar '17

> 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

1 0

Questions about error when using Osmocom sink
by XueQiuyue 19 Mar '17

19 Mar '17

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

2 1

git.osmocom.org cgit improvements
by Harald Welte 17 Mar '17

17 Mar '17

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)

1 0

Recording rtl_fm output
by Martin McCormick 14 Mar '17

14 Mar '17

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

1 1

Re: RTL-SDR and RTL-TCP drivers
by Andreas Eriksen 10 Mar '17

10 Mar '17

Thank you for these patches, indeed they fixed my problems with gqrx :-)

1 0

Technical help, umm I think?
by James Clark - KC3CDV 09 Mar '17

09 Mar '17

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

1 0

[hari.blogscripts@gmail.com: reg. a deadlink]
by Harald Welte 01 Mar '17

01 Mar '17

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)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr March 2017