Hi Thomas,
it's been some time, hope you're doing fine!
Today on IRC we were collectively wondering about one detail in the osmo-trx
mcbts implementation that has been there from day one:
Your're creating the Channelizer and Synthesis class for four channels of 800kHz
within the 3.2Mbps wideband-channel. So far so good.
But why does the code ever only use up to three of them?
And why is there a specific re-ordering, see radioInterfaceMulti.cpp in
getLogicalChan() ?
It would be great if you could share your thoughts on that.
To me, it looks like the constraint to 3 channels is arbitrary and we should just
as well be able to use all four?
Thanks,
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)
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
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)
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)
