FreeCalypso RF calibration revisited

[Mychaela Falconia]

Hello FreeCalypso community,

Earlier this week I gave the go-ahead to Technotronix to assemble the
next batch of FCDEV3B boards.  They told me that the assembly price
would be the same whether we do all 12 remaining boards at once or
just another 8 at first and then the remaining 4, so I told them to do
another 8 boards for now.

These new boards are expected to be done some time in late August or
early September, and I have been working on the automated production
test, batch programming and calibration software for our FreeCalypso
device production line: when the boards first arrive from Technotronix,
they are naturally untested, and we absolutely need an automated and
efficient way to program them with the current production firmware
image, verify that they boot correctly, initialize their FFS and run
the RF calibration procedure with the CMU200 that exercises the RF
tract in both directions for each band.  For the first batch of our
boards I did all of these steps manually as I reconstructed the lost
theory and developed new tools for each calibration step, but it is
now time for proper production line automation.

The software used on the FreeCalypso device production line currently
consists of 3 parts:

1) The same regular FC host tools which are used by our community
firmware tinkerers and empowered end users, i.e., fc-loadtool to
program the fw image and erase any previous garbage, rvinterf to talk
to the newly made board as it boots for the first time, fc-fsio to
format and initialize its FFS and set its IMEI etc;

2) FreeCalypso RF calibration tools (fc-rfcal-tools) to perform all of
the RF calibration steps that require the CMU200, also serving as a
pass/fail test for the RF tract;

3) An in-house FC production shell (fc-prod-shell) that does little
more than invoke all of the previously listed programs in the right
order; this fc-prod-shell produces a sufficiently high-level operator
interface so that the duties of the FC production line operator can be
performed by someone who does not necessary know FreeCalypso innards
and does not even need any real Unix/Linux command line skills.

Part 3 (the streamlined shell for minimally-skilled production line
operators) will remain internal to my family company for the time
being, as there is absolutely nothing that anyone could possibly do
with this software except set up a competing production factory, and
it does not do anything which you couldn't trivially do by simply
invoking the right tools from the fc-host-tools and fc-rfcal-tools
suites.  However, part 2 (fc-rfcal-tools) is now public:

https://bitbucket.org/falconian/fc-rfcal-tools

While I am not too happy about the possibility that our Iranian
"friends" (the ones who made their own bastardized derivative of
Openmoko's GTA02 while constantly striving to bypass and undercut the
FreeCalypso core team at every step instead of working with us) may
take this software and use it toward their purely self-serving ends
without contributing anything back to our community, I feel that we
have reached the point where the value of having the community review
this code and possibly help the FC production team with our needs
outweighs the negative of making it easier for the Iranians to screw
us.  Hence the public release I just made.

The primary purpose of fc-rfcal-tools software is to be used on the
FreeCalypso device production line to test and calibrate the devices
we make and sell, and it absolutely requires a R&S CMU200 RF test
machine to do anything useful - if you don't have a CMU200, all you
can do with this sw is stare at the source code and adore its beauty. :)

However, if someone does have the needed R&S CMU200, there are, at
least hypothetically, some potential legitimate use cases for the
fc-rfcal-tools software besides setting up a competing device
production factory:

* There exists a slight possibility (unknown to me if such a thing
ever happened in reality, but it is at least hypothetically possible)
that some hapless Openmoko FreeRunner (or even GTA01) user may have
ruined their FFS through careless playing with modem flashing software,
especially in pre-FreeCalypso days when this modem was treated as a
"thou shalt not enter" forbidden zone and modem flashing software
(TI's FLUID, running under Windows) was only available on a hush-hush,
whisper-whisper basis.  Any FC community member (not just me) should
be empowered to open a repair service bureau that can recalibrate
Openmoko devices among other services.

* Back in the days when non-smart cellphones were repaired rather than
discarded, it appears that some of those repair service centers had
CMU200 stations for recalibration.  It is conceivable that some of the
RF calibration parameters may drift over time, thus once again a
repair service bureau offering recalibration may be a perfectly
legitimate offering.

* There are some alien Calypso devices (not made by us or by our
predecessor Openmoko) on which we can at least kinda-sorta run our FC
firmware, but on which we are unable to grok their original factory
calibration data.  Mot C1xx phones are the prime example.  If we ever
get our FC firmware working on Mot C139 (or some other C1xx) in a
usable manner, but we are still not able to retrieve their original RF
calibration values, we would be running with an uncalibrated radio
like we currently do on those phones.  If some member of our community
steps up to offer new RF calibration (with a CMU200) for FreeCalypso-
converted C1xx phones, more power to them.

With the public release of fc-rfcal-tools out of the way, here are the
remaining calibration-related issues I still need to get resolved:

* I recently reran the calibration on a board which I had previously
calibrated (as part of testing fc-prod-shell), and was surprised to
see that the RF power measurements reported by my CMU200 are now 0.5 dB
less than they were previously.  At first I thought something was
wrong with the FCDEV3B, but then I realized that it is a result of the
work I did on the CMU200 itself: I replaced the Rx/Tx module inside to
fix the broken main signal generator (the Rx part of the original
Rx/Tx module was fine, but the Tx side was dead), and the instrument
now reports different RF power readings, 0.5 dB less than before.
Which raises the question: are the new measurements low by 0.5 dB
relative to the real truth, or were the old ones high by 0.5 dB
relative to the real truth?  Or is the real truth something else
altogether?

* My current Tx levels calibration profiles (see txlevels/fcom1* and
doc/Tx-cal-theory in the just-released fc-rfcal-tools tree) were
created under the assumption that the numbers which my CMU200 reported
prior to the internal module swap were the real truth, i.e., what the
FCDEV3B transmitter actually puts out.  But if the previous numbers
were actually high by around 0.5 dB and if the numbers I'm getting now
are closer to the real truth, then these profiles are NOT correct. :-(

Thus I am reaching the conclusion that I really need to get my CMU200
calibrated, and if I am not able to afford official calibration (which
will most likely be the case), at least do an informal calibration:
find someone who can lend the use of a *trustworthy* signal generator
(i.e., one whose output level is reliably known with 0.1 dB or at
least 0.5 dB precision), connect it to my CMU and see what the latter
reports.  And given the level of precision I am working with, I also
need to confirm that the insertion loss of my coax (between the CMU200
and the DUT) really is what I think it is, and if such assurance is
not possible with the cheap coax I am currently using, possibly
replace it with a more expensive metrology-grade one.

At this point I could really use some help from the community with
getting my CMU200 and the interconnecting coax calibrated, but in
order to be useful, the help would need to be at least somewhat local
to me in Southern California.

Hasta la Victoria, Siempre,
Mychaela aka The Mother