New RF changes and discoveries

[Mychaela Falconia]

Hello FC community,

Over the past week or so I did a bunch of RF tests with our CMU200
instrument that have resulted in a few changes to our FC firmware and
some knowledge gains:

* On TI's older Clara RF platform (RF 10) the AGC range went from 6 to
50 dB, whereas on the Rita chip used in all Calypso devices we work
with this AGC range has been reduced, now going from 14 to 40 dB.  I
am guessing that TI made this simplification change to their RF silicon
because the narrower AGC range is sufficient with the improved baseband
ADC resolution in the Iota ABB compared to Nausica.  However, as I was
reviewing some AGC-related code in L1, I caught a bug that was made by
TI back when they first introduced RF 12 (Rita) support, and that was
apparently never caught back in the days when Calypso was active,
neither by TI nor by any of TI-based phone manufacturers: the low_agc
field in the T_AGC structure in l1_rf12.c was set to 6, which is not a
valid AGC value for Rita RF, with the valid range being [14,40].  This
number was clearly an overlooked remnant from l1_rf10.c for Clara RF,
where it is correct.  The effect of this bug is that when the cell
search process was doing power measurements in "low AGC" mode, the AGC
would get effectively set to 14 dB (the lowest possible value on Rita
RF), but the higher level control code assumed it was 6 dB, with the
measurement results being off by 8 dB.  I fixed this bug by changing
the low_agc number to 14 for Rita RF.

* This weekend I was finally able to confirm through CMU200 testing
that the tables of Tx ramp templates we got from Openmoko (extracted
from OM's l1_cust.obj blob) are indeed correct for our OM-based RF
hardware on our current FCDEV3B boards.  When the CMU200 analyses the
Tx signal put out by the DUT, it reports whether the power ramp meets
or violates official spec tolerances, and in my FCDEV3B testing it
showed passing ramp for every power control level in each of the 3
bands we support.  We will probably never know whether TI-Taiwan
customized these Tx ramp templates for FIC's choice of RF3166 PA or if
they were calibrated on a TI Leonardo board with an RF3133 PA and
required no changes for RF3166 (OM could not have changed these
numbers themselves, as they got this part as an object blob from
TI-TW), but whatever the history, at least we know that they are
correct for our current hw, which is a big relief.

* Through further CMU200 testing of several different Calypso-based
target devices which we support, I also confirmed what I previously
suspected: aside from possible cases of two closely related PA models
from the same vendor, every different PA type requires different Tx
ramp templates in order to produce correct power ramp in the final RF
Tx output.  Right now in our current FC firmware we have 3 different
sets of Tx ramp template tables: one for our own FC hardware (from
OM), another for Mot C139/140, and a third one for Mot C11x/12x and
C155/156.  The last one is the most recent addition: until a couple of
days ago we used Mot C139/140 Tx ramp templates on all Mot C1xx
targets, but my CMU200 tests this weekend revealed that these templates
which Compal must have calibrated for their SKY77325 PA on Mot C139/140
do NOT produce correct RF Tx output on the older C1xx subfamilies with
an older SKY77324 PA - yes, just one digit difference in the PA part
number!

Given that we have got two recent changes to the numbers in l1_rf12.c
(the low_agc change affecting all Rita platforms and the change of Tx
ramp template tables for Mot C11x/12x and C155/156), I have put out a
new binary release for FC on C1xx:

ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/c1xx-fcmag-20190311.tar.bz2

For C139/140 the only effective change from the previous 20190129
release is the low_agc change (all Calypso-based phone manufs back in
the days lived with this bug all those years without ever noticing it,
so the impact is *very* minor), but if you playing with FreeCalypso
VPM (voice pseudo-modem) on Mot C11x/12x or C155/156, you definitely
need to update, as the previous incorrect Tx ramp templates result in
non-compliant RF Tx output.

I am also going to make a new production fw release for FCDEV3B
(incorporating the low_agc fix) when I make the next batch of boards,
but there is no urgency, as this low_agc fix is totally non-critical.

In other news, I will soon be adding support for one more historical
Calypso phone target: Sony Ericsson J100.  This phone was made by
Compal just like Mot C1xx, all technical details are much the same
(this SE J100 model is closest to C139/140, but has a different LCD
and a MIDI ringtone player chip instead of Calypso-driven buzzer),
only the style and mechanics of the case and the UI decorations are
different between made-for-Motorola and made-for-Sony-Ericsson phones.
The level of support in FC for this SE J100 model is going to be the
same as for Mot C11x/12x and C155/156: only voice pseudo-modem
operation with the display remaining dark, buttons doing nothing and
AT commands required for control.  The main purpose of adding this
support will be to check how the RF hardware in this phone compares to
other known Compal models in the form of Mot C1xx.  This phone model
is NOT expected to be an attractive choice for FC end users or
tinkerers because it does not have the same headset jack as Mot C1xx,
instead it has a multi-pin proprietary connector for all accessories
(charger, headset, serial interface pins), and the only way to get
serial access on this phone is by constructing your own cable through
some cutting and soldering - as far as I can tell, no one makes serial
cables for these phones like various people make for Mot C1xx.

(Yes, I did the cable surgery myself: I cut apart a Sony Ericsson data
cable that only works in its intact form on other SE phones that have
native USB on the same pins where J100 has our Calypso UART, and
soldered the wires to an off-the-shelf FT232RL adapter board.  The
wires in those SE data cables which need to be cut apart and soldered
are *tiny*, must be no more than 28 AWG, and they are stranded, which
is even more difficult to work with.  I stripped and soldered them the
best way I could, but it is kind of a miracle that they hold at all.)

I am playing with these SE J100 phones because Harald Welte sent me
one, and then I bought one more from a seller on ebay.  Harald sent me
this phone in relation to certain happenings in the funny circus house
known as OsmocomBB: a Russian GSM/RF/SDR/etc tinkering enthusiast
named Vadim Yanitskiy, who is basically the only person doing any
active work on OBB in the recent months/years, has finally (after a
year and a quarter of delay) got around to trying to integrate the
RF calibration reading patch which I made for OBB back in 2017-Nov.

Back at that time in late 2017 I was willing to support users who
wanted to run OBB on our FCDEV3B boards if they would pay the full
commercial price for the hardware (which hasn't happened), and for
that purpose I made a patch to OBB that makes it use correct RF Tx and
VCXO parameters on our hardware instead of the totally wrong numbers
that are hard-coded in their mainline code, as much as OBB's flawed
architecture would allow.  But OBB's architecture also made it
impossible to make this change just for the FCDEV3B target, and I had
to bring all of their pre-existing targets up to par at the same time.
SE J100 was the only OBB-supported target device which I never laid my
hands on previously and which was therefore not supported in FC until
my current effort to add this support.

However, when I tried to run OBB (both with and without my patch)
against our CMU200 instrument to see what OBB puts out in terms of RF
Tx output and how my patch changes it, I was not pleased at all with
what I saw.  As I have just confirmed with the same RF test instrument
that is used in official type approval certification tests, what OBB
puts out on the air is far worse than I previously imagined, and the
problems are far bigger than what my little patch can fix.  See this
post I made to their mailing list:

http://lists.osmocom.org/pipermail/baseband-devel/2019-March/005625.html

TL;DR: if you run OsmocomBB on any Calypso phone (whether your hw was
made by Motorola or FreeCalypso or any other manufacturer) and do it
in open air, i.e., without putting the phone in a Faraday cage or
disconnecting the internal antenna, and if you get FCC regulators
knocking on your door to slap you with a 6-digit fine plus a few
months in jail for interfering with and disrupting radio communication
networks, you will fully 100% deserve that fine and jail term.  OBB's
radio transmissions are *grossly* out of spec, and so bad that they
most definitely *will* cause interference and disruption to GSM or
other cellular networks around you.  OBB's Tx output is so bad that
the CMU200 is not even able to measure it (see the linked post for the
details), hence we don't even know the exact degree of its badness.

There is a world of difference between operating a mobile device that
lacks the official rubber stamp of approval because no one paid for
it, but which in fact operates 100% correctly on the air as verified
with properly calibrated test instruments (the case with FreeCalypso),
versus operating a mobile device whose radio Tx output is wildly out
of spec and highly likely to cause harmful interference (the case with
OsmocomBB), and doing so while *knowing* that your transmitter is bad.
Thus if you get caught causing disruption to cellular networks by
running OBB, and it can be proven that you have seen this warning post
of mine with solid technical backing, then it could be argued in court
that you had *willfully* caused that cellular network disruption, and
your penalties will be correspondingly harsher.

Prior to my CMU200 tests this weekend, I did not realize that OBB's
behaviour on the air was this bad.  It was widely known that OBB fails
to implement many important GSM functions such as handover, and OBB's
toy architecture is unsuitable for any serious use, but prior to now I
mistakenly assumed that it was relatively safe to use within the
constraints of its functional limitations.  But now we know otherwise:
it is not safe at all!

In contrast, our own FreeCalypso products (both our own FCDEV3B as
well as FreeCalypso fw running on Mot C1xx phones) put out 100%
correct, 100% spec-compliant radio transmissions, as verified with the
very same CMU200 instrument - it is the very same test instrument as
used by official compliance testing labs, and our instrument is itself
kept in good calibration standing.  In the case of running FreeCalypso
fw on Mot C1xx phones, correctness of radio transmissions is contingent
on two conditions: if your C1xx variant is anything other than C139/140,
you need to be running the latest firmware which I just put out with
corrected Tx ramp template tables, and for all C1xx variants, you need
to diligently extract the original Tx levels tables with c1xx-calextr
and reupload them into your FreeCalypso FFS with fc-fsio as spelled
out in C1xx-Howto instructions in the release tarball.

Hasta la Victoria, Siempre,
Mychaela aka The Mother