view doc/ARFCN-mapping @ 767:6717f18780d8
target-utils/simtest/simregs.h: a little white space fix
author
Mychaela Falconia <falcon@freecalypso.org>
date
Thu, 11 Mar 2021 23:33:51 +0000 (2021-03-11)
parents
e1c8c5bcb233
children
line source
+ − 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.