FreeCalypso GSM MS development board built and mostly works

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at

Mychaela Falconia mychaela.falconia at
Sun Apr 9 15:49:45 UTC 2017

Hi Harald,

> RF calibration generally is required for [spectrum, regulatory]
> conformity.  For example, the transmit power OsmoocmBB currently uses on
> phones is more or less "random" in a sense that we have simply used one
> value that worked with one given unit of a C123, and assume that all
> other C123 are not too far off from that value.  In reality, this can
> easily mean quite large discrepancy between intended transmit power and
> actual measured transmit power.

Yes, this is the one part of the calibration process which I actually
do understand.  It's the other two parts I'm struggling with: the VCXO
calibration and that for the Rx path.

> For the proof-of-concept / lab type use that was the primary target for
> OsmcoomBB this was sufficient.  See the dbm2apc_gsm900[] table for the
> power calibration values which most definitely are wrong on all but one
> phone.

Once I recreate the CMU200-based calibration procedure and write some
programs to automate it so I can ship FreeCalypso devices with per-unit
calibration like the historical commercial Calypso device manufacturers
did (FCDEV3B is a development board as embedded in its name, but it is
my hope that some commercial end-use-oriented FreeCalypso devices will
follow), you should be able to make use of these Tx power calibration
values (APC DAC values for each Tx power level) in OsmocomBB as well
if you like.

The flash file system format I've adopted for FreeCalypso (the one by
Mads Meisner-Jensen at TI) is quite easy to parse, and if you are
accessing it in a read-only manner, you don't need the full FFS code
from TI's firmware or any other code from TI - a simple written-from-
scratch TIFFS parser will suffice, and you can find not one but two
examples of such parsers in my freecalypso-tools Hg repository:

* The one under ffstools/tiffs-rd is a Unix/Linux host utility that
  parses a TIFFS flash image "in vitro".

* The one under target-utils/libtiffs runs on an actual Calypso target;
  its only current usage in FreeCalypso is that it is linked into the
  pirexplore standalone Pirelli hardware exploration utility.
  Pirelli's official fw uses the same FFS format, and my pirexplore
  utility with libtiffs linked into it can retrieve UI artwork bitmap
  images from Pirelli's FFS and display them on the phone's LCD.

It is worth noting that I reverse-engineered TI's FFS format at a
read-only level (enough to write a reader/parser for this FFS, but not
enough to create or perform write operations on these FFS images) and
wrote the above readers/parsers a couple of months *before* I obtained
the TCS211 firmware semi-src with the full read/write implementation.

The TIFFS reader/parser version under target-utils/libtiffs will
probably be the one best suited for your purposes if you wished to
integrate TIFFS reading into OsmocomBB for retrieving factory RF
calibration values, and it will work with all future FreeCalypso
hardware products as well as Openmoko devices - but not Mot C1xx, as
Compal moved their calibration values out of FFS into their own
proprietary data structures which I don't know how to grok.

> Also, for the VCTCXO: We don't use any calibration here at all. I am not
> even sure what exactly is calibrated in the Motorola or Openmoko
> firmware.

This TI document for their later LoCosto chipset (not Calypso) gives
some clues:

The relevant part is section A.1.11 on PDF pages 33 through 38.  The
values written into the /gsm/rf/afcparams table are:

* 3 AFC DAC values corresponding to the nominal center frequency and
  to some maximum and minimum frequency offsets;

* 4 constants based on some Psi values - this is the part I'm having
  the most difficulty understanding.

Both the DAC values and the Psi voodoo constants do vary from one
produced unit to the next.  In this tarball:

you can find real-life examples of the per-unit calibration values
read out of six (!) different Openmoko GTA02 units, converted from
TI's binary format into readable ASCII.  Look in rfasc-*/global/afcparams
inside to see how the AFC calibration values differ from unit to unit,
and how they differ from the compiled-in values which the fw uses in
the absence of calibration files.

The LoCosto PDF linked above does give the formulas for computing all
of the numbers going into the afcparams table from the frequency offset
measurements made with the CMU200, but:

* I have no way of telling if these formulas are correct or not, as
  some parts look suspicious.  For example, the instructions say the
  ARFCN for the Tx test should be set to 40, but the formula for
  computing Psi_sta (eq. 4.18 near the bottom of page 37) includes an
  Fgsm value given as 900.000000 MHz near the top of page 36.  I
  thought the uplink frequency for ARFCN 40 should be 898 MHz, not 900
  - or am I horribly mistaken somewhere?

* I have no way of telling what may have changed between Calypso and
  LoCosto, and the available document is only for LoCosto.

I was really hoping to get a hold of the production line automated
calibration program so I could see what it actually commands on the
DUT and on the CMU200 (what ARFCN does it tell the DUT fw to transmit
on? what frequency does it tell the CMU200 to look for?) and try to
reverse-engineer its subsequent math, but if obtaining those historical
Windows binaries is not possible, I will try performing the manual
calibration procedure in the LoCosto document (after I climb the CMU200
learning curve a little more), try putting the numbers through those
equations, and try tweaking them until I get something close to what
Openmoko's factory has calibrated on the GTA02 units I have.

> you can see our AFC code in layer1/afc.c is simply using some
> constants for the slope and normalization in order to pull the frequency
> towards its intended target, based on the measured frequency error.

One difference I can see between your AFC code and TI's original is
that you first convert the angle value from the DSP into a frequency
error in Hz, whereas TI's code appears to work with the angles
directly, using those Psi constants I'm having so much difficulty

However, these implementation differences are rather orthogonal to the
key matter at hand here.  The distinction that matters is that your
code uses hard-coded constants for the AFC DAC initial value and for
the AFC slope (by how much should the DAC value be adjusted given a
particular frequency offset or angle value from the DSP), whereas TI's
version expects these constants to be calibrated on a per-unit basis.

I am guessing there has to be *some* downside to having these
constants hard-coded once and for all instead of having them
calibrated per unit...

> No idea, maybe it's simply some temperature curve?

I don't see anything temperature-related in the AFC code in TI's fw or
in the equations given in the LoCosto document.  And as you also
probably know, the VCXO in TI's Leonardo reference design (copied
first by Openmoko, then by me) is a "plain" VCXO, not a VCTCXO.  The
only Calypso device I know of that uses a VCTCXO is the Pirelli DP-L10,
and I don't know why they went for this presumably more expensive

> I suppose reading
> your "preferred firmware" source code should reveal more details what
> this data is actually used for.

As you can surely imagine, I have certainly studied that l1ctl_afc()
function and tried to understand what it does, but the complexity is a
bit beyond me.  But I think I am getting a bit closer now, so once I
learn how to operate the CMU200 I bought on ebay, I will try performing
the calibration procedure: command the Calypso device to transmit
continuously via L1 Test Mode commands (my FreeCalypso Test Mode Shell
accepts these commands in exactly the same syntax as given in TI's PDF
docs!), measure the frequency offsets at different DAC values as the
LoCosto document instructs, and put the resulting values through the
Psi formulas in the document to produce an afcparams table for feeding
to the firmware via the Test Mode Shell's rftw command.

> Doesn't it simply work if you copy the calibration data from a working
> phone (like GTA02) to your FCDEV3B ?

Copy the afcparams calibration values from which GTA02?  They are
different on each individual unit as you can see in the rfcal-examples
tarball linked above - it's the whole point of per-unit calibration.

OK, I was going to try copying the afcparams file from one arbitrarily
picked GTA02 to FCDEV3B S/N 001 just to see what happens, but something
quite unexpected happened.  It was middle of the night here when I went
to try this experiment, the night was unusually cold for April in
Southern California, and the temperature difference made it work!
When I pressed the PWON button on the FCDEV3B, the FreeCalypso fw image
in the flash immediately booted without the usual glitches, and when I
tried the AT+CFUN=1, AT+COPS=0 command sequence, it immediately
connected to the network even though I had *not* uploaded the afcparams
file from the GTA02, i.e., it was using the fw's compiled-in numbers.

Later the flash booting problem came back, so I will still debug it
once I get the "dupont" jumper wires (female to female) for connecting
JTAG, and I don't know if the FB/SB acquisition will start failing
again once the room warms up - but I need to try performing the proper
calibration procedure in any case, as these numbers are meant to be
calibrated per unit rather than hard-coded.


More information about the baseband-devel mailing list