OpenBSC September 2020

openbsc@lists.osmocom.org

14 participants
23 discussions

Fwd: Support for new SDR devices
by Xaver Zu 12 Sep '20

12 Sep '20

That library does a lot of work. Configures HW, sends samples to FPGA via DMA, does calibration, normalization, format conversions ... Highly optimized for Intel CPU. If everything were to be done in an equivalently closed version, it would take several years of work for me. I would like to start with a simple proof-of concept. Implementing only the functions used in osmo-trx-pciesdr. In the first phase, these can be only dummy functions writing or reading zeros. I assume that the GPL violation problem will be solved from the moment I will be able to build the library and link it with osmo-trx and run it. The next step is just a matter of effort from anyone in the community. Xaver

1 0

Re: Support for new SDR devices
by Harald Welte 11 Sep '20

11 Sep '20

Hi Xaver, On Fri, Sep 11, 2020 at 07:51:50AM +0200, Xaver Zu wrote: > I created a short Wiki page. Please see if it's enough as a link to a > commit message. > https://osmocom.org/projects/sdr/wiki/PCIeSDR Thanks. For sure it is sufficient in terms of content. I did some minor reformatting while reading. However, I found a major problem. You state: > The higher-level driver (in userspace) includes a DSP, a calibration stage, and the gateware update. It is in the form of a closed source dynamic library named libsdr.so. The C API for Linux / x86 is in the form of a header file libsdr.h which also serves as brief documentation. This is incompatible with the strong copyleft licensing (AGPLv3) of osmo-trx! You cannot directly link with a proprietary library. The only way I can see a PCIeSDR backend for osmo-trx would be via osmo-trx-ipc, which provides a general-purpose sharde memory interface to another process. The other process can then use the non-free library, if you want that. -- - 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

OsmoDevCon / COVID-19
by Harald Welte 07 Sep '20

07 Sep '20

Dear fellow Osmocom developers, as you all know, we've sadly had to postpone OsmoDevCon 2020 back in April this year. At the time, we discussed to re-visit the situation in October 2020. While legally it is no problem at all to host an event with ~ 20 participants in Berlin/Germany (specific regulations really only start from 50+ participants) - I'm not entirely convinced it would be the smartest move. Legality and public health regulations are only one part of the equation - common sense and profound care for the key members of our community for sure are more relevant considerations to me. I'm not 100% in favour and not 100% against. Hence, I would like to get your input. Should we a) try to get an event organized on-site in Berlin? We'd have to move to a larger venue than IN-Berlin with proper ventilation and sufficient space so we can keep physical distance, but I think that's manageable for sysmocom as organizer. b) simply postpone to 2021? I'm convinced the situation will not change significantly (in a positive way) until late April 2021, so it's not really a "solution" as it will likely mean we have to think of late 2021 or 2022. c) plan some kind of online conference? To be honest, I think this model works fine for events where a single speaker wants to give lectures to hundreds or thousands of participants. But OsmoDevCon is much more interactive. We could record or live-stream some talks or screencasts from home, sure. But that only captures one part of the event. We could also try to set a date for a collaborative mumble, or the like - for the "hallway track". What are your thoughts? Let's avoid cross-posting the discussion to all of the mailing lists and simply have it on openbsc(a)lists.osmocom.org. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2020