Hi,
In rt2x00 I have made an implementation for antenna software diversity
since not all Ralink hardware supports hardware diversity (aka, almost
all Ralink hardware which set the default antenna to diversity imply
software diversity).
However I would like to know if this is something should remain inside
the driver, or if it should be moved into mac80211. Possibly integrated
into the rate selection module, or otherwise as a seperate module which
could allow the user to select a prefered antenna selection method similar
as to how he can select the prefered rate algorithm.
The current implementation in rt2x00 looks a bit like this:
Once per second the link tuner will run.
The link tuner checks if software diversity is active for either TX or RX
or both antennas.
Determine the current average rssi, and the rssi from the previous period.
If the difference between the old and new average rssi is greater than 5
configure device to swap antenna. And raise the rssi sample flag.
After another link tuning period, evaluate sample results and determine
if the antennas should be swapped or not.
The actions don't really sound hardware dependant, based on the rssi
mac80211 should be able to determine if the antenna's should be swapped
or not. All that is required is the driver indicating to mac80211 that it should
perform software diversity when required...
In mac80211 this would mean that the antenna_sel should probably become
an enum looking like this:
enum antenna_sel {
ANTENNA_SEL_DEFAULT,
ANTENNA_SEL_A,
ANTENNA_SEL_B,
ANTENNA_SEL_DIVERSITY,
};
I am not really a fan of the ANTENNA_SEL_DEFAULT, but this is already present
in the current mac80211 implementation. So to remove that, we could use some
method for the driver to let the default antenna known to mac80211, probably
through an extra field in ieee80211_hw perhaps.
The ANTENNA_SEL_DIVERSITY would in this case be hardware diversity unless
the driver has indicated that software diversity is in action, through a flag in
ieee80211_hw.
Ivo
Hi Ivo,
> However I would like to know if this is something should remain inside
> the driver, or if it should be moved into mac80211. Possibly integrated
> into the rate selection module, or otherwise as a seperate module which
> could allow the user to select a prefered antenna selection method similar
> as to how he can select the prefered rate algorithm.
I guess it would be useful for other drivers inside mac80211. Not sure
whether it should be in the rate control algorithm or not.
If it is in the rate control algorithm it could keep track of antenna
per-station to optimise the link to the station (obviously the station
still has to be in range for both antennae when it sends a frame, but
one could in theory achieve better data rates to the station with the
better antenna). On the other hand, I guess nobody would want to
implement such a thing anyway.
I think a basic implementation within mac80211 would be sufficient if
any other drivers need it.
> In mac80211 this would mean that the antenna_sel should probably become
> an enum looking like this:
>
> enum antenna_sel {
> ANTENNA_SEL_DEFAULT,
> ANTENNA_SEL_A,
> ANTENNA_SEL_B,
> ANTENNA_SEL_DIVERSITY,
> };
>
> I am not really a fan of the ANTENNA_SEL_DEFAULT, but this is already present
> in the current mac80211 implementation. So to remove that, we could use some
> method for the driver to let the default antenna known to mac80211, probably
> through an extra field in ieee80211_hw perhaps.
Sounds like a good plan, that way we could maybe even report what
antenna is used to userland.
> The ANTENNA_SEL_DIVERSITY would in this case be hardware diversity unless
> the driver has indicated that software diversity is in action, through a flag in
> ieee80211_hw.
Of course, with 11n all that is moot. Or does 11n hw use diversity for
legacy frames?
johannes
2008/1/14, Ivo van Doorn <[email protected]>:
> Hi,
>
> > > However I would like to know if this is something should remain inside
> > > the driver, or if it should be moved into mac80211. Possibly integrated
> > > into the rate selection module, or otherwise as a seperate module which
> > > could allow the user to select a prefered antenna selection method similar
> > > as to how he can select the prefered rate algorithm.
> >
> > I guess it would be useful for other drivers inside mac80211. Not sure
> > whether it should be in the rate control algorithm or not.
>
> My personal preference would be making it a seperate module.
>
> > If it is in the rate control algorithm it could keep track of antenna
> > per-station to optimise the link to the station (obviously the station
> > still has to be in range for both antennae when it sends a frame, but
> > one could in theory achieve better data rates to the station with the
> > better antenna). On the other hand, I guess nobody would want to
> > implement such a thing anyway.
> >
> > I think a basic implementation within mac80211 would be sufficient if
> > any other drivers need it.
>
> Well at least rt2x00 need it, I searched a bit through the other drivers
> and couldn't find software diversity related code. So either it is not needed
> for them, or they didn't implement it (yet).
>
In ath5k we support hw diversity but we can also force rx and tx
antenna through software (if we disable hw diversity -well it needs
some more work but it can be done, currently hw diversity is on by
default), it would be nice if someone could set the tx/rx antenna
through mac80211 (we wont have to create a driver-specific control for
that). Also in Madwifi we have software diversity (when hw diversity
is off or not supported) because some cards have misplaced stickers
etc and users tend to plug in the antenna on the non-default port
(aux) + some other cards even have bad antenna info on their eeprom,
so we check from what antenna we received more packets and we switch
to that (making it the default antenna). Anything that provides such
functionality would be nice.
In any case it would be great if there was an antenna control module
or something like that, drivers can set a capability bit (eg. supports
hw diversity, supports sw diversity, supports manual antenna setting)
and users will have a way to enable/disable hw/sw diversity or
manually set tx and rx antennas.
> > > The ANTENNA_SEL_DIVERSITY would in this case be hardware diversity unless
> > > the driver has indicated that software diversity is in action, through a flag in
> > > ieee80211_hw.
> >
> > Of course, with 11n all that is moot. Or does 11n hw use diversity for
> > legacy frames?
>
> No idea, I still have to check how rt2800pci and rt2800usb handle antenna configuration.
>
I'm not sure but it seems for 5416/5418 chips we still have diversity
controls (when i call HAL functions to enable/disable hw diversity
they still set the related registers), also there is still a field in
tx descriptor about tx antenna and the default rx antenna register.
We don't have .n support yet in Madwifi so these are only used for
legacy operation. I can't test this further because i don't want to
open my brand new macbook yet and start pluging/unpluging antennas.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
Hi,
> > However I would like to know if this is something should remain inside
> > the driver, or if it should be moved into mac80211. Possibly integrated
> > into the rate selection module, or otherwise as a seperate module which
> > could allow the user to select a prefered antenna selection method similar
> > as to how he can select the prefered rate algorithm.
>
> I guess it would be useful for other drivers inside mac80211. Not sure
> whether it should be in the rate control algorithm or not.
My personal preference would be making it a seperate module.
> If it is in the rate control algorithm it could keep track of antenna
> per-station to optimise the link to the station (obviously the station
> still has to be in range for both antennae when it sends a frame, but
> one could in theory achieve better data rates to the station with the
> better antenna). On the other hand, I guess nobody would want to
> implement such a thing anyway.
>
> I think a basic implementation within mac80211 would be sufficient if
> any other drivers need it.
Well at least rt2x00 need it, I searched a bit through the other drivers
and couldn't find software diversity related code. So either it is not needed
for them, or they didn't implement it (yet).
> > In mac80211 this would mean that the antenna_sel should probably become
> > an enum looking like this:
> >
> > enum antenna_sel {
> > ANTENNA_SEL_DEFAULT,
> > ANTENNA_SEL_A,
> > ANTENNA_SEL_B,
> > ANTENNA_SEL_DIVERSITY,
> > };
> >
> > I am not really a fan of the ANTENNA_SEL_DEFAULT, but this is already present
> > in the current mac80211 implementation. So to remove that, we could use some
> > method for the driver to let the default antenna known to mac80211, probably
> > through an extra field in ieee80211_hw perhaps.
>
> Sounds like a good plan, that way we could maybe even report what
> antenna is used to userland.
Exactly :)
> > The ANTENNA_SEL_DIVERSITY would in this case be hardware diversity unless
> > the driver has indicated that software diversity is in action, through a flag in
> > ieee80211_hw.
>
> Of course, with 11n all that is moot. Or does 11n hw use diversity for
> legacy frames?
No idea, I still have to check how rt2800pci and rt2800usb handle antenna configuration.
Ivo