Half and Quarter rate support
The Atheros NICs have an operating mode which allows the chip to be clocked at half or quarter rate. This has the effect of changing the channel bandwidth to be 10MHz (half) or 5MHz (quarter.)
How's it work?
The basic technique involves under-clocking the MAC and PHY. There are some other things that get setup as part of half/quarter rate support - notably any analog filters will need to be adjusted in width or they will still work over the wider frequency range (20/40MHz), leading to degraded performance.
What are the implications?
Because the chip is now under-clocked, anything which is based on "clock cycle" as a duration measurement must be tweaked to take this into account.
In particular:
- AR_USEC - which is the number of clock cycles in a microsecond (both core clocks and 32KHz clocks on older chips);
- TX and RX latency information.
What works?
Any chipset which isn't listed below hasn't been verified as working. This includes derivatives - ie, just because AR5416 works, doesn't mean AR5418 works; AR9285/AR9287 haven't been verified even though their RF synthesiser programming is the same as the AR9280.
TODO: find out which chips have the half/quarter rate analog filters and which don't.
AR5212 + RF5111 |
untested |
it at least doesn't associate to other chips; the frequency offset(s) may be totally wrong |
AR5212 + RF5112 |
works |
2.5MHz channel offset limitation in 5GHz (see below) |
AR5213 ? |
works? |
Hasn't been verified; likely the same 2.5GHz channel offset limitation in 5GHz |
AR5413 |
works |
2.5MHz channel offset limitation in 5GHz (see below) |
AR5416 |
partially works |
5MHz channel increments only; quarter rate channels on 5GHz currently don't work with the -HEAD driver |
AR9280 |
works |
RF synth correctly programs the quarter rate channel frequencies in 4.9/5GHz - and thus it currently won't inter-operate with any of the above |
Packet transmission requirements
TODO: flesh this out some more!
The slot timing and EIFS are extended out from their default values.
TODO: go figure out why this is!
- All of the duration calculations need to change, as now the OFDM symbols are longer;
- This includes the legacy and 802.11n duration calculations.
Implementation details
In short - grep for _HALF and _QUARTER in the HAL directories.
HAL general changes
- ath_hal_mac_clks() - needs to take the half/quarter rate configuration into account when calculating the number of MAC clock cycles in a microsecond
- ath_hal_computetxtime() - is aware of the OFDM half/quarter rate symbol time difference
AR5212 HAL changes
TBD: needs much more fleshing out
- there's AR_PHY_MODE_HALF and AR_PHY_MODE_QUARTER flags which are written into AR_PHY_MODE
AR5416 HAL changes
- the initPLL routines (ar5416InitPLL(), ar9280InitPLL(), etc) may need to configure the PLL slightly differently for half/quarter rates
- the OFDM delta slope calculations (ar5416SetDeltaSlope()) need to take the scaled clock into account
- The IFS / USEC / Latency calculation updates are done in ar5416SetIFSTiming()
What needs to change
- teach ath_hal_computetxtime() about CCK half/quarter rates
- teach the 11n duration calculation about half/quarter rates
- teach the aggregation logic about the maximum frame duration at half/quarter rates (as the 4ms limit still holds!)
- all those duration and timing calculations need to be calculated, not hard coded! Especially to support longer distance coverage class configurations!
- .. none of this works for the AR9287 because the MAC runs at a much higher speed and the values are hard-coded in, not calculated!
- Teach the AR5416, AR9130, AR9160 channel change (ar2133SetChannel()) about fractional 5G channels, in the same setup as AR5112/AR5213
- Teach AR9280 and later channel change (ar9280SetChannel()) about the fractional 5G channel error (see Limitations section)
Limitations due to RF synthesiser accuracy/flexibility
The RF synthesisers before the AR9280 (and maybe the AR9130/AR9160; I'm not sure yet of the RF synth design) don't support 1MHz channel offsets in 5GHz mode. The smallest increment in 5GHz mode is 2.5MHz - and so representing 5GHz xxx2MHz and xxx7MHz channels isn't possible. The AR5112 RF modules round it to the closest 500KHz.
The RF5111 module (which can be found on AR5212 NICs) is programmed differently - it needs to be checked on a spectrum analyser to see what the centre frequency is. It may only interoperate right now with other AR5212's with RF5111 modules.
The AR5416 RF Synthesiser doesn't support 5GHz channel frequencies which do not end on a 5MHz boundary. So 4.9GHz/5GHz xxx2 MHz and xxx7MHz channel frequencies currently won't work. This means the AR5416, AR9130 and AR9160 won't associate on the 5MHz PSB channels. The 1MHz channel width is only currently supported in 2GHz operation. It is possible to program the AR5416 RF synth in 2.5MHz increments (similar to RF5112/RF5413) but (a) this isn't currently implemented in the RF2133 code, and (b) this needs to be tested for accuracy and spurs before it's enabled by default.
The AR9280 and later RF synthesisers support a fractional mode which gives far greater accuracy than the previous designs - so the 5GHz xxx2MHz and xxx7MHz channels can be accurately represented. However, these haven't yet been tested for spurs and other issues, so be careful using 5GHz quarter-rate modes on the AR9280.
It's possible to program the AR9280 to have the same 2.5MHz channel increment that the previous 5GHz RF synthesisers (ie, program it to be 500KHz "off" when on the relevan channels) but again, this has to be tested for spurs and other issues.