+
−Frequency bands and band-pairs
+
−==============================
+
−
+
−TI's TCS211 L1 (meaning Layer1 component of TI's TCS211 reference fw and of all
+
−FreeCalypso firmwares that are based on TCS211) can operate either in a single
+
−frequency band or in a pair of bands (one low band and one high band)
+
−corresponding to a regional standard.  TI's G23M protocol stack (specifically
+
−its ALR component) commands L1 to operate in a given "standard" (single band or
+
−pair of bands) by way of MPHC_INIT_L1_REQ primitive, which appears in L1 debug
+
−trace output (seen via rvtdump or rvinterf) as a BAND_R trace.  The "standard"
+
−number that appears in this BAND_R trace is one of the following 8
+
−possibilities:
+
−
+
−STD 1 (GSM)
+
−
+
−	This STD tells L1 to operate only in the GSM900 band by itself (not
+
−	paired with DCS1800), and furthermore to use the old definition of this
+
−	GSM900 band with only 124 channels.  TI's code supports this option in
+
−	order to support old RF hardware that was made for this old definition
+
−	of the GSM900 band, but none of the phones, modems or development boards
+
−	we work with in FreeCalypso are this old - thus this STD 1 should never
+
−	get activated unless something is misconfigured somewhere.
+
−
+
−STD 2 (GSM_E)
+
−
+
−	This STD tells L1 to operate in the EGSM band, i.e., the new extended
+
−	definition of the 900 MHz band with 174 channels total - but it still
+
−	specifies only the EGSM band by itself, not paired with DCS1800.  We
+
−	don't have any FC hardware targets that support the 900 MHz band but
+
−	don't support DCS1800, thus this STD can only get selected if the DCS
+
−	band is artificially disabled - and we do not currently know of any use
+
−	case for disabling DCS while keeping EGSM enabled - thus this STD should
+
−	not be seen in practice either.
+
−
+
−STD 3 (PCS1900)
+
−
+
−	This STD tells L1 to operate in the PCS band by itself.  This STD
+
−	selection occurs in regular operation on devices like the Pirelli DP-L10
+
−	and the tri900 version of our FCDEV3B: on such tri900 platforms the G23M
+
−	protocol stack switches L1 back and forth between STD 6 (900+1800 MHz
+
−	band pair, see below) and STD 3 for PCS.  Because tri900 platforms have
+
−	no support for the GSM850 band, the PCS1900 band gets selected as a
+
−	singleton (not a band pair) when the device operates on the "US" side
+
−	of its multi-region frequency band support.
+
−
+
−STD 4 (DCS1800)
+
−
+
−	This STD tells L1 to operate in the DCS band by itself, not paired with
+
−	900 MHz GSM or EGSM.  Triband devices built in the tri850 configuration
+
−	(GTA02-850 and FCDEV3B-850) will select this STD when looking for
+
−	possible DCS1800 cells - however, our expected user pattern is such that
+
−	a user living or operating in EU-band lands (EGSM and/or DCS bands)
+
−	would not be using a tri850 device, much in contrast with the reverse
+
−	situation where tri900 devices are commonly used in the PCS1900 band.
+
−
+
−STD 5 (DUAL)
+
−
+
−	This STD selects a band pair consisting of the old 124-channel
+
−	definition of the GSM900 band plus the DCS1800 band.  Because all hw
+
−	platforms targeted by FreeCalypso support the 900 MHz band in its new
+
−	EGSM definition if they support it at all, this STD 5 should never get
+
−	activated unless something is misconfigured somewhere.
+
−
+
−STD 6 (DUALEXT)
+
−
+
−	This STD selects the classic "EU" band pair of EGSM + DCS1800.  This STD
+
−	selection will occur in normal operation on EU dual-band devices like
+
−	the EU versions of Motorola C1xx and Huawei GTM900-B, as well as tri900
+
−	and quadband devices operating on the "EU" side of their multi-region
+
−	frequency band support.
+
−
+
−STD 7 (GSM850)
+
−
+
−	This STD tells L1 to operate in the GSM850 band by itself.  We don't
+
−	have any FC hardware targets that support the 850 MHz band but don't
+
−	support PCS1900, thus this STD can only get selected if the PCS band is
+
−	artificially disabled.
+
−
+
−STD 8 (DUAL_US)
+
−
+
−	This STD selects the full "US" band pair of GSM850 + PCS1900.  This STD
+
−	selection will occur in normal operation on US dual-band devices like
+
−	the US versions of Motorola C1xx and Huawei GTM900-P, as well as tri850
+
−	and quadband (but not tri900!) devices operating on the "US" side of
+
−	their multi-region frequency band support.  Note that tri900 devices
+
−	will go into STD 3 (PCS1900 band by itself) instead!
+
−
+
−ARFCN munging
+
−=============
+
−
+
−When L1 operates in one of single-band standards 1 (GSM), 3 (PCS1900), 4
+
−(DCS1800) or 7 (GSM850), its internal radio_freq numbers that appear in L1 debug
+
−traces are exactly equal to standard ARFCNs for that band as defined by ETSI.
+
−However, when it operates in STD 2 (EGSM by itself) or in any of the dual-band
+
−standards, it uses its own radio_freq numbers which are different from standard
+
−ARFCNs.  Non-standard internal radio_freq numbers are used in these cases
+
−because L1 needs a continuous number range for indexing arrays, and the mappings
+
−are given below.  STD 6 (DUALEXT) and STD 2 (GSM_E) use the following mapping:
+
−
+
−Band	Standard ARFCN	TCS211 L1 radio_freq
+
−--------------------------------------------
+
−EGSM	1-124		1-124
+
−EGSM	975-1023	125-173
+
−EGSM	0		174
+
−DCS	512-885		175-548
+
−
+
−The internal radio_freq number for the DUALEXT band pair ranges continuously
+
−from 1 to 548.  STD 2 (EGSM by itself) uses the same mapping without the DCS
+
−subrange, with radio_freq ranging continously from 1 to 174.  DUAL_US band pair
+
−(STD 8) uses a continuous radio_freq range from 1 to 423 as follows:
+
−
+
−Band	Standard ARFCN	TCS211 L1 radio_freq
+
−--------------------------------------------
+
−GSM850	128-251		1-124
+
−PCS	512-810		125-423
+
−
+
−Because these internal radio_freq numbers appear in L1 debug traces, power users
+
−who like to understand these traces and see what their phone is doing need to
+
−be able to work with these numbers.  I (Mother Mychaela) currently use a Pirelli
+
−DP-L10 running its original proprietary fw as my everyday phone, for lack of
+
−anything better, and because it is a tri900 device, it operates in STD 3 for
+
−PCS1900 band by itself.  In this configuration all radio_freq numbers that
+
−appear in the debug trace output are native PCS band ARFCNs without any munging,
+
−thus no conversion tools are needed.  However, I am now starting to work more
+
−with quadband Tango modules and development boards (iWOW DSK and FC Caramel2),
+
−and we also have a few FCDEV3B-850 boards; these platforms support both GSM850
+
−and PCS1900 bands and thus go into STD 8 for DUAL_US, and this dual-band STD
+
−involves ARFCN munging as detailed above.  Furthermore, anyone who lives or
+
−operates in EU-band lands would normally be operating in dual-band STD 6
+
−(DUALEXT), and that one also involves ARFCN munging.
+
−
+
−Because there is a need to translate back and forth between standard ARFCNs and
+
−L1 radio_freq numbers, a pair of utilities has been written for this purpose:
+
−arfcn2ti and ti2arfcn.  Their usage and operation is straightforward; each
+
−utility takes two command line arguments: a keyword of "eu" or "us" selecting
+
−the band pair being mapped, and the number to be converted.  The output of the
+
−conversion (the other number) is printed on stdout.