Hello GSM network side folks,
I assume that most of you are probably aware of the existence of a
certain hack called CalypsoBTS: it's a rather unbelievable hack that
takes a piece of hw meant to be a GSM MS and turns it into a poor
man's GSM BTS, all inherent asymmetry in the GSM air interface be
damned. As a manufacturer of Calypso-based GSM MS devices I
occasionally get approached by people who seek to acquire a Calypso
device seemingly for the sole purpose of running that CalypsoBTS hack,
and every time I get approached by someone of that sort, I always
shake my head in bewilderment - isn't there a better way to get your
own little toy BTS running than to misuse GSM MS hardware?
The purpose of the present post is to solicit advice from the community
as to what I should tell those poor souls who are seeking to set up
their own toy BTS and are looking to do it via the CalypsoBTS route -
is there some better way that we as a community can steer them toward
instead?
It is my understanding - please correct me if I'm wrong - that the
least expensive way to set up your own GSM BTS for toy purposes (as
opposed to running a real operational GSM network which people will
depend on for real communication) is to use a generic SDR device of
one of several types that are supported by osmo-bts-trx/osmo-trx - but
this is where my knowledge in this area ends, as this particular mode
of GSM toying has never been an area of interest for me. But for
those people who (unlike me) *are* interested in setting up their own
toy BTS in the least expensive way, what SDR hardware should we as the
community recommend for them? What is the cheapest option that will
be good enough - especially if the criteria for "good enough" are
compared to CalypsoBTS? What would be the least expensive option that
is just good enough to be advocated as a better alternative to the
CalypsoBTS hack?
In the case of my current FCDEV3B hardware the price tag seems to be
an effective deterrent against people misusing it as CalypsoBTS:
FCDEV3B is expensive, and someone whose actual need is to run their
own BTS rather than MS can easily buy a suitable SDR device for the
same price or less, it seems. But the issue is beginning to rear its
ugly head again because I have another development board in the works
(not here yet, probably won't have the hw until December), and there
is a possibility (nothing is certain yet) that it might be a bit less
expensive than FCDEV3B.
Is there an SDR-based option (or any other non-CalypsoBTS option) for
running a toy BTS with osmo-bts-trx and the Osmocom CNI stack behind
it that would cost $250 or less in hardware? The $250 number comes
from my anticipated-around-December new FreeCalypso development board
- there is a chance that it might be that cheap (but again, absolutely
nothing is certain at the present moment) - and if there is no SDR or
other option for running your own toy BTS for the same or lower hw
price, then I fear that I am going to be flooded with support requests
from people asking for help with using my new board as CalypsoBTS,
which I absolutely dread. Hence my present attempt to pre-emptively
seek some better solution for those people.
(It would be nice if that stream of support requests from people
seeking to run the CalypsoBTS hack could be redirected to Sysmocom or
some other commercial entity who could make some money helping those
people, but my experience is that these people are not the kind who
would ever pay for commercial support, so no hope there...)
It may also be worth mentioning that the filter replacement hack
(removing or replacing Rx SAW filters that are meant to limit the GSM
MS device's Rx capability to only specific GSM downlink bands) will
not be possible on the new FreeCalypso GSM MS board that will be
coming around December - that design uses an integrated RF FEM (front
end module) instead of discrete antenna switch and SAW filter
components. But I've also heard that plenty of people run the
CalypsoBTS hack without doing any filter rework, just letting the
strong signal from a nearby GSM MS force its way through wrong SAW
filters and not caring about the 40 dB or so of attenuation being
incurred - I cringe at the thought, but that's what people do...
M~
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)
