/gsm/com/rfcap: tri-band GSM modem believes itself to be quad-band

Thu Jan 16 03:27:31 CET 2014

On Thu 16 January 2014 02:58:29 Michael Spacefalcon wrote:
> Hello Om community,
> 
> In the course of hacking TI GSM firmwares, I have come across something
> that some of you may find interesting, or might even have some insight
> into.
> 
> We all know that our good familiar Neo Freerunner (GTA02) was made in
> two versions: one with 900/1800/1900 MHz bands, the other with
> 850/1800/1900 MHz instead.  The hardware difference is one RF SAW
> filter part populated differently on the same PCB; see this picture:
> 
> http://wiki.openmoko.org/wiki/File:Gta02a6_comms_chips_under_shield.JPG
> 
> The SAW filters for the GSM downlink Rx path are the 3 little buggers
> near the upper right corner, immediately adjacent to the shiny metallic
> component which is the antenna switch.  There is one Rx SAW filter for
> each of the 3 supported bands: one for 1800 MHz (both GTA02 versions),
> one for 1900 MHz (ditto), and one populated for either 850 or 900 MHz.
> (*I think* the topmost one out of the 3 in that picture is the one
> responsible for the 850 vs. 900 MHz difference, but please double-check
> that before attempting any surgery on your Neo!)
> 
> Well, here is the part which will surely surprise at least some of you:
> the standard firmware for the GTA01/02 modem (which is the same for
> all versions, both GTA01 and GTA02) does not actually know which 3
> frequency bands are supported by the device it runs on!  And no, it
> does not auto-detect either: there is no way (short of ESP) for any
> firmware running on the Calypso/Iota/Rita chipset to divine what kind
> of SAW filter sits between that chipset and the antenna.
> 
> Instead, as strange as it may sound, the modem (at least when running
> the standard mokoN firmware, see below) believes itself to be quad-
> band!
> 
> In TI's universe, the "standard" way to "teach" a GSM device (phone or
> modem) which GSM frequency bands it supports is *not* to hard-code
> that knowledge in the firmware at compile time; instead this property
> is stored in a configuration file named /gsm/com/rfcap in the GSM
> device file system.  Yes, TI-based GSM devices all use a flash file
> system with a very UNIX-like "look and feel", including UNIX-style
> pathnames; see my write-up:
> 
> https://bitbucket.org/falconian/freecalypso-sw/src/1852900ce9ea4ac52d4648f7
> d9ca46897eb3640b/doc/TIFFS?at=default
> 
> Like most files in TI's GSM FFS, /gsm/com/rfcap is a binary file, not
> ASCII.  It is a file of exactly 16 bytes, and although I haven't found
> a formal document describing its format in plain English, we can study
> the code that reads this file and acts upon its content:
> 
> http://scottn.us/downloads/peek/TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src/g23m
> -gsm/rr/rr_csf.c
> 
> The 16-byte file is being read into a variable of type EF_RFCAP, which
> is defined here:
> 
> http://scottn.us/downloads/peek/TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src/g23m
> /condat/com/include/pcm.h
> 
> Lines 442 through 460 (inclusive) give the structure definition, which
> is followed by the definitions for the bit fields in each byte.
> 
> And here is what this /gsm/com/rfcap file contains on a standard GTA02
> modem, as revealed by a TIFFS parsing tool such as the mpffs-tools-r1
> package I released last summer:
> 
> 00 1F 41 14 00 00 00 00  50 00 00 A5 05 00 C0 00
> 
> Decoding the meaning of the rest of the bytes is left as an exercise
> for the reader, but I draw your attention to the 2nd byte, which is 1F.
> This byte indicates which RF bands are physically supported by the MS
> (mobile station) hardware, and 1F means quad-band, i.e., all 4 of 850,
> 900, 1800 and 1900 MHz.  Thus even though my trusty GTA02 is only
> 900/1800/1900 MHz tri-band in reality, it believes itself to be
> quad-band!
> 
> Digging some more, one finds that the 16 bytes quoted above appear in
> the moko10 and moko11 fw images (convert them from *.m0 to plain binary
> with the mokosrec2bin.c utility I wrote almost a year ago, then do the
> "binary grep" with the memmem() C library function), and further
> analysis reveals that these "standard" firmwares unconditionally
> overwrite the /gsm/com/rfcap file in FFS with the hard-coded "string"
> of bytes on every boot.  To convince yourself of the latter fact, take
> a GTA02 modem with moko11 in it, change the rfcap file in FFS to
> something else, reboot the modem normally, and observe that the rfcap
> file will be reverted back to the 16 bytes shown above, claiming to be
> a quad-band GSM device.
> 
> My leo2moko firmware does not contain this rfcap-resetting "feature":
> it does not automatically overwrite the rfcap file with anything, and
> uses whatever settings happen to be written in the FFS (the modem's
> flash file system).  At the present, there is no practical difference:
> if your modem ever ran moko10 or moko11 prior to being flashed with
> leo2moko, the content of the /gsm/com/rfcap file in FFS will be what
> moko10/11 wrote into it the last time it booted, which is the hard-
> coded "I am quad-band" value.
> 
> But I wonder - and this is really the main reason for this lengthy
> post of mine - is it really a good idea for a tri-band GSM modem to
> believe itself to be quad-band?  There are two potential problems I
> can think of:
> 
> 1. The modem will waste some time scanning frequencies which it cannot
>    receive because of the "wrong" SAW filter standing in the way.
> 
> 2. Potentially more serious: suppose you are in a geographic region
>    with 850/1900 MHz GSM coverage, and your FR is the (much more
>    common) 900+etc version (my situation), or vice-versa, you are in
>    the 900/1800 MHz lands (EU etc), but have an 850+etc Neo FR.  If
>    the FR advertises itself to the network as supporting all 4 bands,
>    then there is at least a theoretically conceivable possibility of
>    the network then directing it to a low ARFCN which it cannot
>    receive, causing the phone to not work "for no good reason".  OTOH,
>    if the GSM device advertises its RF capabilities truthfully, there
>    a chance that the network will accommodate its limitations and
>    stick to high ARFCNs, which are fully supported by all hw versions.
> 
> I do not know whether there is any GSM network anywhere in the world
> that would direct a mobile station to a low ARFCN if it receives an
> advertisement of such capability, but would stick with high ARFCNs for
> less-capable mobile equipment; much less whether or not any FR user
> has ever been bitten by my hypothetical scenario in the real world.
> Hence I am soliciting the wisdom of the mailing list.
> 
> If the community concludes that having the tri-band modem believe and
> advertise itself as quad-band is *not* a good idea, I would be happy
> to publish the tools and instructions for changing that /gsm/com/rfcap
> file in the modem's FFS to reflect a 900/1800/1900 or 850/1800/1900
> MHz configuration, matching the hardware reality.
> 
> VLR,
> SF

A friend of mine complained about poor reception of the FR I handed to him 
which I used for 6 months without any trouble. Turned out he's using D1 
(900MHz) carrier while my SIM was E1 (1800MHz), and the FR happened to be a US 
model which I forgot about.
Bottom line: even 850MHz FR can do 900MHz but the reception is pretty poor 
though just sufficient in usual urban environment.
I don't think network/BTS can "direct" the mobile to another channel, it can 
only adveritse other channels but it's up to mobile to determine if that 
channel actually works in the particular situation - there may be other 
problems to receive 900MHz band than just a SAW filter, like local interference 
or whatever. When the mobile can't use a certain frequency, the BTS will not 
"force" the mobile to that frequency.

PS: yes, the firmware is the very same for all Openmoko phones. No differences 
in firmware according to model or version.
/j
-- 
()  ascii ribbon campaign - against html e-mail     
/\  www.asciiribbon.org   - against proprietary attachments
(alas the above page got scrapped due to resignation(!!), so here some 
supplementary links:)
http://www.georgedillon.com/web/html_email_is_evil.shtml          
http://www.nonhtmlmail.org/campaign.html
http://www.georgedillon.com/web/html_email_is_evil_still.shtml    
http://www.gerstbach.at/2004/ascii/ (German)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openmoko.org/pipermail/community/attachments/20140116/1183e3f6/attachment.sig>