FCDEV3B bring-up status

Serg l serg at tvman.us
Mon Apr 10 20:55:17 UTC 2017

Thank you very much for this summary.

I have access to a number of RF tools and as my goal is to get just a
limited number of modems manually calibrated, it can be sufficient.

I will research the process and report findings.

Yes, I'd like to get the board, so we can double the effort at this stage.
I'm in the process to get another fresh pair of eyes working on this full
time, if it helps :)

On Mon, Apr 10, 2017 at 3:54 PM, Mychaela Falconia <
mychaela.falconia at gmail.com> wrote:

> 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~
> _______________________________________________
> Community mailing list
> Community at freecalypso.org
> https://www.freecalypso.org/mailman/listinfo/community

More information about the Community mailing list