11n TX and RX experiments..

My experiments so far are as follows (all in 5GHz mode - 2GHz is just too busy in my apartment complex):

• FreeBSD <-> FreeBSD 11n is stable on the AR9160 and AR9220. TX aggregation is disabled, so it reaches around 35-40mbit in HT/20 and 45mbit in HT/40 mode. I'm getting MCS13 between an AP and STA which are in different rooms in my apartment. MCS15 is achievable if the units are close to each other.
• Short-GI in 40MHz works fine.
• When RX aggregation is enabled, and IEEE80211_AMPDU_AGE is enabled with net.wlan.ampdu_age set to 5 (it defaults to 500), I get ~ 55mbit RX in HT/20 and ~ 75mbit RX in HT/40 mode. There's problems with out of order packets that are appearing -before- the calculated block-ack window and net80211 is dropping those. I'll investigate why at some point.
• FreeBSD works fine as an 11n AP, obviously with A-MPDU TX disabled.

There's lots of stuff that needs to be tested at this point, including:

• 2GHz operation, obviously!
• 11n and legacy co-operation.
• Other chipsets - AR5416, AR9280, AR9285.
• Behaviour in the presence of noise, busy channel, etc.
• Make sure that HT/40 mode is -correctly- protecting frames on both channels and is correctly waiting to make sure both channels are free before transmitting!

And stuff that needs to be implemented before we enable it by default:

• A-MPDU TX aggregation, for STA, AP, Mesh and adhoc modes - this one is really needed and is going to take some time to do.
• HT RTS frame protection - I have code for this which I'll commit soon.

(More) wireless hackery

So instead of doing what I should be doing, I did some more wifi hackery.

The short summary version (all 802.11g 2.4ghz testing):

• AR5416 TX is still unhappy and unpredictable. It's also like that with ath9k. AR5416 RX is perfectly fine.
• AR9160 TX/RX is fine.
• AR9220 (Ubiquiti SR71-12 and Ubiquiti-SR71-15) TX/RX is now fine.
• AR9280 closed and open-loop TX is fine, RX is also fine.
• AR9285 TX/RX is fine and stable now.

I'll now go and test out 5GHz AP/STA modes with the above (where appropriate) and see how they behave. I hope they'll be just as stable now.

Bernard has been making inroads into fleshing out the missing parts of the net80211 802.11n support. Many thanks to him for taking the time to dissect the 802.11n spec, the Linux 802.11 stack and spend time with some APs determining what they're doing.

More wireless hackery

I've had a busy week in the land of FreeBSD wireless driver hacking.

I've been porting over the AR9280 TX calibration changes from ath9k. The AR9280 NIC in my laptop loves it - but the AR9220 based SR71-12 is still unhappy. I'll go poke around and see if I can figure out what the problem is. I have some other AR9280 series NICs to try out.

I've been using hostap mode on the AR5416 and AR9160 and it still seems quite fine and stable.

I've ported over a number of changes to the AR9285 codebase from Linux ath9k. These include:

• Fixing the TX power calibration curve code;
• Handling a TX power offset at the beginning of the calibration curve;
• Updating how the board is initially calibrated on reset;
• Adding PA calibration.

I'm also trying to remove some of the duplicate code in the HAL that has crept up as chipset support was added.

I'm waiting to hear back from some other users about what effects it has on their setup. I still have to port over the (completely rewritten) radio board configuration code from ath9k that sets up all kinds of radio related gain, offset and various things. There's also software antenna diversity to port over. I hope that this all fixes the issues users have been reporting with AR9285 NICs just plain not working in a lot of instances - but working fine in others. I also hope it fixes the AR2427 support.

I'm still very unclear what may be up with the AR9280 support. The Ubiquiti high-powered cards tend to have strange EEPROM calibration settings, so it's quite possible FreeBSD just handles one of the options badly. That's going to take some time to figure out.

There's no point in getting 802.11n support enabled if I can't TX and RX cleanly, so I'm leaving 802.11n alone (for the most part) until the radios and MACs are behaving themselves.

AR9280 TX errors - why it's important to care about how your hardware works..

One of the issues that I've been having with my AR9280 NIC is that MCS rates aren't being reliable.

Having fiddled with the TX power control with the AR9160 (and I'll write about that soon!) I remembered that badly-configured TX power control would result in the transmit side spitting out a (sometimes very) unclean spectral mask, with noise all over the place.

I did a little digging into how the AR9280 TX-side calibration works. It turns out that there's two methods of TX power control - closed-loop (with a power-detector ADC which compares the signal to a calibrated level) and open-loop (which I'm not yet sure about.) The AR9280 NIC that I have has the "open loop TX power control" bit set in the EEPROM, which indicates it needs open-loop TX power rather than closed-loop. A little digging shows that FreeBSD's HAL doesn't include closed-loop TX power control or any of the newer AR9280 calibration code (in particular the open-loop temperature compensation code.)

Long-story short, I've added the open-loop TX calibration and temperature compensation code from ath9k to the FreeBSD HAL (but I haven't yet committed it and won't until I figure out how to make it tidy) and suddenly all MCS rates TX perfectly fine.

So if you're using an AR9280 NIC, please keep a look out for when I commit this stuff and let me know if it improves things.