October 2019 - osmocom-sdr - lists.osmocom.org

gr-osmosdr: add clock_source= parameter
by Michael Loeffler 26 Mar '21

26 Mar '21

Hello, the attached patch allows to set the clock_source on uhd devices in programs like gqrx. Bye

1 1

gr-fosphor install troubles:" Unable to share spectrum VBO into OpenCL context" openCL/GL sharing
by Aaron Giles 30 Nov '19

30 Nov '19

>Yeah, the nVidia driver is annoying ... it used to work and they broke >it a few years ago and they don't care enough to fix it. >And since I got a new laptop a few years back, I don't have a nvidia >card to debug or work around it. I compared fosphor to the nVidia OpenCL Simple OpenGL Interop example [1] and noticed that fosphor calls glMapBuffer/glUnmapBuffer to clear the spectrum vbo between the calls to glBufferData and clCreateFromGLBuffer. If I eliminate the map/memset/unmap here by removing the call to gl_vbo_clear in gl_deferred_init [2], then clCreateFromGLBuffer returns CL_SUCCESS and fosphor appears to work with CL/GL sharing. It is not clear to me if clearing the vbo_spectrum is necessary here, since cl_queue_clear_buffers later initializes the mem_spectrum buffer to the noise floor. I'm using an nvidia GTX 1650 with version 430.50 of the nvidia drivers under Linux Mint 18. A friend of mine tested the GTX 1060 and also had success with this workaround. Aaron [1] http://developer.download.nvidia.com/compute/DevZone/OpenCL/Projects/oclSim… [2] https://git.osmocom.org/gr-fosphor/tree/lib/fosphor/gl.c#n235

2 2

[rtl-sdr patch?] lib: retry i2c on failure
by Fab Stz 26 Oct '19

26 Oct '19

Hello, When doing a setFrequency I usually have this error afterwards and the frequency is actually not changed rtlsdr_demod_write_reg failed with -9 r82xx_write: i2c wr failed=-9 reg=17 len=1 r82xx_set_freq: failed=-9 By searching around I found this commit that makes the trick for me. https://github.com/keenerd/rtl-sdr/commit/ 9ed9ffa37e24f3293fa960cfcd74909ac3e9996c This will actually really set the frequency and remove the last 2 errors related to "r82xx". The only error remaining is then rtlsdr_demod_write_reg failed with -9 If you can include that upstream that would be nice. I created a pull request here : https://github.com/steve-m/librtlsdr/pull/56 Actually the commit is part of a large PR that you may be interested in ? https://github.com/keenerd/rtl-sdr/pull/8 Regards,

2 8

Re: [USRP-users] FOSDEM 2020: Free Software Radio Devroom CfP
by Sylvain Munaut 16 Oct '19

16 Oct '19

CC to osmocom sdr ML > Dear friends and fans of software-defined radio and free/open-source radio topics in general, > > FOSDEM 2020 (the free and open-source developer's meeting in Brussels, Europe) will, once again, feature a track on Software Defined Radio, and any other radio-related topics in the (now known as) Free Software Radio devroom. Therefore, we invite developers and users from the free software radio community to join us for this track and present your talks or demos. > > > Software Radio has become an important tool to allow anyone to access the EM spectrum. Using free software radio libraries and applications and cheap hardware, anyone can now start hacking on wireless communications, remote sensing, radar, fun hacks of all sorts, or other applications. At FOSDEM, we hope to network all these projects and improve collaboration, bring new ideas forward and get more people involved. > > > The track's web site resides at the link below. The final schedule will be available through Pentabarf and the official FOSDEM website. > > https://fosdem.org/2020/schedule/track/free_software_radio/ > > > Additional Information will be also available at: https://wiki.gnuradio.org/index.php/FOSDEM_2020 > > > ** Submit your presentations > > To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM20 and follow the instructions (you need an account, but can use your account from last year if you have one). You need to create an 'Event'; make sure it's in the Free Software Radio track! Lengths aren't fixed, but give a realistic estimate and please don't exceed 30 minutes unless you have something special planned (in that case, contact one of us). Also, don't forget to include time for Q&A. > We will typically go for 30-minute slots -- shorter talks, unless they're really short, usually tend to screw up the schedule too much. > > You aren't limited to slide presentations, of course. Be creative. However, FOSDEM is an open-source conference, therefore we ask you to stay clear of marketing presentations and present something relevant to free/open software. We like nitty-gritty technical stuff. > > Topics discussed in this devroom include: > > * SDR Frameworks + Tools > * Cellular/telecoms software > * Free/Open SDR hardware > * Wireless security > * Random fun wireless hacks > * SDR in education > * Satellite/spacecraft communication > * Ham radio related topics > > > ** Important Dates > > FOSDEM is February 1st and 2nd, 2020. The Free Software Radio devroom is happening on Sunday, the 2nd of February. > > The submission deadline is Friday, December 6th. A complete schedule for the presentations in the devroom will be available on the 15th of December. > > > In the last years we were always full to the brim with presentations, so if you want to present, please make sure to submit your abstracts soon! > > ** Steering Committee > The track committee consists of: > > * Phil Balister - "Crofton" > * Sylvain Munaut -"tnt" > * Derek Kozel - "dkozel" > * Nicolas Cuervo - "primercuervo" > * Martin Braun - "mbr0wn" (Emeritus) Cheers, Sylvain

1 0

gr-osmosdr maintainer needed
by Harald Welte 02 Oct '19

02 Oct '19

Dear Osmocom SDR community, Dear Dimitri, the situation around gr-osmosdr has been deteriorating for years. Among other things, I notice: * there has not been a tagged release since 2014 * patches (e.g. fixing clang support) are not merged * there is no support for gnuradio 3.8 I raised at least some of this both on-list (in June 2018 at http://lists.osmocom.org/pipermail/osmocom-sdr/2018-June/001766.html) and off-list in personal discussions, e.g. at CCCamp2019 It is clear that technically there are alternatives these days (mainly SoapySDR, which didn't exist when gr-osmosdr started in 2012). However, at the same time I'm seeing plenty of users asking about gr3.8 support, as there are [probably] lots of existing applications which are not ported to other input blocks. As the overall Osmocom project leader, this puts me in a difficult position: I've never been involved with gr-osmosdr myself, but I get various related e-mail which show that there are users, and that they are struggling by a lack of maintenance. It appears that original author and maintainer Dimitri has lost time and/or interest in maintaining gr-osmosdr. That's very sad, but it is a fact that people have a limited amount of time, and priorities change. I'd like to thank Dimitri and all other gr-osmosdr developers/contributors for what they have done so far. But what has unfortunately been missed here during the last 1-2 years is passing the project over to a new maintainer or group of maintainers. Just because the original author is not around anymore, it doesn't mean the project has to die. So with this message, I'm publicly calling for some other community member[s] to step up and become maintainer[s] of gr-osmosdr. Who is interested in gr-osmosdr and willing to maintain it, possibly in a team with other interested folks? I would be more than happy to provide the respective accounts/access on the osmocom.org redmine as well as the official osmocom.org upstream repository. There's a list of open issues at http://osmocom.org/projects/gr-osmosdr/issues I know there are also many forks on github, including * https://github.com/igorauad/gr-osmosdr/tree/gr3.8 gr3.8 support * https://github.com/xtrx-sdr/gr-osmosdr/ with xtrx support * https://github.com/zhovner/gr-osmosdr and https://github.com/Sevyls/gr-osmosdr with clang/MacOS related fix * https://github.com/wirstrom/gr-osmosdr with soapy end-of-burst fix * https://github.com/thegildedturtle/gr-osmosdr hackrf raspi signedness fix? * https://github.com/ScanOC/gr-osmosdr print AirSpy serial number on connect * https://github.com/romeojulietthotel/gr-osmosdr cosmetics * https://github.com/racerxdl/gr-osmosdr spyserver support? * https://github.com/rascustoms/gr-osmosdr airspy related patches * https://github.com/newdreamlj/gr-osmosdr bladerf multi stream fix * https://github.com/Lukeekul/gr-osmosdr bladerf pass source/sink args * https://github.com/IW0HDV/gr-osmosdr perseus HF support * https://github.com/dl1ksv/gr-osmosdr rs-hfiq support * https://github.com/carpikes/gr-osmosdr/ hackRF AVX/SSE performance * https://github.com/aports-ugly/gr-osmosdr gr3.8 + xtrx support * https://github.com/amungo/gr-osmosdr ADSDR support * https://github.com/0pq76r/gr-osmosdr/commits/master expose rtl-sdr gain stages So there's no shortage of interesting fixes and features to investigate and/or merge, even beyond the 'make a release and port to gr3.8'. Thanks in advance! 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)

2 1