FCDEV3B bring-up status

[Mychaela Falconia]

Hi Serg,

> This is really good that you confirmed RF circuit functionality to some
> degree.

Yes, it is indeed very relieving to know that our RF tract appears to
be perfectly fine, no worse than the historical commercial Calypso-
based GSM phones and modems.

> I remember that you were talking about calibration procedures, could you
> remind me where in the available docs and codebase we have the calibration
> table values defined/described? Just trying not to duplicate the research
> effort :)

There are 3 separate aspects that are expected to be calibrated per
unit in production:

1. The frequency produced by the 26 MHz VCXO as a function of the AFC
   DAC control word;

2. Some aspects of the Rx path (per band) which I have yet to
   understand;

3. Tx power levels, i.e., what value should be written into the APC
   DAC register in order to produce each of the spec-defined Tx power
   levels for each band - very important if you wish your radio
   transmissions to be compliant with the specs, i.e., if you do not
   wish to act as a rogue transmitter and give various regulators a
   legitimate reason to go after us.

The order of inode creation in the FFS images read out of Openmoko-made
GTA02 units indicates that the calibration steps were performed in the
order given above, i.e., the VCXO calibration is supposed to be done
first, and this VCXO calibration is also the most critical step for us
currently: parts 2 and 3 can be skipped as long as we are playing in
the lab and not shipping any commercial products, but without VCXO
calibration our modem is not usable with our TI-based firmware even in
the lab setting.  Thus I am going to focus solely on the VCXO part of
the calibration process in the remainder of this post; the other two
can be addressed after we have conquered the VCXO.

The to-be-calibrated VCXO parameters live in the T_AFC_PARAMS structure
defined in cust0/l1_rf12.h - all *.[ch] file paths are relative to
src/cs/layer1 in fc-magnetite.  The first member of this structure
(eeprom_afc) is stored in FFS in /gsm/rf/afcdac, but it appears to be
a legacy bit which is no longer used.  Instead it is the remaining 8
members of this structure that matter, and those are stored in FFS in
/gsm/rf/afcparams.

The last member of the structure (snr_thr) is a never-changing constant
(never changes from the compiled-in default value), so we don't need to
worry about that one.  The 3 signed 16-bit word members named
dac_center, dac_min and dac_max contain the calibrated values to be
loaded into the AFC DAC to produce an output frequency offset of 0,
-15 ppm and +15 ppm, respectively, according to this TI document:

https://www.freecalypso.org/LoCosto-docs/Production%20test%20and%20calibration/i_sample_rf_test_and_calibration_13_03_04_01991%20-%20v026.pdf

The actual AFC DAC value on the Calypso+Iota chipset is in the range
from -4096 to +4095 (on LoCosto the range appears to have changed to
-8192 to +8191), but the values written into the dac_center, dac_min
and dac_max structure members are the AFC DAC values times 8 on the
Calypso, or times 4 on LoCosto - thus when the above LoCosto document
tells you to multiply these numbers by 4, mentally change it to
multiplying by 8 for Calypso.

The VCXO calibration procedure is described in section A.1.11 of the
above PDF, spanning pages 33 through 38.  Last night I attempted to
perform this procedure: I connected an FCDEV3B to my CMU200 with an
RF coax cable (SMA connector on the FCDEV3B end, N connector on the
CMU200 end), figured out how to put the CMU200 into the RF analyzer
mode where it reports the measured frequency offset of the incoming RF
signal among other things (figuring out how to do it on the CMU200
was surprisingly easy), and executed steps 1 through 12 of the
procedure given on page 34 of TI's LoCosto PDF.

If you would like to replicate these steps when you receive your
FCDEV3B and connect it to a CMU200 or to some other RF test equipment
that can analyze incoming RF signal and measure the frequency offset,
do the following:

* Connect to the IrDA UART on the FCDEV3B - I will prepare a document
  with header pinouts after I get your board sent out.  You'll need
  the FreeCalypso firmware's RVTMUX interface, and it is presented on
  the IrDA UART by default.

* Run FreeCalypso Magnetite fw - given the current problems with flash
  booting, running it out of RAM with fc-xram would be the safest bet
  for the time being.  Your command line will look something like this:

  fc-xram -h fcfam -B 812500 /dev/ttyUSBx ramimage.srec rvinterf

  See the doc/High-speed-serial write-up in the freecalypso-tools
  repository for the ugly hacks you have to do in order to make the
  -B 812500 option work with FTDI adapters, or you could use the
  cleaner CP2102.  You could also omit the -B 812500 option and have
  everything work without hacks on any serial adapter, but then it'll
  be painfully slow.

* With an rvinterf process already running from your fc-xram command
  above, run fc-tmsh in another terminal window.  DO NOT give a -p
  option to fc-tmsh, instead have it to connect to your already running
  rvinterf process - nothing will work right if you have two rvinterf
  processes trying to read from the same serial port.

All Test Mode Shell commands given in the Action column of the
procedure table on PDF pages 34-35 can and should be issued through
our fc-tmsh tool, in exactly the same syntax with only minor changes:

* The command keywords are all lowercase in our version;
* If you get as far as step 21, our version of the rftw command takes
  the table input from an ASCII text file instead of directly on the
  rftw command line;
* In step 22 the PDF document is in error: it should be rfpw 10
  instead of 9 here.  Rfpw 9 sets the actual real-time AFC DAC value
  and the instructions to do rfpw 9 in all previous steps are correct,
  but rfpw 10 is to put the number into that eeprom_afc structure
  member described earlier.

When you execute procedure steps 1 through 6 on page 34, the modem
will start transmitting continuously on ARFCN 40 uplink, which is
898.0 MHz.  Needless to say, you should NEVER issue these fc-tmsh
commands with a real antenna connected, unless you wish to have radio
regulators knocking on your door to investigate your jammer.  Instead
this procedure should ONLY be executed when the RF port on the modem
is connected with a coax to a CMU200 or equivalent.

I got as far as step 12, and as I was changing the AFC DAC value with
rfpw 9 commands, I could immediately see the measured frequency offset
change on the CMU200 screen - it was very cool.  But this is where I
got stuck: the LoCosto document instructs the calibration operator to
set the AFC DAC value to -4096 in step 7, and then to +4096 in step 10.
However, the valid range of AFC DAC values on the Calypso+Iota chipset
is from -4096 to +4095, thus +4096 is not a valid value.

The fundamental problem is that we only have a calibration document
for LoCosto and not Calypso+Iota+Rita, and we don't know what the
details were in the original CIR version prior to LoCostification
changes.  I don't know if the original CIR calibration procedure used
-4096 and +4095 as the endpoint DAC values, or if they used -2048 and
+2048 for half the range just like the LoCosto version uses half of
the LoCosto chipset's physically possible range.

Also look at equations (4.16) through (4.19) on PDF page 37 - these
are the LoCosto equations, but only Cthulhu knows what the original
CIR equations were prior to LoCostification.  There are some comments
on lines 242 through 255 of the original TCS211 l1_rf12.h header file
(look in fc-magnetite), but they just raise more questions.  Finally,
you can look at the code that actually makes use of all these VCXO
calibration values - it is the l1ctl_afc() function in cfile/l1_ctl.c
- but I was not able to figure it out.

Now it should be obvious that these calibration procedures were not
performed manually on each individual unit on factory production lines.
Instead there was an automated program that exchanged L1TM commands
with the DUT on one port, talked SCPI commands to the CMU200 on another
port (serial or GPIB), and performed the entire calibration procedure
including all measurements and computations from a single button click
once the operator connected the RF cable between the DUT and the test
station.

The manufacturer of the World's Most Famous Calypso Smartphone
obviously had a copy of this program for use on their production line.
I was told that they had it in the form of a Windows binary sans source
(no surprise here), but if I had a copy of it, I could reverse-engineer
it: if nothing else, at least sniff its exchanges with the DUT and the
CMU200 and gain a huge amount of insight that way.

But the problem is that I have not been able to obtain a copy of that
Windows binary calibration software so far.  Harald Welte told me at
first that he might have a copy, then he said he looked and couldn't
find it.  I am going to try reaching out to some other folks, but I
don't hold out a whole lot of hope.

If we are not able to obtain a copy of the original calibration
software (or alternatively a calibration procedure document that is
correct for the Calypso+Iota+Rita chipset rather than LoCosto), I may
have to end the FreeCalypso project, writing it off as a failure, and
redirect my life energy to some other activities (like writing
transgender sci-fi novels for example) that don't require obtaining a
copy of unobtainium software or documentation.

To Serg: if you still would like to receive your board given the
crushingly defeating news above, please let me know and I'll ship it
out to you today or tomorrow.

> Maybe I could use some alternative tools than CMU200.

The CMU200 is the easy part.  I just checked on ebay, and the same
seller from whom I bought mine for $895 has another unit up for sale
for only $559.20:

http://www.ebay.com/itm/Rohde-Schwarz-CMU200-with-GSM-900-1800-1900-Audio-Measurement-V3-05-/302252282725?hash=item465fa3d365:g:D94AAOSwhQhYyAlC

This is the cheapest CMU200 listing I see on ebay at the present
moment.  This unit is not as loaded with options as the one I bought,
but from the description this cheap unit has everything that would be
needed for running the calibration procedures.

And if you do wish to use something other than a CMU200, you'll need
some RF test device that can analyze an incoming RF signal and measure
its exact frequency.  I don't know what other RF test devices exist
and what their capabilities are, but you probably know better than I
do.

M~