Hello FC community, Over the past week or so I did a bunch of RF tests with our CMU200 instrument that have resulted in a few changes to our FC firmware and some knowledge gains:
* On TI's older Clara RF platform (RF 10) the AGC range went from 6 to 50 dB, whereas on the Rita chip used in all Calypso devices we work with this AGC range has been reduced, now going from 14 to 40 dB. I am guessing that TI made this simplification change to their RF silicon because the narrower AGC range is sufficient with the improved baseband ADC resolution in the Iota ABB compared to Nausica. However, as I was reviewing some AGC-related code in L1, I caught a bug that was made by TI back when they first introduced RF 12 (Rita) support, and that was apparently never caught back in the days when Calypso was active, neither by TI nor by any of TI-based phone manufacturers: the low_agc field in the T_AGC structure in l1_rf12.c was set to 6, which is not a valid AGC value for Rita RF, with the valid range being [14,40]. This number was clearly an overlooked remnant from l1_rf10.c for Clara RF, where it is correct. The effect of this bug is that when the cell search process was doing power measurements in "low AGC" mode, the AGC would get effectively set to 14 dB (the lowest possible value on Rita RF), but the higher level control code assumed it was 6 dB, with the measurement results being off by 8 dB. I fixed this bug by changing the low_agc number to 14 for Rita RF. * This weekend I was finally able to confirm through CMU200 testing that the tables of Tx ramp templates we got from Openmoko (extracted from OM's l1_cust.obj blob) are indeed correct for our OM-based RF hardware on our current FCDEV3B boards. When the CMU200 analyses the Tx signal put out by the DUT, it reports whether the power ramp meets or violates official spec tolerances, and in my FCDEV3B testing it showed passing ramp for every power control level in each of the 3 bands we support. We will probably never know whether TI-Taiwan customized these Tx ramp templates for FIC's choice of RF3166 PA or if they were calibrated on a TI Leonardo board with an RF3133 PA and required no changes for RF3166 (OM could not have changed these numbers themselves, as they got this part as an object blob from TI-TW), but whatever the history, at least we know that they are correct for our current hw, which is a big relief. * Through further CMU200 testing of several different Calypso-based target devices which we support, I also confirmed what I previously suspected: aside from possible cases of two closely related PA models from the same vendor, every different PA type requires different Tx ramp templates in order to produce correct power ramp in the final RF Tx output. Right now in our current FC firmware we have 3 different sets of Tx ramp template tables: one for our own FC hardware (from OM), another for Mot C139/140, and a third one for Mot C11x/12x and C155/156. The last one is the most recent addition: until a couple of days ago we used Mot C139/140 Tx ramp templates on all Mot C1xx targets, but my CMU200 tests this weekend revealed that these templates which Compal must have calibrated for their SKY77325 PA on Mot C139/140 do NOT produce correct RF Tx output on the older C1xx subfamilies with an older SKY77324 PA - yes, just one digit difference in the PA part number! Given that we have got two recent changes to the numbers in l1_rf12.c (the low_agc change affecting all Rita platforms and the change of Tx ramp template tables for Mot C11x/12x and C155/156), I have put out a new binary release for FC on C1xx: ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/c1xx-fcmag-20190311.tar.bz2 For C139/140 the only effective change from the previous 20190129 release is the low_agc change (all Calypso-based phone manufs back in the days lived with this bug all those years without ever noticing it, so the impact is *very* minor), but if you playing with FreeCalypso VPM (voice pseudo-modem) on Mot C11x/12x or C155/156, you definitely need to update, as the previous incorrect Tx ramp templates result in non-compliant RF Tx output. I am also going to make a new production fw release for FCDEV3B (incorporating the low_agc fix) when I make the next batch of boards, but there is no urgency, as this low_agc fix is totally non-critical. In other news, I will soon be adding support for one more historical Calypso phone target: Sony Ericsson J100. This phone was made by Compal just like Mot C1xx, all technical details are much the same (this SE J100 model is closest to C139/140, but has a different LCD and a MIDI ringtone player chip instead of Calypso-driven buzzer), only the style and mechanics of the case and the UI decorations are different between made-for-Motorola and made-for-Sony-Ericsson phones. The level of support in FC for this SE J100 model is going to be the same as for Mot C11x/12x and C155/156: only voice pseudo-modem operation with the display remaining dark, buttons doing nothing and AT commands required for control. The main purpose of adding this support will be to check how the RF hardware in this phone compares to other known Compal models in the form of Mot C1xx. This phone model is NOT expected to be an attractive choice for FC end users or tinkerers because it does not have the same headset jack as Mot C1xx, instead it has a multi-pin proprietary connector for all accessories (charger, headset, serial interface pins), and the only way to get serial access on this phone is by constructing your own cable through some cutting and soldering - as far as I can tell, no one makes serial cables for these phones like various people make for Mot C1xx. (Yes, I did the cable surgery myself: I cut apart a Sony Ericsson data cable that only works in its intact form on other SE phones that have native USB on the same pins where J100 has our Calypso UART, and soldered the wires to an off-the-shelf FT232RL adapter board. The wires in those SE data cables which need to be cut apart and soldered are *tiny*, must be no more than 28 AWG, and they are stranded, which is even more difficult to work with. I stripped and soldered them the best way I could, but it is kind of a miracle that they hold at all.) I am playing with these SE J100 phones because Harald Welte sent me one, and then I bought one more from a seller on ebay. Harald sent me this phone in relation to certain happenings in the funny circus house known as OsmocomBB: a Russian GSM/RF/SDR/etc tinkering enthusiast named Vadim Yanitskiy, who is basically the only person doing any active work on OBB in the recent months/years, has finally (after a year and a quarter of delay) got around to trying to integrate the RF calibration reading patch which I made for OBB back in 2017-Nov. Back at that time in late 2017 I was willing to support users who wanted to run OBB on our FCDEV3B boards if they would pay the full commercial price for the hardware (which hasn't happened), and for that purpose I made a patch to OBB that makes it use correct RF Tx and VCXO parameters on our hardware instead of the totally wrong numbers that are hard-coded in their mainline code, as much as OBB's flawed architecture would allow. But OBB's architecture also made it impossible to make this change just for the FCDEV3B target, and I had to bring all of their pre-existing targets up to par at the same time. SE J100 was the only OBB-supported target device which I never laid my hands on previously and which was therefore not supported in FC until my current effort to add this support. However, when I tried to run OBB (both with and without my patch) against our CMU200 instrument to see what OBB puts out in terms of RF Tx output and how my patch changes it, I was not pleased at all with what I saw. As I have just confirmed with the same RF test instrument that is used in official type approval certification tests, what OBB puts out on the air is far worse than I previously imagined, and the problems are far bigger than what my little patch can fix. See this post I made to their mailing list: http://lists.osmocom.org/pipermail/baseband-devel/2019-March/005625.html TL;DR: if you run OsmocomBB on any Calypso phone (whether your hw was made by Motorola or FreeCalypso or any other manufacturer) and do it in open air, i.e., without putting the phone in a Faraday cage or disconnecting the internal antenna, and if you get FCC regulators knocking on your door to slap you with a 6-digit fine plus a few months in jail for interfering with and disrupting radio communication networks, you will fully 100% deserve that fine and jail term. OBB's radio transmissions are *grossly* out of spec, and so bad that they most definitely *will* cause interference and disruption to GSM or other cellular networks around you. OBB's Tx output is so bad that the CMU200 is not even able to measure it (see the linked post for the details), hence we don't even know the exact degree of its badness. There is a world of difference between operating a mobile device that lacks the official rubber stamp of approval because no one paid for it, but which in fact operates 100% correctly on the air as verified with properly calibrated test instruments (the case with FreeCalypso), versus operating a mobile device whose radio Tx output is wildly out of spec and highly likely to cause harmful interference (the case with OsmocomBB), and doing so while *knowing* that your transmitter is bad. Thus if you get caught causing disruption to cellular networks by running OBB, and it can be proven that you have seen this warning post of mine with solid technical backing, then it could be argued in court that you had *willfully* caused that cellular network disruption, and your penalties will be correspondingly harsher. Prior to my CMU200 tests this weekend, I did not realize that OBB's behaviour on the air was this bad. It was widely known that OBB fails to implement many important GSM functions such as handover, and OBB's toy architecture is unsuitable for any serious use, but prior to now I mistakenly assumed that it was relatively safe to use within the constraints of its functional limitations. But now we know otherwise: it is not safe at all! In contrast, our own FreeCalypso products (both our own FCDEV3B as well as FreeCalypso fw running on Mot C1xx phones) put out 100% correct, 100% spec-compliant radio transmissions, as verified with the very same CMU200 instrument - it is the very same test instrument as used by official compliance testing labs, and our instrument is itself kept in good calibration standing. In the case of running FreeCalypso fw on Mot C1xx phones, correctness of radio transmissions is contingent on two conditions: if your C1xx variant is anything other than C139/140, you need to be running the latest firmware which I just put out with corrected Tx ramp template tables, and for all C1xx variants, you need to diligently extract the original Tx levels tables with c1xx-calextr and reupload them into your FreeCalypso FFS with fc-fsio as spelled out in C1xx-Howto instructions in the release tarball. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community