Re: FreeCalypso GSM MS development board built and mostly works

Hi Harald, 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. 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. This TI document for their later LoCosto chipset (not Calypso) gives some clues: https://www.freecalypso.org/LoCosto-docs/Production%20test%20and%20calibrat… 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: ftp://ftp.freecalypso.org/pub/GSM/GTA02/rfcal-examples.tar.gz 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. 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 understanding. 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... 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 option. 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. 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. M~