[CUWiN-Dev] Transmit power control / RSS measurement

[Sven-Ola Tuecke]

Dave,

the majority of embedded devices in our mesh is running Broadcom wifi
(bcm4306 radio mostly wrt54g boxes). They run fine. But the backbone
hardware (that based on 4G-meshcubes, mips + 2*MiniPCI) has mostly PrismII.
We are looking for a good alternative for them:

PrismII: Lots of Station Firmwares versions, causes BSSID splits
  with most of them. Others do not run reliable or cause a lot of
  probs with chaotic txpwr setting.

Prism54: Not reliable (Hardmac). Hard to buy. Slow on long links
  and no distance setting for ACK-Timing changes.

BCM: No driver (no source, broadcom-silicon-backplane deps)
  OpenSource driver really not production quality in the moment.

Atheros+OldMadwifi: With our BSSID change included with one of
  the BSD devels on What-the-hack 2005 it is running OK. But the
  old MadWifi causes kernel freezes on weekly basis. Cube maintainer
  is tired of climbing the stairs up and the Cubes do not have a hardware
  watchdog.

Atheros+Madwifi-NG: Runs fine, until transmission stops in the middle
  of heavy load data transfers. No BSSID splits but seems not to be
  too reliable these days. Noticed that IBSS fixes and fiddled with own
  hacks. Does MadWifi-NG still have this "High 32 bit of TSF register
  not initialialized bug"?

Anyhow, thanks for your fast and informative answer.

Sven-Ola

----- Original Message ----- 
From: "David Young" <dyoung at pobox.com>
To: "'CUWiN Development'" <cu-wireless-dev at cuwireless.net>
Sent: Friday, April 28, 2006 3:15 AM
Subject: Re: [CUWiN-Dev] Transmit power control / RSS measurement


> On Thu, Apr 27, 2006 at 04:19:15PM +0900, Jeongkeun Lee wrote:
>> > On Thu, Apr 27, 2006 at 03:16:55PM -0500, Paul Smith wrote:
>> > > David Young wrote:
>> > >
>> > > >Transmit power is controlled by these sysctls,
>> > > >
>> > > >hw.ath0.tpscale = 0
>> > > >hw.ath0.tpc = 0
>> > > >hw.ath0.tpack = 63
>> > > >hw.ath0.tpcts = 63
>> > >
>> > > So, just to ask the naive question, if you, say, turn on TPC, with:
>> > >
>> > > $ sysctl -w hw.ath0.tpc=1
>> > >
>> > > then you can turn the other knobs and have coarsed-grain (i.e., not
>> > > at the packet-level) control over the power output of the device? And
>> > > this currently works? What values should I feed to these sysctls if
>> > > say I wanted to make my radio quieter in a lab space?
>> >
>> > I'm not sure.  Documentation is lacking in NetBSD.  Maybe it is better
>> > in FreeBSD, I haven't checked recently.  Anyway, I believe higher 
>> > values
>> > of tpscale translate to lower power.
>> >
>> > Dave
>> >
>>
>> In my CUwireless build based on the sourceforge source code distribution,
>> the output of '$ sysctl hw.ath0' does not contain 'hw.ath0.tpack' and
>> 'hw.ath0.tpcts'.
>>
>> And the tpcscale option accepts only five integers 0 to 4 as a valid
>> argument. The default is 0 and it is the highest. As I increased the
>> tpcscale value one by one at the transmitter, the RSSI at the receiver
>> (which was very close to the transmitter) showed 2~3 dB degradation.
>>
>> However, the 'tx power' field of tcpdump did not show correlated changes.
>> It was 60dBm with tpcscale 0, and changed to 54dBm, 48 dBm, 63dBm, and
>> 47dBm.
>> Another tcpdump test with a different radio card (but same CM9 model)
>> resulted in a similar phenomenon.
>
> The tx power field in the radiotap header is copied from the ni_txpower
> field of an ieee80211_node; in ad hoc mode, the ieee80211_node is the
> 802.11 layer's representation for one of its peers.  It looks to me
> like ni_txpower is only set when an ieee80211_node is created, so the
> information that the tx power field contains is probably stale.
>
> Aha!  Here is a great discussion of the fields and their meaning:
>
> http://www.mail-archive.com/madwifi-tickets@lists.sourceforge.net/msg00981.html
>
> ath_update_txpow() should probably iterate over all of the ieee80211_nodes
> and set their ni_txpower equal to ic->ic_bss->ni_txpower.
>
> Dave
>
> -- 
> David Young             OJC Technologies
> dyoung at ojctech.com      Urbana, IL * (217) 278-3933
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
>