I tried to install CalypsoBTS have libosmocore installed, osmo-bts osmobsc,
libosmo-netif, libosmo-abis, ortp, trx, libosmo-dsp everything went without
errors, following the instructions I created: touch ~/.osmocom/open-bsc.cfg
, then when you run : osmo-nitb -c ~/.osmocom/open-bsc.cfg-l
~/.osmocom/hlr.sqlite3-P-C --debug=DRLL:CC:MM:RR:RSL:NM shows me:<0005>
bsc_init.c:498 Failed to parse the config file:
'/root/.osmocom/open-bsc.cfg' file tried to create as administrator but
without success , pleas help me
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Calypso-BTS-tp4026753.html
Sent from the baseband-devel mailing list archive at Nabble.com.
Hello OBB gang,
The Potential Calypso Targets page in your wiki lists a whole bunch of
phones with Silabs Aero II (Si4210) RF transceivers:
http://projects.osmocom.org/projects/baseband/wiki/PotentialCalypsoTargets
I wonder, has anyone ever succeeded in finding a datasheet for this
transceiver? I found the datasheet for the older Aero+ transceiver
(a 3-chip solution), but not for the single-chip Aero II aka Si4210.
Here are the Silabs Aero materials I have found so far:
ftp://ftp.freecalypso.org/pub/GSM/Silabs/
I got the marketing briefs for Aero+ and for Aero II, and the full
technical datasheet for the former of the two. If anyone has a
datasheet for Si4210 and would be willing to share it, I will gladly
add it to the above collection.
In the interest of full disclosure, if I get a hold of this datasheet,
adding it to the above FTP archive may be all that I will ever do with
it: even if I had the datasheet, I do not currently have any realistic
plans of adding Silabs Aero RF support to FreeCalypso, let alone to
OBB. I do have a couple of Motorola W220 phones on their way to me
from ebay, and hopefully at least one of them will actually make it to
me, unlike the first one that appears to have fallen into a black hole
somewhere, but even with ideal documentation (full schematics and chip
datasheets), adding support for a very different RF subsystem (in
particular, Silabs' way of doing AGC is entirely different from TI's
way) would require more systems engineering work than I can do at the
moment. It also doesn't help that the only tpudrv12.c reference TPU
driver we have is a reconstructed source made from the disassembly of
tpudrv12.obj, not TI's original source - thus all quarter-bit timing
numbers (there are lots of them, and they are very critical) are just
"magic" numbers, and their original derivation has been lost - does
not bode well for the task of figuring out what the corresponding
timings should be for a different RF transceiver.
All that being said, however, this Si4210 transceiver does look like
an attractive alternative to TI's Rita: the Si4210 is 5x5 mm compared
to TI's 7x7 mm (every square mm counts in a tightly squeezed modem
module), and it has 4 separate LNA inputs for the 4 GSM bands, to be
contrasted with Rita and Aero+ arrangement of 3 LNA inputs, one of
which is shared between EGSM and GSM850. The Si4210 way with 4
separate LNA inputs allows a fully quadband MS to be implemented in a
much more straightforward way. Thus tracking down a datasheet for
this Silabs Aero II transceiver and adding it to the knowledge base
should be a good step for the GSM enthusiast community as a whole.
I already tried asking Silabs for the datasheet, and got the answer
that the product line in question was sold to NXP back in 2007.
Reading up on Wikipedia, it appears that this stuff did not stay long
with NXP either, transferred first to ST-NXP Wireless and then to
ST-Ericsson, and when the latter closed, it is totally unclear where
the Silabs Aero stuff went, other than the great bit bucket in the
sky. :-(
M~
Hello again OBB folks,
In light of my discovery two days ago through CMU200 testing that
current OBB on all Calypso devices (with or without my OS#3582 patch)
produces grossly incorrect (spec-violating) radio transmissions, I am
making the following offer to your gang in the case that any of you
are interested in doing the work to fix your software and bring its
radio transmissions into compliance. The offer is: if there is anyone
in this so-called "community" who (a) has a CMU200 instrument or is
willing to invest into buying one and getting it properly calibrated,
and (b) is willing to do the major work of bringing OBB's radio
transmissions into compliance as verified with that CMU200 instrument,
then I am willing to send that person a fully tested, fully working
and properly calibrated FCDEV3B GSM MS board free of cost.
To recap, the areas in which OBB's radio transmissions were found to
be non-compliant in my CMU200 tests last Saturday are as follows:
1) At least in the test scenario when the CMU200 instrument acting as
a BTS makes a call to the connected MS, OBB's implementation of GSM MS
transmits at each band's maximum power level instead of the lower
power level commanded by the CMU acting as the BTS.
2) When the CMU200 commands the connected MS to change its Tx power
level, OBB's implementation of GSM MS does not act on these commands.
3) Even when the MS Tx power level is set to each band's maximum on
the CMU200 before initiating the call to the MS and not changed
afterward, the power ramp put out by OBB is flagged by the CMU as
being out of tolerance - despite the OS#3582 patch which makes OBB use
the same Tx ramp template bits as the official FreeCalypso and
Motorola firmwares (I tested on both hw platforms), or FreeCalypso fw
on Motorola's hw, all of which produce perfectly compliant power ramps
as deemed by the CMU200.
4) Without the OS#3582 patch, not only the power ramp but also the
power level itself is out of tolerance.
I do not see how anyone could address these defects without having
their own CMU200 instrument so they can reproduce the problem first,
and see the same thing I am seeing, which is why I am limiting my
FCDEV3B offer only to those who have a CMU200 or are willing to invest
in one. Furthermore, I also know from first-hand experience that many
CMU200 units that sell on ebay for cheap may be defective in very
subtle and non-obvious ways, or may have been subjected to repairs or
repair attempts in less than fully diligent ways. Therefore, unless
you bought your CMU200 from a high-end seller who sells it with a
recent calibration certificate and with all case seals from the
calibration lab intact, the only way to know for sure if the
instrument's measurements are trustworthy is to send it to your
nearest Rohde&Schwarz office for calibration, which costs about $1400
at least at the Columbia, Maryland (USA) office, which is where I had
mine calibrated.
For the above reasons, I further limit my free-of-cost FCDEV3B offer
to those who not just own a CMU200 instrument in some unknown
condition, but are also able to present a recent calibration
certificate for it. (And don't even think about faking one, as I know
what real ones look like - I got my own.) You will also need to have
an N-to-SMA RF cable with precisely known insertion loss at GSM
frequencies (at the center frequency of each uplink and downlink band,
8 frequencies in total), i.e., you need to demonstrate sufficient RF
knowledge to compute a good estimate for these insertion loss numbers
if you don't have access to a VNA to measure them directly.
(In case it isn't already obvious, let me spell it out: producing your
own GSM MS implementation that is safe to use on public airwaves does
require spending a non-trivial amount of money on proper test
equipment.)
If you have the necessary test equipment as above and are interested
in getting a free-of-cost FCDEV3B, you will need to further agree to
do the following upon receiving the board:
1) Connect the FCDEV3B to your CMU200 while the board still runs its
official FreeCalypso fw, and confirm with your own eyes and your own
CMU200 that all RF transmissions put out by the FreeCalypso hw+fw
combo satisfy all of the compliance tests.
2) Run OBB on the same FCDEV3B still connected to your CMU200, and
confirm with your own eyes and your own CMU200 that OBB's transmissions
exhibit the same problems which I see in my test setup.
3) Work toward bringing OBB's RF transmissions into compliance as seen
by the CMU200, i.e., toward being like what the official FreeCalypso
fw puts out.
The tests performed by the CMU200 are the exact same ones which are
performed by official certification labs on candidate GSM MS devices
submitted for type approval testing; I don't know exactly what
equipment those labs use, but I wouldn't be surprised if it is the
very same CMU200 at least for the low-level tests, plus something else
(a real BTS maybe) for higher-level GSM L3 protocol tests.
Aside from the just-detailed offer of a free-of-cost board to whoever
is willing to do the above work and has the necessary setup, I am now
restricting sales of FCDEV3B hardware to OBB users. If anyone is
interested in buying an FCDEV3B for the purpose of running OBB on it,
I will only sell it to you if you can demonstrate that you have one of
the following 3 acceptable setups:
Option 1: a CMU200 or some other instrument acting as a base station
simulator;
Option 2: your own BTS plus all of the numerous pieces which are
required in order to connect an MS directly to a BTS with a cabled
setup without any radiated transmissions;
Option 3: your own BTS plus a solid RF-blocking enclosure (reliably
blocking any leakage) that is big enough to fit both your BTS and
your MS.
If I were to sell a board to an OBB user who does not have any of the
above, then I would be helping facilitate willful interference and
disruption of public radio communication networks, and could
potentially be held liable for whatever damage you will cause by
letting OBB transmit on GSM frequencies in open air, so nope, sorry,
won't do.
And finally let me pre-emptively address one very likely response: if
someone says "why don't you, Mychaela, do the work of bringing OBB's
radio transmissions into compliance and contribute code patches, given
that you already have all of the needed high-end test equipment", my
answer is that this work can only be done by someone who believes that
investing effort into further development of OsmocomBB is the right
thing to do, which is a position I disagree with - instead I believe
that OBB (or at least OBB on Calypso, no opinion regarding OBB on SDR
or the floating-around vaporware idea of OBB on MTK) should be
deprecated from use and retired to the dustbin of history as a failed
project that may have been interesting and may have had some merit at
one time, but is now completely pointless.
Sincerely,
Mychaela Falconia,
Mother of FreeCalypso
www.freecalypso.org
