Hello OsmocomBB gang,
Earlier today I was trying to run OBB against my CMU200 GSM MS RF
tester, with the objective of trying to determine if the change
currently stalled in OS#3582 (switching the Tx APC code in OBB from
the original to my modified version that uses the same numbers as each
target's respective original fw, i.e., Compal's numbers on Mot C1xx or
FreeCalypso numbers on the FCDEV3B) makes things better or worse on
OBB's primary compal_e88 platform (Mot C118).
Running OBB with Tx enabled on a Motorola phone that has its internal
antenna connection fully intact is not only illegal (transmitting in
the tightly regulated GSM bands from an unlicensed device) but actually
dangerous and harmful: as my CMU200 experiments have confirmed, OBB's
transmissions are so wildly out of spec that the risk of causing
*actual* interference and disruption to cellular networks is very real.
While I don't give a damn about silly laws that declare perfectly safe
and harmless things to be illegal, I do very much care about not
disrupting cellular networks which people actually use for important
communication, including safety-of-life communication, hence letting
OBB transmit on real live airwaves is a big no-no.
Instead the *only* safe way to run a Tx-enabled build of OBB layer1 on
a Mot C1xx or SE J100 phone is to insert an RF cable terminated with
an appropriate probe adapter into the RF test port on the back of the
phone, and connect this cable to your own test BTS or to a specialized
GSM MS RF tester like R&S CMU200. Pull out the rubber plug that keeps
dust out, and insert the appropriate adapter. I use a Hirose
MS-147-HRMJ-1 adapter for old-style MS-147 RF test ports on C118 and
C155/156 phones, and a Murata MXHS83QH3000 adapter for the newer style
of RF test ports found on Mot C139/140, SE J100, Openmoko, Pirelli and
most newer phones. Both adapters are from Digi-Key, and both are
still readily and cheaply available there. Both adapters convert the
RF test port to SMA, and unlike the other SMA to MS-147 pigtail sold
by Sysmocom, neither of my adapters requires any disassembly of the
phone case - just pull out the rubber plug. The critical point here
is that when you insert a probe into that RF test port under the
rubber cover, the internal antenna is disconnected.
Because I do not currently have my own sysmoBTS (at least not yet, may
be able to afford one in another couple of months) and I have no
interest in messing with SDR devices or trying to make a poor man's
BTS out of one, the only thing to which I can connect GSM MS devices
under test is my R&S CMU200 instrument. This instrument is generally
considered to be the gold standard in the mainstream professional
(non-FOSS) GSM industry, and I use it all the time to test not only my
own FreeCalypso devices, but also various pre-existing ones, and they
don't have to be TI-based or have hackable firmware. The CMU200 does
have a so-called non-signalling mode that allows low-level Rx and Tx
operations to be tested directly, and this mode of operation does
require GSM MS firmware with special RF test modes that bypass all
higher layers of the protocol stack - but the CMU200 instrument also
has a "signalling" mode in which it acts as a standard BTS, allowing
any MS to be tested as a black box.
This signalling mode of the CMU200 works with every GSM MS in my
experience (with FreeCalypso, with Motorola's original fw on all C1xx
phones, and with various other phones with completely unknown chipsets
and firmware architectures) with the exception of OBB. At first I had
no success with getting OBB to play nice with the CMU200 at all: I
would turn on the simulated BTS downlink signal on the CMU, run OBB's
mobile app, and it would register to the test network - but as soon as
I press the "Connect mobile" (call to MS) button on the CMU, everything
would go haywire. However, after a lot of trial and error I figured
out where at least some of the breakage is happening:
1) In order for the "call to MS" operation to succeed, the MS Tx power
level setting on the CMU200 (i.e., the power level which the CMU acting
as a BTS directs the MS to transmit at) must be set to each band's
respective maximum (PCL 5 for low bands or PCL 0 for high bands), which
is not the default setting. If one tries to make a call-to-MS from
the CMU with the MS Tx power level set to something lower, it works
just fine with every type-approved or would-pass-approval-if-someone-
paid-for-it GSM MS including FreeCalypso and Mot original fw, but if
one tries the same thing with OBB, a message pops up on the CMU200
screen saying "Overload at connector RF2", mobile's vty window says
"% Call has been released", and everything breaks from there onward.
At first I was totally bewildered as to how CMU200's input could
possibly be overloaded when the RF2 port in question is rated for
33 dBm continuous power, the PA on my FCDEV3B or on Mot C1xx phones
cannot put out anything more than 30 dBm in the DCS/PCS high bands,
and my cable has about 2.2 dB of attenuation which I account for in
my calibration and test procedures - an overload sounds physically
impossible in this setup. But then I realized what is happening:
because the CMU200 expects the MS to transmit at the power level
instructed by the CMU acting as the BTS, the instrument software
configures its sophisticated Rx chain for optimal reception at power
levels around that target. What appears to be happening with OBB as
the MS is that OBB does not implement Tx power control correctly, and
transmits at the maximum power level even when the BTS told it to
transmit at some much lower level. The CMU does not expect such gross
misbehaviour from candidate MS devices submitted for type approval
testing, and some stage in the configured Rx chain gets overloaded.
Next experiment: I established a call between OBB and the CMU200 by
setting the MS Tx power level knob to the maximum for the band I am
testing in, and then tried changing it within the active call, i.e.,
had the CMU acting as the BTS command the MS to change its Tx power
level while staying in dedicated mode. I am not sure if this
signalling happens over FACCH or SACCH, but once again it works
without a hitch with every type-approved or would-pass-approval phone
I have available for testing, and I use this method all the time to
verify the complete range of Tx power levels on the MS under test.
Not so with OBB: I don't remember the exact error message displayed by
the CMU200, but it was something along the lines of the MS failing to
act on the Tx power level change command, and then it would drop the
call. So apparently OBB fails to implement this aspect of the spec as
well.
So what about the OS#3582 change? Does it make things better or worse?
Answer: I was unable to test it because the other show-stopping defects
in OBB's GSM MS implementation prevent me from getting that far. The
combination of the two bugs above (no ability to establish the call
unless the MS Tx power level is set to max, and no ability to change
the power level within the test call) makes it impossible to step
through the power levels and see what the mobile puts out at each PCL,
hence no ability to test the change.
There also appears to be something wrong with OBB's timing of various
steps involved in burst transmission, i.e., Calypso TPU programming.
I say so because even if I stay at the band's maximum power level
(don't try to change it), the CMU200 reports the power ramp as being
out of tolerance, even with my OS#3582 patch which makes the actual
ramp programming exactly the same as what each device's official fw
uses to produce perfectly passing ramps - so it is probably something
to do with timing.
OK, so why did I produce this OS#3582 patch if it doesn't make things
any better in practice because of other major bugs elsewhere? The
answer is that it was my knee-jerk reaction to seeing hard-coded
numbers for Tx power levels and ramps and for the VCXO slope that are
completely and obviously wrong for Openmoko/FCDEV3B hardware. The
hard-coded Tx power level and VCXO slope numbers in the current OBB
master are approximately correct (at least within the ballpark of
correctness) for Mot C11x/12x/155/156, but are NOT correct even for
Mot C139/140 (different PA with different characteristics), and are
wildly off-base for the completely different Openmoko/FCDEV3B RF hw -
someone claimed Openmoko gta0x as "supported" all those years ago
without anyone doing any real tests on that platform, and without
noticing the utter bogosity.
What was happening is that people were asking about running OBB on
FCDEV3B hardware, I was trying to support those people in the hope
that they would buy the hardware at the fair commercial price (which
hasn't happened), it was obvious to me from a very cursory glance at
the code that the stuff in current master has exactly zero chance of
working anywhere close to correctly on my hw given those totally wrong
hard-coded numbers, so I felt that at that very minimum, I had to fix
those bogus numbers. Trying to fix just the numbers while keeping the
architecture of the code that uses them was also a non-starter (more
utter bogosity like trying to use GSM900 band APC numbers for all
bands), so I did the only thing that seemed sensible: ripped that gunk
out and replaced it with Tx parameter tables in the chip vendor's
original format, filled with bits read from factory RF calibration
records.
But as today's experiments show, it was pretty much for nothing: while
you do need to apply this patch if you wish to have any chance of ever
putting out spec-compliant radio transmissions, it is nowhere close to
being sufficient.
The *only* way how OBB would ever reach a point of being safe to use
as a GSM MS on live airwaves and being able to seriously compete with
properly functioning, spec-compliant GSM MS products like FreeCalypso
or Qualcomm/MTK/etc phones running their respective official fw would
be if someone were to invest many, many person-years into it, and also
invest their own money into appropriate test equipment - a CMU200 or
equivalent is an absolute must, otherwise you have no way of knowing
what your MS really puts out.
And I will *not* *ever* be that person who invests her time and energy
into whipping OBB into something that could kinda-sorta approach what
MTK, Spreadtrum and FreeCalypso (have I missed any other GSM chipset
vendors? I don't count Qualcomm as they hate GSM and give it the
"unwanted bastard child" level of support) already provide today, with
at least one of the listed vendors freely publishing their full source
code.
Meanwhile, the takeaway lesson is that running current OBB with Tx
enabled on a Motorola phone without disconnecting its internal antenna
is NOT safe, and the danger of interference to GSM or other cellular
networks is way too high. People on this list swear up and down that
no one uses OBB as a phone, instead people who call themselves
"researchers" supposedly use it in their test setups somehow. But how
exactly? I somehow doubt that most of you so-called "researchers"
have expensive Faraday cages or go to the trouble of a fully cabled
setup (lots of extra components required: duplexer, attenuators,
multiple cables, adapters for connecting to RF test ports on phones)
with no radiated transmissions. It seems far more likely to me that
most of you so-called "researchers" probably operate your SDR-acting-
as-a-BTS in open air, with the downlink signal power level set low
enough so you don't get caught despite having no actual license, and
your OBB phone transmits back to your home-grown BTS via open air.
What I am here to tell you is that doing the above is NOT as safe as
you think: if OBB is transmitting at the maximum power level the phone
can put out, which is 2 W in the GSM900 band, if the power control is
not working (OBB does not lower its Tx power when the BTS tells it to)
and the power ramp is wrong for whatever reason (the CMU200 shows it
as being out of tolerance), then only Cthulhu knows what kind of
interference you may be putting out.
My greatest hope is that some day more people will see the light and
do the right thing: retire OBB to the dustbin of history as a project
that may have been interesting once upon a time but is absolutely NOT
worth doing any more work on in the present reality, and redirect their
forces to more productive efforts. I am convinced that it would take
far less work to reimplement the researcher-oriented functionality of
OBB on top of the rock-solid FreeCalypso code base than to bring OBB
to a point of being able to compete on technical merit.
M~
