Significance of calibration

[Spacefalcon the Outlaw]

Hello all,

As I wrote many a time before, the goals of FreeCalypso include not
only firmware but also hardware: it would be awesome to produce some
Calypso hardware of our own that would be designed exactly the way we
like, free from the various design defects found in each of the known
and available pre-existing models.  In particular, it would be nice to
have a Calypso modem board that could run not only our own work-in-
progress gcc-built firmware, but also the stable and working TCS211
reference, the same one as leo2moko.

I'm thinking of building a modem board on which we could run TCS211
with absolutely minimal surgery on the binary libs: patch a couple of
bytes in init.obj inside main.lib for memory timings (I would like to
use the S71PL129NC0 flash+pSRAM chip with 2 x 8 MiB of flash and 8 MiB
of pSRAM instead of Openmoko's K5A3281 with just 1 MiB of SRAM - this
way we could have TCS211 in flash and run our own fw via fc-xram) and
another couple of bytes in tpudrv12.obj inside tpudrv.lib for the
triband->quadband change.  (The latter change would be a direct
reversal of the quadband->triband artificial hobbling done by some
unknown middleman between TI and Openmoko.)

Here are the specific features I would like to see on our own modem
board for running both our own fw and TCS211:

* JTAG brought out on a header;
* Both UARTs brought out on headers, for the MODEM UART include not
  only TxD and RxD, but also RTS and CTS: the TCS211 firmware as it
  stands expects to have the latter connected and working, and the
  whole point is to hack it as little as possible so it retains its
  value as a stable and working reference;
* S71PL129NC0 flash+pSRAM chip as mentioned above;
* VCXO and RFFE design copied verbatim from Leonardo/Openmoko, except
  for the reversal of the triband hobbling and restoration of Leonardo
  original quadband FEM;
* A bare modem to be powered with a lab bench power supply and
  controlled via AT commands, thus no UI or battery charging hardware
  yet.

One of the challenges we are going to face in building our own Calypso
hardware will be RF calibration.  Seeking to gain a better
understanding of exactly what needs to be calibrated and how, I took a
closer look at the per-unit RF calibration data stored in the FFS of
Openmoko GTA02 phones.  Here is what I found:

There are 3 separate areas in which calibration is performed:

1: VCXO frequency.  The results of this calibration are recorded in
   /gsm/rf/afcdac and /gsm/rf/afcparams, and this calibration is
   arguably the most critical of all.  As an experiment, I tried
   deleting the two just-named files from my GTA02 modem's FFS (it is
   of course backed up :), causing the firmware (leo2moko) to revert
   to its compiled-in defaults, and the modem lost its ability to
   connect to the GSM network around here: it fails to acquire the
   frequency burst.  So we know that this calibration is truly
   critical.  Furthermore, I got copies of RF calibration values from
   two other Freerunner users, and their VCXO calibration values are
   wildly different from mine - so not only is this particular
   calibration truly critical, but it also really needs to be done on
   each individual unit.

2: RF Rx gain.  There are per-band files under /gsm/rf/rx, two files
   for each band: agcparams.XXX and calchan.XXX.  The agcparams file
   is 8 bytes long and corresponds to the T_RX_CAL_PARAMS structure
   defined in l1_rf12.h, which consists of 4 16-bit words.  It appears
   that only the first word (g_magic) differs between Om's factory
   calibration data and what's hard-coded in the fw.  There is some
   explanation of this g_magic number in TI's old presentation on the
   subject of RF calibration:

   ftp://ftp.ifctf.org/pub/GSM/Calypso/rf_calibration.pdf

   but I admit that I don't really understand it.  However, at least
   for the PCS1900 band of interest to me, the g_magic value programmed
   into my unit at the factory (200) is exactly the same as in the FFS
   images from the other two people, and is not too far away from the
   compiled-in number (188).  The calchan file (40 bytes total, 10
   records of 4 bytes each) seems to specify additional corrections to
   this Rx gain control (?) based on the ARFCN, but the actual numbers
   I see programmed in there seem insignificant: either 0 or -1 in the
   16-bit signed word, with 0 meaning no correction (the compiled-in
   default).

   I tried deleting my /gsm/rf/rx/agcparams.1900 and /gsm/rf/rx/calchan.1900
   files, and as I expected, I saw no difference in the behavior of the
   modem: it still connected to my local operator 310260, successfully
   made a call, and the downlink audio sounded just fine.  So I lean
   toward an impression that this particular calibration is not critical.

3: Tx power levels.  There are 3 tables for each band:

   * The "master" table in levels.XXX: for each defined power level
     (seems to be [5,19] for low bands or [0,15] for high bands, but I
     could be mistaken), the table gives the APC DAC value to be fed
     to the RF PA, the index of the ramp table to be used, and the
     index of the calchan table to be used.  Only the APC DAC value
     differs between fw compiled-in defaults and factory programming,
     and the values do differ from unit to unit.  It appears that
     there are per-unit process variations such that one needs to
     drive a different APC voltage to the PA from one unit to the next
     to achieve the same RF power output level at the antenna.

     I am inclined that we *are* going to need to do this calibration
     on the units we produce, as without this calibration our Tx power
     levels will be slightly wrong.  Probably not by much: if our Tx
     power is too low, the user may experience a poor connection at
     far distances from the BTS, and if our Tx power is a little too
     high, we would be a little out of spec.  I don't think it would
     be too far off, but considering that we would be operating home-
     built GSM devices without type approval, it would probably be a
     good idea to be "model citizens" on the air and make our
     transmissions 100% within the spec.

   * The ramps table in ramps.XXX: specifies ramp-up and ramp-down
     profiles.  Even though this table is recorded in FFS in every
     Om-made unit, and similarly in Pirelli's factory data block, in
     the case of both Om and Pirelli the values in these "per-unit"
     tables are exactly the same as the compiled-in defaults.  It
     appears that getting these ramps calibrated for every unit is too
     burdensome, and they are worked out just once in the engineering
     lab when a design is first produced.  I wonder if perchance we
     might be able to get away with reusing Openmoko's ramp tables
     unchanged if we use the same RF3166 PA in our designs. :)

   * The calchan table (calchan.XXX) provides a fine adjustment to the
     APC DAC value pulled from the "master" table based on the ARFCN.
     The values programmed here by Om do differ from one unit to
     another, but the magnitude doesn't seem to be very large.  OTOH,
     if we are going to have to do our own Tx power level calibration
     on the units we produce, it doesn't seem like it would be too
     much extra burden to do these measurements at several different
     ARFCNs and fill in the calchan adjustments.

So how are the needed calibration measurements performed on the
factory production line?  It appears that the process goes like this:

* For both VCXO and Tx power level calibration, it appears that L1TM
  is commanded (via an ETM packet) to transmit continuously on some
  set ARFCN, and an RF test station connected to the DUT (device under
  test) in place of the antenna (don't *ever* do this with a real
  antenna connected, unless you are in a Faraday cage!) measures both
  the frequency and the power level of the transmitted signal.

  Note that the VCXO frequency calibration is indirect: the test
  station doesn't see the actual 26 MHz output of the VCXO, but only
  sees the result of this 26 MHz being multiplied up into the GHz
  range.  It appears that more L1TM command packets are sent to set
  the AFC DAC to center, minimum and maximum, and the observed output
  frequencies are recorded.  Then some calculations are made (I have
  yet to understand them, more on this topic later) and /gsm/rx/afcdac
  and /gsm/rx/afcparams are written.

* For the Rx gain calibration, it seems that they make their test
  station generate a signal with precisely defined characteristics,
  and then execute power measurements on Calypso - I still don't
  understand it too well.

I remember DS saying that he has some RF test equipment that could be
used for calibration - DS, perhaps you could give us your thoughts on
whether or not the setup you have could be used to perform calibration
procedures as described above for GSM devices of our own make?

Happy hacking,
SF