FreeCalypso > hg > freecalypso-tools
view doc/ARFCN-mapping @ 921:74d284add54d
fc-fsio: guard against bogus readdir results from the target
If the FFS being operated on contains SE K2x0 extended filenames,
readdir will return strings that are bad for printing. We need to
guard against this possibility, and also against possible other
bogosity that could be sent by other alien firmwares.
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 31 Dec 2022 22:55:23 +0000 |
parents | e1c8c5bcb233 |
children |
line wrap: on
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.