#9187 NORM Not Tri: tx power fixation is not working

[Zarro Boogs per Child]

#9187: tx power fixation is not working
----------------------------------------------------------+-----------------
 Reporter:  carrano                                       |                 Owner:  mbletsas     
     Type:  defect                                        |                Status:  new          
 Priority:  normal                                        |             Milestone:  Not Triaged  
Component:  wireless                                      |               Version:  not specified
 Keywords:  tx power, libertas driver, libertas firmware  |           Next_action:  diagnose     
 Verified:  0                                             |   Deployment_affected:               
Blockedby:                                                |              Blocking:               
----------------------------------------------------------+-----------------
 Recently a test kernel patch was released in order to allow testers to set
 the tx power level on the XO and study the impact of this in coverage and
 reliability of a mesh cloud, to give an example.

 But the result is not at all what we would expect and may indicate a
 software or hardware issue in the wireless subsystem. It may as well be
 only the result of the patched kernel itself, but the causes are yet to be
 uncovered.

 The test consists of computing the RX power of the beacons generated
 by the XO under test. In order to rule out environment and receiver
 factors there were three different devices collecting the data
 simultaneously and many batteries (12+) were performed at different
 moments in time to rule out transient factors like interference from other
 devices.

 Also, the collecting devices were placed in different positions two
 and the tests were repeated with 4 different units (B4s and G1G1
 units).

 The attached spreadsheet (with graphs, sorry for the proprietary format)
 indicate a very clear pattern. The rx power curves are totally consistent
 between the batteries, units and receivers, forcing a conclusion that this
 is caused by the transmitter.

 The transmitters are using firmware release 22.p23, (though release
 22.p18 presented the same results) and the test kernel in:

 http://dev.laptop.org/~dsaxena/kernels/test/kernel-2.6.25-20081208.1.olpc.txpowertest.i586.rpm

 Notes:

 - Each color corresponds to a receiver (an ASUS eee, a Thinkpad and an
 Cacetech Airpcap dongle (on a HO laptop))

 - Marvell informed that the device don't actually allow for the tuning of
 21 tx levels (0 to 20dBm) and tx levels are mapped as follows:

 0-5  -> 5 dBm

 6-10 -> 10 dBm

 11-14 -> 14 dBm

 15-20 -> 20 dBm

 meaning that "iwconfig eth0 txpower 15" and "iwconfig eth0 txpower 20"
 would result the same.

 - It is interesting to note that 7, 8 and 9 dBm result in the lowest
 transmission power (not 0 to 5 dBm as we would expect). Also it is
 intriguing that 12dBm is consistently a valley. The tests also indicate
 that 16 dBm is the setting that results in the strongest signal.

-- 
Ticket URL: <http://dev.laptop.org/ticket/9187>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system