On 8 February 2011 10:51, Brian Prodoehl <bprodo...@gmail.com> wrote:
> You may want to look into adding some rough ANI, following the "new" > ANI routines in ath9k. Normally when the OFDM or CCK error rate rises > above a certain level (maybe 200 errors/second), the driver will bump > up a few interference mitigation parameters. Are you successfully > performing noise floor calibration? I'm not sure on the OFDM timing > error, in particular, so maybe someone can shed some light on that > one. I'll take another look at the "new" ANI routines and see how they differ from the old ones. (I guess I should also re-read the patent doc which covers the old ANI implementation.) Ok, I've just re-read the patent and I'm looking at the "new" ANI code. The new ANI code seems to be a lot like the old ANI code, except: * it doesn't use hard-coded ANI tables; * ANI operations become "optional" in some cases; * it caches some of the register values (AR_PHY_SFCORR, AR_PHY_SFCORR_LOW, AR_PHY_SFCORR_EXT, AR_PHY_FIND_SIG, AR_PHY_FIND_SIG_LOW, AR_PHY_TIMING5, AR_PHY_EXT_CCA) at startup; * It modifies (some) of the ANI parameters relative to the cached register values, rather than writing absolute values to the hardware. Does this about summarise it? Adrian _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
