Objective
#105: "Precise knowledge about Atheros hardware/HAL abilities to manipulate each packet's transmission power is critical for implementing dynamic Transmit Power Control."
For the purpose of any development concerning Transmit Power Control (not only a dynamic/adaptive algorithm in the future) it is needed to know whether transmit power manipulation really occurs. In other words: the dependence between transmit power value passed to the HAL and the power of received signal is to be investigated.
Procedure
Hardware
Ideally, a dedicated device for RF signal power measurement / spectrum analysis should be used. Due to lack of such an equipment, RSSI of another WiFi card has been used as the "power of received signal strength" indicator. It is not supposed to give a precise, unbiased measurement, however it seems to be enough just to show whether there is some correlation or not. Two WiFi cards that were used, one acting as a transmitter, second as a receiver. Both of them were Planet WL-8310 (2.4GHz) based on Atheros 5212 chipset along with vendor-supplied "standard" small 2dBi omnidirectional antennas.
Software
To fulfill the task, a short C utility has been written. It had an interface to MadWifi Monitor VAP and used Radiotap headers for reporting RSSI and rate of incoming packets and manipulation of txpower and rate of outgoing packets. All the packets sent contained 1500 bytes of partially-random payload. The only "non-random" part of the payload was a "magic string" to identify the packets and values of rate and txpower parameters used to send this packet. Values of txpower were random, rate was fixed (however, what appeared during the testing, rate didn't have an influence on the distribution).
An important remark: To make per-packet TPC work, it is needed to modify MadWifi to issue ath_hal_settpc(ah, 1)
Results
Using the equipment described above, the data was collected on the receiver side - a set of pairs (txpower requested by the transmitter, RSSI reported by the receiver) was obtained. The following graphs below present the dependence for a few tests conveyed. X-axis is requested transmit power [probably 0.5 dBm], Y-axis is RSSI (without noise floor) [dB].
Same polarity of transmitter and receiver antennas.
Skew (rotated by 45 degrees) polarity of transmitter and receiver antennas.
Orthogonal (rotated by 90 degrees) polarity of transmitter and receiver antennas.
No antenna at the receiver.
Conclusions
The graphs show a strong linear correlation to RSSI is visible in the range 0 to ca. 35 of requested transmit power. This is an evidence that per-packet TPC control really works and probably can be used in production code.
For txpower greater than ca. 35 no difference in RSSI distribution can be seen in the graphs. It seems possible that the unit of "txpower" is 0.5dBm (as noticed somewhere in the MadWifi code) and that 36 corresponds to 18dBm - the maximum power that card is able to transmit at - hence the "clamping" in the graph.
There is an interesting phenomenon concerning RSSI values. It seems that when RSSI is going to reach more than ca. 60dB, the result becomes "unstable" and oscillates between around a few fixed values. This fact is also noticeable in stable and more "standard" environment e.g. while tracing Beacon Frames of nearby AP with tcpdump. The issue probably concerns the RSSI measurement inside the HW or HAL.
Attachments
- same_polarity.png (3.7 kB) -
per-packet TPC test performed with two aligned 2dBi omnidirectional antennas
, added by xmxwx on 03/04/07 01:29:35. - skew_polarity.png (3.9 kB) -
per-packet TPC test performed with two, mutually rotated by 45 degrees, 2dBi omnidirectional antennas
, added by xmxwx on 03/04/07 01:31:17. - orthogonal_polarity.png (4.4 kB) -
per-packet TPC test performed with two, mutually rotated by 90 degrees, 2dBi omnidirectional antennas
, added by xmxwx on 03/04/07 01:31:45. - no_antenna.png (3.5 kB) -
per-packet TPC test performed with on 2dBi omnidirectional antenna (transmitter) and an open RP-SMA connector (receiver)
, added by xmxwx on 03/04/07 01:33:03.




