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 _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
