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

Harald Welte laforge at
Sun Apr 9 10:07:13 UTC 2017

Hi Mychaela,

On Sun, Apr 09, 2017 at 01:22:03AM -0800, Mychaela Falconia wrote:
> Harald invited me to share this news with this list, so here it goes:

thanks for the update!

> Now the following part is bad news for me, but probably good news for
> you guys: right now OsmocomBB works on this board to the point of
> being able to connect to the live commercial GSM network in my part of
> the world, send and receive SMS and make a call, but my own preferred
> firmware is not currently able to the connect to the network (fails in
> the FB/SB acquisition step) because of the lack of VCXO calibration.

this is good news, indeed.  I'm quite sure you will get your preferred
firmware working, too.

> * TI's TCS211 firmware for the Calypso (the basis for FreeCalypso)
>   expects per-unit RF calibration to be performed on the production
>   line, and the VCXO calibration appears to be the most critical step:
>   if I delete the VCXO calibration files on an Openmoko-made GTA02,
>   the modem stops working (fails to acquire FB/SB in the network search
>   just like on my FCDEV3B), whereas all other RF calibration files can
>   be deleted and it still works.  Hence I reason that the lack of this
>   VCXO calibration is the cause of my current inability to connect to
>   the network from my board using my preferred firmware.
> Now here is the part I don't understand: how are you able to get away
> with not requiring RF calibration in OsmocomBB?  

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.

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

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.  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.

The absolute accuracy of the VCTCXO doesn't matter, all that matters is
the relative difference between the local clock and the recovered clock
from the FCCH, and we use that to compensate.

> So where is the catch?  There must be some good reason why TI's TCS211
> fw requires VCXO calibration, and when the fw is redesigned to not
> require such calibration as you seem to have done in OsmocomBB,
> something else (something important probably) must be sacrificed.  

No idea, maybe it's simply some temperature curve?  I suppose reading
your "preferred firmware" source code should reveal more details what
this data is actually used for.

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

- Harald Welte <laforge at> 
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

More information about the baseband-devel mailing list